public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: "N.M. Maclaren" <nmm1@cam.ac.uk>
Cc: "Thomas König" <tk@tkoenig.net>,
	"Franz Sirl" <Franz.Sirl-kernel@lauterbach.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	"Thomas Koenig" <tkoenig@netcologne.de>,
	"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>
Subject: Re: [RFC] -Weverything
Date: Sun, 27 Jan 2019 20:35:00 -0000	[thread overview]
Message-ID: <CAH6eHdTX1UQFDgnO0h+83SqfOs_B_biE4rfRFACPD8yrkX8QLA@mail.gmail.com> (raw)
In-Reply-To: <Prayer.1.3.5.1901271356480.25762@hermes-1.csi.cam.ac.uk>

On Sun, 27 Jan 2019 at 13:56, N.M. Maclaren <nmm1@cam.ac.uk> wrote:
>
> On Jan 23 2019, Thomas König wrote:
> >
> >> Am 23.01.2019 um 12:36 schrieb Jonathan Wakely <jwakely.gcc@gmail.com>:
> >>
> >> When there are new warnings that aren't enabled by -Wall -Wextra,
> >> there's probably a reason they aren't enabled by default.
> >are a higher form of life than mere  Fortran
> >-Wconversion-extra is an example of such a warning.
> >
> > It catches a very common error people make in Fortran, see
> > https://gcc.gnu.org/ml/fortran/2019-01/ms are a higher form of life than
> > mere sg00178.html for a false bug report which it would have caught
> > early.
> >
> >We left it out of -Wextra because people felt it was too noisy.
>
> A bit like discussions on what warnings a compiler should give :-)
>
> There are a few points that don't seem to have been made, though I may have
> missed them, which means that quite a few people would like it.
>
> Despite its older and wider implementation history, Fortran has never
> accumulated the incompatibilities, inconsistencies and system-dependent
> behaviours that C and C++ have.  So the arguments against such a warning
> for those don't really apply.  Obviously, we wouldn't want warnings that a
> construct behaved differently in Fortran 66 or in CDC or DEC Fortran, but I
> don't think that there are any.
>
> I don't buy the claim that developer options are unsuitable for mere users.
> Those of us who wrote highly portable code (and I assume that people still
> do) wanted to know that a construct might misbehave on a bizarre,
> unsupported but still used system, which the author had never heard of and
> has no access to. While that applies to all languages, the attitude that a
> portable program should work on a new system with NO modification,
> pre-processing or make configuration is rare in C and C++, but still common
> in Fortran.
>
> All experience is that warning about things that the programmer might not
> have realised are potentially problematic are very useful. In the cases
> where I have had to suppress warnings, most of them have been because the
> warning was too crude, not that it wasn't useful. For example, in C/C++,
> mixing signed and unsigned when the promoted operand was constant and not
> going to change value. Or, in Fortran, converting obviously exact constants
> to a higher precision - yes, even that WAS an important warning in the
> 1960s, but people really should move on a bit!
>
> So I think that there is a strong argument for such an option in gfortran,
> irrespective of whether there is for gcc and g++.

Then -Wall should enable them for Fortran.

  reply	other threads:[~2019-01-27 20:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 18:34 Thomas Koenig
2019-01-22 18:45 ` Marc Glisse
2019-01-22 18:56   ` Jonathan Wakely
2019-01-22 19:00     ` Jonathan Wakely
2019-01-23 11:21     ` Franz Sirl
2019-01-23 11:37       ` Jonathan Wakely
2019-01-23 13:26         ` Thomas König
2019-01-23 13:53           ` Paul Richard Thomas
2019-01-27 13:56           ` N.M. Maclaren
2019-01-27 20:35             ` Jonathan Wakely [this message]
2019-01-27 20:52               ` Steve Kargl
2019-01-27 21:02                 ` Thomas König
2019-01-27 21:19                   ` Andrew Pinski
2019-01-27 21:28                     ` Steve Kargl
2019-01-28  9:57                       ` N.M. Maclaren
2019-01-28 22:53                     ` Segher Boessenkool
2019-01-22 20:53 ` Jeffrey Walton
2019-01-23  0:53 ` Martin Sebor
2019-01-23  7:17   ` Thomas König
2019-01-23  7:31     ` Jakub Jelinek
2019-01-23  8:26       ` Marc Glisse
2019-01-23  9:31     ` Jonathan Wakely

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=CAH6eHdTX1UQFDgnO0h+83SqfOs_B_biE4rfRFACPD8yrkX8QLA@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=Franz.Sirl-kernel@lauterbach.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=nmm1@cam.ac.uk \
    --cc=tk@tkoenig.net \
    --cc=tkoenig@netcologne.de \
    /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).