Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build does not work with GCC 15+ #1139

Open
pinskia opened this issue Sep 6, 2024 · 8 comments
Open

Build does not work with GCC 15+ #1139

pinskia opened this issue Sep 6, 2024 · 8 comments

Comments

@pinskia
Copy link

pinskia commented Sep 6, 2024

With GCC 15, the build fails due to missing cstdint include. GCC 15 removed some extra includes in the standard headers and caused the issue. See https://gcc.gnu.org/gcc-15/porting_to.html for more information.

GCC 15 output:

In file included from ./src/common/cpuinfo/CpuModel.h:27,
                 from src/common/cpuinfo/CpuModel.cpp:24:
./arm_compute/core/CPP/CPPTypes.h:183:5: error: ‘uint64_t’ does not name a type
  183 |     uint64_t get_sme2_vector_length() const;
      |     ^~~~~~~~
./arm_compute/core/CPP/CPPTypes.h:30:1: note: ‘uint64_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
   29 | #include <memory>
  +++ |+#include <cstdint>
   30 |
@pinskia
Copy link
Author

pinskia commented Sep 6, 2024

Some more errors similar after fixing the above one:

In file included from src/runtime/Allocator.cpp:27:
./arm_compute/runtime/MemoryRegion.h:99:21: error: ‘uint8_t’ was not declared in this scope
   99 |     std::shared_ptr<uint8_t> _mem;
      |                     ^~~~~~~
./arm_compute/runtime/MemoryRegion.h:31:1: note: ‘uint8_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
   30 | #include <cstddef>
  +++ |+#include <cstdint>
   31 |

@morgolock
Copy link

Hi @pinskia

Could you please share these details?

  1. What is the full build command you are using?
  2. The output of g++ --version or the corresponding cross-compiler you are using

@pinskia
Copy link
Author

pinskia commented Sep 10, 2024

The version of GCC I am using:

[apinski@xeond2 upstream-cross-aarch64]$ ./install/bin/aarch64-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=./install/bin/aarch64-linux-gnu-g++
COLLECT_LTO_WRAPPER=/bajas/pinskia/src/upstream-cross-aarch64/install/bin/../libexec/gcc/aarch64-linux-gnu/15.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../configure --target=aarch64-linux-gnu --prefix=/home/apinski/src/upstream-cross-aarch64/install --enable-languages=c,c++,fortran --with-sysroot=/home/apinski/src/upstream-cross-aarch64/install/aarch64-linux-gnu/sysroot
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240903 (experimental) [trunk 4beaa1846dc] (GCC)

This was the trunk version as of last week. as I should have mention adding #include <cstdint> to the following files allowed me to do the testing I needed to do:

arm_compute/core/CPP/CPPTypes.h
arm_compute/runtime/MemoryRegion.h
tests/framework/instruments/hwc_names.hpp

The testing I needed to do was reduce a testcase for GCC where GCC had an internal compiler error due to -flto usage.

@morgolock
Copy link

Hi @pinskia

Could you please share the command used to compile the library ?

@jwakely
Copy link

jwakely commented Sep 11, 2024

It doesn't matter: your code is wrong. You need to include the relevant header before using those types. That's how C++ works. Maybe you've got away with it until now with some compilers, but the code is still wrong.

This is documented as a change that might be needed when using GCC 15: https://gcc.gnu.org/gcc-15/porting_to.html#header-dep-changes

But the bottom line is you need to include the right header for anything in the C++ standard library that you rely on.

@morgolock
Copy link

Hi @jwakely

Many thanks for raising this, we'll have a look at it and fix it

@morgolock
Copy link

Hi @pinskia

Since GCC15 has not yet been released I'm struggling to reproduce the problem. I'm building ACL main branch with GCC 15.0.0 20240514 (experimental) and I can't see the errors mentioned above.

~/ComputeLibrary$ //aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc --version -v
Using built-in specs.
COLLECT_AS_OPTIONS='--version'
COLLECT_GCC=/arm/pdtl/snapshots/fsf-trunk.3697/installed/rhe8x86_64/aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/arm/pdtl/snapshots/fsf-trunk.3697/installed/rhe8x86_64/aarch64-none-linux-gnu/bin/../libexec/gcc/aarch64-none-linux-gnu/15.0.0/lto-wrapper
aarch64-none-linux-gnu-gcc (fsf-trunk.3697) 15.0.0 20240514 (experimental)
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.

It would help if you could either:

  • Contribute directly to ACL. Please submit a patch for review fixing this specific problem, we would be happy to take your contribution.
  • Provide more details as to how to reproduce this: ACL branch you are building, the command you're using to build the library. Once I can reproduce it I'll be happy to fix it myself.

Hope this helps

@jwakely
Copy link

jwakely commented Sep 16, 2024

aarch64-none-linux-gnu-gcc (fsf-trunk.3697) 15.0.0 20240514 (experimental)

The relevant change was committed to GCC trunk on 2024-08-01 so this build won't have it.

There are RPMs of a recent gcc 15 at https://copr.fedorainfracloud.org/coprs/jwakely/gcc-latest/ or you could use the scripts at https://github.com/jwakely/pkg-gcc-latest/ to build a .deb (I only provide a pre-built .deb for x86_64 not aarch64).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants