[Bug middle-end/44882] New: [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

[Bug middle-end/44882] New: [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

[hjl dot tools at gmail dot com]

On Linux/x86-64, revision 161953 failed to build 416.gamess in
SPEC CPU 2006:

gfortran -c -o vibanl.fppized.o -O3 -ffast-math -funroll-loops -ffixed-form
vibanl.fppized.f
trudge.fppized.f: In function 'trudia':
trudge.fppized.f:1037:0: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:3378
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: [4.6 Regression] Failed to build 416.gamess in SPEC CPU
                    2006
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/44882] [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

[hjl dot tools at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]



------- Comment #1 from hjl dot tools at gmail dot com  2010-07-09 00:28 -------
It is caused by revision 161949:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00303.html

[hjl@gnu-32 delta-fortran]$ cat testcase-min.f
      SUBROUTINE TRUDGE(KDIR)
      COMMON /TRUPAR/ DR(10),V(10,10)
      DO 110 I=1,NDIR
  110 DR(I)=V(I,JDIR)
      END
      SUBROUTINE TRUSRC(LEAVE)
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      COMMON /TRUPAR/ DX(10),V(10,10)
      END
[hjl@gnu-32 delta-fortran]$ /export/gnu/import/rrs/161949/usr/bin/gcc -S -O3
-ffast-math -funroll-loops -ffixed-form testcase-min.f
testcase-min.f:8.21:

      COMMON /TRUPAR/ DX(10),V(10,10)                                   
                     1
Warning: Named COMMON block 'trupar' at (1) shall be of the same size
testcase-min.f: In function ‘trudge’:
testcase-min.f:1:0: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:3378
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[hjl@gnu-32 delta-fortran]$ 


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.6.0


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

[Bug middle-end/44882] [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2010-07-09 08:15 -------
Confirmed on darwin. I also see the same ICE with -O3 for the polyhedron test
mdbx.f90.


-- 


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

[Bug middle-end/44882] [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2010-07-09 08:23 -------
Mine.  If I fix the warning

t.f90:8.21:

      COMMON /TRUPAR/ DX(10),V(10,10)                                   
                     1
Warning: Named COMMON block 'trupar' at (1) shall be of the same size

then the ICE vanishes.  Fix as in make DX and V implicit double precision
in trudge as well.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-09 08:23:10
               date|                            |


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

[Bug middle-end/44882] [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-09 08:33 -------
So we have

 <array_ref 0x7ffff7f0c240
    type <real_type 0x7ffff7ef1000 real(kind=4) SF
        size <integer_cst 0x7ffff7ed2708 constant 32>
        unit size <integer_cst 0x7ffff7ed2410 constant 4>
        align 32 symtab 0 alias set 2 canonical type 0x7ffff7ef1000 precision
32
        pointer_to_this <pointer_type 0x7ffff7ef11f8>>

    arg 0 <component_ref 0x7ffff7ee1400
        type <array_type 0x7ffff7fc8c78 type <real_type 0x7ffff7ef1000
real(kind=4)>
            type_2 BLK
            size <integer_cst 0x7ffff7fbe500 constant 320>
            unit size <integer_cst 0x7ffff7fbe668 constant 40>
            align 32 symtab 0 alias set 2 canonical type 0x7ffff7fc8c78 domain
<integer_type 0x7ffff7fcb000>
            pointer_to_this <pointer_type 0x7ffff7fcba80>>

        arg 0 <var_decl 0x7ffff7fcc000 trupar type <record_type 0x7ffff5ad9888>
            addressable public static ignored common decl_3 BLK defer-output
file t.f90 line 2 col 0
            size <integer_cst 0x7ffff7fcd2d0 constant 7040>
            unit size <integer_cst 0x7ffff7fcd280 constant 880>
            align 128 context <function_decl 0x7ffff7fc9c00 trudge> chain
<function_decl 0x7ffff7fc9c00 trudge>>
        arg 1 <field_decl 0x7ffff7fc6720 dr type <array_type 0x7ffff7fc8c78>
            BLK file t.f90 line 2 col 0 size <integer_cst 0x7ffff7fbe500 320>
unit size <integer_cst 0x7ffff7fbe668 40>
            align 32 offset_align 128
            offset <integer_cst 0x7ffff7ed2438 constant 0>
            bit offset <integer_cst 0x7ffff7ed2b40 constant 0> context
<record_type 0x7ffff7fcb930> chain <field_decl 0x7ffff7fc67b8 v>>>
    arg 1 <ssa_name 0x7ffff7fcf528
        type <integer_type 0x7ffff7ee45e8 integer(kind=8) public DI
            size <integer_cst 0x7ffff7ed27d0 constant 64>
            unit size <integer_cst 0x7ffff7ed27f8 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff7ee45e8
precision 64 min <integer_cst 0x7ffff7ed2758 -9223372036854775808> max
<integer_cst 0x7ffff7ed2780 9223372036854775807>
            pointer_to_this <pointer_type 0x7ffff7f235e8>>
        visited var <var_decl 0x7ffff7fcc6e0 D.1580>def_stmt D.1580_6 =
D.1579_5 + -1;

        version 6>>

and the record type is

 <record_type 0x7ffff5ad9888 BLK
    size <integer_cst 0x7ffff7fcd2d0 type <integer_type 0x7ffff7ee40a8
bit_size_type> constant 7040>
    unit size <integer_cst 0x7ffff7fcd280 type <integer_type 0x7ffff7ee4000>
constant 880>
    align 64 symtab 0 alias set 3 canonical type 0x7ffff5ad9888
    fields <field_decl 0x7ffff7fc6850 dx
        type <array_type 0x7ffff7fcbbd0 type <real_type 0x7ffff7ef10a8
real(kind=8)>


see how we are accessing trupar.dr as if it were an array of floats while
the structure type has an array of doubles as elements.

That is going to wreck TBAA.

Now, we could silently continue instead of ICEing here if using MEM_REFs.
The assert we have is basically, for the original access
trupar.dr[D.1580_6], assert that the outermost access alias-set conflicts
with the alias-set of the base object (trupar).  Which it does always
due to record_component_aliases --- iff the types were not wrecked in the
first place.

Thus, I'm simply going to remove the assert.


-- 


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

[Bug fortran/44882] [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-07-09 08:39 -------
I'm going to leave the bug open after that because I think the Fortran frontend
should do better than overriding the type of the common in TRUDGE from the
unused variant in TRUSRC.

Sooner or later you'll trip into another ICE with these mismatched types in
the IL.  Why can't this be a hard error?

Thus, re-assigning to Fortran component.  (yes, I'm still going to "fix" the
middle-end ICE)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |fortran


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

[Bug fortran/44882] [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-07-09 10:05 -------
Subject: Bug 44882

Author: rguenth
Date: Fri Jul  9 10:05:27 2010
New Revision: 161990

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

        PR tree-optimization/44882
        * tree-vect-stmts.c (vectorizable_store): Do not assert alias
        sets do conflict.
        (vectorizable_load): Likewise.

        * gfortran.dg/pr44882.f90: New testcase.

Added:
    trunk/gcc/testsuite/gfortran.dg/pr44882.f90
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vect-stmts.c


-- 


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

[Bug fortran/44882] [4.6 Regression] Bogus types in references with mismatched commons

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2010-07-09 10:10 -------
ICE fixed.  Fortran FE problem remains.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW
            Summary|[4.6 Regression] Failed to  |[4.6 Regression] Bogus types
                   |build 416.gamess in SPEC CPU|in references with
                   |2006                        |mismatched commons


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

[Bug fortran/44882] [4.6 Regression] Bogus types in references with mismatched commons

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2010-07-09 12:16 -------
(In reply to comment #5)
> I'm going to leave the bug open after that because I think the Fortran
> frontend should do better than overriding the type of the common in TRUDGE
> from the unused variant in TRUSRC.

Can you be a bit more specific what the solution of the problem should be?


> Sooner or later you'll trip into another ICE with these mismatched types in
> the IL.  Why can't this be a hard error?

"Named common blocks of the same name shall be of the same size in all scoping
units of a program in which they appear, but blank common blocks may be of
different sizes." (5.7.2.5, Fortran 2008 (FDIS).)

Thus, for blank commons, the standard requires to support it - while for named
commones (such as TRUPAR in comment 1), it does not allow it. However, that did
not stop people from doing so - and the number of (legacy) code which does so
is legion.


-- 


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

[Bug fortran/44882] [4.6 Regression] Bogus types in references with mismatched commons

[rguenther at suse dot de]

------- Comment #9 from rguenther at suse dot de  2010-07-09 12:21 -------
Subject: Re:  [4.6 Regression] Bogus types in references
 with mismatched commons

On Fri, 9 Jul 2010, burnus at gcc dot gnu dot org wrote:

> ------- Comment #8 from burnus at gcc dot gnu dot org  2010-07-09 12:16 -------
> (In reply to comment #5)
> > I'm going to leave the bug open after that because I think the Fortran
> > frontend should do better than overriding the type of the common in TRUDGE
> > from the unused variant in TRUSRC.
> 
> Can you be a bit more specific what the solution of the problem should be?

Good question.  I'd say never change types like that, just leave the
original type in place.  The code is not a valid fortran program anyway
and this avoids invalid trees in the middle-end.

So for the testcase make TRUPAR DR and V real=4, if you'd change it to

      SUBROUTINE TRUSRC(LEAVE)
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      COMMON /TRUPAR/ DX(10),V(10,10)
      END
      SUBROUTINE TRUDGE(KDIR)
      COMMON /TRUPAR/ DR(10),V(10,10)
      DO 110 I=1,NDIR
  110 DR(I)=V(I,JDIR)
      END

make it real=8.

> > Sooner or later you'll trip into another ICE with these mismatched types in
> > the IL.  Why can't this be a hard error?
> 
> "Named common blocks of the same name shall be of the same size in all scoping
> units of a program in which they appear, but blank common blocks may be of
> different sizes." (5.7.2.5, Fortran 2008 (FDIS).)
> 
> Thus, for blank commons, the standard requires to support it - while for named
> commones (such as TRUPAR in comment 1), it does not allow it. However, that did
> not stop people from doing so - and the number of (legacy) code which does so
> is legion.

And when compilers do not reject such code it will never be fixed ;)
Does GFortran have something like -fpermissive?


-- 


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

[Bug fortran/44882] [4.6 Regression] Bogus types in references with mismatched commons

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2010-07-09 13:22 -------
(In reply to comment #9)
> And when compilers do not reject such code it will never be fixed ;)
> Does GFortran have something like -fpermissive?

  -std=legacy

The problem with fixing: That helps for actively maintained code, but if
someone downloads some old program (like I did  a while ago with Cowan's
Hartree Fock code, written 30 years ago), one simply wants to use it and not to
fix correctness bugs. I sincerely hope that no one writes this in new code!


-- 


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

[Bug fortran/44882] [4.6 Regression] Bogus types in references with mismatched commons

[hjl dot tools at gmail dot com]

------- Comment #11 from hjl dot tools at gmail dot com  2010-07-09 13:51 -------
FWIW, the original testcase, vibanl.fppized.f, doesn't
have type mismatch.


-- 


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

[Bug fortran/44882] [4.6 Regression] Bogus types in references with mismatched commons

[dominiq at lps dot ens dot fr]

------- Comment #12 from dominiq at lps dot ens dot fr  2010-07-09 14:35 -------
Reduced test case extracted from the polyhedron test mdbx.f90 that give an ICE
at revision 161959:

[karma] lin/test% cat mdbx_red.f90
!*==MASTER.spg  processed by SPAG 6.55Dc at 09:26 on 23 Sep 2005
      SUBROUTINE MASTER(Nsteps,Nlist,Method,Skin,Ncorr,Nprint)
      IMPLICIT DOUBLE PRECISION(A-H,O-Z)
      PARAMETER (NM=16384)
      COMMON /SCRATC/ DUMmy1(NM) , DUMmy2(NM) , DUMmy3(NM) , DUMmy4(NM)
      END
!*==CBUILD.spg  processed by SPAG 6.55Dc at 09:26 on 23 Sep 2005
      SUBROUTINE CBUILD(Ransq,Icode)
      IMPLICIT DOUBLE PRECISION(A-H,O-Z)
      PARAMETER (NM=16384)
      PARAMETER (LL=10*NM)
      COMMON /LISCOM/ LISt(LL) , MRKr1(NM) , MRKr2(NM) , LISlen
      COMMON /SCRATC/ DUMmy1(NM) , DUMmy2(NM) , DUMmy3(NM) , DUMmy4(NM)
      INTEGER MARk(NM)
      EQUIVALENCE (MARk,DUMmy1)
      EQUIVALENCE (KNTnts,DUMmy2)
      PARAMETER (NNEMAX=512)
      INTEGER neigh(NNEMAX)
      PARAMETER (KNTSIZ=3*NM)
      INTEGER KNTnts(KNTSIZ)
      DO icell = 0 , ncells - 1
         DO jpc = ipc + 1 , npc(icell)
            neigh(nneigc+jpc-ipc) = KNTnts(jpc+icoffs)
         ENDDO
         DO icand = 1 , nneigi
            LISt(nll) = neigh(icand)
            nll = nll + MARk(icand)
         ENDDO
      ENDDO
      END
[karma] lin/test% gfc -O3 mdbx_red.f90
mdbx_red.f90: In function 'cbuild':
mdbx_red.f90:8:0: internal compiler error: in vectorizable_load, at
tree-vect-stmts.c:3828


-- 


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

[Bug fortran/44882] Bogus types in references with mismatched commons

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2010-09-02 10:51 -------
The bogus types are not a regression.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.6 Regression] Bogus types|Bogus types in references
                   |in references with          |with mismatched commons
                   |mismatched commons          |
   Target Milestone|4.6.0                       |---


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