intent(out). I am at a loss now.
I am attaching the latest version of my patch to give you or
Paul or others the opportunity to see what is wrong or add the
missing pieces.
Thanks for your help so far.
Harald
From 989030fc04eacf97a034ab1f7ed85b932669f82d Mon Sep 17 00:00:00 2001
From: Harald An
Hi Mikael,
Am 07.07.23 um 14:21 schrieb Mikael Morin:
I'm attaching what I have (lightly) tested so far, which doesn't work.
It seems gfc_conv_class_to_class reevaluates part of the original
expression, which is not correct after deallocation.
this looks much more elegant than my attempt that
.
Thanks,
Harald
From b6c4f70d2dac4863335874f0bd3486ea7db348d7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 7 Jul 2023 20:25:06 +0200
Subject: [PATCH] Fortran: simplification of FINDLOC for constant complex
arguments [PR110585]
gcc/fortran/ChangeLog:
PR fortran/110585
* arith.cc
Hi Mikael,
Am 08.07.23 um 14:07 schrieb Mikael Morin:
here is what I'm finally coming to. This patch fixes my example, but is
otherwise untested.
The patch has grown enough that I'm tempted to fix my example
separately, in its own commit.
alright. I've interpreted this as a green light for v
Hi Paul,
thanks for taking this.
I have just a minor comment regards coding style:
+ if (tmp
+ && tmp->attr.generic
+ && (tmp = gfc_find_dt_in_generic (tmp)))
+ {
+ if (tmp->attr.flavor == FL_DERIVED)
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type pdt(n)
integer, len :: n = 8
character(len=n) :: c
end type pdt
type(pdt(42)) :: p
integer, parameter ::
rald
From 3b2c523ae31b68fc3b8363b458a55eec53a44365 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 11 Jul 2023 21:21:25 +0200
Subject: [PATCH] Fortran: formal symbol attributes for intrinsic procedures
[PR110288]
gcc/fortran/ChangeLog:
PR fortran/110288
* symbol.cc (gfc_copy_formal_args_i
ut.
Regtests ok on x86_64-linux-gnu/F37.
Regards,
Andre
On Mon, 10 Jul 2023 20:55:29 +0200
Harald Anlauf wrote:
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type
Hi Andre,
I forgot to answer your other question:
Am 11.07.23 um 18:23 schrieb Andre Vehreschild via Gcc-patches:
I tried to use a pdt within a derived type as a component. Is that not allowed
by the standard? I know, I could hunt in the standard for it, but when someone
knows out of his head,
Pushed as:
commit 086a1df4374962787db37c1f0d1bd9beb828f9e3
Thanks,
Harald
On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
Hi Rimvydas,
Gesendet: Sonntag, 12. Februar 2023 um 07:59 Uhr
Von: "Rimvydas Jasinskas"
An: "Harald Anlauf"
Cc: "fortran"
Bet
2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 13 Feb 2023 22:02:44 +0100
Subject: [PATCH] Fortran: error recovery after invalid use of CLASS variable
[PR103475]
gcc/fortran/ChangeLog:
PR fortran/103475
* primary.cc (gfc_expr_attr): Avoid NULL pointer dereference for
Hi Thomas,
On 2/14/23 10:35, Thomas Schwinge wrote:
Hi!
On 2023-02-13T18:50:23+0100, Harald Anlauf via Gcc-patches
wrote:
Pushed as:
commit 086a1df4374962787db37c1f0d1bd9beb828f9e3
On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
There is one thing I cannot test, which is the
Dear all,
I've committed the attached obvious and trivial patch for a NULL
pointer dereference on behalf of Steve and after regtesting on
x86_64-pc-linux-gnu as r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c
Thanks,
Harald
From a418129273725fd02e881e6fb5e0877287a1356c Mon Sep 17 00:00:00 200
Dear all,
I've committed the attached obvious and trivial patch for another
NULL pointer dereference on behalf of Steve and after regtesting on
x86_64-pc-linux-gnu as r13-6067-gc75cbeba81e5b4737a9ab7dd28cce650965535a9
Thanks,
Harald
From c75cbeba81e5b4737a9ab7dd28cce650965535a9 Mon Sep 17 00:00:
for mainline?
The PR is marked as a 10/11/12/13 regression, so I would
like to backport this as far as it seems reasonable.
Thanks,
Harald
From f581f63e206b54278c27a5c888c2566cb5077f11 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 20 Feb 2023 21:28:09 +0100
Subject: [PATCH] Fortran
org/g:6c1b825b3d6499dfeacf7c79dcf4b56a393ac204
commit r13-6265-g6c1b825b3d6499dfeacf7c79dcf4b56a393ac204
Author: Harald Anlauf
Date: Mon Feb 20 21:28:09 2023 +0100
OK either way.
The PR is marked as a 10/11/12/13 regression, so I would
like to backport this as far as it seems reasonable.
Also OK.
Thanks fo
reasonable.
Thanks,
Harald
From 0a392415cb5d5486e3e660880c81d6fdbbb47285 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 21 Feb 2023 22:06:33 +0100
Subject: [PATCH] Fortran: reject invalid CHARACTER length of derived type
components [PR96024]
gcc/fortran/ChangeLog:
PR fortran/96024
-g45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3
Author: Harald Anlauf
Date: Fri Feb 24 19:56:32 2023 +0100
Thanks,
Harald
From 45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 24 Feb 2023 19:56:32 +0100
Subject: [PATCH] Fortran: frontend passes do_subscript leaks gmp memory
[PR108924
Hi Tobias,
Am 24.02.23 um 12:31 schrieb Tobias Burnus:
(B) The attached patch:
With 'intent(out)' there is no reason to do the conversions. While for
nullified
pointers the bounds-conversion loop is skipped, it may still be executed
for undefined
pointers. (Which is usually harmless.) In either
Hi Rimvydas,
Am 24.02.23 um 06:16 schrieb Rimvydas Jasinskas via Gcc-patches:
On Thu, Feb 23, 2023 at 10:53 PM Harald Anlauf wrote:
the patch is mostly fine, but there is a minor style issue:
+ if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+ gfc_error ("Symbol
Hi Mikael,
Am 25.02.23 um 17:35 schrieb Mikael Morin:
Hello,
Harald found a testcase with memory still leaking despite my previous
patch for PR108923.
That patch was fixing a leak caused by absence of memory release, the
attached patch fixes a leak caused by pointer overwrite.
I haven't invest
.
Pushed to mainline as r13-6344-g03c60e525bea13 .
Thanks,
Harald
From 03c60e525bea13c15edd2f64cd582f168fe80bfb Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 25 Feb 2023 19:05:38 +0100
Subject: [PATCH] Fortran: fix memory leak with real to integer conversion
warning
gcc/fortran
Hi Jerry,
regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a
gcc_assert (dim >= 1);
in the right place achieve the same effect, since the first argument
must be an array?
(It's different for SPREAD, though, where SOURCE may be scalar).
Che
.
Attached patch fixes this and regtests on x86_64-pc-linux-gnu.
OK for mainline?
This issue has been there for ages. Shall this be backported
or left in release branches as is?
Thanks,
Harald
From 6844c5ecb271e091a8c913903a79eac932cf5f76 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon
licates at some level.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 4600577e3ecceb2525618685f47c8a979cf9d244 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 2 Mar 2023 22:37:14 +0100
Subject: [PATCH] Fortran: fix CLASS attribute handling [PR106856]
gcc/fortran
Hi Steve,
Am 03.03.23 um 20:57 schrieb Steve Kargl via Gcc-patches:
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
- if (attr->class_ok)
-/* Class container has already been built. */
+ /* Class container has already been built with same name. */
+ if (a
at different
codepaths are tested.
Regtested again on x86_64-pc-linux-gnu.
Any further comments?
Thanks for your very helpful review!
Harald
From 70cba7da18023282546b9a5d80e976fc3744d732 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 5 Oct 2022 22:25:14 +0200
Subject: [PATCH] Fortra
at different
codepaths are tested.
Regtested again on x86_64-pc-linux-gnu.
Any further comments?
Thanks for your very helpful review!
Harald
From 70cba7da18023282546b9a5d80e976fc3744d732 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 5 Oct 2022 22:25:14 +0200
Subject: [PATCH] Fortran: reject
Sorry, attached the wrong patch.
Here's the correct one.
Harald
Am 04.03.23 um 17:02 schrieb Harald Anlauf via Gcc-patches:
The attached revised version uses the above proven changes,
and extends the new testcase class_74.f90 by variations of
the failures remaining with version 1 so
Hi Mikael,
Am 04.03.23 um 18:09 schrieb Mikael Morin:
There was a comment about the old_symbol thing at the end of my previous
message:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613354.html
I think Tobias might be the better person to answer this.
But when playing with variations o
Hi Mikael,
Am 04.03.23 um 23:29 schrieb Mikael Morin:
Le 04/03/2023 à 22:20, Harald Anlauf a écrit :
Hi Mikael,
Am 04.03.23 um 18:09 schrieb Mikael Morin:
There was a comment about the old_symbol thing at the end of my previous
message:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March
nyway.
Thanks,
Harald
From ef96d7d360c088d68e3b405401bdb8b589d562f2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 9 Mar 2023 18:59:08 +0100
Subject: [PATCH] Fortran: fix ICE with bind(c) in block data [PR104332]
gcc/fortran/ChangeLog:
PR fortran/104332
* resolve.cc (resolve_symbol):
Dear all,
I've committed the attached patch to mainline as obvious after
regtesting on x86_64-pc-linux-gnu.
https://gcc.gnu.org/g:2cf5f485e0351bb1faf46196a99e524688f3966e
commit r13-6605-g2cf5f485e0351bb1faf46196a99e524688f3966e
Author: Harald Anlauf
Date: Sat Mar 11 15:37:37 2023
gfortran that
are very likely unrelated to the interface checks. I consider
this rather as post 13-release stuff.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 4453686ae4e70c14a0898c6687db912fa84ece9f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 14 Mar 2023 20
Hi Tobias,
Am 15.03.23 um 10:10 schrieb Tobias Burnus:
Hi Harald,
On 14.03.23 20:38, Harald Anlauf wrote:
The testcase covers only non-coarray cases, as playing with
coarray variants hit pre-exisiting issues in gfortran that
are very likely unrelated to the interface checks.
I concur (but
obvious, see attached patch.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 6406f19855a3b664597d75369f0935d3d31384dc Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 14 May 2023 21:53:51 +0200
Subject: [PATCH] Fortran: CLASS pointer function result in variable
removes the comparison for size > 0 also has the bonus that
it fixes a minor memory leak for the size==0 case...
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 9d2995d2c1cf5708e3297fc7cffb5184d45a65cb Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 17 May 2023 20:39
From bfb708fdb6c313473a3054be710c630dcdebf69d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 21 May 2023 22:25:29 +0200
Subject: [PATCH] Fortran: checking and simplification of RESHAPE intrinsic
[PR103794]
gcc/fortran/ChangeLog:
PR fortran/103794
* check.cc (gfc_check_reshape): Expand
mainline?
Thanks,
Harald
From 738bdcce46bd760fcafd1eb56700c8824621266f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 24 May 2023 21:04:43 +0200
Subject: [PATCH] Fortran: reject bad DIM argument of SIZE intrinsic in
simplification [PR104350]
gcc/fortran/ChangeLog:
PR fortran/104350
Dear all,
the attached patch is pretty much self-explaining: check for bounds violation
when initializing a substring in a data statement and treat the resulting error.
If more detailed information should be emitted with the error message, I'm
open for suggestions.
Regtested on x86_64-pc-linux-g
Hi Thomas,
> Gesendet: Montag, 25. Januar 2021 um 19:58 Uhr
> Von: "Thomas Koenig"
> a.f90:3:10:
>
> 3 | print a(0:3)
>| 1
> Error: Substring start index at (1) is less than one
> a.f90:4:10:
>
> 4 | print a(1:4)
>| 1
> Error: Substring end index a
Dear all,
the fix for this ICE is obvious: make gfc_call_malloc behave as documented.
Apparently the special case in question was not exercised in the testsuite.
Regtested on x86_64-pc-linux-gnu.
OK for master / backports?
Should the testcase be moved to the gomp/ subdirectory?
Thanks,
Harald
Hi Thomas,
> > Should the testcase be moved to the gomp/ subdirectory?
> Yes. It's a compile-time test, and it will then only be run
> if the the compiler can do OpenMP.
>
> You will not need the
>
> +! { dg-options "-fopenmp" }
>
> line, then.
Adjusted and committed as r11-6950-g33a7a93218b1393d
Dear all,
the PR reports an issue detected with an ASAN instrumented compiler,
which can also be verified with valgrind. It appears that the state
of gfc_new_block could be such that it should not be dereferenced.
Reversing the order of condition evaluation helped.
I failed to find out why this
Dear all,
we should not clobber the pointer in case of an allocatable scalar being
an intent(out) dummy argument to a procedure.
Regtested on x86_64-pc-linux-gnu.
OK for master? Since this is a regression, also for backports to 10/9?
Thanks,
Harald
PR fortran/99169 - Do not clobber allocatab
Dear all,
when simplifying the RESHAPE intrinsic we lost the string length when
the resulting array had size zero. The attached patch sets the resulting
length from the source.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
PR fortran/99206 - ICE in add_init_expr_to_sym, a
Dear all,
under certain circumstances a call to MATMUL for rank-2 times rank-1
would invoke a highly tuned rank-2 times rank-2 algorithm which could
lead to invalid reads and writes. The solution is to check the rank
of the second argument to matmul and fall back to a regular algorithm
for rank-1
Dear all,
the present PR has two issues. The first one, addressed by this patch,
was about accepting invalid code where a variable appeared both in a
declaration with PARAMETER as well as in a DATA statement, which could
lead to an ICE. We now reject this.
(There is a separate issue about combi
Early ping.
Harald
> Gesendet: Dienstag, 23. Februar 2021 um 22:46 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on
> temporary array accesses invalid memory
&g
Hi Jerry,
> Yes, OK, however, have you been able to test performance. I am only
> curious. There was a test program we used back when this code was first
> implemented in bugzilla. I do not remember the PR number off hand.
as you mentioned in a private mail, it was PR51119, and the timing program
Here's now my third attempt to fix this PR, taking into account
the comments by Tobias and Bernhard.
> > On 10.06.21 20:52, Harald Anlauf via Fortran wrote:
> > > +static bool
> > > +substring_has_constant_len (gfc_expr *e)
> > > +{
> > > +
Dear all,
here's the second part that should fix this regression for good.
The patch also adjusts the warning message to make it easier to
understand, using the suggestion by Tobias (see PR).
Since F2018 in principle makes RECURSIVE the default, which might
conflict with the purpose of the testca
Dear Fortranners,
I intend to commit the following pretty obvious fix within the next
24 hours unless there are objections.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran: ICE with automatic character object, save, and various options
gcc/fortran/ChangeLog:
PR fortran/68568
Dear all,
the checks for the STAT= and ERRMSG= arguments to the coarray SYNC statements
did not properly handle several cases, such as named constants (parameters).
While fixing this, I adjusted the code similarly to what was recently done
for (DE)ALLOCATE. We now also accept function references
*Ping*
> Gesendet: Dienstag, 03. August 2021 um 23:17 Uhr
> Von: "Harald Anlauf"
> An: "Harald Anlauf"
> Cc: "Tobias Burnus" , "Bernhard Reutner-Fischer"
> , "Harald Anlauf via Gcc-patches"
> , "fortran"
> Be
*Ping*
> Gesendet: Mittwoch, 04. August 2021 um 23:09 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH, part2] PR fortran/98411 [10/11/12 Regression] Pointless:
> Array larger than ‘-fmax-stack-var-size=’, ...
>
>
Hi Tobias,
> Gesendet: Mittwoch, 18. August 2021 um 12:22 Uhr
> Von: "Tobias Burnus"
> > Note, however, that gfc_simplify_len still won't handle neither
> > deferred strings nor their substrings.
> >
> > I think there is nothing to simplify at compile time here.
>
> Obviously, nonsubstrings can
Hi Tobias,
> I am inclined to say that the Intel compiler has a bug by not
> accepting it – but as written before, I regard sub-string length
> (esp. with const expr) inquiries as an odd corner case which
> is unlikely to occur in real-world code.
ok.
> Still does not work – or rather: ...%t(:)(
Hi!
> Gesendet: Freitag, 20. August 2021 um 02:21 Uhr
> Von: "H.J. Lu"
> This may have broken bootstrap on 32-bit hosts:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html
I do not understand the error message:
../../src-master/gcc/fortran/simplify.c: In function ‘bool
Hi Jakob,
thanks for the detailed explanation!
> The other much easier but uglier option is to use a temporary buffer:
> char buffer[21];
> sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val);
> gfc_error ("... %s ...", ... buffer ...);
> This works, as it uses the host sprintf i.e. *print
> Gesendet: Freitag, 20. August 2021 um 12:12 Uhr
> Von: "Jakub Jelinek"
> I have verified it fixes i686-linux bootstrap.
> But the new testcase doesn't trigger any of those new errors, is something
> else in the testsuite covering those or do you have some short snippet that
> could verify the e
Dear all,
I've just pushed the fix for the bootstrap breakage as confirmed by Jakub.
commit r12-3043-g12f22906d3c025e7edb60e3264dc9cd27a49e3e1
Author: Harald Anlauf
Date: Fri Aug 20 13:38:00 2021 +0200
Fortran - use temporary char buffer for passing HOST_WIDE_INT to gfc_error
> Gesendet: Freitag, 20. August 2021 um 14:01 Uhr
> Von: "Tobias Burnus"
> On 20.08.21 12:53, Harald Anlauf wrote:
>
> > I played with variations of the testcase by specifying illegal
> > substring bounds, but all these cases were caught in a different
&g
Hi Tobias,
> LGTM – I am fine with either variant, but I am slightly inclined to
> removing the gcc_assert*
> – as I believe that the existing checks come early enough and do seem to
> work well.
I played some more and found additional cases that we hadn't discussed
before. (At least I hadn't th
Dear Fortranners,
here's a pretty obvious one: we didn't properly check the arguments
for intrinsics when these had to be ALLOCATABLE and in the case that
argument was a coarray object. Simple solution: just reuse a check
that was used for pointer etc.
Regtested on x86_64-pc-linux-gnu. OK for m
Dear all,
the ICE in the original testcase does no longer occur but leads to an
error in a later stage of compilation, and we accepted invalid code.
(Cross-checked with other compilers, such as Intel and NAG).
F2018 states:
15.6.2.6 ENTRY statement
(3) ... If the characteristics of the result
The check of arguments to ALLOCATE did not properly implement
F2008:C628 / F2018:C932, as it excluded unlimited polymophics,
in contrast to the standard text. Fix this.
Committed Steve's patch as obvious after regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran - correct check for constr
A whitespace issue during parsing.
Committed Steve's patch as obvious after regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran - fix whitespace issue during parsing of assigned goto
gcc/fortran/ChangeLog:
PR fortran/102113
* match.c (gfc_match_goto): Allow for whitespac
There was an issue when trying to use an element from an array constructor
which was a broken in a way probably only Gerhard could conceive.
We hit an assert that can be replaced by more robust code.
Patch is basically Steve's.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
I intend to commit the fix to the error message using the patch below
within the next 24h unless there are objections or better suggestions.
The unchanged part of the error message is already covered by
gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03 and does
not need to be adapted.
Thanks,
u and pushed to mainline as
commit r13-2690-g7bd4deb2a7c1394550610ab27507d1ed2af817c2
Thanks,
Harald
From 7bd4deb2a7c1394550610ab27507d1ed2af817c2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 15 Sep 2022 22:06:53 +0200
Subject: [PATCH] Fortran: error recovery for bad deferred character l
.
Committed to mainline after regtesting on x86_64-pc-linux-gnu
as commit r13-2691-g2b75d5f533b9d6b39f4055949aff64ed0d22dd24
This is a 10/11/12/13 regression, so I will check if it can
be backported.
Thanks,
Harald
From 2b75d5f533b9d6b39f4055949aff64ed0d22dd24 Mon Sep 17 00:00:00 2001
From: Harald
On 18.09.22 12:23, Thomas Koenig via Gcc-patches wrote:
On 18.09.22 11:10, Mikael Morin wrote:
It is unfortunate as there is some desirable behavior within reach here.
I think some of the desired behavior can still be salvaged. For
example, for
subroutine foo(a,n)
integer :: n
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it the converse that is true?
Assumed shape can be non-contiguous so have to be excluded, but
on on that.
Thanks,
Harald
From 0b19cfc098554572279c8d19997df4823b426191 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 19 Sep 2022 22:00:45 +0200
Subject: [PATCH] Fortran: Fix function attributes [PR100132]
gcc/fortran/ChangeLog:
PR fortran/100132
* trans-types.cc (create_fn_spec): Fi
Am 20.09.22 um 13:51 schrieb Tobias Burnus:
In several cases, one just wants to have the address where an object starts
without requiring the detour via 'c_loc' and the (locally) required
'target'
attribute.
In principle, type(*),dimension(*) of TS29113 permits this, except that
'dimension(*)'
c092
Thanks,
Harald
From 8dbb15bc2d019488240c1e69d93121b0347ac092 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 20 Sep 2022 22:23:43 +0200
Subject: [PATCH] Fortran: NULL pointer dereference in invalid simplification
[PR106985]
gcc/fortran/ChangeLog:
PR fortran/106985
* exp
ine as
https://gcc.gnu.org/g:5976fbf9d5dd9542fcb82eebb2185886fd52d000
The PR is marked as a 10/11/12/13 regression, thus I plan to
backport.
Thanks,
Harald
From 5976fbf9d5dd9542fcb82eebb2185886fd52d000 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 20 Sep 2022 22:41:48 +0200
Subject: [P
Am 19.09.22 um 22:50 schrieb Mikael Morin:
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t
0259762271b2eb430e058b0bff4d7b11513c48c4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 21 Sep 2022 19:55:30 +0200
Subject: [PATCH] Fortran: fix ICE in generate_coarray_sym_init [PR82868]
gcc/fortran/ChangeLog:
PR fortran/82868
* trans-decl.cc (generate_coarray_sym_init): Skip symbol
if attr.associate_var
Hi Mikael,
Am 21.09.22 um 20:56 schrieb Mikael Morin:
Le 21/09/2022 à 11:57, Thomas Koenig a écrit :
Hi Harald,
I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression
Dear all,
the patch for this PR was submitted for review by Jose here:
https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html
but unfortunately was never reviewed.
I verified that it works on mainline and x86_64-pc-linux-gnu,
and I think that it is fine.
Although the above mail suggest
Dear all,
the patch for these PRs was submitted for review by Jose here:
https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
but unfortunately was never reviewed.
I verified that the rebased patch still works on mainline and
x86_64-pc-linux-gnu, and I think that it is fine. It is al
testcase by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This is a 10/11/12/13 regression and shall be backported.
Thanks,
Harald
From 80285cdad1fe98c52ebf38f9f66070b2a50191c6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 27 Sep 2022 20:54:28 +0200
Subject: [PATCH
Am 04.10.22 um 17:12 schrieb Ben Boeckel:
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Is there a reason that you are touching so many frontends?
diff --gi
l not
have a value that is a procedure pointer.
Attached patch generates an error instead.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 3b15fe83830c1e75339114e0241e9d2158393017 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 4 Oct 2022 21:19:21 +0200
Subject: [
en we try to recover from these errors, and tries to handle
all unary and binary arithmetic expressions.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From ad892a270c504def2f8f84494d5c7bcba9aef27f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 4 Oct 2022 23:04:06 +
for mainline?
And thanks for your comments!
Harald
From 70cba7da18023282546b9a5d80e976fc3744d732 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 5 Oct 2022 22:25:14 +0200
Subject: [PATCH] Fortran: reject procedures and procedure pointers as IO
element [PR107074]
gcc/fortran/ChangeLo
Hi Mikael,
> Gesendet: Mittwoch, 05. Oktober 2022 um 11:23 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf" , "fortran" ,
> "gcc-patches"
> Betreff: Re: [PATCH] Fortran: error recovery for invalid types in array
> constructors [PR107
quent
gfc_simplify_expr (result, 1);
seems to fail in interesting cases (as in PR105371).
So that is something to look into...
Cheers,
Harald
> Gesendet: Donnerstag, 06. Oktober 2022 um 22:32 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf"
> Cc: &qu
Hi Mikael,
> Gesendet: Donnerstag, 06. Oktober 2022 um 22:14 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf"
> Cc: "fortran" , "gcc-patches"
> Betreff: Re: [PATCH, v2] Fortran: error recovery for invalid types in array
> constructors [
Am 07.10.22 um 10:01 schrieb Mikael Morin:
Le 06/10/2022 à 23:36, Harald Anlauf a écrit :
For example, for this case:
[real :: 2] * [real :: +(.true.)]
First there is a "root" invocation of reduce binary with arguments [real
:: 2] and [real :: +(.true.)]
The root invocation of red
Hi Mikael,
Am 07.10.22 um 22:26 schrieb Mikael Morin:
Le 07/10/2022 à 21:47, Mikael Morin a écrit :
Let me have a look.
The attached patch works with your test, I just moved the checks into
the loops.
I'm now checking the patch against the full fortran testsuite.
I'm (finally) fine with that
-linux-gnu. OK for mainline?
Thanks,
Harald
From 4db0aba8309a2c7e2c7ac95195621dff02e9796c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 9 Oct 2022 20:43:32 +0200
Subject: [PATCH] Fortran: fix check of polymorphic elements in data transfers
[PR100971]
gcc/fortran/ChangeLog:
PR fortran
source expression.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 87dae7eb9d4cc76060d258ba99bc53f62c7130f2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 11 Oct 2022 20:37:42 +0200
Subject: [PATCH] Fortran: check types of source expressions before conversion
/, keeping an internal error if any
unhandled type shows up,
- numeric types for **
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From a95f251504bcb8ba28b7db1d2b7990631c761e9c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 11 Oct 2022 22:08:48 +0200
Subject: [PATC
ope I got you right. The attached patch fixes your variant
as well as the original testcase, and regtests fine.
Just to be sure: is this what you were thinking of?
Thanks for the very constructive review!
Harald
From e4816e150c31e127c3b6dc0032ae533a2d42 Mon Sep 17 00:00:00 2001
From: Har
Hi Tobias,
Am 07.03.22 um 15:01 schrieb Tobias Burnus:
The problem is that inside the main program,
y = f(z)
where the the result of z is
type(t) :: z(size(x%a))
and 'x' is a dummy argument.
'x' looses the attr.dummy in gfc_add_interface_mapping
and this leads to an additional indirect re
to 11-branch.
Thanks,
Harald
From e3e369dad6cbecb1b490b3f3b154c600fba5a6f3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 8 Mar 2022 21:47:04 +0100
Subject: [PATCH] Fortran: do not frontend-optimize MINLOC/MAXLOC for character
arrays
gcc/fortran/ChangeLog:
PR fortran/104811
* fro
Hi Tobias,
Am 07.03.22 um 15:16 schrieb Tobias Burnus:
Pre-remark: Related NULL, there some accepts-invalid issues, not
addressed in this
patch. See https://gcc.gnu.org/PR104819
This patch fixes an ICE (12 regression) with NULL() that has no MOLD
argument.
the patch does fix the ICE. But giv
601 - 700 of 1080 matches
Mail list logo
