Re: Anyone for adding -fwrapv to our standard CFLAGS? - Mailing list pgsql-hackers

From Michael Paesold
Subject Re: Anyone for adding -fwrapv to our standard CFLAGS?
Date
Msg-id 005401c5ffc6$a5edf4d0$daf0a8c0@zaphod
Whole thread Raw
In response to Anyone for adding -fwrapv to our standard CFLAGS?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Anyone for adding -fwrapv to our standard CFLAGS?
List pgsql-hackers
Tom Lane wrote:

> It seems that gcc is up to some creative reinterpretation of basic C
> semantics again; specifically, you can no longer trust that traditional
> C semantics of integer overflow hold:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175462
>
> While I don't think we are anywhere using exactly the same trick that
> the referenced mysql code is using, it certainly seems likely to me that
> a compiler that is willing to replace "x < 0 && -x < 0" with "false"
> might be able to break some of the integer overflow checks we do use.
>
> I think we need to add -fwrapv to CFLAGS anytime the compiler will take
> it, same as we recently started doing with -fno-strict-aliasing.

What about this one from the bug (by Jakub Jelinek):

> Now, -fwrapv can be an answer if you are unwilling to fix the broken code,
> but be prepared that the performance will be terrible, as GCC will not be
> able to optimize many loops in a way that it is allowed by the standard.

"Performance will be terrible" does not sound that good.

Is there any other GCC guy you could talk about this? I don't think 
GCC==Jakub Jelinek? What do others suggest? There should be a portable way 
to detect overflow, no?

Best Regards,
Michael Paesold

[Tom, I removed you from CC: because your spam filter tends to eat my mail; 
you should get it through the lists, though.] 




pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: 7.3 failure on platypus
Next
From: Marko Kreen
Date:
Subject: Re: Which qsort is used