https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118520
Bug ID: 118520
Summary: compiles with clang on openmp target, but gcc fails to
compile with unresolved symbol
__cxa_throw_bad_array_new_length
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: schulz.benjamin at googlemail dot com
Target Milestone: ---
Created attachment 60179
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60179&action=edit
openmp offload test for simple pointer arithmetic
the attached file compiles with clang and runs on target, but
gcc -O3 -fopenmp -foffload=nvptx-none -fcf-protection=none
-fno-stack-protector -no-pie ./main.cpp -lm -lstdc++ -lrt
yields:
unresolved symbol __cxa_throw_bad_array_new_length
If it would run, its results would be rather interesting, since in clang the
running file shows rundime problems, when the lines that are commented out in
the source-code, are activated.
I have two devices, one gpu and one cpu, yet the omp device number (at least on
clang) is always 1. This confuses the target enter data and target exit data
commands of openmp. If i set them to work on device(1), they will, on clang
silently work on the host. If i run them on device(0), the mat(alloc: )
preprocessor directive will erase data on the host. But that is for clang.
For gcc, this small test file does not even compile...
I guess that is because there is a new command in a target region? or because
of whatever..., but well, i suspect that i have the c++ language available at
the target?
