[llvm-bugs] [Bug 48070] New: User-defined float literal broken with device nvptx64-nvidia-
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Nov 4 03:47:16 PST 2020
https://bugs.llvm.org/show_bug.cgi?id=48070
Bug ID: 48070
Summary: User-defined float literal broken with device
nvptx64-nvidia-
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenMP
Assignee: unassignedclangbugs at nondot.org
Reporter: gcc.j.kelling at hzdr.de
CC: llvm-bugs at lists.llvm.org
Created attachment 24132
--> https://bugs.llvm.org/attachment.cgi?id=24132&action=edit
minimal reproducer
The attached example, defining a user-defined float literal type and using it
in an OpenMP target region is valid and compiles for x86_64, using
```
clang++ -fopenmp -fopenmp=libomp -fopenmp-targets=x86_64-pc-linux-gnu
literal.cpp
```
It does does not compile with
```
clang++ -fopenmp -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda
literal.cpp
```
failing with the message:
```
../literal/literal.cpp:14:11: error: 'operator""_X' requires 128 bit size 'long
double' type support, but device 'nvptx64-nvidia-cuda' does not support it
a += 1._X;
^
../literal/literal.cpp:1:18: note: 'operator""_X' defined here
constexpr double operator"" _X (long double a)
^
```
Expected behavior: The long double argument type of the literal operator is a
literal and does live at runtime, only the return value enters runtime as a
constant, thus device support for long double by the target architecture is not
needed.
Also note, that such literals for floats can only be defined using long double,
raising the following error when, e.g., using double instead:
```
literal.cpp:1:33: error: invalid literal operator parameter type 'double', did
you mean 'long double'?
constexpr double operator"" _X (double a)
^~~~~~~~
```
Thus, allowing target architecture restriction enter compile time here, would
make support for user-defined literals in target regions impossible.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201104/9979f1b3/attachment.html>
More information about the llvm-bugs
mailing list