I'm using this compiler to compile the same version of the gcc for NetBSD/hcpsh host: shle--netbsdelf build: i386--freebsd4.8 target: shle--netbsdelf configured with: ../configure --prefix=/var/tmp/xtarget --target=shle--netbsdelf --host=shle--netbsdelf --build=i386--freebsd4.8 --disable-multilib --disable-shared --enable-languages=c While compiling function.c the warning about `and' of mutually exclusive equal-tests is always 0 is produced: shle--netbsdelf-gcc -save-temps -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include ../../gcc/function.c -o function.o ../../gcc/function.c: In function `aggregate_value_p': ../../gcc/function.c:4283: warning: suggest parentheses around && within || ../../gcc/function.c: In function `assign_parms': ../../gcc/function.c:4740: warning: `and' of mutually exclusive equal-tests is always 0 I saw this warning with gcc-3.3 release and also with gcc-3.3.1 release as imported into the NetBSD source tree. The warning is triggered by turning optimization on. Compiling with -O0 doesn't produce the warning. The warning about line 4283 is not present for 3.3 and 3.3.1 releases and is not pertinent to this bug report. The offending line is: else if (PARM_BOUNDARY % BITS_PER_WORD != 0) that expands to: else if (((target_flags & (1<<0)) ? 64 : 32) % (8 * (((target_flags & (1<<0)) && ! (target_flags & (1<<8))) ? 8 : 4)) != 0) In particular the following subexpression causes the warning: ((target_flags & (1<<0)) && ! (target_flags & (1<<8))) which is just the TARGET_SHMEDIA macro that is used all over the place without any problems. I did some debugging (sorry, but I know next to nothing about gcc internals) and if I'm reading the output of dump_node correctly, the fold-const.c:fold_truthop() complains about the tree that corresponds to the following C expression: ((target_flags & 0x101) == 1) && ((target_flags & 1) == 0) where the first occurence of `target_flags' is actually a bit_field_ref node. Now, the lhs of this `and' is the correct folding of the ((target_flags & (1<<0)) && ! (target_flags & (1<<8))) TARGET_SHMEDIA macro, but I have no idea where the rhs comes from. After looking through the ChangeLog I thought that might be some shared structures are modified, so I tried to apply the fix from the gcc-3_3-rhl-branch: * fold-const.c (fold): Never modify argument passed to fold, instead change a copy and return it. * convert.c (convert_to_integer): Likewise. by pulling the following diffs: convert.c: 1.19 -> 1.19.18.1 fold-constant.c: 1.227.2.3.4.1 -> 1.227.2.3.4.2 but that didn't help (same warning) and didn't produce any errors with ENABLE_FOLD_CHECKING. This warning seems to indicate a bug in optimizer. gcc-3.4-20030813 snapshot does not have this problem. However, since the next release of NetBSD will be using gcc 3.3.1 as the system compiler, it would be very nice to have a fix or a work-around for this bug on the 3.3 branch. Environment: System: FreeBSD vortex.sparc.spb.su 4.8-STABLE FreeBSD 4.8-STABLE #0: Wed Jun 4 13:52:39 MSD 2003 root@vortex.sparc.spb.su:/usr/obj/usr/src/sys/VORTEX i386 host: i386-unknown-freebsd4.8 build: i386-unknown-freebsd4.8 target: shle--netbsdelf configured with: ../configure --prefix=/var/tmp/xtools --target=shle--netbsdelf --disable-multilib --disable-shared --enable-languages=c How-To-Repeat: With a gcc from the 3.3 branch targeting shle--netbsdelf (probably, any SuperH target) try to compile the following file:
Created attachment 4614 [details] Source file that demonstrates the problem. Oops, it seems that the uuencoded file I included into the PR didn't make it to bugzilla.
Do you know if this is a regression from an earlier GCC?
Subject: Re: [3.3 only] bogus warning while compiling gcc/function.c gcc-2.95.3 (system compiler) that is used to build this gcc-3.3.1 sources as a cross compiler targeting superh compiles this file without that warning. when the resulting gcc-3.3.1 is used to compile the same gcc-3.3.1 sources as the native compiler to be run on the superh host, I get this warning. So this is a regression from 2.95 series.
Thanks I do not know if it is going to be fixed for 3.3.x as it is already fixed in 3.4.
I can reproduce the following warning on powerpc-apple-darwin6.6 in 3.3.2 (20030815): test1.c: In function `f': test1.c:6: warning: `and' of mutually exclusive equal-tests is always 0 It also happens on i686-pc-linux-gnu. The code: int target_flags; int f() { return (((target_flags & (1<<0)) ? 64 : 32) % (8 * (((target_flags & (1<<0)) && ! (target_flags & (1<<8))) ? 8 : 4)) != 0) ; } It does not happen in 3.1 (20020420). Broken : Search converges between 2002-06-02-trunk (#80) and 2002-07-14-trunk (#81). Fixed: Search converges between 2003-07-02-trunk (#331) and 2003-07-03-trunk (#332). Here are two changes on the July 2 which might have fixed this: 2003-07-02 Jeff Law <-- this one needs another patch fix fix a regression which it caused * expr.c (do_store_flag): Remove special case folding for single bit tests. Instead call back into the commonized folder routine. * fold-const.c (fold_single_bit_test): New function, mostly extracted from do_store_flag, with an additional case extracted from fold. (fold): Call fold_single_bit_test appropriately. * tree.h (fold_single_bit_test): Prototype. 2003-07-02 Eric Botcazou PR optimization/11210 * expr.c (handled_component_p) [NOP_EXPR]: Add ??? note about the behaviour with regard to bitfields. * fold-const (decode_field_reference): Record outermost type in case the expression is a NOP. Strip all NOPs. Set the signedness to that of the outermost type (if any) when the bitsize is equal to the size of the type.
Subject: Re: [3.3 Regression] bogus warning while compiling gcc/function.c Doh. I tried to come up with a minimal test case like this, but neither my test, nor yours give me the warning. Thanks a lot, I will try those changes.
Subject: Re: [3.3 Regression] bogus warning while compiling gcc/function.c The warning goes away after applying expr.c: 1.561, 1.562 fold-const.c: 1.273, 1.276 tree.h: 1.419 to the gcc-3.3 branch (patches applied cleanly, with offset). Relevant changelog entries: 2003-07-04 Jeff Law <law@redhat.com> PR c/11428 * expr.c (do_store_flag): Pass in the correct result type when calling fold_single_bit_test. * fold-const.c (fold_single_bit_test): Use result_type for the result when folding a sign bit test. 2003-07-02 Jeff Law <law@redhat.com> * expr.c (do_store_flag): Remove special case folding for single bit tests. Instead call back into the commonized folder routine. * fold-const.c (fold_single_bit_test): New function, mostly extracted from do_store_flag, with an additional case extracted from fold. (fold): Call fold_single_bit_test appropriately. * tree.h (fold_single_bit_test): Prototype. Thanks!
Subject: Re: [3.3 Regression] bogus warning while compiling gcc/function.c On Sat, Aug 16, 2003 at 06:18:50 +0400, Valeriy E. Ushakov wrote: > The warning goes away after applying > > expr.c: 1.561, 1.562 > fold-const.c: 1.273, 1.276 > tree.h: 1.419 It probably also needs fold-const.c 1.280, as c/11449 blames fold-const.c 1.273 2003-07-10 Kazu Hirata <kazu@cs.umass.edu> PR c/11449 * fold-const.c (sign_bit_p): Return EXP if VAL is the sign bit of HOST_WIDE_INT. (fold_single_bit_test): If sign_bit_p() fails, assume that the bit being tested is not a sign bit.
Thanks for looking into it and finding the patch which fixes it. Jeff could ask for inclusion for 3.3.2? <http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00299.html>
If someone would post the exact patch to review for 3.3.2, that would be great.
Created attachment 4707 [details] Relevant fix(es) from -current as applied to the NetBSD in-tree import of gcc-3.3.1 This patch was done by taking these revisions from gcc-current and applying them to gcc-3.3.1 (as imported into NetBSD tree). Th diffs applied cleanly. expr.c: 1.561, 1.562 fold-const.c: 1.273, 1.276, 1.280 tree.h: 1.419 ChangeLog entries are in previous comments. With these diffs the NetBSD world compiles cleanly, though I haven't had a chance to do much testing yet.
The changes required are too invasive for GCC 3.3.x.