[Bug lto/105012] New: [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking

[Bug lto/105012] New: [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking

[tnfchris at gcc dot gnu.org]

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

            Bug ID: 105012
           Summary: [12 Regression] wrf from SPECCPU2017 ICEs during LTO
                    linking
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tnfchris at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64-*

wrf when linking with -mcpu=native -Ofast -fomit-frame-pointer -flto=auto
--param ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=80 (have not reduced
flags yet) fails during final link with:

during GIMPLE pass: ifcvt
module_cam_mp_ndrop.fppized.f90: In function 'dropmixnuc':
module_cam_mp_ndrop.fppized.f90:33:27: internal compiler error: Segmentation
fault
   33 |       subroutine dropmixnuc(lchnk, ncol, ncldwtr,tendnd, temp,omega,  &
      |                           ^
0xb9bee3 crash_signal
        /data/tamar/ci/work/5c94c4ced6ebfcd0/gcc/toplev.cc:322
0xc93978 first_imm_use_stmt
        /data/tamar/ci/work/5c94c4ced6ebfcd0/gcc/ssa-iterators.h:932
0xc93978 dse_classify_store(ao_ref*, gimple*, bool, simple_bitmap_def*, bool*,
tree_node*)
        /data/tamar/ci/work/5c94c4ced6ebfcd0/gcc/tree-ssa-dse.cc:954
0xbf9263 ifcvt_local_dce
        /data/tamar/ci/work/5c94c4ced6ebfcd0/gcc/tree-if-conv.cc:3154
0xbfe1b7 tree_if_conversion(loop*, vec<gimple*, va_heap, vl_ptr>*)
        /data/tamar/ci/work/5c94c4ced6ebfcd0/gcc/tree-if-conv.cc:3383
0xc000af execute
        /data/tamar/ci/work/5c94c4ced6ebfcd0/gcc/tree-if-conv.cc:3461
0xc000af execute
        /data/tamar/ci/work/5c94c4ced6ebfcd0/gcc/tree-if-conv.cc:3449
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[1]: *** [/opt/buildAgent/temp/buildTmp/ccGjHi3g.ltrans8.ltrans.o] Error 1

This has started somewhere between g:79e210f0c8e1fad875333e93b5ae2fe9b4879b7a
and g:9fc8f278ebebc57537dc0cb9d33e36d932be0bc3

Sorry for the lack of a small reproducer, still need to learn how to reduce LTO
cases properly..

Note that this range does contain a fix for the threader failure for wrf in
PR102943 but not sure if related.

[Bug lto/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-03-22
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
I can reproduce that on x86_64-linux-gnu and I'm trying to reduce that.

> Sorry for the lack of a small reproducer, still need to learn how to reduce
> LTO cases properly..

You can do that in the following steps:

1) reduce the number of objects needed on the linker command line - you can put
them to FILES.txt and then use cvise-delta to find a minimal set of files
needed; sometimes one needs to use -shared -fPIC in order to prevent missing
symbols linker errors
2) create pre-processed files for the culprit objects and then run gcc *.i
-flto ... and bisect all files at once with cvise

[Bug lto/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
possibly a latent issue - it looks like not updated SSA form (stmt DCEd w/o
propagating out the VDEF?).  I'll see whether it reproduces for me.

[Bug lto/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |12.0

[Bug lto/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 52661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52661&action=edit
ltrans object file

I have a small LTRANS reproducer:

$ ./lto1 -fltrans /home/marxin/Programming/testcases/wrf_r.ltrans.o
Reading object files: /home/marxin/Programming/testcases/wrf_r.ltrans.o {GC
2365k}  {heap 1168k}
Reading the symbol table:
Merging declarations: {GC 2414k}  {heap 1168k}
Reading summaries: {GC 2414k}  {heap 1168k} {GC 2414k}  {heap 1168k} {GC 2414k}
 {heap 1168k} {GC 2414k}  {heap 1168k} <cp> {GC 2422k}  {heap 1168k} {GC 2422k}
 {heap 1168k} {GC 2422k}  {heap 1168k} {GC 2422k}  {heap 1168k} {GC 2422k} 
{heap 1168k} <modref> {GC 2426k}  {heap 1168k} {GC 2426k}  {heap 1168k}
<static-var> {GC 2426k}  {heap 1168k} {GC 2426k}  {heap 1168k} {GC 2426k} 
{heap 1168k} {GC 2426k}  in:q.4.lto_priv.0 in:p.5.lto_priv.0 in:d.6.lto_priv.0
in:c.7.lto_priv.0 in:b.8.lto_priv.0 in:a.9.lto_priv.0
in:supersat.2.lto_priv.0Reading function bodies:
Performing interprocedural optimizations
Assembling functions:
 <simdclone> {heap 1168k} dropmixnuc.constprop in:__ndrop_MOD_dropmixnuc
in:__error_function_MOD_calerf_r8 in:__error_function_MOD_derf
in:__module_cam_support_MOD_endrun in:wrf_message_ in:wrf_error_fatal_
in:__module_cam_support_MOD_endrun.part.0 in:__ndrop_MOD_loadaer
in:__ndrop_MOD_ccncalc in:__module_cam_support_MOD_outfld {GC madv_dontneed
264k} {GC 6209k -> 3650k} {GC madv_dontneed 652k} {GC 5337k -> 3807k}during
GIMPLE pass: ifcvt

../../../../home/marxin/Programming/cpu2017/benchspec/CPU/521.wrf_r/build/build_peak_gcc-m64.0001/module_cam_mp_ndrop.fppized.f90:
In function ‘dropmixnuc.constprop’:
../../../../home/marxin/Programming/cpu2017/benchspec/CPU/521.wrf_r/build/build_peak_gcc-m64.0001/module_cam_mp_ndrop.fppized.f90:33:27:
internal compiler error: Segmentation fault
0x135c4fb crash_signal
        /home/marxin/Programming/gcc/gcc/toplev.cc:322
0x7ffff78b93cf ???
       
/usr/src/debug/glibc-2.35-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xb02a60 tree_check(tree_node*, char const*, int, char const*, tree_code)
        /home/marxin/Programming/gcc/gcc/tree.h:3450
0x15369e3 first_imm_use_stmt
        /home/marxin/Programming/gcc/gcc/ssa-iterators.h:931
0x15390e6 dse_classify_store(ao_ref*, gimple*, bool, simple_bitmap_def*, bool*,
tree_node*)
        /home/marxin/Programming/gcc/gcc/tree-ssa-dse.cc:954
0x141afe1 ifcvt_local_dce
        /home/marxin/Programming/gcc/gcc/tree-if-conv.cc:3154
0x141b89f tree_if_conversion(loop*, vec<gimple*, va_heap, vl_ptr>*)
        /home/marxin/Programming/gcc/gcc/tree-if-conv.cc:3383
0x141bb02 execute
        /home/marxin/Programming/gcc/gcc/tree-if-conv.cc:3461
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

Richi: Can you please debug this?

[Bug lto/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so we have

(gdb) p debug_gimple_stmt (stmt)
derf(address-taken) ={v} {CLOBBER};

lacking virtual operands and the LHS is

 <function_decl 0x7ffff6346700 derf
    type <function_type 0x7ffff634a348
        type <real_type 0x7ffff6537348 double DF
...

that stmt is input this way from LTO bytecode.  The following should catch
who's building this.

diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index e321d929fd0..fa92a505771 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -4512,7 +4512,8 @@ verify_gimple_assign_single (gassign *stmt)
     }

   if (gimple_clobber_p (stmt)
-      && !(DECL_P (lhs) || TREE_CODE (lhs) == MEM_REF))
+      && !((DECL_P (lhs) && TREE_CODE (lhs) != FUNCTION_DECL)
+          || TREE_CODE (lhs) == MEM_REF))
     {
       error ("%qs LHS in clobber statement",
             get_tree_code_name (TREE_CODE (lhs)));

[Bug lto/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12 Regression] wrf from    |[12 Regression] wrf from
                   |SPECCPU2017 ICEs during LTO |SPECCPU2017 ICEs during LTO
                   |linking                     |linking since
                   |                            |r12-7692-g8db155ddf8cec9

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-7692-g8db155ddf8cec9.

[Bug lto/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> OK, so we have
> 
> (gdb) p debug_gimple_stmt (stmt)
> derf(address-taken) ={v} {CLOBBER};
> 
> lacking virtual operands and the LHS is
> 
>  <function_decl 0x7ffff6346700 derf
>     type <function_type 0x7ffff634a348
>         type <real_type 0x7ffff6537348 double DF
> ...
> 
> that stmt is input this way from LTO bytecode.  The following should catch
> who's building this.
> 
> diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
> index e321d929fd0..fa92a505771 100644
> --- a/gcc/tree-cfg.cc
> +++ b/gcc/tree-cfg.cc
> @@ -4512,7 +4512,8 @@ verify_gimple_assign_single (gassign *stmt)
>      }
>  
>    if (gimple_clobber_p (stmt)
> -      && !(DECL_P (lhs) || TREE_CODE (lhs) == MEM_REF))
> +      && !((DECL_P (lhs) && TREE_CODE (lhs) != FUNCTION_DECL)
> +          || TREE_CODE (lhs) == MEM_REF))
>      {
>        error ("%qs LHS in clobber statement",
>              get_tree_code_name (TREE_CODE (lhs)));

Let me find the builder of this.

[Bug fortran/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|lto                         |fortran

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, it's CCP, but likely transforming

MEM[p_1] = CLOBBER;

into

derf = CLOBBER;

by means of propagating a p_1 = &derf;

Such clobber is useless but we possibly have to deal with it.  Note I wonder
why
the operand scanner doesn't ICE here ...

Indeed we have

;; Function erfcx_r4 (__error_function_MOD_erfcx_r4, funcdef_no=0,
decl_uid=4215, cgraph_uid=1, symbol_order=0)

__attribute__((fn spec (". r ")))
real(kind=4) erfcx_r4 (real(kind=4) & restrict x)
{
  real(kind=4) __result_erfcx_r4(address-taken);
  static integer(kind=4) jint(address-taken) = 2;
  real(kind=4) (*<T66a>) (real(kind=4) & restrict) erfcx_r4.0_1;
  real(kind=4) _6;

  <bb 2> :
  erfcx_r4.0_1 = erfcx_r4;
  *erfcx_r4.0_1 ={v} {CLOBBER};
  calerf_r4 (x_4(D), &__result_erfcx_r4(address-taken), &jint(address-taken));
  _6 = __result_erfcx_r4(address-taken);

and .original already has

__attribute__((fn spec (". r ")))
real(kind=4) erfcx_r4 (real(kind=4) & restrict x)
{
  static integer(kind=4) jint(address-taken) = 2;
  real(kind=4) __result_erfcx_r4(address-taken);

  erfcx_r4 = {CLOBBER};
  calerf_r4 ((real(kind=4) *) x, &__result_erfcx_r4(address-taken),
&jint(address-taken));
  return __result_erfcx_r4(address-taken);
}

[Bug fortran/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
Yes:

$ cat module_cam_error_function.fppized.f90
module error_function
integer, parameter :: r8 = selected_real_kind(12) ! 8 byte real
contains
SUBROUTINE CALERF_r8(ARG, RESULT, JINT)
   integer, parameter :: rk = r8
   real(rk), intent(in)  :: arg
   real(rk), intent(out) :: result
   IF (Y .LE. THRESH) THEN
   END IF
end SUBROUTINE CALERF_r8
FUNCTION DERFC(X)
   integer, parameter :: rk = r8 ! 8 byte real
   real(rk), intent(in) :: X
   real(rk) :: DERFC
   CALL CALERF_r8(X, DERFC, JINT)
END FUNCTION DERFC
end module error_function

$ gcc module_cam_error_function.fppized.f90 -c -O
module_cam_error_function.fppized.f90:10:24:

   10 | end SUBROUTINE CALERF_r8
      |                        ^
Error: 'function_decl' LHS in clobber statement
derfc
derfc ={v} {CLOBBER};
during GIMPLE pass: ccp
module_cam_error_function.fppized.f90:10:24: internal compiler error:
verify_gimple failed
0x10279c5 verify_gimple_in_cfg(function*, bool)
        /home/marxin/Programming/gcc/gcc/tree-cfg.cc:5562
0xeee32e execute_function_todo
        /home/marxin/Programming/gcc/gcc/passes.cc:2085
0xeee94b execute_todo
        /home/marxin/Programming/gcc/gcc/passes.cc:2139
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug fortran/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Built by

void
gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr, bool add_clobber)
{
...
      else if (add_clobber && expr->ref == NULL)
        {
          tree clobber;
          tree var; 
          /* FIXME: This fails if var is passed by reference, see PR
             41453.  */
          var = expr->symtree->n.sym->backend_decl;
          clobber = build_clobber (TREE_TYPE (var));
          gfc_add_modify (&se->pre, var, clobber);
        }

and the fortran code passes down a function as parameter:

FUNCTION ERFCX_R4(X)
!--------------------------------------------------------------------
!
! This subprogram computes approximate values for exp(x*x) * erfc(x).
!   (see comments heading CALERF).
!
!   Author/date: W. J. Cody, March 30, 1987
!
!--------------------------------------------------------------------
   integer, parameter :: rk = r4 ! 8 byte real

   ! argument
   real(rk), intent(in) :: X

   ! return value
   real(rk) :: ERFCX_R4

   ! local variables
   INTEGER :: JINT = 2
   !------------------------------------------------------------------

   CALL CALERF_r4(X, ERFCX_R4, JINT)
END FUNCTION ERFCX_R4

[Bug fortran/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
likely triggered by the INTENT(out), it looks like gfortran fails to properly
name-lookup a variable of the same name as the function?  The intent is likely
to have the return value assigned by CALERF_r8.  So it also looks like gfortran
miscompiles such testcase.

The following sketches a miscompiled testcase (but my fortran fu is too weak to
make it compile)

PROCEDURE Y (Z)
      real(8), intent(out) :: Z
      Z = 1.
END PROCEDURE Y
FUNCTION X
      real(8) :: X
      CALL Y (X)
END FUNCTION X
PROGRAM TEST
    real(8) :: Z
    Z = X();
    if (Z.ne.1.) STOP 1
END

[Bug fortran/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #10)
> likely triggered by the INTENT(out), it looks like gfortran fails to properly
> name-lookup a variable of the same name as the function?  The intent is
> likely
> to have the return value assigned by CALERF_r8.  So it also looks like
> gfortran miscompiles such testcase.
> 
> The following sketches a miscompiled testcase (but my fortran fu is too weak
> to make it compile)
> 
> PROCEDURE Y (Z)
>       real(8), intent(out) :: Z
>       Z = 1.
> END PROCEDURE Y
> FUNCTION X
>       real(8) :: X
>       CALL Y (X)
> END FUNCTION X
> PROGRAM TEST
>     real(8) :: Z
>     Z = X();
>     if (Z.ne.1.) STOP 1
> END

SUBROUTINE Y (Z)
      real(8), intent(out) :: Z
      Z = 1.
END SUBROUTINE Y
FUNCTION X()
      real(8) :: X
      CALL Y (X)
END FUNCTION X
PROGRAM TEST
    real(8) :: Z
    Z = X();
    if (Z.ne.1.) STOP 1
END PROGRAM

but still

t.f90:11:9:

   11 |     Z = X();
      |         1
Error: Return type mismatch of function 'x' at (1) (REAL(4)/REAL(8))

[Bug fortran/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
  erfcx_r4 = {CLOBBER};
  calerf_r4 ((real(kind=4) *) x, &__result_erfcx_r4(address-taken),
&jint(address-taken));

hints at that gfortran somehow knows that it should pass the result but it
still somehow clobbers the function itself!?  So maybe not wrong-code but
missed-optimization.

The operand scanner has

    case FUNCTION_DECL:
    case LABEL_DECL:
    case CASE_LABEL_EXPR:
      /* Expressions that make no memory references.  */
      return;

where it does not assign virtual operands to FUNCTION_DECLs.  It's probably
good to make DSE more forgiving here.  I'm testing such workaround.

[Bug fortran/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:08f263e703c4100fa7b9f08cb26cee6c0bd75e4a

commit r12-7764-g08f263e703c4100fa7b9f08cb26cee6c0bd75e4a
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Mar 22 12:28:30 2022 +0100

    tree-optimization/105012 - fix ICE from local DSE of if-conversion

    The following guards dse_classify_store with the same condition as
    the DSE pass does - availability of a virtual definition.  For
    the PR we run into the fortran frontend generating a clobber for
    a FUNCTION_DECL lhs which is ignored by the operand scanner and has
    no virtual operands assigned.  Apart from fixing the frontend the
    following fixes the ICE by adjusting if-conversion.

    2022-03-22  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/105012
            * tree-if-conv.cc (ifcvt_local_dce): Only call
            dse_classify_store when we have a VDEF.

[Bug fortran/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code,          |missed-optimization
                   |wrong-code                  |
           Priority|P1                          |P4

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
I installed a workaround for the ICE, the fortran issue remains (not sure if it
is a regression), and it looks like it's a missed optimization only - a
"missing" CLOBBER for intent-out arguments.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.0                        |12.2

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 12.1 is being released, retargeting bugs to GCC 12.2.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[anlauf at gcc dot gnu.org]

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > likely triggered by the INTENT(out), it looks like gfortran fails to properly
> > name-lookup a variable of the same name as the function?  The intent is
> > likely
> > to have the return value assigned by CALERF_r8.  So it also looks like
> > gfortran miscompiles such testcase.
[...]
> SUBROUTINE Y (Z)
>       real(8), intent(out) :: Z
>       Z = 1.
> END SUBROUTINE Y
> FUNCTION X()
>       real(8) :: X
>       CALL Y (X)
> END FUNCTION X
> PROGRAM TEST
>     real(8) :: Z
>     Z = X();
>     if (Z.ne.1.) STOP 1
> END PROGRAM
> 
> but still
> 
> t.f90:11:9:
> 
>    11 |     Z = X();
>       |         1
> Error: Return type mismatch of function 'x' at (1) (REAL(4)/REAL(8))

The error message is correct.  The main program is missing a decl that
X is real(8) not real(4).  E.g. adding

  real(8) :: X

resolves the type mismatch.

(Replacing 1. by 1._8 also eliminates some conversions in the dump.)

The dummy argument Z of Y is marked as intent(out):

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = y
  symtree: 'y'           || symbol: 'y'            
    type spec : (UNKNOWN 0)
    attributes: (PROCEDURE  SUBROUTINE)
    Formal arglist: z
  symtree: 'z'           || symbol: 'z'            
    type spec : (REAL 8)
    attributes: (VARIABLE  DUMMY(OUT))

A quick glance at trans-expr.cc::gfc_conv_procedure_call suggests that
the logic that determines whether to generate a clobber depends on the
properties of the formal argument being available.

6505                          bool add_clobber;
6506                          add_clobber = fsym && fsym->attr.intent ==
INTENT_OUT
6507                            && !fsym->attr.allocatable &&
!fsym->attr.pointer
6508                            && e->symtree && e->symtree->n.sym
6509                            && !e->symtree->n.sym->attr.dimension
6510                            && !e->symtree->n.sym->attr.pointer
6511                            && !e->symtree->n.sym->attr.allocatable
6512                            /* See PR 41453.  */
6513                            && !e->symtree->n.sym->attr.dummy
6514                            /* FIXME - PR 87395 and PR 41453  */
6515                            && e->symtree->n.sym->attr.save == SAVE_NONE
6516                            && !e->symtree->n.sym->attr.associate_var
6517                            && e->ts.type != BT_CHARACTER && e->ts.type !=
BT_DERIVED
6518                            && e->ts.type != BT_CLASS &&
!sym->attr.elemental;
6519
6520                          gfc_conv_expr_reference (&parmse, e,
add_clobber);
(gdb) p fsym
$7 = (gfc_symbol *) 0x0

Without an explicit interface, stone-age-style code is not supported here yet.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #18 from anlauf at gcc dot gnu.org ---
Tentative patch, regtests cleanly but otherwise untested:

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 850007fd2e1..0a1520e95ba 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6503,8 +6503,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
                  else
                    {
                      bool add_clobber;
-                     add_clobber = fsym && fsym->attr.intent == INTENT_OUT
-                       && !fsym->attr.allocatable && !fsym->attr.pointer
+                     gfc_symbol *dsym = fsym;
+                     gfc_dummy_arg *dummy;
+
+                     /* Use associated dummy as fallback for formal
+                        argument if there is no explicit interface.  */
+                     if (dsym == NULL
+                         && (dummy = arg->associated_dummy)
+                         && dummy->intrinsicness ==
GFC_NON_INTRINSIC_DUMMY_ARG
+                         && dummy->u.non_intrinsic->sym)
+                       dsym = dummy->u.non_intrinsic->sym;
+
+                     add_clobber = dsym && dsym->attr.intent == INTENT_OUT
+                       && !dsym->attr.allocatable && !dsym->attr.pointer
                        && e->symtree && e->symtree->n.sym
                        && !e->symtree->n.sym->attr.dimension
                        && !e->symtree->n.sym->attr.pointer

Does this fix the remaining issue?

What is the best way to write a testcase that checks that the clobber is
inserted properly?

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to anlauf from comment #18)
> Tentative patch, regtests cleanly but otherwise untested:
> 
> diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> index 850007fd2e1..0a1520e95ba 100644
> --- a/gcc/fortran/trans-expr.cc
> +++ b/gcc/fortran/trans-expr.cc
> @@ -6503,8 +6503,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
> sym,
>                   else
>                     {
>                       bool add_clobber;
> -                     add_clobber = fsym && fsym->attr.intent == INTENT_OUT
> -                       && !fsym->attr.allocatable && !fsym->attr.pointer
> +                     gfc_symbol *dsym = fsym;
> +                     gfc_dummy_arg *dummy;
> +
> +                     /* Use associated dummy as fallback for formal
> +                        argument if there is no explicit interface.  */
> +                     if (dsym == NULL
> +                         && (dummy = arg->associated_dummy)
> +                         && dummy->intrinsicness ==
> GFC_NON_INTRINSIC_DUMMY_ARG
> +                         && dummy->u.non_intrinsic->sym)
> +                       dsym = dummy->u.non_intrinsic->sym;
> +
> +                     add_clobber = dsym && dsym->attr.intent == INTENT_OUT
> +                       && !dsym->attr.allocatable && !dsym->attr.pointer
>                         && e->symtree && e->symtree->n.sym
>                         && !e->symtree->n.sym->attr.dimension
>                         && !e->symtree->n.sym->attr.pointer
> 
> Does this fix the remaining issue?
> 
> What is the best way to write a testcase that checks that the clobber is
> inserted properly?

For the testcase in comment#8 you could do

! { dg-do compile }
! { dg-options "-fdump-tree-original" }

module error_function
integer, parameter :: r8 = selected_real_kind(12) ! 8 byte real
contains
SUBROUTINE CALERF_r8(ARG, RESULT, JINT)
   integer, parameter :: rk = r8
   real(rk), intent(in)  :: arg
   real(rk), intent(out) :: result
   IF (Y .LE. THRESH) THEN
   END IF
end SUBROUTINE CALERF_r8
FUNCTION DERFC(X)
   integer, parameter :: rk = r8 ! 8 byte real
   real(rk), intent(in) :: X
   real(rk) :: DERFC
   CALL CALERF_r8(X, DERFC, JINT)
END FUNCTION DERFC
end module error_function

! { dg-final { scan-tree-dump-not "derfc = {CLOBBER};" } }

tough a more precise test would be to use scan-tree-dump-times "CLOBBER" 1
and scan-tree-dump "__result_derfc = {CLOBBER};".  With the bug we see

__attribute__((fn spec (". r ")))
real(kind=8) derfc (real(kind=8) & restrict x)
{
  integer(kind=4) jint;
  real(kind=8) __result_derfc;

  derfc = {CLOBBER};
  calerf_r8 ((real(kind=8) *) x, &__result_derfc, &jint);
  return __result_derfc;

and corrected there should be either

  __result_derfc = {CLOBBER};

instead or the clobber not emitted (for a missed optimization only).

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
With your patch I still see

__attribute__((fn spec (". r ")))
real(kind=8) derfc (real(kind=8) & restrict x)
{
  integer(kind=4) jint;
  real(kind=8) __result_derfc;

  derfc = {CLOBBER};
  calerf_r8 ((real(kind=8) *) x, &__result_derfc, &jint);
  return __result_derfc;


I think the patch wouldn't adjust what the clobber is added to but only
whether it is added, but it seems it fails to catch this case?  So maybe
the error is elsewhere.

Note with my testcase from comment#11 fixed as you suggest I don't see a
clobber
at all - I probably simplified too much and gfortran needs the wrapped module
to see the intent(out).

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #21 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #18)
> Tentative patch, regtests cleanly but otherwise untested:
> 
> diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> index 850007fd2e1..0a1520e95ba 100644
> --- a/gcc/fortran/trans-expr.cc
> +++ b/gcc/fortran/trans-expr.cc
> @@ -6503,8 +6503,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
> sym,
>                   else
>                     {
>                       bool add_clobber;
> -                     add_clobber = fsym && fsym->attr.intent == INTENT_OUT
> -                       && !fsym->attr.allocatable && !fsym->attr.pointer
> +                     gfc_symbol *dsym = fsym;
> +                     gfc_dummy_arg *dummy;
> +
> +                     /* Use associated dummy as fallback for formal
> +                        argument if there is no explicit interface.  */
> (...)

Note that if there is no explicit interface, I expect associated_dummy to be
NULL, and as a result dsym and fsym to always actually be the same thing.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[anlauf at gcc dot gnu.org]

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

--- Comment #22 from anlauf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #20)
> With your patch I still see
> 
> __attribute__((fn spec (". r ")))
> real(kind=8) derfc (real(kind=8) & restrict x)
> {
>   integer(kind=4) jint;
>   real(kind=8) __result_derfc;
> 
>   derfc = {CLOBBER};
>   calerf_r8 ((real(kind=8) *) x, &__result_derfc, &jint);
>   return __result_derfc;
> 
> 
> I think the patch wouldn't adjust what the clobber is added to but only
> whether it is added, but it seems it fails to catch this case?  So maybe
> the error is elsewhere.

It appears that there are two (only weakly dependent) issues at play here:

1) The patch in comment#18 addresses only the case when the procedures are
   outside of a module, so that the frontend does not see their interfaces.
   But since we nowadays have a more global view of all procedures in a file,
   we are in principle able to exploit things like attributes of the dummies.

2) For the handling of clobber for variables that are associated with
   INTENT(OUT) dummy arguments see also PR41453, which is still open due
   to some corner cases not yet addressed.  The present case, where the
   actual argument is the function result, shows an anomaly:
   The clobber is fine if the function has an explicit result clause,
   while we are confusing symbols (x vs. __result_x) when there is no
   result clause.

   See PR41453#c8 for details.

The remaining problem from PR41453#c8 is the following code in trans-expr.cc:

(gdb) l 9539,9548
9539          else if (add_clobber && expr->ref == NULL)
9540            {
9541              tree clobber;
9542              tree var;
9543              /* FIXME: This fails if var is passed by reference, see PR
9544                 41453.  */
9545              var = expr->symtree->n.sym->backend_decl;
9546              clobber = build_clobber (TREE_TYPE (var));
9547              gfc_add_modify (&se->pre, var, clobber);
9548            }

One needs to understand how to fix up 'var' here for the case at hand.

> Note with my testcase from comment#11 fixed as you suggest I don't see a
> clobber
> at all - I probably simplified too much and gfortran needs the wrapped module
> to see the intent(out).

I thought to have fixed that one...

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[anlauf at gcc dot gnu.org]

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

--- Comment #23 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #21)
> (In reply to anlauf from comment #18)
> > Tentative patch, regtests cleanly but otherwise untested:
> > 
> > diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> > index 850007fd2e1..0a1520e95ba 100644
> > --- a/gcc/fortran/trans-expr.cc
> > +++ b/gcc/fortran/trans-expr.cc
> > @@ -6503,8 +6503,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
> > sym,
> >                   else
> >                     {
> >                       bool add_clobber;
> > -                     add_clobber = fsym && fsym->attr.intent == INTENT_OUT
> > -                       && !fsym->attr.allocatable && !fsym->attr.pointer
> > +                     gfc_symbol *dsym = fsym;
> > +                     gfc_dummy_arg *dummy;
> > +
> > +                     /* Use associated dummy as fallback for formal
> > +                        argument if there is no explicit interface.  */
> > (...)
> 
> Note that if there is no explicit interface, I expect associated_dummy to be
> NULL, and as a result dsym and fsym to always actually be the same thing.

No, they're not, when the procedures are in the same file.
At least that's what gdb tells me...

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[mikael at gcc dot gnu.org]

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

--- Comment #24 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #22)
> 
> The remaining problem from PR41453#c8 is the following code in trans-expr.cc:
> 
> (gdb) l 9539,9548
> 9539          else if (add_clobber && expr->ref == NULL)
> 9540            {
> 9541              tree clobber;
> 9542              tree var;
> 9543              /* FIXME: This fails if var is passed by reference, see PR
> 9544                 41453.  */
> 9545              var = expr->symtree->n.sym->backend_decl;
> 9546              clobber = build_clobber (TREE_TYPE (var));
> 9547              gfc_add_modify (&se->pre, var, clobber);
> 9548            }
> 
> One needs to understand how to fix up 'var' here for the case at hand.
> 
I guess the obvious one (se->expr) doesn’t work?

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[anlauf at gcc dot gnu.org]

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

--- Comment #25 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #24)
> (In reply to anlauf from comment #22)
> > 
> > The remaining problem from PR41453#c8 is the following code in trans-expr.cc:
> > 
> > (gdb) l 9539,9548
> > 9539          else if (add_clobber && expr->ref == NULL)
> > 9540            {
> > 9541              tree clobber;
> > 9542              tree var;
> > 9543              /* FIXME: This fails if var is passed by reference, see PR
> > 9544                 41453.  */
> > 9545              var = expr->symtree->n.sym->backend_decl;
> > 9546              clobber = build_clobber (TREE_TYPE (var));
> > 9547              gfc_add_modify (&se->pre, var, clobber);
> > 9548            }
> > 
> > One needs to understand how to fix up 'var' here for the case at hand.
> > 
> I guess the obvious one (se->expr) doesn’t work?

Could you explain how to use it?  (I don't have the necessary vision.)

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[mikael at gcc dot gnu.org]

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

--- Comment #26 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #25)
> (In reply to Mikael Morin from comment #24)
> > (In reply to anlauf from comment #22)
> > > 
> > > The remaining problem from PR41453#c8 is the following code in trans-expr.cc:
> > > 
> > > (gdb) l 9539,9548
> > > 9539          else if (add_clobber && expr->ref == NULL)
> > > 9540            {
> > > 9541              tree clobber;
> > > 9542              tree var;
> > > 9543              /* FIXME: This fails if var is passed by reference, see PR
> > > 9544                 41453.  */
> > > 9545              var = expr->symtree->n.sym->backend_decl;
> > > 9546              clobber = build_clobber (TREE_TYPE (var));
> > > 9547              gfc_add_modify (&se->pre, var, clobber);
> > > 9548            }
> > > 
> > > One needs to understand how to fix up 'var' here for the case at hand.
> > > 
> > I guess the obvious one (se->expr) doesn’t work?
> 
> Could you explain how to use it?  (I don't have the necessary vision.)

Upon return from gfc_conv_expr, se->expr holds the value of the expression.
So basically var = se->expr;
As we manage to pass __result_derfc as argument, then I expect se->expr to have
value __result_derfc at that point.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[anlauf at gcc dot gnu.org]

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

--- Comment #27 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #26)
> (In reply to anlauf from comment #25)
> > (In reply to Mikael Morin from comment #24)
> > > (In reply to anlauf from comment #22)
> > > > 
> > > > The remaining problem from PR41453#c8 is the following code in trans-expr.cc:
> > > > 
> > > > (gdb) l 9539,9548
> > > > 9539          else if (add_clobber && expr->ref == NULL)
> > > > 9540            {
> > > > 9541              tree clobber;
> > > > 9542              tree var;
> > > > 9543              /* FIXME: This fails if var is passed by reference, see PR
> > > > 9544                 41453.  */
> > > > 9545              var = expr->symtree->n.sym->backend_decl;
> > > > 9546              clobber = build_clobber (TREE_TYPE (var));
> > > > 9547              gfc_add_modify (&se->pre, var, clobber);
> > > > 9548            }
> > > > 
> > > > One needs to understand how to fix up 'var' here for the case at hand.
> > > > 
> > > I guess the obvious one (se->expr) doesn’t work?
> > 
> > Could you explain how to use it?  (I don't have the necessary vision.)
> 
> Upon return from gfc_conv_expr, se->expr holds the value of the expression.
> So basically var = se->expr;
> As we manage to pass __result_derfc as argument, then I expect se->expr to
> have value __result_derfc at that point.

I tried that - just rechecked - and get an ICE: gimplification failed.
So there's some magic missing I don't see...

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[mikael at gcc dot gnu.org]

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

--- Comment #28 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #23)
> 
> No, they're not, when the procedures are in the same file.
> At least that's what gdb tells me...

gdb tells me the same. :-)
It is a side effect of calling gfc_check_externals it seems.


(In reply to anlauf from comment #27)
> (In reply to Mikael Morin from comment #26)
> > 
> > Upon return from gfc_conv_expr, se->expr holds the value of the expression.
> > So basically var = se->expr;
> > As we manage to pass __result_derfc as argument, then I expect se->expr to
> > have value __result_derfc at that point.
> 
> I tried that - just rechecked - and get an ICE: gimplification failed.
> So there's some magic missing I don't see...

With se->expr, what is generated is:
  &__result_derfc = {CLOBBER};

Not too bad, but not exactly there yet.
With the following, I get the expected result.
Indeed, with se->want_pointer set, gfc_conv_expr generates an address
expression, so it has to be dereferenced to get back the variable.

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 6c8fa16e723..367ecc2eb65 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -9602,7 +9602,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr,
bool add_clobber)
          tree var;
          /* FIXME: This fails if var is passed by reference, see PR
             41453.  */
-         var = expr->symtree->n.sym->backend_decl;
+         var = build_fold_indirect_ref_loc (input_location, se->expr);
          clobber = build_clobber (TREE_TYPE (var));
          gfc_add_modify (&se->pre, var, clobber);
        }

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[anlauf at gcc dot gnu.org]

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

--- Comment #29 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #28)
> With the following, I get the expected result.
> Indeed, with se->want_pointer set, gfc_conv_expr generates an address
> expression, so it has to be dereferenced to get back the variable.
> 
> diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> index 6c8fa16e723..367ecc2eb65 100644
> --- a/gcc/fortran/trans-expr.cc
> +++ b/gcc/fortran/trans-expr.cc
> @@ -9602,7 +9602,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr,
> bool add_clobber)
>           tree var;
>           /* FIXME: This fails if var is passed by reference, see PR
>              41453.  */
> -         var = expr->symtree->n.sym->backend_decl;
> +         var = build_fold_indirect_ref_loc (input_location, se->expr);
>           clobber = build_clobber (TREE_TYPE (var));
>           gfc_add_modify (&se->pre, var, clobber);
>         }

I tried the more hackish

@@ -9529,9 +9540,12 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr,
bool add_clobber)
        {
          tree clobber;
          tree var;
+         gfc_symbol *sym = expr->symtree->n.sym;
          /* FIXME: This fails if var is passed by reference, see PR
             41453.  */
          var = expr->symtree->n.sym->backend_decl;
+         if (sym->attr.function && sym->result == sym)
+           var = gfc_get_fake_result_decl (sym, 0);
          clobber = build_clobber (TREE_TYPE (var));
          gfc_add_modify (&se->pre, var, clobber);
        }

but if your patch regtests fine then you should proceed.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |mikael at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #30 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #29)
> 
> but if your patch regtests fine then you should proceed.

Ok, let’s see how good it is.
Assigning.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[mikael at gcc dot gnu.org]

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

--- Comment #31 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #30)
> (In reply to anlauf from comment #29)
> > 
> > but if your patch regtests fine then you should proceed.
> 
> Ok, let’s see how good it is.
> Assigning.

It seems to work, but trying to extend clobbering further, I uncovered a bug
latent on master: PR106817.
Maybe not that good an idea to extend clobbering further. :-(

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #32 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:edaf1e005c90b311c39b46d85cea17befbece112

commit r13-2834-gedaf1e005c90b311c39b46d85cea17befbece112
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Mon Aug 29 11:19:29 2022 +0200

    fortran: Fix invalid function decl clobber ICE [PR105012]

    The fortran frontend, as result symbol for a function without
    declared result symbol, uses the function symbol itself.  This caused
    an invalid clobber of a function decl to be emitted, leading to an
    ICE, whereas the intended behaviour was to clobber the function result
    variable.  This change fixes the problem by getting the decl from the
    just-retrieved variable reference after the call to
    gfc_conv_expr_reference, instead of copying it from the frontend symbol.

            PR fortran/105012

    gcc/fortran/ChangeLog:

            * trans-expr.cc (gfc_conv_procedure_call): Retrieve variable
            from the just calculated variable reference.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_out_15.f90: New test.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #33 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:20aa1eb6cb84e6a0487b47b28b00109c5f46a7e2

commit r13-2836-g20aa1eb6cb84e6a0487b47b28b00109c5f46a7e2
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Wed Aug 31 11:50:35 2022 +0200

    fortran: Support clobbering with implicit interfaces [PR105012]

    Before procedure calls, we clobber actual arguments whose associated
    dummy is INTENT(OUT).  This only applies to procedures with explicit
    interfaces, as the knowledge of the interface is necessary to know
    whether an argument has the INTENT(OUT) attribute.

    This change also enables clobber generation for procedure calls without
    explicit interface, when the procedure has been defined in the same
    file because we can use the dummy arguments' characteristics from the
    procedure definition in that case.

    The knowledge of the dummy characteristics is directly available through
    gfc_actual_arglistâs associated_dummy pointers which have been populated
    as a side effect of calling gfc_check_externals.

            PR fortran/105012

    gcc/fortran/ChangeLog:

            * trans-expr.cc (gfc_conv_procedure_call): Use dummy
            information from associated_dummy if there is no information
            from the procedure interface.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_optimize_5.f90: New test.

    Co-Authored-By: Mikael Morin <mikael@gcc.gnu.org>

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #34 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Mikael Morin
<mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:e34e5195025acd623c2383c36b99cc88ca026acf

commit r11-10299-ge34e5195025acd623c2383c36b99cc88ca026acf
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Mon Aug 29 11:19:29 2022 +0200

    fortran: Fix invalid function decl clobber ICE [PR105012]

    The fortran frontend, as result symbol for a function without
    declared result symbol, uses the function symbol itself.  This caused
    an invalid clobber of a function decl to be emitted, leading to an
    ICE, whereas the intended behaviour was to clobber the function result
    variable.  This change fixes the problem by getting the decl from the
    just-retrieved variable reference after the call to
    gfc_conv_expr_reference, instead of copying it from the frontend symbol.

            PR fortran/105012

    gcc/fortran/ChangeLog:

            * trans-expr.c (gfc_conv_procedure_call): Retrieve variable
            from the just calculated variable reference.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_out_15.f90: New test.

    (cherry picked from commit edaf1e005c90b311c39b46d85cea17befbece112)

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #35 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Mikael Morin
<mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:9d18ff4606dabadc5bda11e6cdadc4383ec2f4e5

commit r10-11028-g9d18ff4606dabadc5bda11e6cdadc4383ec2f4e5
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Mon Aug 29 11:19:29 2022 +0200

    fortran: Fix invalid function decl clobber ICE [PR105012]

    The fortran frontend, as result symbol for a function without
    declared result symbol, uses the function symbol itself.  This caused
    an invalid clobber of a function decl to be emitted, leading to an
    ICE, whereas the intended behaviour was to clobber the function result
    variable.  This change fixes the problem by getting the decl from the
    just-retrieved variable reference after the call to
    gfc_conv_expr_reference, instead of copying it from the frontend symbol.

            PR fortran/105012

    gcc/fortran/ChangeLog:

            * trans-expr.c (gfc_conv_procedure_call): Retrieve variable
            from the just calculated variable reference.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_out_15.f90: New test.

    (cherry picked from commit edaf1e005c90b311c39b46d85cea17befbece112)

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Mikael Morin
<mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:5d645a9dbda0174a25358bf5090640acedec1159

commit r12-8825-g5d645a9dbda0174a25358bf5090640acedec1159
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Mon Aug 29 11:19:29 2022 +0200

    fortran: Fix invalid function decl clobber ICE [PR105012]

    The fortran frontend, as result symbol for a function without
    declared result symbol, uses the function symbol itself.  This caused
    an invalid clobber of a function decl to be emitted, leading to an
    ICE, whereas the intended behaviour was to clobber the function result
    variable.  This change fixes the problem by getting the decl from the
    just-retrieved variable reference after the call to
    gfc_conv_expr_reference, instead of copying it from the frontend symbol.

            PR fortran/105012

    gcc/fortran/ChangeLog:

            * trans-expr.cc (gfc_conv_procedure_call): Retrieve variable
            from the just calculated variable reference.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_out_15.f90: New test.

    (cherry picked from commit edaf1e005c90b311c39b46d85cea17befbece112)

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #37 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #14)
> I installed a workaround for the ICE, the fortran issue remains

Fortran issue now fixed as well, and backported for 12.3, 11.4, and 10.5
releases.
Closing.