Hi all,
I tried this — building GHC HEAD configured to use the native code gen, and
then building the cross compiler using that, and got the same errors as
everything else thus far:
https://gist.github.com/lukexi/02366ed57171400b961a
10.9 Mavericks is likely coming out in less than a month, along
On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg wrote:
> According to the Haskell 2010 report
> (http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011),
> a datatype with no constructors cannot derive any instances.
You're quite right! I should have looked over the t
According to the Haskell 2010 report
(http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011),
a datatype with no constructors cannot derive any instances.
But, instead of creating a new extension for this feature, what about just
co-opting EmptyDataDecls? More concretely
No, I'm unfamiliar with both sets of code. IIRC, we also have a
buildbot infrastructure, for which anyone can volunteer a machine to do
a build on, but we don't tend to do a very good job of taking care of
these machines. Perhaps if we centralized things a bit and made it
easier for GHC devs to t
It looks to me that the problem is caused by an outdated libraries/base repo.
Have you run ./sync-all pull? In particular, your libraries/base repo needs to
be at ab9e8e3… or later.
Let me know if this was indeed the problem!
Thanks,
Richard
On Aug 11, 2013, at 2:21 AM, Dr. ERDI Gergo wrote:
Technically, EmptyDataDecls is part of Haskell 2010, so it is standard
these days (and H2010 is our default in GHC.)
As far as I know, the 2010 standard doesn't address this point about
deriving for empty data decls, but I agree with your reasoning here.
It's more consistent to have it apply to al
Maybe it's best if Show, Ord, etc., echo the new behavior for Eq, if
EmmptyDataDecls is specified. The reason for the check in cond_stdOK is to make
sure that we're conforming to the Haskell standard. But, if the user has
specified EmptyDataDecls, then we're not bound to that requirement anymore
Hi,
I've posted the details here:
http://www.haskell.org/pipermail/ghc-devs/2013-August/001907.html
It fails in phase 2 for me.
Bye,
Gergo
On Aug 12, 2013 9:47 AM, "Richard Eisenberg" wrote:
> I'm not aware of any outstanding bugs in the role checker that would cause
> a core lint failure (or
I'm not aware of any outstanding bugs in the role checker that would cause a
core lint failure (or any other problems), so if you're seeing one, that sounds
like new news. How did you run into this?
Thanks,
Richard
On Aug 9, 2013, at 3:33 AM, Dr. ERDI Gergo wrote:
> On Fri, 9 Aug 2013, Luke Ia
What if you build a copy of head with the native code gen. Then build the
cross compiler using head on head?
On Sunday, August 11, 2013, Luke Iannini wrote:
> And the truly final word for the moment : ) —
> I built a tool to partially automate the indentation workaround for LLVM
> 3.0 and it yiel
And the truly final word for the moment : ) —
I built a tool to partially automate the indentation workaround for LLVM
3.0 and it yields the same "co-processor offset out of range"/"unsupported
relocation on symbol LCPI65_0" errors LLVM 3.3/3.4 did when it finally gets
to integer-simple/GHC/Integer
OK! So just to summarize:
Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the bootstrap)
on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior wherein
layout-based code along with mixed-tabs-and-spaces code fails to parse
correctly, with issues in hundreds of files in the GHC HEAD
12 matches
Mail list logo
