[Patch, fortran] PR103508 - ICE in gfc_find_symtree, at fortran/symbol.c:2979

One liner fix found by Steve Kargl - thanks! Pushed as 'obvious' in r16-4016. Paul

[patch, wwwdocs] Mention -fexternal-blas64 option

Hello world, the attached patch mentions -fexternal-blas64 in the changes.html file for gcc16. Checked with "tidy -e" and by visual inspection with Firefox. Any comments or suggestions for better wording? OK to commit? Best regards Thomas diff --git a/htdocs/gcc-16/chan

Re: [patch, Fortran] Some more tweaks to -fexternal-matmul64

Hi Paul, It looks good to me. Thanks for the patch. Committed as 0f28eb8ab909712aaf6517c0c818e5b36de32383. Thanks for the review! Best regards Thomas

Re: [patch, Fortran] Some more tweaks to -fexternal-matmul64

Hi Thomas, It looks good to me. Thanks for the patch. Regards Paul On Sun, 21 Sept 2025 at 12:10, Thomas Koenig wrote: > > Hello world, > > the attached patch is fairly self-explanatory. > > Regression-tested with > > make -j8 check-fortran RUNTESTFLAGS="--targe

[patch, Fortran] Some more tweaks to -fexternal-matmul64

Hello world, the attached patch is fairly self-explanatory. Regression-tested with make -j8 check-fortran RUNTESTFLAGS="--target_board=unix\{,-m32\}" OK for trunk? Best regards Thomas Fix test case and add errors for when -fexternal-blas64 makse no sense. -fexter

[Patch, fortran] PR83746 - Errors using the max intrinsic in a PDT length parameter expression for a function result

