User account creation filtered due to spam.

Bug 37864 - warning from fold looks at macro expansion
Summary: warning from fold looks at macro expansion
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on:
Reported: 2008-10-17 19:44 UTC by Mike Stump
Modified: 2012-05-14 11:18 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2012-05-14 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Stump 2008-10-17 19:44:15 UTC
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))
$ ./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)
Comment 1 Richard Biener 2008-10-18 11:22:46 UTC
I don't see where the bug is here.  So let's turn this into an enhancement
request - to what? - emit these kinds of diagnostics from the preprocessor?

IMHO not a very sane request.
Comment 2 Manuel López-Ibáñez 2008-10-18 15:07:23 UTC
We do not have any way to know that something comes from preprocessor expansion.
Comment 3 Manuel López-Ibáñez 2012-05-14 11:18:24 UTC
This should be possible now that we track macro expansion. It only needs someone to implement it.