- ghc-tickets - Haskell.org

[GHC] #10133: Problemlösung pur- durch advana tone abnehmen
by GHC 03 Mar '15

03 Mar '15

#10133: Problemlösung pur- durch advana tone abnehmen -------------------------------------+------------------------------------- Reporter: betwig | 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: | -------------------------------------+------------------------------------- Eine erfolgsversprechende Diätstrategie mit Advana.Tone & Advana.Cleanse sind ein Geheimrezept im Gesundheitssektor. Dabei sind die Diätmittel 100% natürlich und für die Gesundheit unbedenklich. Durch die Erfahrung mit den Produkten ist bewiesen wurden, dass die neue Diätmethode über wenige Wochen bis zu 16 kg Gewichtsverlust bringt. Diese Ergebnisse sind bei anderen Schlankmachern bis heute in keiner Weise beobachtet wurden, diese bahnbrechende Diätstrategie ist also sehr vielversprechend. Erfahrungsrezensionen der Käufer mit Advana.Tone & Advana.Cleanse Mithilfe von diesen Diätpillen können hunderte Anwender nun wiederum zu dem Traumkörper finden und deswegen zu gewünschter Lebensqualität zurückfinden. Sind erstmal für den Stoffwechsel unabdingbare Prozesse im Körper in Gang gesetzt, kann zu körperlicher Kraft gefunden werden. Die Inhaltstoffe und Wirkweise von Advana-Tone & Advana.Cleanse In der neuen Diät werden neu entwickelte Stoffe verwendet, die eine Entschlackung des Körpers anregen. [http://www.advana-tone.net/ Advana Tone] unterstützt die Körperfett-Verbrennung und Advana.Cleanse sorgt für eine Entschlackung des Körpers. Die Zusammensetzung dieser neuen Diätprodukte sind unter anderem die Acai-Beere und ein Extrakt aus grünem Tee. Die Beeren der Acai enthalten viele gesunde Spurenelemente und Grüner-Tee-Extrakt enthält Abwehr- Substanzen. Advana-Tone & Advana.Cleanse im Test wir empfehlen diese Diät-Methode, da sie sehr vielen Personen helfen konnte und nicht zuletzt unser eigenes Testverfahren beste Testergebnisse gezeigt hat. Aber nicht nur beim Abnehmen helfen die Diätpillen, sie sind außerdem bei Profi-Bodybuildern für die fettminimierende doch gleichzeitig Muskel-erhaltenden Wirkungsweise berühmt. Die Substanzen in den Produkten sind allesamt klinisch getestet wurden und ihre Wirkung bewiesen. Zur Bestellweise von Advana Tone & Advana-Cleanse Die Hersteller sind ein geprüftes Unternehmen, das für die wirksamen Naturprodukte geschätzt ist. Die Käufer können nachweisen, dass der Anbieter sehr zuverlässig ist, eine Bestätigung dafür ist die Geld-zurück- Garantie.Diese Geld-zurück Garantie kann verlangt werden, sollten die Diätprodukte bei einer Person wirkungslos sein. Die Produkte können über das Internet bestellt werden und können den Empfänger innerhalb eines kurzen Zeitraums erreichen. Möchte man sich tiefer zu den Diätprodukten erkundigen, können verschiedene Testberichte im WWW aufgerufen werden. Darüber hinaus kann man sich über die Inhaltsstoffe belesen, die auf der Herstellerseite aufgelistet sind. Bei zusätzlichen Nachfragen kann man sich via Anfrage an den Hersteller richten um weitere Informationen über [http://www.advana-tone.net/category/advana-cleanse/ Advana Tone] und Advana Cleanse zu erlangen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8274: Core pretty-printer doesn't print # on unboxed literals
by GHC 03 Mar '15

03 Mar '15

#8274: Core pretty-printer doesn't print # on unboxed literals ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I just noticed that Core pretty printer produces something like this (this is part of expected output for T3772 in testsuite): {{{ case GHC.Prim.<=# n# 0 of _ { __DEFAULT -> xs n#; 1 -> GHC.Tuple.() } }}} Both `0` (in scrutinee) and `1` (one of branch alternatives) are unboxed values, so they should be printed as `0#` and `1#` respectively. I haven't checked whether unboxed literals of other types (`Word`, `Double`, `Float`) are printed in that way, but I would guess that yes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax
by GHC 03 Mar '15

03 Mar '15

#2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D669 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2530#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #17: Separate warnings for unused local and top-level bindings
by GHC 03 Mar '15

03 Mar '15

#17: Separate warnings for unused local and top-level bindings -------------------------------------+------------------------------------- Reporter: magunter | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: None Resolution: fixed | Keywords: -fwarn- Operating System: Unknown/Multiple | unused-binds newcomer Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #3283 | Test Case: | Blocking: | Differential Revisions: Phab:D591 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: None => fixed Comment: Merged, thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/17#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

03 Mar '15

