[Patch, fortran] PR115070 (and PR115348) - [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[Paul Richard Thomas]

Hi All,

I am not sure that I understand why this bug occurs. The regression was
introduced by my patch that had gfc_trans_class_init_assign return
NULL_TREE, when all the components of the default initializer are NULL.
Note that this only afflicts scalar dummy arguments.

With pr115070:
void my_sub (struct __class_my_mod_My_type_t & restrict obs)
  c_char fpstate.5[33];    // This disappears, when NULL is returned.
  try
    {
      _gfortran_ieee_procedure_entry ((void *) &fpstate.5);

With pr115348:
void myroutine (struct __class_mymodule_Mytype_t & restrict self)
{
  static logical(kind=4) is_recursive.0 = 0;  // This disappears when NULL
is returned
  try
    {
      if (is_recursive.0)

The fix is equally magical in that finishing build_empty_stmt seems to
provide the backend with everything that it needs to retain these
declarations. See the attached patch. If somebody can explain what causes
the problem and why the patch fixes it, I would be very pleased. As far as
I can tell, the tail end of trans_code should have been sufficient to
handle the return of NULL_TREE.

Anyway, work it does and regtests OK. OK for mainline and backporting?

Regards

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240715/2aec864d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change.Logs
Type: application/octet-stream
Size: 496 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240715/2aec864d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: submit.diff
Type: text/x-patch
Size: 3967 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240715/2aec864d/attachment.bin>