On 09/04/18 16:30, Jeff Law wrote:
> On 09/03/2018 06:35 AM, Bernd Edlinger wrote:
> [ Big snip, dropping lots of context ]
> 
>>>>>
>>>>
>>>> No I don't think so, because at that time BRACE_ENCLOSED_INITIALIZER_P
>>>> property does no longer work, as I explained in the previous mail.
>>>>
>>>> And cp_complete_array_type does use that property:
>>> [ ... ]
>>> Jason's the expert here.    I'll defer to his expertise.  It just seemed
>>> a bit odd to me that we have a routine to "complete" an array that does
>>> any special C++ handling (cp_complete_array_type) and we're not using it.
>>>
>>
>> Agreed, I have posted an update which uses cp_complete_array_type, since
>> Jason raised the same point.
>>
>> But since C++ does not need the recursion here, things are a lot more easy.
>> The patch still completes the array type _after_ the FE is completely done with the
>> parsing, since I want to avoid to destroy the information too early, since the FE is looking
>> at the TYPE_DOMAIN==NULL at various places.
> FYI, I don't see a follow-up for this patch?  Did I miss it?  Or is it
> under a different subject line?
> 
> jeff
> 

Yes, thanks for reminding me.
I had forgotten to post the updated patch.

So here is my latest version of the flexible array patch.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu (together with the other STRING_CST-v2 patches).
Is it OK for trunk?


Thanks
Bernd.