[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-01-17 10:57 --- Well, I don't know how fortran strings are supposed to work, but for the 80 chars in a C string you need 81 bytes, 1 byte for the terminating null character. Also you single-file testcase prints nothing at -O0 for me, the expected output with optimization. At -O0 I see loads of ==5461== Conditional jump or move depends on uninitialised value(s) ==5461==at 0x40D1E7A: (within /usr/lib/libgfortran.so.3.0.0) ==5461==by 0x40D0921: (within /usr/lib/libgfortran.so.3.0.0) ==5461==by 0x8048FA6: print2_ (in /tmp/t) ==5461==by 0x8048A16: printe_ (in /tmp/t) ==5461==by 0x8048819: MAIN__ (in /tmp/t) ==5461== Use of uninitialised value of size 4 ==5461==at 0x41624E6: (within /lib/i686/cmov/libc-2.7.so) ==5461==by 0x4165C9B: vfprintf (in /lib/i686/cmov/libc-2.7.so) ==5461==by 0x418B323: vsnprintf (in /lib/i686/cmov/libc-2.7.so) ==5461==by 0x416D451: snprintf (in /lib/i686/cmov/libc-2.7.so) ==5461==by 0x40CB189: (within /usr/lib/libgfortran.so.3.0.0) ==5461==by 0x40D0CBA: (within /usr/lib/libgfortran.so.3.0.0) ==5461==by 0x8048FA6: print2_ (in /tmp/t) ==5461==by 0x8048A16: printe_ (in /tmp/t) ==5461==by 0x8048819: MAIN__ (in /tmp/t) this is with GFortran 4.3. With GFortran 4.4 I get output at -O0 but also ==5485== Conditional jump or move depends on uninitialised value(s) ==5485==at 0x40D1E7A: (within /usr/lib/libgfortran.so.3.0.0) ==5485==by 0x40D0921: (within /usr/lib/libgfortran.so.3.0.0) ==5485==by 0x8048FC0: print2_ (in /tmp/t) ==5485==by 0x80489F7: printe_ (in /tmp/t) ==5485==by 0x80487FC: MAIN__ (in /tmp/t) ==5485==by 0x80493F8: main (in /tmp/t) so I guess this is a problem in the Fortran runtime or the problem is exposed there. But I wonder why there is a difference with optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #19 from dominiq at lps dot ens dot fr 2009-01-17 12:29 ---
Further reduced test case:
PROGRAM testcase
IMPLICIT NONE
INTEGER NENERT
PARAMETER (NENERT=62)
LOGICAL QENER(NENERT)
CHARACTER*4 ANER(NENERT)
CHARACTER*80 LINE
INTEGER NTERMS, J, START, STOP, PUNIT
PUNIT = 6
qener = .false.
qener(5:10) = .true.
aner = ''
ANER(5)='BOND'
ANER(6)='ANGL'
ANER(7)='DIHE'
ANER(8)='IMPR'
ANER(9) ='VDW '
ANER(10)='ELEC'
LINE=' '
LINE(2:2)='|'
LINE(80:80)='|'
NTERMS=2
DO J=1,NENERT
! IF (QENER(J).AND.ANER(J).NE.'') THEN
IF (QENER(J)) THEN
IF (NTERMS.GE.4) THEN
WRITE(PUNIT,'(A80)') LINE
LINE=' '
LINE(2:2)='|'
LINE(80:80)='|'
NTERMS=0
write(10,*) LINE
END IF
NTERMS=NTERMS+1
START=(NTERMS-1)*19 +3
STOP=NTERMS*19+2
write (10,*) stop, LINE(80:80)
WRITE(LINE(START:STOP),'(4A)') ' E(',ANER(J),')='
END IF
END DO
IF (NTERMS.GE.1) WRITE(PUNIT,'(A80)') LINE
END
gives at -O3
| E(BOND)= E(ANGL)=
| E(DIHE)= E(IMPR)= E(VDW )= E(ELEC)=
|
If I replace the line
IF (QENER(J)) THEN
by the commented one, I get
| E(BOND)= E(ANGL)=
| E(DIHE)= E(IMPR)= E(VDW )= E(ELEC)=
The content of fort.10 show that the content of LINE(80:80) is wrong.
One thing I did not realized when writing comment #10, is that I don't build
gcc with graphite on my G5:
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=powerpc-apple-darwin9
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.4.0 20090116 (experimental) [trunk revision 143431] (GCC)
while I have it on i686-apple-darwin9:
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--with-cloog=/opt/cloog/build --with-ppl=/opt/ppl/build
Thread model: posix
gcc version 4.4.0 20090116 (experimental) [trunk revision 143431p3] (GCC)
Somehow I got the impression that graphite is now enabled at -O2, although I
may have misunderstood what I read. Could the correlation of this pr with
graphite be checked? Just in case I cc Sebastian Pop.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
CC||sebpop at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-01-17 12:54 --- With Dominique's reduced test case I see three valgrind errors. Actual output is fine. I am looking further. ==4359== Conditional jump or move depends on uninitialised value(s) ==4359==at 0x43793D: strlen (in /home/jerry/prs/pr38868/a.out) ==4359==by 0x40871F: write_integer (write.c:859) ==4359==by 0x40BB4E: _gfortrani_list_formatted_write (write.c:1081) ==4359==by 0x400610: MAIN__ (pr38868.f:38) ==4359==by 0x400819: main (fmain.c:21) ==4359== ==4359== Conditional jump or move depends on uninitialised value(s) ==4359==at 0x4170A4: __ctype_toupper_loc (in /home/jerry/prs/pr38868/a.out) ==4359==by 0x40DF02: next_char (format.c:93) ==4359==by 0x40DFAE: format_lex (format.c:183) ==4359==by 0x40EE86: _gfortrani_parse_format (format.c:1034) ==4359==by 0x4053F7: data_transfer_init (transfer.c:1932) ==4359==by 0x4006D6: MAIN__ (pr38868.f:39) ==4359==by 0x400819: main (fmain.c:21) ==4359== ==4359== Conditional jump or move depends on uninitialised value(s) ==4359==at 0x417064: __ctype_b_loc (in /home/jerry/prs/pr38868/a.out) ==4359==by 0x40E15F: format_lex (format.c:168) ==4359==by 0x40E34C: parse_format_list (format.c:463) ==4359==by 0x40EEB7: _gfortrani_parse_format (format.c:1035) ==4359==by 0x4053F7: data_transfer_init (transfer.c:1932) ==4359==by 0x4006D6: MAIN__ (pr38868.f:39) ==4359==by 0x400819: main (fmain.c:21) | E(BOND)= E(ANGL)= | | E(DIHE)= E(IMPR)= E(VDW )= E(ELEC)= | ==4359== -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #21 from sebpop at gmail dot com 2009-01-17 15:11 --- Subject: Re: r143152 breaks output routines in xplor-nih On Sat, Jan 17, 2009 at 6:29 AM, dominiq at lps dot ens dot fr gcc-bugzi...@gcc.gnu.org wrote: Somehow I got the impression that graphite is now enabled at -O2 We did enabled -floop-block and -fgraphite-identity in -O2 and higher, again, only in the graphite branch, not in trunk. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2009-01-17 16:40 --- Comment 20 was compiled with -static -g. Each error is at functions outside libgfortran. Valgrind reports zero errors if the test case is compiled without -static. I suspect comment 20 is misleading. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-01-16 08:14 --- Regressing r143152 from current gcc trunk also eliminates the problem confirming that commit is the origin of the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-16 09:42 --- I tried to reproduce this on i686-linux without success (-O3 -fPIC -mfpmath=sse -msse2 -m32). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #10 from dominiq at lps dot ens dot fr 2009-01-16 10:00 --- I don't see any problem on powerpc-apple-darwin9, but I confirm it on i686-apple-darwin9 on 32 bit mode. The problem disappear with either -m64 and/or -fno-pic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-01-16 15:27 --- I've not had any luck reproducing this issue on linux. A few other notes. I don't see this problem with the Macintel gfortran binaries from... http://gcc.gnu.org/wiki/GFortranBinaries However those may be built under darwin8 since they run on both darwin8 and darwin9. Also if I reduce the test case to just a set of assignments and write statements, the problem isn't reproduced. I'll try to reduce the existing test case down further but suspect this will have be analyzed from the differences in the generated assembly with and with r143152. I have also verified that the same binary produces the incorrect results on a MacPro (Xeon) and a MacBook Pro (Core 2 Duo). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-01-16 15:33 --- Any ideas on how to debug this further locally? If I add,,, --- testcase.f.org 2009-01-16 10:28:14.0 -0500 +++ testcase.f 2009-01-16 10:28:47.0 -0500 @@ -194,5 +194,6 @@ WRITE(PUNIT,'(A80)') LINE ENDIF C + write(6,*) RETURN END or --- testcase.f.org 2009-01-16 10:28:14.0 -0500 +++ testcase.f 2009-01-16 10:31:40.0 -0500 @@ -159,6 +159,7 @@ IF (QENER(J).AND.ANER(J).NE.'') THEN IF (NTERMS.GE.4) THEN WRITE(PUNIT,'(A80)') LINE + write(6,*) LINE=' ' LINE(2:2)='|' LINE(80:80)='|' the problem is suppressed. The issue is also suppressed with,,, -O0 -O1 -O2/-O3 -funroll-loops -O2/-O3 -funroll-all-loops -O2/-O3 -fno-PIC I've tried about every other option and those don't suppress the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-01-17 00:49 --- Created an attachment (id=17125) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17125action=view) testcase reduced to single file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-01-17 00:58 --- Breaking this down into separate files, as expected, the regression only occurs when the PRINT2 subroutine is compiled at -O2 or higher. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-01-17 01:02 --- I have no idea what this means, but if I change... CHARACTER*80 LINE in the PRINT2 subroutine to... CHARACTER*81 LINE the error at -O3 disappears. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-01-17
01:13 ---
If I use gdb (which doesn't suppress the bug like write statements do), and add
break points at...
STOP=NTERMS*19+2
WRITE(LINE(START:STOP),'(4A)') ' E(',ANER(J),')=',ST(1:STLEN)
END IF
bracketing the write statement that sets the LINE characters, I get...
Starting program: /Users/howarth/testcase3/a.out
Breakpoint 1, print2 (qspcl=.TRUE., renrl=()) at print2.f:81
81WRITE(LINE(START:STOP),'(4A)') ' E(',ANER(J),')=',ST(1:STLEN)
(gdb) p LINE
$3 = ' | Etotal =-0.012 grad(E)=0.005', ' ' repeats 44 times, '|'
(gdb) c
Continuing.
| Etotal =-0.012 grad(E)=0.005 E(BOND)=0.000 E(ANGL)=0.000
|
Breakpoint 2, print2 (qspcl=.TRUE., renrl=()) at print2.f:84
84IF (NTERMS.GE.1) WRITE(PUNIT,'(A80)') LINE
(gdb) p LINE
$4 = ' | E(DIHE)=0.000 E(IMPR)=0.000 E(VDW )=-0.012 E(ELEC)=0.000
'
with the original 80 character LINE declaration.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-01-17
01:17 ---
Hmm, I can't look at what happens to START or STOP at those break points
because gdb reports...
Breakpoint 1, print2 (qspcl=.TRUE., renrl=()) at print2.f:81
81WRITE(LINE(START:STOP),'(4A)') ' E(',ANER(J),')=',ST(1:STLEN)
(gdb) p START
$1 = variable optimized away by compiler
Current language: auto; currently fortran
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-01-16 07:07 --- Created an attachment (id=17113) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17113action=view) testcase extracted from xplor-nih -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-01-16 07:08 --- The problem exists in r143152 but not r143140. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-01-16 07:10 --- Created an attachment (id=17114) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17114action=view) assembly file from testcase.f under r143140 on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-01-16 07:11 --- Created an attachment (id=17115) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17115action=view) assembly file from testcase.f under r143152 on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-01-16 07:12 --- Created an attachment (id=17116) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17116action=view) diff of assembly from testcase.f under r143140 and r143152 on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-01-16 07:14 --- I haven't had any luck reproducing this under Linux but since the problem is suppressed by adding write statements it may be a bad memory access that only darwin is triggering. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-01-16 07:21 --- This problem is also suppressed on i686-apple-darwin9 if I compile with... gfortran -O3 -fno-PIC testcase.f ...since Darwin defaults to -fPIC, this may be why I wasn't seeing the failure on Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
