Bug 215333 - head -r310046 for powerpc family: sys/powerpc/powerpc/intr_machdep.c's i->trig == -1 if-tests reported as always false by compiler
Summary: head -r310046 for powerpc family: sys/powerpc/powerpc/intr_machdep.c's i->tri...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: powerpc Any
: --- Affects Only Me
Assignee: Justin Hibbits
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-16 07:54 UTC by Mark Millard
Modified: 2017-04-01 19:32 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2016-12-16 07:54:36 UTC
--- intr_machdep.o ---
/usr/src/sys/powerpc/powerpc/intr_machdep.c:454:15: warning: comparison of constant -1 with expression of type 'enum intr_trigger' is always false [-Wtautological-constant-out-of-range-compare]
              if (i->trig == -1)
                  ~~~~~~~ ^  ~~
/usr/src/sys/powerpc/powerpc/intr_machdep.c:500:16: warning: comparison of constant -1 with expression of type 'enum intr_trigger' is always false [-Wtautological-constant-out-of-range-compare]
                      if (i->trig == -1)
                          ~~~~~~~ ^  ~~

Justin Hibbits wrote about the note that I sent him that listed the above:

This may or may not be a problem, depending on optimization settings.  Can you file a bug for this so it doesn't get lost?


I also noted:

There are other comparisons around with a constant
result at compile time. But they tend to be in less
central areas like zfs. Similarly for some other
types of compiler reports.
Comment 1 Mark Millard 2016-12-17 21:55:35 UTC
(In reply to Mark Millard from comment #0)

This is more likely a kernel source code issue than a toolchain issue as far as
I know: It is  not a claim that the compiler's report is wrong.

More likely the source code violates a C rule in a way that the compiler is
allowed any handling. That handling can change with optimization level and
at some optimization levels it might appears to be working even though the
language standard makes no such guarantees.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2016-12-18 02:20:34 UTC
Submitter notes that this is more likely an issue of the src code itself.
Comment 3 Justin Hibbits freebsd_committer 2017-01-30 05:29:34 UTC
Fixed in r312974, to be MFC'd with the other clang bits.
Comment 4 Justin Hibbits freebsd_committer 2017-04-01 19:32:20 UTC
MFC'd to stable/11 r316369