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
