Hi!
On 2021-04-21T09:10:52-0600, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org>
wrote:
> On 4/21/2021 6:56 AM, Richard Biener wrote:
>> libatomic isn't built for amdgcn but reduction-16.c adds it
>> via -foffload=-latomic when offloading for nvptx is enabled.
(ACK for that problem.)
>> The following avoids linker errors when offloading to amdgcn is enabled
>> as well.
>>
>> Tested on x86_64-unknown-linux-gnu, OK for trunk and GCC 11 branch?
With which offloading targets? ;-)
>> 2021-04-21 Richard Biener <rguent...@suse.de>
>>
>> libgomp/
>> * testsuite/libgomp.c-c++-common/reduction-16.c: Use -latomic
>> only on nvptx-none.
>
> OK
Actually, NACK. ;-|
-/* { dg-additional-options "-foffload=-latomic" { target
offload_target_nvptx } } */
+/* { dg-additional-options "-foffload=nvptx-none=-latomic" { target
offload_target_nvptx } } */
The original options meant that code for *all* offloading targets is
generated. (... passing '-latomic' to all of them, which is problematic
indeed.)
The new options now mean that code *only* for nvptx offloading is
generated (..., passing '-latomic' to that one), but no other offloading
code is generated anymore; see the 'diff' of 'gcc -v':
[...]
Reading specs from [...]
COLLECT_GCC=[...]
COLLECT_LTO_WRAPPER=[...]
-OFFLOAD_TARGET_NAMES=amdgcn-amdhsa:nvptx-none:x86_64-intelmicemul-linux-gnu
+OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
[...]
Etc.
Thus (presumably) host-fallback execution when running this on a
non-Nvidia GPU system (so not noticeable by default, but also not testing
what is meant to be tested here).
So we need a different solution.
I certainly do agree that the '-foffload' interface is clunky,
overloaded.
Grüße
Thomas
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
