public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jeff Law <law@redhat.com>
Cc: Xi Ruoyao <xry111@mengyan1223.wang>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)
Date: Mon, 4 Jan 2021 22:00:18 +0100	[thread overview]
Message-ID: <20210104210018.GD725145@tucnak> (raw)
In-Reply-To: <c87e5369-50b1-2927-284c-9e8e74f3972e@redhat.com>

On Mon, Jan 04, 2021 at 01:51:59PM -0700, Jeff Law via Gcc-patches wrote:
> > Sorry, I forgot to include the ChangeLog:
> >
> >     gcc/ChangeLog:
> >     
> >     2020-12-31  Xi Ruoyao <xry111@mengyan1223.wang>
> >     
> >             PR target/98491
> >             * config/mips/mips.c (mips_symbol_insns): Do not use
> >               MSA_SUPPORTED_MODE_P if mode is MAX_MACHINE_MODE.
> So I absolutely agree the current code is wrong as it does an out of
> bounds array access.
> 
> 
> Would it be better to instead to change MSA_SUPPORTED_MODE_P to evaluate
> to zero if MODE is MAX_MACHINE_MODE?  That would protect all the uses of
> MSA_SUPPORTED_MODE_P.    Something like this perhaps?

But MAX_MACHINE_MODE is the one past last valid mode, I'm not aware of
any target that would protect all macros that deal with modes that way.

So, perhaps best would be stop using the MAX_MACHINE_MODE as magic value
for that function and instead use say VOIDmode that shouldn't normally
appear either?

But I don't really see anything wrong on the mips_symbol_insns above
change either.

	Jakub


  reply	other threads:[~2021-01-04 21:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-31 23:29 [PATCH] MIPS: Fix PR target/98491 Xi Ruoyao
2020-12-31 23:34 ` [PATCH] MIPS: Fix PR target/98491 (ChangeLog) Xi Ruoyao
2021-01-04 20:51   ` Jeff Law
2021-01-04 21:00     ` Jakub Jelinek [this message]
2021-01-04 21:19       ` Jeff Law
2021-01-10 17:01         ` Xi Ruoyao
2021-01-10 17:04           ` Xi Ruoyao
2021-02-12 14:17           ` Xi Ruoyao
2021-02-12 14:54             ` Xi Ruoyao
2021-02-12 14:57               ` Xi Ruoyao
2021-02-12 15:15                 ` Xi Ruoyao
2021-02-15 23:16             ` Jeff Law
2021-02-16  3:59               ` Xi Ruoyao
2021-02-17 11:13                 ` Xi Ruoyao
2021-02-17 12:02                   ` Richard Sandiford
2021-03-02 23:16                     ` Jeff Law

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=20210104210018.GD725145@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=xry111@mengyan1223.wang \
    /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).