[Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement

[Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement

[bardeau at iram dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

            Bug ID: 115070
           Summary: ICE using IEEE_ARITHMETIC in a derived type method
                    with intent(out) statement
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bardeau at iram dot fr
  Target Milestone: ---

Hi,

gfortran 14.0.1 raises an ICE in the following context:

~> uname -a
Linux bardeau-lap 6.8.8-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 27
17:53:31 UTC 2024 x86_64 GNU/Linux

~> cat /etc/redhat-release 
Fedora release 40 (Forty)

~> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-14.0.1-20240411/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240411 (Red Hat 14.0.1-0) (GCC)

~> cat bug-gfortran.f90
module my_mod
  type my_type
    integer :: a
  end type my_type
contains
  subroutine my_sub(obs)
    use ieee_arithmetic
    class(my_type), intent(out) :: obs
  end subroutine my_sub
end module my_mod

~> gfortran -c bug-gfortran.f90 
bug-gfortran.f90:10:17:

   10 | end module my_mod
      |                 ^
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3307
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <http://bugzilla.redhat.com/bugzilla> for instructions.

It seems that the combination of "use ieee_arithmetic" and the "intent(out)"
statement is important (for example using intent(inout) fixes the ICE). I let
you rephrase the summary to a better description.

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |12.3.1
     Ever confirmed|0                           |1
   Target Milestone|---                         |13.3
           Priority|P3                          |P4
   Last reconfirmed|                            |2024-05-13
      Known to fail|                            |13.2.1, 14.1.0, 15.0
            Summary|ICE using IEEE_ARITHMETIC   |[13/14/15 Regression] ICE
                   |in a derived type method    |using IEEE_ARITHMETIC in a
                   |with intent(out) statement  |derived type method with
                   |                            |class, intent(out)
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed as a regression.  12-branch works here, current 13-branch fails.

Replacing class by type also avoids the ICE.

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

--- Comment #2 from anlauf at gcc dot gnu.org ---
Replacing the scalar argument 'obs' by something with rank > 0 avoids the ICE,
but then assumed-rank is not accepted with intent(out).  Another bug...

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gmail dot com,
                   |                            |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to anlauf from comment #2)
> Replacing the scalar argument 'obs' by something with rank > 0 avoids the
> ICE,
> but then assumed-rank is not accepted with intent(out).  Another bug...

The tree output with 12-branch is:
__attribute__((fn spec (". r w ")))
void __copy_my_mod_My_type (struct my_type & restrict src, struct my_type &
restrict dst)
{
  *dst = *src;
}


__attribute__((fn spec (". w ")))
void my_sub (struct __class_my_mod_My_type_t & restrict obs)
{
  c_char fpstate.0[33];

  try
    {
      _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
      if (obs->_vptr->_final != 0B)
        {
          {
            struct array00_my_type desc.1;

            desc.1.dtype = {.elem_len=4, .rank=0, .type=5};
            desc.1.data = (void * restrict) obs->_data;
            desc.1.span = (integer(kind=8)) desc.1.dtype.elem_len;
            obs->_vptr->_final (&desc.1, obs->_vptr->_size, 0);
          }
        }
      (void) __builtin_memcpy ((void *) obs->_data, (void *)
obs->_vptr->_def_init, (unsigned long) obs->_vptr->_size);

    }
  finally
    {
      _gfortran_ieee_procedure_exit ((void *) &fpstate.0);
    }
}

13- through 15-branches lack the default copy of the default initializer. This
disappeared with the fix for pr112407 and is required by the standard if the
derived type has no default initializer. This suggests a workaround, which
indeed "works":
  type my_type
    integer :: a = 0
  end type my_type

I cannot see anything in the ieee procedures that would cause this but then I
know zip-all about ieee.

Putting Francois-Xavier in copy in the hope that he can shed some light.

Cheers

Paul

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[bardeau at iram dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

--- Comment #4 from Sebastien Bardeau <bardeau at iram dot fr> ---
Thanks for the hints. It seems to me that an intent(out) class without
component initialization values is probably out of the standard (unpredictable
results). So on my side the work-around I choose is to provide an
initialization value.

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu.org

--- Comment #5 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
The only thing IEEE_ARITHMETIC does here is call _gfortran_ieee_procedure_entry
/ _gfortran_ieee_procedure_exit to save and restore the floating-point state.

The middle-end code that errors out is this:

  /* ??? If this is a local variable, and it has not been seen in any
     outer BIND_EXPR, then it's probably the result of a duplicate
     declaration, for which we've already issued an error.  It would
     be really nice if the front end wouldn't leak these at all.
     Currently the only known culprit is C++ destructors, as seen
     in g++.old-deja/g++.jason/binding.C.
     Another possible culpit are size expressions for variably modified
     types which are lost in the FE or not gimplified correctly.  */
  if (VAR_P (decl)
      && !DECL_SEEN_IN_BIND_EXPR_P (decl)
      && !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
      && decl_function_context (decl) == current_function_decl)
    {
      gcc_assert (seen_error ());
      return GS_ERROR;
    }


I don't have a debug build available right now, so I don't know which variable
is causing the issue or why. But it seems like a very weird interplay between
IEEE and DT (which are normally completely orthogonal), so maybe we're just
catching it "by chance" and the bug is preexisting (but silent).

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

--- Comment #6 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
So the var_decl in question is fpstate.0:

 <var_decl 0x1034e1200 fpstate.0
    type <array_type 0x1036c4b28
        type <integer_type 0x1035003f0 c_char public unsigned QI
            size <integer_cst 0x1034bce70 constant 8>
            unit-size <integer_cst 0x1034bce88 constant 1>
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1035003f0 precision:8 min <integer_cst 0x1034bced0 0> max <integer_cst
0x1034bceb8 255>
            pointer_to_this <pointer_type 0x103503bb8>>
        BLK
        size <integer_cst 0x103546988 constant 264>
        unit-size <integer_cst 0x103546aa8 constant 33>
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4b28
        domain <integer_type 0x1036c4a80 type <integer_type 0x1035007e0>
            DI
            size <integer_cst 0x1034bcd80 constant 64>
            unit-size <integer_cst 0x1034bcd98 constant 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4a80 precision:64 min <integer_cst 0x1034bd050 0> max <integer_cst
0x103546a60 32>>
        pointer_to_this <pointer_type 0x1036c4bd0>>
    addressable used ignored BLK s.f90:10:17 size <integer_cst 0x103546988 264>
unit-size <integer_cst 0x103546aa8 33>
    align:8 warn_if_not_align:0 context <function_decl 0x1036c8100 my_sub>>

And if I look at the tree dump, it seems the variable is indeed not created
correctly:

__attribute__((fn spec (". w ")))
void my_sub (struct __class_my_mod_My_type_t & restrict obs)
{
  try
    {
      _gfortran_ieee_procedure_entry ((void *) &fpstate.0);

see the missing declaration for fpstate.0. But it is created by
gfc_create_var(), like so many other local variables in the front-end, so I
have no idea why it's disappearing.

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #6)
> So the var_decl in question is fpstate.0:
> 
>  <var_decl 0x1034e1200 fpstate.0
>     type <array_type 0x1036c4b28
>         type <integer_type 0x1035003f0 c_char public unsigned QI
>             size <integer_cst 0x1034bce70 constant 8>
>             unit-size <integer_cst 0x1034bce88 constant 1>
>             align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x1035003f0 precision:8 min <integer_cst 0x1034bced0 0> max <integer_cst
> 0x1034bceb8 255>
>             pointer_to_this <pointer_type 0x103503bb8>>
>         BLK
>         size <integer_cst 0x103546988 constant 264>
>         unit-size <integer_cst 0x103546aa8 constant 33>
>         align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x1036c4b28
>         domain <integer_type 0x1036c4a80 type <integer_type 0x1035007e0>
>             DI
>             size <integer_cst 0x1034bcd80 constant 64>
>             unit-size <integer_cst 0x1034bcd98 constant 8>
>             align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x1036c4a80 precision:64 min <integer_cst 0x1034bd050 0> max
> <integer_cst 0x103546a60 32>>
>         pointer_to_this <pointer_type 0x1036c4bd0>>
>     addressable used ignored BLK s.f90:10:17 size <integer_cst 0x103546988
> 264> unit-size <integer_cst 0x103546aa8 33>
>     align:8 warn_if_not_align:0 context <function_decl 0x1036c8100 my_sub>>
> 
> And if I look at the tree dump, it seems the variable is indeed not created
> correctly:
> 
> __attribute__((fn spec (". w ")))
> void my_sub (struct __class_my_mod_My_type_t & restrict obs)
> {
>   try
>     {
>       _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
> 
> see the missing declaration for fpstate.0. But it is created by
> gfc_create_var(), like so many other local variables in the front-end, so I
> have no idea why it's disappearing.

Thanks for both the comments, Francois-Xavier. I will look to see if, somehow,
the way in which the finalization is stacked on the function tree is somehow
overwriting the ieee entry call and or the decl of fpstate.0.

Paul

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 58263
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58263&action=edit
Patch that fixes this PR

Somehow, when a null is returned from the call to gfc_trans_class_init_assign,
the messing around with blocks at the end of gfc_generate_function_code loses
the declaration. I tried giving the ieee calls their own block and merging it
to the top of 'body'. That fixed this PR but broke a number of ieee tests in
the testsuite.

This fix is not very elegant but it does work and even regtests OK.

I am continuing to work on it before submitting this patch.

Paul