[Bug driver/105171] New: `local_tick` can overflow and become -1

[jason at zx2c4 dot com]

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

            Bug ID: 105171
           Summary: `local_tick` can overflow and become -1
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jason at zx2c4 dot com
  Target Milestone: ---

In gcc/toplev.c, there's the comment:

    /* A local time stamp derived from the time of compilation. It will be
       zero if the system cannot provide a time.  It will be -1u, if the
       user has specified a particular random seed.  */
    unsigned local_tick;

This is affirmed by init_local_tick()'s comment:

    /* Initialize local_tick with the time of day, or -1 if
       flag_random_seed is set.  */
    static void init_local_tick (void)

And indeed we see it assigned -1 when flag_random_seed != NULL:

    else
      local_tick = -1;

So far so good. However, in the case where flag_random_seed == NULL, local_tick
is assigned like this:

    struct timeval tv;
    gettimeofday (&tv, NULL);
    local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000;

Recall that local_tick is of type "unsigned". Somewhat often, that expression
calculates to be 0xffffffff, which means local_tick winds up being -1 even when
flag_random_seed == NULL.

This is a problem for plugins that follow the documentation comments in order
to determine whether -frandom-seed is being used. To work around this bug,
these plugins should just call get_random_seed(noinit=true) in their plugin
init functions and check there whether the return value is zero. If they use a
local_tick==-1 check, once in a blue moon, it'll be wrong.

Probably, though, the type of local_tick should be changed to a HOST_WIDE_INT,
or something similar to that.