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?
