https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #17 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jonathan Wakely <r...@gcc.gnu.org>: https://gcc.gnu.org/g:d045eb13b0b42870a1f081895df3901112a358f0 commit r16-1118-gd045eb13b0b42870a1f081895df3901112a358f0 Author: Jonathan Wakely <jwak...@redhat.com> Date: Wed May 28 15:19:18 2025 +0100 libstdc++: Make system_clock::to_time_t always_inline [PR99832] For some 32-bit targets Glibc supports changing the size of time_t to be 64 bits by defining _TIME_BITS=64. That causes an ABI change which would affect std::chrono::system_clock::to_time_t. Because to_time_t is not a function template, its mangled name does not depend on the return type, so it has the same mangled name whether it returns a 32-bit time_t or a 64-bit time_t. On targets where the size of time_t can be selected at preprocessing time, that can cause ODR violations, e.g. the linker selects a definition of to_time_t that returns a 32-bit value but a caller expects 64-bit and so reads 32 bits of garbage from the stack. This commit adds always_inline to to_time_t so that all callers inline the conversion to time_t, and will do so using whatever type time_t happens to be in that translation unit. Existing objects compiled before this change will either have inlined the function anyway (which is likely if compiled with any optimization enabled) or will contain a COMDAT definition of the inline function and so still be able to find it at link-time. The attribute is also added to system_clock::from_time_t, because that's an equally simple function and it seems reasonable for them to both be always inlined. libstdc++-v3/ChangeLog: PR libstdc++/99832 * include/bits/chrono.h (system_clock::to_time_t): Add always_inline attribute to be agnostic to the underlying type of time_t. (system_clock::from_time_t): Add always_inline for consistency with to_time_t. * testsuite/20_util/system_clock/99832.cc: New test.
