Re: any successfull ghc registerised builds on arm?

[Karel Gardas]

On 01/19/13 11:37 PM, Karel Gardas wrote:


Hi,

I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float
ABI distro. I used distro provided LLVM 3.0 and configured GHC with:

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0



Also the testsuite results run by:

make THREADS=2 WAY="normal threaded1 threaded2"

are here:

OVERALL SUMMARY for test run started at Sun Jan 20 10:33:22 CET 2013
3400 total tests, which gave rise to
8325 test cases, of which
   3 caused framework failures
3835 were skipped

4209 expected passes
 151 had missing libraries
  40 expected failures
   4 unexpected passes
  83 unexpected failures

Unexpected passes:
   profiling/should_compile  2410 (normal)
   profiling/should_compile  prof001 (normal)
   profiling/should_compile  prof002 (normal)
   thTH_spliceE5_prof (normal)

Unexpected failures:
   ../../libraries/base/tests/IO   4855 [exit code non-0] 
(threaded1)
   ../../libraries/base/tests/IO   openFile008 [bad exit code] 
(normal,threaded1,threaded2)
   ../../libraries/hpc/tests/function  subdir/tough2 [bad stderr] 
(normal)
   ../../libraries/hpc/tests/function  tough [bad stderr] 
(threaded1,threaded2)
   ../../libraries/hpc/tests/ghc_ghci  hpc_ghc_ghci [bad exit code] 
(normal)
   ../../libraries/template-haskell/tests  dataToExpQUnit [exit code 
non-0] (normal)

   annotations/should_compile  ann01 [exit code non-0] (normal)
   annotations/should_run  annrun01 [exit code non-0] 
(normal,threaded1,threaded2)
   codeGen/should_compile  jmp_tbl [exit code non-0] 
(normal)
   codeGen/should_compile  massive_array [exit code 
non-0] (normal)

   driver  T706 [bad exit code] (normal)
   ghc-api/T4891   T4891 [bad exit code] (normal)
   ghc-api/apirecomp001apirecomp001 [bad exit code] 
(normal)

   ghc-e/should_run2228 [bad exit code] (normal)
   ghc-e/should_run3890 [bad stderr] (normal)
   ghc-e/should_runghc-e001 [bad exit code] 
(normal)
   ghc-e/should_runghc-e002 [bad exit code] 
(normal)
   ghc-e/should_runghc-e003 [bad exit code] 
(normal)

   ghc-e/should_runghc-e004 [bad stderr] (normal)
   ghc-e/should_runghc-e005 [bad stderr] (normal)
   ghci/linkingghcilink001 [bad exit code] 
(normal)
   ghci/linkingghcilink002 [bad exit code] 
(normal)
   ghci/linkingghcilink003 [bad exit code] 
(normal)
   ghci/linkingghcilink004 [bad exit code] 
(normal)
   ghci/linkingghcilink005 [bad exit code] 
(normal)
   ghci/linkingghcilink006 [bad exit code] 
(normal)
   ghci/prog004ghciprog004 [bad exit code] 
(normal)

   ghci/scriptsghci024 [bad exit code] (normal)
   ghci/scriptsghci037 [bad exit code] (normal)
   ghci/should_run 3171 [bad stdout] (normal)
   perf/compiler   T1969 [stat not good enough] 
(normal)
   perf/compiler   T3064 [stat not good enough] 
(normal)
   perf/compiler   T4801 [stat not good enough] 
(normal)
   perf/compiler   T5321FD [stat not good 
enough] (normal)
   perf/compiler   T5321Fun [stat not good 
enough] (normal)
   perf/compiler   T5631 [stat not good enough] 
(normal)
   perf/compiler   T5642 [stat not good enough] 
(normal)
   perf/compiler   T5837 [stat not good enough] 
(normal)
   perf/compiler   T783 [stat not good enough] 
(normal)
   perf/compiler   parsing001 [stat not good 
enough] (normal)
   plugins plugins01 [bad exit code] 
