[Bug c/87588] New: gcc does not warn about unused about unused variable which references to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87588
Bug ID: 87588
Summary: gcc does not warn about unused about unused variable
which references to itself
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at breakpoint dot cc
Target Milestone: ---
The .c file:
>8-
struct list {
struct list *prev, *next;
};
struct mutex {
struct list waiters;
};
static struct mutex mutex = \
{.waiters = {.prev = , .next = }};
static int a;
static int *b =
>8-
produces:
gcc -o a.o a.c -c -O2 -Wall
a.c:14:13: warning: 'b' defined but not used [-Wunused-variable]
14 | static int *b =
| ^
Would it be possible to also warn that the variable 'mutex' is unused? Except
that its member (.list.prev) is referenced to itself, it is not used outside of
that "initialization" construct.
[Bug target/69124] arm miss compiled code since gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 --- Comment #3 from Sebastian Andrzej Siewior --- gcc -v Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 5.3.1 20151219 (Debian 5.3.1-4) gcc -o fp_mul fp_mul_comba_32.c -g -O2 -march=armv7-a -mtune=cortex-a9 -mhard-float -mfpu=vfpv3-d16 gcc -o fp_mul-nt fp_mul_comba_32.c -g -O2 -march=armv7-a -mhard-float -mfpu=vfpv3-d16 (sid_armhf-dchroot)bigeasy@harris:~/tc$ ./fp_mul (sid_armhf-dchroot)bigeasy@harris:~/tc$ ./fp_mul-nt 27 0x0a7d8ff8 != 0xce804437 28 0x1c8a1f70 != 0x1c8a1f6f -> 3 So it does not trigger here with -mtune=cortex-a9 as well. Do you know what is selected for -mtune as default if it is not specified at build-time? I tried with cortex-a7 but it does not trigger :/
[Bug target/69124] New: arm miss compiled code since gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 Bug ID: 69124 Summary: arm miss compiled code since gcc 5 Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc at breakpoint dot cc Target Milestone: --- Host: arm-linux-gnueabihf Target: arm-linux-gnueabihf Build: arm-linux-gnueabihf Created attachment 37213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37213=edit test case, fp_mul_comba_32.c Attached a testcase that miss compiles on ARM since gcc-5 (Debian gcc, built with --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard). gcc -o fp_mul fp_mul_comba_32.c -O2 -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations ./fp_mul 27 0x0a7d8ff8 != 0xce804437 28 0x1c8a1f70 != 0x1c8a1f6f -> 3 I don't see this with problem with -O1, or arm-linux-gnueabi target (i.e. no output). The bug does not trigger with -fsanitize=undefined but it does not show any output.
[Bug target/69124] arm miss compiled code since gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 --- Comment #1 from Sebastian Andrzej Siewior --- Created attachment 37214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37214=edit -E output of the test case
[Bug rtl-optimization/64294] invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294 --- Comment #8 from Sebastian Andrzej Siewior gcc at breakpoint dot cc --- Created attachment 34305 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34305action=edit self-contained complete TC
[Bug rtl-optimization/64294] invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294 --- Comment #9 from Sebastian Andrzej Siewior gcc at breakpoint dot cc --- I added the complete function including its callers. $ gcc -g -o petite petite.c -Wall -O2 $ ./petite 447= 5 452= 5 447= 5 452= 5 447= 0 452= 0 Segmentation fault --- $ gcc -g -o petite petite.c -Wall -O1 $ ./petite 447= -12 -1 As you see the value in line 447 is different in -O2 vs -O1. And with -O2 it continues with 0 to start the loop. I have to run now, maybe I have later some time to figure out why the value in line 447 is different in -O2 vs -O1.
[Bug rtl-optimization/64294] invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294 Sebastian Andrzej Siewior gcc at breakpoint dot cc changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Sebastian Andrzej Siewior gcc at breakpoint dot cc --- (In reply to Mikael Pettersson from comment #10) You're invoking undefined behaviour due to overflow in signed integer arithmetic. Sir, you made my day. So it is undefained behaviour and showed me even how to catch those things. Thank you.
[Bug rtl-optimization/64294] invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294 Sebastian Andrzej Siewior gcc at breakpoint dot cc changed: What|Removed |Added Known to work||4.7.2 --- Comment #6 from Sebastian Andrzej Siewior gcc at breakpoint dot cc --- I just reprduced this on arm-linux-gnueabi. Unless there is something wrong with the code, this isn't x86 specific as the Target suggests.
[Bug rtl-optimization/64294] invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294 Sebastian Andrzej Siewior gcc at breakpoint dot cc changed: What|Removed |Added Attachment #34272|0 |1 is obsolete|| --- Comment #3 from Sebastian Andrzej Siewior gcc at breakpoint dot cc --- Created attachment 34275 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34275action=edit tc-macro version
[Bug rtl-optimization/64294] invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294 --- Comment #4 from Sebastian Andrzej Siewior gcc at breakpoint dot cc --- Created attachment 34276 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34276action=edit tc-static function
[Bug rtl-optimization/64294] invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294 Sebastian Andrzej Siewior gcc at breakpoint dot cc changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Sebastian Andrzej Siewior gcc at breakpoint dot cc --- I re-open it. This time I attached the whole .i twice: - macro contains the second CLI_ISCONTAINED() invocation as a macro - static contains the second CLI_ISCONTAINED() as a static function The first one (macro) segfaults, the second one (static) works as a expected. The only obvious change I made in the static version is that the size argument is not signed but unsigned. Changing the type of sb_size to signed int results in the segfault again. I saw this problem with gcc-4.8 and 4.9. gcc 4.7 seems not to miss compile it. Comparing the disassemble between those two .i I see: - macro + static label: - 8b 44 24 44 mov0x44(%esp),%eax - 89 c1 mov%eax,%ecx + 8b 44 24 20 mov0x20(%esp),%eax + 85 c0 test %eax,%eax + 0f 84 8c fb ff ff je 3f0 petite_inflate2x_1to9+0x3f0 + 8b 4c 24 58 mov0x58(%esp),%ecx + 8b 44 24 20 mov0x20(%esp),%eax For me as a no-compiler guy it looks like the zero check has been removed because for some reason the size argument has to be != 0. I'm not sure if this is related but #26763 fixed a problem with the same macro. Sebastian
[Bug rtl-optimization/64294] New: invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294
Bug ID: 64294
Summary: invalid code, zero check gets optimized away
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at breakpoint dot cc
Created attachment 34272
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34272action=edit
the testcase
The testcase is a minimized / cut-out of some code which basically does:
if (!backsize)
exit(11);
while(backsize--) {
*ddst=*(ddst+backbytes);
ddst++;
}
gcc somehow assumes that backsize can't get zero which it can. I added an 'asm
volatile(labele:);' statement so the check can be easy spotted. At -O2 gcc
produces:
020a labele:
20a: 8b 44 24 20 mov0x20(%esp),%eax
20e: 66 90 xchg %ax,%ax
210: 0f b6 54 0d 00 movzbl 0x0(%ebp,%ecx,1),%edx
215: 83 c5 01add$0x1,%ebp
218: 88 55 ffmov%dl,-0x1(%ebp)
21b: 39 e8 cmp%ebp,%eax
21d: 75 f1 jne210 labele+0x6
So it copies the first byte before checking for equal/zero.
With -O1 instead:
028a labele:
28a: 85 f6 test %esi,%esi
28c: 75 0a jne298 labele+0xe
28e: 83 ec 0csub$0xc,%esp
291: 6a 0b push $0xb
293: e8 fc ff ff ff call 294 labele+0xa
294: R_386_PC32 exit
298: 8b 5c 24 10 mov0x10(%esp),%ebx
29c: 8b 54 24 2c mov0x2c(%esp),%edx
2a0: 0f b6 0c 13 movzbl (%ebx,%edx,1),%ecx
2a4: 88 0b mov%cl,(%ebx)
2a6: 83 c3 01add$0x1,%ebx
2a9: 39 d8 cmp%ebx,%eax
2ab: 75 f3 jne2a0 labele+0x16
There is the 0 check withint the first two opcodes including the exit(0)
statement.
[Bug rtl-optimization/64294] invalid code, zero check gets optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294
--- Comment #2 from Sebastian Andrzej Siewior gcc at breakpoint dot cc ---
It seems exit(0) is dropped with -O1 -ftree-vrp.
(In reply to Andreas Schwab from comment #1)
This condition is true if backsize == 0:
Ehm, yes. The Code is:
--
printf(bufsz: %u backsize: %d\n, bufsz, backsize);
if(!CLI_ISCONTAINED(buf, bufsz, ddst, backsize) || !CLI_ISCONTAINED(buf, bufsz,
ddst+backbytes, back size)) {
free(usects);
return 1;
}
asm volatile(labele:);
--
So I would expect that it leaves the function but I see a segfault in the while
loop later on and according the printf, backsize was 0.
[Bug other/44116] 64bit inodes for source code causes Value too large for defined data type (XFS,inode64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44116 Sebastian Andrzej Siewior gcc at breakpoint dot cc changed: What|Removed |Added CC||gcc at breakpoint dot cc, ||iant at google dot com --- Comment #5 from Sebastian Andrzej Siewior gcc at breakpoint dot cc 2013-02-07 21:17:46 UTC --- I run into this myself today with an older compiler. This has been fixed in svn commit 166230. The fix is part of gcc-4.6.0+ and it does not look like it has been backported. It can be closed now :)
[Bug rtl-optimization/55396] -O2 -m32 -fno-omit-frame-pointer: internal compiler error: in check_rtl, at lra.c:2007
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55396 Sebastian Andrzej Siewior gcc at breakpoint dot cc changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Sebastian Andrzej Siewior gcc at breakpoint dot cc 2012-11-21 20:24:54 UTC --- (In reply to comment #2) Author: vmakarov Date: Tue Nov 20 21:32:59 2012 New Revision: 193678 yup, that works. Thanks. Sebastian
[Bug rtl-optimization/55396] New: -O2 -m32 -fno-omit-frame-pointer: internal compiler error: in check_rtl, at lra.c:2007
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55396 Bug #: 55396 Summary: -O2 -m32 -fno-omit-frame-pointer: internal compiler error: in check_rtl, at lra.c:2007 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@breakpoint.cc Created attachment 28736 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28736 pre-processed file Compiling the linux kernel ends with: |kernel/sched/core.c: In function '__schedule': |kernel/sched/core.c:2891:1: internal compiler error: in check_rtl, at lra.c:2007 | } | ^ While removing Compiler options the ICE goes away if one of the following options is removed: -O2 -m32 -fno-omit-frame-pointer gcc -v says: Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.8.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20121116-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-snap --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.0 20121116 (experimental) [trunk revision 193562] (Debian 20121116-1)
[Bug tree-optimization/52798] New: __builtin_object_size() based overflow check is a false positive due to parameter optimisation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52798
Bug #: 52798
Summary: __builtin_object_size() based overflow check is a
false positive due to parameter optimisation
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@breakpoint.cc
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
This is slightly modified from linux kernel fs/binfmt_misc.c:
static int parse_command(const char __user *buffer, size_t count)
{
char s[40];
if (!count)
return 0;
if (count 3)
return -EINVAL;
if (count == 1 || count == 2 || count == 3)
if (copy_from_user(s, buffer, count))
return -EFAULT;
if (copy_from_user(s, buffer, count))
return -EFAULT;
}
Each copy_from_user() has a __builtin_object_size() based check for length of s
vs length specified in count. The s buffer is 40bytes, we return if count 3.
copy_from_user() produces a #error/#warning for in the overflow case where
count is larger than s.
Since we do check for count 3 and abort, there is no overflow.
gcc on the other hand detects one. Both calls are in my opinion the same. Using
only the first check (count ==1 || count...) avoids the warning, the second
triggers the warning.
The short version of the assembly looks the following way (param via regs in
x86-32, count in edx):
07e0 parse_command.part.2:
8d 72 fflea-0x1(%edx),%esi
83 fe 02cmp$0x2,%esi
77 5d ja 858 parse_command.part.2+0x78
(esi - 1) compared against 2, so this is the 3 check (and 0 I guess).
#1 call to the copy routine
89 d9 mov%ebx,%ecx
89 fa mov%edi,%edx
e8 fc ff ff ff call 81a parse_command.part.2+0x3a
#2 call to the copy routine. There is no check for ebx/ecx in between, so the
count check from #1 is
recognized as unchanged and valid.
This looks to me like gcc knows the exact (and correct) size of s in both cases
but somehow an optimization pass removes it (because it redundant) and the gcc
threats it as not available and therefore produces the warning.
The copy routine looks the following:
static inline unsigned long __must_check copy_from_user(void *to,
const void __user *from,
unsigned long n)
{
int sz = __compiletime_object_size(to);
/* asm volatile(); */
if (likely(sz == -1 || sz = n))
n = _copy_from_user(to, from, n);
else
copy_from_user_overflow();
return n;
}
Adding the asm volatile statement (where it is commented out) adds the
follwoing code before the second call:
83 fb 28cmp$0x28,%ebx
77 65 ja 875 parse_command.part.2+0x95
So here the compiler really assumes that there is no upper limit of count.
I attach the .i output of the testcase which can be compiled with:
gcc -O2 -m32 -pipe -c -o binfmt_misc.o binfmt_misc.i
The outout error: call to ‘co.. is returned if gcc detects the overflow.
Sebastian
[Bug tree-optimization/52798] __builtin_object_size() based overflow check is a false positive due to parameter optimisation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52798 --- Comment #1 from Sebastian Andrzej Siewior gcc at breakpoint dot cc 2012-03-30 21:54:33 UTC --- Created attachment 27051 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27051 .i test case
[Bug target/44606] Wrong SPE floating point during computation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606 --- Comment #17 from Sebastian Andrzej Siewior gcc at breakpoint dot cc 2011-03-17 13:02:58 UTC --- (In reply to comment #16) Does the testcase still test for the problem if you replace the declarations of stderr etc. with #include stdio.h? This fails with link errors of the unresolved reference to stderr variety on newlib targets. As long as your stdio.h does not optimize fprintf away it should work :)
[Bug boehm-gc/41208] illegal instruction lwsync reported on e500
--- Comment #1 from gcc at breakpoint dot cc 2010-07-01 17:12 --- This can be closed IMHO. In latest binutils (those in trunk) lwsync is turned into in an (m)sync if -me500 is specified. boehm-gc upstream is fixed since they use .long right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41208
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #49 from gcc at breakpoint dot cc 2010-06-28 11:18 --- Modified: trunk/gcc/ChangeLog trunk/gcc/caller-save.c trunk/gcc/config/rs6000/e500.h Is it possible to get this into the 4.4 and 4.5 branch as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug rtl-optimization/44605] New: Wrong floating point on
-- Summary: Wrong floating point on Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-linux-gnuspe GCC host triplet: powerpc-linux-gnuspe GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44605
[Bug rtl-optimization/44605] Wrong floating point on
--- Comment #1 from gcc at breakpoint dot cc 2010-06-21 07:56 --- was too early -- gcc at breakpoint dot cc changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Wrong floating point on |Wrong floating point on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44605
[Bug tree-optimization/44606] New: Wrong SPE floating point during computation
I attached two testcase which is stripped down graphicsmagick code. tc-resize2.c has a few instructions more than tc-resize.c. I belive the bug is the same. gcc -o tc2 -O0 -Wall -Wextra tc-resize.c gcc -o tc2 -O2 -Wall -Wextra tc-resize.c ( ./tc0 ; echo -; ./tc2 ) .19 2484.00 .21 2700.00 .23 2916.00 .24 3132.00 .26 3348.00 - .0 2484.00 .0 2700.00 .0 2916.00 .0 3132.00 .0 3348.00 gcc -o tc20 -O0 -Wall -Wextra tc-resize2.c gcc -o tc22 -O2 -Wall -Wextra tc-resize2.c ( ./tc20 ; echo -; ./tc22 ) .26 3264.00 .28 3520.00 .30 3776.00 .32 4032.00 .34 4288.00 - .14 1734.00 .15 1870.00 .16 2006.00 .17 2142.00 .18 2278.00 Now here is stripped down output of the assembly file: MinifyImage: evstdd 26,88(11) .L9: li 26,0 stw 26,64(1) .L11: #APP # 105 tc-resize.c 1 nop # 0 2 #NO_APP lis 19,@ha efdmul 5,9,26 r26 should be 0.0078125 but is 0 r26 bits 32..63 are, dunno about 0..31 la 19,@l(19) evldd 19,0(19) r19 is 0.5 efdadd 5,5,19 r5 is expected to be .5 efdctuiz 5,5r5 is 0 rlwinm 5,5,0,0xff #APP # 107 tc-resize.c 1 nop # 0 2 #NO_APP evmergehi 6,9,9 mr 7,9 mr 8,7 mr 7,6 crxor 6,6,6 that should be 9,9,9 but is a different issue :) bl fprintf # r5 int (bad), r6 pad, r7 r8 double r26 is zero and that is wrong. I belive 1/128.0 gets replaced by 0.0 and optimized. Sebastian -- Summary: Wrong SPE floating point during computation Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-linux-gnuspe GCC host triplet: powerpc-linux-gnuspe GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug tree-optimization/44606] Wrong SPE floating point during computation
--- Comment #1 from gcc at breakpoint dot cc 2010-06-21 09:10 --- Created an attachment (id=20950) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20950action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug tree-optimization/44606] Wrong SPE floating point during computation
--- Comment #2 from gcc at breakpoint dot cc 2010-06-21 09:10 --- Created an attachment (id=20951) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20951action=view) slightly extended tc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug tree-optimization/44606] Wrong SPE floating point during computation
--- Comment #3 from gcc at breakpoint dot cc 2010-06-21 09:11 --- Created an attachment (id=20952) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20952action=view) -S output of the first tc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #37 from gcc at breakpoint dot cc 2010-06-09 07:50 --- Created an attachment (id=20873) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20873action=view) this fails to compile in -O2 with the fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #38 from gcc at breakpoint dot cc 2010-06-09 07:54 --- (In reply to comment #28) Please bootstrap and test this addition to e500.h /* When setting up caller-save slots (MODE == VOIDmode) ensure we allocate space for DFmode. Save gprs in the correct mode too. */ #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \ (TARGET_E500_DOUBLE ((MODE) == VOIDmode || (MODE) == DFmode) \ ? DFmode \ : choose_hard_reg_mode ((REGNO), (NREGS), false)) Okay. Now I found something: inst/bin/powerpc-linux-gnuspe-gcc extract_chmLib.i -o extract_chmLib.S -S -O2 extract_chmLib.c: In function '_extract_callback': extract_chmLib.c:29: internal compiler error: in change_address_1, at emit-rtl.c:1954 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. extract_chmLib.i is attached. Adding -mfloat-gprs=single which avoids using 64bit gprs for double makes this go away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #42 from gcc at breakpoint dot cc 2010-06-09 13:52 --- (In reply to comment #41) The ICE in #38 is due to a bug in caller-save.c Thank you for the very quick fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #34 from gcc at breakpoint dot cc 2010-06-08 11:23 --- (In reply to comment #28) #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \ (TARGET_E500_DOUBLE ((MODE) == VOIDmode || (MODE) == DFmode) \ ? DFmode \ : choose_hard_reg_mode ((REGNO), (NREGS), false)) I applied it on 4.4 branch. The big Perl thing is passes its testsuite with this. Also I don't see evldd X, stw X, ld X constructs, there is just one evldd. It looks good so far. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
--- Comment #3 from gcc at breakpoint dot cc 2010-06-07 04:21 --- Thank you Alan. Trunk and 4.5 branch is affected, the 4.4 branch just built. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #5 from gcc at breakpoint dot cc 2010-06-03 20:17 --- So clearly the caller's assembly is wrong; it should be saving all 64-bits of r9 (volatile gpr) first. Yes, that it what I've been pointing out. There is an optimization in the stack code which uses 32bit stores/loads if no double types are used. I looks to me like the functions branch and register saves are done by the RTL and it does not know about the 64bit GPRs here. This is only a guess, I'm not a gcc guy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug rtl-optimization/44364] New: Wrong code with e500 double floating point
The testcase (which is stripped down perl code) attached compiled with: gcc -fPIC -fno-strict-aliasing -pipe \ -O2 \ -g -o tc-lossings-floats tc-lossings-floats.c -Wall -mno-isel results in after executing: |RESET: 252.00 | 0.00 |RESET: 504.00 | 252.00 |RESET: 756.00 | 504.00 |RESET: 1008.00 | 756.00 |RESET: 1260.00 | 1008.00 |RESET: 1512.00 | 1260.00 |RESET: 1764.00 | 1512.00 |RESET: 2016.00 | 1764.00 |RESET: 2268.00 | 2016.00 = 2268.00 |RESET: 2520.00 | 0.00 |RESET: 2772.00 | 2520.00 With -O1 instead -O2: |RESET: 252.00 | 0.00 |RESET: 504.00 | 252.00 |RESET: 756.00 | 504.00 |RESET: 1008.00 | 756.00 |RESET: 1260.00 | 1008.00 |RESET: 1512.00 | 1260.00 |RESET: 1764.00 | 1512.00 |RESET: 2016.00 | 1764.00 |RESET: 2268.00 | 2016.00 = 2268.00 |RESET: 2520.00 | 2268.00 |RESET: 2772.00 | 2520.00 The = line sets the the second value in the |RESET line. With -O1 is remains where it is, with -O2 it gets overwritten. The original perl code gets here a totally random values. Now. It is getting better. The source compiled with -S and the resulting assembly file assembled with gcc-4.3 does not show this problem. After diffing of the two resulting binaries I saw a difference in __floatdidf() which is called from Kino_OutStream_tell(). The variant which is attached by the 4.3 compiler does not use floating point instead it uses integer code which calls other functions (__floatsidf, __muldf3, __floatunsidf, __adddf3) which use also interger code. The 4.3 compiler was not compiled with --enable-e500_double. So after looking at the code I saw now the following: 1c24 __floatdidf: 1c6c: 11 23 1a 2c evmergehi r9,r3,r3 This function is touching the complete 64bit r9 register The code which calls it: 1a40: 91 21 00 20 stw r9,32(r1) 1a44: 4e 80 04 21 bctrl # tell function which in turn calls floatdidf 1a7c: 81 21 00 20 lwz r9,32(r1) 1a80: 38 60 00 00 li r3,0 1a84: 7e 33 8b 78 mr r19,r17 1a88: 12 49 92 e1 efdsub r18,r9,r18 1a8c: 10 80 92 fa efdctsiz r4,r18 1a90: 12 49 4a 17 evmrr18,r9 So we just save the lower 32bit of r9 before calling the function and the upper 32bit are overwritten by efdsub. -- Summary: Wrong code with e500 double floating point Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-linux-gnuspe GCC host triplet: powerpc-linux-gnuspe GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug rtl-optimization/44364] Wrong code with e500 double floating point
--- Comment #1 from gcc at breakpoint dot cc 2010-06-01 13:42 --- Created an attachment (id=20793) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20793action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug rtl-optimization/44364] Wrong code with e500 double floating point
--- Comment #2 from gcc at breakpoint dot cc 2010-06-01 13:42 --- Created an attachment (id=20794) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20794action=view) objdump of the compiled testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #27 from gcc at breakpoint dot cc 2010-05-21 15:16 --- This fix is causing PR44169 on powerpc-linux-gnuspe, the second TLS load is missing a lwz. The same testcase on powerpc-linux-gnu has no problems. The gnuspe target has (as far as I figured out) just different pre-defines. Switching them off (-mabi=nospe -mno=spe) makes the problem not go away. Changing the CPU does. I reverted this change and I pass the testcase from PR44169. -- gcc at breakpoint dot cc changed: What|Removed |Added CC||gcc at breakpoint dot cc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #11 from gcc at breakpoint dot cc 2010-05-21 15:21 --- Reverting the change in PR39254 makes the issue go away. Any ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] New: Wrong code while generating TLS offsets
libgomp testsuite fails with a segfault. It segfaults in gomp_resolve_num_threads(), accessing the second TLS value. The first access: .LBB28: .file 2 ../../../src/libgomp/libgomp.h .loc 2 380 0 bcl 20,31,$+8 .long _GLOBAL_OFFSET_TABLE_-$ mflr 9 lwz 0,0(9) add 9,9,0 lwz 9,gomp_tls_d...@got@tprel(9) add 9,9,gomp_tls_d...@tls lwz 9,40(9) The second: .LBE27: .loc 1 47 0 cmpwi 7,3,1 beq- 7,.L37 .LVL32: .loc 1 49 0 bcl 20,31,$+8 .long _GLOBAL_OFFSET_TABLE_-$ mflr 9 add 9,9,0 lwz 9,gomp_tls_d...@got@tprel(9) add 9,9,gomp_tls_d...@tls lwz 0,28(9) After mflr, the lwz is missing. r0 has the offset from last lr which is wrong here. The RTL in tc.c.185r.cprop_hardreg has the lwz included, the next pass tc.c.186r.dce does not anymore. lwz gets not killed if I used -mcpu=power or -mcpu=e300c3. I used -mcpu=8540 which is default for powerpc-linux-gnuspe. -O1 was used in the test case. The complete cmd line: /build/bigeasy/gcc-4.4-4.4.4/build/./gcc/xgcc \ -B/build/bigeasy/gcc-4.4-4.4.4/build/./gcc/ \ -B/usr/powerpc-linux-gnuspe/bin/ \ -B/usr/powerpc-linux-gnuspe/lib/ \ -isystem \ /usr/powerpc-linux-gnuspe/include \ -isystem \ /usr/powerpc-linux-gnuspe/sys-include \ -Werror \ -pthread \ -ftls-model=initial-exec \ -O2 \ -pthread \ -fPIC \ -DPIC \ tc.c \ -o \ tc.S \ -S \ -mcpu=8540 \ -O1 \ -fdump-rtl-all \ -c \ A side note: the complete file (parallel.c from libgomp) was compiled with -O2 and the lwz was killed between parallel.c.174r.postreload and parallel.c.176r.split2. -- Summary: Wrong code while generating TLS offsets Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-linux-gnuspe GCC host triplet: powerpc-linux-gnuspe GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #1 from gcc at breakpoint dot cc 2010-05-17 15:44 --- Created an attachment (id=20683) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20683action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #2 from gcc at breakpoint dot cc 2010-05-17 15:44 --- Created an attachment (id=20684) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20684action=view) rtl pass 185r.cprop_hardreg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #3 from gcc at breakpoint dot cc 2010-05-17 15:45 --- Created an attachment (id=20685) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20685action=view) rtl pass 186r.dce -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #3 from gcc at breakpoint dot cc 2009-04-22 18:41 ---
Wasn't
# echo 'int main(void) { return 0; }' file.c
not enough or did you overlook that part?
The -E output is pretty much the same, it is:
$ cat test.i
# 1 test.c
# 1 built-in
# 1 command-line
# 1 test.c
int main(void)
{
return 0;
}
---
The -S output (I guess you meant that) would be:
$ m68k-linux-gnu-gcc -o test.S test.c -static -pg -S cat test.S
#NO_APP
.file test.c
.text
.align 2
.globl main
.type main, @function
main:
link.w %fp,#0
.data
.align 2
.LP2:
.long 0
.text
lea (.LP2,%pc),%a1
jbsr _mcount
clr.l %d0
unlk %fp
rts
.size main, .-main
.ident GCC: (Sourcery G++ Lite 4.3-43) 4.3.2
.section.note.GNU-stack,,@progbits
And my rec for the fix was to get rid of the lea before the branch to the
_mcount call. However someone might need it, I'm not sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #1 from gcc at breakpoint dot cc 2008-07-24 19:48 --- Does anybody care about this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug c/36047] New: -pg does not work on large binaries and m68k
[EMAIL PROTECTED]:~/cc$ echo 'int main(void) { return 0; }' file.c
[EMAIL PROTECTED]:~/cc$ m68k-linux-gnu-gcc -o file file.c -static -pg
/tmp/ccw33VYP.o: In function `main':
file.c:(.text+0x6): relocation truncated to fit: R_68K_PC16 against `.data'
collect2: ld returned 1 exit status
It works fine with a small binary (without -static).
I don't really know what the label is used for. I patched my gcc with:
|--- a/gcc/config/m68k/linux.h
|+++ b/gcc/config/m68k/linux.h
|@@ -143,7 +143,6 @@ along with GCC; see the file COPYING3.
| #undef FUNCTION_PROFILER
| #define FUNCTION_PROFILER(FILE, LABELNO) \
| { \
|- asm_fprintf (FILE, \tlea (%LLP%d,%Rpc),%Ra1\n, (LABELNO));\
| if (flag_pic) \
| fprintf (FILE, \tbsr.l [EMAIL PROTECTED]);\
| else\
|--- a/gcc/config/m68k/m68k.h
|+++ b/gcc/config/m68k/m68k.h
|@@ -576,7 +576,7 @@ extern enum reg_class regno_reg_class[];
| #define FUNCTION_ARG(CUM, MODE, TYPE, NAMED) 0
|
| #define FUNCTION_PROFILER(FILE, LABELNO) \
|- asm_fprintf (FILE, \tlea %LLP%d,%Ra0\n\tjsr mcount\n, (LABELNO))
|+ asm_fprintf (FILE, \tjsr mcount\n, (LABELNO))
|
| #define EXIT_IGNORE_STACK 1
|
I'm not using glibc's mcount function but my own in which I unwind the stack in
order to obtain caller's address (that's the purpose of the label I guess).
I checked gcc-core-4.3.0.tar.bz2 and the two lea lines are unchanged so the bug
should be still there.
Now how do we fix this? Removing the label or allowing larger distances?
--
Summary: -pg does not work on large binaries and m68k
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at breakpoint dot cc
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-uclinux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/31635] New: -mno-vrsave ignored on ppc64
The -mno-vrsave switch as well as the old -mvrsave=no is ignored on 64bit target. Testcase is an empty file. Results with powerpc64-unknown-linux-gnu-gcc -o a.s -c b.c -maltivec -mno-vrsave -S -fverbose-asm -m64 into: # rs6000/powerpc options: -msdata=none .section.toc,aw .section.text # GNU C version 4.1.2 (Gentoo 4.1.2) (powerpc64-unknown-linux-gnu) # compiled by GNU C version 4.1.1 (Gentoo 4.1.1-r3). # GGC heuristics: --param ggc-min-expand=44 --param ggc-min-heapsize=27672 # options passed: -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix # -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix # -msecure-plt -maltivec -mno-vrsave -m64 -auxbase-strip -fverbose-asm # options enabled: -falign-loops -fargument-alias -fbranch-count-reg # -fcommon -fearly-inlining -feliminate-unused-debug-types -ffunction-cse # -fgcse-lm -fident -finline-functions-called-once -fivopts # -fkeep-static-consts -fleading-underscore -floop-optimize2 -fmath-errno # -fpeephole -freg-struct-return -fsched-interblock -fsched-spec # -fsched-stalled-insns-dep -fshow-column -fsplit-ivs-in-unroller # -ftrapping-math -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize # -ftree-vect-loop-version -fverbose-asm -fzero-initialized-in-bss -m64 # -maix-struct-return -maltivec -mbig -mbig-endian -mfp-in-toc # -mfused-madd -mhard-float -mnew-mnemonics -mpowerpc -mpowerpc-gfxopt # -mpowerpc64 -msched-prolog -msecure-plt -mupdate -mvrsave # Compiler executable checksum: 9f98a4867284f64c17c8db6425da4d5f .ident GCC: (GNU) 4.1.2 (Gentoo 4.1.2) Somehow -mvrsave comes into option enabled -m32 does not pass this. -- Summary: -mno-vrsave ignored on ppc64 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc64-linux-gnu GCC host triplet: powerpc64-linux-gnu GCC target triplet: powerpc64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31635
[Bug rtl-optimization/31552] New: -fcall-used-vXX turns into ICE
If gcc runs out of volatile VMX registers, he is going to save the non volatile registers. This fails if one of them is defined in -fcall-used-vXX (test case attaced) -- Summary: -fcall-used-vXX turns into ICE Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
[Bug rtl-optimization/31552] -fcall-used-vXX turns into ICE
--- Comment #1 from gcc at breakpoint dot cc 2007-04-12 18:02 --- Created an attachment (id=13357) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13357action=view) test case for the internal compiler error: in propagate_one_insn, at flow.c:1699 Reults ins: powerpc64-unknown-linux-gnu-gcc -Wall -maltivec -Os -mabi=altivec -fcall-used-v20 -o altivec_prolog.o altivec_prolog.c -c altivec_prolog.c: In function 'f2': altivec_prolog.c:64: error: Attempt to delete prologue/epilogue insn: (insn 231 230 232 2 (set (reg:V4SI 97 20) (mem:V4SI (plus:DI (reg/f:DI 1 1) (reg:DI 0 0)) [1 S16 A8])) -1 (nil) (nil)) altivec_prolog.c:64: internal compiler error: in propagate_one_insn, at flow.c:1699 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
[Bug rtl-optimization/31552] -fcall-used-vXX turns into ICE
--- Comment #2 from gcc at breakpoint dot cc 2007-04-12 18:04 --- Created an attachment (id=13358) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13358action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
