Building with ClangCL/MSVC for x86_64 fails with the default configuration

[solbjorn]

A lot of compiler errors of the same type within one file:

src\core\transform\ojph_transform_avx512.cpp(228,23): error : always_inline function '_mm512_set1_ps' requires target feature 'avx512f', but would be inlined into function 'avx512_irv_vert_step' that is compiled without support for 'avx512f'
    228 |       __m512 factor = _mm512_set1_ps(a);
        |                       ^

I used OJPH_DISABLE_AVX512=ON for now, it compiles fine. It's sorta ok as don't have AVX512 on my CPU, but I believe the library should compile cleanly to use runtime dispatching on CPUs with AVX512.

LLVM 22.1.8, I use -flto -mavx2 among others, but this shouldn't have any impact on the mentioned file.

zlib-ng also compiles with AVX512 support by default, but doesn't have any build issues.

[aous72]

Hi Alexander,

Thank you for your inquiry.

I suspect this is a problem of -flto.
The function avx512_irv_vert_step is part of the ojph_transform_avx512.cpp file, which is compiled with -mavx512f -mavx512cd flags.
The library compiles with clang and gcc for a variety of platforms without issues.

I need to investigate the -flto flag.

A search in Google, which uses Gemini, gives:

How to Fix It

You can resolve this issue in one of three ways, depending on how you want to handle your build environment:

1. Strip LTO From SIMD Files (Recommended)

You can continue using -flto globally for the rest of your application, but you must instruct your build system to disable LTO explicitly for OpenJPH's SIMD-specific files. If using CMake: You can turn off LTO on a per-target or per-file basis using the target property:

cmake
set_target_properties(openjph PROPERTIES INTERPROCEDURAL_OPTIMIZATION FALSE)

Use code with caution.

2. Align LTO Code Generation Flags

