Florian Weimer <fweimer@redhat.com> writes:

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

Not that we have to follow Clang, but deviating by adding -fpermissive
(which is a GCC-only flag) for C may not be desirable, and following
Clang would let people use the same method for silencing known-bad
codebases for now.

>
> 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've not seen very much of this so far, FWIW. Only for the more annoying
C23 warnings which have well-documented problems (and unrelated to this,
so I won't go on about it anymore).

But -fpermissive does have a nice property in that it's immediately
obvious you're doing something *terrible* if you use it.

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

Yeah, this is one of those things where we need it happening in CI for
people and at the point of development.

(Such an option might be nice in general, but not for this if its
default didn't include these warnings or if distributions were likely
to override it to something weaker.)

thanks,
sam