Re: Running GHC Tests for Cross-Compiler?

[Erik de Castro Lopo]

Stephen Paul Weber wrote:

> Anyone know the best way to build the GHC test suite so that it can be run 
> on another device (so that I can run them for my cross-compiler)?

I can't answer the question for GHC, but for one of my projects (libsndfile)
I have make target that builds a testsuite binary tarball which includes all
the test programs (as binaries), the required test data and a single script
to run the whole test suite. Works like a charm.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Literate Markdown

[Trevor Elliott]

Hi All,

I've implemented support for literate markdown in a branch [1].  After 
doing a search on the bug tracker to see if anyone had already worked on 
this I came across bug #4836 [2], which details some unexpected 
interactions between the markdown format, unlit and CPP.  Specifically, 
unlit attempts to keep CPP in the comment sections of a literate file, 
which clashes with the way that headings are defined in markdown.


The approach that I took is that when GHC is processing markdown files, 
it passes the -r and -# flags to unlit, causing it to remove CPP in the 
comment parts of the file.  I've added support for .markdown and .md as 
source file extensions supported by GHC to be able to detect when this 
is necessary.  CPP can still be used within code blocks, giving a path 
forward for the case where the file was generated by something that 
wishes to leave #line markers.  I've documented the changes on the wiki 
at [3].


Does this approach sound reasonable?  If so, should I attach a patch to 
#4836, or create a new ticket?


Thanks!

--trevor


[1] https://github.com/elliottt/ghc/tree/literate-markdown
[2] http://hackage.haskell.org/trac/ghc/ticket/4836
[3] http://hackage.haskell.org/trac/ghc/wiki/LiterateMarkdown



smime.p7s
Description: S/MIME Cryptographic Signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Running GHC Tests for Cross-Compiler?

[Stephen Paul Weber]

Anyone know the best way to build the GHC test suite so that it can be run 
on another device (so that I can run them for my cross-compiler)?


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Integer constant folding in the presence of new primops

[Nicolas Frisby]

The relief comes when we can confirm, explain, and hopefully avoid it :)
On Jun 19, 2013 3:20 PM, "Jan Stolarek"  wrote:

> Nicolas, I kinda like that explanation, because it relieves me of any
> responsibility for this
> problem :) Still, I have reasons to suspect that this might actually be my
> fault. Generated Core
> is slightly different - the generated worker function accepts parameters
> in different order - and
> I don't know why that happens. I also don't see why this would impact
> performance. Looks like I
> will need to become familiar with the profiling tools that you mentioned.
>
> Janek
>
> Dnia środa, 19 czerwca 2013, Nicolas Frisby napisał:
> > I'm also seeing performance regressions in the shootout benchmarks that I
> > can't identify in the asm. The new asm looks better but performs worse,
> > with a ~15% slowdown.
> >
> > I fired up the performance counters in my CPU and the free Intel code for
> > inspecting them showed that my CPU utilization took about a 10% hit, even
> > while executing fewer total instructions.
> >
> >   1) Jan, perhaps we're seeing the same sort of behavior -- the shootout
> > benchmarks have extremely hot loops (hundreds of millions of iterations
> > IIRC). I used ticky profiling too, and saw no suspicious changes in any
> > counters.
> >
> >   2) Dear Low-level Gurus: How feasible is it that a ~15% slowdown in a
> > program with a very hot loop is due to incidentally inhibiting some
> caching
> > behavior (instr? data?)? Or perhaps effecting alignment? FTR my CPU is a
> > Core i7-2620M, Sandy Bridge.
> >
> > Thanks all.
> >
> > On Wed, Jun 19, 2013 at 9:27 AM, Jan Stolarek  >wrote:
> > > > If it's not sorted out, can you open a ticket, put in the relevant
> info
> > >
> > > (so
> > >
> > > > we don't need to look at the email trail), and we can tackle it when
> > > > you get here.
> > >
> > > Currently there's a temporary workaround: I'm using new folding rules
> for
> > > all primitive types,
> > > except for Integer, in which case I left the old folding rules
> unchanged.
> > > This of course should
> > > be modified to make all rules uniform, but for now it at least passes
> > > validation. I didn't fill
> > > the ticket, because the bug does not exist yet :) It only manifests
> > > itself in my patches, which
> > > have not been applied yet. I'll add all the information from this
> > > discussion to my github fork of
> > > GHC and then move it to Trac once the bug makes it to HEAD.
> > >
> > > What worries me more about my patches is the performance regression in
> > > kahan, because I see no
> > > obvious differences in the generated assembly.
> > >
> > > Janek
> > >
> > > > Simon
> > > >
> > > > -Original Message-
> > > > From: ghc-devs-boun...@haskell.org
> > > > [mailto:ghc-devs-boun...@haskell.org]
> > >
> > > On
> > >
> > > > Behalf Of Jan Stolarek Sent: 20 May 2013 12:35
> > > > To: Ian Lynagh
> > > > Cc: ghc-devs@haskell.org
> > > > Subject: Re: Integer constant folding in the presence of new primops
> > > >
> > > > > If you remove everything but the quotInteger test from
> > > > > integerConstantFolding and compile with -ddump-rule-rewrites then
> > > > > you'll see that the eqInteger rule fires before quotInteger. This
> is
> > > > > presumably comparing against 0, as the definition of quot for
> Integer
> > > > > (in GHC.Real) is
> > > > > _ `quot` 0 = divZeroError
> > > > > n `quot` d = n `quotInteger` d
> > > >
> > > > Yes, I noticed these two rules firing together - perhaps that's the
> > > > explanation why. I created a small program for testing:
> > > >
> > > > main = print quotInt
> > > > quotInt :: Integer
> > > > quotInt = 100063 `quot` 156
> > > >
> > > > I noticed that when I define eqInteger wrapper to be NOINLINE, the
> call
> > >
> > > to
> > >
> > > > quot is translated to Core as:
> > > >
> > > > Main.quotInt =
> > > >   GHC.Real.$fIntegralInteger_$cquot
> > > > (__integer 100063) (__integer 156)
> > > >
> > > > but when I change the wrapper to INLINE I get:
> > > >
> > > > Main.quotInt =
> > > >   GHC.Real.$fNumRatio_$cquot < NumRatio instead
> of
> > > > IntegralInteger (__integer 100063) (__integer 156)
> > > >
> > > > All rule firing happens later (I used -ddump-simpl-iterations
> > > > -ddump-rule-firings), except that for $fNumRatio_$cquot the quot
> rules
> > > > don't fire.
> > > >
> > > > > Do you also still have eqInteger wired in? It sounds like you might
> > > > > have given them both the same unique?
> > > >
> > > > No, they didn't have the same unique. I modified the existing rules
> to
> > >
> > > work
> > >
> > > > on the new primops and ignore their wrappers. At the moment I
> reverted
> > > > these changes so that I can make progress and leave this problem for
> > >
> > > later.
> > >
> > > > Janek
> > > >
> > > > ___
> > > > ghc-devs mailing list
> > > > ghc-devs@haskell.org
> > > > http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Integer constant folding in the presence of new primops

