Hi Jonathan, the respective outputs of g++ -v using the aforementioned g++ compiler are as follows: on my personal machine where bf16 works: " marc@marc-ThinkPad-T490s:~$ g++-13 -v Using built-in specs. COLLECT_GCC=g++-13 COLLECT_LTO_WRAPPER=/home/marc/install/gcc-13/libexec/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./../gcc-source/configure --prefix=/home/marc/install/gcc-13 --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.1 20230727 (GCC) " On the cluster where I installed it from source: " Using built-in specs. COLLECT_GCC=g++-13 COLLECT_LTO_WRAPPER=/dss/dsshome1/lxc03/ga65jeg2/gcc_install/libexec/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./../git_gcc-13-source/configure --prefix=/dss/dsshome1/lxc03/ga65jeg2/gcc_install --enable-languages=c,c++ --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.1 20230802 (GCC) " On the cluster where it came installed as a module: " Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/cosma/local/gcc/13.1.0/libexec/gcc/x86_64-pc-linux-gnu/13.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --prefix=/cosma/local/gcc/13.1.0/ --enable-languages=c,c++,fortran,go --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.1.0 (GCC) " the main difference I see is that multilib was disabled on both of the clusters. Where i have done this the multilib features were causing compile errors and I thought I would not need 32-bit libraries anyway. Note that "COLLECT_GCC=g++-13" is simply because I use an alias to differentiate the default installation of g++ from my from-source installation, it gives the same output and the same results if I call it with g++ or execute the executable directly. Best, Marc M-L ________________________________ From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx> Sent: 06 August 2023 21:28:29 To: Marc Marot-Lassauzaie Cc: gcc-help@xxxxxxxxxxx Subject: Re: g++13 fixed-width floating point implementations On Sun, 6 Aug 2023 at 18:30, Marc Marot-Lassauzaie via Gcc-help <gcc-help@xxxxxxxxxxx> wrote: > > Hello, > > > my name is Marc Marot-Lassauzaie, I have recently been using g++13 in order to use the 16-bit floating point formats bf16 and fp16 but unfortunately these aren't defined on some of the machines I've been working on and I'd like to know why that is and whether there is any possibility of resolving this. > > Specifically, I have three machines that I've been working on: one is my personal work laptop and the other two are HPC-Clusters that I've been accessing for work purposes. On my personal machine as well as one of the clusters I've installed g++13.2 from source, on the other cluster g++13.1 comes installed as a module. On my machine all of the std::floatxx_t formats are defined and available via the "stdfloat"<https://en.cppreference.com/w/cpp/header/stdfloat> header and all of their corresponding predefined macros are defined. On both of the clusters neither of these are true. > > The C-language type "_Float16" is available for all three machines, meaning I can make use of fp16 but I couldn't find any way to make bf16 work on either of the clusters. > > > My best guess is that the hardware of the clusters somehow doesn't support these types but all three machines have the same microarchitecture, running the command "uname -m" returns the value "x86_64" for all three. I have found on the changelog of the gcc 13 release series<https://gcc.gnu.org/gcc-13/changes.html> that the __bf16 type is supported only if SSE2 and above are enabled, which I assume is related to this issue. > > Could you let me know based on which criteria g++13 activates or deactivates this feature, whether there is any way to make it available anyway (even if this involves emulation) or whether there is any other way of using bf16-floating types for C++? The type is enabled whenever SSE2 support is enabled and when using -std=c++23 or -std=gnu++23. > Please let me know if anything is unclear or if you have any additional questions. The uname -m output is not useful, nearly all x86 chips produced in the past 20 years are "x86_64". What does 'gcc -v' show for your GCC 13 on each machine? What does 'gcc -Q --help=target | grep sse2' show for your GCC 13? All x86_64 processors should support SSE2, so the only reason I can think of that bfloat16 wouldn't be enabled is that either you're not using C++23 mode, or you're compiling for 32-bit mode with -m32 and not telling GCC to compile for a processor with SSE2 support (e.g. by using something like -m32 -march=x86-64 or -m32 -msse2).
