https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87392
--- Comment #8 from Eugeniu Rosca <roscaeugeniu at gmail dot com> --- On 2018-09-25 at 08:53:34 UTC, Jonathan Wakely wrote in comment #6: > He already did. Comment 1 quotes the GCC manual which references > the relevant sections of the standards. Comment 1 does indeed reference "(C90 6.3, C99 and C11 6.5)". But if you check my first post again, you'll see that neither C89->"3.3.7 Bitwise shift operators" [18] nor its C90 [19] counterpart C90->"6.3.7 Bitwise shift operators" says a word about signed integers in the definition of the '<<' operator. This is in contrast with later C standards which supplement the definition of "E1 << E2" by "If E1 has a signed type ...". It is simply not possible to conclude from C89->3.3.7 or from C90->6.3.7 that "left-shifting of signed integer into the sign bit" is implementation-defined behavior. The C89/C90 sections conveying this message are: - C89: "A.6.3 Implementation-defined behavior" -> "A.6.3.4 Integers" - C90: "G.3 Implementation-defined behavior" -> "G.3.5 Integers" The latter is referenced by you in Comment 6, but not in Comment 1. > > - Since U-Boot is compiled using '-std=gnu11' and since UBSAN reports > > (1 << 31) as undefined behavior and since C11 standard says that > > encountering an UB the compiler may "ignore the situation completely > > with unpredictable results", > It may do that, or it may do other things (like print a UBsan error). I wish there was an "and" relationship between the two, i.e. the error to be dependent on the UB, with no false positives. > > what are there real-life issues expected from shifting signed > > integers into (*not past*) the sign bit? What to expect in the worst case? > I think with GCC the worst that will happen is you get a UBsan error (which > might make the program abort, depending on the options used to compile it). In U-Boot/Linux kernel execution goes on, so the latter is not of concern. I am quite surprised that, in spite of no harm expected from shifting a signed integer into the sign bit, GCC (std=c99, std=c11) still decides to fire a warning. It seems like the idea behind UBSAN is to inform the user about what C standard says on paper rather than how it is implemented. This is quite unfortunate. > You've already been given the link to the GCC documentation which says > that GCC doesn't treat it as undefined in C99 and C11, even though the > standards (and UBsan) say it's undefined. Ok, let's come back to it. Here is what you refer to: -----8<----- As an extension to the C language, GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed ‘<<’ as undefined. However, -fsanitize=shift (and -fsanitize=undefined) will diagnose such cases. -----8<----- I am not sure if you or anybody else cares, but this sounds pretty similar to "Some children study too hard to succeed" [20]. I can understand the above excerpt in two ways: 1. As an extension to the C language, GCC does not use the latitude given in C99 and C11 in order to treat only certain aspects of signed ‘<<’ as undefined. [..] 2. As an extension to the C language, GCC does not use the latitude given in C99 and C11 of only treating certain aspects of signed ‘<<’ as undefined. [..] Regardless of the variant I pick, without GCC community support I'm still clueless about: - what kind of latitude is provided by C99/C11 standards. - which gcc aspects of signed ‘<<’ diverge from the C99/C11 standards and which do not. > There is no bug here. It's correct for UBsan to depend on the C standard > chosen, > because what is and isn't undefined depends on the standard. As expressed above, my expectation was that UBSAN reflects how compiler implements the standard rather than what standard itself says. I am still surprised that this expectation is broken, but I will just accept it and keep going. It's also unfortunate that, as a user, I can't disable the UBSAN warning of shifting into (not past) the sign bit. Enabling either -fsanitize=shift-exponent or -fsanitize=shift-base alone would disable other precious UBSAN warnings as a side effect, which is not acceptable. All in all, the summary which I take from this discussion is "don't be concerned about left shifting into the sign bit, even if UBSAN annoys you with a warning". If there is no way GCC folks can support communities like U-Boot/coreboot to at least individually turn off benign UBSAN warnings, I have no choice but to finally agree with the status of this bug report. Thanks and regards, Eugeniu. [18] http://port70.net/~nsz/c/c89/c89-draft.html [19] http://read.pudn.com/downloads133/doc/565041/ANSI_ISO%2B9899-1990%2B[1].pdf [20] https://guinlist.wordpress.com/2016/02/08/124-structures-with-a-double-meaning/
