Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[llvm-gcc] Error when an implicitly external function is re-declared as static #616

Closed
llvmbot opened this issue Feb 17, 2004 · 13 comments
Closed

[llvm-gcc] Error when an implicitly external function is re-declared as static #616

llvmbot opened this issue Feb 17, 2004 · 13 comments
Assignees
@lattner

Comments

@llvmbot
Copy link
Member

llvmbot commented Feb 17, 2004

Bugzilla Link 244
Resolution FIXED
Resolved on Feb 22, 2010 12:49
Version 1.0
OS All
Attachments C code to reproduce the problem, Incorrect output generated by the test case.
Reporter LLVM Bugzilla Contributor

Extended Description

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).
@llvmbot
Copy link
Member Author

llvmbot commented Feb 17, 2004

assigned to @lattner

@llvmbot
Copy link
Member Author

llvmbot commented Feb 17, 2004

This bug blocks the correct functioning of the espresso Malloc Benchmark.

@lattner
Copy link
Collaborator

lattner commented Feb 17, 2004

I love C! :)

@lattner
Copy link
Collaborator

lattner commented Feb 20, 2004

FWIW, this is probably related to Bug 232.

@lattner
Copy link
Collaborator

lattner commented Feb 20, 2004

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

@lattner
Copy link
Collaborator

lattner commented Feb 20, 2004

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

@lattner
Copy link
Collaborator

lattner commented Feb 20, 2004

*** Bug #604 has been marked as a duplicate of this bug. ***

@lattner
Copy link
Collaborator

lattner commented Mar 16, 2004

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

@lattner
Copy link
Collaborator

lattner commented Jun 20, 2004

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

@llvmbot
Copy link
Member Author

llvmbot commented Jun 20, 2004

I'm curious. How are the names of the two "func" functions different? Or, did
you mean with different signatures?

@lattner
Copy link
Collaborator

lattner commented Jun 20, 2004

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

@lattner
Copy link
Collaborator

lattner commented Nov 28, 2004

Fixed. Testcase here:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041122/021383.html

Patch here:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041122/021384.html

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#33311

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 1, 2021
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
@Lancern
[CIR][CIRGen] Add CIRGen for binary fp2fp builtin operations (llvm#616)
cda4ef5 
This PR adds the following operations for the builtin binary fp2fp
functions:

  - `cir.copysign` for `__builtin_copysign`;
  - `cir.fmax` for `__builtin_fmax`;
  - `cir.fmin` for `__builtin_fmin`;
  - `cir.fmod` for `__builtin_fmod`;
  - `cir.pow` for `__builtin_pow`.

This PR also includes CIRGen support for these new operations.
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
@Lancern @lanza
[CIR][CIRGen] Add CIRGen for binary fp2fp builtin operations (llvm#616)
d73a8b2 
This PR adds the following operations for the builtin binary fp2fp
functions:

  - `cir.copysign` for `__builtin_copysign`;
  - `cir.fmax` for `__builtin_fmax`;
  - `cir.fmin` for `__builtin_fmin`;
  - `cir.fmod` for `__builtin_fmod`;
  - `cir.pow` for `__builtin_pow`.

This PR also includes CIRGen support for these new operations.
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
@Lancern
[CIR][Fix] FP builtins should lower directly to LLVM builtins (llvm#670)
c1e7b87 
LLVM lowering for the following operations is introduced in llvm#616 and
llvm#651: `cos`, `exp`, `exp2`, `log`, `log10`, `log2`, `sin`, `sqrt`,
`fmod`, and `pow`. However, they are not lowered to their corresponding
LLVM intrinsics; instead they are transformed to libc calls during
lowering prepare. This does not match the upstream behavior.

This PR tries to correct this mistake. It makes all CIR FP intrinsic ops
lower to their corresponding LLVM intrinsics (`fmod` is a special case
and it is lowered to the `frem` LLVM instruction).
keryell pushed a commit to keryell/llvm-project that referenced this issue Oct 19, 2024
@Lancern @lanza
[CIR][CIRGen] Add CIRGen for binary fp2fp builtin operations (llvm#616)
01dd7d8 
This PR adds the following operations for the builtin binary fp2fp
functions:

  - `cir.copysign` for `__builtin_copysign`;
  - `cir.fmax` for `__builtin_fmax`;
  - `cir.fmin` for `__builtin_fmin`;
  - `cir.fmod` for `__builtin_fmod`;
  - `cir.pow` for `__builtin_pow`.

This PR also includes CIRGen support for these new operations.
keryell pushed a commit to keryell/llvm-project that referenced this issue Oct 19, 2024
@Lancern @lanza
[CIR][Fix] FP builtins should lower directly to LLVM builtins (llvm#670)
5aaa637 
LLVM lowering for the following operations is introduced in llvm#616 and
llvm#651: `cos`, `exp`, `exp2`, `log`, `log10`, `log2`, `sin`, `sqrt`,
`fmod`, and `pow`. However, they are not lowered to their corresponding
LLVM intrinsics; instead they are transformed to libc calls during
lowering prepare. This does not match the upstream behavior.

This PR tries to correct this mistake. It makes all CIR FP intrinsic ops
lower to their corresponding LLVM intrinsics (`fmod` is a special case
and it is lowered to the `frem` LLVM instruction).
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lattner lattner

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lattner @llvmbot