`-mno-avx256-split-unaligned-load` and `-mno-avx256-split-unaligned-store` may not exist

[Grinslad]

Version

No response

Platform

No response

What steps will reproduce the bug?

Hi there. I am trying to build ada in a wierd environment. Namely natively on mac and building for x86_64 in docker while on apple silicon.

When building in docker these flags throw a gcc unsupported error. This makes sense because we wouldn't have AVX instructions on mac silicon. However, Lots of x86_64 processors do not have AVX. So I would assume this happens in those cases too.

Can we check to see if these flags exist prior to using them? I do not think that it is suitable to check the SYSTEM_PROCESSOR field because not all x86_64 processors have AVX instructions. I am thinking of a few intel generations which just like - didn't. In my case we are building through docker on arm silicon and run into these being fed through (see CesiumGS/cesium-native#1131)

I think what happens is gcc throws an error that these flags are unsupported when the arch is x86_64 and there is no AVX

GPT throws out a solution like this? (big grain of salt...)

include(CheckCXXCompilerFlag)

# Check if the compiler supports the AVX-related options
check_cxx_compiler_flag("-mno-avx256-split-unaligned-load" HAS_NO_AVX256_SPLIT_UNALIGNED_LOAD)
check_cxx_compiler_flag("-mno-avx256-split-unaligned-store" HAS_NO_AVX256_SPLIT_UNALIGNED_STORE)

# Workaround for GNU GCC poor AVX load/store code generation
if ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") AND (CMAKE_SYSTEM_PROCESSOR MATCHES "^(i.86|x86(_64)?)$"))
  if (HAS_NO_AVX256_SPLIT_UNALIGNED_LOAD AND HAS_NO_AVX256_SPLIT_UNALIGNED_STORE)
    target_compile_options(ada PRIVATE -mno-avx256-split-unaligned-load -mno-avx256-split-unaligned-store)
  endif()
endif()

How often does it reproduce? Is there a required condition?

Be on a x86_64 system without AVX support

What is the expected behavior?

It compiles without AVX

What do you see instead?

It does not compile

Additional information

No response

[anonrig]

cc @lemire

[lemire]

@Grinslad

If you are cross-compiling then it is your responsibility to set CMAKE_SYSTEM_PROCESSOR properly (if it is going to set at all). Please see...

https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html

When cross-compiling, a CMAKE_TOOLCHAIN_FILE should set the CMAKE_SYSTEM_PROCESSOR variable to match your target architecture.

I do not see any description of your CMAKE_TOOLCHAIN_FILE file.

You write: "Be on a x86_64 system without AVX support". But that's not your scenario. You are cross-compiling arm/x64.

You can verify that flag does not require an AVX-capable target...

gcc -march=westmere -mno-avx256-split-unaligned-load myprogram.c

All it requires is an x86 target.

[Grinslad]

Hi @lemire, this is not a cross compiling issue, we are not using a cross compiler. This is an issue with detecting what the system supports with virtualization, and I suspect this occurs when a given x86_64 processor does not have AVX instructions so would fail under a wide array of intel SKUs

The target architecture is still x86_64. Its building with x86_64 gcc. From ubuntu repos.

i think the root cause is that checking x86_64 is not suitable for detecting if gcc will support these compile flags. There were many x86_64 processors which did not have support for these, so its a normal use case to not have AVX on x86_64, such as if running virtualized on apple silicon.

This error is from native x86_64 gcc, but running in a containerized environment.

[lemire]

@Grinslad The flag -mno-avx256-split-unaligned-load does not require AVX support. It only requires GCC on x86.

Please refer to the GCC documentation

https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc.pdf

[Grinslad]

Hi @lemire. Thank you for your patience and for clarifying. I had a look at GCCs source and ya, why is this setup coming up as x86?? Apologies for assuming avx relation - the name of the flag is a bit confusing in that way. It made sense as a logical explanation at the time.

As this is a dependency of a dependency I am working upstream to see if we can find a solution (ensuring the system processor is set). I have confirmed that I can build ada with pretty much the same environment as mentioned in CesiumGS/cesium-native#1131 (pasted below), so this is looking out of your hands for now. I will come back to this and close if we can find a solution upstream, else will close in short order or ask for a small change to support our use case.

FROM python:3.12-slim

USER root

ARG DEBIAN_FRONTEND=noninteractive
RUN echo "deb http://deb.debian.org/debian trixie main" >> /etc/apt/sources.list
RUN groupadd -r -g 999 mrnobody && \
    useradd -r -g mrnobody -u 999 mrnobody && \
    apt-get update && \
    apt-get install -y -t trixie \
        bison build-essential cmake cmake-data curl flex git \
        jq perl pkg-config ninja-build tar unzip zip && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
    
# Set the working directory
WORKDIR /usr/src/app

# Clone the ada-url repository using SSH
RUN git clone https://github.com/ada-url/ada.git

# Change directory to the cloned repository
WORKDIR /usr/src/app/ada

# Build the project
RUN mkdir build && cd build && cmake .. && make

# Set the entrypoint to bash
ENTRYPOINT ["/bin/bash"]

Thanks!

[anonrig]

Closing, since the issue doesn't seem to be related to Ada.

[Grinslad]

@anonrig @lemire

Thank you for your time and energy, and apologies for the confusion and involving you!