https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Louis Dionne from comment #4) > (In reply to Andrew Pinski from comment #2) > > You should not be building on top of GCC's limits.h header at all really. > > Rather implementations should have their own. > > What do you mean by "implementations"? Do you mean implementations of the C > library or compiler implementations, or what? GCC limits.h is the implementation detail of GCC. Yes I know it gets fuzzy. This is why GCC even has fixincludes to make sure target headers are always correct. See the comment I posted. If clang/libc++ wants built on top of GCC's implementation of GCC's C implementation, then it will need to similar tricks as GCC does for other targets. GCC does fixincludes trick to support other targets besides Linux even. > > > (In reply to Jonathan Wakely from comment #3) > > (In reply to Andrew Pinski from comment #2) > > > Rather implementations should have their own. > > > > Or just use GCC's one without change, which is what libstdc++ does. We don't > > provide any <limits.h> in libstdc++, only <climits>. When you #include > > <limits.h> with G++ you just get GCC's own <limits.h> as-is. > > Yeah but we may need to add stuff to <limits.h> on some platforms, so we may > need to have such a header. Also, I assume you only do that for a subset of > headers, because you must have <foo.h> headers in libstdc++ for a few > headers that require adding const-correct overloads of e.g. `memchr`? Yes and some targets such as solaris even includes some of those inside foo.h ... GCC's libstdc++ had issues with that previous and needed some changes.