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)