https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #34 from rguenther at suse dot de <rguenther at suse dot de> --- On February 8, 2016 4:49:20 PM GMT+01:00, "alalaw01 at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 > >alalaw01 at gcc dot gnu.org changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Status|RESOLVED |REOPENED > Resolution|FIXED |--- > >--- Comment #33 from alalaw01 at gcc dot gnu.org --- >(In reply to rguent...@suse.de from comment #31) >> >> 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)) >> { > >So is there a case where we want this for C ? > >If I declare a struct with a VLA, and access it through a pointer - GCC >recognizes the VLA idiom and keeps the accesses. If I access it from a >decl, >yes we optimize away the out-of-bounds accesses (in FRE, long before we >reach >the tree-ssa-scopedtables changes). So OK, if I access it from a extern >or >__attribute__((weak) decl, which I then get the linker to replace with >a bigger >decl, then I get "wrong" code (it ignores the extra elements in the >bigger >decl) - but I'd say that was invalid code. > >So if this is Fortran-only, we probably have to hook off --std=legacy, >right? Yes.
