[GHC] #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon"

2006-10-23 Thread GHC 
#959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon"
+---
Reporter:  igloo|   Owner: 
Type:  bug  |  Status:  new
Priority:  normal   |   Milestone:  6.6.1  
   Component:  Compiler (Type checker)  | Version:  6.6
Severity:  normal   |Keywords: 
  Difficulty:  Unknown  |Testcase: 
Architecture:  Unknown  |  Os:  Unknown
+---
With GHC 6.6, this module:
 {{{
 module G where

 testL = foo undefined

 class Foo t where
 foo :: m a -> t m a
 }}}
 leaks some debugging info(?):
 {{{
 Urk! Inventing strangely-kinded void TyCon:
 :t{tc ae2}
 (* -> *) -> * -> *

 tmp.hs:4:8:
 Ambiguous type variable `t' in the constraint:
   `Foo t' arising from use of `foo' at tmp.hs:4:8-20
 Possible cause: the monomorphism restriction applied to the following:
   testL :: forall (m :: * -> *) a. t m a (bound at tmp.hs:4:0)
 Probable fix: give these definition(s) an explicit type signature
   or use -fno-monomorphism-restriction
 }}}

 I haven't managed to get this message in an acceptable program.

 (found by fasta on IRC)

-- 
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] #958: deriving Show, impossible happened

2006-10-23 Thread GHC 
#958: deriving Show, impossible happened
--+-
Reporter:  [EMAIL PROTECTED]  |   Owner:   
Type:  bug|  Status:  new  
Priority:  normal |   Milestone:   
   Component:  GHCi   | Version:  6.6  
Severity:  normal |Keywords:   
  Difficulty:  Unknown|Testcase:   
