public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: Richard Biener <richard.guenther@gmail.com>,
	Aaron Ballman <aaron@aaronballman.com>
Cc: Michael Matz <matz@suse.de>,
	Alexander Monakov <amonakov@ispras.ru>,
	Paul Eggert <eggert@cs.ucla.edu>,
	Jonathan Wakely <jwakely.gcc@gmail.com>,
	Aaron Ballman <aaron@aaronballman.com>,
	Zack Weinberg <zack@owlfolio.org>,
	c-std-porting@lists.linux.dev,
	Autoconf Development <autoconf@gnu.org>,
	GCC Development <gcc@gcc.gnu.org>,
	cfe-commits@lists.llvm.org, Gnulib bugs <bug-gnulib@gnu.org>
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Wed, 16 Nov 2022 15:35:08 +0000	[thread overview]
Message-ID: <00C3EDCD-D2DA-4B0D-8A8A-08B76552D865@gentoo.org> (raw)
In-Reply-To: <CAFiYyc2RwHLA+HQWWZk069G3-2xA6-i0E_n1mMpAcNA_g7n3Qw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]



> On 16 Nov 2022, at 15:27, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc <gcc@gcc.gnu.org> wrote:
>> 
>> Hey,
>> 
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>> 
>>>> The idea is so obvious that I'm probably missing something, why autoconf
>>>> can't use that idiom instead.  But perhaps the (historic?) reasons why it
>>>> couldn't be used are gone now?
>>> 
>>> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
>>> and thus no symbol reference remains in the resulting assembly.
>> 
>> Err, right, *head-->table*.
>> Playing with volatile should help:
>> 
>> char foobar(void);
>> char (* volatile ptr)(void);
>> int main(void) {
>>    ptr = foobar;
>>    return ptr != 0;
>> }
> 
> using printf for foobar this works even with GCC 2.95.2 and with trunk
> and -Wall diagnoses
> 
> t.c:1:6: warning: conflicting types for built-in function 'printf';
> expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
>    1 | char printf(void);
>      |      ^~~~~~
> t.c:1:1: note: 'printf' is declared in header '<stdio.h>'
>  +++ |+#include <stdio.h>
>    1 | char printf(void);
> 
> so without -Werror this should be fine.
> 
Unrelated but I was a bit tempted to ask for throwing in -Wbuiltin-declaration-mismatch
to default -Werror while Clang 16 was at it, but I suppose we don't want the world to
burn too much, and it's got a very obvious usecase (this one) whereas implicit
func decls are too hard to justify.

> Richard.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

  reply	other threads:[~2022-11-16 15:35 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 17:16 Zack Weinberg
2022-11-10 17:52 ` Nick Bowler
2022-11-10 17:58   ` Jonathan Wakely
2022-11-10 18:12     ` Jonathan Wakely
2022-11-10 18:44       ` Aaron Ballman
2022-11-12  2:56   ` Zack Weinberg
2022-11-10 18:05 ` Rich Felker
2022-11-10 21:44   ` Florian Weimer
2022-11-12  3:22   ` Zack Weinberg
2022-11-10 18:08 ` Florian Weimer
2022-11-12  3:40   ` Zack Weinberg
2022-11-12  3:43     ` Sam James
2022-11-12 14:27       ` Zack Weinberg
2022-11-12  3:45     ` Joseph Myers
2022-11-12 15:59   ` Wookey
2022-11-12 16:12     ` Zack Weinberg
2022-11-10 18:19 ` Aaron Ballman
2022-11-10 21:05   ` Paul Eggert
2022-11-11 15:11     ` Aaron Ballman
2022-11-13  0:43       ` Paul Eggert
2022-11-14 12:41         ` Aaron Ballman
2022-11-14 18:14           ` Paul Eggert
2022-11-14 18:30             ` Florian Weimer
2022-11-14 18:35             ` Aaron Ballman
2022-11-15 14:50             ` Jonathan Wakely
2022-11-15 19:08               ` Paul Eggert
2022-11-15 19:27                 ` Jonathan Wakely
2022-11-15 20:27                   ` Paul Eggert
2022-11-15 20:57                     ` Aaron Ballman
2022-11-15 23:09                       ` Paul Eggert
2022-11-15 23:43                         ` Ben Boeckel
2022-11-16 14:26                     ` Michael Matz
2022-11-16 14:40                       ` Alexander Monakov
2022-11-16 15:01                         ` Michael Matz
2022-11-16 15:27                           ` Richard Biener
2022-11-16 15:35                             ` Sam James [this message]
2022-11-16 15:59                               ` Michael Matz
2022-11-16 16:20                                 ` Jonathan Wakely
2022-11-16 16:34                                   ` Michael Matz
2022-11-16 16:46                                     ` Jonathan Wakely
2022-11-16 18:17                       ` Paul Eggert
2022-11-16 18:40                         ` Jeffrey Walton
2022-11-17 18:45                           ` Paul Eggert
2022-11-16 18:59                         ` Zack Weinberg
2022-11-17 18:58                           ` Paul Eggert
2022-11-17 21:35                             ` Bruno Haible
2022-11-17 22:27                               ` Paul Eggert
2022-11-17 13:30                         ` Michael Matz
2022-11-15 20:36                 ` Aaron Ballman
2022-11-15  5:03         ` Sam James
2022-11-15 13:30           ` Zack Weinberg
2022-11-15 13:34             ` Sam James
2022-11-16  0:08           ` Bob Friesenhahn
2022-11-13  0:43       ` Paul Eggert
2022-11-17 13:57         ` Jason Merrill
2022-11-10 20:19 ` Paul Eggert
     [not found] ` <d785b19371e8419f5a5817d7cdb429db91614a3a.camel@orlitzky.com>
2022-11-11  3:08   ` Sam James
2022-11-11  3:33     ` Zack Weinberg
2022-11-11  8:40       ` Sam James
2022-11-11  9:02       ` Paul Eggert
2022-11-12 14:09         ` Zack Weinberg
2022-11-11 23:25       ` Sam James
2022-11-12  0:53         ` Paul Eggert
2022-11-12  4:00           ` Sam James
2022-11-11  9:15 ` 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=00C3EDCD-D2DA-4B0D-8A8A-08B76552D865@gentoo.org \
    --to=sam@gentoo.org \
    --cc=aaron@aaronballman.com \
    --cc=amonakov@ispras.ru \
    --cc=autoconf@gnu.org \
    --cc=bug-gnulib@gnu.org \
    --cc=c-std-porting@lists.linux.dev \
    --cc=cfe-commits@lists.llvm.org \
    --cc=eggert@cs.ucla.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=matz@suse.de \
    --cc=richard.guenther@gmail.com \
    --cc=zack@owlfolio.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).