[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
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
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 target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
All of the following is in except.cc.
The problem is that the count in the label is relative to 'call_site_base'.
In convert_to_eh_region_ranges, those get bumped - but the function reset it at
the end. They do get accumulated via, e.g., dw2_output_call_site_table but, in
GCN, the output_function_exception_table is exit early because of:
3229 if (!crtl->uses_eh_lsda
3230 || targetm_common.except_unwind_info (_options) ==
UI_NONE)
3231return;
Thus, the next time convert_to_eh_region_ranges is called, it starts with the
very same numbers.
The reason that this gets produced is because there is an ERT_MUST_NOT_THROW
("MUST_NOT_THROW regions prevent all exceptions from propagating. This region
type is used in C++ to surround destructors being run inside a CLEANUP
region.")
As there are both "-1" (implies no action) and "-2" (MUST_NOT_THROW), GCN
produces this output. For whatever reason, nvptx has no "-1" actions in the
function, thus, after the change to "-2", there is no flip and - hence, no
output is produced - avoiding the issue.
→ I bet that both gcn and nvptx are affected (unless luck or compiled with
-fno-exceptions).
[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331 --- Comment #1 from Richard Biener --- These are exception handling region labels, possibly nvptx has no way to do EH.
