https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #100 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #99)
> Hm .. those don't fail on sh-elf ... maybe something related to the atomics?
> Atomics are off by default for sh-elf, but on for sh-linux.

Maybe.  It could be something atomic related.
For 14.cc case, replacing locale.o and cxx11-shim_facets.o with
ones from non-LRA build fixes the failure.
For example, std::locale::locale(std::locale const&) is compiled
very differently in LRA/non-LRA builds.  Strangely, the problem
can't be reproduced with recompiling these objects with -mlra in
non-LRA builds.  The above constructor is compiled to

[LRA build]
   0:   c6 2f           mov.l   r12,@-r15
   2:   0b c7           mova    30 <_ZNSt6localeC1ERKS_+0x30>,r0
   4:   0a dc           mov.l   30 <_ZNSt6localeC1ERKS_+0x30>,r12       ! 0
<_ZNSt6localeC1ERKS_>
   6:   0c 3c           add     r0,r12
   8:   52 62           mov.l   @r5,r2
   a:   0a d0           mov.l   34 <_ZNSt6localeC1ERKS_+0x34>,r0        ! 0
<_ZNSt6localeC1ERKS_>
   c:   ce 01           mov.l   @(r0,r12),r1
   e:   18 21           tst     r1,r1
  10:   09 8d           bt.s    26 <_ZNSt6localeC1ERKS_+0x26>
  12:   22 24           mov.l   r2,@r4
  14:   02 c7           mova    20 <_ZNSt6localeC1ERKS_+0x20>,r0
  16:   f3 61           mov     r15,r1
  18:   fa ef           mov     #-6,r15
  1a:   22 63           mov.l   @r2,r3
  1c:   01 73           add     #1,r3
  1e:   32 22           mov.l   r3,@r2
  20:   13 6f           mov     r1,r15
  22:   0b 00           rts     
  24:   f6 6c           mov.l   @r15+,r12
  26:   22 61           mov.l   @r2,r1
  28:   01 71           add     #1,r1
  2a:   12 22           mov.l   r1,@r2
  2c:   0b 00           rts     
  2e:   f6 6c           mov.l   @r15+,r12
        ...
                        30: R_SH_GOTPC  _GLOBAL_OFFSET_TABLE_
                        34: R_SH_GOT32  __pthread_key_create
[non-LRA build]
   0:   c6 2f           mov.l   r12,@-r15
   2:   0b c7           mova    30 <_ZNSt6localeC1ERKS_+0x30>,r0
   4:   0a dc           mov.l   30 <_ZNSt6localeC1ERKS_+0x30>,r12       ! 0
<_ZNSt6localeC1ERKS_>
   6:   22 4f           sts.l   pr,@-r15
   8:   0c 3c           add     r0,r12
   a:   52 61           mov.l   @r5,r1
   c:   09 d0           mov.l   34 <_ZNSt6localeC1ERKS_+0x34>,r0        ! 0
<_ZNSt6localeC1ERKS_>
   e:   ce 02           mov.l   @(r0,r12),r2
  10:   28 22           tst     r2,r2
  12:   07 8d           bt.s    24 <_ZNSt6localeC1ERKS_+0x24>
  14:   12 24           mov.l   r1,@r4
  16:   13 64           mov     r1,r4
  18:   07 d1           mov.l   38 <_ZNSt6localeC1ERKS_+0x38>,r1        ! 1a
  1a:   03 01           bsrf    r1
  1c:   01 e5           mov     #1,r5
  1e:   26 4f           lds.l   @r15+,pr
  20:   0b 00           rts     
  22:   f6 6c           mov.l   @r15+,r12
  24:   12 62           mov.l   @r1,r2
  26:   01 72           add     #1,r2
  28:   22 21           mov.l   r2,@r1
  2a:   26 4f           lds.l   @r15+,pr
  2c:   0b 00           rts     
  2e:   f6 6c           mov.l   @r15+,r12
        ...
                        30: R_SH_GOTPC  _GLOBAL_OFFSET_TABLE_
                        34: R_SH_GOT32  __pthread_key_create
  38:   1a 00           sts     macl,r0
                        38: R_SH_PLT32  _ZN9__gnu_cxx12__atomic_addEPVii
        ...

Perhaps the both codes are ok, though something odd happens
on atomic things anyway.

Reply via email to