This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Fix unaligned TARGET_MEM_REF expansion (PR 91615)
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>, Jeff Law <law at redhat dot com>
- Date: Thu, 5 Sep 2019 06:11:45 +0000
- Subject: [PATCH] Fix unaligned TARGET_MEM_REF expansion (PR 91615)
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yt6GSMLhg+gLFyne9YHJlT7uf+/b4ZbL1T9+0Ee8sog=; b=CEGINh8ZnNxE8f9699CDhEcYy28YJYdi17arM73r9nPG1dMLf6vexKsNtrA+dHhNY2GrsdAnLbly64xvYqR7JErrGYDLsvJHe5i9y88hwJ4JfrlhM0FT/5VMZzWYrcpYvppd2JtBGSSSc/wbSWnuHCEpTHnuGfXqiHZ+IjGnuWsjCrvAu0tJ4CNBkBYcuovVcIJuKfVXdIb7XS9mVhxlFatSGDpDan7zmul3L8YKgRQYhXilxz6rOS/cJhcFiuBhB+5JFhR3FmtWiuFlvVj0WxaHQYRnJWVzSrp7jAWjsc/tbgYkWEM0zKGPuNe9+6/ErG8xH2Z9I1hcWjeLYykshQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h8ZWVWC4LOKUZHuAtfl8ZjLRTXGvGKK8tiLgSNmo6Iv4bAOS4rOzi3uza2hBxpFXXr31EwbdVoPhIgO1HxxmxlSM1/FeMTfC5PlVqk9XNkIVapFF82OS9xLXycOeqDU5tYuRst2f1TYicX9tgANnNF4dOv6oC0/SMiTYz/6frG4VybF555f1hzkn9ywkeSfS/dIvkdLiBTHy+foQhBrLVg82sEautNTCH3woWLM3IDqglvPIknHOsXkSKr0uQ0R4NUbhEx+9Grz4TSFTaFyi5yOvZBI9sLdwfuYiZgwS50Lj/lMWpsoh0Jc/+rTzHp4aBXJn0cPIi4IB7BXwX1/pSw==
Hi,
it turns out the TARGET_MEM_REF causes ICEs in armeb-none-linux-gnueabihf,
a big-endian cross compiler. See PR 91615.
All of them are caused by an unaligned TARGET_MEM_REF for which there is
no movmisalign optab, as it seems.
Fixed by adding extract_bit_field if that happens.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu and used
an armeb cross compiler to check that each of the mentioned test cases
are fixed at -O3 and -Ofast.
Is it OK for trunk?
Thanks
Bernd.
2019-09-04 Bernd Edlinger <bernd.edlinger@hotmail.de>
PR middle-end/91615
* expr.c (expand_expr_real_1): Handle misaligned TARGET_MEM_REF
without movmisalign optab.
Index: gcc/expr.c
===================================================================
--- gcc/expr.c (Revision 275342)
+++ gcc/expr.c (Arbeitskopie)
@@ -10313,7 +10313,6 @@ expand_expr_real_1 (tree exp, rtx target, machine_
{
addr_space_t as
= TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 0))));
- enum insn_code icode;
unsigned int align;
op0 = addr_for_mem_ref (exp, as, true);
@@ -10325,21 +10324,27 @@ expand_expr_real_1 (tree exp, rtx target, machine_
if (modifier != EXPAND_WRITE
&& modifier != EXPAND_MEMORY
&& mode != BLKmode
- && align < GET_MODE_ALIGNMENT (mode)
- /* If the target does not have special handling for unaligned
- loads of mode then it can use regular moves for them. */
- && ((icode = optab_handler (movmisalign_optab, mode))
- != CODE_FOR_nothing))
+ && align < GET_MODE_ALIGNMENT (mode))
{
- class expand_operand ops[2];
+ enum insn_code icode;
- /* We've already validated the memory, and we're creating a
- new pseudo destination. The predicates really can't fail,
- nor can the generator. */
- create_output_operand (&ops[0], NULL_RTX, mode);
- create_fixed_operand (&ops[1], temp);
- expand_insn (icode, 2, ops);
- temp = ops[0].value;
+ if ((icode = optab_handler (movmisalign_optab, mode))
+ != CODE_FOR_nothing)
+ {
+ class expand_operand ops[2];
+
+ /* We've already validated the memory, and we're creating a
+ new pseudo destination. The predicates really can't fail,
+ nor can the generator. */
+ create_output_operand (&ops[0], NULL_RTX, mode);
+ create_fixed_operand (&ops[1], temp);
+ expand_insn (icode, 2, ops);
+ temp = ops[0].value;
+ }
+ else if (targetm.slow_unaligned_access (mode, align))
+ temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
+ 0, unsignedp, NULL_RTX,
+ mode, mode, false, NULL);
}
return temp;
}