Enable 'gcc.dg/pr114768.c' for nvptx target [PR114768] (was: [PATCH] rtlanal: Fix set_noop_p for volatile loads or stores [PR114768])

Hi! On 2024-04-19T12:30:25+0200, Jakub Jelinek wrote: > On Fri, Apr 19, 2024 at 12:23:03PM +0200, Thomas Schwinge wrote: >> On 2024-04-19T08:24:03+0200, Jakub Jelinek wrote: >> > --- gcc/testsuite/gcc.dg/pr114768.c.jj 2024-04-18 15:37:49.139433678 >> > +0200 &g

Re: [PATCH] rtlanal: Fix set_noop_p for volatile loads or stores [PR114768]

Hi Jakub! On 2024-04-19T08:24:03+0200, Jakub Jelinek wrote: > --- gcc/testsuite/gcc.dg/pr114768.c.jj2024-04-18 15:37:49.139433678 > +0200 > +++ gcc/testsuite/gcc.dg/pr114768.c 2024-04-18 15:43:30.389730365 +0200 > @@ -0,0 +1,10 @@ > +/* PR rtl-optimization/114768 */ > +/* { dg-do

GCN: Enable effective-target 'vect_long_long'

Hi! OK to push the attached "GCN: Enable effective-target 'vect_long_long'"? (Or is that not what you'd expect to see for GCN? I haven't checked the actual back end code...) Grüße Thomas >From d74cc9caadfe36652503782a8da172ae1975915c Mon Sep 17 00:00:00 2001 From: Thomas Schwin

build: Use of cargo not yet supported here in Canadian cross configurations (was: [PATCH] build: Check for cargo when building rust language)

ed "build: Use of cargo not yet supported here in Canadian cross configurations"? Grüße Thomas >From eb38990b4147951dd21f19def43072368f782af5 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 15 Apr 2024 14:27:45 +0200 Subject: [PATCH] build: Use of cargo not yet supporte

build: Don't check for host-prefixed 'cargo' program (was: [PATCH] build: Check for cargo when building rust language)

rom 913be0412665d02561f8aeb999860ce8d292c61e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 15 Apr 2024 13:33:48 +0200 Subject: [PATCH] build: Don't check for host-prefixed 'cargo' program Follow-up to commit 3e1e73fc99584440e5967577f2049573eeaf4596 "build: Check for cargo when

Re: [PATCH] build: Check for cargo when building rust language

Hi! On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote: > The rust frontend requires cargo to build some of it's components, In GCC upstream still: 's%requires%is going to require'. ;-) > it's presence was not checked during configuration. After confirming the desired

Re: [gcc r14-7544] gccrs: libproc_macro: Build statically

mit e3fda76af4f342ad1ba8bd901a72d811e8357e99 "Inline 'gcc/rust/Make-lang.in:RUST_LIBDEPS' into single user" Grüße Thomas >From cb70a49b30f0a22ec7a1b7df29c3ab370d603f90 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 28 Feb 2024 22:41:42 +0100 Subject: [PATCH 1/4] Remove

Re: [nvptx PATCH] Correct pattern for popcountdi2 insn in nvptx.md.

Hi Roger! On 2023-01-09T13:29:14+, "Roger Sayle" wrote: > The result of a POPCOUNT operation in RTL should have the same mode > as its operand. This corrects the specification of popcount in > the nvptx backend, splitting the current generic define_insn into > two, one for popcountsi2 and

Re: [PATCH] Regenerate opt.urls

Hi! After having received around a dozen more buildbot notifications... On 2024-04-10T06:46:04-0700, Palmer Dabbelt wrote: > On Tue, 09 Apr 2024 07:57:24 PDT (-0700), ishitatsuy...@gmail.com wrote: >> Fixes: 97069657c4e ("RISC-V: Implement TLS Descriptors.") >> >> gcc/ChangeLog: >> *

Re: [PATCH] contrib/check-params-in-docs.py: Ignore target-specific params

Hi! On 2024-04-12T09:08:13+0200, Filip Kastl wrote: > On Thu 2024-04-11 20:51:55, Thomas Schwinge wrote: >> On 2024-04-11T19:52:51+0200, Martin Jambor wrote: >> > contrib/check-params-in-docs.py is a script that checks that all >> > options reported with ./

Re: [PATCH, OpenACC 2.7, v3] Adjust acc_map_data/acc_unmap_data interaction with reference counters

Hi Chung-Lin! On 2024-04-11T22:08:47+0800, Chung-Lin Tang wrote: > On 2024/3/15 7:24 PM, Thomas Schwinge wrote: >> - if (n->refcount != REFCOUNT_INFINITY) >> + if (n->refcount != REFCOUNT_INFINITY >> + && n->refcount != RE

Re: [PATCH] contrib/check-params-in-docs.py: Ignore gcn-preferred-vectorization-factor

Hi! On 2024-04-11T19:52:51+0200, Martin Jambor wrote: > contrib/check-params-in-docs.py is a script that checks that all > options reported with ./gcc/xgcc -Bgcc --help=param are in > gcc/doc/invoke.texi and vice versa. Eh, first time I'm hearing about this one! (a) Shouldn't this be running

Re: [PATCH, OpenACC 2.7] Connect readonly modifier to points-to analysis

Hi Chung-Lin, Richard! >From me just a few mechanical pieces, see below. Richard, are you able to again comment on Chung-Lin's general strategy, as I'm not at all familiar with those parts of the code? On 2024-04-03T19:50:55+0800, Chung-Lin Tang wrote: > On 2023/10/30 8:46 PM, Richard Biener

Re: [PATCH] openmp: Add support for the 'indirect' clause in C/C++

Hi! I've filed <https://gcc.gnu.org/PR114690> "OpenMP 'indirect' clause: dynamic image loading/unloading" for the following issue: On 2023-11-13T12:47:04+0100, Tobias Burnus wrote: > On 13.11.23 11:59, Thomas Schwinge wrote: >>>> Also, for my understanding: w

Regeneration of 'gcc/config/riscv/riscv.opt.urls' (was: [PATCH v2 2/3] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64))

Hi! On 2024-04-09T09:24:29-0700, Palmer Dabbelt wrote: > On Tue, 09 Apr 2024 01:04:34 PDT (-0700), buga...@gmail.com wrote: >> On Tue, Apr 9, 2024 at 10:27 AM Thomas Schwinge >> wrote: >>> Thanks, pushed to trunk branch: >>> >>> - commit 532c57f8

Re: [PATCH v2 2/3] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64)

Hi! On 2024-04-05T15:13:33+0300, Sergey Bugaev wrote: > On Tue, Apr 2, 2024 at 8:26 PM Richard Sandiford > wrote: >> I don't know if you're waiting on me, but just in case: this and patch 3 >> still LGTM if Thomas is OK with them. > > Thanks. Thomas asked me to resubmit with Changelog entries

Re: [PATCH] rust: Add rust.install-dvi and rust.install-html rules

Hi Christophe! On 2024-04-04T16:27:19+, Christophe Lyon wrote: > rust has the (empty) rust.dvi and rust.html rules, but lacks the > (empty) rust.install-dvi and rust.install-html ones. Thanks, looks good to me. Grüße Thomas > 2024-04-04 Christophe Lyon > > gcc/rust/ > *

GCN: '--param=gcn-preferred-vectorization-factor=[default,32,64]' (was: GCN: '--param=gcn-preferred-vector-lane-width=[default,32,64]')

Hi! On 2024-04-08T13:24:06+0100, Andrew Stubbs wrote: > On 08/04/2024 11:45, Thomas Schwinge wrote: >> On 2024-03-28T08:00:50+0100, I wrote: >>> On 2024-03-22T15:54:48+, Andrew Stubbs wrote: >>>> This patch alters the default (preferred) vector si

New effective-target 'asm_goto_with_outputs' (was: [PATCH] testsuite: Fix up lra effective target)

79.c', currently uses 'target lra', and uses > 'asm goto' -- but not with outputs, so is 'asm_goto_with_outputs' not > really applicable? The test case does PASS for nvptx target (but I've > not verified what it's actually doing/testing). How to handle that one? I've now pushed a v2 vers

GCN: '--param=gcn-preferred-vector-lane-width=[default,32,64]' (was: [committed] amdgcn: Prefer V32 on RDNA devices)

t; PASS: gcc.target/gcn/umax_1.c scan-assembler-times \\tv_cmp_gt_u64\\tvcc, > v[[0-9]+:[0-9]+], v[[0-9]+:[0-9]+] 8 > FAIL: gcc.target/gcn/umax_1.c scan-assembler-times > \\tv_cmpx_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 56 > [-PASS:-]{+FAIL:+} gcc.target/gcn/umax_1.c s

nvptx: In mkoffload.cc, call diagnostic_color_init + gcc_init_libintl: Restore 'libgomp.c/reverse-offload-sm30.c' testing (was: [Patch] nvptx: In mkoffload.cc, call diagnostic_color_init + gcc_init_li

c_init_libintl (); >diagnostic_initialize (global_dc, 0); > + diagnostic_color_init (global_dc); > >if (atexit (mkoffload_cleanup) != 0) > fatal_error (input_location, "atexit failed"); >From 679f81a32f706645f45900fdb1659fb5fe607f77 Mon Sep 17 00:00:00 2001 From: T

Re: [Patch] nvptx: In mkoffload.cc, call diagnostic_color_init + gcc_init_libintl

Hi Tobias! On 2024-04-03T14:06:45+0200, Tobias Burnus wrote: > Nvptx's mkoffload.cc contains 14 'fatal_error' calls and one 'warning_at' > call, > which stands out more clearly (color, bold) when enabling >diagnostic_color_init > which this patch does. — Additionally, the call

Re: [committed] amdgcn: Adjust GFX10/GFX11 cache coherency

Hi! To again state this in public: On 2024-03-22T15:54:49+, Andrew Stubbs wrote: > The RDNA devices have different cache architectures to the CDNA devices, and > the differences go deeper than just the assembler mnemonics, so we > probably need to generate different code to maintain

Re: [committed] amdgcn: Prefer V32 on RDNA devices

Hi Andrew! On 2024-03-22T15:54:48+, Andrew Stubbs wrote: > This patch alters the default (preferred) vector size to 32 on RDNA devices to > better match the actual hardware. 64-lane vectors will continue to be > used where they are hard-coded (such as function prologues). > > We run these

Re: [PATCH] vect: more oversized bitmask fixups

Hi! On 2024-03-22T14:15:36+, Andrew Stubbs wrote: > On 22/03/2024 08:43, Richard Biener wrote: > Thanks, here's what I pushed. > vect: more oversized bitmask fixups > > These patches fix up a failure in testcase vect/tsvc/vect-tsvc-s278.c when > configured to use V32 instead of V64 (I plan

Re: [committed] amdgcn: Ensure gfx11 is running in cumode

Hi Andrew! On 2024-03-21T13:39:53+, Andrew Stubbs wrote: > CUmode "on" is the setting for compatibility with GCN and CDNA devices. > --- a/gcc/config/gcn/gcn-hsa.h > +++ b/gcc/config/gcn/gcn-hsa.h > @@ -107,6 +107,7 @@ extern unsigned int gcn_local_sym_hash (const char *name); >

New effective-target 'asm_goto_with_outputs' (was: [PATCH] testsuite: Fix up lra effective target)

test case, 'gcc.dg/pr110079.c', currently uses 'target lra', and uses 'asm goto' -- but not with outputs, so is 'asm_goto_with_outputs' not really applicable? The test case does PASS for nvptx target (but I've not verified what it's actually doing/testing). How to handle that one? Grüße Thomas >

GCN: Enable effective-target 'vect_hw_misalign'

Hi! OK to push the attached "GCN: Enable effective-target 'vect_hw_misalign'"? (Or is that not what you'd expect to see for GCN? I haven't checked the actual back end code...) Grüße Thomas >From dad0686e179e9395408a39ccfbf760bc30acffc9 Mon Sep 17 00:00:00 2001 From: Thomas S

GCN: Enable effective-target 'vect_long_mult'

Hi! OK to push the attached "GCN: Enable effective-target 'vect_long_mult'"? (Or is that not what you'd expect to see for GCN? I haven't checked the actual back end code...) Grüße Thomas >From e0e58dfc350581ed0519420ad02adcc01e645eae Mon Sep 17 00:00:00 2001 From: Thomas Schwin

GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'

e8055aeee7d7b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 9 Jan 2024 10:25:48 +0100 Subject: [PATCH] GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw' Via XPASSing test cases after commit a657c7e3518fcfc796f223d47385cad5e97dc9a5 "testsuite: un-xfail

Re: [PATCH gcc] Hurd x86_64: add unwind support for signal trampoline code

Hi! Please note that emails to , or don't reach me anymore, and, at least for the time being, likewise for -- is the new thing; see . (Or use , , , as before.) On 2024-03-01T02:33:10+0100, Samuel

Re: [PATCH gcc 1/3] Move GNU/Hurd startfile spec from config/i386/gnu.h to config/gnu.h

Hi! On 2024-01-03T09:49:06+, Richard Sandiford wrote: > The series looks good to me FWIW, but Thomas should have the final say. Richard, thanks for your review. Sergey, great work on aarch64 GNU/Hurd! (... where these GCC bits clearly were the less complicated part...) ;-) Please

Re: [PATCH, OpenACC 2.7] struct/array reductions for Fortran

Hi Chung-Lin! Thanks for your work here, which I'm beginning to look into (prerequisite "[PATCH, OpenACC 2.7] Implement reductions for arrays and structs", first, of course); it'll take me some time. In non-offloading testing, I noticed for x86_64-pc-linux-gnu '-m32': +PASS:

Re: [PATCH, OpenACC 2.7, v2] Adjust acc_map_data/acc_unmap_data interaction with reference counters

Hi Chung-Lin! I realized: please add "PR libgomp/92840" to the Git commit log, as your changes are directly a continuation of my earlier changes. On 2024-03-05T01:18:28+0900, Chung-Lin Tang wrote: > On 2023/10/31 11:06 PM, Thomas Schwinge wrote: >>> @@ -691,15 +694,27

OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing (was: [PATCH, OpenACC 2.7, v2] readonly modifier support in front-ends)

end kernels >> + >> + !$acc serial copyin(readonly: a(:), b(:n)) copyin(c(:)) >> + do i = 1,32 >> + !$acc cache (readonly: a(:), b(:n)) >> + !$acc cache (c(:)) >> + enddo >> + !$acc end serial >> + >> + !$acc data co

Re: [PATCH, OpenACC 2.7, v2] readonly modifier support in front-ends

Hi Chung-Lin! On 2024-03-07T17:02:02+0900, Chung-Lin Tang wrote: > On 2023/10/26 6:43 PM, Thomas Schwinge wrote: >>>>>> +++ b/gcc/tree.h >>>>>> @@ -1813,6 +1813,14 @@ class auto_suppress_location_wrappers >>>>>

Re: nvptx: 'cuDeviceGetCount' failure is fatal

Hi Tobias! On 2024-03-07T15:28:21+0100, Tobias Burnus wrote: > Thomas Schwinge wrote: >> OK to push the attached "nvptx: 'cuDeviceGetCount' failure is fatal"? > > I think the real question is: what does a 'cuDeviceGetCount' fail mean? Internally to the CUDA stack: th

Re: [PATCH v2] openmp: Change to using a hashtab to lookup offload target addresses for indirect function calls

Hi! On 2024-01-29T17:48:47+, Kwok Cheung Yeung wrote: > A splay-tree was previously used to lookup equivalent target addresses > for a given host address on offload targets. However, as splay-trees can > modify their structure on lookup, they are not suitable for concurrent > access from

Fix 'char' initialization, copy, check in 'libgomp.oacc-fortran/acc-memcpy.f90' (was: [patch] OpenACC: Add Fortran routines acc_{alloc,free,hostptr,deviceptr,memcpy_{to,from}_device*})

_device (char, dptr, 256_c_size_t) > + > + do i = -128, 127 > +char(i) = int (j, int8) > +if (char(i) /= j) & > + stop 2 > + end do > + > + do i = 0, 255 > +if (acc_is_present (transfer (transfer(char, i) + i, dptr), 1)) & > + stop 3 > + en

GCN, nvptx: Errors during device probing are fatal (was: Stabilizing flaky libgomp GCN target/offloading testing)

Hi! On 2024-02-21T13:34:01+0100, I wrote: > On 2024-02-01T15:49:02+0100, Richard Biener wrote: >> On Thu, 1 Feb 2024, Thomas Schwinge wrote: >>> [...] what I >>> got with '-march=gfx1100' for AMD Radeon RX 7900 XTX. [...] > >>> [...] execution test FA

Re: GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is not fatal

isn't applicable (non-shared memory system)" does clarify that. Just to close this out, let's try again for the other discussion items: > Thomas Schwinge wrote: >> On 2024-03-07T12:43:07+0100, Tobias Burnus wrote: >>> Thomas Schwinge wrote: >>>> First, I th

GCN: The original meaning of 'GCN_SUPPRESS_HOST_FALLBACK' isn't applicable (non-shared memory system) (was: GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is

> On 2024-03-07T12:43:07+0100, Tobias Burnus wrote: >> Thomas Schwinge wrote: >>> [...] libgomp GCN plugin 'GCN_SUPPRESS_HOST_FALLBACK' [...] >>> >>> [...] originates in the libgomp HSA plugin, where the idea was -- in my >>> understanding -- that you wo

Re: GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is not fatal

Hi Tobias! On 2024-03-07T12:43:07+0100, Tobias Burnus wrote: > Thomas Schwinge wrote: >> An issue with libgomp GCN plugin 'GCN_SUPPRESS_HOST_FALLBACK' (which is >> different from the libgomp-level host-fallback execution): >>> +failure: >>&

Re: GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is not fatal

Hi Andrew! On 2024-03-07T11:38:27+, Andrew Stubbs wrote: > On 07/03/2024 11:29, Thomas Schwinge wrote: >> On 2019-11-12T13:29:16+, Andrew Stubbs wrote: >>> This patch contributes the GCN libgomp plugin, with the various >>> configure and make bits to

nvptx: 'cuDeviceGetCount' failure is fatal (was: [Patch] OpenMP: Move omp requires checks to libgomp)

+ else if (new_num_devs >= 1) > { > /* Augment DEVICES and NUM_DEVICES. */ OK to push the attached "nvptx: 'cuDeviceGetCount' failure is fatal"? Grüße Thomas >From 8090da93cb00e4aa47a8b21b6548d739b2cebc49 Mon Sep 17 00:00:00 2001 From: Th

