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
returning class(*), pointer that ICE'd too.
The or
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
On Fri, Apr 18, 2025 at 05:48:46PM -0700, 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
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.
Rega
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(
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, pure_subroutine
Hi Tobias!
On 2025-04-15T11:30:18+0200, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/map-alloc-comp-6.f90
> @@ -0,0 +1,308 @@
> +! NOTE: This code uses POINTER.
> +! While map(p, var%p) etc. maps the ptr/ptr comp p / var%p (incl.
> allocatable comps),
> +! map(v
On 4/15/25 12:01 PM, Harald Anlauf wrote:
Dear all,
the testcase in the PR shows a case where the pureness of a function
is not properly determined, even though the function is resolved, and
its attributes clearly show that it is pure, because gfc_pure_function
relies on isym or esym being set.
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
Am 11.04.25 um 19:15 schrieb Harald Anlauf:
There is a duplicate "and and" here:
+ gfc_error ("Mismatch between subroutine and and "
+ "function at %L", &actual->where);
OK with this fixed.
Ah, yes :-)
Thanks for the patch!
Commit
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
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 subroutine attribute can be reached, but I thought better
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 mod
On 4/8/25 10:44 AM, Tobias Burnus wrote:
This patch is essentially the one of PR101602, comment 6.
Thus, it has the same issues as that patch:
* LOCAL for derived-type variables with default
initalizers do not work (not initialized)
* LOCAL/LOCAL_INIT for assumed-shape arrays fails
(need s
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 module procedure within the same interface
,
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
This patch is essentially the one of PR101602, comment 6.
Thus, it has the same issues as that patch:
* LOCAL for derived-type variables with default
initalizers do not work (not initialized)
* LOCAL/LOCAL_INIT for assumed-shape arrays fails
(need some 'malloc'/'free' calls + some more other
On Sun, 6 Apr 2025 at 14:39, Paul Richard Thomas
wrote:
>
> Hi All,
>
> As far as I can tell, the attached patch fixes the problems with the reduce
> intrinsic. I would be grateful to the reporters if they would confirm that
> this is the case.
>
> The key to the fix appears in reduce_3.f90, whi
Hi Paul,
> > --- a/libgfortran/intrinsics/reduce.c
> > +++ b/libgfortran/intrinsics/reduce.c
> > @@ -83,8 +83,8 @@ reduce (parray *ret,
> >if (dim_present)
> > {
> >if ((*dim < 1) || (*dim > (GFC_INTEGER_4)array_rank))
> > - runtime_error ("DIM in REDUCE intrinsic is less th
Hi Andre,
On Mon, 7 Apr 2025 at 07:29, Andre Vehreschild wrote:
> Hi Paul,
>
> shouldn't this be done in iresolve.cc to make other parts of gfortran
> benefit
> from learning, that the sym is allocatable?
>
> I'll give it a try. I was attempting to eliminate any wider side effects
by setting the
Hi Paul,
shouldn't this be done in iresolve.cc to make other parts of gfortran benefit
from learning, that the sym is allocatable?
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -3883,6 +3883,13 @@ gfc_conv_intrinsic_funcall (gfc_se * se, gfc_expr *
expr) append_args
On Sun, Apr 6, 2025 at 5:39 AM Paul Richard Thomas
wrote:
>
> Hi All,
>
> As far as I can tell, the attached patch fixes the problems with the reduce
> intrinsic. I would be grateful to the reporters if they would confirm that
> this is the case.
>
> The key to the fix appears in reduce_3.f90, w
Hi All,
As far as I can tell, the attached patch fixes the problems with the reduce
intrinsic. I would be grateful to the reporters if they would confirm that
this is the case.
The key to the fix appears in reduce_3.f90, which failed even with -m64.
Although it was not apparent from the tree dump
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
On Mon, Mar 24, 2025 at 09:40:38PM +0100, Thomas Koenig wrote:
>
> Regression-tested. Again no test case because I don't know
> how. During testing, I also found that vtabs were dumped,
> this is also corrected.
>
> OK for trunk?
Thanks for working on this, but ...
>
> /* This section deals
On Wed, Mar 19, 2025 at 11:23 AM Paul Richard Thomas
wrote:
>
> Hi Andre,
>
> Thanks for the review - I'll act on the points that you raised.
>
> The Linaro people reported a failure in reduce_1.f90 execution, which I
> believe is due to incorrect casting of 'dim' and a wrong specification of its
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 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 s
Hi Harald,
looks good to me. Thanks for the patch.
- Andre
Andre Vehreschild * ve...@gmx.de
Am 26. März 2025 22:18:41 schrieb Harald Anlauf :
Dear all,
it seems that my patch for default-initialization of function results
of derived type could trigger a weird issue if a type-bound function
of
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
Hello Harald,
OK with the above addressed.
Both addressed and pushed in
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=737a5760bb24a0a945cc2c916ba452e3f0060c58
Thanks for the review (and for catching the miscellaneous
problems on the way)!
Best regards
Thomas
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 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_interface(gfc_expr*, gfc_expr*)':
../../gcc-trunk/gcc/fortr
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
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) :: lookup
integer(C_INT), VALUE :: idx
lookup = C_FUNLO
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 at
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 attribute
> instead of the ALLOCATABLE
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,
Thanks for the review - I'll act on the points that you raised.
The Linaro people reported a failure in reduce_1.f90 execution, which I
believe is due to incorrect casting of 'dim' and a wrong specification of
its kind. I am waiting to hear back from them as to whether or not I have
fix
Hi Paul,
I took a look at your patch and think I found some improvements needed. In
+bool
+gfc_check_reduce (gfc_expr *array, gfc_expr *operation, gfc_expr *dim,
+ gfc_expr *mask, gfc_expr *identity, gfc_expr *ordered)
+{
...
+ if (formal->sym->attr.allocatable || formal->sym->
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
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 had a previously undetected error
and n
H.J. Lu wrote:
gfortran: fatal error: cannot read spec file 'libgomp.spec': No such
file or directory
...
FAIL: gfortran.dg/gomp/declare-variant-mod-1.f90 -O (test for excess errors)
The problem is that dg-additional-sources does not work with '-o' with
dg-compile ("-c") as more than one fi
On Sat, Mar 15, 2025 at 3:46 AM Tobias Burnus wrote:
>
> I wonder why sometimes my line breaks are preserved and at other times all
> eaten.
>
> Next try ...
>
> Tobias Burnus wrote:
>
> Hi Thomas,
>
> Thomas Koenig wrote:
> > Just one question - as this will change the module file, will we still
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
On 3/16/25 10:26 AM, Paul Richard Thomas wrote:
--- snip ---
A slight niggle is the linker error that comes up if compiled without
any optimization:
/usr/bin/ld: warning: /tmp/cc9cx9Rw.o: requires executable stack
(because the .note.GNU-stack section is executable)
I think that this is unlikely
Hi All,
This version of the REDUCE intrinsic patch has evolved somewhat since the
posting on 2nd March. The most important changes are to the wrapper
function and the addition of two testsuite entries.
The wrapper function now effects:
subroutine wrapper (a, b, c)
type_of_ARRAY, inte
Hello,
sorry to come late to the party.
Le 08/03/2025 à 13:52, Thomas Koenig a écrit :
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index edec907d33a..e3bc22f25e5 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -5836,6 +5836,8 @@ gfc_get_formal_from_
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
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.
Thanks for the patch!
Best regards
Thomas
Hi Thomas,
Thomas Koenig wrote:
Attached is a long overdue bug fix, given that OpenMP's declare variant
is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021).
(and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp
declare simd' was already handled in the .mod file, 'de
I wonder why sometimes my line breaks are preserved and at other times all
eaten.
Next try ...
Tobias Burnus wrote:
Hi Thomas,
Thomas Koenig wrote:
Just one question - as this will change the module file, will we still
be compatible with reading gfortran 8 to gfortran 14-written module
file
Hi Tobias,
Attached is a long overdue bug fix, given that OpenMP's declare variant
is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and
in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare
simd' was already handled in the .mod file, 'declare variant' was no
Attached is a long overdue bug fix, given that OpenMP's declare variant
is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and in C/C++ since
r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare simd' was
already handled in the .mod file, 'declare variant' was not. It is
eas
Am 12.03.25 um 18:33 schrieb Thomas Koenig:
The test case should stay, but I will remove the dg-error directives.
Fix committed as obvious and simple as r15-8006 .
Thanks for the heads-up!
Best regards
Thomas
Hi Andre,
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 8)
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 9)
When I revert your patch and test again, above fails do not occur. Could you
please investigate, if I am right?
Jep, I missed
Hi Thomas,
I think this patch produced a regression:
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 8)
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 9)
When I revert your patch and test again, above fails do not occur. Could you
please i
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
On Thu, Mar 06, 2025 at 10:49:08PM +0100, Harald Anlauf wrote:
>
> Thanks for the speedy review!
>
It was a bit easier than normal. After I submitted
the PR, I started to poke around in fortran/resolve.cc
to see if I could deal with the issue. I saw that you
grab the PR last night, and left yo
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
Thomas
Abstract interfaces and dummy arguments ar
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
Am 11.03.25 um 10:22 schrieb Andre Vehreschild:
Hi Thomas,
looks good to me as well. Thanks for the patch.
Committed as r15-7964.
Thanks Harald and Andre!
Best regards
Thomas
Hi Thomas,
looks good to me as well. Thanks for the patch.
Regards,
Andre
On Tue, 11 Mar 2025 07:11:53 +0100
Thomas Koenig wrote:
> Am 10.03.25 um 22:34 schrieb Harald Anlauf:
>
> > the patch looks basically fine but I cannot find the testcase.
>
> You're right, here it is.
>
> Best re
Am 10.03.25 um 22:34 schrieb Harald Anlauf:
the patch looks basically fine but I cannot find the testcase.
You're right, here it is.
Best regards
Thomas
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 20bf6e127ff..ef9c80147cc 100644
--- a/gcc/fortra
Hi Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
Thanks for the patch!
Best regards
Thomas
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
Le 09/03/2025 à 17:40, Thomas Koenig a écrit :
Hi Mikael,
_symbol *asym = a->expr->symtree->n.sym;
You may consider calling gfc_commit_symbol(s) instead at the end of
the function body. It might avoid leaking the old_symbol field in
case the function is called more than once or the symbol
Hi Mikael,
_symbol *asym = a->expr->symtree->n.sym;
You may consider calling gfc_commit_symbol(s) instead at the end of the
function body. It might avoid leaking the old_symbol field in case the
function is called more than once or the symbol is already existing (not
completely clear wheth
Am 08.03.25 um 20:29 schrieb Steve Kargl:
On Sat, Mar 08, 2025 at 01:52:06PM +0100, Thomas Koenig wrote:
While looking at the code, I also saw that a member of gfc_symbol
introduced with my patch should be a bitfield of width 1.
OK for trunk?
OK (assuming a successful regression test run).
On Sat, Mar 08, 2025 at 01:52:06PM +0100, Thomas Koenig wrote:
>
> the attached patch fixes an ICE regresseion where undo state was not
> handled properly when generating formal from actual arguments, which
> occurred under certain conditions with the newly introduced
> -Wexternal-argument-mismatc
Hello world,
the attached patch fixes an ICE regresseion where undo state was not
handled properly when generating formal from actual arguments, which
occurred under certain conditions with the newly introduced
-Wexternal-argument-mismatch option.
The fix is simple: When we are generating these
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 expression.
>
> The fix I chose turned out to be a l
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 expre
: [PATCH] Fortran: improve checking of substring bounds [PR119118]
After the fix for pr98490 no substring bounds check was generated if the
substring start was not a variable. While the purpose of that fix was to
suppress a premature check before implied-do indices were substituted, this
prevented a
Hi Andre,
while the patch looks ok to me, why did you not choose to generate a "22.7.2
Variable-Length Parameter Lists"
https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html
when the arguments differ? Then its the callee responsibility to figure
stuff
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
Hi Thomas,
while the patch looks ok to me, why did you not choose to generate a "22.7.2
Variable-Length Parameter Lists"
https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html
when the arguments differ? Then its the callee responsibility to figure
stuff o
Hello world,
this patch is a bit more complicated than originally envisioned.
The problem was that we were not handling external dummy arguments
with -fc-prototypes-external. In looking at this, I found that we
were not warning about external procedures with different argument
lists. This can a
Hi Andre,
Am 03.03.25 um 10:08 schrieb Andre Vehreschild:
Hi Harald,
in +++ b/gcc/fortran/symbol.cc
@@ -4624,12 +4624,28 @@ verify_bind_c_derived_type (gfc_symbol *derived_sym)
there is
+ else if (!pedantic)
+ gfc_warning (0, "Derive ...
To me the "not pedantic" is counter-intuiti
Hi Harald,
in +++ b/gcc/fortran/symbol.cc
@@ -4624,12 +4624,28 @@ verify_bind_c_derived_type (gfc_symbol *derived_sym)
there is
+ else if (!pedantic)
+ gfc_warning (0, "Derive ...
To me the "not pedantic" is counter-intuitive. In pedantic mode I would have
expected this to be at leas
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 problem
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 problems, in an
> attempt to further red
only submitting now after re-regtesting
on x86_64-pc-linux-gnu.
I will commit as obvious within 24 hours unless there are comments.
Thanks,
Harald
From 35adb4c16aaaf89dae78e2c494998043a14099b2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 1 Mar 2025 15:42:57 +0100
Subject: [PATCH
No problem, created PR119054 with a reproducer and some details.
Cheers,
Peter
On Thu, 27 Feb 2025 at 20:45, Jerry D wrote:
>
> 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
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 origina
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 original check, this patch f
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 original check, this patch fixes the case where the
other actual argument is an array literal (
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 original check, this patch fixes the case where the
other actual argument is an array literal (or something else other
than a variable)
On 2/21/25 09:21, Andre Vehreschild wrote:
Hi Harald,
seconding Thomas here, thanks for the patch.
Thanks, Andre!
Pushed: r15-7663-g7d383a7343af05
- Andre
On Thu, 20 Feb 2025 21:18:01 +0100
Harald Anlauf wrote:
Dear all,
the attached simple patch addresses a small, left-over issue in t
Hi Harald,
seconding Thomas here, thanks for the patch.
- Andre
On Thu, 20 Feb 2025 21:18:01 +0100
Harald Anlauf wrote:
> Dear all,
>
> the attached simple patch addresses a small, left-over issue in the
> above PR and was already OK'ed in the PR by Thomas. With it we
> initialize the data co
03:12 +0100
Subject: [PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer
[PR48958]
PR fortran/48958
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_deferred_array): Initialized the data
component of non-saved pointers when -fcheck=pointer is set.
gcc/testsuite/Chan
On 2/19/25 10:08 AM, Tobias Burnus wrote:
The attached patch does some ground-laying work for OpenMP
deep mapping - touching common gfortran code.
It does so by:
(1)gfc_tree_array_size now can determine the array size not only from
the passed Fortran gfc_expr but also using a descriptor, passe
Just to be clear: the following touches generic Fortran code and, hence,
needs Fortran FE review (still pending):
Tobias Burnus wrote:
(1) gfc_tree_array_size now can determine the array size not only from
the passed Fortran gfc_expr but also using a descriptor, passed as
gimple 'tree'.
(2)
The attached patch does some ground-laying work for OpenMP
deep mapping - touching common gfortran code.
It does so by:
(1)gfc_tree_array_size now can determine the array size not only from the
passed Fortran gfc_expr but also using a descriptor, passed as gimple
'tree'.
(2) Adds missingGFC_
Am 17.02.25 um 05:53 schrieb Steve Kargl:
On Sun, Feb 16, 2025 at 09:36:20AM +0100, Thomas Koenig wrote:
this patch is a variation of Jakub's patch in the PR, which
avoids overflow on the mask used for exponentiation and
fixes unsigned HOST_WIDE_INT. I tried testing this on
a POWER machine, bu
On Sun, Feb 16, 2025 at 09:36:20AM +0100, Thomas Koenig wrote:
>
> this patch is a variation of Jakub's patch in the PR, which
> avoids overflow on the mask used for exponentiation and
> fixes unsigned HOST_WIDE_INT. I tried testing this on
> a POWER machine, but --with-build-config=bootstrap-ubs
Hello world,
I just committed the attached patch as obvious, simple and having
no user impact), as r15-7575.
Previously, a dump looked like
attributes: (VARIABLE IMPLICIT-SAVE BIND(C) SAVE-IMPLICIT)
and now it is
attributes: (VARIABLE IMPLICIT-SAVE BIND(C))
Best regards
Thom
Hello world,
this patch is a variation of Jakub's patch in the PR, which
avoids overflow on the mask used for exponentiation and
fixes unsigned HOST_WIDE_INT. I tried testing this on
a POWER machine, but --with-build-config=bootstrap-ubsan
fails bootstrap there.
Regression-tested. OK for trunk?
1 - 100 of 1671 matches
Mail list logo