If you are compiling your application to run exclusively on modern machines that support AVX-512, ensure your optimization flags match at both the compilation and the linking phase. Add the architecture flags directly to your linking command (https://indico.cern.ch/event/1106734/sessions/431201/attachments/2401345/4106749/Transition%20from%20Intel%20C++%20Compiler%20Classic%20to%20ICX.pdf):

# Ensure both compile and link steps know AVX-512 is available
-flto -mavx512f

Use code with caution.

3. Disable LTO Entirely

If LTO is not strictly required for your deployment binary, stripping -flto from your CMAKE_CXX_FLAGS or environment flags (CFLAGS/CXXFLAGS) will immediately restore OpenJPH's default, multi-platform build behavior.

[solbjorn]

@aous72, thanks, I'll try. It's interesting though, as I have several libraries with runtime dispatching and compilation units for AVX-512 (zlib-ng etc) and all of them compile fine.

Are you sure you don't need to mark AVX-512 functions with compiler attributes like target("avx512")?

[solbjorn]

My Gemini doesn't agree with yours :>

Your intuition is 100% correct, and you should trust it. The author’s advice to disable LTO or downgrade your microarchitecture level (-march=x86_64-v3) is a workaround for a fundamental flaw in how OpenJPH handles its compilation units.
The error occurs because the file is missing explicit function target attributes (e.g., __attribute__((target("avx512f")))), and OpenJPH relies entirely on a brittle build-system layout that breaks under Link-Time Optimization (LTO).

The Root Cause of the Failure

When you pass -march=x86_64-v3, the compiler’s global baseline target allows SIMD extensions up to AVX2, but not AVX512 (which belongs to x86_64-v4).
In a standard build without LTO, a build system will typically isolate ojph_transform_avx512.cpp into its own translation unit and ideally append an explicit compiler flag (like /arch:AVX512 or -mavx512f) to just that one file. However, LTO changes the game.
Under -flto, the compiler defers actual code generation until the link phase. It merges translation units and analyzes functions globally. If an AVX512 file does not explicitly declare its functions as targeting AVX512 at the C++ code level via attributes, the LTO linker passes the global baseline compiler state (-march=x86_64-v3) to the inliner. The compiler then sees a strict conflict: you are attempting to force-inline a macro/intrinsic that demands AVX512 (_mm512_set1_ps) into a function that the compiler thinks only has permission to use AVX2.

Why Other Libraries (like zlib-ng) Work

Libraries like zlib-ng or mimalloc are designed from the ground up for modern toolchains and toolchain optimizations like LTO. They do not rely solely on source-file separation. Instead, they explicitly decorate their runtime-dispatched functions using target attributes:

// What robust modern libraries do for runtime dispatch:

__attribute__((target("avx512f")))
void avx512_specific_function() {
    // Intrinsic usage here is perfectly safe, even under LTO with a lower baseline
}

This tells the LTO pipeline exactly what features the function requires, ensuring it compiles safely regardless of the global -march baseline. Looking at the ojph_transform_avx512.cpp source code you provided, the author implements the functions as naked void avx512_irv_vert_step(...) functions, completely omitting these guard attributes.

[aous72]

Let's focus on the basics.
The statement

src\core\transform\ojph_transform_avx512.cpp(228,23): error : always_inline function '_mm512_set1_ps' requires target feature 'avx512f', but would be inlined into function 'avx512_irv_vert_step' that is compiled without support for 'avx512f'

is incorrect, because the function avx512_irv_vert_step is part of the ojph_transform_avx512.cpp file, which is compiled with -avx512f and -avx512cd flags.
The question is: what is happening?
I guess the problem is happening because the -flto is messing up the build.

Out of curiosity, are you using this in CMakeLists.txt?

set_property(TARGET openjph PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

?
I tested with the above cmake property with an old version of gcc or clang, not sure, and that compiled properly, except for a warning about the same object names in different files.
The library has been compiled with -flto before.

Hope this helps. I will try to run it again, perhaps you can provide more details.

PS: I do not like the __attribute__((target("avx512f"))) because it does not work will Microsoft Visual Studio -- you need to build a conditional compilation around it, and then I need to put this around many functions.

This worked

This worked on Ubuntu 26.04, clang version 22.1.2

Add

set_property(TARGET openjph PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

After

add_library(openjph ${SOURCES})

in src/core/CMakeLists.txt

Then use

cmake -DCMAKE_LINKER=ld.lld-22 -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld" -DCMAKE_C_COMPILER=/usr/bin/clang-22 -DCMAKE_CXX_COMPILER=/usr/bin/clang++-22 ..

before building. I installed apt install lld-22 -- without this, I had a problem with linking the C code in ojph_mem_c.c.
I suspect this is not needed if clang22 is installed natively.

[aous72]

I tested a bit more. To compile with -flto, all you need is the call cmake with -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=TRUE; that is,

cmake ..  -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=TRUE

plus whatever options you want.

Cheers,
Aous.

[solbjorn]

CMAKE_INTERPROCEDURAL_OPTIMIZATION enables ThinLTO. I use FatLTO (-flto) for better optimization.

zlib-ng and similar libraries with runtime dispatching build and work correctly, they also support MSVC, so I don't think __attribute__((target())) is a problem if handled correctly (MSVC doesn't support __attribute__(), but its LTCG doesn't need them I think as it's way less powerful than ClangLTO). You can check the code of these libraries to get the idea.

Again, if X libs build and work correctly and one library doesn't, I'm not convinced it's my problem.

[solbjorn]

Maybe a similar change would help: BLAKE3-team/BLAKE3@15e83a5

[aous72]

Sorry Alexander, I should have responded earlier.
I already have that; see

OpenJPH/src/core/CMakeLists.txt

Lines 94 to 110 in 96f6d39

	set_source_files_properties(codestream/ojph_codestream_sse.cpp PROPERTIES COMPILE_FLAGS -msse)
	set_source_files_properties(codestream/ojph_codestream_sse2.cpp PROPERTIES COMPILE_FLAGS -msse2)
	set_source_files_properties(codestream/ojph_codestream_avx.cpp PROPERTIES COMPILE_FLAGS -mavx)
	set_source_files_properties(codestream/ojph_codestream_avx2.cpp PROPERTIES COMPILE_FLAGS -mavx2)
	set_source_files_properties(coding/ojph_block_decoder_ssse3.cpp PROPERTIES COMPILE_FLAGS -mssse3)
	set_source_files_properties(coding/ojph_block_decoder_avx2.cpp PROPERTIES COMPILE_FLAGS -mavx2)
	set_source_files_properties(coding/ojph_block_encoder_avx2.cpp PROPERTIES COMPILE_FLAGS -mavx2)
	set_source_files_properties(coding/ojph_block_encoder_avx512.cpp PROPERTIES COMPILE_FLAGS "-mavx512f -mavx512cd")
	set_source_files_properties(transform/ojph_colour_sse.cpp PROPERTIES COMPILE_FLAGS -msse)
	set_source_files_properties(transform/ojph_colour_sse2.cpp PROPERTIES COMPILE_FLAGS -msse2)
	set_source_files_properties(transform/ojph_colour_avx.cpp PROPERTIES COMPILE_FLAGS -mavx)
	set_source_files_properties(transform/ojph_colour_avx2.cpp PROPERTIES COMPILE_FLAGS -mavx2)
	set_source_files_properties(transform/ojph_transform_sse.cpp PROPERTIES COMPILE_FLAGS -msse)
	set_source_files_properties(transform/ojph_transform_sse2.cpp PROPERTIES COMPILE_FLAGS -msse2)
	set_source_files_properties(transform/ojph_transform_avx.cpp PROPERTIES COMPILE_FLAGS -mavx)
	set_source_files_properties(transform/ojph_transform_avx2.cpp PROPERTIES COMPILE_FLAGS -mavx2)
	set_source_files_properties(transform/ojph_transform_avx512.cpp PROPERTIES COMPILE_FLAGS "-mavx512f -mavx512cd")

Somehow the compiler ignores all of these with the way you are using -flto; it seems that the compiler put everything in one file ignoring the flags associated with each file. The reason you are not having issues with avx2 and lower is because you are passing -mavx2.

In Fedora, the OpenJPH library is built with LTO; see
https://kojipkgs.fedoraproject.org//packages/radcli/1.5.3/1.eln159/data/logs/x86_64/build.log

Can you try the following:

export CXXFLAGS="-flto=auto -ffat-lto-objects" 
cmake .. 
make

This worked for me and, as far as I can tell, this will compile with fat LTO globally.

Cheers,
Aous

[solbjorn]

@aous72, yup I've seen that you do that. However, it's done only if MSVC is false, but when building with clang-cl for Windows/MSVC, it's true, so the first branch is taken which adds MSVC-specific flags.

I can try changing this condition to if (MSVC AND NOT CMAKE_C_COMPILER_ID STREQUAL "Clang") to see if that helps.

[solbjorn]

@aous72, yup, this is enough to make it build and work correctly with Clang and FatLTO on Windows:

diff --git a/src/core/CMakeLists.txt b/src/core/CMakeLists.txt
index be833576f05e..47f8525221a9 100644
--- a/src/core/CMakeLists.txt
+++ b/src/core/CMakeLists.txt
@@ -79,7 +79,7 @@ else()
       endif()

       # Set compilation flags
-      if (MSVC)
+      if (MSVC AND NOT CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
         set_source_files_properties(codestream/ojph_codestream_avx.cpp PROPERTIES COMPILE_FLAGS "/arch:AVX")
         set_source_files_properties(codestream/ojph_codestream_avx2.cpp PROPERTIES COMPILE_FLAGS "/arch:AVX2")
         set_source_files_properties(coding/ojph_block_decoder_avx2.cpp PROPERTIES COMPILE_FLAGS "/arch:AVX2")

In this case, CMake adds GNU-style architecture flags which are native for Clang (and supported by clang-cl) and don't result in error regardless of the configuration (LTO etc.). MSVC-style architecture flags are less fine-grained (only one for AVX512 without any differentiation) and seem to be not enough for Clang.

Should I make a PR or you'd like to commit such trivial change yourself?