it falls under the umbrella of "linking not working in ghci", But
it could be that didn't try the -fshared-llvm + ghci in 7.6
On Mon, May 5, 2014 at 5:01 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
On 05/05/14 21:58, Carter Schonwald wrote:
no, i was sa
hould* work,
even with 7.6.3. What goes wrong in that case?
Cheers,
Simon
merely that theres no way to get llvm-general to work on ghci in 7.6 afaik
On Mon, May 5, 2014 at 4:54 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
I don't see any reason why llvm-general with
mon
Another interesting twist is that my experience under Windows
is the opposite of the negative experience described on this
page. What I mean by this is more versions of ghci seem to
work under Windows (correctly linking to R.dll) than work
under Linux!
On Fri, May 2, 2014 at 3:45 PM, Simo
ave an Haskell app that embeds R (as in the sample code
attached to the above ticket), but when it tries to do some calculations
it seg faults (works fine with 7.8.2).
On Fri, May 2, 2014 at 3:45 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
> Can you give me a quick
On 04/05/14 11:10, Johan Tibell wrote:
I found myself needing atomic operations on basic, mutable numeric
values. I wrote a short design doc that I'd like feedback on:
https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops
I will try to implement these for 7.10.
Right now, all CmmUnsafeForeignCa
On 04/05/14 16:45, Sergei Trofimovich wrote:
On Sun, 4 May 2014 09:34:16 +0100
William Kenyon wrote:
I tested my patch on an old 32 bit laptop over night and it didn't work.
I think it's best to revert Simon's patch and let him fix it when he gets
chance.
On 3 May 2014 12:59, William Kenyon
can actually link to the library like normal
rather than link it in directly, but it isn't clear to me what would
happen even with those hooks if we rolled back to something like the old
custom linker.
-Edward
On Thu, May 1, 2014 at 5:30 PM, Simon Marlow mailto:marlo...@gmail.com>> w
here.
Thanks,
Dominick
On Thu, May 1, 2014 at 5:27 PM, Simon Marlow wrote:
On 01/05/14 14:48, Dominick Samperi wrote:
The problem with some graphics libraries used via FFI (and other libraries
that are not thread-safe), if I understand the situation correctly, is
that ghci
forks a thread when
n
turned off, and I don't know how to check that this is so.
Nevertheless, I checked
the linking issue and it is NOT fixed with this build, so
DYNAMIC_GHC_PROGRAMS=YES is required to prevent the problems
reported by me and others.
On Fri, May 2, 2014 at 9:09 AM, Simon Marlow wrote:
On 02/0
lisers :)
Cheers,
Simon
-Edward
On Fri, May 2, 2014 at 9:47 AM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
On 02/05/2014 14:28, Edward Kmett wrote:
> Perhaps. We actually tried that originally, but had issues about
> where and how to get cabal to place it. We&#x
tant cache.
>>>
>>> If they do that then we can actually link to the library like normal
>>> rather than link it in directly, but it isn't clear to me what would
>>> happen even with those hooks if we rolled back to something like the old
>>> custom
On 01/05/14 15:27, Edward Kmett wrote:
Figured I'd make one case for dynamic linking:
https://github.com/ekmett/rounded
Dynamic linking is finally enabling us to build a version of MPFR
bindings for Haskell for scientific/high precision computing with 7.8. I
would really hate to lose it after a
latter is
now scheduled for 7.10.1
On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow wrote:
On 30/04/2014 01:35, George Colpitts wrote:
It doesn't have anything about the dynamic linking changes made for 7.8.
I think it's worth mentioning the improvements we expect to get from
th
t GHCi and TH on
unregisterised platforms. In 7.8, GHCi and TH now works on some
platforms where it didn't before (albeit not very widely used platforms).
Cheers,
Simon
On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
On 30/04/2014 01:35, George
On 30/04/2014 01:35, George Colpitts wrote:
It doesn't have anything about the dynamic linking changes made for 7.8.
I think it's worth mentioning the improvements we expect to get from
that. The highlights of the release notes do mention it, so maybe that
suffices.
In particular, I'm hoping tha
o
> interact with the use of an axiom. (The obscurity of the case is one reason
> I believe I didn’t implement it this way to begin with!) So, I think I’m
> going to leave off the test case for now.
>
> Richard
>
> On Apr 29, 2014, at 1:08 PM, Simon Marlow wrote:
>
> >
We should reject LLVM 3.2 if it's known to be bad - I remember running
into this on the RPi too. LlvmCodeGen already checks the version number
and emits warnings if it's too old or too new.
On 24/04/2014 20:04, Austin Seipp wrote:
GHC 7.6 did not support LLVM 3.2 - it was only tested with up-
On 29/04/2014 08:56, Simon Peyton Jones wrote:
Richard,
Looks good, but *surely* worth a Note [unSubCo] in the file? It's manifestly
non-obvious or you'd have done this from day 1. Moreover, the *reason* Conal
needed it, and the new optimsations it enables, are also non-obvious and
deserve
On 29/04/2014 10:58, Herbert Valerio Riedel wrote:
Hello Simon,
On 2014-04-28 at 11:28:35 +0200, Simon Marlow wrote:
[...]
However, we can configure the lagged mirror such that we'd automatically
mirror github's 'master' branch into our lagged mirror (we'd still be
On 28/04/2014 09:32, Herbert Valerio Riedel wrote:
Hello Simon,
On 2014-04-28 at 10:16:39 +0200, Simon Marlow wrote:
So let me check that I'm understanding correctly. Right now the
source of truth for these repos is under git.haskell.org/ghc, and
you're proposing that we move the
I believe sync-all pull is supposed to automatically do a submodule
update. If it doesn't then that's a bug - Simon please create a ticket.
Cheers,
Simon
On 24/04/2014 09:36, Johan Tibell wrote:
I believe you need to run `git submodule update`. The orf branch was
likely set to use a different
So let me check that I'm understanding correctly. Right now the source
of truth for these repos is under git.haskell.org/ghc, and you're
proposing that we move the source of truth to github. In addition we
would still need the git.haskell.org/ghc repos, but they would become
lagging repos tra
ot sure if
theres any docs convention for the C code in ghc,
perhaps simon marlow or austin can chime in?
On Thu, Apr 24, 2014 at 12:45 PM, Howard B. Golden
mailto:howard_b_gol...@yahoo.com>> wrote:
Hi, I am working on a patch for GHC Trac ticket #9021. I wonder
whether it would be welcome
Could we have a comment with the ticket number next to the prototype
please? Otherwise some well-meaning developer will "fix" it again in
the future :-)
Cheers,
Simon
On 22/04/2014 05:40, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link
This reminds me: the instructions shouldn't be recommending that people
add GHC's own mingw tools to their PATH. The build should work without
that, and indeed we want to know if the build is using gcc from PATH
because that's a bug (and could cause real problems).
Cheers,
Simon
On 22/04/201
ustin, would you like to go ahead and do that?
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon
| Marlow
| Sent: 18 April 2014 21:32
| To: Austin Seipp
| Cc: ghc-devs@haskell.org
| Subject: Re: Heap usage of GHC increased in 7.8 vs. 7.6
|
|
On 15/04/14 05:52, Jan Stolarek wrote:
I think Simon Marlow is even more conservative, and
does his validate builds in a separate tree so he catches missing files.
I thought everyone is doing that.
It's the recommended workflow, but I must admit it doesn't always work
out, and
If there is, maybe this
won't be problematic in the end or we should revisit it when the
numbers are solid. I honestly don't know what all the expected
intra-module changes might be (I've CC'd Edward in case he'd like to
chime in about that.)
On Fri, Apr 18, 2014 at 10:3
I noticed that T1969 is failing again, and decided to do a little
investigation. The maximum residency when compiling T1969 with HEAD
compared with 7.6.3 looks like this:
7.6.3: 10,473,920
HEAD: 13,783,536
This is with +RTS -h -i0.01 to avoid sampling errors as much as
possible. The figure
Thanks Edward. Austin, can you cherry-pick this for 7.8.3 please?
Cheers,
Simon
On 13/04/2014 07:37, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/e3938f3adac0093b23694fd347774244ce121478/ghc
On 11/04/2014 11:55, Johan Tibell wrote:
On Fri, Apr 11, 2014 at 10:58 AM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
Let me second this. In particular, I think we regress on GHC
performance regularly, because the perf tests just aren't a good way
to prevent regress
On 10/04/2014 08:58, Simon Peyton Jones wrote:
Friends
The thread below concerns GHC's performance. I'm writing to ask for your help.
In developing GHC we always run 'validate', which runs a lot of regression
tests. A few of those are performance tests, but because we do so frequently,
none
On 08/04/2014 09:58, Joachim Breitner wrote:
Hi,
Am Dienstag, den 08.04.2014, 10:31 +0200 schrieb Herbert Valerio Riedel:
Just a reminder, as not everybody may be aware yet:
There's already daily GHC HEAD packages for Debian at
http://deb.haskell.org/
thanks for the reminder. I guess I n
On 08/04/2014 09:30, Joachim Breitner wrote:
we also need a culture of just doing stuff, and less asking for it.
Where is the "like" button on this line?
+1
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo
ter)$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
>From f65e9fe435a72ac3de1487a3e5a24b347c1a809b Mon Sep 17 00:00:00 2001
From: Simon Marlow
Date: Fri, 4 Apr 2014 17:02:20 +0100
Subject: [PATCH] Disable thin a
Thanks for the wiki page. One thing missing I noticed is what happens
the next time you update your tree, after having checked out master (or
a branch) in one of the submodules.
Cheers,
Simon
On 23/03/2014 21:03, Herbert Valerio Riedel wrote:
On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jon
On 24/03/2014 06:49, kyra wrote:
On 3/23/2014 20:51, Jost Berthold wrote:
Hello,
With the patch to deriveConstants, a build on an older Windows (32bit
Vista, MinGW32 installation, which used to work) now fails with error
Can't find "STD_HDR_SIZE"
Same here: Windows 64-bit, MSYS2, nm being
Ok, I buy the argument that if we're already compiling everything, we
shouldn't have to re-typecheck it all in Haddock. Of course if you're
*not* already compiling everything, then the argument doesn't apply:
Haddock does support generating documentation from source files without
precompiling t
On 10/03/2014 19:58, Sergei Trofimovich wrote:
On Mon, 10 Mar 2014 18:59:38 +0100
Johan Tibell wrote:
Added:
https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c
While at it:
SRC_HC_OPTS= ... -H64m
Just wondering: that '-H64m' is from some old times (pre 2007
On 18/03/2014 11:42, Yuras Shumovich wrote:
On Tue, 2014-03-18 at 12:37 +1100, Manuel M T Chakravarty wrote:
Library implementation can't generate native dynamic wrapper, it has to
use slow libffi.
When we first implemented the FFI, there was no libffi. Maintaining the
adjustor code for all
On 19/03/2014 03:06, Horsng Junn wrote:
Hi list!
This is my first mail to the list; please correct me if I made any mistakes.
Welcome :-)
I’ve been studying GHC source code for studying’s sake, and think I’ve found a
few problems in this function.
Below comes the function in its current for
On 18/03/2014 18:20, Mateusz Kowalczyk wrote:
Hi all,
I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox
and it reminded me of something I've been wondering for a while: why do
we not store Haddock docstrings in the interface file?
I think that if we did, we could do some gre
On 18/03/2014 18:17, Johan Tibell wrote:
Lets give some example workflows for working with submodules. Here's
what I think a raw (i.e. no sync-all) update to base will look like.
Please correct me if I'm wrong.
# Step 1:
cd ~/src/ghc/libraries/base
# edit some_file
git add some_file
git commit -
#x27;m open for suggestions. Just let me know if you think it is better
to start with return value support for foreign import.
Thanks,
Yuras
On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote:
I'm really keen to have support for returning structs in particular.
Passing structs less so, because wor
On 18/03/2014 01:37, Manuel M T Chakravarty wrote:
Yuras Shumovich :
I think the compiler is the right place. It is impossible to have
efficient implementation in a library.
For dynamic wrapper (foreign import "wrapper" stuff) ghc generates piece
of executable code at runtime. There are native
On 13/03/14 21:36, Johan Tibell wrote:
On Thu, Mar 13, 2014 at 10:24 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
It's a bad idea for large arrays (>= 3k), because when allocated via
allocate() these arrays get a blocked marked with BF_LARGE that
doesn't g
On 13/03/14 20:39, Johan Tibell wrote:
Hi all,
After some refactoring of the StgCmmPrim, it's now possible to have both
an inline and an out-of-line (in PrimOps.cmm) version of the same
primop. Very soon (#8876) we'll have both an inline and an out-of-line
version of newByteArray#. The inline ve
Add another build type for your use case. The "quick" build means
"build everything as quickly as possible", which is useful for general
development, but not benchmarking.
Cheers,
Simon
On 08/03/2014 07:45, Johan Tibell wrote:
Hi,
In my mind the "quick" build should be like the "perf" build
Johan and I talked about this on IRC. The card table is actually
irrelevant for newly allocated arrays, so in fact we can just not
initialise it at all.
Cheers,
Simon
On 10/03/2014 08:22, Johan Tibell wrote:
Hi,
For MutableArray#s, a card is supposed to be marked if the array is
pointing to
f the code generated by GHC, the performance of GHC itself,
and the size of GHC's source code. You want to measure all these
independently.
Cheers,
Simon
On Sat, Mar 8, 2014 at 5:20 AM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
On 08/03/14 07:54, Herbert Valerio Ried
On 08/03/14 07:54, Herbert Valerio Riedel wrote:
Hi Simon,
On 2014-03-08 at 08:18:20 +0100, Simon Marlow wrote:
On 06/03/14 09:50, Johan Tibell wrote:
[...]
* Are there any tweaks to mk/build.mk <http://build.mk> we can do to
make the build faster without compromising the r
On 06/03/14 09:50, Johan Tibell wrote:
Hi,
I'd like to set up a performance build bot for GHC, but before I can do
that I need a script that reliably builds GHC and runs nofib. Do we have
such a script? Here's a strawman proposal for one:
cabal install happy alex
git clone git://git.h
Yes, it's always out-of-line.
Cheers,
Simon
On 06/03/2014 20:20, Johan Tibell wrote:
Is the below code it (from rts/PrimOps.cmm)? Does it being in
PrimOps.cmm mean that it's always out-of-line?
stg_newArrayzh ( W_ n /* words */, gcptr init )
{
W_ words, size;
gcptr p, arr;
agai
that will work on the .ll
files instead, if that's feasible ...
Regards
Ralph
-----Original Message-
From: Simon Marlow [mailto:marlo...@gmail.com
<mailto:marlo...@gmail.com>]
Sent: Freitag, 28. Februar 2014 10:43
To: Benzinger, Ralph; gh
t all. (My understanding is that I
can leave the hfun_stub alone.)
Am I missing something?
Regards
Ralph
-Original Message-
From: Simon Marlow [mailto:marlo...@gmail.com]
Sent: Mittwoch, 26. Februar 2014 09:11
To: Benzinger, Ralph; ghc-devs@haskell.org
Subject: Re: Runtime error using
My guess is that this isn't working because GHC needs to post-process
the assembly generated by LLVM to support tables-next-to-code. You
could extract this phase from GHC (it's just one module, in
compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.
Cheers,
Simon
On 21/02/201
Ah, I realise it's ok so long as the original definition of foldl/foldl'
gets optimised to the right thing. If that's the case just ignore me.
Cheers,
Simon
On 17/02/2014 10:22, Simon Marlow wrote:
This worries me a bit. If foldl isn't inlined, I get a less efficient
v
This worries me a bit. If foldl isn't inlined, I get a less efficient
version, so it has to be inlined everywhere. So -O0 code gets worse,
and binary sizes for -O1+ get bigger - foldl, sum, and product are now
INLINE.
What I'm arguing is that we should have more flexibility to *not* inline
This worries me a bit. If foldl isn't inlined, I get a less efficient
version, so it has to be inlined everywhere. So -O0 code gets worse,
and binary sizes for -O1+ get bigger - foldl, sum, and product are now
INLINE.
What I'm arguing is that we should have more flexibility to *not* inline
Hi Jan - I'm not sure I agree that the case you removed was superfluous.
There are two cases we want to replace a branch to a block with the
contents of the block itself:
(1) when the block is referenced only once
(2) when the block is small enough
The case you removed was (2). Now, as i
These are just the binary builds, you can bootstrap it on your own
system to support whatever glibc version you have.
Cheers,
Simon
On 07/02/2014 18:05, Ryan Newton wrote:
Yes, this is a really annoying issue on RHEL, which includes many
supercomputers.
Sent from my phone.
On Feb 7, 2014 1:3
On 04/02/2014 01:41, Joachim Breitner wrote:
Proposal
Nobody gets to push to master directly. Instead, every push to master is
diverted¹ to a temporary branch "validating/". One of our
servers detects the appearance of such a branch and will
* check it out,
* validate it,
* if ok:
I don't think it's a good idea to export it from GHC.hs, because it
works in terms of TcRn, which isn't exposed via GHC. Someone using this
API will need to use other bits from the typechecker.
It's fine to export it from TcRnDriver (and of course add a comment to
explain why). Maybe there s
So there's no problem in casMutVar#?
There's probably no good reason not to use the gcc intrinsics. Either
they didn't exist when I wrote the inline asm, or they had been added to
gcc since I last read the docs.
Cheers,
Simon
On 01/02/2014 19:35, Ryan Newton wrote:
Ok, my bad, sorry all.
Why is the installed version of cabal-install relevant? We don't use it
in the GHC build.
On 24/01/14 14:12, Carter Schonwald wrote:
What version of cabal-install are you using?
On Friday, January 24, 2014, Jan Stolarek mailto:jan.stola...@p.lodz.pl>> wrote:
A couple of days ago I realiz
On 24/01/14 10:17, Simon Marlow wrote:
On 22/01/14 23:32, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/c5088e299a66109346057afc151c33e47b850b92/ghc
On 22/01/14 23:32, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/c5088e299a66109346057afc151c33e47b850b92/ghc
---
commit c5088e299
On 24/01/14 01:38, Manuel M T Chakravarty wrote:
Simon Marlow :
And what about this one:
main = do
forkIO $ runGhc libdir $ do ...
forkIO $ runGhc libdir $ do ...
The problem with this is the RTS linker, which is a single piece of shared
global state. We could actually fix that if
On 10/01/14 08:52, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/73c08ab10e4077e18e459a1325996bff110360c3/ghc
---
commit 73c08ab10
On 13/01/14 21:49, Herbert Valerio Riedel wrote:
On 2014-01-13 at 21:57:03 +0100, Simon Marlow wrote:
On 13/01/14 13:25, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/integer-gmp
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset
On 13/01/14 13:25, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/integer-gmp
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a2e5c5fa/integer-gmp
---
ister pressure a lot. So there is a downside too.
You seldom do things without a very good reason, so I feel I must be missing
something.
Simon
| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 10 January 2014 17:00
| To: Simon Peyton Jones; Herbert Valeri
that perhaps a conversation on
the users list and/or waiting a cycle isn't a bad idea.
Richard
On Jan 13, 2014, at 4:51 AM, Simon Marlow wrote:
On 12/01/2014 22:56, Krzysztof Gogolewski wrote:
I propose to enable -XTypeHoles in GHC by default.
GHC supports strict Haskell 2010 by defau
On 12/01/2014 22:56, Krzysztof Gogolewski wrote:
I propose to enable -XTypeHoles in GHC by default.
GHC supports strict Haskell 2010 by default, and enabling any extensions
breaks that property. That's why we don't have any extensions on by
default.
Cheers,
Simon
__
On 07/01/2014 13:55, Benno Fünfstück wrote:
Hello,
is the following safe to do?
main = do
runGhc libdir $ do ...
runGhc libdir $ do ...
Or will this cause trouble? Is there state that is shared between the
two calls?
The main restriction here is that you can only set the static flags
On 03/01/2014 18:43, Mateusz Kowalczyk wrote:
On 03/01/14 13:27, Simon Peyton-Jones wrote:
[snip]
Thank you. We need lots of help!
[snip]
While I hate to interrupt this thread, I think this is a good chance to
mention something.
I think the big issue for joining GHC development is the lack o
On 07/01/2014 18:18, Mateusz Kowalczyk wrote:
Ah, I think I understand now. If this is the case, at least the
‘alexGetChar’ could be removed, right? Is Alex 2.x compatibility
necessary for any reason whatsoever?
Yes, the backwards compatibility could be removed now that we require a
very rec
://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/StackAreas
| >
| > I agree that we have no concrete syntax for talking about areas, but
| that is something we could fix. But I'm worried that they may not mean
| what they used to mean.
| >
| > Simon
| >
| > | -Origina
story
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/StackAreas
I agree that we have no concrete syntax for talking about areas, but that is
something we could fix. But I'm worried that they may not mean what they used
to mean.
Simon
| -Original Message-
| From: Simo
the
-fregs-graph flag is not used with GHC 7.8.1. As far as I know it
compiles when using the LLVM backend too, but you don't have to use
LLVM: the NCG works fine.
Cheers,
Simon
On Thu, Jan 9, 2014 at 3:17 PM, Adam Wick mailto:aw...@galois.com>> wrote:
On Jan 8, 2014, at 2:4
There's a ticket for this:
https://ghc.haskell.org/trac/ghc/ticket/8180
On 02/01/2014 22:36, Yorick Laupa wrote:
Hi Carter,
Someone figured it out on #ghc. It seems we need to compile with
-dynamic when having TH code now
(https://ghc.haskell.org/trac/ghc/ticket/8180)
About a snippet, I worki
Simon
| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 08 January 2014 09:26
| To: Simon Peyton Jones; Herbert Valerio Riedel
| Cc: ghc-devs@haskell.org
| Subject: Re: High-level Cmm code and stack allocation
|
| On 07/01/14 22:53, Simon Peyton Jones wrote:
| >
On 07/01/14 09:59, Ben Lippmeier wrote:
On 06/01/2014, at 19:43 , Simon Peyton-Jones wrote:
| Note that removing the flag isn't a "solution" to the underlying problem
| of the intermediate code being awful. Switching to the linear allocator
| just permits compilation of core code that was wor
On 08/01/14 07:35, Carter Schonwald wrote:
well said iavor.
It perhaps hints at the register allocators needing some love? I hope to
dig deep into those myself later this year, but maybe it needs some
wibbles to clean up for 7.8 right now?
There's a bit of confusion here. Let me try to clarify
On 27/12/13 20:21, Ben Gamari wrote:
Simon Marlow writes:
This sounds right to me. Did you submit a patch?
Note that dynamic linking with LLVM is likely to produce significantly
worse code that with the NCG right now, because the LLVM back end uses
dynamic references even for symbols in the
essage-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon
| Marlow
| Sent: 07 January 2014 16:05
| To: Herbert Valerio Riedel; ghc-devs@haskell.org
| Subject: Re: High-level Cmm code and stack allocation
|
| On 04/01/2014 23:26, Herbert Valerio Riedel wrote:
| > Hello
On 07/01/2014 16:14, Herbert Valerio Riedel wrote:
Hello Simon,
On 2014-01-07 at 17:04:52 +0100, Simon Marlow wrote:
[...]
Yes, this is technically wrong but luckily works.
...but only as long as the code-generator doesn't try to push something
on the stack, like e.g. when perfo
On 04/01/2014 23:26, Herbert Valerio Riedel wrote:
Hello,
According to Note [Syntax of .cmm files],
| There are two ways to write .cmm code:
|
| (1) High-level Cmm code delegates the stack handling to GHC, and
| never explicitly mentions Sp or registers.
|
| (2) Low-level Cmm manages the
On 05/01/2014 11:46, Herbert Valerio Riedel wrote:
On 2014-01-05 at 01:15:53 +0100, Carter Schonwald wrote:
hey Herbert,
I generally start with looking at the primops.cmm file for examples
https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L572-L588
stg_decodeFloatzuIntzh ( F_ arg )
Krasimir is right, it would be hard to use Alex's built-in Unicode
support because we have to automatically generate the character classes
from the Unicode spec somehow. Probably Alex ought to include these as
built-in macros, but right now it doesn't.
Even if we did have access to the right
On 23/12/13 17:59, Ben Gamari wrote:
Ian Lynagh writes:
You shouldn't need dynamic-by-default. It should Just Work in HEAD, both
unregisterised and registerised.
Just to clarify, how does one configure GHCi to use dynamic linking now?
You set DYNAMIC_GHC_PROGRAMS=YES (which is the default
On 24/12/13 22:13, Aaron Friel wrote:
Still working on getting my own development environment configured, I am
seeing make install perform a lot of rebuilds of libraries:
> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m
-O0 -fasm-package-name base-4.7.0.0 -hide-all-pac
On 28/12/13 03:58, Ben Lippmeier wrote:
On 27/12/2013, at 12:07 PM, Kazu Yamamoto (山本和彦) wrote:
Hi,
When I tried to build the SHA library with GHC head on on 32bit Linux,
GHC head got panic. GHC 7.4.2 can build SHA on the same machine.
Configuring SHA-1.6.1...
Building SHA-1.6.1...
Failed to
On 03/01/14 08:35, Jens Petersen wrote:
On 3 January 2014 03:10, Corey O'Connor mailto:coreyocon...@gmail.com>> wrote:
My interest is just to get involved somehow in the NCG. Starting a
new backend seemed reasonable only because I couldn't break
something that didn't exist. ;-)
Wel
On 03/01/14 12:37, Simon Peyton-Jones wrote:
| I've been tinkering with ARM NCG idea for quite some time now, but
| honestly I've been always in doubts if it's the best way for GHC at all.
| I've thought that the plan was to kind of move out of NCG to LLVM based
| backends and I've though that al
existing clients on Hackage.
Cheers,
Simon
Simon
| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 02 January 2014 15:10
| To: Simon Peyton-Jones
| Cc: ghc-devs
| Subject: Re: GHC Api
|
| On 02/01/14 07:06, Simon Peyton-Jones wrote:
| >
On 02/01/14 07:06, Simon Peyton-Jones wrote:
Simon and othere
Happy new year!
When debugging Trac #8628 I wrote the following:
main
= do [libdir] <- getArgs
ok <- runGhc (Just libdir) $ do
dflags <- getSessionDynFlags -- (1)
setSessionDynFlags dflags
This sounds right to me. Did you submit a patch?
Note that dynamic linking with LLVM is likely to produce significantly
worse code that with the NCG right now, because the LLVM back end uses
dynamic references even for symbols in the same package, whereas the NCG
back-end uses direct static r
GHC's policy is:
- we do not require that the user installs any libraries or
upgrades any libraries in order to build GHC.
- we support bootstrapping with the two previous major releases
of GHC.
So that means, after the 7.8 release, the HEAD will support only 7.6 and
7.8. So that mean
I don't feel terribly strongly about this, but I'd rather not clutter up
the commit messages. As long as we keep the old testsuite.git
repository attached to Trac, we can always find the old commits, and
Google is a good hash table for SHA-1 keys.
Cheers,
Simon
On 10/12/2013 21:42, Herbert V
301 - 400 of 639 matches
Mail list logo
