public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/94941] New: Expansion of some internal fns can drop the lhs on the floor Date: Mon, 04 May 2020 08:49:46 +0000 [thread overview] Message-ID: <bug-94941-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941 Bug ID: 94941 Summary: Expansion of some internal fns can drop the lhs on the floor Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org Target Milestone: --- internal-fn.c:expand_mask_load_optab_fn uses expand_insn to emit the load instruction, but doesn't then test whether the coerced output operand is the same as the target of the gcall. It might not be, for example, in unoptimised code, where the target of the gcall expands to a MEM rtx and the load insn requires a REG destination. We need the equivalent of: if (!rtx_equal_p (lhs_rtx, ops[0].value)) emit_move_insn (lhs_rtx, ops[0].value); in expand_while_optab_fn. This can be seen for AArch64 with the following test, compiled with -O0 -march=armv8.2-a+sve: ---------------------------------------------------------- #include <arm_sve.h> svfloat32_t foo (float *ptr) { svbool_t pg = svptrue_pat_b32 (SV_VL1); svfloat32_t res = svld1 (pg, ptr); return res; } int main (void) { svbool_t pg = svptrue_pat_b32 (SV_VL1); float x[1] = { 1 }; if (svptest_any (pg, svcmpne (pg, foo (x), 1.0))) __builtin_abort (); return 0; } ---------------------------------------------------------- We emit: ;; res_5 = .MASK_LOAD (ptr_4(D), 4B, _2); (insn 9 8 10 (set (reg/f:DI 96) (mem/f/c:DI (plus:DI (reg/f:DI 87 virtual-stack-vars) (const_poly_int:DI [-40, -32])) [3 ptr+0 S8 A64])) "/tmp/foo.c":7:21 -1 (nil)) (insn 10 9 0 (set (reg:VNx4SF 97) (unspec:VNx4SF [ (reg:VNx4BI 92 [ _2 ]) (mem:VNx4SF (reg/f:DI 96) [0 MEM <svfloat32_t> [(float *)ptr_4(D)]+0 S[16, 16] A8]) ] UNSPEC_LD1_SVE)) "/tmp/foo.c":7:21 -1 (nil)) but don't store reg 97 to the stack slot for "res". Then the return statement loads from "res": (insn 12 11 0 (set (reg:VNx4SF 93 [ _6 ]) (unspec:VNx4SF [ (subreg:VNx4BI (reg:VNx16BI 98) 0) (mem/c:VNx4SF (plus:DI (reg/f:DI 87 virtual-stack-vars) (const_poly_int:DI [-32, -32])) [2 res+0 S[16, 16] A128]) ] UNSPEC_PRED_X)) "/tmp/foo.c":8:10 -1 (nil)) meaning we return uninitialised stack contents. The same problem affects expand_load_lanes_optab_fn and expand_gather_load_optab_fn. I think this problem has existed since the mask load/store functions were introduced, but it was probably latent until GCC 10 because nothing would use them in unoptimised code.
next reply other threads:[~2020-05-04 8:49 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-04 8:49 rsandifo at gcc dot gnu.org [this message] 2020-05-04 8:55 ` [Bug middle-end/94941] " rsandifo at gcc dot gnu.org 2020-05-04 20:22 ` cvs-commit at gcc dot gnu.org 2020-05-04 20:22 ` cvs-commit at gcc dot gnu.org 2020-05-04 20:24 ` rsandifo at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-94941-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).