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.