Unlike GCC, llvm always uses an integrated assembler, which attempts to
recognized all `asm` statements written in the C code. glibc uses some
syntactically invalid asm statements to emit constants into assembly that
are later extracted with a sed or AWK script.
This change fixes two such invalid `asm` statements by wrapping the
output in a `.ascii` directive.. This does not break the sed/AWK (the same
special sequence is output) but it makes the statement syntactically valid.
See cf8e3f8757 for a previous fix for the same issue.
Bug 22639 reports localtime failing to handle time offset transitions
correctly in 2039 and later on platforms with 64-bit time_t.
The problem is the use of SECSPERDAY (constant 86400) in calculations
such as
t = ((year - 1970) * 365
+ /* Compute the number of leapdays between 1970 and YEAR
(exclusive). There is a leapday every 4th year ... */
+ ((year - 1) / 4 - 1970 / 4)
/* ... except every 100th year ... */
- ((year - 1) / 100 - 1970 / 100)
/* ... but still every 400th year. */
+ ((year - 1) / 400 - 1970 / 400)) * SECSPERDAY;
where t is of type time_t and year is of type int. Before my commit
92bd70fb85 (an update from tzcode,
included in 2.26 and later releases), SECSPERDAY was obtained from a
file imported from tzcode, where the value included a cast to
int_fast32_t. On 64-bit platforms, glibc defines int_fast32_t to be
long int, so 64-bit, but my patch resulted in it changing to int.
(The bug would probably have existed even before my patch for x32,
which has 64-bit time_t but 32-bit int_fast32_t, but I haven't
verified that.)
This patch fixes the problem by including a cast to time_t in the
definition of SECSPERDAY. (64-bit time support for 32-bit systems
should move such code that isn't a public interface to using the
internal 64-bit version of time_t throughout.)
Tested for x86_64 and x86.
[BZ #22639]
* time/tzset.c (SECSPERDAY): Cast to time_t.
* time/tst-y2039.c: New file.
* time/Makefile (tests): Add tst-y2039.
These comments should make it easier to see the (small) diff introduced
in cf8e3f8757. Without these comments, the diff may get list on a future
upstream merge.
The gen-as-const and gen-py-const scripts are used to generate integer constant
definitions from a list of constant C-expressions. This is achieved by
generating a C program with inline `asm` statements, that depend on
these constant expressions. During compilation, the constant expressions
are evaluated, and included in the inline asm. The build process
generates only the assembly, and then used `sed` to extract the values
from the assembly text.
This is clever. It allows the build process to extract the value of C
statements built under the target architecture. The implementation is a
bit fragile, but it is not immediately obvious to me how it could be
improved.
This change slightly modifies `gen-as-const` and `gen-py-const` to emit
valid assembly directives instead of invalid directives that were
previously emitted. Since the values are extracted via string parsing,
this has no effect on the values extracted. This is needed because the
LLVM assembler validates all statements before emitting them, whereas it
appears GCC will literally emit any `asm` directives without validation
or recognition.
This completes the deprecation and removal of this inclusion, which
was begun in the 2.25 release.
* posix/sys/types.h: Don't include sys/sysmacros.h.
* misc/sys/sysmacros.h: Remove the conditional deprecation
warnings for the macros defined by this header.
+ Use DOT_MACHINE macro instead of ".machine" instruction.
+ Use __isinf and __isinff instead of builtin versions.
+ In s_logb, s_logbf and s_logbl functions, used float versions to
calculate "ret = x & 0x7f800000;" expression.
