[llvm-dev] GEP with a null pointer base

Florian Weimer via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 7 00:29:19 PDT 2017


* Erich Keane:

> 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

For posterity:

commit 2fd4de4b15a66f821057af90714145d2c034a609
Author: Roland McGrath <roland at gnu.org>
Date:   Wed Jan 11 05:43:11 2006 +0000

    [BZ #321]
    
    2005-10-14  Paul Eggert  <eggert at cs.ucla.edu>
…
            [BZ #321]
            Fix portability bugs encountered when porting to Itanium.
            * malloc/obstack.h (obstack_empty_p, obstack_finish): Do not
            assume that the "contents" member is suitably aligned.  It is
            not, for some hosts and alignments: e.g., Itanium, long-double.
            * malloc/obstack.c (_obstack_begin, _obstack_begin_1,
            _obstack_newchunk): Likewise.
            * malloc/obstack.c: Include <stddef.h>, for size_t.
            Include <inttypes.h>, <stdint.h> if needed and available.
            (DEFAULT_ALIGNMENT): Now an enum constant, not a macro.
            Use C89 offsetof rather than K&R trick.
            Use the maximum alignment of uintmax_t, long double, void *
            rather than the alignment of double.
            (union fooround): Use uintmax_t, long double, void * members
            rather than just long and double.
    
            [BZ #321]
            Fix portability bugs encountered when porting to the IBM iSeries,
            where pointers are 256 bits wide and no integers are that wide.
            * malloc/obstack.h (__PTR_TO_INT, __INT_TO_PTR): Remove.
            All uses changed to:
            (__BPTR_ALIGN, __PTR_ALIGN): New macros.
            (struct _obstack_chunk.temp): Change from int to a union
            of pointer and int.  All uses changed.

The referenced bug is here:

  https://sourceware.org/bugzilla/show_bug.cgi?id=321

I don't doubt that alignment code is needed.  The new allocation
buffers I wrote for glibc have that as well, hopefully in a slightly
more portable manner.  But the workaround added at the time to
<obstack.h> (and which is still used today) doesn't seem quite right.

Fortunately, all our targets have uintptr_t and pretty much a flat
address space.

If someone could provide a minimal test case with #include <obstack.h>
and the Clang version(s) that exhibit the problem, I can file
something in glibc Bugzilla to track this at least.


More information about the llvm-dev mailing list