(normal)
   plugins plugins05 [exit code non-0] 
(normal,threaded1,threaded2)
   plugins plugins06 [exit code non-0] 
(normal,threaded1)
   programs/barton-mangler-bug barton-mangler-bug [exit 
code non-0] (threaded2)
   programs/joao-circular  joao-circular [exit code 
non-0] (normal,threaded1,threaded2)
   quasiquotation/T4491T4491 [exit code non-0] 
(normal,threaded1,threaded2)

   quasiquotation/qq007qq007 [exit code non-0] (normal)
   rts 3424 [exit code non-0] 
(normal,threaded1)
   rts T2615 [bad exit code] 
(normal,threaded1,threaded2)
   rts   

Re: Error building ghc on raspberry pi.

[roconnor]

On Wed, 16 Jan 2013, Karel Gardas wrote:

You should not IMHO. My patch should solve all your issues. :-) The only 
issue you may get is that your distro ghc will compile for soft-float ABI and 
your compiled GHC will compile to hard-float and object files will get mixed 
somewhere. But I trust your distro ghc builders that this is not the case so 
both GHCs should compile using hard-float. So issue solved, at least should 
be. Now I'm just waiting if you verify this or not so I'm either able to 
submit the patch for inclusion or hack it more...


I switched to using llvm-3.0 from rasbian, and made a lot of progress. (In 
retrospect I built llvm-3.1 using nix, and it was in a completely 
different toolchain than the rest of the build.  I should have known that 
it wouldn't work).


I was able to complete the build of ghc-7.6.1 using Karel's patch and

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0

I was able to make binary-dist after doing

mkdir compiler/stage2/doc

However after unpacking the binary distribution and doing a make install I 
get:


Installing library in /tmp/bindist/lib/ghc-7.6.1/ghc-prim-0.3.0.0
ghc-cabal: Failed to read "target arch" value "ArchARM {armISA = ARMv6,
armISAExt = [VFPv2], armABI = }"
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2

And in particular the installed ghc gives the error:

$ bin/ghc
Failed to read "target arch" value "ArchARM {armISA = ARMv6, armISAExt = 
[VFPv2], armABI = }"


Sounds to me like Karel's patch is almost, but not quite there.

Karel, maybe you should try deploying a binary-dist on your panda board?

--
Russell O'Connor  
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[Karel Gardas]

On 01/20/13 07:17 PM, rocon...@theorem.ca wrote:

On Wed, 16 Jan 2013, Karel Gardas wrote:


You should not IMHO. My patch should solve all your issues. :-) The
only issue you may get is that your distro ghc will compile for
soft-float ABI and your compiled GHC will compile to hard-float and
object files will get mixed somewhere. But I trust your distro ghc
builders that this is not the case so both GHCs should compile using
hard-float. So issue solved, at least should be. Now I'm just waiting
if you verify this or not so I'm either able to submit the patch for
inclusion or hack it more...


I switched to using llvm-3.0 from rasbian, and made a lot of progress.
(In retrospect I built llvm-3.1 using nix, and it was in a completely
different toolchain than the rest of the build. I should have known that
it wouldn't work).


Ehm, building LLVM on your own is always a risky business. See my 
blog[1] for more details especially find the post where I compare 
quality of various LLVM builds using various optimization options...




I was able to complete the build of ghc-7.6.1 using Karel's patch and

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0

I was able to make binary-dist after doing

mkdir compiler/stage2/doc

However after unpacking the binary distribution and doing a make install
I get:

Installing library in /tmp/bindist/lib/ghc-7.6.1/ghc-prim-0.3.0.0
ghc-cabal: Failed to read "target arch" value "ArchARM {armISA = ARMv6,
armISAExt = [VFPv2], armABI = }"
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2

And in particular the installed ghc gives the error:

$ bin/ghc
Failed to read "target arch" value "ArchARM {armISA = ARMv6, armISAExt =
[VFPv2], armABI = }"

