[Bug libfortran/103886] New: Use 64-bit time_t on 32-bit glibc targets
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #2 from Janne Blomqvist ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #4 from Janne Blomqvist ---
(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/98507] timezone is incorrect on last day of year for "TZ" hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- (In reply to anlauf from comment #1) > Not a confirmation, just an observation: libgfortran/intrinsics/time_1.h > prefers gettimeofday over clock_gettime, whereas the Linux manpages have: > > GETTIMEOFDAY(2) Linux Programmer's Manual > GETTIMEOFDAY(2) > > CONFORMING TO >SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not > settimeofday(). >POSIX.1-2008 marks gettimeofday() as obsolete, recommending the use > of clock_get- >time(2) instead. > > > Janne chose this prioritization in 2012, but there is no comment explaining > his choice. Should this be revisited? Usage of gettimeofday() was, and still is, ubiquitous. In find it hard to imagine any C library would remove it just because POSIX has deprecated it, unless they want a significant fraction of applications to stop working. That being said, my main motivation for preferring gettimeofday() was that back then clock_gettime was not found in the glibc libc.so but rather in librt (which is part of glibc, but not linked by default for single-threaded programs). See the weakref trickery in intrinsics/system_clock.c for how using clock_gettime on glibc < 2.17 was done, where there was a real motivation for using clock_gettime, namely to access the monotonic clock. So preferring gettimeofday() in time_1.h:gf_gettime() meant that as many targets as possible used the same code path as glibc targets, reducing the risk of target-specific bugs that I would have difficulty deciphering considering I was developing on Linux myself. However, this is all water under the bridge by now, as clock_gettime is part of glibc libc.so since glibc 2.17. So I think switching the order now in 2021 is perfectly fine. As an additional datapoint, per https://man7.org/linux/man-pages/man7/vdso.7.html all Linux targets that provide gettimeofday() as a VDSO also provide clock_gettime() as a VDSO, so no concerns there either. As a minor nit, now that clock_gettime() is the "main" implementation for gf_gettime() you might want to change it to return nanoseconds rather than microseconds, and update the callers.
[Bug fortran/107373] Unexpected result with loop optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373 --- Comment #3 from Janne Blomqvist --- 63ee540430c3 might be related wrt fixing it?
[Bug fortran/108131] New: Incorrect bound calculation when bound intrinsic used in size expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131 Bug ID: 108131 Summary: Incorrect bound calculation when bound intrinsic used in size expression Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- This is from https://stackoverflow.com/questions/74814027/where-to-report-possible-gfortran-compiler-bug . Consider program test integer, parameter :: mg(0:10) = 0 integer, parameter :: u = ubound(mg, dim=1) integer, parameter :: cx(-1:ubound(mg, dim=1)) = 1 integer, parameter :: cy(-1:10) = 2 integer, parameter :: cz(-1:u) = 3 write(*,*) lbound(mg, dim=1), ubound(mg, dim=1) write(*,*) lbound(cx, dim=1), ubound(cx, dim=1) write(*,*) lbound(cy, dim=1), ubound(cy, dim=1) write(*,*) lbound(cz, dim=1), ubound(cz, dim=1) end program test Obviously the ubounds of all the 4 arrays should be 10. However running the program results in: $ ./a.out 0 10 -1 11 -1 10 -1 10 This affects master as of today, an earlier 12.x snapshot I had lying around, and 11.3.0 as shipped with Ubuntu 22.04. Based on a comment on the stackoverflow question, versions 7, 8, 9, and 10 are ok. Looking at -fdump-tree-original output, the error occurs already in the gfortran frontend.
[Bug fortran/101632] NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org Depends on||91413 --- Comment #4 from Janne Blomqvist --- In PR91413 we discussed the issue of stack overflows if recursive is made the default. Some decision and solution on that issue is needed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413 [Bug 91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe
[Bug fortran/90504] Improved NORM2 algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504 --- Comment #2 from Janne Blomqvist --- (In reply to anlauf from comment #1) > (In reply to Janne Blomqvist from comment #0) > > Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference > > Implementation for Carefully Computing the Euclidean Norm, > > https://dl.acm.org/citation.cfm?id=3134441 > > > > Above article tests different algorithms for NORM2 and tests performance and > > numerical accuracy. > > This article is behind a paywall. > > Is there a publicly available description? https://kar.kent.ac.uk/67205/1/remark.pdf (Found via the https://unpaywall.org/ browser extension)
