[compiler-rt] r248346 - [builtins] Fixing broken bot building on linux with -Werror

[Chris Bieneman via llvm-commits]

You’re being pedantic, the compiler is being -Wpedantic, let’s just all be pedantic :-)

-Chris

> On Sep 23, 2015, at 2:06 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> 
> On Wed, Sep 23, 2015 at 11:32 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote:
>> 
>> On Sep 23, 2015, at 5:30 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> 
>> On Tue, Sep 22, 2015 at 8:01 PM, Chris Bieneman <beanz at apple.com> wrote:
>> 
>> 
>> 
>> On Sep 22, 2015, at 4:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> 
>> On Tue, Sep 22, 2015 at 7:35 PM, Chris Bieneman via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>> 
>> Author: cbieneman
>> Date: Tue Sep 22 18:35:24 2015
>> New Revision: 248346
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=248346&view=rev
>> Log:
>> [builtins] Fixing broken bot building on linux with -Werror
>> 
>> Returning a void expression is bad.
>> 
>> 
>> Why is returning a void expression bad? Also, why do these require
>> return statements at all?
>> 
>> 
>> Returning a void expression is a warning on -Wpedantic
>> (lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/20392).
>> 
>> 
>> Good to know, thanks!
>> 
>> The return itself isn't needed, but is common C convention.
>> 
>> 
>> This is the first I've heard that this is a C convention (but I'm not
>> claiming that it isn't). It doesn't appear to be one we adhere to with
>> any consistency -- I did a quick scan of other builtins (see
>> atomic_signal_fence.c and atomic_thread_fence.c) and they elide the
>> return. Since it's not needed anyway, I think it'd be good to remove.
>> 
>> 
>> Revised r248385.
> 
> Thank you! I will go be pedantic elsewhere now. ;-)
> 
> ~Aaron
> 
>> 
>> -Chris
>> 
>> 
>> ~Aaron
>> 
>> 
>> -Chris
>> 
>> 
>> ~Aaron
>> 
>> 
>> Modified:
>>  compiler-rt/trunk/lib/builtins/atomic_flag_clear.c
>>  compiler-rt/trunk/lib/builtins/atomic_flag_clear_explicit.c
>> 
>> Modified: compiler-rt/trunk/lib/builtins/atomic_flag_clear.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/builtins/atomic_flag_clear.c?rev=248346&r1=248345&r2=248346&view=diff
>> ==============================================================================
>> --- compiler-rt/trunk/lib/builtins/atomic_flag_clear.c (original)
>> +++ compiler-rt/trunk/lib/builtins/atomic_flag_clear.c Tue Sep 22 18:35:24
>> 2015
>> @@ -21,7 +21,8 @@
>> #include <stdatomic.h>
>> #undef atomic_flag_clear
>> void atomic_flag_clear(volatile atomic_flag *object) {
>> -  return __c11_atomic_store(&(object)->_Value, 0, __ATOMIC_SEQ_CST);
>> +  __c11_atomic_store(&(object)->_Value, 0, __ATOMIC_SEQ_CST);
>> +  return;
>> }
>> 
>> #endif
>> 
>> Modified: compiler-rt/trunk/lib/builtins/atomic_flag_clear_explicit.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/builtins/atomic_flag_clear_explicit.c?rev=248346&r1=248345&r2=248346&view=diff
>> ==============================================================================
>> --- compiler-rt/trunk/lib/builtins/atomic_flag_clear_explicit.c (original)
>> +++ compiler-rt/trunk/lib/builtins/atomic_flag_clear_explicit.c Tue Sep 22
>> 18:35:24 2015
>> @@ -22,7 +22,8 @@
>> #undef atomic_flag_clear_explicit
>> void atomic_flag_clear_explicit(volatile atomic_flag *object,
>>                               memory_order order) {
>> -  return __c11_atomic_store(&(object)->_Value, 0, order);
>> +  __c11_atomic_store(&(object)->_Value, 0, order);
>> +  return;
>> }
>> 
>> #endif
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150923/b937fc9a/attachment.html>