On Fri, Nov 03, 2017 at 09:33:48PM +0800, Yubin Ruan wrote: > Thanks Paul, > > 2017-11-03 20:27 GMT+08:00 Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>: > > On Fri, Nov 03, 2017 at 09:54:15AM +0800, Yubin Ruan wrote: > >> Does anyone have any idea why this thread > >> > >> https://lkml.org/lkml/2003/2/25/270 > > > > Hmmm... This is quite the blast from the past. Compilers have changed > > a bit in the last 14 years. Nevertheles... > > Unfortunately I got several old servers with GCC 3.x so I have to keep > an eye on these things (and worse, I am one of those guys who like to > home-brew some locking primitives...) > > >> is related to strict-aliasing? To me, a compiler barrier like this will fix it: > >> > >> if((stream + event_len) < ends) { > >> iwe->len = event_len; > >> barrier(); > >> memcpy(stream, (char *) iwe, event_len); > >> stream += event_len; > >> } > > > > As with many bugs, there are a number of ways to fix this one. I suggest taking > > a look at the documentation for -no-strict-alias. This stackoverflow URL might > > not be a bad place to start: > > > > https://stackoverflow.com/questions/23848188/strict-aliasing-rule-and-char-pointers > > Basically I understand what aliasing means (for the C/C++ Languages) > and I know what a strict aliasing rule it is. I just cannot see why a > strict aliasing rule will cause this reordering problem... OK. Then please tell me why exactly you believe that strict aliasing does not allow the compiler to reverse the order of the first two statements in the body of the above "if" statement. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe perfbook" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
