[Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.
Hi all,
attached patch fixes a 12-regression when an assignment to a pointer array is
done. The issue was a missing indirect ref on assign as it was already done for
allocatable arrays.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 27ca62555c4b09349ab33f806b386b485dfe7c8a Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Tue, 4 Mar 2025 12:56:20 +0100
Subject: [PATCH] Fortran: Fix gimplification error on assignment to pointer
[PR103391]
PR fortran/103391
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_trans_assignment_1): Do not use poly assign
for pointer arrays on lhs (as it is done for allocatables
already).
gcc/testsuite/ChangeLog:
* gfortran.dg/assign_12.f90: New test.
---
gcc/fortran/trans-expr.cc | 16 +++---
gcc/testsuite/gfortran.dg/assign_12.f90 | 28 +
2 files changed, 36 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/assign_12.f90
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 0d790b63f95..fbe7333fd71 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -12876,14 +12876,14 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
needed. */
lhs_attr = gfc_expr_attr (expr1);
- is_poly_assign = (use_vptr_copy || lhs_attr.pointer
- || (lhs_attr.allocatable && !lhs_attr.dimension))
- && (expr1->ts.type == BT_CLASS
- || gfc_is_class_array_ref (expr1, NULL)
- || gfc_is_class_scalar_expr (expr1)
- || gfc_is_class_array_ref (expr2, NULL)
- || gfc_is_class_scalar_expr (expr2))
- && lhs_attr.flavor != FL_PROCEDURE;
+ is_poly_assign
+= (use_vptr_copy
+ || ((lhs_attr.pointer || lhs_attr.allocatable) && !lhs_attr.dimension))
+ && (expr1->ts.type == BT_CLASS || gfc_is_class_array_ref (expr1, NULL)
+ || gfc_is_class_scalar_expr (expr1)
+ || gfc_is_class_array_ref (expr2, NULL)
+ || gfc_is_class_scalar_expr (expr2))
+ && lhs_attr.flavor != FL_PROCEDURE;
assoc_assign = is_assoc_assign (expr1, expr2);
diff --git a/gcc/testsuite/gfortran.dg/assign_12.f90 b/gcc/testsuite/gfortran.dg/assign_12.f90
new file mode 100644
index 000..be31021f24c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/assign_12.f90
@@ -0,0 +1,28 @@
+!{ dg-do run }
+!
+! Check assignment works for derived types to memory referenced by pointer
+! Contributed by G. Steinmetz
+
+program pr103391
+ type t
+ character(1) :: c
+ end type
+ type t2
+ type(t), pointer :: a(:)
+ end type
+
+ type(t), target :: arr(2)
+ type(t2) :: r
+
+ arr = [t('a'), t('b')]
+
+ r = f([arr])
+ if (any(r%a(:)%c /= ['a', 'b'])) stop 1
+contains
+ function f(x)
+ class(t), intent(in), target :: x(:)
+ type(t2) :: f
+ allocate(f%a(size(x,1)))
+ f%a = x
+ end
+end
--
2.48.1
Re: [patch, Fortran] Fix PR 119049 and 119074, external prototypes with different arglists
Hi Thomas, Am 03.03.25 um 22:50 schrieb Thomas Koenig: Hello world, this patch is a bit more complicated than originally envisioned. The problem was that we were not handling external dummy arguments with -fc-prototypes-external. In looking at this, I found that we were not warning about external procedures with different argument lists. This can actually be legal (see the two test cases) but creates a problem for the C prototypes: If we have something like subroutine foo(a,n) external a if (n == 1) call a(1) if (n == 2) call a(2,3) end subroutine foo then, pre-C23, we could just have written out the prototype as void foo_ (void (*a) (), int *n); but this is illegal in C23. What to do? I finally chose to warn about the argument mismatch, with a new option. Warn only because the code above is legal, but include in -Wall because such code seems highly suspect. This option is also implied in -fc-prototypes-external. I also put a warning in the generated header file in that case, so users have a chance to see what is going on (especially since gcc now defaults to C23). Regression-tested. Comments? Suggestions for better wordings? Is -Wall too strong, should this be -Wextra (but then nobody would see it, probably...)? OK for trunk? Best regards Thomas aren't we wasting memory here? @@ -2023,6 +2023,10 @@ typedef struct gfc_symbol scope. Used in the suppression of uninitialized warnings in reallocation on assignment. */ unsigned allocated_in_scope:1; + /* Set if an external dummy argument is called with different argument lists. + This is legal in Fortran, but can cause problems with autogenerated + C prototypes for C23. */ + unsigned ext_dummy_arglist_mismatch; I assume you wanted a single bit instead of a full unsigned, i.e.: + unsigned ext_dummy_arglist_mismatch:1; Harald
Re: [Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.
Hi Paul, thanks for the review. Committed as gcc-15-7812-g04909c7ecc0. Yes please: you do the backport. Thank you very much. I am looking at pr104684 at the moment, which is the last regression on my list (i.e. that I am assigned or cc'ed to). When the regression test for this is fine, I will continue with the coarray teams stuff. If you find any regressions I have caused or you don't find the solution for, just add me to cc. Thanks again, Andre On Tue, 4 Mar 2025 13:46:33 + Paul Richard Thomas wrote: > Hi Andre, > > You beat me to it! I had just noticed the missing indirect reference. Yes, > this is good for mainline and backporting to 14-branch at very least. > > Thanks for the patch. If you want to do the push to mainline, I will do the > backporting if you like? I'll not be back at base for a little while so > there will be a suitable delay. > I have several Steinmetz sourced regression fixes to bring to the list in > the next days. > > Cheers > > Paul > > > On Tue, 4 Mar 2025 at 12:02, Andre Vehreschild wrote: > > > Hi all, > > > > attached patch fixes a 12-regression when an assignment to a pointer array > > is > > done. The issue was a missing indirect ref on assign as it was already > > done for > > allocatable arrays. > > > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > > > > Regards, > > Andre > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.
Hi Andre, You beat me to it! I had just noticed the missing indirect reference. Yes, this is good for mainline and backporting to 14-branch at very least. Thanks for the patch. If you want to do the push to mainline, I will do the backporting if you like? I'll not be back at base for a little while so there will be a suitable delay. I have several Steinmetz sourced regression fixes to bring to the list in the next days. Cheers Paul On Tue, 4 Mar 2025 at 12:02, Andre Vehreschild wrote: > Hi all, > > attached patch fixes a 12-regression when an assignment to a pointer array > is > done. The issue was a missing indirect ref on assign as it was already > done for > allocatable arrays. > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
[Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.
Hi all,
attached patch fixes a gimplification fault when a pointer assignment to an
allocatable array is done. The tree type is different, because of that flag in
the lang_specific structure. View-converting the type fixes the issue.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 3acd5266f70c29d6b2b3078e122f61f6537b602d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Tue, 4 Mar 2025 17:06:31 +0100
Subject: [PATCH] Fortran: Add view convert to pointer assign when only
pointer/alloc attr differs [PR104684]
PR fortran/104684
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_expr_descriptor): Look at the
lang-specific akind and do a view convert when only the akind
attribute differs between pointer and allocatable array.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/ptr_comp_6.f08: New test.
---
gcc/fortran/trans-array.cc| 10 +++-
.../gfortran.dg/coarray/ptr_comp_6.f08| 25 +++
2 files changed, 34 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/coarray/ptr_comp_6.f08
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 6a00d26cb2f..925030465ac 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -8186,8 +8186,16 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
{
if (se->direct_byref && !se->byref_noassign)
{
+ struct lang_type *lhs_ls
+ = TYPE_LANG_SPECIFIC (TREE_TYPE (se->expr)),
+ *rhs_ls = TYPE_LANG_SPECIFIC (TREE_TYPE (desc));
+ /* When only the array_kind differs, do a view_convert. */
+ tmp = lhs_ls && rhs_ls && lhs_ls->rank == rhs_ls->rank
+ && lhs_ls->akind != rhs_ls->akind
+ ? build1 (VIEW_CONVERT_EXPR, TREE_TYPE (se->expr), desc)
+ : desc;
/* Copy the descriptor for pointer assignments. */
- gfc_add_modify (&se->pre, se->expr, desc);
+ gfc_add_modify (&se->pre, se->expr, tmp);
/* Add any offsets from subreferences. */
gfc_get_dataptr_offset (&se->pre, se->expr, desc, NULL_TREE,
diff --git a/gcc/testsuite/gfortran.dg/coarray/ptr_comp_6.f08 b/gcc/testsuite/gfortran.dg/coarray/ptr_comp_6.f08
new file mode 100644
index 000..397a09bc8bc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/ptr_comp_6.f08
@@ -0,0 +1,25 @@
+!{ dg-do run }
+!
+! Contributed by Arseny Solokha
+
+program pr104684
+ type :: index_map
+integer, allocatable :: send_index(:)
+ end type
+ type(index_map) :: imap
+
+ imap%send_index = [5,4,3]
+ call sub(imap)
+contains
+ subroutine sub(this)
+type(index_map), intent(inout), target :: this
+type :: box
+ integer, pointer :: array(:)
+end type
+type(box), allocatable :: buffer[:]
+allocate(buffer[*])
+buffer%array => this%send_index
+if (any(buffer%array /= [5,4,3])) stop 1
+ end subroutine
+end program
+
--
2.48.1
Re: [Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.
Hi Andre, Am 04.03.25 um 17:11 schrieb Andre Vehreschild: Hi all, attached patch fixes a gimplification fault when a pointer assignment to an allocatable array is done. The tree type is different, because of that flag in the lang_specific structure. View-converting the type fixes the issue. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? this LGTM. I am wondering if this kind of fix also helps with pr107143, where pointer remapping is used, but your code is not reached in that situation. Thanks for the patch! Harald Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, PR77872, v1] Fix ICE when getting caf-token from abstract class type.
Hi Steve, thanks for the review. Committed as gcc-15-7804-g5bd66483839. Thanks again, Andre On Mon, 3 Mar 2025 12:34:49 -0800 Steve Kargl wrote: > On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote: > > > > attached patches fix a 12-regression, when a caf token is requested from an > > abstract class-typed dummy. The token was not looked up in the correct spot. > > Due the class typed object getting an artificial variable for direct derived > > type access, the get_caf_decl was looking at the wrong decl. > > > > This patch consists of two parts, the first is just some code complexity > > reduction, where an existing attr is now used instead of checking for > > BT_CLASS type and branching. > > > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > > > > Thanks. OK to commit. > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [patch, Fortran] Fix PR 119049 and 119074, external prototypes with different arglists
Hi Thomas, while the patch looks ok to me, why did you not choose to generate a "22.7.2 Variable-Length Parameter Lists" https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html when the arguments differ? Then its the callee responsibility to figure stuff out. Just out of curiosity. Is this prohibited by any standard? My question is just out of interest. No need to change the patch. Having a warning is better, then running into "WTF?". Look good to me, ok for mainline. Thanks for the patch, Andre On Mon, 3 Mar 2025 22:50:16 +0100 Thomas Koenig wrote: > Hello world, > > this patch is a bit more complicated than originally envisioned. > > The problem was that we were not handling external dummy arguments > with -fc-prototypes-external. In looking at this, I found that we > were not warning about external procedures with different argument > lists. This can actually be legal (see the two test cases) but > creates a problem for the C prototypes: If we have something like > > subroutine foo(a,n) >external a >if (n == 1) call a(1) >if (n == 2) call a(2,3) > end subroutine foo > > then, pre-C23, we could just have written out the prototype as > > void foo_ (void (*a) (), int *n); > > but this is illegal in C23. What to do? I finally chose to warn > about the argument mismatch, with a new option. Warn only because the > code above is legal, but include in -Wall because such code seems highly > suspect. This option is also implied in -fc-prototypes-external. I also > put a warning in the generated header file in that case, so users > have a chance to see what is going on (especially since gcc now > defaults to C23). > > Regression-tested. > > Comments? Suggestions for better wordings? Is -Wall too strong, > should this be -Wextra (but then nobody would see it, probably...)? > OK for trunk? > > Best regards > > Thomas -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [patch, Fortran] Fix PR 119049 and 119074, external prototypes with different arglists
Hi Andre, while the patch looks ok to me, why did you not choose to generate a "22.7.2 Variable-Length Parameter Lists" https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html when the arguments differ? Then its the callee responsibility to figure stuff out. Just out of curiosity. Is this prohibited by any standard? My question is just out of interest. No need to change the patch. Having a warning is better, then running into "WTF?". A variable-length parameter list is something that the caller and the callee must agree on, otherwise this can (and will) cause breakage on many ABIs - aarch64 and Power among them. x86_64 is an exception, there it is mostly harmless. Look good to me, ok for mainline. Committed as r15-7817-g21ca9153ebe525b077ac96811cfd48be6b259e7e . Thanks for the review! I will mention the new option in changes.html shortly. Best regards Thomas
Re: GCC GSoC 2025: Call for project ideas and mentors
Hello everyone, I am pleased that I can announce that we have been accepted to be a GSoC mentoring organization also in 2025!. This also means that students are now really starting to look at our idea page and so if anyone wants to add a project, it is still possible but we should not delay it much longer. More information is in my call for projects quoted below. Thanks to everyone who helped me with this so far. I am very happy that we'll get this chance to attract new contributors this year too. Martin On Wed, Jan 29 2025, Martin Jambor wrote: > Hello, > > another year has passed, Google has announced there will be again Google > Summer of Code (GsoC) in 2025 and the deadline for organizations to > apply is already approaching (February 11th). I'd like to volunteer to > be the main org-admin for GCC again but let me know if you think I > shouldn't or that someone else should or if you want to do it instead. > Otherwise I'll assume that I will and I hope that I can continue to rely > on David Edelsohn and Thomas Schwinge to back me up and help me with > some decision making along the way as my co-org-admins. > > The most important bit: > > I would like to ask all (moderately) seasoned GCC contributors to > consider mentoring a contributor this year and ideally also come up > with a project that they would like to lead. We are collecting > proposal on our wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel > free to add yours to the top list there. Or, if you are unsure, post > your offer and project idea as a reply here to the mailing list. > > Additionally, if you have added an idea to the list in the recent years, > please review it whether it is still up-to-date or needs adjusting or > should be removed altogether. > > = > > At this point, we need to collect list of project ideas. Eventually, > each listed project idea should have: > > a) a project title, > b) more detailed description of the project (2-5 sentences), > c) expected outcomes (we do have a catch-almost-all formulation that > outcome is generally patches at the bottom of the list on the > wiki), > d) skills required/preferred, > e) project size - whether it is expected to take approximately 350, > 175 or just 90 hours (see below about the last option), > f) difficulty (easy, hard or medium, but we don't really have easy > projects), and > g) expected mentors. > > Project ideas that come without an offer to also mentor them are always > fun to discuss, by all means feel free to reply to this email with yours > and I will attempt to find a mentor, but please be aware that we can > only use the suggestion it if we actually find one or ideally two. > > Everybody in the GCC community is invited to go over > https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or > otherwise bad project suggestions and help improve viable ones. > > Finally, please continue helping (prospective) students figure stuff out > about GCC like you have always done in the past. > > As far as I know, GSoC 2025 should be quite similar to the last year, > the most important parameters probably are these: > > - Contributors (formerly students) must either be full-time students > or be "beginners to open source." > > - There are now three project sizes: roughly 90 hors (small), roughly > 175 hours (medium-sized) and roughly 350 hours (large) of work in > total. The small option was introduced in 2024 but because our projects > usually have a lengthy learning period, I think we will usually want > to stick to the medium and large variants. > > - Timing should be pretty much as flexible as last year. The > recommended "standard" duration is 12 weeks but depending on > contributor's and mentor's needs and circumstances, projects can > take anywhere between 10 and 22 weeks. There will be one mid-term > and one final evaluation. > > For further details you can see: > > - The announcement of GSoC 2025: > > https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html > > - GSoC rules: > https://summerofcode.withgoogle.com/rules > > - The detailed GSoC 2025 timeline: > https://developers.google.com/open-source/gsoc/timeline > > - Elaborate project idea guidelines: > https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list > > Thank you very much for your participation and help. Let's hope we > attract some great contributors again this year. > > Martin
