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

warnings compiling Stacker compiler on Mac OS X #676

Closed
llvmbot opened this issue Mar 30, 2004 · 3 comments
Closed

warnings compiling Stacker compiler on Mac OS X #676

llvmbot opened this issue Mar 30, 2004 · 3 comments
Assignees
@lattner

Comments

@llvmbot
Copy link
Member

llvmbot commented Mar 30, 2004

Bugzilla Link 304
Resolution FIXED
Resolved on Nov 07, 2018 00:17
Version 1.2
OS MacOS X
Reporter LLVM Bugzilla Contributor

Extended Description

I happened to notice that the Stacker lexer has tokens named TRUE and FALSE, which conflict
with macros defined in system headers on Mac OS X. This results in macro redefinition warnings during
compilation. (It looks like this might also be true of the llvm assembly parser.)

StackerParser.h::1: warning: "TRUE" redefined
/usr/include/mach/boolean.h::1: warning: this is the location of the previous definition
StackerParser.h::1: warning: "FALSE" redefined
/usr/include/mach/boolean.h::1: warning: this is the location of the previous definition
StackerParser.h::1: warning: "TRUE" redefined
/usr/include/mach/boolean.h::1: warning: this is the location of the previous definition
StackerParser.h::1: warning: "FALSE" redefined
/usr/include/mach/boolean.h::1: warning: this is the location of the previous definition
@llvmbot
Copy link
Member Author

llvmbot commented Mar 30, 2004

assigned to @lattner

@lattner
Copy link
Collaborator

lattner commented Mar 31, 2004

Fixed, patches here:

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040329/013376.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040329/013377.html

Brian, please verify that this makes the warnings go away.

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Mar 31, 2004

Yes it does, thanks!

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 1, 2021
This was referenced Jan 25, 2022
Open
Open
Open
Open
This was referenced Aug 19, 2022
Open
Open
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
@ghehg
[CIR][LowerToLLVM][CXXABI] Fix basic block ordering issue. (llvm#676)
1c0064b 
When loweringPrepare cg.var_arg for AArch64, we create multiple basic
blocks, but didn't really get ordering of the blocks in the blocklist of
the parent region right. That is, we didn't make sure the last of the
block list is the naturally last block (exit) of the region. This PR
fixes this problem.

If we don't fix this problem, FlattenCFGPass will fail verification
because CIRScopeOpFlattening in this pass is onlyy expecting to see
cir.yield op in the last block of the region's block list.
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
@ghehg @lanza
[CIR][LowerToLLVM][CXXABI] Fix basic block ordering issue. (llvm#676)
b1594b6 
When loweringPrepare cg.var_arg for AArch64, we create multiple basic
blocks, but didn't really get ordering of the blocks in the blocklist of
the parent region right. That is, we didn't make sure the last of the
block list is the naturally last block (exit) of the region. This PR
fixes this problem.

If we don't fix this problem, FlattenCFGPass will fail verification
because CIRScopeOpFlattening in this pass is onlyy expecting to see
cir.yield op in the last block of the region's block list.
keryell pushed a commit to keryell/llvm-project that referenced this issue Oct 19, 2024
@ghehg @lanza
[CIR][LowerToLLVM][CXXABI] Fix basic block ordering issue. (llvm#676)
7abde0a 
When loweringPrepare cg.var_arg for AArch64, we create multiple basic
blocks, but didn't really get ordering of the blocks in the blocklist of
the parent region right. That is, we didn't make sure the last of the
block list is the naturally last block (exit) of the region. This PR
fixes this problem.

If we don't fix this problem, FlattenCFGPass will fail verification
because CIRScopeOpFlattening in this pass is onlyy expecting to see
cir.yield op in the last block of the region's block list.
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