Bug 1349067
Summary: | lxqt-config FTBFS on aarch64 epel7 | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | D. Marlin <dmarlin> | ||||
Component: | gcc | Assignee: | Marek Polacek <mpolacek> | ||||
Status: | CLOSED ERRATA | QA Contact: | Michael Petlan <mpetlan> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.2 | CC: | bschmidt, helio, law, mcermak, mnewsome, mpetlan, mpolacek, perobins, rdieter, ti.eugene, vmakarov, yselkowi | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | aarch64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | gcc-4.8.5-15.el7 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2017-08-01 22:35:59 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1285484, 1357680, 1390370 | ||||||
Attachments: |
|
Description
D. Marlin
2016-06-22 15:59:51 UTC
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 |