Executing on host: /tmp/cvs/gcc-20050909/Build/gcc/testsuite/../g++ -B/tmp/cvs/gcc-20050909/Build/gcc/testsuite/../ /tmp/cvs/gcc-20050909/gcc/testsuite/g++.dg/init/pr23180-2.C -nostdinc++ -I/tmp/cvs/gcc-20050909/Build/ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux -I/tmp/cvs/gcc-20050909/Build/ia64-suse-linux/libstdc++-v3/include -I/tmp/cvs/gcc-20050909/libstdc++-v3/libsupc++ -I/tmp/cvs/gcc-20050909/libstdc++-v3/include/backward -I/tmp/cvs/gcc-20050909/libstdc++-v3/testsuite -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -S -o pr23180-2.s (timeout = 300) /tmp/cvs/gcc-20050909/gcc/testsuite/g++.dg/init/pr23180-2.C:10: internal compiler error: no-op convert from 8 to 4 bytes in initializer
Note this is a new testcase for 4.1. Just to double check, did you try compiling it with 4.0?
Sure I did.
Also appears on ia64-hp-hpux11.23 (-mlp64 only).
Also fails on x86-64, according to <http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00458.html>. All 64-bit targets appear to be affected.
Note the testcase is now called struct3.C. Confirmed.
Caused by: http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00040.html Reduced testcase: struct Track { char soundName[15]; }; int foobar = ((long) (& ((Track *) 42)->soundName[0])) - 42;
DJ, apparently you caused this one.
Subject: Re: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer > DJ, apparently you caused this one. Yup, and I had reservations about that portion of the patch at the time, too, which have turned out to be justified (the reservations, not the patch). I think the best option at this point is to just take the check out (leaving in the other part of the patch, which is needed for m32c). The code will still be buggy if the no-op converts to a larger size, though, because it doesn't take endianness into account when padding. I'm rather surprised that the test case works for sizeof(long) > sizeof(int), I'd expect the bytes to be truncated in amusing ways.
The failures on powerpc64-linux are due to a long (64-bit) to int (32-bit) conversion. When such a conversion is the outermost one, as in this case, it ought to be allowed. The assembler will (or should) handle big/little endian issues and give an error on overflow.
Subject: Re: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer I recall that the opposite case is problematic; initializing a large int from a smaller one, because gcc always zero pads at the end. Perhaps a lt/gt comparison would be more appropriate?
Any progress on this one?
For the testcase we get at output_constant time for the C++ frontend: (intD.2) (long intD.5) &42B->soundNameD.2065[-42] C frontend: (intD.0) (long intD.2) &42B->soundNameD.1608 - 42 the C++ frontend ICEs, the C frontend not (as we have an outer MINUS_EXPR). Whatever you wanted to fix with your patch will not work in every case - but you didn't add a testcase.
Subject: Bug 23799 CVSROOT: /cvs/gcc Module name: gcc Changes by: rguenth@gcc.gnu.org 2005-10-12 08:55:59 Modified files: gcc : ChangeLog varasm.c Log message: 2005-10-12 Richard Guenther <rguenther@suse.de> PR c++/23799 * varasm.c (output_constant): Correct typo from previous patch by DJ. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10142&r2=2.10143 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.531&r2=1.532
Fixed.
*** Bug 24343 has been marked as a duplicate of this bug. ***