Re: Error building ghc on raspberry pi.
(Sorry, forgot to CC the list) Original Message From: Thijs Alkemade m...@thijsalkema.de Sent: Thu Jan 03 10:31:50 CET 2013 To: rocon...@theorem.ca Subject: Re: Error building ghc on raspberry pi. rocon...@theorem.ca wrote: Some further information it seems that llc is segfaulting: pi@raspberrypi /tmp/ghc-7.4.1 $ llc -O3 -relocation-model=static /tmp/ghc7189_0/ghc7189_0.bc -o /tmp/ghc7189_0/ghc7189_0.lm_s Stack dump: 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc7189_0/ghc7189_0.bc -o /tmp/ghc7189_0/ghc7189_0.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc7189_0/ghc7189_0.bc'. 2. Running pass 'ARM Instruction Selection' on function '@ghczmprim_GHCziTypes_Czh_info' Segmentation fault pi@raspberrypi /tmp/ghc-7.4.1 $ llc --version Low Level Virtual Machine (http://llvm.org/): llvm version 3.0 (Debian 3.0-10)Optimized build. Built Jul 26 2012 (20:20:52). Host: arm-unknown-linux-gnueabihf Host CPU: (unknown) Registered Targets: alpha- Alpha [experimental] arm - ARM bfin - Analog Devices Blackfin [experimental] c- C backend cellspu - STI CBEA Cell SPU [experimental] cpp - C++ backend mblaze - MBlaze mips - Mips mips64 - Mips64 [experimental] mips64el - Mips64el [experimental] mipsel - Mipsel msp430 - MSP430 [experimental] ppc32- PowerPC 32 ppc64- PowerPC 64 ptx32- PTX (32-bit) [Experimental] ptx64- PTX (64-bit) [Experimental] sparc- Sparc sparcv9 - Sparc V9 systemz - SystemZ thumb- Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore- XCore On Wed, 2 Jan 2013, rocon...@theorem.ca wrote: I'm trying to build ghc-7.4.1 using ghc-7.4.1 on my raspberry pi (armv6l) and I get the following error: inplace/bin/ghc-stage1 -H32m -O-package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o Stack dump: 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc6324_0/ghc6324_0.bc -o /tmp/ghc6324_0/ghc6324_0.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc6324_0/ghc6324_0.bc'. 2. Running pass 'ARM Instruction Selection' on function '@ghczmprim_GHCziTypes_Czh_info' /tmp/ghc6324_0/ghc6324_0.lm_s: openBinaryFile: does not exist (No such file or directory) make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 make: *** [all] Error 2 Anyone have any thoughts on what might be the matter and what I can do to fix it. (If only openBinaryFile said which file doesn't exist.) I believe I had the same problem, which disappeared after upgrading llvm from 3.0 to 3.1, and using that instead for ./configure. Hope this helps, Thijs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DoCon and GHC
On Wed, Jan 02, 2013 at 11:27:15PM +, Simon Peyton-Jones wrote:
I made a second mistake. I meant (LinSolvRing (UPol k)). Apologies.
| I don't know why 7.4 accepts it, but I'm not inclined to investigate...
| looks like a bug in 7.4.
|
| ghc-7.4.1 may use a special trick, but is correct.
I don't understand your explanation. What is wrong with this reasoning?
1. The call to upEucRing in cubicExt gives rise the constraint
(LinSolvRing (UPol k))
Corect?
2. There are two overlapping instances for (LinSolvRing (UPol k)),
defined in UPol2_ and UPol3_
Correct?
3. So GHC cannot solve the constraint using an instance declaration.
Correct?
4. The type signature provides
(Field k, FactorizationRing (UPol k))
but neither is enough to satisfy LinSolvRing (UPol k).
Correct?
5. Therefore we must add LinSolvRing (UPol k) to the signature.
If you believe that the function should typecheck as-is, please explain
how to deduce (LinSolvRing (UPol k)) from
(Field k, FactorizationRing (UPol k)).
1. I try adding `, LinSolvRing (UPol k)' to the sig of cubeExt.
Now, ghc-7.6.1.20121207
builds docon-2.12 but does not compile the demonstration of T_cubeext.hs
(where cubicExt is)
-- with {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-}
prepended to the module.
Can you, please, reproduce this in ghc-7.6.1.20121207 ?
Because
a) the problem is in porting to a fresh stable GHC version,
b) ghc-7.6.1.20121207 is announced to become a fresh ghc-7.6.2,
and it asks for testing,
c) if I use an older version, then, why, I could simply remain with
ghc-7.4.1.
2. Now suppose that a fresh GHC is fixed, and the point (1) works.
Adding `, LinSolvRing (UPol k)' is not an error.
But is an awkward algebraic statement.
For example, one can formulate
for all integer p 2 such that p is prime and p is odd,
it holds Foo(p).
Adding and p is odd is not an error, but looks awkward, because it is
derived from (p 2, p is prime) according to previous theory.
This reduces redability of the text, because the reader starts to think
that he is missing something subtle.
Similarly, LinSolvRing (UPol k) is derived in cubicExt from
cubicExt and from the proper DoCon.
The matter is that the algorithm (instance) for this LinSolvRing (UPol k)
is derived in multiple ways -- overlapping instances.
3. For this particular case, I agree to tell to GHC:
choose any derivation way you like.
Because a) I know that the needed final result part does not depend on
this choice (even though the algoritms differ),
b) the cost difference will not be great.
How can I tell this to GHC -- with respect to only this function signature,
or maybe, only to this module ?
4. Probably, the rule of the substitutional instance specialization in
Haskell+Glasgow is not enough to follow algebra.
Why not give the user an additional way to choose the derivation?
For example, let there be the instances I, II, III, IV, and the instance
(Foo T) is derived from I, II, III, IV in multiple ways.
The programmer writes the signature
f :: (..., (Foo T, using {II, III}, notUsing {I, IV})) = ...
which means to consider for (Foo T) only those derivations which use
{II, III} and do not use {I, IV}.
I do not know, may be I am missing something.
5. Now, I specify how LinSolvRing (UPol k) is derived in the existing
Haskell+Glasgow language.
DoCon = Proper-DoCon + demo;cubicExt is a part of demo.
First, Proper-DoCon is installed -- this works.
And cubicExt is not compiled.
Proper-DoCon includes:
GCDRing a and EuclideanRing a are superclasses for Field a, (I)
class (GCDRing a, LinSolvRing a) = EuclideanRing a where ... (II)
instance GCDRing a = GCDRing (UPol a) where ...(III)
instance Field k = EuclideanRing (UPol k) where ... (IV)
instance EuclideanRing a = LinSolvRing (UPol a) where ...(V)
(in Pol2_.hs)
Each of these has a very useful algebraic meaning.
Now, GHC starts to compile cubicExt. And there
Field k = LinSolvRing (UPol k)
is derived from I -- V in at least two ways, and may be there are
even more of them.
Algebraically, these overlaps are all right, they are in the nature,
these derivations give equivalent results.
But one may insist: choose the way, because the algorithms are different,
and the computation cost may differ.
For example, for
Field k = LinSolvRing (UPol k),
I would choose this way:
Field k is declared.
Euclidean is a superclass for Field by (I).
hence there is the instance Euclidean k.
hence there is the instance LinSolvRing (UPol k)
by V with a := k.
And Haskell+Glasgow sees this derivation surely.
In the algebra textbooks it is expressed like this:
k is a Field, hence it
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
worked for me under x86 SunOS 5.10 Cheers Christian OVERALL SUMMARY for test run started at Donnerstag, 3. Januar 2013, 09:52:19 Uhr CET 3402 total tests, which gave rise to 13556 test cases, of which 10 caused framework failures 10486 were skipped 2954 expected passes 47 had missing libraries 36 expected failures 0 unexpected passes 33 unexpected failures Unexpected failures: ../../libraries/base/tests/IOopenFile003 [bad stdout] (normal) ../../libraries/process/tests3994 [bad exit code] (threaded1) ../../libraries/process/testsprocess007 [bad stdout] (normal) ../../libraries/unix/tests 3816 [bad exit code] (normal) ../../libraries/unix/tests user001 [bad stdout] (normal) ../../libraries/unix/tests/libposix posix002 [bad exit code] (normal) ../../libraries/unix/tests/libposix posix005 [bad stdout] (normal) cabal/cabal01cabal01 [bad exit code] (normal) cabal/cabal03cabal03 [bad exit code] (normal) cabal/cabal04cabal04 [bad exit code] (normal) lib/integer IntegerConversionRules [bad stderr] (normal) lib/integer T7041 [bad stderr] (normal) lib/integer integerConstantFolding [bad exit code] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) perf/haddock haddock.compiler [stat too good] (normal) plugins plugins01 [bad exit code] (normal) plugins plugins02 [stderr mismatch] (normal) plugins plugins03 [stderr mismatch] (normal) rts exec_signals [bad exit code] (normal) safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly05 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly06 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly07 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly08 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly09 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly10 [exit code non-0] (normal) safeHaskell/check/pkg01 safePkg01 [bad exit code] (normal) simplCore/should_compile T5658b [bad exit code] (normal) simplCore/should_compile T5776 [bad exit code] (normal) On 09/12/12 21:39, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 7.6.2: http://www.haskell.org/ghc/dist/7.6.2-rc1/ This includes the source tarball, installers for Windows, and bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64. We plan to make the 7.6.2 release early in 2013. Please test as much as possible; bugs are much cheaper if we find them before the release! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: DoCon and GHC
OK I have tested with today's GHC 7.6.2, which is very slightly later than the release candidate. When I add (EuclideanRing (UPol k)) to the signature for cubicExt, the whole of demotest compiles. So that works. Your misconception is here: | c) Pol3_ has |instance (LinSolvRing (Pol a), CommutativeRing a) = | LinSolvRing (UPol (Pol a)) |But this does not overlap with Field k = LinSolvRing (UPol k). | |Because Pol a is never of a Field nor of EuclideanRing. When matching instances, GHC does not take account of the context of the instance. Say you have data T a = ... data S1 = ... data S2 = ... [a] instance Num a = Num (T a) where ... [b] instance Show a = Num (T a) where ... instance Num S1 and suppose you need an instance of (Num (T S1)). Then although [a] and [b] overlap, you might say we should use [a], since S1 is an instance of Num, but not an instance of Show. But GHC does not do this. It matches instances only based on the bit after the =. I'm sorry, but that's the way it is. (There are good reasons for this.) If you don't care which of the overlapping instances is picked, then you can use -XIncoherentInstances. But you have to set that flag at the *instance declaration* not at the *use* of the instance. In this case it would be the instance for LinSolvRing (UPol k) Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DoCon and GHC
On Thu, Jan 3, 2013 at 4:57 AM, Simon Peyton-Jones simo...@microsoft.com wrote: When matching instances, GHC does not take account of the context of the instance. Say you have data T a = ... data S1 = ... data S2 = ... [a] instance Num a = Num (T a) where ... [b] instance Show a = Num (T a) where ... instance Num S1 and suppose you need an instance of (Num (T S1)). Then although [a] and [b] overlap, you might say we should use [a], since S1 is an instance of Num, but not an instance of Show. But GHC does not do this. It matches instances only based on the bit after the =. It seems you're making GHC seem more capricious than it is here. Even were GHC to consider contexts in instance selection, the choice of [a] over [b] would still be incoherent: the compiler has no way to prove that there is no later instance adding S1 to class Show. Indeed, the S1's and S2's are in some sense not relevant: because Haskell provides no mechanism to exclude types from classes, there is no way to ever coherently use instance [a] or [b], regardless of the argument to T. /g -- Sent from my mail client. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DoCon and GHC
This is copying to the list my reply to Simon: On Thu, Jan 03, 2013 at 12:57:02PM +, Simon Peyton-Jones wrote: OK I have tested with today's GHC 7.6.2, which is very slightly later than the release candidate. When I add (EuclideanRing (UPol k)) to the signature for cubicExt, the whole of demotest compiles. So that works. Also ghc $doconCpOpt --make Main ./Main must end with No errors detected, and take not more than 4 sec on a 2 GHz machine (for suppose that an overlap is resolved unluckily for the cost, so that the time becomes, say 60 sec). Your misconception is here: | c) Pol3_ has |instance (LinSolvRing (Pol a), CommutativeRing a) = | LinSolvRing (UPol (Pol a)) |But this does not overlap with Field k = LinSolvRing (UPol k). | |Because Pol a is never of a Field nor of EuclideanRing. When matching instances, GHC does not take account of the context of the instance. Say you have [..] I knew this, and have forgotten. Thank you. If you don't care which of the overlapping instances is picked, then you can use -XIncoherentInstances. But you have to set that flag at the *instance declaration* not at the *use* of the instance. In this case it would be the instance for LinSolvRing (UPol k) Probably, this will work good in one place where this instance is used, and work bad in another place. In the papers on algorithmic algebra the authors often compute some foo for a domain T, and consider various methods for this computation, and often a method is defined by the choice of the instance derivation. And the author writes: apply the method defined by this and this instance construction, this costs, say, O(n^3) bit operations, and so on (literally, the word `instance' is not written). So, there is not a problem of specifying the overlap resolving in papers and lectures, this is done easily. But Haskell+Glasgow does not provide a sufficient language construct for such a resolving. It has the rule of a substitutionally more special instance. Probably, something appropriate can be added to this rule. Anyway, I shall wait for ghc-7.6.2, and see. Thanks, -- Sergei ___ 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.
rocon...@theorem.ca writes: Some further information it seems that llc is segfaulting: Where did you get your LLVM build from? Did you try running the LLVM testsuite? IIRC, LLVM 3.0 was less than stellar on ARM. - Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Suppress Duplicate constraints warning?
Yes, please do add a flag to suppress this duplicate constraints warning, e.g., -fno-warn-duplicate-constraints. Thanks! -- Conal On Mon, Dec 31, 2012 at 9:27 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Hmm. Actually there isn’t a flag to suppress it, I’m afraid. Would you like me to add one? (It would be easy to do.) Simon ** ** *From:* glasgow-haskell-users-boun...@haskell.org [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott *Sent:* 30 December 2012 19:56 *To:* glasgow-haskell-users@haskell.org *Subject:* Suppress Duplicate constraints warning? ** ** Is there a way to suppress GHC's Duplicate constraints warning? I'm auto-generating some code, and it's a lot more convenient for me to leave the duplicates than filter them out. -- Conal ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Suppress Duplicate constraints warning?
Oh! I see it's already done. Thanks much! On Thu, Jan 3, 2013 at 11:55 AM, Conal Elliott co...@conal.net wrote: Yes, please do add a flag to suppress this duplicate constraints warning, e.g., -fno-warn-duplicate-constraints. Thanks! -- Conal On Mon, Dec 31, 2012 at 9:27 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Hmm. Actually there isn’t a flag to suppress it, I’m afraid. Would you like me to add one? (It would be easy to do.) Simon ** ** *From:* glasgow-haskell-users-boun...@haskell.org [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott *Sent:* 30 December 2012 19:56 *To:* glasgow-haskell-users@haskell.org *Subject:* Suppress Duplicate constraints warning? ** ** Is there a way to suppress GHC's Duplicate constraints warning? I'm auto-generating some code, and it's a lot more convenient for me to leave the duplicates than filter them out. -- Conal ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
