[PATCH v3] clear VLA bounds in attribute access (PR 97172)

[Martin Sebor]

On 1/28/21 2:22 AM, Jakub Jelinek wrote:
> On Thu, Jan 28, 2021 at 09:31:46AM +0100, Richard Biener via Gcc-patches wrote:
>> +  if (TREE_CODE (bound) == PLUS_EXPR
>> +      && integer_all_onesp (TREE_OPERAND (bound, 1)))
>> +    {
>> +      bound = TREE_OPERAND (bound, 0);
>> +      if (TREE_CODE (bound) == NOP_EXPR)
>> +       bound = TREE_OPERAND (bound, 0);
>> +    }
>>
>> so it either does or does not strip a -1 but has no indication on
>> whether it did that?  That looks fragile and broken.
> 
> Yeah.  Plus again STRIP_NOPs in there should be used.  But certainly it
> needs to remember whether there was + -1 or not and compensate for it.
> 
>> The free-lang-data parts are OK.
> 
> But is fld the right spot to do it?
> If it is only the FE that emits the warnings, shouldn't it be stripped
> already before gimplification so that it isn't actually corrupted?
> 
> I mean in c_parse_final_cleanups or c_common_parse_file depending on
> if it is just C or C++ too?

I've been asking for a good place to do it since December and
free_lang_data was the only suggestion.  I even mentioned it
to you this Tuesday.  c_parse_final_cleanups looks like a better
place but I don't understand why you've waited until now to point
me to it.

> 
> Plus, if the expressions in the attribute don't contain SAVE_EXPRs, why
> there isn't unshare_expr called on them (and if they do, I don't see how
> it would be guaranteed, can't one e.g. do
> int bar (void);
> void foo (int n, int a[n + 1][bar () + 2], int b[sizeof (a[0]) + 32])
> {
> }
> ?) the unsharing variant I've pasted into the PR.

I'm not sure what you're asking here or if you're just repeating
the same question we went over in November when I posted the first
patch to unshare the expressions.  In that thread, after I explained
that the expressions in the attribute aren't evaluated, you ultimately
agreed it wasn't necessary:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559953.html

The front end wraps each VLA bound that needs to be evaluated in
a SAVE_EXPR (and, as Joseph points out in the same thread, if
there are more of them, they're wrapped in a COMPOUND_EXPR).  But
the attribute doesn't use these SAVE_EXPRs -- instead, it uses
the expressions before they're wrapped.  This wasn't a choice I
made deliberately.  I just didn't know about the COMPOUND_EXPR
wrapped bounds.

Martin