This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/37864] New: incorrect warning from fold
- From: "mrs at apple dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 17 Oct 2008 19:44:16 -0000
- Subject: [Bug middle-end/37864] New: incorrect warning from fold
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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