On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote:
> > Aren't *intrin.h system headers too?
>
> I was under impression that they are not, since they live outside of
> /usr/include.
Yes, they aren't in /usr/include, but they are still system headers.
If I preprocess something that #include <x86intrin.h> with my system
compiler, I get:
# 1 "/usr/lib/gcc/x86_64-redhat-linux/10/include/x86intrin.h" 1 3 4
where that 3 stands for system header.
My preference would be a new attribute that for always_inline says it is ok
to inline even when there are target or optimization mismatches (and
effectively get the target/optimization options from the caller for the
body) and start using that new attribute in glibc headers (for
-D_FORTIFY_SOURCE wrappers at least, those really don't have any target
dependencies nor anything floating point that might e.g. depend on
-ffast-math etc.) and perhaps the __rdtsc and similar intrinsics in
*intrin.h.
Even that can be a can of worms, because some target or optimization options
are used already in the FE processing or during the GIMPLE passes before
inlining, and while it might work somehow if e.g. during those passes we
treat it like -ffast-math and after inlining not like that or vice versa,
there is a risk that we e.g. fold/lower something with some assumptions and
later assume that (with different options) such constructs can't appear in
the IL.
> If the patch does not differentiate between system and user headers,
> then please revert it.
It does but intrinsic headers are system headers.
Jakub
