From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 0EEDE385803B for ; Thu, 7 Jan 2021 14:20:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0EEDE385803B Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 107E7r1d190055; Thu, 7 Jan 2021 09:20:49 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 35x33r9pge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jan 2021 09:20:49 -0500 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 107E8GIQ192228; Thu, 7 Jan 2021 09:20:48 -0500 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com with ESMTP id 35x33r9pfe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jan 2021 09:20:48 -0500 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 107EIfJI005963; Thu, 7 Jan 2021 14:20:47 GMT Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by ppma01wdc.us.ibm.com with ESMTP id 35tgf9d18d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jan 2021 14:20:47 +0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 107EKiRf11404028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 7 Jan 2021 14:20:44 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6805DC6055; Thu, 7 Jan 2021 14:20:44 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4250EC6059; Thu, 7 Jan 2021 14:20:42 +0000 (GMT) Received: from work-tp (unknown [9.65.216.78]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTPS; Thu, 7 Jan 2021 14:20:41 +0000 (GMT) Date: Thu, 7 Jan 2021 11:20:39 -0300 From: Raoni Fassina Firmino To: Jeff Law Cc: Richard Biener , gcc-patches@gcc.gnu.org, segher@kernel.crashing.org, joseph@codesourcery.com, jakub@redhat.com, hp@bitrange.com, will_schmidt@vnet.ibm.com Subject: Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193] Message-ID: <20210107142039.iypqohea4fbwznqw@work-tp> Mail-Followup-To: Jeff Law , Richard Biener , gcc-patches@gcc.gnu.org, segher@kernel.crashing.org, joseph@codesourcery.com, jakub@redhat.com, hp@bitrange.com, will_schmidt@vnet.ibm.com References: <20201103231150.zlqccshb3qw63bdv@work-tp> <20201104151049.psotxu7xarcxmv5g@work-tp> <0341a102-6c1d-ceb1-ff4a-c9857ad2ec0f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0341a102-6c1d-ceb1-ff4a-c9857ad2ec0f@redhat.com> X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-07_06:2021-01-07, 2021-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 suspectscore=0 priorityscore=1501 spamscore=0 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 mlxscore=0 bulkscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101070088 X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 14:20:56 -0000 It seems to me we have two unrelated concerns mixed in the threads, I will reply in two different sub-threads to make this easier. This one to discuss the values of FE_* macros. On Tue, Nov 17, 2020 at 03:23:02PM -0700, AL gcc-patches wrote: > >>> +@cindex @code{fegetround@var{m}} instruction pattern > >>> +@item @samp{fegetround@var{m}} > >>> +Store the current machine floating-point rounding mode into operand 0. > >>> +Operand 0 has mode @var{m}, which is scalar. This pattern is used to > >>> +implement the @code{fegetround} function from the ISO C99 standard. > >> I think this needs to elaborate on the format of the "rounding mode". > >> > >> AFAICS you do nothing to marshall with the actually used libc > >> implementation which AFAIU can choose arbitrary values for > >> the FE_* macros. I'm not sure we require the compiler to be > >> configured for one specific C library and for example require > >> matching FE_* macro definitions for all uses of the built > >> compiler. > >> > >> For the patch at hand you seem to assume the libc "format" > >> matches the hardware one (which would of course be reasonable). > >> > >> Does that actually hold up when looking at libcs other than > >> glibc supporting powerpc? > > I checked in some other libc implementations that have POWER support and > > all have the same value as glic for the four rounding modes and the five > > exception flags from libc. The libcs implementations I checked are: > > > > - musl > > - uclibc & uclibc-ng > > - freebsd > > > > Is There any other I am missing? > I think the concern here is that while the libcs we have visibility into > have consistent values, I don't think that's necessarily guaranteed.   > I'm not sure how to DTRT here.  We may not have the target headers if > we're doing a cross compile, so a configure test may not do what we  > need.  In fact, ISTM that there is no reliable configure or compile time > check we can do since the constants are part of the runtime and can > change independently of the compiler. >From other subthreads Joseph and segher mentioned this: On Wed, Nov 04, 2020 at 09:06:02PM +0000, Joseph Myers wrote: > On Wed, 4 Nov 2020, Raoni Fassina Firmino via Gcc-patches wrote: > > > IMHO, It seems like it is not necessary if there not a libc that have > > different values for the FE_* macros. I didn't check other archs, but if > > is the case for some other arch I think it could be changed if and when > > some other arch implements expands for these builtins. > > SPARC is the case I know of where the FE_* values vary depending on target > libc (see the SPARC_LOW_FE_EXCEPT_VALUES target macro). On Wed, Nov 18, 2020 at 06:38:22AM -0600, Segher Boessenkool wrote: > We can handle the constants issue similarly to what we do for > __builtin_fpclassify, too. I think that if we must safe-guard for future or unforeseen libc implementations doing what __builtin_fpclassify does is the way to go. I don't know what is the GCC police here, but IMHO I don't think we should add complexity before it is needed in this case. And looking at __builtin_fpclassify, it seems a lot, IIUC this solution needs fixinclude to work, seems to me too much add maintenance for something that is not needed yet, because SPARC don't have this expands, none has for now. I don't know if it helps, but the included tests also check the values changes against the libc implementations, so may catch discrepancies if building gcc with other libcs. It, of course, doesn't help if using for example a gcc built with glibc and compiling a program with it with some unknown libc. I wonder if some safe check that can be done at runtime, whilst building a program with gcc and some unknown libc. o/ Raoni Fassina