https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- I'm not entirely sure what the point of testing for __clang__ is, really. Is libstdc++ used with, or supposed to be used (say, as a system library) with __clang__? If so, wouldn't it be useful if it actually worked as expected? Currently, the code compiles just fine, though it fails to parse %I%p if compiled with the actual __clang__ (or when __clang__ is defined on other compilers for whatever reasons, but that's besides the point). My thinking is that either libstdc++ headers are to work with clang, in which case there's an error in that bit, or they aren't, in which case the preprocessor test is superfluous and, in this oddball case, harmful. As for tm bits, my suggestion was to overwrite tm fields internally, not to expose that externally. They'd be used as scratch bits. As in, member functions in the public interface would not use incoming tm bits as __time_get_state, but rather a zeroed-out __time_get_state structure, as today, but when calling the internal implementation primitive do_get, they'd *blindly* *overwrite* some of the tm bits with those from __time_get_state, and when do-get returns, they'd pull them back into __time_get_state and out of tm. They'd be used as scratch bits, which AFAICT is permissible. do_get, being protected and thus more of an internal implementation bit, could make use of those scratch bits. do_get overriders could tweak them, for better or worse, but since this use would be nonstandard, we could probably get away with assuming any such uses to be libstdc++-specific. It would probably not be wise for users to rely on this internal extension, though, since one can hope the standard will eventually make room for an implementation of time_get that is both standard-compliant and compatible with reasonable strptime expectations.
