This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]