2017-11-03 22:03 GMT+08:00 Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>: > 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. Indeed, the compiler is free to reorder those two statements and strict aliasing does not prevent the compiler from doing so. But, from my perspective, this reordering issue might just come from some other optimization rules (so we have to use barrier()), not because of the strict aliasing rule. Hmm... am I missing anything? 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
