public inbox for
 help / color / mirror / Atom feed
From: Segher Boessenkool <>
To: Alexandre Oliva <>
	David Edelsohn <>
Subject: Re: [PATCH v2] libstdc++: ppc: conditionalize vsx-only simd intrinsics
Date: Fri, 6 May 2022 11:14:21 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, May 02, 2022 at 11:00:02PM -0300, Alexandre Oliva wrote:
> On May  2, 2022, Segher Boessenkool <> wrote:
> > Send full patches always please.
> I'll try to remember that.  In case I fail, I hope you won't mind too
> much reminding me.
> (You'd also asked me not to send patches as followups, but...  revised
> versions of a patch still belong in the same thread, right?)

No.  This makes it much harder to keep versions apart, even worse if you
use patchwork or similar.

The mail with the patch should be the head of a mail thread (or just
below the head if that is a cover mail), and everything below that is
discussion related to that patch.  The mail with the patch should be
ready to be committed as-is, so it should not have mangled whitespace
or encoding, should have proper commit message, etc.  This a) makes it
possible to review what will actualle be committed, and b) it makes it
possible for someone else to commit it (and that includes patch test
systems, often mistakenly called CI or CD, which are completely
different things).

> libstdc++'s bits/simd.h section for PPC (Altivec) defines various

(Spelling: PowerPC, AltiVec.  But this isn't about AltiVec really

> intrinsic vector types that are only available along with VSX: 64-bit
> long double, double, (un)signed long long, and 64-bit (un)signed long.

> +#if defined __VSX__ || __LONG_WIDTH__ == 32
>  _GLIBCXX_SIMD_PPC_INTRIN(signed long);
>  _GLIBCXX_SIMD_PPC_INTRIN(unsigned long);
> +#endif

Is __LONG_WIDTH__ the right macro to use here?  Nothing else in
libstdc++v3 uses it.  "__CHAR_BIT__ * __SIZEOF_LONG__" is the usual
thing to do.  Is __LONG_WIDTH__ always defined anyway?

> @@ -2450,10 +2456,11 @@ template <typename _Tp, size_t _Bytes>
>      static constexpr bool _S_is_ldouble = is_same_v<_Tp, long double>;
>      // allow _Tp == long double with -mlong-double-64
>      static_assert(!(_S_is_ldouble && sizeof(long double) > sizeof(double)),
> -		  "no __intrinsic_type support for long double on PPC");
> +		  "no __intrinsic_type support for 128-bit floating point on PPC");

You might do s/PPC/PowerPC/ at the same time.

Okay for trunk with __LONG_WIDTH__ dealt with.  Okay for the branches
a week or so after that.  Thanks!


  reply	other threads:[~2022-05-06 16:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28  6:09 [PATCH] " Alexandre Oliva
2022-04-28 13:03 ` Segher Boessenkool
2022-04-29  1:53   ` Alexandre Oliva
2022-04-29 18:44     ` Matthias Kretz
2022-05-02 21:36     ` Segher Boessenkool
2022-05-03  2:00       ` [PATCH v2] " Alexandre Oliva
2022-05-06 16:14         ` Segher Boessenkool [this message]
2022-05-06 17:05           ` Jonathan Wakely
2022-05-06 18:24             ` [PATCH v3] " Alexandre Oliva
2022-04-28 13:56 ` [PATCH] " Matthias Kretz
2022-04-28 16:06   ` Segher Boessenkool

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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).