Re: Overflow hazard in pgbench

2021-07-08 Thread Andres Freund
Hi, On 2021-06-27 16:21:46 -0400, Tom Lane wrote: > BTW, for grins I tried building today's HEAD without -fwrapv, using > gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC) > which is the newest version I have at hand. Not very surprisingly, > that reproduced the failure shown on moonjell

Re: Overflow hazard in pgbench

2021-06-29 Thread Fabien COELHO
Hello Tom, The failure still represents a gcc bug, because we're using -fwrapv which should disable that assumption. Ok, I'll report it. Done at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254 Fixed at r12-1916-ga96d8d67d0073a7031c0712bc3fb7759417b2125 https://gcc.gnu.org/git/gitweb.

Re: Overflow hazard in pgbench

2021-06-29 Thread Fabien COELHO
The failure still represents a gcc bug, because we're using -fwrapv which should disable that assumption. Ok, I'll report it. Done at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254 -- Fabien.

Re: Overflow hazard in pgbench

2021-06-28 Thread Tom Lane
Fabien COELHO writes: >> I suggest applying the attached in branches that have the required >> functions. > The proposed patch does fix the issue in pgbench TAP test. I'd suggest to > add unlikely() on all these conditions, as already done elsewhere. See > attached version. Done that way, tho

Re: Overflow hazard in pgbench

2021-06-28 Thread Fabien COELHO
Hello Tom, moonjelly just reported an interesting failure [1]. I noticed. I was planning to have a look at it, thanks for digging! It seems that with the latest bleeding-edge gcc, this code is misoptimized: else if (imax - imin < 0 || (imax - imin) + 1 < 0)

Re: Overflow hazard in pgbench

2021-06-27 Thread Tom Lane
I wrote: > ... according to the C99 > spec this code is broken, because the compiler is allowed to assume > that signed integer overflow doesn't happen, whereupon the second > if-block is provably unreachable. The failure still represents a gcc > bug, because we're using -fwrapv which should disab

Overflow hazard in pgbench

2021-06-27 Thread Tom Lane
moonjelly just reported an interesting failure [1]. It seems that with the latest bleeding-edge gcc, this code is misoptimized: /* check random range */ if (imin > imax) { pg_log_error("empty range given to random");