Skip to content

Cannot compile simple example #13

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.

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

Closed
siraben opened this issue Oct 1, 2020 · 4 comments
Closed

Cannot compile simple example #13

siraben opened this issue Oct 1, 2020 · 4 comments
Labels
external issue working as intended Nothing is behaving incorrectly

Comments

@siraben
Copy link

siraben commented Oct 1, 2020

Using the latest macOS release binary linked in the wiki: https://jacobly.com/llvm/ez80-clang-macOSRelease.zip

hello.c

short square(short x) {
  return x * x;
}

int main() {
  short x = square(2);
  return x;
}
$ ez80-clang -O3 -o hello hello.c
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:1:no such instruction: `section .text,"ax",@progbits'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:2:no such instruction: `assume adl =1'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:3:no such instruction: `section .text,"ax",@progbits'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:4:no such instruction: `public _square'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:5:no such instruction: `private _square'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:7:no such instruction: `ld iy, 0'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:8:too many memory references for `add'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:9:no such instruction: `ld bc, (iy+3)'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:10:32-bit absolute addressing is not supported for x86-64
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:10:cannot do signed 4 byte relocation
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:11:32-bit absolute addressing is not supported for x86-64
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:11:cannot do signed 4 byte relocation
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:14:no such instruction: `section .text,"ax",@progbits'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:16:no such instruction: `section .text,"ax",@progbits'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:17:no such instruction: `public _main'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:18:no such instruction: `private _main'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:20:no such instruction: `ld hl, 4'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:22:no such instruction: `section .text,"ax",@progbits'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:24:no such instruction: `ident "clang version 12.0.0 (https://github.com/jacobly0/llvm-project 185536120e21b4d1407bfb888e2216423ef0e736)"'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:25:no such instruction: `extern __Unwind_SjLj_Register'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:26:no such instruction: `extern __Unwind_SjLj_Unregister'
/var/folders/s1/sm71lqk553d1_f8drd3tz_5r0000gn/T/hello-802185.s:27:no such instruction: `extern __imulu'
ez80-clang: error: assembler command failed with exit code 1 (use -v to see invocation)

It does generate assembly though, with the -S CLI option.

@jacobly0
Copy link
Owner

jacobly0 commented Oct 1, 2020

Yes, I only use it for generating assembly, and link that with external tools, so none of the object emitting and assembler code is implemented yet. Also, that is calling your system assembler, so no surprise that it's so confused.

@siraben
Copy link
Author

siraben commented Oct 1, 2020

Which external tools do you use? And how do you properly resolve the call to __smulu?

@jacobly0
Copy link
Owner

jacobly0 commented Oct 1, 2020

I use this for linking, but there's no documentation about the linker commands and such since it's only used by exactly one project. The name __smulu comes from the eZ80 ZDS toolchain, which was where the original c compiler/linker came from, but was abandoned due to the inability to fix bugs in closed source software, but which does include the C and assembly source for its runtime routines. Eventually, I intend to replace them all with manual implementations written by me or other assembly experts in the community.

@siraben
Copy link
Author

siraben commented Oct 1, 2020

Thanks, from the examples I've tried so far the quality of the Z80 output has been pretty high!

@siraben siraben closed this as completed Oct 1, 2020
jacobly0 pushed a commit that referenced this issue Dec 11, 2020
CXXDeductionGuideDecl with a local typedef has its own copy of the
TypedefDecl with the CXXDeductionGuideDecl as the DeclContext of that
TypedefDecl.
```
      template <typename T> struct A {
        typedef T U;
        A(U, T);
      };
      A a{(int)0, (int)0};
```
Related discussion on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2020-November/067252.html

Without this fix, when we import the CXXDeductionGuideDecl (via
VisitFunctionDecl) then before creating the Decl we must import the
FunctionType. However, the first parameter's type is the afore mentioned
local typedef. So, we then start importing the TypedefDecl whose
DeclContext is the CXXDeductionGuideDecl itself. The infinite loop is
formed.
```
 #0 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0
 #1 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:405:0
 #2 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0
 #3 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0
 #4 clang::ASTImporter::ImportContext(clang::DeclContext*) clang/lib/AST/ASTImporter.cpp:8297:0
 #5 clang::ASTNodeImporter::ImportDeclContext(clang::Decl*, clang::DeclContext*&, clang::DeclContext*&) clang/lib/AST/ASTImporter.cpp:1852:0
 #6 clang::ASTNodeImporter::ImportDeclParts(clang::NamedDecl*, clang::DeclContext*&, clang::DeclContext*&, clang::DeclarationName&, clang::NamedDecl*&, clang::SourceLocation&) clang/lib/AST/ASTImporter.cpp:1628:0
 #7 clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool) clang/lib/AST/ASTImporter.cpp:2419:0
 #8 clang::ASTNodeImporter::VisitTypedefDecl(clang::TypedefDecl*) clang/lib/AST/ASTImporter.cpp:2500:0
 #9 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:315:0
 #10 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0
 #11 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0
 #12 llvm::Expected<clang::TypedefNameDecl*> clang::ASTNodeImporter::import<clang::TypedefNameDecl>(clang::TypedefNameDecl*) clang/lib/AST/ASTImporter.cpp:165:0
 #13 clang::ASTNodeImporter::VisitTypedefType(clang::TypedefType const*) clang/lib/AST/ASTImporter.cpp:1304:0
 #14 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:74:0
 #15 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0
 #16 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0
 #17 clang::ASTNodeImporter::VisitFunctionProtoType(clang::FunctionProtoType const*) clang/lib/AST/ASTImporter.cpp:1244:0
 #18 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:47:0
 #19 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0
 #20 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0
 #21 clang::QualType clang::ASTNodeImporter::importChecked<clang::QualType>(llvm::Error&, clang::QualType const&) clang/lib/AST/ASTImporter.cpp:198:0
 #22 clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) clang/lib/AST/ASTImporter.cpp:3313:0
 #23 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0
