[Bug c++/32182] New: -fstrict-aliasing optimizations cause constructor not to run in causing segfault
by 0x80489F2: TestClass::operator=(TestClass const&) (Wrapper.cxx:33) ==30651==by 0x8048BE2: getItem (Wrapper.cxx:101) ==30651==by 0x804887B: main (main.c:35) ==30651== ==30651== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 19 from 1) ==30651== malloc/free: in use at exit: 1,008 bytes in 12 blocks. ==30651== malloc/free: 12 allocs, 0 frees, 1,008 bytes allocated. ==30651== For counts of detected errors, rerun with: -v ==30651== searching for pointers to 12 not-freed blocks. ==30651== checked 100,788 bytes. ==30651== ==30651== LEAK SUMMARY: ==30651==definitely lost: 0 bytes in 0 blocks. ==30651== possibly lost: 0 bytes in 0 blocks. ==30651==still reachable: 1,008 bytes in 12 blocks. ==30651== suppressed: 0 bytes in 0 blocks. ==30651== Rerun with --leak-check=full to see details of leaked memory. Segmentation fault The program doesn't crash when compiled with Intel's 9.0.21 C++ compiler. It doesn't crash when compiled with pre-4.2 GCC versions either. Based on this evidence, it seems possible that this illustrates a case of over zealous optimization. Release:gcc-4.2 (GCC) 4.2.1 20070525 (prerelease) (Debian 4.2-20070525-1) System: Linux driftcreek 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux Architecture: i686 configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-targets=all --disable-werror --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu -- Summary: -fstrict-aliasing optimizations cause constructor not to run in causing segfault Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: epperly2 at llnl dot gov GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run in causing segfault
--- Comment #1 from epperly2 at llnl dot gov 2007-06-01 20:44 --- Created an attachment (id=13646) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13646&action=view) tar file containing complete source to reproduce problem % sha1sum bug32182.tar.bz2 ce7372671f73d316ad946aede1aad3d4176908bb bug32182.tar.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #2 from epperly2 at llnl dot gov 2007-06-01 20:53 --- To avoid depending on system #include files, the example has typedef unsigned int size_t; hardwired in the code. This may be an incorrect definition for some platforms. Oddly enough, if I delete NextClass and make TestClass inherit directly from BaseClass, the program no longer segfaults. I am not sure if all the features of this example are strictly necessary. I basically created a new program from scratch that has the same characteristics as the original 100+K program, and I added things until it reproduced the same behavior. -- epperly2 at llnl dot gov changed: What|Removed |Added Summary|-fstrict-aliasing |-fstrict-aliasing |optimizations cause |optimizations cause |constructor not to run in |constructor not to run for |causing segfault|object causing segfault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #3 from epperly2 at llnl dot gov 2007-06-01 21:07 --- The Babel bug tracking entry corresponding to this GCC issue report is here: https://www.cca-forum.org/bugs/babel/issue480 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #5 from epperly2 at llnl dot gov 2007-06-01 21:24 --- In response to comment #4, I may be violating C++ aliasing rules, but I don't see how that explains the behavior I am seeing and where I am seeing it. How could aliasing analysis give the compiler permission to skip _local_result's constructor? If it assumed that the operator= method didn't read from the left hand side, it might make such a mistake. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #6 from epperly2 at llnl dot gov 2007-06-01 22:04 --- Created an attachment (id=13647) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13647&action=view) An example involving less casting than the previous one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #7 from epperly2 at llnl dot gov 2007-06-01 22:12 --- Created an attachment (id=13648) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13648&action=view) A further simplified example showing the problem without any C++ casting -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #8 from epperly2 at llnl dot gov 2007-06-01 22:14 --- I've simplified the sample case that demonstrates the problem, and it has *no* casting in C++. In C, it casts the result of malloc to the appropriate pointer type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #9 from epperly2 at llnl dot gov 2007-06-01 23:24 --- Created an attachment (id=13650) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13650&action=view) The function pointer in RefCount_t can be removed too This is a smaller program that removes a couple function pointer casts. At this point, I don't think there are any aliasing problems. -- epperly2 at llnl dot gov changed: What|Removed |Added Attachment #13646|0 |1 is obsolete|| Attachment #13647|0 |1 is obsolete|| Attachment #13648|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #11 from epperly2 at llnl dot gov 2007-06-02 02:52 --- I tried test_4.tar.bz2 on my home PC whose details are below. I had to change the definition of size_t to "typedef unsigned long size_t;" in RefCount.c. It failed just like the other system I tested it with. > ./compile > ./test_aliasing Segmentation fault > ./test_noaliasing Max value: 1804289383 System: Linux faerun 2.6.21-1-amd64 #1 SMP Sat May 26 17:22:54 CEST 2007 x86_64 GNU/Linux Architecture: x86_64 Release: gcc-4.2 (GCC) 4.2.1 20070528 (prerelease) (Debian 4.2-20070528-1 ) host: x86_64-pc-linux-gnu build: x86_64-pc-linux-gnu target: x86_64-pc-linux-gnu configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c ++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/l ib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-inc lude-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enabl e-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=release --bui ld=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu >From comment #10, I see the issue is already addressed in the trunk. Will changes to the trunk make it into gcc-4.2.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug fortran/21130] New: 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
I work on a language interoperability tool called Babel. It generates F90 code
that wraps up objects written in other languages. I have an example with 38822
lines in 22 files. The last file is 4967 lines long, and it takes roughly 10
minutes to compile with a snapshot of GCC 4.0 on an essentially idle dual 3GHz
P4 Linux box. gfortran does ultimately compile the file, so I will understand if
you don't consider this a bug.
Here are the details about the version and build of gfortran:
[EMAIL PROTECTED] gfortran_issue]$
/usr/casc/babel/apps/linux_el/gcc40_pre0/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0-20050319/configure
--with-gmp=/usr/casc/babel/apps/linux_el/gcc40_pre0
--prefix=/usr/casc/babel/apps/linux_el/gcc40_pre0
--enable-languages=c,c++,java,f95
Thread model: posix
gcc version 4.0.0 20050319 (prerelease)
I know that tar files are not preferred, but it seems like the only reasonable
means of providing all the required files. I include a compile.sh shell script
to compile the files in the correct order. Each file is compiled with "gfortran
-c file.f90". This shows the timing output from running "sh copmile.sh".
[EMAIL PROTECTED] gfortran_issue]$ sh compile.sh
Wed Apr 20 15:27:16 PDT 2005
The following file will take roughly 10 minutes to compile
Wed Apr 20 15:27:25 PDT 2005
Wed Apr 20 15:39:18 PDT 2005
--
Summary: 38822 lines of Fortran 90 takes more than 10 minutes to
compile on a dual 3GHz P4 Linux box with lots of RAM
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: epperly2 at llnl dot gov
CC: gcc-bugs at gcc dot gnu dot org
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=21130
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Additional Comments From epperly2 at llnl dot gov 2005-04-20 22:46 --- Created an attachment (id=8690) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8690&action=view) Source files and compile script to reproduce the performance issue I am attaching a bzip2 compressed tar file with the source and a compile.sh script to reproduce this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
