- ghc-tickets - Haskell.org

Re: [GHC] #2615: ghci doesn't play nice with linker scripts
by GHC 29 Jan '15

29 Jan '15

#2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Jinhui_Chen): * cc: hvr (added) * owner: hgolden => * status: closed => new * resolution: fixed => Comment: I recently encounter a problem which I think is related to this bug. This is illustrated by this Haskell program: {{{ import ObjLink import Foreign import Foreign.C.Types import Foreign.C.String foreign import ccall "setlocale" c_setlocale :: CInt -> CString -> IO CString main = do withCString "zh_CN.UTF-8" $ \lc -> c_setlocale 5 lc r <- loadDLL "/usr/lib/libc.so" putStrLn (show r) }}} which outputs: {{{ Just "/usr/lib/libc.so: \26080\25928\30340 ELF \22836" }}} The "\26080\25928\30340 ELF \22836" part is "无效的ELF头" in Chinese. I suspect the problem is caused by addDLL function, which expects dlopen to return "invalid ELF header", and that is not true on non-C/non-en locales. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2615#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10042: progain 350 overview
by GHC 29 Jan '15

29 Jan '15

#10042: progain 350 overview -------------------------------------+------------------------------------- Reporter: Holten | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- More power with the help of Progain 350 and [http://progain350-uk.com/progain-350-testinate-250/ Testinate 250] Do you belong also to the people who like to run quickly build muscle and burn calories at the same time want? Then do the Progain 350 experience when you did your workout sometimes insufficient condition, which prepares you to create your goal difficulty? No matter what you have learned so far about muscle building products, Progain 350 and Testinate 250 offer excellent help in training. Now there are no more excuses. Do you want to buy Progain 350? Additional or on the [http://progain350-uk.com/progain-350-testinate-250-ingredients-effect/ Progain 350 ingredients effect] experienced then read on. Progain 350 ingredients and the effect we have recorded in a detailed self-test. That intensive training needs to effectively build muscle, which is obvious to all of us. But the result is always the question why people still keep up with a similar physique in training highly varying lengths of time. Would you also like to effectively build muscle as others? Use Progain 350, so that a real rock is from you. Experience muscles of steel and a sexy body shape. To draw the attention of all girls guaranteed to be! Go from increased by 52% from structure to muscles. The compiled by the developers formulation is based on the effect of nitric oxide. During exercise, the body must be available enough. With Progain 350 you can do just that. The constituents nitrogen oxides are made available which make it conceivable to train and extremely easy to manage your fixed workouts. Fast fatigue and performance lows thing of the past. Start by same. Become quickly limp when running training? Have you set appropriate workouts, but they can still barely cope? Then you should use Progain 350 and feel like you can work out with a much longer time. With up to 41 percent more performance you can make a persistent and successful training and felt easier to reach your goal. Forget the training days when you did not want or condition. Win with 350 Progain now the necessary fighting spirit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9928: Wrong information about the version of the time library in the release notes of various versions of GHC
by GHC 29 Jan '15

29 Jan '15

#9928: Wrong information about the version of the time library in the release notes of various versions of GHC -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The information about the version of the time library is wrong in the release notes of [https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release… GHC 7.10.1], [https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/release-7-8-… GHC 7.8.3] and [https://downloads.haskell.org/~ghc/7.6.1/docs/html/users_guide/release-7-6-… GHC 7.6.1]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9928> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux
by GHC 29 Jan '15

29 Jan '15

#9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------+---------------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: Other | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- When cross-compiling from x86_64-linux to aarch64-linux I get: {{{ rts/StgCRun.c: In function ‘StgRun’: rts/StgCRun.c:756:5: error: unknown register name ‘%lr’ in ‘asm’ __asm__ volatile ( }}} It seems the asm code here is for iOS and does not work for Linux. Have a patch in progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10031: coerce can cause compiler to loop
by GHC 29 Jan '15

29 Jan '15

#10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This program causes GHC to loop at compile time {{{ {-# LANGUAGE ScopedTypeVariables #-} import Data.Coerce coerce' :: Coercible b a => a -> b coerce' = coerce (\x -> x :: b) :: forall a b. Coercible b a => a -> b }}} I encountered this trying to use a similar construction in https://github.com/glguy/profunctors/blob/coerce/src/Data/Profunctor/Unsafe… I'm not absolutely certain about what aspect of this snippet is looping the compiler, but it's pretty small. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10031> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10040: Add hint on typed-hole error message
by GHC 28 Jan '15

