[Bug other/99903] 32-bit x86 frontends randomly crash while reporting timing on Windows

["izbyshev at ispras dot ru" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from Alexey Izbyshev <izbyshev at ispras dot ru> ---
Crashes eventually occurred with both one- and two-processor affinity masks, so
pinning GCC to a single core doesn't help. But I've tracked the reason down.

When `get_time()` from `gcc/timevar.c` gets inlined into its callers (which
happens with -O2), it "returns" the result on a x87 FPU register. Then
`timevar_accumulate()` computes the difference between this 80-bit number and a
64-bit double stored in the timer structure. So when `clock()` returns 15 at
both start and end measurements, this code basically subtracts 15 * (1.0 /
1000) stored with 64-bit precision from itself computed with 80-bit precision,
and the difference is 8.673617379884035472e-19. When `clock()` returns 15 for
all measurements during a single cc1 run, the total time and each phase time
are equal to this same constant, and the sum of phase times is twice the total
time:

Timing error: total of phase timers exceeds total time.
user    1.734723475976807094e-18 > 8.673617379884035472e-19

Maybe GCC should round such ridiculously small intervals to zero?