Re: [Patch, fortran] PR117077 - ICE due to allocatable component in hidden type

Am 19.04.26 um 9:04 PM schrieb Harald Anlauf:
> Hi Paul!
> 
> Am 19.04.26 um 4:11 PM schrieb Paul Richard Thomas:
>> I initially found it difficult to imagine where one might use the
>> testcase. However, the elaborated version that appears in the attached
>> patch indicates some potential uses.
> 
> This use is so creative that NAG does not like it:
> 
> NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7203
> Error: pr117077.f90, line 48: Intrinsic TRANSFER of derived type 
> FOO_TYPE with allocatable component
> [NAG Fortran Compiler error termination, 1 error]

For clarification I think NAG is wrong here.  The standard has:

16.9.212 TRANSFER (SOURCE, MOLD [, SIZE])

Description. Transfer physical representation.

[...]

SOURCE shall be a scalar or array of any type.


Which is obviously the case.

I can imagine subtle implementation issues when the "any" type has
allocatable components, maybe even nested, which would require
deep-copy semantics.  I am not sure how this is to be interpreted
as a transfer of physical representation in that case, unless the
later assignment takes care of the reallocations needed.

NAG (+ one derivative I know of) seem to be the only compilers
to reject the testcase.

Harald

> Nevertheless, this is unrelated to the actual fix.
> 
>> The fix addresses the cause of the ICE directly:
>> in fold-const.cc
>>      default:
>>        if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig))
>> return fold_build1_loc (loc, NOP_EXPR, type, arg);
>>        gcc_unreachable ();
>>      }
>>
>> If this condition is not met, the rhs is converted to a
>> VIEW_CONVERT_EXPR. I have taken the conservative choice of not
>> replacing the fold_convert entirely, just to prevent potential
>> regressions before the gcc-16 release.
>>
>> Regtested of FC43/x86_64 - OK for mainline?
>>
>> Paul
> 
> Looks safe and good to me.
> 
> Thanks for the patch!
> 
> Harald
> 
> 
>