#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 simonpj):
Thanks for producing a patch. THAT is the best way to move the ticket
forward!
I've added a saying: The above patches look commendably small. But the
resulting code contains absolutely no clue about the importance of the way
those particular lines of code are written. Please, I beg,
* write a Note [Deterministic builds] somewhere,
* describe the issues in the note,
* mention the ticket #4012 for more background
* refer to the Note from the places in the code that are carefully
written to support determinism
See our [wiki:Commentary/CodingStyle Coding Style guidelines].
Thank you!
Does that close the ticket? Or are there further determinism issues?
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:52>
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):
I submitted a patch yesterday with which I managed to create byte-
identical binaries with `ghc --make` (and `cabal build` if you use cabal
1.20):
https://github.com/nh2/ghc/compare/deterministic-binarieshttps://phabricator.haskell.org/D175
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:51>
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 Fuuzetsu):
I just had a problem due to this on NixOS, what would be the way to push
this ticket forward bar fixing it myself? I'm afraid that it will just
keep getting the milestone bumped forever.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:49>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#1487: unix package: test needed for getLoginName
-------------------------------------+-------------------------------------
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: lowest | Milestone:
Component: | Version:
libraries/unix | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: Linux | Difficulty: Easy (less than 1
Type of failure: Incorrect | hour)
result at runtime | Blocked By:
Test Case: | Related Tickets: #8293
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by ezyang):
From a cygwin terminal, I am moshed into a screen session. I can't easily
test xterm because I don't have X forwarding.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1487#comment:25>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#1487: unix package: test needed for getLoginName
-------------------------------------+-------------------------------------
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: lowest | Milestone:
Component: | Version:
libraries/unix | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: Linux | Difficulty: Easy (less than 1
Type of failure: Incorrect | hour)
result at runtime | Blocked By:
Test Case: | Related Tickets: #8293
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by thomie):
@ezyang: which terminal emulator are you using? Does it work with `xterm`?
Maybe we should change the signature of `getLoginName` to:
{{{
getLoginName :: IO (Maybe String)
}}}
, since the man page explicitly mentions that
[http://linux.die.net/man/3/getlogin getlogin] can return NULL:
{{{
getlogin() returns a pointer to a string containing the name of the
user logged in on the controlling terminal of the process, or a NULL
pointer if this information cannot be determined.
}}}
The same applies to `getGroupEntryForID`, ticket #8293.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1487#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#1487: unix package: test needed for getLoginName
-------------------------------------+-------------------------------------
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: lowest | Milestone:
Component: | Version:
libraries/unix | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: Linux | Difficulty: Easy (less than 1
Type of failure: Incorrect | hour)
result at runtime | Blocked By:
Test Case: | Related Tickets: #8293
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Changes (by ezyang):
* owner: thomie =>
* status: closed => new
* resolution: fixed =>
Comment:
Hello, the test is still failing for me, using GHC HEAD and the latest
version of unix:
{{{
=====> user001(normal) 5 of 29 [0, 0, 0]
cd . && '/5playpen/t-edyang/ghc-master/inplace/bin/ghc-stage2' -fforce-
recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopts -fno-ghci-history -o user001 user001.hs -package unix
>user001.comp.stderr 2>&1
cd . && ./user001 >user001.run.stdout 2>user001.run.stderr
Actual stdout output differs from expected:
--- ./user001.stdout 2014-08-22 23:28:41.969906580 +0100
+++ ./user001.run.stdout 2014-08-23 00:33:07.631841764 +0100
@@ -3,11 +3,11 @@
getEffectiveUserID: OK
getEffectiveGroupID: OK
getGroups: OK
-getLoginName: OK
+getLoginName: ERROR: getLoginName: does not exist (No such file or
directory)
getEffectiveUserName: OK
getGroupEntryForID: OK
getGroupEntryForName: OK
getAllGroupEntries: OK
getUserEntryForID: OK
-getUserEntryForName: OK
+getUserEntryForName: ERROR: getLoginName: does not exist (No such file or
directory)
getAllUserEntries: OK
*** unexpected failure for user001(normal)
Unexpected results from:
TEST="user001"
}}}
On my box, running the following C program in terminal returns null:
{{{
#include <stdio.h>
#include <unistd.h>
int main() {
printf("%p\n", getlogin());
}
}}}
This StackOverflow post suggests that getlogin works quite unreliably:
http://stackoverflow.com/questions/4785126/getlogin-c-function-returns-
null-and-error-no-such-file-or-directory
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1487#comment:23>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7206: Implement cheap build
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: ⊥
Component: Compiler | Version: 7.4.2
Resolution: | Keywords:
Operating System: | Architecture: Unknown/Multiple
Unknown/Multiple | Difficulty: Unknown
Type of failure: | Blocked By:
None/Unknown | Related Tickets:
Test Case: |
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by dfeuer):
Even more kinds of producers makes for even more fusion rules. If we
decide to rewrite ''all'' consumers to `foldr`, I suppose that then opens
up the possibility of having multiple producers instead, but expanding on
both ends makes for a rule explosion. I'm also trying, on and off, to see
if we can get away with writing all these enumerations using `unfoldr` or
similar; I'm not sure how these ideas interact.
An idea that might be crazy: introduce a local annotation indicating that
a certain function should be treated as `CONLIKE` at a particular call
site. So then you'd have just `{-# CHEAP #-} build blah` and leave the
fusion rules alone.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
