[Bug c/114819] New: 'constructor', 'destructor' function attributes vs. function signature

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114819

Bug ID: 114819
   Summary: 'constructor', 'destructor' function attributes vs.
function signature
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic, documentation
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

In context of PR114818 "'constructor', 'destructor' function attributes vs.
'extern'", I also found that there's no user documentation that the
constructor, destructor function signature has to match 'void FN(void)', and
GCC currently doesn't check/diagnose this.

Should we update 'gcc/doc/extend.texi' for this, and implement a diagnostic
(warning or even error, enabled by default)?

I found that we only document in 'gcc/target.def':

/* Output a constructor for a symbol with a given priority.  */
DEFHOOK
(constructor,
 "If defined, a function that outputs assembler code to arrange to call\n\
the function referenced by @var{symbol} at initialization time.\n\
\n\
Assume that @var{symbol} is a @code{SYMBOL_REF} for a function taking\n\
no arguments and with no return value.  [...]

Note "a function taking no arguments and with no return value".

[Bug c/114818] New: 'constructor', 'destructor' function attributes vs. 'extern'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114818

Bug ID: 114818
   Summary: 'constructor', 'destructor' function attributes vs.
'extern'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic, documentation
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

By chance, I noticed that when 'constructor', 'destructor' function attributes
appear on an 'extern' function declaration, then that is (a) accepted without
any diagnostic by the C, C++ front ends, but (b) no 'constructor', 'destructor'
calls are emitted.  (Doesn't matter whether the function does or doesn't get
linked in.)

Assuming that is the expected behavior, should we update 'gcc/doc/extend.texi'
for this, and implement a diagnostic (warning or even error, enabled by
default)?

I found that in 'gcc/doc/tm.texi', '@node Initialization' we state:

[...] Each
object file that defines an initialization function also puts a word in
the constructor section to point to that function.  [...]

Note "defines", which excludes 'extern'.

[Bug other/113317] New test case libgomp.c++/ind-base-2.C fails with ICE

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||openmp
   Last reconfirmed||2024-04-18
 CC||burnus at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #9 from Thomas Schwinge  ---
Reproduced with a native build on cfarm120.cfarm.net
(powerpc64le-unknown-linux-gnu, "POWER10 (architected), altivec supported"),
with '--enable-checking=yes,extra,rtl'.

And, 'libgomp.c/../libgomp.c-c++-common/ind-base-4.c',
'libgomp.c++/../libgomp.c-c++-common/ind-base-4.c' ICE in the same way.

[Bug libgomp/92840] [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92840

--- Comment #5 from Thomas Schwinge  ---
As determined during patch review, there's still an unresolved issue:

On 2024-04-16T17:12:17+0800, Chung-Lin Tang  wrote:
> If we continue to use k->refcount itself as the flag holder of map type, I 
> guess we will not be able to directly determine whether it is a
> structured or dynamic adjustment at that point. Probably need a new field 
> entirely.

[Bug libgomp/92840] [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92840

Thomas Schwinge  changed:

   What|Removed |Added

 CC||cltang at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
commit r14-9991-ga7578a077ed8b64b94282aa55faf7037690abbc5 "OpenACC 2.7: Adjust
acc_map_data/acc_unmap_data interaction with reference counters"

[Bug driver/114717] '-fcf-protection' vs. offloading compilation

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114717

--- Comment #5 from Thomas Schwinge  ---
Distributions injecting some '-fcf-protection' by default could also inject
'-foffload-options=amdgcn-amdhsa=-fno-cf-protection' (or similar) to keep the
default case of offloading compilation working, but then with explicit
user-specified '-fcf-protection', the user would still get an error for
offloading compilation -- which may actually be desirable (for some)?

Alternatively: yes, the 'mkoffload's could filter that out -- but there is a
policy question, whether 'mkoffload's are permitted to silently drop
user-requested '-f[...]' flags?  Probably that's OK if the '-fcf-protection'
documentation is updated accordingly?

I guess I don't have any strong preference.  ;-)

[Bug target/114718] New: GCN's '-march'es vs. default multilib

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114718

Bug ID: 114718
   Summary: GCN's '-march'es vs. default multilib
   Product: gcc
   Version: 14.0
   URL: https://github.com/gcc-mirror/gcc/commit/1bf18629c54ad
f4893c8db5227a36e1952ee69a3#commitcomment-140648051
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

When a specific multilib build for GCN's '-march'es is not available (has not
been 'configure'd/packaged), GCC resorts to the default multilib build -- which
in the case of GCN won't even link: 'ld: error: incompatible mach'.  Instead of
attempting the latter (default multilib build), should this case be diagnosed
properly, instead?

(Independent of the vague idea that multilib builds for GCN be made "more
permeable".)

Reported, for example, by Oscar Barenys in
.

[Bug target/114717] New: '-fcf-protection' vs. offloading compilation

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114717

Bug ID: 114717
   Summary: '-fcf-protection' vs. offloading compilation
   Product: gcc
   Version: 14.0
   URL: https://github.com/gcc-mirror/gcc/commit/1bf18629c54ad
f4893c8db5227a36e1952ee69a3#commitcomment-140648051
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---
Target: GCN, nvptx

If '-fcf-protection' is in effect (as, for example, enabled by default in
certain distributions), that option gets forwarded to the offloading compilers,
but for both GCN and nvptx:

lto1: error: ‘-fcf-protection=full’ is not supported for this target

Originally reported by Oscar Barenys in
.

[Bug libgomp/114690] OpenMP 'indirect' clause: dynamic image loading/unloading

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114690

--- Comment #1 from Thomas Schwinge  ---
I suggest that in the short term, we at least add a safeguard in the
'GOMP_OFFLOAD_load_image's to error out if 'GOMP_INDIRECT_ADDR_MAP' has already
been set (that should address (a), right?), and in the
'GOMP_OFFLOAD_unload_image's error out if 'GOMP_INDIRECT_ADDR_MAP' has been set
(that should address (b) -- right?).  (I'm assuming that stale mappings being
present may potentially be problematic?)

Those should be no-ops for the presumably common case that either dynamic
loading/unloading of images isn't used at all, or if it is, that no 'indirect'
clauses are actually present.

[Bug libgomp/114690] New: OpenMP 'indirect' clause: dynamic image loading/unloading

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114690

Bug ID: 114690
   Summary: OpenMP 'indirect' clause: dynamic image
loading/unloading
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
kcy at codesourcery dot com
  Target Milestone: ---

The OpenMP 'indirect' clause mapping table is not populated at image load time
(host-side), but upon the first device kernel invocation (device-side:
'build_indirect_map'), and is then immutable.

This is sufficient for a lot of cases, but breaks if additional images are
loaded after the first device kernel invocation (new mappings not added), or if
images get unloaded (stale mappings not retired).

Reference:

"[PATCH] openmp: Add support for the 'indirect' clause in C/C++", "Also, for my
understanding: [...]" ff.

[Bug other/111966] GCN '--with-arch=[...]' not considered for 'mkoffload' default 'elf_arch'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111966

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |burnus at gcc dot 
gnu.org
 CC||rguenth at gcc dot gnu.org
 Status|REOPENED|ASSIGNED

--- Comment #5 from Thomas Schwinge  ---
Tobias is working on this.

[Bug middle-end/112653] PTA should handle correctly escape information of values returned by a function

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #16 from Thomas Schwinge  ---
By means of facilitating an additional '-Wuninitialized' diagnostic, this
commit r14-5879-gf7884f7673444b8a2c10ea0981d480f2e82dd16a
"tree-optimization/112653 - PTA and return" found a bug in GCC/Rust front end
C++ constructor code: see 
"`Block.Rust::AST::ExprWithoutBlock::Rust::AST::Expr.Rust::AST::Expr::node_id’
is used uninitialized [-Werror=uninitialized]`".  :-)

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://github.com/Rust-GCC
   ||/gccrs/issues/2890
 CC||cohenarthur at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
If I understood Arthur correctly, GCC/Rust is going to effectively require
'dlopen' (and therefore '--enable-plugin'?), so that means, if the latter's not
available we have to auto-disable Rust language front end if enabled
'--enable-languages=all' vs. raise a 'configure'-time error if enabled via
explicit '--enable-languages=rust'?

Related is also  "Don't
hard-code `-ldl -lpthread` for `format_args`".

[Bug target/114302] New: [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302

Bug ID: 114302
   Summary: [14 Regression] GCN regressions after: vect: Tighten
vect_determine_precisions_from_range [PR113281]
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

If my tracking/bisecting is to be believed, commit
r14-8492-g1a8261e047f7a2c2b0afb95716f7615cba718cd1 "vect: Tighten
vect_determine_precisions_from_range [PR113281]" is causing a few
'scan-assembler' regressions for GCN, for all '-march'es; see full list below. 
(No execution test regressions, so presumably not wrong-code.)  Due to lack of
knowledge of the relevant parts, I can't tell what needs to be adjusted.

For example, for '-march=gfx90a', 'gcc.target/gcn/simd-math-5-char-16.c' we get
before vs. after:

--- before/simd-math-5-char-16-march=gfx90a.s 2024-03-04
10:49:00.532961673 +0100
+++ after/simd-math-5-char-16-march=gfx90a.s  2024-03-04
11:02:31.409941756 +0100
@@ -269,18 +269,20 @@
v_addc_co_u32   v7, s[22:23], 0, v7, s[22:23]
flat_load_ubyte v16, v[6:7] offset:0
s_waitcnt   0
+   v_mov_b32_sdwa  v16, sext(v16) src0_sel:BYTE_0
v_add_co_u32v4, s[22:23], s34, v1
v_mov_b32   v5, s35
v_addc_co_u32   v5, s[22:23], 0, v5, s[22:23]
flat_load_ubyte v17, v[4:5] offset:0
s_waitcnt   0
+   v_mov_b32_sdwa  v17, sext(v17) src0_sel:BYTE_0
s_add_u32   s40, s14, 80
s_addc_u32  s41, s15, 0
s_getpc_b64 s[42:43]
s_add_u32   s42, s42, __divv16hi3@rel32@lo+4
s_addc_u32  s43, s43, __divv16hi3@rel32@hi+4
-   v_mov_b32_sdwa  v9, sext(v17) src0_sel:BYTE_0
-   v_mov_b32_sdwa  v8, sext(v16) src0_sel:BYTE_0
+   v_mov_b32   v9, v17
+   v_mov_b32   v8, v16
s_swappc_b64s[18:19], s[42:43]
s_mov_b64   exec, 65535
v_mov_b32_sdwa  v8, v8 dst_sel:BYTE_0 dst_unused:UNUSED_PAD
src0_sel:WORD_0
@@ -291,12 +293,13 @@
s_add_u32   s38, s14, 64
s_addc_u32  s39, s15, 0
s_getpc_b64 s[44:45]
-   s_add_u32   s44, s44, __modv16qi3@rel32@lo+4
-   s_addc_u32  s45, s45, __modv16qi3@rel32@hi+4
-   v_mov_b32   v9, v17
-   v_mov_b32   v8, v16
+   s_add_u32   s44, s44, __modv16si3@rel32@lo+4
+   s_addc_u32  s45, s45, __modv16si3@rel32@hi+4
+   v_mov_b32_sdwa  v9, sext(v17) src0_sel:WORD_0
+   v_mov_b32_sdwa  v8, sext(v16) src0_sel:WORD_0
s_swappc_b64s[18:19], s[44:45]
s_mov_b64   exec, 65535
+   v_mov_b32_sdwa  v8, v8 dst_sel:BYTE_0 dst_unused:UNUSED_PAD
src0_sel:DWORD
v_add_co_u32v4, s[22:23], s38, v1
v_mov_b32   v5, s39
v_addc_co_u32   v5, s[22:23], 0, v5, s[22:23]
@@ -334,8 +337,11 @@
v_addc_co_u32   v5, s[22:23], 0, v5, s[22:23]
flat_load_ubyte v9, v[4:5] offset:0
s_waitcnt   0
+   v_mov_b32_sdwa  v9, sext(v9) src0_sel:BYTE_0
+   v_mov_b32_sdwa  v8, sext(v8) src0_sel:BYTE_0
s_swappc_b64s[18:19], s[44:45]
s_mov_b64   exec, 65535
+   v_mov_b32_sdwa  v8, v8 dst_sel:BYTE_0 dst_unused:UNUSED_PAD
src0_sel:DWORD
v_add_co_u32v4, s[22:23], s42, v1
v_mov_b32   v5, s43
v_addc_co_u32   v5, s[22:23], 0, v5, s[22:23]
@@ -557,5 +563,5 @@
 .LEFDE0:
.globl  __modsi3
.globl  __divsi3
-   .globl  __modv16qi3
+   .globl  __modv16si3
.globl  __divv16hi3

Due to no registers getting renamed, that one is the smallest of all before vs.
after 'diff's; but is illustrative of what generally happens, as far as I can
tell.

Let me know if you'd like me to provide any artifacts.

Full list:

@@ -607,28 +607,28 @@ PASS: gcc.target/gcn/simd-math-5-char-16.c (test for
excess errors)
XFAIL: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__divmod16.i4@rel32@lo 1
PASS: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__divv16hi3@rel32@lo 1
PASS: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__divv16qi3@rel32@lo 0
[-PASS:-]{+FAIL:+} gcc.target/gcn/simd-math-5-char-16.c
scan-assembler-times __modv16qi3@rel32@lo 1
PASS: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__udivv16qi3@rel32@lo 0
PASS: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times

[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2024-02-20 00:00:00 |2024-3-6
 CC||ams at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Status|ASSIGNED|NEW

--- Comment #4 from Thomas Schwinge  ---
(I've not yet started working on this, but) I've noticed that we run into the
same issue for 'libgomp.c++/firstprivate-2.C' that Jakub recently added in
commit r14-9257-g4f82d5a95a244d0aa4f8b2541b47a21bce8a191b "OpenMP/C++: Fix
(first)private clause with member variables [PR110347]":

spawn -ignore SIGHUP g++
../source-gcc/libgomp/testsuite/libgomp.c++/firstprivate-2.C [...] -fopenmp -O2
-lm -o ./firstprivate-2.exe
/tmp/ccLrOMGJ.mkoffload.2.s:215:1: error: symbol '.LEHB0' is already
defined
.LEHB0:
^
/tmp/ccLrOMGJ.mkoffload.2.s:241:1: error: symbol '.LEHE0' is already
defined
.LEHE0:
^
/tmp/ccLrOMGJ.mkoffload.2.s:341:1: error: symbol '.LEHB0' is already
defined
.LEHB0:
^
/tmp/ccLrOMGJ.mkoffload.2.s:367:1: error: symbol '.LEHE0' is already
defined
.LEHE0:
^
/tmp/ccLrOMGJ.mkoffload.2.s:467:1: error: symbol '.LEHB0' is already
defined
.LEHB0:
^
/tmp/ccLrOMGJ.mkoffload.2.s:493:1: error: symbol '.LEHE0' is already
defined
.LEHE0:
^
gcn mkoffload: fatal error: x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc
returned 1 exit status
[...]
FAIL: libgomp.c++/firstprivate-2.C (test for excess errors)

Again, that's for GCN offloading compilation only, but not nvptx.

[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-20
 Status|UNCONFIRMED |ASSIGNED
 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
Planning to look into this as part of my ongoing GPU C++ support task.

[Bug other/111966] GCN '--with-arch=[...]' not considered for 'mkoffload' default 'elf_arch'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111966

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED
   Last reconfirmed||2024-01-24
 Resolution|FIXED   |---

--- Comment #3 from Thomas Schwinge  ---
Tobias, thanks for fixing the easy part ('s%803%900' default) -- however, the
harder part still remains to be done; see this issue's initial comment.

[Bug target/113022] GCN offloading bricked by "amdgcn: Work around XNACK register allocation problem"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113022

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ams at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
Resolved via commit r14-6997-g78dff4c25c1b959e4682d7da50d00fb371849a46 "amdgcn:
Match new XNACK defaults in mkoffload".

[Bug target/112937] [14 Regression] GCN: FAILs due to unconditional 'f->use_flat_addressing = true;'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112937

--- Comment #3 from Thomas Schwinge  ---
The GCN offloading 'libgomp.fortran/target1.f90' regression has been cured by
commit r14-6996-gc5c3aab38132ea34dc1ee69d93fded787e6ac7a4 "amdgcn: Don't
double-count AVGPRs" (..., but not the GCN target regressions that I initially
reported here).

[Bug rust/113056] [14 regression] Build failure in libgrust

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Thomas Schwinge  ---
Should be fixed.  If not, please re-open providing more data.

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112997

Thomas Schwinge  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #11 from Thomas Schwinge  ---
ACK; I had the same change in my WIP tree:

In my GCN and nvptx target libstdc++ work (WIP), I see:

[...]/source-gcc/libstdc++-v3/libsupc++/eh_call.cc:39:1: error:
conflicting C language linkage declaration ‘void __cxa_call_terminate(void*)’
[-Werror]
   39 | __cxa_call_terminate(void* ue_header_in) throw ()
  | ^~~~
In file included from
[...]/source-gcc/libstdc++-v3/libsupc++/eh_call.cc:28:
[...]/source-gcc/libstdc++-v3/libsupc++/unwind-cxx.h:170:17: note:
previous declaration ‘void
__cxxabiv1::__cxa_call_terminate(_Unwind_Exception*)’
  170 | extern "C" void __cxa_call_terminate (_Unwind_Exception*) throw
()
  | ^~~~
cc1plus: all warnings being treated as errors
make[4]: *** [eh_call.lo] Error 1

[Bug libgomp/113192] [11/12/13/14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192

Thomas Schwinge  changed:

   What|Removed |Added

Summary|[14 Regression] ERROR:  |[11/12/13/14 Regression]
   |couldn't execute|ERROR: couldn't execute
   |"../../../gcc/libgomp/tests |"../../../gcc/libgomp/tests
   |uite/flock": no such file   |uite/flock": no such file
   |or directory|or directory
 Blocks||66005
Version|14.0|11.0

--- Comment #1 from Thomas Schwinge  ---
(In reply to John David Anglin from comment #0)
> HP-UX doesn't have flock but it does have perl. configure tries to create
> a fallback but a relative path to libgomp/testsuite/flock is generated.
> It is wrong when the testsuite is run.
> 
> AC_MSG_NOTICE([checking for flock implementation])
> AC_CHECK_PROGS(FLOCK, flock)
> # Fallback if 'perl' is available.
> if test -z "$FLOCK"; then
>   AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
> fi

Aha, sorry.  Does it work if you changes:

-AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
+AC_CHECK_PROG(FLOCK, perl, $ac_abs_srcdir/testsuite/flock)

..., so that this:

> configure: checking for flock implementation
> checking for flock... no
> checking for perl... ../../../gcc/libgomp/testsuite/flock

... turns into an absolute path, to resolve:

> Running /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/c.exp ...
> ERROR: tcl error sourcing
> /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/c.exp.
> ERROR: tcl error code NONE
> ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file
> or directory

... this.

If that works, and you submit a patch, please in the commit log cite this
commit:

> This problem was introduced by the following commit:
> 
> commit 04abe1944d30eb18a2060cfcd9695d085f7b4752
> Author: Thomas Schwinge 
> Date:   Mon May 15 20:00:07 2023 +0200
> 
> Support parallel testing in libgomp: fallback Perl 'flock' [PR66005]

..., and also specify 'PR testsuite/66005' in the commit log.

If that suggestion doesn't easily resolve this issue, then I'll be able to look
into it next week.


> It appears this problem can be worked around by exporting FLOCK.

But only if that specifies an absolute path (or a "suitable" relative one), I
suppose?


I've also set this "11/12/13 Regression", as these branches use the exact same
code.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
[Bug 66005] libgomp make check time is excessive

[Bug rtl-optimization/112918] [m68k] [LRA] ICE: maximum number of generated reload insns per insn achieved (90)

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113097,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113098
   Assignee|unassigned at gcc dot gnu.org  |vmakarov at gcc dot 
gnu.org

[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005

Thomas Schwinge  changed:

   What|Removed |Added

  Component|libfortran  |testsuite
   Last reconfirmed||2023-12-21
 Target|powerpc64le-linux-gnu   |
 CC||burnus at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Turns out, this isn't actually specific to powerpc64le-linux-gnu, but rather
the following: my testing where I saw the timeouts was not build-tree 'make
check' testing, but instead "installed" testing (where you invoke 'runtest' on
a 'make install'ed GCC tree).  In that case, r266482 "Tweak libgomp env vars in
parallel make check (take 2)" is not in effect, that is, there's no limiting to
'OMP_NUM_THREADS=8'.

For example, manually running the '-O0' variant of
'libgomp.fortran/rwlock_1.f90' on a "big-iron" x86_64-pc-linux-gnu system:

$ grep ^model\ name < /proc/cpuinfo | uniq -c
256 model name  : AMD EPYC 7V13 64-Core Processor
$ \time env OMP_NUM_THREADS=[...] LD_LIBRARY_PATH=[...] ./rwlock_1.exe

..., I produce the following data on an idle system:

'OMP_NUM_THREADS=8':

0.16user 0.56system 0:02.36elapsed 31%CPU (0avgtext+0avgdata
4452maxresident)k
0.17user 0.54system 0:02.30elapsed 30%CPU (0avgtext+0avgdata
4532maxresident)k

'OMP_NUM_THREADS=16':

0.40user 1.03system 0:04.52elapsed 31%CPU (0avgtext+0avgdata
5832maxresident)k
0.49user 0.99system 0:04.39elapsed 33%CPU (0avgtext+0avgdata
5876maxresident)k

'OMP_NUM_THREADS=32':

0.98user 2.36system 0:09.33elapsed 35%CPU (0avgtext+0avgdata
8528maxresident)k
0.98user 2.25system 0:09.02elapsed 35%CPU (0avgtext+0avgdata
8548maxresident)k

'OMP_NUM_THREADS=64':

1.82user 5.83system 0:18.44elapsed 41%CPU (0avgtext+0avgdata
13952maxresident)k
1.54user 6.03system 0:18.22elapsed 41%CPU (0avgtext+0avgdata
13996maxresident)k

'OMP_NUM_THREADS=128':

3.71user 12.41system 0:38.02elapsed 42%CPU (0avgtext+0avgdata
24376maxresident)k
3.96user 12.52system 0:39.34elapsed 41%CPU (0avgtext+0avgdata
24476maxresident)k

'OMP_NUM_THREADS=256' (or not set, for that matter):

9.65user 25.19system 1:20.93elapsed 43%CPU (0avgtext+0avgdata
45816maxresident)k
8.99user 25.82system 1:19.40elapsed 43%CPU (0avgtext+0avgdata
45636maxresident)k

For comparison, if I remove 'LD_LIBRARY_PATH', such that the system-wide GCC 10
libraries are used, I get for the latter case:

9.28user 24.54system 1:22.09elapsed 41%CPU (0avgtext+0avgdata
45588maxresident)k
11.26user 24.51system 1:24.32elapsed 42%CPU (0avgtext+0avgdata
45712maxresident)k

..., so only a little bit of an improvement of the new "rwlock" libgfortran vs.
old "mutex" GCC 10 one, curiously.  (But supposedly that depends on the
hardware or other factors?)

Anyway: should these test cases be limiting themselves to some lower
'OMP_NUM_THREADS', for example via 'num_threads' clauses?

The powerpc64le-linux-gnu systems:

$ grep ^cpu < /proc/cpuinfo | uniq -c

160 cpu : POWER8 (raw), altivec supported

152 cpu : POWER8NVL (raw), altivec supported

128 cpu : POWER9, altivec supported

[Bug rtl-optimization/112918] [m68k] [LRA] ICE: maximum number of generated reload insns per insn achieved (90)

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #14 from Thomas Schwinge  ---
*** Bug 112265 has been marked as a duplicate of this bug. ***

[Bug target/112265] [14 Regression] GCN offloading 'libgomp.c-c++-common/for-5.c': 'internal compiler error: maximum number of generated reload insns per insn achieved (90)'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112265

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |vmakarov at gcc dot 
gnu.org

--- Comment #4 from Thomas Schwinge  ---
Resolved via commit r14-6667-g989e67f827b74b76e58abe137ce12d948af2290c
"[PR112918][LRA]: Fixing IRA ICE on m68k".

*** This bug has been marked as a duplicate of bug 112918 ***

[Bug rust/113056] [14 regression] Build failure in libgrust

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #12 from Thomas Schwinge  ---
(In reply to Sam James from comment #0)
> checking for suffix of object files... configure: error: in
> `/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/libgrust':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details
> make[1]: *** [Makefile:16176: configure-libgrust] Error 1

Notice that this is the *host* libgrust build -- unexpectedly multilibbed. 
Please test

"libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056]".

[Bug rust/113056] [14 regression] Build failure in libgrust

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Status|WAITING |ASSIGNED
 CC||tschwinge at gcc dot gnu.org

--- Comment #11 from Thomas Schwinge  ---
Reproduced, and I think I know what's happening.

[Bug target/113022] New: GCN offloading bricked by "amdgcn: Work around XNACK register allocation problem"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113022

Bug ID: 113022
   Summary: GCN offloading bricked by "amdgcn: Work around XNACK
register allocation problem"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openacc, openmp, testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

I've not seen a problem in GCN target testing, but GCN offloading -- at least
in my testing -- is bricked (for non-'-march=gfx90a'?) by the recent commit
r14-6503-g4c12bcbeb0c0fd6da4c56e7622814201daadd585 "amdgcn: Work around XNACK
register allocation problem":

/tmp/ccwsYf5g.mkoffload.2.s:1:17: error: .amdgcn_target directive's target
id amdgcn-unknown-amdhsa--gfx900:xnack- does not match the specified target id
amdgcn-unknown-amdhsa--gfx900
.amdgcn_target "amdgcn-unknown-amdhsa--gfx900:xnack-"
   ^
/tmp/ccwsYf5g.mkoffload.2.s:29:4: error: .amdhsa_reserve_xnack_mask does
not match target id
  .amdhsa_reserve_xnack_mask0
  ^~
[...]

Reverting that commit is my workaround for the time being.

Is maybe simply something missing in GCN 'mkoffload'?

[Bug libfortran/113005] New: 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005

Bug ID: 113005
   Summary: 'libgomp.fortran/rwlock_1.f90',
'libgomp.fortran/rwlock_3.f90' execution test timeouts
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux-gnu

On several of our "big iron" powerpc64le-linux-gnu systems, I'm seeing the new
test cases 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' run
into execution test timeouts (300 s).  Those were added in commit
r14-6425-gb806c88fab3f9c6833563f9a44b608dd5dd14de9 "libgfortran: Replace mutex
with rwlock".

PASS: libgomp.fortran/rwlock_1.f90   -O0  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O0  execution test
PASS: libgomp.fortran/rwlock_1.f90   -O1  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O1  execution test
PASS: libgomp.fortran/rwlock_1.f90   -O2  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O2  execution test
PASS: libgomp.fortran/rwlock_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/rwlock_1.f90   -O3 -g  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O3 -g  execution test
PASS: libgomp.fortran/rwlock_1.f90   -Os  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -Os  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O0  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -O0  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O1  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -O1  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O2  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -O2  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
PASS: libgomp.fortran/rwlock_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O3 -g  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -O3 -g  execution test
PASS: libgomp.fortran/rwlock_2.f90   -Os  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -Os  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O0  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O0  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O1  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O1  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O2  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O2  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O3 -g  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O3 -g  execution test
PASS: libgomp.fortran/rwlock_3.f90   -Os  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -Os  execution test

All-PASS on all x86_64-pc-linux-gnu systems that I've tested.

[Bug analyzer/112955] Valgrind error in ana::feasibility_state::maybe_update_for_edge

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112955

Thomas Schwinge  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
*** Bug 112704 has been marked as a duplicate of this bug. ***

[Bug analyzer/112704] FAIL: gcc.dg/analyzer/data-model-20.c (test for warnings, line 17)

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112704

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Thomas Schwinge  ---
Should be resolved via commit
r14-6434-g6008b80b25d71827fb26ce49f49aae02b645bb12 "analyzer: fix uninitialized
bitmap [PR112955]".

*** This bug has been marked as a duplicate of bug 112955 ***

[Bug c++/112847] [14 Regression] nvptx: 'FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler _Z1gI1XEvT_', 'scan-assembler _Z1gI1YEvT_'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112847

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
This one (but not PR112846 "nvptx: 'FAIL: g++.dg/abi/anon6.C -std=c++20
scan-assembler
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv'",
which I'd filed at the same time) has been fixed by commit
r14-6432-g074c6f15f7a28c620c756f18c2a310961de00539 "testsuite: update
mangling", I presume.  (The new 'g++.dg/cpp2a/concepts-explicit-inst1a.C' also
is all-PASS.)

[Bug target/112937] [14 Regression] GCN: FAILs due to unconditional 'f->use_flat_addressing = true;'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112937

--- Comment #1 from Thomas Schwinge  ---
The unconditional GCN 'f->use_flat_addressing = true;' also has an effect on
one (only!) libgomp offloading test case, for
'-foffload-options=amdgcn-amdhsa=-march=gfx90a' (only!):

@@ -6188,11 +6188,11 @@ PASS: libgomp.fortran/target1.f90   -O1  execution
test
PASS: libgomp.fortran/target1.f90   -O2  (test for excess errors)
PASS: libgomp.fortran/target1.f90   -O2  execution test
PASS: libgomp.fortran/target1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/target1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/target1.f90   -O3 -g  (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/target1.f90   -O3 -g  execution test
PASS: libgomp.fortran/target1.f90   -Os  (test for excess errors)
PASS: libgomp.fortran/target1.f90   -Os  execution test

libgomp: GCN fatal error: Asynchronous queue error
Runtime message: HSA_STATUS_ERROR_INVALID_ISA: The instruction set
architecture is invalid.
[hangs]

Huh!?  That looks very odd (to me, at least).

Manually trying with simply '-O3', that appears to be 100 % reproducible on our
gfx90a systems -- but nowhere else.  ..., and disappears with the unconditional
GCN 'f->use_flat_addressing = true;' reverted.  (..., which of course would
regress other new test cases.)

[Bug libgomp/112264] Occasionally (but very rare): 'FAIL: libgomp.fortran/target-nowait-array-section.f90 -O execution test'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112264

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-09
 Ever confirmed|0   |1

[Bug target/112937] New: [14 Regression] GCN: FAILs due to unconditional 'f->use_flat_addressing = true;'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112937

Bug ID: 112937
   Summary: [14 Regression] GCN: FAILs due to unconditional
'f->use_flat_addressing = true;'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

The unconditional GCN 'f->use_flat_addressing = true;' applied as part of
commit r14-6226-ge7d6c277fa28c0b9b621d23c471e0388d2912644 "amdgcn, libgomp:
low-latency allocator" is causing a few regressions for GCN target (not
offloading) testing (tested '-march=gfx906', '-march=gfx90a'):

C:

[-PASS:-]{+FAIL:+} gcc.dg/pr64935-1.c (test for excess errors)

xgcc: error: [...]/gcc.dg/pr64935-1.c: '-fcompare-debug' failure (length)

Fortran:

PASS: gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single  -O2  (test for
excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single 
-O2  execution test

PASS: gfortran.dg/team_change_1.f90   -O0  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/team_change_1.f90   -O0  execution test
[Etc.]

PASS: gfortran.dg/team_end_1.f90   -O0  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/team_end_1.f90   -O0  execution test
[Etc.]

PASS: gfortran.dg/team_form_1.f90   -O0  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/team_form_1.f90   -O0  execution test
[Etc.]

PASS: gfortran.dg/team_number_1.f90   -O0  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/team_number_1.f90   -O0  execution test
[Etc.]

These execution test FAILs are generally of the form:

Memory access fault by GPU node-2 (Agent handle: 0x20a1d40) on address
0x7f56. Reason: Page not present or supervisor privilege.

Additionally, I'm seeing the following in my libstdc++ enablement tree:

PASS: std/ranges/iota/max_size_type.cc  -std=gnu++20 (test for excess
errors)
{+WARNING: std/ranges/iota/max_size_type.cc  -std=gnu++20 execution test
program timed out.+}
[-PASS:-]{+FAIL:+} std/ranges/iota/max_size_type.cc  -std=gnu++20 execution
test
PASS: std/ranges/iota/max_size_type.cc  -std=gnu++26 (test for excess
errors)
{+WARNING: std/ranges/iota/max_size_type.cc  -std=gnu++26 execution test
program timed out.+}
[-PASS:-]{+FAIL:+} std/ranges/iota/max_size_type.cc  -std=gnu++26 execution
test

(I guess I could provide pre-processed files for those if you'd like to
reproduce.)

To restore the Fortran test cases, just reverting the GCN back end change is
not sufficient: also need to rebuild GCN target libraries.  (That is, the GCN
back end change does affect code generated for GCN target libraries.)

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289

Thomas Schwinge  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Thomas Schwinge  ---
(In reply to myself from comment #2)
> Similarly seen for GCN target, and this is now fatal

Actually, sorry, that's not accurate; the "warning: conflicting types" didn't
turn fatal.

Anyway: 'libgcc/emutls.c' should now be clean to build; please re-open if not.

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

--- Comment #5 from Thomas Schwinge  ---
(I did see that the '__cxa_thread_atexit_impl' issue has been resolved
differently, but there is a genuine GCC/nvptx issue here.)

(In reply to myself from comment #1)
> Indeed in 'build-gcc/nvptx-none/libstdc++-v3/libsupc++/atexit_thread.o' I
> see:
> 
> // BEGIN GLOBAL FUNCTION DECL: __cxa_thread_atexit_impl
> .extern .func (.param .u32 %value_out) __cxa_thread_atexit_impl (.param
> .u64 %in_ar0, .param .u64 %in_ar1, .param .u64 %in_ar2);
> 
> That is, '.extern' instead of '.weak' linking directive, huh.

That one indeed is a GCC/nvptx back end issue.  A fix might look similar to the
following:

--- gcc/config/nvptx/nvptx.cc
+++ gcc/config/nvptx/nvptx.cc
@@ -1001,10 +1001,11 @@ write_fn_proto_1 (std::stringstream , bool
is_defn,
  const char *name, const_tree decl, bool force_public)
 {
-  if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)) == NULL)
+  if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)) == NULL
+  && !DECL_WEAK (decl))
 write_fn_marker (s, is_defn, TREE_PUBLIC (decl) || force_public,
name);

   /* PTX declaration.  */
   if (DECL_EXTERNAL (decl))
-s << ".extern ";
+s << (DECL_WEAK (decl) ? ".weak " : ".extern ");
   else if (TREE_PUBLIC (decl) || force_public)
 s << (DECL_WEAK (decl) ? ".weak " : ".visible ");

> ..., but still doing the NULL check: [...]

..., and that check ('if (__cxa_thread_atexit_impl)') then fails to assemble,
and thus the build (!) fails:

ptxas fatal   : Cannot take address of function '__cxa_thread_atexit_impl' 

Thus, more smarts are needed to make "weak, undefined" work.  (May be able to
fix this up in the linker, assuming seeing the whole program; similar to
PR105018 "[nvptx] Need better alias support" ideas?)  (For reference, "weak,
defined" does not run into this problem.)

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289

Thomas Schwinge  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #8 from Thomas Schwinge  ---
(In reply to myself from comment #2)
> [...]/source-gcc/libgcc/emutls.c: In function ‘__emutls_get_address’:
> [...]/source-gcc/libgcc/emutls.c:172:13: error: implicit declaration of
> function ‘calloc’ [-Wimplicit-function-declaration]
>   172 |   arr = calloc (size + 1, sizeof (void *));
>   | ^~
> [...]/source-gcc/libgcc/emutls.c:32:1: note: include ‘’ or
> provide a declaration of ‘calloc’
>31 | #include "gthr.h"
>   +++ |+#include 
>32 |
> [...]/source-gcc/libgcc/emutls.c:172:13: warning: incompatible implicit
> declaration of built-in function ‘calloc’ [-Wbuiltin-declaration-mismatch]
>   172 |   arr = calloc (size + 1, sizeof (void *));
>   | ^~
> [...]/source-gcc/libgcc/emutls.c:172:13: note: include ‘’ or
> provide a declaration of ‘calloc’
> [...]/source-gcc/libgcc/emutls.c:184:13: error: implicit declaration of
> function ‘realloc’ [-Wimplicit-function-declaration]
>   184 |   arr = realloc (arr, (size + 1) * sizeof (void *));
>   | ^~~
> [...]/source-gcc/libgcc/emutls.c:184:13: note: include ‘’ or
> provide a declaration of ‘realloc’
> [...]/source-gcc/libgcc/emutls.c:184:13: warning: incompatible implicit
> declaration of built-in function ‘realloc’ [-Wbuiltin-declaration-mismatch]
> [...]/source-gcc/libgcc/emutls.c:184:13: note: include ‘’ or
> provide a declaration of ‘realloc’

> GCC's suggestion to "include ‘’" needs to be carefully reviewed,
> in case this is meant to be buildable in an environment without C library
> headers?

(In reply to Florian Weimer from comment #3)
> Thomas, the safe thing to do would be to use __builtin_calloc and
> __builtin_realloc in those spots because it avoids a dependency on an
> external header that might not exist at this point.

That part got resolved differently, in commit
r14-6207-g6e84dafcc72d1cd6d028b42f1801e092a91d3214 "tsystem.h: Declare
calloc/realloc #ifdef inhibit_libc".

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289

--- Comment #7 from Thomas Schwinge  ---
Created attachment 56805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56805=edit
'0001-WIP-GCC-PR109289-Conflicting-types-for-built-in-func.patch'

Attaching my current WIP patch.  I may later bring this to completion
(properly), unless anyone gets there first.

[Bug target/112858] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

--- Comment #2 from Thomas Schwinge  ---
Earlier in 'libstdc++-v3/libsupc++/atexit_thread.cc', we have:

[...]
#if _GLIBCXX_HAVE___CXA_THREAD_ATEXIT

// Libc provides __cxa_thread_atexit definition.

#elif _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL

extern "C" int __cxa_thread_atexit_impl (void (_GLIBCXX_CDTOR_CALLABI
*func) (void *),
 void *arg, void *d);
extern "C" int
__cxxabiv1::__cxa_thread_atexit (void (_GLIBCXX_CDTOR_CALLABI *dtor)(void
*),
 void *obj, void *dso_handle)
  _GLIBCXX_NOTHROW
{
  return __cxa_thread_atexit_impl (dtor, obj, dso_handle);
}

#else /* _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL */
[...]

..., that is, indeed a non-weak '__cxa_thread_atexit_impl' declaration --
however, that's active only if not '_GLIBCXX_HAVE___CXA_THREAD_ATEXIT' and not
'_GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL', but we have per
'include/nvptx-none/bits/c++config.h':

/* Define to 1 if you have the `__cxa_thread_atexit' function. */
/* #undef _GLIBCXX_HAVE___CXA_THREAD_ATEXIT */

/* Define to 1 if you have the `__cxa_thread_atexit_impl' function. */
/* #undef _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL */

[Bug target/112858] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

--- Comment #1 from Thomas Schwinge  ---
Indeed in 'build-gcc/nvptx-none/libstdc++-v3/libsupc++/atexit_thread.o' I see:

// BEGIN GLOBAL FUNCTION DECL: __cxa_thread_atexit_impl
.extern .func (.param .u32 %value_out) __cxa_thread_atexit_impl (.param
.u64 %in_ar0, .param .u64 %in_ar1, .param .u64 %in_ar2);

That is, '.extern' instead of '.weak' linking directive, huh.

..., but still doing the NULL check:

[...]
.reg .u64 %r29;
.reg .pred %r30;
[...]
mov.u64 %r29,__cxa_thread_atexit_impl;
setp.eq.u64 %r30,%r29,0;
@ %r30 bra $L9;
.loc 2 156 37
{
.param .u32 %value_in;
.param .u64 %out_arg1;
st.param.u64 [%out_arg1],%r26;
.param .u64 %out_arg2;
st.param.u64 [%out_arg2],%r27;
.param .u64 %out_arg3;
st.param.u64 [%out_arg3],%r28;
call (%value_in),__cxa_thread_atexit_impl,(%out_arg1,%out_arg2,%out_arg3);
ld.param.u32 %r34,[%value_in];
}
mov.u32 %r25,%r34;
.loc 2 156 59
bra $L8;
$L9:
[...]

[Bug target/112858] New: nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

Bug ID: 112858
   Summary: nvptx: 'unresolved symbol __cxa_thread_atexit_impl'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---

With commit r14-6082-gf4dd9416843308d4ae519983415fe62212662536 "libsupc++: try
cxa_thread_atexit_impl at runtime", there's one regression in nvptx target
testing (only visible on top of my WIP C++ enablement changes):

[-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++14 (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++14 [-execution
test-]{+compilation failed to produce executable+}
[-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++17 (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++17 [-execution
test-]{+compilation failed to produce executable+}
[-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++20 (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++20 [-execution
test-]{+compilation failed to produce executable+}
UNSUPPORTED: g++.dg/tls/thread_local6.C  -std=c++98

unresolved symbol __cxa_thread_atexit_impl
collect2: error: ld returned 1 exit status

Very likely, this isn't an issue with that commit, but rather due to GCC/nvptx'
deficient implementation of weak symbols.

[Bug c++/112847] [14 Regression] nvptx: 'FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler _Z1gI1XEvT_', 'scan-assembler _Z1gI1YEvT_'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112847

Thomas Schwinge  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
Same as for PR112846, the issue disappears if I revert commit
r14-6064-gc3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 "c++: mangle function
template constraints".  I don't know yet (a) what that means, and (b) why nvptx
target behaves differently from everything else.

[Bug c++/112846] [14 Regression] nvptx: 'FAIL: g++.dg/abi/anon6.C -std=c++20 scan-assembler _Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec00000000000EEEEEEvv'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112846

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=112847
 CC||jason at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
Same as for PR112847, the issue disappears if I revert commit
r14-6064-gc3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 "c++: mangle function
template constraints".  I don't know yet (a) what that means, and (b) why nvptx
target behaves differently from everything else.

[Bug c++/112847] New: [14 Regression] nvptx: 'FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler _Z1gI1XEvT_', 'scan-assembler _Z1gI1YEvT_'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112847

Bug ID: 112847
   Summary: [14 Regression] nvptx: 'FAIL:
g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20
scan-assembler _Z1gI1XEvT_', 'scan-assembler
_Z1gI1YEvT_'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

For nvptx target, something in Git
r14-5829-g449b6b817ed76173e6475debd02b195ea9dab0a0..r14-6074-gb74981b5cf32ebf4bfffd25e7174b5c80243447a
regresses:

UNSUPPORTED: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++98
UNSUPPORTED: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++14
UNSUPPORTED: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++17
PASS: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20 (test for excess
errors)
[-PASS:-]{+FAIL:+} g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20 
scan-assembler _Z1gI1XEvT_
[-PASS:-]{+FAIL:+} g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20 
scan-assembler _Z1gI1YEvT_
PASS: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20  scan-assembler
_Z1gIiEvT_

--- concepts-explicit-inst1.s   2023-12-04 12:44:38.047527549 +0100
+++ concepts-explicit-inst1.s   2023-12-04 12:44:20.675703887 +0100
@@ -26,2 +26,2 @@
-// BEGIN GLOBAL FUNCTION DECL: _Z1gI1XEvT_
-.weak .func _Z1gI1XEvT_ (.param.u64 %in_ar0);
+// BEGIN GLOBAL FUNCTION DECL: _Z1gITk1D1XEvT_
+.weak .func _Z1gITk1D1XEvT_ (.param.u64 %in_ar0);
@@ -29,2 +29,2 @@
-// BEGIN GLOBAL FUNCTION DEF: _Z1gI1XEvT_
-.weak .func _Z1gI1XEvT_ (.param.u64 %in_ar0)
+// BEGIN GLOBAL FUNCTION DEF: _Z1gITk1D1XEvT_
+.weak .func _Z1gITk1D1XEvT_ (.param.u64 %in_ar0)
@@ -46,2 +46,2 @@
-// BEGIN GLOBAL FUNCTION DECL: _Z1gI1YEvT_
-.weak .func _Z1gI1YEvT_ (.param.u64 %in_ar0);
+// BEGIN GLOBAL FUNCTION DECL: _Z1gITk1C1YEvT_
+.weak .func _Z1gITk1C1YEvT_ (.param.u64 %in_ar0);
@@ -49,2 +49,2 @@
-// BEGIN GLOBAL FUNCTION DEF: _Z1gI1YEvT_
-.weak .func _Z1gI1YEvT_ (.param.u64 %in_ar0)
+// BEGIN GLOBAL FUNCTION DEF: _Z1gITk1C1YEvT_
+.weak .func _Z1gITk1C1YEvT_ (.param.u64 %in_ar0)

[Bug c++/112846] New: [14 Regression] nvptx: 'FAIL: g++.dg/abi/anon6.C -std=c++20 scan-assembler _Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec00000000000EEEEEEvv'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112846

Bug ID: 112846
   Summary: [14 Regression] nvptx: 'FAIL: g++.dg/abi/anon6.C
-std=c++20  scan-assembler
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut
_Edi9RightNameLd405ec000EEvv'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

For nvptx target, something in Git
r14-5829-g449b6b817ed76173e6475debd02b195ea9dab0a0..r14-6074-gb74981b5cf32ebf4bfffd25e7174b5c80243447a
regresses:

UNSUPPORTED: g++.dg/abi/anon6.C  -std=c++98
UNSUPPORTED: g++.dg/abi/anon6.C  -std=c++14
UNSUPPORTED: g++.dg/abi/anon6.C  -std=c++17
PASS: g++.dg/abi/anon6.C  -std=c++20 (test for excess errors)
[-PASS:-]{+FAIL:+} g++.dg/abi/anon6.C  -std=c++20  scan-assembler
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv

--- anon6.s 2023-12-04 12:22:40.631978250 +0100
+++ anon6.s 2023-12-04 12:22:21.592135699 +0100
@@ -8,2 +8,2 @@
-// BEGIN GLOBAL FUNCTION DECL:
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
-.weak .func
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv;
+// BEGIN GLOBAL FUNCTION DECL:
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
+.weak .func
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv;
@@ -11,2 +11,2 @@
-// BEGIN GLOBAL FUNCTION DEF:
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
-.weak .func
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
+// BEGIN GLOBAL FUNCTION DEF:
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
+.weak .func
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
@@ -26 +26 @@
-   call
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv;
+   call
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv;

[Bug modula2/112825] Modula 2 builds target objects as part of all-gcc

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112825

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
I too, months ago, had run into this problem -- via the nvptx 'as' failing on
'-o /dev/null'... (which I'll fix anyway).  After a quick look at
'gcc/m2/tools-src/makeSystem' I did presume that the compiler is invoked there
only for some side effects (remember, '-o /dev/null'), and thus fixing this
might be...

(In reply to Gaius Mulley from comment #3)
> Created attachment 56782 [details]
> Proposed fix
> 
> This patch changes all invocations of gm2 -c to gm2 -S to avoid invoking the
> target assembler (which might not be present if make all-gcc is run).

... as simple as this.  (Then, of course, interrupted by higher-priority
things, and I never got back to this.)

Therefore, for what it's worth, conceptual ACK to this proposed change (which
I've not yet tested, but will, eventually).

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2023-12-01 00:00:00 |2023-12-3
 CC||tschwinge at gcc dot gnu.org
   Keywords||build

--- Comment #3 from Thomas Schwinge  ---
I'm actually running into this ICE already during powerpc64le-linux-gnu build:

libtool: compile:  [...]/build-gcc/./gcc/xgcc [...] -fchecking=1 [...]
-mabi=ibmlongdouble -mno-gnu-attribute -fcx-fortran-rules -ffunction-sections
-fdata-sections -mabi=ieeelongdouble -g -O2 -MT norm2_r17.lo -MD -MP -MF
.deps/norm2_r17.Tpo -c [...]/source-gcc/libgfortran/generated/norm2_r17.c 
-fPIC -DPIC -o .libs/norm2_r17.o
cc1: warning: Using IEEE extended precision ‘long double’ [-Wpsabi]
during GIMPLE pass: evrp
[...]/source-gcc/libgfortran/generated/norm2_r17.c: In function
‘norm2_r17’:
[...]/source-gcc/libgfortran/generated/norm2_r17.c:214:1: internal compiler
error: in fold_range, at range-op.cc:206
  214 | }
  | ^
0x10bf213b range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
[...]/source-gcc/gcc/range-op.cc:206
0x11d8790b fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
[...]/source-gcc/gcc/gimple-range-fold.cc:702
0x11d89873 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
[...]/source-gcc/gcc/gimple-range-fold.cc:602
0x11d89eaf fold_range(vrange&, gimple*, range_query*)
[...]/source-gcc/gcc/gimple-range-fold.cc:322
0x11d7c6e3 ranger_cache::get_global_range(vrange&, tree_node*, bool&)
[...]/source-gcc/gcc/gimple-range-cache.cc:1052
0x11d69577 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
[...]/source-gcc/gcc/gimple-range.cc:311
0x11221b93 range_query::value_of_stmt(gimple*, tree_node*)
[...]/source-gcc/gcc/value-query.cc:113
0x111c6ae7 rvrp_folder::value_of_stmt(gimple*, tree_node*)
[...]/source-gcc/gcc/tree-vrp.cc:999
0x11044fbb
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
[...]/source-gcc/gcc/tree-ssa-propagate.cc:820
0x11ce966b dom_walker::walk(basic_block_def*)
[...]/source-gcc/gcc/domwalk.cc:311
0x110436f3
substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
[...]/source-gcc/gcc/tree-ssa-propagate.cc:999
0x111c1877 execute_ranger_vrp(function*, bool, bool)
[...]/source-gcc/gcc/tree-vrp.cc:1064
0x111c6a6b execute
[...]/source-gcc/gcc/tree-vrp.cc:1307
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [norm2_r17.lo] Error 1

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-01
 CC||ams at gcc dot gnu.org,
   ||fw at gcc dot gnu.org,
   ||jules at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Thomas Schwinge  ---
Similarly seen for GCN target, and this is now fatal after Florian's recent
changes (I presume -- and I fully do support those, for avoidance of doubt):

[...]/source-gcc/libgcc/emutls.c:61:7: warning: conflicting types for
built-in function ‘__emutls_get_address’; expected ‘void *(void *)’
[-Wbuiltin-declaration-mismatch]
   61 | void *__emutls_get_address (struct __emutls_object *);
  |   ^~~~
[...]/source-gcc/libgcc/emutls.c:63:6: warning: conflicting types for
built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned
int,  unsigned int,  void *)’ [-Wbuiltin-declaration-mismatch]
   63 | void __emutls_register_common (struct __emutls_object *, word,
word, void *);
  |  ^~~~
[...]/source-gcc/libgcc/emutls.c:140:1: warning: conflicting types for
built-in function ‘__emutls_get_address’; expected ‘void *(void *)’
[-Wbuiltin-declaration-mismatch]
  140 | __emutls_get_address (struct __emutls_object *obj)
  | ^~~~
[...]/source-gcc/libgcc/emutls.c: In function ‘__emutls_get_address’:
[...]/source-gcc/libgcc/emutls.c:172:13: error: implicit declaration of
function ‘calloc’ [-Wimplicit-function-declaration]
  172 |   arr = calloc (size + 1, sizeof (void *));
  | ^~
[...]/source-gcc/libgcc/emutls.c:32:1: note: include ‘’ or
provide a declaration of ‘calloc’
   31 | #include "gthr.h"
  +++ |+#include 
   32 |
[...]/source-gcc/libgcc/emutls.c:172:13: warning: incompatible implicit
declaration of built-in function ‘calloc’ [-Wbuiltin-declaration-mismatch]
  172 |   arr = calloc (size + 1, sizeof (void *));
  | ^~
[...]/source-gcc/libgcc/emutls.c:172:13: note: include ‘’ or
provide a declaration of ‘calloc’
[...]/source-gcc/libgcc/emutls.c:184:13: error: implicit declaration of
function ‘realloc’ [-Wimplicit-function-declaration]
  184 |   arr = realloc (arr, (size + 1) * sizeof (void *));
  | ^~~
[...]/source-gcc/libgcc/emutls.c:184:13: note: include ‘’ or
provide a declaration of ‘realloc’
[...]/source-gcc/libgcc/emutls.c:184:13: warning: incompatible implicit
declaration of built-in function ‘realloc’ [-Wbuiltin-declaration-mismatch]
[...]/source-gcc/libgcc/emutls.c:184:13: note: include ‘’ or
provide a declaration of ‘realloc’
[...]/source-gcc/libgcc/emutls.c: At top level:
[...]/source-gcc/libgcc/emutls.c:204:1: warning: conflicting types for
built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned
int,  unsigned int,  void *)’ [-Wbuiltin-declaration-mismatch]
  204 | __emutls_register_common (struct __emutls_object *obj,
  | ^~~~
make[2]: *** [[...]/source-gcc/libgcc/static-object.mk:17: emutls.o] Error
1

GCC's suggestion to "include ‘’" needs to be carefully reviewed, in
case this is meant to be buildable in an environment without C library headers?

[Bug target/112669] GCN: wrong 'LIBRARY_PATH' in presence of several different '-march=[...]' flags

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Thomas Schwinge  ---
Fixed in master branch; not currently planning on backporting.

[Bug target/112725] New: [14 Regression] powerpc64le-linux-gnu: 'c-c++-common/builtin-classify-type-1.c:113:3: error: AltiVec argument passed to unprototyped function'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112725

Bug ID: 112725
   Summary: [14 Regression] powerpc64le-linux-gnu:
'c-c++-common/builtin-classify-type-1.c:113:3: error:
AltiVec argument passed to unprototyped function'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Test run for powerpc64le-linux-gnu, very likely commit
r14-5615-g509b470dcee9795887a60ddb32ab454f22e74411 "c, c++: Add new value for
vector types for __builtin_classify_type":

[-PASS:-]{+FAIL:+} c-c++-common/builtin-classify-type-1.c  -Wc++-compat 
(test for excess errors)
[-PASS:-]{+UNRESOLVED:+} c-c++-common/builtin-classify-type-1.c 
-Wc++-compat  [-execution test-]{+compilation failed to produce executable+}

[...]/c-c++-common/builtin-classify-type-1.c: In function 'main':
[...]/c-c++-common/builtin-classify-type-1.c:113:3: error: AltiVec argument
passed to unprototyped function
[...]/c-c++-common/builtin-classify-type-1.c:115:3: error: AltiVec argument
passed to unprototyped function

[Bug analyzer/112704] FAIL: gcc.dg/analyzer/data-model-20.c (test for warnings, line 17)

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112704

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||tschwinge at gcc dot gnu.org
   Last reconfirmed||2023-11-27
 Status|UNCONFIRMED |NEW

--- Comment #1 from Thomas Schwinge  ---
(In reply to John David Anglin from comment #0)
> FAIL: gcc.dg/analyzer/data-model-20.c  (test for warnings, line 17)

I also see this is my configurations (targets amdgcn-amdhsa, nvptx-none,
powerpc64le-linux-gnu, x86_64-pc-linux-gnu) -- however, not always (that is,
some test runs PASS), and not consistently between what I would consider
comparable test runs...

[Bug c++/112724] C++ "'excess_precision_expr' not supported by dump_expr"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112724

--- Comment #1 from Thomas Schwinge  ---
I found that PR108698 "decltype ((T() + ‘excess_precision_expr’ not supported
by dump_expr)) median(ndarray) [with T = double]’: since 
r13-3290-g98e341130f87984a" discussed a similar issue, but I don't know if it's
actually related.

[Bug c++/112724] New: C++ "'excess_precision_expr' not supported by dump_expr"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112724

Bug ID: 112724
   Summary: C++ "'excess_precision_expr' not supported by
dump_expr"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic, testsuite-fail
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

(Only) in '-m32' testing of x86_64-pc-linux-gnu, I see (only) for C++ testing
of the test case added in commit
r14-5827-g1802f64e674eeef0c0d7e8f6ca2846145ec16315 "OpenMP: Accept argument to
depobj's destroy clause":

+PASS: c-c++-common/gomp/depobj-3.c  -std=c++98  at line 17 (test for
warnings, line 15)
+FAIL: c-c++-common/gomp/depobj-3.c  -std=c++98  at line 39 (test for
warnings, line 37)
+PASS: c-c++-common/gomp/depobj-3.c  -std=c++98  at line 43 (test for
errors, line 41)
+PASS: c-c++-common/gomp/depobj-3.c  -std=c++98  (test for warnings, line
45)
+FAIL: c-c++-common/gomp/depobj-3.c  -std=c++98 (test for excess errors)

[...]/c-c++-common/gomp/depobj-3.c: In function 'int main()':
[...]/c-c++-common/gomp/depobj-3.c:37:38: warning: the 'destroy' expression
''excess_precision_expr' not supported by dump_expr' should
be the same as the 'depobj' argument 'obj' [-Wopenmp]

This should be:

[...]/c-c++-common/gomp/depobj-3.c:37:38: warning: the 'destroy' expression
'(a + (float)5)' should be the same as the 'depobj' argument 'obj' [-Wopenmp]

[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
 Status|NEW |RESOLVED

--- Comment #8 from Thomas Schwinge  ---
PASSes as of commit r14-5476-gf5d94999ee6a7bd247c3d74959ebdd46334d7804
"testsuite: tsan: add fallback overload for pthread_cond_clockwait".

[Bug target/112669] GCN: wrong 'LIBRARY_PATH' in presence of several different '-march=[...]' flags

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-22
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

[Bug target/112669] GCN: wrong 'LIBRARY_PATH' in presence of several different '-march=[...]' flags

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669

--- Comment #1 from Thomas Schwinge  ---
Tracing through 'gcc/gcc.cc': 'build_search_list' -> 'for_each_path', I find:

For '-march=gfx908', we have:

(gdb) print multilib_dir
$3 = 0x82e6c0 "gfx908"
(gdb) print multilib_os_dir
$4 = 0x82e6c0 "gfx908"

For '-march=gfx906 -march=gfx908', we have:

(gdb) print multilib_dir
$3 = 0x0
(gdb) print multilib_os_dir
$4 = 0x0

These are:

/* Subdirectory to use for locating libraries.  Set by
   set_multilib_dir based on the compilation options.  */

static const char *multilib_dir;

/* Subdirectory to use for locating libraries in OS conventions.  Set by
   set_multilib_dir based on the compilation options.  */

static const char *multilib_os_dir;

Indeed, simpler:

$ build-gcc-offload-amdgcn-amdhsa/gcc/xgcc -print-multi-directory
-march=gfx908
gfx908
$ build-gcc-offload-amdgcn-amdhsa/gcc/xgcc -print-multi-directory
-march=gfx906 -march=gfx908
.

Instead of '.' (default), the latter should also print 'gfx908'.

I'll look into 'set_multilib_dir' etc.

[Bug target/112669] New: GCN: wrong 'LIBRARY_PATH' in presence of several different '-march=[...]' flags

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669

Bug ID: 112669
   Summary: GCN: wrong 'LIBRARY_PATH' in presence of several
different '-march=[...]' flags
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

I've run into a weird issue when several different '-march=[...]' flags appear.
 This causes linking to fail: the linker tries to link in the wrong multilib's
libraries.  This happens, for example, if the user provides '-march=[...]' for
libgomp offloading testing, but a test cases also specifies a specific
'-march=[...]'.

The problem might perhaps be in GCN multilib setup, however it doesn't seem
related to the recent changes ("amdgcn: deprecate Fiji device and multilib"),
as I'm also reproducing the issue with previous GCC release branches.

The issue -- I suppose -- boils down to:

No '-march=[...]' flag appears, default paths:

$ build-gcc-offload-amdgcn-amdhsa/gcc/xgcc -print-search-dirs | sed -n -e
"/^libraries: =/{s%[^=]\+=%%;s%$PWD%[...]%g;s%:%\n%g;p}" > default
$ cat < default 
   
[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/
[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/
   
[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/../../../../../../amdgcn-amdhsa/lib/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/
   
[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/../../../../../../amdgcn-amdhsa/lib/
   
[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../amdgcn-amdhsa/lib/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/
[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../amdgcn-amdhsa/lib/

If one '-march=[...]' flag appears, we get those multilib paths prepended:

$ build-gcc-offload-amdgcn-amdhsa/gcc/xgcc -print-search-dirs -march=gfx906
| sed -n -e "/^libraries: =/{s%[^=]\+=%%;s%$PWD%[...]%g;s%:%\n%g;p}" > gfx906
$ diff -U1 default gfx906
--- default 2023-11-22 11:47:14.021018613 +0100
+++ gfx906  2023-11-22 11:47:21.856931965 +0100
@@ -1 +1,7 @@
   
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/gfx906/
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/gfx906/
   
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/../../../../../../amdgcn-amdhsa/lib/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/gfx906/
   
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/../../../../../../amdgcn-amdhsa/lib/gfx906/
   
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../amdgcn-amdhsa/lib/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/gfx906/
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../amdgcn-amdhsa/lib/gfx906/

[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/

Similarly, if the same '-march=[...]' flag appears twice, we get those multilib
paths prepended:

$ build-gcc-offload-amdgcn-amdhsa/gcc/xgcc -print-search-dirs -march=gfx908
-march=gfx908 | sed -n -e "/^libraries:
=/{s%[^=]\+=%%;s%$PWD%[...]%g;s%:%\n%g;p}" > gfx908
$ diff -U1 default gfx908
--- default 2023-11-22 11:47:14.021018613 +0100
+++ gfx908  2023-11-22 11:47:34.760789347 +0100
@@ -1 +1,7 @@
   
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/gfx908/
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/gfx908/
   
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/../../../../../../amdgcn-amdhsa/lib/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/gfx908/
   
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/../../../../../../amdgcn-amdhsa/lib/gfx908/
   
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../amdgcn-amdhsa/lib/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/gfx908/
+[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../amdgcn-amdhsa/lib/gfx908/

[...]/build-gcc-offload-amdgcn-amdhsa/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/accel/amdgcn-amdhsa/

However, if several different '-march=[...]' flags appear, we're back to the
default:

$ build-gcc-offload-amdgcn-amdhsa/gcc/xgcc -print-search-dirs -march=gfx906
-march=gfx908 | sed -n -e "/^libraries:
=/{s%[^=]\+=%%;s%$PWD%[...]%g;s%:%\n%g;p}" > gfx906,gfx908
$ cmp default gfx906,gfx908 && echo 'no difference'
no difference
$ build-gcc-offload-amdgcn-amdhsa/gcc/xgcc -print-search-dirs -march=gfx908
-march=gfx906 | sed -n -e 

[Bug rtl-optimization/112606] New: [14 Regression] powerpc64le-linux-gnu: 'FAIL: gcc.target/powerpc/p8vector-fp.c scan-assembler xsnabsdp'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606

Bug ID: 112606
   Summary: [14 Regression] powerpc64le-linux-gnu: 'FAIL:
gcc.target/powerpc/p8vector-fp.c scan-assembler
xsnabsdp'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: pinskia at gcc dot gnu.org, xry111 at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux-gnu

If my tracking is to be believed, the recent commit
r14-5542-g9e9279fadbd1c673c875b9d20261d2de0473f63f "Only allow (copysign x,
NEG_CONST) -> (fneg (fabs x)) simplification for constant folding [PR112483]"
causes a regression for powerpc64le-linux-gnu:

@@ -169558,7 +169764,7 @@ PASS: gcc.target/powerpc/p8vector-fp.c
scan-assembler xsdivdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsdivsp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsmuldp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsmulsp
[-PASS:-]{+FAIL:+} gcc.target/powerpc/p8vector-fp.c scan-assembler xsnabsdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsnegdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xssqrtdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xssqrtsp

With that commit reverted (PASS) vs. non-reverted (FAIL):

--- p8vector-fp.s   2023-11-18 14:22:23.862421425 +0100
+++ p8vector-fp.s   2023-11-18 14:11:49.554421425 +0100
@@ -33,13 +33,15 @@
 0: addis 2,12,.TOC.-.LCF1@ha
addi 2,2,.TOC.-.LCF1@l
.localentry nabs_sf,.-nabs_sf
+   addis 9,2,.LC0@toc@ha
lxsspx 32,0,3
 #APP
  # 16 "[...]/source-gcc/gcc/testsuite/gcc.target/powerpc/p8vector-fp.c" 1
# reg 32
  # 0 "" 2
 #NO_APP
-   xsnabsdp 1,32
+   lfs 1,.LC0@toc@l(9)
+   xscpsgndp 1,1,32
blr
.long 0
.byte 0,0,0,0,0,0,0,0
@@ -201,13 +203,15 @@
 0: addis 2,12,.TOC.-.LCF9@ha
addi 2,2,.TOC.-.LCF9@l
.localentry nabs_df,.-nabs_df
+   addis 9,2,.LC2@toc@ha
lxsdx 32,0,3
 #APP
  # 77 "[...]/source-gcc/gcc/testsuite/gcc.target/powerpc/p8vector-fp.c" 1
# reg 32
  # 0 "" 2
 #NO_APP
-   xsnabsdp 1,32
+   lfd 1,.LC2@toc@l(9)
+   xscpsgndp 1,1,32
blr
.long 0
.byte 0,0,0,0,0,0,0,0
@@ -338,5 +342,14 @@
.cfi_endproc
 .LFE15:
.size   sqrt_df,.-sqrt_df
+   .section.rodata.cst4,"aM",@progbits,4
+   .align 2
+.LC0:
+   .long   -1082130432
+   .section.rodata.cst8,"aM",@progbits,8
+   .align 3
+.LC2:
+   .long   0
+   .long   -1074790400
.gnu_attribute 4, 1
.section.note.GNU-stack,"",@progbits

[Bug fortran/111661] [OpenACC] Detach+Attach of DT component gives libgomp: [0x405140,96] is not mapped when running 'acc update' on DT var itself

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111661

--- Comment #4 from Thomas Schwinge  ---
Created attachment 56608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56608=edit
'pr111661.c'

Before getting the Fortran case to work, let's indeed first look into some
conceptually corresponding C code:

(In reply to Tobias Burnus from comment #2)
> Looking at the code more closely, the problem is:
> 
>   #pragma omp target oacc_exit_data map(delete:tab.val.data [len: 88])
> 
> this tries to 'delete' the array descriptor - but as tab.val.data is part of
> 'tab', this deletes all of "tab".

..., and indeed the same appears to happen in C:

> Compare the C example:

I completed this into a functional code, as follows (and attached).

> struct t { int *a; int n; };
> void f() {
>   struct t s;

Here, first initialize 's':

s.n = 10;
s.a = __builtin_malloc(s.n * sizeof *s.a);

Now, before 's.a', we first need to establish 's' itself:

#pragma acc enter data copyin(s)

>   #pragma acc enter data copyin(s.a[:s.n])

Then, let's do something observable, for example:

#pragma acc serial present(s)
  {
for (int i = 0; i < s.n; ++i)
  s.a[i] = i * i;
  }

To be able to observe the computations, instead of:

>   #pragma acc exit data delete(s.a[:s.n])

..., do:

#pragma acc exit data copyout(s.a[:s.n]) //finalize

After this, we expect 's' still to be alive:

if (!acc_is_present(, sizeof s))
  __builtin_abort();

>   // for completeness, not relevant here:
>   #pragma acc exit data detach(s.a)
>   #pragma acc exit data delete(s.a)

I don't understand what you're doing here; I commented out these two.

Instead, now get rid of 's':

#pragma acc exit data delete(s)
if (acc_is_present(, sizeof s))
  __builtin_abort();

Verify results, and clean up:

for (int i = 0; i < s.n; ++i)
  if (s.a[i] != i * i)
__builtin_abort();

__builtin_free(s.a);

> }

This works fine with 'finalize' commented out.  However, with 'finalize'
enabled, we see:

> Again, here a 'finalize' would force
> the reference counts to zero and, hence, also delete 's' and not only the
> pointee/pointer target *s.a / s.a[0:.n] but also the pointer 's.a' itself.

... this behavior.

I've never in detail looked into the 'struct' mapping stuff -- I suppose the
problem here is not "simply" that ' == ', and that's confusing the
runtime?

> QUESTION: Is the current code for C (and Fortran) correct according to the
> OpenACC specification or not?

Per my -- quick, not in-depth -- first look, I'd say the code is correct, and
thus GCC's behavior is wrong.

> FOLLOW UP QUESTION: If GCC's result is incorrect, what should the compiler
> do instead?

It has to treat the outer 's' separate from the inner 's.a'.  (..., even if
they happen to have the same address -- in case that's relevant here).

How does corresponding OpenMP code behave?

[Bug c++/93431] FAIL: g++.dg/cpp2a/lambda-uneval9.C -std=c++2a (test for excess errors)

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93431

--- Comment #4 from Thomas Schwinge  ---
(In reply to myself from comment #3)
> Supposedly same issue for nvptx target, [...]

I just noticed that the nvptx target instance of this happens to have been
addressed by recent commit r14-5159-g9837f62f066db532c9db6df38ccf2653d0c3a960
"nvptx: Use the usual '#define MAKE_DECL_ONE_ONLY(DECL) (DECL_WEAK (DECL) =
1)'".

[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483

Thomas Schwinge  changed:

   What|Removed |Added

 Target|loongarch64-linux-gnu   |loongarch64-linux-gnu
   ||powerpc64le-linux-gnu
 CC||tschwinge at gcc dot gnu.org

--- Comment #6 from Thomas Schwinge  ---
(In reply to Xi Ruoyao from comment #5)
> In simplify_binary_operation_1, simplify-rtx.cc:
> 
> case COPYSIGN:
>   if (rtx_equal_p (trueop0, trueop1) && ! side_effects_p (op0))
> return op0; 
>   if (CONST_DOUBLE_AS_FLOAT_P (trueop1))
> {
>   REAL_VALUE_TYPE f1;
>   real_convert (, mode, CONST_DOUBLE_REAL_VALUE (trueop1));
>   rtx tmp = simplify_gen_unary (ABS, mode, op0, mode);
>   if (REAL_VALUE_NEGATIVE (f1))
> tmp = simplify_gen_unary (NEG, mode, op0, mode);
>  ^^^
>   return tmp; 
> }
> 
> shouldn't the "op0" with caret be "tmp" instead??

I have no knowledge at all about that code, but your suggested change appears
legit, and I do confirm that it does fix the following powerpc64le-linux-gnu
regressions:

@@ -169421,7 +169467,7 @@ PASS: gcc.target/powerpc/p8vector-fp.c
scan-assembler xsdivdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsdivsp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsmuldp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsmulsp
[-PASS:-]{+FAIL:+} gcc.target/powerpc/p8vector-fp.c scan-assembler xsnabsdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsnegdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xssqrtdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xssqrtsp

PASS: gfortran.dg/ieee/ieee_2.f90   -O0  (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90   -O0  execution test
PASS: gfortran.dg/ieee/ieee_2.f90   -O1  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/ieee/ieee_2.f90   -O1  execution test
PASS: gfortran.dg/ieee/ieee_2.f90   -O2  (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90   -O2  execution test
PASS: gfortran.dg/ieee/ieee_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
@@ -63715,7 +63751,7 @@ PASS: gfortran.dg/ieee/ieee_2.f90   -O3
-fomit-frame-pointer -funroll-loops -fpe
PASS: gfortran.dg/ieee/ieee_2.f90   -O3 -g  (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90   -O3 -g  execution test
PASS: gfortran.dg/ieee/ieee_2.f90   -Os  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/ieee/ieee_2.f90   -Os  execution test

[Bug debug/107231] [13/14 Regression] c-c++-common/goacc/kernels-loop-g.c: '-fcompare-debug' failure (length)

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107231

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #4 from Thomas Schwinge  ---
Resolved by Alexandre's recent commit
r14-5257-g61d2b4746300a604469df15789194d0a7c73791b "skip debug stmts when
assigning locus discriminators", thanks!

Is this desirable to also cherry-pick into GCC 13?

[Bug modula2/110779] SysClock can not read the clock

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #18 from Thomas Schwinge  ---
Noticed by chance:

(In reply to CVS Commits from comment #15)
> commit r13-7716-ga11ca333df2b6abb4187b39f32bb35a195d8fb33
> Author: Gaius Mulley 
> Date:   Sat Aug 12 20:20:45 2023 +0100
> 
> PR modula2/110779 SysClock can not read the clock (Darwin fixes)
> 
> This patch adds corrections to defensively check against glibc
> functions, structures and contains fallbacks.  These fixes were
> required under Darwin.

> libgm2/ChangeLog:
> 
> PR modula2/110779

> * configure.ac: Provide special case test for Darwin cross
> configuration.

That's 'GLIBCXX_IS_NATIVE' -- but that's then not actually used anywhere?

> (GLIBCXX_CONFIGURE): New statement.
> (GLIBCXX_CHECK_GETTIMEOFDAY): New statement.
> (GLIBCXX_ENABLE_LIBSTDCXX_TIME): New statement.

But without actual definitions; spotted during libgm2 'configure':

[...]
checking target system type... powerpc64le-unknown-linux-gnu
[...]/source-gcc/libgm2/configure: line 4013: GLIBCXX_CONFIGURE: command
not found
[...]/source-gcc/libgm2/configure: line 4016: GLIBCXX_CHECK_GETTIMEOFDAY:
command not found
[...]/source-gcc/libgm2/configure: line 4019:
GLIBCXX_ENABLE_LIBSTDCXX_TIME: command not found
checking for a BSD-compatible install... /usr/bin/install -c
[...]

[Bug modula2/111956] Many powerpc platforms do _not_ have support for IEEE754 long double

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956

--- Comment #10 from Thomas Schwinge  ---
In addition to what Maciej said (..., and similarly, I don't have any proper
knowledge about PowerPC details):

(In reply to Gaius Mulley from comment #6)
> Created attachment 56522 [details]
> Proposed fix v5

Thanks for looking into this!

> Here is the latest patch which [...] 96
> failures on gcc135.  [...]

With no special 'configure' flags, I'm seeing (presumably) those, too.

I noticed in 'build-gcc/gcc/m2/config-make' (generated from
'gcc/m2/config-make.in'):

# Does the target have -mabi=ieeelongdouble support in libm?  (yes/no).
HAVE_TARGET_LONG_DOUBLE_IEEE = @have_target_long_double_ieee@

..., so missing 'AC_SUBST' or similar -- but is that actually unused?

I further noticed the following delta when regenerating 'libgm2/configure':

 case "$target" in
powerpc*-*-linux*)
- LONG_DOUBLE_COMPAT_FLAGS="$LONG_DOUBLE_COMPAT_FLAGS
-mno-gnu-attribute"
  # Check for IEEE128 support in libm:


(In reply to Gaius Mulley from comment #8)
> Here is the same patch as v5 but generated using git diff -w.

Please don't include unrelated changes (here: whitespace cleanup); handle that
separately (if you must).  ;-)

[Bug target/112405] New: GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112405

Bug ID: 112405
   Summary: GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error:
conversion of register to a different size in
'view_convert_expr'"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, avieira at gcc dot gnu.org,
jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

The test case 'gcc.dg/vect/vect-simd-clone-20.c' added in recent commit
r14-5113-gaed00696a01ac065e9ed327434ec29d1cf50179e "vect: allow using inbranch
simdclones for masked loops" ICEs for GCN target (tested '-march=gfx90a'):

[...]/source-gcc/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c: In
function 'masked':
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c:22:1:
error: conversion of register to a different size in 'view_convert_expr'
VIEW_CONVERT_EXPR(loop_mask_1);

_23 = VIEW_CONVERT_EXPR(loop_mask_1);
during GIMPLE pass: vect
dump file: ./vect-simd-clone-20.c.176t.vect
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c:22:1:
internal compiler error: verify_gimple failed
0x1022708 verify_gimple_in_cfg(function*, bool, bool)
[...]/source-gcc/gcc/tree-cfg.cc:5646
0xe6edd7 execute_function_todo
[...]/source-gcc/gcc/passes.cc:2088
0xe6f6e5 execute_todo
[...]/source-gcc/gcc/passes.cc:2142

[Bug target/112363] GCN: 'FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112363

--- Comment #2 from Thomas Schwinge  ---
Right, that's what I suspected (see my "signed zero" comment).  And indeed, the
first check in 'main' instrumented as follows:

--- gcc/testsuite/gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
+++ gcc/testsuite/gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
@@ -74,8 +74,11 @@ main ()
   double res4 = reduc_minus_double (a, -0.0, cond1, n);
   double ref4 = reduc_minus_double_ref (a, -0.0, cond1, n);

+  __builtin_printf("L0\n");
+  __builtin_printf("eq %d, SBres 0x%x, SBref 0x%x\n", res1 == ref1,
signbit (res1), signbit (ref1));
   if (res1 != ref1 || signbit (res1) != signbit (ref1))
 __builtin_abort ();
+  __builtin_printf("L1\n");

..., I see:

L0
eq 1, SBres 0, SBref 8000
GCN Kernel Aborted
Kernel aborted

..., so unexpected 'signbit' difference of '-0.0' '+' reduction, and thus
'abort'.  Thus, likely, a GCN target issue -- for Andrew/Julian to take over.

[Bug target/112363] New: GCN: 'FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112363

Bug ID: 112363
   Summary: GCN: 'FAIL:
gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
execution test'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

For GCN target (tested '-march=gfx90a'), the
'gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c' recently added with
PR111401 commit r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec608c7 "ifcvt/vect:
Emit COND_OP for conditional scalar reduction" FAILs its execution test:

'[...]/build-gcc/gcc/gcn-run'
'./vect-cond-reduc-in-order-2-signed-zero.exe'; echo XYZ$?ZYX
GCN Kernel Aborted
Kernel aborted
XYZ134ZYX
OK> 
Elapsed time: 199 ms
FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test

As that commit and test case does mention "signed zero", maybe that's where the
problem lies?

[Bug target/112313] New: [14 Regression] GCN target 'gcc.dg/pr111082.c' ICE, 'during RTL pass: vregs': 'error: unrecognizable insn'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112313

Bug ID: 112313
   Summary: [14 Regression] GCN target 'gcc.dg/pr111082.c' ICE,
'during RTL pass: vregs': 'error: unrecognizable insn'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

(Assuming my tacking is to be believed) something in Git commit
r14-2060-gad5ab848cc487b3f7fd82c7cb3c408747bd10422..r14-3575-g7f2ed06ddc825e8a4e0edfd1d66b5156e6dc1d34
triggers a new GCN target ICE (tested '-march=gfx90a'):

[...]/gcc/testsuite/gcc.dg/pr111082.c: In function 'minarray2':
[...]/gcc/testsuite/gcc.dg/pr111082.c:10:1: error: unrecognizable insn:
(insn 10 9 11 2 (set (reg:V2DI 433)
(smin:V2DI (reg:V2DI 434)
(reg:V2DI 430))) -1
 (nil))
during RTL pass: vregs
[...]/gcc/testsuite/gcc.dg/pr111082.c:10:1: internal compiler error: in
extract_insn, at recog.cc:2791
0x74b91f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
[...]/gcc/rtl-error.cc:108
0x74b9a0 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
[...]/gcc/rtl-error.cc:116
0xed182e extract_insn(rtx_insn*)
[...]/gcc/recog.cc:2791
0xb42cfc instantiate_virtual_regs_in_insn
[...]/gcc/function.cc:1610
0xb42cfc instantiate_virtual_regs
[...]/gcc/function.cc:1983
0xb42cfc execute
[...]/gcc/function.cc:2030

[Bug target/112311] New: GCN: occasional 'WARNING: gcc.dg/pr82274-1.c execution test program timed out.'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112311

Bug ID: 112311
   Summary: GCN: occasional 'WARNING: gcc.dg/pr82274-1.c execution
test program timed out.'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

In GCN target testing, occasionally I see:

 PASS: gcc.dg/pr82274-1.c (test for excess errors)
+WARNING: gcc.dg/pr82274-1.c execution test program timed out.
 PASS: gcc.dg/pr82274-1.c execution test

This is a 'dg-shouldfail' test case that normally terminates instantly. 
Sometimes, however, it times out.

[Bug target/112308] New: [14 Regression] GCN: 'error: literal operands are not supported' for 'v_add_co_u32'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112308

Bug ID: 112308
   Summary: [14 Regression] GCN: 'error: literal operands are not
supported' for 'v_add_co_u32'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: rejects-valid, testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

(Assuming my tacking is to be believed) something in Git commit
r14-4720-gaf4bb221153359f5948da917d5ef2df738bb1e61..r14-4986-g4d3d2cdb574488223d023b590c3a34ddd93f4dae
regresses (or, likely, exposes?) the following:

PASS: gcc.c-torture/compile/pr48596.c   -O0  (test for excess errors)
PASS: gcc.c-torture/compile/pr48596.c   -O1  (test for excess errors)
PASS: gcc.c-torture/compile/pr48596.c   -O2  (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.c-torture/compile/pr48596.c   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
[-PASS:-]{+FAIL:+} gcc.c-torture/compile/pr48596.c   -O3 -g  (test for
excess errors)
PASS: gcc.c-torture/compile/pr48596.c   -Os  (test for excess errors)

/tmp/ccZPdmCF.s:123:33: error: literal operands are not supported
v_add_co_u32v4, s[22:23], v7, 80
  ^

That's the only instance of 'error: literal operands are not supported' I can
find in all test logs.

That's for '-march=gfx90a', and that's LLVM 13.0.1, in case that's relevant. 
(I'm happy to just have this FAIL if the issue is due to old/buggy LLVM.)

[Bug modula2/111956] Many powerpc platforms do _not_ have support for IEEE754 long double

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||build
 CC||egallager at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Last reconfirmed||2023-10-31
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Thomas Schwinge  ---
While you (Gaius) here report test failure, similar to what Maciej had reported
in PR112091 "rs6000: redefinition of 'constexpr long double std::abs(long
double)', while building libgm2", I can't even build libgm2 anymore.

Similar had reported Eric (CCed here) on GCC IRC, 2023-10-20:

 ok now this is an error I haven't seen before

/home/egallager/gcc/.cfarm135_build.build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/std_abs.h:137:3:
error: redefinition of 'constexpr long double std::abs(long double)'
 seen on cfarm135
 I think I remember something about __float128 being weird on
certain powerpc systems? Is there a configure flag that affects it?
 I'll open a bug about it...
 although actually wait... I'm not quite sure the component,
though... it's an error from a libstdc++ header, but it shows up while building
KeyBoardLEDs.lo for libm2cor in libgm2, but only for a specific target...

For example, I've got on powerpc64le-unknown-linux-gnu on indeed old Ubuntu
14.04 "trusty":

+#define M2C_LONGREAL_FLOAT128 1
+#define M2C_LONGREAL_PPC64LE 1

..., and this fails to build as follows:

libtool: compile:  [...]/build-gcc/./gcc/xg++ -B[...]/build-gcc/./gcc/
-nostdinc++ -nostdinc++
-I[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I[...]/source-gcc/libstdc++-v3/libsupc++
-I[...]/source-gcc/libstdc++-v3/include/backward
-I[...]/source-gcc/libstdc++-v3/testsuite/util
-L[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/powerpc64le-unknown-linux-gnu/bin/ -B/powerpc64le-unknown-linux-gnu/lib/
-isystem /powerpc64le-unknown-linux-gnu/include -isystem
/powerpc64le-unknown-linux-gnu/sys-include -c
-I[...]/source-gcc/libgm2/libm2cor -g -O2 -D_GNU_SOURCE -g -O2 -I. -I..
-I[...]/source-gcc/gcc/m2/gm2-libs -I[...]/source-gcc/gcc/m2/gm2-libs-iso
-DBUILD_GM2_LIBS -I[...]/source-gcc/libgm2/libm2cor/../
-I[...]/source-gcc/libgm2/libm2cor/../libm2iso -mabi=ieeelongdouble
[...]/source-gcc/libgm2/libm2cor/KeyBoardLEDs.cc  -fPIC -DPIC -o
.libs/KeyBoardLEDs.o
cc1plus: warning: Using IEEE extended precision ‘long double’ [-Wpsabi]
In file included from
[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cstdlib:81,
 from
[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/stdlib.h:36,
 from [...]/source-gcc/libgm2/libm2cor/KeyBoardLEDs.cc:43:
   
[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/std_abs.h:137:3:
error: redefinition of ‘constexpr long double std::abs(long double)’
  137 |   abs(__float128 __x)
  |   ^~~
   
[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/std_abs.h:79:3:
note: ‘constexpr long double std::abs(long double)’ previously defined here
   79 |   abs(long double __x)
  |   ^~~
make[5]: *** [KeyBoardLEDs.lo] Error 1

[...]

libtool: compile:  [...]/build-gcc/./gcc/xg++ -B[...]/build-gcc/./gcc/
-nostdinc++ -nostdinc++
-I[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I[...]/source-gcc/libstdc++-v3/libsupc++
-I[...]/source-gcc/libstdc++-v3/include/backward
-I[...]/source-gcc/libstdc++-v3/testsuite/util
-L[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L[...]/build-gcc/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/powerpc64le-unknown-linux-gnu/bin/ -B/powerpc64le-unknown-linux-gnu/lib/
-isystem /powerpc64le-unknown-linux-gnu/include -isystem
/powerpc64le-unknown-linux-gnu/sys-include -c
-I[...]/source-gcc/libgm2/libm2pim -g -O2 -D_GNU_SOURCE -g -O2 -I. -I..
-I[...]/source-gcc/gcc/m2/gm2-libs -I[...]/source-gcc/gcc/m2/gm2-libs-iso
-DBUILD_GM2_LIBS -I[...]/source-gcc/libgm2/libm2pim/../
-I[...]/source-gcc/libgm2/libm2pim/../libm2iso -mabi=ieeelongdouble
[...]/source-gcc/libgm2/libm2pim/wrapc.cc  -fPIC -DPIC -o .libs/wrapc.o
cc1plus: warning: Using IEEE extended precision ‘long double’ [-Wpsabi]

[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534' since r14-4796-g3e3d73ed5e85e7

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269

--- Comment #6 from Thomas Schwinge  ---
Created attachment 56479
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56479=edit
'initlist13.ii.xz'

(In reply to Patrick Palka from comment #5)
> I can't reproduce any of these testsuite failures on trunk with x86_64
> -m32... could you provide a preprocessed source file perhaps?

Sure; I'm attaching 'testsuite/g++.dg/cpp0x/initlist13.C' (picked at random;
not yet reduced):

$ build-gcc/gcc/cc1plus -fpreprocessed initlist13.ii -quiet -m32
-mtune=generic -march=x86-64 -pedantic-errors -Wno-long-long -std=c++20 -o
initlist13.s
In file included from
[...]/source-gcc/gcc/testsuite/g++.dg/cpp0x/initlist13.C:4:
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/complex: In
member function ‘constexpr std::complex&
std::complex::operator/=(const std::complex<_Tp>&)’:
   
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/complex:1493:16:
internal compiler error: in tsubst_expr, at cp/pt.cc:21534
[...]


For avoidance of doubt:

(In reply to Andreas Schwab from comment #2)
> Similar failures on m68k.
> 
> g++[...]

..., indeed I'm seeing similar C++ front end testing regressions -- I just had
not yet looked into those test results when I filed this issue.

PASS: g++.dg/cpp0x/initlist13.C  -std=c++14 (test for excess errors)
PASS: g++.dg/cpp0x/initlist13.C  -std=c++17 (test for excess errors)
[-PASS:-]{+FAIL: g++.dg/cpp0x/initlist13.C  -std=c++20 (internal compiler
error: in tsubst_expr, at cp/pt.cc:21534)+}
{+FAIL:+} g++.dg/cpp0x/initlist13.C  -std=c++20 (test for excess errors)
UNSUPPORTED: g++.dg/cpp0x/initlist13.C  -std=c++98

@@ -330299,8 +332283,9 @@ PASS: g++.dg/cpp0x/udlit-general.C  -std=c++14
(test for excess errors)
PASS: g++.dg/cpp0x/udlit-general.C  -std=c++14 execution test
PASS: g++.dg/cpp0x/udlit-general.C  -std=c++17 (test for excess errors)
PASS: g++.dg/cpp0x/udlit-general.C  -std=c++17 execution test
[-PASS:-]{+FAIL: g++.dg/cpp0x/udlit-general.C  -std=c++20 (internal
compiler error: in tsubst_expr, at cp/pt.cc:21534)+}
{+FAIL:+} g++.dg/cpp0x/udlit-general.C  -std=c++20 (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} g++.dg/cpp0x/udlit-general.C  -std=c++20
[-execution test-]{+compilation failed to produce executable+}
UNSUPPORTED: g++.dg/cpp0x/udlit-general.C  -std=c++98

PASS: g++.dg/cpp1y/complex_literals1.C  -std=c++14 (test for excess errors)
PASS: g++.dg/cpp1y/complex_literals1.C  -std=c++17 (test for excess errors)
[-PASS:-]{+FAIL: g++.dg/cpp1y/complex_literals1.C  -std=c++20 (internal
compiler error: in tsubst_expr, at cp/pt.cc:21534)+}
{+FAIL:+} g++.dg/cpp1y/complex_literals1.C  -std=c++20 (test for excess
errors)
UNSUPPORTED: g++.dg/cpp1y/complex_literals1.C  -std=c++98

PASS: g++.dg/cpp1y/udlit-userdef-string.C  -std=c++14 (test for excess
errors)
PASS: g++.dg/cpp1y/udlit-userdef-string.C  -std=c++17 (test for excess
errors)
[-PASS:-]{+FAIL: g++.dg/cpp1y/udlit-userdef-string.C  -std=c++20 (internal
compiler error: in tsubst_expr, at cp/pt.cc:21534)+}
{+FAIL:+} g++.dg/cpp1y/udlit-userdef-string.C  -std=c++20 (test for excess
errors)
UNSUPPORTED: g++.dg/cpp1y/udlit-userdef-string.C  -std=c++98

@@ -379174,8 +381318,9 @@ PASS: g++.dg/opt/nrv17.C  -std=c++14 (test for
excess errors)
PASS: g++.dg/opt/nrv17.C  -std=c++14 execution test
PASS: g++.dg/opt/nrv17.C  -std=c++17 (test for excess errors)
PASS: g++.dg/opt/nrv17.C  -std=c++17 execution test
[-PASS:-]{+FAIL: g++.dg/opt/nrv17.C  -std=c++20 (internal compiler error:
in tsubst_expr, at cp/pt.cc:21534)+}
{+FAIL:+} g++.dg/opt/nrv17.C  -std=c++20 (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} g++.dg/opt/nrv17.C  -std=c++20 [-execution
test-]{+compilation failed to produce executable+}
PASS: g++.dg/opt/nrv17.C  -std=c++98 (test for excess errors)
PASS: g++.dg/opt/nrv17.C  -std=c++98 execution test

PASS: g++.dg/modules/xtreme-header-5_a.H -std=c++17 (test for excess
errors)
[-PASS:-]{+FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (internal
compiler error: in tsubst_expr, at cp/pt.cc:21534)+}
{+FAIL:+} g++.dg/modules/xtreme-header-5_a.H -std=c++2a (test for excess
errors)
[-PASS:-]{+FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2b (internal
compiler error: in tsubst_expr, at cp/pt.cc:21534)+}
{+FAIL:+} g++.dg/modules/xtreme-header-5_a.H -std=c++2b (test for excess
errors)[-PASS: g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)-]
[-PASS: g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)-]
PASS: g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
{+FAIL: g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)+}
{+FAIL: 

[Bug c++/112269] New: [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269

Bug ID: 112269
   Summary: [14 Regression] x86_64 GNU/Linux '-m32' multilib
'libstdc++-v3/include/complex:1493: internal compiler
error: in tsubst_expr, at cp/pt.cc:21534'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, testsuite-fail
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

(Assuming my tacking is to be believed) something in Git commit
r14-4720-gaf4bb221153359f5948da917d5ef2df738bb1e61..r14-4986-g4d3d2cdb574488223d023b590c3a34ddd93f4dae
ICE-regresses a few x86_64 GNU/Linux '-m32' multilib test cases:

[-PASS:-]{+FAIL:+} 24_iterators/reverse_iterator/100639.cc  -std=c++20
(test for excess errors)
[-PASS:-]{+FAIL:+} 24_iterators/reverse_iterator/100639.cc  -std=c++26
(test for excess errors)

In file included from
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/ccomplex:39,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h:127,
 from :
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/complex: In
member function 'constexpr std::complex&
std::complex::operator/=(const std::complex<_Tp>&)':
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/complex:1493:
internal compiler error: in tsubst_expr, at cp/pt.cc:21534
0x784e58 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
[...]/source-gcc/gcc/cp/pt.cc:21534
0xf03edb fold_non_dependent_expr_template
[...]/source-gcc/gcc/cp/constexpr.cc:9030
0xfa17ed fold_for_warn(tree_node*)
[...]/source-gcc/gcc/cp/expr.cc:412
0x1144377 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
[...]/source-gcc/gcc/cp/typeck.cc:5436
0x11525b3 cp_build_modify_expr(unsigned int, tree_node*, tree_code,
tree_node*, int)
[...]/source-gcc/gcc/cp/typeck.cc:9522
0xec5c4d build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
[...]/source-gcc/gcc/cp/call.cc:7312
0x11536a5 build_x_modify_expr(unsigned int, tree_node*, tree_code,
tree_node*, tree_node*, int)
[...]/source-gcc/gcc/cp/typeck.cc:9728
0x103f464 cp_parser_assignment_expression
[...]/source-gcc/gcc/cp/parser.cc:10611
0x103f6b4 cp_parser_expression
[...]/source-gcc/gcc/cp/parser.cc:10740
0x10441c7 cp_parser_expression_statement
[...]/source-gcc/gcc/cp/parser.cc:12939
0x10504ea cp_parser_statement
[...]/source-gcc/gcc/cp/parser.cc:12719
0x10517f7 cp_parser_statement_seq_opt
[...]/source-gcc/gcc/cp/parser.cc:13188
0x1051a27 cp_parser_compound_statement
[...]/source-gcc/gcc/cp/parser.cc:13042
0x1073d95 cp_parser_function_body
[...]/source-gcc/gcc/cp/parser.cc:25560
0x1073d95 cp_parser_ctor_initializer_opt_and_function_body
[...]/source-gcc/gcc/cp/parser.cc:25611
0x107a1ae cp_parser_function_definition_after_declarator
[...]/source-gcc/gcc/cp/parser.cc:32273
0x107a634 cp_parser_late_parsing_for_member
[...]/source-gcc/gcc/cp/parser.cc:33241
0x104c3e4 cp_parser_class_specifier
[...]/source-gcc/gcc/cp/parser.cc:26761
0x104c3e4 cp_parser_type_specifier
[...]/source-gcc/gcc/cp/parser.cc:19725
0x104cb6b cp_parser_decl_specifier_seq
[...]/source-gcc/gcc/cp/parser.cc:16283

Similarly:

[-PASS:-]{+FAIL:+} std/ranges/iota/93267.cc  -std=c++20 (test for excess
errors)
[-PASS:-]{+FAIL:+} std/ranges/iota/93267.cc  -std=c++26 (test for excess
errors)

[-PASS:-]{+FAIL:+} std/ranges/iota/96042.cc  -std=c++20 (test for excess
errors)
[-PASS:-]{+FAIL:+} std/ranges/iota/96042.cc  -std=c++26 (test for excess
errors)

[-PASS:-]{+FAIL:+} std/ranges/iota/size.cc  -std=c++20 (test for excess
errors)
[-PASS:-]{+FAIL:+} std/ranges/iota/size.cc  -std=c++26 (test for excess
errors)

[-PASS:-]{+FAIL:+} std/ranges/subrange/96042.cc  -std=c++20 (test for
excess errors)
[-PASS:-]{+FAIL:+} std/ranges/subrange/96042.cc  -std=c++26 (test for
excess errors)

[Bug target/112265] [14 Regression] GCN offloading 'libgomp.c-c++-common/for-5.c': 'internal compiler error: maximum number of generated reload insns per insn achieved (90)'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112265

Thomas Schwinge  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
The ICE goes away if I revert PR111000 commit
r14-4786-gd118738e71cf4615f170fff8dabe66442206d008 "tree-optimization/111000 -
restrict invariant motion of shifts".  What that now tells us I have no clue.

[Bug target/112265] New: [14 Regression] GCN offloading 'libgomp.c-c++-common/for-5.c': 'internal compiler error: maximum number of generated reload insns per insn achieved (90)'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112265

Bug ID: 112265
   Summary: [14 Regression] GCN offloading
'libgomp.c-c++-common/for-5.c': 'internal compiler
error: maximum number of generated reload insns per
insn achieved (90)'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp, testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

(Assuming my tacking is to be believed) something in Git commit
r14-4720-gaf4bb221153359f5948da917d5ef2df738bb1e61..r14-4986-g4d3d2cdb574488223d023b590c3a34ddd93f4dae
regressed GCN offloading 'libgomp.c-c++-common/for-5.c' both C and C++
compilation:

[-PASS:-]{+FAIL: libgomp.c/../libgomp.c-c++-common/for-5.c (internal
compiler error: maximum number of generated reload insns per insn achieved
(90))+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-5.c (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/../libgomp.c-c++-common/for-5.c
[-execution test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c (internal
compiler error: maximum number of generated reload insns per insn achieved
(90))+}
{+FAIL:+} libgomp.c++/../libgomp.c-c++-common/for-5.c (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c++/../libgomp.c-c++-common/for-5.c
[-execution test-]{+compilation failed to produce executable+}

All of '-march=fiji', '-march=gfx900', '-march=gfx906', '-march=gfx908',
'-march=gfx90a' are affected.

[Bug libgomp/112264] New: Occasionally (but very rare): 'FAIL: libgomp.fortran/target-nowait-array-section.f90 -O execution test'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112264

Bug ID: 112264
   Summary: Occasionally (but very rare): 'FAIL:
libgomp.fortran/target-nowait-array-section.f90   -O
execution test'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp, testsuite-fail
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

As reported in

"OpenMP/Fortran: Use firstprivat not alloc for ptr attach for arrays" almost a
year ago:

| For non-offloading x86_64-pc-linux-gnu '-m32', I'm occasionally (but very
| rarely!) seeing ['libgomp.fortran/target-nowait-array-section.f90']
| FAIL its execution test.  Similar can also
| be seen on occasional reports via ,
| .

..., and Jakub's report in
 "libgomp: Fix comment
typo".

[Bug target/112088] New: [14 Regression] GCN target testing broken by "amdgcn: add -march=gfx1030 EXPERIMENTAL"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112088

Bug ID: 112088
   Summary: [14 Regression] GCN target testing broken by "amdgcn:
add -march=gfx1030 EXPERIMENTAL"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

Assuming that I did my bisecting correctly, it's the recent commit
r14-4787-gc7ec7bd1c6590cf4eed267feab490288e0b8d691 "amdgcn: add -march=gfx1030
EXPERIMENTAL" that completely distorts GCN target testing: execution test FAILs
all over the place due to 'gcn-run' failing with:

Possible kernel exit value corruption, 2 most significant bytes aren't
0x, 0xcafe, or 0: 0x9d4c0038

(The last value different each time.)

I've tested '-march=gfx90a' and '-march=fiji'.

[Bug other/111966] New: GCN '--with-arch=[...]' not considered for 'mkoffload' default 'elf_arch'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111966

Bug ID: 111966
   Summary: GCN '--with-arch=[...]' not considered for 'mkoffload'
default 'elf_arch'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

I've noticed this issue long ago; it probably existed since commit
r11-2178-ga4f49061b6d921f72b2faf4843144f3c75f828f7 "amdgcn: Handle early debug
info in mkoffload", when GCN offloading GCC 'configure'd different from
(implicit or explicit) '--with-arch=fiji', and compiling user code without
explicit '-foffload-options=amdgcn-amdhsa=-march=[...]'.  In that case, the
compiler-side default doesn't match 'gcc/config/gcn/mkoffload.cc:uint32_t
elf_arch = EF_AMDGPU_MACH_AMDGCN_GFX803;', and 'elf_arch' isn't getting
corrected by an explicit '-march'.  In that case, you'll get offloading
compilation failures if debugging ('-g') is enabled, for example:

[-PASS:-]{+FAIL:+} libgomp.fortran/declare-target-1.f90   -O3 -g  (test for
excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.fortran/declare-target-1.f90   -O3 -g 
[-execution test-]{+compilation failed to produce executable+}

... due to:

[...]
ld: error: incompatible mach: /tmp/cc8pa454.mkoffload.dbg.o
collect2: error: ld returned 1 exit status
gcn mkoffload: fatal error:
[...]/x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc returned 1 exit status
[...]

('elf_arch' is used only in 'copy_early_debug_info'.)

Not a very typical configuration that anyone but me would have used ;-) -- but
I'm reporting it now, given that as of recent commit
r14-4734-g56ed1055b2f40ac162ae8d382280ac07a33f789f "amdgcn: deprecate Fiji
device and multilib", users are more likely to run into this: the compiler-side
default is now '--with-arch=gfx900' instead of 'fiji', and generally people may
specify a specific non-'fiji' '--with-arch=[...]' (for example, together with
'--without-multilib-list'), and build their code without explicit
'-foffload-options=amdgcn-amdhsa=-march=[...]'.

We need to propagate the compiler-side default '--with-arch=[...]' into
'mkoffload' 'elf_arch' -- or change the driver to simply always pass an
explicit '-march' to 'mkoffload' (and verify that, make the default 'elf_arch'
invalid)?

[Bug target/111937] [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data.

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
Created attachment 56178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56178=edit
0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch

(In reply to Xiao Ma from comment #0)
> Recently, I wanted to port an open source gpgpu target (a custom
> modification of RISCV) to GCC/openmp (Following the approach of gcu and
> nvptx, using offloading (https://gcc.gnu.org/wiki/Offloading)).

Interesting!  Please keep us posted how this works out.

> However, the
> upstream after this patch
> (https://github.com/mxlol233-ventus/gcc/commit/
> 3496ca4e6566fc3c5f1093a0290bb88c34d368f8#diff-
> 98b71abedd6e59eb80cb43e75ebb507ffa8bf540ee88aa099c6c7fe7cf90ae3e),
> NUM_POLY_INT_COEFFS became greater than 1, while for the x86-64-*-* target,
> NUM_POLY_INT_COEFFS=1. This makes it impossible for a RISC-V*-*-* lto1 to
> parse the data in the LTO sections (e.g. gnu.offload_lto_*) of the object
> files generated by x86-64-*-*.

I'm not sure about your initial analysis; I'm not familiar with the
code/changes you cite.

However, please try building with the attached
'0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch'.  If that triggers, we've
(likely...) found (one of) your issue(s).

[Bug fortran/111938] Missing OpenACC/Fortran handling in 'gcc/fortran/frontend-passes.c'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111938

--- Comment #1 from Thomas Schwinge  ---
(In reply to Thomas Schwinge from comment #0)
> 'EXEC_OACC_ATOMIC') are handled in 'gcc/fortran/frontend-passes.c'

> Disabling the OpenMP handling, and running 'gomp.exp', I don't get much, but
> still one ICE in 'gfortran.dg/gomp/pr92977.f90'

Aha: PR92977, PR93462.

> [...], so I
> conclude this code is doing something useful for OpenMP, and we should
> investigate whether OpenACC also needs to be handled?

That I already had suspected almost a decade ago;

"OpenACC fortran front end":

| Doesn't gcc/fortran/frontend-passes:gfc_code_walker need to be updated
| for OpenACC?

;'-)

[Bug fortran/111938] New: Missing OpenACC/Fortran handling in 'gcc/fortran/frontend-passes.c'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111938

Bug ID: 111938
   Summary: Missing OpenACC/Fortran handling in
'gcc/fortran/frontend-passes.c'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

I've noticed that none of the OpenACC 'EXEC_OACC_[...]' codes (other than
'EXEC_OACC_ATOMIC') are handled in 'gcc/fortran/frontend-passes.c'
('gfc_code_walker'), and similarly the respective 'gfc_omp_clauses' members not
'WALK_SUBEXPR'ed.

At least a lot of (possibly, all?) OpenMP 'EXEC_OMP_[...]' codes and
'gfc_omp_clauses' members appear to be handled.  (Not verified in detail.)

Disabling the OpenMP handling, and running 'gomp.exp', I don't get much, but
still one ICE in 'gfortran.dg/gomp/pr92977.f90', and a dump scanning FAIL in
'gfortran.dg/gomp/workshare2.f90' (nothing for 'check-target-libgomp'), so I
conclude this code is doing something useful for OpenMP, and we should
investigate whether OpenACC also needs to be handled?

[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=66005 |

--- Comment #11 from Thomas Schwinge  ---
This one (libgomp) is finally resolved, and three similar-in-spirit patches
submitted:

  - 
"libffi: Consider '--with-build-sysroot=[...]' for target libraries' build-tree
testing (instead of build-time 'CC' etc.) [PR109951]"
  - 
"libatomic: Consider '--with-build-sysroot=[...]' for target libraries'
build-tree testing (instead of build-time 'CC' etc.) [PR109951]"
  - 
"libgo: Consider '--with-build-sysroot=[...]' for target libraries' build-tree
testing (instead of build-time 'CC' etc.) [PR109951]"

[Bug other/100059] [OpenMP] wrong code with 'declare target link' and a scalar variable

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059

Thomas Schwinge  changed:

   What|Removed |Added

  Component|middle-end  |other
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Assignee|burnus at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #7 from Thomas Schwinge  ---
commit r14-3650-gfe0f9e09413047484441468b05288412760d8a09 "Add
'libgomp.c-c++-common/pr100059-1.c'"

[Bug middle-end/100059] [OpenMP] wrong code with 'declare target link' and a scalar variable

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
   See Also||https://github.com/MentorEm
   ||bedded/nvptx-tools/pull/29

--- Comment #6 from Thomas Schwinge  ---
(In reply to Tobias Burnus from comment #4)
> https://github.com/MentorEmbedded/nvptx-tools/pull/29

This is now finally incorporated, sorry for the (long...) delay.

Are you going to push the GCC-level test case (submitted in this PR), or want
me to?  For nvptx offloading, it'll FAIL its execution test until nvptx-tools
updated, but that's OK in my opinion.

[Bug target/106271] Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such file or directory

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271

Thomas Schwinge  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||palmer at gcc dot gnu.org,
   ||rzinsly at ventanamicro dot com

--- Comment #6 from Thomas Schwinge  ---
I noticed recent commit r14-3387-g47f95bc4be4eb14730ab3eaaaf8f6e71fda47690
"RISC-V: Add multiarch support on riscv-linux-gnu" -- but can't tell off-hand
whether that fixed all the issues here?

[Bug libgomp/111024] New: libgomp: FAILs with oldish libnuma/libmemkind

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111024

Bug ID: 111024
   Summary: libgomp: FAILs with oldish libnuma/libmemkind
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

Re commit r14-2462-g450b05ce54d3f08c583c3b5341233ce0df99725b "libgomp: Use
libnuma for OpenMP's partition=nearest allocation trait" (plus commit
r14-2514-g407d68daed00e040a7d9545b2a18aa27bf93a106 "libgomp: Fix allocator
handling for Linux when libnuma is not available"), on our amdfury2, nvidia-4a
systems (not necessarily an exhaustive list), I see:

+PASS: libgomp.c/../libgomp.c-c++-common/alloc-11.c (test for excess
errors)
+FAIL: libgomp.c/../libgomp.c-c++-common/alloc-11.c execution test

alloc-11.exe: src/memkind_interleave.c:54: memkind_interleave_init_once:
Assertion `err == 0' failed.

+PASS: libgomp.c/../libgomp.c-c++-common/alloc-12.c (test for excess
errors)
+FAIL: libgomp.c/../libgomp.c-c++-common/alloc-12.c execution test

alloc-12.exe: src/memkind_interleave.c:54: memkind_interleave_init_once:
Assertion `err == 0' failed.

Same for C++.

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x775b2921 in __GI_abort () at abort.c:79
#2  0x775a248a in __assert_fail_base (fmt=0x77729750
"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x77169682 "err == 0",
file=file@entry=0x7716986a "src/memkind_interleave.c", line=line@entry=54,
function=function@entry=0x77169890 "memkind_interleave_init_once") at
assert.c:92
#3  0x775a2502 in __GI___assert_fail (assertion=0x77169682 "err
== 0", file=0x7716986a "src/memkind_interleave.c", line=54,
function=0x77169890 "memkind_interleave_init_once") at assert.c:101
#4  0x771691c4 in memkind_interleave_init_once () from
/usr/lib/x86_64-linux-gnu/libmemkind.so.0
#5  0x77972907 in __pthread_once_slow (once_control=0x7736d72c,
init_routine=0x77169180 ) at
pthread_once.c:116
#6  0x77166d95 in memkind_malloc () from
/usr/lib/x86_64-linux-gnu/libmemkind.so.0
#7  0x77bbed04 in omp_aligned_alloc (alignment=1, size=4,
allocator=6309568) at [...]/libgomp/config/linux/../../allocator.c:521
#8  0x00400fd9 in main () at
source-gcc/libgomp/testsuite/libgomp.c-c++-common/alloc-11.c:182

Note that the failure is in libmemkind; the commits that trigger it are for
libnuma support.

Both these system have Ubuntu bionic libnuma1 2.0.11-2.1ubuntu0.1, libmemkind0
1.1.0-0ubuntu1.  Assuming this is similar to the latter's upstream v1.1.0,
that's
,
where, per assembly-level debugging, we've got 'err = MEMKIND_ERROR_MALLCTL'
from '‎memkind_arena_create_map‎';
.

Might be a bug in libnuma/libmemkind, fixed in later versions (we're not seeing
these FAILs on other systems), or is the bug on our side, due to calling into
libnuma/libmemkind with some unexpected parameters, for example?

[Bug fortran/88420] Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88420

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/110750] [og13] nvptx offloading FAILs 'libgomp.c-c++-common/target-implicit-map-4.c' execution test

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110750

--- Comment #1 from Thomas Schwinge  ---
... but it *does not* FAIL in my powerpc64le testing with Nvidia Tesla V100
(but *does* FAIL with powerpc64le Nvidia Quadro GV100 in the same way as it
does for x86_64 originally reported here).

[Bug middle-end/110750] New: [og13] nvptx offloading FAILs 'libgomp.c-c++-common/target-implicit-map-4.c' execution test

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110750

Bug ID: 110750
   Summary: [og13] nvptx offloading FAILs
'libgomp.c-c++-common/target-implicit-map-4.c'
execution test
   Product: gcc
   Version: og13 (devel/omp/gcc-13)
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

On og13 (but not master branch!), I notice that
'libgomp.c-c++-common/target-implicit-map-4.c' PASSes GCN ('-march=gfx90a'),
but FAILs nvptx offloading execution test:

spawn [open ...]

libgomp: cuCtxSynchronize error: an illegal memory access was encountered
[...]
FAIL: libgomp.c/../libgomp.c-c++-common/target-implicit-map-4.c execution
test

FAIL: libgomp.c++/../libgomp.c-c++-common/target-implicit-map-4.c execution
test

commit fab6ab642205f7226e98a5ee4a3b46bc85e50360 "OpenMP (C/C++): Keep pointer
value of unmapped ptr with default mapping [PR110270]",
.

[Bug tree-optimization/110412] [14 Regression] GCN 'gcc.dg/vect/pr65494.c' ICE, 'error: invalid types in nop conversion'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110412

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Thomas Schwinge  ---
(In reply to Andrew Pinski from comment #1)
> I think this was just fixed by r14-2085 or r14-2086 (both aka PR 110371).

Thanks!  Indeed commit r14-2086-g1bfe7e5352d1f4ac525317454aca45aa80a517ba 'Use
cvt_op to save intermediate type operand instead of "subtle" vec_dest' does
resolve this ICE:

PASS: gcc.dg/vect/pr65494.c (test for excess errors)
PASS: gcc.dg/vect/pr65494.c scan-tree-dump vect "vectorized 1 loops in
function"

*** This bug has been marked as a duplicate of bug 110371 ***

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #11 from Thomas Schwinge  ---
*** Bug 110412 has been marked as a duplicate of this bug. ***

[Bug target/110412] New: [14 Regression] GCN 'gcc.dg/vect/pr65494.c' ICE, 'error: invalid types in nop conversion'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110412

Bug ID: 110412
   Summary: [14 Regression] GCN 'gcc.dg/vect/pr65494.c' ICE,
'error: invalid types in nop conversion'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

In GCC commit
bc6bd0d608da1609c1caeb04ab795a83720add55..ad5ab848cc487b3f7fd82c7cb3c408747bd10422
appeared a new GCN ICE:

[-PASS:-]{+FAIL: gcc.dg/vect/pr65494.c (internal compiler error:
verify_gimple failed)+}
{+FAIL:+} gcc.dg/vect/pr65494.c (test for excess errors)
[-FAIL:-]{+PASS:+} gcc.dg/vect/pr65494.c scan-tree-dump vect "vectorized 1
loops in function"

[...]/gcc/testsuite/gcc.dg/vect/pr65494.c: In function 'foo':
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__37.29_187 = (vector(64) float) vect__36.27_201;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__37.29_185 = (vector(64) float) vect__36.28_199;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__56.38_164 = (vector(64) float) vect__55.36_169;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__56.38_162 = (vector(64) float) vect__55.37_167;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__75.47_141 = (vector(64) float) vect__74.45_146;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__75.47_139 = (vector(64) float) vect__74.46_144;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__94.20_218 = (vector(64) float) vect__93.18_223;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__94.20_216 = (vector(64) float) vect__93.19_221;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__113.12_238 = (vector(64) float) vect__112.10_243;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__113.12_236 = (vector(64) float) vect__112.11_241;
during GIMPLE pass: vect
dump file: pr65494.c.173t.vect
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: internal compiler error:
verify_gimple failed
0xfcd424 verify_gimple_in_cfg(function*, bool, bool)
[...]/gcc/tree-cfg.cc:5646
0xe2b117 execute_function_todo
[...]/gcc/passes.cc:2098
0xe2ba45 execute_todo
[...]/gcc/passes.cc:2152

[Bug testsuite/66005] libgomp make check time is excessive

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005

--- Comment #21 from Thomas Schwinge  ---
Jakub, given that 'libgomp is usually the “long tail” of [...] testing' (GCC
IRC, 2023-06-05), Iain has asked that I backport to release branches the
changes implemented here:

  - commit r14-854-ge797db5c744f7b4e110f23a495fca8e6b8aebe83 "Support parallel
testing in libgomp, part I [PR66005]"
  - commit r14-855-g6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba "Support parallel
testing in libgomp, part II [PR66005]"
  - commit r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752 "Support parallel
testing in libgomp: fallback Perl 'flock' [PR66005]"

(I haven't looked yet in detail, but there shouldn't be any non-trivial
prerequisite commits, if any at all.)

I've not had any reports about breakage or regressions, so that does seem safe
to me -- any objections?

[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110308

--- Comment #10 from Thomas Schwinge  ---
(In reply to manolis.tsamis from comment #9)
> test whether the patch in 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308#c10 also fixes this issue?

Thanks, it does!

[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313

Thomas Schwinge  changed:

   What|Removed |Added

 CC||manolis.tsamis at vrull dot eu

--- Comment #4 from Thomas Schwinge  ---
(In reply to myself from comment #2)
> I had found, and wanted to report the same thing:
> 
> (In reply to Andrew Stubbs from comment #1)
> > This ICE also affect the following standalone test failures (raw amdgcn, no
> > offloading):
> > 
> > gfortran.dg/assumed_rank_21.f90
> > gfortran.dg/finalize_38.f90
> > gfortran.dg/finalize_38a.f90
> 
> ... but with the additional detail: ICE in their '-O3 -g' testing variants
> only.

Also, there appears to be some non-determinism involved here: in another run of
the exact same toolchain build I've then also seen the ICE for
'gfortran.dg/PR100906.f90' (again, '-O3 -g' testing variant only).

(In reply to myself from comment #0)
> I'm now bisecting.

With commit r14-1873-g6a2e8dcbbd4bab374b27abea375bf7a921047800 "cprop_hardreg:
Enable propagation of the stack pointer if possible" reverted, we're back to
normal, both for GCN target and for GCN offloading.

That, however, is completely outside my area of competence -- if such a thing
exists at all...  ;-)

[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-20

--- Comment #2 from Thomas Schwinge  ---
I had found, and wanted to report the same thing:

(In reply to Andrew Stubbs from comment #1)
> This ICE also affect the following standalone test failures (raw amdgcn, no
> offloading):
> 
> gfortran.dg/assumed_rank_21.f90
> gfortran.dg/finalize_38.f90
> gfortran.dg/finalize_38a.f90

... but with the additional detail: ICE in their '-O3 -g' testing variants
only.

[Bug target/110313] New: [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313

Bug ID: 110313
   Summary: [14 Regression] GCN Fiji reload ICE in
'process_alt_operands'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, burnus at gcc dot gnu.org, jules at 
gcc dot gnu.org
  Target Milestone: ---
Target: GCN

Between GCC commit
2720bbd597f56742a17119dfe80edc2ba86af255..bc6bd0d608da1609c1caeb04ab795a83720add55
(that is, 2023-05-30 - 2023-06-16) appeared some changes in GCC that cause an
ICE for a small number of libgomp offloading test cases, for GCN offloading
only, and with (default) '-march=fiji' only.

[-PASS:-]{+FAIL: libgomp.c++/../libgomp.c-c++-common/for-9.c (internal
compiler error: Segmentation fault)+}
{+FAIL:+} libgomp.c++/../libgomp.c-c++-common/for-9.c (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c++/../libgomp.c-c++-common/for-9.c
[-execution test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/../libgomp.c-c++-common/for-9.c (internal
compiler error: Segmentation fault)+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-9.c (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/../libgomp.c-c++-common/for-9.c
[-execution test-]{+compilation failed to produce executable+}

The latter C++ variant not always observed.

Additionally (same ICE), but so far observed on one system only, when running
the exact same toolchain:

[-PASS:-]{+FAIL: libgomp.c/../libgomp.c-c++-common/for-16.c (internal
compiler error: Segmentation fault)+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-16.c (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/../libgomp.c-c++-common/for-16.c
[-execution test-]{+compilation failed to produce executable+}

The ICE is:

spawn -ignore SIGHUP gcc
../source-gcc/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/for-9.c
-I../source-gcc/libgomp/testsuite/../../include
-I../source-gcc/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -O2 -lm -o
./for-9.exe
during RTL pass: reload
../source-gcc/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/for-2.h:
In function 'f20_dpf_ds128_runtime':
   
../source-gcc/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/for-2.h:346:1:
internal compiler error: Segmentation fault
0xe28adf crash_signal
[...]/source-gcc/gcc/toplev.cc:314
0xc19737 process_alt_operands
[...]/source-gcc/gcc/lra-constraints.cc:2789
0xc19737 curr_insn_transform
[...]/source-gcc/gcc/lra-constraints.cc:4201
0xc1ed0e lra_constraints(bool)
[...]/source-gcc/gcc/lra-constraints.cc:5396
0xbff652 lra(_IO_FILE*)
[...]/source-gcc/gcc/lra.cc:2396
0xb9c639 do_reload
[...]/source-gcc/gcc/ira.cc:5967
0xb9c639 execute
[...]/source-gcc/gcc/ira.cc:6153
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
gcn mkoffload: fatal error: x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc
returned 1 exit status
compilation terminated.
lto-wrapper: fatal error: [...]/amdgcn-amdhsa/mkoffload returned 1 exit
status

'gcc/lra-constraints.cc':

2778   if (operand_reg[nop] != NULL_RTX
2779   /* Output operands and matched input operands are
2780  not inherited.  The following conditions do not
2781  exactly describe the previous statement but they
2782  are pretty close.  */
2783   && curr_static_id->operand[nop].type != OP_OUT
2784   && (this_alternative_matches < 0
2785   || curr_static_id->operand[nop].type != OP_IN))
2786 {
2787   int last_reload = (lra_reg_info[ORIGINAL_REGNO
2788   (operand_reg[nop])]
2789  .last_reload);

Tobias mentioned that 'operand_reg[nop]' is '(reg/f:DI 16 s16 [3483])'.

It was "obvious" to try, but reverting Vlad's three recent commits:

  - commit r14-1891-g154c69039571c66b3a6d16ecfa9e6ff22942f59f "RA: Ignore
conflicts for some pseudos from insns throwing a final exception"
  - commit r14-1610-g8cc8707446b77f9413654b31704f5a639673c916 "RA: Constrain
class of pic offset table pseudo to general regs"
  - commit r14-1417-g30038a207c10a2783fa2695b62c7c8458ef05e73 "LRA: Update insn
sp offset if its input reload changes SP"

... does *not* cure this issue.

I've not 

[Bug other/110178] [14 regression] gfortran.dg/gomp/target-update-1.f90 fails after r14-1579-g4ede915d5dde93

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110178

Thomas Schwinge  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu   |
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||tschwinge at gcc dot gnu.org
  Build|powerpc64le-linux-gnu   |
URL||https://inbox.sourceware.or
   ||g/202306062250.356Mo6Qw3100
   ||125 at shliclel4214 dot 
sh.intel.c
   ||om
   Host|powerpc64le-linux-gnu   |
   Assignee|unassigned at gcc dot gnu.org  |burnus at gcc dot 
gnu.org
   Keywords||openmp

--- Comment #1 from Thomas Schwinge  ---
Fixed as part of commit r14-1736-g38944ec2a6fa108d24e5cfbb24c52020f9aa3015
"OpenMP: Cleanups related to the 'present' modifier".