[llvm-bugs] [Bug 43603] New: C11 atomics always yielding library call with -mcpu=cortex-m0plus

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Oct 8 04:03:39 PDT 2019


https://bugs.llvm.org/show_bug.cgi?id=43603

            Bug ID: 43603
           Summary: C11 atomics always yielding library call with
                    -mcpu=cortex-m0plus
           Product: clang
           Version: 9.0
          Hardware: Other
                OS: other
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: marian.buschsieweke at ovgu.de
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Using this minimum example code:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <stdatomic.h>

void foo(void);
extern atomic_int_least16_t bar;

void foo(void)
{
        atomic_store_explicit(&bar, 0x1337, memory_order_relaxed);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Compiling with "clang -mcpu=cortex-m3 -mlittle-endian -mthumb -mfloat-abi=soft
-target arm-none-eabi -Weverything -Werror -c -o test.o test.c" works fine.

Compiling with "clang -mcpu=cortex-m0plus -mlittle-endian -mthumb
-mfloat-abi=soft -target arm-none-eabi -Weverything -Werror -c -o test.o
test.c" yields:

> test.c:8:2: error: large atomic operation may incur significant performance
>       penalty [-Werror,-Watomic-alignment]
>         atomic_store_explicit(&bar, 0x1337, memory_order_relaxed);
>         ^
> /usr/lib/clang/9.0.0/include/stdatomic.h:118:31: note: expanded from macro
>       'atomic_store_explicit'
> #define atomic_store_explicit __c11_atomic_store
>                               ^
> 1 error generated.


However, compiling with "arm-none-eabi-gcc -mcpu=cortex-m0plus -mlittle-endian
-mthumb -mfloat-abi=soft -Wall -Wextra -pedantic -Werror -c -o test.o test.c"
works fine and generates:

> arm-none-eabi-objdump -d test.o
> 
> test.o:     file format elf32-littlearm
> 
> 
> Disassembly of section .text:
> 
> 00000000 <foo>:
>    0:	b580      	push	{r7, lr}
>    2:	b082      	sub	sp, #8
>    4:	af00      	add	r7, sp, #0
>    6:	4b07      	ldr	r3, [pc, #28]	; (24 <foo+0x24>)
>    8:	607b      	str	r3, [r7, #4]
>    a:	1cbb      	adds	r3, r7, #2
>    c:	4a06      	ldr	r2, [pc, #24]	; (28 <foo+0x28>)
>    e:	801a      	strh	r2, [r3, #0]
>   10:	1cbb      	adds	r3, r7, #2
>   12:	2200      	movs	r2, #0
>   14:	5e9b      	ldrsh	r3, [r3, r2]
>   16:	b29a      	uxth	r2, r3
>   18:	687b      	ldr	r3, [r7, #4]
>   1a:	801a      	strh	r2, [r3, #0]
>   1c:	46c0      	nop			; (mov r8, r8)
>   1e:	46bd      	mov	sp, r7
>   20:	b002      	add	sp, #8
>   22:	bd80      	pop	{r7, pc}
>   24:	00000000 	.word	0x00000000
>   28:	00001337 	.word	0x00001337

Therefore, I assume that the atomic store can be implemented without resorting
a a library call to __atomic_store_2().

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191008/efd1fc65/attachment.html>


More information about the llvm-bugs mailing list