GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-02-27T21:12:50Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8976dll-split: internal error: evacuate(static): strange closure type 02022-02-27T21:12:50ZJens Petersendll-split: internal error: evacuate(static): strange closure type 0ghc-7.8.1 fails to build on Fedora ARM.
This appears to be a regression compared to 7.8.1 RC2.
```
:
chmod +x inplace/bin/runghc
inplace/bin/dll-split compiler/stage2/build/.depend-v-d...ghc-7.8.1 fails to build on Fedora ARM.
This appears to be a regression compared to 7.8.1 RC2.
```
:
chmod +x inplace/bin/runghc
inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet"
dll-split: internal error: evacuate(static): strange closure type 0
(GHC version 7.8.1 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [compiler/stage2/dll-split.stamp] Aborted
```
This is the bug report!
This happens on both Fedora 20 (current latest stable release) and 21 (in development). The build is against ghc-7.6.3 and llvm 3.3 and 3.4 respectively.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"dll-split: internal error: evacuate(static): strange closure type 0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc-7.8.1 fails to build on Fedora ARM.\r\nThis appears to be a regression compared to 7.8.1 RC2.\r\n\r\n{{{\r\n:\r\nchmod +x inplace/bin/runghc\r\ninplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell \"DynFlags\" \"Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet\"\r\ndll-split: internal error: evacuate(static): strange closure type 0\r\n (GHC version 7.8.1 for arm_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nmake[1]: *** [compiler/stage2/dll-split.stamp] Aborted\r\n}}}\r\n\r\nThis is the bug report!\r\n\r\nThis happens on both Fedora 20 (current latest stable release) and 21 (in development). The build is against ghc-7.6.3 and llvm 3.3 and 3.4 respectively.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/703all binaries built by ghc have executable stacks2019-07-07T19:17:21Zduncanall binaries built by ghc have executable stacks# Non-executable stacks
The GNU toolchain supports marking object files that do not need to use an executable stack. Currently all object files produced by GHC lack these notes and so the linker defaults to using an executable stack for...# Non-executable stacks
The GNU toolchain supports marking object files that do not need to use an executable stack. Currently all object files produced by GHC lack these notes and so the linker defaults to using an executable stack for the resulting binary.
This makes some people grumpy. In particular it makes the Gentoo QA people grumpy. :-)
**The long story**:
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
**The quick story**:
Every .S file produced by ghc should include:
```
.section .note.GNU-stack,"",@progbits
```
Currently this does not happen for either -fasm or -fvia-C.
## For -fasm
ghc simply does not emit the .section .note.GNU-stack stuff into the assembly output.
## For -fvia-C
ghc emits C which is then compiled by gcc. The resulting .raw_s file does
contain the .section .note.GNU-stack. However ghc then runs the generated assembly through the "evil mangler" which doesn't grok the .section
1. note.GNU-stack and does not emit it to the final assembly file.
So the solution is to get ghc to emit the .note.GNU-stack in it's native code geneerator and to modify the evil mangler to pass the .note.GNU-stack through to the output.
We may still have a problem with the "split objs" feature (which ghc uses for its own libraries). Hopefully it'd just be a matter of adding .note.GNU-stack to each .s file that is spat out by ghc -split-objs.
----
For reference see http://bugs.gentoo.org/show_bug.cgi?id=123698
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"all binaries built by ghc have executable stacks","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"= Non-executable stacks =\r\nThe GNU toolchain supports marking object files that do not need to use an executable stack. Currently all object files produced by GHC lack these notes and so the linker defaults to using an executable stack for the resulting binary.\r\n\r\nThis makes some people grumpy. In particular it makes the Gentoo QA people grumpy. :-)\r\n\r\n'''The long story''':\r\nhttp://www.gentoo.org/proj/en/hardened/gnu-stack.xml\r\n\r\n'''The quick story''':\r\nEvery .S file produced by ghc should include:\r\n{{{\r\n.section .note.GNU-stack,\"\",@progbits\r\n}}}\r\n\r\nCurrently this does not happen for either -fasm or -fvia-C.\r\n\r\n== For -fasm ==\r\nghc simply does not emit the .section .note.GNU-stack stuff into the assembly output.\r\n\r\n== For -fvia-C ==\r\nghc emits C which is then compiled by gcc. The resulting .raw_s file does\r\ncontain the .section .note.GNU-stack. However ghc then runs the generated assembly through the \"evil mangler\" which doesn't grok the .section\r\n.note.GNU-stack and does not emit it to the final assembly file.\r\n\r\nSo the solution is to get ghc to emit the .note.GNU-stack in it's native code geneerator and to modify the evil mangler to pass the .note.GNU-stack through to the output.\r\n\r\nWe may still have a problem with the \"split objs\" feature (which ghc uses for its own libraries). Hopefully it'd just be a matter of adding .note.GNU-stack to each .s file that is spat out by ghc -split-objs.\r\n\r\n----\r\n\r\nFor reference see http://bugs.gentoo.org/show_bug.cgi?id=123698","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/3543-fext-core doesn't force recompilation when .hcr file doesn't exist2019-07-07T19:03:25Zchevalier@alum.wellesley.edu-fext-core doesn't force recompilation when .hcr file doesn't existIf I do:
ghc -o foo foo.hs
and then immediately afterward:
ghc -fext-core -c foo.hs
and foo.hcr doesn't exist, ghc still says "Compilation is not required" and doesn't create the External Core file. It should generate the .hcr given the...If I do:
ghc -o foo foo.hs
and then immediately afterward:
ghc -fext-core -c foo.hs
and foo.hcr doesn't exist, ghc still says "Compilation is not required" and doesn't create the External Core file. It should generate the .hcr given the -fext-core flag, even if the .hi file is up to date.
Sorry if this is a duplicate bug (I know that making the compilation manager pay attention to flags is an ongoing issue).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-fext-core doesn't force recompilation when .hcr file doesn't exist","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I do:\r\nghc -o foo foo.hs\r\nand then immediately afterward:\r\nghc -fext-core -c foo.hs\r\n\r\nand foo.hcr doesn't exist, ghc still says \"Compilation is not required\" and doesn't create the External Core file. It should generate the .hcr given the -fext-core flag, even if the .hi file is up to date.\r\n\r\nSorry if this is a duplicate bug (I know that making the compilation manager pay attention to flags is an ongoing issue).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9776-frule-check flag not recognized without parameter2019-07-07T18:39:05ZJan Stolarekjan.stolarek@ed.ac.uk-frule-check flag not recognized without parameter```
$ ghc Foo.hs -frule-check
ghc: on the commandline: unrecognised flag: -frule-check
Usage: For basic information, try the `--help' option.
```
That error message is confusing. `-frule-check` is a valid flag, it's just being used inco...```
$ ghc Foo.hs -frule-check
ghc: on the commandline: unrecognised flag: -frule-check
Usage: For basic information, try the `--help' option.
```
That error message is confusing. `-frule-check` is a valid flag, it's just being used incorrectly. It should be followed by a parameter:
```
$ ghc Foo.hs -frule-check ruleFoo
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-frule-check flag not recognized without parameter","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ ghc Foo.hs -frule-check\r\nghc: on the commandline: unrecognised flag: -frule-check\r\nUsage: For basic information, try the `--help' option.\r\n}}}\r\n\r\nThat error message is confusing. `-frule-check` is a valid flag, it's just being used incorrectly. It should be followed by a parameter:\r\n\r\n{{{\r\n$ ghc Foo.hs -frule-check ruleFoo\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1carlostomecarlostomehttps://gitlab.haskell.org/ghc/ghc/-/issues/9963GHCi panic with --print-libdir flag2019-07-07T18:38:11ZJan Stolarekjan.stolarek@ed.ac.ukGHCi panic with --print-libdir flagReported on GHC devs:
```
$ ghc-stage2 --print-libdir
/dane/projekty/ghc/build/inplace/lib
$ ghc-stage2 --interactive --print-libdir
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.9.20141222 for x86_64-unknown-linux):
...Reported on GHC devs:
```
$ ghc-stage2 --print-libdir
/dane/projekty/ghc/build/inplace/lib
$ ghc-stage2 --interactive --print-libdir
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.9.20141222 for x86_64-unknown-linux):
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.9.20141222 for x86_64-unknown-linux):
v_unsafeGlobalDynFlags: not initialised
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Does not happen with GHC 7.8.x.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi panic with --print-libdir flag","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reported on GHC devs:\r\n\r\n{{{\r\n$ ghc-stage2 --print-libdir\r\n/dane/projekty/ghc/build/inplace/lib\r\n$ ghc-stage2 --interactive --print-libdir\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.9.20141222 for x86_64-unknown-linux):\r\n ghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.9.20141222 for x86_64-unknown-linux):\r\n v_unsafeGlobalDynFlags: not initialised\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nDoes not happen with GHC 7.8.x.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Thomas MiedemaThomas Miedema