First Last Prev Next    No search results available
Details
: [llvm-gcc] Error when an implicitly external function is ...
Bug#: 244
: tools
: llvm-gcc
Status: RESOLVED
Resolution: FIXED
: All
: All
: 1.0
: P2
: normal
: 1.4

:
: compile-fail
:
:
  Show dependency tree - Show dependency graph
People
Reporter: John T. Criswell <criswell@uiuc.edu>
Assigned To: Chris Lattner <sabre@nondot.org>

Attachments
C code to reproduce the problem (106 bytes, text/plain)
2004-02-17 11:34, John T. Criswell
Details
Incorrect output generated by the test case. (23.20 KB, text/plain)
2004-02-17 11:34, John T. Criswell
Details


Note

You need to log in before you can comment on or make changes to this bug.

Related actions


Description:   Opened: 2004-02-17 11:33
The attached code produces a warning with GCC but otherwise produces a single
function defintion.

With LLVM GCC, the attached code generates one function declaration (but no
function definition) and one internal function (which is defined).
------- Comment #1 From John T. Criswell 2004-02-17 11:34:29 -------
Created an attachment (id=81) [details]
C code to reproduce the problem

To reproduce, use the following:

llvm-gcc -S test.c -o test.ll

With GCC 3.3, we get the warning:

test.c:10: warning: `two' was declared implicitly `extern' and later `static'
test.c:4: warning: previous declaration of `two'
------- Comment #2 From John T. Criswell 2004-02-17 11:34:52 -------
Created an attachment (id=82) [details]
Incorrect output generated by the test case.
------- Comment #3 From John T. Criswell 2004-02-17 11:35:29 -------
This bug blocks the correct functioning of the espresso Malloc Benchmark.
------- Comment #4 From Chris Lattner 2004-02-17 11:39:12 -------
I _love_ C!  :)
------- Comment #5 From Chris Lattner 2004-02-20 00:18:41 -------
FWIW, this is probably related to Bug 232.
------- Comment #6 From Chris Lattner 2004-02-20 10:57:52 -------
Here's another broken testcase:
int one(int a) {
  two(a, 5);
  return 0;
}

static void two(int a, int b) {}


... in this case, the body of 'two' never gets emitted.

-Chris
------- Comment #7 From Chris Lattner 2004-02-20 11:37:40 -------
Fixed.  Here's the (one token) patch:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040216/011969.html

Testcase here:
test/Regression/CFrontend/2004-02-20-StaticRedeclare.c.tr

It turns out that the second "bad case" that I included in this bug is actually
erroneous C code, so it's not a suprise we don't handle it. :)

-Chris
------- Comment #8 From Chris Lattner 2004-02-20 11:39:58 -------
*** Bug 232 has been marked as a duplicate of this bug. ***
------- Comment #9 From Chris Lattner 2004-03-16 15:34:31 -------
I'm reopening this bug.  There seems to be no way to fix both this bug and Bug
276 at the same time.

It appears that the root cause of this bug is internal to the GCC front-end. 
This should be revisited for 1.3 when we have hopefully sync'd up with GCC CVS more.

-Chris
------- Comment #10 From Chris Lattner 2004-06-20 14:21:44 -------
Note that this bug is preventing us from being able to compile 134.perl.  There
the situation looks like this:

-----
static int func();
void bar() {
  int func();
  foo(func);
}
static int func(char** A, char ** B) {}
---------

Two prototypes with different names are created for 'func'.

-Chris
------- Comment #11 From Reid Spencer 2004-06-20 14:25:33 -------
I'm curious. How are the names of the two "func" functions different? Or, did
you mean with different signatures?
------- Comment #12 From Chris Lattner 2004-06-20 14:29:27 -------
The C front-end (buggily) gave the prototype one name ".func_1" and the body
another ".func_2", which the linker, understandably, does not link up.

This is a CFE bug.

-Chris

First Last Prev Next    No search results available