This one was painfully obvious once I looked in the right place :-( Pushed to mainline as r16-3989. Paul Fortran: Intrinsic functions in PDT specification exprs. [PR83746] 2025-09-19 Paul Thomas gcc/fortran PR fortran/83746 * trans-array.cc (structure_alloc_comps): Add the pre and post

Re: [patch, Fortran] Implement -fexternal-blas64, PR 121161

Am 18.09.25 um 19:02 schrieb H.J. Lu: FAIL: gfortran.dg/matmul_blas_3.f90 -O scan-tree-dump-not original "integer\\(kind=4\\)" Hm... would ! { dg-require-effective-target lp64 } be the right way to fix this? Best regards Thomas

[Patch, fortran] PR121948 - gfortran rejects structure constructor without (default) derived type parameter

Hi All, The recent change of PDT constructors to allow "structure-constructor is type-name [ ( type-param-spec-list ) ]( [ component-spec-list ] )" missed the possibility that the (type-param-spec-list) is optional, if default values are available. This patch permits this by looking for a left han

Re: [patch, Fortran] Implement -fexternal-blas64, PR 121161

Hi Steve, On Tue, Sep 16, 2025 at 10:10:16PM +0200, Thomas Koenig wrote: Hello world, the attached patch implements a new option, -fexternal-blas64, so people can use 64-bit libraries for external BLAS, like Intel MKL. Regression-tested. OK for trunk? Thanks. I've read through the

[patch, Fortran] Implement -fexternal-blas64, PR 121161

Hello world, the attached patch implements a new option, -fexternal-blas64, so people can use 64-bit libraries for external BLAS, like Intel MKL. Regression-tested. OK for trunk? Best regards Thomas Implement -fexternal-blas64 option. Libraries like Intel MKL use 64-bit integers in

Re: [Patch, fortran] PR83763 - PDT dependency in assignment

Hi Jerry, Thanks for the review and testing. Pushed as r16-3851. As to the memory leak in pdt_3.f03, I will take a look at it this morning. I will raise a PR for it whatever I find. Regards Paul On Sun, 14 Sept 2025 at 20:14, Jerry D wrote: > > On 9/14/25 6:04 AM, Paul Richard Thomas

[Patch, fortran] PR83763 - PDT dependency in assignment

Hi All, The title in the PR is, "Bug 83763 - PDT variable sees content deallocated if variable is passed as an input to a function, and the function result is assigned to that same variable". The above is slightly more concise! The fix for the PR itself comprises the chunks in trans-expr.cc. On c

[Fix, fortran] PR84008 -ICE accessing kind and len parameters

Hi All, This 'obvious' fix has been pushed as r16-3648. Paul Change.Logs Description: Binary data diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index d51301aec44..bd0e6e9f540 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -5871,13 +5871,47 @@ gfc_resolve_subs

[Patch, fortran] PR84119 - Type parameter inquiry for PDT returns array instead of scalar

Hi All, This patch corrects the current behaviour of gfortran to return arrays for type parameter references, when the designator is an array. It reuses existing code, as described in the ChangeLog. The necessary modification to pdt_20.f03 is a sufficient test. Regtests on FC42/x86_64. OK for mai

Re: [Patch, fortran] PR84119 - Type parameter inquiry for PDT returns array instead of scalar

Paul On Sat, 6 Sept 2025 at 17:20, Jerry D wrote: > On 9/6/25 5:25 AM, Paul Richard Thomas wrote: > > Hi All, > > > > This patch corrects the current behaviour of gfortran to return arrays > > for type parameter references, when the designator is an array. It > >

Re: [Patch fortran] PR84432 & PR114815 - test for non-conforming default PDT initializers

Nit eradicated and pushed as r16-3590. Thanks Paul On Thu, 4 Sept 2025 at 21:53, Harald Anlauf wrote: > Hi Paul! > > Am 04.09.25 um 20:46 schrieb Paul Richard Thomas: > > Hi All, > > > > PDT components with default initializers must have type parameter and > &g

Re: [Patch, fortran] PR87362 - [PDT] ICE on variable declaration with undefined PDT parameter

Duly swung! Pushed as r16-3589. Thanks Paul On Thu, 4 Sept 2025 at 17:21, Jerry D wrote: > On 9/4/25 6:22 AM, Paul Richard Thomas wrote: > > Hi All, > > > > Although PR87362 is marked as fixed, the error becomes rather more > explicit with > > this patch,

[Patch fortran] PR84432 & PR114815 - test for non-conforming default PDT initializers

Hi All, PDT components with default initializers must have type parameter and length expressions that reduce to compile time integer constants. The chunk in expr.cc verifies that this is the case for array bounds and character lengths. This error checking results in pdt_26.f03 segfaulting because

[Patch, fortran] PR87362 - [PDT] ICE on variable declaration with undefined PDT parameter

Hi All, Although PR87362 is marked as fixed, the error becomes rather more explicit with this patch, which I actually developed for PR102457. Regtests on FC42/x86_64 - OK for mainline Paul Change.Logs Description: Binary data diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc index 1e91b57

[Patch, fortran] PR87669 -Select type, incorrect handling of parameterized derived type

Hi All, The attached ChangeLogs explain the chunk in expr.cc. The chunk in is_extension_of was something of a surprise to me since I thought that we had stopped using the hash to identify derived types and to restrict their use to intrinsic types a long time ago. Using the vptr location is unambig

Re: [PATCH] Fortran: fix TRANSFER with rank 1 unlimited polymorphic SOURCE [PR121263]

Hi Harald, This is fine. The use of GFC_DECL_SAVED_DESCRIPTOR occurs all over the place and is necessitated by gfortran's handling of dummy arrays. I wonder how many other such cases are waiting out there? Thanks for the patch and to you, Jerry, for giving it a whirl. Paul On Tue, 2 Sept 2025

Re: [Patch, fortran] PR84432 - [F08] Detect illegal component initialization in pdt_27.f03

the noise. Paul On Tue, 2 Sept 2025 at 22:09, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > This is another straightforward patch that detects variables with > non-integer type being used as PDT parameters. Note that much of the time, > when b

[Patch, fortran] PR84432 - [F08] Detect illegal component initialization in pdt_27.f03

Hi All, This is another straightforward patch that detects variables with non-integer type being used as PDT parameters. Note that much of the time, when being parsed, variable expressions have type BT_PROCEDURE and so the type of the symbol must be checked. The parameter fed to the PDT in pr95090

Re: [Patch, fortran] PR87669 -Select type, incorrect handling of parameterized derived type

ards Paul On Tue, 2 Sept 2025 at 18:13, Jerry D wrote: > On 9/2/25 4:43 AM, Paul Richard Thomas wrote: > > Hi All, > > > > The attached ChangeLogs explain the chunk in expr.cc. The chunk > > in is_extension_of was something of a surprise to me since I thought > t

[Patch, fortran] PR89707 - [F03] PDT with procedure pointer component

Hi All, This is another relatively straight forward PDT patch that enables typebound procedures with a parameterized kind specification for the interface. Regtests with FC42/x86_64. OK for mainline Paul PS Patches for PRs 84432, 103414 & 114815 are on the way. With all of the pending patches ap

Re: [Patch, fortran] PR99709 - [PDT] VALUE attribute for an object with nonconstant length parameter

Pushed as r16-3481. Thanks for your help in getting it over the line! Paul On Sun, 31 Aug 2025 at 12:45, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Harald and Jerry, > > As it happens, I had done the regtesting, caught the failures of > value_opti

Re: [Patch, fortran] PR99709 - [PDT] VALUE attribute for an object with nonconstant length parameter

> On 8/30/25 9:16 AM, Harald Anlauf wrote: > >> On 8/30/25 18:04, Jerry D wrote: > >>> On 8/30/25 8:04 AM, Paul Richard Thomas wrote: > >>>> Hi All, > >>>> > >>>> This patch is only a temporary fix because the chunks in trans

[Patch, fortran] PR99709 - [PDT] VALUE attribute for an object with nonconstant length parameter

Hi All, This patch is only a temporary fix because the chunks in trans-array.cc are representation dependent. As a whole, the patch is so straightforward that the ChangeLog serves as an explanation. Regtests with FC32/x86_64 - OK for mainline? Paul Change.Logs Description: Binary data diff --g

[RFC] c++: Vectorizing default struct and std::array equality

>From 289487b58709575a90fca0cbebc6ae968aba73ab Mon Sep 17 00:00:00 2001 From: Thomas de Bock Date: Thu, 28 Aug 2025 16:10:08 +0100 Subject: [PATCH] Vectorizing default struct and std::array equality --- Notes: Added 2 SSA passes enabling the vectorization of default equality on structs

[Patch, fortran] PR82843 - (PDT) Constructors with PDT components do not work.

This patch corrects errors due to PDT components taking the PDT template as their type in PDT constructors and component references. The latter took a long time to debug because yours truly did not catch on to the basic problem until a light bulb moment, triggered by an excess of coffee :-) With th

