Strange errors after system gcc upgraded to 13.1.1

Dear all!

I’m having an OpenACC project that compiles fine in the past. However, after a system upgrade (Arch Linux, gcc upgraded to 13.1.1), my project was broken.

The project compiles fine with GCC on CPU only.

The error persists no matter what c++ standard I use (tried default, c++11 c++14 and c++17).

Could someone please take a look and tell me is there anything wrong with my project or I should just downgrade my compiler?

Really appreciate your help!

The error messages I received:

[lisanhu@lisanhu-xps-15 build]$ cmake ../
-- The C compiler identification is NVHPC 23.3.0
-- The CXX compiler identification is NVHPC 23.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/lisanhu/mine/program/nvhpc/Linux_x86_64/23.3/compilers/bin/nvc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/lisanhu/mine/program/nvhpc/Linux_x86_64/23.3/compilers/bin/nvc++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.8s)
-- Generating done (0.0s)
-- Build files have been written to: /home/lisanhu/mine/workspace/cmdb2/build
[lisanhu@lisanhu-xps-15 build]$ make foo-gpu
/usr/bin/cmake -S/home/lisanhu/mine/workspace/cmdb2 -B/home/lisanhu/mine/workspace/cmdb2/build --check-build-system CMakeFiles/Makefile.cmake 0
make  -f CMakeFiles/Makefile2 foo-gpu
make[1]: Entering directory '/home/lisanhu/mine/workspace/cmdb2/build'
/usr/bin/cmake -S/home/lisanhu/mine/workspace/cmdb2 -B/home/lisanhu/mine/workspace/cmdb2/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/lisanhu/mine/workspace/cmdb2/build/CMakeFiles 2
make  -f CMakeFiles/Makefile2 CMakeFiles/foo-gpu.dir/all
make[2]: Entering directory '/home/lisanhu/mine/workspace/cmdb2/build'
make  -f CMakeFiles/foo-gpu.dir/build.make CMakeFiles/foo-gpu.dir/depend
make[3]: Entering directory '/home/lisanhu/mine/workspace/cmdb2/build'
cd /home/lisanhu/mine/workspace/cmdb2/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/lisanhu/mine/workspace/cmdb2 /home/lisanhu/mine/workspace/cmdb2 /home/lisanhu/mine/workspace/cmdb2/build /home/lisanhu/mine/workspace/cmdb2/build /home/lisanhu/mine/workspace/cmdb2/build/CMakeFiles/foo-gpu.dir/DependInfo.cmake --color=
make[3]: Leaving directory '/home/lisanhu/mine/workspace/cmdb2/build'
make  -f CMakeFiles/foo-gpu.dir/build.make CMakeFiles/foo-gpu.dir/build
make[3]: Entering directory '/home/lisanhu/mine/workspace/cmdb2/build'
[ 50%] Building CXX object CMakeFiles/foo-gpu.dir/bindings.cc.o
/home/lisanhu/mine/program/nvhpc/Linux_x86_64/23.3/compilers/bin/nvc++   -O2 -gopt --c++17 --gnu_extensions -MD -MT CMakeFiles/foo-gpu.dir/bindings.cc.o -MF CMakeFiles/foo-gpu.dir/bindings.cc.o.d -o CMakeFiles/foo-gpu.dir/bindings.cc.o -c /home/lisanhu/mine/workspace/cmdb2/bindings.cc
"/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/type_traits", line 3363: error: type name is not allowed
    inline constexpr bool is_convertible_v = __is_convertible(_From, _To);
                                                              ^

"/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/type_traits", line 3363: error: type name is not allowed
    inline constexpr bool is_convertible_v = __is_convertible(_From, _To);
                                                                     ^

"/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/type_traits", line 3363: error: identifier "__is_convertible" is undefined
    inline constexpr bool is_convertible_v = __is_convertible(_From, _To);
                                             ^

"/usr/include/stdlib.h", line 141: error: identifier "_Float32" is undefined
  extern _Float32 strtof32 (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 147: error: identifier "_Float64" is undefined
  extern _Float64 strtof64 (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 153: error: identifier "_Float128" is undefined
  extern _Float128 strtof128 (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 159: error: identifier "_Float32x" is undefined
  extern _Float32x strtof32x (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 165: error: identifier "_Float64x" is undefined
  extern _Float64x strtof64x (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 234: error: identifier "_Float32" is undefined
                       _Float32 __f)
                       ^

"/usr/include/stdlib.h", line 240: error: identifier "_Float64" is undefined
                       _Float64 __f)
                       ^

"/usr/include/stdlib.h", line 246: error: identifier "_Float128" is undefined
                        _Float128 __f)
                        ^

"/usr/include/stdlib.h", line 252: error: identifier "_Float32x" is undefined
                        _Float32x __f)
                        ^

"/usr/include/stdlib.h", line 258: error: identifier "_Float64x" is undefined
                        _Float64x __f)
                        ^

