[Bug c/101913] New: -Wstrict-overflow -O3 false alarm on tzdb localtime.c

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

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

            Bug ID: 101913
           Summary: -Wstrict-overflow -O3 false alarm on tzdb localtime.c
           Product: gcc
           Version: 11.2.1
            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 51304
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51304&action=edit
-Wstrict-overflow -O3 false alarms

I ran into this problem when compiling tzdb localtime.c with gcc (GCC) 11.2.1
20210728 (Red Hat 11.2.1-1) on x86-64. To reproduce, compile the attached
program v.i with:

gcc -Wstrict-overflow -O3 -fsanitize=undefined -S v.i

The output is:

v.i: In function ‘tzloadbody’:
v.i:22:1: warning: assuming signed overflow does not occur when simplifying
con\
ditional to constant [-Wstrict-overflow]
   22 | tzloadbody (struct state *sp, int leapcnt0, int timecnt0)
      | ^~~~~~~~~~
v.i:29:25: warning: assuming signed overflow does not occur when simplifying
co\
nditional to constant [-Wstrict-overflow]
   29 |       sp->types[i] = at <= 0xffffffffu;
      |                      ~~~^~~~~~~~~~~~~~

1. These diagnostics make no sense, since none of the underlined code involves
any operations that can overflow.

2. I looked through the code carefully, and none of the arithmetic operations
can possibly overflow. In (result << 8), 'result' is at most 2**32 - 1 and this
fits comfortably into 'long'. -1L << 63 is LONG_MIN. "++i" is executed only
when i is less than some other int. timecnt++ and leapcnt++ are executed at
most INT_MAX times. prevcorr + 1 is evaluated only when prevcorr < corr, and
prevcorr - 1 is evaluated only when prevcorr > corr.

3. The diagnostics vanish if you change MYSTERY from 5 to 4 in the first line.
This suggests that GCC is somehow getting confused about whether 'long' has 8
bytes (which it does on this platform) or 4 bytes.