[Patch, fortran] PR82205 - parametrized derived types, problems with initialization

This patch corrects the form of PDT constructors so that they are standard conforming: structure-constructor is type-name [ ( type-param-spec-list ) ] ( [ component-spec-list ] ) At present, the type-param-spec-list for PDTs is rolled into the component-spec-list. The patch separates the type-par

Re: [Patch, fortran] PR84122 redux - Incorrect statement sequence in PDT definition

Committed as r16-3308. Thanks, Jerry. Paul On Wed, 20 Aug 2025 at 19:27, Jerry D wrote: > On 8/20/25 8:54 AM, Paul Richard Thomas wrote: > > Hi Jerry, > > > > The attached patch fixes both pr84122 and pr85942. Beyond the more > > elaborate chunk in parse.cc,

Re: [Patch, fortran] PR84122 redux - Incorrect statement sequence in PDT definition

PDT object so that the type parameters do not appear. A few more parse errors will be fixed before I hit the representation of PDTs(pr82649). Cheers Paul On Tue, 19 Aug 2025 at 17:23, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Jerry, > > Thanks for taking a l

Re: [Patch, fortran] PR84122 - Incorrect statement sequence in PDT definition

!.. private by default !.. type data real(kind=k) :: m_a(c,r) end type mat_t Sorry about that. Thanks again Paul On Tue, 19 Aug 2025 at 17:13, Jerry D wrote: > On 8/19/25 4:15 AM, Paul Richard Thomas wrote: > > Hi All, > > > > I have just noticed that line

Re: [Patch, fortran] PR84122 - Incorrect statement sequence in PDT definition

Hi All, I have just noticed that line 9 in the testcase is not what was intended. It should read: integer, len, PUBLIC :: idim ! { dg-error "is not allowed" } and that the second dg-error should be removed. Paul On Tue, 19 Aug 2025 at 10:58, Paul Richard Thomas < paul.richard.tho

[Patch, fortran] PR84122 - Incorrect statement sequence in PDT definition

This is a trivial patch that enforces the requirement that PDT parameters do not have an access specification and appear before a PRIVATE statement within the derived type. Regtests on FC42/x86_64. OK for mainline? Paul diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc index 300a7a36fbd..d

[Patch, fortran] PR89092 - Host-associated generic used instead of use-associated TBP in call

The attached patch is utterly trivial. The only useful attribute that FooPrivate possesses to detect that it has been declared is 'subroutine'. This was missed in the attribute test in resolve.cc(was_declared). Adding it fixes the problem and regtests on FC42/x86_64. OK for mainline and some judi

Re: [Patch, fortran] PR121398 - gfortran rejects procedure binding on PDT

Thanks, Jerry. Pushed as r16-3135. Paul On Mon, 11 Aug 2025 at 18:38, Jerry D wrote: > On 8/11/25 8:10 AM, Paul Richard Thomas wrote: > > Hi All, > > > > This patch eliminates errors that arose in the use of generic bindings > in PDT > > templates and their inst

[Patch, fortran] PR121398 - gfortran rejects procedure binding on PDT