Sounds to me like Karel's patch is almost, but not quite there.


Looks like you do have corrupted settings file. Recover it by adding 
"HARD" following "armABI = ", so result should be:


ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"

That's all what's needed, honestly speaking I don't know why it's 
screwed on your board.



Karel, maybe you should try deploying a binary-dist on your panda board?


Sorry? What's "binary-dist"? And why I should do that? And what exactly 
do you mean by "deploying"? And on what OS? Ubuntu or Raspbian run in 
Ubuntu chroot?


Karel
[1]: https://ghcarm.wordpress.com/

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Karel Gardas wrote:
I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float ABI 
distro. I used distro provided LLVM 3.0 and configured GHC with:


Please keep in mind that GHC HEAD is completely different beast as 
there is new codegen put on by defaul there and LLVM codegen is not working 
correctly with it yet.


Oh?  If LLVM codegen is broken in HEAD, that would explain why it's not 
working for ARM :)  Hopefully I can get it working soon with at least an 
unregistered build.  I have to build HEAD, since I'm doing cross-compiling.


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

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Karel Gardas]

On 01/20/13 07:39 PM, Stephen Paul Weber wrote:

Somebody claiming to be Karel Gardas wrote:

I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is
hard-float ABI distro. I used distro provided LLVM 3.0 and configured
GHC with:

Please keep in mind that GHC HEAD is completely different beast as
there is new codegen put on by defaul there and LLVM codegen is not
working correctly with it yet.


Oh? If LLVM codegen is broken in HEAD, that would explain why it's not
working for ARM :) Hopefully I can get it working soon with at least an
unregistered build. I have to build HEAD, since I'm doing cross-compiling.


The receipt is simple, first try LLVM-based build on fast x86 machine 
(i.e. cd mk; cp build.mk.sample build.mk; edit to uncomment BuildFlavour 
= quick-llvm) and once it's working attempt LLVM-based (the only way) 
build on ARM.


Also, forget unregisterised build, rather ask Austin how is it looking 
with his work on fixing LLVM codegen in HEAD.


And a last note: please keep in mind that cross-compiling is supported 
only using NCG. LLVM is completely out of question now, so you will have 
some work here anyway. I don't think it'll be complicated, but certainly 
some hacking with passing target triplet down to LLVM, but IIRC you've 
already found that anyway...


Karel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[roconnor]

On Sun, 20 Jan 2013, Karel Gardas wrote:


On 01/20/13 07:17 PM, rocon...@theorem.ca wrote:

On Wed, 16 Jan 2013, Karel Gardas wrote:


You should not IMHO. My patch should solve all your issues. :-) The
only issue you may get is that your distro ghc will compile for
soft-float ABI and your compiled GHC will compile to hard-float and
object files will get mixed somewhere. But I trust your distro ghc
builders that this is not the case so both GHCs should compile using
hard-float. So issue solved, at least should be. Now I'm just waiting
if you verify this or not so I'm either able to submit the patch for
inclusion or hack it more...


I switched to using llvm-3.0 from rasbian, and made a lot of progress.
(In retrospect I built llvm-3.1 using nix, and it was in a completely
different toolchain than the rest of the build. I should have known that
it wouldn't work).


Ehm, building LLVM on your own is always a risky business. See my blog[1] for 
more details especially find the post where I compare quality of various LLVM 
builds using various optimization options...




I was able to complete the build of ghc-7.6.1 using Karel's patch and

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0

I was able to make binary-dist after doing

mkdir compiler/stage2/doc

However after unpacking the binary distribution and doing a make install
I get:

Installing library in /tmp/bindist/lib/ghc-7.6.1/ghc-prim-0.3.0.0
ghc-cabal: Failed to read "target arch" value "ArchARM {armISA = ARMv6,
armISAExt = [VFPv2], armABI = }"
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2

And in particular the installed ghc gives the error:

