GHC compilation error (re-post).

2013-01-17 Thread Caitlin 
Hi all.

I wrote the following test program:

bar x = x * x

on a Win32 (SP3) machine using the Haskell Platform and GHC-7.6.1
(standalone) and I have noticed the same frustrating errors. Any
suggestions would be most appreciated.

Thanks,

~Caitlin

C:\>ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude>
Prelude> :l bar
[1 of 1] Compiling Main ( bar.hs, interpreted )
*** Exception: CreateDirectory ".": permission denied (Access is denied.)
>
> :l bar.hs
[1 of 1] Compiling Main ( bar.hs, interpreted )
*** Exception: CreateDirectory ".": permission denied (Access is denied.)
>
> :l "C:\\bar.hs"
[1 of 1] Compiling Main ( C:\bar.hs, interpreted )
*** Exception: CreateDirectory "C:\\": permission denied (Access is denied.)
>
>
___
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.

2013-01-17 Thread roconnor 

On Thu, 17 Jan 2013, Austin Seipp wrote:


There have been a few of these bugs recently it seems. If you could:
use the stage1 compiler to compile a simple executable, like 'main =
return ()' or hello world or whatever.

The stage1 compiler can be located in the build directory, under
'inplace/bin/ghc-stage1'. So something like:

/inplace/bin/ghc-stage1 -fforce-recomp hello_world.hs

Check if the output executable crashes immediately. If it does, then
it is likely a miscompilation of the runtime or libraries somewhere.
Otherwise, we'll have to narrow down another way.


$ inplace/bin/ghc-stage1 -fforce-recomp /tmp/Main.hs
[1 of 1] Compiling Main ( /tmp/Main.hs, /tmp/Main.o )
Linking /tmp/Main ...
$ /tmp/Main
Segmentation fault


If it does fail, please use GDB on the executable, and give a
backtrace from the crash (using the 'bt' command, after the program
has crashed.)


I'll get back to you on this.


You can also try linking with the debug RTS, by passing the -debug and
-rtsopts flag to ghc-stage1. Then run again, and see if something else
was tripped. You can see all the sanity checks you can enable, if you
run the executable using './program.exe +RTS --help'. The debug flags
are named things like '-Ds' and '-Da', etc and should be passed to the
RTS.


--
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: Should ghc -msse imply gcc -msse

2013-01-17 Thread Johan Tibell 
On Thu, Jan 17, 2013 at 12:29 PM, Simon Marlow  wrote:
> If the intended meaning of -msse is
>
>   Use SSE instructions in Haskell compilations
>
> then of course we should pass -mattr=+sse to LLVM, because it is the backend
> for Haskell compilations.  But we should not pass it to gcc, unless we're
> using the C backend.

Lets do at least this then.

-- Johan

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

Re: Should ghc -msse imply gcc -msse

2013-01-17 Thread Simon Marlow 

On 17/01/13 20:06, Johan Tibell wrote:

On Thu, Jan 17, 2013 at 12:01 PM, Johan Tibell  wrote:

I forgot I once raised this on the GHC bug tracker:
http://hackage.haskell.org/trac/ghc/ticket/7025

Here's what Simon M had to say back then:

"The right thing is to put -msse in the cc-options field of your
.cabal file, if that's what you want.

I'm distinctly uneasy about having -msse magically pass through to gcc.

* There are many flags that we do not pass through to gcc, so having
one that we do pass through could be confusing (and lead to lots more
requests for more flags to be passed through)

* What if there is a variant of -msse that gcc supports but we don't?
Wouldn't we have to keep them in sync?

I'm going to close this as wontfix, but please feel free to reopen and
disagree."


One problem with having the user set cc-options in addition to passing
-msse to GHC, is that the user might not realize that he/she needs to
do this. This is bad if you use -fllvm, as your -msse will essentially
just be ignored as the LLVM primitives we use in the LLVM backend
(e.g. for popcnt) won't convert to SSE instructions.

Even worse, LLVM doesn't support a -msse flag, instead you need to use
-mattr=+sse, so the user needs to be aware of this difference and
change his/her flags depending on if we use the native backend or the
LLVM backend.


If the intended meaning of -msse is

  Use SSE instructions in Haskell compilations

then of course we should pass -mattr=+sse to LLVM, because it is the 
backend for Haskell compilations.  But we should not pass it to gcc, 
unless we're using the C backend.