#6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: Phab:D691 -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"5200bdeb26c5ec98739b14b10fc8907296bceeb9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5200bdeb26c5ec98739b14b10fc8907296bceeb9" Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64 Summary: On Windows, the default action for things like division by zero and segfaults is to pop up a Dr. Watson error reporting dialog if the exception is unhandled by the user code. This is a pain when we are SSHed into a Windows machine, or when we want to debug a problem with gdb (gdb will get a first and second chance to handle the exception, but if it doesn't the pop-up will show). veh_excn provides two macros, `BEGIN_CATCH` and `END_CATCH`, which will catch such exceptions in the entire process and die by printing a message and calling `stg_exit(1)`. Previously this code was handled using SEH (Structured Exception Handlers) however each compiler and platform have different ways of dealing with SEH. `MSVC` compilers have the keywords `__try`, `__catch` and `__except` to have the compiler generate the appropriate SEH handler code for you. `MinGW` compilers have no such keywords and require you to manually set the SEH Handlers, however because SEH is implemented differently in x86 and x64 the methods to use them in GCC differs. `x86`: SEH is based on the stack, the SEH handlers are available at `FS[0]`. On startup one would only need to add a new handler there. This has a number of issues such as hard to share handlers and it can be exploited. `x64`: In order to fix the issues with the way SEH worked in x86, on x64 SEH handlers are statically compiled and added to the .pdata section by the compiler. Instead of being thread global they can now be Image global since you have to specify the `RVA` of the region of code that the handlers govern. You can on x64 Dynamically allocate SEH handlers, but it seems that (based on experimentation and it's very under-documented) that the dynamic calls cannot override static SEH handlers in the .pdata section. Because of this and because GHC no longer needs to support < windows XP, the better alternative for handling errors would be using the in XP introduced VEH. The bonus is because VEH (Vectored Exception Handler) are a runtime construct the API is the same for both x86 and x64 (note that the Context object does contain CPU specific structures) and the calls are the same cross compilers. Which means this file can be simplified quite a bit. Using VEH also means we don't have to worry about the dynamic code generated by GHCi. Test Plan: Prior to this diff the tests for `derefnull` and `divbyzero` seem to have been disabled for windows. To reproduce the issue on x64: 1) open ghci 2) import GHC.Base 3) run: 1 `divInt` 0 which should lead to ghci crashing an a watson error box displaying. After applying the patch, run: make TEST="derefnull divbyzero" on both x64 and x86 builds of ghc to verify fix. Reviewers: simonmar, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D691 GHC Trac Issues: #6079 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6079#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10104: Show '#' on unboxed literals
by GHC 03 Mar '15

03 Mar '15

#10104: Show '#' on unboxed literals -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #8274 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, unboxed literals are shown in the same way as boxed literals (without #): {{{ Prelude> :set -XMagicHash Prelude> :m GHC.Prim Prelude GHC.Prim> data T = MkT Int# deriving Show Prelude GHC.Prim> MkT 3# MkT 3 }}} It would be nice if this would show `MkT 3#` instead. I have a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x
by GHC 03 Mar '15

03 Mar '15

#10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.11 (other) | Operating System: Solaris Keywords: | Type of failure: Building GHC Architecture: sparc | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello, recent HEAD is using integer-gmp2 wrapper around GMP library. This tries to be compatible with and use only functionality of GMP 4.x, but still it also uses some functions from GMP 5.x which makes this incompatible with GMP 4.x. The issue is for example shown on Solaris/SPARC platform where the OS provided library is GMP 4.3.2 and linking of stage2 binaries fails with: {{{ Undefined first referenced symbol in file __gmpn_andn_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_and_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_ior_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_xor_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) ld: fatal: symbol referencing errors. No output written to ghc/stage2/build/tmp/ghc-stage2 }}} the unresolve symbols are from GMP 5.x. GMP 4.x does not provide them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #2986: :info printing instances often isn't wanted
by GHC 03 Mar '15

03 Mar '15

#2986: :info printing instances often isn't wanted -------------------------------------+------------------------------------- Reporter: Remi | Owner: Remi Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: :info Operating System: Unknown/Multiple | instances Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #1581 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #1581 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2986#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs
by GHC 03 Mar '15

03 Mar '15

#2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs
by GHC 03 Mar '15

03 Mar '15

#2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): I have just (2015/03/03) written a shell script (attached) that tests for binutils support for 64 bit pc-relative relocatons. The test passes on *all* modern linux systems, but fails on Mac OSX (Mavericks) and OpenBSD 5.5 (current is 5.6). The failure is one OpenBSD says: {{{ linkasm.s:3: Error: can not do 8 byte pc-relative relocation }}} OpenBSD has GNU binutils 2.15 but they are unlikely to upgrade to a later version because later versions are under GPLv3 instead of GPLv2. However, they may at some stage switch to some other linker. OSX has the linker from LLVM which theoretically could be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0