28 Jan '15

#10040: Add hint on typed-hole error message -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If you write {{{ f flag = _flag + 4 }}} it's possible that you didn't intend a typed hole; you just mis-typed `_flag`. So I propose to add hint to the error message saying that {{{ Found hole ‘_flag’ with type: t Where: ...blah blah... Or perhaps ‘_flag’ is mis-spelled, or not in scope Relevant bindings include it :: t (bound at <interactive>:9:1) }}} The third line is the new one. See [https://www.haskell.org/pipermail/glasgow-haskell- users/2015-January/025599.html this email trail]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 28 Jan '15

28 Jan '15

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Segmentation fault, segfault, long Type of failure: Runtime crash | input Blocked By: 4258 | Architecture: x86_64 Related Tickets: | (amd64) | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by merijn): * cc: merijn (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 27 Jan '15

27 Jan '15

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: 7.12.1 Resolution: | Version: 7.0.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime | Architecture: performance bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 5877 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it. Does anyone feel motivated to actually work on this ticket? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10028: GHC Panic (The Impossible Happened)
by GHC 27 Jan '15

27 Jan '15

#10028: GHC Panic (The Impossible Happened) -------------------------------------+------------------------------------- Reporter: | Owner: archaephyrryx | Status: new Type: bug | Milestone: Priority: normal | Version: 7.4.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time panic,impossible,irrefutable | crash Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): compiler/rename/RnPat.lhs:535:39-79: Irrefutable pattern failed for pattern gres@(gre : _) }}} Cause: Importing a Module containing a record-syntax defined datatype, hiding one of the record fields, causes the use of the language pragma RecordWildCards to make GHC encounter a fatal error. A minimal reproduction case is attached to this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #6079: SEH exception handler not implemented on Win64
by GHC 27 Jan '15

27 Jan '15

#6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): Summary of what's changed and how It affects the GHC side of things: on x86 SEH handling was done via the stack. On a thread FS[0] would always point to the SEH linked list. It was also prone to buffer overflows and made it hard to share error handlers. on x64 it was cleaned up a bit and the EH information is now stored in the the PE headers in tables. instead of an EH covering an entire thread until popped, you know have to explicitly specify the rva (relative virtual address) of the region to which the EH should apply. Microsoft compilers calculate this information at compile time from the !__try, !__catch and !__except1 symbols and this information is statically added to the PE file. GCC's implementation works by dynamically manipulating the table (using '''RtlAddFunctionTable''' and related functions). It's implemented in MingW64 from version 4.6.2 (current version of msys2 ships with newer version so should be fine) and is based on GAS's implementation http://code.google.com/p/propgcc/source/browse/binutils/gas/config/obj- coff-seh.h The only way to use this is inline assembly in gcc: BEGIN_CATCH and END_CATCH theoretically become: >long CALLBACK !__hs_exception_handler(EXCEPTION_POINTERS *exception_data); >#define BEGIN_CATCH asm (".l_start:\n" \ > "\t.seh_handler !__C_specific_handler, @except\n" \ > "\t.seh_handlerdata\n" \ > "\t.long 1\n" \ > "\t.rva .l_start, .l_end, !__hs_exception_handler, .l_end\n" \ > "\t.text" \ > ); > #define END_CATCH asm ("nop\n" \ > "\t.l_end:\n" \ > "\tnop\n" \ > ); everything between the .l_start and .l_end label is covered by the function !__hs_exception_handler. {{{ The interesting part here is the line "\t.rva .l_startw, .l_endw, _gnu_exception_handler ,.l_endw\n". The first rva is the start-address of the first instruction within try-block, the next is the end-address of the try-block (be aware that it needs to +1 after end of last instruction in try-block). The third rva is the handler to be called, and the fourth is the address of the finally-block. }}} (NOTE: the \t are only for indenting if viewing the dissassembly generated from gcc with -S) --- Implementation wise, a few things make it difficult: 1) the function real_main() in RtsMain is decorated with !__noreturn!__, this makes GCC perform dead code elimination and remove the END_CATCH, the linker will then refuse to link as the .l_end label will be missing. Instead moving the BEGIN_CATCH and END_CATCH blocks inside the real_main to appropriate positions allows it all to work. --- I have the changes implemented but the handler is not being called for some reason. I will figure out what's wrong and create a patch. I'm concerned that when linking, the .l_end label is put in a position that does not cover the user code, in which case this implementation would probably get more complex -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6079#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0