--- 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.
--
h
--- 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
wrote:
> Somehow I got the impression that graphite is now enabled at -O2
We did enabled
--- 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 (
--- 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
INTEGE
--- 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
--- 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)') '
--- 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
--- 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_b
--- 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
--- 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=17125&action=view)
testcase reduced to single file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- 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
--- 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
--- 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=388
--- 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
--- 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
--- 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.
--
--- 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/bu
--- 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=17116&action=view)
diff of assembly from testcase.f under r143140 and r143152 on
i686-apple-darwin9
--
http://gcc.gn
--- 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=17115&action=view)
assembly file from testcase.f under r143152 on i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla/
--- 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=17114&action=view)
assembly file from testcase.f under r143140 on i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla/
--- 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
--- 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=17113&action=view)
testcase extracted from xplor-nih
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
22 matches
Mail list logo
