public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Mikael Pettersson <mikpelinux@gmail.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]
Date: Fri, 19 Jan 2024 16:07:46 -0700	[thread overview]
Message-ID: <dacf29e0-1551-496e-b99c-dda7abc47bc6@gmail.com> (raw)
In-Reply-To: <20240118164052.11548-1-mikpelinux@gmail.com>



On 1/18/24 09:39, Mikael Pettersson wrote:
> When generating RMW logical operations on m68k, the backend
> recognizes single-bit operations and rewrites them as bit
> instructions on operands adjusted to address the intended byte.
> When offsetting the addresses the backend keeps the modes as
> SImode, even though the actual access will be in QImode.
> 
> The uclinux target defines M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
> which adds a check that the adjusted operand is within the bounds
> of the original object.  Since the address has been offset it is
> not, and the compiler ICEs.
> 
> The bug is that the modes of the adjusted operands should have been
> narrowed to QImode, which is that this patch does.  Nearby code
> which narrows to HImode gets that right.
> 
> Bootstrapped and regression tested on m68k-linux-gnu.
> 
> Ok for master? (Note: I don't have commit rights.)
> 
> gcc/
> 
> 	PR target/108640
> 	* config/m68k/m68k.cc (output_andsi3): Use QImode for
> 	address adjusted for 1-byte RMW access.
> 	(output_iorsi3): Likewise.
> 	(output_xorsi3): Likewise.
> 
> gcc/testsuite/
> 
> 	PR target/108640
> 	* gcc.target/m68k/pr108640.c: New test.
While not really a regression, this can clearly only affect the m68k 
target and fixes an ICE.  So I went ahead and pushed it to the trunk.

Just a note for the future, the test really isn't m68k specific in that 
it should compile just fine on any target GCC supports.  It just 
happened to ICE on the m68k.  We generally prefer to put such tests in 
target independent directories.  dg-torture, c-torture would be better 
choices for this kind of test in the future.

Thanks.

Jeff

      reply	other threads:[~2024-01-19 23:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18 16:39 Mikael Pettersson
2024-01-19 23:07 ` Jeff Law [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=dacf29e0-1551-496e-b99c-dda7abc47bc6@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mikpelinux@gmail.com \
    /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).