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

2025-07-11 Thread Paul Richard Thomas
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.

2025-07-10 Thread Thomas Koenig
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'

2025-07-09 Thread Thomas Schwinge
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]

2025-07-07 Thread Thomas Schwinge
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.

2025-07-04 Thread Thomas Koenig
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

2025-07-03 Thread Thomas Schwinge
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

2025-06-30 Thread Thomas Schwinge
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.

2025-06-26 Thread Paul Richard Thomas
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.

2025-06-25 Thread Thomas Koenig
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

2025-06-24 Thread Thomas Otto
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.

2025-06-24 Thread Paul Richard Thomas
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

2025-06-23 Thread Paul Richard Thomas
->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

2025-06-18 Thread Thomas Koenig
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

2025-06-05 Thread Thomas Schwinge
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

2025-06-04 Thread Thomas Schwinge
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.

2025-06-02 Thread Thomas Koenig
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

2025-05-30 Thread Thomas Schwinge
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'

2025-05-30 Thread Thomas Schwinge
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

2025-05-30 Thread Thomas Schwinge
-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

2025-05-30 Thread Thomas Schwinge
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

2025-05-30 Thread Thomas Schwinge
. * 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]

2025-05-30 Thread Thomas Schwinge
... 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

2025-05-30 Thread Thomas Koenig
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])

2025-05-28 Thread Thomas Schwinge
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])

2025-05-27 Thread Thomas Schwinge
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]

2025-05-23 Thread 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 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]

2025-05-19 Thread Thomas Schwinge
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

[PUSHED] Add 'libgomp.c-c++-common/target-abi-struct-1-O0.c', 'libgomp.oacc-c-c++-common/abi-struct-1.c'

2025-05-19 Thread Thomas Schwinge
libgomp/ * testsuite/libgomp.c-c++-common/target-abi-struct-1-O0.c: New. * testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c: Likewise. --- .../target-abi-struct-1-O0.c | 3 + .../libgomp.oacc-c-c++-common/abi-struct-1.c | 96 +++ 2 files

[PUSHED] Fix libgomp.oacc-fortran/lib-13.f90 async bug

2025-05-19 Thread Thomas Schwinge
From: Julian Brown libgomp/ * testsuite/libgomp.oacc-fortran/lib-13.f90: End data region after wait API calls. --- libgomp/testsuite/libgomp.oacc-fortran/lib-13.f90 | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libgomp/testsuite/libgomp.oacc-fortra

Re: [patch, Fortran] Fix PR 120139, missing asterisk on prototype with -fc-prototypes

2025-05-14 Thread Thomas Koenig
Hi Paul, Same remark as for PR120107! LGTM for both branches. Committed both patches. Thanks for the reviews! Best regards Thomas

Re: [patch, Fortran] Fix PR 120139, missing asterisk on prototype with -fc-prototypes

2025-05-13 Thread Paul Richard Thomas
Hi Thomas, Same remark as for PR120107! LGTM for both branches. Thanks Paul On Tue, 13 May 2025 at 21:30, Thomas Koenig wrote: > Hello world, > > this fixes the other regression which crept in with gfortran. > Again, regression-tested, plus the local testing script is > attac

Re: [patch, Fortran] Fix 15/16 regression when non-interoperable types were dumped

2025-05-13 Thread Paul Richard Thomas
Hi Thomas, I don't think that anybody else has been up to the job of hacking dejagnu to test patches to dump-parse-tree.cc :-) I think that the patch verges on the 'obvious' and is good for both 15-branch and mainline. Thanks for the patch. Paul On Tue, 13 May 2025 at 21:15

[patch, Fortran] Fix PR 120139, missing asterisk on prototype with -fc-prototypes

2025-05-13 Thread Thomas Koenig
Hello world, this fixes the other regression which crept in with gfortran. Again, regression-tested, plus the local testing script is attached. Ok for trunk and gcc-15? Best regards Thomas Fix explicit arrays with non-constant size for -fc-prototypes. gcc/fortran/ChangeLog

[patch, Fortran] Fix 15/16 regression when non-interoperable types were dumped

2025-05-13 Thread Thomas Koenig
Hello world, the attached patch fixes a 15/16 regression and should be fairly self-explanatory. Regarding testing: I'm not sure I am up to the task of hacking dejagnu to do this. I am now running local tests, which is better than nothing (I guess). Regression-testing: Passed, though this does n

