public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch] Fix PR middle-end/92071
Date: Fri, 13 Mar 2020 08:50:27 +0100	[thread overview]
Message-ID: <CAFiYyc18oPxMrS5DFr=ip30vPCog_S62O8Ab7Vu0W1eSEk+xkw@mail.gmail.com> (raw)
In-Reply-To: <2521598.uXN90iOnz7@polaris>

On Fri, Mar 13, 2020 at 8:37 AM Eric Botcazou <ebotcazou@adacore.com> wrote:
>
> Hi,
>
> this is a regression present on the mainline for the ARM in the form of an
> assertion failure at -O2 in the back-end, which rightfully refuses to generate
> a load from an unaligned memory location (the ARM target is strict-alignment).
>
> It comes from a __builtin_memcpy generating:
>
> MEM <unsigned char[8]> [(char * {ref-all})&b] = MEM <unsigned char[8]> [(char
> * {ref-all})a.0_1];
>
> in the .optimized dump, where b is a small union.  As a result, store_field is
> invoked with:
>
> (gdb) p debug_rtx(target)
> (reg/v:DI 113 [ b ])
>
> and sends:
>
> (gdb) p debug_rtx(temp)
> (mem:BLK (reg/f:SI 115) [0 MEM <unsigned char[8]> [(char * {ref-all})a.0_1]+0
> S8 A8])
>
> to store_bit_field with 64 bits and BLKmode.  The unaligned memory reference
> is then generated by store_integral_bit_field, which does:
>
> rtx value_word = operand_subword_force (value, wordnum, value_mode);
>
> thus creating an unaligned word mode (SImode) load.
>
> store_integral_bit_field is ready to handle BLKmode fields, there is even a
> subtlety with their handling on big-endian targets, see PR middle-end/50325,
> but not if they are unaligned, so the fix is simply to call extract_bit_field
> for them in order to generate an unaligned load.  As a bonus, this subsumes
> the big-endian specific path that was added under PR middle-end/50325.
>
> Bootstrapped/regtested on x86-64/Linux and SPARC/Solaris, OK for mainline?

OK.

Thanks,
Richard.

>
> 2019-03-13  Eric Botcazou  <ebotcazou@adacore.com>
>
>         PR middle-end/92071
>         * expmed.c (store_integral_bit_field): For fields larger than a word,
>         call extract_bit_field on the value if the mode is BLKmode.  Remove
>         specific path for big-endian targets and tidy things up a little bit.
>
>
> 2019-03-13  Eric Botcazou  <ebotcazou@adacore.com>
>
>         * gcc.c-torture/compile/20200313-1.c: New test.
>
> --
> Eric Botcazou

      reply	other threads:[~2020-03-13  7:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-13  7:36 Eric Botcazou
2020-03-13  7:50 ` Richard Biener [this message]

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='CAFiYyc18oPxMrS5DFr=ip30vPCog_S62O8Ab7Vu0W1eSEk+xkw@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@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: link
Be 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).