On 17 November 2015 at 11:59, Markus Armbruster <arm...@redhat.com> wrote: > Laszlo Ersek <ler...@redhat.com> writes: > >> On 11/17/15 11:28, Paolo Bonzini wrote: >>> >>> >>> On 17/11/2015 11:19, Peter Maydell wrote: >>>> I think we should only take this patch if you can get a cast-iron >>>> guarantee from both clang and gcc that they will never use this >>>> UB to drive optimizations. As you say gcc already say this more or >>>> less, but clang doesn't, and if they're warning about it that to >>>> me suggests that they will feel freer to rely on the UB in future. >>> >>> If and when this happens we will add "-fno-strict-overflow" for clang, >>> just like we are using "-fno-strict-aliasing" already. >> >> How about adding "-fwrapv -fno-strict-overflow" right now? (Spelling out >> the latter of those explicitly for pointer arithmetic.) > > One of them, not both. > > Quote gcc manual: > > Using -fwrapv means that integer signed overflow is fully defined: > it wraps. When -fwrapv is used, there is no difference between > -fstrict-overflow and -fno-strict-overflow for integers.
I thought this too, but note that it says "for integers". As Laszlo says, the reason to provide both is to get the -fno-strict-overflow behaviour for pointer arithmetic, which is not affected by -fwrapv. thanks -- PMM
