[PATCH] D37042: Teach clang to tolerate the 'p = nullptr + n' idiom used by glibc

Andy Kaylor via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 23 12:53:45 PDT 2017

andrew.w.kaylor added a comment.

My intention here was to make this as strict/limited as possible while still handling the cases of interest.  There are two different implementations I want to handle.  You can see the first variation in the __BPTR_ALIGN definition being added here:


You can see the other in the __INT_TO_PTR definition that was being deleted in the same change set here:


This second case shows up in some benchmark code, so it's important even though glibc phased it out.

I'm really not sure what this looks like in the front end, but it seems like it could be relatively open-ended as to where the value came from.

Basically, my intention is to eliminate anything I know isn't what I'm looking for and then handle whatever remains being added to a null pointer.  Given that adding to a null pointer is undefined behavior, whatever we do should be acceptable in all cases.  What I found in practice was that even with the existing handling of this it took an awful lot of optimizations before the null-based GEP and the load associated with it got close enough together for us to recognize that we could optimize it away, so I don't think we'd be losing much by tolerating additional cases in the way this patch proposes.


More information about the cfe-commits mailing list