thr3ads.net - llvm dev - [LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux [Sep 2009]

If this information is useful, please help other people find it:
Share via:

Edward O'Callaghan

2009-Sep-23 04:01 UTC

[LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux

Clang does indeed built it with one warning.

[ 55%] Building C object
lib/CMakeFiles/CompilerRT-Common.dir/gcc_personality_v0.c.o
/export/home/edward/lab/llvm/build/compiler-rt/lib/gcc_personality_v0.c:232:36:
warning: implicit declaration of function
'__builtin_eh_return_data_regno' is invalid in C99
      [-Wimplicit-function-declaration]
            _Unwind_SetGR(context, __builtin_eh_return_data_regno(0),
                                   ^
1 diagnostic generated.

I committed a fix for the other warnings and a fix for each of the
#endif, I did not think they where very 'clear/readable' however they
are now.

Thanks for your work on the CMake system btw !

I think we need a 'clean' CMake test for the above problem instead of
the build just blowing up like that.
I guess I will have a look in the morning (its late here) unless you
have already committed something by then.

Cheers,
Edward.

2009/9/23 Shantonu Sen <ssen at apple.com>:> Seems pretty clear cut to me.
>
> #if defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_INT) &&
> defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_LONG)
> ...
> #elif defined(__WIN32__)
> ...
> #elif defined(HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT) &&
> defined(HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG)
> ...
> #else
> #error unknown atomic compare-and-swap primitive
> #endif
>
> The problem isn't mismatched #if/#endif. The #error says it all, cmake
> couldn't detect an appropriate atomic built-in implementation.
>
> Please use llvm-gcc or clang to build compiler-rt. Same as how nobody
> expects to build libgcc with anything other than gcc.
>
> Shantonu
>
> Sent from my MacBook
>
> On Sep 22, 2009, at 8:06 PM, Edward O'Callaghan wrote:
>
>> No, As it worked fine before.
>>
>> I can't see the #if that goes with +#elif defined(__WIN32__) as you
>> removed -#if TARGET_OS_MAC.
>> Please go over your #if / #endif blocks and trail the #endif with a
>> comment. I am willing to bet there is a problem there.
>>
>> Thanks for your time,
>> Edward.
>>
>> 2009/9/23 Shantonu Sen <ssen at apple.com>:
>>>
>>> Sounds like your system compiler doesn't support gcc-style
builtin
>>> atomics.
>>> Please use a different compiler?
>>>
>>> Shantonu
>>>
>>> Sent from my MacBook
>>>
>>> On Sep 22, 2009, at 7:54 PM, Edward O'Callaghan wrote:
>>>
>>>> Breaks Builds on Solaris and AuroraUX with:
>>>>
>>>> bash-3.2$ make
>>>> Scanning dependencies of target BlocksRuntime
>>>> [  1%] Building C object
>>>> BlocksRuntime/CMakeFiles/BlocksRuntime.dir/runtime.c.o
>>>>
>>>>
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:77:2:
>>>> error: #error unknown atomic compare-and-swap primitive
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:
>>>> In function 'latching_incr_int':
>>>>
>>>>
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:118:
>>>> warning: implicit declaration of function
'OSAtomicCompareAndSwapInt'
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:
>>>> In function '_Block_dump':
>>>>
>>>>
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:664:
>>>> warning: format '%#lx' expects type 'long unsigned
int', but argument
>>>> 3 has type 'unsigned int'
>>>>
>>>>
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:672:
>>>> warning: format '%#lx' expects type 'long unsigned
int', but argument
>>>> 3 has type 'unsigned int'
>>>>
>>>>
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:673:
>>>> warning: format '%#lx' expects type 'long unsigned
int', but argument
>>>> 3 has type 'unsigned int'
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:
>>>> In function '_Block_byref_dump':
>>>>
>>>>
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:688:
>>>> warning: format '%#lx' expects type 'long unsigned
int', but argument
>>>> 3 has type 'unsigned int'
>>>>
>>>>
>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:689:
>>>> warning: format '%#lx' expects type 'long unsigned
int', but argument
>>>> 3 has type 'unsigned int'
>>>>
>>>> Please check these.
>>>>
>>>> Thank you,
>>>> Edward O'Callaghan.
>>>>
>>>> 2009/9/22 Chris Lattner <clattner at apple.com>:
>>>>>
>>>>> On Sep 21, 2009, at 9:15 AM, Shantonu Sen wrote:
>>>>>
>>>>> [forwarding to llvm-commits, which is where i meant to send
it the
>>>>> first
>>>>> time]
>>>>>
>>>>> The source changes seem fine to me, and I don't have an
opinion about
>>>>> the
>>>>> build system changes - I suggest committing them and seeing
if anyone
>>>>> screams :)
>>>>> Thanks Shantonu,
>>>>> -Chris
>>>>>
>>>>> Ping?
>>>>> Shantonu Sen
>>>>> ssen at apple.com
>>>>> Sent from my Mac Pro
>>>>> Begin forwarded message:
>>>>>
>>>>> From: Shantonu Sen <ssen at apple.com>
>>>>> Date: September 18, 2009 11:14:13 AM PDT
>>>>> To: LLVM Developers Mailing List <llvmdev at
cs.uiuc.edu>
>>>>> Subject: [LLVMdev] [PATCH] BlocksRuntime updates for Linux
>>>>>
>>>>> The attached diff cleans up the BlocksRuntime/ directory of
compiler-rt
>>>>> for
>>>>> better portability, eliminates compiler warnings, and adds
support to
>>>>> the
>>>>> cmake build to install the results.
>>>>>
>>>>> More specifically, the changes:
>>>>> 1) Remove cmake-specific #define usage from the exported
>>>>> Block.h/Block_private.h headers, since clients won't
know what to set.
>>>>> These
>>>>> are moved into runtime.c as appropriate
>>>>> 2) Use cmake checks for CAS builtins, instead of guessing
based on GCC
>>>>> #defines (which aren't set by clang and llvm-gcc
anyway)
>>>>> 3) "#pragma mark" isn't supported by FSF gcc,
so "#if 0" it out. It
>>>>> should
>>>>> still show up in IDEs that support it
>>>>> 4) Fix some compiler warnings. GCC 4.3.3 seems super strict
about %p.
>>>>> function pointers can't be cast to void * either.
>>>>> 5) Avoid a warning for apple_versioning.c that "ISO C
does not allow
>>>>> empty
>>>>> files"
>>>>>
>>>>> Tested on Ubuntu Linux 9.04 with clang and llvm-gcc and
-fblocks to
>>>>> define
>>>>> and copy some blocks (and invoke them, obviously). Also
tested on Mac
>>>>> OS
>>>>> X
>>>>> 10.6 and linking against -lBlocksRuntime ahead of -lSystem.
>>>>>
>>>>> <blocks-linux.diff>
>>>>>
>>>>> Shantonu Sen
>>>>> ssen at apple.com
>>>>>
>>>>> Sent from my Mac Pro
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Edward O'Callaghan
>>>> http://www.auroraux.org/
>>>> eocallaghan at auroraux dot org
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>
>>
>>
>> --
>> --
>> Edward O'Callaghan
>> http://www.auroraux.org/
>> eocallaghan at auroraux dot org
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org