[Jan Stolarek]

Nicolas, I kinda like that explanation, because it relieves me of any 
responsibility for this 
problem :) Still, I have reasons to suspect that this might actually be my 
fault. Generated Core 
is slightly different - the generated worker function accepts parameters in 
different order - and 
I don't know why that happens. I also don't see why this would impact 
performance. Looks like I 
will need to become familiar with the profiling tools that you mentioned.

Janek

Dnia środa, 19 czerwca 2013, Nicolas Frisby napisał:
> I'm also seeing performance regressions in the shootout benchmarks that I
> can't identify in the asm. The new asm looks better but performs worse,
> with a ~15% slowdown.
>
> I fired up the performance counters in my CPU and the free Intel code for
> inspecting them showed that my CPU utilization took about a 10% hit, even
> while executing fewer total instructions.
>
>   1) Jan, perhaps we're seeing the same sort of behavior — the shootout
> benchmarks have extremely hot loops (hundreds of millions of iterations
> IIRC). I used ticky profiling too, and saw no suspicious changes in any
> counters.
>
>   2) Dear Low-level Gurus: How feasible is it that a ~15% slowdown in a
> program with a very hot loop is due to incidentally inhibiting some caching
> behavior (instr? data?)? Or perhaps effecting alignment? FTR my CPU is a
> Core i7-2620M, Sandy Bridge.
>
> Thanks all.
>
> On Wed, Jun 19, 2013 at 9:27 AM, Jan Stolarek wrote:
> > > If it's not sorted out, can you open a ticket, put in the relevant info
> >
> > (so
> >
> > > we don't need to look at the email trail), and we can tackle it when
> > > you get here.
> >
> > Currently there's a temporary workaround: I'm using new folding rules for
> > all primitive types,
> > except for Integer, in which case I left the old folding rules unchanged.
> > This of course should
> > be modified to make all rules uniform, but for now it at least passes
> > validation. I didn't fill
> > the ticket, because the bug does not exist yet :) It only manifests
> > itself in my patches, which
> > have not been applied yet. I'll add all the information from this
> > discussion to my github fork of
> > GHC and then move it to Trac once the bug makes it to HEAD.
> >
> > What worries me more about my patches is the performance regression in
> > kahan, because I see no
> > obvious differences in the generated assembly.
> >
> > Janek
> >
> > > Simon
> > >
> > > -Original Message-
> > > From: ghc-devs-boun...@haskell.org
> > > [mailto:ghc-devs-boun...@haskell.org]
> >
> > On
> >
> > > Behalf Of Jan Stolarek Sent: 20 May 2013 12:35
> > > To: Ian Lynagh
> > > Cc: ghc-devs@haskell.org
> > > Subject: Re: Integer constant folding in the presence of new primops
> > >
> > > > If you remove everything but the quotInteger test from
> > > > integerConstantFolding and compile with -ddump-rule-rewrites then
> > > > you'll see that the eqInteger rule fires before quotInteger. This is
> > > > presumably comparing against 0, as the definition of quot for Integer
> > > > (in GHC.Real) is
> > > > _ `quot` 0 = divZeroError
> > > > n `quot` d = n `quotInteger` d
> > >
> > > Yes, I noticed these two rules firing together - perhaps that's the
> > > explanation why. I created a small program for testing:
> > >
> > > main = print quotInt
> > > quotInt :: Integer
> > > quotInt = 100063 `quot` 156
> > >
> > > I noticed that when I define eqInteger wrapper to be NOINLINE, the call
> >
> > to
> >
> > > quot is translated to Core as:
> > >
> > > Main.quotInt =
> > >   GHC.Real.$fIntegralInteger_$cquot
> > > (__integer 100063) (__integer 156)
> > >
> > > but when I change the wrapper to INLINE I get:
> > >
> > > Main.quotInt =
> > >   GHC.Real.$fNumRatio_$cquot < NumRatio instead of
> > > IntegralInteger (__integer 100063) (__integer 156)
> > >
> > > All rule firing happens later (I used -ddump-simpl-iterations
> > > -ddump-rule-firings), except that for $fNumRatio_$cquot the quot rules
> > > don't fire.
> > >
> > > > Do you also still have eqInteger wired in? It sounds like you might
> > > > have given them both the same unique?
> > >
> > > No, they didn't have the same unique. I modified the existing rules to
> >
> > work
> >
> > > on the new primops and ignore their wrappers. At the moment I reverted
> > > these changes so that I can make progress and leave this problem for
> >
> > later.
> >
> > > Janek
> > >
> > > ___
> > > ghc-devs mailing list
> > > ghc-devs@haskell.org
> > > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Integer constant folding in the presence of new primops

[Nicolas Frisby]

Thanks Austin.

The program exhibiting these behaviors is shootout/reverse-complement. The
performance monitoring I used was Intel's pcm from

http://software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-utilization

I've been working only on my MBP, so no perfmon yet. I plan to investigate
this with different architectures/machines when this issue percolates back
up my todo list.