Hi All, This patch eliminates errors that arose in the use of generic bindings in PDT templates and their instances. This came about because none of the pdt instances matched the PDT template types and some of them might not match not match the containing specific type; ie. with different kind par

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi Jerry et al., I attached an earlier version of the patch - apologies! Please find the latest attached. Paul On Thu, 7 Aug 2025 at 17:07, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Jerry, Steve and co., > > Thanks for the reviews. > > I have made

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

> With your updated patch addressing Steve's comments OK. > > We have time for minor tweaks if necessary. > > On 8/3/25 11:06 AM, Steve Kargl wrote: > > On Sun, Aug 03, 2025 at 12:20:24PM +0100, Paul Richard Thomas wrote: > > > > First, the easy one: >

Re: [PATCH 0/6] fortran: Remove isolated array descriptor fields updates

Hi Mikael, I feel sure that most of these updates result from ad hoc fixes to PRs that were completely fixed later on or are remnants of old fixes. Thanks for doing all this cleanup work. As you said in the second message, let's see how it pans out. The span field was initially introduced to dea

Re: [PATCH 0/3] fortran: Use existing setters and getters to access array descriptors

Hi Mikael, All three patches are OK for mainline. About half of the chunks I recognise and blames should point to me :-( Thanks for the patch. Paul On Sun, 3 Aug 2025 at 14:30, Mikael Morin wrote: > From: Mikael Morin > > The fortran frontend has getter and setter functions to generate code

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

important omission. Apart from the date, the ChangeLogs remain the same. OK for mainline? Paul On Tue, 29 Jul 2025 at 21:29, Harald Anlauf wrote: > Hi Paul! > > Am 24.07.25 um 08:07 schrieb Paul Richard Thomas: > > I forgot to include subroutine tests. Please find attached t

[RFC] c++: Optimize out dynamic_cast call when target is final, replacing it with a vtable address comparison

Notes: This patch optimizes out calls to __dynamic_cast when the type being cast to is final (or its destructor), replacing them with a simple comparison of the types' vtable addresses. This is already implemented and done by default in clang (https://review s.llvm.org/D154658), but can

Re: [PATCH] fortran: Evaluate class function bounds in the scalarizer

Hi Mikael, The patch applies cleanly, regtests and fixes the problem, as advertised. It does likewise on 15-branch. Good for mainline and, I would suggest, backporting. Thanks for the patch. Paul On Wed, 30 Jul 2025 at 10:04, Mikael Morin wrote: > From: Mikael Morin > > This one may look l

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, That's exactly how I had a mind to do it. You beat me to it :-( Just get on, polish the patch and add more tests. Thanks Paul On Wed, 30 Jul 2025 at 15:53, Yuao Ma wrote: > Hi all, > > This patch introduces support for conditional expressions (also known as > ternary operators in s

Re: [PATCH] Don't pass vector params through to offload targets

* params.opt (-param=vect-epilogues-nomask): Add NoOffload. > (-param=vect-partial-vector-usage): Likewise. > (-param=vect-inner-loop-cost-factor): Likewise. Do we want to document these three in 'gcc/doc/invoke.texi' as "not passed through to offload compilat

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Anlauf wrote: > Hi Paul! > > Am 24.07.25 um 08:07 schrieb Paul Richard Thomas: > > I forgot to include subroutine tests. Please find attached the patch with > > updated testcases. > > > > Paul > > > > On Wed, 23 Jul 2025 at 17:53, Paul Richard Thomas &

Re: [RFC] c++: Optimize out dynamic_cast call when target is final [PR63164]

I can do in my next RFC. From: David Malcolm Sent: 28 July 2025 22:16:03 To: Thomas de Bock; gcc-patches@gcc.gnu.org Subject: [ext] Re: [RFC] c++: Optimize out dynamic_cast call when target is final [PR63164] On Mon, 2025-07-28 at 16:50 +, Thomas de Bock wrote: > This patch optimizes

Re: cobol: [PATCH] Bring the COBOL front end in releases/gcc-15 up to GCC-16

'git rebase -i', for example. (..., and remove '--allow-empty', '--allow-empty-message', '--keep-redundant-commits' from your notes, for next time.) If that wasn't clear: you should then eventually yourself 'git push' these changes into releases/gcc-15 branch. Otherwise: glad we got that sorted out! Git is a very powerful tool, that takes some training. I suppose that you were just missing '--reverse' in your 'git rev-list', so you got the commits in the wrong order. Grüße Thomas

Re: [PATCH 3/3] fortran: Consistently use the same assignment reallocation condition [PR121185]

Hi Mikail, Yes to this third patch as well. I haven't had time to track them down but there are other places where code has had to be inserted to prevent non-polymorphic references in a polymorphic way. I wonder if they cannot be unified at some time? All three can be pushed to mainline. Many th

Re: [PATCH 2/3] fortran: Trigger reference saving on pointer dereference [PR121185]

Hi Mikail, I apologise for the delay between reviewing this patch and the first. Some daytime work issues came up that I couldn't ignore. This addition is fine, does as advertised and is good for mainline. Thanks Paul On Sat, 26 Jul 2025 at 20:32, Mikael Morin wrote: > From: Mikael Morin >

[RFC] c++: Optimize out dynamic_cast call when target is final [PR63164]

This patch optimizes out calls to __dynamic_cast when the type being cast to is final (or its destructor), replacing them with a simple comparison of the types' vtable addresses. This is already implemented and done by default in clang (https://reviews.llvm.org/D154658), but can be turned off wi

RE: GCC 15.1.1 Status Report (2025-07-11)

ts that had alread made it into releases/gcc-15 branch, and 'git cherry-pick --skip'ed the last few diagnostics-related ones, and: everything else of those GCC/Cobol commits 'git cherry-pick -x'ed without any conflicts. I'm happy to put that branch into my usual testing, and/o

[PUSHED] nvptx/nvptx.opt: Update -march-map= for newer sm_xxx: test cases

Test cases for commit 60ba2b61af23e6d561c5cbab8df57ea093ade3b3 "nvptx/nvptx.opt: Update -march-map= for newer sm_xxx". gcc/testsuite/ * gcc.target/nvptx/march-map=sm_100.c: New. * gcc.target/nvptx/march-map=sm_100a.c: Likewise. * gcc.target/nvptx/march-map=sm_100f.c

Re: PING (and v2) – [Patch] nvptx/nvptx.opt: Update -march-map= for newer sm_xxx

sm_100/101/120 (Blackwell) currently/now map to >> sm_89, GCC generates PTX ISA .version 7.8 for them. >> Otherwise, sm_80 and sm_89 produce (for now) identical code. > nvptx/nvptx.opt: Update -march-map= for newer sm_xxx Pushed to trunk branch commit 60ba2b61af23e6d561c5cbab8df57e

Re: [PATCH 1/3] fortran: Bound class container lookup after array descriptor [PR121185]

Hi Mikael, This looks fine to me. OK for mainline. Thanks for the fix. Paul On Sat, 26 Jul 2025 at 20:31, Mikael Morin wrote: > From: Mikael Morin > > Regression-tested on x86_64-pc-linux-gnu. > OK for master? > > -- >8 -- > > Don't look for a class container too far after an array descript

Re: GCC 15.1.1 Status Report (2025-07-11)

ght be necessary for any commits that didn't touch 'gcc/cobol/', 'libgcobol/', 'gcc/testsuite/cobol.dg/' but are still relevant, like build system changes. That's where some '--regexp-ignore-case --grep=cobol' might come handy, so maybe just work on: $ git log --reverse --stat -p --regexp-ignore-case --grep=cobol "$rev_start"..origin/trunk Grüße Thomas

[PUSHED] diagnostics: move diagnostic.c to diagnostics/context.cc: restore build with GCC 5

Building with GCC 5, with commit 8d9d9515f5db9bab758e484f3956033150931de5 "diagnostics: move diagnostic.c to diagnostics/context.cc", we got: ../../source-gcc/gcc/diagnostics/context.cc: In member function ‘bool diagnostics::context::diagnostic_impl(rich_location*, const diagnostics::metadat

[PUSHED] diagnostics: convert diagnostic_t to enum class diagnostics::kind: restore build with GCC 5

Building with GCC 5, with commit 3cc27ed5b6fb4253d3fe2139dcc6295e85372a3a "diagnostics: convert diagnostic_t to enum class diagnostics::kind", we got: ../../source-gcc/gcc/diagnostics/option-classifier.cc: In member function ‘diagnostics::kind diagnostics::option_classifier::update_effective

Re: [Fortran, Coarray] Call-out to everyone having Fortran coarray-codes available

Am 23.07.25 um 21:47 schrieb Toon Moene: Today I used Thomas's "locks" example code from the same e-mail message (showing the full output): Actually, I think that example is flawed, it lacks synchronization. Sorry for that. Best regards Thomas

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

I forgot to include subroutine tests. Please find attached the patch with updated testcases. Paul On Wed, 23 Jul 2025 at 17:53, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > The attached implements the F2018 generic statement, which has the same >

[Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi All, The attached implements the F2018 generic statement, which has the same semantics as the typebound version but can appear in any specification statement. As it says in the first comment in the patch, use is made of the existing, typebound matching functions to obtain access-spec and gener

[RFC] c++: Optimize out dynamic_cast call when target is final [PR63164]

This patch optimizes out calls to __dynamic_cast when the type being cast to is final (or its destructor), replacing them with a simple comparison of the types' vtable addresses. This is already implemented and done by default in clang (https://reviews.llvm.org/D154658), but can be turned off wi

[RFC] libstdc++: Optimize out dynamic_cast call when target is final [PR63164]

This patch optimizes out calls to __dynamic_cast when the type being cast to is final (or its destructor), replacing them with a simple comparison of the types' vtable addresses. This is already implemented and done by default in clang (https://reviews.llvm.org/D154658), but can be turned off wi

Re: [ARM EABI] Adjust 'libgomp.c++/target-cdtor-{1,2}.C' for 'targetm.cxx.use_aeabi_atexit' [PR119853, PR119854] (was: [Linaro-TCWG-CI] gcc-16-130-gaafe942227b: 10 regressions on arm)

Hi! Maxim, thanks for the explanations. Otherwise: On 2025-07-21T15:12:59+1200, Maxim Kuvyrkov wrote: >> On Jul 18, 2025, at 23:51, Thomas Schwinge wrote: >> On 2025-04-26T00:09:21+, ci_notify--- via Gcc-regression >> wrote: >>> Our automatic CI has detect

Re: Coarray shared memory testing

and END CRITICAL, allocatable coarrays etc. If this testing is not done (and resulting bugs fixed), there is an extremely high chance that race conditions and other problems such as memory leaks are introduced. Best regards Thomas

Re: [Fortran, Patch, PR119106, v1] Allow iterator substitution in array constructors

Hi Andre, After a false start, the patch was applied to mainline, did what it was supposed to do and regtests fine. Ok for mainline. Thanks Paul On Fri, 18 Jul 2025 at 13:42, Andre Vehreschild wrote: > Hi all, hi Harald, > > attached patch fixes a runtime out-of-bounds error when an iterato

[ARM EABI] Adjust 'libgomp.c++/target-cdtor-{1,2}.C' for 'targetm.cxx.use_aeabi_atexit' [PR119853, PR119854] (was: [Linaro-TCWG-CI] gcc-16-130-gaafe942227b: 10 regressions on arm)

Hi! On 2025-04-26T00:09:21+, ci_notify--- via Gcc-regression wrote: > Our automatic CI has detected problems related to your patch(es). Please find > some details below. > > In gcc_check master-arm, after: > | commit gcc-16-130-gaafe942227b > | Author: Thomas Sc

[PUSHED] GCN, nvptx offloading: Restrain 'WARNING: program timed out.' while in 'dynamic_cast' only for effective-target 'offload_device' [PR119692]

In PR119692 "C++ 'typeinfo', 'vtable' vs. OpenACC, OpenMP 'target' offloading": > --- Comment #8 from Rainer Orth --- > The last commit made things worse on sparc-sun-solaris2.11: since that one > (dg-timeout 10) I regularly get > > WARNING: libgomp.c++/target-exceptions-bad_cast-1.C (test for ex

ICE with new IMPORT feature

Dear All, The failure that Steve mentioned below is fixed. ChangeLogs and patch are self-describing. Regtests fine - OK for mainline? Paul On Sat, 12 Jul 2025 at 19:57, Steve Kargl wrote: > All, Paul, > > In testing Paul's recent addition of support for IMPORT, > I have uncovered an ICE due t

[Patch, fortran] PR121060 - ICE when argument is associate name created from type-bound operator result

At first this PR looked as if it was going to be one of those horrible typebound procedure/operator tangles. However, it turned out that this was entirely down to the attempt to extract the specific procedure for the ASSOCIATE name during parsing. Returning NULL before expression resolution fixed

Re: [Patch, fortran] PR106135 - Implement F2018 IMPORT statements

Thanks, Jerry. Pushed as r16-2189. Note however that s/pr106135/pr106035 is required throughout. I will attend to it tomorrow. Paul On Mon, 23 Jun 2025 at 19:27, Jerry D wrote: > On 6/23/25 9:43 AM, Paul Richard Thomas wrote: > > Hello All, > > > > I was mulling ove

Re: [Patch, Fortran, Coarray, PR88076, v2] Add a shared memory multi process coarray library.

Am 10.07.25 um 11:27 schrieb Andre Vehreschild: Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Did you run extensive tests on all potential race conditions, and fix the resulting fallout? If you did, please post your test cases and the results. Otherwise, https://gcc.gnu.org/piperm

[PUSHED] Fix 'main' function in 'gcc.dg/builtin-dynamic-object-size-pr120780.c'

Fix-up for commit 72e85d46472716e670cbe6e967109473b8d12d38 "tree-optimization/120780: Support object size for containing objects". 'size_t sz' is unused here, and GCC/nvptx doesn't accept this: spawn -ignore SIGHUP [...]/nvptx-none-run ./builtin-dynamic-object-size-pr120780.exe error :

Re: [PUSHED] GCN, nvptx: Support '-mfake-exceptions', and use it for offloading compilation [PR118794]

Hi Jan-Benedict! On 2025-06-05T10:24:35+0200, Jan-Benedict Glaw wrote: > On Tue, 2025-04-15 00:22:26 +0200, Thomas Schwinge > wrote: >> diff --git a/gcc/except.cc b/gcc/except.cc >> index d5eb9274a62..205811c6567 100644 >> --- a/gcc/except.cc >> +++ b/gcc/e

Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

Am 04.07.25 um 14:12 schrieb Andre Vehreschild: Regtests ok on x86_64-pc-linux-gnu and aarch64-unknown-freebsd14.3. Ok for mainline? The whole patch set needs including the library needs rigorous and extensive testing against race conditions, as outlined in https://gcc.gnu.org/pipermail/fortran

[PUSHED] OpenMP: Add omp_get_initial_device/omp_get_num_devices builtins: Fix test cases

With this fix-up for commit 387209938d2c476a67966c6ddbdbf817626f24a2 "OpenMP: Add omp_get_initial_device/omp_get_num_devices builtins", we progress: PASS: c-c++-common/gomp/omp_get_num_devices_initial_device.c (test for excess errors) PASS: c-c++-common/gomp/omp_get_num_devices_initial_

Re: [Patch] builtins.def: Enable OpenMP/OpenACC builtins also with -fno-nonansi-builtins

t;DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_NORMAL, TYPE, TYPE,\ > - flag_openmp, true, true, ATTRS, false, flag_openmp) > + flag_openmp, true, false, ATTRS, false, flag_openmp) (... like you do here.) Also, is this really applicable to 'DEF_GOACC_BUILTIN_COMPILER', 'DEF_GOMP_BUILTIN_COMPILER' only, but not the other ones: 'DEF_GOACC_BUILTIN', 'DEF_GOACC_BUILTIN_ONLY', 'DEF_GOMP_BUILTIN'? Grüße Thomas

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

and the > dependencies in the build system have not been updated, because that is > what > the error message indicates. Can you try again? > > Because "works for me" using a clean build directory. How can I help you > further? > > Regards, > Andre > &

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Andre, this series of patches (six in total) adds a new coarray backend library to libgfortran. The library uses shared memory and processes to implement running multiple images on the same node. The work is based on work started by Thomas and Nicolas Koenig. No changes to the gfortran

[PATCH] dwarf2out reproduceability: do not hash pointer

Erroneously changed when converting dwarf2out to the new inchash interface (f768061c4c0). The other hash_loc_operands calls were left in place. gcc/Changelog: * dwarf2out.cc (hash_loc_operands): do not hash pointer --- gcc/dwarf2out.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

plement > running multiple images on the same node. The work is based on work > started by > Thomas and Nicolas Koenig. No changes to the gfortran compile part are > required > for this. > > Unfortunately I found some defects in the gfortran compiler, that needed > to be >

[Patch, fortran] PR106135 - Implement F2018 IMPORT statements

->do_not_resolve_again = 1; + if (t && gfc_current_ns->import_state != IMPORT_NOT_SET) +t = check_import_status (e); + return t; } @@ -10583,6 +10735,7 @@ resolve_select_type (gfc_code *code, gfc_namespace *old_ns) int rank = 0, corank = 0; gfc_ref* ref = NULL; gfc_