Shantonu Sen

2009-Sep-23 04:35 UTC

head link

[LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux

There's an Apple internal bug for that. I've cloned it to Bugzilla as:

<http://llvm.org/bugs/show_bug.cgi?id=5034> Implement  
__builtin_eh_return_data_regno()

I can probably make the cmake configure stage fail up front if none of  
the supported mechanisms are found. I'll look at that. Thanks for the  
feedback!

Shantonu

Sent from my MacBook

On Sep 22, 2009, at 9:01 PM, Edward O'Callaghan wrote:
> Clang does indeed built it with one warning.
>
> [ 55%] Building C object
> lib/CMakeFiles/CompilerRT-Common.dir/gcc_personality_v0.c.o
> /export/home/edward/lab/llvm/build/compiler-rt/lib/ 
> gcc_personality_v0.c:232:36:
> warning: implicit declaration of function
> '__builtin_eh_return_data_regno' is invalid in C99
>      [-Wimplicit-function-declaration]
>            _Unwind_SetGR(context, __builtin_eh_return_data_regno(0),
>                                   ^
> 1 diagnostic generated.
>
> I committed a fix for the other warnings and a fix for each of the
> #endif, I did not think they where very 'clear/readable' however
they
> are now.
>
> Thanks for your work on the CMake system btw !
>
> I think we need a 'clean' CMake test for the above problem instead
of
> the build just blowing up like that.
> I guess I will have a look in the morning (its late here) unless you
> have already committed something by then.
>
> Cheers,
> Edward.
>
> 2009/9/23 Shantonu Sen <ssen at apple.com>:
>> Seems pretty clear cut to me.
>>
>> #if defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_INT) &&
>> defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_LONG)
>> ...
>> #elif defined(__WIN32__)
>> ...
>> #elif defined(HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT) &&
>> defined(HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG)
>> ...
>> #else
>> #error unknown atomic compare-and-swap primitive
>> #endif
>>
>> The problem isn't mismatched #if/#endif. The #error says it all,  
>> cmake
>> couldn't detect an appropriate atomic built-in implementation.
>>
>> Please use llvm-gcc or clang to build compiler-rt. Same as how nobody
>> expects to build libgcc with anything other than gcc.
>>
>> Shantonu
>>
>> Sent from my MacBook
>>
>> On Sep 22, 2009, at 8:06 PM, Edward O'Callaghan wrote:
>>
>>> No, As it worked fine before.
>>>
>>> I can't see the #if that goes with +#elif defined(__WIN32__) as
you
>>> removed -#if TARGET_OS_MAC.
>>> Please go over your #if / #endif blocks and trail the #endif with a
>>> comment. I am willing to bet there is a problem there.
>>>
>>> Thanks for your time,
>>> Edward.
>>>
>>> 2009/9/23 Shantonu Sen <ssen at apple.com>:
>>>>
>>>> Sounds like your system compiler doesn't support gcc-style
builtin
>>>> atomics.
>>>> Please use a different compiler?
>>>>
>>>> Shantonu
>>>>
>>>> Sent from my MacBook
>>>>
>>>> On Sep 22, 2009, at 7:54 PM, Edward O'Callaghan wrote:
>>>>
>>>>> Breaks Builds on Solaris and AuroraUX with:
>>>>>
>>>>> bash-3.2$ make
>>>>> Scanning dependencies of target BlocksRuntime
>>>>> [  1%] Building C object
>>>>> BlocksRuntime/CMakeFiles/BlocksRuntime.dir/runtime.c.o
>>>>>
>>>>>
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:77:2:
>>>>> error: #error unknown atomic compare-and-swap primitive
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:
>>>>> In function 'latching_incr_int':
>>>>>
>>>>>
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:118:
>>>>> warning: implicit declaration of function  
>>>>> 'OSAtomicCompareAndSwapInt'
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:
>>>>> In function '_Block_dump':
>>>>>
>>>>>
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:664:
>>>>> warning: format '%#lx' expects type 'long
unsigned int', but
>>>>> argument
>>>>> 3 has type 'unsigned int'
>>>>>
>>>>>
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:672:
>>>>> warning: format '%#lx' expects type 'long
unsigned int', but
>>>>> argument
>>>>> 3 has type 'unsigned int'
>>>>>
>>>>>
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:673:
>>>>> warning: format '%#lx' expects type 'long
unsigned int', but
>>>>> argument
>>>>> 3 has type 'unsigned int'
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:
>>>>> In function '_Block_byref_dump':
>>>>>
>>>>>
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:688:
>>>>> warning: format '%#lx' expects type 'long
unsigned int', but
>>>>> argument
>>>>> 3 has type 'unsigned int'
>>>>>
>>>>>
>>>>>
/export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/
>>>>> runtime.c:689:
>>>>> warning: format '%#lx' expects type 'long
unsigned int', but
>>>>> argument
>>>>> 3 has type 'unsigned int'
>>>>>
>>>>> Please check these.
>>>>>
>>>>> Thank you,
>>>>> Edward O'Callaghan.
>>>>>
>>>>> 2009/9/22 Chris Lattner <clattner at apple.com>:
>>>>>>
>>>>>> On Sep 21, 2009, at 9:15 AM, Shantonu Sen wrote:
>>>>>>
>>>>>> [forwarding to llvm-commits, which is where i meant to
send it
>>>>>> the
>>>>>> first
>>>>>> time]
>>>>>>
>>>>>> The source changes seem fine to me, and I don't
have an opinion
>>>>>> about
>>>>>> the
>>>>>> build system changes - I suggest committing them and
seeing if
>>>>>> anyone
>>>>>> screams :)
>>>>>> Thanks Shantonu,
>>>>>> -Chris
>>>>>>
>>>>>> Ping?
>>>>>> Shantonu Sen
>>>>>> ssen at apple.com
>>>>>> Sent from my Mac Pro
>>>>>> Begin forwarded message:
>>>>>>
>>>>>> From: Shantonu Sen <ssen at apple.com>
>>>>>> Date: September 18, 2009 11:14:13 AM PDT
>>>>>> To: LLVM Developers Mailing List <llvmdev at
cs.uiuc.edu>
>>>>>> Subject: [LLVMdev] [PATCH] BlocksRuntime updates for
Linux
>>>>>>
>>>>>> The attached diff cleans up the BlocksRuntime/
directory of
>>>>>> compiler-rt
>>>>>> for
>>>>>> better portability, eliminates compiler warnings, and
adds
>>>>>> support to
>>>>>> the
>>>>>> cmake build to install the results.
>>>>>>
>>>>>> More specifically, the changes:
>>>>>> 1) Remove cmake-specific #define usage from the
exported
>>>>>> Block.h/Block_private.h headers, since clients
won't know what
>>>>>> to set.
>>>>>> These
>>>>>> are moved into runtime.c as appropriate
>>>>>> 2) Use cmake checks for CAS builtins, instead of
guessing based
>>>>>> on GCC
>>>>>> #defines (which aren't set by clang and llvm-gcc
anyway)
>>>>>> 3) "#pragma mark" isn't supported by FSF
gcc, so "#if 0" it
>>>>>> out. It
>>>>>> should
>>>>>> still show up in IDEs that support it
>>>>>> 4) Fix some compiler warnings. GCC 4.3.3 seems super
strict
>>>>>> about %p.
>>>>>> function pointers can't be cast to void * either.
>>>>>> 5) Avoid a warning for apple_versioning.c that
"ISO C does not
>>>>>> allow
>>>>>> empty
>>>>>> files"
>>>>>>
>>>>>> Tested on Ubuntu Linux 9.04 with clang and llvm-gcc and
-
>>>>>> fblocks to
>>>>>> define
>>>>>> and copy some blocks (and invoke them, obviously). Also
tested
>>>>>> on Mac
>>>>>> OS
>>>>>> X
>>>>>> 10.6 and linking against -lBlocksRuntime ahead of
-lSystem.
>>>>>>
>>>>>> <blocks-linux.diff>
>>>>>>
>>>>>> Shantonu Sen
>>>>>> ssen at apple.com
>>>>>>
>>>>>> Sent from my Mac Pro
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>>
>>>>>> _______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Edward O'Callaghan
>>>>> http://www.auroraux.org/
>>>>> eocallaghan at auroraux dot org
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Edward O'Callaghan
>>> http://www.auroraux.org/
>>> eocallaghan at auroraux dot org
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
>
>
> -- 
> -- 
> Edward O'Callaghan
> http://www.auroraux.org/
> eocallaghan at auroraux dot org
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090922/c6499ff6/attachment.html>

Chris Lattner

2009-Sep-23 06:11 UTC

head link

[LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux

On Sep 22, 2009, at 9:35 PM, Shantonu Sen wrote:
> There's an Apple internal bug for that. I've cloned it to Bugzilla
as:
>
> <http://llvm.org/bugs/show_bug.cgi?id=5034> Implement  
> __builtin_eh_return_data_regno()
>
> I can probably make the cmake configure stage fail up front if none  
> of the supported mechanisms are found. I'll look at that. Thanks for  
> the feedback!
Implemented, what a goofy builtin.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090922/3b25108a/attachment.html>

Reasonably Related Threads

Search for more seemingly similar threads

llvm dev - Sep 2009 - [LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux

[LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux

[LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux

[LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux

Reasonably Related Threads