On 11/17/15 13:04, Peter Maydell wrote: > 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.
Correct, that's what I meant. > > thanks > -- PMM >