libgomp: Add a few more OpenMP/USM test cases (was: Add effective-target 'offload_device_usm', 'libgomp.c-c++-common/target-usm-1.c')

2025-05-12 Thread Thomas Schwinge
Hi! On 2025-05-12T17:03:29+0200, I wrote: > "Add effective-target 'offload_device_usm', > 'libgomp.c-c++-common/target-usm-1.c'" On top, we could then add the attached "libgomp: Add a few more OpenMP/USM test cases"? These all PASS for GCN gfx9

Add effective-target 'offload_device_usm', 'libgomp.c-c++-common/target-usm-1.c' (was: [committed] libgomp.fortran/map-alloc-comp-9{,-usm}.f90: Add unified_shared_memory variant)

2025-05-12 Thread Thomas Schwinge
e flag and/or environment variable in addition to source-code-level '#pragma omp requires unified_shared_memory' etc., I suppose? > Depending on the access > pattern, way how USM is implemented and location of host vs. device > process, copying (mapping) or direct access (

[PUSHED] GCN, nvptx offloading: Restrain 'WARNING: program timed out.' while in 'dynamic_cast'" [PR119692]

2025-05-12 Thread Thomas Schwinge
PR target/119692 libgomp/ * testsuite/libgomp.c++/pr119692-1-4.C: '{ dg-timeout 10 }'. * testsuite/libgomp.c++/pr119692-1-5.C: Likewise. * testsuite/libgomp.c++/target-exceptions-bad_cast-1.C: Likewise. * testsuite/libgomp.c++/target-exceptions-bad_ca

[PUSHED] nvptx: Support '-march=sm_61'

2025-05-12 Thread Thomas Schwinge
gcc/ * config/nvptx/nvptx-sm.def: Add '61'. * config/nvptx/nvptx-gen.h: Regenerate. * config/nvptx/nvptx-gen.opt: Likewise. * config/nvptx/nvptx.cc (first_ptx_version_supporting_sm): Adjust. * config/nvptx/nvptx.opt (-march-map=sm_61, -march-map=sm_62

[PUSHED] nvptx: Support '-mptx=5.0'

2025-05-12 Thread Thomas Schwinge
gcc/ * config/nvptx/nvptx-opts.h (enum ptx_version): Add 'PTX_VERSION_5_0'. * config/nvptx/nvptx.cc (ptx_version_to_string) (ptx_version_to_number): Adjust. * config/nvptx/nvptx.h (TARGET_PTX_5_0): New. * config/nvptx/nvptx.opt (Enum(ptx_versi

[PUSHED] GCN, nvptx libstdc++: Force use of '__atomic' builtins: revert 'atomicity_dir=cpu/generic/atomicity_builtins' hard-coding [PR119645]"

2025-05-12 Thread Thomas Schwinge
Thanks to commit 86627faec10da53d7532805019e5296fcf15ac09 "libstdc++: Rewrite atomic builtin checks [PR70560]", for both GCN, nvptx we now get: +configure:16060: checking for atomic builtins for _Atomic_word +[...] +configure:16073: result: yes ..., and thus may revert the 'atomicity_

libstdc++: Rewrite atomic builtin checks: Fix up 'GLIBCXX_ENABLE_BACKTRACE' check with 'size_t' [PR119667] (was: [PATCH] libstdc++: Rewrite atomic builtin checks [PR70560])

2025-05-12 Thread Thomas Schwinge
lts. > I need to do more testing on other targets. Hmm... ;-P Pushed to trunk branch commit 4589ccbed5cad42296d4d1810b61e8dec0dadf79 "libstdc++: Rewrite atomic builtin checks: Fix up 'GLIBCXX_ENABLE_BACKTRACE' check with 'size_t' [PR119667]", see attached. Grüße T

Re: [parch, fortran] Fix PR 120163, 15/16 regression

2025-05-10 Thread Thomas Koenig
Am 10.05.25 um 20:32 schrieb Harald Anlauf: Hi Thomas! Am 10.05.25 um 11:42 schrieb Thomas Koenig: This bug was another case of generating a formal arglist from an actual one where we should not have done so.  The fix is straightforward:  If we have resolved the formal arglist, we should not

[parch, fortran] Fix PR 120163, 15/16 regression

2025-05-10 Thread Thomas Koenig
This bug was another case of generating a formal arglist from an actual one where we should not have done so. The fix is straightforward: If we have resolved the formal arglist, we should not generare a new one. OK for trunk and backport to gcc 15? Best regards Thomas Do not

Re: [PATCH, fortran] Fix simple typo in libgfortran

2025-05-10 Thread Thomas Koenig
follow them closely. The patch itself is OK. There should be a ChangeLog entry. You can generate a template by running your patch through contrib/mklog.py, which you can then fill out with the details. Best regards Thomas

Re: [PATCH] fortran: Fix debug info for unsigned(kind=1) and unsigned(kind=4) [PR120193]

2025-05-10 Thread Thomas Koenig
thanks for the patch! Best regards Thomas

Re: [PATCH] libfortran: Fix up maxval/maxloc for UNSIGNED [PR120158]

2025-05-07 Thread Thomas Koenig
Hi Jakub, Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 15.2? OK. Thanks for catching and fixing this! Best regards Thomas König

Re: [PATCH] libfortran: Add 5 missing UNSIGNED symbols [PR120153]

2025-05-07 Thread Thomas Koenig
_15 symbol version as they've never been there, so the patch adds them to a new GFORTRAN_15.2 symbol version instead. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 15.2? OK. And thanks, again! Best regards Thomas

Re: [PATCH] libfortran: Readd 15 accidentally removed libgfortran symbols [PR120152]

2025-05-07 Thread Thomas Koenig
. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 15.2? OK. Thanks a lot for for fixing this! Best regards Thomas

Re: [patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

2025-05-06 Thread Thomas Koenig
o gcc-15? OK for both.  Thanks for the patch! Committed as r16-423-ge7a2b8b76ae0c8f1e49c780aa82ebb5f0325f515 so far, will commit to gcc-15 in a few days. Thanks for the review! Best regards Thomas

Re: [patch, fortram] Bug 120049 - ICE when using IS_C_ASSOCIATED ()

2025-05-06 Thread Paul Richard Thomas
HI Jerry, The patch looks good to me. OK for mainline and for backporting. I never quite know what to suggest for delaying backporting and so I will leave it to your judgement. Thanks for the patch. Paul On Tue, 6 May 2025 at 04:30, Jerry D wrote: > Attached patch fixes this by checking for

vect-simd-clone-1[6-8][cd].c: Expect in-branch clones for x86: Fix target selector syntax (was: [PATCH stage1 4/6] vect-simd-clone-1[6-8][cd].c: Expect in-branch clones for x86)

2025-05-05 Thread Thomas Schwinge
{ dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 0 > "vect" { target x86_64-*-* i?86-*-* } } } */ Here, '!aarch64*-*-*' isn't valid target selector syntax. I've pushed to trunk branch commit c9982eec2d3edc5306291d4628f08825ba46d483 "vect-simd-c

'libgomp.c/interop-hsa.c': GCN offloading only (was: [PATCH] OpenMP, GCN: Add interop-hsa testcase)

2025-05-05 Thread Thomas Schwinge
hing but GCN offloading compilation (and host compilation, via dead code elimination). We could do some OpenMP 'declare variant' thing, I suppose, but as that whole test case really is applicable to GCN offloading only, I've pushed to trunk branch commit 85ad0d84fcec720c1d94b9bda9a617ce

Re: [patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

2025-05-04 Thread Thomas Koenig
sense to remove the checks when the other attributes are present (or PR96073 may come back in different guise, even if I have to test case at present). I have also converted the test to a run-time check. Ok for trunk and backport to gcc-15? Best regards Thomas gcc/fortran/ChangeLog

Re: [PATCH] Fortran: array subreferences and components of derived types [PR119986]

2025-05-04 Thread Paul Richard Thomas
Hi Harald, This looks good to me both for mainline and backporting as far back as you wish. Thanks Paul On Sat, 3 May 2025 at 19:51, Harald Anlauf wrote: > Dear all, > > the attached, semi-obvious patch fixes bugging issues with passing of > array subreferences when either an inquiry referen

[patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

2025-05-03 Thread Thomas Koenig
this patch also excludes from testing. Regression-tested. OK for trunk and backport to gcc-15? Best regards Thomas gcc/fortran/ChangeLog: PR fortran/119928 * interface.cc (gfc_check_dummy_characteristics): Do not issue error for type if one argument is an unlimited

[patch, wwwdocs, committed] Fix option name in gcc15/changes.html

2025-05-03 Thread Thomas Koenig
Hello world, I just committed the following patch after noticing that an option name was wrong in the gcc15/changes.html file. diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index d851a744..b442b8d9 100644 --- a/htdocs/gcc-15/changes.html +++ b/htdocs/gcc-15/changes.html @@

[Patch fortran] PR119948 - Source allocation of pure function result rejected

2025-05-01 Thread Paul Richard Thomas
Committed as r16-329-g0abc77da9d704bba55a376bb5c162a54826ab94a following OK by Jerry on PR. I am ready to backport in a few weeks time if that is wanted. Regards Paul Fortran: Source allocation of pure function result rejected [PR119948] 2025-05-01 Paul Thomas gcc/fortran

GCN, nvptx offloading: Host/device compatibility: Itanium C++ ABI, DSO Object Destruction API [PR119853, PR119854]

2025-04-25 Thread Thomas Schwinge
7; only for 'target cxa_atexit', I've pushed to trunk branch commit aafe942227baf8c2bcd4cac2cb150e49a4b895a9 "GCN, nvptx offloading: Host/device compatibility: Itanium C++ ABI, DSO Object Destruction API [PR119853, PR119854]", see attached. Grüße Thomas >From aafe94

[PUSHED] Add 'libgomp.c-c++-common/target-cdtor-1.c'

2025-04-25 Thread Thomas Schwinge
libgomp/ * testsuite/libgomp.c-c++-common/target-cdtor-1.c: New. --- .../libgomp.c-c++-common/target-cdtor-1.c | 89 +++ 1 file changed, 89 insertions(+) create mode 100644 libgomp/testsuite/libgomp.c-c++-common/target-cdtor-1.c diff --git a/libgomp/testsuite/

[PATCH] GCN, nvptx offloading: Host/device compatibility: Itanium C++ ABI, DSO Object Destruction API [PR119853, PR119854]

2025-04-23 Thread Thomas Schwinge
'__dso_handle' for '__cxa_atexit', '__cxa_finalize'. See . PR target/119853 PR target/119854 libgcc/ * config/gcn/crt0.c (_fini_array): Call '__GCC_offload___cxa_finalize'. * config/nvptx/

[PATCH] GCN: Properly switch sections in 'gcn_hsa_declare_function_name' [PR119737]

2025-04-22 Thread Thomas Schwinge
: Likewise. * testsuite/libgomp.oacc-c++/exceptions-throw-1.C: Likewise. * testsuite/libgomp.oacc-c++/exceptions-throw-2.C: Likewise. Co-authored-by: Thomas Schwinge --- gcc/config/gcn/gcn.cc | 6 +++--- libgomp/testsuite/libgomp.c++/target-

Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for 'targetm.arm_eabi_unwinder' [PR118794] (was: [Linaro-TCWG-CI] gcc-15-9463-gaa3e72f9430: 2 regressions on arm)

2025-04-22 Thread Thomas Schwinge
Hi! On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression wrote: > Our automatic CI has detected problems related to your patch(es). Please find > some details below. > > In bootstrap_check master-arm-check_bootstrap, after: > | commit gcc-15-9463-gaa3e72f9430 >

[PUSHED] Disable parallel testing for 'rust/compile/nr2/compile.exp' [PR119508]

2025-04-19 Thread Thomas Schwinge
..., using the standard idiom. This '*.exp' file doesn't adhere to the parallel testing protocol as defined in 'gcc/testsuite/lib/gcc-defs.exp'. This also restores proper behavior for '*.exp' files executing after (!) this one, which erroneously caused hundreds or even thousands of individual tes

Re: [Patch] Fortran/OpenMP: Support automatic mapping allocatable components (deep mapping)

2025-04-18 Thread Thomas Schwinge
ger :: tmp_x(2,2), tmp_y(2,2), tmp_z(2,2), i, j > + tmp_x = reshape([1, 4, 11, 14], [2,2]) > + tmp_y = reshape([2, 5, 12, 15], [2,2]) > + tmp_z = reshape([3, 6, 13, 16], [2,2]) > + do j = 1, 2 > +do i = 1, 2 > + if (var4%Q%D(i,j)%x /= tmp_x(i,j)) stop 16 > + if (va

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)

2025-04-18 Thread Paul Richard Thomas
Hi Andre, On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild wrote: > Hi Jerry, > > thanks for the review and sorry for the long delay. With publishing the > team's > patches for gfortran, I also created a pull request for OpenCoarrays. > There I > was asked to add some testcase with more "beef" in

Fix time zone for 'cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob' [PR119818] (was: cobol: [committed] More testcases)

2025-04-18 Thread Thomas Schwinge
18]", see attached? Or, is another approach preferable? Grüße Thomas --- /dev/null +++ b/gcc/testsuite/cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob @@ -0,0 +1,334 @@ + *> { dg-do run } + +identification division. +program-id. test

[PUSHED] nvptx: Remove 'TARGET_ASM_NEED_VAR_DECL_BEFORE_USE'

2025-04-17 Thread Thomas Schwinge
Unused; remnant of an (internal) experiment, before we had nvptx 'as'. gcc/ * config/nvptx/nvptx.cc (TARGET_ASM_NEED_VAR_DECL_BEFORE_USE): Don't '#define'. --- gcc/config/nvptx/nvptx.cc | 2 -- 1 file changed, 2 deletions(-) diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/co

Remove 'ALWAYS_INLINE' workaround in 'libgomp.c++/target-exceptions-pr118794-1.C' (was: [PUSHED] GCN, nvptx: Support '-mfake-exceptions', and use it for offloading compilation [PR118794])

2025-04-16 Thread Thomas Schwinge
INE >C(int) {}; >~C() {}; Pushed to trunk branch commit 518efed8cb7d003cd85477060b1fe926a2d7a53b "Remove 'ALWAYS_INLINE' workaround in 'libgomp.c++/target-exceptions-pr118794-1.C'", see attached. Grüße Thomas >From 518efed8cb7d003cd85477060b1fe9

[PUSHED] Add 'libgomp.c++/pr106445-1{,-O0}.C' [PR106445]

2025-04-16 Thread Thomas Schwinge
PR target/106445 libgomp/ * testsuite/libgomp.c++/pr106445-1.C: New. * testsuite/libgomp.c++/pr106445-1-O0.C: Likewise. --- libgomp/testsuite/libgomp.c++/pr106445-1-O0.C | 3 +++ libgomp/testsuite/libgomp.c++/pr106445-1.C| 18 ++ 2 files changed

For nvptx offloading, make sure to emit C++ constructor, destructor aliases [PR97106] (was: [committed][nvptx] Use .alias directive for mptx >= 6.3)

2025-04-16 Thread Thomas Schwinge
Hi! On 2025-03-25T11:51:26+0100, Tom de Vries wrote: > On 3/25/25 11:18, Thomas Schwinge wrote: >> On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches >> wrote: >>> Starting with ptx isa version 6.3, a ptx directive .alias is available. >> >> Regar

[PUSHED 1/3] Add 'std::bad_cast' exception test cases for GCN, nvptx target and OpenACC, OpenMP 'target' offloading

2025-04-14 Thread Thomas Schwinge
gcc/testsuite/ * g++.target/gcn/exceptions-bad_cast-1.C: New. * g++.target/nvptx/exceptions-bad_cast-1.C: Likewise. libgomp/ * testsuite/libgomp.c++/target-exceptions-bad_cast-1.C: New. * testsuite/libgomp.oacc-c++/exceptions-bad_cast-1.C: Likewise. -

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

2025-04-14 Thread Thomas Schwinge
With '-mfake-exceptions' enabled, the user-visible behavior in presence of exception handling constructs changes such that the compile-time 'sorry, unimplemented: exception handling not supported' is skipped, code generation proceeds, and instead, exception handling constructs 'abort' at run time.

[PUSHED] Add 'g++.target/gcn/gcn.exp' for GCN-specific C++ test cases

2025-04-14 Thread Thomas Schwinge
Like 'gcc.target/gcn/gcn.exp' is modeled after 'gcc.dg/dg.exp', this new 'g++.target/gcn/gcn.exp' is modeled after 'g++.dg/dg.exp'. gcc/testsuite/ * g++.target/gcn/gcn.exp: New. --- gcc/testsuite/g++.target/gcn/gcn.exp | 56 1 file changed, 56 insertio

[PUSHED 3/3] Add 'throw', dead code test cases for GCN, nvptx target and OpenACC, OpenMP 'target' offloading

2025-04-14 Thread Thomas Schwinge
gcc/testsuite/ * g++.target/gcn/exceptions-throw-3.C: New. * g++.target/nvptx/exceptions-throw-3.C: Likewise. libgomp/ * testsuite/libgomp.c++/target-exceptions-throw-3.C: New. * testsuite/libgomp.oacc-c++/exceptions-throw-3.C: Likewise. --- .../g++.

[PUSHED 2/3] Add 'throw', caught test cases for GCN, nvptx target and OpenACC, OpenMP 'target' offloading

2025-04-14 Thread Thomas Schwinge
gcc/testsuite/ * g++.target/gcn/exceptions-throw-2.C: New. * g++.target/nvptx/exceptions-throw-2.C: Likewise. libgomp/ * testsuite/libgomp.c++/target-exceptions-throw-2.C: New. * testsuite/libgomp.c++/target-exceptions-throw-2-offload-sorry-GCN.C: Li

[PUSHED 1/3] Add 'throw' test cases for GCN, nvptx target and OpenACC, OpenMP 'target' offloading

2025-04-14 Thread Thomas Schwinge
gcc/testsuite/ * g++.target/gcn/exceptions-throw-1.C: New. * g++.target/nvptx/exceptions-throw-1.C: Likewise. libgomp/ * testsuite/libgomp.c++/target-exceptions-throw-1.C: New. * testsuite/libgomp.c++/target-exceptions-throw-1-O0.C: Likewise.

[PUSHED 3/3] Add 'std::bad_cast' exception, dead code test cases for GCN, nvptx target and OpenACC, OpenMP 'target' offloading

2025-04-14 Thread Thomas Schwinge
gcc/testsuite/ * g++.target/gcn/exceptions-bad_cast-3.C: New. * g++.target/nvptx/exceptions-bad_cast-3.C: Likewise. libgomp/ * testsuite/libgomp.c++/target-exceptions-bad_cast-3.C: New. * testsuite/libgomp.oacc-c++/exceptions-bad_cast-3.C: Likewise. -

[PUSHED 2/3] Add 'std::bad_cast' exception, caught test cases for GCN, nvptx target and OpenACC, OpenMP 'target' offloading

2025-04-14 Thread Thomas Schwinge
gcc/testsuite/ * g++.target/gcn/exceptions-bad_cast-2.C: New. * g++.target/nvptx/exceptions-bad_cast-2.C: Likewise. libgomp/ * testsuite/libgomp.c++/target-exceptions-bad_cast-2.C: New. * testsuite/libgomp.c++/target-exceptions-bad_cast-2-offload-sor

[PUSHED] Add test cases for exception handling constructs in dead code for GCN, nvptx target and OpenMP 'target' offloading [PR118794]

2025-04-14 Thread Thomas Schwinge
PR target/118794 gcc/testsuite/ * g++.target/gcn/exceptions-pr118794-1.C: New. * g++.target/nvptx/exceptions-pr118794-1.C: Likewise. libgomp/ * testsuite/libgomp.c++/target-exceptions-pr118794-1.C: New. * testsuite/libgomp.c++/target-exceptio

[PUSHED] Add PR119692 "C++ 'typeinfo', 'vtable' vs. OpenACC, OpenMP 'target' offloading" test cases [PR119692]

2025-04-14 Thread Thomas Schwinge
... documenting the status quo. PR c++/119692 gcc/testsuite/ * g++.target/gcn/pr119692-1-1.C: New. * g++.target/nvptx/pr119692-1-1.C: Likewise. libgomp/ * testsuite/libgomp.c++/pr119692-1-1.C: New. * testsuite/libgomp.c++/pr119692-1-2.C: Like

[v2] Polish 'dg-output-file' test logs (was: [PATCH] testsuite: Add support for dg-output-file directive)

2025-04-14 Thread Thomas Schwinge
("eval" body line 1) invoked from within "eval saved-dg-test $args " (procedure "dg-test" line 1) invoked from within "dg-test $testcase $options ${default-extra-options}" (procedure "dg-runtest" line 10)

Re: Asan/Tsan Unit/Regression testing (was [asan] Emit GIMPLE direclty, small cleanups)

2025-04-14 Thread Thomas Schwinge
ppose we could move this wrapping setup into 'asan_init', and then undo it in 'asan_finish'. I'll be happy to draft a patch if someone confirms my thinking. Grüße Thomas

Polish 'dg-output-file' test logs (was: [PATCH] testsuite: Add support for dg-output-file directive)

2025-04-13 Thread Thomas Schwinge
verbose "Failed test for output line $linenum" 3 > + pass "$name output file test" > + verbose "Passed test for output file [lindex ${output-file} > 1]" 3 OK to push the attached "Polish 'dg-output-f

Re: [patch, Fortran] Fix PR 119669

2025-04-13 Thread Thomas Koenig
Ah, yes :-) Thanks for the patch! Committed as r15-9406-g64319b2ccae2fdfae06347545e031e56d790dad7 . Thanks for the review! Best regards Thomas

[PUSHED] Fortran: Add code gen for do, concurrent's LOCAL/LOCAL_INIT: Fix 'static_assert' [PR101602]

2025-04-12 Thread Thomas Schwinge
Fix-up for commit 2d7e1d6e40a13a5f160b584336795b80f193ec3b "Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]": ../../source-gcc/gcc/fortran/trans-stmt.cc: In function ‘void gfc_trans_concurrent_locality_spec(bool, stmtblock_t*, std::vector*, gfc_expr_list**)’: ../../

Documentation for the REDUCE intrinsic

2025-04-12 Thread Paul Richard Thomas
Hi All, Now that the reduce intrinsic seems to be OK on all platforms, I thought that it was time to catch up with the documentation. The attached produces good .html without any additional warnings or errors using texi2any and ~/share/info/gfortran.info is as intended. OK for mainline? Paul di

[patch, Fortran] Fix PR 119669

2025-04-11 Thread Thomas Koenig
ought better safe than sorry. Most of the patch is actually reformatting due to the 80-column-rule. (Do we really want to keep that for gfortran?) Regression-tested. OK for trunk? Best regards Thomas Fix ICE in compare_parameter. gcc/fortran/ChangeLog: PR fortran/1

OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause [PR119692]

2025-04-09 Thread Thomas Schwinge
standardization by the OpenACC Technical Committee.) Grüße Thomas >From 660ffe85a98e9f0ec6ddd6ba1f383a44b672502c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 9 Apr 2025 17:35:42 +0200 Subject: [PATCH] OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' cla

[PUSHED 1/2] GCN, nvptx: Define '_Unwind_DeleteException'

2025-04-08 Thread Thomas Schwinge
This resolves GCN: ld: error: undefined symbol: _Unwind_DeleteException >>> referenced by eh_catch.cc:109 ([...]/source-gcc/libstdc++-v3/libsupc++/eh_catch.cc:109) >>> eh_catch.o:(__cxa_end_catch) in archive [...]/build-gcc/amdgcn-amdhsa/libstdc++-v3/src/.libs/libstdc++

[PUSHED 2/2] GCN, nvptx: Define '_Unwind_RaiseException', '_Unwind_Resume_or_Rethrow'

2025-04-08 Thread Thomas Schwinge
This resolves GCN: ld: error: undefined symbol: _Unwind_RaiseException >>> referenced by eh_throw.cc:93 ([...]/source-gcc/libstdc++-v3/libsupc++/eh_throw.cc:93) >>> eh_throw.o:(__cxa_throw) in archive /srv/data/tschwinge/amd-instinct2/gcc/build/submit-light-target_gcn/b

[PUSHED] nvptx: In offloading compilation, special-case certain host-setup symbol aliases: avoid unused label 'emit_ptx_alias' diagnostic

2025-04-08 Thread Thomas Schwinge
Minor fix-up for commit 65b31b3fff2fced015ded1026733605f34053796 "nvptx: In offloading compilation, special-case certain host-setup symbol aliases [PR101544]", as of which we see for non-offloading configurations: +[...]/source-gcc/gcc/config/nvptx/nvptx.cc: In function 'void nvptx_asm_outpu

[PUSHED] GCN, nvptx libstdc++: Force use of '__atomic' builtins [PR119645]

2025-04-07 Thread Thomas Schwinge
For both GCN, nvptx, this gets rid of 'configure'-time: configure: WARNING: No native atomic operations are provided for this platform. configure: WARNING: They will be faked using a mutex. configure: WARNING: Performance of certain classes will degrade as a result. ..., and changes:

nvptx: Support '-mfake-ptx-alloca': defer failure to run-time 'alloca' usage (was: [PUSHED] nvptx: Support '-mfake-ptx-alloca')

2025-04-07 Thread Thomas Schwinge
e to compile-time detection of 'sorry, unimplemented: dynamic stack allocation not supported' in 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune', we should also be able to implement a corrsponding thing for this run-time failure, via new machinery in the repla

GCN, nvptx libstdc++: Force use of '__atomic' builtins [PR119645] (was: GCN, nvptx: Allow for "hosted" libstdc++ build)

2025-04-07 Thread Thomas Schwinge
s [PR119645]"? Jonathan, please put a sharp eye on the 'libstdc++-v3/acinclude.m4:GLIBCXX_ENABLE_LOCK_POLICY' change; to make sure this only affects GCN, nvptx, but nothing else. Grüße Thomas >From 1d3278050f9560666f6debcd2ead711660bebd4e Mon Sep 17 00:00:00 2001 From: Thoma

Re: [Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs

2025-04-06 Thread Paul Richard Thomas
Hi Andre, On Mon, 7 Apr 2025 at 07:29, Andre Vehreschild wrote: > Hi Paul, > > shouldn't this be done in iresolve.cc to make other parts of gfortran > benefit > from learning, that the sym is allocatable? > > I'll give it a try. I was attempting to eliminate any wider side effects by setting the

[Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs

2025-04-06 Thread Paul Richard Thomas
Hi All, As far as I can tell, the attached patch fixes the problems with the reduce intrinsic. I would be grateful to the reporters if they would confirm that this is the case. The key to the fix appears in reduce_3.f90, which failed even with -m64. Although it was not apparent from the tree dump

[PUSHED] Add 'gcc.target/nvptx/alias-unsupported-1.c'

2025-04-05 Thread Thomas Schwinge
... testing for the GCC/nvptx "alias definitions not supported" error diagnostic. gcc/testsuite/ * gcc.target/nvptx/alias-unsupported-1.c: New. --- gcc/testsuite/gcc.target/nvptx/alias-unsupported-1.c | 9 + 1 file changed, 9 insertions(+) create mode 100644 gcc/testsuite

[PATCH 2/2] GCN: Don't emit weak undefined symbols [PR119369]

2025-04-05 Thread Thomas Schwinge
This resolves all instances of PR119369 "GCN: weak undefined symbols -> execution test FAIL, 'HSA_STATUS_ERROR_VARIABLE_UNDEFINED'"; for all affected test cases, the execution test status progresses FAIL -> PASS. This however also causes a small number of (expected) regressions, very similar to G

[PUSHED] Add 'g++.target/nvptx/alias-g++.dg_init_dtor2-2.C'

2025-04-05 Thread Thomas Schwinge
... next to '-malias' variant: commit a1865fd33897bc6c6e0109df0a12ee73ce386315 "Add 'g++.target/nvptx/alias-g++.dg_init_dtor2-1.C'", to document what we're doing to '-mno-alias'. gcc/testsuite/ * g++.target/nvptx/alias-g++.dg_init_dtor2-2.C: New. --- .../nvptx/alias-g++.dg_init_dt

[PATCH] nvptx: In offloading compilation, special-case certain host-setup symbol aliases [PR101544]

2025-04-05 Thread Thomas Schwinge
configurations; any comments before I push the attached "nvptx: In offloading compilation, special-case certain host-setup symbol aliases [PR101544]"? In particular, is the use of a new 'c++ cdtor alias' attribute OK? Grüße Thomas >From 9bc9f515ed26602e97ebbcac453f73cddb8

  1   2   3   4   5   6   7   8   9   10   >