```

The fix is to first create the TypedefDecl and only then start to import
the DeclContext.
Basically, we could do this during the import of all other Decls (not
just for typedefs). But it seems, there is only one another AST
construct that has a similar cycle: a struct defined as a function
parameter:
```
int struct_in_proto(struct data_t{int a;int b;} *d);

```
In that case, however, we had decided to return simply with an error
back then because that seemed to be a very rare construct.

Differential Revision: https://reviews.llvm.org/D92209
@jacobly0 jacobly0 added enhancement New feature or request help wanted Extra attention is needed wontfix This will not be worked on external issue working as intended Nothing is behaving incorrectly and removed enhancement New feature or request help wanted Extra attention is needed wontfix This will not be worked on labels Jan 31, 2022
jacobly0 pushed a commit that referenced this issue Nov 20, 2024
…onger cause a crash (llvm#116569)

This PR fixes a bug introduced by llvm#110199, which causes any half float
argument to crash the compiler on MIPS64.

Currently compiling this bit of code with `llc -mtriple=mips64`: 
```
define void @half_args(half %a) nounwind {
entry:
        ret void
}
```

Crashes with the following log:
```
LLVM ERROR: unable to allocate function argument #0
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: llc -mtriple=mips64
1.	Running pass 'Function Pass Manager' on module '<stdin>'.
2.	Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function '@half_args'
 #0 0x000055a3a4013df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32d0df8)
 #1 0x000055a3a401199e llvm::sys::RunSignalHandlers() (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32ce99e)
 #2 0x000055a3a40144a8 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f00bde558c0 __restore_rt libc_sigaction.c:0:0
 #4 0x00007f00bdea462c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007f00bde55822 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #6 0x00007f00bde3e4af abort ./stdlib/abort.c:81:7
 #7 0x000055a3a3f80e3c llvm::report_fatal_error(llvm::Twine const&, bool) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x323de3c)
 #8 0x000055a3a2e20dfa (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x20dddfa)
 #9 0x000055a3a2a34e20 llvm::MipsTargetLowering::LowerFormalArguments(llvm::SDValue, unsigned int, bool, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::SDLoc const&, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const MipsISelLowering.cpp:0:0
#10 0x000055a3a3d896a9 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30466a9)
#11 0x000055a3a3e0b3ec llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c83ec)
#12 0x000055a3a3e09e21 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c6e21)
#13 0x000055a3a2aae1ca llvm::MipsDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) MipsISelDAGToDAG.cpp:0:0
#14 0x000055a3a3e07706 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c4706)
#15 0x000055a3a3051ed6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x230eed6)
#16 0x000055a3a35a3ec9 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x2860ec9)
#17 0x000055a3a35ac3b2 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x28693b2)
#18 0x000055a3a35a499c llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x286199c)
#19 0x000055a3a262abbb main (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x18e7bbb)
#20 0x00007f00bde3fc4c __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#21 0x00007f00bde3fd05 call_init ./csu/../csu/libc-start.c:128:20
#22 0x00007f00bde3fd05 __libc_start_main@GLIBC_2.2.5 ./csu/../csu/libc-start.c:347:5
#23 0x000055a3a2624921 _start /builddir/glibc-2.39/csu/../sysdeps/x86_64/start.S:117:0
```

This is caused by the fact that after the change, `f16`s are no longer
lowered as `f32`s in calls.

Two possible fixes are available:
- Update calling conventions to properly support passing `f16` as
integers.
- Update `useFPRegsForHalfType()` to return `true` so that `f16` are
still kept in `f32` registers, as before llvm#110199.

This PR implements the first solution to not introduce any more ABI
changes as llvm#110199 already did.

As of what is the correct ABI for halfs, I don't think there is a
correct answer. GCC doesn't support halfs on MIPS, and I couldn't find
any information on old MIPS ABI manuals either.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external issue working as intended Nothing is behaving incorrectly
Projects
None yet
Development

No branches or pull requests

2 participants