llvm dev - Feb 2013 - [LLVMdev] A bug in LLVM-GCC 4.2 with inlining __exchange_and_add

Hi,
I have encountered an issue which seems to be a serious reproducible bug in
LLVM-GCC 4.2. It can be reproduced by compiling the following C++ file that uses
boost:#include "boost/statechart/event.hpp"


using namespace std;


class EvActivate : public boost::statechart::event< EvActivate >
{
public:
    EvActivate(){}
    
private:
};


extern "C" const void* activate()
{
    return (EvActivate()).intrusive_from_this().get();
}
The problem is that the generated assembler looks like:_activate:00000000	   
b5f0	push	{r4, r5, r6, r7, lr}00000002	    af03	add	r7, sp, #1200000004	e92d0d00
stmdb	sp!, {r8, sl, fp}00000008	ed2d8b10	vstmdb	sp!, {d8-d15}0000000c	    b094
sub	sp, #800000000e	f2405088	movw	r0,
:lower16:__ZN5boost10statechart6detail9id_holderI10EvActivateE11idProvider_E-0x24+0xfffffffc00000012
2300	movs	r3, #000000014	f2c00000	movt	r0,
:upper16:__ZN5boost10statechart6detail9id_holderI10EvActivateE11idProvider_E-0x24+0xfffffffc00000018
f2407140	movw	r1, :lower16:0x770-0x2c+0xfffffffc0000001c	f2c00100	movt	r1,
:upper16:0x770-0x2c+0xfffffffc00000020	f24052c8	movw	r2,
:lower16:__ZTV10EvActivate-0x34+0xfffffffc00000024	    4478	add	r0, pc00000026
f2c00200	movt	r2, :upper16:__ZTV10EvActivate-0x34+0xfffffffc0000002a	    9304
str	r3, [sp, #16]0000002c	    4479	add	r1, pc0000002e	    9005	str	r0, [sp,
#20]00000030	    a803	add	r0, sp, #1200000032	    9006	str	r0, [sp, #24]00000034
447a	add	r2, pc00000036	f8ddc018	ldr.w	ip, [sp, #24]0000003a	    3004	adds	r0,
#40000003c	    9001	str	r0, [sp, #4]0000003e	    6808	ldr	r0, [r1, #0]00000040
f1020108	add.w	r1, r2, #8	@ 0x800000044	f8cc1000	str.w	r1, [ip]00000048	f3bf8f5a
dmb	ishst0000004c	    9901	ldr	r1, [sp, #4]0000004e	e8512f00	ldrex	r2,
[r1]00000052	    9200	str	r2, [sp, #0]00000054	    441a	add	r2, r300000056
e8412c00	strex	ip, r2, [r1]0000005a	f1bc0f00	cmp.w	ip, #0	@ 0x00000005e	    d1f6
bne.n	0x4e...
What happens in the code between 4e and 5e is an atomic check of a variable by
the inlined __exchange_and_add. The problem is that the result read by ldrex is
stored by the inline optimization on the stack for further use. However, as the
atomically read variable is also on the stack and resides very close to this
compiler-induced intermediate storage - the write hits the ERG. On Apple's
A6X devices this reproduced consistently - the code entered a perpetual loop, as
the str instruction at 0x52 caused the srtex at 0x56 to always fail and always
return 1 and the following branch started it all over.
Generating such code violates the ARM recommendation:"For these reasons ARM
recommends that:the Load-Exclusive and Store-Exclusive are no more than 128
bytes apartno explicit cache maintenance operations or data accesses are
performed between the Load-Exclusive and the Store-Exclusive."
I've encountered this issue in a real code and would be glad to get the
feedback on it. Please let me know if I need to submit a bug somewhere to get it
resolved. I've found out that clang does not have this problem.

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

> I've encountered this issue in a real code and would be glad to get the
> feedback on it. Please let me know if I need to submit a bug somewhere to
get it resolved. I've found out that clang does not have this problem.
Then use clang. llvm-gcc is deprecated.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Feb 3, 2013, at 2:32 AM, Anton Korobeynikov <anton at
korobeynikov.info> wrote:
>> I've encountered this issue in a real code and would be glad to get
the
>> feedback on it. Please let me know if I need to submit a bug somewhere
to get it resolved. I've found out that clang does not have this problem.
> Then use clang. llvm-gcc is deprecated.
I'd go farther: llvm-gcc is quite dead now.

-Chris