This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/67391] [SH] Convert clrt addc to normal add insn


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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #36396|0                           |1
        is obsolete|                            |

--- Comment #22 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 36400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36400&action=edit
Another trail, works with LRA

(In reply to Kazumoto Kojima from comment #21)
> No new failures with -mlra here too.  The test without -mlra is still
> running, though there is a new failure:
> 
> /home/ldroot/dodes/xsh-gcc/gcc/xgcc -B/home/ldroot/dodes/xsh-gcc/gcc/
> -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -ffat-lto-objects
> -c -o sync-3.o
> /exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c
> /exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c:
> In function 'test_op_ignore':
> /exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c:
> 75:3: note: '__sync_fetch_and_nand' changed semantics in GCC 4.4
> /exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c:
> In function 'test_fetch_and_op':
> /exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c:
> 164:1: error: insn does not satisfy its constraints:
> (insn 729 728 42 2 (set (reg:SI 7 r7)
>         (plus:SI (reg:SI 0 r0)
>             (const_int 0 [0])))

Thanks.  I could reproduce it here with "-O1 -m4 -ml
-matomic-model=soft-gusa,strict" and this snippet:

void test_fetch_and_op (void)
{
signed char sc[2];
unsigned char uc[2];
signed short ss[2];
unsigned short us[2];
signed int si[2];
unsigned int ui[2];
signed long sl[2];
unsigned long ul[2];
signed long long sll[2];
unsigned long long ull[2];

  sc[1] = __sync_fetch_and_and (&sc[1], -11);
  uc[1] = __sync_fetch_and_and (&uc[1], -11);
  ss[1] = __sync_fetch_and_and (&ss[1], -11);
  us[1] = __sync_fetch_and_and (&us[1], -11);
  si[1] = __sync_fetch_and_and (&si[1], -11);
  ui[1] = __sync_fetch_and_and (&ui[1], -11);
  sl[1] = __sync_fetch_and_and (&sl[1], -11);
  sll[1] = __sync_fetch_and_and (&sll[1], -11);
  ull[1] = __sync_fetch_and_and (&ull[1], -11);

  sc[1] = __sync_fetch_and_nand (&sc[1], -11);
  uc[1] = __sync_fetch_and_nand (&uc[1], -11);
  ss[1] = __sync_fetch_and_nand (&ss[1], -11);
  us[1] = __sync_fetch_and_nand (&us[1], -11);
  ul[1] = __sync_fetch_and_nand (&ul[1], -11);
}

Maybe I should run sh-elf tests with -matomic-model=<something> to catch
those...

I couldn't really catch where the const_int 0 gets in.  It happens during
reload, but not through the addsi3 expander.  Then *addsi3 ends up with
non-overlapping-regs operands[0] and operands[1] and operands[2] == const0_rtx,
which effectively is a reg-reg move.  So I've added handling of this case to
the splitters and it seems to fix the problem.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]