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?