On Wed, Jun 19, 2013 at 11:39 AM, Austin Seipp  wrote:

> I mean, it certainly *seems* reasonable a 15% hit could come from
> pipelining changes or cache behavior or something. I don't think
> alignment would really be a huge issue; post-Nehalem I believe
> non-aligned writes/reads are extremely cheap. Non-intuitive behavior
> can totally happen too: I've seen cases of adding instructions to a
> loop which speeds things up (e.g. by taking the extra step, you may
> mitigate a dependency stall, which massively helps pipelining across
> the loop body etc.)
>
> Nicolas, can I ask what benchmark you're looking at? And what
> performance tools are you using, Intels'? If you're on Linux, the
> 'perf' tool on a modern kernel can be used to quickly get an overview
> of how many cache misses/hits your process has, how many pipeline
> stalls occur, etc. You can then use it to drill down a bit into the
> assembly that's problematic.
>
> That might not give you an exact culprit (it could be many changes and
> accumulative hits,) but it's a start.
>
> On Wed, Jun 19, 2013 at 10:43 AM, Nicolas Frisby
>  wrote:
> > I'm also seeing performance regressions in the shootout benchmarks that I
> > can't identify in the asm. The new asm looks better but performs worse,
> with
> > a ~15% slowdown.
> >
> > I fired up the performance counters in my CPU and the free Intel code for
> > inspecting them showed that my CPU utilization took about a 10% hit, even
> > while executing fewer total instructions.
> >
> >   1) Jan, perhaps we're seeing the same sort of behavior — the shootout
> > benchmarks have extremely hot loops (hundreds of millions of iterations
> > IIRC). I used ticky profiling too, and saw no suspicious changes in any
> > counters.
> >
> >   2) Dear Low-level Gurus: How feasible is it that a ~15% slowdown in a
> > program with a very hot loop is due to incidentally inhibiting some
> caching
> > behavior (instr? data?)? Or perhaps effecting alignment? FTR my CPU is a
> > Core i7-2620M, Sandy Bridge.
> >
> > Thanks all.
> >
> > On Wed, Jun 19, 2013 at 9:27 AM, Jan Stolarek 
> > wrote:
> >>
> >> > If it's not sorted out, can you open a ticket, put in the relevant
> info
> >> > (so
> >> > we don't need to look at the email trail), and we can tackle it when
> you
> >> > get here.
> >> Currently there's a temporary workaround: I'm using new folding rules
> for
> >> all primitive types,
> >> except for Integer, in which case I left the old folding rules
> unchanged.
> >> This of course should
> >> be modified to make all rules uniform, but for now it at least passes
> >> validation. I didn't fill
> >> the ticket, because the bug does not exist yet :) It only manifests
> itself
> >> in my patches, which
> >> have not been applied yet. I'll add all the information from this
> >> discussion to my github fork of
> >> GHC and then move it to Trac once the bug makes it to HEAD.
> >>
> >> What worries me more about my patches is the performance regression in
> >> kahan, because I see no
> >> obvious differences in the generated assembly.
> >>
> >> Janek
> >>
> >> >
> >> > Simon
> >> >
> >> > -Original Message-
> >> > From: ghc-devs-boun...@haskell.org [mailto:
> ghc-devs-boun...@haskell.org]
> >> > On
> >> > Behalf Of Jan Stolarek Sent: 20 May 2013 12:35
> >> > To: Ian Lynagh
> >> > Cc: ghc-devs@haskell.org
> >> > Subject: Re: Integer constant folding in the presence of new primops
> >> >
> >> > > If you remove everything but the quotInteger test from
> >> > > integerConstantFolding and compile with -ddump-rule-rewrites then
> >> > > you'll see that the eqInteger rule fires before quotInteger. This is
> >> > > presumably comparing against 0, as the definition of quot for
> Integer
> >> > > (in GHC.Real) is
> >> > > _ `quot` 0 = divZeroError
> >> > > n `quot` d = n `quotInteger` d
> >> >
> >> > Yes, I noticed these two rules firing together - perhaps that's the
> >> > explanation why. I created a small program for testing:
> >> >
> >> > main = print quotInt
> >> > quotInt :: Integer
> >> > quotInt = 100063 `quot` 156
> >> >
> >> > I noticed that when I define eqInteger wrapper to be NOINLINE, the
> call
> >> > to
> >> > quot is translated to Core as:
> >> >
> >> > Main.quotInt =
> >> >   GHC.Real.$fIntegralInteger_$cquot
> >> > (__integer 100063) (__integer 156)
> >> >
> >> > but when I change the wrapper to INLINE I get:
> >> >
> >> > Main.quotInt =
> >> >   GHC.Real.$fNumRatio_$cquot < NumRatio instead of
> >> > IntegralInteger (__integer 100063) (__integer 156)
> >> >
> >> 

Re: Integer constant folding in the presence of new primops

[Austin Seipp]

I mean, it certainly *seems* reasonable a 15% hit could come from
pipelining changes or cache behavior or something. I don't think
alignment would really be a huge issue; post-Nehalem I believe
non-aligned writes/reads are extremely cheap. Non-intuitive behavior
can totally happen too: I've seen cases of adding instructions to a
loop which speeds things up (e.g. by taking the extra step, you may
mitigate a dependency stall, which massively helps pipelining across
the loop body etc.)

Nicolas, can I ask what benchmark you're looking at? And what
performance tools are you using, Intels'? If you're on Linux, the
'perf' tool on a modern kernel can be used to quickly get an overview
of how many cache misses/hits your process has, how many pipeline
stalls occur, etc. You can then use it to drill down a bit into the
assembly that's problematic.

That might not give you an exact culprit (it could be many changes and
accumulative hits,) but it's a start.

On Wed, Jun 19, 2013 at 10:43 AM, Nicolas Frisby
 wrote:
