[Bug c/114965] New: wrong code generated for Emacs/Gnulib strftime (regression from 13.2)

["eggert at cs dot ucla.edu" <gcc-bugzilla@gcc.gnu.org>]

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).