[Bug target/53020] New: __atomic_fetch_or doesn't generate `1 insn` variant

[kirill.yukhin at intel dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020

             Bug #: 53020
           Summary: __atomic_fetch_or doesn't generate `1 insn` variant
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: kirill.yuk...@intel.com


Hello,
while working on Intel's TSX extensions, I've found strange (to me) thing.

We have in config/i386/sync.md:
(define_insn "atomic_<code><mode>"
  [(set (match_operand:SWI 0 "memory_operand" "+m")
        (unspec_volatile:SWI
          [(any_logic:SWI (match_dup 0)
                          (match_operand:SWI 1 "nonmemory_operand" "<r><i>"))
           (match_operand:SI 2 "const_int_operand")]            ;; model
          UNSPECV_LOCK))
...

any_logic covers (unconditionally) covers AND IOR and XOR ops.

However, generated insn-opinit.c lacks IOR variant initalization:
...
set_direct_optab_handler (atomic_and_optab, QImode, CODE_FOR_atomic_andqi);
set_direct_optab_handler (atomic_xor_optab, QImode, CODE_FOR_atomic_xorqi);
...

So, having such simple test:
void
foo (int *p, int v)
{
  __atomic_fetch_or (p, 1, __ATOMIC_ACQUIRE | __ATOMIC_HLE_ACQUIRE);
}

`lock orl      %edx, (%eax)` wont' be generated, since there is no
corresponding occurence in IOR optab.
Here is the code, that fails to find it:
optabs.c:maybe_emit_op
...
      if (use_memmodel)
        {
          icode = direct_optab_handler (optab->mem_no_result, mode);
...

The most strange thing to me is that it works fine with XOR and AND ops.