> I'm also seeing performance regressions in the shootout benchmarks that I
> can't identify in the asm. The new asm looks better but performs worse, with
> a ~15% slowdown.
>
> I fired up the performance counters in my CPU and the free Intel code for
> inspecting them showed that my CPU utilization took about a 10% hit, even
> while executing fewer total instructions.
>
>   1) Jan, perhaps we're seeing the same sort of behavior — the shootout
> benchmarks have extremely hot loops (hundreds of millions of iterations
> IIRC). I used ticky profiling too, and saw no suspicious changes in any
> counters.
>
>   2) Dear Low-level Gurus: How feasible is it that a ~15% slowdown in a
> program with a very hot loop is due to incidentally inhibiting some caching
> behavior (instr? data?)? Or perhaps effecting alignment? FTR my CPU is a
> Core i7-2620M, Sandy Bridge.
>
> Thanks all.
>
> On Wed, Jun 19, 2013 at 9:27 AM, Jan Stolarek 
> wrote:
>>
>> > If it's not sorted out, can you open a ticket, put in the relevant info
>> > (so
>> > we don't need to look at the email trail), and we can tackle it when you
>> > get here.
>> Currently there's a temporary workaround: I'm using new folding rules for
>> all primitive types,
>> except for Integer, in which case I left the old folding rules unchanged.
>> This of course should
>> be modified to make all rules uniform, but for now it at least passes
>> validation. I didn't fill
>> the ticket, because the bug does not exist yet :) It only manifests itself
>> in my patches, which
>> have not been applied yet. I'll add all the information from this
>> discussion to my github fork of
>> GHC and then move it to Trac once the bug makes it to HEAD.
>>
>> What worries me more about my patches is the performance regression in
>> kahan, because I see no
>> obvious differences in the generated assembly.
>>
>> Janek
>>
>> >
>> > Simon
>> >
>> > -Original Message-
>> > From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
>> > On
>> > Behalf Of Jan Stolarek Sent: 20 May 2013 12:35
>> > To: Ian Lynagh
>> > Cc: ghc-devs@haskell.org
>> > Subject: Re: Integer constant folding in the presence of new primops
>> >
>> > > If you remove everything but the quotInteger test from
>> > > integerConstantFolding and compile with -ddump-rule-rewrites then
>> > > you'll see that the eqInteger rule fires before quotInteger. This is
>> > > presumably comparing against 0, as the definition of quot for Integer
>> > > (in GHC.Real) is
>> > > _ `quot` 0 = divZeroError
>> > > n `quot` d = n `quotInteger` d
>> >
>> > Yes, I noticed these two rules firing together - perhaps that's the
>> > explanation why. I created a small program for testing:
>> >
>> > main = print quotInt
>> > quotInt :: Integer
>> > quotInt = 100063 `quot` 156
>> >
>> > I noticed that when I define eqInteger wrapper to be NOINLINE, the call
>> > to
>> > quot is translated to Core as:
>> >
>> > Main.quotInt =
>> >   GHC.Real.$fIntegralInteger_$cquot
>> > (__integer 100063) (__integer 156)
>> >
>> > but when I change the wrapper to INLINE I get:
>> >
>> > Main.quotInt =
>> >   GHC.Real.$fNumRatio_$cquot < NumRatio instead of
>> > IntegralInteger (__integer 100063) (__integer 156)
>> >
>> > All rule firing happens later (I used -ddump-simpl-iterations
>> > -ddump-rule-firings), except that for $fNumRatio_$cquot the quot rules
>> > don't fire.
>> >
>> > > Do you also still have eqInteger wired in? It sounds like you might
>> > > have given them both the same unique?
>> >
>> > No, they didn't have the same unique. I modified the existing rules to
>> > work
>> > on the new primops and ignore their wrappers. At the moment I reverted
>> > these changes so that I can make progress and leave this problem for
>> > later.
>> >
>> > Janek
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Integer constant folding in the presence of new primops

[Nicolas Frisby]

I'm also seeing performance regressions in the shootout benchmarks that I
can't identify in the asm. The new asm looks better but performs worse,
with a ~15% slowdown.

I fired up the performance counters in my CPU and the free Intel code for
inspecting them showed that my CPU utilization took about a 10% hit, even
while executing fewer total instructions.

  1) Jan, perhaps we're seeing the same sort of behavior — the shootout
benchmarks have extremely hot loops (hundreds of millions of iterations
IIRC). I used ticky profiling too, and saw no suspicious changes in any
counters.

  2) Dear Low-level Gurus: How feasible is it that a ~15% slowdown in a
program with a very hot loop is due to incidentally inhibiting some caching
behavior (instr? data?)? Or perhaps effecting alignment? FTR my CPU is a
Core i7-2620M, Sandy Bridge.

Thanks all.

On Wed, Jun 19, 2013 at 9:27 AM, Jan Stolarek wrote:

