undefined behavior of signed left shifts (was Re: [PULL 00/40] ppc patch queue 2015-06-03)
On 05/06/2015 17:45, Peter Maydell wrote: >>> ...but things like "(1U << 31)" are entirely valid. >> >> They're only valid until someone does a ~ on them. I think it's >> reasonable to forbid them in our coding standards, if we want to fix >> ubsan's warning of (1 << 31). >> >> I don't think it's reasonable for compiler writers to exploit the >> undefinedness of (1 << 31) anyway, and if it were possible to shut up >> ubsan about this particular kind of undefined behavior, I would prefer it. > > I don't think it's reasonable for compiler writers to exploit > undefined behaviour either, but historically they absolutely > have done. Most cases of undefined behavior are rooted in "you should never do that anyway". This is not the case for bitwise operations, since they are not mathematical concepts and the representation of integers as bits is only implementation-defined. > Absent a guarantee from gcc that it will never do > so, I think we should avoid any UB in our code. The GCC manual says "GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed '<<' as undefined, but this is subject to change". It would certainly be nice if they removed the "this is subject to change" part. Paolo
Re: undefined behavior of signed left shifts (was Re: [PULL 00/40] ppc patch queue 2015-06-03)
On Fri, 5 Jun 2015, Paolo Bonzini wrote: > The GCC manual says "GCC does not use the latitude given in C99 and C11 > only to treat certain aspects of signed '<<' as undefined, but this is > subject to change". It would certainly be nice if they removed the > "this is subject to change" part. The correct statement would be more complicated. That is: the value returned is as documented, without that latitude being used for *optimization*, but (a) -fsanitize=undefined (and its subcase -fsanitize=shift) intends to follow exactly what the different standards specify when giving runtime errors and (b) the cases that are undefined are thereby not considered integer constant expressions (with consequent pedwarns-if-pedantic in various cases, and corner case effects on what's a null pointer constant). (The only "subject to change" would be that if there are still missing cases from the runtime detection or the not treating as integer constant expressions, then those missing cases may be fixed. I don't think it would be a good idea to add optimizations on this basis - for example, optimizations of x * 2 based on undefined overflow should not be applied to x << 1.) -- Joseph S. Myers jos...@codesourcery.com
Re: undefined behavior of signed left shifts (was Re: [PULL 00/40] ppc patch queue 2015-06-03)
On 5 June 2015 at 16:55, Paolo Bonzini wrote: > The GCC manual says "GCC does not use the latitude given in C99 and C11 > only to treat certain aspects of signed '<<' as undefined, but this is > subject to change". It would certainly be nice if they removed the > "this is subject to change" part. Does clang provide a similar guarantee? I couldn't find one in a quick scan through the docs, but I might be looking in the wrong place. thanks -- PMM
