[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368

--- Comment #31 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 5 Feb 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to Wilco from comment #29)
> > (In reply to rguenther@suse.de from comment #28)
> > > On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote:
> > 
> > > > Should I raise a new bug for this, as both this and 53068 are CLOSED?
> > > 
> > > I think this has been discussed in some other dup already and
> > > the Fortran FE folks disagreed (it was never "legal", not even in F77).
> > > 
> > > I also don't see how it can be a FE only fix.  Possibly we can
> > > implemnet a middle-end switch that tells us that the size of commons
> > > is not to be trusted.  The FE could then set that flag with -std=legacy.
> > > 
> > > You can, after all, "simulate" the very same failure with C.
> > 
> > Isn't there already a special exception for C (array of size 1 at end of
> > structure)?
> 
> Yes, the exception is for flexible array members and what people commonly use
> as flexible array member replacement (basically [0] sized arrays and all other
> arrays at the end of structures/unions, unless followed by some other field in
> outer structure or by another array member.
> But, all those exceptions are for the case how you can legally use flexible
> array members, i.e. heap allocated objects (or mmap etc.), so pretty much where
> the base is a pointer dereference.  If the base is a symbol, the only supported
> case is the GNU extension of initializing flexible array members.
> Otherwise, if you have size of some decl 32 bytes, trying to access 32th and
> following byte is considered undefined.
> 
> And what Richi suggests, some new switch which would allow treating DECL_COMMON
> bases more conservatively, expecting that if you have a flexible array member
> or something like that at the end of a DECL_COMMON decl that in (invalid)
> program it might be unified with a larger DECL_COMMON from other TU.

Yes.

Note there isn't really a special-casing of [1] sized arrays.  It just
happens to fall out of the case where maxsize ends up equal to size.

Thus a "fix" for the case where treating a[i] as a[0] is the issue
would be

Index: gcc/tree-dfa.c
===================================================================
--- gcc/tree-dfa.c      (revision 233172)
+++ gcc/tree-dfa.c      (working copy)
@@ -617,7 +617,11 @@ get_ref_base_and_extent (tree exp, HOST_
       if (maxsize == -1
          && DECL_SIZE (exp)
          && TREE_CODE (DECL_SIZE (exp)) == INTEGER_CST)
-       maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
+       {
+         maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
+         if (maxsize == size)
+           maxsize = -1;
+       }
     }
   else if (CONSTANT_CLASS_P (exp))
     {

but that wouldn't fix the aggressive-loop optimization issue as that is
_not_ looking at DECL_SIZE but at the array types domain.  Fortran
has a union/record type with one array element of size one.

A Fortran FE fix for that would be to make that array have unknown size
but still somehow force a size to the decl (the FE doesn't know there
is another unit that also defines the decl but with some larger size).

We have a similar issue with deriving alignment from DECL_COMMONs
where appearantly the ELF spec doesn't say anything here and thus
we give up and can't re-align global DECL_COMMONs for better
vectorization for example.