More C type errors by default for GCC 14

[David Brown]

On 10/05/2023 15:10, Basile Starynkevitch wrote:
> Hello all,
> 
> After a suggestion by Eric Gallager
>> Idea for a compromise: What if, instead of flipping the switch on all
>> 3 of these at once, we staggered them so that each one becomes a
>> default in a separate release? i.e., something like:
>>
>> - GCC 14: -Werror=implicit-function-declaration gets added to the 
>> defaults
>> - GCC 15: -Werror=implicit-int gets added to the defaults
>> - GCC 16: -Werror=int-conversion gets added to the defaults
>>
>> That would give people more time to catch up on a particular warning,
>> rather than overwhelming them with a whole bunch all at once. Just an
>> idea.
> 
> Eli Zaretskii <eliz@gnu.org> wrote on 10 may 2023, at 14:00
> 
>> And that is just one example of perfectly valid reasons for not
>> wanting or not being able to make changes to pacify GCC.
>>
>> Once again, my bother is not about "villains" who don't want to get
>> their act together, my bother is about cases such as the one above,
>> where the developers simply have no practical choice.
>>
>> And please don't tell me they should use an older GCC, because as
>> systems go forward and are upgraded, older GCC will not work anymore.
> 
> 
> My experience is that for safety critical software (per DOI 178C, 
> embedded in aircrafts, or for the French covid breathing machine on 
> https://github.com/Recovid/Controller ) the regulations, funders, and 
> authorities requires a very specific version of GCC with very specific 
> compilation flags.
> 
> 
> Changing either the compiler (even from gcc-12.1 to gcc-12.2) or the 
> compilation flags (even changing -O1 by -O2) requires written (on paper) 
> approval by a large number of human persons, and formal certifications 
> (eg ISO9001, ISO27001 procedures) and lots of checks and headaches.
> 
> 
> I do know several persons making their living of these constraints.
> 
> I do know several corporations making a living from them (and keeping 
> decade older GCC compiler binaries on many disks).
> 
> So I really think that for safety critical software (whose failure may 
> impact lives) people are using an older (and well specified) GCC.
> 
> 
> Of course, to compile an ordinary business web service (e-shop for 
> clothes) with e.g. libonion (from https://github.com/davidmoreno/onion 
> ...) or to compile a zsh.org from source code (for or on a developer's 
> laptop) the constraints are a lot lighter.
> 
> Regards!
> 

In my line of work (small-systems embedded programming), the source for 
a program does not just include the C source code.  It includes the 
build system, compiler version, the flags used, and the library used - 
everything that can affect the resulting binary.  I realise I am far 
more paranoid about that kind of thing than the majority of developers, 
but it is also noteworthy that there is a trend towards reproducible 
builds in more mainstream development.

The oldest gcc I have on my machine is 2.95.3 for the 68k, from 1998.  I 
have some older compilers, but they are not gcc.

I wouldn't say I made a living out of this, but I have had a customer 
who was very happy that I could make a fix in a program I wrote 20 years 
previously, and could compile it with exactly the same tools as I used then.

One of the reasons I use gcc (in a world where companies are willing to 
pay $5000 for tools from the likes of Green Hills) is that I can keep 
the old versions around, and copy and use them at will.

And for those that are more demanding than me, they can of course 
archive the sources for gcc (and other parts of the toolchain).

Those that /really/ need old versions of the toolchain, can use old 
versions of the toolchain.  And if gcc 14 changes in such a way that 
distro maintainers can't use it to build ancient packages, then they 
should make gcc-13 a part of their base packages as well as current gcc, 
and ship gcc version 13 for as long as they ship "ed", "rn" and other 
software from the middle ages.