If instead the intended meaning of -msse is

  Use SSE instructions in all compilations

then we should pass it to gcc too.  This just feels a bit too magical to 
me, and since we have a way to say exactly what you want, I'm not sure 
it's necessary.


Cheers,
Simon


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

Re: Should ghc -msse imply gcc -msse

2013-01-17 Thread Johan Tibell 
On Thu, Jan 17, 2013 at 12:01 PM, Johan Tibell  wrote:
> I forgot I once raised this on the GHC bug tracker:
> http://hackage.haskell.org/trac/ghc/ticket/7025
>
> Here's what Simon M had to say back then:
>
> "The right thing is to put -msse in the cc-options field of your
> .cabal file, if that's what you want.
>
> I'm distinctly uneasy about having -msse magically pass through to gcc.
>
> * There are many flags that we do not pass through to gcc, so having
> one that we do pass through could be confusing (and lead to lots more
> requests for more flags to be passed through)
>
> * What if there is a variant of -msse that gcc supports but we don't?
> Wouldn't we have to keep them in sync?
>
> I'm going to close this as wontfix, but please feel free to reopen and
> disagree."

One problem with having the user set cc-options in addition to passing
-msse to GHC, is that the user might not realize that he/she needs to
do this. This is bad if you use -fllvm, as your -msse will essentially
just be ignored as the LLVM primitives we use in the LLVM backend
(e.g. for popcnt) won't convert to SSE instructions.

Even worse, LLVM doesn't support a -msse flag, instead you need to use
-mattr=+sse, so the user needs to be aware of this difference and
change his/her flags depending on if we use the native backend or the
LLVM backend.

-- Johan

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

Re: Should ghc -msse imply gcc -msse

2013-01-17 Thread Johan Tibell 
Hi all,

I forgot I once raised this on the GHC bug tracker:
http://hackage.haskell.org/trac/ghc/ticket/7025

Here's what Simon M had to say back then:

"The right thing is to put -msse in the cc-options field of your
.cabal file, if that's what you want.

I'm distinctly uneasy about having -msse magically pass through to gcc.

* There are many flags that we do not pass through to gcc, so having
one that we do pass through could be confusing (and lead to lots more
requests for more flags to be passed through)

* What if there is a variant of -msse that gcc supports but we don't?
Wouldn't we have to keep them in sync?

I'm going to close this as wontfix, but please feel free to reopen and
disagree."

___
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.

2013-01-17 Thread Austin Seipp 
There have been a few of these bugs recently it seems. If you could:
use the stage1 compiler to compile a simple executable, like 'main =
return ()' or hello world or whatever.

The stage1 compiler can be located in the build directory, under
'inplace/bin/ghc-stage1'. So something like:

/inplace/bin/ghc-stage1 -fforce-recomp hello_world.hs

Check if the output executable crashes immediately. If it does, then
it is likely a miscompilation of the runtime or libraries somewhere.
Otherwise, we'll have to narrow down another way.

If it does fail, please use GDB on the executable, and give a
backtrace from the crash (using the 'bt' command, after the program
has crashed.)

You can also try linking with the debug RTS, by passing the -debug and
-rtsopts flag to ghc-stage1. Then run again, and see if something else
was tripped. You can see all the sanity checks you can enable, if you
run the executable using './program.exe +RTS --help'. The debug flags
are named things like '-Ds' and '-Da', etc and should be passed to the
RTS.

On Thu, Jan 17, 2013 at 1:11 PM,   wrote:
> On Wed, 16 Jan 2013, Karel Gardas wrote:
>
>> On 01/16/13 08:12 PM, rocon...@theorem.ca wrote:
>>>
>>> On Wed, 16 Jan 2013, Karel Gardas wrote:
>>>

 Good! So the patch I already provided is working fine at least w.r.t.
 change in configure. I've tested it here on my raspbian chroot on
 pandaboard where I've hacked config.guess to print exactly what you
 get on real rpi.

 Now, I'm curious if the hack in DriverPipeline.hs helps too.

 Were you able to merge the patch into your GHC? And rebuild? What was
 the result?
