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 rguent...@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.
