c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: David Edelsohn <dje.gcc@gmail.com>,
	gcc@gcc.gnu.org, c-std-porting@lists.linux.dev
Subject: Re: More C type errors by default for GCC 14
Date: Thu, 11 May 2023 16:32:34 -0500	[thread overview]
Message-ID: <20230511213234.GF19790@gate.crashing.org> (raw)
In-Reply-To: <87cz394b63.fsf@oldenburg.str.redhat.com>

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

  reply	other threads:[~2023-05-11 21:38 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
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 [this message]
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=20230511213234.GF19790@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=c-std-porting@lists.linux.dev \
    --cc=dje.gcc@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    /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).