| View previous topic :: View next topic |
| Author |
Message |
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
 Posted: Thu Feb 13, 2025 4:38 pm Post subject: Sycl |
 |
|
Hello everyone,
in this thread I recall my attempts trying SYCL. The base system is a gentoo machine, up to date. This is also a sequel of a different thread (https://forums.gentoo.org/viewtopic-t-1172966.html).
In order to play around with SYCL (https://link.springer.com/book/10.1007/978-1-4842-9691-2) I tried the Intel software.
SYCL is written in terms of C++17, so the compilation can be done by different compilers. The problem is the linker, because at some point the kernels have to be generated.
A long story short: to compile SYCL programs, special tools are needed. I tried two of them:
1- The intel DPC++ compiler (https://www.intel.com/content/www/us/en/developer/tools/oneapi/dpc-compiler.html#gs.kbdt89)
2- The community tool, with the same name (https://github.com/intel/llvm#oneapi-data-parallel-c-compiler)
Option #1 is very easy to try. Just download and install. I did install it as a non root, so a new directory was created in my user space (~/intel/oneapi).
Inside that directory there was a convenient script that I sourced to set the environment variables (setvars.sh).
Intel has a website with the requirements: https://www.intel.com/content/www/us/en/developer/articles/system-requirements/intel-oneapi-base-toolkit-system-requirements.html , which does not include Gentoo.
The problem was when I tried to compile a first example, adapted from the book (the first reference to SYCL above):
| Code: | #include <iostream>
#include <string>
#include <sycl/sycl.hpp>
const std::string secret{"Ifmmp-!xpsme\"\012J(n!tpssz-!Ebwf/!"
"J(n!bgsbje!J!dbo(u!ep!uibu/!.!IBM\01"
};
const auto sz = secret.size();
int main( void )
{
sycl::queue q;
char* result = sycl::malloc_shared< char >( sz, q );
std::memcpy( result, secret.data(), sz );
q.parallel_for( sz, [=]( auto& i ) { result[i] -= 1; } ).wait();
std::cout << result << '\n';
sycl::free( result, q );
return 0;
} |
The command line to compile was very simple:
# icpx -fsycl hello.cpp -o hello
And I got an error message:
| Code: | In file included from hello.cpp:1:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/iostream:41:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/ostream:40:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/ios:40:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/iosfwd:42:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/postypes.h:40:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/cwchar:44:
In file included from /usr/include/wchar.h:30:
/usr/include/bits/floatn.h:79:52: error: unsupported machine mode '__TC__'
79 | typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
| ^
1 error generated. |
I opened a ticket in the Intel forum (https://community.intel.com/t5/Intel-oneAPI-DPC-C-Compiler/Compilation-error/m-p/1665330#M4299) and I was reminded that there are requirements.
The answer I've got, mentioned g++13, so I tried that one also (emerged sys-devel/gcc:13 and gcc-config to swith to it). The error message is very similar, essentially with a 13 inplace of the 14. I reverted gcc-config to point to gcc14 right after this experiment.
If I use icpx to compile a non SYCL program, then it appears to work ok. I did not test extensively, just a hello world. It also executes ok. So it seems to be the case that g++ is being used in the background when SYCL code has to be generated.
Then I decided to try option #2. It is not difficult, but requires some patience cloning the whole source code.
I created the workspace directory as told, and executed the python scripts to configure (python $DPCPP_HOME/llvm/buildbot/configure.py) and compile (python $DPCPP_HOME/llvm/buildbot/compile.py).
Configuring went ok (it checks out a number of additional sources), but the compilation failed, and the error message is:
| Code: | [16/78] Generating ../../lib/libsycl-fallback-complex.bc
FAILED: lib/libsycl-fallback-complex.bc /home/pablo/Dokumente/Lernen/C++/SYCL/DPCPP_HOME/llvm/build/lib/libsycl-fallback-complex.bc
cd /home/pablo/Dokumente/Lernen/C++/SYCL/DPCPP_HOME/llvm/build/tools/libdevice && /home/pablo/Dokumente/Lernen/C++/SYCL/DPCPP_HOME/llvm/build/bin/clang-20 -I /home/pablo/Dokumente/Lernen/C++/SYCL/DPCPP_HOME/llvm/build/include -Wno
In file included from /home/pablo/Dokumente/Lernen/C++/SYCL/DPCPP_HOME/llvm/libdevice/fallback-complex.cpp:12:
In file included from /home/pablo/Dokumente/Lernen/C++/SYCL/DPCPP_HOME/llvm/build/bin/../include/sycl/stl_wrappers/cmath:7:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/cmath:47:
In file included from /usr/include/math.h:43:
/usr/include/bits/floatn.h:79:52: error: unsupported machine mode '__TC__'
79 | typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
| ^
1 error generated. |
The error appears in several modules, I copied here it only once. I do not think that gcc13 will do any better here, but that is only my intuition, I did not try.
Right now I have no clue what to try. If someone has a hint, I'm all ears.
Of course I can provide more information if it can be useful.
Thank you in advance!
_________________
p. |
|
| Back to top |
|
 |
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2737
|
| Posted: Thu Feb 13, 2025 4:54 pm Post subject: Re: Sycl |
|
|
| pstickar wrote: |
| Code: |
In file included from /usr/include/math.h:43:
/usr/include/bits/floatn.h:79:52: error: unsupported machine mode '__TC__'
79 | typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
| ^
1 error generated. |
|
I think it's including the wrong headers in both cases. This ticket mentions something about environment variables, see if you can figure out something from their comments: https://github.com/arduino/Arduino/issues/7997
Best Regards,
Georgi |
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2737
|
| Posted: Thu Feb 13, 2025 6:21 pm Post subject: |
|
|
The fact that the bug is new doesn't make it more relevant. Don't give it much hope, instead work out how to make sure you're using the headers from the user installation and not the system headers. However I can't help you with that and I don't have the time to dig into it for you.
Best Regards,
Georgi |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1822
Location: South America
|
| Posted: Thu Feb 13, 2025 7:33 pm Post subject: |
|
|
There's a setup procedure before using the oneAPI DPC++/C++ compiler, apparently. Have you followed it?
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
| Posted: Fri Feb 14, 2025 10:11 am Post subject: |
|
|
| GDH-gentoo wrote: | | There's a setup procedure before using the oneAPI DPC++/C++ compiler, apparently. Have you followed it? |
Yes, I did. Otherwise the command line looks very different.
_________________
p. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1822
Location: South America
|
| Posted: Fri Feb 14, 2025 3:26 pm Post subject: |
|
|
Alright. What's the result of g++ -c test.cpp and icpx -c test.cpp for this source file?
test.cpp
| Code: | #include <bits/floatn.h>
__CFLOAT128 x;
int main() {
static_cast<void>(x);
return 0;
} |
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
| Posted: Sat Feb 15, 2025 2:42 pm Post subject: |
|
|
Both g++ and icpx compile that code without warnings or errors. It executes ok in both cases.
The result is different if we add the compilation flag for SYCL:
icpx -o test test.cpp -fsycl gives the error:
| Code: | In file included from test.cpp:2:
/usr/include/bits/floatn.h:79:52: error: unsupported machine mode '__TC__'
79 | typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
| ^
1 error generated. |
That flag is esential to activate the SYCL features.
The results are the same if I force icpx to look for include files in /usr/include (with the compilation flag -B/usr/include).
In my opinion, the icpx compiler has been using the same include files as g++ does, but it throws an error when SYCL output is desired.
_________________
p. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23121
|
| Posted: Sat Feb 15, 2025 3:25 pm Post subject: |
|
|
As I read that header, this block is guarded by: | /usr/include/bits/floatn.h: | /* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1. */
# if __HAVE_FLOAT128
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
/* Add a typedef for older GCC compilers which don't natively support
_Complex _Float128. */
typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
|
Assuming that __GNUC_PREREQ works as its usage suggests[1], this says you're using a compiler that is gcc older than 7.0, or is g++ older than 13.0. If not, then this guard would be false, and you would not process that typedef at all. Incidentally, clang is a compiler that is gcc older than 7.0[2]. This suggests that clang either needs to accept this mode, or stop claiming to be so old that the typedef is judged necessary.
[1]: __GNUC_PREREQ does: | /usr/include/features.h: | /* Convenience macro to test the version of gcc.
Use like this:
#if __GNUC_PREREQ (2,8)
... code requiring gcc 2.8 or later ...
#endif
Note: only works for GCC 2.0 and later, because __GNUC_MINOR__ was
added in 2.0. */
#if defined __GNUC__ && defined __GNUC_MINOR__
# define __GNUC_PREREQ(maj, min) \
((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
#else
# define __GNUC_PREREQ(maj, min) 0
#endif
|
[2]: | Code: | $ for cc in clang-18 g++-13 g++-14; do $cc --version; printf '#include <features.h>\ngcc versions\n%s versions = __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__ -> __GNUC_PREREQ(7, 0) / __GNUC_PREREQ(13, 0)\n' "$cc" | $cc -E -o - -x c++ -|sed -n -e '1,/gcc versions/d' -e '/^ *$/d' -e p; done
clang version 18.1.8
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/18/bin
Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg
clang-18 versions = 4 2 1 -> ((4 << 16) + 2 >= ((7) << 16) + (0)) / ((4 << 16) + 2 >= ((13) << 16) + (0))
g++-13 (Gentoo Hardened 13.3.1_p20241025 p1) 13.3.1 20241024
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g++-13 versions = 13 3 1 ->
# 3 "<stdin>" 3 4
((13 << 16) + 3 >= ((
# 3 "<stdin>"
7
# 3 "<stdin>" 3 4
) << 16) + (
# 3 "<stdin>"
0
# 3 "<stdin>" 3 4
))
# 3 "<stdin>"
/
# 3 "<stdin>" 3 4
((13 << 16) + 3 >= ((
# 3 "<stdin>"
13
# 3 "<stdin>" 3 4
) << 16) + (
# 3 "<stdin>"
0
# 3 "<stdin>" 3 4
))
g++-14 (Gentoo Hardened 14.2.1_p20241221 p7) 14.2.1 20241221
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g++-14 versions = 14 2 1 ->
# 3 "<stdin>" 3 4
((14 << 16) + 2 >= ((
# 3 "<stdin>"
7
# 3 "<stdin>" 3 4
) << 16) + (
# 3 "<stdin>"
0
# 3 "<stdin>" 3 4
))
# 3 "<stdin>"
/
# 3 "<stdin>" 3 4
((14 << 16) + 2 >= ((
# 3 "<stdin>"
13
# 3 "<stdin>" 3 4
) << 16) + (
# 3 "<stdin>"
0
# 3 "<stdin>" 3 4
))
|
|
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
| Posted: Sat Feb 15, 2025 3:59 pm Post subject: |
|
|
In my system I get (using icpx in place of clang-18, but otherwise the same command line as Hu above):
| Code: | $ for cc in icpx g++-14; do $cc --version; printf '#include <features.h>\ngcc versions\n%s versions = __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__ -> __GNUC_PREREQ(7, 0) / __GNUC_PREREQ(13, 0)\n' "$cc" | $cc -E -o - -x c++ -|sed -n -e '1,/gcc versions/d' -e '/^ *$/d' -e p; done
Intel(R) oneAPI DPC++/C++ Compiler 2025.0.4 (2025.0.4.20241205)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/pablo/intel/oneapi/compiler/2025.0/bin/compiler
Configuration file: /home/pablo/intel/oneapi/compiler/2025.0/bin/compiler/../icpx.cfg
icpx versions = 4 2 1 -> ((4 << 16) + 2 >= ((7) << 16) + (0)) / ((4 << 16) + 2 >= ((13) << 16) + (0))
g++-14 (Gentoo 14.2.1_p20241221 p6) 14.2.1 20241221
Copyright (C) 2024 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
g++-14 versions = 14 2 1 ->
# 3 "<stdin>" 3 4
((14 << 16) + 2 >= ((
# 3 "<stdin>"
7
# 3 "<stdin>" 3 4
) << 16) + (
# 3 "<stdin>"
0
# 3 "<stdin>" 3 4
))
# 3 "<stdin>"
/
# 3 "<stdin>" 3 4
((14 << 16) + 2 >= ((
# 3 "<stdin>"
13
# 3 "<stdin>" 3 4
) << 16) + (
# 3 "<stdin>"
0
# 3 "<stdin>" 3 4
)) |
_________________
p. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2159
|
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1822
Location: South America
|
| Posted: Sat Feb 15, 2025 4:59 pm Post subject: |
|
|
I don't know why if Clang and the oneAPI DPC++/C++ compiler claim to be GCC 4.2.1, macro __HAVE_FLOAT128 gets defined in floatn.h, and, more importantly, if icpx will choke on type _Float128 (128-bit floating point) —or C 1999-style complex number types— when compiling SYCL input. Anyway, more tests:
1) Output of echo __x86_64__ __GNUC__ __GNUC_MINOR__ | icpx -E -?
2) Output of echo __x86_64__ __GNUC__ __GNUC_MINOR__ | icpx -fsycl -E -?
3) Result of compiling the test program with icpx -c -fgnuc-version=13.0.0 and icpx -c -fsycl -fgnuc-version=13.0.0? (I suppose that's the correct syntax)
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
| Posted: Sat Feb 15, 2025 5:38 pm Post subject: |
|
|
1) echo __x86_64__ __GNUC__ __GNUC_MINOR__ | icpx -E -
| Code: | # 1 "<stdin>"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 402 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "<stdin>" 2
1 4 2 |
2) echo __x86_64__ __GNUC__ __GNUC_MINOR__ | icpx -fsycl -E -
| Code: | // __CLANG_OFFLOAD_BUNDLE____START__ sycl-spir64-unknown-unknown
# 1 "<stdin>"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 784 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "<stdin>" 2
1 4 2
// __CLANG_OFFLOAD_BUNDLE____END__ sycl-spir64-unknown-unknown
// __CLANG_OFFLOAD_BUNDLE____START__ host-x86_64-unknown-linux-gnu
# 1 "<stdin>"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 407 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/tmp/icpx-0574af402e/--header-abff00.h" 1
# 2 "<built-in>" 2
# 1 "<stdin>" 2
# 1 "/tmp/icpx-0574af402e/--footer-484e78.h" 1
# 1 "<stdin>" 2 |
3a) icpx -c -fgnuc-version=13.0.0 test.cpp
Generated test.o. No error, no warning.
3b) icpx -c -fgnuc-version=13.0.0 -fsycl test.cpp
| Code: | In file included from test.cpp:2:
/usr/include/bits/floatn.h:79:52: error: unsupported machine mode '__TC__'
79 | typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
| ^
1 error generated. |
After the installation of icpx, there is a man page for it. The option -fgnuc-version does not appear in that manual.
_________________
p. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1822
Location: South America
|
| Posted: Sat Feb 15, 2025 5:53 pm Post subject: |
|
|
| pstickar wrote: | | The option -fgnuc-version does not appear in that manual. |
It is a Clang option, and the note here says icpx supports them (I believe it's basically a modified Clang).
OK, let's try being explicit and see if there's some hope:
| Code: | _Float128 _Complex x;
int main() {
static_cast<void>(x);
return 0;
} |
Does icpx -c -fsycl accept this input?
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
| Posted: Sat Feb 15, 2025 6:02 pm Post subject: |
|
|
Nope. It is not accepted:
icpx test1.cpp -fsycl
gives
| Code: | test1.cpp:1:1: error: unknown type name '_Float128'
1 | _Float128 _Complex x;
| ^
1 error generated. |
Leaving out the option -fsycl does not change anything.
If I reorder the first sentence (_Complex _Float128 instead of _Float128 _Complex), then the error message is different:
| Code: | test1.cpp:1:1: warning: plain '_Complex' requires a type specifier; assuming '_Complex double'
1 | _Complex _Float128 x;
| ^
| double
test1.cpp:1:19: error: expected ';' after top level declarator
1 | _Complex _Float128 x;
| ^
| ;
test1.cpp:5:21: error: use of undeclared identifier 'x'
5 | static_cast<void>(x);
| ^
1 warning and 2 errors generated. |
_________________
p. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1822
Location: South America
|
| Posted: Sat Feb 15, 2025 7:08 pm Post subject: |
|
|
I see. So, when using Intel's oneAPI DPC++/C++ compiler, one can specify a C 1999-style complex type in SYCL input, but apparently there's no way of specifying a 128-bit floating point type. Neither as _Float128, nor with the GCC mode(TC) attribute. So, when using GCC's implementation of the C++ standard library, none of the two definitions of __CFLOAT128 in /usr/include/bits/floatn.h will work.
In fact, it looks like __CFLOAT128 should not be defined at all when processing the file with icpx, but the logic for defining __HAVE_FLOAT128 somehow yields a false positive:
amd64 /usr/include/bits/floatn.h - GNU libc 2.40
| Code: | /* Defined to 1 if the current compiler invocation provides a
floating-point type with the IEEE 754 binary128 format, and this
glibc includes corresponding *f128 interfaces for it. The required
libgcc support was added some time after the basic compiler
support, for x86_64 and x86. */
#if (defined __x86_64__ \
? __GNUC_PREREQ (4, 3) \
: (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4)))
# define __HAVE_FLOAT128 1
#else
# define __HAVE_FLOAT128 0
#endif |
| Code: | /* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1. */
# if __HAVE_FLOAT128
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
/* Add a typedef for older GCC compilers which don't natively support
_Complex _Float128. */
typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
# define __CFLOAT128 __cfloat128
# else
# define __CFLOAT128 _Complex _Float128
# endif
# endif |
So, every SYCL source file that includes a standard C++ header that, with GCC's implementation, ends up indirectly including /usr/include/bits/floatn.h —such as <iostream>— is not going to compile.
I guess we have to label this an incompatibility between the oneAPI DPC++/C++ compiler and the GNU libc, and see what happens with issue 16903...
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
Last edited by GDH-gentoo on Sat Feb 15, 2025 7:31 pm; edited 1 time in total |
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
| Posted: Sat Feb 15, 2025 7:31 pm Post subject: |
|
|
| GDH-gentoo wrote: | | I guess we have to label this an incompatibility between the oneAPI DPC++/C++ compiler and the GNU libc, and see what happens with issue 16903... |
Yet another possibility would be to downgrade glibc to 2.40, as people are suggesting (e.g. https://github.com/ggerganov/whisper.cpp/issues/2803). I'm reluctant.
On the other hand, I'm not sure the issue 16903 will be dealt with soon. It looks like most developers are working on platforms (Ubuntu...) that do not yet have the problem.
I will shelf my experiments with SYCL and come back when there is a solution for this issue.
_________________
p. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1822
Location: South America
|
| Posted: Sat Feb 15, 2025 7:36 pm Post subject: |
|
|
2.40 is current Gentoo stable and has this definition already. You'd have to go back to 2.25 (early 2017) to get a wchar.h that doesn't indirectly include <bits/floatn.h>
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2737
|
| Posted: Sat Feb 15, 2025 7:54 pm Post subject: |
|
|
| pstickar wrote: | | GDH-gentoo wrote: | | I guess we have to label this an incompatibility between the oneAPI DPC++/C++ compiler and the GNU libc, and see what happens with issue 16903... |
Yet another possibility would be to downgrade glibc to 2.40 |
Downgrading glibc is unsupported and will break your system.
Best Regards,
Georgi |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2159
|
| Posted: Sat Feb 15, 2025 8:32 pm Post subject: |
|
|
| Did you see the bug I linked? It would be better to just quickly patch the header. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1822
Location: South America
|
| Posted: Sat Feb 15, 2025 10:22 pm Post subject: |
|
|
| sam_ wrote: | | Did you see the bug I linked? It would be better to just quickly patch the header. |
Do you believe it'll help? According to the tests shown, icpx seems to have no problem with the header as-is without -fsycl, i. e. when treating input as 'ordinary' C++ instead of SYCL.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23121
|
| Posted: Sat Feb 15, 2025 10:28 pm Post subject: |
|
|
| Whether or not it helps, it's an easy enough test to try. If it doesn't help, that will be interesting. If it does help, then that suggests a change that the Gentoo maintainers may want to apply more widely. |
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
| Posted: Sun Feb 16, 2025 8:49 am Post subject: |
|
|
Changing __glibc_clang_prereq (3, 4) to __glibc_clang_prereq (3, 9) in /usr/include/bits/floatn.h (exactly two changes) does not fix the problem. The error message stays the same.
_________________
p. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1822
Location: South America
|
| Posted: Sun Feb 16, 2025 5:43 pm Post subject: |
|
|
Wait. I didn't realize that you had version 2.41 installed (are you on the Gentoo testing branch?). No wonder why I couldn't understand how __HAVE_FLOAT128 seemed to get defined as 1.
Try commenting the first call to __glibc_clang_prereq() instead, so that the condition looks like in version 2.40:
| Code: | #if (defined __x86_64__ \
? __GNUC_PREREQ (4, 3) \
: (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4))) /*\
|| __glibc_clang_prereq (3, 4) */
# define __HAVE_FLOAT128 1
#else
# define __HAVE_FLOAT128 0
#endif |
(note the /* and */)
and try compiling the first test program again with -fsycl. If you get somenting like "error: unknown type name '__CFLOAT128'", try next with a real SYCL example program.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pstickar
Tux's lil' helper
Joined: 26 Nov 2006
Posts: 78
Location: Germany
|
| Posted: Sun Feb 16, 2025 8:07 pm Post subject: |
|
|
That works.
After the modification, the error compiling the first test.cpp program is indeed
| Code: | test.cpp:4:1: error: unknown type name '__CFLOAT128'
4 | __CFLOAT128 x;
| ^
1 error generated. |
and a real SYCL program compiles now (and executes ok as well).
Yes, I'm in the testing branch.
_________________
p. |
|
| Back to top |
|
|
|
Unsupported Software
