summaryrefslogtreecommitdiff
path: root/compiler/codeGen
diff options
context:
space:
mode:
Diffstat (limited to 'compiler/codeGen')
-rw-r--r--compiler/codeGen/StgCmmClosure.hs6
-rw-r--r--compiler/codeGen/StgCmmExpr.hs4
-rw-r--r--compiler/codeGen/StgCmmHeap.hs2
3 files changed, 6 insertions, 6 deletions
diff --git a/compiler/codeGen/StgCmmClosure.hs b/compiler/codeGen/StgCmmClosure.hs
index 8a32a7fff9..fff2078237 100644
--- a/compiler/codeGen/StgCmmClosure.hs
+++ b/compiler/codeGen/StgCmmClosure.hs
@@ -732,7 +732,7 @@ blackHoleOnEntry cl_info
{- Note [Black-holing non-updatable thunks]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We must not black-hole non-updatable (single-entry) thunks otherwise
-we run into issues like Trac #10414. Specifically:
+we run into issues like #10414. Specifically:
* There is no reason to black-hole a non-updatable thunk: it should
not be competed for by multiple threads
@@ -745,7 +745,7 @@ we run into issues like Trac #10414. Specifically:
- is not updated (of course)
- hence, if it is black-holed and another thread tries to evaluate
it, that thread will block forever
- This actually happened in Trac #10414. So we do not black-hole
+ This actually happened in #10414. So we do not black-hole
non-updatable thunks.
* How could two threads evaluate the same non-updatable (single-entry)
@@ -755,7 +755,7 @@ we run into issues like Trac #10414. Specifically:
thunk, because lazy black-holing only affects thunks with an
update frame on the stack.
-Here is and example due to Reid Barton (Trac #10414):
+Here is and example due to Reid Barton (#10414):
x = \u [] concat [[1], []]
with the following definitions,
diff --git a/compiler/codeGen/StgCmmExpr.hs b/compiler/codeGen/StgCmmExpr.hs
index 5ad2e98abc..70a044a7ab 100644
--- a/compiler/codeGen/StgCmmExpr.hs
+++ b/compiler/codeGen/StgCmmExpr.hs
@@ -375,7 +375,7 @@ Suppose we have this STG code:
f = \[s : State# RealWorld] ->
case s of _ -> blah
This is very odd. Why are we scrutinising a state token? But it
-can arise with bizarre NOINLINE pragmas (Trac #9964)
+can arise with bizarre NOINLINE pragmas (#9964)
crash :: IO ()
crash = IO (\s -> let {-# NOINLINE s' #-}
s' = s
@@ -532,7 +532,7 @@ See Note [case on bool]
It's odd, and it's flagrantly inconsistent with the rules described
Note [Compiling case expressions]. However, after eliminating the
-tagToEnum# (Trac #13397) we will have:
+tagToEnum# (#13397) we will have:
case (a>b) of ...
Rather than make it behave quite differently, I am testing for a
comparison operator here in in the general case as well.
diff --git a/compiler/codeGen/StgCmmHeap.hs b/compiler/codeGen/StgCmmHeap.hs
index 3b170eb3a1..da9e85f1e7 100644
--- a/compiler/codeGen/StgCmmHeap.hs
+++ b/compiler/codeGen/StgCmmHeap.hs
@@ -519,7 +519,7 @@ heapCheck checkStack checkYield do_gc code
[" Trying to allocate more than "++show mBLOCK_SIZE++" bytes.",
"",
"This is currently not possible due to a limitation of GHC's code generator.",
- "See http://ghc.haskell.org/trac/ghc/ticket/4505 for details.",
+ "See https://gitlab.haskell.org/ghc/ghc/issues/4505 for details.",
"Suggestion: read data from a file instead of having large static data",
"structures in code."]
| hpHw > 0 = Just (mkIntExpr dflags (hpHw * (wORD_SIZE dflags)))