- ghc-tickets - Haskell.org

[GHC] #8650: Unexpected behaviour of import ccall "header.h function"
by GHC 22 Dec '14

22 Dec '14

#8650: Unexpected behaviour of import ccall "header.h function" ------------------------------------+-------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- When I write {{{ foreign import ccall "myheader.h myfunction" function :: IO ... }}} Is GHC supposed to check the existence of the header file, or do anything with it? Because I can still write {{{"myheaderBLA.h myfunction"}}} and it doesn't care about the first word (no error, ever, not even in linking, executable builds all fine). ---- Relatedly, I can write {{{ foreign import ccall "some.rubbish" f :: IO ... }}} and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain. carter suggested that maybe names with a dot inside are ignored by a linker. This leads me to the question: In my example above, is {{{myheaderBLA.h}}} actually understood as some kind of file and ignored by e.g. GHC, or is it a garbled symbol name? In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest this if the {{{"string.h"}}} part is ignored? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9916: ghc -e ":foo bar" exit status is inconsistent
by GHC 22 Dec '14

22 Dec '14

#9916: ghc -e ":foo bar" exit status is inconsistent -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #7962, #9905 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Since #7962 `ghc -e EXPR` exits with status code 1 if `EXPR` fails to compile. While it's undocumented, `ghc -e` does also accept anything that's valid input to GHCi, including GHCi commands like `:t`. In this case, the exit code of `ghc -e` is not always 1 when the command apparently failed. For example, all of: {{{ ghc -e ':t' ghc -e ':t +' ghc -e ':t =' ghc -e ':t x' ghc -e ':l nonexistentfile.hs' }}} exit with status code 0. But `ghc -e ':l a'` exits with status code 1, because `a` is not a (possible) module name or a source file. (At the code level, `ghc -e ":foo bar"` currently exits with status code 1 when the function for `:foo` raises an exception, and with status code 0 in all other cases.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3814: Compile to more than one (sub)-architecture
by GHC 22 Dec '14

22 Dec '14

#3814: Compile to more than one (sub)-architecture -------------------------------------+------------------------------------- Reporter: filcab | Owner: Type: feature | Status: closed request | Milestone: ⊥ Priority: normal | Version: 6.12.1 Component: Compiler | Keywords: architecture, Resolution: duplicate | compiler, x86_64 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4163 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): The description touches on two issues: (1) being able to cross-compile at all and (2) being able to generate code for several different targets with the same compiler by using command-line switches. We have (1) currently (though it's a bit DIY), but not (2). But I'll let someone else file a feature request for (2) if they want it, since I'm not convinced it's sufficiently more valuable than just having one ghc installed for each target. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3814#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9909: Linker error (TemplateHaskell + HPC?)
by GHC 21 Dec '14

21 Dec '14

#9909: Linker error (TemplateHaskell + HPC?) -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm getting the following error message when compiling a Yesod application (which uses Template Haskell rather a lot) with -fhpc: {{{ /usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when making a shared object; recompile with -fPIC }}} Steps to reproduce: 1. Run `yesod init` to make a new scaffold. Call it `testsite` and select `simple` for no database. 2. Run: {{{ cd testsite ghc --make app/main.hs -XTemplateHaskell -XCPP -XOverloadedStrings -XMultiParamTypeClasses -XTypeFamilies -XQuasiQuotes -fhpc -O1 }}} Running the `ghc` line again completes successfully. It seems that there is a missing `./Settings.dyn_o` in the `gcc` command line that `ghc` calls, the first time through. It's there the second time so the link succeeds. No idea what that might mean. It's not a problem at `-O0`. I'm using 7.8.3 so this might be fixed now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9913: Discrepancy in type synonym definition and usage
by GHC 21 Dec '14

21 Dec '14

#9913: Discrepancy in type synonym definition and usage -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Minor consistency issue, the following compiles fine (note parentheses): {{{#!hs type Alg f a = f a -> a initial :: Alg(f) a initial = undefined }}} But changing the definition to mirror its use: {{{#!hs type Alg(f) a = f a -> a initial :: Alg(f) a initial = undefined }}} and it fails with: {{{#!hs Unexpected type ‘f’ In the type declaration for ‘Alg’ A type declaration should have form type Alg a b c = ... Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9913> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5001: makeCorePair: arity missing
by GHC 21 Dec '14

21 Dec '14

#5001: makeCorePair: arity missing -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | deSugar/should_compile/T5001 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: simonpj => * status: closed => new * resolution: fixed => Comment: Not fully fixed yet. I just observed this when compiling `mono- traversable-0.6.2` using GHC-7.8.4-rc1: {{{ [2 of 7] Compiling Data.MonoTraversable ( src/Data/MonoTraversable.hs, dist-ghc/build/Da ta/MonoTraversable.o ) src/Data/MonoTraversable.hs:39:1: Warning: The import of `$, replicate' from module `Prelude' is redundant makeCorePair: arity missing $cofoldMap{v aaQ1} [lid] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5001#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9912: Where injured soldiers
by GHC 20 Dec '14

20 Dec '14

#9912: Where injured soldiers -------------------------------------+------------------------------------- Reporter: ZafinaPrincess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Where injured soldiers would occasionally go into shock and I within minutes are being given blood from plastic I V bottles before that time blood was stored in glass bottles but in 1948 with the invention a plastic blood storage bags the military abandon the story to blooding glass bottles since they were too easily broken in a wartime environment unfortunately but ballads leaked from the plastic bags into the stored blood. http://xtremenitrotruth.com/blackline-elite/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9908: Improve enumFromX support for OverloadedLists
by GHC 19 Dec '14

19 Dec '14

#9908: Improve enumFromX support for OverloadedLists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At present, `OverloadedLists` desugars `[m..n]` as `fromList (enumFromTo m n)`. This is sometimes okay, but terrible for `Data.Sequence`. In particular, I want, for example, {{{#!hs [m..n] :: Seq Int }}} to end up as `fromFunction (n-m+1) (+m)`, which performs much better. There are a few approaches that look reasonable: 1. Try to catch `fromList (enumFromTo m n)` before `enumFromTo` becomes `eftInt`. This does not, unfortunately, seem to work. 2. Grab `eftInt` after it gets written back from `eftIntFB`. This would probably work, but it's currently impossible because `eftInt` is not exported from `GHC.Exts` or even `GHC.Enum`. 3. Add `enumFromTo`, etc., to the `IsList` class. Default to the current behavior, but if possible use `fromListN` for well-known `Enum` types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically
by GHC 19 Dec '14

19 Dec '14

#9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHC API | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: 9480, 8935, 8376 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is code from the dynamic-cabal project, but I've distilled it into an easier test case. Basically you load a module that calls the Cabal configure function, and we try to call a function and get the result. This works fine if the executable is compiled with -dynamic, but segfaults (on Ubuntu at least) if the executable is static. I've had that behavior since 7.8.1 and I've seen several similar bugs come and be fixed, but the issue is still present in 7.8.4 rc1 (ghc-7.8.3.20141119) I attach the full project, with the cabal file, the Main.hs module that loads the DynamicCabalQuery.hs module -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9845> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7473: getModificationTime gives only second-level resolution
by GHC 19 Dec '14

19 Dec '14

#7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by redneb): I just posted a pull request for that on github: https://github.com/haskell/directory/pull/11. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7473#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0