#6077: Respect XDG_CONFIG_HOME
-------------------------------------+-------------------------------------
Reporter: So8res | Owner:
Type: feature | Status: new
request | Milestone:
Priority: normal | Version: 7.4.1
Component: None | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: Linux | Difficulty: Unknown
Type of failure: Other | Blocked By: 5966
Test Case: | Related Tickets:
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by god):
Supporting XDG spec in the standard library is one thing but actually
converting the ghc itself to use it is another. Those tasks are certainly
related but I think it's worth to keep the corresponding bugs separate.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6077#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4012: Compilation results are not deterministic
-------------------------------------+-------------------------------------
Reporter: kili | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.10.1
Component: Compiler | Version: 6.12.2
Resolution: | Keywords:
Operating System: | Architecture: Unknown/Multiple
Unknown/Multiple | Difficulty: Difficult (2-5
Type of failure: Other | days)
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by nh2):
@simonmar: Then I shall leave this ticket to issues concerning (1), and
create a separate one for byte-identical compilation.
Why would you want byte-identical compilation (or, how Debian calls it,
"reproducible builds")? There are a few reasons (3 is the key point for me
right now):
1. Distributions want it (see
https://wiki.debian.org/ReproducibleBuilds#Why_do_we_want_reproducible_buil…)
2. It allows users of open source projects (e.g. Tor, TrueCrypt had famous
efforts in this direction) to verify that the binary they downloaded
really is built from the unmodified source
3. It gives recompilation avoidance in build systems outside of GHC. If
the binary you just produced is byte-identical to what was already there,
you can stop (e.g. don't need to run tests in CI etc.).
And finally, a more-belief-than-evidence-supported point:
5. It will improve binary distributions of cabal packages and similar
things. For example, I would like to build a Haskell equivalent to
`ccache`, and having byte-identical output for the same input would make
that much easier.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:56>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9538: unwords does not participate in list fusion
-------------------------------------+-------------------------------------
Reporter: dfeuer | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.2
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 not quite sure how far this can go, but `unwords` should almost
certainly be a good consumer or a good consumer. Currently it is neither.
Making it a good consumer is trivial, given `concatMap` that fuses:
{{{#!hs
unwords = tail . concatMap (' ':)
}}}
Alternatively, we should be able to make it a good producer without too
much trouble, I think. I have my doubts about making it both.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9538>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9512: T9329 fails test on unregisterised i386
----------------------------+-------------------------------------------
Reporter: slyfox | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.3
Keywords: | Operating System: Unknown/Multiple
Architecture: x86 | Type of failure: None/Unknown
Difficulty: Unknown | Test Case: T9329
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
----------------------------+-------------------------------------------
ghc-HEAD '''./configure --enable-unregistersied''' on i386-linux fails as:
{{{
=====> T9329(normal) 118 of 4091 [0, 0, 0]
cd ./codeGen/should_compile && '/root/ghc/inplace/bin/ghc-stage2' -fforce-
recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopts -optc-fno-builtin -fno-ghci-history -c T9329.cmm -no-hs-main
>T9329.comp.stderr 2>&1
Compile failed (status 256) errors were:
/tmp/ghc23160_0/ghc23160_2.hc: In function ‘foo’:
/tmp/ghc23160_0/ghc23160_2.hc:10:12:
error: ‘c0_info’ undeclared (first use in this function)
*Sp = (W_)&c0_info;
^
/tmp/ghc23160_0/ghc23160_2.hc:10:12:
note: each undeclared identifier is reported only once for each
function it appears in
}}}
The generated C code is:
{{{
/* GHC_PACKAGES
*/
#include "Stg.h"
FN_(foo) {
FB_
_c0:
if ((W_)(((W_)Sp-4) < (W_)SpLim)) goto _c2; else goto _c3;
_c2:
*Sp = (W_)&c0_info;
JMP_((W_)&stg_gc_noregs);
_c3:
R1.w = 0x0;
JMP_(*((P_)(*Sp)));
FE_
}
}}}
while on UNREG x86_64 test does not fail and generates the following C:
{{{
/* GHC_PACKAGES
*/
#include "Stg.h"
FN_(foo) {
FB_
_c0:
goto _c3;
_c3:
R1.w = 0x0;
JMP_(*((P_)(*Sp)));
FE_
}
}}}
Looks like there is no stack check at all.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9512>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4012: Compilation results are not deterministic
-------------------------------------+-------------------------------------
Reporter: kili | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.10.1
Component: Compiler | Version: 6.12.2
Resolution: | Keywords:
Operating System: | Architecture: Unknown/Multiple
Unknown/Multiple | Difficulty: Difficult (2-5
Type of failure: Other | days)
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by simonmar):
We can separate this problem into two:
1. non-determinism in the ABI, which leads to different ABI hashes being
generated, and different package identities in the package database. This
annoys OS packagers, who like to be able to generate deterministic package
names.
2. non-determinism in the generated object file. (who cares about this
and why?)
(1) is a prerequisite for (2), and (2) is more difficult. The ticket
description contains a list of issues that need to be fixed for (1).
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:55>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#367: Infinite loops can hang Concurrent Haskell
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: ezyang
Type: bug | Status: new
Priority: lowest | Milestone: ⊥
Component: Compiler | Version: 6.4.1
Resolution: None | Keywords: scheduler
Operating System: | allocation
Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: Incorrect | Difficulty: Unknown
result at runtime | Blocked By:
Test Case: | Related Tickets:
concurrent/should_run/T367, |
concurrent/should_run/T367_letnoescape|
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by simonmar):
Yes, this is an instance of the bug. Does it work with `-fno-omit-
yields`?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/367#comment:40>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#367: Infinite loops can hang Concurrent Haskell
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: ezyang
Type: bug | Status: new
Priority: lowest | Milestone: ⊥
Component: Compiler | Version: 6.4.1
Resolution: None | Keywords: scheduler
Operating System: | allocation
Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: Incorrect | Difficulty: Unknown
result at runtime | Blocked By:
Test Case: | Related Tickets:
concurrent/should_run/T367, |
concurrent/should_run/T367_letnoescape|
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by jberryman):
As a user I'm having trouble understanding if the bug being discussed is
the one reported. To be clear, is the following (very similar to #8521) an
instance of this bug? Compiled with ghc 7.8.3 with `-O2 -threaded`, run
with `+RTS -N` on a machine with two real cores.
{{{
module Main
where
import Data.IORef
import Control.Concurrent
main = do
r <- newIORef False
putStrLn "About to fork"
forkIO $ f r
threadDelay 1000000 -- 1 second
putStrLn "Why is this never printed?!"
writeIORef r True
-- and why do we never exit?
f :: IORef Bool -> IO ()
f r = readIORef r >>= \b-> if b then print "Done" else f r
}}}
This wouldn't seem to have anything to do with whether `f`'s thread can be
pre-empted or not, which is why I'm unsure.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/367#comment:39>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
