From: Jeff Law <law@redhat.com>
To: Martin Sebor <msebor@gmail.com>,
Gcc Patch List <gcc-patches@gcc.gnu.org>
Subject: Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)
Date: Wed, 27 Jun 2018 15:17:00 -0000 [thread overview]
Message-ID: <f46744a6-4b3e-139c-976b-7b96c48239dd@redhat.com> (raw)
In-Reply-To: <393ca33b-647d-c180-311b-5e89c98ae34e@gmail.com>
On 06/26/2018 08:57 PM, Martin Sebor wrote:
> With the exception of built-ins with the ellipsis (like sprintf),
> GCC silently accepts declarations of built-in functions without
> prototypes as well as calls to such functions with any numbers
> or types of arguments, compatible or otherwise. Calls with
> arguments whose number and types match exactly those of
> the built-in are considered by the middle-end for optimization.
> Other calls (compatible or not, irrespective of whether their
> number matches the number expected by the function) are then
> made to the library functions.
>
> Attached is a small fix to -Wbuiltin-declaration-mismatch to
> have it diagnose built-in declarations without a prototype.
> The warning is enabled by default so it causes a fair number
> of tests to fail because of declarations like 'void abort();'
> The breakdown of the built-ins behind the test failures is
> below.
>
> Before I take the time to clean up the test suite let me post
> what I have in case going this route is not acceptable. As
> an alternative, I could try to avoid some of these warnings,
> e.g., by diagnosing incompatible calls instead but I think
> it's even less worthwhile for built-ins than trying to do
> it for ordinary functions with -Wstrict-prototypes. There
> is, in my view, no justification today for standard functions
> to be declared without a prototype. (I could also make
> the warning depend on language mode and -Wpedantic if that
> were more preferable.)
>
> Martin
>
> About 115 tests fail due to incompatible declarations of
> the built-in functions below (the number shows the number
> of warnings for each functions):
>
> 428Â Â abort
> Â 58Â Â exit
> Â 36Â Â memcpy
> Â 17Â Â memmove
> Â 15Â Â realloc
> Â 14Â Â cabs
> Â 5Â Â strncpy
> Â 4Â Â strcmp
> Â 3Â Â alloca
> Â 2Â Â rindex
> Â 1Â Â aligned_alloc
I'm supportive of this change. Though I'm more worried about the
affects on the distros than I am on the testsuite (which I expected to
be in worse shape WRT this issue than your analysis indicates).
Unfortunately I don't have the tester set up to do distro style testing
yet. So I can't just throw your patch in and see what is spit out. But
even so, I still think this is the right thing to do.
Jeff
next prev parent reply other threads:[~2018-06-27 15:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 2:58 Martin Sebor
2018-06-27 15:17 ` Jeff Law [this message]
2018-06-27 15:27 ` Jakub Jelinek
2018-06-27 21:53 ` Jeff Law
2018-06-28 2:41 ` Martin Sebor
2018-06-29 15:23 ` Jeff Law
2018-06-29 15:43 ` Jakub Jelinek
2018-06-29 16:26 ` Martin Sebor
2018-07-04 2:34 ` Jeff Law
2018-07-04 17:32 ` Martin Sebor
2018-07-05 19:44 ` Jeff Law
2018-11-02 19:50 ` [PATCH] " Martin Sebor
2018-11-02 22:52 ` Joseph Myers
2018-11-02 23:40 ` Martin Sebor
2018-11-06 23:56 ` Martin Sebor
2018-11-14 18:08 ` Jeff Law
2018-11-15 10:11 ` Richard Biener
2018-11-15 19:14 ` Martin Sebor
2018-06-29 17:25 ` [RFC PATCH] " Eric Gallager
2018-06-28 1:41 ` Martin Sebor
2018-06-27 18:44 ` Eric Gallager
2018-06-28 2:01 ` Martin Sebor
2018-06-30 13:52 Bernd Edlinger
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=f46744a6-4b3e-139c-976b-7b96c48239dd@redhat.com \
--to=law@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=msebor@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).