GCN, nvptx: Fatal error for missing symbols in 'libhsa-runtime64.so.1', 'libcuda.so.1' (was: [PATCH] Allow building GCC with PTX offloading even without CUDA being installed (gcc and nvptx-tools patch

tached "GCN, nvptx: Fatal error for missing symbols in 'libhsa-runtime64.so.1', 'libcuda.so.1'"? > + [...] > + cuda_lib_inited = true; > + return true; > } Grüße Thomas >From 6a6520e01f7e7118b556683c2934f2c64c6dbc81 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 7 Mar 2024 12:31:52 +01

GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is not fatal (was: [PATCH 7/7 libgomp,amdgcn] GCN Libgomp Plugin)

lets libgomp proper do its thing), and I propose we do the same here. OK to push the attached "GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is not fatal"? Grüße Thomas >From f037d2d8274940f042633a0ecb18a53942c075f5 Mon Sep 17 00:00:00 2001 From: Thomas Sch

amdgcn: additional gfx1030/gfx1100 support: adjust test cases (was: [PATCH] amdgcn: additional gfx1100 support)

: NULL); > +operands[2] = shiftwidth; > + > +if (!shiftwidth) > + return "v_mov_b32 %0, %1"; > +else if ( == extend || == trunc) > + return "v_lshlrev_b32\t%0, %2, %1\;v_ashrrev_i32\t%0, %2, %0"; > +else > + retur

