That's because of the CSE (common subexpression elimination) pass. Here's an
example:
module Lib where
foo :: a -> a
foo x = x
bar :: a -> a
bar x = x
Build with -O -ddump-stg and you'll see something like:
Lib.foo :: forall a. a -> a
[GblId, Arity=1,
I don't think so, for two reasons:
- We update static thunks just fine so I don't think they're in a read-only
section.
- Forwarding pointers are needed when moving objects, and we don't move static
objects, so we don't need to make them forwarding pointers (I think you
confused forwarding
Hi devs,
I just found that the Cmm code of `GHC.Base.id` refers to `breakpoint`
in the same module, however, in the Haskell source of `GHC.Base`, the
definition of `id` and `breakpoint` are totally unrelated:
```
id :: a -> a
id x= x
breakpoint :: a ->
Just guessing here, maybe this thunk type lives in (read-only?) static
sections, and as such it will never be overwritten with forwarding
pointers?
Gabor
On 2/5/19, Ömer Sinan Ağacan wrote:
> I just came across a closure that is according to this code is not valid:
>
> >>> print
That aside, the CIs don't seem stable at all. Frequent timeouts even before
they start. I have been trying to merge 3 changes for a while now and
everytime one of them times out and I have to restart the timed out ones.
Then there are merge conflicts and I have to start over.
This is "bot
The solution I use to this branch overload is changing my fetch refspecs to
list explicitly the branches I want.
https://git-scm.com/book/en/v2/Git-Internals-The-Refspec
It's not ideal but it gets the job done. I wish git allowed you to exclude
branches instead, as I could just exclude /wip/*
What is the advantage of having ghc-wip instead of having all devs just have
their own forks?
I am all for each dev having its own fork. The ghc-wip repo would be just for
devs having an SVN workflow (i.e. several people working with commit rights on
the same branch/fork). If no-one uses
Hi,
Every time we fetch the main GHC repository, we get *a lot* of "wip/*"
branches. That's a lot of noise, making the bash completion of "git
checkout" pretty useless for instance:
> git checkout
zsh: do you wish to see all 945 possibilities (329 lines)?
Unless I'm missing something, they
I'm relying on Simon M here. I'm out of my depth!
Simon
| -Original Message-
| From: ghc-devs On Behalf Of Ömer Sinan
| Agacan
| Sent: 05 February 2019 13:38
| To: ghc-devs
| Subject: Re: Min closure payload size?
|
| I just came across a closure that is according to this code is not
I just came across a closure that is according to this code is not valid:
>>> print *get_itbl(0x7b2870)
$8 = {
layout = {
payload = {
ptrs = 0,
nptrs = 0
},
bitmap = 0,
large_bitmap_offset = 0,
__pad_large_bitmap_offset =
> On 5 Feb 2019, at 3:06 am, Ben Gamari wrote:
>
> TL;DR. Have a look at this [2] test import of GHC's Trac tickets. Tell us
> what issues you find.
>
First up, it’s utterly amazing to me that this is importable and with all links
transferred and syntax highlighting and whatnot! so
11 matches
Mail list logo
