Harald Anlauf :
Dear all,
the attached simple and obvious patch fixes an erroneous runtime check
with -fcheck=pointer when passing a non-associated proc-pointer to an
optional dummy.
Regtested on x86_64-pc-linux-gnu. OK for mainline / backports?
Thanks,
Harald
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
Hi Mikael,
Am 10.07.25 um 22:01 schrieb Mikael Morin:
From: Mikael Morin
Hello,
here are three patches as follow-up to this message.
These started as an attempt to remove the PR fortran/108889 workaround,
which I didn't understand.
I had to keep it in the end but this is what I could save fro
lementing optimizations.
If enforcing evaluation of function calls on the source image helps
here, do it. And let us discuss specific examples for optimization
later.
Thanks,
Harald
Regards,
Andre
On Mon, 7 Jul 2025 20:53:16 +0200
Harald Anlauf wrote:
Andre,
I still don't get
my words too much.
NAG:
Runtime Error: array_constructor_1.f90, line 12: ALLOCATABLE LIST is not
currently allocated
Program terminated by fatal error
Aborted
Regards,
Andre
On Tue, 8 Jul 2025 22:17:23 +0200
Harald Anlauf wrote:
Am 05.07.25 um 14:55 schrieb Mikael Morin:
Hello Andr
Am 05.07.25 um 14:55 schrieb Mikael Morin:
Hello Andre,
I get a regression on this testcase with a patch that is otherwise
regression-free.
I think the testcase is invalid.
It does:
type(container), allocatable :: list(:)
list = [list, new_elem(5)]
so it's using the variable 'list
re the code fragment and now only allow pure
*and* elemental intrinsic function and pure *and* elemental user-defined
functions (hoping that's the opposite of intrinsics) in a caf accessor. For all
others a temporary is to be created in the helper structure. I also added a
comment to clarify
erly declared.
Regtest ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
On Tue, 1 Jul 2025 12:54:49 -0700
Jerry D wrote:
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 th
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
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
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,
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.
Reg
Am 27.06.25 um 22:57 schrieb Jerry D:
On 6/27/25 1:48 PM, Harald Anlauf wrote:
Dear all,
my original patch caused a regression on previously working code where
an imported interface was *not* renamed-on-use, as the related new logic
did not expect a local_name to be an empty string.
Funnily
this and regtests fine on x86_64-pc-linux-gnu.
OK for mainline and affected branch(es)?
Thanks,
Harald
From f5589149d5ae434c4c68c77ef0b5dd912da574df Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 27 Jun 2025 22:37:41 +0200
Subject: [PATCH] Fortran: follow-up fix to checking of renamed-on
Am 25.06.25 um 13:45 schrieb Andre Vehreschild:
Hi,
while hunting for pr120711 I found a construct where a call-tree was created
and never used. The patch now just suppresses the tree creation and instead
uses directly the tree that is desired.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for m
Am 25.06.25 um 13:42 schrieb Andre Vehreschild:
Hi,
attached patch prevents generation of a token component in derived types, when
-fcoarray=single is used. Generating the token only wastes memory. It is never
even initialized nor accessed.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainl
Am 25.06.25 um 13:39 schrieb Andre Vehreschild:
Hi all,
attached patch fixes an out of bounds access in the clean up code of a
concatenating array constructor. A fragment like
list = [ list, something() ]
lead to clean up using an offset (of the list array) that was manipulated in
the loop cop
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
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
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
rename
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 genera
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
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
Am 17.06.25 um 21:27 schrieb Harald Anlauf:
Am 17.06.25 um 19:44 schrieb Steve Kargl:
On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote:
On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote:
Am 16.06.25 um 02:18 schrieb Steve Kargl:
Harald,
I did a quick glance at the patch
Am 17.06.25 um 19:44 schrieb Steve Kargl:
On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote:
On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote:
Am 16.06.25 um 02:18 schrieb Steve Kargl:
Harald,
I did a quick glance at the patch and did not see anything that
jumped out as
Am 16.06.25 um 02:18 schrieb Steve Kargl:
Harald,
I did a quick glance at the patch and did not see anything that
jumped out as needing a change. OK to commit.
Earlier today I came to the same conclusion that -1 on overflow is
probably the right thing to do. Gfortran would need a way to
suppl
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
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. (It is
explicitly required only for SOURCE
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
hrieb Harald Anlauf:
Hi Steve,
On 6/11/25 23:06, Steve Kargl wrote:
On Wed, Jun 11, 2025 at 10:18:37PM +0200, Harald Anlauf wrote:
- for the INTEGER(KIND=4) versions the STATUS returns ERANGE if
an overflow is encountered.
The latter is certainly debatable, as one of the existing testcases
stat
Hi Steve,
On 6/11/25 23:06, Steve Kargl wrote:
On Wed, Jun 11, 2025 at 10:18:37PM +0200, Harald Anlauf wrote:
- for the INTEGER(KIND=4) versions the STATUS returns ERANGE if
an overflow is encountered.
The latter is certainly debatable, as one of the existing testcases
stat_{1,2}.f90 may
?
Thanks,
Harald
From 0d283e310b8b4d5bac6a1354168fe3340e89d6d8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 11 Jun 2025 21:25:09 +0200
Subject: [PATCH] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics
[PR82480]
The GNU intrinsics STAT/LSTAT/FSTAT were inherited from g77, but changed
the names of some keywords: FILE
Hi Andre,
On 6/3/25 13:31, Andre Vehreschild wrote:
Hi all,
thanks for the explanations, Christophe. This is very much appreciated. And
sorry, I can't follow all presentations, conferences and publications. There is
meanwhile way too much for me to process out there.
Anyway, the regression I p
: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-temporaries. The cause was that the locus was not
set for the initializer of the symbol for the testcase. The obvious
fix is to then use the
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
Hi Jerry,
On 5/31/25 19:38, Jerry D wrote:
Hi all,
The attached patch fixes a latent issue where we were saving a parsed
and checked format string that had a missing comma. This resulted in the
correct error on the first use of the string, but a missed error on
subsequent uses of the string.
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 simplificati
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
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
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
Hi Jerry!
On 5/28/25 17:11, 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?
This LGTM.
Thanks for the patch!
Harald
Regards,
Jerry
No failures after reverting this:
commit r16-914-g787a8dec1acedf5561c8ee43bed0b3653fca150d
Author: Harald Anlauf
As my daughter would say. It happens to the best of us.
Jerry
--- snip ---
FAIL: gfortran.dg/associate_68.f90 -O0 (test for excess errors)
FAIL: gfortran.dg/associate_68.f90
Hi Jerry!
On 5/27/25 21:36, Jerry D wrote:
On 5/27/25 11:24 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a variety of small issues with parsing of
inquiry references of substrings. The testcase exercises variations
of the examples in the PR and ensures that these are
Hi Jerry!
On 5/27/25 21:02, Jerry D wrote:
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff
linux-gnu. OK for mainline?
I believe this is sufficiently safe that it can be backported
later to 15-branch, unless someone objects.
Thanks,
Harald
From 48a3bb2f5822b0e69211e89bd92fa3d497321f4c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 27 May 2025 19:23:16 +0200
Subject: [
Am 26.05.25 um 18:36 schrieb Steve Kargl:
On Mon, May 26, 2025 at 09:30:59AM +, Yuao Ma wrote:
Hi Steve,
I looked at the patch in a bit more detail, and
I am not thrilled with large-scale whitespace
changes mingled with functional changes. It makes
the patch harder to read and review.
I'
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one thru the other module, which is the reason for
.
Cheers,
Harald
Am 18.05.25 um 23:46 schrieb Jerry D:
On 5/18/25 2:34 PM, Jerry D wrote:
On 5/18/25 2:10 PM, Harald Anlauf wrote:
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly:
print *, c_associated(c_loc(val
Pushed as r16-734-gbf98b735ae01c6 after an off-list OK by Jerry,
and no other responses to the opposite.
Harald
On 5/18/25 22:53, Harald Anlauf wrote:
Dear all,
the attached proposed patch fixes PR120099 by modifying
gfc_return_by_reference so that it returns true with -ff2c
also for
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly:
print *, c_associated(c_loc(val), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR, c_loc(val))
These should get rejected, too. Can you see how to catch these, too?
65d7c6efe51371ba4d0681fc2fa0e732b70b70d7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 18 May 2025 22:42:26 +0200
Subject: [PATCH] Fortran: fix FAIL of gfortran.dg/specifics_1.f90 after
r16-372 [PR120099]
After commit r16-372, testcase gfortran.dg/specifics_1.f90 started to
FAIL at -O2 and higher, as DCE lead to
2025 22:36:19 schrieb Harald Anlauf :
Dear all,
the attached patch fixes missing default-initialization of function
results of derived type that happens under some conditions, see PR.
The logic when default initialization is to be applied is rather
contorted, and reversing the order of two
further would need backporting of other
patches (e.g. to pr98454), so if someone pushes me, I can try.
Let me know what you think.
Cheers,
Harald
From 8a1f2ae8c0ea3a92d9b20f0e678b56583ca4a849 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 15 May 2025 21:07:07 +0200
Subject: [PATCH
Hi Jerry!
Am 10.05.25 um 21:53 schrieb Jerry D:
On 5/10/25 11:33 AM, Harald Anlauf wrote:
Early ping.
Am 06.05.25 um 21:06 schrieb Harald Anlauf:
Dear all,
here's another rather obvious case where a temporary is needed for
an inquiry reference of a complex array which is a component
Early ping.
Am 06.05.25 um 21:06 schrieb Harald Anlauf:
Dear all,
here's another rather obvious case where a temporary is needed for
an inquiry reference of a complex array which is a component of a
derived type. In contrast to PR119986, the argument is handled
within the code fo
Hi Thomas!
Am 10.05.25 um 11:42 schrieb Thomas Koenig:
This bug was another case of generating a formal arglist from
an actual one where we should not have done so. The fix is
straightforward: If we have resolved the formal arglist, we should
not generare a new one.
OK for trunk and backpor
ne
so far as r16-480-g6ce73ad4370c14.
A backport to 15 will follow soon.
Thanks,
Harald
From 4914d9b0ccce843452ab3c921817513441e187ff Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 8 May 2025 22:21:03 +0200
Subject: [PATCH] Fortran: parsing issue with DO CONCURRENT;ENDDO on same
h the present one.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I'd also like to backport this one to 15-branch if this is ok.
Thanks,
Harald
From 981aa53bc258d3c3b75ecdcd33d993346db1fd12 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 6 May 2025 20:59:48 +0200
Subject: [PATC
Hi Jerry, all,
the new logic misses the following bad code:
print *, c_associated(c_loc(val), 42)
This now ICEs here.
I suggest to not 'return true' too early before all arguments
have been checked.
Cheers,
Harald
On 5/6/25 19:15, Jerry D wrote:
On 5/6/25 12:44 AM, Paul Richard Thomas wr
Hi Thomas,
Am 04.05.25 um 12:10 schrieb Thomas Koenig:
Hi Harald,
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved
Thanks
Paul
On Sat, 3 May 2025 at 19:51, Harald Anlauf wrote:
Dear all,
the attached, semi-obvious patch fixes bugging issues with passing of
array subreferences when either an inquiry reference to a complex array
or a substring reference to a character array was involved, and the
array was a
least 15-branch, if this is ok.
Thanks,
Harald
From 8d49cd9e0fe76d2c45495017cb87588e9b9824cf Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 3 May 2025 20:35:57 +0200
Subject: [PATCH] Fortran: array subreferences and components of derived types
[PR119986]
PR fortran/119986
gcc/fo
Hi Thomas,
I haven't tested your patch very thorougly, but when manually
compiling
% gfc-16 gcc/testsuite/gfortran.dg/proc_ptr_52.f90
-Wexternal-argument-mismatch && ./a.out
STOP 1
It appears that something is not right and generates wrong code with
the check enabled. Can you have another lo
Hi Jerry,
Am 24.04.25 um 22:56 schrieb Jerry D:
On 4/24/25 12:59 PM, Harald Anlauf wrote:
Dear all,
the attached patch is the result of my attempts to fix an ICE when
compiling gfortran.dg/proc_ptr_52.f90 with -fcheck=all. While
trying to reduce this, I found several oddities with functions
rs,
Harald
From a6ec26a7d7a92a5e2cefedf08a4616060783050e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 24 Apr 2025 21:28:35 +0200
Subject: [PATCH] Fortran: fix procedure pointer handling with -fcheck=pointer
[PR102900]
PR fortran/102900
gcc/fortran/ChangeLog:
* tra
Hi Andre,
Am 22.04.25 um 15:07 schrieb Andre Vehreschild:
Hi all,
attached patch fixes an illegal use of gfc_current_locus during the
check()-phase of several coarray functions. Instead gfc_current_intrinsic_where
needs to be used.
this is bordering on the obvious and thus OK, except for:
@@
dummy arguments, making this patch very safe.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 5ebb5bb438e8ccf6ea30559604a9f27a75dea0ef Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 15 Apr 2025 20:43:05 +0200
Subject: [PATCH] Fortran: pure subroutine with pure procedu
Hi Thomas!
Am 11.04.25 um 17:50 schrieb Thomas Koenig:
Hello world,
the attached patch fixes an ICE by setting the typespec of a dummy
argument from a global function if known. plus setting the correct flag.
This also removes the corresponding assert. I'm not quite sure that the
code with the
Am 09.04.25 um 04:06 schrieb Jerry D:
On 4/8/25 1:43 PM, Harald Anlauf wrote:
Hi all,
the attached patch fixes a rather strange 12/13/14/15 regression.
When walking through the list of procedures in an interface to
find the matching one, the code could remember an inferred type
from a false
,
Harald
From 468ca59fd29ad629198dc2ada0d73e7898588edc Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 8 Apr 2025 22:30:15 +0200
Subject: [PATCH] Fortran: fix issue with impure elemental subroutine and
interface [PR119656]
PR fortran/119656
gcc/fortran/ChangeLog:
* interface.cc
the original error
was kept.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b17beebd9c7c6475d7f89eef99c0075a562df0b8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 17 Mar 2025 22:34:19 +0100
Subject: [PATCH] Fortran: check type-spec in ALLOCATE of dummy with
Am 28.03.25 um 20:35 schrieb Harald Anlauf:
Dear all,
I am going to commit the attached patch as obvious.
Pushed as r15-9016-gfb132276d17390.
Harald
Dear all,
I am going to commit the attached patch as obvious.
Harald
From 8ea7254f7042582afd4a9dba5a1dd379467f30ff Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 28 Mar 2025 20:31:08 +0100
Subject: [PATCH] Fortran: fix spelling of flag -fallow-invalid-boz
gcc/fortran/ChangeLog
Hi Jabuk!
Am 28.03.25 um 13:42 schrieb Jakub Jelinek:
Hi!
Ok, here is a new version of the patch.
The current behavior in gfortran.dg/ and libgomp.fortran/libgomp.oacc-fortran
is that tests without any dg-do directive are implicitly dg-do compile
and tests with dg-do compile or without dg-do d
Hi Jakub, all,
Am 27.03.25 um 20:04 schrieb Jakub Jelinek:
On Thu, Mar 27, 2025 at 07:34:14PM +0100, Jakub Jelinek wrote:
The following patch runs the test only in the -O3 -g case (just using -O3
there would run it twice, once with
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -
Sam,
who approved the fortran testsuite changes?
Am 27.03.25 um 14:28 schrieb Sam James:
These just fix inconsistent/unusual style to avoid noise when grepping
and also people picking up bad habits when they see it (as similar
mistakes can be harmful).
This one should be reverted. The reason
Hi Andre,
Am 26.03.25 um 22:49 schrieb Andre Vehreschild:
Hi Harald,
looks good to me. Thanks for the patch.
pushed as r15-8945-gb70bd691cfd77b.
Thanks for the swift review!
Harald
- Andre
Andre Vehreschild * ve...@gmx.de
Am 26. März 2025 22:18:41 schrieb Harald Anlauf :
Dear all,
it
From: Harald Anlauf
Date: Wed, 26 Mar 2025 22:04:39 +0100
Subject: [PATCH] Fortran: fix bogus recursion with DT default initialization
[PR118796]
PR fortran/118796
gcc/fortran/ChangeLog:
* resolve.cc: Do not apply default initialization to a derived-type
function result if the resolved
Hi Thomas,
Am 24.03.25 um 22:28 schrieb Thomas Koenig:
Hi Harald,
the attached patch contains a chunk changing resolve.cc
that is neither described in the suggested commit message,
and it fails to compile here:
../../gcc-trunk/gcc/fortran/resolve.cc: In function 'void
check_c_funptr_assign_in
Hi Thomas,
Am 24.03.25 um 21:40 schrieb Thomas Koenig:
Hello world,
the attached patch handles dumping prototypes for C functions returning
function pointers. For the test case
MODULE test
USE, INTRINSIC :: ISO_C_BINDING
CONTAINS
FUNCTION lookup(idx) BIND(C)
type(C_FUNPTR) :: lo
Am 19.03.25 um 23:25 schrieb Steve Kargl:
On Wed, Mar 19, 2025 at 11:08:58PM +0100, Harald Anlauf wrote:
the attached patch addresses an actually very long-standing issue
with bogus bounds checks for components of nested derived types in
assignments when an intermediate level has the POINTER
for mainline?
As this issue leads to wrong code, is it OK to backport
e.g. to 14-branch?
Thanks,
Harald
From 74ef401638194bfc86fec3e78b451445ed86eabe Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 19 Mar 2025 22:56:03 +0100
Subject: [PATCH] Fortran: fix bogus bounds check for
Hi Andre,
Am 17.03.25 um 09:56 schrieb Andre Vehreschild:
The issue is that the tbp (the typebound proc info structure) is not resolved
completely when the associate tries to do an early resolve to determine the
rank of the associate variable. When the expression to be resolved for that
contains
Am 18.03.25 um 00:20 schrieb Jerry D:
On 3/17/25 2:47 PM, Harald Anlauf wrote:
Dear all,
F2003:C626 was only partly implemented: we missed the case of ALLOCATE
of character dummy arguments with assumed length, where the type-spec
must use asterisk, i.e. (*).
Regtesting found one testcase that
Hi Thomas,
Am 15.03.25 um 16:22 schrieb Thomas Koenig:
Hi Harald,
The solution is to use the auxiliary parameter of gfc_traverse_expr
to control whether to descend into character length or not.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
pushed as r15-8079-gb2b13
4fa9af7adb7a828daf39d822bb8c1244b31c3c1c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 15 Mar 2025 15:11:22 +0100
Subject: [PATCH] Fortran: fix bogus dependency check in ALLOCATE statement
[PR60560]
Restrict dependency check of ALLOCATE object to variables in the same
statement, but exclude
, also in the function
from where I plagiated... ;-) after regtesting.
See r15-8040-ga5d56278d145d4 and attached.
Thanks,
Harald
Am 06.03.25 um 23:00 schrieb Steve Kargl:
On Thu, Mar 06, 2025 at 10:49:08PM +0100, Harald Anlauf wrote:
Thanks for the speedy review!
It was a bit easier than
Hi Andre!
Am 11.03.25 um 17:13 schrieb Andre Vehreschild:
Hi all,
attached patch adds parsing of TEAM_NUMBER= named arguments in coindexed
expressions. The patch also ensures that once in an image_selector_list no more
regular coarray indexes are accepted, i.e. coarray[1,2,3, STAT=S, 5] is
reje
Hi Thomas!
Am 11.03.25 um 07:13 schrieb Thomas Koenig:
Hi Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
Thanks for the patch!
Committed as r15-7966-g5e9f71254a5276.
Thanks for the review!
Best regards
Thomas
K for mainline?
Thanks,
Harald
From 7e8f9a0d625f1c66014f71775190218b8ac51e4b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 10 Mar 2025 22:24:27 +0100
Subject: [PATCH] Fortran: reject SAVE of a COMMON in a BLOCK construct
[PR119199]
PR fortran/119199
gcc/fortran/ChangeLog:
* de
Hi Thomas,
Am 10.03.25 um 21:01 schrieb Thomas Koenig:
Hello world,
the attached patch makes sure that procedures from abstract
interfaces and dummy arguments are not put into the global
symbol table, and are not checked against global symbols.
Regression-tested. OK for trunk?
Best regards
Hi Steve,
Am 06.03.25 um 22:32 schrieb Steve Kargl:
On Thu, Mar 06, 2025 at 10:04:08PM +0100, Harald Anlauf wrote:
this patch fixes an interesting regression that prevented substring
bounds checks from being generated if the substring start was not a
variable, but rather a constant or an
and
link to the current discussion on the ML so that your arguments
are properly tracked. Especially if the discussion and the solution
takes a little longer.
Or you do think your patch makes anything worse?
Thanks,
Harald
Regards,
Andre
On Wed, 5 Mar 2025 20:53:37 +0100
Harald Anl
expression being used needs scanning for
implied-do indices. See attached patch for details.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From c100ca04bb5b540732837d92f67529212a7c0899 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 6 Mar 2025 21:45:42 +0100
Subject
Hi Andre,
Jerry already OK'ed your patch, but:
Am 05.03.25 um 15:34 schrieb Andre Vehreschild:
This fixes the PR, but not really the problem, because when say a
obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I don't
have a solution for that error. It might be needed to
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.
Re
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 exter
6b9f74b767 .
Thanks for the review!
Harald
Besides that: Looks good to me.
Regards,
Andre
On Sun, 2 Mar 2025 22:35:47 +0100
Harald Anlauf wrote:
Dear all,
due to an oversight in the Fortran standard before 2018,
empty derived types with bind(C) attribute were explicitly
(delibera
Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 2 Mar 2025 22:20:28 +0100
Subject: [PATCH] Fortran: reject empty derived type with bind(C) attribute
[PR101577]
PR fortran/101577
gcc/fortran/ChangeLog:
* symbol.cc (verify_bind_c_derived_type): Generate error message
for derived type with no
Am 01.03.25 um 19:20 schrieb Steve Kargl:
On Sat, Mar 01, 2025 at 03:56:21PM +0100, Harald Anlauf wrote:
the attached patch fixes a front-end memleak that is seen when
running f951 under valgrind and while parsing invalid uses of
NULLIFY.
I had this in my tree for some time without any
1 - 100 of 1115 matches
Mail list logo