>>>
>>>
>>> I'm still trying to figure out the correct usage of
>>> -optlc-float-abi=hard in mk/build.mk. I've ben getting a lot of errors
>>> about two occurances of the float-abi=hard flag.
>>
>>
>> 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...
>
>
> The first run of the stage2 compilier fails with a segfault:
>
>   HC [stage 2] utils/ghctags/dist-install/build/Main.o
> /bin/sh: line 1: 30064 Segmentation fault  "inplace/bin/ghc-stage2"
> -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp
> -optlc=-mattr=+vfp2 -i -iutils/ghctags/. -iutils/ghctags/dist-install/build
> -iutils/ghctags/dist-install/build/autogen
> -Iutils/ghctags/dist-install/build
> -Iutils/ghctags/dist-install/build/autogen -package ghc -no-user-package-db
> -rtsopts -odir utils/ghctags/dist-install/build -hidir
> utils/ghctags/dist-install/build -stubdir utils/ghctags/dist-install/build
> -hisuf hi -osuf o -hcsuf hc -c utils/ghctags/./Main.hs -o
> utils/ghctags/dist-install/build/Main.o
> make[1]: *** [utils/ghctags/dist-install/build/Main.o] Error 139
>
> make: *** [all] Error 2
>
> using
>
>
> SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard
> -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts= -O
> -fllvm GhcStage2HcOpts= -O0 -fllvm
> GhcLibHcOpts   = -O -fllvm
>
> --
> 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



-- 
Regards,
Austin

___
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.

2013-01-17 Thread roconnor 

On Wed, 16 Jan 2013, Karel Gardas wrote:


On 01/16/13 08:12 PM, rocon...@theorem.ca wrote:

On Wed, 16 Jan 2013, Karel Gardas wrote:



Good! So the patch I already provided is working fine at least w.r.t.
change in configure. I've tested it here on my raspbian chroot on
pandaboard where I've hacked config.guess to print exactly what you
get on real rpi.

Now, I'm curious if the hack in DriverPipeline.hs helps too.

Were you able to merge the patch into your GHC? And rebuild? What was
the result?


I'm still trying to figure out the correct usage of
-optlc-float-abi=hard in mk/build.mk. I've ben getting a lot of errors
about two occurances of the float-abi=hard flag.


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...


The first run of the stage2 compilier fails with a segfault:

  HC [stage 2] utils/ghctags/dist-install/build/Main.o
/bin/sh: line 1: 30064 Segmentation fault  "inplace/bin/ghc-stage2" -H64m 
-Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 
-i -iutils/ghctags/. -iutils/ghctags/dist-install/build 
-iutils/ghctags/dist-install/build/autogen -Iutils/ghctags/dist-install/build 
-Iutils/ghctags/dist-install/build/autogen -package ghc -no-user-package-db -rtsopts 
-odir utils/ghctags/dist-install/build -hidir utils/ghctags/dist-install/build -stubdir 
utils/ghctags/dist-install/build -hisuf hi -osuf o -hcsuf hc -c utils/ghctags/./Main.hs 
-o utils/ghctags/dist-install/build/Main.o
make[1]: *** [utils/ghctags/dist-install/build/Main.o] Error 139
make: *** [all] Error 2

using

SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 
GhcStage1HcOpts= -O -fllvm 
GhcStage2HcOpts= -O0 -fllvm

GhcLibHcOpts   = -O -fllvm

--
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

RULES map (\x -> x) = id

2013-01-17 Thread Joachim Breitner 
Hi,

I am experimenting with rewrite rules, but found that they do not fire
as often as I wanted them. Here is a small example:

module MapId where

myMap f [] = []
myMap f (x:xs) = f x : myMap f xs

{-# RULES "map id" myMap id = id #-}
{-# RULES "map id2" myMap (\x -> x) = id #-}

mapId = myMap id
mapIdApp x = myMap id x

mapLamId = myMap (\x -> x)
mapLamIdApp x = myMap (\x -> x) x

This works as expected, i.e. the latter four functions become some kind
of identity. But I am a bit surprised that I do need two rules to catch
all cases, as I thought that the simplifier „looks through“ definitions
like "id". But when I remove the "map id" rule, the functions "mapId"
and "mapIdApp" are not optimized. 

So I wonder: Why is rule "map id2" not enough here?

Thanks,
Joachim


-- 
Joachim "nomeata" Breitner
  m...@joachim-breitner.de  |  nome...@debian.org  |  GPG: 0x4743206C
  xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/



signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users