From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id A4EEA3858D39 for ; Wed, 20 Sep 2023 14:56:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A4EEA3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 688BD1FB; Wed, 20 Sep 2023 07:57:33 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CD9C13F5A1; Wed, 20 Sep 2023 07:56:55 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Richard Biener via Gcc-patches , richard.sandiford@arm.com Cc: Richard Biener via Gcc-patches Subject: Re: [PATCH][RFC] middle-end/106811 - document GENERIC/GIMPLE undefined behavior References: <20230915115010.D2F8513251@imap2.suse-dmz.suse.de> Date: Wed, 20 Sep 2023 15:56:54 +0100 In-Reply-To: (Richard Biener's message of "Wed, 20 Sep 2023 13:45:49 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-24.8 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Richard Biener writes: > On Wed, 20 Sep 2023, Richard Sandiford wrote: > >> Thanks for doing this. Question below... >> >> Richard Biener via Gcc-patches writes: >> > The following attempts to provide a set of conditions GENERIC/GIMPLE >> > considers invoking undefined behavior, leaning on the C standards >> > Annex J, as to provide portability guidance to language frontend >> > developers. >> > >> > I've both tried to remember cases we exploit undefined behavior >> > and went over C2x Annex J to catch more stuff. I'd be grateful >> > if people could point out obvious omissions or cases where the >> > wording isn't clear. I plan to check/amend the individual operator >> > documentations as well, but not everything fits there. >> > >> > I've put this into generic.texi because it applies to GENERIC as >> > the frontend interface. All constraints apply to GIMPLE as well. >> > I plan to add a section to gimple.texi as to how to deal with >> > undefined behavior. >> > >> > As said, every comment is welcome. >> > >> > For testing I've built doc and inspected the resulting pdf. >> > >> > PR middle-end/106811 >> > * doc/generic.texi: Add portability section with >> > subsection on undefined behavior. >> > --- >> > gcc/doc/generic.texi | 87 ++++++++++++++++++++++++++++++++++++++++++++ >> > 1 file changed, 87 insertions(+) >> > >> > diff --git a/gcc/doc/generic.texi b/gcc/doc/generic.texi >> > index 6534c354b7a..0969f881146 100644 >> > --- a/gcc/doc/generic.texi >> > +++ b/gcc/doc/generic.texi >> > @@ -43,6 +43,7 @@ seems inelegant. >> > * Functions:: Function bodies, linkage, and other aspects. >> > * Language-dependent trees:: Topics and trees specific to language front ends. >> > * C and C++ Trees:: Trees specific to C and C++. >> > +* Portability issues:: Portability summary for languages. >> > @end menu >> > >> > @c --------------------------------------------------------------------- >> > @@ -3733,3 +3734,89 @@ In either case, the expression is void. >> > >> > >> > @end table >> > + >> > + >> > +@node Portability issues >> > +@section Portability issues >> > + >> > +This section summarizes portability issues when translating source languages >> > +to GENERIC. Everything written here also applies to GIMPLE. This section >> > +heavily relies on interpretation according to the C standard. >> > + >> > +@menu >> > +* Undefined behavior:: Undefined behavior. >> > +@end menu >> > + >> > +@node Undefined behavior >> > +@subsection Undefined behavior >> > + >> > +The following is a list of circumstances that invoke undefined behavior. >> > + >> > +@itemize @bullet >> > +@item >> > +When the result of negation, addition, subtraction or division of two signed >> > +integers or signed integer vectors not subject to @option{-fwrapv} cannot be >> > +represented in the type. >> >> Couldn't tell: is the omission of multiplication deliberate? > > No. Fixed. Do you by chance remember/know anything about RTL 'div' > and behavior on overflow (INT_MIN/-1), in particular with -fwrapv? No, sorry. I thought SDIV was allowed (but not required) to trap on overflow, but I don't know off-hand what effect -fwrapv has on the way that we use it. Richard