[Bug c++/38705] New: ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t
I turfed up an ICE with optimization, but the thing compiled fine without. To reproduce, use the soon-to-be attached source and do: madison.gams.com:/home/steve/lang/cpp/alpsBug$g++ -c AlpsTreeNode.ii madison.gams.com:/home/steve/lang/cpp/alpsBug$g++ -O3 -c AlpsTreeNode.ii AlpsTreeNode.cpp: In member function 'AlpsReturnStatus AlpsTreeNode::encodeAlps(AlpsEncoded*) const': AlpsTreeNode.cpp:144: internal compiler error: canonical types differ for identical types const int and const AlpsNodeIndex_t Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I was using the trunk src at rev 142984: $gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local2 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20081231 (experimental) (GCC) -- Summary: ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38705
[Bug c++/38705] ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t
--- Comment #1 from sdirkse at gams dot com 2009-01-02 16:49 --- Created an attachment (id=17023) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17023action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38705
[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #17 from sdirkse at gams dot com 2008-12-22 20:37 --- After all the updates committed for this bug, I thought I'd try the latest, including updating to ggmp-4.2.4 and mpfr-2.3.2. Here's the result for the GCC 4.3.2 release and the latest GCC. Note that the 32-bit stuff hasn't changed and now I get all-stars output for *both* outputs in 64-bit, not just one of the outputs. sigvm:/export/home/distrib/lang/f90$/usr/local2/bin/gfortran -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../configure CC=gcc --prefix=/usr/local2 --build=i386-pc-solaris2.10 --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --enable-languages=c,c++,fortran --enable-shared Thread model: posix gcc version 4.3.2 (GCC) sigvm:/export/home/distrib/lang/f90$cat bug.f PROGRAM bug IMPLICIT NONE DOUBLE PRECISION r COMMON /91/ r DOUBLE PRECISION x x = 1001 write(6,*) 'x = ', x r = 1000 write(6,*) 'r = ', r END sigvm:/export/home/distrib/lang/f90$/usr/local2/bin/gfortran -o bug32 -m32 bug.f sigvm:/export/home/distrib/lang/f90$/usr/local2/bin/gfortran -o bug64 -m64 bug.f sigvm:/export/home/distrib/lang/f90$./bug32 x =1001.0 r = 1000.00 sigvm:/export/home/distrib/lang/f90$./bug64 x =1001.0 r = sigvm:/export/home/distrib/lang/f90$/usr/local3/bin/gfortran -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../configure CC=gcc --prefix=/usr/local3 --build=i386-pc-solaris2.11 --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --enable-languages=c,c++,fortran --enable-shared Thread model: posix gcc version 4.4.0 20081222 (experimental) (GCC) sigvm:/export/home/distrib/lang/f90$/usr/local3/bin/gfortran -o bug32 -m32 bug.f sigvm:/export/home/distrib/lang/f90$/usr/local3/bin/gfortran -o bug64 -m64 bug.f sigvm:/export/home/distrib/lang/f90$./bug32 x =1001.0 r = 1000.00 sigvm:/export/home/distrib/lang/f90$./bug64 x = r = sigvm:/export/home/distrib/lang/f90$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug fortran/37472] New: bad output on default-format write of double in common block with -m64 flag i
If I do write (6,*) 'x=', x for a double, I get lots of stars for doubles in a common block when I do a 64-bit compile. The output is OK for 32-bit or for doubles not in common. Here's some output, I'll try attaching the test case too. sigvm:/export/home/distrib/lang/f90$make ./bug gfortran -c -m64 bug.f gfortran -o bug -m64 ./bug.o -ldl x =1001.0 r = sigvm:/export/home/distrib/lang/f90$gfortran -c -m32 bug.f sigvm:/export/home/distrib/lang/f90$gfortran -o bug32 -m32 bug.o -ldl sigvm:/export/home/distrib/lang/f90$./bug32 x =1001.0 r = 1000.00 -- Summary: bad output on default-format write of double in common block with -m64 flag i Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC host triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #1 from sdirkse at gams dot com 2008-09-11 00:56 --- Created an attachment (id=16289) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16289action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug c++/36826] New: ICE in fold_convert, at fold-const.c:2528
$gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080714 (experimental) (GCC) Running g++ -O3 -fomit-frame-pointer -pipe -pedantic-errors -Wall -MD -MP -c -fPIC -DPIC -o ClpSimplex.o ClpSimplex.i on the soon-to-be attached file I get: ClpSimplex.cpp: In member function 'void ClpSimplex::deleteRim(int)': ClpSimplex.cpp:4325: internal compiler error: in fold_convert, at fold-const.c:2528 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in fold_convert, at fold-const.c:2528 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36826
[Bug middle-end/36826] ICE in fold_convert, at fold-const.c:2528
--- Comment #1 from sdirkse at gams dot com 2008-07-14 20:18 --- Created an attachment (id=15907) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15907action=view) zipped, pre-processed source to turf up the bug I couldn't generate the .i file using -save-temps, so I used -E instead. Is that also a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36826
[Bug fortran/36751] New: assignment between allocatable arrays of different size causes glibc error
If I assign allocatable arrays of different size I get a glibc error and a backtrace. This happens with every version of gfortran I've tried, including 4.1, 4.3, and 4.4. The workaround is easy enough, but perhaps the compiler could be improved also. Here's the output: $gfortran --version GNU Fortran (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42) Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $gfortran -o repro_g repro.f90 ./repro_g *** glibc detected *** ./repro_g: free(): invalid next size (fast): 0x14d314d0 *** === Backtrace: = /lib64/libc.so.6[0x359ae71634] /lib64/libc.so.6(cfree+0x8c)[0x359ae74c5c] /usr/lib64/libgfortran.so.1(_gfortran_deallocate+0x26)[0x2ad9cffa72a6] ./repro_g[0x4009f4] ./repro_g[0x400a2e] /lib64/libc.so.6(__libc_start_main+0xf4)[0x359ae1d8b4] ./repro_g[0x400609] === Memory map: 0040-00401000 r-xp fd:06 5493742 /home/steve/lang/f90/repro_g 0060-00601000 rw-p fd:06 5493742 /home/steve/lang/f90/repro_g 14d2b000-14d4c000 rw-p 14d2b000 00:00 0 359aa0-359aa1a000 r-xp fd:00 12636395 /lib64/ld-2.5.so 359ac1a000-359ac1b000 r--p 0001a000 fd:00 12636395 /lib64/ld-2.5.so 359ac1b000-359ac1c000 rw-p 0001b000 fd:00 12636395 /lib64/ld-2.5.so 359ae0-359af4a000 r-xp fd:00 12636396 /lib64/libc-2.5.so 359af4a000-359b149000 ---p 0014a000 fd:00 12636396 /lib64/libc-2.5.so 359b149000-359b14d000 r--p 00149000 fd:00 12636396 /lib64/libc-2.5.so 359b14d000-359b14e000 rw-p 0014d000 fd:00 12636396 /lib64/libc-2.5.so 359b14e000-359b153000 rw-p 359b14e000 00:00 0 359b20-359b282000 r-xp fd:00 12636403 /lib64/libm-2.5.so 359b282000-359b481000 ---p 00082000 fd:00 12636403 /lib64/libm-2.5.so 359b481000-359b482000 r--p 00081000 fd:00 12636403 /lib64/libm-2.5.so 359b482000-359b483000 rw-p 00082000 fd:00 12636403 /lib64/libm-2.5.so 35a9c0-35a9c0d000 r-xp fd:00 12636418 /lib64/libgcc_s-4.1.2-20080102.so.1 35a9c0d000-35a9e0d000 ---p d000 fd:00 12636418 /lib64/libgcc_s-4.1.2-20080102.so.1 35a9e0d000-35a9e0e000 rw-p d000 fd:00 12636418 /lib64/libgcc_s-4.1.2-20080102.so.1 2ad9cff7b000-2ad9cff7c000 rw-p 2ad9cff7b000 00:00 0 2ad9cff95000-2ad9cff96000 rw-p 2ad9cff95000 00:00 0 2ad9cff96000-2ad9d002c000 r-xp fd:00 1293923 /usr/lib64/libgfortran.so.1.0.0 2ad9d002c000-2ad9d022b000 ---p 00096000 fd:00 1293923 /usr/lib64/libgfortran.so.1.0.0 2ad9d022b000-2ad9d022d000 rw-p 00095000 fd:00 1293923 /usr/lib64/libgfortran.so.1.0.0 2ad9d022d000-2ad9d022f000 rw-p 2ad9d022d000 00:00 0 2ad9d400-2ad9d4021000 rw-p 2ad9d400 00:00 0 2ad9d4021000-2ad9d800 ---p 2ad9d4021000 00:00 0 7fffdab19000-7fffdab2f000 rw-p 7fffdab19000 00:00 0 [stack] ff60-ffe0 ---p 00:00 0 [vdso] Aborted $ -- Summary: assignment between allocatable arrays of different size causes glibc error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36751
[Bug fortran/36751] assignment between allocatable arrays of different size causes glibc error
--- Comment #1 from sdirkse at gams dot com 2008-07-07 18:00 --- Created an attachment (id=15872) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15872action=view) test case No flags required to reproduce: gfortran -o repro repro.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36751
[Bug translation/32959] msgfmt fails on file libcpp/po/fr.po
--- Comment #2 from sdirkse at gams dot com 2008-02-01 18:24 --- I tried a more recent GCC checkout of the trunk and I no longer have this issue, even with the old gettext. If this reoccurs I'll try updating gettext. Thanks, and please feel free to close this issue report. Or should I close it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32959
[Bug fortran/34722] New: compile results in internal compiler error: segmentation fault message
Here's the log of the failed compile: madison.gams.com:/home/steve/lang/f90/bug3$uname -a Linux madison.gams.com 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 x86_64 GNU/Linux madison.gams.com:/home/steve/lang/f90/bug3$gfortran -c -m64 -O gamsana1.f90 gamsana1.f90:1541: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: compile results in internal compiler error: segmentation fault message Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug fortran/34722] compile results in internal compiler error: segmentation fault message
--- Comment #1 from sdirkse at gams dot com 2008-01-09 01:11 --- Created an attachment (id=14906) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14906action=view) zipped source and doit.sh script to reproduce To reproduce, unzip the attachment and run ./doit.sh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug fortran/34722] compile results in internal compiler error: segmentation fault message
--- Comment #2 from sdirkse at gams dot com 2008-01-09 01:16 --- I should have mentioned: I get this with a checkout of the gcc trunk from 8 Jan 2008. Also, this is not likely unique to 64-bit: I get the same error message on Linux32 with a similar file and a slightly older revision of gcc trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug bootstrap/32959] New: msgfmt fails on file libcpp/po/fr.po
My build of gcc fails with an error running msgfmt. If I do /usr/bin/msgfmt --statistics libcpp/po/fr.po -o /dev/null I get failure with the current gcc (rev 127119) but if I use the file fr.po from rev 111982 the command works. Does the fix need to happen to fr.po or to my msgfmt binary? I have Fedora Core 6 installed, with gettext RPM 0.14.6-4. -- Summary: msgfmt fails on file libcpp/po/fr.po Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32959
[Bug target/31394] cos() returns wrong value unless -O0 is used
--- Comment #3 from sdirkse at gams dot com 2007-03-30 21:36 --- I installed gcc 20070329 and the problem I was having is solved. I suppose that makes it a duplicate of PR30980. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394
[Bug c/31394] New: cos() returns wrong value unless -O0 is used
I have some code that involves computing a cosine via cos(), specifically b = cos(v). Depending on the context of the cos call, I get correct and incorrect answers. In the example code's main program, I get a correct result regardless of the compilation flags. In the MATHNEW_funceval routine, correctness depends on the flags. Just a note on correctness since these are floating-point operations: IMHO the incorrect result is far enough away from the true result to remove all doubt, but I can say more if necessary. In the output below, b = is correct, but b2= is incorrect. Here's the output I get: sunamd1:/export/home/gams/lang/cosbug$gmake ./cosbug gcc -m64 -Wall -w -m64 -fwrapv -O1 -save-temps -v -o cosbug cosbug.c -lm Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../configure --build=i386-pc-solaris2.10 --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld -with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --enable-languages=c,c++,fortran --enable-shared Thread model: posix gcc version 4.3.0 20070301 (experimental) /usr/local/libexec/gcc/i386-pc-solaris2.10/4.3.0/cc1 -E -quiet -v -imultilib amd64 cosbug.c -m64 -mtune=generic -Wall -w -fwrapv -O1 -fpch-preprocess -o cosbug.i ignoring nonexistent directory /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/../../../../i386-pc-solaris2.10/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/include /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/include-fixed /usr/include End of search list. /usr/local/libexec/gcc/i386-pc-solaris2.10/4.3.0/cc1 -fpreprocessed cosbug.i -quiet -dumpbase cosbug.c -m64 -mtune=generic -auxbase cosbug -O1 -Wall -w -version -fwrapv -o cosbug.s GNU C version 4.3.0 20070301 (experimental) (i386-pc-solaris2.10) compiled by GNU C version 4.3.0 20070301 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 15fd974b8d70fc2c218783c6076c49f0 /usr/sfw/bin/gas --traditional-format -V -Qy --64 -s -o cosbug.o cosbug.s GNU assembler version 2.15 (i386-pc-solaris2.10) using BFD version 2.15 /usr/local/libexec/gcc/i386-pc-solaris2.10/4.3.0/collect2 -V -Y P,/lib/64:/usr/lib/64 -Qy -o cosbug /usr/lib/amd64/crt1.o /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/amd64/crtbegin.o -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/../../.. cosbug.o -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/amd64/crtend.o /usr/lib/amd64/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.482 0 = 0 x0= -635.4813998334932 y = -7.036102677544457e-09 z = 635.4813998264574 *** |t| mu: return smoother v = -3.141592653589793 b = -1.224646799147353e-16 *** |t| mu: return smoother v2= -3.141592653589793 b2= -0.04318444754676655 sunamd1:/export/home/gams/lang/cosbug$ Now using the .i file I get: sunamd1:/export/home/gams/lang/cosbug$gcc -m64 -o xxx cosbug.i -lm sunamd1:/export/home/gams/lang/cosbug$./xxx 0 = 0 x0= -635.4813998334932 y = -7.036102677544457e-09 z = 635.4813998264574 *** |t| mu: return smoother v = -3.141592653589793 b = -1.224646799147353e-16 *** |t| mu: return smoother v2= -3.141592653589793 b2= -1.224646799147353e-16 sunamd1:/export/home/gams/lang/cosbug$gcc -m64 -O1 -o xxx cosbug.i -lm sunamd1:/export/home/gams/lang/cosbug$./xxx 0 = 0 x0= -635.4813998334932 y = -7.036102677544457e-09 z = 635.4813998264574 *** |t| mu: return smoother v = -3.141592653589793 b = -1.224646799147353e-16 *** |t| mu: return smoother v2= -3.141592653589793 b2= -0.04318444754676655 -- Summary: cos() returns wrong value unless -O0 is used Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394
[Bug c/31394] cos() returns wrong value unless -O0 is used
--- Comment #1 from sdirkse at gams dot com 2007-03-29 17:55 --- Created an attachment (id=13297) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13297action=view) test case for the bug Building with gcc -m64 -O1 -o xxx cosbug.i -lm shows the bug bug gcc -m64 -o xxx cosbug.i -lm is OK. I observe the bug also with -O2 and -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394
[Bug c/31085] New: internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
My compilation resulted in an internal compiler error and a request to submit a bug report. Here's the command used and it's output: the input will be attached. mamie:$gcc -v -DLNX -fPIC -w -m32 -fwrapv -O3 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c utilcomp.i Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20070305 (experimental) /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed utilcomp.i -quiet -dumpbase utilcomp.i -m32 -mtune=generic -auxbase utilcomp -O3 -w -version -fPIC -fwrapv -o /tmp/ccokSDVr.s GNU C version 4.3.0 20070305 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070305 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: af9ea66eb7bed348134eeea0b2925c17 utilcomp.c: In function 'filecheck': utilcomp.c:5124: internal compiler error: in create_mem_ref, at tree-ssa-address.c:606 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in create_mem_ref, at tree-ssa- address.c:606 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug c/31085] internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
--- Comment #1 from sdirkse at gams dot com 2007-03-08 14:39 --- Created an attachment (id=13172) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13172action=view) result of gcc-save-temps run on .c file To reproduce the bug with this file, do: mamie$gcc -v -DLNX -fPIC -w -m32 -fwrapv -O3 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c utilcomp.i Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20070305 (experimental) /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed utilcomp.i -quiet -dumpbase utilcomp.i -m32 -mtune=generic -auxbase utilcomp -O3 -w -version -fPIC -fwrapv -o /tmp/ccokSDVr.s GNU C version 4.3.0 20070305 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070305 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: af9ea66eb7bed348134eeea0b2925c17 utilcomp.c: In function 'filecheck': utilcomp.c:5124: internal compiler error: in create_mem_ref, at tree-ssa-address.c:606 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug c/31075] New: 2's complement arithmetic (LLONG_MIN-1) works differently with and without optimization
testing if LLONG_MIN-1 == LLONG_MAX gives different results with -O3 and
without. Here's a short example and the output I get on my machine.
mamie:/home/distrib/lang/pas$cat mini64.c
#include stdio.h
typedef signed long long int int64;
#define MAXINT64 9223372036854775807LL
#define MININT64 ((-9223372036854775807LL)-1LL)
int main (int argc, char **argv)
{
int64 minint64;
printf (mini64: test 2's-complement arithmetic\n);
minint64 = MININT64;
printf (minint64-1 = %lld\n, minint64-1);
if (minint64 - 1 != MAXINT64) {
printf (minint64 - 1 MAXINT64\n);
}
else {
printf (minint64 - 1 == MAXINT64\n);
}
return 0;
} /* main */
mamie:/home/distrib/lang/pas$gcc -o mini64 mini64.c ./mini64
mini64: test 2's-complement arithmetic
minint64-1 = 9223372036854775807
minint64 - 1 == MAXINT64
mamie:/home/distrib/lang/pas$gcc -O3 -o mini64 mini64.c ./mini64
mini64: test 2's-complement arithmetic
minint64-1 = 9223372036854775807
minint64 - 1 MAXINT64
mamie:/home/distrib/lang/pas$gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.3.0 20070305 (experimental)
--
Summary: 2's complement arithmetic (LLONG_MIN-1) works
differently with and without optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sdirkse at gams dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31075
[Bug c/31075] 2's complement arithmetic (LLONG_MIN-1) works differently with and without optimization
--- Comment #2 from sdirkse at gams dot com 2007-03-07 22:52 --- Thanks for telling me about the -fwrapv flag, that's good to know - I should have double-checked my KR 2nd Edition before sending the bug. But I tried running the above example with the addition of the -fwrapv flag, and it didn't change the behavior one bit. Also, I tried a similar example with 32- instead of 64-bit types. It behaved similarly. So, can we call this a bug now? -- sdirkse at gams dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31075
[Bug c/31075] 2's complement arithmetic (LLONG_MIN-1) works differently with and without optimization
--- Comment #4 from sdirkse at gams dot com 2007-03-07 23:10 --- DOH! I wasn't running the executable compiled with -fwrapv. Using the -fwrapv flag does indeed make things work as I hoped and as documented. -- sdirkse at gams dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31075
[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
--- Comment #3 from sdirkse at gams dot com 2007-02-22 18:52 --- I took out the restriction in resolve.c that leads to the error message, and it does give me a clean compile, but the code does not do what I expect. For example, passing a real(kind=8) by-value to C doesn't get me a good double, ditto for a integer(kind=8). The examples work when using ifort/icc. I can send them if you'd like, but they are vanilla one-liners, almost. Enough facts, now for some ignorant speculation: I suppose there is some logic missing to pass a value from the caller when the size of the value is not the default size (i.e. 4 for my platform, Linux 32-bit). -- sdirkse at gams dot com changed: What|Removed |Added CC||sdirkse at gams dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
--- Comment #6 from sdirkse at gams dot com 2007-02-22 21:35 --- (In reply to comment #4) (In reply to comment #3) Enough facts, now for some ignorant speculation: I suppose there is some logic missing to pass a value from the caller when the size of the value is not the default size (i.e. 4 for my platform, Linux 32-bit). See conv_arglist_function in trans-expr.c. Brilliant! I changed the code in there to use a size of MAX(default_kind,expression_kind) instead of just default_kind, and it seems to work now, i.e. the one-liner example is OK. The code was easier to read and modify than I was expecting, a pleasant surprise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
