[Bug target/59091] __builtin_trap calls abort for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59091 Marcus Shawcroft changed: What|Removed |Added CC||marcus.shawcroft at arm dot com --- Comment #2 from Marcus Shawcroft --- Mark Mitchell proposed a patch some time back, not sure why it didn't get installed: See: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00639.html
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 Marcus Shawcroft changed: What|Removed |Added CC||marcus.shawcroft at arm dot ||com --- Comment #1 from Marcus Shawcroft 2011-03-17 16:14:36 UTC --- The code sequence in question looks like this: dmb sy 1: ldrex r0, ... cmp r0, r1 bne 2f strex r4, r2, .. teq r4, #0 bne 1b dmb sy 2: The ARM Architecture reference manual (section 3.4.5) requires that there are no explicit memory references between the LDREX and the STREX, this requirement does not extended to speculative loads in branch shadows. An LDREX without a following STREX is explicilty permitted by the reference manual (section 3.4.5). The CLREX instruction is provided for use by context switch code in order to prevent a false positive STREX following a context switch (section 3.4.4). The inclusion of a CLREX instruction in the above fragment is not required by the ARM architecture reference manual.
[Bug rtl-optimization/45966] New: Incorrect combiner transformation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45966
Summary: Incorrect combiner transformation.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marcus.shawcr...@arm.com
Created attachment 22015
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22015
Code fragment that exhibits miss compilation.
The change svn 163383 introduced a change causes incorrect compilation of
the attached code fragment at -O2. Found on ARM target, causing boehm garbage
collector to be miss compiled.
Prior to svn:163383 the compiler compiled the attached fragment as:
GC_is_marked:
bicr2, r0, #4080
movwr3, #:lower16:GC_arrays
bicr2, r2, #15
movtr3, #:upper16:GC_arrays
movr1, r2, lsr #22
ubfxip, r2, #12, #10
rsbr2, r2, r0
After svn:163383 we get:
GC_is_marked:
bicr3, r3, #4080
movwr2, #:lower16:GC_arrays
bicr3, r3, #15
movtr2, #:upper16:GC_arrays
movr1, r3, lsr #22
movr0, r0, asl #20
Note the first instruction refers to r3, rather than r0!
It looks to me that the issue arises in the combiner as follows, given:
(insn 2 4 3 2 (set (reg/v/f:SI 152 [ p ])
(reg:SI 0 r0 [ p ])) mark.i:25 165 {*arm_movsi_insn}
(expr_list:REG_DEAD (reg:SI 0 r0 [ p ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:SI 153)
(and:SI (reg/v/f:SI 152 [ p ])
(const_int -4081 [0xf00f]))) mark.i:26 69
{*arm_andsi3_insn}
(nil))
(insn 7 6 8 2 (set (reg:SI 134 [ D.2028 ])
(and:SI (reg:SI 153)
(const_int -16 [0xfff0]))) mark.i:26 69
{*arm_andsi3_insn}
(expr_list:REG_DEAD (reg:SI 153)
(expr_list:REG_EQUAL (and:SI (reg/v/f:SI 152 [ p ])
(const_int -4096 [0xf000]))
(nil
(insn 8 7 9 2 (set (reg:SI 154)
(minus:SI (reg/v/f:SI 152 [ p ])
(reg:SI 134 [ D.2028 ]))) mark.i:28 29 {*arm_subsi3_insn}
(expr_list:REG_DEAD (reg/v/f:SI 152 [ p ])
(nil)))
The combiner does:
Trying 2, 6, 7 -> 8:
...
Successfully matched this instruction:
(set (reg:SI 134 [ D.2028 ])
(and:SI (reg/v/f:SI 152 [ p ])
(const_int -4096 [0xf000])))
Successfully matched this instruction:
(set (reg:SI 154)
(and:SI (reg:SI 0 r0 [ p ])
(const_int 4095 [0xfff])))
deferring deletion of insn with uid = 6.
deferring deletion of insn with uid = 2.
Subsequently insn uid == 2 is deleted leaving (reg 152) in the above fragment
undefined.
[Bug rtl-optimization/45966] Incorrect combiner transformation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45966 --- Comment #2 from Marcus Shawcroft 2010-10-11 14:15:05 UTC --- Hi, ./install/bin/arm-none-eabi-gcc -S -O2 mark.i -da Configured: Target: arm-none-eabi Configured with: /work/home/marcus/arm-work/gcc/configure --target=arm-none-eabi --with-cpu=cortex-a9 --with-float-abi=softfp --with-fpu=neon --prefix=/work/home/marcus/arm-work/install --with-gmp=/work/home/marcus/arm-work/build-arm-none-eabi/host-tools --with-mpfr=/work/home/marcus/arm-work/build-arm-none-eabi/host-tools --with-mpc=/work/home/marcus/arm-work/build-arm-none-eabi/host-tools --disable-shared --disable-nls --disable-threads --disable-tls --disable-lto --enable-checking=yes --enable-languages=c,c++ --with-newlib /Marcus From: bernds at gcc dot gnu.org [gcc-bugzi...@gcc.gnu.org] Sent: 11 October 2010 14:55 To: Marcus Shawcroft Subject: [Bug rtl-optimization/45966] Incorrect combiner transformation. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45966 --- Comment #1 from Bernd Schmidt 2010-10-11 13:55:03 UTC --- Over here the replacement isn't happening due to costs: Successfully matched this instruction: (set (reg:SI 155) (and:SI (reg:SI 0 r0 [ p ]) (const_int 4095 [0xfff]))) rejecting combination of insns 2, 6, 7 and 8 original costs 4 + 4 + 4 + 8 = 20 replacement costs 12 + 12 = 24 What's your exact cc1 command line? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 --- Comment #3 from Marcus Shawcroft 2011-05-24 13:37:03 UTC --- The primitive is required to have lock semantics therefore the load of the old value must be followed by a dmb in the case that the old value comparison succeeds and the swap goes ahead. In the branch out case the final dmb serves no purpose, the swap did not occur and no lock was taken. Therefore the branch over dmb is ok.
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 --- Comment #7 from Marcus Shawcroft 2011-06-23 09:32:59 UTC --- (In reply to comment #5) > Michael: > I think I agree with you on the need for the barrier in the branch out case; > gcc's info page (section 6.49 'Built-in functions for atomic memory access') > state: I agree. The DMB needs to be included in the branch out case in order to comply with the "full barrier" requirement. /Marcus
