From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 5698F3858413; Fri, 6 May 2022 16:16:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5698F3858413 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 246GELSl030961; Fri, 6 May 2022 11:14:21 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 246GELAQ030960; Fri, 6 May 2022 11:14:21 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 6 May 2022 11:14:21 -0500 From: Segher Boessenkool To: Alexandre Oliva Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, David Edelsohn Subject: Re: [PATCH v2] libstdc++: ppc: conditionalize vsx-only simd intrinsics Message-ID: <20220506161421.GJ25951@gate.crashing.org> References: <20220428130306.GS25951@gate.crashing.org> <20220502213619.GW25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2022 16:16:25 -0000 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 anyway?) > 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 > 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! Segher