https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
Bug ID: 114965
Summary: wrong code generated for Emacs/Gnulib strftime
(regression from 13.2)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
Created attachment 58111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58111&action=edit
Test with "gcc -O2 u5.i; ./a.out". The output should be a "123 " line.
I ran into this problem when building newish GNU Emacs with gcc (GCC) 14.0.1
20240411 (Red Hat 14.0.1-0) on x86-64.
GCC generates incorrect code for emacs/lib/nstrftime.c, which is taken from
Gnulib. The incorrect code causes some of Emacs's own test cases ("make check")
to fail. Possibly you'll see a similar problem with glibc strftime, though I
haven't tested this.
A stripped-down version of the problem is attached. Compile and run it with:
gcc -O2 u5.i
./a.out
The output is "123000", but it should be "123 " - that is, three spaces
should follow the "123" instead of three zeros.
Looking at the generated code, it appears that GCC gets confused by the
complicated logic involving the 'pad' local variable, switch statements, etc.
The code generated for line 62 behaves as if (pad == '0' || pad == '+') is
true, even though it is false because pad == '_'.
Compiling without -O2 makes the problem go away. The problem does not occur
with GCC 13.2.0, which I built myself. Nor does it occur with gcc (GCC) 8.5.0
20210514 (Red Hat 8.5.0-4).
