Hi Linus, On 28 March 2017 at 17:20, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Mar 28, 2017 at 7:19 AM, Dibyendu Majumdar > <mobile@xxxxxxxxxxxxxxx> wrote: >> >> Well the unsimplified output is correct. The problem appears after >> simplification. > > No. The unsimplified output has the exact same bug: > > main: > .L0: > <entry-point> > load.32 %r1 <- 0[s3] > shl.32 %r2 <- $1, $6 > and.32 %r3 <- %r1, $-65 > > That "load.32" loads an uninitialized value from the stack. > > The simplification then just simplifies the uninitialized load to just > be an uninitialized pseudo instead. Exact same code. > > And arguably both unsimplified and simplified code is "correct" in the > sense that it's exactly what the original source code does: > > s3.onebit = 1; > I think that the unsimplified output is correct in that it is doing what the C code says. Because if you look at the C code, the code is only accessing a field that has been initialized prior to access - so I do not think this counts as undefined behaviour. I am unable to find the wording in the C standard that would make this clear one way or another, but my reading of the standard is that the C code is legal. I understand that to the simplification phase the first load looks like load of undefined value - but that is not the semantic of the C code that led to it. I checked that clang generates the same sequence of instructions as sparse when optimization is switched off - but turning on optimization gets rid of all the code except for the return. Thanks and Regards Dibyendu -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
