January 2015 - ghc-tickets

[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 26 Jan '15

26 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

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

26 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: -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: simonmar (added) * owner: => Phyx- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6079#comment:9> 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 26 Jan '15

26 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 nomeata): I just put two 15000-element unboxed vector of Word16 in a module, using `fromList [...]` and compile time is annoying, and the runtime overhear is (possibly unjustified) worrying me. Having a way to have a literal form of such an array (which then hopefully is put into the program as-is) would be nice. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #9674, #9921, #9970
by GHC 26 Jan '15

26 Jan '15

Batch modification to #9674, #9921, #9970 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 milestone. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=9674%2C9921%2C9970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5364: Access RTS flag values from inside Haskell programs
by GHC 26 Jan '15

26 Jan '15

#5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10022 | Blocking: | Differential Revisions: Phab:D306 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * related: => #10022 Comment: Yes, we should make those cleanups. I've filed another ticket: #10022. However, this ticket is (in general) worth closing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5364#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1851: "make install-strip" should work
by GHC 26 Jan '15

26 Jan '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9961: compile-time performance regression compiling genprimcode
by GHC 26 Jan '15

26 Jan '15

#9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- compiling `utils/genprimopcode` (where compiling the Alex-generated Lexer takes up the most amount of time) with GHC 7.8.4: ``` $ time /opt/ghc/7.8.4/bin/ghc -Rghc-timing --make -O Main.hs [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) [5 of 5] Compiling Main ( Main.hs, Main.o ) Linking Main ... <<ghc: 20742311240 bytes, 2092 GCs, 60174814/140258264 avg/max bytes residency (33 samples), 332M in use, 0.00 INIT (0.00 elapsed), 7.84 MUT (8.35 elapsed), 6.93 GC (6.93 elapsed) :ghc>> real 0m15.331s user 0m15.173s sys 0m0.172s ``` (btw, is it ok that GC takes up so much?) the same with a GHC 7.10 snapshot takes *alot* longer: ``` $ time /opt/ghc/7.10.1/bin/ghc -Rghc-timing --make -O Main.hs [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) [5 of 5] Compiling Main ( Main.hs, Main.o ) Linking Main ... <<ghc: 147681534568 bytes, 37824 GCs, 203338614/375314176 avg/max bytes residency (538 samples), 876M in use, 0.001 INIT (0.001 elapsed), 81.374 MUT (81.888 elapsed), 235.240 GC (235.136 elapsed) :ghc>> real 5m17.061s user 5m16.702s sys 0m0.499s ``` ...and here the GC/MUT ratio is even more off. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9961> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD
by GHC 26 Jan '15

26 Jan '15

#7273: Binary size increase in nofib/grep between 7.6.1 and HEAD -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7273#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 26 Jan '15

26 Jan '15

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Runtime System | Milestone: 7.12.1 Resolution: | Version: Operating System: MacOS X | Keywords: thread- Type of failure: Runtime | local state, TLS clang performance bug | Architecture: x86_64 Blocked By: 7678 | (amd64) Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0