https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 31 May 2024, law at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298 > > --- Comment #4 from Jeffrey A. Law <law at gcc dot gnu.org> --- > Agh. I was looking in the main config directory, not common/config. So it > all > makes sense now. > > So if we go back to your original analysis, I think we can say things are > behaving correctly and we just need to adjust the testcase to either skip on > these targets or add the flag. Yes. It's still bad now with a memset(p, 1) having the same effect on other archs. But it's still "correct" given in the caller one could do if (q == (void *)0x0101010101010101) foo (p, q); so I don't really see how we can avoid this without magic hand-waving and muttering "unlikely", aka not what a compiler should do. Of course it now means that every time an INTEGER escapes which means always (a literal INTEGER would always have to be considered escaped) everything breaks down. So do we need to consider void bar () { *(int *)0xdeadbeef = 1; } int foo () { int x = 0; bar (); return x; } and consider carefully laid out stack so bar () clobbers 'x'? We do have to assume 0xdeadbeef is a valid address as otherwise UB. We do close bugs as INVALID that use the address of 'a' to get to 'b' for 'int a, b;' based on pointer arithmetic rules but we have bugs with conditional copy propagation wrecking things. That said, I'm somewhat considering to change INTEGER address behavior in points-to, making them _not_ alias any named object. Would that work in practice? We currently have ANYTHING = &ANYTHING ESCAPED = *ESCAPED ESCAPED = ESCAPED + UNKNOWN *ESCAPED = NONLOCAL NONLOCAL = &NONLOCAL NONLOCAL = &ESCAPED INTEGER = &ANYTHING and I'd change default INTEGER constraints to INTEGER = &INTEGER INTEGER = NONLOCAL 'INTEGER' are objects at literal addresses, they can initially refer to other 'INTEGER' objects and to global (named) objects. That excludes pointing to the stack top for example (we'd be back to ANYTHING if that's OK). Anyway, we'll see if any concrete performance issues arise from the fixed ANYTHING handling.
