AaronBallman wrote: > > The kernel should not be redefining what's provided by the compiler or > > standard library. But I expect you already explored the "just don't do > > that!" idea and that's why we're here. > > I don't really see a way to fix the kernel here. The kernel is providing > these types for its own internal usage since it does not consume any standard > library or compiler headers in the general case. As far as I can tell, the > kernel tries to limit what is included from the compiler but it is > unavoidable for things like NEON/Altivec intrinsics/builtins, which is how we > are in this predicament. The kernel unconditionally defines `int64_t` as > `u64` / `unsigned long long` in `include/linux/types.h` because this will > guarantee a 64-bit wide type for both 64-bit and 32-bit platforms.
Except it does not guarantee that, as we can clearly see. ;-) My point is: the compiler knows things the Linux kernel does not and we put those things into the headers the compiler vends, like `stdint.h`, and this works in both hosted and freestanding environments with no outside library support needed. If our compiler supported headers are insufficient for you to use, we should fix that on our end because we'd consider that to be a bug and we'd rather fix those kinds of bugs than add language dialect flags. At some point, this becomes "you're exporting your tech debt to our project" and I think some of the push back you're getting here is because of concerns this will happen more often. That said, perhaps something for us to consider is a single language dialect flag for the Linux kernel instead of one-off flags for individual behaviors. We already have `-fapple-kext` for Apple's kernel extensions, and `-fms-kernel` for Microsoft's kernel extensions, so maybe we should think about `-flinux-kernel` for the Linux kernel extensions at some point. Regardless of the general lack of excitement and enthusiasm for supporting this kind of situation, upon such tradeoffs are production tools built and we'll live with it here. :-) https://github.com/llvm/llvm-project/pull/234780 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