$ bin/ghc
Failed to read "target arch" value "ArchARM {armISA = ARMv6, armISAExt =
[VFPv2], armABI = }"

Sounds to me like Karel's patch is almost, but not quite there.


Looks like you do have corrupted settings file. Recover it by adding "HARD" 
following "armABI = ", so result should be:


ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"

That's all what's needed, honestly speaking I don't know why it's screwed on 
your board.



Karel, maybe you should try deploying a binary-dist on your panda board?


Sorry? What's "binary-dist"? And why I should do that? And what exactly do 
you mean by "deploying"? And on what OS? Ubuntu or Raspbian run in Ubuntu 
chroot?


What I'm suggesting is that if you want to try to reproduce my corrupt 
setting file error and ammend your patch for including in GHC, you should 
after making ghc-7.6.1 (or whatever version you are building) do a


make binary-dist  # this will product a ghc-7.6.1-arm-unknown-linux.tar.bz2 file

extract ghc-7.6.1-arm-unknown-linux.tar.bz2 in some temporary directory.

in that extracted directory run

./configue --prefix=
make install



Karel
[1]: https://ghcarm.wordpress.com/



--
Russell O'Connor  
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[Karel Gardas]

On 01/20/13 07:50 PM, rocon...@theorem.ca wrote:

Karel, maybe you should try deploying a binary-dist on your panda board?


Sorry? What's "binary-dist"? And why I should do that? And what
exactly do you mean by "deploying"? And on what OS? Ubuntu or Raspbian
run in Ubuntu chroot?


What I'm suggesting is that if you want to try to reproduce my corrupt
setting file error and ammend your patch for including in GHC, you
should after making ghc-7.6.1 (or whatever version you are building) do a

make binary-dist # this will product a
ghc-7.6.1-arm-unknown-linux.tar.bz2 file

extract ghc-7.6.1-arm-unknown-linux.tar.bz2 in some temporary directory.

in that extracted directory run

./configue --prefix=
make install


Aha, I understand, but could you be so kind and first verify that the 
settings file you do have inside your build tree is the same exactly 
like the settings file distributed with your bin dist? If not, then make 
binary-dist is somehow buggy. If yes, then the configure is buggy and 
its surprising you've been able to build ghc at all...


Sorry, I cannot test it here as my 7.6.1 build on ARM is already gone 
due to hard-drive space constraints here as it freed space for GHC 
i386/x64 solaris cross-compilation tests...


Thanks,
Karel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[roconnor]

On Sun, 20 Jan 2013, Karel Gardas wrote:


On 01/20/13 07:50 PM, rocon...@theorem.ca wrote:

Karel, maybe you should try deploying a binary-dist on your panda board?


Sorry? What's "binary-dist"? And why I should do that? And what
exactly do you mean by "deploying"? And on what OS? Ubuntu or Raspbian
run in Ubuntu chroot?


What I'm suggesting is that if you want to try to reproduce my corrupt
setting file error and ammend your patch for including in GHC, you
should after making ghc-7.6.1 (or whatever version you are building) do a

make binary-dist # this will product a
ghc-7.6.1-arm-unknown-linux.tar.bz2 file

extract ghc-7.6.1-arm-unknown-linux.tar.bz2 in some temporary directory.

in that extracted directory run

./configue --prefix=
make install


Aha, I understand, but could you be so kind and first verify that the 
settings file you do have inside your build tree is the same exactly like the 
settings file distributed with your bin dist? If not, then make binary-dist 
is somehow buggy. If yes, then the configure is buggy and its surprising 
you've been able to build ghc at all...


both the settings and inplace/lib/settings are correct in my build tree. 
This suggests taht binary-dist is buggy.


Sorry, I cannot test it here as my 7.6.1 build on ARM is already gone due to 
hard-drive space constraints here as it freed space for GHC i386/x64 solaris 
cross-compilation tests...


Thanks,
Karel



--
Russell O'Connor  
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[roconnor]

