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
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 -
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 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
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
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
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 16.03.25 um 22:37 schrieb Jonathan Wakely via Gcc:
On Sun, 16 Mar 2025 at 21:30, Harald Anlauf via Gcc wrote:
since I am experiencing extreme (temporary) performance problems
again with a recently increased frequency and only during evening
hours in Europe, I am asking if this is still the
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
Am 16.03.25 um 22:59 schrieb Mark Wielaard:
There is currently a botnet attacking lots of http git endpoints on
various systems including sourceware. We are trying to coordinate a
bit, but given that it seems a fairly large botnet with lots of ips
(which often only do one or two hits per day), it
Hello all,
Am 15.08.24 um 21:31 schrieb Mark Wielaard:
Hi,
On Thu, Aug 15, 2024 at 10:31:12AM -0700, H.J. Lu via Gcc wrote:
On Thu, Aug 15, 2024 at 10:17 AM Harald Anlauf via Gcc wrote:
is it only me who is recently experiencing intermittent
but extreme slowness of "git pull"?
[
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
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
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
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
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
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
4b767 .
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
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
Am 28.02.25 um 08:24 schrieb Andre Vehreschild:
Hi Thomas,
are you really telling me, that gfortran's coarray test library is compiled for
offloading to GPU (or other SIMD processors)? Because that's what NVPTX is used
for most, right? In my opinion that makes no sense, because coarrays in Fortr
Hi Andre,
Am 27.02.25 um 18:36 schrieb Andre Vehreschild:
Hi all,
attached patch fixes user defined finalizers in derived (class) types not
getting called, when the variable declared of that type was not used in the
current block. The patch ensures calling the finalizer by marking the
variable
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 trunk and backport to 14?
OK for trunk.
I don't think we backpo
to.
I will add a comment, when ko one comes up with the macro by Monday.
Thanks,
Andre
Andre Vehreschild * ve...@gmx.de
Am 22. Februar 2025 15:29:20 schrieb Harald Anlauf :
Hi Andre,
Am 21.02.25 um 14:35 schrieb Andre Vehreschild:
Hi all,
during testing and compiling some larger coarray codes,
Hi Andre,
Am 21.02.25 um 14:35 schrieb Andre Vehreschild:
Hi all,
during testing and compiling some larger coarray codes, I found a few
deficiencies. One was with handling class types when splitting the coarray
expression and the other was that the backend_decl of a formal argument in a
functio
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
SIZE intrinsic) trigger consistently and not randomly.
I plan to commit within 24h unless there are comments.
Regtested on x86_64-pc-linux-gnu. ON for mainline?
Thanks,
Harald
From eca02da7cfa3781727dfd1a0914b7d9d377b1511 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 20 Feb 2025 21:
of intrinsic types. For more details see the attached.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 3e20f044243dea8d7a873217c8836bcdfbdd90c3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 14 Feb 2025 20:12:10 +0100
Subject: [PATCH] Fortran: passing of derived
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 not a review, just some random comments on the testsuite changes
by your patch
Hi Thomas,
Am 10.02.25 um 20:26 schrieb Thomas Koenig:
Hello Harld,
the attached patch enhances the checking of pointer targets in structure
constructors to catch the following invalid cases (before we ICE :)
- different rank
- vector subscript of target
Regtested on x86_64-pc-linux-gnu. OK
118a6c3247bb30ef932341cec3ca15e2c6304b69 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 10 Feb 2025 18:47:45 +0100
Subject: [PATCH] Fortran: checking of pointer targets for structure
constructors [PR56423]
Check the target of a pointer component in a structure constructor for same
ranks, and that the initial
Hi Thomas,
Am 08.02.25 um 15:31 schrieb Thomas Koenig:
Hello world,
this fixes a rather old PR from 2005, where a subroutine
could be passed and called as a function. This patch checks
for that, also for the reverse, and for wrong types of functions.
looks good, just two minor comments:
+
Hi Steve,
Am 07.02.25 um 21:39 schrieb Steve Kargl:
On Fri, Feb 07, 2025 at 09:31:12PM +0100, Harald Anlauf wrote:
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks reasonable.
While it is a really old bug but wrong code, I'd like to backport
this also at least to 14-branch.
old bug but wrong code, I'd like to backport
this also at least to 14-branch. Any reservations?
Thanks,
Harald
From f90b21d89c206507c4383e349db12546b793ce31 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 7 Feb 2025 21:21:10 +0100
Subject: [PATCH] Fortran: fix initializati
Am 03.02.25 um 19:31 schrieb Jerry D:
On 2/3/25 2:49 AM, Richard Sandiford wrote:
Steve Kargl writes:
On Sat, Feb 01, 2025 at 09:49:17PM +0100, Harald Anlauf wrote:
Am 01.02.25 um 21:03 schrieb Steve Kargl:
On Sat, Feb 01, 2025 at 07:25:51PM +0100, Harald Anlauf wrote:
the attached patch
Am 01.02.25 um 21:49 schrieb Harald Anlauf:
So why must we be so tough?
Here's what I get from other compilers:
Intel, Nvidia, AMD flang: silent by default.
ifx -stand f18:
char_array_constructor_5.f90(11): warning #8208: If type specification
is omitted, each ac-value expression i
Am 01.02.25 um 21:03 schrieb Steve Kargl:
On Sat, Feb 01, 2025 at 07:25:51PM +0100, Harald Anlauf wrote:
the attached patch downgrades different constant character lengths in an
array constructor from a GNU to a legacy extension, so that users get a
warning with -std=gnu. We continue to
testcase where this
triggered... :)
OK for mainline?
Thanks,
Harald
From c2ab5fc3e4cc758ca00e1878394c8f1466462f84 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 1 Feb 2025 19:14:21 +0100
Subject: [PATCH] Fortran: different character lengths in array constructor
[PR93289]
PR fortran
Am 31.01.25 um 18:37 schrieb Jerry D:
On 1/30/25 1:44 PM, Harald Anlauf wrote:
Dear all,
analyzing the the PR (by Gerhard) turned out to two slightly related
issues. The first one, where a variable in a COMMON block is falsely
resolved to a derived type declared in the host, leads to a false
Hi Jerry,
Am 30.01.25 um 21:50 schrieb Jerry D:
On 1/29/25 10:30 AM, Jerry D wrote:
Follow-up:
On 1/28/25 1:33 PM, Harald Anlauf wrote:
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang
disagree wi
3ab31890f81d24b0231da6d9a5dc29ea316e364d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 30 Jan 2025 22:21:19 +0100
Subject: [PATCH] Fortran: host association issue with symbol in COMMON block
[PR108454]
When resolving a flavorless symbol that is already registered with a COMMON
block, and
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang
disagree with it.
Adding the following lines before the check with the STOP statement:
write(*,'(a)') output1
write(*,'(a)') output2
write (*, fmt1) 'RADIX',
-pc-linux-gnu.
Will also backport to 14-branch, which has the same code.
Thanks,
Harald
From b6309e6fe318b8f63eed1a1a68c78c43fcf38ab4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 28 Jan 2025 21:21:40 +0100
Subject: [PATCH] Fortran: fix passing of component ref to assumed-rank dummy
Am 27.01.25 um 01:41 schrieb Jerry D:
On 1/26/25 2:07 PM, Harald Anlauf wrote:
Dear all,
in the checking of imported interfaces we need to use the local names
of procedures that are renamed-on-use, as the original name becomes
inaccessible. Similarly, we should not compare interfaces of
non
accessible via a use statement, see testcase.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Could this one be backportable, e.g. to 14-branch?
Thanks,
Harald
From fb19a4bd29f49935514a7c2a43dbc9f2a6e9b147 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 26 Jan 2025 22:56:57 +0100
Subject
Am 25.01.25 um 21:05 schrieb Jerry D:
On 1/25/25 11:12 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes bogus errors with CLASS variables in BLOCK DATA
that showed up because some compiler-generated components were not
declared as artificial.
Furthermore, a warning can be emitted
iable" is set.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From dba6e9bcf284d1d875529520cd7ae52230c1e65b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 25 Jan 2025 19:59:56 +0100
Subject: [PATCH] Fortran: fix issues with variables in BLOCK DATA [PR58857]
Hi Mikael,
Am 23.01.25 um 15:00 schrieb Mikael Morin:
Le 22/01/2025 à 22:55, Harald Anlauf a écrit :
Dear all,
while looking at details of a related but slightly different PR, I found
that we did evaluate the arguments to MINLOC/MAXLOC too often in the
inlined version.
The attached patch
once. This required
a minor adjustment for the rank-1 algorithm, which is documented.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From d2a52256b3e4817e16a5d222c2fecd7bc66e5613 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 22 Jan 2025 22:44:39 +0100
Subject: [PATCH
Dear all,
I've pushed the following minor improvement of an error message
as suggested by the reporter as obvious after regtesting in the
gfortran.dg/gomp subdirectory.
Thanks,
Harald
From 96f4ba4d19a765902af7b79aa77d52c62fa2f82c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 2
, Harald Anlauf wrote:
Dear all,
this patch addresses a long-standing difference between gfortran and
other brands: when an array actual argument was passed to a procedure,
and the dummy argument had no intent specified, we would often create
packing and unpacking code. Only the case of the
we do not simply create
suitable array descriptors when passing to assumed-shape dummies,
which may avoid the packing.
From 387177dbeed5a2c6563d3c2275fee8a4d756d7a5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 19 Jan 2025 21:06:56 +0100
Subject: [PATCH] Fortran: do not copy back for
Hi Jerry,
Am 17.01.25 um 22:04 schrieb Jerry Delisle:
Looks Ok by me.
Committed and pushed r15-7009-gca2681d45a4507 .
Thanks,
Harald
Thanks,
Jerry
On Fri, Jan 17, 2025, 12:25 PM Harald Anlauf wrote:
Dear all,
the attached obvious patch extends G formatting to UNSIGNED by reusing
the
Dear all,
the attached obvious patch extends G formatting to UNSIGNED by reusing
the code for I formatting.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 5ba7e37a089257dc40e9f347a835a481121a3f3f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 17 Jan 2025 21
Hi Thomas,
Am 16.01.25 um 20:38 schrieb Thomas Koenig:
Hello Harald,
the conversion of (unsigned) integers to decimal in output was designed
to be efficient up to INTEGER(kind=16) and did not handle values larger
than roughly (10^19 * 2^64).
The attached obvious patch fixes this.
Regtested o
From f66049d52327242743e7e9ff59d8373fcb333212 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 16 Jan 2025 20:23:06 +0100
Subject: [PATCH] libfortran: fix conversion of UNSIGNED(kind=16) to decimal in
output [PR118406]
PR libfortran/118406
libgfortran/ChangeLog:
* runtime/string.c
2001
From: Harald Anlauf
Date: Wed, 15 Jan 2025 19:42:52 +0100
Subject: [PATCH] Fortran: reject NULL as source-expr in ALLOCATE with SOURCE=
or MOLD= [PR71884]
PR fortran/71884
gcc/fortran/ChangeLog:
* resolve.cc (resolve_allocate_expr): Reject intrinsic NULL as
source-expr.
gcc/testsuite
Hi Thomas,
Am 12.01.25 um 19:33 schrieb Thomas Koenig:
Hell world,
after finding that an attribute I was looking for was not
in the -fdump-fortran-original dump, I started putting in
attributes and didn't stop until I had them all (or so
I hope :-) It should be easier to read than looking at
t
Hi Thomas,
Am 11.01.25 um 23:38 schrieb Thomas Koenig:
Hi Harald,
Thanks for pointing this out! I've also added a few gcc_unreachable()
to prevent other potential false positives, see attached.
Just a couple of documentation nits: The documentation says INTEGER
or REAL only, but it also wo
e -Ofast.
Seems like I got lost looking too long at tree and optimized dumps...
Thanks,
Harald
Best regards
Thomas
From 2ff2308edabbcd412bf137f3e74a6db3e5cea387 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 11 Jan 2025 08:35:44 +0100
Subject: [PATCH] Fortran: implemen
c-linux-gnu. OK for mainline?
Thanks,
Harald
From 39f9632844370eaf7377d9bfa182e824b898 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 10 Jan 2025 22:16:09 +0100
Subject: [PATCH] Fortran: implement F2018 intrinsic OUT_OF_RANGE [PR115788]
Implementation of the Fortran 2018 standard in
Hi Jerry!
Am 03.01.25 um 05:21 schrieb Jerry D:
On 1/2/25 12:04 PM, Harald Anlauf wrote:
Dear all,
this patch addresses overeager optimization of Cray pointers when
used in comparisons. Cray pointers are non-standard, and odd in a
sense that they were introduced before modern Fortran
ort?
Thanks,
Harald
From 2043df2056e451d7a2f48d3da9cd560eccd2dd51 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 2 Jan 2025 20:22:23 +0100
Subject: [PATCH] Fortran: Cray pointer comparison wrongly optimized away
[PR106692]
PR fortran/106692
gcc/fortran/ChangeLog:
* trans-expr.
Am 23.12.24 um 18:51 schrieb Jerry D:
On 12/23/24 9:19 AM, Harald Anlauf wrote:
Dear all,
while preparing the testcase null_actual_7.f90 for commit r15-6408,
I overlooked a corner case, leading to a regression (PR118179).
The obvious solution is to extend the suppression of copying back
the
.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 49754a5acc6ca4c0927d54c3c00cc3f93f1ce4dd Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 23 Dec 2024 17:56:46 +0100
Subject: [PATCH] Fortran: fix NULL without MOLD argument to scalar DT pointer
dummy [PR118179
Am 22.12.24 um 22:36 schrieb rep.dot@gmail.com:
On 22 December 2024 21:50:41 CET, Harald Anlauf wrote:
Dear all,
please find attached fixes for GMP memleaks in the gfortran frontend
found when running f951 under valgrind. One of them surfaced when
looking at a testcases that invoved
Hi Steve,
Am 18.12.24 um 22:37 schrieb Steve Kargl:
So, it seems that this section of the patch
+ gfc_init_se (&asis_se, se);
+ gfc_conv_expr (&asis_se, asis);
+ gfc_add_block_to_block (&se->pre, &asis_se.pre);
+ tmp = fold_build3_loc (input_location, COND_EXPR,
:00:00 2001
From: Harald Anlauf
Date: Sun, 22 Dec 2024 21:34:19 +0100
Subject: [PATCH] Fortran: fix front-end GMP memleaks
gcc/fortran/ChangeLog:
* check.cc (gfc_check_random_seed): Clear gmp variables returned by
gfc_array_size.
* expr.cc (gfc_check_pointer_assign): Likewise.
---
gcc/fortran
Hi Andre,
Am 21.12.24 um 17:41 schrieb Andre Vehreschild:
Hi Harald,
the patch looks ok to me.
thanks for taking a look!
Pushed as r15-6408.
Harald
Thanks for the patch,
Andre
On Fri, 20 Dec 2024 19:00:05 +0100
Harald Anlauf wrote:
Ping!
Am 14.12.24 um 20:56 schrieb Harald
Ping!
Am 14.12.24 um 20:56 schrieb Harald Anlauf:
Dear all,
this patch is the 4th part of a series on the passing of NULL() to
assumed-rank dummies. This one handles the case of a derived type
dummy and is mostly straightforward.
There was one particular problem I encountered: passing NULL
Am 20.12.24 um 00:46 schrieb Jerry D:
On 12/19/24 1:34 PM, Harald Anlauf wrote:
Dear all,
the check for potential aliasing of lhs and rhs currently shortcuts
if the types differ. This is a problem if one is of type complex
and the other is of type real (and of the same kind parameter value
From: Harald Anlauf
Date: Thu, 19 Dec 2024 22:22:52 +0100
Subject: [PATCH] Fortran: potential aliasing of complex pointer inquiry
references [PR118120]
PR fortran/118120
gcc/fortran/ChangeLog:
* trans-array.cc (symbols_could_alias): If one symbol refers to a
complex type and the other to a
Am 18.12.24 um 22:05 schrieb Steve Kargl:
On Wed, Dec 18, 2024 at 01:11:14PM +0100, Harald Anlauf wrote:
I haven't looked close enough, but you may have to add support
for 'asis' being an optional dummy variable. The following
example crashes here with a segfault:
(prog
Am 18.12.24 um 19:09 schrieb Jerry D:
On 12/18/24 4:11 AM, Harald Anlauf wrote:
Hi Steve,
thanks for the draft patch.
I haven't looked close enough, but you may have to add support
for 'asis' being an optional dummy variable. The following
example crashes here with a segfaul
Hi Steve,
thanks for the draft patch.
I haven't looked close enough, but you may have to add support
for 'asis' being an optional dummy variable. The following
example crashes here with a segfault:
program foo
use iso_c_binding, only : c_null_char, c_char, f_c_string, c_size_t
implicit n
backporting if you are inclined to do so. (14 is certainly fine).
Thanks for the patch!
Harald
Regards,
Andre
On Fri, 13 Dec 2024 14:09:25 +0100
Harald Anlauf wrote:
Hi Andre,
while the patch works with the reduced testcase, it runs into the
newly added gcc_assert() when trying the
eone would like to assist with the case of class
dummies, please let me know.
From bef5e605ee14c4db85c96a3b30a765669570cac0 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 14 Dec 2024 20:26:47 +0100
Subject: [PATCH] Fortran: fix passing of NULL() to assumed-rank, derived type
dummy [PR10
Hi Andre,
while the patch works with the reduced testcase, it runs into the
newly added gcc_assert() when trying the original testcase in the PR.
I also wonder if this use of gcc_assert() is a good idea or good style:
+ gcc_assert (gfc_resolve_expr (tgt_expr));
Since gcc_assert is a macro
Thanks, Jerry!
Pushed as r15-6053.
Am 08.12.24 um 23:57 schrieb Jerry Delisle:
Looks good, OK to push.
On Sun, Dec 8, 2024, 1:39 PM Harald Anlauf wrote:
Dear all,
while looking at testcases with inquiry refs, I encountered two minor
GMP memleaks due to double-initialization of GMP
,
Harald
From a299b38fa34869b19f5e11bcc389cd78c877c319 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 8 Dec 2024 22:30:32 +0100
Subject: [PATCH] Fortran: fix two minor front-end GMP memleaks
gcc/fortran/ChangeLog:
* expr.cc (find_array_section): Do not initialize GMP variables
twice
1 - 100 of 918 matches
Mail list logo
