[Bug libfortran/103886] New: Use 64-bit time_t on 32-bit glibc targets

[Bug libfortran/103886] New: Use 64-bit time_t on 32-bit glibc targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886

            Bug ID: 103886
           Summary: Use 64-bit time_t on 32-bit glibc targets
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

In order to solve the Y2038 problem glibc now supports 64-bit time_t on 32-bit
platforms. As this is an ABI change, it has to be explicitly enabled through
setting the _TIME_BITS=64 preprocessor macro (similar to _FILE_OFFSET_BITS=64
to enable support for files larger than 2 GB).

See https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
and https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

I don't think any time_t (or structs containing time_t members) are part of the
libgfortran ABI, so this should be an internal change not requiring any ABI
bumping.

Some other 32-bit targets already have 64-bit time_t; At least NetBSD, OpenBSD
and Linux with musl libc 1.2+, https://musl.libc.org/time64.html .

[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Is there anything to be done as the time_t is now defaults to 64bit on the
trunk of glibc?

[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886

--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Is there anything to be done as the time_t is now defaults to 64bit on the
> trunk of glibc?

AFAIU it's not the default, you need to explicitly opt-in by setting the
_TIME_BITS preprocessor macro to 64 (64-bit time_t is the default on musl, and
{Net,Open}BSD ).

Or are you saying that since the _TIME_BITS thing was introduced (with glibc
2.34), the upcoming 2.35/trunk has changed the default?

[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Janne Blomqvist from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Is there anything to be done as the time_t is now defaults to 64bit on the
> > trunk of glibc?
> 
> AFAIU it's not the default, you need to explicitly opt-in by setting the
> _TIME_BITS preprocessor macro to 64 (64-bit time_t is the default on musl,
> and {Net,Open}BSD ).
> 
> Or are you saying that since the _TIME_BITS thing was introduced (with glibc
> 2.34), the upcoming 2.35/trunk has changed the default?

Yes, the upcoming 2.35 has changed the default:
https://sourceware.org/pipermail/libc-alpha/2021-December/134576.html

Sorry I was not clear about that.

[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886

--- Comment #4 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Janne Blomqvist from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Is there anything to be done as the time_t is now defaults to 64bit on the
> > > trunk of glibc?
> > 
> > AFAIU it's not the default, you need to explicitly opt-in by setting the
> > _TIME_BITS preprocessor macro to 64 (64-bit time_t is the default on musl,
> > and {Net,Open}BSD ).
> > 
> > Or are you saying that since the _TIME_BITS thing was introduced (with glibc
> > 2.34), the upcoming 2.35/trunk has changed the default?
> 
> Yes, the upcoming 2.35 has changed the default:
> https://sourceware.org/pipermail/libc-alpha/2021-December/134576.html

I'm not super-familiar with glibc, but it seems that this changes the default
(in ./bits/timesize.h) to 64 for targets not overriding it, however it
adds/modifies a number of target-specific overrides to retain the previous
behavior? In particular for x86 there is
./sysdeps/unix/sysv/linux/x86/bits/timesize.h which says:

#if defined __x86_64__ && defined __ILP32__
/* For x32, time is 64-bit even though word size is 32-bit.  */
# define __TIMESIZE     64
#else
/* For others, time size is word size.  */
# define __TIMESIZE     __WORDSIZE
#endif


If my reading of the above is correct, on 32-bit x86 __TIMESIZE is set to
__WORDSIZE, that is, 32.

Similarly for ./sysdeps/unix/sysv/linux/arm/bits/timesize.h it says

#define __TIMESIZE      32

[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 1 Jan 2022, jb at gcc dot gnu.org via Gcc-bugs wrote:

> I'm not super-familiar with glibc, but it seems that this changes the default
> (in ./bits/timesize.h) to 64 for targets not overriding it, however it
> adds/modifies a number of target-specific overrides to retain the previous
> behavior?

Exactly.  "Default" here means "default for architectures that don't 
provide their own bits/timesize.h header"; there is no change to the 
default for any existing architecture.  It was already required that new 
glibc ports must use 64-bit time_t; the effect of this change is that new 
glibc ports to 32-bit architectures no longer need to have a 
bits/timesize.h header of their own (in general, we want the defaults to 
be such that new ports need as few sysdeps files as possible).