Re: [PATCH] fortran: Statically initialize length of SAVEd character arrays

Hi Mikael, Regression-tested on x86_64-pc-linux-gnu. OK for master? Just wondering... how does this relate to the recent fix of PR120483 by Andre? Is this also a regression? If so, maybe a backport would be in order. Best regads Thomas

Re: [PATCH] Add newlib to gitignore

se "git push" to publish your local commits) Untracked files: (use "git add ..." to include in what will be committed) newlib nothing added to commit but untracked files present (use "git add" to track) ;-) > I think I'l

[PUSHED] Avoid SIGSEGV in nvptx 'mkoffload' for voluminous PTX code

In commit 50be486dff4ea2676ed022e9524ef190b92ae2b1 "nvptx: libgomp+mkoffload.cc: Prepare for reverse offload fn lookup", some additional tracking of the PTX code was added, and this assumes that potentially every single character of PTX code needs to be tracked as a new chunk of PTX code. That's p

Re: [Fortran, Patch, PR120483, v1] Fix wrong type of saved allocatable strings.

ok on x86_64-pc-linux-gnu / F41. Ok for mainlines? OK for trunk and also for backporting to gcc 15 (it is a 15/16 regression). Best regards Thomas

[PUSHED] libgomp: Add testcases for the standard C++ math library on offload targets

