e the required feature is already mostly implemented,
but I just did not see it.)
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Reviewed, applied, regression checked here OK.
make info has no errors and the generated info file looks good.
OK for mainline.
Thanks for the work!
Jerry
and 'the' in between 'if' and
'designator'. ??
Cheers,
Jerry
On 9/4/25 6:22 AM, Paul Richard Thomas wrote:
Hi All,
Although PR87362 is marked as fixed, the error becomes rather more explicit with
this patch, which I actually developed for PR102457.
Regtests on FC42/x86_64 - OK for mainline
Paul
Yes, OK
Swing Away.
Jerry
ewing.
Otherwise regtests fine on x86_64-pc-linux-gnu. OK for trunk/backports?
Thanks,
Harald
Regtests here OK here. Seems simple enough. If you want to wait for Paul
no problem. Otherwise OK by me.
Regards,
Jerry
well. Applied and tested OK.
Thanks much!
Jerry
a long time ago. Using the vptr location is unambiguous.
Regtests (yes, really :-) ) on FC42, x86_64. OK for mainline?
Paul
This is OK, the patch trys to add pdt_41.f90 which existed here already. ???
Tested here OK.
Thanks,
Jerry
?
Thanks,
Harald
OK, and I even tested it. ;)
Regards,
Jerry
On 8/30/25 9:16 AM, Harald Anlauf wrote:
On 8/30/25 18:04, Jerry D wrote:
On 8/30/25 8:04 AM, Paul Richard Thomas wrote:
Hi All,
This patch is only a temporary fix because the chunks in trans-
array.cc are representation dependent. As a whole, the patch is so
straightforward that the
?
Paul
Yes, OK and thanks for the fix.
Regards,
Jerry
would consider this
a gfortran extension for the time being.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Yes, OK Harald.
Thanks for the work.
Jerry
for the patch!
Regards,
Jerry
+ gfortran representation this rather awkward because the two are not
>>>>>>>> ^ is
+ /* Generate this instance using the type parameters using the
+ first argument list and return the parameter list in
+ ctr_arglist. */
the component in a component reference is that
syntax -^^^- ;)
Thanks for patch.
Jerry
The attached patch provides an error with -std=f95 or higher.
Regression tested on x86_64.
OK for trunk?
Regards,
Jerry
Author: Jerry DeLisle
Date: Tue Aug 26 11:36:25 2025 -0700
Fortran: H edit descriptor error with -std=f95
PR fortran/114611
gcc/fortran/ChangeLog
.cc (create_int_parameter_array): Avoid NULL
pointer dereference and enhance error message.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr121627.f90: New test.
On 8/21/25 1:42 PM, Jerry D wrote:
On 8/21/25 12:32 PM, Steve Kargl wrote:
fortran/121627 found an issue with a N
eebsd.
Hello Steve,
This looks reasonable to me and OK for trunk. I will commit for you after I
apply and test on Linux x86_64. (Unless you want to commit yourself)
(I will make sure I git you as author. I forget to do that sometimes.)
Thanks,
Jerry
diff --git a/gcc/fortran/module.cc
On 8/20/25 8:54 AM, Paul Richard Thomas wrote:
Hi Jerry,
The attached patch fixes both pr84122 and pr85942. Beyond the more
elaborate chunk in parse.cc, a new chunk was required in
simplify.cc(get_kind) to convert KIND expressions involving PDT kind
parameters into viable initialization
64. OK for mainline?
Paul
OK with correction as noted.
Thanks Paul,
Jerry
oblem
and regtests on FC42/x86_64.
OK for mainline and some judicious backporting in a while?
Paul
PS It came up automatically on bugzilla, while I was messing with PR1211482.
This latter also fixed pr82753.
Yes, OK and backport. Truly trivial.
Jerry
containing specific type; ie. with different kind parameters. The comments in
the patch explain the workings.
Regtests on FC42/x86_64 - OK for mainline?
Paul
I think this is OK Paul.
Many thanks,
Jerry
errycommit bb9a09fb431bf8e5debf88952725b8d79dfc226c
Author: Jerry DeLisle
Date: Tue Aug 5 12:10:24 2025 -0700
Fortran: Fix runtime bogus diagnostic with ';'
PR libfortran/121234
libgfortran/ChangeLog:
* io/list_read.c (read_character): Add che
With your updated patch addressing Steve's comments OK.
We have time for minor tweaks if necessary.
On 8/3/25 11:06 AM, Steve Kargl wrote:
On Sun, Aug 03, 2025 at 12:20:24PM +0100, Paul Richard Thomas wrote:
First, the easy one:
+ /* Match the binding name; depending on type (operator / gen
for mainline and backport as you see fit.
Regards,
Jerry, stuck in th airport,lol.
On 7/19/25 5:06 PM, Jerry D wrote:
On 7/19/25 2:26 PM, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these
as
Thank you, this helps me to understand better. I will strive to achieve this
kind of testing. Suggestions from others as code samples would be greatly
appreciated.
We should be able to build up a suite of tests to use for validation.
Best Regards,
Jerry
On 7/19/25 10:59 AM, Toon Moene wrote:
On 7/19/25 18:32, Jerry D wrote:
I expanded on Toon's random_weather.f90 test using:
!integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP =
1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240
integer, parameter :: DNX = 1000
On 7/17/25 9:37 PM, Jerry D wrote:
I have created a new gfortran-test branch on gcc here.
origin/devel/gfortran-test
This has the patches applied as needed to do the testing I have done.
When Andre's patches are approved I will revert and rebase this so we can test
the next set of
Yes Ok to push. Thanks. Jerry
On Tue, Jul 15, 2025, 9:44 AM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Dear All,
>
> The failure that Steve mentioned below is fixed. ChangeLogs and patch are
> self-describing.
>
> Regtests fine - OK for mainline?
>
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
bug.cgi?id=121043
Maybe some tests to adjust?
Jerry
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 hope
On 7/7/25 8:39 AM, Andre Vehreschild wrote:
Ping!
OK for mainline.
Thanks,
Jerry
On Thu, 26 Jun 2025 15:32:47 +0200
Andre Vehreschild wrote:
Hi,
I found a bug in the module cleanup expression at the end of the test. In the
attached patch it is corrected.
Regtests ok on x86_64-pc
On 7/2/25 4:12 PM, Jerry D wrote:
On 7/2/25 9:40 AM, Jerry D wrote:
On 7/2/25 3:14 AM, Andre Vehreschild wrote:
Hi all,
I successfully created a big mess with the previous patch. First of all by
applying an outdated one and secondly by adding the conformance checks for
coranks in
does.
Regards,
Jerry
On 7/2/25 9:40 AM, Jerry D wrote:
On 7/2/25 3:14 AM, Andre Vehreschild wrote:
Hi all,
I successfully created a big mess with the previous patch. First of all by
applying an outdated one and secondly by adding the conformance checks for
coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc
needed.
Jerry, Harald: Sorry for all the bother and all my mistakes. I am really sorry
to have wasted your time.
The patch has been regtested fine on x86_64-pc-linux-gnu / F41. Ok for mainline
and later backport to gcc-15?
Regards,
Andre
--- snip ---
With this fixer patch, I can
-forward.
Thanks,
Jerry
in the testsuite...
The attached fixes this and regtests fine on x86_64-pc-linux-gnu.
OK for mainline and affected branch(es)?
Thanks,
Harald
The patch is simple enough. OK for mainline and branches as you think suitable.
Jerry
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
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
ld be appreciated.
Best regards,
Jerry
for mainline?
Paul
I do think the new test case is very thorough. I reviewed that patch for
anything glaring and it looks good. I also tried it on some things here
and got what I expected.
If you and Steve have been in touch I think it is OK for mainline.
Cheers,
Jerry
. OK for mainline / backports?
Thanks,
Harald
Yes, all good. Thanks!
Jerry
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/fort
64-pc-linux-gnu. OK for mainline / 15-branch?
Thanks,
Harald
Yes, looks OK Harald. Thanks.
Jerry
this issue to the list: is
there general agreement to proceed in this direction?
Best,
FX
I agree with Steve, it would be well worth it to have this script so we
can normalize how regeneration gets done. Much appreciated.
Jerry
tested on x86_64
OK for trunk and eventual backport to 15?
Regards,
Jerrycommit 078912fe348838513a9eabd9dfca3e76ff3475df
Author: Jerry DeLisle
Date: Sat May 31 08:57:22 2025 -0700
Fortran: Fix handling of parsed format strings.
Previously parsed strings with errors were being
This was a followup to make the error message a little better.
Committed.
commit c69afa2f1bd7455457ab4e028a6bc51211b2dd20 (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLisle
Date: Thu May 29 10:02:00 2025 -0700
Fortran: Make minor adjustment to error mess
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
Yes, Steve I have it backward. I will fix it before commit.
On Wed, May 28, 2025, 10:15 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 teste
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Regards,
Jerrycommit 845768cbead03f76265e491bcf5ea6de7020ff39
Author: Jerry DeLisle
Date: Wed May 28 07:56:12 2025 -0700
Fortran: Adjust handling of optional
-ext.def: New extensions
* config/riscv/riscv-ext.opt: Auto re-generated
gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.target/riscv/arch-57.c: New test
* gcc/testsuite/gcc.target/riscv/arch-58.c: New test
Signed-off-by: Jerry Zhang Jian
---
gcc/config/riscv/riscv-ext.def | 26
On 5/27/25 2:19 PM, Harald Anlauf wrote:
Jerry, all,
that was entirely my fault - attempting a last-minute cleanup
that reordered code, trying to use a refactoring. I've put
on my brown bag and pushed a corrections as obvious as:
r16-921-g74a2281ae18c6d.
See attached.
Caveat: thi
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 -O1 (test for excess errors)
FAIL: gfortran.dg/associate_68.f90 -O2 (test for excess errors)
FAIL
On 5/27/25 12:39 PM, Harald Anlauf wrote:
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
_ARRAY && ref->next->type == REF_SUBSTRING)
+ {
+ strarr = ref;
+ break;
+ }
+ }
+ else
+ tail->type = REF_ARRAY;
Otherwise, OK
Jerry
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),
it fixes only the case of direct use of
I think I found the bug that caused the test failure, and will send v3
later.
BRs
Jerry
Jerry Zhang Jian 於 2025年5月25日 週日 下午11:05寫道：
> Add support of double trap extension [1], enabling GCC
> to recognize the following extensions at compile time.
>
> New extensions:
>
-ext.def: New extensions
* config/riscv/riscv-ext.opt: Auto re-generated
gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.target/riscv/arch-57.c: New test
* gcc/testsuite/gcc.target/riscv/arch-58.c: New test
Signed-off-by: Jerry Zhang Jian
---
gcc/config/riscv/riscv-ext.def | 26
-ext.def: New extensions
gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.target/riscv/arch-56.c: New test
* gcc/testsuite/gcc.target/riscv/arch-57.c: New test
Signed-off-by: Jerry Zhang Jian
---
gcc/config/riscv/riscv-ext.def | 26
gcc/testsuite/gcc.target/riscv
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 the
original ICE and the PR.
So if you want to
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), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR
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), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR, c_loc(val))
These should get
N". As it is with the patch I return "VOID".
I added a new test case.
I want to add Steve as Co-author as soon as I figure out how to do that
with the git machinery.
Regression tested on x86_64. OK for trunk and eventual backport to 15?
Regards,
Jerry
Author: Jerry DeLisle
st regards,
Jerry
Thanks,
Harald
On 5/6/25 10:59 AM, Steve Kargl wrote:
On Tue, May 06, 2025 at 07:43:41PM +0200, Harald Anlauf wrote:
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.
On 5/6/25 12:44 AM, Paul Richard Thomas wrote:
HI Jerry,
The patch looks good to me. OK for mainline and for backporting. I never
quite know what to suggest for delaying backporting and so I will leave
it to your judgement.
Thanks for the patch.
Paul
Thanks Paul, committed as:
commit
also like to backport to
14 and 15.
Best regards,
Jerry
Author: Jerry DeLisle
Date: Mon May 5 20:05:22 2025 -0700
Fortran: Fix ICE with use of c_associated.
PR fortran/120049
gcc/fortran/ChangeLog:
* check.cc (gfc_check_c_associated): Modify checks to avoid
rv64im_zve32x
instead of rv64gc_zve32x to avoid Zicsr implied by g. Extra m is
added to avoid current 'V' extension requires 'M' extension
Signed-off-by: Jerry Zhang Jian
---
gcc/common/config/riscv/riscv-common.cc| 1 +
gcc/testsuite/gcc.target/ri
rv64i_zve32x
instead of rv64gc_zve32x to avoid Zicsr implied by g
Signed-off-by: Jerry Zhang Jian
---
gcc/common/config/riscv/riscv-common.cc| 1 +
gcc/testsuite/gcc.target/riscv/predef-19.c | 34 ++
2 files changed, 4 insertions(+), 31 deletions(-)
diff --git a/gcc
rv64i_zve32x
instead of rv64gc_zve32x to avoid Zicsr implied by g, add -c to
avoid multilib not supported in the test time
Signed-off-by: Jerry Zhang Jian
---
gcc/common/config/riscv/riscv-common.cc| 1 +
gcc/testsuite/gcc.target/riscv/predef-19.c | 34 ++
2
rv64i_zve32x
instead of rv64gc_zve32x to avoid Zicsr implied by g
Signed-off-by: Jerry Zhang Jian
---
gcc/common/config/riscv/riscv-common.cc| 1 +
gcc/testsuite/gcc.target/riscv/predef-19.c | 22 +++---
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/gcc
x86_64-pc-linux-gnu. OK for mainline?
Cheers,
Harald
OK Harald,
Jerry
Ping! Can we backport this to 15 please?
Regards,
Jerry
On 4/18/25 6:35 PM, Jerry D wrote:
On 4/18/25 5:48 PM, Jerry D wrote:
I will be committing a fix for this to the 16 mainline tonight.
I am requesting Release Manager approval to push to 15 release branch
after full testing here
On 4/18/25 5:48 PM, Jerry D wrote:
I will be committing a fix for this to the 16 mainline tonight.
I am requesting Release Manager approval to push to 15 release branch
after full testing here.
Regards,
Jerry
See attached diff.
2025-04-18 Steven G. Kargl
PR fortran/119836
* resolve.cc
On 4/18/25 9:13 AM, Paul Richard Thomas wrote:
Hi Andre,
On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild <mailto:ve...@gmx.de>> wrote:
Hi Jerry,
thanks for the review and sorry for the long delay. With publishing
the team's
patches for gfortran, I also created
I will be committing a fix for this to the 16 mainline tonight.
I am requesting Release Manager approval to push to 15 release branch
after full testing here.
Regards,
Jerry
See attached diff.
2025-04-18 Steven G. Kargl
PR fortran/119836
* resolve.cc(check_pure_function
On 4/18/25 8:05 AM, Jerry D wrote:
On 4/17/25 6:20 AM, Andre Vehreschild wrote:
Hi Jerry,
thanks for the review and sorry for the long delay. With publishing
the team's
patches for gfortran, I also created a pull request for OpenCoarrays.
There I
was asked to add some testcase with
On 4/17/25 6:20 AM, Andre Vehreschild wrote:
Hi Jerry,
thanks for the review and sorry for the long delay. With publishing the team's
patches for gfortran, I also created a pull request for OpenCoarrays. There I
was asked to add some testcase with more "beef" in it. I.e. someth
t the change to the case of functions
as dummy arguments, making this patch very safe.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Yes, OK for mainline.
Thanks Herald
Jerry
On 4/13/25 11:47 PM, Andre Vehreschild wrote:
Hi Jerry,
thank you very much for the review.
I would love to fix the nits you found, but I don't see, what you see. Can you
elaborate? May be some mail client has removed something, or I am missing
something. Are you commenting on
gfc_
.
It looks OK to commit.
Regards,
Jerry
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -11467,12 +11467,11 @@ resolve_scalar_variable_as_arg (const char
*name, bt exp_type, int exp_kind,
gfc_expr *e)
{
gfc_resolve_expr (e);
if (e
&&
The attached patch fixes this bug by adding checks for negative unit
numbers in CLOSE and OPEN statements.
Regression tested on x86_64_linux_gnu.
OK for trunk
Author: Jerry DeLisle
Date: Sat Apr 12 19:51:23 2025 -0700
Fortran: Fix runtime segfault closing negative unit
ion, but added error
diagnostic for the unsupported bits + updated the testcases.
(And add one for assumed-shape arrays).
OK for GCC 15 mainline?
Tobias
OK by me Tobias.
Jerry
to backport this as
appropriate.
Thanks,
Harald
This looks OK Harold, thanks!
Jerry
array construction. And only for those.
Sorry, I am having a hard time explaining things today. So I hope the code
above will do.
Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
OK and thanks for the fix. Your prose is fine and your comment in the
code suffices.
Thanks for
needed adjustment, which I chose such that the original error
was kept.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Yes, OK and thanks for the fix.
Jerry
gi?id=117455
Regards,
Jerry
On 3/10/25 9:57 AM, Jerry D wrote:
On 3/10/25 1:08 AM, Andre Vehreschild wrote:
Hi Steve and Jerry,
thanks for the review and the proposed changes. I have based on them, but
needed to adapt some places, because the meaning was changed. Can you
please
take another look?
Jerry, where do I
On 3/10/25 1:08 AM, Andre Vehreschild wrote:
Hi Steve and Jerry,
thanks for the review and the proposed changes. I have based on them, but
needed to adapt some places, because the meaning was changed. Can you please
take another look?
Jerry, where do I find this check-script? In bin/ nothing
change.
For www-docs there is an html check script provided. You can also review
by looking with a web browser.
For texi files, if make info succeeds and review the resulting info
files installed in the usr/share if I recall correctly.
Jerry
descriptor for a function call, that is unsuitable in
forall's pointer assignment."
s/prevent/prevents/
-- Jerry
On 2/27/25 11:31 AM, Harald Anlauf wrote:
Am 27.02.25 um 02:58 schrieb Jerry D:
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for t
On 2/27/25 12:33 PM, Peter Hill wrote:
On Thu, 27 Feb 2025 at 18:09, Jerry D wrote:
On 2/27/25 7:38 AM, Peter Hill wrote:
Dear all,
The attached patch fixes an ICE in gfc_resolve_code when passing an
optional array to an elemental procedure with `-pedantic` enabled.
PR95446 added the
On 2/26/25 5:58 PM, Jerry D wrote:
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 14?
Regards,
Jerry
A
(or something else other
than a variable). The ICE is present since 11.1, so this could be
backported?
Cheers,
Peter
Hi Peter, was there a PR associated with this one?
Jerry
--- snip ---
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 14?
Regards,
Jerry
Author: Jerry DeLisle
Date: Wed
haped data type (like a complex number in this case). The current fix
just removes the save_expr from the lhs in an assignment and everything is fine.
Regtest ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Looks OK Andre, thanks.
Jerry
Regards,
Andre
--
Andre Vehreschild * Email:
ous, while allocatables are
always contigous).
Build and regtested on x86-64_gnu-linux.
OK for mainline?
Looks good Tobias. I don't know if anyone else was looking through it.
Jerry
* * *
When doing the change (2) back when I first created the patch, I
encountered an issue, which I could
On 2/13/25 7:09 PM, Jerry D wrote:
On 2/13/25 1:42 PM, Harald Anlauf wrote:
Am 12.02.25 um 21:49 schrieb Jerry D:
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
This is
On 2/13/25 11:48 AM, Jerry D wrote:
On 2/10/25 2:25 AM, Andre Vehreschild wrote:
[PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635]
I have applied all patches. Regression tested OK here.
From patch 5 there was one reject:
patching file gcc/testsuite/gfortran.dg/coarray
1 - 100 of 837 matches
Mail list logo
