Le 01/04/2026 à 22:38, Harald Anlauf a écrit :
Dear all,

the attached almost obvious patch fixes actually two issues:
- when C_FUNLOC is applied to a procedure pointer instead of
   a procedure, and the procedure pointer is a dummy, we need
   to dereference it;
- a procedure pointer dummy with intent(out) was clobbered,
   but the clobber was using the dereferenced pointer, which
   did fail in gimple at -O1 and higher (and is actually
   detecting wrong code).
   The solution is to   not clobber (and we have a couple of
   similar exceptions).

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

As the above issues can be naughty, is it OK to backport to 15-branch?

Thanks,
Harald

pr124652.diff

From b76f5b9108d8ac1dfaa54817d42fae292451ff02 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <[email protected]>
Date: Wed, 1 Apr 2026 22:28:02 +0200
Subject: [PATCH] Fortran: fix passing a procedure pointer to c_funloc
 [PR124652]

        PR fortran/124652

gcc/fortran/ChangeLog:

        * trans-expr.cc (gfc_conv_procedure_call): Do not clobber a
        procedure pointer intent(out) argument.
        * trans-intrinsic.cc (conv_isocbinding_function): When passing to
        C_FUNLOC a procedure pointer that is a dummy, dereference it.

gcc/testsuite/ChangeLog:

        * gfortran.dg/c_funloc_tests_10.f90: New test.
---
 gcc/fortran/trans-expr.cc                     |  1 +
 gcc/fortran/trans-intrinsic.cc                |  3 +
 .../gfortran.dg/c_funloc_tests_10.f90         | 86 +++++++++++++++++++
 3 files changed, 90 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/c_funloc_tests_10.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 52918961584..3945d9eaa67 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7549,6 +7549,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
                                  && !e->ts.u.derived->attr.alloc_comp
                                  && !e->ts.u.derived->attr.pdt_type
                                  && !gfc_is_finalizable (e->ts.u.derived, 
NULL)))
+                         && e->ts.type != BT_PROCEDURE
                          && !sym->attr.elemental)
                        {
                          tree var;

I agree, if the argument is a dummy procedure or dummy procedure pointer we don't want the clobber, but if the argument is a local procedure pointer, we do want the clobber, don't we?

I think we should check that the var clobbered is a VAR_DECL, or maybe a PARM_DECL or RESULT_DECL (or a conversion of such a DECL?).

If you don't have time to refine it further, please go ahead with your patch as is. At least it prevents the ICE.

Mikael

Reply via email to