gt; | -Original Message-
>> | From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org]
>> On
>> | Behalf Of Austin Seipp
>> | Sent: 17 December 2012 17:35
>> | To: cvs-ghc
>> | Subject: PATCH: Rename cmmz flags for consistency
>> |
>
Minor nitpick:
On Mon, Dec 17, 2012 at 5:26 PM, Austin Seipp wrote:
> I don't know how relevant dynamic-by-default here is, but I see how
> it's going to get you around the first issue, which is the major one.
s/but I see/but I can't see/
We discussed this on IRC the other day but since I have a copy of GHC
open I dug through it to refresh my memory. I don't think it would be
currently possible with the way things currently are. Someone is free
to correct me.
To explain the reasoning, I'll parrot that paragraph and specialize it
to
Hi,
The attached patch renames the various '*-cmmz-*' flags to '*-cmm-*'
now that the new backend is live. It also fixes some inconsistencies;
namely, there were flags like -ddump-cmmz-rewrite, vs -ddump-cps-cmm,
etc. Also, since the new backend went live, '-ddump-cmm' was terribly
broken: it was
Hi,
Attached are two patches that update the users guide with respect to
unboxed tuples, and another one that fixes DriverPipeline so that it
does not pass -Wimplicit to the C++ compiler (this gives an ugly
warning in gcc 4.6+ because it's C/ObjC only, and I have a cabal
package that builds a lot
Saying 'make V=1' instead of 'make' should do the trick.
On Wed, Jul 18, 2012 at 10:37 AM, Dimitrios Vytiniotis
wrote:
> Hi, I had not built HEAD for a while so I observed that something changed in
> the build system.
>
> When I run make or validate I now get less verbose information, e.g:
>
>
Yep, fixed. Thanks Simon!
On Fri, Apr 20, 2012 at 12:22 PM, Simon Peyton-Jones
wrote:
> I know.. I'm about to push. sorry
>
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
> | users-boun...@haskell.org] On Be
Yes, I believe this interpretation is correct, per the link Karel
posted. Because the optimizer cannot look inside an asm statement, if
something is not marked input, output, or clobber, GCC may freely use
it in the process of allocating registers to the input/output
operands, given the constraints
Fix confirmed. Thanks Ian!
On Sun, Nov 27, 2011 at 8:15 AM, Ian Lynagh wrote:
> On Sun, Nov 27, 2011 at 02:09:45AM -0600, austin seipp wrote:
>> I'll note this patch causes ./configure to fail when using the gold
>> linker on Linux systems
>
> Thanks for the r
I'll note this patch causes ./configure to fail when using the gold
linker on Linux systems, as it doesn't understand these options, so if
it's your default (i.e. you installed `binutils-gold`) you'll need to
update your alternatives or merely remove the package.
The trac ticket (#5204) notes that
Are you compiling with -XMagicHash? It doesn't really change program
semantics - it merely allows you to add '#' to the end of an
identifier, which GHC typically uses to indicate unboxed/primitive
types (technically it also introduces a few extra literal forms too.)
Note the wording of the users gu
11 10:31, austin seipp wrote:
>>
>> Okay, so I took a stab at the build system and getting the analysis
>> plugin at least building, and the results are in this commit:
>>
>>
>> https://github.com/thoughtpolice/ghc/commit/c30b32fc98a78e322d872b82bed670ee4627ecf0
>&
I found a relevant discussion topic here:
http://groups.google.com/group/llvm-dev/browse_thread/thread/8baba4531a9feb07/139c9eba3525ebe?pli=1
The gist of it is that as of 10.6, the OS X linker started producing
'compact unwind information' in linked images, that ld creates from
the DWARF unwind i
Okay, so I took a stab at the build system and getting the analysis
plugin at least building, and the results are in this commit:
https://github.com/thoughtpolice/ghc/commit/c30b32fc98a78e322d872b82bed670ee4627ecf0
I'm working on pushing a version that moves most of the logic in this
commit direc
I tried this with a recent checkout, by running:
$ make TESTS="plugins02"
in ./testsuite/tests, and it failed with a similar error, but with
another checkout of the testsuite repository, I can't seem to
reproduce this failure at all anymore after several attempts.
This is an Ubuntu Linux machine
I tested the greedy and PBQP register allocators with a recent GHC
HEAD (today) build and LLVM v3.0svn (revision 139459.) With nofib they
actually both give worse results than linear scan it seems.
Results of GHC's regular NCG vs LLVM:
NoFib Results
-
(CC'ing Dan so he can chime in, for those who don't IRC.)
Dan Knapp (dankna on freenode) is running OS X Lion on his machine
(and corresponding new xcode tools I believe,) and apparently Apple
have gone the whole way in the next release and by default making
'gcc' a symbolic link to 'llvm-gcc.' It
Simon,
Just a note. I updated the 'NewPlugins' page with a link to my github
repository and updated the ticket (I think):
http://hackage.haskell.org/trac/ghc/wiki/NewPlugins
I merged master last on May 2nd, but I believe I have a new merge in
my local repo at home and at least 1 test in the test
Seconded! I think this will also significantly help the plugins work
I'm trying to get cleaned up - annotations that were part of packages
which exposed a GHC plugin (and thus, dependened on the GHC library)
would cause GHC to get linked into the resulting executable, even
though the annotation was
Blast, I always just hit 'reply' instead of 'reply to all'. For the
curious, my original email to Edward describing his situation is as
follows, uneditied.
=
Hi Edward,
I did some investigation into the STG and NCG machinery to try a
2010_11_19.dpatch
and updated it on the trac page. I'll continue updating the patch on
my server to reflect the most recent changes as they come in.
Original message below.
Regards,
Austin
On Fri, Nov 19, 2010 at 8:06 PM, austin seipp wrote:
> Hello everybody,
>
> (CC'ing m
Mon Jul 6 16:39:37 CDT 2009 Austin Seipp
* fix mk/build.mk for HaveLibGmp/HaveFrameworkGMP
Previously if you were to set HaveFrameworkGMP/HaveLibGmp in
mk/build.mk (e.g. on mac os) the settings would be ignored, as
gmp/config.mk is included late in GHC's ghc.mk, meaning aut
Excerpts from Ian Lynagh's message of Wed Apr 29 15:24:08 -0500 2009:
>
> Hi all,
>
> I've added Haskeline support into the HEAD now, so after pulling you
> will need to do:
> ./darcs-all get --complete
> to get the new libraries.
>
> You may also need to do
> sh boot
> ./configure
>
Excerpts from Simon Peyton-Jones's message of Mon Sep 08 07:22:15 -0500 2008:
> Dear BDS hackers
>
> We'd like GHC to be buildable on BSD, but at the moment it isn't. We support
> GHC on Linux, Windows, Mac, but we really need help with BSD.
>
> Alas, we didn't get much response to Simon's messa
(I apologize for the trite subject line, but I feel it conveys the
point.)
For the past two weeks or so I have been unable to build the latest
GHC HEAD from the main darcs development branch (I believe the last
one I managed to build here on OS X 10.5 was 20080720.) From the looks
of it this is du
25 matches
Mail list logo