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

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

[jules at gcc dot gnu.org]

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

            Bug ID: 113331
           Summary: AMDGCN: Compilation failure due to duplicate
                    .LEHB<n>/.LEHE<n> symbols
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jules at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57037&action=edit
Test case

The attached file fails to compile with AMD GCN offloading on current mainline.
It also fails on GCC 13.2.0 as packaged in Debian, so this doesn't appear to be
a regression.

$ g++ -fopenmp -foffload=amdgcn-amdhsa -save-temps  dup-syms.cc -o dup-syms 
./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:256:1: error: symbol '.LEHB0' is
already defined
.LEHB0:
^
./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:258:1: error: symbol '.LEHE0' is
already defined
.LEHE0:
^
./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:288:1: error: symbol '.LEHB1' is
already defined
.LEHB1:
^
./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:290:1: error: symbol '.LEHE1' is
already defined
.LEHE1:
^

The test case doesn't trigger with NVPTX offloading, but I don't think that
definitely implies that this is something GCN-specific (vs. generically
offload-related).

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

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
These are exception handling region labels, possibly nvptx has no way to do EH.

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
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 (&global_options) ==
UI_NONE)
3231        return;

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<n>/.LEHE<n> symbols

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> 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 <tschwinge at gcc dot gnu.org> ---
Planning to look into this as part of my ongoing GPU C++ support task.

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

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> 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 <tschwinge at gcc dot gnu.org> ---
(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.