Re: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9

[GHC]

#1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a
PPC Mac OS X 10.5 Leopard as part of GHC 6.9
-+--
 Reporter:  thorkilnaur  |  Owner:  thorkilnaur
 Type:  bug  | Status:  new
 Priority:  high |  Milestone:  6.8.3  
Component:  Compiler |Version:  6.9
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  powerpc
   Os:  MacOS X  |  
-+--
Comment (by thorkilnaur):

 Trying a few combinations of compiler options shows: With
 {{{
 SRC_HC_OPTS   = -H32m -O2
 GhcHcOpts = -Rghc-timing
 GhcLibHcOpts  =
 GhcLibWays=
 }}}
 in mk/build.mk, the build ends with:
 {{{
 ../../compiler/stage1/ghc-inplace -package-name unix-2.2 -hide-all-
 packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build
 -Iinclude -#include "HsUnix.h" -#include "execvpe.h" -odir dist/build
 -hidir dist/build -stubdir dist/build -package base-3.0 -package
 directory-1.0 -O -XCPP -XForeignFunctionInterface -idist/build  -H32m -O2
 -c dist/build/System/Posix/Semaphore.hs -o
 dist/build/System/Posix/Semaphore.o  -ohi
 dist/build/System/Posix/Semaphore.hi
 collect2: ld terminated with signal 10 [Bus error]
 make[2]: *** [dist/build/System/Posix/Semaphore.o] Error 1
 make[1]: *** [make.library.unix] Error 2
 make: *** [stage1] Error 2
 }}}
 (The extra-packages are included in this build.) If I then change
 mk/build.mk to
 {{{
 SRC_HC_OPTS   = -H32m -O2
 GhcHcOpts = -Rghc-timing
 GhcLibHcOpts  =
 GhcLibWays=
 SplitObjs = NO
 }}}
 the build ends with:
 {{{
 /usr/bin/ld -r -x -o HSghc.o  stage2/basicTypes/BasicTypes.o
 stage2/basicTypes/DataCon.o stage2/basicTypes/Demand.o
 stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o
 stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o
 stage2/basicTypes/Module.o stage2/basicTypes/Name.o
 stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o
 stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o
 stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o
 stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o
 stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o
 stage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o
 stage2/cmm/CmmBrokenBlock.o stage2/cmm/CmmCPS.o stage2/cmm/CmmCPSGen.o
 stage2/cmm/CmmCPSZ.o stage2/cmm/CmmCallConv.o stage2/cmm/CmmContFlowOpt.o
 stage2/cmm/CmmCvt.o stage2/cmm/CmmExpr.o stage2/cmm/CmmInfo.o
 stage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmLive.o
 stage2/cmm/CmmLiveZ.o stage2/cmm/CmmOpt.o stage2/cmm/CmmParse.o
 stage2/cmm/CmmProcPoint.o stage2/cmm/CmmProcPointZ.o
 stage2/cmm/CmmSpillReload.o stage2/cmm/CmmTx.o stage2/cmm/CmmUtils.o
 stage2/cmm/CmmZipUtil.o stage2/cmm/DFMonad.o stage2/cmm/Dataflow.o
 stage2/cmm/MachOp.o stage2/cmm/MkZipCfg.o stage2/cmm/MkZipCfgCmm.o
 stage2/cmm/OptimizationFuel.o stage2/cmm/PprC.o stage2/cmm/PprCmm.o
 stage2/cmm/PprCmmZ.o stage2/cmm/StackColor.o stage2/cmm/StackPlacements.o
 stage2/cmm/ZipCfg.o stage2/cmm/ZipCfgCmmRep.o stage2/cmm/ZipCfgExtras.o
 stage2/cmm/ZipDataflow0.o stage2/codeGen/Bitmap.o
 stage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o
 stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o stage2/codeGen/CgCon.o
 stage2/codeGen/CgExpr.o stage2/codeGen/CgForeignCall.o
 stage2/codeGen/CgHeapery.o stage2/codeGen/CgHpc.o
 stage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o
 stage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o
 stage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o
 stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o
 stage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o
 stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o
 stage2/codeGen/SMRep.o stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o
 stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o
 stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o
 stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o
 stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o
 stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o
 stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o
 stage2/deSugar/Coverage.o stage2/deSugar/Desugar.o
 stage2/deSugar/DsArrows.o stage2/deSugar/DsBinds.o
 stage2/deSugar/DsCCall.o stage2/deSugar/DsExpr.o
 stage2/deSugar/DsForeign.o stage2/deSugar/DsGRHSs.o
 stage2/deSugar/DsListComp.o stage2/deSugar/DsMeta.o
 stage2/deSugar/DsMonad.o stage2/deSugar/DsUtils.o stage2/deSugar/Match.o
 stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o
 stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o
 stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o
 stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o
 stage2/ghci/Debugger.o stage2/ghci/GhciMonad.o stage2/ghci/GhciTags.o
 stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o stage2/ghci/ObjLink.o
 sta

Re: [GHC] #2059: Erroneous results in trigonometric functions for > double-precision values

[GHC]

#2059: Erroneous results in trigonometric functions for > double-precision 
values
--+-
Reporter:  daniel.is.fischer  |Owner:   
Type:  feature request|   Status:  new  
Priority:  normal |Milestone:   
   Component:  Compiler   |  Version:  6.8.1
Severity:  normal |   Resolution:   
Keywords: | Testcase:   
Architecture:  x86|   Os:  Linux
--+-
Changes (by ajd):

  * type:  bug => feature request
  * summary:  Erroneous results in trigonometric functions => Erroneous
  results in trigonometric functions for >
  double-precision values

Comment:

 The problem is that the Double type cannot store that much precision and
 so GHC can't calculate trig functions at all accurately. (This is actually
 documented, see [http://www.haskell.org/ghc/docs/latest/html/users_guide
 /wrong-compilee.html]. Since this is the way the compiler is documented to
 work, I'm changing the status to feature request.)

 From my understanding, in order to solve this, one would need to implement
 an arbitrary precision ''floating-point'' system in GHC (currently, we
 only have arbitrary precision ''integers'' through GMP). This ''could'' be
 done through something like MPFR, but I'm guessing that would be a huge
 job and potentially plagued with the same problems as GMP, as the latter
 is a dependency of the former.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #2059: Erroneous results in trigonometric functions

[GHC]

#2059: Erroneous results in trigonometric functions
--+-
Reporter:  daniel.is.fischer  |   Owner:  
Type:  bug|  Status:  new 
Priority:  normal |   Component:  Compiler
 Version:  6.8.1  |Severity:  normal  
Keywords: |Testcase:  
Architecture:  x86|  Os:  Linux   
--+-
 For large inputs, sin, cos and tan return the input value:
 {{{GHCi, version 6.8.1: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude> sin 1e20
 1.0e20
 Prelude> cos 1e20
 1.0e20
 Prelude> cos 1e19
 1.0e19
 Prelude> cos 1e18
 0.11965025504785125
 Prelude> tan 1e19
 1.0e19}}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1837: ghc-pkg should not accept unversioned depends

[Frederik Eaton]

On Sun, Jan 20, 2008 at 06:21:56PM +, Duncan Coutts wrote:
> 
> On Sun, 2008-01-20 at 17:37 +, Frederik Eaton wrote:
> > Hi Duncan,
> > 
> > Thanks, --gen-pkg-config works.
> > 
> > I don't know if Cabal will ever be suitable for me - I prefer to be
> > able to build specific targets, and to track dependencies to minimize
> > build time, and there is a tool for this called 'make' which is a lot
> > older, faster, and more stable which I prefer to use.
> 
> http://hackage.haskell.org/trac/hackage/ticket/15
> 
> Yes, make style dependency analysis and incremental builds is the next
> major feature we need for Cabal. Lots of other stuff that we want to do
> depends on that (like building specific targets with minimal and
> parallel rebuilds). It should also make it easier to integrate with
> other build systems by adding rules in Setup.hs.
> 
> > Cabal does thesethings well if one is not using too many derived
> > files, or too many languages other than Haskell, but those
> > restrictions aren't compatible with many of my projects (although for
> > some it is fine!).
> 
> So don't despair that it'll never work. Make sure your issues are
> recorded so we can see features we can pick off once we have dep
> tracking.

OK. Well, for me the best way to do dependency analysis would be to
allow users to specify a command which should be run on each source
file just *before* cabal/ghc checks its timestamp. In my case, this
command would be 'make'. So that way, if one source file is generated
from another, 'make' will bring it up to date, and cabal will see that
its timestamp has changed... (for efficiency, the command could be
given multiple file arguments at once). I've already suggested this
for ghc... It seems like it should be a simple change.

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

Re: [GHC] #1837: ghc-pkg should not accept unversioned depends

[Duncan Coutts]

On Sun, 2008-01-20 at 17:37 +, Frederik Eaton wrote:
> Hi Duncan,
> 
> Thanks, --gen-pkg-config works.
> 
> I don't know if Cabal will ever be suitable for me - I prefer to be
> able to build specific targets, and to track dependencies to minimize
> build time, and there is a tool for this called 'make' which is a lot
> older, faster, and more stable which I prefer to use.

http://hackage.haskell.org/trac/hackage/ticket/15

Yes, make style dependency analysis and incremental builds is the next
major feature we need for Cabal. Lots of other stuff that we want to do
depends on that (like building specific targets with minimal and
parallel rebuilds). It should also make it easier to integrate with
other build systems by adding rules in Setup.hs.

> Cabal does thesethings well if one is not using too many derived
> files, or too many languages other than Haskell, but those
> restrictions aren't compatible with many of my projects (although for
> some it is fine!).

So don't despair that it'll never work. Make sure your issues are
recorded so we can see features we can pick off once we have dep
tracking.

Duncan

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

Re: [GHC] #1837: ghc-pkg should not accept unversioned depends

[Frederik Eaton]

Hi Duncan,

Thanks, --gen-pkg-config works.

I don't know if Cabal will ever be suitable for me - I prefer to be
able to build specific targets, and to track dependencies to minimize
build time, and there is a tool for this called 'make' which is a lot
older, faster, and more stable which I prefer to use. Cabal does these
things well if one is not using too many derived files, or too many
languages other than Haskell, but those restrictions aren't compatible
with many of my projects (although for some it is fine!).

Best wishes,

Frederik

On Sun, Jan 20, 2008 at 05:06:10PM +, Duncan Coutts wrote:
> 
> On Sun, 2008-01-20 at 16:08 +, Frederik Eaton wrote:
> > Hello,
> > 
> > I can't use Cabal on some of my projects, for various reasons that
> > I've discussed here earlier... 
> 
> BTW, just so we do not loose track of those reasons could you double
> check that all the problems and limitations you reported are described
> accurately in the hackage trac. That'd be great.
> 
> http://hackage.haskell.org/trac/hackage/
> 
> In the cases where what you're trying to do does not quite chime with
> the way Cabal works now it's probably best to describe what you're
> actually trying to achieve as well as the immediate problem.
> 
> > However, I can have a cabal file to
> > describe the dependencies and so forth. Is there a way to generate a
> > proper package config using a cabal file? Or is there some other way
> > to do it so I get the right versions? I am now seeing the warning
> > message which was introduced by this bug fix, but don't know what to
> > do about it.
> 
> Yes, you can:
> 
> cabal configure
> cabal register --gen-pkg-config=foo.pkg
> ghc-pkg register foo.pkg
> 
> So that does depend on being able to configure the package successfully.
> 
> If you don't use cabal-install yet replace "cabal" with "runghc
> Setup.hs" in the above commands.
> 
> Duncan
> 

-- 
http://ofb.net/~frederik/
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1837: ghc-pkg should not accept unversioned depends

[Duncan Coutts]

On Sun, 2008-01-20 at 16:08 +, Frederik Eaton wrote:
> Hello,
> 
> I can't use Cabal on some of my projects, for various reasons that
> I've discussed here earlier... 

BTW, just so we do not loose track of those reasons could you double
check that all the problems and limitations you reported are described
accurately in the hackage trac. That'd be great.

http://hackage.haskell.org/trac/hackage/

In the cases where what you're trying to do does not quite chime with
the way Cabal works now it's probably best to describe what you're
actually trying to achieve as well as the immediate problem.

> However, I can have a cabal file to
> describe the dependencies and so forth. Is there a way to generate a
> proper package config using a cabal file? Or is there some other way
> to do it so I get the right versions? I am now seeing the warning
> message which was introduced by this bug fix, but don't know what to
> do about it.

Yes, you can:

cabal configure
cabal register --gen-pkg-config=foo.pkg
ghc-pkg register foo.pkg

So that does depend on being able to configure the package successfully.

If you don't use cabal-install yet replace "cabal" with "runghc
Setup.hs" in the above commands.

Duncan

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

Re: [GHC] #1599: testsuite timeout doesn't kill subprocesses on Windows

[GHC]

#1599: testsuite timeout doesn't kill subprocesses on Windows
+---
 Reporter:  simonmar|  Owner:  igloo 
 Type:  bug | Status:  closed
 Priority:  normal  |  Milestone:  6.8 branch
Component:  Test Suite  |Version:  6.6.1 
 Severity:  normal  | Resolution:  fixed 
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86   
   Os:  Windows |  
+---
Changes (by igloo):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 The timeout program in the testsuite now does this.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1837: ghc-pkg should not accept unversioned depends

[Frederik Eaton]

Hello,

I can't use Cabal on some of my projects, for various reasons that
I've discussed here earlier... However, I can have a cabal file to
describe the dependencies and so forth. Is there a way to generate a
proper package config using a cabal file? Or is there some other way
to do it so I get the right versions? I am now seeing the warning
message which was introduced by this bug fix, but don't know what to
do about it.

Thanks,

Frederik

On Tue, Nov 06, 2007 at 03:31:02PM -, GHC wrote:
> #1837: ghc-pkg should not accept unversioned depends
> -+--
> Reporter:  duncan|   Owner:  
> Type:  bug   |  Status:  new 
> Priority:  normal|   Milestone:  
>Component:  Build System  | Version:  6.8.1   
> Severity:  normal|Keywords:  
>   Difficulty:  Easy (1 hr)   |Testcase:  
> Architecture:  Multiple  |  Os:  Multiple
> -+--
>  Historically ghc-pkg accepted a format where the "depends:" field did not
>  require version numbers. Then ghc would just resolve it to some installed
>  version. However now that ghc bakes in the version number to libraries
>  when it compiles them it really crucial that a package gets linked with
>  exactly the versions of packages it was built against. Allowing ghc-pkg to
>  accept unversioned depends and resolving them to some random installed
>  version is just asking for trouble.
> 
>  It's not too serious since Cabal always uses versioned depends, however I
>  just noticed that older autoconf/automake build systems do not.
> 
>  So, in summary allowing undersioned depends is just asking for trouble and
>  ghc-pkg should reject them.
> 
> -- 
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler

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


-- 
http://ofb.net/~frederik/
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function

[GHC]

#1498: Optimisation: eliminate unnecessary heap check in recursive function
--+-
 Reporter:  simonmar  |  Owner:  
 Type:  task  | Status:  new 
 Priority:  normal|  Milestone:  6.10 branch 
Component:  Compiler  |Version:  6.6.1   
 Severity:  normal| Resolution:  
 Keywords:| Difficulty:  Moderate (1 day)
 Testcase:|   Architecture:  Unknown 
   Os:  Unknown   |  
--+-
Changes (by tibbe):

 * cc: [EMAIL PROTECTED] (added)

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build

[GHC]

#915: Implement list fusion using streams instead of foldr/build
+---
 Reporter:  simonpj |  Owner:
 Type:  task| Status:  new   
 Priority:  normal  |  Milestone:  6.10 branch   
Component:  libraries/base  |Version:  6.8   
 Severity:  normal  | Resolution:
 Keywords:  fusion  | Difficulty:  Project (> 1 week)
 Testcase:  N/A |   Architecture:  Multiple  
   Os:  Unknown |  
+---
Changes (by tibbe):

 * cc: [EMAIL PROTECTED] (added)

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #2058: Ghci tab-completion cannot handle Unicode

[GHC]

#2058: Ghci tab-completion cannot handle Unicode
-+--
Reporter:  desegnis  |   Owner:
Type:  bug   |  Status:  new   
Priority:  normal|   Component:  GHCi  
 Version:  6.9   |Severity:  normal
Keywords:|Testcase:
Architecture:  Unknown   |  Os:  Linux 
-+--
 Ghci on *nix is capable of handling input Unicode identifiers encoded as
 UTF-8:

 {{{
 Prelude> let ŝaŭmmanĝaĵo = "hmmm..."
 Prelude> let identifier_α = ()
 Prelude> let test_π = 1
 Prelude> let test_ρ = 2
 Prelude> ŝaŭmmanĝaĵo
 "hmmm..."
 }}}

 However, there is no working tab completion for those identifiers:

 {{{
 Prelude> ŝa-- Nothing happens
 Prelude> identifier_� -- Tab-completed garbage
 Prelude> test_   -- Unreadable alternatives
 }}}

 Since code input is interpreted as UTF-8, tab-completion output should be
 converted to UTF-8, too.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs