AHA! The clang libs weren't/aren't being built split-obj!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
The clang executable size mystery deepens:
The sizes are indeed wy big:
7.4M test-files-clang/test*
4.5M test-files-clang/test-stripped*
1.4M test-files-gcc/test*
1.1M test-files-gcc/test-stripped*
Looking at the load info from the stripped versions, it is all in the main
text segment:
It won't work in our case because the gcc 4.9 build we have references it's
own c rts lib, which is 4.9 specific, and is notably different than what is
on a stock Mac
Imagine if we were to ship a libHSrts.a, compiled against the gcc 4.9 libc
(and it's includes). Now a user without gcc 4.9 on thier
So, it appears that the one ending with 21 is the likely correct result; as
opposed to 22.
Is this an issue with some underlying library (glibc etc.); or an issue
with GHC itself?
On Sat, Jul 12, 2014 at 8:03 PM, GHC wrote:
> #9304: Floating point woes; Different behavior on Mac vs Linux
> ---
On Fri, Jul 11, 2014 at 6:40 AM, Austin Seipp wrote:
> The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.3.
>
haddock 2.14.3 that ships with it seems to be quite broken. Perhaps it's a
bad interaction with cabal, it's hard to say from the outside, but here are
some details
why wouldn't it work?
heres my 4.9 gcc build, I believe it should work on any >= 10.7 system that
has xcode cli tools installed,
please let me know if it fails!
http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.3-x86_64-apple-darwin.tar.bz2
On Sat, Jul 12, 2014 at 9:04 P
I will try to measure on 10.7 later today.
Preliminary numbers for gcc 4.9 are even better than clang - it saves 12%
over gcc 4.2 builds. However, the gcc runtime isn't the same as the Apple
standard... and we are so far at a loss how to package a ghc based on 4.9
that would work for Mac users wit
Maybe it depends on the version of OS X being used? Maybe TLS works
differently pre 10.8 or 10.9?
On Saturday, July 12, 2014, Johan Tibell wrote:
> I thought clang was slower than gcc because clang doesn't support thread
> local variables (in some form we need) and therefore GC performance
> su
Thank you Luke. The binaries are uploaded and on the webpage.
On Fri, Jul 11, 2014 at 9:54 PM, Luke Iannini wrote:
> Hi Austin/all,
> Here are the iOS builds!
> http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.bz2
> http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.bz2.sha1
> http://tree.is/files/
This is great!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
I thought clang was slower than gcc because clang doesn't support thread
local variables (in some form we need) and therefore GC performance
suffered a lot on clang.
On Sat, Jul 12, 2014 at 9:27 PM, Mark Lentczner
wrote:
> In building the OS X bindist for 7.8.3, I had to choose which of several
In building the OS X bindist for 7.8.3, I had to choose which of several
ways to build it. In particular, I could build it with a newere Xcode,
which uses clang, or an older Xcode which uses gcc. I decided to nofib
benchmark the variations and see before I released. Here is what I found...
I compa
On 7/12/14, Joachim Breitner wrote:
> Hi,
>
> I just added a .travis.yml file to GHC master. This means that every
> push will be validated automatic and for free by travis; you can check
> the build status at https://travis-ci.org/ghc/ghc/builds
>
> It is not a full validation. In particular,
>
Hi,
I just added a .travis.yml file to GHC master. This means that every
push will be validated automatic and for free by travis; you can check
the build status at https://travis-ci.org/ghc/ghc/builds
It is not a full validation. In particular,
* it skips DPH
* it does not build dynamic librari
Yes, this will cause problems in some modes, namely -debug and -prof
that need to be able to scan the heap linearly. Usually we invoke the
OVERWRITING_CLOSURE() macro which overwrites the original closure with
zero words, but this won't work in your case because you want to keep
the original c
Hi *,
Quick notice: I spent some time hacking to get Phabricator to build
code reviews you publish against the GHC repository. It luckily was
not that hard to do so - hooray!
Go here for an example:
https://phabricator.haskell.org/D64
Look at the top set of information, and find 'Build Status'.
Hello Simon (et al.)
While experimenting with refactoring/improving integer-gmp, I'd like to
represent a GMP number just by a ByteArrays# (and thus save a redundant
limb-count field). However, for that I'd need an efficient way to resize
a MutableByteArray# for the result value in case its initial
17 matches
Mail list logo
