From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id 6D9153858D3C for ; Tue, 21 Mar 2023 18:12:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6D9153858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 881D244C1017; Tue, 21 Mar 2023 18:12:30 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 881D244C1017 Date: Tue, 21 Mar 2023 21:12:30 +0300 (MSK) From: Alexander Monakov To: Jeff Law cc: gcc-patches@gcc.gnu.org Subject: Re: Should -ffp-contract=off the default on GCC? In-Reply-To: <4a670847-9728-e0cb-46f3-d476839f7cd4@gmail.com> Message-ID: References: <6659A77B-DA2F-40A6-BDBD-E8B29B9E901D@oracle.com> <87384938-FDB1-487B-8B03-7787996435B2@comcast.net> <7C6B7ED7-7AA4-47EF-8E44-E3AD81BF3E29@oracle.com> <4a670847-9728-e0cb-46f3-d476839f7cd4@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1504533605-1679422350=:6944" X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1504533605-1679422350=:6944 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 21 Mar 2023, Jeff Law via Gcc-patches wrote: > On 3/21/23 11:00, Qing Zhao via Gcc-patches wrote: > > > >> On Mar 21, 2023, at 12:56 PM, Paul Koning wrote: > >> > >>> On Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches > >>> wrote: > >>> > >>> ... > >>> Most of the compiler users are not familiar with language standards, or no > >>> access to language standards. Without clearly documenting such warnings > >>> along with the option explicitly, the users have not way to know such > >>> potential impact. > >> > >> With modern highly optimized languages, not knowing the standard is going > >> to get you in trouble. There was a wonderful paper from MIT a few years > >> ago describing all the many ways C can bite you if you don't know the > >> rules. > > > > Yes, it’s better to know the details of languages standard. -:) > > However, I don’t think that this is a realistic expectation to the compiler > > users: to know all the details of a language standard. > Umm, they really do need to know that stuff. > > If the developer fails to understand the language standard, then they're > likely going to write code that is ultimately undefined or doesn't behave in > they expect. How is the compiler supposed to guess what the developer > originally intended? How should the compiler handle the case when two > developers have different understandings of how a particular piece of code > should work? In the end it's the language standard that defines how all this > stuff should work. > > Failure to understand the language is a common problem and we do try to emit > various diagnostics to help developers avoid writing non-conformant code. But > ultimately if a developer fails to understand the language standard, then > they're going to be surprised by the behavior of their code. W h a t. This subthread concerns documenting the option better ("Without clearly documenting such warnings ..."). Are you arguing against adding a brief notice to the documentation blurb for the -ffp-contract= option? Perplexed, Alexander --8323328-1504533605-1679422350=:6944--