[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- 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

[Bug middle-end/38868] New: r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

The change....

Author: rguenth
Date: Wed Jan  7 10:53:30 2009
New Revision: 143152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143152
Log:
2009-01-07  Richard Guenther  <rguenther@suse.de>

        PR middle-end/38751
        * fold-const.c (extract_muldiv): Remove obsolete comment.
        (fold_plusminus_mult_expr): Undo MINUS_EXPR
        to PLUS_EXPR canonicalization for the canonicalization.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c

causes broken code in xplor-nih when compiled with -O2 or higher. Specifically,
the output
routine in xplor-nih losses the final character of a line. For example...

 | Etotal =-0.012     grad(E)=0.005      E(BOND)=0.000      E(ANGL)=0.000     
|
 | E(DIHE)=0.000      E(IMPR)=0.000      E(VDW )=-0.012     E(ELEC)=0.000     
|

becomes...

 | Etotal =-0.012     grad(E)=0.005      E(BOND)=0.000      E(ANGL)=0.000     
|
 | E(DIHE)=0.000      E(IMPR)=0.000      E(VDW )=-0.012     E(ELEC)=0.000       

The problem doesn't occur at -O0 or -O1 and doesn't occur if I use
-funroll-loops or
-funroll-all-loops. I also can also suppress the problem by adding a final
write(6,*) statement
to the test program.


-- 
           Summary: r143152 breaks output routines in xplor-nih
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- 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

[howarth at nitro dot med dot uc dot edu]

------- 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/show_bug.cgi?id=38868

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- 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/show_bug.cgi?id=38868

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- 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.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- 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

[howarth at nitro dot med dot uc dot edu]

------- 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

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[dominiq at lps dot ens dot fr]

------- 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

[howarth at nitro dot med dot uc dot edu]

------- 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

[howarth at nitro dot med dot uc dot edu]

------- 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.000000000 -0500
+++ testcase.f  2009-01-16 10:28:47.000000000 -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.000000000 -0500
+++ testcase.f  2009-01-16 10:31:40.000000000 -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

[howarth at nitro dot med dot uc dot edu]

------- 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

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- 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

[howarth at nitro dot med dot uc dot edu]

------- 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

[howarth at nitro dot med dot uc dot edu]

------- 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
81            WRITE(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
84            IF (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

[howarth at nitro dot med dot uc dot edu]

------- 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
81            WRITE(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

[rguenth at gcc dot gnu dot org]

------- 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

[dominiq at lps dot ens dot fr]

------- 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

[jvdelisle at gcc dot gnu dot org]

------- 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

[sebpop at gmail dot com]

------- 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-bugzilla@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

[jvdelisle at gcc dot gnu dot org]

------- 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] [4.4 Regression] r143152 breaks output routines in xplor-nih

[burnus at gcc dot gnu dot org]

------- Comment #23 from burnus at gcc dot gnu dot org  2009-01-17 22:51 -------
Program of comment 19 works here (x86-64) with all options I tried, incl. -m32,
-fgraphite-identity etc. - valgrind shows no problems.

For the program in attachment 17125 / commment 13: I get the same valgrind
output as Richard, but comparing with NAG f95 shows similar valgrind errors and
with checking turned on, the NAG f95 compiled program aborts with:
  Reference to undefined variable ANER
  In PRINT2, line 162 of test.f


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org
            Summary|r143152 breaks output       |[4.4 Regression] r143152
                   |routines in xplor-nih       |breaks output routines in
                   |                            |xplor-nih


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #24 from howarth at nitro dot med dot uc dot edu  2009-01-17 23:23 -------
I've had no luck triggering this problem on targets other than
i686-apple-darwin9. On that target -m64, suppresses the problem. As to the
issue with ANER(J) being undefined on line 162, this can be fixed with...

--- testcase2.f.org     2009-01-17 18:21:01.000000000 -0500
+++ testcase2.f 2009-01-17 18:22:00.000000000 -0500
@@ -17,6 +17,7 @@
       RENRL(SSSD)=5.03071296871847578E-003

       DO I=1,NENERT
+      ANER(I)='    '
       QENER(I)=.false.
       END DO

but has no impact on the bug observed under Intel darwin9 either way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[dominiq at lps dot ens dot fr]

------- Comment #25 from dominiq at lps dot ens dot fr  2009-01-17 23:28 -------
In the reduced case in comment #19 ANER is initialized and the output is still
wrong.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[dominiq at lps dot ens dot fr]

------- Comment #26 from dominiq at lps dot ens dot fr  2009-01-17 23:48 -------
Further reduced test case:

      PROGRAM testcase
      IMPLICIT NONE

      INTEGER NENERT
      PARAMETER (NENERT=62)
      CHARACTER*4 ANER(NENERT)
      CHARACTER*80 LINE
      INTEGER PUNIT
      PUNIT = 6
      aner = ''
      ANER(5)='BOND'
      ANER(6)='ANGL'
      LINE=' '
      LINE(2:2)='|'
      LINE(80:80)='|'
      write (10,*) "'", line, "'"
      WRITE(PUNIT,'(A80)') LINE
      END

[ibook-dhum] f90/bug% cat fort.10
 ' |                                                                           
  '

If I comment one of the two lines:

      ANER(5)='BOND'
      ANER(6)='ANGL'

the bug disappears.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[dominiq at lps dot ens dot fr]

------- Comment #27 from dominiq at lps dot ens dot fr  2009-01-18 12:00 -------
Further reduced test case:

      PROGRAM testcase
      IMPLICIT NONE

      CHARACTER*4 ANER(18)
      CHARACTER*80 LINE
      aner = ''
      ANER(1)='A   '
      ANER(2)='    '
      LINE=' '
      LINE(78:80)='xyz'
      WRITE(*,'(A82)') "'"//LINE//"'"
      END

With this test almost any change remove the bug: the lenght of line has to be
80, the size of the array ANER has to be 18 or larger, LINE has to be
initialized with ' ' and not '', the two ANER elements have to contain at least
one nonblank character, ANER has to be initialized before its two elements, ...
.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[dominiq at lps dot ens dot fr]

------- Comment #28 from dominiq at lps dot ens dot fr  2009-01-18 12:06 -------
The difference between the results of -fdump-tree-optimized for the cases

      aner = ''
      ANER(1)='A   '
      ANER(2)='    '

and

      ANER(1)='A   '
      ANER(2)='    '
      aner = ''

is ('pre' with the bug, 'rev' without it)

--- pr38868_red_2.f90-pre       2009-01-18 12:42:15.000000000 +0100
+++ pr38868_red_2.f90-rev       2009-01-18 12:41:33.000000000 +0100
@@ -16,6 +16,8 @@

 <bb 2>:
   _gfortran_set_options (8, &options.0);
+  aner[0] = "A   ";
+  aner[1] = "    ";
   ivtmp.33 = 0;

 <bb 3>:
@@ -27,8 +29,6 @@
     goto <bb 3>;

 <bb 4>:
-  aner[0] = "A   ";
-  aner[1] = "    ";
   __builtin_memcpy (&line, &" "[1]{lb: 1 sz: 1}, 1);
   __builtin_memset (&line[2]{lb: 1 sz: 1}, 32, 79);
   __builtin_memcpy (&line[78]{lb: 1 sz: 1}, &"xyz"[1]{lb: 1 sz: 1}, 3);

Can anyone see the difference between the two marked lines? The hexdump for the
diff without -u is:

00000000  31 38 61 31 39 2c 32 30  0a 3e 20 20 20 61 6e 65  |18a19,20.>   ane|
00000010  72 5b 30 5d 20 3d 20 22  41 20 20 20 22 3b 0a 3e  |r[0] = "A   ";.>|
00000020  20 20 20 61 6e 65 72 5b  31 5d 20 3d 20 22 20 20  |   aner[1] = "  |
00000030  20 20 22 3b 0a 33 30 2c  33 31 64 33 31 0a 3c 20  |  ";.30,31d31.< |
00000040  20 20 61 6e 65 72 5b 30  5d 20 3d 20 22 41 20 20  |  aner[0] = "A  |
00000050  20 22 3b 0a 3c 20 20 20  61 6e 65 72 5b 31 5d 20  | ";.<   aner[1] |
00000060  3d 20 22 20 20 20 20 22  3b 0a                    |= "    ";.|

The difference between the assembly is:

--- pr38868_red_2.s-pre 2009-01-18 12:50:15.000000000 +0100
+++ pr38868_red_2.s-rev 2009-01-18 12:51:04.000000000 +0100
@@ -26,34 +26,34 @@
        leal    _options.0.1497-"L00000000001$pb"(%ebx), %eax
        movl    %eax, 4(%esp)
        call    L__gfortran_set_options$stub
-       xorl    %eax, %eax
+       movl    LC0-"L00000000001$pb"(%ebx), %eax
        leal    -96(%ebp), %edx
+       movl    %eax, -96(%ebp)
+       movl    LC1-"L00000000001$pb"(%ebx), %eax
+       movl    %eax, -92(%ebp)
+       xorl    %eax, %eax
        .align 4,0x90
 L2:
        movl    $538976288, (%edx,%eax,4)
        addl    $1, %eax
        cmpl    $18, %eax
        jne     L2
-       movl    LC0-"L00000000001$pb"(%ebx), %eax
        leal    -172(%ebp), %edi
-       movl    $19, %ecx
-       leal    -176(%ebp), %esi
-       movb    $32, -176(%ebp)
-       movb    $32, -175(%ebp)
-       movl    %eax, -96(%ebp)
-       movl    LC1-"L00000000001$pb"(%ebx), %eax
-       movw    $8224, -174(%ebp)
-       movw    $31096, -99(%ebp)
-       movb    $122, -97(%ebp)
-       movl    %eax, -92(%ebp)
        movl    $538976288, %eax
+       movl    $19, %ecx
        rep stosl
        leal    LC2-"L00000000001$pb"(%ebx), %eax
        leal    -680(%ebp), %edi
        movl    %eax, -672(%ebp)
        leal    LC3-"L00000000001$pb"(%ebx), %eax
+       leal    -176(%ebp), %esi
        movl    %eax, -632(%ebp)
        movl    %edi, (%esp)
+       movb    $32, -176(%ebp)
+       movb    $32, -175(%ebp)
+       movw    $8224, -174(%ebp)
+       movw    $31096, -99(%ebp)
+       movb    $122, -97(%ebp)
        movl    $11, -668(%ebp)
        movl    $5, -628(%ebp)
        movl    $4096, -680(%ebp)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[dominiq at lps dot ens dot fr]

------- Comment #29 from dominiq at lps dot ens dot fr  2009-01-18 12:50 -------
Created an attachment (id=17133)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17133&action=view)
Assembly corresponding to the test case in comment #27

When I compile the attached file with gfortran 4.3, the executable shows the
bug. Could this file be compiled on linux?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[dominiq at lps dot ens dot fr]

------- Comment #30 from dominiq at lps dot ens dot fr  2009-01-18 13:13 -------
If I compile the test in comment #27 with -O1 and all the other flags supposed
to be turned on by -O2
(taken from
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options) the
bug does not show up. What are the missing differences between -O1 and -O2?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[burnus at gcc dot gnu dot org]

------- Comment #31 from burnus at gcc dot gnu dot org  2009-01-18 13:24 -------
(In reply to comment #27)
> Further reduced test case:

Using gfortran on x86-64-linux, I see with -m64 and all -O* a line which ends
in "  xyz'". However, with -m32 and -O<n> (n >= 2) I only see:
"    z'". I tried to reproduce it with 4.3 but there it works.

I looked at *.123t.optimized but it showes no difference.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|i686-apple-darwin9          |
   GCC host triplet|i686-apple-darwin9          |
 GCC target triplet|i686-apple-darwin9          |
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[burnus at gcc dot gnu dot org]

------- Comment #32 from burnus at gcc dot gnu dot org  2009-01-18 13:25 -------
Created an attachment (id=17134)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17134&action=view)
Assembler diff on x86-64-openSUSE Factory with -m32 -O1 (working) and -m32 -O2
(failing)

Attached the assembler difference.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #33 from howarth at nitro dot med dot uc dot edu  2009-01-18 17:02 -------
Could the additional .p2align assembly operands in the failing assembly have
anything to do with this problem?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #34 from howarth at nitro dot med dot uc dot edu  2009-01-18 19:49 -------
I also see the testcase in Comment 27 fail when compiled at -O2 or higher with
i686-apple-darwin10. As with i686-apple-darwin9, the problem only occurs with
-m32 and not -m64.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

------- Comment #35 from rguenth at gcc dot gnu dot org  2009-01-19 10:29 -------
I can reproduce the issue with the testcase in comment #27 on x86_64-linux
with -m32 -O2 vs. -m32 -O.

It can be reduced to the effect of -fschedule-insns2 and -fforward-propagate
(disabling either on -O2 -fno-strict-aliasing is enough to fix the failure,
enabling both is enough to trigger the failure with -O).

I didn't track down which asm difference makes it fail, but there are some
changes across calls which look dubious.  CCing Paolo and Steven ...


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stevenb dot gcc at gmail dot
                   |                            |com, bonzini at gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-19 10:29:50
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

------- Comment #36 from bonzini at gnu dot org  2009-01-19 10:33 -------
Would you please attach the assembler diff:
1) between -m32 -O1 and -m32 -O1 -fforward-propagate
2) between the latter and -m32 -O1 -fforward-propagate -fschedule-insns2?

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

