public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Richard Biener <richard.guenther@gmail.com>
Cc: will schmidt <will_schmidt@vnet.ibm.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	David Edelsohn <dje.gcc@gmail.com>
Subject: Re: [PATCH, rs6000] Fix Vector long long subtype (PR96139)
Date: Fri, 4 Sep 2020 03:47:15 -0500	[thread overview]
Message-ID: <20200904084715.GE28786@gate.crashing.org> (raw)
In-Reply-To: <CAFiYyc1fnVW34WMuinmPWkz+8uQf3zuQmZ-ooKaYOW=E8fST7A@mail.gmail.com>

Hi!

On Fri, Sep 04, 2020 at 08:55:43AM +0200, Richard Biener wrote:
> On Thu, Sep 3, 2020 at 8:10 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Thu, Sep 03, 2020 at 10:37:33AM -0500, will schmidt wrote:
> > > On Wed, 2020-09-02 at 05:13 -0500, Segher Boessenkool wrote:
> > > > On Tue, Sep 01, 2020 at 09:00:20PM -0500, will schmidt wrote:
> > > > > -  V2DI_type_node = rs6000_vector_type (TARGET_POWERPC64 ?
> > > > > "__vector long"
> > > > > -                                : "__vector long long",
> > > > > -                                intDI_type_node, 2);
> > > > > +  V2DI_type_node
> > > > > +    = rs6000_vector_type (TARGET_POWERPC64
> > > > > +                   ? "__vector long" : "__vector long long",
> > > > > +                   TARGET_POWERPC64
> > > > > +                   ? long_long_integer_type_node :
> > > > > intDI_type_node,
> > > > > +                   2);
> > > >
> > > > Can't you just use long_long_integer_type_node in all cases?  Or,
> > > > what
> > > > else is intDI_type_node for 32 bit?
> > >
> > > I'm not sure offhand.  I'm tending to assume the use of intDI_type_node
> > > is critical for some underlying reason.    I'll give this a spin with
> > > just long_long_integer_type_node and see what happens.
> >
> > If that works, that is okay for trunk (and all backports you want).  If
> > not, just use what you sent.
> 
> Beware of alias issues!  'long' and 'long long' are distinct types even if
> they have the same size and long * aliases with vector<long> * but not
> with vector<long long> *.

That is what this patch is all about, so I do beware (right now ;-) ),
don't worry :-)

> So if the user writes 'vector long' you should use the appropriate component
> type.  If the user writes 'vector intDI_type' you should use intDI_type.

Yes.  But intDI is not something the user can write, it is an internal
name, and for 32 bit it is just long long int.  We use intDI if
something is long on 64 bit and long long on 32 bit, but here we always
want long long, so we can just as well just write that :-)

  intDI_type_node = make_or_reuse_type (GET_MODE_BITSIZE (DImode), 0);


Segher

  reply	other threads:[~2020-09-04  8:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02  2:00 will schmidt
2020-09-02 10:13 ` Segher Boessenkool
2020-09-03 15:37   ` will schmidt
2020-09-03 18:09     ` Segher Boessenkool
2020-09-04  6:55       ` Richard Biener
2020-09-04  8:47         ` Segher Boessenkool [this message]
2020-09-04 14:47           ` will schmidt

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=20200904084715.GE28786@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    --cc=will_schmidt@vnet.ibm.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).