Works better with patch attached...

Am 13.12.21 um 21:25 schrieb Harald Anlauf via Gcc-patches:
> Hi Mikael,
> 
> Am 09.12.21 um 21:37 schrieb Mikael Morin:
>> Hello,
>>
>> On 09/12/2021 21:05, Harald Anlauf via Fortran wrote:
>>> Dear all,
>>>
>>> I had thought that we had fixed this in the past (see PR31001),
>>> but it did fail for me with all gcc versions I have tried (7-12)
>>> for a slightly more elaborate case as in the old testcase.
>>>
>>> The loop in pack_internal did try to access the first element of
>>> the array argument to PACK even if one (or more) extents were zero.
>>> This is not good.
>>>
>>> Solution: check the extents and return early.  (We already do a
>>> related check for the vector argument if present).
>>
>> If there is a vector argument, aren’t we supposed to copy it to the
>> result ?
>> There is something else to pay attention for, the early return should
>> come at least after the return array bounds have been set.  In the
>> testcase an array with the correct bounds has been allocated beforehand
>> to hold the return value, but it’s not always the case.
> 
> you are absolutely right, I had gotten that wrong.
> 
>> For what it’s worth, the non-generic variant in pack.m4 (or in
>> pack_{i,f,c}{1,2,4,8,10,16}.c) has a zero extent check and it clears the
>> source ptr in that case, which makes it setup the return array and then
>> jump to the vector copy at the end of the function.
>>
> 
> The code is so similar (for good reason) that it makes sense to keep
> it synchronous.  I added code for 'zero_sized' array with the minor
> difference that I made it boolean instead of integer.
> 
> I also extended the testcase so that it exercises PACK/pack_internal
> a little, for argument 'vector' present as well as not.  (There are
> existing tests for intrinsic types, but not for the issue at hand).
> 
> Regtested again, and checked the testcase (against other compilers
> and also with valgrind).
> 
> OK now?
> 
> Thanks,
> Harald
>