------- Comment #37 from bonzini at gnu dot org  2009-01-19 10:36 -------
This is the fishy part: notice that the %esi in the failing test case is
completely bogus.

-       leal    -680(%ebp), %esi
-       movb    $32, (%esi)
-       movb    $32, -679(%ebp)
-       movw    $8224, -678(%ebp)
+       leal    -176(%ebp), %ebx
+       leal    -257(%ebp), %esi
+       movb    $32, -176(%ebp)
+       movb    $32, -175(%ebp)
+       movw    $8224, -174(%ebp)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

------- Comment #38 from rguenth at gcc dot gnu dot org  2009-01-19 10:50 -------
Created an attachment (id=17139)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17139&action=view)
assembler diff between -O -m32 -fforward-propagate and -O -m32
-fforward-propagate -fschedule-insns2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

------- Comment #39 from bonzini at gnu dot org  2009-01-19 11:04 -------
Looks like a scheduling bug:

-O1 -fforward-propagate has
        leal    -676(%ebp), %edi
        movl    $19, %ecx
        movl    $538976288, %eax
        rep stosl
        movw    $31096, -603(%ebp)
        movb    $122, -601(%ebp)

-O1 -fforward-propagate -fschedule-insns has
        leal    -676(%ebp), %edi
        movl    $19, %ecx
        movw    $31096, -603(%ebp)
        movl    $538976288, %eax
        rep stosl
        movb    $122, -601(%ebp)