> > If it's not sorted out, can you open a ticket, put in the relevant info
> (so
> > we don't need to look at the email trail), and we can tackle it when you
> > get here.
> Currently there's a temporary workaround: I'm using new folding rules for
> all primitive types,
> except for Integer, in which case I left the old folding rules unchanged.
> This of course should
> be modified to make all rules uniform, but for now it at least passes
> validation. I didn't fill
> the ticket, because the bug does not exist yet :) It only manifests itself
> in my patches, which
> have not been applied yet. I'll add all the information from this
> discussion to my github fork of
> GHC and then move it to Trac once the bug makes it to HEAD.
>
> What worries me more about my patches is the performance regression in
> kahan, because I see no
> obvious differences in the generated assembly.
>
> Janek
>
> >
> > Simon
> >
> > -Original Message-
> > From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
> On
> > Behalf Of Jan Stolarek Sent: 20 May 2013 12:35
> > To: Ian Lynagh
> > Cc: ghc-devs@haskell.org
> > Subject: Re: Integer constant folding in the presence of new primops
> >
> > > If you remove everything but the quotInteger test from
> > > integerConstantFolding and compile with -ddump-rule-rewrites then
> > > you'll see that the eqInteger rule fires before quotInteger. This is
> > > presumably comparing against 0, as the definition of quot for Integer
> > > (in GHC.Real) is
> > > _ `quot` 0 = divZeroError
> > > n `quot` d = n `quotInteger` d
> >
> > Yes, I noticed these two rules firing together - perhaps that's the
> > explanation why. I created a small program for testing:
> >
> > main = print quotInt
> > quotInt :: Integer
> > quotInt = 100063 `quot` 156
> >
> > I noticed that when I define eqInteger wrapper to be NOINLINE, the call
> to
> > quot is translated to Core as:
> >
> > Main.quotInt =
> >   GHC.Real.$fIntegralInteger_$cquot
> > (__integer 100063) (__integer 156)
> >
> > but when I change the wrapper to INLINE I get:
> >
> > Main.quotInt =
> >   GHC.Real.$fNumRatio_$cquot < NumRatio instead of
> > IntegralInteger (__integer 100063) (__integer 156)
> >
> > All rule firing happens later (I used -ddump-simpl-iterations
> > -ddump-rule-firings), except that for $fNumRatio_$cquot the quot rules
> > don't fire.
> >
> > > Do you also still have eqInteger wired in? It sounds like you might
> > > have given them both the same unique?
> >
> > No, they didn't have the same unique. I modified the existing rules to
> work
> > on the new primops and ignore their wrappers. At the moment I reverted
> > these changes so that I can make progress and leave this problem for
> later.
> >
> > Janek
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Integer constant folding in the presence of new primops

[Jan Stolarek]

> If it's not sorted out, can you open a ticket, put in the relevant info (so
> we don't need to look at the email trail), and we can tackle it when you
> get here.
Currently there's a temporary workaround: I'm using new folding rules for all 
primitive types, 
except for Integer, in which case I left the old folding rules unchanged. This 
of course should 
be modified to make all rules uniform, but for now it at least passes 
validation. I didn't fill 
the ticket, because the bug does not exist yet :) It only manifests itself in 
my patches, which 
have not been applied yet. I'll add all the information from this discussion to 
my github fork of 
GHC and then move it to Trac once the bug makes it to HEAD.

What worries me more about my patches is the performance regression in kahan, 
because I see no 
obvious differences in the generated assembly.

Janek

>
> Simon
>
> -Original Message-
> From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On
> Behalf Of Jan Stolarek Sent: 20 May 2013 12:35
> To: Ian Lynagh
> Cc: ghc-devs@haskell.org
> Subject: Re: Integer constant folding in the presence of new primops
>
> > If you remove everything but the quotInteger test from
> > integerConstantFolding and compile with -ddump-rule-rewrites then
> > you'll see that the eqInteger rule fires before quotInteger. This is
> > presumably comparing against 0, as the definition of quot for Integer
> > (in GHC.Real) is
> > _ `quot` 0 = divZeroError
> > n `quot` d = n `quotInteger` d
>
> Yes, I noticed these two rules firing together - perhaps that's the
> explanation why. I created a small program for testing:
>
> main = print quotInt
> quotInt :: Integer
> quotInt = 100063 `quot` 156
>
> I noticed that when I define eqInteger wrapper to be NOINLINE, the call to
> quot is translated to Core as:
>
> Main.quotInt =
>   GHC.Real.$fIntegralInteger_$cquot
> (__integer 100063) (__integer 156)
>
> but when I change the wrapper to INLINE I get:
>
> Main.quotInt =
>   GHC.Real.$fNumRatio_$cquot < NumRatio instead of
> IntegralInteger (__integer 100063) (__integer 156)
>
> All rule firing happens later (I used -ddump-simpl-iterations
> -ddump-rule-firings), except that for $fNumRatio_$cquot the quot rules
> don't fire.
>
> > Do you also still have eqInteger wired in? It sounds like you might
> > have given them both the same unique?
>
> No, they didn't have the same unique. I modified the existing rules to work
> on the new primops and ignore their wrappers. At the moment I reverted
> these changes so that I can make progress and leave this problem for later.
>
> Janek
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Integer constant folding in the presence of new primops

[Simon Peyton-Jones]

Jan

I'm conscious that we have not closed the loop on this thread, below.  (I think 
the attached email is also relevant.) 

If it's not sorted out, can you open a ticket, put in the relevant info (so we 
don't need to look at the email trail), and we can tackle it when you get here.

Simon

-Original Message-
From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Jan Stolarek
Sent: 20 May 2013 12:35
To: Ian Lynagh
Cc: ghc-devs@haskell.org
Subject: Re: Integer constant folding in the presence of new primops

> If you remove everything but the quotInteger test from 
> integerConstantFolding and compile with -ddump-rule-rewrites then 
> you'll see that the eqInteger rule fires before quotInteger. This is 
> presumably comparing against 0, as the definition of quot for Integer 
> (in GHC.Real) is
> _ `quot` 0 = divZeroError
> n `quot` d = n `quotInteger` d
Yes, I noticed these two rules firing together - perhaps that's the explanation 
why. I created a small program for testing:

main = print quotInt
quotInt :: Integer
quotInt = 100063 `quot` 156

I noticed that when I define eqInteger wrapper to be NOINLINE, the call to quot 
is translated to Core as:

Main.quotInt =
  GHC.Real.$fIntegralInteger_$cquot
(__integer 100063) (__integer 156)

but when I change the wrapper to INLINE I get:

Main.quotInt =
  GHC.Real.$fNumRatio_$cquot < NumRatio instead of 
IntegralInteger
(__integer 100063) (__integer 156)

All rule firing happens later (I used -ddump-simpl-iterations 
-ddump-rule-firings), except that for $fNumRatio_$cquot the quot rules don't 
fire.

> Do you also still have eqInteger wired in? It sounds like you might 
> have given them both the same unique?
No, they didn't have the same unique. I modified the existing rules to work on 
the new primops and ignore their wrappers. At the moment I reverted these 
changes so that I can make progress and leave this problem for later.

