RE: [RFC] PR81358: Enable automatic linking of libatomic

Hi Prathamesh! On 2025-01-10T04:17:52+, Prathamesh Kulkarni wrote: >> -Original Message- >> From: Thomas Schwinge >> Sent: 07 January 2025 17:45 >> On 2024-12-20T15:37:42+, Prathamesh Kulkarni >> wrote: >> > [...] copying libatomic.a ov

Honor dump options for C/C++ '-fdump-tree-original'

how much more polish does this need, or if no, how should we approach this issue otherwise? (I need this, no surprise, for use in test cases.) Grüße Thomas >From 5820291e06c3f5ae7002ef1ec735e4e6b8590c1f Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 16 Jan 2025 15:32:56 +0100 Subje

[PUSHED] [OpenACC/Fortran testsuite] Use relative line numbers for a few DejaGnu directives

From: Thomas Schwinge For easier maintenance. gcc/testsuite/ * gfortran.dg/goacc/assumed.f95: Use relative line numbers for a few DejaGnu directives. * gfortran.dg/goacc/list.f95: Likewise. * gfortran.dg/goacc/loop-1-2.f95: Likewise. * gfortran.dg

Clarify 'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P' in 'gcc/tree-pretty-print.cc:dump_omp_clause' (was: [PATCH, v2, OpenMP 5.0] Implement relaxation of implicit map vs. existing device mappings (for mainline

dumps files, I recently got confused why '[implicit]' didn't match 'OMP_CLAUSE_MAP_IMPLICIT', and it took me a moment to realize that it actually means 'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P'. OK to "Clarify 'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P' in 'gcc/t

Re: [PATCH] testsuite: libstdc++: Use effective-target libatomic

Hi! On 2025-01-13T11:04:50+, Jonathan Wakely wrote: > On Mon, 13 Jan 2025 at 11:03, Thomas Schwinge wrote: >> On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON >> wrote: >> > On 2025-01-12 01:05, Jonathan Wakely wrote: >> >> On Mon,

Re: [PATCH] testsuite: libstdc++: Use effective-target libatomic

Hi! On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON wrote: > On 2025-01-12 01:05, Jonathan Wakely wrote: >> On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON, >> mailto:torbjorn.svens...@foss.st.com>> >> wrote: >> >> Ok for trunk and releases/gcc-14? >> >> OK > > Pushed as r15-6828-g4b0ef49d02

Re: [gcc r15-6807] vect: Force alignment peeling to vectorize more early break loops [PR118211]

Hi! On 2025-01-10T21:22:03+, Tamar Christina via Gcc-cvs wrote: > https://gcc.gnu.org/g:68326d5d1a593dc0bf098c03aac25916168bc5a9 > > commit r15-6807-g68326d5d1a593dc0bf098c03aac25916168bc5a9 > Author: Alex Coplan > Date: Mon Mar 11 13:09:10 2024 + > > vect: Force alignment peeling

Un-XFAIL 'dg-note's in 'gfortran.dg/goacc/routine-external-level-of-parallelism-2.f' (was: [Patch] Fortran: Fix location_t in gfc_get_extern_function_decl; support 'omp dispatch interop')

essage "optimized: assigned OpenACC > worker vector loop parallelism" } > ! { dg-error "routine call uses same OpenACC parallelism as containing loop" > "" { target *-*-* } .-1 } > -! { dg-bogus "note: routine 'gangf' declared here" "TODO1" { xfail

nvptx: Add '__builtin_frame_address(0)' test case (was: nvptx: Add '__builtin_stack_address()' test case (was: Causes to nvptx bootstrap fail: [PATCH v5] Introduce strub: machine-independent stack scr

Hi! On 2025-01-10T11:35:49+0100, I wrote: > On 2023-12-06T19:12:25-0300, Alexandre Oliva wrote: >> On Dec 6, 2023, Thomas Schwinge wrote: >>> As I understand things, ["strub"] cannot be implemented (at the call site) >>> for >>> nvptx, given tha

nvptx: Add '__builtin_stack_address()' test case (was: Causes to nvptx bootstrap fail: [PATCH v5] Introduce strub: machine-independent stack scrubbing)

Hi! On 2023-12-06T19:12:25-0300, Alexandre Oliva wrote: > On Dec 6, 2023, Thomas Schwinge wrote: >> As I understand things, ["strub"] cannot be implemented (at the call site) >> for >> nvptx, given that the callee's stack is not visible there: PTX is

'git mv gcc/testsuite/gcc.dg/{,torture/}crc-linux-3.c' (was: [committed] Move some CRC tests into the gcc.dg/torture directory)

s isn't active. I've thus pushed to trunk branch commit 310c8a6728cab1aa1c6816b5469ae4d603e2dfdd "'git mv gcc/testsuite/gcc.dg/{,torture/}crc-linux-3.c'", see attached. Grüße Thomas >From 310c8a6728cab1aa1c6816b5469ae4d603e2dfdd Mon Sep 17 00:00:00 2001 From: Th

nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181] (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04))

2'+ [PR65181]", see attached. Grüße Thomas >From 3861d362ec7e3c50742fc43833fe9d8674f4070e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 7 Dec 2024 00:17:49 +0100 Subject: [PATCH] nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR6518

nvptx: For '-march=sm_52' and higher, default at least to '-mptx=7.3' (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04))

ble" ("bookworm", 2023-06) has 11.8.89~11.8.0-5~deb12u1 > packaged Pushed to trunk branch commit b7f168644966d451fbe46ee9d06c9763a539c41b "nvptx: For '-march=sm_52' and higher, default at least to '-mptx=7.3'", see attached, so that we'll be able to use PTX '

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

gcc/ * config/nvptx/nvptx-opts.h (enum ptx_version): Add 'PTX_VERSION_7_3'. * config/nvptx/nvptx.cc (ptx_version_to_string) (ptx_version_to_number): Adjust. * config/nvptx/nvptx.h (TARGET_PTX_7_3): New. * config/nvptx/nvptx.opt (Enum(ptx_versi

nvptx: Add effective-target 'nvptx_softstack', use for effective-target 'alloca' (was: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack))

\ > } while (0) Pushed to trunk branch commit 975638b2d76ce6f26965ac3160c5af8029e16c29 "nvptx: Add effective-target 'nvptx_softstack', use for effective-target 'alloca'", see attached. Grüße Thomas >From 975638b2d76ce6f26965ac3160c5af8029e

[PUSHED 2/2] nvptx: Handle '__builtin_stack_save()' in a well-behaved way for PTX "native" stacks [PR65181]

PR target/65181 gcc/ * config/nvptx/nvptx.md [!TARGET_SOFT_STACK] (save_stack_block): 'define_expand'. gcc/testsuite/ * gcc.target/nvptx/__builtin_stack_save___builtin_stack_restore-1.c: Adjust. --- gcc/config/nvptx/nvptx.md

[PUSHED 1/2] nvptx: Add '__builtin_stack_save()', '__builtin_stack_restore()' test case [PR65181]

Documenting the status quo. PR target/65181 gcc/testsuite/ * gcc.target/nvptx/__builtin_stack_save___builtin_stack_restore-1.c: Add. --- ...tin_stack_save___builtin_stack_restore-1.c | 32 +++ 1 file changed, 32 insertions(+) create mode 100644 gc

[PUSHED] nvptx: Clarify that the PTX "native" stack pointer is handled implicitly at function level [PR65181]

PR target/65181 gcc/ * config/nvptx/nvptx.h (STACK_SAVEAREA_MODE): '#define'. * config/nvptx/nvptx.md [!TARGET_SOFT_STACK] (save_stack_function): 'define_expand'. (restore_stack_function): Handle '!TARGET_SOFT_STACK'. --- gcc/config/nvptx/nvptx.h |

[PUSHED] nvptx: Add '__builtin_alloca(0)' test cases [PR65181]

Documenting the status quo. This specific behavior relates to a 1994 change (Subversion r7229, Git commit 15fc002672d643fd9d93d220027b5cd2aefc632c). That one, however, isn't to blame here: we'd otherwise of course run into nvptx' 'sorry, unimplemented: target cannot support alloca'. PR ta

[PUSHED] nvptx: Add a test case where 'alloca's evaporate [PR65181]

Documenting the status quo. PR target/65181 gcc/testsuite/ * gcc.target/nvptx/alloca-2-O1.c: New. --- gcc/testsuite/gcc.target/nvptx/alloca-2-O1.c | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 gcc/testsuite/gcc.target/nvptx/alloca-2-O1.c d

nvptx: Add 'sorry, unimplemented: target cannot support alloca' test cases [PR65181] (was: [nvptx] alloca & stack alignment)

766365c0c7023be55ebef67b70bf4 "nvptx: Add 'sorry, unimplemented: target cannot support alloca' test cases [PR65181]", see attached. Grüße Thomas >From aae1db742a1766365c0c7023be55ebef67b70bf4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 11 Dec 2024 15:22:0

nvptx: Re-enable "Stack alignment causes use of alloca" test cases

ot;, see attached. Grüße Thomas >From 84e90b69fba1cfa2a77942251ddfd0527fb22811 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 28 Nov 2022 10:37:26 +0100 Subject: [PATCH] nvptx: Re-enable "Stack alignment causes use of alloca" test cases These generally PASS n

nvptx: Support '-march=sm_37': update '-march-map=sm_50' documentation (was: [PUSHED] nvptx: Support '-march=sm_37')

762caf2125a49a7 "nvptx: Support '-march=sm_37': update '-march-map=sm_50' documentation", see attached. Grüße Thomas >From 59a4089ccab5a8ae3ddfa7b1b762caf2125a49a7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 17 Dec 2024 22:23:50 +0100 Subject: [PATCH] n

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

Hi Paul-Antoine! On 2024-12-16T19:35:01+0100, Paul-Antoine Arras wrote: > On 15/11/2024 14:59, Tobias Burnus wrote: >> Paul-Antoine Arras wrote: >>> This patch adds support for the `dispatch` construct and the >>> `adjust_args` clause to the Fortran front-end. >>> >>> Handling of `adjust_args` ac

RE: [RFC] PR81358: Enable automatic linking of libatomic

Hi Prathamesh! Thanks for working on this! Per my understanding, this patch won't automagically resolve the need to (occasionally) having to specify '-foffload-options=nvptx-none=-latomic' for nvptx offloading: it doesn't use 'LINK_LIBATOMIC_SPEC', currently only used via 'GNU_USER_TARGET_LINK_G

nvptx: Switch default from '-march=sm_30' to '-march=sm_52' (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04))

Hi! On 2024-09-20T18:49:46+0200, Thomas Schwinge wrote: > We'd like to raise nvptx code generation from PTX ISA 6.0, sm_30 "Kepler" > to default PTX ISA 7.3, sm_52 "Maxwell", therefore CUDA 11.3 (2021-04). > This is, primarily, so that we're able to use &#

Rust: libformat_parser: Lower minimum Rust version to 1.49 (was: Rust: Work around 'error[E0658]: `let...else` statements are unstable')

Hi! On 2024-12-05T13:37:13+0100, Arthur Cohen wrote: > On 12/4/24 13:35, Thomas Schwinge wrote: >> On 2024-11-25T11:24:08+0100, Arthur Cohen wrote: >>> [...] We had previously done something similar to >>> adapt to Rust 1.72 when we originally reused the format

Re: GCN: Fix 'real_from_integer' usage (was: [committed, amdgcn] Zero-initialise masked load destinations)

lude > @@ -761,7 +761,0 @@ private: > -/* Some of the headers included by can use "abort" within a > - namespace, e.g. "_VSTD::abort();", which fails after we use the > - preprocessor to redefine "abort" as "fancy_abort" below

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

gcc/ * config/nvptx/nvptx-sm.def: Add '52'. * 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_52): Likewise.

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

gcc/ * config/nvptx/nvptx-sm.def: Add '89'. * 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_89, -march-map=sm_90

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

gcc/ * config/nvptx/nvptx-opts.h (enum ptx_version): Add 'PTX_VERSION_7_8'. * config/nvptx/nvptx.cc (ptx_version_to_string) (ptx_version_to_number): Adjust. * config/nvptx/nvptx.h (TARGET_PTX_7_8): New. * config/nvptx/nvptx.opt (Enum(ptx_versi

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

gcc/ * config/nvptx/nvptx-sm.def: Add '37'. * 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_37, -march-map=sm_50

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

gcc/ * config/nvptx/nvptx-opts.h (enum ptx_version): Add 'PTX_VERSION_4_1'. * config/nvptx/nvptx.cc (ptx_version_to_string) (ptx_version_to_number): Adjust. * config/nvptx/nvptx.h (TARGET_PTX_4_1): New. * config/nvptx/nvptx.opt (Enum(ptx_versi

nvptx: Expose '-mptx=4.2' (was: [committed][nvptx] Choose -mptx default based on -misa)

se to the user and which not to. Therefore, let's just expose all of them. I've pushed to trunk branch commit 1af83aa09979e5f2ca36f844d56ccd629268057d "nvptx: Expose '-mptx=4.2'", see attached. Grüße Thomas >From 1af83aa09979e5f2ca36f844d56ccd629268057d Mon Sep 17 00:00:00 200

nvptx: Clarify that our baseline is PTX ISA Version 3.1 (was: [committed][nvptx] Choose -mptx default based on -misa)

N_4_2, >PTX_VERSION_6_0, >PTX_VERSION_6_3, >PTX_VERSION_7_0 Pushed to trunk branch commit 380ceb23b130a2b9ec541607a3eb1ffd0387c576 "nvptx: Clarify that our baseline is PTX ISA Version 3.1", see attached. Grüße Thomas >From 380ceb23b130a2b9ec541607a3eb1ffd0387c5

nvptx: Support '--with-multilib-list' (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04))

branch commit 86b3a7532d56f74fcd1c362f2da7f95e8cc4e4a6 "nvptx: Support '--with-multilib-list'", see attached. Grüße Thomas >From 86b3a7532d56f74fcd1c362f2da7f95e8cc4e4a6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 27 Sep 2024 17:44:16 +0200 Subject: [PATCH] nvptx: Support '--wit

nvptx: Enhance '-march-map=[...]' test cases (was: [committed][nvptx] Add march-map)

f8647cad95470fe79 "nvptx: Enhance '-march-map=[...]' test cases", see attached. Grüße Thomas >From ee6711ead30876daf2a8a66f8647cad95470fe79 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 10 Nov 2024 18:29:25 +0100 Subject: [PATCH] nvptx: Enhance '-march-m

nvptx: Enhance '-march=[...]' test cases (was: [committed][nvptx, testsuite] Add gcc.target/nvptx/sm*.c)

nhance '-march=[...]' test cases", see attached. Grüße Thomas >From ed96ce81b19b76ba6a5edfe68dd86d8ea319c6d9 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 10 Nov 2024 20:09:42 +0100 Subject: [PATCH] nvptx: Enhance '-march=[...]' test cases This e

nvptx: Enhance '-mptx=[...]' test cases (was: [committed][nvptx] Add __PTX_ISA_VERSION_{MAJOR,MINOR}__)

gcc.target/nvptx/ptx63.c: New test. > * gcc.target/nvptx/ptx70.c: New test. Pushed to trunk branch commit b7abc7cabdbcc889a74cde1cdc1ffb27cf965128 "nvptx: Enhance '-mptx=[...]' test cases", see attached. Grüße Thomas >From b7abc7cabdbcc889a74cde1cdc1ffb27cf965

Re: [PATCH] config: nvptx: fix bashisms with gen-copyright.sh use

Hi Sam and Tom! On 2024-12-06T09:13:40+, Sam James wrote: > Providing parameters to `.` when sourcing is a bashism and not supported > by POSIX shell which causes a build failure when compiling a toolchain > for nvptx-none with dash as /bin/sh. Hmm, something must be wrong in that statement,

Re: 'gcc/config/nvptx/gen-multilib-matches.sh': Support '--selftest' (was: 'gcc/config/nvptx/t-nvptx': Don't use the 'shell' function of 'make' (was: nvptx: Allow '--with-arch' to override the default

Hi Sam! On 2024-12-06T09:34:32+, Sam James wrote: > The script has #!/bin/sh shebang (and hence must have POSIX shell > compatibility), but the patch introduces uses of the 'local' keyword > which isn't in POSIX. > > While many shells do have the 'local' keyword, its behaviour isn't > portabl

'gcc/config/nvptx/gen-multilib-matches.sh': Support '--selftest' (was: 'gcc/config/nvptx/t-nvptx': Don't use the 'shell' function of 'make' (was: nvptx: Allow '--with-arch' to override the default '-m

+ $(srcdir)/config/nvptx/nvptx-sm.def > + $(SHELL) $< \ > + $(dir $<) \ > + $(multilib_options_isa_default) \ > + '$(multilib_options_isa_list)' \ > + > $@ > + > +include t-nvptx-gen-multilib-matches Pushed to trunk branch com

[PUSHED] 'gcc/config/nvptx/gen-*.sh': Simplify interface

What we currently pass in as '$1' is simply 'dirname "$0"'. gcc/ * config/nvptx/gen-h.sh: Don't pass in '$1'; compute it locally. * config/nvptx/gen-multilib-matches.sh: Likewise. * config/nvptx/gen-omp-device-properties.sh: Likewise. * config/nvptx/gen-opt.

'gcc/config/nvptx/gen-multilib-matches.sh': Encapsulate main logic (was: nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup))

e main logic", see attached. Grüße Thomas >From b352f89d81bb30dbeb406ff7e4d148e2fb640975 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 2 Dec 2024 16:34:03 +0100 Subject: [PATCH] 'gcc/config/nvptx/gen-multilib-matches.sh': Encapsulate main logic Refactoring for lat

'gcc/config/nvptx/t-nvptx': Don't use the 'shell' function of 'make' (was: nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup))

a shell syntax error in 'gen-multilib-matches.sh' -- which '$(shell [...])' swept under the table. Pushed to trunk branch commit 490443357668a87e3c322f218873a7649a2552df "'gcc/config/nvptx/t-nvptx': Don't use the 'shell' function of 'make'", see attached. Grü

[PUSHED] nvptx: Tag '-misa=[...]', '-mptx=[...]' as 'Negative' of themselves [PR117916]

This issue is similar to what a year ago I resolved for GCN in PR112669 "GCN: wrong 'LIBRARY_PATH' in presence of several different '-march=[...]' flags". Given the current standard nvptx configuration, we get: $ build-gcc-offload-nvptx-none/gcc/xgcc -print-multi-directory -mptx=6.3 .

GCN: Fix 'real_from_integer' usage (was: [committed, amdgcn] Zero-initialise masked load destinations)

-# include -#endif In other words, (unconditional) '#include ' appears to preclude ability to convert 'NULL' into a mode? (Or, I'm off-track, of course...) Either way: OK to push the attached "GCN: Fix 'real_from_integer' usage" after testi

Re: Rust: Work around 'error[E0658]: `let...else` statements are unstable'

g the tree buildable with old 'rustc'/'cargo'.) Grüße Thomas > On 11/23/24 9:09 PM, Thomas Schwinge wrote: >> Hi! >> >> On 2024-08-01T16:56:01+0200, Arthur Cohen wrote: >>> Compile libformat_parser and link to it. >> >>> --- /d

Re: [Patch] plugin/plugin-gcn.c: Fix error handling of GOMP_OFFLOAD_openacc_async_construct (was: [Patch] libgomp/plugin/plugin-gcn.c: async-queue init - fix function-return type and fail fatally)

Hi Tobias! On 2024-12-03T11:28:19+0100, Tobias Burnus wrote: > Thomas Schwinge wrote: >> That's a bug in 'libgomp/plugin/plugin-gcn.c:maybe_init_omp_async' (or >> its users); the real user of ['GOMP_OFFLOAD_openacc_async_construct'] does >> han

gccrs: Remove unused files 'gcc/rust/typecheck/rust-hir-type-check-toplevel.{cc,h}' (was: [PATCH] gccrs: Remove unused files)

mmit 104cc285533e742726ae18a7d3d4f384dd20c350 "gccrs: Refactor TypeResolution to be a simple query based system". gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-toplevel.cc: Removed. * typecheck/rust-hir-type-check-toplevel.h: Removed. Signed-off-by: Owen Avery Co

Fix 'libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_get_property-gcn.c' for C23 default (was: [committed] c: Default to -std=gnu23)

ed', I ran into another one; I've pushed to trunk branch commit bcb764ec7c063326a17eb6213313cc9c0fd348b3 "Fix 'libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_get_property-gcn.c' for C23 default", see attached. Grüße Thomas >From bcb764ec7c063326a17eb6213313cc9

Address UNRESOLVED for 'g++.dg/tree-ssa/empty-loop.C' (was: optimize basic_string)

f" "cddce3"} } */ Pushed to trunk branch commit 3e8d3079c31567d3e9f43cc2cb100ddef25f48a2 "Address UNRESOLVED for 'g++.dg/tree-ssa/empty-loop.C'", see attached. Grüße Thomas >From 3e8d3079c31567d3e9f43cc2cb100ddef25f48a2 Mon Sep 17 00:00:00 200

Re: [wwwdocs][committed] projects/gomp/: Update for OpenMP 6.0 spec release

Hi Tobias! On 2024-11-14T18:18:57+0100, Tobias Burnus wrote: > maybe doing parallel work doesn't work well. >From my own experience: no, doesn't. ;-) > --- a/htdocs/projects/gomp/index.html > +++ b/htdocs/projects/gomp/index.html > omp_target_memset and > - omp_target_memset_rect_a

