* [Bug c/67386] missing diagnostic on a use of an undeclared function
2015-08-28 16:21 [Bug c/67386] New: missing diagnostic on a use of an undeclared function msebor at gcc dot gnu.org
@ 2015-08-28 17:55 ` joseph at codesourcery dot com
2015-08-28 23:04 ` msebor at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: joseph at codesourcery dot com @ 2015-08-28 17:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 28 Aug 2015, msebor at gcc dot gnu.org wrote:
> GCC isn't completely consistent in diagnosing references to undeclared
> functions. In the test case below, it issues an error for only the last three
> out of the four definitions of foo. It issues a warning for the first one,
> even though it too references an undeclared identifier.
This is a consequence of C90 implicit declarations being accepted as an
extension in C11 mode. The implicit declaration from the call in the
first case is in scope for the non-call reference. In no other case is
there a declaration, even implicit, in scope for such a reference.
> Versions prior to 5.1 diagnosed only the second and fourth forms.
Previous versions defaulted to gnu89. In C99 and later, each half of an
if statement has its own scope; before C99, the scope of the implicit
declaration in case 3 would have been the whole of the body of the
function.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug c/67386] missing diagnostic on a use of an undeclared function
2015-08-28 16:21 [Bug c/67386] New: missing diagnostic on a use of an undeclared function msebor at gcc dot gnu.org
2015-08-28 17:55 ` [Bug c/67386] " joseph at codesourcery dot com
@ 2015-08-28 23:04 ` msebor at gcc dot gnu.org
2015-08-30 16:50 ` msebor at gcc dot gnu.org
2015-08-31 10:59 ` joseph at codesourcery dot com
3 siblings, 0 replies; 5+ messages in thread
From: msebor at gcc dot gnu.org @ 2015-08-28 23:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
Thanks. I think I may have misinterpreted the C90 rules that describe implicit
function declarations. The C90 text says:
If the expression that precedes the parenthesized argument list in a function
call consists solely of an identifier, and if no declaration is visible for
this identifier, the identifier is implicitly declared exactly as if, in the
innermost block containing the function call, the declaration
extern int identifier();
appeared.
My reading was that the implicit declaration is intended to be in effect only
for the call to the otherwise undeclared function, but GCC and the other
compilers I've tried let it persist (at least) until the end of the scope and
use it for references to the undeclared function that aren't calls (such as
assigning its address to a pointer).
While trying to better understand both the rule and the implementation (since
it affects the fix for pr66516), I created the following test case and tried it
with GCC and the other compilers. GCC's output for the test case is below (the
errors are the same with c98, gnu98, c99, gnu99, c11, and gnu11 as arguments to
-std=, and with or without -pedantic). Clang, however, doesn't issue any
errors, and neither does IBM xlc. The EDG front end behaves the same as GCC.
I think Clang and IBM xlc are both wrong since the reference to abs on line 8
should clearly be diagnosed. The C90 words aren't completely clear about where
in the innermost block the extern int identifier(); declaration is supposed to
appear but it stands to reason that it should appear where all other
declarations must appear in C90: before any executable code. So diagnosing the
reference to abs on line 11 is incorrect because the call to abs(0) on the
following line should introduce an implicit declaration of the function just
before line 11 where its address is taken.
Unless you disagree, I'll close this as NOTABUG and open a new bug for the
incorrect diagnostic on line 11.
$ cat -n t.c && ~/bin/gcc-5.1.0/bin/gcc -c t.c
1 int (*p)(int);
2 int i;
3
4 void f0 (void) {
5 i = abs (0); // okay, abs implicitly declared in this scope
6 }
7 void f1 (void) {
8 p = abs; // error, no implicitly declaration in scope
9 }
10 void f2 (void) {
11 p = abs; // GCC bug?
12 i = abs (0); // injects an implicit declaration into the
enclosing block
13 }
14 void f3 (void) {
15 i = abs (0); // introduces an implicit declaration into scope
16 p = abs; // okay, abs implicitly declared above
17 }
18
t.c: In function ‘f0’:
t.c:5:9: warning: implicit declaration of function ‘abs’
[-Wimplicit-function-declaration]
i = abs (0);
^
t.c: In function ‘f1’:
t.c:8:9: error: ‘abs’ undeclared (first use in this function)
p = abs;
^
t.c:8:9: note: each undeclared identifier is reported only once for each
function it appears in
t.c: In function ‘f2’:
t.c:11:9: error: ‘abs’ undeclared (first use in this function)
p = abs;
^
>From gcc-bugs-return-495833-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 28 23:07:58 2015
Return-Path: <gcc-bugs-return-495833-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29190 invoked by alias); 28 Aug 2015 23:07:57 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29140 invoked by uid 48); 28 Aug 2015 23:07:54 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67390] New: [6 regression] FAIL: g++.dg/torture/pr64312.C -O1 (test for excess errors)
Date: Fri, 28 Aug 2015 23:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: memory-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter cc blocked target_milestone cf_gcctarget
Message-ID: <bug-67390-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg01975.txt.bz2
Content-length: 952
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg390
Bug ID: 67390
Summary: [6 regression] FAIL: g++.dg/torture/pr64312.C -O1
(test for excess errors)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: memory-hog
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: schwab@linux-m68k.org
CC: alalaw01 at gcc dot gnu.org
Blocks: 67283
Target Milestone: ---
Target: m68k-*-*
After r227265:
$ (ulimit -v $((1024*1024)); gcc/xg++ -Bgcc/
../gcc/testsuite/g++.dg/torture/pr64312.C -O1 -S -o pr64312.s)
cc1plus: out of memory allocating 2056 bytes after a total of 530935808 bytes
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg283
[Bug 67283] GCC regression over inlining of returned structures
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug c/67386] missing diagnostic on a use of an undeclared function
2015-08-28 16:21 [Bug c/67386] New: missing diagnostic on a use of an undeclared function msebor at gcc dot gnu.org
2015-08-28 17:55 ` [Bug c/67386] " joseph at codesourcery dot com
2015-08-28 23:04 ` msebor at gcc dot gnu.org
@ 2015-08-30 16:50 ` msebor at gcc dot gnu.org
2015-08-31 10:59 ` joseph at codesourcery dot com
3 siblings, 0 replies; 5+ messages in thread
From: msebor at gcc dot gnu.org @ 2015-08-30 16:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
>From Doug Gwyn's response on the WG14 list about the C90 wording with respect
to the placement of the implicit declaration (quoted below) it seems that even
though diagnosing line 11 in f2() in comment #2 goes against a strict
interpretation of the C90 rule, it is in the spirit of the original K&R C and
the consequences of the strict interpretation may not have been intended.
After thinking about it some more, it doesn't seem worthwhile to open a new bug
for this. It would likely and up getting closed as WONTFIX anyway since
changing the behavior would only serve to break legacy code.
>> ... But again, I'm surprised to find that some compilers inject it just
> before the call
>> to the function, while others inject it "at the top of the block."
>> The former compilers then issue an error for the first reference to foo
> below:
>> void bar (int i, int (*p)(int)) {
>> p = foo; /* valid? */
>> i = foo (i);
>> }
>
> One could reasonably argue that the "top of the block" compilers more
> accurately
> implement the C90 wording; however, Ritchie's PDP-11 C compiler (which I
> continue to
> enhance and maintain) enacts an implicit declaration of "foo" (as an extern
> int in this
> example) at the first place it is seen, and therefore issues an error for
> the second,
> incompatible occurrence. This compiler was designed to be pretty much
> "one pass".
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug c/67386] missing diagnostic on a use of an undeclared function
2015-08-28 16:21 [Bug c/67386] New: missing diagnostic on a use of an undeclared function msebor at gcc dot gnu.org
` (2 preceding siblings ...)
2015-08-30 16:50 ` msebor at gcc dot gnu.org
@ 2015-08-31 10:59 ` joseph at codesourcery dot com
3 siblings, 0 replies; 5+ messages in thread
From: joseph at codesourcery dot com @ 2015-08-31 10:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386
--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 28 Aug 2015, msebor at gcc dot gnu.org wrote:
> My reading was that the implicit declaration is intended to be in effect only
> for the call to the otherwise undeclared function, but GCC and the other
> compilers I've tried let it persist (at least) until the end of the scope and
Yes (remember, two scopes are the same if they end at the same point;
saying what block the declaration appears in is the same as saying where
it ends).
> I think Clang and IBM xlc are both wrong since the reference to abs on line 8
> should clearly be diagnosed. The C90 words aren't completely clear about where
> in the innermost block the extern int identifier(); declaration is supposed to
> appear but it stands to reason that it should appear where all other
> declarations must appear in C90: before any executable code. So diagnosing the
In general, it's a mistake to interpret "X is equivalent to Y" statements
in the C standard as referring to a textual substitution; there are plenty
of other places where applying such a substitution goes wrong. Cf. cases
where something is said to be equivalent to a particular sequence of
declarations and statements and it must be implicitly understood that the
variable names in those declarations and statements are not special in any
way.
^ permalink raw reply [flat|nested] 5+ messages in thread