Re: More C type errors by default for GCC 14

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi Florian,

On Tue, May 09, 2023 at 08:22:44PM +0200, Florian Weimer via Gcc wrote:
> * alleged code generation bugs because the upper 32 bits of a pointer
>   are set to zero or 0xffffffff, resulting in crashes.  This can happen
>   if GCC synthesizes an implicit int declaration for a pointer-returning
>   function.
> 
> * Alleged code generation bugs because a function returning bool does
>   not set the entire register, as expected the caller.  This can happen
>   if GCC makes up a function declaration returning int for a function
>   that actually returns bool on x86-64.

Both of these cannot happen with better ABIs, by design.  Of course
every ABI has its own idiosyncrasies :-)

> I hope this makes things clearer.  I do think the current GCC defaults
> are needlessly frustrating, which is why I spent so much time on proving
> (from my perspective) that it should be feasible to change them.

Yes, I agree with this sentiment, and I think we can do a lot better
than we do now.

> We can get fairly close by injecting appropriate -Werror= options during

As you know, IMNSHO the only appropriate subset of -Werror= options is
the empty subset.

-Werror is for the user (the USER, not the build system) to ask "yes
please, I have all my priorities upside down, do fail compiling anything
that may look unexpected".  Most warnings are *heuristic*.  Other
warnings are for code that does not follow (modern) best practices.

But (most of) the diagnostics you propose to upgrade from warnings to
errors are not like this at all: they point out definite flaws, things
that just are not correct C code at all, and never were for that matter.
We always warn for those (without -Wall even) already, so upgrading
these to errors is a no-brainer really, as long as we also get
-fpermissive!


Segher