Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • M mu-impl-fast
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 40
    • Issues 40
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • mumu
  • mu-impl-fast
  • Issues
  • #35
Closed
Open
Issue created Jun 07, 2017 by Isaac Gariano@igariano01Maintainer

x86-64 calling functions with int<128> arguments

I have unfortunately broken then x86-64 backend, I belive this is due to changing the call for UDIV/UREM/SREM/SDIV to pass 128-bit values instead of 64-bit ones. Specifically when running the PySOM test I get the following error:

        thread '<unnamed>' panicked at 'not yet implemented', src/compiler/backend/arch/x86_64/inst_sel.rs:2948
        stack backtrace:
           0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
                     at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
           1: std::sys_common::backtrace::_print
                     at /checkout/src/libstd/sys_common/backtrace.rs:71
           2: std::panicking::default_hook::{{closure}}
                     at /checkout/src/libstd/sys_common/backtrace.rs:60
                     at /checkout/src/libstd/panicking.rs:355
           3: std::panicking::default_hook
                     at /checkout/src/libstd/panicking.rs:371
           4: std::panicking::rust_panic_with_hook
                     at /checkout/src/libstd/panicking.rs:549
           5: std::panicking::begin_panic
           6: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_precall_convention
           7: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_c_call_internal
           8: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_runtime_entry
           9: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_binop
          10: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::instruction_select
          11: <mu::compiler::backend::x86_64::inst_sel::InstructionSelection as mu::compiler::passes::CompilerPass>::visit_function
          12: mu::compiler::passes::CompilerPass::execute
          13: mu::compiler::Compiler::compile
          14: mu::vm::vm::VM::make_boot_image_internal
          15: mu::vm::api::api_bridge::_forwarder__MuCtx__make_boot_image
          16: fnc_40
          17: main
          18: __libc_start_main
          19: _start
        fatal runtime error: failed to initiate panic, error 5

It seems there is a bug in the x86-64 emit_precall_convention function, which I am unable to fix as I am unfamiliar with the x86 calling conventions.

Assignee
Assign to
Time tracking