ially that test case;
however, I checked whether some #if 0 could be removed - and indeed all
but one could be removed, i.e. more code actually works - whether fixed
on the generic gfortran side or on the OpenMP, I don't know but I also
don't care as long as it works :-) Committed as
On Sun, Mar 23, 2025 at 10:09:46AM +0100, Thomas Koenig wrote:
> Hi Paul,
>
> > By the way, the standard just specifies integer for 'dim' in reduce,
> > which I take to mean it should be default_integer_kind.
>
> Hmm... I'm not sure that this is actually the case; I believe it
> can actually be a
Hi Paul,
By the way, the standard just specifies integer for 'dim' in reduce,
which I take to mean it should be default_integer_kind.
Hmm... I'm not sure that this is actually the case; I believe it
can actually be any integer kind, although anything larger than
default integer would be kind o
e to time. I wish there was a
> method to stop int32_t (and its typedef-alias GFC_INTEGER_4)
> being type-compatible with int. The commit message is
> almost the same as that for r15-6427-ga5b1f3e14ae635.
>
> Committed as obvious after a build of libgfortran for
> cris-elf succee
message is
almost the same as that for r15-6427-ga5b1f3e14ae635.
Committed as obvious after a build of libgfortran for
cris-elf succeeded with this patch.
-- >8 --
Without this, after r15-8650-g94fa9f4d27bac5, you'll see,
for targets where GFC_INTEGER_4 alias int32_t is a typedef
of long int (b
sue does not manifest for in-tree testing when the system
provides what is needed.)
Committed as r15-8085-g2d5c1e5149809f.
Thanks for the report!
Tobias
commit 2d5c1e5149809f978ea2c07517de13fdbb925de6
Author: Tobias Burnus
Date: Mon Mar 17 10:12:44 2025 +0100
Move gfortran.dg/
Dear all,
while testing different stuff using code from the initial commit,
I figured that I copy-pasted erroneous code that could lead to
an infinite loop which did not update its control variable,
and an unhandled REF_INQUIRY in a switch statement.
Fixed and committed as simple and obvious
Hi!
ICE on this test was fixed by r15-2131. This just adds test for it.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2025-03-06 Jakub Jelinek
PR fortran/104826
* gfortran.dg/gomp/pr104826.f90: New test.
--- gcc/testsuite/gfortran.dg
With a compiler setup to compile (also) for nvptx offloading,
the testcase triggered a bogus error - and that prevents in
addition the gimple scan.
Fixed by adding an xfail and an xfailed dg-bogus.
The issue itself is the known https://gcc.gnu.org/PR118694
Committed as obvious asr15-7606
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
Hello world,
I just committed Andrew's patch from the PR as obvious as
r15-7557-gbf84e5e64662f8f0fdebfc0212e32bfca678f9eb .
Best regards
Thomas
Remove defunct web site for site of Fortran preprocessor.
gcc/fortran/ChangeLog:
PR fortran/1
Hello world,
I just committed the fix for PR 11845 as obvious and simple, as
r15-7552-gfd00010ba21c04bddb20aef52f62de5636075067 .
Fix PR 118884, Lapack build failure.
The fix for PR 118845 introduced new checks, which in turn exposed
a case where the typespec information on a symbol generated
For an example output, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113067#c2
Fixed in commit r15-7376-g6f95af4f22b641 which also fixes the testsuite
issue (off by one) of my previous commit for PR118745, ups!
Tobias
commit 6f95af4f22b641fbb3509f1436bce811d4e4acad
Author: Tobias Burnus
D
actually does not happen,
i.e. in that sense the code is "fine" as it does not crash. Still,
having NULL + some offset is not the best pointee.)
Committed asr15-7366-g3a5882707df50e Tobias
commit 3a5882707df50ed29905b3c47cbaa0868ea248c9
Author: Tobias Burnus
Date: Wed Feb 5 08:44:41
This was seemingly forgotten when UNROLL/TILE was added.
Committed asr15-7220-g7cd133a6e4b042 as obvious. Tobias
commit 7cd133a6e4b04262620489dbf4b4e3ae5e96c95f
Author: Tobias Burnus
Date: Mon Jan 27 00:35:17 2025 +0100
Fortran: In openmp.cc, uncomment unroll/tile lines of
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, 20 Jan 2
Dear all,
I've committed the attached obvious patch to reject an invalid NULL
in ALLOCATE after it was OK'ed in the PR by Steve.
Regtested on x86_64-pc-linux-gnu. Pushed as r15-6925-g892304f1fe .
Thanks,
Harald
From 892304f1fe3e808b9f498353c144f1ae0591 Mon Sep 17 00:00:00
Hello world,
I have committed the attached patch as obvious and simple after
regression-testing. I could not construct a test case that
actually failed, though, but the logic was wrong (pointer aliasing
and the field that was accessed had the wrong offset).
Commit is r15-6831
On 1/2/25 20:22, Maciej W. Rozycki wrote:
On Tue, 31 Dec 2024, Sandra Loosemore wrote:
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index d11d37761d9..b47180126ca 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -1577,7 +1577,7 @@ if @var{Y} is
On Tue, 31 Dec 2024, Sandra Loosemore wrote:
> diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
> index d11d37761d9..b47180126ca 100644
> --- a/gcc/fortran/intrinsic.texi
> +++ b/gcc/fortran/intrinsic.texi
> @@ -1577,7 +1577,7 @@ if @var{Y} is present, @var{X} shall be REAL.
>
gcc/fortran/ChangeLog
* gfortran.texi (Function ABI Documentation): Make menu ordering
consistent with subsection ordering.
---
gcc/fortran/gfortran.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index
In English usage, "that" introduces a restrictive clause while "which"
introduces a non-restrictive or descriptive clause. "That" is almost
never preceded by a comma while "which" often is. The Fortran manual
had many instances where these uses were reversed, or where a comma
was used with "that"
Continuing a series of patches to tidy the Fortran manual, this
installment fixes problems with inappropriate use of future tense and
adds some missing markup I noticed in passing.
gcc/fortran/ChangeLog
* intrinsic.texi: Grammar and markup fixes throughout
the file.
---
gcc/fortra
change to building libgfortran as C++? 1/2 :-)
Committed as obvious after a build of libgfortran for
cris-elf succeeded with this patch.
-- >8 --
Without this, after r15-6415-g586477d67bf2e3, you'll see,
for targets where int32_t is a typedef of long int (beware
of artificially broken lin
Hello world,
a change in the section heading of the documentation broke a link
in gcc-15/changes.html, fixed with this patch.
Best regards
Thomas
Author: Thomas Koenig
Date: Fri Nov 29 07:19:36 2024 +0100
Correct link to unsigned integers for Fortran.
* htdocs/gcc-
Hello world,
I just committed the attached documentatin patch as obvious,
in r15-5344-gbf00f117eb4b5527592029e39a3d79f2048745d8 .
Best regards
Thomas
Document that SELECT CASE works for unsigned.
gcc/fortran/ChangeLog:
* gfortran.texi: Document that SELECT CASE works for
On Sat, Nov 16, 2024 at 02:55:11PM +0100, Thomas Koenig wrote:
>
> Steve found a test case where unsigned constants were not handled
> in a module. Single-line patch committed as obvious and simple,
> r15-5341-g66096151afc6631f8f2a3458b154c5daa822b963 .
>
> Best regards
Hello world,
Steve found a test case where unsigned constants were not handled
in a module. Single-line patch committed as obvious and simple,
r15-5341-g66096151afc6631f8f2a3458b154c5daa822b963 .
Best regards
Thomas
Handle unsigned constants for module I/O.
gcc/fortran/ChangeLog
Committed attached patch as r15-4565-g0ecc45a88d7722. It removes
'terminal_width', an unused leftover before switching to the common
diagnostic, which I missed when doing the last cleanup. Best regards,
Tobias
commit 0ecc45a88d772268a3bd83af02759857da0826d4
Author: Tobias Burnus
D
see attached.
by re-adding a testcase which actually tests the builtin.
Committed as r15-4388-gee4fdda70f1080.
Tobias
commit ee4fdda70f1080bba5e49cadebc44333e19edeb4
Author: Tobias Burnus
Date: Wed Oct 16 16:15:40 2024 +0200
Add libgomp.oacc-fortran/acc_on_device-1-4.f
Kind of u
Committed as r15-4127-gb95ad25f9c9376
Hi Thomas,
Thomas Schwinge wrote:
On 2024-10-07T17:07:05+0200, Tobias Burnus wrote:
If anyone can reproduce this, I would be interested in the excess errors.
gfortran: fatal error: cannot read spec file 'libgomp.spec': No such file
or
dg-error needs an argument for "why" / a comment.
gcc/testsuite/ChangeLog:
PR fortran/116858
* gfortran.dg/initialization_25.f90: Fix dg-error arguments.
---
gcc/testsuite/gfortran.dg/initialization_25.f90 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/te
Only because I wrote earlier that I'd do this patch.
Committed as obvious. Sanity-checked by running the test in
a native tree as "make check-gcc-fortran
RUNTESTFLAGS=dg.exp=open_errors_2.f90"
-- >8 --
Now that fort.N files are removed by the testsuite
framework, remove t
The test was disabled/XFAIL'd informally in r0-100012-gcdc6637d7c78ec,
but r15-3890-g34bf6aa41ba539 didn't realize this, causing a FAIL.
Fix that by marking it as XFAIL per the original intent.
gcc/testsuite/ChangeLog:
PR fortran/35779
PR fortran/116858
* gfortran.dg/init
gcc/testsuite/ChangeLog:
* g++.dg/modules/reparent-1_c.C: Fix whitespace around '-' in dg
directive.
* gfortran.dg/initialization_25.f90: Ditto.
---
Committed as obvious.
gcc/testsuite/g++.dg/modules/reparent-1_c.C | 2 +-
gcc/testsuite/gfortran.dg/initialization_
exp: Ditto.
---
Committed as obvious.
gcc/testsuite/gfortran.dg/coarray/caf.exp | 2 +-
gcc/testsuite/lib/gfortran-dg.exp | 2 +-
gcc/testsuite/lib/gm2-dg.exp | 2 +-
gcc/testsuite/lib/go-dg.exp | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc
I just committed the fix for PR 116653 as obvious.
Unfortunately, I left out the description in the ChangeLog, I hope it
is clear enough.
Best regards
Thomas
https://gcc.gnu.org/g:5d9486c29938d79beb798dce1a5509da54fe8c9f
commit r15-3619-g5d9486c29938d79beb798dce1a5509da54fe8c9f
Hello world,
I just pushed Steve's patch for module support to trunk as obvious, as
https://gcc.gnu.org/g:2847a541c1f19b67ae84be8d0f6dc8e1f9371d16 .
Best regards
Thomas
gcc/fortran/ChangeLog:
* module.cc (bt_types): Add BT_UNSIGNED.
gcc/testsuite/ChangeLog:
* gfortra
This patch fixes an issue with unintialized variables causing random ICE.
Committed as r15-3581-g4e9265a474def9
* * *
However, follow-up work is needed as there are multiple issues:
* The check whether something is a identifier (integer parameter) and
not just a constant expression did fail
test ~ 65 minutes on the latter and ~ 85 minutes + ~ 70 minutes
> on the former, so if you can get it tested faster than that, go ahead and
> commit it, if not, I'll commit it when I'm done with testing.
> It certainly got past the point of the failed bootstraps already.
H
Dear all,
I've pushed the attached simple patch for initialization of local variables
to silence warnings for LTO builds after Sam James' confirmation as
https://gcc.gnu.org/g:2b23a444bcf7eb67cb04b431d8fd4fa6f65222de
Thanks,
Harald
From 2b23a444bcf7eb67cb04b431d8fd4fa6f65222de Mon Sep 17 00:00:
all' attribute ignored") and I
didn't run it with -m32, but it was reported by Haochen's script +
manually confirmed by him.
(Thanks for the report and checking – and sorry for the FAIL.)
Committed asr15-2401-g15158a8853a69f. Tobias
OpenMP target regions, but not yet OpenACC
compute
+ regions. @c The latter needs
'GOMP_NVPTX_NATIVE_GPU_THREAD_STACK_SIZE'.
I think an "in" (or 'within') is missing before OpenACC.
Yes, "...not yet within OpenACC compute regions", please.
Than
On 6/6/24 06:06, Tobias Burnus wrote:
Hi Thomas,
regarding the commit r15-1070-g3a4775d4403f2e /
https://gcc.gnu.org/r15-1070
First, thanks for adding I/O support to nvptx offloading.
I have a wording nit, to be confirmed by a native speaker:
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgom
Hi Thomas,
regarding the commit r15-1070-g3a4775d4403f2e / https://gcc.gnu.org/r15-1070
First, thanks for adding I/O support to nvptx offloading.
I have a wording nit, to be confirmed by a native speaker:
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
...
+@item I/O within OpenMP tar
Dear all,
the attached obvious patch fixes a frontend memleak that was introduced
recently, and which shows up when checking for inquiry references.
I came across it when working on pr115039.
Committed after regtesting as r15-391-g13b6ac4ebd04f0.
Thanks,
Harald
From
, considerably simplifying the Makefile rules to create
the version scripts.
Bootstrapped without regressions on i386-pc-solaris2.11 and
sparc-sun-solaris2.11, verifying that the version scripts are identical
except for the input filenames.
Committed to trunk.
Rainer
Dear all,
I've committed the attached simple & obvious patch for an ICE due to
an invalid read in frontend optimization after regtesting and an OK
by Jerry in the PR.
Pushed: https://gcc.gnu.org/g:3be2b8f475f22c531d6cef1b041c0573b3ea5133
As this PR is marked as a regression, I plan to
Some gfortran tests still contain references to long-obsolete Solaris 9.
This patch removes them.
Tested on i386-pc-solaris2.11.
Committed to trunk.
Rainer
--
-
Rainer Orth, Center for Biotechnology
Dear all,
commit r11-1235 for pr95331 addressed array bounds issues with
unlimited polymorphic array dummies, but caused regressions for
CLASS array dummies that lead to either wrong code with bounds-checking,
or an ICE. The solution is simple: add a check whether the dummy
is unlimited polymorph
Dear all,
I've pushed the attached obvious patch for a regression due to a
wrong array bounds check after regtesting on x86_64-pc-linux-gnu
and verification of the fix by the reporter in the PR.
https://gcc.gnu.org/g:94b2e6cb1cc4feb122bf77f19a657c97bffa9b42
Thanks,
Harald
From 94b2e6cb1cc4feb12
Dear all,
I've committed the attached, simple & obvious patch for a
gmp memory leak in gfc_get_nodesc_array_type that shows
up when running f951 under valgrind e.g. on testcase
gfortran.dg/class_optional_2.f90, after regtesting on
x86_64-pc-linux-gnu.
(Note that this does not ad
The following has been committed per discussion in the subject PR.
commit 95b70545331764c85079a1d0e1e19b605bda1456 (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLisle
Date: Wed Dec 13 19:04:50 2023 -0800
fortran: Add degree based trig functions for F2023
only on 64-bit targets, on 32-bit ones it is just 8 bytes,
> so the explicit matching of the * 16 multiplication only works on the
> former.
>
> Tested on x86_64-linux -m32/-m64, committed to trunk.
That was quick, thank you! Apologies for the breakage.
Julian
16 multiplication only works on the
former.
Tested on x86_64-linux -m32/-m64, committed to trunk.
2023-12-14 Jakub Jelinek
* c-c++-common/gomp/target-enter-data-1.c: Match also sizeof bar on
32-bit targets - 8 bytes - rather than just 16 bytes.
--- gcc/testsuite/c-c++-common/g
a1034...@rivosinc.com/T/#t
OK.
Jeff
Committed.
Patrick
See PR for a discussion whether this change is required for alignment (or
other) reasons
(looks as if not) - or"just" to match the indented order (arg names +
description) and
to silence a -Walloc-size warning.
Committed as r14-5148-g17df6ddcf11aef
(BTW: I don't think that it i
Dear all,
the attached simple patch fixes a memleak in the frontend when a
character literal is passed to a character,value dummy of a bind(c)
procedure, by relying on gfc_replace_expr to do the cleanup.
(This can be tested e.g. with gfortran.dg/bind_c_usage_13.f03
and running f951 under valgrind)
Yet another omission, the flag was not properly set for deeply buried
'omp teams' as I stopped too early when walking up the stack.
Now fixed by commit r14-2826-g081e25d3cfd86c
* * *
This was found when 'repairing' the feature on the OG13
(devel/omp/gcc-13) branch for metadirectives, cf. the se
The testcase should use dg-additional-options instead of dg-options to
not overwrite default compile flags that include path for finding
the IEEE modules.
gcc/testsuite/ChangeLog:
* gfortran.dg/ieee/comparisons_3.F90: Use dg-additional-options
instead of dg-options.
Tested on x86_64-linu
Hi Tobias!
On 2023-07-19T10:26:12+0200, Tobias Burnus wrote:
> Now committed as Rev. r14-2634-g85da0b40538fb0
On devel/omp/gcc-13 branch, the corresponding
commit b003e6511754dce475f7f5b0c5cd887a177e41b3
"OpenMP/Fortran: Non-rectangular loops with constant steps other than 1 or -1
[
Now committed as Rev. r14-2634-g85da0b40538fb0
Changes:
* I missed to updated another 'sorry' (msg wording change) - now fixed;
I also added it to the sorry-testcase file non-rectangular-loop-5.f90.
* I decided to retire the PR as several issues have been fixed and the
original tit
Committed the attached patch as r14-2582-g89d0f082b3c95f.
This is about OpenMP's uses_allocators clause to the 'target' directive.
Using the clause with predefined allocators as list arguments is
required if those allocators are used in a target region - unless
there is a
Hi all, hi Harald,
thanks for the review. I choose to use gfc_replace_expr() and retested.
Everything went fine now.
Also thank you clarifying the pdt as a component in a derived type and that
that is still a bug and I didn't do it wrong.
I have pushed the attached patch seconds ago.
Thanks for
Dear all,
the previous patches to this PR unfortunately caused a regression,
seen on Power big-endian systems/-m32 (pr110419), and while trying
to investigate on x86 also showed a regression (ICE) on cases that
were not covered in the testsuite before.
The original fix did not properly handle the
Dear all,
the first part of the patch came with a testcase that also exercised
code for constant string arguments, which was not touched by that patch
but seems to have caused runtime failures on big-endian platforms
(e.g. Power-* BE) for all optimization levels, and on x86 / -m32
at -O1 and highe
A rather obvious fix. The allocator(...) bit showed up with -fdump-parse-tree.
Committed as Rev. r14-1988-g99e3214f582b08
Side remark:
Regarding the example inside the commit log: OpenMP 5.1 permitted derived-type
components. Due to global wording changes, OpenMP 5.2 disabled it for both
the
he content of the OMP_* modules
(except for the API routines) but missed two recently added named constants,
which I now added.
Committed as r14-1936-ge9c1679c350be0.
Like always, comments are highly welcome!
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulf
constant 0x1 rather than some small number
on little-endian and if target doesn't have enough memory for 4 times
that (i.e. 16GB allocation), it ICEs.
Fixed thusly, bootstrapped/regtested on
{x86_64,i686,powerpc64le,aarch64,s390x}-linux, preapproved in bugzilla
by Harald, committed to trunk
l
On Fri, 2 Jun 2023 at 19:06, Harald Anlauf via Fortran
wrote:
Dear all,
I've committed that attached simple patch on behalf of Steve
after discussion in the PR and regtesting on x86_64-pc-linux-gnu.
It fixes a duplicate error message and an ICE.
Pushed a
Hi Harald,
It looks good to me. Thanks to you and Steve for the fix. I suggest
that it is such and obvious one that it deserved back-porting.
Cheers
Paul
On Fri, 2 Jun 2023 at 19:06, Harald Anlauf via Fortran
wrote:
>
> Dear all,
>
> I've committed that attached simple p
Dear all,
I've committed that attached simple patch on behalf of Steve
after discussion in the PR and regtesting on x86_64-pc-linux-gnu.
It fixes a duplicate error message and an ICE.
Pushed as r14-1505-gfae09dfc0e6bf4cfe35d817558827aea78c6426f .
Thanks,
Harald
I have now re-diffed the patch and cleaned up some comments, and spend
some time proof reading it myself. And have now committed it as
r14-1301-gd64e8e1224708e7f5b87c531aeb26f1ed07f91ff
As the subject line states, it adds parsing support for "!$omp allocate"
as declarative directi
The patch has now been committed as r14-931-g80bb0b8a81fdc5
The only change is that I added the &&VAR_P in 'if (sym->ts.deferred &&
VAR_P (length))' in trans-decl.cc just to avoid potential issues in case
length is not a var decl (but e.g. a '0' tree node
On 28 April 2023 09:26:06 CEST, Tobias Burnus wrote:
>Committed as r14-319-g7ebd4a1d61993c0a75e9ff3098aded21ef04a4da
> Only other changes are fixing the variable name a(b)breviated_modproc_decl
I think this is not good, I've mentioned it somewhere, i think, but I'll rename
it.
thanks!
Committed as r14-319-g7ebd4a1d61993c0a75e9ff3098aded21ef04a4da
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München
Dear all,
I've committed the attached patch which fixes a portability issue
when bootstrapping on Solaris. Discussed and confirmed in the PR
by Jonathan for Solaris and regtested by me on x86_64-pc-linux-gnu.
https://gcc.gnu.org/g:43816633afd275a9057232a6ebfdc19e441f09ec
(Unfortunatel
Hi Tobias,
I started applying my poor knowledge of regular expressions to fix this
last night and timed out. Thanks for doing it for me. I will look carefully
and learn from the master :-)
Is it really a regression, when a change exposes a latent bug? Never mind,
though, it's fixed.
Cheers
Paul
Commit r13-7137 fixes thethe dump issue with -m32, cf. attachment.
Tobias
On 09.04.23 00:11, haochen.jiang via Gcc-patches wrote:
Fortran: Fix dg directives and remove trailing whitespaces in testsuite
caused
FAIL: gfortran.dg/gomp/affinity-clause-1.f90 -O scan-tree-dump-times original
Dear all,
while looking at variations of testcases in pr107560, I discovered
a minor FE memleak that was introduced in the BOZ rework and is
fixed by the attached simple patch.
Regtested on x86_64-pc-linux-gnu on OK'ed in the PR by Steve.
Thanks,
Harald
From 833233a4aefc9981b671c1bda34676c20b76
nto GCC 14 once trunk has opened (and
after some simpler pending patches have been merged). It requires some
re-diffing to be more digestible.
* * *
OG12: This patch as been committed to the devel/omp/gcc-12 branch as
https://gcc.gnu.org/g:a63735b8034db65a33c359633462accd9d71d3b5
* * *
This patch
On OG12, the OpenMP deep-mapping support added a callback procedure to the
vtable.
That one did not handle error recovery well (ICE when a CLASS component as not
(class_)ok.
The attached patch has been committed as
https://gcc.gnu.org/g:9c18db65914a751e4a1d9330ccc1659fe5ef270d
and applies
Dear all,
I've committed the attached simple patch after discussion with
Steve (see PR). We need to reject alternate return arguments
of FINAL subroutines.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From 3e791f45ded89626bc1f9f8013728f6e035801b2 Mon Sep 17 00:00:00 2001
From: H
Hi Thomas,
On 25.02.23 10:11, Thomas Schwinge wrote:
Do to the scan patterns need adjusting, or is something wrong?
The former. Regarding:
* gfortran.dg/goacc/finalize-1.f - for 'acc exit data':
!$ACC EXIT DATA FINALIZE DELETE (del_f_p(2:5))
Here, 'map\\(to:del_f_p [pointer set]' chang
Dear all,
while checking f951 for memory leaks on testcases that appeared
relevant during work on pr108924, I found that the conversion
warning triggered by do_subscript_6.f90 uses a code path that
forgot to mpfr_clear a used variable.
The attached obvious patch fixes this - verified by valgrind.
Dear all,
as reported by Richard - although without a testcase - we leak
gmp memory in do_subscript(). The attached patch was derived
by inspection of the code pointed at by valgrind and regtested
on x86_64-pc-linux-gnu.
Committed as obvious as
commit r13-6336
Committed as obvious:
commit 061b13ed014ba0b6891800a5c7f852bf58e4d856
Author: Jerry DeLisle
Date: Thu Feb 16 18:13:56 2023 -0800
Fortran Tests: Allow passing on mingw.
gcc/testsuite/ChangeLog:
* gfortran.dg/bind_c_array_params_2.f90: Add *-*-ming* to
dg-final.
and
On Wed, Feb 15, 2023 at 10:28:00PM +0100, Harald Anlauf via Fortran wrote:
> 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-ga418129273725fd02e88
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
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:
Dear all,
the attached simple and obvious patch fixes a NULL pointer dereference
on an invalid use of a CLASS variable.
Committed to mainline after regtesting on x86_64-pc-linux-gnu as
https://gcc.gnu.org/g:2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a
Thanks,
Harald
From
Dear all,
the attached trivial and obvious patch replaces an internal error
on encountering an invalid kind in a character conversion by a
regular error recovery.
Pushed after regtesting on x86_64-pc-linux-gnu as
r13-5760-ga618b45ac41cf480f54c4fa4014aed6218931290
Thanks,
Harald
From a618b45ac41
Dear all,
the fix for PR108527 came with a testcase that revealed a latent
bug with array sections and invalid array declarations. The ICE
first popped up on powerpc64-linux-gnu (big endian), but the issue
was not so clear as such on x86_64-pc-linux-gnu, as it did not show
up e.g. in valgrind. T
Tested on x86_64-gnu-linux with -m32 and -m64. It was discussed on
#gfortran IRC and tested with MinGW64 with/by nightstrike.
Committed to mainline.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter
Dear all,
I've committed the attached simple and obvious patch by
Steve after regtesting on x86_64-pc-linux-gnu.
Instead of generating an internal error when wrong types
are passed to a bounds comparison, simply return false.
Committed:
https://gcc.gnu.
Dear all,
we ICE'd in the simplification of the transformational intrinsic
ANY when the passed ARRAY argument had an invalid declaration.
The reason was a reference to array->shape which was NULL.
Obvious solution: then just don't attempt to simplify.
Regtested on x86_64-pc-linux-gnu and pushed
On 12/19/22 2:29 AM, Jakub Jelinek wrote:
On Sat, Dec 17, 2022 at 09:12:43AM -0800, Jerry D via Gcc-patches wrote:
The attached patch fixes a regression and is a patch from Steve. I have
regression tested it and provided a test case. It is fairly simple and I
will commit under the "simple" rul
On Sat, Dec 17, 2022 at 09:12:43AM -0800, Jerry D via Gcc-patches wrote:
> The attached patch fixes a regression and is a patch from Steve. I have
> regression tested it and provided a test case. It is fairly simple and I
> will commit under the "simple" rule in a little while.
>
> Thanks Steve
On 09.12.22 22:12, Tobias Burnus wrote:
Found when working on the just submitted/committed patch.
Committed as r13-4590 – but it required a follow-up that I somehow
missed :-/ but that is now committed as well (as r13-4597).
Tobias
-
Siemens Electronic Design Automation GmbH
On Wed, Nov 16, 2022 at 10:58:18PM +0100, Harald Anlauf via Fortran wrote:
>
> @Steve: please close PR if you think everything is ok.
>
Thanks. I'll close the pr.
--
Steve
1 - 100 of 217 matches
Mail list logo