From: Kwok Cheung Yeung libgomp/ * testsuite/libgomp.c++/target-std__cmath.C: New. * testsuite/libgomp.c++/target-std__complex.C: Likewise. * testsuite/libgomp.c++/target-std__numbers.C: Likewise. --- .../testsuite/libgomp.c++/target-std__cmath.C | 340 ++

[PUSHED] Add 'libgomp.c++/target-valarray-1.C'

libgomp/ * testsuite/libgomp.c++/target-std__valarray-1.C: New. * testsuite/libgomp.c++/target-std__valarray-1.output: Likewise. --- .../libgomp.c++/target-std__valarray-1.C | 179 ++ .../libgomp.c++/target-std__valarray-1.output | 22 +++ 2 files chan

[PUSHED] libgomp: Add testcases for concurrent access to standard C++ containers on offload targets

-concurrent.C: Likewise. * testsuite/libgomp.c++/target-std__vector-concurrent.C: Likewise. Co-authored-by: Thomas Schwinge --- .../target-std__array-concurrent.C| 60 ++ .../target-std__bitset-concurrent.C | 67 +++ .../target-std__deque

[PUSHED] libgomp: Add testcases for concurrent access to standard C++ containers on offload targets, a number of USM variants

libgomp/ * testsuite/libgomp.c++/target-std__array-concurrent-usm.C: New. * testsuite/libgomp.c++/target-std__array-concurrent.C: Adjust. * testsuite/libgomp.c++/target-std__bitset-concurrent-usm.C: New. * testsuite/libgomp.c++/target-std__bitset-concurrent.C

