On Thu, 22 Sept 2022 at 23:14, Jason Merrill wrote: > On 9/22/22 09:39, Marek Polacek wrote: > > This patch doesn't make libstdc++ use the new built-ins, but I had to > > rename a class otherwise its name would clash with the new built-in. > > Sigh, that's going to be a hassle when comparing compiler versions on > preprocessed code.
Good point. Clang has some gross hacks that we could consider. When it sees a declaration that uses a built-in name, it disables the built-in for the remainder of the translation unit. It does this precisely to allow a new Clang to compile old std::lib headers where a built-in like __is_assignable was used as a normal class template, not the built-in (because no such built-in existed at the time the library code was written). For us, this is only really a problem when bisecting bugs and using a newer compiler to compile .ii files from odler headers, but for Clang combining a new Clang with older libstdc++ headers is a hard requirement (recall that when Clang was first deployed to macOS it had to consume the system's libstdc++ 4.2 headers). It's a big kluge, but it would mean that a new GCC could happily consume preprocessed code from older libstdc++ headers.
