GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:28:31Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11792Optimised unsafe FFI call can get wrong argument2019-07-07T18:28:31ZSzuntiOptimised unsafe FFI call can get wrong argumentAttached a simple test case. It should print 7457, but the C function is called with 0 as the third argument.
If I compile with -O0 or omit the unsafe keyword in the FFI import it works as it should.
In gdb disassembly looks to me as e...Attached a simple test case. It should print 7457, but the C function is called with 0 as the third argument.
If I compile with -O0 or omit the unsafe keyword in the FFI import it works as it should.
In gdb disassembly looks to me as edx (the place for third argument on 64-bit) is set to 7457, then the opaquify is inlined, but it doesn't preserve
edx and then third_arg is called with the zeroed edx.
----------------
Specs
-------------
64-bit Archlinux with arch-haskell repo
gcc -v:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5-20160209/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC)
```
ghc compile output:
```
Glasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.10.3
Using binary package database: /usr/lib/ghc-7.10.3/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d
wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181
wired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d
wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181
wired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *Main.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2016-04-05 14:24:20.801997492 UTC
ms_mod = Main,
ms_textual_imps = [import (implicit) Prelude, import Data.Word]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file Main.hs
Created temporary directory: /tmp/ghc1541_0
*** Checking old interface for Main:
[1 of 1] Compiling Main ( Main.hs, Main.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size of Desugar (after optimization)
= {terms: 317, types: 387, coercions: 3}
*** Core Linted result of Desugar (after optimization):
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 261, types: 290, coercions: 14}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 216, types: 262, coercions: 18}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 216, types: 262, coercions: 18}
*** Core Linted result of Simplifier:
*** Specialise:
Result size of Specialise = {terms: 216, types: 262, coercions: 18}
*** Core Linted result of Specialise:
*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}):
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = False})
= {terms: 274, types: 305, coercions: 18}
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}):
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 407, types: 388, coercions: 70}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 463, types: 375, coercions: 25}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 430, types: 362, coercions: 25}
*** Core Linted result of Simplifier:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 426, types: 363, coercions: 25}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 426, types: 363, coercions: 25}
*** Core Linted result of Simplifier:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 310, types: 291, coercions: 25}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 248, types: 217, coercions: 25}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=3
= {terms: 336, types: 242, coercions: 25}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 336, types: 242, coercions: 25}
*** Core Linted result of Simplifier:
*** Float inwards:
Result size of Float inwards
= {terms: 336, types: 242, coercions: 25}
*** Core Linted result of Float inwards:
*** Called arity analysis:
Result size of Called arity analysis
= {terms: 336, types: 242, coercions: 25}
*** Core Linted result of Called arity analysis:
*** Simplifier:
Result size of Simplifier = {terms: 336, types: 242, coercions: 25}
*** Core Linted result of Simplifier:
*** Demand analysis:
Result size of Demand analysis
= {terms: 336, types: 242, coercions: 25}
*** Core Linted result of Demand analysis:
*** Worker Wrapper binds:
Result size of Worker Wrapper binds
= {terms: 369, types: 283, coercions: 25}
*** Core Linted result of Worker Wrapper binds:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 354, types: 266, coercions: 25}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 354, types: 266, coercions: 25}
*** Core Linted result of Simplifier:
*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = True})
= {terms: 356, types: 267, coercions: 25}
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
*** Common sub-expression:
Result size of Common sub-expression
= {terms: 356, types: 267, coercions: 25}
*** Core Linted result of Common sub-expression:
*** Float inwards:
Result size of Float inwards
= {terms: 356, types: 267, coercions: 25}
*** Core Linted result of Float inwards:
*** Simplifier:
Result size of Simplifier = {terms: 356, types: 267, coercions: 25}
*** Core Linted result of Simplifier:
*** Tidy Core:
Result size of Tidy Core = {terms: 356, types: 267, coercions: 25}
*** Core Linted result of Tidy Core:
writeBinIface: 18 Names
writeBinIface: 81 dict entries
*** CorePrep:
Result size of CorePrep = {terms: 654, types: 379, coercions: 25}
*** Core Linted result of CorePrep:
*** Stg2Stg:
*** CodeGen:
*** Assembler:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -x assembler -c /tmp/ghc1541_0/ghc_2.s -o Main.o
Upsweep completely successful.
*** Deleting temp files:
Deleting: /tmp/ghc1541_0/ghc_3.c /tmp/ghc1541_0/ghc_2.s /tmp/ghc1541_0/ghc_1.s
Warning: deleting non-existent /tmp/ghc1541_0/ghc_3.c
Warning: deleting non-existent /tmp/ghc1541_0/ghc_1.s
link: linkables are ...
LinkableM (2016-04-05 15:42:11.288210053 UTC) Main
[DotO Main.o]
Linking Main ...
*** C Compiler:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_4.c -o /tmp/ghc1541_0/ghc_5.o -I/usr/lib/ghc-7.10.3/include
*** C Compiler:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_7.s -o /tmp/ghc1541_0/ghc_8.o -I/usr/lib/ghc-7.10.3/include
*** Linker:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -o Main Main.o Test.o -L/usr/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM -L/usr/lib/ghc-7.10.3/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/usr/lib/ghc-7.10.3/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/lib/ghc-7.10.3/rts /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_8.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -lgmp -lm -lrt -ldl
link: done
*** Deleting temp files:
Deleting: /tmp/ghc1541_0/ghc_10.rsp /tmp/ghc1541_0/ghc_9.rsp /tmp/ghc1541_0/ghc_8.o /tmp/ghc1541_0/ghc_7.s /tmp/ghc1541_0/ghc_6.rsp /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_4.c
*** Deleting temp dirs:
Deleting: /tmp/ghc1541_0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| 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":"Optimised unsafe FFI call can get wrong argument","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attached a simple test case. It should print 7457, but the C function is called with 0 as the third argument.\r\n\r\nIf I compile with -O0 or omit the unsafe keyword in the FFI import it works as it should.\r\n\r\nIn gdb disassembly looks to me as edx (the place for third argument on 64-bit) is set to 7457, then the opaquify is inlined, but it doesn't preserve\r\nedx and then third_arg is called with the zeroed edx.\r\n\r\n----------------\r\nSpecs\r\n-------------\r\n64-bit Archlinux with arch-haskell repo\r\n\r\ngcc -v:\r\n{{{\r\nUsing built-in specs.\r\nCOLLECT_GCC=gcc\r\nCOLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper\r\nTarget: x86_64-unknown-linux-gnu\r\nConfigured with: /build/gcc-multilib/src/gcc-5-20160209/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release\r\nThread model: posix\r\ngcc version 5.3.0 (GCC)\r\n}}}\r\n\r\nghc compile output:\r\n{{{\r\nGlasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.10.3\r\nUsing binary package database: /usr/lib/ghc-7.10.3/package.conf.d/package.cache\r\nwired-in package ghc-prim mapped to ghc-prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e\r\nwired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d\r\nwired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181\r\nwired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\nHsc static flags: \r\nwired-in package ghc-prim mapped to ghc-prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e\r\nwired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d\r\nwired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181\r\nwired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\n*** Chasing dependencies:\r\nChasing modules from: *Main.hs\r\nStable obj: []\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = 2016-04-05 14:24:20.801997492 UTC\r\n ms_mod = Main,\r\n ms_textual_imps = [import (implicit) Prelude, import Data.Word]\r\n ms_srcimps = []\r\n }]\r\n*** Deleting temp files:\r\nDeleting: \r\ncompile: input file Main.hs\r\nCreated temporary directory: /tmp/ghc1541_0\r\n*** Checking old interface for Main:\r\n[1 of 1] Compiling Main ( Main.hs, Main.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\nResult size of Desugar (after optimization)\r\n = {terms: 317, types: 387, coercions: 3}\r\n*** Core Linted result of Desugar (after optimization):\r\n*** Simplifier:\r\nResult size of Simplifier iteration=1\r\n = {terms: 261, types: 290, coercions: 14}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier iteration=2\r\n = {terms: 216, types: 262, coercions: 18}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier = {terms: 216, types: 262, coercions: 18}\r\n*** Core Linted result of Simplifier:\r\n*** Specialise:\r\nResult size of Specialise = {terms: 216, types: 262, coercions: 18}\r\n*** Core Linted result of Specialise:\r\n*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}):\r\nResult size of Float out(FOS {Lam = Just 0,\r\n Consts = True,\r\n OverSatApps = False})\r\n = {terms: 274, types: 305, coercions: 18}\r\n*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}):\r\n*** Simplifier:\r\nResult size of Simplifier iteration=1\r\n = {terms: 407, types: 388, coercions: 70}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier iteration=2\r\n = {terms: 463, types: 375, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier = {terms: 430, types: 362, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\n*** Simplifier:\r\nResult size of Simplifier iteration=1\r\n = {terms: 426, types: 363, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier = {terms: 426, types: 363, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\n*** Simplifier:\r\nResult size of Simplifier iteration=1\r\n = {terms: 310, types: 291, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier iteration=2\r\n = {terms: 248, types: 217, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier iteration=3\r\n = {terms: 336, types: 242, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier = {terms: 336, types: 242, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\n*** Float inwards:\r\nResult size of Float inwards\r\n = {terms: 336, types: 242, coercions: 25}\r\n*** Core Linted result of Float inwards:\r\n*** Called arity analysis:\r\nResult size of Called arity analysis\r\n = {terms: 336, types: 242, coercions: 25}\r\n*** Core Linted result of Called arity analysis:\r\n*** Simplifier:\r\nResult size of Simplifier = {terms: 336, types: 242, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\n*** Demand analysis:\r\nResult size of Demand analysis\r\n = {terms: 336, types: 242, coercions: 25}\r\n*** Core Linted result of Demand analysis:\r\n*** Worker Wrapper binds:\r\nResult size of Worker Wrapper binds\r\n = {terms: 369, types: 283, coercions: 25}\r\n*** Core Linted result of Worker Wrapper binds:\r\n*** Simplifier:\r\nResult size of Simplifier iteration=1\r\n = {terms: 354, types: 266, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\nResult size of Simplifier = {terms: 354, types: 266, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\n*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):\r\nResult size of Float out(FOS {Lam = Just 0,\r\n Consts = True,\r\n OverSatApps = True})\r\n = {terms: 356, types: 267, coercions: 25}\r\n*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):\r\n*** Common sub-expression:\r\nResult size of Common sub-expression\r\n = {terms: 356, types: 267, coercions: 25}\r\n*** Core Linted result of Common sub-expression:\r\n*** Float inwards:\r\nResult size of Float inwards\r\n = {terms: 356, types: 267, coercions: 25}\r\n*** Core Linted result of Float inwards:\r\n*** Simplifier:\r\nResult size of Simplifier = {terms: 356, types: 267, coercions: 25}\r\n*** Core Linted result of Simplifier:\r\n*** Tidy Core:\r\nResult size of Tidy Core = {terms: 356, types: 267, coercions: 25}\r\n*** Core Linted result of Tidy Core:\r\nwriteBinIface: 18 Names\r\nwriteBinIface: 81 dict entries\r\n*** CorePrep:\r\nResult size of CorePrep = {terms: 654, types: 379, coercions: 25}\r\n*** Core Linted result of CorePrep:\r\n*** Stg2Stg:\r\n*** CodeGen:\r\n*** Assembler:\r\n/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -x assembler -c /tmp/ghc1541_0/ghc_2.s -o Main.o\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: /tmp/ghc1541_0/ghc_3.c /tmp/ghc1541_0/ghc_2.s /tmp/ghc1541_0/ghc_1.s\r\nWarning: deleting non-existent /tmp/ghc1541_0/ghc_3.c\r\nWarning: deleting non-existent /tmp/ghc1541_0/ghc_1.s\r\nlink: linkables are ...\r\nLinkableM (2016-04-05 15:42:11.288210053 UTC) Main\r\n [DotO Main.o]\r\nLinking Main ...\r\n*** C Compiler:\r\n/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_4.c -o /tmp/ghc1541_0/ghc_5.o -I/usr/lib/ghc-7.10.3/include\r\n*** C Compiler:\r\n/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_7.s -o /tmp/ghc1541_0/ghc_8.o -I/usr/lib/ghc-7.10.3/include\r\n*** Linker:\r\n/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -o Main Main.o Test.o -L/usr/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM -L/usr/lib/ghc-7.10.3/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/usr/lib/ghc-7.10.3/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/lib/ghc-7.10.3/rts /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_8.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -lgmp -lm -lrt -ldl\r\nlink: done\r\n*** Deleting temp files:\r\nDeleting: /tmp/ghc1541_0/ghc_10.rsp /tmp/ghc1541_0/ghc_9.rsp /tmp/ghc1541_0/ghc_8.o /tmp/ghc1541_0/ghc_7.s /tmp/ghc1541_0/ghc_6.rsp /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_4.c\r\n*** Deleting temp dirs:\r\nDeleting: /tmp/ghc1541_0\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/11810Filtering of cost-center profiler output no longer works2019-07-07T18:28:26ZBen GamariFiltering of cost-center profiler output no longer worksWith the following testcase,
```hs
import Control.Monad (replicateM)
main :: IO ()
main = do
let xs = replicate 10000000 $ 42
print $ length xs
print $ sum xs
```
Running like this,
```
ghc -prof -auto-all Hi.hs && ./Hi +...With the following testcase,
```hs
import Control.Monad (replicateM)
main :: IO ()
main = do
let xs = replicate 10000000 $ 42
print $ length xs
print $ sum xs
```
Running like this,
```
ghc -prof -auto-all Hi.hs && ./Hi +RTS -hy[] -hc
```
with 7.10.3 produces a useful profile with the output one would expect. 8.0.1-rc2, on the other hand produces empty samples.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Filtering of cost-center profiler output no longer works","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With the following testcase,\r\n{{{#!hs\r\nimport Control.Monad (replicateM)\r\n\r\nmain :: IO ()\r\nmain = do\r\n let xs = replicate 10000000 $ 42\r\n print $ length xs\r\n print $ sum xs\r\n}}}\r\n\r\nRunning like this,\r\n{{{\r\nghc -prof -auto-all Hi.hs && ./Hi +RTS -hy[] -hc\r\n}}}\r\nwith 7.10.3 produces a useful profile with the output one would expect. 8.0.1-rc2, on the other hand produces empty samples.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11830Disabling idle GC leads to freeze2019-07-07T18:28:22ZNeil MitchellDisabling idle GC leads to freezeI'm currently getting a runtime freeze with a spinning CPU with the latest GHC 8.0.1 RC (8.0.0.20160411). Testing 2 months ago on whatever was the latest release candidate showed no problems. The reproduction steps are a bit long winded:...I'm currently getting a runtime freeze with a spinning CPU with the latest GHC 8.0.1 RC (8.0.0.20160411). Testing 2 months ago on whatever was the latest release candidate showed no problems. The reproduction steps are a bit long winded:
- All tested on Ubuntu Linux.
- Checkout Shake, https://github.com/ndmitchell/shake.git (currently at 75505baa5fc5d1b99a1162edae6ecf7669f00ed9).
- `cabal install`
- Checkout Ninja, https://github.com/ninja-build/ninja.git (currently at 78f548880e549c701bd77760e4b3f3a4ee147641).
- Change to the `ninja` directory.
- Run `./configure.py --bootstrap`
- Run `cp ninja nin`
- Run `./nin -t clean`
- Run `shake`
Observe that Shake fails to complete and starts spinning on 1 CPU.
If you modify `shake.cabal` to remove `-with-rtsopts=-I0 -qg -qb` then it works again and completes in \< 1 min. Adding back flags with `+RTS -I0 -RTS` shows that `-I0` alone is the culprit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Disabling idle GC leads to freeze","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I'm currently getting a runtime freeze with a spinning CPU with the latest GHC 8.0.1 RC (8.0.0.20160411). Testing 2 months ago on whatever was the latest release candidate showed no problems. The reproduction steps are a bit long winded:\r\n\r\n* All tested on Ubuntu Linux.\r\n* Checkout Shake, https://github.com/ndmitchell/shake.git (currently at 75505baa5fc5d1b99a1162edae6ecf7669f00ed9).\r\n* {{{cabal install}}}\r\n* Checkout Ninja, https://github.com/ninja-build/ninja.git (currently at 78f548880e549c701bd77760e4b3f3a4ee147641).\r\n* Change to the {{{ninja}}} directory.\r\n* Run {{{./configure.py --bootstrap}}}\r\n* Run {{{cp ninja nin}}}\r\n* Run {{{./nin -t clean}}}\r\n* Run {{{shake}}}\r\n\r\nObserve that Shake fails to complete and starts spinning on 1 CPU.\r\n\r\nIf you modify {{{shake.cabal}}} to remove {{{-with-rtsopts=-I0 -qg -qb}}} then it works again and completes in < 1 min. Adding back flags with {{{+RTS -I0 -RTS}}} shows that {{{-I0}}} alone is the culprit.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/11997hSetFileSize zeroes file2019-07-07T18:28:04ZjaceredahSetFileSize zeroes fileThe following sequence:
```
cp /bin/echo /tmp/echo && ghc -e 'import System.IO' -e 'withFile "/tmp/echo" WriteMode (`hSetFileSize` 1000)'
```
results in /tmp/echo containing 1000 zeros. I would expect the truncated content as if trunca...The following sequence:
```
cp /bin/echo /tmp/echo && ghc -e 'import System.IO' -e 'withFile "/tmp/echo" WriteMode (`hSetFileSize` 1000)'
```
results in /tmp/echo containing 1000 zeros. I would expect the truncated content as if truncate() was called.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hSetFileSize zeroes file","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following sequence:\r\n\r\n\r\n{{{\r\ncp /bin/echo /tmp/echo && ghc -e 'import System.IO' -e 'withFile \"/tmp/echo\" WriteMode (`hSetFileSize` 1000)'\r\n}}}\r\n\r\nresults in /tmp/echo containing 1000 zeros. I would expect the truncated content as if truncate() was called.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12012Socket operations on Windows check errno instead of calling WSAGetLastError()2019-07-07T18:27:59ZenolanSocket operations on Windows check errno instead of calling WSAGetLastError()Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't unders...Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't understand it very well.
The upshot here is that every error message originating from Winsock is wrong. Nobody noticed since any error used to just crash your program (#12010).
Here's some MinGW documentation http://oldwiki.mingw.org/index.php/sockets and something from MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ms740121%28v=vs.85%29.aspx
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Socket operations on Windows check errno instead of calling WSAGetLastError()","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't understand it very well.\r\n\r\nThe upshot here is that every error message originating from Winsock is wrong. Nobody noticed since any error used to just crash your program (#12010).\r\n\r\nHere's some MinGW documentation http://oldwiki.mingw.org/index.php/sockets and something from MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ms740121%28v=vs.85%29.aspx","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1AzelAzelhttps://gitlab.haskell.org/ghc/ghc/-/issues/12134PowerPC 64-bit: Foreign functions with more than 8 float parameters broken2019-07-07T18:27:31ZPeter Trommlerptrommler@acm.orgPowerPC 64-bit: Foreign functions with more than 8 float parameters brokenConsider the following:
```c
void many_floats(float f1, float f2, float f3, float f4, float f5,
float f6, float f7, float f8, float f9, float f10,
float f11, float f12, float f13, float f14) {
printf(...Consider the following:
```c
void many_floats(float f1, float f2, float f3, float f4, float f5,
float f6, float f7, float f8, float f9, float f10,
float f11, float f12, float f13, float f14) {
printf("%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n",
f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13, f14);
}
```
and
```hs
foreign import ccall "many_floats" many :: CFloat -> CFloat ->
CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat ->
CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> IO ()
main = many 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5 10.5 11.5 12.5 13.5 14.5
```
gives
```
1.500000
2.500000
3.500000
4.500000
5.500000
6.500000
7.500000
8.500000
0.000000
0.000000
3.000000
14.500000
13.500000
0.000000
```
on PowerPC 64-bit Linux.
According to the ABI for PowerPC 64-bit ELF v1.9 and ELF v2.0 the first 13 floating or double parameters are passed in floating point registers.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"PowerPC 64-bit: Foreign functions with more than 8 float parameters broken","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"trommler"},"version":"8.0.1","keywords":["ccall"],"differentials":[],"test_case":"","architecture":"","cc":["erikd","hvr"],"type":"Bug","description":"Consider the following:\r\n{{{#!c\r\nvoid many_floats(float f1, float f2, float f3, float f4, float f5,\r\n float f6, float f7, float f8, float f9, float f10,\r\n float f11, float f12, float f13, float f14) {\r\n printf(\"%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n%f\\n\",\r\n\t f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13, f14);\r\n}\r\n}}}\r\nand\r\n{{{#!hs\r\nforeign import ccall \"many_floats\" many :: CFloat -> CFloat ->\r\n CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat ->\r\n CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> IO ()\r\nmain = many 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5 10.5 11.5 12.5 13.5 14.5\r\n}}}\r\ngives\r\n{{{\r\n1.500000\r\n2.500000\r\n3.500000\r\n4.500000\r\n5.500000\r\n6.500000\r\n7.500000\r\n8.500000\r\n0.000000\r\n0.000000\r\n3.000000\r\n14.500000\r\n13.500000\r\n0.000000\r\n}}}\r\non PowerPC 64-bit Linux.\r\n\r\nAccording to the ABI for PowerPC 64-bit ELF v1.9 and ELF v2.0 the first 13 floating or double parameters are passed in floating point registers.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/12167<<loop>> when zip + unzipping a shadowed Vector type variable2019-07-07T18:27:22Zmarkog<<loop>> when zip + unzipping a shadowed Vector type variable```hs
module Main where
import Data.Vector.Unboxed (Vector)
import qualified Data.Vector.Unboxed as V
(|>) :: a -> (a -> b) -> b
x |> f = f x
main = do
s <- do
x <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)
...```hs
module Main where
import Data.Vector.Unboxed (Vector)
import qualified Data.Vector.Unboxed as V
(|>) :: a -> (a -> b) -> b
x |> f = f x
main = do
s <- do
x <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)
d <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)
let
xd :: (Vector Int, Vector Int)
xd =
V.zip x d
|> V.unzip
(x,d) = xd -- here is where the error happens
-- returning xd works
-- removing the shadowing also works
in return x
print s
```
I do not see how the above code warrants a \<\<loop\>\> error as there is really no recursion in it. The linter always complains when I shadow variables, but I often use the above style in F\# to reduce the namespace bloat. Shadowing is not a problem when the variables have different types.
Is the above really a compiler error?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| 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":"<<loop>> when zip + unzipping a shadowed Vector type variable","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nmodule Main where\r\n import Data.Vector.Unboxed (Vector)\r\n import qualified Data.Vector.Unboxed as V\r\n\r\n (|>) :: a -> (a -> b) -> b\r\n x |> f = f x\r\n\r\n main = do\r\n s <- do\r\n x <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)\r\n d <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)\r\n let\r\n xd :: (Vector Int, Vector Int)\r\n xd =\r\n V.zip x d\r\n |> V.unzip\r\n (x,d) = xd -- here is where the error happens\r\n -- returning xd works\r\n -- removing the shadowing also works\r\n in return x\r\n print s\r\n}}}\r\n\r\nI do not see how the above code warrants a <<loop>> error as there is really no recursion in it. The linter always complains when I shadow variables, but I often use the above style in F# to reduce the namespace bloat. Shadowing is not a problem when the variables have different types.\r\n\r\nIs the above really a compiler error?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12186Windows linker stack commit setting causing issues2019-07-07T18:27:15Ztim-m89Windows linker stack commit setting causing issuesI've been trying to work on a library that allows Haskell to call into .Net code, but there's a major show stopper in that the .Net runtime starting with version 4.0, doesn't like the executable files that GHC produces.
I've managed to ...I've been trying to work on a library that allows Haskell to call into .Net code, but there's a major show stopper in that the .Net runtime starting with version 4.0, doesn't like the executable files that GHC produces.
I've managed to reduce a test case to not actually depend on using Haskell, but just using GHC to compile a C file, and that C file being nothing but a dumb wrapper around a small dll. The resulting executable exhibits the incorrect behaviour:
```
> stack exec ghc -- main.c -no-hs-main
> main
1
2
3
4
5
6
ICLRRuntimeHost Start failed w/hr 0x80004005
```
Then I can also use GCC on the intermediate object file that was created, and produce an executable that exhibits the correct behaviour:
```
> stack exec gcc -- main.o -o main2.exe
> main2
1
2
3
4
5
6
7
8
```
I've put a copy of the test case here:
https://gitlab.com/tim-m89/DotNetHostingTest
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC compiled executable incompatible with 3rd party software","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"I've been trying to work on a library that allows Haskell to call into .Net code, but there's a major show stopper in that the .Net runtime starting with version 4.0, doesn't like the executable files that GHC produces.\r\n\r\nI've managed to reduce a test case to not actually depend on using Haskell, but just using GHC to compile a C file, and that C file being nothing but a dumb wrapper around a small dll. The resulting executable exhibits the incorrect behaviour:\r\n{{{\r\n> stack exec ghc -- main.c -no-hs-main\r\n> main\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\nICLRRuntimeHost Start failed w/hr 0x80004005\r\n}}}\r\n\r\nThen I can also use GCC on the intermediate object file that was created, and produce an executable that exhibits the correct behaviour:\r\n\r\n{{{\r\n> stack exec gcc -- main.o -o main2.exe\r\n> main2\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n}}}\r\n\r\nI've put a copy of the test case here:\r\nhttps://gitlab.com/tim-m89/DotNetHostingTest","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12194ghc-pkg, package database path containing a trailing slash, and ${pkgroot}2019-07-07T18:27:12Zdudeboutghc-pkg, package database path containing a trailing slash, and ${pkgroot}When passing a package database to ghc-pkg via GHC_PACKAGE_PATH or --package-db, ${pkgroot} does not get computed properly if the input path contains a trailing slash.
Default behavior:
$ ghc-pkg describe base \| grep pkgroot
> pkgr...When passing a package database to ghc-pkg via GHC_PACKAGE_PATH or --package-db, ${pkgroot} does not get computed properly if the input path contains a trailing slash.
Default behavior:
$ ghc-pkg describe base \| grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
Correct behavior (no trailing slash):
$ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base \| grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
$ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe base \| grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
Incorrect behavior (with trailing slash):
$ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe base \| grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d"
$ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe base \| grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d"
When this bug happens, ghc-pkg check complains about missing files for packages using ${pkgroot}.
This bug happens because ${pkgroot} is computed using takeDirectory. It should instead use (takeDirectory . dropTrailingPathSeparator)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg, package database path containing a trailing slash, and ${pkgroot}","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["pkgroot"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When passing a package database to ghc-pkg via GHC_PACKAGE_PATH or --package-db, ${pkgroot} does not get computed properly if the input path contains a trailing slash.\r\n\r\nDefault behavior:\r\n $ ghc-pkg describe base | grep pkgroot\r\n pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n\r\nCorrect behavior (no trailing slash):\r\n $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base | grep pkgroot\r\n pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n\r\n $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe base | grep pkgroot\r\n pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n\r\nIncorrect behavior (with trailing slash):\r\n $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe base | grep pkgroot\r\n pkgroot: \"/usr/lib/ghc-7.10.2/package.conf.d\"\r\n\r\n $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe base | grep pkgroot\r\n pkgroot: \"/usr/lib/ghc-7.10.2/package.conf.d\"\r\n\r\nWhen this bug happens, ghc-pkg check complains about missing files for packages using ${pkgroot}.\r\n\r\nThis bug happens because ${pkgroot} is computed using takeDirectory. It should instead use (takeDirectory . dropTrailingPathSeparator)","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12202GHC 7.10.3 throws away callstack frames in some cases2019-07-07T18:27:11ZBen GamariGHC 7.10.3 throws away callstack frames in some casesIt was noticed that GHC 7.10.3 sometimes drops outer callers from IP callstacks. For instance,
```hs
{-# LANGUAGE ImplicitParams #-}
import GHC.Stack
import Control.Monad.Catch
newtype MyError = MyError CallStack
instance Exception My...It was noticed that GHC 7.10.3 sometimes drops outer callers from IP callstacks. For instance,
```hs
{-# LANGUAGE ImplicitParams #-}
import GHC.Stack
import Control.Monad.Catch
newtype MyError = MyError CallStack
instance Exception MyError
instance Show MyError where
show (MyError e) = show e
fromEvents :: (MonadThrow m, ?loc :: CallStack) => m (Maybe Int)
fromEvents = do
Just <$> require 42
where
-- require :: (MonadThrow m, ?loc :: CallStack) => Int -> m Int
require n -- line 17
| even n = throwM $ MyError ?loc
| otherwise = return n
main = do
putStrLn "Hello world"
fromEvents -- line 24
```
GHC 8.0.1 produces the correct output,
```
$ ./Hi
Hello world
Hi: [("fromEvents",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]
```
GHC 7.10.3 produces only one
```hs
$ ./Hi
Hello world
Hi: CallStack {getCallStack = [("?loc",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 17, srcLocStartCol = 35, srcLocEndLine = 17, srcLocEndCol = 39})]}
```
Uncommenting the type signature for `require` however results in more-or-less the expected callstack with 7.10.3,
```hs
$ ./Hi
Hello world
Hi: CallStack {getCallStack = [("?loc",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 18, srcLocStartCol = 35, srcLocEndLine = 18, srcLocEndCol = 39}),("require",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 14, srcLocStartCol = 14, srcLocEndLine = 14, srcLocEndCol = 21}),("fromEvents",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 7.10.3 throws away callstack frames for outer","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It was noticed that GHC 7.10.3 sometimes drops outer callers from IP callstacks. For instance,\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ImplicitParams #-}\r\n\r\nimport GHC.Stack\r\nimport Control.Monad.Catch\r\n\r\nnewtype MyError = MyError CallStack\r\ninstance Exception MyError\r\n\r\ninstance Show MyError where\r\n show (MyError e) = show e\r\n\r\nfromEvents :: (MonadThrow m, ?loc :: CallStack) => m (Maybe Int)\r\nfromEvents = do\r\n Just <$> require 42\r\n where\r\n -- require :: (MonadThrow m, ?loc :: CallStack) => Int -> m Int\r\n require n -- line 17\r\n | even n = throwM $ MyError ?loc\r\n | otherwise = return n\r\n\r\n\r\nmain = do\r\n putStrLn \"Hello world\"\r\n fromEvents -- line 24\r\n}}}\r\n\r\n\r\nGHC 8.0.1 produces the correct output,\r\n{{{\r\n$ ./Hi\r\nHello world\r\nHi: [(\"fromEvents\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]\r\n}}}\r\n\r\nGHC 7.10.3 produces only one\r\n{{{#!hs\r\n$ ./Hi\r\nHello world\r\nHi: CallStack {getCallStack = [(\"?loc\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 17, srcLocStartCol = 35, srcLocEndLine = 17, srcLocEndCol = 39})]}\r\n}}}\r\n\r\nUncommenting the type signature for `require` however results in more-or-less the expected callstack with 7.10.3,\r\n{{{#!hs\r\n$ ./Hi\r\nHello world\r\nHi: CallStack {getCallStack = [(\"?loc\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 18, srcLocStartCol = 35, srcLocEndLine = 18, srcLocEndCol = 39}),(\"require\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 14, srcLocStartCol = 14, srcLocEndLine = 14, srcLocEndCol = 21}),(\"fromEvents\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]}\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/12403Template Haskell boxes unboxed tuple types when reifying them2019-07-07T18:26:46ZRyan ScottTemplate Haskell boxes unboxed tuple types when reifying themExample:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE UnboxedTuples #-}
module Main where
import Language.Haskell.TH
data T = T (# Int, Int #)
$(return [])
main :: IO ()
main = putStrLn $(reify ''T >>= stringE . pprint)
```
...Example:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE UnboxedTuples #-}
module Main where
import Language.Haskell.TH
data T = T (# Int, Int #)
$(return [])
main :: IO ()
main = putStrLn $(reify ''T >>= stringE . pprint)
```
```
$ /opt/ghc/8.0.1/bin/ghc -fforce-recomp Constraints.hs
[1 of 1] Compiling Main ( Constraints.hs, Constraints.o )
Linking Constraints ...
$ ./Constraints
data Main.T = Main.T ((,,,) GHC.Types.Int GHC.Types.Int)
```
Patch coming soon.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell boxes tuple types when reifying them","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Example:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# LANGUAGE UnboxedTuples #-}\r\nmodule Main where\r\n\r\nimport Language.Haskell.TH\r\n\r\ndata T = T (# Int, Int #)\r\n\r\n$(return [])\r\n\r\nmain :: IO ()\r\nmain = putStrLn $(reify ''T >>= stringE . pprint)\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc -fforce-recomp Constraints.hs\r\n[1 of 1] Compiling Main ( Constraints.hs, Constraints.o )\r\nLinking Constraints ...\r\n$ ./Constraints \r\ndata Main.T = Main.T ((,,,) GHC.Types.Int GHC.Types.Int)\r\n}}}\r\n\r\nPatch coming soon.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12469Memory fence on writes to MutVar/Array missing on ARM2019-07-07T18:26:28ZrrnewtonMemory fence on writes to MutVar/Array missing on ARMThe memory model question has been debated now and again. This
thread from ten years back
(https://mail.haskell.org/pipermail/haskell-prime/2006-April/001237.html)
lays out the basic situation with thunk update, writeIORef, and memory fe...The memory model question has been debated now and again. This
thread from ten years back
(https://mail.haskell.org/pipermail/haskell-prime/2006-April/001237.html)
lays out the basic situation with thunk update, writeIORef, and memory fences.
But we recently began experimenting with GHC on ARM platforms, and it
seems to lack a memory fence that the participants in the cited thread
expect it to have.
Here's an attempt to construct a program which writes fields of a data
structure, and then writes the pointer to that structure to an IORef,
without the proper fence inbetween:
```haskell
import Data.IORef
import Control.Concurrent
data Foo = Foo Int deriving Show
{-# NOINLINE mkfoo #-}
mkfoo x = Foo x
{-# NOINLINE dowrite #-}
dowrite r n = writeIORef r $! mkfoo n
main =
do r <- newIORef (Foo 3)
forkIO (dowrite r 4)
x <- readIORef r
print x
```
Here are the relevant bits of the CMM that results when compiled on an
ARM 64 machine:
```C
mkfoo_rn1_entry() // []
{ []
}
{offset
c40i:
P64[MainCapability+872] = P64[MainCapability+872] + 16;
if (P64[MainCapability+872] > I64[MainCapability+880]) goto c40m; else goto c40l;
c40m:
I64[MainCapability+928] = 16;
P64[MainCapability+24] = mkfoo_rn1_closure;
call (I64[MainCapability+16])(R1) args: 16, res: 0, upd: 8;
c40l:
I64[P64[MainCapability+872] - 8] = Foo_con_info;
P64[P64[MainCapability+872]] = P64[I64[MainCapability+856]];
P64[MainCapability+24] = P64[MainCapability+872] - 7;
I64[MainCapability+856] = I64[MainCapability+856] + 8;
call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8;
}
}
dowrite_entry() // []
{ []
}
{offset
c44j:
call a_r3Dy_entry() args: 24, res: 0, upd: 8;
}
}
a_r3Dy_entry() // [R1]
{ []
}
{offset
c41D:
if (I64[MainCapability+856] - 16 < I64[MainCapability+864]) goto c41H; else goto c41I;
c41H:
P64[MainCapability+24] = a_r3Dy_closure;
call (I64[MainCapability+16])(R1) args: 24, res: 0, upd: 8;
c41I:
I64[I64[MainCapability+856] - 8] = block_c41B_info;
P64[I64[MainCapability+856] - 16] = P64[I64[MainCapability+856] + 8];
I64[MainCapability+856] = I64[MainCapability+856] - 16;
call mkfoo_rn1_entry() args: 16, res: 8, upd: 8;
}
}
block_c41B_entry() // [R1]
{ []
}
{offset
c41B:
_s3Ep::P64 = P64[I64[MainCapability+856] + 8];
I64[I64[MainCapability+856] + 8] = block_c41G_info;
_s3Es::P64 = P64[MainCapability+24];
P64[MainCapability+24] = _s3Ep::P64;
P64[I64[MainCapability+856] + 16] = _s3Es::P64;
I64[MainCapability+856] = I64[MainCapability+856] + 8;
if (P64[MainCapability+24] & 7 != 0) goto u41S; else goto c41K;
u41S:
call block_c41G_entry(R1) args: 0, res: 0, upd: 0;
c41K:
call (I64[I64[P64[MainCapability+24]]])(R1) args: 8, res: 8, upd: 8;
}
}
block_c41G_entry() // [R1]
{ []
}
{offset
c41G:
_s3Ev::P64 = P64[P64[MainCapability+24] + 7];
P64[_s3Ev::P64 + 8] = P64[I64[MainCapability+856] + 8];
call "ccall" arg hints: [PtrHint,
PtrHint] result hints: [] dirty_MUT_VAR(MainCapability+24, _s3Ev::P64);
P64[MainCapability+24] = ()_closure+1;
I64[MainCapability+856] = I64[MainCapability+856] + 16;
call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8;
}
}
```
The fence should happen before the write of the pointer into the
IORef. I can't find the fence, and can't find a codepath in the
compiler that would insert it (i.e. with MO_WriteBarrier).
`dirty_MUT_VAR` is actually too late to perform the fence, but it
doesn't either:
```C
void
dirty_MUT_VAR(StgRegTable *reg, StgClosure *p)
{
Capability *cap = regTableToCapability(reg);
if (p->header.info == &stg_MUT_VAR_CLEAN_info) {
p->header.info = &stg_MUT_VAR_DIRTY_info;
recordClosureMutated(cap,p);
}
}
```
(Neither does `recordClosureMutated`.)8.0.2Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/12554Testsuite exhibits large amount of framework failures2019-07-07T18:26:07ZTamar ChristinaTestsuite exhibits large amount of framework failuresI've tried this on multiple computers and they all have the same issue.
I get around 400 testsuite failures with the error:
```
r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-inter...I've tried this on multiple computers and they all have the same issue.
I get around 400 testsuite failures with the error:
```
r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run T11797 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run T10734 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run T11345 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run T10820 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run T11484 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run T9022 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run T12130 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run T8761 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run T12513 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run T12530 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run')
```
What they all have in common is that they are all using the latest MSYS2 and tools:
```
Tamar@Squid MINGW64 ~/ghc
$ python3 --version
Python 3.5.2
Tamar@Squid MINGW64 ~/ghc
$ uname -a
MINGW64_NT-10.0 Kino 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite exibits large amount of framework failures","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've tried this on multiple computers and they all have the same issue.\r\n\r\nI get around 400 testsuite failures with the error:\r\n\r\n{{{\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run T11797 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run T10734 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run T11345 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run T10820 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run T11484 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run T9022 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run T12130 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run T8761 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run T12513 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run T12530 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run')\r\n}}}\r\n\r\nWhat they all have in common is that they are all using the latest MSYS2 and tools:\r\n\r\n{{{\r\nTamar@Squid MINGW64 ~/ghc\r\n$ python3 --version\r\nPython 3.5.2\r\n\r\nTamar@Squid MINGW64 ~/ghc\r\n$ uname -a\r\nMINGW64_NT-10.0 Kino 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12614Integer division can overwrite other arguments to foreign call2019-07-07T18:25:50ZjschollInteger division can overwrite other arguments to foreign callIf you call a foreign function, GHC can generate incorrect code while passing the arguments to the function, overwriting the 3rd argument if a later argument contains an integer division.
Main.hs:
```
{-# LANGUAGE ForeignFunctionInterf...If you call a foreign function, GHC can generate incorrect code while passing the arguments to the function, overwriting the 3rd argument if a later argument contains an integer division.
Main.hs:
```
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
{-# NOINLINE foo #-}
foo :: Int -> IO ()
foo x = c_foo 0 0 x $ x + x `quot` 10
foreign import ccall "foo" c_foo :: Int -> Int -> Int -> Int -> IO ()
main :: IO ()
main = do
foo 202
foo 203
foo 204
```
foo.c:
```
#include <stdio.h>
void foo(int a, int b, int c, int d) {
printf("%d, %d, %d, %d\n", a, b, c, d);
}
```
Expected output:
```
0, 0, 202, 222
0, 0, 203, 223
0, 0, 204, 224
```
Actual output:
```
0, 0, 2, 222
0, 0, 3, 223
0, 0, 4, 224
```
The bug has to be somewhere in the code generator. The cmm reads:
```
call "ccall" arg hints: [‘signed’, ‘signed’, ‘signed’, ‘signed’] result hints: [] foo(0, 0, _s3nE::I64, _s3nE::I64 + %MO_S_Quot_W64(_s3nE::I64, 10));
```
This generates the following assembler code:
```
xorl %edi,%edi
xorl %esi,%esi
movq %rbx,%rdx
movl $10,%ecx
movq %rax,%rdx <-- move 3rd argument into rdx
movq %rbx,%rax
movq %rdx,%r8
cqto
idivq %rcx <-- rax := rax / rcx; rdx := rax % rcx
movq %rbx,%rcx
addq %rax,%rcx
subq $8,%rsp
xorl %eax,%eax
movq %r8,%rbx
call foo
```
Thus rdx is overwritten again before the call, leading to incorrect results.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Integer division can overwrite other arguments to foreign call","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["division","integer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you call a foreign function, GHC can generate incorrect code while passing the arguments to the function, overwriting the 3rd argument if a later argument contains an integer division.\r\n\r\nMain.hs:\r\n\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule Main where\r\n\r\n{-# NOINLINE foo #-}\r\nfoo :: Int -> IO ()\r\nfoo x = c_foo 0 0 x $ x + x `quot` 10\r\n\r\nforeign import ccall \"foo\" c_foo :: Int -> Int -> Int -> Int -> IO ()\r\n\r\nmain :: IO ()\r\nmain = do\r\n foo 202\r\n foo 203\r\n foo 204\r\n}}}\r\n\r\nfoo.c:\r\n\r\n{{{\r\n#include <stdio.h>\r\n\r\nvoid foo(int a, int b, int c, int d) {\r\n printf(\"%d, %d, %d, %d\\n\", a, b, c, d);\r\n}\r\n}}}\r\n\r\nExpected output:\r\n{{{\r\n0, 0, 202, 222\r\n0, 0, 203, 223\r\n0, 0, 204, 224\r\n}}}\r\n\r\nActual output:\r\n{{{\r\n0, 0, 2, 222\r\n0, 0, 3, 223\r\n0, 0, 4, 224\r\n}}}\r\n\r\nThe bug has to be somewhere in the code generator. The cmm reads:\r\n\r\n{{{\r\ncall \"ccall\" arg hints: [‘signed’, ‘signed’, ‘signed’, ‘signed’] result hints: [] foo(0, 0, _s3nE::I64, _s3nE::I64 + %MO_S_Quot_W64(_s3nE::I64, 10));\r\n}}}\r\n\r\nThis generates the following assembler code:\r\n\r\n{{{\r\n xorl %edi,%edi\r\n xorl %esi,%esi\r\n movq %rbx,%rdx\r\n movl $10,%ecx\r\n movq %rax,%rdx <-- move 3rd argument into rdx\r\n movq %rbx,%rax\r\n movq %rdx,%r8\r\n cqto\r\n idivq %rcx <-- rax := rax / rcx; rdx := rax % rcx\r\n movq %rbx,%rcx\r\n addq %rax,%rcx\r\n subq $8,%rsp\r\n xorl %eax,%eax\r\n movq %r8,%rbx\r\n call foo\r\n}}}\r\n\r\nThus rdx is overwritten again before the call, leading to incorrect results.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12736Calling a complex Haskell function (obtained via FFI wrapper function) from M...2019-07-07T18:25:21ZbavismCalling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modifiedAccording to the [MSDN](https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx), in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer vi...According to the [MSDN](https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx), in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer via dynamic wrapper that, when called from MSVC x64 C code, does not preserve these registers, causing further floating-point operations in the C code to fail.
I can reproduce this error in [this project](https://github.com/bavis-m/raycast), which is a DOOM-style raycasting engine written in Haskell, that imports a C DLL with glue for rendering and window management. The Haskell executable generates a FunPtr to a frame update function using the dynamic import mechanism, and passes this to a long-lived C function that runs the update loop. Any time this update function is called from the C loop, subsequent floating point operations produce incorrect results (in this case, the next operations compute a view matrix for the OpenGL window).
The output on every frame showing the view matrix should be:
```
viewM: 0.003125 0.000000 0.000000 -1.000000
0.000000 0.004167 0.000000 -1.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000
```
Running the raycaster with the Release version of the DLL causes the value of this matrix to be corrupted. There is a patch provided (stub.patch in the root folder) that turns the Haskell update function into an empty stub. This causes the program to work. When stepping through the assembly code with this patch applied, I can see in the function prologue where the XMM registers are saved. Without the patch, these registers are not saved. Running the Debug version does not show this error; the register allocation must be different.
I have been attempting to create a much simpler test case to reveal this code-generation issue, however it has been difficult. Even seemingly trivial changes can cause the bug to not show up, it is clearly dependent on the register allocation used internally to produce the assembly code.
Instructions for building the project are in the readme. (You will need the Haskell Stack Tool, and Visual Studio 15).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":["ffi,registers,sse2,clobber,xmm"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to the [https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx MSDN], in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer via dynamic wrapper that, when called from MSVC x64 C code, does not preserve these registers, causing further floating-point operations in the C code to fail.\r\n\r\nI can reproduce this error in [https://github.com/bavis-m/raycast this project], which is a DOOM-style raycasting engine written in Haskell, that imports a C DLL with glue for rendering and window management. The Haskell executable generates a FunPtr to a frame update function using the dynamic import mechanism, and passes this to a long-lived C function that runs the update loop. Any time this update function is called from the C loop, subsequent floating point operations produce incorrect results (in this case, the next operations compute a view matrix for the OpenGL window).\r\n\r\nThe output on every frame showing the view matrix should be:\r\n{{{\r\nviewM: 0.003125 0.000000 0.000000 -1.000000\r\n 0.000000 0.004167 0.000000 -1.000000\r\n 0.000000 0.000000 1.000000 0.000000\r\n 0.000000 0.000000 0.000000 1.000000\r\n}}}\r\n\r\nRunning the raycaster with the Release version of the DLL causes the value of this matrix to be corrupted. There is a patch provided (stub.patch in the root folder) that turns the Haskell update function into an empty stub. This causes the program to work. When stepping through the assembly code with this patch applied, I can see in the function prologue where the XMM registers are saved. Without the patch, these registers are not saved. Running the Debug version does not show this error; the register allocation must be different.\r\n\r\nI have been attempting to create a much simpler test case to reveal this code-generation issue, however it has been difficult. Even seemingly trivial changes can cause the bug to not show up, it is clearly dependent on the register allocation used internally to produce the assembly code.\r\n\r\nInstructions for building the project are in the readme. (You will need the Haskell Stack Tool, and Visual Studio 15).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12802prototype mismatch with EFF_ from unregisterisered GHC when building ieee7542019-07-07T18:25:06Zclintprototype mismatch with EFF_ from unregisterisered GHC when building ieee754Where building ieee754 succeeded with GHC 7.10, it fails with 8.0 on platforms without registerised builds, for example arm64:
```
[1 of 2] Compiling Numeric.IEEE ( Numeric/IEEE.hs, dist-ghc/build/Numeric/IEEE.o )
In file included ...Where building ieee754 succeeded with GHC 7.10, it fails with 8.0 on platforms without registerised builds, for example arm64:
```
[1 of 2] Compiling Numeric.IEEE ( Numeric/IEEE.hs, dist-ghc/build/Numeric/IEEE.o )
In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error:
/tmp/ghc8e40_0/ghc_2.hc:2448:6: error:
error: conflicting types for 'nextup'
EFF_(nextup);
^
/usr/lib/ghc/include/Stg.h:228:24: error:
note: in definition of macro 'EFF_'
#define EFF_(f) void f() /* See Note [External function prototypes] */
^
In file included from /usr/include/features.h:364:0: error:
0,
from /usr/include/math.h:26,
from /usr/lib/ghc/include/Stg.h:74,
from /tmp/ghc8e40_0/ghc_2.hc:3:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error:
note: previous declaration of 'nextup' was here
__MATHCALL (nextup,, (_Mdouble_ __x));
^
In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error:
/tmp/ghc8e40_0/ghc_2.hc:2501:6: error:
error: conflicting types for 'nextup'
EFF_(nextup);
^
/usr/lib/ghc/include/Stg.h:228:24: error:
note: in definition of macro 'EFF_'
#define EFF_(f) void f() /* See Note [External function prototypes] */
^
In file included from /usr/include/features.h:364:0: error:
0,
from /usr/include/math.h:26,
from /usr/lib/ghc/include/Stg.h:74,
from /tmp/ghc8e40_0/ghc_2.hc:3:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error:
note: previous declaration of 'nextup' was here
__MATHCALL (nextup,, (_Mdouble_ __x));
^
In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error:
/tmp/ghc8e40_0/ghc_2.hc:2554:6: error:
error: conflicting types for 'nextupf'
EFF_(nextupf);
^
/usr/lib/ghc/include/Stg.h:228:24: error:
note: in definition of macro 'EFF_'
#define EFF_(f) void f() /* See Note [External function prototypes] */
^
In file included from /usr/lib/ghc/include/Stg.h:74:0: error:
0,
from /tmp/ghc8e40_0/ghc_2.hc:3:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error:
note: previous declaration of 'nextupf' was here
__MATHCALL (nextup,, (_Mdouble_ __x));
^
In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error:
/tmp/ghc8e40_0/ghc_2.hc:2607:6: error:
error: conflicting types for 'nextupf'
EFF_(nextupf);
^
/usr/lib/ghc/include/Stg.h:228:24: error:
note: in definition of macro 'EFF_'
#define EFF_(f) void f() /* See Note [External function prototypes] */
^
In file included from /usr/lib/ghc/include/Stg.h:74:0: error:
0,
from /tmp/ghc8e40_0/ghc_2.hc:3:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error:
note: previous declaration of 'nextupf' was here
__MATHCALL (nextup,, (_Mdouble_ __x));
^
In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error:
/tmp/ghc8e40_0/ghc_2.hc:2660:6: error:
error: conflicting types for 'nextdown'
EFF_(nextdown);
^
/usr/lib/ghc/include/Stg.h:228:24: error:
note: in definition of macro 'EFF_'
#define EFF_(f) void f() /* See Note [External function prototypes] */
^
In file included from /usr/include/features.h:364:0: error:
0,
from /usr/include/math.h:26,
from /usr/lib/ghc/include/Stg.h:74,
from /tmp/ghc8e40_0/ghc_2.hc:3:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error:
note: previous declaration of 'nextdown' was here
__MATHCALL (nextdown,, (_Mdouble_ __x));
^
In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error:
/tmp/ghc8e40_0/ghc_2.hc:2713:6: error:
error: conflicting types for 'nextdown'
EFF_(nextdown);
^
/usr/lib/ghc/include/Stg.h:228:24: error:
note: in definition of macro 'EFF_'
#define EFF_(f) void f() /* See Note [External function prototypes] */
^
In file included from /usr/include/features.h:364:0: error:
0,
from /usr/include/math.h:26,
from /usr/lib/ghc/include/Stg.h:74,
from /tmp/ghc8e40_0/ghc_2.hc:3:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error:
note: previous declaration of 'nextdown' was here
__MATHCALL (nextdown,, (_Mdouble_ __x));
^
In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error:
/tmp/ghc8e40_0/ghc_2.hc:2766:6: error:
error: conflicting types for 'nextdownf'
EFF_(nextdownf);
^
/usr/lib/ghc/include/Stg.h:228:24: error:
note: in definition of macro 'EFF_'
#define EFF_(f) void f() /* See Note [External function prototypes] */
^
In file included from /usr/lib/ghc/include/Stg.h:74:0: error:
0,
from /tmp/ghc8e40_0/ghc_2.hc:3:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error:
note: previous declaration of 'nextdownf' was here
__MATHCALL (nextdown,, (_Mdouble_ __x));
^
In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error:
/tmp/ghc8e40_0/ghc_2.hc:2819:6: error:
error: conflicting types for 'nextdownf'
EFF_(nextdownf);
^
/usr/lib/ghc/include/Stg.h:228:24: error:
note: in definition of macro 'EFF_'
#define EFF_(f) void f() /* See Note [External function prototypes] */
^
In file included from /usr/lib/ghc/include/Stg.h:74:0: error:
0,
from /tmp/ghc8e40_0/ghc_2.hc:3:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error:
note: previous declaration of 'nextdownf' was here
__MATHCALL (nextdown,, (_Mdouble_ __x));
^
`gcc' failed in phase `C Compiler'. (Exit code: 1)
```
```
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv -fno-builtin")
,("C compiler command","/usr/bin/gcc")
,("C compiler flags"," -fno-stack-protector")
,("C compiler link flags"," -fuse-ld=gold -Wl,-z,noexecstack")
,("Haskell CPP command","/usr/bin/gcc")
,("Haskell CPP flags","-E -undef -traditional")
,("ld command","/usr/bin/ld.gold")
,("ld flags"," -z noexecstack")
,("ld supports compact unwind","YES")
,("ld supports build-id","YES")
,("ld supports filelist","NO")
,("ld is GNU ld","YES")
,("ar command","/usr/bin/ar")
,("ar flags","q")
,("ar supports at file","YES")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("libtool command","libtool")
,("perl command","/usr/bin/perl")
,("cross compiling","NO")
,("target os","OSLinux")
,("target arch","ArchARM64")
,("target word size","8")
,("target has GNU nonexec stack","True")
,("target has .ident directive","True")
,("target has subsections via symbols","False")
,("Unregisterised","YES")
,("LLVM llc command","llc-3.7")
,("LLVM opt command","opt-3.7")
,("Project version","8.0.1")
,("Project Git commit id","4986837f8168cacf95c24fecc84d7b36c47f3c11")
,("Booter version","7.10.3")
,("Stage","2")
,("Build platform","aarch64-unknown-linux")
,("Host platform","aarch64-unknown-linux")
,("Target platform","aarch64-unknown-linux")
,("Have interpreter","YES")
,("Object splitting supported","NO")
,("Have native code generator","NO")
,("Support SMP","NO")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p")
,("RTS expects libdw","NO")
,("Support dynamic-too","YES")
,("Support parallel --make","YES")
,("Support reexported-modules","YES")
,("Support thinning and renaming package flags","YES")
,("Requires unified installed package IDs","YES")
,("Uses package keys","YES")
,("Uses unit IDs","YES")
,("Dynamic by default","NO")
,("GHC Dynamic","YES")
,("GHC Profiled","NO")
,("Leading underscore","NO")
,("Debug on","False")
,("LibDir","/usr/lib/ghc")
,("Global Package DB","/usr/lib/ghc/package.conf.d")
]
```
The same is true for mips64el, s390x, alpha, hppa, m68k, sh4, sparc64, and I imagine mips and mipsel as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"prototype mismatch with EFF_ from unregisterisered GHC when building ieee754","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Where building ieee754 succeeded with GHC 7.10, it fails with 8.0 on platforms without registerised builds, for example arm64:\r\n\r\n{{{\r\n[1 of 2] Compiling Numeric.IEEE ( Numeric/IEEE.hs, dist-ghc/build/Numeric/IEEE.o )\r\n\r\nIn file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: \r\n\r\n/tmp/ghc8e40_0/ghc_2.hc:2448:6: error:\r\n error: conflicting types for 'nextup'\r\n EFF_(nextup);\r\n ^\r\n\r\n/usr/lib/ghc/include/Stg.h:228:24: error:\r\n note: in definition of macro 'EFF_'\r\n #define EFF_(f) void f() /* See Note [External function prototypes] */\r\n ^\r\n\r\nIn file included from /usr/include/features.h:364:0: error:\r\n 0,\r\n from /usr/include/math.h:26,\r\n from /usr/lib/ghc/include/Stg.h:74,\r\n from /tmp/ghc8e40_0/ghc_2.hc:3:\r\n\r\n/usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error:\r\n note: previous declaration of 'nextup' was here\r\n __MATHCALL (nextup,, (_Mdouble_ __x));\r\n ^\r\n\r\nIn file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: \r\n\r\n/tmp/ghc8e40_0/ghc_2.hc:2501:6: error:\r\n error: conflicting types for 'nextup'\r\n EFF_(nextup);\r\n ^\r\n\r\n/usr/lib/ghc/include/Stg.h:228:24: error:\r\n note: in definition of macro 'EFF_'\r\n #define EFF_(f) void f() /* See Note [External function prototypes] */\r\n ^\r\n\r\nIn file included from /usr/include/features.h:364:0: error:\r\n 0,\r\n from /usr/include/math.h:26,\r\n from /usr/lib/ghc/include/Stg.h:74,\r\n from /tmp/ghc8e40_0/ghc_2.hc:3:\r\n\r\n/usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error:\r\n note: previous declaration of 'nextup' was here\r\n __MATHCALL (nextup,, (_Mdouble_ __x));\r\n ^\r\n\r\nIn file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: \r\n\r\n/tmp/ghc8e40_0/ghc_2.hc:2554:6: error:\r\n error: conflicting types for 'nextupf'\r\n EFF_(nextupf);\r\n ^\r\n\r\n/usr/lib/ghc/include/Stg.h:228:24: error:\r\n note: in definition of macro 'EFF_'\r\n #define EFF_(f) void f() /* See Note [External function prototypes] */\r\n ^\r\n\r\nIn file included from /usr/lib/ghc/include/Stg.h:74:0: error:\r\n 0,\r\n from /tmp/ghc8e40_0/ghc_2.hc:3:\r\n\r\n/usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error:\r\n note: previous declaration of 'nextupf' was here\r\n __MATHCALL (nextup,, (_Mdouble_ __x));\r\n ^\r\n\r\nIn file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: \r\n\r\n/tmp/ghc8e40_0/ghc_2.hc:2607:6: error:\r\n error: conflicting types for 'nextupf'\r\n EFF_(nextupf);\r\n ^\r\n\r\n/usr/lib/ghc/include/Stg.h:228:24: error:\r\n note: in definition of macro 'EFF_'\r\n #define EFF_(f) void f() /* See Note [External function prototypes] */\r\n ^\r\n\r\nIn file included from /usr/lib/ghc/include/Stg.h:74:0: error:\r\n 0,\r\n from /tmp/ghc8e40_0/ghc_2.hc:3:\r\n\r\n/usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error:\r\n note: previous declaration of 'nextupf' was here\r\n __MATHCALL (nextup,, (_Mdouble_ __x));\r\n ^\r\n\r\nIn file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: \r\n\r\n/tmp/ghc8e40_0/ghc_2.hc:2660:6: error:\r\n error: conflicting types for 'nextdown'\r\n EFF_(nextdown);\r\n ^\r\n\r\n/usr/lib/ghc/include/Stg.h:228:24: error:\r\n note: in definition of macro 'EFF_'\r\n #define EFF_(f) void f() /* See Note [External function prototypes] */\r\n ^\r\n\r\nIn file included from /usr/include/features.h:364:0: error:\r\n 0,\r\n from /usr/include/math.h:26,\r\n from /usr/lib/ghc/include/Stg.h:74,\r\n from /tmp/ghc8e40_0/ghc_2.hc:3:\r\n\r\n/usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error:\r\n note: previous declaration of 'nextdown' was here\r\n __MATHCALL (nextdown,, (_Mdouble_ __x));\r\n ^\r\n\r\nIn file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: \r\n\r\n/tmp/ghc8e40_0/ghc_2.hc:2713:6: error:\r\n error: conflicting types for 'nextdown'\r\n EFF_(nextdown);\r\n ^\r\n\r\n/usr/lib/ghc/include/Stg.h:228:24: error:\r\n note: in definition of macro 'EFF_'\r\n #define EFF_(f) void f() /* See Note [External function prototypes] */\r\n ^\r\n\r\nIn file included from /usr/include/features.h:364:0: error:\r\n 0,\r\n from /usr/include/math.h:26,\r\n from /usr/lib/ghc/include/Stg.h:74,\r\n from /tmp/ghc8e40_0/ghc_2.hc:3:\r\n\r\n/usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error:\r\n note: previous declaration of 'nextdown' was here\r\n __MATHCALL (nextdown,, (_Mdouble_ __x));\r\n ^\r\n\r\nIn file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: \r\n\r\n/tmp/ghc8e40_0/ghc_2.hc:2766:6: error:\r\n error: conflicting types for 'nextdownf'\r\n EFF_(nextdownf);\r\n ^\r\n\r\n/usr/lib/ghc/include/Stg.h:228:24: error:\r\n note: in definition of macro 'EFF_'\r\n #define EFF_(f) void f() /* See Note [External function prototypes] */\r\n ^\r\n\r\nIn file included from /usr/lib/ghc/include/Stg.h:74:0: error:\r\n 0,\r\n from /tmp/ghc8e40_0/ghc_2.hc:3:\r\n\r\n/usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error:\r\n note: previous declaration of 'nextdownf' was here\r\n __MATHCALL (nextdown,, (_Mdouble_ __x));\r\n ^\r\n\r\nIn file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: \r\n\r\n/tmp/ghc8e40_0/ghc_2.hc:2819:6: error:\r\n error: conflicting types for 'nextdownf'\r\n EFF_(nextdownf);\r\n ^\r\n\r\n/usr/lib/ghc/include/Stg.h:228:24: error:\r\n note: in definition of macro 'EFF_'\r\n #define EFF_(f) void f() /* See Note [External function prototypes] */\r\n ^\r\n\r\nIn file included from /usr/lib/ghc/include/Stg.h:74:0: error:\r\n 0,\r\n from /tmp/ghc8e40_0/ghc_2.hc:3:\r\n\r\n/usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error:\r\n note: previous declaration of 'nextdownf' was here\r\n __MATHCALL (nextdown,, (_Mdouble_ __x));\r\n ^\r\n`gcc' failed in phase `C Compiler'. (Exit code: 1)\r\n}}}\r\n\r\n{{{\r\n [(\"Project name\",\"The Glorious Glasgow Haskell Compilation System\")\r\n ,(\"GCC extra via C opts\",\" -fwrapv -fno-builtin\")\r\n ,(\"C compiler command\",\"/usr/bin/gcc\")\r\n ,(\"C compiler flags\",\" -fno-stack-protector\")\r\n ,(\"C compiler link flags\",\" -fuse-ld=gold -Wl,-z,noexecstack\")\r\n ,(\"Haskell CPP command\",\"/usr/bin/gcc\")\r\n ,(\"Haskell CPP flags\",\"-E -undef -traditional\")\r\n ,(\"ld command\",\"/usr/bin/ld.gold\")\r\n ,(\"ld flags\",\" -z noexecstack\")\r\n ,(\"ld supports compact unwind\",\"YES\")\r\n ,(\"ld supports build-id\",\"YES\")\r\n ,(\"ld supports filelist\",\"NO\")\r\n ,(\"ld is GNU ld\",\"YES\")\r\n ,(\"ar command\",\"/usr/bin/ar\")\r\n ,(\"ar flags\",\"q\")\r\n ,(\"ar supports at file\",\"YES\")\r\n ,(\"touch command\",\"touch\")\r\n ,(\"dllwrap command\",\"/bin/false\")\r\n ,(\"windres command\",\"/bin/false\")\r\n ,(\"libtool command\",\"libtool\")\r\n ,(\"perl command\",\"/usr/bin/perl\")\r\n ,(\"cross compiling\",\"NO\")\r\n ,(\"target os\",\"OSLinux\")\r\n ,(\"target arch\",\"ArchARM64\")\r\n ,(\"target word size\",\"8\")\r\n ,(\"target has GNU nonexec stack\",\"True\")\r\n ,(\"target has .ident directive\",\"True\")\r\n ,(\"target has subsections via symbols\",\"False\")\r\n ,(\"Unregisterised\",\"YES\")\r\n ,(\"LLVM llc command\",\"llc-3.7\")\r\n ,(\"LLVM opt command\",\"opt-3.7\")\r\n ,(\"Project version\",\"8.0.1\")\r\n ,(\"Project Git commit id\",\"4986837f8168cacf95c24fecc84d7b36c47f3c11\")\r\n ,(\"Booter version\",\"7.10.3\")\r\n ,(\"Stage\",\"2\")\r\n ,(\"Build platform\",\"aarch64-unknown-linux\")\r\n ,(\"Host platform\",\"aarch64-unknown-linux\")\r\n ,(\"Target platform\",\"aarch64-unknown-linux\")\r\n ,(\"Have interpreter\",\"YES\")\r\n ,(\"Object splitting supported\",\"NO\")\r\n ,(\"Have native code generator\",\"NO\")\r\n ,(\"Support SMP\",\"NO\")\r\n ,(\"Tables next to code\",\"YES\")\r\n ,(\"RTS ways\",\"l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p\")\r\n ,(\"RTS expects libdw\",\"NO\")\r\n ,(\"Support dynamic-too\",\"YES\")\r\n ,(\"Support parallel --make\",\"YES\")\r\n ,(\"Support reexported-modules\",\"YES\")\r\n ,(\"Support thinning and renaming package flags\",\"YES\")\r\n ,(\"Requires unified installed package IDs\",\"YES\")\r\n ,(\"Uses package keys\",\"YES\")\r\n ,(\"Uses unit IDs\",\"YES\")\r\n ,(\"Dynamic by default\",\"NO\")\r\n ,(\"GHC Dynamic\",\"YES\")\r\n ,(\"GHC Profiled\",\"NO\")\r\n ,(\"Leading underscore\",\"NO\")\r\n ,(\"Debug on\",\"False\")\r\n ,(\"LibDir\",\"/usr/lib/ghc\")\r\n ,(\"Global Package DB\",\"/usr/lib/ghc/package.conf.d\")\r\n ]\r\n}}}\r\n\r\nThe same is true for mips64el, s390x, alpha, hppa, m68k, sh4, sparc64, and I imagine mips and mipsel as well.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13004Timeout no longer kills processes on timeout2019-07-07T18:24:09ZTamar ChristinaTimeout no longer kills processes on timeoutThere's a bug in timeout where processes aren't being killed on a timeout.
e.g. `~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 "sleep 10000s"` never ends
<details><summary>Trac metadata</summary>
| Trac field ...There's a bug in timeout where processes aren't being killed on a timeout.
e.g. `~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 "sleep 10000s"` never ends
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Timeout no longer kills processes on timeout","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There's a bug in timeout where processes aren't being killed on a timeout. \r\n\r\ne.g. `~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 \"sleep 10000s\"` never ends","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13007ghc-options -threaded present but -N option unrecognised on ARM2019-07-07T18:24:08Ztmpzghc-options -threaded present but -N option unrecognised on ARMWhen compiling a program on ARM (Raspberry PI 3, OS: Raspbian Jessi) with ghc it is possible to specify as runtime options
```
-threaded -rtsopts -with-rtsopts=-N
```
However when running the program with -N, -N is not a recognised opt...When compiling a program on ARM (Raspberry PI 3, OS: Raspbian Jessi) with ghc it is possible to specify as runtime options
```
-threaded -rtsopts -with-rtsopts=-N
```
However when running the program with -N, -N is not a recognised option. See output here http://pastebin.com/sKjfkRtq
Running with --info gives the following http://pastebin.com/q36Ef7y4 showing that ("RTS way", "rts_thr") is available.
Investigation already done here: https://www.reddit.com/r/haskell/comments/5j0u36/getting_haskell_and_stack_on_a_rapsberry_pi_3/dbcgbht/
Steps used to get ghc on the system: http://allocinit.io/haskell/haskell-on-raspberry-pi-3/
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-options -threaded present but -N option unrecognised on ARM","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["arm,","raspberrypi,","raspbian,","rts,","threaded"],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"When compiling a program on ARM (Raspberry PI 3, OS: Raspbian Jessi) with ghc it is possible to specify as runtime options\r\n\r\n{{{\r\n-threaded -rtsopts -with-rtsopts=-N\r\n}}}\r\n\r\nHowever when running the program with -N, -N is not a recognised option. See output here http://pastebin.com/sKjfkRtq\r\n\r\nRunning with --info gives the following http://pastebin.com/q36Ef7y4 showing that (\"RTS way\", \"rts_thr\") is available.\r\n\r\nInvestigation already done here: https://www.reddit.com/r/haskell/comments/5j0u36/getting_haskell_and_stack_on_a_rapsberry_pi_3/dbcgbht/\r\n\r\nSteps used to get ghc on the system: http://allocinit.io/haskell/haskell-on-raspberry-pi-3/","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13203Implement Bits Natural clearBit2019-07-07T18:23:12Zdylan@dylex.netImplement Bits Natural clearBitThe current Bits Natural implementation says:
`TODO: setBit, clearBit, complementBit (needs more primitives)`.
The default implementations of setBit and complementBit work fine, but clearBit relies on complement, and so fails. Even if it...The current Bits Natural implementation says:
`TODO: setBit, clearBit, complementBit (needs more primitives)`.
The default implementations of setBit and complementBit work fine, but clearBit relies on complement, and so fails. Even if it had to use a conditional complementBit on testBit, it would be better than nothing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement Bits Natural clearBit","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The current Bits Natural implementation says:\r\n{{{TODO: setBit, clearBit, complementBit (needs more primitives)}}}.\r\nThe default implementations of setBit and complementBit work fine, but clearBit relies on complement, and so fails. Even if it had to use a conditional complementBit on testBit, it would be better than nothing.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.2Sven TennieSven Tenniehttps://gitlab.haskell.org/ghc/ghc/-/issues/13285Bug in GHC.Stack.callStack when used with sections2019-07-07T18:22:36ZSimon Hengelsol@typeful.netBug in GHC.Stack.callStack when used with sectionsSince GHC `8.0.1` call stacks are not constructed consistently anymore. Specifically, no stack frames are added for call sites that use section syntax.
This used to work with GHC `7.10.2`. I haven't tried with `7.10.3`.
Call stacks are...Since GHC `8.0.1` call stacks are not constructed consistently anymore. Specifically, no stack frames are added for call sites that use section syntax.
This used to work with GHC `7.10.2`. I haven't tried with `7.10.3`.
Call stacks are used in `hspec` and `HUnit` to attach location information to failing test cases. Moreover, it is somewhat common to use section syntax with `hspec`. This is why I describe the bug in the context of `hspec`. But first, I give minimal steps on how to reproduce without the need of any additional dependencies.
# TL;DR Minimal steps to reproduce
```haskell
-- Main.hs
import GHC.Stack
main :: IO ()
main = do
foo 23 42
(`foo` 23) 42
foo :: HasCallStack => Int -> Int -> IO ()
foo _ _ = print (length . getCallStack $ callStack)
```
```
$ runhaskell Main.hs
```
expected output:
```
1
1
```
actual output:
```
1
0
```
# Description of the bug from a users perspective (in the context of Hspec)
This section describes the bug in the context of `hspec`. If you already understand how this bug affects users and why this is problematic you may choose to skip this section.
## A working example
Looking at the following example
```haskell
-- Spec.hs
import Test.Hspec
main :: IO ()
main = hspec $ do
it "works for my use case" $ do
23 `shouldBe` 42
```
call stacks work as expected:
```
$ runhaskell Spec.hs
...
Failures:
Spec.hs:6:
1) works for my use case
expected: 42
but got: 23
...
```
The users sees a source locations that points him to the failing test case.
## A slightly modified and broken example
If we rephrase the above example using section syntax we get
```haskell
-- Spec.hs
import Test.Hspec
main :: IO ()
main = hspec $ do
it "works for my use case" $ do
(`shouldBe` 42) 23
```
and things suddenly go bad:
```
$ runhaskell Spec.hs
...
Failures:
src/Test/Hspec/Expectations.hs:91:
1) works for my use case
expected: 42
but got: 23
...
```
The user expects to see the call site of `shouldBe`, that points him to the failing test case. But instead he gets an unhelpful location that points somewhere at the implementation of `hspec-expectations`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Bug in GHC.Stack.callStack when used with sections","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Since GHC {{{8.0.1}}} call stacks are not constructed consistently anymore. Specifically, no stack frames are added for call sites that use section syntax.\r\n\r\nThis used to work with GHC {{{7.10.2}}}. I haven't tried with {{{7.10.3}}}.\r\n\r\nCall stacks are used in {{{hspec}}} and {{{HUnit}}} to attach location information to failing test cases. Moreover, it is somewhat common to use section syntax with {{{hspec}}}. This is why I describe the bug in the context of {{{hspec}}}. But first, I give minimal steps on how to reproduce without the need of any additional dependencies.\r\n\r\n= TL;DR Minimal steps to reproduce\r\n\r\n{{{\r\n#!haskell\r\n-- Main.hs\r\nimport GHC.Stack\r\n\r\nmain :: IO ()\r\nmain = do\r\n foo 23 42\r\n (`foo` 23) 42\r\n\r\nfoo :: HasCallStack => Int -> Int -> IO ()\r\nfoo _ _ = print (length . getCallStack $ callStack)\r\n}}}\r\n{{{\r\n$ runhaskell Main.hs\r\n}}}\r\n\r\nexpected output:\r\n{{{\r\n1\r\n1\r\n}}}\r\n\r\nactual output:\r\n{{{\r\n1\r\n0\r\n}}}\r\n\r\n= Description of the bug from a users perspective (in the context of Hspec)\r\nThis section describes the bug in the context of {{{hspec}}}. If you already understand how this bug affects users and why this is problematic you may choose to skip this section.\r\n\r\n\r\n== A working example\r\nLooking at the following example\r\n{{{\r\n#!haskell\r\n-- Spec.hs\r\nimport Test.Hspec\r\n \r\nmain :: IO ()\r\nmain = hspec $ do\r\n it \"works for my use case\" $ do\r\n 23 `shouldBe` 42\r\n}}}\r\n\r\ncall stacks work as expected:\r\n\r\n{{{\r\n$ runhaskell Spec.hs\r\n...\r\nFailures:\r\n\r\n Spec.hs:6: \r\n 1) works for my use case\r\n expected: 42\r\n but got: 23\r\n...\r\n}}}\r\n\r\nThe users sees a source locations that points him to the failing test case.\r\n\r\n== A slightly modified and broken example\r\nIf we rephrase the above example using section syntax we get\r\n\r\n{{{\r\n#!haskell\r\n-- Spec.hs\r\nimport Test.Hspec\r\n\r\nmain :: IO ()\r\nmain = hspec $ do\r\n it \"works for my use case\" $ do\r\n (`shouldBe` 42) 23\r\n}}}\r\n\r\nand things suddenly go bad:\r\n\r\n{{{\r\n$ runhaskell Spec.hs\r\n...\r\nFailures:\r\n\r\n src/Test/Hspec/Expectations.hs:91: \r\n 1) works for my use case\r\n expected: 42\r\n but got: 23\r\n...\r\n}}}\r\n\r\nThe user expects to see the call site of {{{shouldBe}}}, that points him to the failing test case. But instead he gets an unhelpful location that points somewhere at the implementation of {{{hspec-expectations}}}.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Simon Peyton JonesSimon Peyton Jones