Janek

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
--- Begin Message ---
> All the same issues arise for Int# too, right?
I guess you're right :) I removed the rules for wrappers (eqInteger) and 
created rules
for "primOps" (eqIntegerPrim, which I think I'll rename to eqInteger#)

> Why?  Because eqInteger is now inlined, so the rule doesn't get a chance to
> fire?
There's something very subtle going on with inlining and I can't grasp what it 
is. At the moment I
have this in prelude/PrelNames.lhs:

eqIntegerPrimIdKey  = mkPreludeMiscIdUnique 70
eqIntegerPrimName = varQual gHC_INTEGER_TYPE (fsLit "eqIntegerPrim") 
eqIntegerPrimIdKey

and in prelude/PrelRules.lhs I have this:

builtinIntegerRules = [
  ...
   rule_binop_Prim "eqIntegerPrim"   eqIntegerPrimName   (==),
  ...]
where
  rule_binop_Prim str name op
   = BuiltinRule { ru_name = fsLit str, ru_fn = name, ru_nargs = 2,
   ru_try = match_Integer_binop_Prim op }

match_Integer_binop_Prim binop dflags _ id_unf [xl, yl]
  | Just (LitInteger x _) <- exprIsLiteral_maybe id_unf xl
  , Just (LitInteger y _) <- exprIsLiteral_maybe id_unf yl
  = Just (if x `binop` y then trueValInt dflags else falseValInt dflags)
match_Integer_binop_Prim _ _ _ _ _ = Nothing

My understanding is that this rule will fire if it finds a function 
"eqIntegerPrim" with two
Integer literals as parameters. Given my definitions in integer-gmp library:

{-# NOINLINE eqIntegerPrim #-}
eqIntegerPrim :: Integer -> Integer -> Int#
eqIntegerPrim ... -- same as before, but uses new primops

{-# INLINE eqInteger #-}
eqInteger :: Integer -> Integer -> Bool
eqInteger  a b = tagToEnum# (a `eqIntegerPrim`  b)

my understanding is that in expression:

eqIntegerE = (100012 :: Integer) == 100012

the (==) gets inlined to eqInteger:

eqIntegerE = (100012 :: Integer) `eqInteger` 100012

which in turn gets inlined to eqIntegerPrim:

eqIntegerE = tagToEnum# ((100012 :: Integer) `eqIntegerPrim` 100012)

At this point inling stops (because of NOINLINE) and my rule fires giving:

eqIntegerE = tagToEnum# 1#

which in turns allows the rule for tagToEnum# to fire, giving:

eqIntegerE = GHC.Prim.True

Now here's the tricky part. I'm testing this with test 
lib/integer/integerConstantFolding in the
testsuite and the test fails because rules for quotRemInteger, divModInteger, 
quotInteger and
remInteger don't fire, leaving the constants unfolded. I noticed that if I mark 
eqInteger with
NOINLINE, then these rules fire, but then obviously comparisons like (100012 :: 
Integer) ==
100012 don't get folded and the test fails anyway. I'm analyzing how the 
function quotInteger and
others use eqInteger, but I don't see anything that would be obvious.

Janek
--- End Message ---
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mai

RE: Windows failures

[Simon Peyton-Jones]

Curiously you are right.  Target is 
,("Target platform","i386-unknown-mingw32")

Weird since it's a 64-bit machine.

Simon

-Original Message-
From: Ian Lynagh [mailto:i...@well-typed.com] 
Sent: 18 June 2013 23:06
To: Simon Peyton-Jones
Cc: ghc-devs@haskell.org
Subject: Re: Windows failures

On Mon, Jun 17, 2013 at 08:48:15PM +, Simon Peyton-Jones wrote:
> This is 'sh validate" on 64bit Windows.  Rather a lot of failures.  Might you 
> look?

Sure.

> The perf tests seem to fail because it's comparing with the *32* bit numbers, 
> even though this is definitely a *64* bit laptop.   Whether the entire build 
> system thinks it's a 32 bit machine, or just the testsuite, I can't tell.

If you have a 64bit Windows machine, then you'll be able to run both the 32bit 
and 64bit GHC builds. If you run "ghc --info | grep Target" then you'll see 
which is being used - it'll say x86_64-unknown-mingw32 if it's 64bit, and 
i386-unknown-mingw32 if it's 32bit. I suspect that you have a 32bit GHC, so 
comparing with the 32bit numbers is right. They probably just need updating for 
recent wobbles.


Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

[Simon Marlow]

On 09/06/13 17:51, Ian Lynagh wrote:

On Sun, Jun 09, 2013 at 11:15:37AM -0500, Austin Seipp wrote:



I'm referring to Joachim Breitner's work on
splitting the base.


So what's the timeline here?


As soon as possible after 7.8 is branched.


Has there been a decision somewhere on what to do? The wiki page sets 
out the parameters of the design, but doesn't have any conclusions that 
I could see.  Splitting base has the potential to be extremely 
destabilising, I want to make sure that we're getting appreciable 
benefits in exchange.


Cheers,
Simon


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: status of template haskell + cross compiling plans for 7.8?

[Simon Marlow]

The issue that we hit sooner than this is that when we build a 
cross-compiler, we build all the libs for the target platform and not 
the host platform (see 
http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation).  So to make 
TH work, we have to change the way we build cross compilers, and make 
the build system able to build and install two sets of libs.  This is 
probably a big job.


I think it might be possible to avoid needing a multi-target GHC, as 
long as you have two identical GHCs, one that produces code for the host 
platform (host-GHC) and one for the target platform (cross-GHC).  You 
compile all the code once with host-GHC, and then again with the 
cross-GHC, the second time using the .o files produced by host-GHC to 
run the TH code.


Cheers,
Simon

On 17/06/13 14:52, Simon Peyton-Jones wrote:

I have not been following the details of this debate, but there is a
good reason why TH doesn’t work on a cross compiler. Specifically,
suppose module M imports module X, which defines a function mkD that M
calls in a splice, thus $(mkD “wobble”).

Currently, we compile X to X.o, and when compiling M we dynamically link
X.o (and all the other libraries it relies on) into GHC so that we can
call foo.  Obviously X.o has to be runnable on the machine doing the
compiling, so if X.o is for some other architecture that’s not going to
work.

There is no reason in principle why one could not compile X into
X.bytecode (along with all its dependencies), where X.bytecode is
architecture independent. Then X.bytecode could be interpreted on any
platform.  But GHC has no mechanism for doing this at all.   I’ve always
take the view that if you want X.bytecode, you may as well load X.hs and
translate it into bytecode.  A bit slower, to be sure, but maybe fast
enough.  But don’t forget those libraries.

Anyway that’s the state of play.   Have fun!

Simon

*From:*ghc-devs-boun...@haskell.org
[mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Carter Schonwald
*Sent:* 13 June 2013 22:44
*To:* ghc-devs@haskell.org
*Subject:* status of template haskell + cross compiling plans for 7.8?

Hey All,

Whats the story planned for template haskell + cross compiler support
come ghc 7.8?

I understand theres a lot of Template Haskell design underway, some of
which will help support tools like Manuel's Inline-Objective-C work.
Does this mean that factored out within this reorganization is a better
story for cross compilation?

Especially since one kill "app" for the Inline-Objective-C template
haskell work would be writing IOS applications. Though I guess that also
touches on the need to sort out supporting "FAT" ARM binaries too, right?

This intersects with a few different large subsets of tickets, so i'm
not sure if any single ticket is the right fora for this question.

thanks!

-Carter



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: PSA: GHC can now be built with Clang

[Austin Seipp]

Yes, we're using -undef -traditional. We're also suppressing some
extra warnings from Clang concerning other things; you can see my
recent commits.

I have filed a related LLVM bug, regarding the preprocessor behavior
that affects primitive: http://llvm.org/bugs/show_bug.cgi?id=16371

I have worked around this bug manually inside primitive, and with it,
I have been able to do a complete stage2 build with all libraries up
to DPH, so we're extremely close! I'll keep hacking away in the mean
time.

On Wed, Jun 19, 2013 at 2:38 AM, Gabor Greif  wrote:
> Please make sure that all bugs are reported back to the Clang devs.
> They are usually very fast in fixing them.
>
> I assume that the ${CPP} is in traditional mode?
>
> Cheers,
>
> Gabor
>
>
> On 6/19/13, Carter Schonwald  wrote:
>> Awesome!
>>
>> I'm actually hitting another CPP bug right now in building ghc head with
>> clang head, also I'll reach out to an apple dude i know to find out if we
>> can get any help from them on this or the related TLS issue.
>>
>>
>> On Wed, Jun 19, 2013 at 12:44 AM, Austin Seipp  wrote:
>>
>>> Hi all,
>>>
>>> As of commit 5dc74f it should now be possible to build a working
>>> stage1 and stage2 compiler with (an extremely recent) Clang. With some
>>> caveats.
>>>
>>> You can just do:
>>>
>>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
>>> $ make
>>>
>>> I have done this work on Linux. I don't expect much difficulty on Mac
>>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
>>> is considered experimental.
>>>
>>> The current caveats are:
>>>
>>>  * The testsuite will probably fail everywhere, because of some
>>> warnings that happen during the linking phase when you invoke the
>>> built compiler. So the testsuite runner will probably be unhappy.
>>> Clang is very noisy about unused options, unlike GCC. That needs to be
>>> fixed somewhere in DriverPipeline I'd guess, but with some
>>> refactoring.
>>>  * Some of the stage2 libraries don't build due to a Clang bug. These
>>> are vector/primitive/dph so far.
>>>  * There is no buildbot or anything to cover it.
>>>
>>> You will need a very recent Clang. Due to this bug (preventing
>>> primitive etc from building,) you'll preferably want to use an SVN
>>> checkout from about 6 hours ago at latest:
>>>
>>> http://llvm.org/bugs/show_bug.cgi?id=16363
>>>
>>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
>>> module due to some CPP weirdness. But even with a proper bugfix and no
>>> segfault, it still fails to correctly parse this same module with the
>>> same CPP declarations. I'm fairly certain this is another bug in
>>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
>>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
>>> it will *probably* work if we just get rid of the CPP tomfoolery in
>>> primitive. I'll be testing it in the next few days to see if we can
>>> get 3.3 supported. (I'm sort of kicking myself in the head for not
>>> doing this a week or two ago...)
>>>
>>> Anyway, there are some rough edges but it should be in shape for 7.8 I
>>> hope. It should be especially welcome for Mac users. (I'm also hoping
>>> modern Macs could even go all-clang-all-the-time if my fix for #7602
>>> can go in soon...)
>>>
>>> PS. If you use ASSERT, I just fixed a lot of instances of using that
>>> macro, involving whitespace between the name and arguments (commit
>>> d8ee2b.) Clang does not forgive you for this. Should I note this
>>> anywhere for the future in the wiki or something?
>>>
>>> --
>>> Regards,
>>> Austin - PGP: 4096R/0x91384671
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>



-- 
Regards,
Austin - PGP: 4096R/0x91384671

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: build error on Mac

[山本和彦]

Hi Austin,

> Once my Mac is back online I'll push my changes again, hopefully
> without err. :)

Fixed. Thank you!

--Kazu

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: PSA: GHC can now be built with Clang

[Gabor Greif]

Please make sure that all bugs are reported back to the Clang devs.
They are usually very fast in fixing them.

I assume that the ${CPP} is in traditional mode?

Cheers,

Gabor


On 6/19/13, Carter Schonwald  wrote:
> Awesome!
>
> I'm actually hitting another CPP bug right now in building ghc head with
> clang head, also I'll reach out to an apple dude i know to find out if we
> can get any help from them on this or the related TLS issue.
>
>
> On Wed, Jun 19, 2013 at 12:44 AM, Austin Seipp  wrote:
>
>> Hi all,
>>
>> As of commit 5dc74f it should now be possible to build a working
>> stage1 and stage2 compiler with (an extremely recent) Clang. With some
>> caveats.
>>
>> You can just do:
>>
>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
>> $ make
>>
>> I have done this work on Linux. I don't expect much difficulty on Mac
>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
>> is considered experimental.
>>
>> The current caveats are:
>>
>>  * The testsuite will probably fail everywhere, because of some
>> warnings that happen during the linking phase when you invoke the
>> built compiler. So the testsuite runner will probably be unhappy.
>> Clang is very noisy about unused options, unlike GCC. That needs to be
>> fixed somewhere in DriverPipeline I'd guess, but with some
>> refactoring.
>>  * Some of the stage2 libraries don't build due to a Clang bug. These
>> are vector/primitive/dph so far.
>>  * There is no buildbot or anything to cover it.
>>
>> You will need a very recent Clang. Due to this bug (preventing
>> primitive etc from building,) you'll preferably want to use an SVN
>> checkout from about 6 hours ago at latest:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=16363
>>
>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
>> module due to some CPP weirdness. But even with a proper bugfix and no
>> segfault, it still fails to correctly parse this same module with the
>> same CPP declarations. I'm fairly certain this is another bug in
>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
>> it will *probably* work if we just get rid of the CPP tomfoolery in
>> primitive. I'll be testing it in the next few days to see if we can
>> get 3.3 supported. (I'm sort of kicking myself in the head for not
>> doing this a week or two ago...)
>>
>> Anyway, there are some rough edges but it should be in shape for 7.8 I
>> hope. It should be especially welcome for Mac users. (I'm also hoping
>> modern Macs could even go all-clang-all-the-time if my fix for #7602
>> can go in soon...)
>>
>> PS. If you use ASSERT, I just fixed a lot of instances of using that
>> macro, involving whitespace between the name and arguments (commit
>> d8ee2b.) Clang does not forgive you for this. Should I note this
>> anywhere for the future in the wiki or something?
>>
>> --
>> Regards,
>> Austin - PGP: 4096R/0x91384671
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: build error on Mac

[Carter Schonwald]

yup, thanks, figured it out :)



On Wed, Jun 19, 2013 at 3:10 AM, Austin Seipp  wrote:

> This is Clang related and not strictly related to Kazu's error. I'm
> confused why you would encounter this. This problem should be fixed by
> commit 7b0695 which I pushed to the tree today.
>
> On Wed, Jun 19, 2013 at 2:07 AM, Carter Schonwald
>  wrote:
> > any push you just made didn't fix this error
> >
> > compiler/HsVersions.h:29:5:
> >  error: '#' is not followed by a macro parameter
> > {-# NOINLINE name #-}; \
> > ^
> >
> > compiler/HsVersions.h:34:5:
> >  error: '#' is not followed by a macro parameter
> > {-# NOINLINE name #-};  \
> > ^
> > 2 errors generated.
> > make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1
> >
> >
> > I'm getting it even when I used gcc and llvm 3.2 and quick-llvm...
> > also when i do a quick build  plus gcc
> >
> > anyone else getting this problem
> >
> >
> >
> > On Wed, Jun 19, 2013 at 2:29 AM, Austin Seipp  wrote:
> >>
> >> Hi Kazu, this should now be fixed.
> >>
> >> Once my Mac is back online I'll push my changes again, hopefully without
> >> err. :)
> >>
> >> On Wed, Jun 19, 2013 at 1:21 AM, Kazu Yamamoto  wrote:
> >> >> I will push a fix very shortly.
> >> >
> >> > OK. I will try again when you push it.
> >> >
> >> > --Kazu
> >> >
> >> > ___
> >> > ghc-devs mailing list
> >> > ghc-devs@haskell.org
> >> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Austin - PGP: 4096R/0x91384671
> >>
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> >
>
>
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: build error on Mac

[Austin Seipp]

This is Clang related and not strictly related to Kazu's error. I'm
confused why you would encounter this. This problem should be fixed by
commit 7b0695 which I pushed to the tree today.

On Wed, Jun 19, 2013 at 2:07 AM, Carter Schonwald
 wrote:
> any push you just made didn't fix this error
>
> compiler/HsVersions.h:29:5:
>  error: '#' is not followed by a macro parameter
> {-# NOINLINE name #-}; \
> ^
>
> compiler/HsVersions.h:34:5:
>  error: '#' is not followed by a macro parameter
> {-# NOINLINE name #-};  \
> ^
> 2 errors generated.
> make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1
>
>
> I'm getting it even when I used gcc and llvm 3.2 and quick-llvm...
> also when i do a quick build  plus gcc
>
> anyone else getting this problem
>
>
>
> On Wed, Jun 19, 2013 at 2:29 AM, Austin Seipp  wrote:
>>
>> Hi Kazu, this should now be fixed.
>>
>> Once my Mac is back online I'll push my changes again, hopefully without
>> err. :)
>>
>> On Wed, Jun 19, 2013 at 1:21 AM, Kazu Yamamoto  wrote:
>> >> I will push a fix very shortly.
>> >
>> > OK. I will try again when you push it.
>> >
>> > --Kazu
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>>
>> --
>> Regards,
>> Austin - PGP: 4096R/0x91384671
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>



-- 
Regards,
Austin - PGP: 4096R/0x91384671

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: build error on Mac

[Carter Schonwald]

any push you just made didn't fix this error

compiler/HsVersions.h:29:5:
 error: '#' is not followed by a macro parameter
{-# NOINLINE name #-}; \
^

compiler/HsVersions.h:34:5:
 error: '#' is not followed by a macro parameter
{-# NOINLINE name #-};  \
^
2 errors generated.
make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1


I'm getting it even when I used gcc and llvm 3.2 and quick-llvm...
also when i do a quick build  plus gcc

anyone else getting this problem



On Wed, Jun 19, 2013 at 2:29 AM, Austin Seipp  wrote:

> Hi Kazu, this should now be fixed.
>
> Once my Mac is back online I'll push my changes again, hopefully without
> err. :)
>
> On Wed, Jun 19, 2013 at 1:21 AM, Kazu Yamamoto  wrote:
> >> I will push a fix very shortly.
> >
> > OK. I will try again when you push it.
> >
> > --Kazu
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs