Cannot build stb_image when spdlog is imported from the precompiled header

[OverShifted]

#1258
gabime/spdlog#2248
https://stackoverflow.com/questions/70657762/linux-c-compilation-error-emmintrin-h

Is there any way to fix this? I'm using the latest version of stb_image and using the latest commit of spdlog's v1.x branch.
It was fine before I updated spdlog submodule (the last version I was using, was about 2 years old)

[rygorous]

This looks like spdlog is #define-ing an identifier that the stb_image resamplers use internally, or something along those lines.

I don't understand why the file setting #define STB_IMAGE_IMPLEMENTATION needs to include spdlog.h to begin with. Tracking this down will probably require asking the compiler to preprocess the source for you, but more to the point, there's no reason to have this problem to begin with.

Just make sure that the .c/.cpp file (or other translation unit) that defines STB_IMAGE_IMPLEMENTATION doesn't include spdlog.h. There's no reason to, and if you don't include both they're not going to clash.

[OverShifted]

It's actually included because of pch. I could move the "impl-ing" translation unit to a separate CMake target which disables pch.

But the error happens in /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/emmintrin.h which is a system header. So maybe it is unrelated to stb_image?

[rygorous]

As said before, this is almost certainly a preprocessor macro problem, if you want to get to the bottom of this you'll need to look at the preprocessed source.

Which header file it materializes in is almost certainly completely immaterial.

[OverShifted]

The error is fixed by undefining __OPTIMIZE__ (on that specific translation unit). But spdlog is not defining __OPTIMIZE__ anywhere in its code. I couldn't find any other macro name collisions either.

Also, the error only happens when pch is used and when spdlog is included from the pch.

It works fine when I'm using pch but including spdlog normally, or when not using pch at all (I even tested it without using a build system).

And it only happens on gcc. clang works fine, but also consider that clang's emmintrin.h is completely different.

[nothings]

As far as I understand it, you have a viable workaround: compile with STB_IMAGE_IMPLEMENTATION from a standalone C file that doesn't include pch.h.

If you want to root cause it, feel free, but I'm not sure there's much point. stb libraries rely on compiling the header file two different ways depending on context, which obviously has potential to not play nicely with precompiled headers. While nothing in your minimal repro seems to involve that, the mere fact that you're having the problem in this context makes me suspicious.

[rygorous]

I don't know. None of that's us either, maybe ask the GCC folks?

[mmozeiko]

The problem comes from fmt library that is bundled with spdlog: https://github.com/fmtlib/fmt/blob/master/include/fmt/core.h#L287
This line enables optimization - so any code included afterwards will work as if __OPTIMIZE__ define is set. This makes your precompiled header be created with __OPTIMIZE__ define. Even for "debug" builds. But when you compile actual code then optimizations are not enabled and _mm_slli_si128 intrinsic will not be able to work (no inlining) as it is defined as inline function when __OPTIMIZE__ is enabled.

Kind of related gcc bug here: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=105120

One workaround would be to put #define FMT_GCC_PRAGMA(...) inside your pch.h file before spdlog includes.

[OverShifted]

Got it!

[OverShifted]

What I still don't understand, is why GCC throws such an unrelated error (error: the last argument must be an 8-bit immediate).
And that the only difference between the two optimized and non-optimized versions is that one of them uses inline functions while the other one uses macros (and why the macros version is not the optimized one? shouldn't they have the same performance?). So to my current understanding, they should both work under all circumstances. Is there some under-the-hood compiler magic that treats inline functions differently?

[mmozeiko]

Look how _mm_srli_si128 is implemented in gcc headers: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/emmintrin.h#L1207-L1240

If __OPTIMIZE__ is set (basically when -Og/1/2/3 passed to compiler) then they are done as functions that call __builtin_ia32_psrldqi128 builtin. But this builtin expects second argument to be immediate, not variable. Thus this code expects these functions be forcefully inlined. Otherwise it won't compile.

Without OPTIMIZE define they are defined as defines, so no expectations of inlining.

fmt header (part of spdlog) messes up this #ifdef. Because creates defines OPTIMIZE define when you precompile header because fmt enables -Og, but when you actually run compilation on your main.cpp then no optimizations are defined. The compiler will choose functions not ifdefs, but no inlining is enabled (because no -Og/1/2/3 is passed) - thus the compilation error. Arguably this is GCC compiler bug.

But this has nothing to do with performance for function vs macro. It's just an issue of how gcc has created their headers for emmintrin.h and fmt library messing up with optimizer settings. No idea why they created emmintrin.h header like this. Maybe because of some backwards compatibility.

You can get same problem in this situation:
pch.h file

#pragma GCC push_options
#pragma GCC optimize ("Og")
struct dummy
{
  dummy() {}
};
#pragma GCC pop_options

main.cpp file

#include <emmintrin.h>
__m128i fun(__m128i x) { return _mm_srli_si128(x, 1); }

and then build like:

g++ -c pch.h
g++ -c -include pch.h main.cpp

and you'll get same error.
But this error won't happen if one of -Og/1/2/3 is passed for second command.

[OverShifted]

The compiler will choose functions not ifdefs, but no inlining is enabled (because no -Og/1/2/3 is passed)

Thank you. I thought functions declared as inline, are always inlined, even without optimizations. (It also has additional attributes such as __always_inline__)