and 676+19*4 = 600 so -603(%ebp) is 0x2020 in the bad code, 0x7978 in the good
code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

------- Comment #40 from rguenth at gcc dot gnu dot org  2009-01-19 12:20 -------
Which means this might be a target bug as well, more specifically a bug in the
*rep_stossi pattern.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uros at gcc dot gnu dot org,
                   |                            |hubicka at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

------- Comment #41 from rguenth at gcc dot gnu dot org  2009-01-19 12:37 -------
In

(insn 37 86 40 4 t.f:9 (parallel [
            (set (reg:SI 2 cx [74])
                (const_int 0 [0x0]))
            (set (reg/f:SI 5 di [72])
                (plus:SI (ashift:SI (reg:SI 2 cx [74])
                        (const_int 2 [0x2]))
                    (reg/f:SI 5 di [72])))
            (set (mem/s/j:BLK (reg/f:SI 5 di [72]) [0 line+80 A32])
                (const_int 0 [0x0]))
            (use (reg:SI 0 ax [73]))
            (use (reg:SI 2 cx [74]))
        ]) 856 {*rep_stossi} (expr_list:REG_DEAD (reg:SI 0 ax [73])
        (expr_list:REG_UNUSED (reg/f:SI 5 di [72])
            (expr_list:REG_UNUSED (reg:SI 2 cx [74])
                (nil)))))

