We found an interesting bootstrap failure in gcc after changing a machine
definition some, the important bits are below.  Something is wrong, but it is
hard to say exactly what.  The warning would be fine, if there were no
preprocessor involved.  But, it is.  The warning doesn't make any sense for the
source in stmt.c, and the definitions in insn-*.h are also valid.  When the
preprocessor combines them, then the result is worthy of warning about, but,
that's hardly the fault of stmt.c, or the machine definition.  Logically, we
want to only issue the warning if the code in question came from the user, not
as a combination of macro preprocessing.  I can't recall any other place in the
compiler when we take into consideration the preprocessor like this, so that
makes this case weird in my book.

So, some solutions:

  Don't use -Werror, because stmt.c can warn on some .md files.
  Remove the warning, the benefit isn't work the risk of false positives.
  Keep the warning, but somehow take into consideration the preprocessor (ick).
  Recode how the insn-*.h files are generated to avoid the warning.
  Redo stmt.c to use a local variable and then use that in the conditional.

Thoughts?  Currently we're taking the last approach, but it just feels icky. 
Longer term, would be nice if gcc were architected so that this can't crop up.

$ cat /tmp/t.c
extern int target_flags;
#define ARM ((target_flags & (1 << 16)) != 0)
#define THUMB (!ARM)
#define LONGCALL ((target_flags & (1 << 11)) != 0)

#define ARMLONGCALL ((target_flags & ((1<<16) | (1<<11))) != 0)

// 4.2 version:
//#define HAVE_tablejump (ARM || LONGCALL)
// shows same problem in 4.4
#define HAVE_tablejump (ARMLONGCALL)
#define HAVE_casesi (THUMB)

void foo();

void expand_case()
{
  if (0
      /* If neither casesi or tablejump is available, we can                    
         only go this way.  */
      || (!HAVE_casesi && !HAVE_tablejump))
    foo();
}
$ ./xgcc -B./ -c /tmp/t.c -O    
/tmp/t.c: In function 'expand_case':
/tmp/t.c:21: warning: 'and' of mutually exclusive equal-tests is always 0

gcc version 4.4.0 20081003 (experimental) [trunk revision 140855] (GCC)


-- 
           Summary: incorrect warning from fold
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mrs at apple dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37864

Reply via email to