Architecture:  x86|  Os:  Linux
--+-
Here's the program (note the missing "deriving Show" clause on the Succ
 data type)...

 {{{
 data Succ a = S a
 data Seq' a = Cons' a (Seq' (Succ a)) | Nil' deriving Show
 }}}
 ...and here's the error message for 'ghci -fglasgow-exts -fallow-
 undecidable-instances foo.hs'...

 {{{
___ ___ _
   / _ \ /\  /\/ __(_)
  / /_\// /_/ / /  | |  GHC Interactive, version 6.6, for Haskell 98.
 / /_\\/ __  / /___| |  http://www.haskell.org/ghc/
 \/\/ /_/\/|_|  Type :? for help.

 Loading package base ... linking ... done.
 ghc-6.6: panic! (the 'impossible' happened)
   (GHC version 6.6 for i386-unknown-linux):
 solveDerivEqns: probable loop
 (main:Main.$f1{v rLa} base:GHC.Show.Show{tc 2h} main:Main.Seq'{tc rFH}
 [a{tv aFR} [tv]] = [base:GHC.Show.Show{tc 2h} a{tv aFR} [tv],
 base:GHC.Show.Show{tc 2h} (main:Main.Seq'{tc rFH} (main:Main.Succ{tc rFN}
 a{tv aFR} [tv]))])
 [[base:GHC.Show.Show{tc 2h} a{tv aFR} [tv],
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} a{tv aFR} [tv]),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} a{tv aFR} [tv])),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} a{tv aFR} [tv]))),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} a{tv aFR} [tv],
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} a{tv aFR} [tv]),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} a{tv aFR} [tv])),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} a{tv aFR}
 [tv]))),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} a{tv aFR} [tv],
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} a{tv aFR} [tv]),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} a{tv aFR}
 [tv])),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} a{tv aFR} [tv]))),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} a{tv aFR} [tv],
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} a{tv aFR}
 [tv]),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc rFN} (main:Main.Succ{tc
 rFN} a{tv aFR} [tv])),
   base:GHC.Show.Show{tc 2h} (main:Main.Succ{tc r

Re: [GHC] #706: GHC uses _stub.c files regardless of whether any 'foreign import' decls remain in a .hs file

2006-10-23 Thread GHC 
#706: GHC uses _stub.c files regardless of whether any 'foreign import' decls
remain in a .hs file
--+-
 Reporter:  [EMAIL PROTECTED]  |  Owner:  igloo   
 Type:  bug   | Status:  new 
 Priority:  normal|  Milestone:  6.8 
Component:  Compiler (FFI)|Version:  6.4.1   
 Severity:  minor | Resolution:  
 Keywords:  ffi, link | Difficulty:  Moderate (1 day)
 Testcase:|   Architecture:  Multiple
   Os:  Multiple  |  
--+-
Changes (by [EMAIL PROTECTED]):

  * testcase:  =>
  * summary:  GHC links _stub.o files regardless of whether any 'foreign
  import' decls remain in a .hs file => GHC uses
  _stub.c files regardless of whether any
  'foreign import' decls remain in a .hs file

Comment:

 The description of the bug is incorrect. It picks up the _stub.c files,
 not the _stub.o files, and it picks them up even if the file is recompiled
 (and didn't re-generate the _stub.c file).

 Verified with GHC 6.6. not even -fforce-recomp works, only manually
 deleting the _stub.c files works around the problem.

 Problem with 6.6 is that it won't generate _stub.c files for modules where
 previous versions did (for modules that _use_ other modules which have the
 FFI that causes _stub.c files), so after upgrading you may encounter this
 problem.

-- 
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] #952: gcc should be passed the -fwrapv flag

2006-10-23 Thread GHC 
#952: gcc should be passed the -fwrapv flag
--+-
 Reporter:  simonmar  |  Owner:  
 Type:  bug   | Status:  reopened
 Priority:  normal|  Milestone:  6.6.1   
Component:  Compiler  |Version:  6.6 
 Severity:  normal| Resolution:  
 Keywords:| Difficulty:  Unknown 
 Testcase:|   Architecture:  Multiple
   Os:  Multiple  |  
--+-
-- 
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] #952: gcc should be passed the -fwrapv flag

2006-10-23 Thread GHC 
#952: gcc should be passed the -fwrapv flag
--+-
 Reporter:  simonmar  |  Owner:  
 Type:  bug   | Status:  reopened
 Priority:  normal|  Milestone:  6.6.1   
Component:  Compiler  |Version:  6.6 
 Severity:  normal| Resolution:  
 Keywords:| Difficulty:  Unknown 
 Testcase:|   Architecture:  Multiple
   Os:  Multiple  |  
--+-
Changes (by simonmar):

  * resolution:  fixed =>
  * summary:  Floating point exception building HEAD with 6.6 => gcc should
  be passed the -fwrapv flag
  * status:  closed => reopened

Comment:

 re-opening.  After giving this some more thought, I realised that the
 Haskell report's meaning of "undefined" is different from the C language
 specification's meaning of "undefined", and that in fact `ghc -fvia-C` is
 behaving incorrectly here.

 Overflow of `Int` should return either `_|_` or an implementation-defined
 value, according to the Haskell report.  In the code affected by this bug,
 we were returning an implementation-defined value (2's complement
 wrapping) but a subsequent test on the value was returning an inconsistent
 answer; this is allowed by the C spec, but not by Haskell.

 The upshot is that I believe we should invoke gcc with `-fwrapv` where it
 is supported (gcc 3.4+).  This is more than required: it forces 2's
 complement wrapping behviour, but prevents the illegal optimisations that
 give rise to this bug.

-- 
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: smart relinking bug

2006-10-23 Thread Simon Marlow 

Lemmih wrote:

On 10/21/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:


Hello Lemmih,

Saturday, October 21, 2006, 8:11:02 PM, you wrote:

>> gcc -c -o a.o a.c
>> ghc --make Main.hs a.o
>>
>> this command incorrectly don't relinks executable if a.c was changed
>> but Main.hs wasn't

> Did you mean a.o instead of a.c?

if a.c changes then first line will recompile it and change a.o too :)
for '--make' command a.o will be changed and main.hs remains old



Ah, I didn't read the two lines as a single command.

I think adding something like this to DriverPipeline should fix it:

   extra_ld_inputs <- readIORef v_Ld_inputs
   extra_times <- mapM (IO.try . getModificationTime) extra_ld_inputs)
   let linking_needed
   | Left _  <- e_exe_time = True
   | Right t <- e_exe_time =
   any (t <) (map linkableTime linkables) ||
   any (t <) [ t' | Right t' <- extra_times ]


Looks good - you can simplify with a ++ instead of the ||, though.

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

Re: [GHC] #957: Build failure in Cabal/cabal-setup: -lgmp doesn't honor LDFLAGS

2006-10-23 Thread GHC 
#957: Build failure in Cabal/cabal-setup: -lgmp doesn't honor LDFLAGS
--+-
 Reporter:  [EMAIL PROTECTED]  |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone: 
