c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc@gcc.gnu.org,  c-std-porting@lists.linux.dev
Subject: Re: More C type errors by default for GCC 14
Date: Tue, 09 May 2023 18:59:01 +0200	[thread overview]
Message-ID: <87pm794f1m.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <97CCB305-9ECD-4B3C-B13E-4F2790FE0543@gmail.com> (Richard Biener's message of "Tue, 9 May 2023 17:16:19 +0200")

* Richard Biener:

>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
>> 
>> TL;DR: This message is about turning implicit-int,
>> implicit-function-declaration, and possibly int-conversion into errors
>> for GCC 14.
>
> I suppose the goal is to not need to rely on altering CFLAGS but
> change the default behavior with still being able to undo this using
> -Wno-error= or -Wno-?

That's what Clang does (and the defaults chang along with -std=
settings). To me, -Werror by default for some warnings seems rather
hackish.  But that's just my personal preference, I do not have a strong
objection to doing it that way.

One downside with -Wno- is that some developers jump on this rather
quickly instead of fixing the real problem.  So far, I've seen this in
both Chromium and the kernel, in fringe areas admittedly, but still.
The advantage is that there is a familiar workaround to get things
compiling quickly again, of course.

> I think instead of hard-coding a set of changes would it be possible
> to alter the default setting of diagnostic options during GCC
> configuration?  And maybe even note that when diagnosing?

I'd be worried about our package maintainers if we do something like
that.  We'd like them to report build failures upstream, and if it's
just one or two distributions doing that and not GCC upstream, well, I
guess we just got a preview of how some upstreams are going to react.
Package maintainers tend to be volunteer or junior engineering roles, I
think, so this doesn't seem fair to me.

Thanks,
Florian


  parent reply	other threads:[~2023-05-09 16:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 12:15 More C type errors by default for GCC 14 Florian Weimer
2023-05-09 15:16 ` Richard Biener
2023-05-09 16:05   ` Jakub Jelinek
2023-05-09 16:11     ` Sam James
2023-05-09 16:59   ` Florian Weimer [this message]
2023-05-09 17:07     ` Sam James
2023-05-09 17:35       ` Florian Weimer
     [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
2023-05-09 15:07   ` Sam James
2023-05-09 15:14   ` Jonathan Wakely
     [not found]     ` <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net>
     [not found]       ` <87r0rp5uf8.fsf@aarsen.me>
     [not found]         ` <83ttwla1ep.fsf@gnu.org>
     [not found]           ` <CAH6eHdS-7USHzX3rPJaR66sEdjG+-nHp7mDb0gD7ceBnp+Fmpg@mail.gmail.com>
     [not found]             ` <83lehx9vix.fsf@gnu.org>
     [not found]               ` <ZFqZ25xKm4w4IkqF@tucnak>
     [not found]                 ` <83fs859unu.fsf@gnu.org>
     [not found]                   ` <CAGWvny=xi++Ghyo2Ez5MJdYy5h3yH16gVpviKC99Ufu_bUmdYQ@mail.gmail.com>
     [not found]                     ` <CAH6eHdRAVwBcCmBgiuPyQNWGx3x33diAgQU8UG3s_NrJxK3ucQ@mail.gmail.com>
     [not found]                       ` <CAGWvnyk_MkQOrNNh1C=ubPj8qzg5x-p8CBfgWNqqtDVJ1mbhMg@mail.gmail.com>
     [not found]                         ` <CAF9ehCWsq-N9+U1+mTQahKT7cXEqLTptLb=b3Yq58gsWFEnxgA@mail.gmail.com>
     [not found]                           ` <CAH6eHdS_sQ37VTpJHL7cqtgSdCSL3i4=tqMoY65wep9G56cf5g@mail.gmail.com>
     [not found]                             ` <CAMfHzOsR=gY6QTss2R029Q-uMOTpC-RDV09bEF2FO7x5jpy5gg@mail.gmail.com>
2023-05-10 10:45                               ` Sam James
2023-05-10 10:56                                 ` Neal Gompa
2023-05-10 12:06                                   ` Eli Zaretskii
2023-05-10 12:10                                     ` Neal Gompa
2023-05-10 12:41                                       ` Eli Zaretskii
2023-05-09 18:22   ` Florian Weimer
2023-05-11 21:32     ` Segher Boessenkool
2023-05-12  9:33 ` Martin Jambor
2023-05-12 12:30   ` Jakub Jelinek
2023-05-15 12:46     ` Michael Matz
2023-05-15 13:14     ` Richard Earnshaw (lists)
     [not found] <CAGWvnynMpa83AduLhRhf1PxkVujngDmmwE7Z4vk1z6+UqqAuKA@mail.gmail.com>
     [not found] ` <BBE9950C-28AA-4A1C-A4C5-7F486538004E@gmail.com>
2023-05-09 16:44   ` Florian Weimer
2023-05-09 16:58     ` Ian Lance Taylor
2023-05-09 17:08     ` Jason Merrill
2023-05-09 17:16       ` Sam James

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=87pm794f1m.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=c-std-porting@lists.linux.dev \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@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 NNTP newsgroup(s).