On Thu, Mar 25, 2021 at 2:14 PM Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > 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.
Err, but _which_ mismatches do you ignore with such new attribute? If I have __rdtsc and compile that into a -mno-rdtsc unit/function would that be OK? IMHO always-inline obviously means "ignore any option mismatches", the user has to make sure to not introduce incompatible caller/callee pairs, if the pair is incompatible the unit is ill-formed (we can't inline, and thus violate always-inline) - we might want to document "no diagnostic required" here, eventually even "behavior is undefined". Everything else is just putting a new label on exactly the same problem. Either a function is always-inline or it is not. It looks to me the x86 intrinsic functions are not? At -O0 we have many of them as macros and thus "inline" them with any kind of option mismatch as well. Those are likely the cases where inlining is required - ignoring option mismatches there is thus obviously OK. Richard. > 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 >
