Re: How can Autoconf help with the transition to stricter compilation defaults?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On 16 Nov 2022, at 15:27, Richard Biener <richard.guenther@xxxxxxxxx> wrote:
> 
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc <gcc@xxxxxxxxxxx> 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: signature.asc
Description: Message signed with OpenPGP


[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux