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

[gcc r14-10039] Enable 'gcc.dg/pr114768.c' for nvptx target [PR114768]

https://gcc.gnu.org/g:9451b6c0a941dc44ca6f14ff8565d74fe56cca59 commit r14-10039-g9451b6c0a941dc44ca6f14ff8565d74fe56cca59 Author: Thomas Schwinge Date: Fri Apr 19 12:32:03 2024 +0200 Enable 'gcc.dg/pr114768.c' for nvptx target [PR114768] Follow-up to commit

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

[gcc r14-10004] GCN: Enable effective-target 'vect_long_long'

https://gcc.gnu.org/g:420ece6b2334bcbbd9da905866f2ca77d4b5fdae commit r14-10004-g420ece6b2334bcbbd9da905866f2ca77d4b5fdae Author: Thomas Schwinge Date: Tue Apr 16 14:10:15 2024 +0200 GCN: Enable effective-target 'vect_long_long' ... as made apparent by a number of unexpectedly

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

[gcc r14-9988] build: Don't check for host-prefixed 'cargo' program

https://gcc.gnu.org/g:3ebc7898a55988e84ab3625700a827e3e82b016f commit r14-9988-g3ebc7898a55988e84ab3625700a827e3e82b016f Author: Thomas Schwinge Date: Mon Apr 15 13:33:48 2024 +0200 build: Don't check for host-prefixed 'cargo' program Follow-up to commit

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: 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

Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)

