[llvm-dev] GEP with a null pointer base

[Keane, Erich via llvm-dev]

Responded to this earlier but didn't get llvm-dev on the list:

This is the commit that caused the newest revision of the problem: https://github.com/lattera/glibc/commit/2fd4de4b15a66f821057af90714145d2c034a609

Note that it removes the OLDER version of the problem (__PTR_TO_INT/__INT_TO_PTR).  The interesting part of the old version is the comment:

-/* We use subtraction of (char *) 0 instead of casting to int
-   because on word-addressable machines a simple cast to int
-   may ignore the byte-within-word field of the pointer.  */

I'll note that I tried both the new and old version, and think Clang's emit for this pattern (GEP(i8,nullptr, %SOMETHING)) will correct this issue.

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Florian Weimer via llvm-dev
Sent: Thursday, July 6, 2017 1:06 PM
To: Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] GEP with a null pointer base

* Andrew via llvm-dev Kaylor:

> The most recent glibc code is a bit more complicated than I 
> represented below.  If you look up obstack.h you can see what’s there 
> now.  Basically, they’re computing a pointer alignment that may be 
> based on some non-null base pointer or may be based on null, depending 
> on the target architecture.  I’m sure it’s possible to make it more 
> sensible, but I’ve never interacted with the glibc community so I’m 
> not sure how open they would be to changing this.  I suspect I’d need 
> a more compelling argument than clang-compatibility (or maybe even 
> standards compatibility).

Not at all, we are fine with making installed headers more palatable to a wider range of compilers.

That being said, I find obstacks rather horrible and wouldn't be surprised if they can't be implemented in a standard-conforming manner.  Strictly speaking, you can't take a pointer, convert it to (u)intptr_t, twiddle some bits for alignment purposes, and cast it back to get another object pointer.  But it seems to me that obstacks go beyond that in terms of C language abuse.

The offset relative to NULL was probably needed for some old compilers.  We should rewrite this using uintptr_t and __alignof__.
If anyone wants to work on this and change the macros, we'd definitely review a patch submission (if it is short enough or is backed by a copyright assignment, sorry).
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev