https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103964
--- Comment #5 from Ilya Maximets <i.maximets at ovn dot org> --- (In reply to Richard Biener from comment #4) > the IVOPTs reference is likely due to the fact that while IVOPTs uses > uintptrs to create the base pointer the TARGET_MEM_REF contained arithmetic > itself is still considered pointer arithmetic (like also here the embedded > MEM_REF pointer offsetting) and the base "pointer" cannot be a non-pointer > to disable that behavior. Does this mean that this is UB and the GCC itself relies on a certain result of it? Shouldn't this mean that this should not be an UB in the end, so other users can rely on that behavior as it is beneficial for certain code patterns? Or at least be configurable? Is that correct that dynamically allocated memory is never a subject for this kind of a pointer check, i.e. we can safely offset pointers to the dynamically allocated memory? If so, can we be sure that this check will always be there for dynamically allocated memory, so we can avoid unnecessary fixes for this kind of use cases? (Allocating ovs_list dynamically indeed fixes our test case.) We have a bit less than a million lines of code heavily using discussed data structures and without automated ways to find the problematic places it will be not an easy job to fix (UBsan doesn't flag anything and I doubt someone will actually sit and re-check the whole code base manually). (In reply to Richard Biener from comment #3) > where I think passing &pos->elem and &member->elem to ovs_list_insert is > already wrong since 'pos' doesn't point to a valid object if the > ultimate written destination is 'start'. > Doing the 'pos' initialization with uintptr_t isn't enough - you need to > do this all the way up to the &pos->elem computation Maybe there is a way to not treat a &pos->elem as a pointer arithmetic? Maybe there should be one? I mean, compilers allows users to perform computations with offsets of structure fields where the base pointer is NULL, and NULL obviously doesn't point to any valid object. I'm not sure if it's an UB or not, but constructions like '&((struct s *)NULL)->field' are very common.