or disable '--enable-languages=rust' for those. Grüße Thomas > Revision: a3281dd0f4b46c16ec1192ad411c0a96e6d086eb > Worker: bb1-1 > Build Reason: (unknown) > Blamelist: H.J. Lu , Pierre-Emmanuel Patry > , Tamar Christina > , Thomas Schwinge > > Steps: > > - 0: w

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

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: [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: [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

[gcc r14-9964] Remove 'libgrust/libproc_macro_internal' from 'gcc/rust/Make-lang.in:RUST_LDFLAGS'

https://gcc.gnu.org/g:cb70a49b30f0a22ec7a1b7df29c3ab370d603f90 commit r14-9964-gcb70a49b30f0a22ec7a1b7df29c3ab370d603f90 Author: Thomas Schwinge Date: Wed Feb 28 22:41:42 2024 +0100 Remove 'libgrust/libproc_macro_internal' from 'gcc/rust/Make-lang.in:RUST_LDFLAGS' This isn't

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: >> *

[gcc r14-9945] Regenerate opt.urls

https://gcc.gnu.org/g:c9500083073ff5e0f5c1c9db92d7ce6e51a62919 commit r14-9945-gc9500083073ff5e0f5c1c9db92d7ce6e51a62919 Author: Tatsuyuki Ishi Date: Tue Apr 9 23:57:24 2024 +0900 Regenerate opt.urls Fixes: 97069657c4e ("RISC-V: Implement TLS Descriptors.")

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

[gcc r14-9858] libgcc: Add basic support for aarch64-gnu (GNU/Hurd on AArch64)

https://gcc.gnu.org/g:46c91665f4bceba19aed56f5bd6e934c548b84ff commit r14-9858-g46c91665f4bceba19aed56f5bd6e934c548b84ff Author: Sergey Bugaev Date: Sat Mar 23 17:35:13 2024 +0300 libgcc: Add basic support for aarch64-gnu (GNU/Hurd on AArch64) There is currently no unwinding

[gcc r14-9857] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64)

https://gcc.gnu.org/g:9670a2326333caa8482377c00beb65723b7b4b26 commit r14-9857-g9670a2326333caa8482377c00beb65723b7b4b26 Author: Sergey Bugaev Date: Sat Mar 23 17:35:12 2024 +0300 aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64) Coupled with a corresponding binutils

[gcc r14-9856] Move GNU/Hurd startfile spec from config/i386/gnu.h to config/gnu.h

https://gcc.gnu.org/g:532c57f8c3a15b109a46d3e2b14d60a5c40979d5 commit r14-9856-g532c57f8c3a15b109a46d3e2b14d60a5c40979d5 Author: Sergey Bugaev Date: Sat Mar 23 17:35:11 2024 +0300 Move GNU/Hurd startfile spec from config/i386/gnu.h to config/gnu.h Since it's not i386-specific;

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/ > *

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

[gcc r14-9844] GCN, nvptx: Errors during device probing are fatal

https://gcc.gnu.org/g:a02d7f0edc47495ffe456af7ab7718896e0a0c25 commit r14-9844-ga02d7f0edc47495ffe456af7ab7718896e0a0c25 Author: Thomas Schwinge Date: Thu Mar 7 14:42:07 2024 +0100 GCN, nvptx: Errors during device probing are fatal Currently, we silently disable libgomp GCN

[gcc r14-9846] GCN: '--param=gcn-preferred-vectorization-factor=[default, 32, 64]'

https://gcc.gnu.org/g:df7625c3af004a81c13d54bb8810e03932eeb59a commit r14-9846-gdf7625c3af004a81c13d54bb8810e03932eeb59a Author: Thomas Schwinge Date: Sat Feb 24 00:29:14 2024 +0100 GCN: '--param=gcn-preferred-vectorization-factor=[default,32,64]' ..., and specify '--param=gcn

[gcc r14-9845] New effective-target 'asm_goto_with_outputs'

https://gcc.gnu.org/g:3fa8bff30ab58bd8b8018764d390ec2fcc8153bb commit r14-9845-g3fa8bff30ab58bd8b8018764d390ec2fcc8153bb Author: Thomas Schwinge Date: Mon Mar 4 16:04:11 2024 +0100 New effective-target 'asm_goto_with_outputs' After commit e16f90be2dc8af6c371fe79044c3e668fa3dda62

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

[gcc r14-9806] nvptx: In mkoffload.cc, call diagnostic_color_init + gcc_init_libintl: Restore 'libgomp.c/reverse-of

https://gcc.gnu.org/g:679f81a32f706645f45900fdb1659fb5fe607f77 commit r14-9806-g679f81a32f706645f45900fdb1659fb5fe607f77 Author: Thomas Schwinge Date: Fri Apr 5 14:04:53 2024 +0200 nvptx: In mkoffload.cc, call diagnostic_color_init + gcc_init_libintl: Restore 'libgomp.c/reverse-offload

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

[gcc r14-9722] GCN: Enable effective-target 'vect_hw_misalign'

https://gcc.gnu.org/g:7cc68c48633ea92fd294193fbc1f9c4fbf4a5c6f commit r14-9722-g7cc68c48633ea92fd294193fbc1f9c4fbf4a5c6f Author: Thomas Schwinge Date: Wed Mar 20 23:52:26 2024 +0100 GCN: Enable effective-target 'vect_hw_misalign' ... as made apparent by commit

[gcc r14-9723] GCN: Enable effective-target 'vect_long_mult'

https://gcc.gnu.org/g:e162228e0baebc836c74c82521d1c7a3c46d9ab1 commit r14-9723-ge162228e0baebc836c74c82521d1c7a3c46d9ab1 Author: Thomas Schwinge Date: Wed Mar 20 23:56:58 2024 +0100 GCN: Enable effective-target 'vect_long_mult' ... as made apparent by commit

[gcc r14-9721] GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'

https://gcc.gnu.org/g:ec8e3dbdc3befa22b25da975b03d80443f5d938c commit r14-9721-gec8e3dbdc3befa22b25da975b03d80443f5d938c Author: Thomas Schwinge Date: Tue Jan 9 10:25:48 2024 +0100 GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw' Via XPASSing test cases

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

[gcc r14-9581] Hurd x86_64: add unwind support for signal trampoline code

https://gcc.gnu.org/g:b7c4ae5ace82b81dafffbc50e8026adfa3cc76e7 commit r14-9581-gb7c4ae5ace82b81dafffbc50e8026adfa3cc76e7 Author: Flavio Cruz Date: Wed Feb 28 22:59:09 2024 -0500 Hurd x86_64: add unwind support for signal trampoline code Tested with some simple toy examples where

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

Re: GSoC

Hi Abhinav! Thanks for your interest in contributing to GCC, and thanks to Martin for all the information you already provided. Just a bit more, to get you started on developing a proper project proposal: On 2024-03-13T14:54:52+0100, Martin Jambor wrote: > On Tue, Mar 12 2024, Abhinav Gupta

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

[gcc r14-9472] OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing

https://gcc.gnu.org/g:38958ac987dc3e6162e2ddaba3c7e7f41381e079 commit r14-9472-g38958ac987dc3e6162e2ddaba3c7e7f41381e079 Author: Thomas Schwinge Date: Thu Mar 14 15:01:01 2024 +0100 OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing

[gcc r14-9471] Minor fixes for OpenACC/Fortran 'self' clause for compute constructs

https://gcc.gnu.org/g:473c6123ffad38dddef7b126bf97971784d94b40 commit r14-9471-g473c6123ffad38dddef7b126bf97971784d94b40 Author: Thomas Schwinge Date: Fri Oct 20 15:49:35 2023 +0200 Minor fixes for OpenACC/Fortran 'self' clause for compute constructs ... to fix up recent commit

[gcc r14-9470] Fix 'char' initialization, copy, check in 'libgomp.oacc-fortran/acc-memcpy.f90'

https://gcc.gnu.org/g:25242ed8eb93613af6f296785da2d4ece816b7d6 commit r14-9470-g25242ed8eb93613af6f296785da2d4ece816b7d6 Author: Thomas Schwinge Date: Wed Mar 6 23:18:08 2024 +0100 Fix 'char' initialization, copy, check in 'libgomp.oacc-fortran/acc-memcpy.f90' Our dear friend

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

[gcc r14-9397] GCN: The original meaning of 'GCN_SUPPRESS_HOST_FALLBACK' isn't applicable (non-shared memory system

https://gcc.gnu.org/g:84fc8f4f3263d66503663bb784b58b49dd714dd9 commit r14-9397-g84fc8f4f3263d66503663bb784b58b49dd714dd9 Author: Thomas Schwinge Date: Thu Mar 7 15:51:54 2024 +0100 GCN: The original meaning of 'GCN_SUPPRESS_HOST_FALLBACK' isn't applicable (non-shared memory system

[gcc r14-9396] nvptx: 'cuDeviceGetCount' failure is fatal

https://gcc.gnu.org/g:37078f241a22c45db6380c5e9a79b4d08054bb3d commit r14-9396-g37078f241a22c45db6380c5e9a79b4d08054bb3d Author: Thomas Schwinge Date: Thu Mar 7 13:18:23 2024 +0100 nvptx: 'cuDeviceGetCount' failure is fatal Per commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0

[gcc r14-9395] GCN, nvptx: Fatal error for missing symbols in 'libhsa-runtime64.so.1', 'libcuda.so.1'

https://gcc.gnu.org/g:ab70addf560e18210d238edfd605fc91fcce9df1 commit r14-9395-gab70addf560e18210d238edfd605fc91fcce9df1 Author: Thomas Schwinge Date: Thu Mar 7 12:31:52 2024 +0100 GCN, nvptx: Fatal error for missing symbols in 'libhsa-runtime64.so.1', 'libcuda.so.1' If 'libhsa

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

[gcc r14-9337] amdgcn: additional gfx1030/gfx1100 support: adjust test cases

https://gcc.gnu.org/g:71aad5231447484046b45e6c8381f8096d3c287d commit r14-9337-g71aad5231447484046b45e6c8381f8096d3c287d Author: Thomas Schwinge Date: Mon Mar 4 10:40:39 2024 +0100 amdgcn: additional gfx1030/gfx1100 support: adjust test cases The "SDWA" changes

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 ==

Re: Help needed with maintainer-mode

Hi! On 2024-03-04T00:30:05+, Sam James wrote: > Mark Wielaard writes: >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote: >>> [...], I read >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration >>> which basically says "run autoreconf in every dir where there is a >>>

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: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

dbot/#/builders/132/builds/1691 > > Build state: failed compile (failure) > Revision: 6895e0bb24ddc3893f917537b319ac20ba31f369 > Worker: bb1-2 > Build Reason: (unknown) > Blamelist: Arthur Cohen , Thomas Schwinge > > > Steps: > > - 0: worker_preparation ( succes

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

Full details are available at: > https://builder.sourceware.org/buildbot/#/builders/16/builds/1917 > > Build state: failed compile (failure) > Revision: e9de5b410da43cb2ac5f9865756153648e6f078b > Worker: bb3 > Build Reason: (unknown) > Blamelist: Arthur Cohen , Thoma

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

  1   2   3   4   5   6   7   8   9   10   >