Re: [Patch] libgomp/plugin/plugin-gcn.c: async-queue init - fix function-return type and fail fatally

Hi Tobias! On 2024-11-18T14:23:24+0100, Tobias Burnus wrote: > This fixes a C23 error, causing a build fail: 'false' > should have been 'NULL'. ACK. > The NULL value is not really handled as the code calling > maybe_init_omp_async assumes that agent->omp_async_queue can be > dereferenced. Henc

Rust: Work around 'error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope' (was: [PATCH 048/125] gccrs: format-args: Start storing string in Rust memory)

the current scope'"? Builds and tests fine, but I don't know if this code path is actually exercised at this time, so please check carefully; as you know I'm not actually a Rust programmer (yet). ;-) Grüße Thomas >From 8d4821dabcf4663e51c7db859801837710038821 Mon Sep 17

Re: [PATCH] build: Remove INCLUDE_MEMORY [PR117737]

Hi Andrew! On 2024-11-22T13:15:13-0800, Andrew Pinski wrote: > Since diagnostic.h is included in over half of the sources, requiring to > `#define INCLUDE_MEMORY` > does not make sense. Instead lets unconditionally include memory in system.h. > > The majority of this patch is just removing `#def

Re: [PATCH] v2: Run selftests for C++ as well as C

Hi! I'd like to add selftests for an aspect of the GCC/nvptx back end's multilib configuration, outside of the language front ends: at Makefile/shell level. Looking into GCC's selftest implementation, I found one issue to potentially refactor: On 2018-10-13T09:12:03-0400, David Malcolm wrote: >

Clarify libgomp nvptx 'omp_low_lat_mem_space' documentation (was: [PATCH v2 1/3] libgomp, nvptx: low-latency memory allocator)

t's all fine if just using GCC's defaults. OK to push "Clarify libgomp nvptx 'omp_low_lat_mem_space' documentation", see attached? Grüße Thomas >From a6cdf1358c8b2f5279517ec7ebeb3336299ea928 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 12 Nov 2024 09

Adjust 'libgomp.c/max_vf-*.c' (was: [PATCH 4/4] openmp: Add testcases for omp_max_vf)

offload_nvptx } } } } */ > + > +int main() {} For configurations where both GCN and nvptx offloading are enabled, we get FAILs here. Avoid these via 'only_for_offload_target [...]'. Pushed to trunk branch commit 730f28b081bea4a749f9b82902446731ec8faa93 "Adjust 'libgomp.c/max_vf-*.c'

Re: [PATCH 1/4] openmp: Tune omp_max_vf for offload targets

Hi Andrew! On 2024-11-06T15:27:19+, Andrew Stubbs wrote: > If requested, return the vectorization factor appropriate for the offload > device, if any. > --- a/gcc/omp-general.cc > +++ b/gcc/omp-general.cc > @@ -987,10 +987,11 @@ find_combined_omp_for (tree *tp, int *walk_subtrees, > void *d

Re: [PATCH] Assorted --disable-checking fixes [PR117249]

Hi Jakub! Just one item, quickly: On 2024-10-25T10:19:58+0200, Jakub Jelinek wrote: > We have currently 3 different definitions of gcc_assert macro, one used most > of the time (unless --disable-checking) which evaluates the condition at > runtime and also checks it at runtime, then one for --di

Use unique_ptr in more places in pretty_printer/diagnostics: 'gcc/config/gcn/mkoffload.cc' [PR116613] (was: [RFC/PATCH] Use unique_ptr in more places in pretty_printer/diagnostics [PR116613])

clude "system.h" > #include "coretypes.h" ..., but we likewise need to adjust the GCN one; I've pushed to trunk branch commit b3aa301db1b09b533b3635791a98d6bf906e9a15 "Use unique_ptr in more places in pretty_printer/diagnostics: 'gcc/config/gcn/mkoffload.cc

Re: Fortran test typebound_operator_7.f03 broken by non-Fortran commit. Confirm anyone?

> +se->expr = update_builtin_function (se->expr, sym); > + >/* Allocatable scalar function results must be freed and nullified > after use. This necessitates the creation of a temporary to > hold the result to prevent duplicate calls. */ ..., how

OpenACC 'nohost' clause: harmonize 'libgomp.oacc-{c-c++-common,fortran}/routine-nohost-1.*'

7; "evaluates at compile time to a constant". > +! { dg-skip-if "TODO PR82391" { *-*-* } { "-O0" } } > + > +! { dg-additional-options "-fdump-tree-oaccdevlow" } > + > +program main > +[...] ..., but here we didn't. To address that, I've pushed to trunk br

Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Revert 'gimple_fold_builtin_acc_on_device' change

-tree-dump-times {(?n)^OpenACC routine 'fact_nohost' >> has 'nohost' clause\.$} 1 oaccloops { target { c && offloading_enabled } } } >> } >> { dg-final { scan-tree-dump-times {(?n)^OpenACC routine >> 'fact_nohost\(int\)' has 'nohost

Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Harmonize 'libgomp.oacc-fortran/acc_on_device-1-*'

8593bc9f83195b60ae "Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Harmonize 'libgomp.oacc-fortran/acc_on_device-1-*'", see attached. Grüße Thomas >From 9f549d216c9716e787aaa38593bc9f83195b60ae Mon Sep 17 00:00:00 2001

Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Fix effective-target keyword in 'libgomp.oacc-fortran/acc_on_device-2.f90'

r >> +!$acc routine >> +use openacc >> +implicit none (type, external) >> +if (acc_on_device(acc_device_host)) then >> + xxxx = 1234 >> +else >> + = 4242 >> +end if >> + end >> +end module m >> + &

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device

Hi Tobias! On 2024-10-13T10:21:01+0200, Tobias Burnus wrote: > Now pushed as r15-4298-g3269a722b7a036. > Tobias Burnus wrote: >> Anyone feeling like reviewing this patch? Yes. But please allow for more than 1 1/2 work days. >> Tobias Burnus write: >>> Tobias Burnus wrote: Sometimes waiti

Re: [r15-4104 Regression] FAIL: gfortran.dg/gomp/allocate-static.f90 -Os (test for excess errors) on Linux/x86_64

Hi Tobias! On 2024-10-07T17:07:05+0200, Tobias Burnus wrote: > haochen.jiang wrote: >> On Linux/x86_64, >> FAIL: gfortran.dg/gomp/allocate-static.f90 -O0 (test for excess errors) > > If anyone can reproduce this, I would be interested in the excess errors. gfortran: fatal error: cannot re

nvptx: Disable effective-target 'freestanding' (was: [PATCH 3/9] nvptx: Re-enable test cases by removing effective target 'freestanding')

r variant of this to trunk branch in commit 65c7616c251a6697134b2a3ac7fe6460d308d2ed "nvptx: Disable effective-target 'freestanding'", see attached. Grüße Thomas >From 65c7616c251a6697134b2a3ac7fe6460d308d2ed Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 28 Nov 20

Handle non-grouped stores as single-lane SLP: adjust 'gcc.dg/vect/slp-26.c', GCN (was: [PATCH 3/3] Handle non-grouped stores as single-lane SLP)

Hi! On 2024-10-03T13:34:47+0200, Richard Biener wrote: > On Thu, 3 Oct 2024, Thomas Schwinge wrote: >> On 2024-09-06T11:30:06+0200, Richard Biener wrote: >> > On Thu, 5 Sep 2024, Richard Biener wrote: >> >> The following enables single-lane loop SLP discovery

Re: [PATCH 3/3] Handle non-grouped stores as single-lane SLP

Hi! On 2024-09-06T11:30:06+0200, Richard Biener wrote: > On Thu, 5 Sep 2024, Richard Biener wrote: >> The following enables single-lane loop SLP discovery for non-grouped stores >> and adjusts vectorizable_store to properly handle those. > I have now pushed this as r15-3509-gd34cda72098867 >> -

Re: [nvptx PATCH] Implement isfinite and isnormal optabs in nvptx.md.

erands[1], zero)); > + emit_insn (gen_setcc_isnormal (pred2, operands[1])); > + emit_insn (gen_andbi3 (pred3, pred1, pred2)); > + emit_insn (gen_setccsi_from_bi (operands[0], pred3)); > + DONE; > +}) > --- /dev/null > +++ b/gcc/testsuite/gcc.target/nvptx/isnormal.c > @@ -0,0 +1,9 @@

Re: [nvptx PATCH] Implement isfinite and isnormal optabs in nvptx.md.

Hi Roger! On 2024-07-27T19:18:35+0100, "Roger Sayle" wrote: > Firstly, thanks to Haochen Gui for recently adding optab support for > isfinite and isnormal to the middle-end. Do we, by the way, have documentation (I suppose that should be in "GNU Compiler Collection (GCC) Internals"?) about the r

RE: [nvptx] Fix code-gen for alias attribute

lias baz,foo; > > gcc/ChangeLog: > PR target/104957 > * config/nvptx/nvptx.cc (nvptx_asm_output_def_from_decls): Use > cgraph_node::get(name)->ultimate_alias_target instead of value. > > gcc/testsuite/ChangeLog: > PR target/104957 > *

Re: [COMMITTED] testsuite: debug: fix dejagnu directive syntax

Hi Andrew, Sam! On 2024-09-20T14:21:33-0700, Andrew Pinski wrote: > On Fri, Sep 20, 2024 at 1:53 AM Thomas Schwinge > wrote: >> On 2024-09-20T05:12:19+0100, Sam James wrote: >> > In this case, they were all harmless in reality (no diff in test logs). >&g

Re: [Patch, v3] gcn/mkoffload.cc: Use #embed for including the generated ELF file

Hi Tobias! I've not verified, but I very much suspect that this change: On 2024-09-13T16:24:47+0200, Tobias Burnus wrote: > commit 508ef585243d4674d06b0737bfe8769fc18f824f > Author: Tobias Burnus > Date: Fri Sep 13 16:18:46 2024 +0200 > > gcn/mkoffload.cc: Use #embed for including the gen

Re: [Patch][v2] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

Hi Tobias! On 2024-09-19T19:11:32+0200, Tobias Burnus wrote: > OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines '[omp_]get_device_from_uid'. > Those TR13/OpenMP 6.0 routines permit a reproducible offloading to > a specific device by mapping an OpenMP device number to a > unique

Re: [COMMITTED] testsuite: debug: fix dejagnu directive syntax

Hi Sam! On 2024-09-20T05:12:19+0100, Sam James wrote: > In this case, they were all harmless in reality (no diff in test logs). > -/* { dg-do compile ) */ > +/* { dg-do compile } */ DejaGnu directives are matched by '{ dg-[...] }' (simplified; see '/usr/share/dejagnu/dg.exp:dg-get-options' for

GCC 15: nvptx '-mptx=3.1' multilib variants are deprecated

e users for another 1.5 years.) These '-mptx=3.1' multilib variants are only useful for users of ancient CUDA/Nvidia Driver, which doesn't support GCC's default PTX ISA 6.0 multilib variants; PTX ISA 6.0 is supported as of CUDA 9, 2017-09. Grüße Thomas >From 8c099b2c4f

Re: libgomp: with USM, init 'link' variables with host address

Hi Tobias! On 2024-09-15T00:32:21+0200, Tobias Burnus wrote: > The idea of link variables is to replace he full device variable by a > pointer, permitting to map only parts of the variable to the device, > saving memory. > > However, having a pointer permits for (unified) shared memory to point

RE: [nvptx] Pass -m32/-m64 to host_compiler if it has multilib support

Hi Prathamesh! On 2024-09-10T13:22:10+, Prathamesh Kulkarni wrote: >> -Original Message- >> From: Thomas Schwinge >> Sent: Monday, September 9, 2024 8:50 PM >> > Could you please test the patch for gcn backend ? I've successfully tested x86_6

RE: [nvptx] Pass -m32/-m64 to host_compiler if it has multilib support

Hi Prathamesh! On 2024-09-09T06:31:18+, Prathamesh Kulkarni wrote: >> -Original Message- >> From: Thomas Schwinge >> Sent: Friday, September 6, 2024 2:31 PM >> On 2024-08-16T15:36:29+, Prathamesh Kulkarni >> wrote: >> >> > A

Match: Fix ordered and nonequal: Fix 'gcc.dg/opt-ordered-and-nonequal-1.c' re 'LOGICAL_OP_NON_SHORT_CIRCUIT' [PR116635] (was: [PATCH] Match: Fix ordered and nonequal)

h: Fix ordered and nonequal: Fix 'gcc.dg/opt-ordered-and-nonequal-1.c' re 'LOGICAL_OP_NON_SHORT_CIRCUIT' [PR116635]", see attached? Grüße Thomas >From 3e85cb373fb86db5fad86a452a69e713c7050f16 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 9 Sep 2024 08:39:10

RE: [nvptx] Pass -m32/-m64 to host_compiler if it has multilib support

Hi! On 2024-08-16T15:36:29+, Prathamesh Kulkarni wrote: >> > Am 13.08.2024 um 17:48 schrieb Thomas Schwinge >> : >> > On 2024-08-12T07:50:07+, Prathamesh Kulkarni >> wrote: >> >>> From: Thomas Schwinge >> >>> Sent: Friday, Aug

nvptx: Emit DECL and DEF linker markers for aliases [PR104957] (was: Add 'g++.target/nvptx/alias-g++.dg_init_dtor2-1.C' (was: Enhance 'gcc.target/nvptx/alias-*.c' assembler scanning (was: [committed][

the current behavior is an > actual problem. Finally, commit 8f5aade15e595b288a2c4ec60ddde8dc80df1a80 "nvptx: Emit DECL and DEF linker markers for aliases [PR104957]", see attached, to address this issue. Grüße Thomas >From 8f5aade15e595b288a2c4ec60ddde8dc80df1a80 Mon Sep

Add 'g++.target/nvptx/alias-g++.dg_init_dtor2-1.C' (was: Enhance 'gcc.target/nvptx/alias-*.c' assembler scanning (was: [committed][nvptx] Use .alias directive for mptx >= 6.3))

9df0a12ee73ce386315 "Add 'g++.target/nvptx/alias-g++.dg_init_dtor2-1.C'", see attached, as one representative example of C++ code where the current behavior is an actual problem. Grüße Thomas >From a1865fd33897bc6c6e0109df0a12ee73ce386315 Mon Sep 17 00:00:00 2001 From: Th

Enhance 'gcc.target/nvptx/alias-*.c' assembler scanning (was: [committed][nvptx] Use .alias directive for mptx >= 6.3)

mmit d0f02538494ded78cac12c63f5708a53f5a77bda "Enhance 'gcc.target/nvptx/alias-*.c' assembler scanning", see attached. Grüße Thomas >From d0f02538494ded78cac12c63f5708a53f5a77bda Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 17 Jul 2024 15:27:51 +0200 Subject: [P

Re: [committed][nvptx] Use .alias directive for mptx >= 6.3

Hi! 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. > Use this directive to support symbol aliases, as far as possible. > The alias support has the following [and more] limitations. > Aliases to aliases

Fix 'gcc.target/nvptx/alias-2.c' comment (was: [committed][nvptx] Use .alias directive for mptx >= 6.3)

lly: 's%static%extern'. Pushed to trunk branch commit 973c1bf51fb0f58fbfe43651bb0a61e1d124b35d "Fix 'gcc.target/nvptx/alias-2.c' comment", see attached. Grüße Thomas >From 973c1bf51fb0f58fbfe43651bb0a61e1d124b35d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 18 Sep 2023 22:41:56 +020

Move from 'gcc.target/nvptx/nvptx.exp' into 'target-supports.exp' additions for nvptx target (was: [PATCH] Make 'target-supports.exp' additions for nvptx target generally available)

branch commit a121af90fe9244258c8620901dd6fa22537767bb "Move from 'gcc.target/nvptx/nvptx.exp' into 'target-supports.exp' additions for nvptx target", see attached. Grüße Thomas >From a121af90fe9244258c8620901dd6fa22537767bb Mon Sep 17 00:00:00 2001 From: Thomas

nvptx: Use 'enum ptx_version', 'enum ptx_isa' instead of 'int'

Hi! Pushed to trunk branch in commit fee2fbedbb43ad7a017a33ed2b820be79b75e7e5 "nvptx: Use 'enum ptx_version', 'enum ptx_isa' instead of 'int'", see attached. Grüße Thomas >From fee2fbedbb43ad7a017a33ed2b820be79b75e7e5 Mon Sep 17 00:00:00 2001 From:

Fix branch prediction dump message (was: Predict loops containing recursive call with fewer iterations)

01 From: Frederik Harwath Date: Tue, 16 Nov 2021 16:13:51 +0100 Subject: [PATCH] Fix branch prediction dump message Instead of, for instance, "Loop got predicted 1 to iterate 10 times" the message should be "Loop 1 got predicted to iterate 10 times". gcc/ChangeLog: * predict

Fix gimple_debug_cfg declaration (was: [PATCH v2 2/N] Introduce dump_flags_t type and use it instead of int, type)

Hi! On 2017-05-17T11:02:09+0200, Martin Liška wrote: > On 05/17/2017 09:44 AM, Richard Biener wrote: >> On Tue, May 16, 2017 at 4:55 PM, Martin Liška wrote: >>> On 05/16/2017 03:48 PM, Richard Biener wrote: On Fri, May 12, 2017 at 3:00 PM, Martin Liška wrote: > Second part changes 'int

[PING] Handle 'NUM' in 'PUSH_INSERT_PASSES_WITHIN' (was: [PATCH 03/11] Handwritten part of conversion of passes to C++ classes)

PUSH_INSERT_PASSES_WITHIN'"? > > This depends on > <https://inbox.sourceware.org/87jzi9tgcw@euler.schwinge.ddns.net> > "Rewrite usage comment at the top of 'gcc/passes.def'" to avoid running > into the 'ERROR: Can't locate [...]'

Add 'gcc.target/nvptx/alias-to-alias-1.c' (was: [nvptx] Fix code-gen for alias attribute)

a 'ultimate_alias_target': + { dg-final { scan-assembler-times "\\.alias baz,foo;" 1 } } */ /* { dg-final { scan-assembler-times "\\.visible \\.func baz;" 1 } } */ Grüße Thomas >From a89321c890b96c583671b73fc802e87545e4a2b1 Mon Sep 17 00:00:00 2001 From:

Add 'gcc.target/nvptx/alias-weak-1.c' (was: [nvptx] Fix code-gen for alias attribute)

cef7b462f2bb2128bc8ace30 "Add 'gcc.target/nvptx/alias-weak-1.c'", see attached. Grüße Thomas >From 2267d254eb6ad782cef7b462f2bb2128bc8ace30 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 4 Sep 2024 09:58:32 +0200 Subject: [PATCH] Add 'gcc.target/nvptx/a

Re: [nvptx] Fix code-gen for alias attribute

Hi! Honza (or others, of course), there's a question about 'ultimate_alias_target'. On 2024-08-26T10:50:36+, Prathamesh Kulkarni wrote: > For the following test (adapted from pr96390.c): > > __attribute__((noipa)) int foo () { return 42; } > int bar () __attribute__((alias ("foo"))); > int b

Un-XFAIL 'gcc.dg/signbit-5.c' for GCN (was: [PATCH] RISC-V: Remove testcase XFAIL)

-if "truth type does not match vector type" { riscv_v } } */ Same thing for GCN; I've pushed to trunk branch commit 2daf6187c7289d012365419e10995042139cf8f5 "Un-XFAIL 'gcc.dg/signbit-5.c' for GCN", see attached. Grüße Thomas >From 2daf6187c7289d012365419e10

RE: [nvptx] Pass -m32/-m64 to host_compiler if it has multilib support

Hi Prathamesh! On 2024-08-12T07:50:07+, Prathamesh Kulkarni wrote: >> From: Thomas Schwinge >> Sent: Friday, August 9, 2024 12:55 AM >> On 2024-08-08T06:46:25-0700, Andrew Pinski wrote: >> > On Thu, Aug 8, 2024 at 6:11 AM Prathamesh Kulkarni >>

  1   2   3   4   5   6   7   8   9   10   >