On Fri, Nov 29, 2013 at 02:04:10AM +0000, Greg Stark wrote:
> Attached is what I have so far. I have to say I'm starting to come
> around to Tom's point of view. This is a lot of hassle for not much
> gain. i've noticed a number of other overflow checks that the llvm
> optimizer is not picking up on so even after this patch it's not clear
> that all the signed overflow checks that depend on -fwrapv will be
> gone.
>
> This patch still isn't quite finished though.
>
> a) It triggers a spurious gcc warning about overflows on constant
> expressions. These value of these expressions aren't actually being
> used as they're used in the other branch of the overflow test. I think
> I see how to work around it for gcc using __builtin_choose_expr but it
> might be pretty grotty.
>
> b) I'm concerned these checks depend on INT_MIN/MAX and SHRT_MIN/MAX
> which may not be exactly the right length. I'm kind of confused why
> c.h assumes long is 32 bits and short is 16 bits though so I don't
> think I'm making it any worse. It may be better for us to just define
> our own limits since we know exactly how large we expect these data
> types to be.
>
> c) I want to add regression tests that will ensure that the overflow
> checks are all working. So far I haven't been able to catch any being
> optimized away even with -fno-wrapv and -fstrict-overflow. I think I
> just didn't build with the right options though and it should be
> possible.
>
> The goal here imho is to allow building with -fno-wrapv
> -fstrict-overflow safely. Whether we actually do or not is another
> question but it means we would be able to use new compilers like clang
> without worrying about finding the equivalent of -fwrapv for them.
Where are we on this?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
