public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Eric Gallager <egall@gwmail.gwu.edu>
Cc: Gcc Patch List <gcc-patches@gcc.gnu.org>
Subject: Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)
Date: Thu, 28 Jun 2018 02:01:00 -0000	[thread overview]
Message-ID: <b8477104-a1c4-508e-423a-baa0787e9047@gmail.com> (raw)
In-Reply-To: <CAMfHzOv+h4Ujy-012py28eu5atEST3CawqM22qEU7LL_0UseLA@mail.gmail.com>

On 06/27/2018 12:44 PM, Eric Gallager wrote:
> On 6/26/18, Martin Sebor <msebor@gmail.com> 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
>>
>
> Could you do something to differentiate it a bit more from the
> -Wshadow warning that is also touched in this patch? It'd be kind of
> annoying to get warnings from both flags for the same code...

I don't think it's possible to get both warnings.  The block
with the -Wshadow warning returns before the one
-Wbuiltin-declaration-mismatch is entered.

Martin


  reply	other threads:[~2018-06-28  2:01 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
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 [this message]
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=b8477104-a1c4-508e-423a-baa0787e9047@gmail.com \
    --to=msebor@gmail.com \
    --cc=egall@gwmail.gwu.edu \
    --cc=gcc-patches@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 read-only IMAP folder(s) and NNTP newsgroup(s).