Re: 6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes
Hi Rainer,
thanks for testing and also for giving a solution. I was sure, I would break
something. Fixed as obvious as gcc-15-7662-g08bdc2ac98a after regtesting ok on
x86_64-pc-linux-gnu / Fedora 41 (which gets more unstable with every update I
receive IMO). I opted for the __builtin_alloca version. That seemed to be the
most portable one.
Thanks again for the report and keep testing please,
Andre
On Thu, 20 Feb 2025 19:26:41 +0100
Rainer Orth wrote:
> Hi Andre,
>
> this patch broke Solaris bootstrap:
>
> /vol/gcc/src/hg/master/local/libgfortran/caf/single.c: In function
> ‘_gfortran_caf_transfer_between_remotes’:
> /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:675:23: error: implicit
> declaration of function ‘alloca’ [-Wimplicit-function-declaration] 675 |
> transfer_desc = alloca (desc_size); | ^~
> /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:675:23: warning:
> incompatible implicit declaration of built-in function ‘alloca’
> [-Wbuiltin-declaration-mismatch]
> /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:680:20: warning:
> incompatible implicit declaration of built-in function ‘alloca’
> [-Wbuiltin-declaration-mismatch] 680 | transfer_ptr = alloca
> (*opt_dst_charlen * src_size); |^~ make[3]: ***
> [Makefile:4675: caf/single.lo] Error 1
>
> Solaris needs to include to get an alloca declaration. While
> this could be handled with AC_FUNC_ALLOCA (like libcpp does) or checking
> for alloca.h and including it if found (like libssp does), I guess
> there's a simpler way: several runtime libs use __builtin_alloca
> unconditionally (libgcc, libquadmath, libstdc++-v3).
>
> Rainer
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 76b2b1ee14024bba0a618ee98505550cd7c41a1d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 21 Feb 2025 08:18:40 +0100
Subject: [PATCH] Fortran: Fix build on solaris [PR107635]
libgfortran/ChangeLog:
PR fortran/107635
* caf/single.c: Replace alloca with __builtin_alloca.
---
libgfortran/caf/single.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgfortran/caf/single.c b/libgfortran/caf/single.c
index d4e081be4dd..9c1c0c1bc8c 100644
--- a/libgfortran/caf/single.c
+++ b/libgfortran/caf/single.c
@@ -672,12 +672,12 @@ _gfortran_caf_transfer_between_remotes (
if (!scalar_transfer)
{
const size_t desc_size = sizeof (*transfer_desc);
- transfer_desc = alloca (desc_size);
+ transfer_desc = __builtin_alloca (desc_size);
memset (transfer_desc, 0, desc_size);
transfer_ptr = transfer_desc;
}
else if (opt_dst_charlen)
-transfer_ptr = alloca (*opt_dst_charlen * src_size);
+transfer_ptr = __builtin_alloca (*opt_dst_charlen * src_size);
else
{
buffer = NULL;
--
2.48.1
Re: [PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer [PR48958]
Hi Harald, seconding Thomas here, thanks for the patch. - Andre On Thu, 20 Feb 2025 21:18:01 +0100 Harald Anlauf wrote: > Dear all, > > the attached simple patch addresses a small, left-over issue in the > above PR and was already OK'ed in the PR by Thomas. With it we > initialize the data component of a non-saved pointer variable when > -fcheck=pointer is specified, so that subsequent pointer checks > (e.g. for the SIZE intrinsic) trigger consistently and not randomly. > > I plan to commit within 24h unless there are comments. > > Regtested on x86_64-pc-linux-gnu. ON for mainline? > > Thanks, > Harald > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: 6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes
Hi Andre, > thanks for testing and also for giving a solution. I was sure, I would break > something. Fixed as obvious as gcc-15-7662-g08bdc2ac98a after regtesting ok on > x86_64-pc-linux-gnu / Fedora 41 (which gets more unstable with every update I > receive IMO). I opted for the __builtin_alloca version. That seemed to be the > most portable one. agreed, and the least intrusive one. > Thanks again for the report and keep testing please, Sure: usually once a day ;-) Thanks for the quick fix. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[Fortran, Patch, PR107635, 4_v1] Fix class type and descriptor handling for new coarray interface [PR107635]
Hi all,
during testing and compiling some larger coarray codes, I found a few
deficiencies. One was with handling class types when splitting the coarray
expression and the other was that the backend_decl of a formal argument in a
function's symbol was not the same as the one the function was compiled to. So
looking at the function-decl's tree n-th formal argument is the way to go there.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From efc6ed615b36bb6b42a43f6f35bf81a1adce2941 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 21 Feb 2025 14:06:28 +0100
Subject: [PATCH] Fortran: Fix detection of descriptor arrays in coarray
[PR107635]
Look at the formal arguments generated type in the function declaration
to figure if an argument is a descriptor arrays. Fix handling of class
types while splitting coarray expressions.
PR fortran/107635
gcc/fortran/ChangeLog:
* coarray.cc (fixup_comp_refs): For class types set correct
component (class) type.
(split_expr_at_caf_ref): Provide location.
* trans-intrinsic.cc (conv_caf_send_to_remote): Look at
generated formal argument and not declared one to detect
descriptor arrays.
(conv_caf_sendget): Same.
---
gcc/fortran/coarray.cc | 15 ++-
gcc/fortran/trans-intrinsic.cc | 15 +--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/gcc/fortran/coarray.cc b/gcc/fortran/coarray.cc
index e5648e0d027..f53de0b20e3 100644
--- a/gcc/fortran/coarray.cc
+++ b/gcc/fortran/coarray.cc
@@ -295,11 +295,12 @@ move_coarray_ref (gfc_ref **from, gfc_expr *expr)
static void
fixup_comp_refs (gfc_expr *expr)
{
- gfc_symbol *type = expr->symtree->n.sym->ts.type == BT_DERIVED
- ? expr->symtree->n.sym->ts.u.derived
- : (expr->symtree->n.sym->ts.type == BT_CLASS
- ? CLASS_DATA (expr->symtree->n.sym)->ts.u.derived
- : nullptr);
+ bool class_ref = expr->symtree->n.sym->ts.type == BT_CLASS;
+ gfc_symbol *type
+= expr->symtree->n.sym->ts.type == BT_DERIVED
+ ? expr->symtree->n.sym->ts.u.derived
+ : (class_ref ? CLASS_DATA (expr->symtree->n.sym)->ts.u.derived
+ : nullptr);
if (!type)
return;
gfc_ref **pref = &(expr->ref);
@@ -317,6 +318,9 @@ fixup_comp_refs (gfc_expr *expr)
ref = nullptr;
break;
}
+ if (class_ref)
+ /* Link to the class type to allow for derived type resolution. */
+ (*pref)->u.c.sym = ref->u.c.sym;
(*pref)->next = ref->next;
ref->next = NULL;
gfc_free_ref_list (ref);
@@ -372,6 +376,7 @@ split_expr_at_caf_ref (gfc_expr *expr, gfc_namespace *ns,
st->n.sym->attr.dummy = 1;
st->n.sym->attr.intent = INTENT_IN;
st->n.sym->ts = *caf_ts;
+ st->n.sym->declared_at = expr->where;
*post_caf_ref_expr = gfc_get_variable_expr (st);
(*post_caf_ref_expr)->where = expr->where;
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 80e98dc3c20..f48f39d7a82 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -1445,8 +1445,9 @@ conv_caf_send_to_remote (gfc_code *code)
NULL_TREE, gfc_trans_force_lval (&block, lhs_se.string_length));
else
opt_lhs_charlen = build_zero_cst (build_pointer_type (size_type_node));
- if (!TYPE_LANG_SPECIFIC (TREE_TYPE (caf_decl))->rank
- || GFC_ARRAY_TYPE_P (TREE_TYPE (caf_decl)))
+ tmp = TREE_VALUE (TREE_CHAIN (TREE_CHAIN (TYPE_ARG_TYPES (
+ TREE_TYPE (receiver_fn_expr->symtree->n.sym->backend_decl);
+ if (!GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (tmp)))
opt_lhs_desc = null_pointer_node;
else
opt_lhs_desc
@@ -1635,8 +1636,9 @@ conv_caf_sendget (gfc_code *code)
NULL_TREE, gfc_trans_force_lval (&block, lhs_se.string_length));
else
opt_lhs_charlen = build_zero_cst (build_pointer_type (size_type_node));
- if (!TYPE_LANG_SPECIFIC (TREE_TYPE (lhs_caf_decl))->rank
- || GFC_ARRAY_TYPE_P (TREE_TYPE (lhs_caf_decl)))
+ tmp = TREE_VALUE (TREE_CHAIN (TREE_CHAIN (TYPE_ARG_TYPES (
+ TREE_TYPE (receiver_fn_expr->symtree->n.sym->backend_decl);
+ if (!GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (tmp)))
opt_lhs_desc = null_pointer_node;
else
opt_lhs_desc
@@ -1677,8 +1679,9 @@ conv_caf_sendget (gfc_code *code)
rhs_size = gfc_typenode_for_spec (ts)->type_common.size_unit;
}
}
- else if (!TYPE_LANG_SPECIFIC (TREE_TYPE (rhs_caf_decl))->rank
- || GFC_ARRAY_TYPE_P (TREE_TYPE (rhs_caf_decl)))
+ else if (!GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (TREE_VALUE (
+ TREE_CHAIN (TREE_CHAIN (TREE_CHAIN (TREE_CHAIN (TYPE_ARG_TYPES (
+ TREE_TYPE (sender_fn_expr->symtree->n.sym->backend_decl))
{
rhs_se.data_not_needed = 1;
gfc_conv_expr_descriptor (&rhs_se, rhs_expr);
--
2.48.1
Re: [PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer [PR48958]
On 2/21/25 09:21, Andre Vehreschild wrote: Hi Harald, seconding Thomas here, thanks for the patch. Thanks, Andre! Pushed: r15-7663-g7d383a7343af05 - Andre On Thu, 20 Feb 2025 21:18:01 +0100 Harald Anlauf wrote: Dear all, the attached simple patch addresses a small, left-over issue in the above PR and was already OK'ed in the PR by Thomas. With it we initialize the data component of a non-saved pointer variable when -fcheck=pointer is specified, so that subsequent pointer checks (e.g. for the SIZE intrinsic) trigger consistently and not randomly. I plan to commit within 24h unless there are comments. Regtested on x86_64-pc-linux-gnu. ON for mainline? Thanks, Harald -- Andre Vehreschild * Email: vehre ad gmx dot de