Stabilize flaky GCN target/offloading testing

Hi! On 2024-02-21T17:32:13+0100, Richard Biener wrote: > Am 21.02.2024 um 13:34 schrieb Thomas Schwinge : >> [...] per my work on <https://gcc.gnu.org/PR66005> >> "libgomp make check time is excessive", all execution testing in libgomp >> is

Re: [Patch] OpenMP: Reject non-const 'condition' trait in Fortran (was: [Patch] OpenMP: Handle DECL_ASSEMBLER_NAME with 'declare variant')

Hi Tobias! On 2024-02-13T18:31:02+0100, Tobias Burnus wrote: > --- a/gcc/fortran/openmp.cc > +++ b/gcc/fortran/openmp.cc > + /* Device number must be conforming, which includes > + omp_initial_device (-1) and omp_invalid_device (-4). */ > + if (property_kind ==

Update GCC 14 OpenACC changes some more (was: [wwwdocs] gcc-14/changes.html + projects/gomp/: OpenMP + OpenACC update)

hanges.html + projects/gomp/: OpenMP + OpenACC update", I've pushed commit df2bc49fc018c2b1aeb27030fe1967470d0d4ec3 "Update GCC 14 OpenACC changes some more", see attached. Grüße Thomas >From df2bc49fc018c2b1aeb27030fe1967470d0d4ec3 Mon Sep 17 00:00:00 2001 From: Thomas Schwin

Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests

Hi! On 2024-02-01T19:20:57+, John David Anglin wrote: > Tested on hppa-unknown-linux-gnu. Committed to trunk. > Set num_threads to 50 on 32-bit hppa in two libgomp loop tests > > We support a maximum of 50 threads on 32-bit hppa. What happens if you go higher? Curious, what/why is that

Re: [PATCH] lto, Darwin: Fix offload section names.

Hi Iain! On 2024-01-16T15:00:16+, Iain Sandoe wrote: > Currently, these section names have wrong syntax for Mach-O. > Although they were added some time ago; recently added tests are > now emitting them leading to new fails on Darwin. > > This adds a Mach-O variant for each. >

Re: [patch] OpenACC: Add Fortran routines acc_{alloc,free,hostptr,deviceptr,memcpy_{to,from}_device*}

Hi Tobias! On 2024-02-27T13:29:33+0100, Tobias Burnus wrote: > Thomas Schwinge: >>> @table @asis >>> @item @emph{Description} >>> -This function allocates @var{len} bytes of device memory. It returns >>> +This function allocates @var{bytes} of device

Re: [patch] OpenACC: Add Fortran routines acc_{alloc,free,hostptr,deviceptr,memcpy_{to,from}_device*}

Hi Tobias! On 2024-02-19T22:36:51+0100, Tobias Burnus wrote: > While waiting for some testing to finish, I got distracted and added the > very low hanging OpenACC 3.3 fruits, i.e. those Fortran routines that directly > map to their C counter part. > > Comments, remarks? Thanks, that largely

Stabilizing flaky libgomp GCN target/offloading testing (was: libgomp GCN gfx1030/gfx1100 offloading status)

Hi! On 2024-02-01T15:49:02+0100, Richard Biener wrote: > On Thu, 1 Feb 2024, Thomas Schwinge wrote: >> On 2024-01-26T10:45:10+0100, Richard Biener wrote: >> > On Fri, 26 Jan 2024, Richard Biener wrote: >> >> On Wed, 24 Jan 2024, Andrew Stubbs wrote: >>

Re: GCN RDNA2+ vs. GCC SLP vectorizer

Hi Richard! On 2024-02-20T08:44:35+0100, Richard Biener wrote: > On Mon, 19 Feb 2024, Thomas Schwinge wrote: >> On 2024-02-19T17:31:20+0100, I wrote: >> > On 2024-02-19T11:52:55+0100, Richard Biener wrote: >> >> On Mon, 19 Feb 2024, Thomas Schwinge wrote: >>

GCN: Restore lost '__gfx90a__' target CPU definition (was: [Patch] GCN: Add pre-initial support for gfx1100)

intentional that we lost gfx90a here -- I've pushed to master branch commit 159174f25716c18a74a915cb01b9a28024ea7a3d "GCN: Restore lost '__gfx90a__' target CPU definition", see attached. Grüße Thomas >From 159174f25716c18a74a915cb01b9a28024ea7a3d Mon Sep 17 00:00:00 2001 F

Re: GCN RDNA2+ vs. GCC SLP vectorizer

Hi! On 2024-02-19T17:31:20+0100, I wrote: > On 2024-02-19T11:52:55+0100, Richard Biener wrote: >> On Mon, 19 Feb 2024, Thomas Schwinge wrote: >>> On 2024-02-16T14:53:04+0100, I wrote: >>> > On 2024-02-16T12:41:06+, Andrew Stubbs wrote: >>> >&

Re: GCN RDNA2+ vs. GCC SLP vectorizer

Hi! On 2024-02-19T11:52:55+0100, Richard Biener wrote: > On Mon, 19 Feb 2024, Thomas Schwinge wrote: >> On 2024-02-16T14:53:04+0100, I wrote: >> > On 2024-02-16T12:41:06+, Andrew Stubbs wrote: >> >> On 16/02/2024 12:26, Richard Biener wrote: >> >>

Re: GCN RDNA2+ vs. GCC SLP vectorizer

Hi! On 2024-02-16T14:53:04+0100, I wrote: > On 2024-02-16T12:41:06+, Andrew Stubbs wrote: >> On 16/02/2024 12:26, Richard Biener wrote: >>> On Fri, 16 Feb 2024, Andrew Stubbs wrote: >>>> On 16/02/2024 10:17, Richard Biener wrote: >>>>&g

GCN: Conditionalize 'define_expand "reduc__scal_"' on '!TARGET_RDNA2_PLUS' [PR113615] (was: [patch] gcn/gcn-valu.md: Disable fold_left_plus for TARGET_RDNA2_PLUS [PR113615])

and "reduc__scal_" [(match_operand: 0 "register_operand") (fminmaxop:V_FP (match_operand:V_FP 1 "register_operand"))] - "" + "!TARGET_RDNA2_PLUS" { /* fmin/fmax are identical to smin/smax. */

Re: GCN RDNA2+ vs. GCC SLP vectorizer

Hi! On 2024-02-16T12:41:06+, Andrew Stubbs wrote: > On 16/02/2024 12:26, Richard Biener wrote: >> On Fri, 16 Feb 2024, Andrew Stubbs wrote: >>> On 16/02/2024 10:17, Richard Biener wrote: >>>> On Fri, 16 Feb 2024, Thomas Schwinge wrote: >>>>> On 2

GCN RDNA2+ vs. GCC SLP vectorizer (was: [committed] amdgcn: add -march=gfx1030 EXPERIMENTAL)

Hi! On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote: > I've committed this patch ... as commit c7ec7bd1c6590cf4eed267feab490288e0b8d691 "amdgcn: add -march=gfx1030 EXPERIMENTAL", which the later RDNA3/gfx1100 support builds on top of, and that's what I'm currently working on getting proper

Re: GCN RDNA2+ vs. GCC vectorizer "Reduce using vector shifts"

> On Wed, 14 Feb 2024, Andrew Stubbs wrote: >> >>>> On 13/02/2024 08:26, Richard Biener wrote: >> >>>>> On Mon, 12 Feb 2024, Thomas Schwinge wrote: >> >>>>>> On 2023-10-20T12:51:03+0100, Andrew Stubbs >> >>>>>> wrot

GCN RDNA2+ vs. GCC vectorizer "Reduce using vector shifts" (was: [committed] amdgcn: add -march=gfx1030 EXPERIMENTAL)

Hi! On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote: > I've committed this patch ... as commit c7ec7bd1c6590cf4eed267feab490288e0b8d691 "amdgcn: add -march=gfx1030 EXPERIMENTAL". The RDNA2 ISA variant doesn't support certain instructions previous implemented in GCC/GCN, so a number of

libgomp GCN gfx1030/gfx1100 offloading status (was: [PATCH] amdgcn: additional gfx1100 support)

Hi! On 2024-01-26T10:45:10+0100, Richard Biener wrote: > On Fri, 26 Jan 2024, Richard Biener wrote: >> On Wed, 24 Jan 2024, Andrew Stubbs wrote: >> > [...] is enough to get gfx1100 working for most purposes, on top of the >> > patch that Tobias committed a week or so ago; there are still some

GCN: Don't hard-code number of SGPR/VGPR/AVGPR registers (was: [PATCH v3 05/10] GCN back-end code)

fine VGPR_REGNO(N)((N)+FIRST_VGPR_REG) > +#define LAST_VGPR_REG415 OK to push "GCN: Don't hard-code number of SGPR/VGPR/AVGPR registers", see attached? Grüße Thomas >From ff812668636bce9d203acbcbdc19260f98857e03 Mon Sep 17 00:00:00 2001 From: Thomas S

GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'

Hi! On 2024-01-31T11:31:00+, Andrew Stubbs wrote: > On 31/01/2024 10:36, Thomas Schwinge wrote: >> OK to push "GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'", >> see attached? >> >> In pre-RDNA 3 ISA manuals, there are notes for 'DS_CMPST_[...]',

GCN: Remove 'FIRST_{SGPR,VGPR,AVGPR}_REG', 'LAST_{SGPR,VGPR,AVGPR}_REG' from machine description (was: [PATCH v3 04/10] GCN machine description)

etween 'gcn.h' and 'gcn.md'? Until that's settled, OK to push the attached "GCN: Remove 'FIRST_{SGPR,VGPR,AVGPR}_REG', 'LAST_{SGPR,VGPR,AVGPR}_REG' from machine description"? (I assume "still builds" is sufficient validation of this change.) Grüße Thomas >From 6af477

GCN: Remove 'SGPR_OR_VGPR_REGNO_P' definition (was: [PATCH v3 05/10] GCN back-end code)

uot;GCN: Remove 'SGPR_OR_VGPR_REGNO_P' definition"? Grüße Thomas >From 849a52b3dcfdd840e6d24a1924962bb01762c1b1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 31 Jan 2024 12:25:25 +0100 Subject: [PATCH] GCN: Remove 'SGPR_OR_VGPR_REGNO_P' definition ..., which was always (a)

GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'

ße Thomas >From df6e031bf4b46d9e5b2de117fecd66b8b9b6dd20 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 31 Jan 2024 10:19:00 +0100 Subject: [PATCH] GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn' For OpenACC/GCN '-march=gfx1100', a lot of test cases FAIL: /tmp/ccGfLJ8a.mkof

Re: [v2][patch] plugin/plugin-nvptx.c: Fix fini_device call when already shutdown [PR113513]

Hi Tobias! On 2024-01-23T10:55:16+0100, Tobias Burnus wrote: > Slightly changed patch: > > nvptx_attach_host_thread_to_device now fails again with an error for > CUDA_ERROR_DEINITIALIZED, except for GOMP_OFFLOAD_fini_device. > > I think it makes more sense that way. Agreed. > Tobias Burnus

Re: [patch] nvptx.opt: Add sm_89 and sm_90a to -march-map=

Hi Tobias! On 2024-01-20T10:57:29+0100, Tobias Burnus wrote: > Stumbled over this as we recently got a sm_89 card. > > -march-map= is mostly a future proof method for user to ensure to use > always the best code gen for a specific card - without needing to know > which GCC version added

Re: [patch] amdgcn: config.gcc - enable gfx1030 and gfx1100 multilib; add them to the docs

Hi! Great progress that you've made! :-) On 2024-01-26T13:32:02+0100, Tobias Burnus wrote: > Tobias Burnus wrote: >> Am 24.01.24 um 17:01 schrieb Tobias Burnus: >>> Okay to enable gfx1100 multilib building and to document gfx1100 in >>> the manual? >> >> and, with this patch, additionally

Re: [PATCH] x86: Update PR 35513 tests

Hi! On 2022-02-10T05:55:15-0800, "H.J. Lu via Gcc-patches" wrote: > 1. Require linker with GNU_PROPERTY_1_NEEDED support for PR 35513 > run-time tests. Moving my x86_64-pc-linux-gnu testing from an old to a newish system (Ubuntu 20.04), I notice: [-PASS: g++.target/i386/pr35513-1.C

MAINTAINERS: Update my work email address

♂️ | | GCC, GNU Toolchain, HPC, embedded -- and more to come! | | (Please allow us some time to regroup.) Copyright assignment for BayLibre is in progress. Grüße Thomas >From 7fcdb501366632fbf98a1eff275d76b9eea91aa1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 24 Jan 2024 12:

GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'

bde8055aeee7d7b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 9 Jan 2024 10:25:48 +0100 Subject: [PATCH] GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw' Via XPASSing test cases after commit a657c7e3518fcfc796f223d47385cad5e97dc9a5 "testsuite: un-xfail TS

Re: [PATCHSET] Fix Rust bootstrap for future libgrust changes

Hi! On 2024-01-11T15:22:07+0100, Arthur Cohen wrote: > Sorry about this - two simple changes to Makefile.def we had missed > during our first libgrust/ patchset I don't think those were "missed" but rather "intentionally omitted"? I'll have to have a more detailed look. (..., and almost no

Re: [PATCH 1/8] OpenMP: lvalue parsing for map/to/from clauses (C++)

Hi Julian! On 2024-01-07T16:04:37+0100, Tobias Burnus wrote: > Am 05.01.24 um 13:23 schrieb Julian Brown: >> Here's a rebased/retested version [...] > LGTM - [...] Got pushed as commit r14-7033-g1413af02d62182bc1e19698aaa4dae406f8f13bf "OpenMP: lvalue parsing for map/to/from clauses (C++)".

Re: [Patch] GCN: Add pre-initial support for gfx1100

ße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From f9290cdf4697f467fd0fb7c710f58cc12e497889 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 8 Jan 2

Re: OpenMP offloading vs. C++ static local variables

Hi! On 2023-12-21T13:58:23+0100, Jakub Jelinek wrote: > On Thu, Dec 21, 2023 at 01:31:19PM +0100, Thomas Schwinge wrote: >> [...] the gimplification-level code re >> 'Static locals [...] need to be "omp declare target"' runs *after* >> 'omp_discover_implicit_declar

Re: OpenMP offloading vs. C++ static local variables

Hi Jakub! On 2023-12-07T16:33:08+0100, Jakub Jelinek wrote: > On Thu, Dec 07, 2023 at 04:09:04PM +0100, Thomas Schwinge wrote: >> > Yeah, I believe we should in the omp_discover_* sub-pass handle with >> > a help of a langhook automatically mark the guard variables (possibly

RE: [PATCH v7] libgfortran: Replace mutex with rwlock

Hi! On 2023-12-13T21:52:29+0100, I wrote: > On 2023-12-12T02:05:26+, "Zhu, Lipeng" wrote: >> On 2023/12/12 1:45, H.J. Lu wrote: >>> On Sat, Dec 9, 2023 at 7:25 PM Zhu, Lipeng wrote: >>> > On 2023/12/9 23:23, Jakub Jelinek wrote: >>> > > On Sat, Dec 09, 2023 at 10:39:45AM -0500, Lipeng Zhu

Re: [PATCH] tree-optimization/113073 - amend PR112736 fix

Hi Richard! On 2023-12-20T14:44:29+0100, Richard Biener wrote: > On Wed, 20 Dec 2023, Richard Biener wrote: >> On Wed, 20 Dec 2023, Thomas Schwinge wrote: >> > On 2023-12-19T13:30:58+0100, Richard Biener wrote: >> > > The PR112736 testcase fails on RISC-V

No libstdc++ for GCN (was: No libstdc++ for nvptx)

Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 4d9d015cf4

Re: [PATCH] tree-optimization/113073 - amend PR112736 fix

Hi! On 2023-12-19T13:30:58+0100, Richard Biener wrote: > The PR112736 testcase fails on RISC-V because the aligned exception > uses the wrong check. The alignment support scheme can be > dr_aligned even when the access isn't aligned to the vector size > but some targets are happy with element

Unify OpenACC/C and C++ behavior re duplicate OpenACC 'declare' directives for 'extern' variables [PR90868] (was: [committed] [PR90868] Document status quo for duplicate OpenACC 'declare' directives f

Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From cf840a7f7c14242ab7018071310851486a55

libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056] (was: [PATCH v2 2/4] libgrust: Add libproc_macro and build system)

nchen; Registergericht München, HRB 106955 >From 71e00b191bd630aa3be66e38069c707ae76a91d3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 18 Dec 2023 16:27:39 +0100 Subject: [PATCH] libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056] ..., but not for host builds, which

Re: [committed] amdgcn: XNACK support

Hi Andrew! On 2023-12-13T15:46:45+, Andrew Stubbs wrote: > Some AMD GCN devices support an "XNACK" mode in which the device can > handle page-misses (and maybe other traps in memory instructions), but > it's not completely invisible to software. > > We need this now to support OpenMP Unified

Re: [PATCH v7 4/5] OpenMP/OpenACC: Unordered/non-constant component offset runtime diagnostic

ns Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From bc7546e32c5a942e240ef97776352d21105ef291 Mon Sep 17 00:00:00 2001 From: Tho

Re: [PATCH v2 2/4] libgrust: Add libproc_macro and build system

Hi Jason! I think you usually deal with these kind of GCC Git things? If not, please let me know. On 2023-10-26T10:21:18+0200, I wrote: > First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2 > the "v2" libgrust changes as posted by Arthur, so that people can easily > test this

RE: [PATCH v4] [tree-optimization/110279] Consider FMA in get_reassociation_width

into _63 = powmult_1 + powmult_3; $ grep -cF .FMA pr110279-2.c.265t.optimized 0 Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf;

Re: [PATCH] Fix tests for gomp

Hi! On 2023-12-13T12:09:14+0100, Jakub Jelinek wrote: > On Wed, Dec 13, 2023 at 11:03:50AM +, Andre Vieira (lists) wrote: >> Hmm I think I understand what you are saying, but I'm not sure I agree. >> So before I enabled simdclone testing for aarch64, this test had no target >> selectors.

Update 'gcc.dg/vect/vect-simd-clone-*.c' GCN 'dg-warning's (was: [PATCH] aarch64: enable mixed-types for aarch64 simdclones)

tinbranch > +#endif > __attribute__((noinline)) long int > bar (int a, int b, long int c) > { - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heu

In 'gcc/gimple-ssa-sccopy.cc', '#define INCLUDE_ALGORITHM' instead of '#include ' (was: [PATCH v4] A new copy propagation and PHI elimination pass)

n, HRB 106955 >From 65e41f4fbfc539c5cc429c684176f8ea39f4b8f2 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 14 Dec 2023 14:12:45 +0100 Subject: [PATCH] In 'gcc/gimple-ssa-sccopy.cc', '#define INCLUDE_ALGORITHM' instead of '#include ' ... to avoid issues such as: In file included from [...]/lib/gcc/i

RE: [PATCH v7] libgfortran: Replace mutex with rwlock

Hi Lipeng! On 2023-12-14T02:28:22+, "Zhu, Lipeng" wrote: > On 2023/12/14 4:52, Thomas Schwinge wrote: >> On 2023-12-12T02:05:26+, "Zhu, Lipeng" wrote: >> > On 2023/12/12 1:45, H.J. Lu wrote: >> >> On Sat, Dec 9, 2023 at 7:25 PM Zhu, L

RE: [PATCH v7] libgfortran: Replace mutex with rwlock

Hi Lipeng! On 2023-12-12T02:05:26+, "Zhu, Lipeng" wrote: > On 2023/12/12 1:45, H.J. Lu wrote: >> On Sat, Dec 9, 2023 at 7:25 PM Zhu, Lipeng wrote: >> > On 2023/12/9 23:23, Jakub Jelinek wrote: >> > > On Sat, Dec 09, 2023 at 10:39:45AM -0500, Lipeng Zhu wrote: >> > > > This patch try to

Fix 'libgomp/config/linux/allocator.c' 'size_t' vs. '%ld' format string mismatch (was: Build breakage)

Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 5445ff4a51fcee4d281f79b5f54b349290d0327d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 13 Dec 2023 1

Re: GCC/Rust libgrust-v2/to-submit branch

Hi Arthur, Pierre-Emmanuel! On 2023-12-12T10:39:50+0100, I wrote: > On 2023-11-27T16:46:08+0100, I wrote: >> On 2023-11-21T16:20:22+0100, Arthur Cohen wrote: >>> On 11/20/23 15:55, Thomas Schwinge wrote: >>>> Arthur and Pierre-Emmanuel have prepared a GCC/Rust lib

  1   2   3   4   5   6   7   8   9   10   >