the MEM_EXPR of

            (set (mem/s/j:BLK (reg/f:SI 5 di [72]) [0 line+80 A32])
                (const_int 0 [0x0]))

is bogus, it should be line, not line+80.  Does forwprop adjust MEM_EXPRs
properly?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

------- Comment #42 from rguenth at gcc dot gnu dot org  2009-01-19 12:40 -------
Rather it is broken from expansion:

;; __builtin_memset (&line[2]{lb: 1 sz: 1}, 32, 79);

(insn 28 27 29 t.f:9 (parallel [
            (set (reg:SI 70)
                (plus:SI (reg/f:SI 54 virtual-stack-vars)
                    (const_int -656 [0xfffffffffffffd70])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil))

(insn 29 28 30 t.f:9 (parallel [
            (set (reg:SI 71)
                (plus:SI (reg:SI 70)
                    (const_int 1 [0x1])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil))

(insn 30 29 31 t.f:9 (set (reg:SI 72)
        (reg:SI 71)) -1 (nil))

(insn 31 30 32 t.f:9 (set (reg:SI 73)
        (const_int 538976288 [0x20202020])) -1 (nil))

(insn 32 31 33 t.f:9 (set (mem/s/j:QI (reg:SI 72) [0 line+1 S1 A8])
        (subreg:QI (reg:SI 73) 0)) -1 (nil))

(insn 33 32 34 t.f:9 (parallel [
            (set (reg:SI 72)
                (plus:SI (reg:SI 72)
                    (const_int 1 [0x1])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil))

(insn 34 33 35 t.f:9 (set (mem/s/j:HI (reg:SI 72) [0 line+2 S2 A16])
        (subreg:HI (reg:SI 73) 0)) -1 (nil))

(insn 35 34 36 t.f:9 (parallel [
            (set (reg:SI 72)
                (plus:SI (reg:SI 72)
                    (const_int 2 [0x2])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil))

(insn 36 35 37 t.f:9 (set (reg:SI 74)
        (const_int 19 [0x13])) -1 (nil))

(insn 37 36 0 t.f:9 (parallel [
            (set (reg:SI 74)
                (const_int 0 [0x0]))
            (set (reg:SI 72)
                (plus:SI (ashift:SI (reg:SI 74)
                        (const_int 2 [0x2]))
                    (reg:SI 72)))
            (set (mem/s/j:BLK (reg:SI 72) [0 line+80 A32])
                (const_int 0 [0x0]))
            (use (reg:SI 73))
            (use (reg:SI 74))
        ]) -1 (nil))


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target
 GCC target triplet|                            |i?86-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

------- Comment #43 from bonzini at gnu dot org  2009-01-19 14:06 -------
The bug is actually in target independent code.  The code to change_address_1
in adjust_address_1 does nothing if the addr is simple, and this causes the
creation of shared or wrong RTL.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

------- Comment #44 from bonzini at gnu dot org  2009-01-19 15:03 -------
Created an attachment (id=17146)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17146&action=view)
patch under test

testing this patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[dominiq at lps dot ens dot fr]

------- Comment #45 from dominiq at lps dot ens dot fr  2009-01-19 19:31 -------
The patch in comment #44 fixes the problem (as far as I can test it) on
i686-apple-darwin9 without regression for gcc, g++, gfortran, objc, and
obj-c++, full test this night.

Thanks for the patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #46 from howarth at nitro dot med dot uc dot edu  2009-01-19 23:44 -------
I can confirm that gcc trunk with the proposed patch can now build xplor-nih at
-O3 (with to resorting to -funroll-loops) and the output code works correctly
now on i686-apple-darwin9. Thanks for fixing this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gcc dot gnu dot org]

------- Comment #47 from bonzini at gnu dot org  2009-01-20 13:24 -------
Subject: Bug 38868

Author: bonzini
Date: Tue Jan 20 13:24:25 2009
New Revision: 143513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143513
Log:
gcc:
2008-01-20  Paolo Bonzini  <bonzini@gnu.org>

        PR target/38868
        * emit-rtl.c (adjust_address_1): Make sure memref is never
        overwritten.

gcc/testsuite:
2008-01-20  Paolo Bonzini  <bonzini@gnu.org>

        PR target/38868
        * gfortran.dg/pr38868.f: New testcase.


Added:
    trunk/gcc/testsuite/gfortran.dg/pr38868.f
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/emit-rtl.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

------- Comment #48 from bonzini at gnu dot org  2009-01-20 13:25 -------
Fixed; the bug is latent in 4.3.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[hjl dot tools at gmail dot com]

------- Comment #49 from hjl dot tools at gmail dot com  2009-01-20 14:27 -------
(In reply to comment #48)
> Fixed; the bug is latent in 4.3.
> 

The testcase should be added to 4.3 to make sure that it remains latent
even with future backports.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[hjl at gcc dot gnu dot org]

------- Comment #50 from hjl at gcc dot gnu dot org  2009-01-24 15:26 -------
Subject: Bug 38868

Author: hjl
Date: Sat Jan 24 15:26:14 2009
New Revision: 143645

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143645
Log:
2009-01-24  H.J. Lu  <hongjiu.lu@intel.com>

        Backport from mainline:
        2008-01-20  Paolo Bonzini  <bonzini@gnu.org>

        PR target/38868
        * gfortran.dg/pr38868.f: New testcase.

Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/pr38868.f
Modified:
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868