On Sun, 20 Jan 2013, Karel Gardas wrote:


On 01/20/13 07:17 PM, rocon...@theorem.ca wrote:

On Wed, 16 Jan 2013, Karel Gardas wrote:


You should not IMHO. My patch should solve all your issues. :-) The
only issue you may get is that your distro ghc will compile for
soft-float ABI and your compiled GHC will compile to hard-float and
object files will get mixed somewhere. But I trust your distro ghc
builders that this is not the case so both GHCs should compile using
hard-float. So issue solved, at least should be. Now I'm just waiting
if you verify this or not so I'm either able to submit the patch for
inclusion or hack it more...


I switched to using llvm-3.0 from rasbian, and made a lot of progress.
(In retrospect I built llvm-3.1 using nix, and it was in a completely
different toolchain than the rest of the build. I should have known that
it wouldn't work).


Ehm, building LLVM on your own is always a risky business. See my blog[1] for 
more details especially find the post where I compare quality of various LLVM 
builds using various optimization options...




I was able to complete the build of ghc-7.6.1 using Karel's patch and

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0

I was able to make binary-dist after doing

mkdir compiler/stage2/doc

However after unpacking the binary distribution and doing a make install
I get:

Installing library in /tmp/bindist/lib/ghc-7.6.1/ghc-prim-0.3.0.0
ghc-cabal: Failed to read "target arch" value "ArchARM {armISA = ARMv6,
armISAExt = [VFPv2], armABI = }"
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2

And in particular the installed ghc gives the error:

$ bin/ghc
Failed to read "target arch" value "ArchARM {armISA = ARMv6, armISAExt =
[VFPv2], armABI = }"

Sounds to me like Karel's patch is almost, but not quite there.


Looks like you do have corrupted settings file. Recover it by adding "HARD" 
following "armABI = ", so result should be:


ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"


Okay, I patched the settings filed generted by ./configure in the 
binary-dist and rank make install which completed.  However,


pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
pi@raspberrypi /tmp/bindist $ ./Main
Segmentation fault
pi@raspberrypi /tmp/bindist $ cat Main.hs
main = putStrLn "Hello World."

Damn it.  So close.  I don't know how make install succeded without 
segfaulting.


--
Russell O'Connor  
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[Karel Gardas]

On 01/20/13 08:27 PM, rocon...@theorem.ca wrote:

Looks like you do have corrupted settings file. Recover it by adding
"HARD" following "armABI = ", so result should be:

ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"


Okay, I patched the settings filed generted by ./configure in the
binary-dist and rank make install which completed. However,

pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
pi@raspberrypi /tmp/bindist $ ./Main
Segmentation fault
pi@raspberrypi /tmp/bindist $ cat Main.hs
main = putStrLn "Hello World."

Damn it. So close. I don't know how make install succeded without
segfaulting.


Sigh! Go back to your build tree and try the same thing with 
inplace/bin/ghc-stage2 and let us know if this works or not. BTW: What's 
in Main.hs?


Thanks!
Karel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Global constant propagation

[C Rodrigues]

I'm curious about global constant propagation in GHC.  It's a fairly basic 
optimization in the CFG-based compiler domain, and it's similar to constructor 
specialization, but it doesn't seem to be in GHC's repertoire.  Perhaps it's 
usually subsumed by other optimizations or it's more complicated than I am 
thinking.  Is this optimization worth implementing?

This optimization can help when a case expression returns a product, some 
fields of which are the same in all branches.  The following program is a 
minimal example of an optimizable situation that GHC doesn't exploit.


