Hi Tobias, hi Walter,
On Tue, Sep 23, 2025 at 2:13 AM Tobias Burnus <[email protected]> wrote:
> This seems to be fixed by Yuao's latest patch. In one of my local
> branches, I have it applied – in the other not. And the one that has it
> works, in the other, I get the segfault. Thus, it really must be that patch.
This issue indeed will be resolved in my latest patch, specifically
the following segment. The problem lies in the gfc_conv_constant
function not handling want_pointer. Therefore, when gfc_trans_transfer
requests a reference to a constant in the true or false branch, it is
simply ignored. In the test case above, the address received is 0x1,
which is clearly invalid.
diff --git a/gcc/fortran/trans-const.cc b/gcc/fortran/trans-const.cc
index ea1501a4d54..54c9ac54f39 100644
--- a/gcc/fortran/trans-const.cc
+++ b/gcc/fortran/trans-const.cc
@@ -438,4 +438,12 @@ gfc_conv_constant (gfc_se * se, gfc_expr * expr)
structure, too. */
if (expr->ts.type == BT_CHARACTER)
se->string_length = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (se->expr)));
+
+ if (se->want_pointer)
+ {
+ if (expr->ts.type == BT_CHARACTER && !gfc_is_proc_ptr_comp (expr))
+ gfc_conv_string_parameter (se);
+ else
+ se->expr = gfc_build_addr_expr (NULL_TREE, se->expr);
+ }
}
Perhaps the patch above could be handled/tested/committed first?
> Namely: Why are procedure-pointer components handled differently?
I must admit that I borrowed this code snippet from gfc_conv_variable.
I am unsure if gfc_is_proc_ptr_comp is appropriate here, so I included
it to keep them consistent.
Thanks,
Yuao
