
#11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): To get generated code we can run: {{{ "inplace/bin/ghc-stage1" \ -static -H64m -O1 \ -optc-flto=9 -optc-ffat-lto-objects \ -optl-flto=9 -optl-ffat-lto-objects \ -optc-ggdb2 -optl-ggdb2 \ -j4 \ -optc-Werror=implicit-function-declaration -optc-Werror=overflow \ -Wall \ -lbfd \ -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header \ -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build \ -DCOMPILING_RTS -this-package-key rts \ -optc-DNOSMP -dcmm-lint \ -i -irts -irts/dist/build \ -irts/dist/build/autogen \ -Irts/dist/build -Irts/dist/build/autogen \ -O2 \ -C rts/Exception.cmm \ -o rts/dist/build/Exception.hc }}} '''rts/dist/build/Exception.hc''' contains the following declarations: {{{ /* (incomplete) symbol declaraion */ EF_(raiseExceptionHelper); ... /* exact prototype dectaration, assignment and call: */ { W_ (*ghcFunPtr)(void *, void *, void *); ghcFunPtr = ((W_ (*)(void *, void *, void *))raiseExceptionHelper); _c2y = ghcFunPtr((void *)(W_)BaseReg, (void *)(W_)CurrentTSO, (void *)_c2z);;} }}} It comes from '''rts/Exception.cmm''': {{{ retry_pop_stack: SAVE_THREAD_STATE(); (frame_type) = ccall raiseExceptionHelper(BaseReg "ptr", CurrentTSO "ptr", exception "ptr"); LOAD_THREAD_STATE(); }}} As we see unannotated return type defaults to '''W_''' ('''StgWord''', non-pointer type). So the question is: Does gcc ignore type coercion given in '''ghcFunPtr =''' assignment and uses original declaration? gcc's '''-fdump-*-all''' options might hint at where gcc loses information about argument type. Could it be real (but similar) error happens somewhere else? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11395#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler