public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Qing Zhao <qing.zhao@oracle.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: Should -ffp-contract=off the default on GCC?
Date: Tue, 21 Mar 2023 19:01:36 +0000	[thread overview]
Message-ID: <9787B47E-9800-47B1-B98D-60430257C4E5@oracle.com> (raw)
In-Reply-To: <4a670847-9728-e0cb-46f3-d476839f7cd4@gmail.com>



> On Mar 21, 2023, at 1:59 PM, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> 
> 
> 
> On 3/21/23 11:00, Qing Zhao via Gcc-patches wrote:
>>> On Mar 21, 2023, at 12:56 PM, Paul Koning <paulkoning@comcast.net> wrote:
>>> 
>>> 
>>> 
>>>> On Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org> 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.
Theoretically, yes, I agree with you.

But in reality, many programmers don’t know all the details of the language standard and writing problematic code, that’s one of the reasons the compiler issues different warnings to the users in order to avoid those issues. 

In addition to this, Standards have been changed from time to time.

The code previously worked now has some issue since we added some new stuff into standard, and the compiler added some new transformation based on this new stuff. Should the compiler issue some warnings to warn the users about such change? Then the user will go to the new standard to get more info? 

Qing

> 
> 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.
> 
> Jeff


  parent reply	other threads:[~2023-03-21 19:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 16:24 Qing Zhao
2023-03-16 16:31 ` Andrew Pinski
2023-03-16 16:38   ` Qing Zhao
2023-03-16 16:53     ` Jakub Jelinek
2023-03-16 18:40       ` Qing Zhao
2023-03-20 22:05       ` Qing Zhao
2023-03-20 22:25         ` Jakub Jelinek
2023-03-21 12:49           ` Qing Zhao
2023-03-21 15:01           ` Qing Zhao
2023-03-21 16:56             ` Paul Koning
2023-03-21 17:00               ` Qing Zhao
2023-03-21 17:59                 ` Jeff Law
2023-03-21 18:03                   ` Paul Koning
2023-03-21 18:55                     ` Toon Moene
2023-03-21 18:12                   ` Alexander Monakov
2023-03-21 18:18                     ` Jeff Law
2023-03-22 10:13                       ` Richard Biener
2023-03-22 12:26                         ` Alexander Monakov
2023-03-22 13:57                           ` Richard Biener
2023-03-22 15:52                             ` Qing Zhao
2023-03-24  7:12                               ` Fangrui Song
2023-03-24 19:42                                 ` Andrew Pinski
2023-03-31 16:31                                   ` Qing Zhao
2023-03-21 19:01                   ` Qing Zhao [this message]
2023-03-21 19:12                     ` Jakub Jelinek
2023-03-21 23:28                       ` Jeff Law
2023-03-21 23:31                         ` Jakub Jelinek
2023-03-21 19:51                     ` Jeff Law
2023-03-21 21:08                       ` Qing Zhao
2023-03-22 12:33           ` Alexander Monakov
2023-03-22 14:33             ` Qing Zhao
2023-03-27  9:03 Zeson

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9787B47E-9800-47B1-B98D-60430257C4E5@oracle.com \
    --to=qing.zhao@oracle.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).