[compiler-rt] r246454 - builtins: implement __emutls_get_address

[Chih-hung Hsieh via llvm-commits]

What are the compilation flags to trigger that failure?
It is unexpected that a target integer word is 8 and sizeof(size_t) is 4.
If that configuration is correct, and also needs emutls, then it cannot use
both gnu's emutls.c and this one because the layout difference. If that
platform does not need emutls or compatibility with gcc, then we can skip
this test for that platform.



On Fri, Sep 4, 2015 at 8:00 AM, H.J. Lu <hjl.tools at gmail.com> wrote:

> On Mon, Aug 31, 2015 at 10:14 AM, Chih-Hung Hsieh via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > Author: chh
> > Date: Mon Aug 31 12:14:07 2015
> > New Revision: 246454
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=246454&view=rev
> > Log:
> > builtins: implement __emutls_get_address
> >
> > For targets like Android that depends on libgcc's emulated thread local
> storage.
> > clang/llvm can generate calls to __emutls_get_address since
> > http://reviews.llvm.org/D10522 and http://reviews.llvm.org/D10524
> >
> > Differential Revision: http://reviews.llvm.org/D12001
> >
> >
> > Added:
> >     compiler-rt/trunk/lib/builtins/emutls.c
> > Modified:
> >     compiler-rt/trunk/lib/builtins/CMakeLists.txt
> >     compiler-rt/trunk/lib/builtins/README.txt
> >     compiler-rt/trunk/lib/builtins/int_util.h
> >
> >
> > +/* Emulated TLS objects are always allocated at run-time. */
> > +static inline void* emutls_allocate_object(__emutls_control* control) {
> > +    /* Use standard C types, check with gcc's emutls.o. */
> > +    typedef unsigned int gcc_word __attribute__((mode(word)));
> > +    typedef unsigned int gcc_pointer __attribute__((mode(pointer)));
> > +    COMPILE_TIME_ASSERT(sizeof(size_t) == sizeof(gcc_word));
>
> What is this assert for?  It is false for x32 where size_t is 4 bytes and
> gcc_word 8 bytes.
>
> > +    COMPILE_TIME_ASSERT(sizeof(uintptr_t) == sizeof(gcc_pointer));
> > +    COMPILE_TIME_ASSERT(sizeof(uintptr_t) == sizeof(void*));
> >
> --
> H.J.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150904/528d3fe1/attachment.html>