Re: More C type errors by default for GCC 14

[Thomas Koenig <tkoenig@netcologne.de>]

Not replying to anybody in particular, just a bit of history, with
some potential parallels.

In gfortran, we have had two major issues with interfaces.  One was that
code which had happily violated the compiler ABI started failing, due
to a fix in the gfortran front end which meant that we were no longer
mixing varargs and non-varargs calls (which led to code being correctly
compiled for POWER which had been miscompiled for basically forewer).

Among other things, this broke R, and was fixed by Jakub by applying
a workaround.  After a few years, people in core libraries like BLAS
and Netlib are finally getting around to fixing their code.  There is
no knowing what codes still have that, so the workaround will probably
stay around forever, although we don't promise that it does.

Partially motivated by this, we then added a file-level check for
argument list mismatches (type and rank), which issued an error.

That error could be disabled by a new option, -fallow-argument-mismatch,
but that caused problems for people using different versions of the
compiler. So we added this option to -std=legacy, which is a catch-all
kitchen sink, which accepts some not-so-nice things.

Of course, as everybody on this list knows, mixing types like this is
dangerous, and is liable to break sooner or later in future compiler
release. Nonetheless, even a package like MPICH chose to use autoconf
to set the -fallow-argument-mismatch flag rather than fix the code :-(

Others, like the LAPACK maintainers, have reacted and installed
patches.

So... using an error message as a crowbar to change people's behavior
failed, at least partially.  And you only hear from the people who
complain, not from those who are glad that they found errors that they
would otherwise have missed.

What does that mean for the case at hand?  Based on past experience,
I'd lean towards putting all the warnings about the special offending
codes into one warning option (-Wsevere, or something) which could
then be made into an error by -Werror=severe or such variant; maybe
other warnings could be grouped in there as well.  And if these severe
warnings should then be made default or not, well... that (like the
rest of my mail) is open for discussion.

Best regards

	Thomas