[PUSHED] Add 'libgomp.c++/target-flex-[...].C' test cases

. * testsuite/libgomp.c++/target-flex-80.C: New test. * testsuite/libgomp.c++/target-flex-81.C: New test. * testsuite/libgomp.c++/target-flex-90.C: New test. * testsuite/libgomp.c++/target-flex-common.h: New test. Co-authored-by: Thomas Schwinge --- .../testsuite/libgomp.c

[PUSHED] Defuse 'RESULT_DECL' check in 'pass_nrv' (for offloading compilation) [PR119835]

... to avoid running into ICEs per PR119835, until that's resolved properly. PR middle-end/119835 gcc/ * tree-nrv.cc (pass_nrv::execute): Defuse 'RESULT_DECL' check. libgomp/ * testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c: '#pragma GCC optimize

[patch, Fortran, committed] Fix PR 120355, regression with global functions

d for pointing out the source of the problem in the PR. Best regards Thomas Type mismatch for passed external function gcc/fortran/ChangeLog: PR fortran/120355 * interface.cc (compare_parameter): If the global function has a result clause, take typespec from there fo

Defuse 'RESULT_DECL' check in 'pass_nrv' for offloading compilation [PR119835] (was: Disable 'pass_nrv' for offloading compilation [PR119835])

Hi! On 2025-05-28T09:18:29+0200, Richard Biener wrote: > On Tue, 27 May 2025, Thomas Schwinge wrote: >> "'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p'" isn't actually >> a GIMPLE semantics invariant, thanks. I conclude tha

Disable 'pass_nrv' for offloading compilation [PR119835] (was: [PATCH] Verify 'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p' [PR119835])

Hi! On 2025-05-23T17:01:31+0200, Richard Biener wrote: > Am 23.05.2025 um 16:49 schrieb Thomas Schwinge : >> This fell out of me looking into PR119835. This doesn't resolve the >> underlying >> issue, but instead of failing GIMPLE semantics verification just by cha

[PATCH] Verify 'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p' [PR119835]

This fell out of me looking into PR119835. This doesn't resolve the underlying issue, but instead of failing GIMPLE semantics verification just by chance in the 'GIMPLE pass: nrv' context, it makes the issue observable generally. (... thereby regressing a small number of offloading test cases wher

[PUSHED] 'TYPE_EMPTY_P' vs. code offloading [PR120308]

We've got 'gcc/stor-layout.cc:finalize_type_size': /* Handle empty records as per the x86-64 psABI. */ TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type); (Indeed x86_64 is still the only target to define 'TARGET_EMPTY_RECORD_P', calling 'gcc/tree.cc-default_is_empty_record'.) An

  1   2   3   4   5   6   7   8   9   10   >