Bug 1349067

Created attachment 1170872 [details]
lxqt-config-0.10.0-5.el7 mock EPEL7 build log

Full build log from the mock build.

Also seen in https://bugzilla.suse.com/show_bug.cgi?id=980495; despite what is written there, this might actually be PR 63190, in which case the fix should be:

https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00383.html

Reassigning to RHEL gcc.

It's not PR63190 after all, as 4.8 completely precedes that code.

I can confirm that this ICEs with GCC 4.8 and doesn't ICE with GCC 4.9.  But so far my attempts to bisect the fix failed.

Reduced testcase from the PR -O2 -fPIC:
struct A { float x; float y; };
A a, b, c;
int d, e;
A bar ();
void foo (A, A);
inline A operator/ (A, A p2) { if (p2.x) return a; }
struct B { A dval; };
int baz (A, B, A, int);

void
test ()
{
  B q;
  A f, g, h, k;
  h.x = 1.0;
  f = h;
  struct A i, j = f;
  do {
    i = bar ();
    g = i / j;
    foo (g, c);
    int l = baz (k, q, b, e);
    if (l)
      goto cleanup;
    j = i;
  } while (d);
cleanup:;
}

These seems to be a reload or backend bug (4.8 still uses reload on aarch64, 4.9 uses LRA by default and supports -mno-lra and 5+ only supports LRA).
In *.ira we have:
(insn 3 115 101 2 (set (reg:SF 78 [ j ])
        (const_double:SF 1.0e+0 [0x0.8p+1])) pr70549.ii:17 38 {*movsf_aarch64}
     (expr_list:REG_EQUAL (const_double:SF 1.0e+0 [0x0.8p+1])
        (nil)))
where:
(define_insn "*movsf_aarch64"
  [(set (match_operand:SF 0 "nonimmediate_operand" "=w, ?r,w,w  ,w,m,r,m ,r")
        (match_operand:SF 1 "general_operand"      "?rY, w,w,Ufc,m,w,m,rY,r"))]
but in *.reload we end up with:
(insn 119 115 3 2 (set (reg:SF 0 x0)
        (const_double:SF 1.0e+0 [0x0.8p+1])) pr70549.ii:17 38 {*movsf_aarch64}
     (nil))
(insn 3 119 101 2 (set (mem/c:SF (plus:DI (reg/f:DI 29 x29)
                (const_int 96 [0x60])) [4 %sfp+-16 S4 A128])
        (reg:SF 0 x0)) pr70549.ii:17 38 {*movsf_aarch64}
     (expr_list:REG_EQUAL (const_double:SF 1.0e+0 [0x0.8p+1])
        (nil)))
x0 is a GPR register, so it only allows sources to be a FP/SIMD register, or memory, or another GPR register, so the above is wrong, 1.0e+0 constant matches the Ufc constraint and thus could be only used with a FP/SIMD register destination.
Reloads for insn # 3
Reload 0: reload_out (SF) = (reg:SF 78 [ j ])
        NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
        reload_out_reg: (reg:SF 78 [ j ])
Reload 1: reload_in (SF) = (const_double:SF 1.0e+0 [0x0.8p+1])
        CORE_REGS, RELOAD_FOR_INPUT (opnum = 1)
        reload_in_reg: (const_double:SF 1.0e+0 [0x0.8p+1])
        reload_reg_rtx: (reg:SF 0 x0)

Unfortunately, it seems that the patch is missing in gcc-4.8.5-14.el7.src.rpm and also, the same gcc still reproduces ICE with the code from comment #6.

Fixed again in gcc-4.8.5-15.el7.

So, gcc-4.8.5-16.el7.aarch64 seems to be OK, it passes the related test, also manually, it compiles the example from comment #6 and does not reproduce the ICE.

This bz can be pushed to VERIFIED when it reaches the ON_QA state.

As per comment #14, switching to VERIFIED.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2094