{-# OPTIONS_GHC -O3 -funbox-strict-fields #-}


data D = D !Int !Int


foo n = if n > 0

        then D 0 0

        else D 0 n


main =

  case foo $ read "7"

  of D x y -> if x == 0 then return () else print y >> putStrLn "A"


After inlining and case-of-case transformation, GHC produces


main = let n = read "7"

           k x y = case x of {0 -> return (); _ -> print y >> putStrLn "A"}

       in if n > 0

          then k 0 0

          else k 0 n


If the simplifier could discover that x is always 0, it could eliminate one 
parameter of 'k' and the case expression.

  
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[roconnor]

On Sun, 20 Jan 2013, Karel Gardas wrote:


On 01/20/13 08:27 PM, rocon...@theorem.ca wrote:

Looks like you do have corrupted settings file. Recover it by adding
"HARD" following "armABI = ", so result should be:

ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"


Okay, I patched the settings filed generted by ./configure in the
binary-dist and rank make install which completed. However,

pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
pi@raspberrypi /tmp/bindist $ ./Main
Segmentation fault
pi@raspberrypi /tmp/bindist $ cat Main.hs
main = putStrLn "Hello World."

Damn it. So close. I don't know how make install succeded without
segfaulting.


Sigh! Go back to your build tree and try the same thing with 
inplace/bin/ghc-stage2 and let us know if this works or not. BTW: What's in 
Main.hs?


pi@raspberrypi /tmp $ ghc-7.6.1c/inplace/bin/ghc-stage2 Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
pi@raspberrypi /tmp $ ./Main
Hello World.

The stage2 compiler works fine inplace.

--
Russell O'Connor  
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[roconnor]

On Sun, 20 Jan 2013, Karel Gardas wrote:


On 01/20/13 08:27 PM, rocon...@theorem.ca wrote:

Looks like you do have corrupted settings file. Recover it by adding
"HARD" following "armABI = ", so result should be:

ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"


Okay, I patched the settings filed generted by ./configure in the
binary-dist and rank make install which completed. However,

pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
pi@raspberrypi /tmp/bindist $ ./Main
Segmentation fault
pi@raspberrypi /tmp/bindist $ cat Main.hs
main = putStrLn "Hello World."

Damn it. So close. I don't know how make install succeded without
segfaulting.


Sigh! Go back to your build tree and try the same thing with 
inplace/bin/ghc-stage2 and let us know if this works or not. BTW: What's in 
Main.hs?


Main.hs is

main = putStrLn "Hello World."

--
Russell O'Connor  
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[wren ng thornton]

On 1/14/13 1:09 PM, Simon Peyton-Jones wrote:

Friends

I'd like to propose a way to "promote" newtypes over their enclosing type.  
Here's the writeup
   http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers

Any comments?  Below is the problem statement, taken from the above page.

I'd appreciate

* A sense of whether you care. Does this matter?


I care. So far I've gotten around some of the problems by defining 
rewrite rules which take (fmap NT), (fmap unNT), etc into unsafeCoerce. 
I haven't run into the eta problems that I'm aware of, but the 
non-constant-time maps are something that shows up quite a lot.


I'd prefer the second approach since it's cleaner to programmers: No new 
syntax; no namespace pollution. The one problem I could see is that 
there's no way to restrict export of the NTC instance, which may be 
necessary for correctness when the constructors aren't exported due to 
invariants...



* Improvements to the design I propose


I'd suggest the name newtypeCoerce (to match unsafeCoerce) rather than 
newtypeCast. The "casting" terminology isn't terribly common in Haskell 
(I don't think).


--
Live well,
~wren

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[wren ng thornton]

On 1/14/13 2:47 PM, Stephen Paul Weber wrote:

Somebody claiming to be Simon Peyton-Jones wrote:

 *   For x1 we can write map MkAge x1 :: [Age]. But this does not
follow  the newtype cost model: there will be runtime overhead from
executing the  map at runtime, and sharing will be lost too. Could GHC
optimise the map  somehow?


My friend pointed out something interesting:

If GHC can know that MkAge is just id (in terms of code, not in terms of
type), which seems possible, and if the only interesting case is a
Functor, which seems possible, then a RULE fmap id = id would solve
this.  No?


The problem is precisely that the types don't line up, so that rule 
won't fire. A more accurate mental model is that when we write:


newtype Foo = MkFoo { unFoo :: Bar }

the compiler generates the definitions:

MkFoo :: Bar -> Foo
MkFoo = unsafeCoerce

unFoo :: Foo -> Bar
unFoo = unsafeCoerce

(among others). So the rule we want is:

fmap unsafeCoerce = unsafeCoerce

Except, there are functions other than fmap which behave specially on 
identity functions. Another major one is (.) where newtypes (but not id) 
introduce an eta-expansion that can ruin performance.


It strikes me that the cleanest solution would be to have GHC explicitly 
distinguish (internally) between "identity" functions and other 
functions, so that it can ensure that it treats all "identity" functions 
equally. Where that equality means rewrite rules using id, special 
optimizations about removing id, etc, all carry over to match on other 
"identity" functions as well.


--
Live well,
~wren

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[wren ng thornton]

On 1/14/13 9:15 PM, Iavor Diatchki wrote:

It looks like what we need is a different concept: one that talks about the
equality of the representations of types, rather then equality of the types
themselves.


+1.

In fact, this distinction is one of the crucial ones I had in mind when 
working on the language I abandoned when I discovered Haskell.  It's 
also something that came up when working on the Dyna language. And now 
it's coming up here. There's a big difference between semantic types and 
representation types; and it sounds like it's high time for working that 
distinction into the compiler (painful though it may be).


--
Live well,
~wren

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

[Karel Gardas]

On 01/21/13 12:49 AM, rocon...@theorem.ca wrote:

On Sun, 20 Jan 2013, Karel Gardas wrote:


Okay, I patched the settings filed generted by ./configure in the
binary-dist and rank make install which completed. However,

pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
pi@raspberrypi /tmp/bindist $ ./Main
Segmentation fault
pi@raspberrypi /tmp/bindist $ cat Main.hs
main = putStrLn "Hello World."

Damn it. So close. I don't know how make install succeded without
segfaulting.


Sigh! Go back to your build tree and try the same thing with
inplace/bin/ghc-stage2 and let us know if this works or not. BTW:
What's in Main.hs?


pi@raspberrypi /tmp $ ghc-7.6.1c/inplace/bin/ghc-stage2 Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
pi@raspberrypi /tmp $ ./Main
Hello World.

The stage2 compiler works fine inplace.


OK, so binary-dist not only corrupted your settings file, but also 
somehow your compiler. Nice to see you are able to get working compiler 
on your RPi board. Congratulations! :-)


Karel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[Shachaf Ben-Kiki]

On Sun, Jan 20, 2013 at 8:13 PM, wren ng thornton  wrote:
> I care. So far I've gotten around some of the problems by defining rewrite
> rules which take (fmap NT), (fmap unNT), etc into unsafeCoerce. I haven't
> run into the eta problems that I'm aware of, but the non-constant-time maps
> are something that shows up quite a lot.

1. As far as I can tell, the (fmap NT) rewrite rule won't ever fire.
At least, I haven't figured out a way to do it, because newtype
constructors (though not selectors) get turned into unsafeCoerces too
early, before any rewrite rules have a change to fire. See
.

2. This might not be relevant in your case, but this rule isn't safe
in general -- you can derive unsafeCoerce from it using an invalid
Functor instance.

For example:

{-# LANGUAGE TypeFamilies #-}
import Unsafe.Coerce

newtype Id a = MkId { unId :: a }

{-# RULES "fmap unId" fmap unId = unsafeCoerce #-}

data family Foo x y a
data instance Foo x y (Id a) = FooI x
data instance Foo x y Bool   = FooB { unB :: y }

instance Functor (Foo x y) where fmap = undefined

coerce :: a -> b
coerce = unB . fmap unId . FooI

Even without extensions, this would let you break invariants in types
like Data.Set by defining an invalid Functor instance. This is a
bigger deal than it might seem, given SafeHaskell -- you can't export
this sort of rule from a Trustworthy library.

Shachaf

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users