Bug 1349067 - lxqt-config FTBFS on aarch64 epel7
Summary: lxqt-config FTBFS on aarch64 epel7
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gcc
Version: 7.2
Hardware: aarch64
OS: Linux
Target Milestone: rc
: ---
Assignee: Marek Polacek
QA Contact: Michael Petlan
Depends On:
Blocks: epel7aarch64 1390370 1357680
TreeView+ depends on / blocked
Reported: 2016-06-22 15:59 UTC by D. Marlin
Modified: 2017-08-01 22:35 UTC (History)
12 users (show)

Fixed In Version: gcc-4.8.5-15.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-01 22:35:59 UTC
Target Upstream Version:

Attachments (Terms of Use)
lxqt-config-0.10.0-5.el7 mock EPEL7 build log (281.58 KB, text/plain)
2016-06-22 16:02 UTC, D. Marlin
no flags Details

System ID Priority Status Summary Last Updated
GNU Compiler Collection 70549 None None None 2016-06-22 21:18:03 UTC
Red Hat Product Errata RHBA-2017:2094 normal SHIPPED_LIVE gcc bug fix update 2017-08-01 19:36:07 UTC

Description D. Marlin 2016-06-22 15:59:51 UTC
Description of problem:

lxqt-config fails to build from source for Fedora EPEL7 on RHELSA-7.2.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  On a RHELSA-7.2 host:
     mock -r epel-7-aarch64 lxqt-config-0.10.0-5.el7.src.rpm

Actual results:

/builddir/build/BUILD/lxqt-config-0.10.0/lxqt-config-monitor/monitorpicture.cpp: In member function 'void MonitorPictureDialog::moveMonitorPictureToNearest(MonitorPicture*)':
/builddir/build/BUILD/lxqt-config-0.10.0/lxqt-config-monitor/monitorpicture.cpp:385:1: error: insn does not satisfy its constraints:
(insn 2047 16 17 32 (set (reg:SF 3 x3)
        (const_double:SF -1.0e+0 [-0x0.8p+1])) /builddir/build/BUILD/lxqt-config-0.10.0/lxqt-config-monitor/monitorpicture.cpp:287 38 {*movsf_aarch64}
/builddir/build/BUILD/lxqt-config-0.10.0/lxqt-config-monitor/monitorpicture.cpp:385:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:411

Expected results:

builds without errors.

Additional info:

The same version built successfully for Fedora 23 AArch64:


Comment 1 D. Marlin 2016-06-22 16:02:44 UTC
Created attachment 1170872 [details]
lxqt-config-0.10.0-5.el7 mock EPEL7 build log

Full build log from the mock build.

Comment 2 Yaakov Selkowitz 2016-06-22 16:24:35 UTC
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:


Reassigning to RHEL gcc.

Comment 3 Yaakov Selkowitz 2016-06-22 21:18:04 UTC
It's not PR63190 after all, as 4.8 completely precedes that code.

Comment 4 Marek Polacek 2016-07-12 12:15:27 UTC
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.

Comment 6 Jakub Jelinek 2017-03-07 19:46:06 UTC
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);

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);

Comment 7 Jakub Jelinek 2017-03-08 07:02:24 UTC
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])
(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}
(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])
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)

Comment 12 Michael Petlan 2017-05-31 15:55:34 UTC
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.

Comment 13 Marek Polacek 2017-06-01 08:45:37 UTC
Fixed again in gcc-4.8.5-15.el7.

Comment 14 Michael Petlan 2017-06-05 14:24:02 UTC
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.

Comment 15 Michael Petlan 2017-06-06 10:49:07 UTC
As per comment #14, switching to VERIFIED.

Comment 16 errata-xmlrpc 2017-08-01 22:35:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.