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... Yubin -- 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
