On 10/17/2016, 01:45 PM, Peter Zijlstra wrote: > And given GCC7 is still in development, this might be a good time to get > a knob added for our benefit. I tried and failed, see below. Citing from: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 (In reply to Jiri Slaby from comment #16) > (In reply to Jakub Jelinek from comment #15) > > lots of them that rely on pointer arithmetics being defined only within the > > same object. > > Sure, but the two pointers (taken implicitly of the arrays) are within the > same object. So I do not see, why it wouldn't work? I.e. where exactly this > breaks the C specs? No. In C extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; declares two external arrays, thus they are two independent objects. It is like if you have: int a[10]; int b[10]; in your program, although they might be allocated adjacent, such that int *p = &a[10]; int *q = &b[0]; memcmp (&p, &q, sizeof (p)) == 0; &b[0] - &a[0] is still UB. What you do with __start_*/__end_* symbols is nothing you can define in C, you need linker support or asm for that, and to use it without UB you also need to use an optimization barrier that has been suggested. ============================== > And given gcc 7 is to be released yet, can we have a switch to disable this > optimization? This is nothing new in GCC 7, you've most likely just been extremely lucky in the past that it happened to work as you expected. Other projects had to change similar UB code years ago. It isn't just a single optimization, but lots of them that rely on pointer arithmetics being defined only within the same object. -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html