Component:  Build System  |Version:  6.6
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  FreeBSD   |  
--+-
Comment (by [EMAIL PROTECTED]):

 A brief update:  later on in the compilation, a similar error happened:

 {{{
 gmake -f Makefile.ghcbin -wr HS_PROG=stage2/ghc-6.6 stage2/ghc-6.6
 gmake[3]: Entering directory `/usr/home/tim/local/src/ghc-6.6/compiler'
 ../compiler/stage1/ghc-inplace -H16m -O -package ghc -Istage2 -cpp
 -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen
 -Iparser -Rghc-timing  -DGHCI -DBREAKPOINT -threaded-c main/Main.hs -o
 stage2/main/Main.o  -ohi stage2/main/Main.hi
 <>
 ../compiler/stage1/ghc-inplace -o stage2/ghc-6.6 -H16m -O -package ghc
 -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen
 -InativeGen -Iparser -Rghc-timing  -DGHCI -DBREAKPOINT -threaded
 stage2/main/Main.o
 /usr/bin/ld: cannot find -lgmp
 <>
 gmake[3]: *** [stage2/ghc-6.6] Error 1
 gmake[3]: Leaving directory `/usr/home/tim/local/src/ghc-6.6/compiler'
 gmake[2]: *** [stage2/ghc-6.6] Error 2
 gmake[2]: Leaving directory `/usr/home/tim/local/src/ghc-6.6/compiler'
 gmake[1]: *** [stage2] Error 2
 gmake[1]: Leaving directory `/usr/home/tim/local/src/ghc-6.6'
 gmake: *** [bootstrap2] Error 2
 }}}

 Again, I was able to continue the compilation after manually executing the
 failing command with an additional -L/usr/local/lib.

-- 
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] #606: Sparc native code generator

2006-10-23 Thread GHC 
#606: Sparc native code generator
--+-
 Reporter:  simonmar  |  Owner:
 Type:  task  | Status:  new   
 Priority:  normal|  Milestone:  _|_   
Component:  Compiler  |Version:  None  
 Severity:  normal| Resolution:  None  
 Keywords:| Difficulty:  Difficult (1 week)
 Testcase:  N/A   |   Architecture:  sparc 
   Os:  Unknown   |  
--+-
Changes (by simonmar):

  * architecture:  Unknown => sparc

Comment:

 Lack of access to machines is not the limiting factor, unfortunately.  In
 fact, I have access to a Sparc machine (at Berlin) on which I debugged the
 threaded RTS problems recently.

-- 
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] #957: Build failure in Cabal/cabal-setup: -lgmp doesn't honor LDFLAGS

2006-10-23 Thread GHC 
#957: Build failure in Cabal/cabal-setup: -lgmp doesn't honor LDFLAGS
-+--
Reporter:  [EMAIL PROTECTED]  |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone: 
   Component:  Build System  | Version:  6.6
Severity:  normal|Keywords: 
  Difficulty:  Unknown   |Testcase: 
Architecture:  x86   |  Os:  FreeBSD
-+--
When building ghc-6.6 from source on FreeBSD 6, I get this error:

 {{{
 == gmake all - --no-print-directory -r;
  in /usr/home/tim/local/src/ghc-6.6/libraries/Cabal/cabal-setup
 
 ../../../compiler/ghc-inplace -o cabal-setup -H16m -O -package Cabal
 CabalSetup.o
 /usr/bin/ld: cannot find -lgmp
 gmake[3]: *** [cabal-setup] Error 1
 gmake[2]: *** [all] Error 1
 gmake[1]: *** [all] Error 1
 gmake[1]: Leaving directory `/usr/home/tim/local/src/ghc-6.6/libraries'
 gmake: *** [stage1] Error 2
 1:12 ~/local/src/ghc-6.6$ cd libraries/Cabal/cabal-setup
 2:01 ~/local/src/ghc-6.6/libraries/Cabal/cabal-setup$ ../../../compiler
 /ghc-inplace -o cabal-setup -H16m -O -package Cabal CabalSetup.o
 -L/usr/local/lib
 2:02 ~/local/src/ghc-6.6/libraries/Cabal/cabal-setup$ cd -
 ~/local/src/ghc-6.6
 2:02 ~/local/src/ghc-6.6$ gmake
 gmake -C utils/mkdependC boot
 gmake[1]: Entering directory
 `/usr/home/tim/local/src/ghc-6.6/utils/mkdependC'
 gmake[1]: Leaving directory
 `/usr/home/tim/local/src/ghc-6.6/utils/mkdependC'
 }}}

 I configured with:

 {{{
 export CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
 ./configure --prefix=$HOME/local
 }}}

 My system has /usr/local/lib/libgmp.so; /usr/local/lib is, on FreeBSD,
 traditionally not in the default search path.  It must be specified
 explicitly to the linker.


 Once I compiled cabal-setup by hand, adding -L/usr/local/lib (as shown
 above), the rest of the build completed normally.

 I'm reporting this against ghc 6.6, but I noticed it on 6.4.2 as well.

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