Re: [Fortran, Patch, PR120843, v2] Fix reject valid, because of inconformable coranks
Hi all,
here now the version of the patch that seems to be more complete.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline and later backport to
gcc-15?
Regards,
Andre
On Fri, 27 Jun 2025 15:44:20 +0200
Andre Vehreschild wrote:
> I take this patch back. It seems to be incomplete.
>
> - Andre
>
> On Fri, 27 Jun 2025 14:45:36 +0200
> Andre Vehreschild wrote:
>
> > Hi all,
> >
> > this patch fixes a reject valid when the coranks of two operands do not
> > match and no coindex is given. I.e. when only an implicit this_image co-ref
> > is used.
> >
> > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
> >
> > Regards,
> > Andre
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 427ab489cefe47b801a29e0642d2eedc20474053 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 27 Jun 2025 14:39:13 +0200
Subject: [PATCH] Fortran: Fix non-conformable corank on this_image ref
[PR120843]
PR fortran/120843
gcc/fortran/ChangeLog:
* resolve.cc (resolve_operator): Report inconsistent coranks
only when not referencing this_image.
(gfc_op_rank_conformable): Treat coranks as inconformable only
when a coindex other then implicit this_image is used.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/coindexed_6.f90: New test.
---
gcc/fortran/resolve.cc | 7 ---
.../gfortran.dg/coarray/coindexed_6.f90 | 17 +
2 files changed, 21 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/coarray/coindexed_6.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 58f7aee29c3..50a6fe7fc52 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -4828,7 +4828,8 @@ resolve_operator (gfc_expr *e)
if (e->shape == NULL)
e->shape = gfc_copy_shape (op2->shape, op2->corank);
}
- else
+ else if ((op1->ref && !gfc_ref_this_image (op1->ref))
+ || (op2->ref && !gfc_ref_this_image (op2->ref)))
{
gfc_error ("Inconsistent coranks for operator at %L and %L",
&op1->where, &op2->where);
@@ -6070,8 +6071,8 @@ gfc_op_rank_conformable (gfc_expr *op1, gfc_expr *op2)
gfc_expression_rank (op2);
return (op1->rank == 0 || op2->rank == 0 || op1->rank == op2->rank)
- && (op1->corank == 0 || op2->corank == 0
- || op1->corank == op2->corank);
+ && (op1->corank == 0 || op2->corank == 0 || op1->corank == op2->corank
+ || (!gfc_is_coindexed (op1) && !gfc_is_coindexed (op2)));
}
/* Resolve a variable expression. */
diff --git a/gcc/testsuite/gfortran.dg/coarray/coindexed_6.f90 b/gcc/testsuite/gfortran.dg/coarray/coindexed_6.f90
new file mode 100644
index 000..8f5dcabb859
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/coindexed_6.f90
@@ -0,0 +1,17 @@
+!{ dg-do compile }
+
+! Check PR120843 is fixed
+
+program p
+ implicit none
+
+ integer, allocatable :: arr(:,:) [:,:]
+ integer :: c[*]
+
+ c = 7
+
+ allocate(arr(4,3)[2,*], source=6)
+
+ if (arr(2,2)* c /= 42) stop 1
+
+end program p
--
2.50.0
Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.
Andre,
I've never built gcc for aarch64-freebsd. I was going to
suggest doing the full bootstrap, but that seems to be too
slow. On amd64, I use
../gcc/configure --prefix=$WDIR \
--enable-languages=c,c++,fortran,lto \
--enable-bootstrap \
--disable-nls \
--disable-libssp \
--disable-multilib \
--without-libintl
I looked at the FreeBSD ports collection and how it builds
gcc16. I did not see missing --enable-* or --disable-*.
If you have the ports collection installed in the vm, you
can do
cd /usr/ports/lang/gcc16-devel
make config |& tee logfile
to see if the port is doing anything to mitigate the issue.
Note, you might need 'make configure'. This likely a slow
process as it downloads the source code and computes a md5
and then uncompresses.
(more below)
On Mon, Jun 30, 2025 at 03:40:33PM +0200, Andre Vehreschild wrote:
>
> how to you get a recent gcc compile on aarch64-freebsd-14.3 ? I am seeing
> several issues in core libraries of gcc that are far away from where I touched
> the compiler.
>
> I am configuring with:
>
> configure --disable-multilib\
>--enable-stage1-languages=c,fortran,c++\
>--enable-checking=yes \
>--enable-offload-defaulted \
>--prefix="${INSTALLPATH}" \
>CFLAGS="-g -O0 -DENABLE_ASSERT_CHECKING" CXXFLAGS="-g
> -O0"\
>STAGE1_CFLAGS="-g -O0 -DENABLE_ASSERT_CHECKING"
> STAGE1_CXXFLAGS="-g -O0"
>
> Yes, I am doing only stage1. I run this fully virtualized and it is slow. I
> don't want to wait three days for a full bootstrap.
>
> One of the errors I get is:
>
> /libgcc/unwind-dw2-fde-dip.c:69:10: error: 'ElfW' redefined [-Werror]
>69 | # define ElfW __ElfN
> | ^~~~
> In file included from /usr/include/machine/elf.h:45,
> from /usr/include/elf.h:37,
> from /gcc/gcc.test/libgcc/unwind-dw2-fde-dip.c:36:
> /usr/include/sys/elf_generic.h:59:9: note: this is the location of the
> previous
> definition
> 59 | #define ElfW(x) __ElfN(x)
> | ^~~~
>
> Have you ever seen this before and know a way around it?
>
I've not seen this error. elf_generic.h. has the comment
/* Define ElfW for compatibility with Linux, prefer __ElfN() in FreeBSD code */
#define ElfW(x) __ElfN(x)
perhaps, just deleteing the line will allow you to proceed.
--
Steve
Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.
Hi Steve,
how to you get a recent gcc compile on aarch64-freebsd-14.3 ? I am seeing
several issues in core libraries of gcc that are far away from where I touched
the compiler.
I am configuring with:
configure --disable-multilib\
--enable-stage1-languages=c,fortran,c++\
--enable-checking=yes \
--enable-offload-defaulted \
--prefix="${INSTALLPATH}" \
CFLAGS="-g -O0 -DENABLE_ASSERT_CHECKING" CXXFLAGS="-g
-O0"\
STAGE1_CFLAGS="-g -O0 -DENABLE_ASSERT_CHECKING"
STAGE1_CXXFLAGS="-g -O0"
Yes, I am doing only stage1. I run this fully virtualized and it is slow. I
don't want to wait three days for a full bootstrap.
One of the errors I get is:
/libgcc/unwind-dw2-fde-dip.c:69:10: error: 'ElfW' redefined [-Werror]
69 | # define ElfW __ElfN
| ^~~~
In file included from /usr/include/machine/elf.h:45,
from /usr/include/elf.h:37,
from /gcc/gcc.test/libgcc/unwind-dw2-fde-dip.c:36:
/usr/include/sys/elf_generic.h:59:9: note: this is the location of the previous
definition
59 | #define ElfW(x) __ElfN(x)
| ^~~~
Have you ever seen this before and know a way around it?
Regards,
Andre
On Sun, 29 Jun 2025 22:02:38 -0700
Steve Kargl wrote:
> On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote:
> > On Sun, Jun 29, 2025 at 03:30:21PM -0700, Steve Kargl wrote:
> > > On Sun, Jun 29, 2025 at 11:07:31AM -0700, Steve Kargl wrote:
> > > > On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote:
> > > > >
> > > > > === gfortran Summary ===
> > > > >
> > > > > # of expected passes73149
> > > > > # of unexpected failures522
> > >
>
> After forcefully adding '#include ', '#include ',
> and 'extern char **environ' where needed. I now see
>
> === gfortran Summary ===
>
> # of expected passes73561
> # of unexpected failures110
> # of expected failures 343
> # of unresolved testcases 78
> # of unsupported tests 94
>
> for 'gmake check-fortran', and if I use RUNTESTFLAGS='dg.exp=\*unsign\*'
> to test the unsigned issue reported earlier, I see
>
> === gfortran Summary ===
>
> # of expected passes434
> # of unsupported tests 6
> /home/kargl/gcc/obj/gcc/gfortran version 16.0.0 20250629 (experimental)
> (GCC)
>
> I suspect we'll need to have
>
> #include "config.h"
>
> #indef HAVE_UNISTD_H
> #include
> #endif
>
> and similar for other headers files. I further suspect that this
> are going to be rough on CYWIN/MINGW.
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, PR120846, v1] Fix ICE when a function is called more than once in a coarray expression.
Am 30.06.25 um 15:29 schrieb Andre Vehreschild: Hi all, attached patch fixes an ICE when in an expression with a coindex a function was used more than once. E.g. coarray(mod( something ), mod( something else ))[i] ICE'd because a component for aliasing the second mod() could not be created. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline and gcc-15 later on? Regards, Andre Yes, this is OK for both. (Be careful about PR numbers, they are correct in the patch; the subject is off-by-one.) Thanks for the patch! Harald
[Fortran, Patch, PR120846, v1] Fix ICE when a function is called more than once in a coarray expression.
Hi all,
attached patch fixes an ICE when in an expression with a coindex a function was
used more than once. E.g. coarray(mod( something ), mod( something else ))[i]
ICE'd because a component for aliasing the second mod() could not be created.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline and gcc-15 later on?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From e4d4dd9768f7797e30542ec99b16093a663c65f3 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 27 Jun 2025 15:31:21 +0200
Subject: [PATCH] Fortran: Ensure arguments in coarray call get unique
components in add_data [PR120847]
PR fortran/120847
gcc/fortran/ChangeLog:
* coarray.cc (check_add_new_comp_handle_array): Make the count
of components static to be able to create more than one. Create
an array component only for array expressions.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/coindexed_7.f90: New test.
---
gcc/fortran/coarray.cc| 4 ++--
.../gfortran.dg/coarray/coindexed_7.f90 | 24 +++
2 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/coarray/coindexed_7.f90
diff --git a/gcc/fortran/coarray.cc b/gcc/fortran/coarray.cc
index 2f067f855e5..6914697c78b 100644
--- a/gcc/fortran/coarray.cc
+++ b/gcc/fortran/coarray.cc
@@ -503,7 +503,7 @@ check_add_new_comp_handle_array (gfc_expr *e, gfc_symbol *type,
gfc_symbol *add_data)
{
gfc_component *comp;
- int cnt = -1;
+ static int cnt = -1;
gfc_symtree *caller_image;
gfc_code *pre_code = caf_accessor_prepend;
bool static_array_or_scalar = true;
@@ -566,7 +566,7 @@ check_add_new_comp_handle_array (gfc_expr *e, gfc_symbol *type,
else
{
comp->initializer = gfc_copy_expr (e);
- if (e_attr.dimension)
+ if (e_attr.dimension && e->rank)
{
comp->attr.dimension = 1;
comp->as = get_arrayspec_from_expr (e);
diff --git a/gcc/testsuite/gfortran.dg/coarray/coindexed_7.f90 b/gcc/testsuite/gfortran.dg/coarray/coindexed_7.f90
new file mode 100644
index 000..066397024f4
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/coindexed_7.f90
@@ -0,0 +1,24 @@
+!{ dg-do compile }
+
+! Check PR120847 is fixed.
+
+program p
+ implicit none
+
+ type T
+integer, allocatable :: i(:, :) [:]
+ end type T
+
+ type(T) :: o
+ integer, allocatable :: c[:]
+ integer :: i
+
+ c = 7
+
+ allocate(o%i(4, 5)[*], source=6)
+
+ do i = 1, 4
+c = o%i(mod(i, 2), mod(i, 3))[1]
+ end do
+
+end program p
--
2.50.0
Re: [Fortran, Patch, PR120843, v2] Fix reject valid, because of inconformable coranks
Am 30.06.25 um 15:25 schrieb Andre Vehreschild: Hi all, here now the version of the patch that seems to be more complete. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline and later backport to gcc-15? This looks good to me. OK for both. Thanks for the patch! Harald Regards, Andre On Fri, 27 Jun 2025 15:44:20 +0200 Andre Vehreschild wrote: I take this patch back. It seems to be incomplete. - Andre On Fri, 27 Jun 2025 14:45:36 +0200 Andre Vehreschild wrote: Hi all, this patch fixes a reject valid when the coranks of two operands do not match and no coindex is given. I.e. when only an implicit this_image co-ref is used. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre
