Hi Andre,
Am 18.07.25 um 21:41 schrieb Andre Vehreschild:
Hi Harald,
that looks fine to me. Ok to commit and backport. Thanks for the patch.
pushed as r16-2355-g8f9450505f8244 so far.
Thanks for the review!
Harald
- Andre
Andre Vehreschild * ve...@gmx.de
Am 18. Juli 2025 21:19:00 schrieb
Hi Harald,
that looks fine to me. Ok to commit and backport. Thanks for the patch.
- Andre
Andre Vehreschild * ve...@gmx.de
Am 18. Juli 2025 21:19:00 schrieb Harald Anlauf :
Dear all,
the attached simple and obvious patch fixes an erroneous runtime check
with -fcheck=pointer when passing a no
Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 18 Jul 2025 21:12:03 +0200
Subject: [PATCH] Fortran: fix bogus runtime error with optional procedure
argument [PR121145]
PR fortran/121145
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): Do not create pointer
check for
Le 16/07/2025 à 00:05, Steve Kargl a écrit :
On Sun, Jul 13, 2025 at 10:59:32AM +0200, Mikael Morin wrote:
Regression tested on x86_64-pc-linux-gnu.
OK for master?
Yes, with one observation below.
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1561936daf1..af62e
On Sun, Jul 13, 2025 at 10:59:32AM +0200, Mikael Morin wrote:
>
> Regression tested on x86_64-pc-linux-gnu.
> OK for master?
>
Yes, with one observation below.
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
> index 1561936daf1..af62e17442b 100644
> --- a/gcc/fortran/tran
OK Paul, thanks. We probably ought to back port it to 15
On Tue, Jul 15, 2025, 9:22 AM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> At first this PR looked as if it was going to be one of those horrible
> typebound procedure/operator tangles. However, it turned out that this was
At first this PR looked as if it was going to be one of those horrible
typebound procedure/operator tangles. However, it turned out that this was
entirely down to the attempt to extract the specific procedure for the
ASSOCIATE name during parsing. Returning NULL before expression resolution
fixed
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Save subexpressions of array descriptor references to variables, so that
all the expressions using the descriptor as base object benefit from a
simplified reference using the variables.
This limits the size of the expressions gen
On 7/11/25 10:36 PM, Tobias Burnus wrote:
Now, finally pushed as r16-2213-g451b6dbf475959.
Tobias
On June 27, 2025, Tobias Burnus wrote:
Background: In real-world code, one can find:
!$ACC DECLARE COPYIN(c1es, c2es, ...)
as here for the ICON weather model. This clearly implies that other
co
Now, finally pushed as r16-2213-g451b6dbf475959.
Tobias
On June 27, 2025, Tobias Burnus wrote:
Background: In real-world code, one can find:
!$ACC DECLARE COPYIN(c1es, c2es, ...)
as here for the ICON weather model. This clearly implies that other
compilers accept and, potentially, require th
On 7/10/25 2:27 AM, Andre Vehreschild wrote:
Hi all,
after Jerry had the idea to use OpenCoarray's tests to also test
caf_shmem, a few issue arose. Those have been fixed now in the updated
patch-series.
I have put all patches into one mail to allow the CIs to pick them all
up and hopefully test
Thanks, Jerry.
Pushed as r16-2189. Note however that s/pr106135/pr106035 is required
throughout. I will attend to it tomorrow.
Paul
On Mon, 23 Jun 2025 at 19:27, Jerry D wrote:
> On 6/23/25 9:43 AM, Paul Richard Thomas wrote:
> > Hello All,
> >
> > I was mulling over the F2018 status of gfort
Am 10.07.25 um 11:27 schrieb Andre Vehreschild:
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Did you run extensive tests on all potential race conditions,
and fix the resulting fallout?
If you did, please post your test cases and the results. Otherwise,
https://gcc.gnu.org/piperm
Hi Jerry,
good you could build Toon's code.
Your idea of using the OpenCoarray tests to test caf_shmem made me think about
how to do it the easiest.
I came up with the following:
1. Pull a recent OpenCoarray source tree from Github or use a clean existing
one.
2. Apply attached patch.
3. Crea
Paul,
Either resolve.cc has sufficiently evolved since you
submitted your patch or the patch is somehow mangled.
When I apply it to my tree for resolve.cc, I see
Hunk #1 succeeded at 3919.
Hunk #2 succeeded at 4223.
Hunk #3 succeeded at 7940 (offset -28 lines).
Hunk #4 succeeded at 8068 (offset
On 7/4/25 5:12 AM, Andre Vehreschild wrote:
Hi all,
attached patches goes on top of other 6 caf_shmem coarray patches and fixes
missing includes esp. on non-Linux systems. I have tested this on a FreeBSD,
which is very time consuming due to it being fully virtualized on my system.
Regtests ok o
Andre,
either your patch to coarray.cc is wrong, or the comment in the code
is not concise, or I am too dense to understand the intent of the
change:
diff --git a/gcc/fortran/coarray.cc b/gcc/fortran/coarray.cc
index ef8fd4e42d0..01aac581a74 100644
--- a/gcc/fortran/coarray.cc
+++ b/gcc/fortran/
Am 04.07.25 um 14:12 schrieb Andre Vehreschild:
Regtests ok on x86_64-pc-linux-gnu and aarch64-unknown-freebsd14.3. Ok for
mainline?
The whole patch set needs including the library needs rigorous and
extensive testing against race conditions, as outlined in
https://gcc.gnu.org/pipermail/fortran
+0200
Subject: [PATCH] Fortran: Fix includes in caf_shmem (esp. for BSDs) [PR88076]
PR fortran/88076
libgfortran/ChangeLog:
* caf/shmem.c: Remove declaration of environment.
* caf/shmem/allocator.h: Fix required includes.
* caf/shmem/hashmap.h: Same.
* caf/shmem/shared_memory.h: Same.
* caf
,
> > Harald
> >
>
> Yes, OK, straight-forward.
>
> Thanks,
>
> Jerry
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 4b9181aab9fc1b3982724a442b19c69458459b5f Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 4 Jul 2025 11:26:
On Thu, Jul 03, 2025 at 10:12:52PM +0200, Mikael Morin wrote:
> From: Mikael Morin
>
> Regression-tested on aarch64-unknown-linux-gnu.
> OK for master?
>
Yes. Almost looks obvious once someone finds and fixes the issue.
Thanks for the patch.
--
Steve
From: Mikael Morin
Regression-tested on aarch64-unknown-linux-gnu.
OK for master?
-- >8 --
Add the preliminary code produced for the evaluation of the FROM and TO
arguments of the MOVE_ALLOC intrinsic before using their values.
Before this change, the preliminary code was ignored and dropped,
l
Am 01.07.25 um 21:54 schrieb Jerry D:
On 7/1/25 12:51 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes the following minor issues found by running
f951 under valgrind for the just added new testcases coindexed_6.f90
and coindexed_7.f90:
- minor front-end memleaks with non-freed stri
On 7/1/25 12:51 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes the following minor issues found by running
f951 under valgrind for the just added new testcases coindexed_6.f90
and coindexed_7.f90:
- minor front-end memleaks with non-freed strings and lost GMP variables
(these are
2001
From: Harald Anlauf
Date: Tue, 1 Jul 2025 21:41:53 +0200
Subject: [PATCH] Fortran: fix minor issues with coarrays
gcc/fortran/ChangeLog:
* coarray.cc (check_add_new_component): Treat pure and elemental
intrinsic functions the same as non-intrinsic ones.
(create_caf_add_data_parameter_type
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 \
--disa
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++\
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:
> > > >
> > > > === gfortr
Yet, another head scratcher.
../../../gcc/libgfortran/caf/shmem/supervisor.c:235:27: error: 'environ'
undeclared (first use in this function)
235 | for (char **e = environ; *e; ++e, ++n)
| ^~~
I see 'extern char **environ;' in shmem.c. Is this sup
On Sun, Jun 29, 2025 at 07:06:57PM -0700, Steve Kargl wrote:
> On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote:
> >
> > /usr/local/bin/ld: cannot find -lcaf_shmem: No such file or directory
> > collect2: error: ld returned 1 exit status
> > compiler exited with status 1
> >
> > The fre
On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote:
>
> /usr/local/bin/ld: cannot find -lcaf_shmem: No such file or directory
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
>
> The freshly built gfortran cannot find the libcaf_shmem.a.
>
% find . -name \*li
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
> > >
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
It seems that something is mucking wi
On Sun, Jun 29, 2025 at 08:36:38PM +0200, Andre Vehreschild wrote:
>
> I would do git am pr88076_v1_1.patch or patch -p1 each of the patch files. Then they go where they ought to be.
Thanks. I needed -p1 for v1_5 and v1_6.
> Pro tip: create a new branch before doing the git am, then you can ju
Hi Steve,
I would do git am pr88076_v1_1.patch or patch -p1 each of the patch files. Then they go where they ought to be.
Pro tip: create a new branch before doing the git am, then you can just
switch back to master when desired.
- Andre
Andre Vehreschild * ve...@gmx.de
Am 29. Juni 2025 20:2
On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote:
>
> Just applied the 6 patch (with the update part 5). I'm
> seeing a significant increase in the number of failures
> in 'make check-fortran' testing.
>
Just re-applied your patches in the top-level gcc/ directory.
I was expecting mo
On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote:
>
> === gfortran Summary ===
>
> # of expected passes73149
> # of unexpected failures522
> # of expected failures 343
> # of unresolved testcases 78
> # of unsupported tests 94
On Thu, Jun 26, 2025 at 10:15:01AM +0200, Andre Vehreschild wrote:
>
> I deem this library fit for educational and research use,
> where small to medium sized problems are researched. I do
> not expect it to support a long term running application,
> because is does not join adjacent blocks in th
On Tue, Jun 24, 2025 at 03:09:33PM +0200, Andre Vehreschild wrote:
>
> this series of patches (six in total) adds a new coarray backend library to
> libgfortran. The library uses shared memory and processes to implement
> running multiple images on the same node. The work is based on work starte
Background: In real-world code, one can find:
!$ACC DECLARE COPYIN(c1es, c2es, ...)
as here for the ICON weather model. This clearly implies that other
compilers accept and, potentially, require those. For better
compatibility with real-world use, the just released OpenACC 3.4 now
permits PARAME
Hi Jerry,
for the moment only the static library is configured in the build scripts.
Therefore only that is build named libcaf_shmem.a That's completely correct
and desired.
I have asked the same question about performance or stress tests and got
only the coarray_icar (link in the 0/6 mail).
On 6/26/25 12:22 AM, Andre Vehreschild wrote:
Hi Jerry,
thanks for testing. I have fixed IMO most of the whitespace issues in the
patch attached to this mail:
https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html
About the 32 vs. 64 bit versions of the libraries: I never got in touch with
Hi Andre,
I used a clean build directory but don't recall if I reconfigured. I was 10
minutes away from leaving for the airport! I'll try again when I am back at
base.
Please, everyone else, don't hesitate to review and test.
Regards
Paul
On Tue, 24 Jun 2025, 23:47 Andre Vehreschild, wrote:
Hi Thomas,
> I have a few questions.
>
> First, I see that your patch series does not use gfortran's descriptors
> for accessing coarrays via shared memory, as the original work by
> Nicolas did. Can you comment on that?
The ABI for invoking coarray functionality is sufficient for doing the job
Hi Jerry,
thanks for testing. I have fixed IMO most of the whitespace issues in the
patch attached to this mail:
https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html
About the 32 vs. 64 bit versions of the libraries: I never got in touch with
that. I am doing the same as for caf_single. In
Hi all,
fix incorrect declarations in the libcaf.h header and use the correct printf
function when printing a va_list. (The latter is stripped into a separate file
by the next patch of this series.)
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehre
On 6/24/25 11:49 PM, Andre Vehreschild wrote:
Hi Jerry,
thank you very much. Just try it. I can only imagine that Paul had a somehow
corrupted build directory or left overs from some previous build. I am still
wondering, that I got no automated mail from the build hosts, but I can
imagine, that
Andre,
this series of patches (six in total) adds a new coarray backend library to
libgfortran. The library uses shared memory and processes to implement
running multiple images on the same node. The work is based on work started by
Thomas and Nicolas Koenig. No changes to the gfortran compile
Hi all,
this patch fixes handling of optional arguments to coarray routines. Again I
stumbled over this while implementing caf_shmem. I did not find a ticket either.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot
If gfortran will have a shared-memory coarray implemented, it would be
great to also drop the requirement to pass -fcoarray. Other compilers
have trended in the direction of dropping the flag too, including Cray and
NAG.
Even all these years after Fortran 2008 introduced multi-image execution, I
Hi all,
this patch fixes setting the coarray bounds correctly when a scalar char array
(i.e. CHARACTER(len=N)) is passed to function expecting a coarray. And when a
derived type coarray is passed to a function expecting a polymorphically typed
coarray as argument.
Regtests ok on x86_64-pc-linux-
Andre,
I assumed that there would be some overhead, and perhaps bloat,
if -fcoarray=single were made the default. With the introduction
of a shmem runtime, changing the default is likely a GCC 17 change
and not something we should pursue for GCC 16.
Yes, I know that this uses shmem and not MPI.
Hi Jerry,
thank you very much. Just try it. I can only imagine that Paul had a somehow
corrupted build directory or left overs from some previous build. I am still
wondering, that I got no automated mail from the build hosts, but I can
imagine, that they get issues with a series of patches, that b
Giving something new time to mature before making it the default is always
a great policy. My suggestion is aspirational. I’m describing a dream that
I hope can be the ultimate goal. There’s no need to rush into implementing
my proposed vision.
D
On Tue, Jun 24, 2025 at 23:25 Andre Vehreschild
Hi Damian, hi Steve,
enabling coarray-support by default has implications we need to consider. The
memory footprint of a coarray enabled program is larger than the one of a
non-coarray one. This is simply because the coarray token needs to be stored
somewhere.
Furthermore, I just yesterday figure
rald
From 5bc92717b804483a17dd5095f8b6d4fd75a472b1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 24 Jun 2025 20:46:38 +0200
Subject: [PATCH] Fortran: fix ICE in verify_gimple_in_seq with substrings
[PR120743]
PR fortran/120743
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_substring): Substring indi
Hi all,
this series of patches (six in total) adds a new coarray backend library to
libgfortran. The library uses shared memory and processes to implement
running multiple images on the same node. The work is based on work started by
Thomas and Nicolas Koenig. No changes to the gfortran compile
On 6/24/25 6:09 AM, Andre Vehreschild wrote:
Hi all,
this series of patches (six in total) adds a new coarray backend library to
libgfortran. The library uses shared memory and processes to implement
running multiple images on the same node. The work is based on work started by
Thomas and Nico
Hi Andre,
All six patches require git apply --whitespace=fix --ignore-space-change <
~/prs/Shared_Memory/pr88076_v1_x.patch to apply.
The build fails with:
Makefile:3848: caf/.deps/caf_error.Plo: No such file or directory
make[2]: *** No rule to make target 'caf/.deps/caf_error.Plo'. Stop.
make
Am 24.06.25 um 21:11 schrieb Steve Kargl:
On Tue, Jun 24, 2025 at 09:00:46PM +0200, Harald Anlauf wrote:
here's an obvious fix for a recent regression: substring offset
calculations used a wrong type that crashed in gimplification.
Andre basically OK'ed it in the PR, but here it is nevertheless
On Tue, Jun 24, 2025 at 09:00:46PM +0200, Harald Anlauf wrote:
>
> here's an obvious fix for a recent regression: substring offset
> calculations used a wrong type that crashed in gimplification.
> Andre basically OK'ed it in the PR, but here it is nevertheless.
>
> Regtested on x86_64-pc-linux-g
Damian,
I submitted a patch a long time ago to make -fcoarray=single the
default behavior. The patch made -fcoarray=none a NOP. With
inclusion of a shmem implementation of the runtime parts, this
might be the way to go. I'll leave that decision to Andre, Thomas,
and Nicolas.
I believe that the
This patch adds the OpenACC routines acc_attach and acc_detach.
However, in order to avoid the generation of a temporary, which
breaks this feature, a special case had to be added to
gfc_trans_call.
Otherwise, I think it completes the Fortran additions of existing
C/C++ functions, by adding this
Hi all,
this small patch unifies handling of the optional team argument to
failed_/stopped_images(). I did not find a ticket for this, but stumbled over
it while implementing caf_shmem.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Kreu
Hi all,
this is the last patch of the mini-series. It just updates the testcases common
to coarrays in the gfortran testsuite. All tests in the
gcc/testsuite/gfortran.dg/caf directory are now also run with caf_shmem. The
test driver ensures, that no more than 8 images are used per testcase (if not
On 6/23/25 9:43 AM, Paul Richard Thomas wrote:
Hello All,
I was mulling over the F2018 status of gfortran, when I came across the
additions to the IMPORT statement. This seemed like such a useful
addition to fortran that I set about an implementation; thinking that
this would be low hanging f
On 6/23/25 12:39 PM, Harald Anlauf wrote:
Dear all,
here's an obvious fix for a rejects-valid when an interface was
renamed on use and is extended in the importing module. One check
incorrectly referred to the original interface name, not the
renamed one.
Regtested on x86_64-pc-linux-gnu. OK
Am 23.06.25 um 22:33 schrieb Jerry D:
On 6/23/25 12:39 PM, Harald Anlauf wrote:
Dear all,
here's an obvious fix for a rejects-valid when an interface was
renamed on use and is extended in the importing module. One check
incorrectly referred to the original interface name, not the
renamed one.
Hi Mikael!
Am 23.06.25 um 19:51 schrieb Mikael Morin:
Le 22/06/2025 à 21:09, Harald Anlauf a écrit :
Hi Mikael!
Am 20.06.25 um 12:08 schrieb Mikael Morin:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
Ok for master?
-- >8 --
The temporary variables that are generated to
arald
From 69c64f3e21b9702d19a833534f2f8621845b5c98 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 23 Jun 2025 21:33:40 +0200
Subject: [PATCH] Fortran: fix checking of renamed-on-use interface name
[PR120784]
PR fortran/120784
gcc/fortran/ChangeLog:
* interface.cc (gfc_match_end_inte
Le 22/06/2025 à 21:09, Harald Anlauf a écrit :
Hi Mikael!
Am 20.06.25 um 12:08 schrieb Mikael Morin:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
Ok for master?
-- >8 --
The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (befo
Hello All,
I was mulling over the F2018 status of gfortran, when I came across the
additions to the IMPORT statement. This seemed like such a useful addition
to fortran that I set about an implementation; thinking that this would be
low hanging fruit. Parsing and checking the constraints C897-8100
Hi Mikael!
Am 20.06.25 um 12:08 schrieb Mikael Morin:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
Ok for master?
-- >8 --
The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (before this change) a name depending only
on the typ
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
Ok for master?
-- >8 --
The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (before this change) a name depending only
on the type. This can produce confusing dumps with code having multi
Le 18/06/2025 à 23:50, Thomas Koenig a écrit :
Hi Mikael,
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Just wondering... how does this relate to the recent fix of PR120483
by Andre? Is this also a regression? If so, maybe a backport would be
in order.
Best regads
Thoma
Le 18/06/2025 à 23:22, Jerry D a écrit :
On 6/18/25 2:02 PM, Mikael Morin wrote:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Was there a PR for this? or something you just ran into?
I'm not aware of any PR. I was trying to create a testcase exercising
t
Hi Mikael,
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Just wondering... how does this relate to the recent fix of PR120483
by Andre? Is this also a regression? If so, maybe a backport would be
in order.
Best regads
Thomas
On 6/18/25 2:02 PM, Mikael Morin wrote:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Was there a PR for this? or something you just ran into?
Not a problem either way, just curious.
It looks OK to me. OK for master.
Jerry
-- >8 --
gcc/fortran/ChangeL
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_deferred_array): Statically
initialize deferred length variable for SAVEd character arrays.
gcc/testsuite/ChangeLog:
* gfortran.d
The was_finalized tracking mechanism was introduced in commit 1af22e4 to
prevent duplicate finalization of the same expression+component combination
within a namespace. However, this mechanism had a flaw: it
stored gfc_expr* pointers that could become stale, leading to use-after-free
bugs and compi
Hi Jerry,
Am 16.06.25 um 00:13 schrieb Jerry D:
On 6/15/25 1:22 PM, Harald Anlauf wrote:
Am 15.06.25 um 21:25 schrieb Harald Anlauf:
Dear all,
the attached patch fixes a rejects-valid: in an ALLOCATE statement with
MOLD= present, if the allocate-object has an explicit-shape-spec, the
compatib
On 6/15/25 1:22 PM, Harald Anlauf wrote:
Am 15.06.25 um 21:25 schrieb Harald Anlauf:
Dear all,
the attached patch fixes a rejects-valid: in an ALLOCATE statement with
MOLD= present, if the allocate-object has an explicit-shape-spec, the
compatibility of ranks is not required by the standard. (
ranch?
Thanks,
Harald
Harald
From 7194cdde73ed2b2c6ad6bc1a200a9f508c9659fa Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 15 Jun 2025 21:09:28 +0200
Subject: [PATCH] Fortran: fix checking of MOLD= in ALLOCATE statements
[PR51961]
In ALLOCATE statements where the MOLD= argument is presen
Dear all,
the attached patch fixes a rejects-valid: in an ALLOCATE statement with
MOLD= present, if the allocate-object has an explicit-shape-spec, the
compatibility of ranks is not required by the standard. (It is
explicitly required only for SOURCE=).
Since this could surprise users, we emit
Hi Yuao,
Yuao Ma wrote:
Fixed in this patch. Thinking about tex is always a pain...
> Additionally, I think all "half-revolutions" should be "half
revolutions"
Thanks! I have another nit:
* intrinsic.texi: Add new doc. Reorder doc for atand.
The first part is not really clear. I hav
Hi Yuao,
Yuao Ma wrote:
This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this
patch, we
add intrinsic documentation for the newly added trig functions with
half-revolutions. We also reorder the documentation for `atand` to
place it in
correct alphabetical order.
When I try to
Hi all,
This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this patch, we
add intrinsic documentation for the newly added trig functions with
half-revolutions. We also reorder the documentation for `atand` to place it in
correct alphabetical order.
BR,
Yuao
0001-fortran-add-intrin
Hi Harald,
Lgtm. That patch is nearly obvious. Ok for trunk and backport.
Thanks for the patch,
Andre
Andre Vehreschild * ve...@gmx.de
Am 3. Juni 2025 20:43:52 schrieb Harald Anlauf :
Dear all,
here's a fix for another one of Gerhard's "torture tests" that triggers
an ICE with -Warray-tempor
Hi Andre,
On 6/3/25 21:03, Andre Vehreschild wrote:
Hi Harald,
Lgtm. That patch is nearly obvious. Ok for trunk and backport.
Thanks for the patch,
Andre
thanks for the swift review!
Pushed as r16-1090-g0768ec0d32f570.
Thanks,
Harald
Andre Vehreschild * ve...@gmx.de
Am 3. Juni 2025 20:43
or generated for
the data values.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b8c58ba3e8113cb05a45e8263dfd60726e173e68 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 3 Jun 2025 20:30:30 +0200
Subject: [PATCH] Fortran: ICE due to missing locus with data st
On 5/30/25 19:44, Steve Kargl wrote:
On Fri, May 30, 2025 at 07:37:49PM +0200, Harald Anlauf wrote:
here's a patch fixing the handling of parameter inquiries of
constant complex arrays. It profits from previous fixes for
inquiries of substrings and essentially adds only the simplification
of %
On Fri, May 30, 2025 at 07:37:49PM +0200, Harald Anlauf wrote:
>
> here's a patch fixing the handling of parameter inquiries of
> constant complex arrays. It profits from previous fixes for
> inquiries of substrings and essentially adds only the simplification
> of %re/%im applies to complex arra
to
15-branch with some delay.
Thanks,
Harald
From 1d7fcd242134b99eb1b2642d4aa87d5b95b49e94 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 30 May 2025 19:25:15 +0200
Subject: [PATCH] Fortran: parameter inquiries of constant complex arrays
[PR102599,PR114022]
PR fortran/102599
PR fo
Hello world,
I have just committed the attached patch as obvious and simple
after regression-testing. Will backport to gcc 15 soonish.
This fixes a 15/16 regression where the code was looking at
the typespec of the symbol which we don't set if there is
a RESULT clause.
Thanks to Harald for poin
Hi Tobias and Harald,
I sincerely apologize for the breakage! I did test both preprocessor branches,
but I tested against the same MPFR version (4.2.2, which is the latest on Arch
Linux). Going forward, I will test against versions both above and below 4.2.0
to ensure this type of breakage doesn't
Hi Tobias,
On 5/28/25 22:46, Tobias Burnus wrote:
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3:
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3: error: 'mpfr_fmod_ui'
was not declared in this scop
On 5/28/25 19:51, Tobias Burnus wrote:
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_e
On 5/28/25 10:09 AM, Steve Kargl wrote:
On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Yes, with one question.
commit 845768cbead03f76265e491bcf5ea6de7020
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
1 - 100 of 1839 matches
Mail list logo
