On Mon, 20 Jan 2020, Sandra Loosemore wrote:
> I'm not happy with this -- we shouldn't be talking about internal concepts
> like GIMPLE and RTL in the GCC user manual. Can we instead talk about which
> user-visible optimization options cause problems, so that users who feel the
> urgent need to write hacky code like that know what to disable? (I'd guess it
> would be things involving alias analysis.) Otherwise, I think we should stick
> with the current "don't do this" language or some variant of it that explains
> briefly that, while such code is technically allowed by the C standard, it
> confuses GCC's optimizers.
The problem is in code shared by multiple RTL optimizers, so I'm afraid we
cannot give a list of optimizations to disable. Instead, we can suggest that
users can place optimization barriers on problematic pointers:
ptr = (void *) iptr;
__asm__ ("" : "+g"(ptr));
// use *ptr
i.e. prevent incorrect tracking of possible pointer targets by copying the
pointer value through an asm statement. To make the intent of the asm more
clear, users may wish to enumerate possible targets in input constraints
of such asm:
ptr = (void *) iptr;
__asm__ ("" : "+g"(ptr) : "X"(&obj1), "X"(&obj2), ...);
// use *ptr
Alexander
