public inbox for
 help / color / mirror / Atom feed
From: Segher Boessenkool <>
To: Alexandre Oliva <>
	David Edelsohn <>
Subject: Re: [PATCH] libstdc++: ppc: conditionalize vsx-only simd intrinsics
Date: Thu, 28 Apr 2022 08:03:06 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On Thu, Apr 28, 2022 at 03:09:54AM -0300, Alexandre Oliva wrote:
> libstdc++'s bits/simd.h section for PPC (Altivec) defines various
> 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.
> experimental/simd/standard_abi_usable{,_2}.cc tests error out reporting
> the unmet requirements when the target cpu doesn't enable VSX.  Make the
> reported instrinsic types conditional on VSX so that <experimental/simd>
> can be used on ppc variants that do not have VSX support.

> 	* include/experimental/bits/simd.h [__ALTIVEC__]: Require VSX
> 	for double, long long, and 64-bit long and 64-bit long double
> 	intrinsic types.

> --- a/libstdc++-v3/include/experimental/bits/simd.h
> +++ b/libstdc++-v3/include/experimental/bits/simd.h
> @@ -2430,17 +2430,23 @@ template <typename _Tp>
>    template <>                                                                  \
>      struct __intrinsic_type_impl<_Tp> { using type = __vector _Tp; }
> +# ifdef __VSX__

No space after # (here and everywhere else).

>  #ifndef __VSX__
> -    static_assert(!is_same_v<_Tp, double>,
> -		  "no __intrinsic_type support for double on PPC w/o VSX");
> +    static_assert(!(is_same_v<_Tp, double>
> +		    || (_S_is_ldouble && sizeof(long double) == sizeof(double))),
> +		  "no __intrinsic_type support for [long] double on PPC w/o VSX");
>  #endif

This change isn't in the changelog.  The message should not say "long
double" without qualifying it as "64-bit long double".  It is probably
best to just keep the message as-is, the other possibilities for long
double aren't supported either, not even with VSX, and all this becomes
much too complicated to put in a simple error message.  It confuses the
poor user, as well.

Alternatively you can make it two separate error messages, one for
double, one for 64-bit long double.

Okay for trunk without this part of the patch, and the spaces after the
hash signs deleted.  Or send a new patch with the "[long] double" thing



  reply	other threads:[~2022-04-28 13:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28  6:09 Alexandre Oliva
2022-04-28 13:03 ` Segher Boessenkool [this message]
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
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).