This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)
On 06/29/2018 09:11 AM, Jeff Law wrote:
On 06/27/2018 08:40 PM, Martin Sebor wrote:
On 06/27/2018 03:53 PM, Jeff Law wrote:
On 06/27/2018 09:27 AM, Jakub Jelinek wrote:
On Wed, Jun 27, 2018 at 09:17:07AM -0600, Jeff Law wrote:
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).
I'm mainly worried about configure tests, those will be hit hardest by
this and might result in silently turning off many features of the
compiled
programs.
It's certainly a concern. Sadly, it's a hard one to deal with because
we can't just throw code at it and see what complains. Instead we end
up with packages that don't configure in the appropriate features.
I checked all GCC's config logs and although there are 543
instances of the -Wbuiltin-declaration-mismatch warning in
an x86_64-linux build, none of them is an error and
the number is the same as before the patch.
That's both depressing and promising at the same time. Depressing
there's so many, promising that none trigger an error.
All the warnings I have seen are because of declarations like
the one in the test below that checks for the presence of symbol
sin in the library:
char sin ();
int main () { return sin (); }
GCC has warned for this code by default since at least 4.1 so if
it is, in fact, a problem it has been with us for over a decade.
There's a comment in the test that explains that the char return
type is deliberate to prevent GCC from treating the function as
a built-in. (That, of course, relies on undefined behavior
because names of extern library functions are reserved and
conforming compilers could simply avoid emitting the call or
replace it with a trap.)
I wonder if stepping forward to a more modern version of autoconf is
going to help here and if we should be feeding them updates to make this
kind of stuff less pervasive, at least in standard autoconf tests.
That would make sense to me. The tests should not rely on
undefined behavior. They should declare standard functions with
the right prototypes. IMO, for GCC and compatible compilers they
should disable built-in expansion instead via -fno-builtin. For
all other compilers, they could store the address of each function
in a (perhaps volatile) pointer and use it to make the call instead.
But since the number of warnings here hasn't changed, the ones
in GCC logs predate my changes. So updating the tests seems
like an improvement to consider independently of the patch.
Martin