"/usr/include/stdlib.h", line 317: error: identifier "_Float32" is undefined
  extern _Float32 strtof32_l (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 324: error: identifier "_Float64" is undefined
  extern _Float64 strtof64_l (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 331: error: identifier "_Float128" is undefined
  extern _Float128 strtof128_l (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 338: error: identifier "_Float32x" is undefined
  extern _Float32x strtof32x_l (const char *__restrict __nptr,
         ^

"/usr/include/stdlib.h", line 345: error: identifier "_Float64x" is undefined
  extern _Float64x strtof64x_l (const char *__restrict __nptr,
         ^

18 errors detected in the compilation of "/home/lisanhu/mine/workspace/cmdb2/bindings.cc".
make[3]: *** [CMakeFiles/foo-gpu.dir/build.make:79: CMakeFiles/foo-gpu.dir/bindings.cc.o] Error 2
make[3]: Leaving directory '/home/lisanhu/mine/workspace/cmdb2/build'
make[2]: *** [CMakeFiles/Makefile2:88: CMakeFiles/foo-gpu.dir/all] Error 2
make[2]: Leaving directory '/home/lisanhu/mine/workspace/cmdb2/build'
make[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/foo-gpu.dir/rule] Error 2
make[1]: Leaving directory '/home/lisanhu/mine/workspace/cmdb2/build'
make: *** [Makefile:172: foo-gpu] Error 2

Hi Sanhu_Li,

Not too surprising that there are issues given GNU 13.1 just came out and we haven’t been able to adjust to their changes. In order to be object compatible with g++, we need to use the GNU STL.

As for the error, I can recreate it with just including “iostream”:

% cat test.cpp
#include <iostream>
% nvc++ -c --gcc-toolchain=/home/sw/thirdparty/gcc/gcc-13.1.0/Linux_x86_64/ test.cpp "/home/sw/thirdparty/gcc/gcc-13.1.0/Linux_x86_64/lib/gcc/x86_64-pc-linux-gnu/13.1.0/../../../../include/c++/13.1.0/type_traits", line 3363: error: type name is not allowed
    inline constexpr bool is_convertible_v = __is_convertible(_From, _To);
                                                              ^

"/home/sw/thirdparty/gcc/gcc-13.1.0/Linux_x86_64/lib/gcc/x86_64-pc-linux-gnu/13.1.0/../../../../include/c++/13.1.0/type_traits", line 3363: error: type name is not allowed
    inline constexpr bool is_convertible_v = __is_convertible(_From, _To);
                                                                     ^

"/home/sw/thirdparty/gcc/gcc-13.1.0/Linux_x86_64/lib/gcc/x86_64-pc-linux-gnu/13.1.0/../../../../include/c++/13.1.0/type_traits", line 3363: error: identifier "__is_convertible" is undefined
    inline constexpr bool is_convertible_v = __is_convertible(_From, _To);
                                             ^

3 errors detected in the compilation of "test.cpp".
% nvc++ -c --gcc-toolchain=/home/sw/thirdparty/gcc/gcc-13.1.0/Linux_x86_64/ test.cpp --std=c++14
%

However for me, it appears to be limited to C++17. Setting “–std=c++14” works around the issue.

How are you setting the language version?

Can you please provide an example where it still fails with C++14?

Thanks,
Mat

Hi Mat!

Thank you so much for your help!
cmdb2-main.zip (764.1 KB)

Our project is currently private, but I can send you an archive to test it out (since it’s far from done).

The project is having some Rust code and some C/C++ code. In order to test, you just need to create a build folder at the root and cmake ../ and finally make.

In CMakeLists.txt, there’s a commented out line that can set up the CXX versions.

I think my code fails because it contains #include <algorithm>, but I’m not sure about this.

I don’t have the Arch Linux system at my hand right now, and I couldn’t test it out. I’ll tell you more when I find a system with gcc-13.

Thank you so much for your quick reply!

FYI, here’s some info I got back from engineering:

__is_convertible is a built-in operator than is new in GCC 13. Because it is brand new, our front-end doesn’t support it yet.

There is also a bug in the <type_traits> header in GCC 13.1. There are two uses of __is_convertible in that header. One of them is protected by #if __has_builtin(__is_convertible), and has a fallback mechanism when __is_convertible is not available. The other use doesn’t have that check. That’s the one that triggers the failure in nvc++.

GCC 13.1 is pretty much unusable with NVC++ 23.3 and earlier, because lots of headers include <type_traits>. I think there is a simple workaround that we can make so that GCC 13.1 <type_traits> will work with future releases.

Thank you so much for the updates! I’m on Arch Linux and currently everything is unusable. I tried to installed gcc-12 via homebrew but it’s giving me the following errors:

[lisanhu@lisanhu-xps-15 build]$ cmake ../
-- The C compiler identification is NVHPC 23.3.0
-- The CXX compiler identification is NVHPC 23.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /home/lisanhu/mine/program/nvhpc/Linux_x86_64/23.3/compilers/bin/nvc
-- Check for working C compiler: /home/lisanhu/mine/program/nvhpc/Linux_x86_64/23.3/compilers/bin/nvc - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
  The C compiler

    "/home/lisanhu/mine/program/nvhpc/Linux_x86_64/23.3/compilers/bin/nvc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/lisanhu/mine/workspace/cmdb2/build/CMakeFiles/CMakeScratch/TryCompile-6b515Q
    
    Run Build Command(s):/usr/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_e80e5/fast && /usr/bin/make  -f CMakeFiles/cmTC_e80e5.dir/build.make CMakeFiles/cmTC_e80e5.dir/build
    make[1]: Entering directory '/home/lisanhu/mine/workspace/cmdb2/build/CMakeFiles/CMakeScratch/TryCompile-6b515Q'
    Building C object CMakeFiles/cmTC_e80e5.dir/testCCompiler.c.o
    /home/lisanhu/mine/program/nvhpc/Linux_x86_64/23.3/compilers/bin/nvc    -MD -MT CMakeFiles/cmTC_e80e5.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_e80e5.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_e80e5.dir/testCCompiler.c.o -c /home/lisanhu/mine/workspace/cmdb2/build/CMakeFiles/CMakeScratch/TryCompile-6b515Q/testCCompiler.c
    Linking C executable cmTC_e80e5
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_e80e5.dir/link.txt --verbose=1
    /home/lisanhu/mine/program/nvhpc/Linux_x86_64/23.3/compilers/bin/nvc CMakeFiles/cmTC_e80e5.dir/testCCompiler.c.o -o cmTC_e80e5 
    /usr/bin/ld: cannot find /home/linuxbrew/.linuxbrew/Cellar/gcc/crtbegin.o: No such file or directory
    make[1]: *** [CMakeFiles/cmTC_e80e5.dir/build.make:100: cmTC_e80e5] Error 2
    make[1]: Leaving directory '/home/lisanhu/mine/workspace/cmdb2/build/CMakeFiles/CMakeScratch/TryCompile-6b515Q'
    make: *** [Makefile:127: cmTC_e80e5/fast] Error 2
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:3 (project)


-- Configuring incomplete, errors occurred!

It seems cmake is looking at the wrong locations for crtbegin.o, after finding the file and setting the parent folder into $LIBRARY_PATH, I’m still having the same error messages.

Really appreciate your work and confirmation on this problem and I think I’ll re-install my OS with something not using gcc-13 right now for our code.

How did you configure NVHPC to use you homebrew GNU 12?

Did you edit the localrc file or use makelocalrc?

The location of the crt files is defined in the DEFSTDOBJDIR variable, which should point to a system directory not your homebrew. For example:

set DEFSTDOBJDIR=/usr/lib/x86_64-linux-gnu;

Not instead of editing the localrc file, you can use the “–gcc-toolchain=/path/to/base/gnu/install” instead.

1 Like

Thank you so much for your help, Mat!

For now, I have already re-installed the OS and I’m now on Fedora 38 (which also uses gcc-13.1, and I also installed a gcc-12 through homebrew). This time it’s working smoothly.

I have called makelocalrc previously on Arch. However, it’s still not able to find the crt files. I think the reason is Arch is storing those files in a special path which include compiler version ( somewhere in the path there’s a 13.1 ), and that’s something making some of my compiles fail. I wasn’t aware about the DEFSTDOBJDIR thing, but I think if I knew it, it should work. Thank you so much for your help! I’m really happy I’m learning new things.

EDIT: I saw the problem again, I fixed it by setting the line GCCDIR line to the system one in the localrc file. Sadly the DEFSTDOBJDIR doesn’t seem to work this time.

Thank you so much for all your efforts helping me! I really appreciate it!

Hi Mat! Just recently had the same issue. Any chance 23.5 will have a workaround for this? In any case, I solved it by loading a GCC/12.3.0 module then using the “–gcc-toolchain” flag pointing to the install path of said module. Leaving my reply here so others can try the same workaround.

Engineering is testing a work around for the type_traits issue which hopefully can be added to 23.5. No guarantees that other issue wont occur, but it should work around this one (assuming it makes it in the final release).

Hi Lucas, Sanhu_li,

The work around for the __is_convertible issue in GNU 13’s type_traits header was added to 23.5. You might encounter other issues as we’re still working on compatibility issues with this new GNU release, but hopefully this will get you further.

-Mat

Thank you so much for your help!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.