On 1/4/21 5:59 AM, Richard Biener via Gcc-patches wrote:
> On Sun, Dec 20, 2020 at 6:43 PM Martin Sebor <mse...@gmail.com> wrote:
>> On 12/19/20 12:48 AM, Richard Biener via Gcc-patches wrote:
>>> On December 19, 2020 1:55:02 AM GMT+01:00, Martin Sebor via Gcc-patches
>>> <gcc-patches@gcc.gnu.org> wrote:
>>>> To keep tree expressions stored by the front end in attribute
>>>> access for nontrivial VLA bounds from getting corrupted during
>>>> Gimplification and to avoid breaking the preconditions verified
>>>> by the LTO streamer that no such trees exist in the IL,
>>>> the attached patch replaces those bounds with a string
>>>> representation of those expressions (as STRING_CST). It also
>>>> tweaks the pretty-printer to improve the formatting of the VLA
>>>> bounds and avoid inserting spurious spaces in some cases.
>>>>
>>>> The strings are only used by the front end to verify that
>>>> redeclarations of the same function match in the form and bounds
>>>> of their VLA arguments, and they're not needed in the middle end.
>>>> I considered removing them just before the front end finishes but
>>>> I couldn't find an efficient way to do that. Is there some data
>>>> structure that stores all function declarations in a translation
>>>> unit? If there is, then traversing it and removing the attribute
>>>> arguments might also be an option, either in addition to this
>>>> change or in lieu of it.
>>> There is the free lang data pass in tree.c which walks all reachable tree
>>> nodes.
>> You said in response to Honza's suggestion in pr97172 to do that:
>>
>> The frontend needs to make sure no frontend specific tree codes
>> leak into GENERIC so GENERICization is the place where the FE
>> should clear those. FLD is too late and doing it there would
>> be a hack.
>>
>> Are you now saying you've had a change of heart and that doing it
>> there isn't a hack after all?
> Well, removing a FE specific attribute [when having non-constant arg] might
> be OK there. But note you asked for a "pass over all tree nodes" thing
> and I just pointed out free-lang-data.
>
> Doing the STRING_CST is certainly less fragile since the SSA names
> created at gimplification time could even be ggc_freed when no longer
> used in the IL.
Obviously we can't use SSA_NAMEs as they're specific to each function as
they get compiled. But what's not as clear to me is why we can't use a
SAVE_EXPR of the original expression that indicates the size of the
parameter.
Jeff
