https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87392
--- Comment #5 from Eugeniu Rosca <roscaeugeniu at gmail dot com> --- Hi Andrew, Thanks for the much more satisfying answer. > In C90, it was implemented defined behavior (while in C99 and above it is > undefined behavior). I trust you, but why not giving a reference to the source? Based on my reading of the C89 draft, it should be based on Chapter "A.6.3 Implementation-defined behavior", more specifically subchapter "A.6.3.4 Integers" saying: * The results of bitwise operations on signed integers (3.3). > See the thread which added undefined santizer: > https://gcc.gnu.org/ml/gcc-patches/2013-06/msg00275.html That turned to be a useful reference. +1. > YES there is a huge difference between the languages It's helpful to see you putting such an emphasis on the difference between the standards. > which cannot be changed now as that would be requiring to change C90. IMHO a valid scenario would also be not touching C89/C90, but correcting C11 so that "left-shifting into the sign bit" becomes defined or implementation-defined. To my knowledge, such kind of step actually exists in the form of DR463 entry in the "Defect Report Summary for C11" (see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_463 ), which tried "Harmonizing left-shift with C++14". The latter considers "left-shifting into the sign bit" as defined behavior. >> ANSI C > ANSI C is ISO C. ANSI is a member of ISO. I think you meant to write ANSI > C89 there :). By "ANSI C" I mean C89/C90 and so do references [14-16], so it's quite surprising we are not on the same page. Before I consider this topic closed, I kindly ask you to provide below feedback which I will share with U-Boot people: - 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", what are there real-life issues expected from shifting signed integers into (*not past*) the sign bit? What to expect in the worst case? - Is it possible to provide a sample code which would showcase that "left-shifting into the sign bit" can lead to program behavior being erroneous, unexpected or dependent on the gcc optimization level? For example, we know [17] that "(a + 1 > a)" can lead to surprising results depending on whether the program is compiled with "-fwrapv" or not. Are there any similar examples involving '<<' ? This would be of extreme help for U-Boot community. - What would be your personal choice between '-std=gnu89' (still used by Linux kernel) and '-std=gnu11' (used in U-Boot/coreboot), given your GCC experience gathered so far? Thank you in advance. Best regards, Eugeniu. [14] https://en.wikipedia.org/wiki/ANSI_C This (C89) version of the language is often referred to as "ANSI C" [15] https://stackoverflow.com/a/3783805/2381750 In common parlance, the phrase "ANSI C" usually refers to C89. [16] https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/C-Dialect-Options.html#C-Dialect-Options In C mode, this (-ansi) is equivalent to -std=c90. [17] http://thiemonagel.de/2010/01/signed-integer-overflow/
