[Bug c/67386] New: missing diagnostic on a use of an undeclared function

[Bug c/67386] New: missing diagnostic on a use of an undeclared function

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386

            Bug ID: 67386
           Summary: missing diagnostic on a use of an undeclared function
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

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.

Versions prior to 5.1 diagnosed only the second and fourth forms.

$ (set -x && cat t.c && for i in 1 2 3 4; do ~/bin/gcc-5.1.0/bin/gcc -DFOO=$i
-c t.c; done)
+ cat t.c
#if FOO == 1
void* foo (int i) {
    return i ? foobar (i) : foobar;
}
#elif FOO == 2
void* foo (int i) {
    return i ? 0 : foobar;
}
#elif FOO == 3
void* foo (int i) {
    if (i)
        return foobar (i);
    else
        return foobar;
}
#else
void* foo (int i) {
    if (i)
        return 0;
    else
        return foobar;
}
#endif
+ for i in 1 2 3 4
+ /home/msebor/bin/gcc-5.1.0/bin/gcc -DFOO=1 -c t.c
t.c: In function ‘foo’:
t.c:3:16: warning: implicit declaration of function ‘foobar’
[-Wimplicit-function-declaration]
     return i ? foobar (i) : foobar;
                ^
t.c:3:27: warning: pointer/integer type mismatch in conditional expression
     return i ? foobar (i) : foobar;
                           ^
+ for i in 1 2 3 4
+ /home/msebor/bin/gcc-5.1.0/bin/gcc -DFOO=2 -c t.c
t.c: In function ‘foo’:
t.c:7:20: error: ‘foobar’ undeclared (first use in this function)
     return i ? 0 : foobar;
                    ^
t.c:7:20: note: each undeclared identifier is reported only once for each
function it appears in
+ for i in 1 2 3 4
+ /home/msebor/bin/gcc-5.1.0/bin/gcc -DFOO=3 -c t.c
t.c: In function ‘foo’:
t.c:12:16: warning: implicit declaration of function ‘foobar’
[-Wimplicit-function-declaration]
         return foobar (i);
                ^
t.c:12:16: warning: return makes pointer from integer without a cast
[-Wint-conversion]
t.c:14:16: error: ‘foobar’ undeclared (first use in this function)
         return foobar;
                ^
t.c:14:16: note: each undeclared identifier is reported only once for each
function it appears in
+ for i in 1 2 3 4
+ /home/msebor/bin/gcc-5.1.0/bin/gcc -DFOO=4 -c t.c
t.c: In function ‘foo’:
t.c:21:16: error: ‘foobar’ undeclared (first use in this function)
         return foobar;
                ^
t.c:21:16: note: each undeclared identifier is reported only once for each
function it appears in
>From gcc-bugs-return-495815-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 28 16:23:50 2015
Return-Path: <gcc-bugs-return-495815-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 89777 invoked by alias); 28 Aug 2015 16:23:50 -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 89686 invoked by uid 55); 28 Aug 2015 16:23:46 -0000
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/66752] spec2000 255.vortex performance compiled with GCC is ~20% lower than with CLANG
Date: Fri, 28 Aug 2015 16:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
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:
Message-ID: <bug-66752-4-KrFJXyKz58@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66752-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66752-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/msg01957.txt.bz2
Content-length: 1284

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf752

--- Comment #18 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Aug 28 16:23:12 2015
New Revision: 227307

URL: https://gcc.gnu.org/viewcvs?rev"7307&root=gcc&view=rev
Log:
[PATCH][lto/66752] Fix missed FSM jump thread

        PR lto/66752
        * tree-ssa-threadedge.c (simplify_conrol_stmt_condition): If we are
        unable to find X NE 0 in the tables, return X as the simplified
        condition.
        (fsm_find_control_statement_thread_paths): If nodes in NEXT_PATH are
        in VISISTED_BBS, then return failure.  Else add nodes from NEXT_PATH
        to VISISTED_BBS.
        * tree-ssa-threadupdate.c (duplicate_thread_path): Fix up edge flags
        after removing the control flow statement and unnecessary edges.

        PR lto/66752
        * gcc.dg/tree-ssa/pr66752-2.c: New test.
        * gcc.dg/torture/pr66752-1.c: New test
        * g++.dg/torture/pr66752-2.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/torture/pr66752-2.C
    trunk/gcc/testsuite/gcc.dg/torture/pr66752-1.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr66752-3.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-threadedge.c
    trunk/gcc/tree-ssa-threadupdate.c

[Bug c/67386] missing diagnostic on a use of an undeclared function

[joseph at codesourcery dot com]

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.

[Bug c/67386] missing diagnostic on a use of an undeclared function

[msebor at gcc dot gnu.org]

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

[Bug c/67386] missing diagnostic on a use of an undeclared function

[msebor at gcc dot gnu.org]

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".

[Bug c/67386] missing diagnostic on a use of an undeclared function

[joseph at codesourcery dot com]

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.