On 2016.10.19 at 12:25 +0200, Peter Zijlstra wrote: > On Wed, Oct 19, 2016 at 11:33:41AM +0200, Richard Biener wrote: > > On Wed, 19 Oct 2016, Peter Zijlstra wrote: > > > > This is also an entirely different class of optimizations than the whole > > > pointer arithmetic is only valid inside an object thing. > > > > Yes, it is not related to that. I've opened > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035 to track an > > inconsistency in that new optimization. > > > > > The kernel very much relies on unbounded pointer arithmetic, including > > > overflow. Sure, C language says its UB, but we know our memory layout, > > > and it would be very helpful if we could define it. > > > > It's well-defined and correctly handled if you do the arithmetic > > in uintptr_t. No need for knobs. > > So why not extend that to the pointers themselves and be done with it? > > In any case, so you're saying our: > > #define RELOC_HIDE(ptr, off) \ > ({ \ > unsigned long __ptr; \ > __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \ > (typeof(ptr)) (__ptr + (off)); \ > }) > > could be written like: > > #define RELOC_HIDE(ptr, off) \ > ({ \ > uintptr_t __ptr = (ptr); \ > (typeof(ptr)) (__ptr + (off)); \ > }) > > Without laundering it through inline asm? > > Is there any advantage to doing so? > > But this still means we need to be aware of this and use these macros to > launder our pointers. > > Which gets us back to the issue that started this whole thread. We have > code that now gets miscompiled, silently. > > That is a bad situation. So we need to either avoid the miscompilation, > or make it verbose.
FYI this issue was fixed on gcc trunk by: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=76bc343a2f1aa540e3f5c60e542586bb1ca0e032 -- Markus
