[Bug target/35658] between -funroll-loops -fno-automatic -O2 and common block variable
--- Comment #10 from kmccarty at debian dot org 2008-08-23 02:59 --- (In reply to comment #9) > Kevin, I can no longer reproduce this bug. I think it was fixed by the same > patch that fixed PR 35659. Are you able to reproduce this or can we close it > as fixed? First, sorry for the delayed reply. With the latest gfortran from the gcc 4.3 branch in svn, I can unfortunately still reproduce this bug using both my test case and the cut-down test case provided by Steve Ellcey. I do find that PR 35659 is now fixed for me. (sid)[EMAIL PROTECTED]:~$ ~/gcc-4.3-branch/bin/gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ./configure --enable-fortran --prefix=/home/kmccarty/gcc-4.3-branch/ --with-mpfr=/home/kmccarty/gcc-4.3-branch/ --with-gmp=/home/kmccarty/gcc-4.3-branch/ Thread model: posix gcc version 4.3.2 20080822 (prerelease) (GCC) Would you like me to also try with SVN trunk? Anything else you need to know? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
[Bug target/35658] between -funroll-loops -fno-automatic -O2 and common block variable
--- Comment #11 from kmccarty at debian dot org 2008-08-23 03:24 --- (In reply to comment #9) By the way, Steve, I do find (as you mentioned) that -frename-registers in place of -funroll-loops also triggers the bug, and that adding -fno-schedule-insns2 makes it go away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
[Bug target/35079] [arm] ICE (segfault) with gfortran -O3 -funroll-loops
--- Comment #2 from kmccarty at debian dot org 2008-03-21 17:06 --- Hi gfortran developers, I can confirm that this ICE still happens on arm with gfortran 4.3 rc2 [*], and with the optimization reduced to -O2 (-funroll-loops -O1 is OK, as is -O3 without -funroll-loops). [*] This is on a machine that I don't administer so unfortunately I cannot test with the very latest gfortran. (sid)[EMAIL PROTECTED]:~$ gfortran-4.3 -v Using built-in specs. Target: arm-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.0 20080301 (prerelease) [gcc-4_3-branch revision 132801] (Debian 4.3.0~rc2-1) (sid)[EMAIL PROTECTED]:~$ gfortran-4.3 -funroll-loops -O2 -c seispack.f seispack.f: In function 'invit': seispack.f:1742: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. I have also observed a similar ICE, which could very well be the same bug, with a smaller FORTRAN file "ranecu.F" that may be easier to run tests on. In that case the ICE occurs with -funroll-loops and with optimization as low as -O1. That ICE I have reported in Debian's BTS at http://bugs.debian.org/466791 -- and I prepared a simple test case for it at http://people.debian.org/~kmccarty/arm-ICE-test.tar.gz . (The .f and .s files in that tarball were generated by gfortran from svn 20080202, Debian package version 4.3-20080202-1, but since the ICE still occurs I'm guessing this doesn't matter so much, and you can easily regenerate them with the Makefile in the test case tarball.) best regards, Kevin McCarty -- kmccarty at debian dot org changed: What|Removed |Added CC| |kmccarty at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35079
[Bug fortran/35658] New: [4.3 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable
Hi, [This bug was initially submitted to the Debian BTS at http://bugs.debian.org/466911 -- at the request of Debian's gcc maintainer, I am also sending it here] In porting CERNLIB to gfortran, I've found an apparent gfortran compiler bug that results in incorrect code on ia64 (Itanium) with the compiler flags -funroll-loops -fno-automatic -O2 (or higher), possibly due to a bad interaction between these flags and a common block variable used in a computed GO TO statement of the form "GO TO (1,2,3,4), L". The bug ONLY occurs in gfortran-4.3 -- I have tested that it does NOT happen in gfortran-4.1 (4.1.2-19), gfortran-4.2 (4.2.3-1), or g77-3.4 (3.4.6-6). The output of gfortran-4.3 -v is: (sid)[EMAIL PROTECTED]:~$ gfortran-4.3 -v Using built-in specs. Target: ia64-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080309 (prerelease) (Debian 4.3.0-1) Please see the complete test case I've provided at http://people.debian.org/~kmccarty/ia64-gfortran-test-fail.tar.gz [Note, I have updated this test case tarball to the gfortran version noted above since I originally submitted this bug to the Debian BTS.] Notes on the test case: 1) The code that gets mis-compiled is in c201s.F (this can be verified by building c201s.F with -O0 and building all the rest with -funroll-loops -fno-automatic -O2, then linking and running the test program c201test) 2) If *any* of the compiler flags are changed (remove -funroll-loops, remove -fno-automatic, or lower the optimization to -O1) the code is built OK. 3) I have put the output of gfortran-4.3 on ia64 (files c201s.f, c201s.s, and c201s.o) for various compiler flag combinations in subdirectories in the test case tarball. Also the output of the test program when run, in the file output.txt in each subdirectory. (Subdirectories are named first after whether the test succeeds, and second after the specific compiler flags used.) You can quickly regenerate this output for all the various flag combinations in the test case with "make output". 4) I believe the problem is that the variable L in common block "FLABEL" is not seen as having the correct value (should be 1, is set to that value in c201m.F prior to any call of C201S) within c201s.F. 5) If I make any tweak to L in c201s.F, the bug disappears. (Argh, heisenbug!) For instance, any of the following tweaks individually causes the test program to succeed: a) changing L to a local variable initialized to the value 1 at the top of c201s.F b) setting L=1 at the top of c201s.F (keeping it in the common block) c) printing the value of L to stdout at the top of c201s.F with a WRITE statement d) printing the literal string 'L=n' to stdout (n being one of 1,2,3,4) immediately after each label that the first GO TO jumps to (i.e. the value of L is not even directly read from). Hence I was not able to simplify the test case any, unfortunately. best regards, Kevin McCarty -- Summary: [4.3 regression] Bad interaction on ia64 between - funroll-loops -fno-automatic -O2 and common block variable Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kmccarty at debian dot org GCC build triplet: ia64-linux-gnu GCC host triplet: ia64-linux-gnu GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
[Bug fortran/35659] New: Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
Hi, [This bug was initially submitted to the Debian BTS at http://bugs.debian.org/466948 -- at the request of Debian's gcc maintainer, I am also sending it here] There is apparently a miscompilation of CERNLIB code in the "kernlib" library on ia64 with gfortran-4.3 at optimization level -O2 or higher. (Oddly, compiling with -O2 -funroll-loops does not expose the problem, which is why I didn't notice it earlier.) I've verified that this problem occurs on ia64 with gfortran-4.3 versions 4.3-20080202-1, 4.3-20080219-1 and 4.3.0. For the most recent trial: (sid)[EMAIL PROTECTED]:~$ gfortran-4.3 -v Using built-in specs. Target: ia64-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080309 (prerelease) (Debian 4.3.0-1) Please see the complete test case I've provided at http://people.debian.org/~kmccarty/tlsc-test-case.tar.gz [Note, the files libkernlib.a and libkerngent.a in the tarball were compiled on ia64 from CERNLIB source code, which is GPL; it is available from the Debian source package of "cernlib" version 2006.dfsg.2-10] [Note 2, I have updated this test case tarball to the gfortran version noted above since I originally submitted this bug to the Debian BTS.] The file tlsc.F in the test case is where the optimization bug happens. I saved files tlsc.f, tlsc.s and tlsc.o into subdirectories of the test case for three different combinations of compile flags: -O2 (causes miscompiled code) in obj-fail subdir -O0 (seems fine) -O2 -funroll-loops (seems fine) both in obj-success subdir. Also the output of the test case, saved as output.txt in each subdir. You can regenerate all of these files with these three combinations of compiler flags quickly with "make output". The presence or absence of -fno-automatic on the gfortran command line (I omitted it in all three cases) appears to make no difference. best regards, Kevin McCarty -- Summary: Miscompiled code with -O2 (but not with -O2 -funroll- loops) on ia64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kmccarty at debian dot org GCC build triplet: ia64-linux-gnu GCC host triplet: ia64-linux-gnu GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug fortran/35662] New: [4.3 regression] gfortran interfaces badly with glibc sincosf() causing breakage
Hi, On Debian's mips and mipsel ports, gfortran 4.3 at -O1 or higher generates object code that calls the sincosf() function in glibc's libm. Unfortunately the function call does not produce the correct result: it returns 0 for the sine and 1 for the cosine. Since an equivalent C program that uses sincosf() does yield the right results, I conclude that it is gfortran and not libm where the bug occurs -- somehow the call to sincosf() in the generated object code is wrong. (Not being too knowledgeable on either MIPS or assembly, I unfortunately can't tell you why. An erroneous assumption about the byte size of the sine and cosine values returned by sincosf(), perhaps?) This is a regression from gfortran 4.2.3, but the reason is apparently that previous gfortran versions do not generate calls to sincosf(). Version information: (sid)[EMAIL PROTECTED]:~$ gfortran-4.3 -v Using built-in specs. Target: mips-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080309 (prerelease) (Debian 4.3.0-1) Test case is at http://people.debian.org/~kmccarty/gfortran-sincos-err-mips.tar.gz The FORTRAN code is "sincos.F", and equivalent C code (I translated the FORTRAN to C by hand) that explicitly uses sincosf() is "sincos.c". The bad object code is located in subdirectories obj-fail/-O1 and obj-fail/-O2 of the tarball. Correct object code generated at -O0 is in obj-success/-O0, but may not be that useful for comparison, as the generated assembly with no optimization calls the sinf() and cosf() functions individually. Output of the FORTRAN and C programs are in "output.txt" and "coutput.txt", respectively, in each subdirectory. You can quickly regenerate these files with "make output". best regards, Kevin McCarty -- Summary: [4.3 regression] gfortran interfaces badly with glibc sincosf() causing breakage Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kmccarty at debian dot org GCC build triplet: mips-linux-gnu GCC host triplet: mips-linux-gnu GCC target triplet: mips-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35662
[Bug target/35659] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #2 from kmccarty at debian dot org 2008-03-24 16:47 --- (In reply to comment #1) > Does it work with gcc 4.2? Yes, it does, at least with this version: (sid)[EMAIL PROTECTED]:~$ gfortran-4.2 -v Using built-in specs. Target: ia64-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/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-objc-gc --enable-mpfr --disable-libmudflap --disable-libssp --with-system-libunwind --enable-checking=release --build=ia64-linux-gnu --host=ia64-linux-gnu --target=ia64-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-2) The test case works in all cases with gfortran 4.2, regardless of whether I use libkernlib.a and libkerngent.a compiled with gfortran 4.2 or 4.3. (But please let me know if you need copies of these libraries built with gfortran 4.2 anyway.) I also just noticed, surprisingly, that with gfortran 4.3, if I compile the test program with -O3 or with -O3 -funroll-loops, the test succeeds. So oddly enough it is ONLY with -O2 (without -funroll-loops) that the test fails. (Again, this behavior is independent of which gfortran version I use to build libkernlib.a and libkerngent.a.) Please also let me know if you need the intermediate .f and .o files built with gfortran-4.3 -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #5 from kmccarty at debian dot org 2008-05-21 03:50 --- (In reply to comment #4) > I wonder if this is related to PR target/35695, the floating point division > bug > that Jim Wilson fixed. Could you try it with ToT or with the latest 4.3 > branch, both of which have Jim's fix in them. I tried with the gcc-4_3-branch from Subversion today, but it doesn't change things: plain -O2 fails but both -O2 -funroll-loops and -O1 succeed on the test case. For the record: (sid)[EMAIL PROTECTED]:~$ ~/gcc-4.3-branch/bin/gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,fortran --prefix=/home/kmccarty/gcc-4.3-branch --enable-shared --with-mpfr=/home/kmccarty/gcc-4.3-branch Thread model: posix gcc version 4.3.1 20080521 (prerelease) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35658] [4.3/4.4 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable
--- Comment #3 from kmccarty at debian dot org 2008-05-21 03:59 --- (In reply to comment #2) > Test# 1 ( GENT ): *** failed *** > > I get this when I use -fno-automatic -O2 -funroll-loops and when I use no > optimization at all. This is with GCC 4.3 released bits and ToT bits on > a Debian 3.1 IA64 system. I tried again with the version of gcc from the 4.3 release branch (Subversion branch gcc-4_3-branch downloaded today) and can still reproduce the bug (and also can still reproduce the successes with no optimization or with -fno-automatic -O2 but not -funroll-loops). This is on an up-to-date Debian Sid system. (N.B. are you aware that Debian 3.1 is no longer security-supported?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
