This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING] Re: [PATCH] c/66516 - missing diagnostic on taking the address of a builtin function
- From: Martin Sebor <msebor at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Marek Polacek <polacek at redhat dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 28 Aug 2015 15:33:13 -0600
- Subject: Re: [PING] Re: [PATCH] c/66516 - missing diagnostic on taking the address of a builtin function
- Authentication-results: sourceware.org; auth=none
- References: <5587432A dot 9000602 at redhat dot com> <20150622144010 dot GK10139 at redhat dot com> <5588BD78 dot 4030607 at gmail dot com> <20150623101829 dot GQ10139 at redhat dot com> <20150623102909 dot GK10247 at tucnak dot redhat dot com> <55897735 dot 1040509 at redhat dot com> <5590965B dot 6030103 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1507021411440 dot 29415 at digraph dot polyomino dot org dot uk> <55985EE0 dot 3060802 at gmail dot com> <55A483E8 dot 7060708 at gmail dot com> <55A52443 dot 10800 at redhat dot com> <55A54DBF dot 7080702 at gmail dot com> <55B84AAA dot 7040503 at redhat dot com> <55E0BD94 dot 2060105 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1508282006110 dot 18238 at digraph dot polyomino dot org dot uk>
On 08/28/2015 02:09 PM, Joseph Myers wrote:
On Fri, 28 Aug 2015, Martin Sebor wrote:
I ran into one regression in the gcc.dg/lto/pr54702_1.c test.
The file takes the address of malloc without declaring it, and
after calling it first. The code is invalid but GCC compiles it
due to a bug. I raised it in c/67386 -- missing diagnostic on
a use of an undeclared function, and suppressed the error by
But that PR isn't a bug - the code is working exactly as it's meant to (an
implicit declaration acts exactly like an explicit declaration "int func
();" in the nearest containing scope). The declaration has an
incompatible type, it's true, but GCC deliberately allows that with a
warning.
What if (a) you use a built-in function that returns int, instead of
malloc, and (b) use -std=gnu89, so the implicit declaration isn't even an
extension? Then you have something that's completely valid, including
taking the address of the implicitly declared function.
In that case the patched GCC issues an error for taking the address
of the undeclared function as the test case below shows.
I was aware of the C90 implicit declaration rule but I interpreted
it as saying that the injected declaration is only in effect for
the call expression. Since no other tests broke, I assumed the one
that did was buggy. Anyway, after testing a few other compilers it
looks like they all also extend the implicit declaration through
the rest of the scope, so the patch will need further tweaking to
allow this corner case.
The problem is that DECL_IS_BUILTIN(expr) returns true for
an implicitly declared builtin function with a library fallback
but false for one that's been declared explicitly. I'll either
have to find some other test to determine that the implicitly
declared function has a fallback or fix whatever is causing
the macro to return the wrong value.
Martin
$ cat t.c && /build/gcc-66516/gcc/xgcc -B /build/gcc-66516/gcc
-std=gnu89 t.cint (*p)(int);
void foo (void) {
p = abs;
}
int bar (void) {
int n = abs (0);
p = abs;
return n;
}
t.c: In function ‘foo’:
t.c:4:9: error: ‘abs’ undeclared (first use in this function)
p = abs;
^
t.c:4:9: note: each undeclared identifier is reported only once for each
function it appears in
t.c: In function ‘bar’:
t.c:9:5: error: builtin function ‘abs’ must be directly called
p = abs;
^