Re: [GHC] #822: -keep-tmp-files does not keep all temporary files

[GHC]

#822: -keep-tmp-files does not keep all temporary files
--+-
  Reporter:  [EMAIL PROTECTED]  |  Owner:
  Type:  bug  | Status:  new   
  Priority:  normal   |  Milestone:
 Component:  Driver   |Version:  6.4.2 
  Severity:  minor| Resolution:
  Keywords:   | Os:  Linux 
Difficulty:  Unknown  |   Architecture:  x86_64 (amd64)
--+-
Comment (by [EMAIL PROTECTED]):

 This is with lhs2TeX 1.11

-- 
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: incoherent instance selection when it should be still coherent

[Ralf Lammel]

What I really find odd about it is that GHC has a notion of coherences
that it tries to adhere to (and this is great), unless you ask it to
violate coherence. However this specific situation is the only case that
I am aware of where GHC is even incoherent when not positively
instructed to may be so ...

Is there some well-argued example where someone would explain why this
could be at all useful?

Thanks,
Ralf

> -Original Message-
> From: Simon Peyton-Jones
> Sent: Tuesday, July 25, 2006 5:45 AM
> To: Ralf Lammel; glasgow-haskell-bugs@haskell.org
> Subject: RE: incoherent instance selection when it should be still
> coherent
> 
> It's clear that the type checker cannot do better, because in
>   uuh (Wrap x) (Wrap y) = bar x y
> the call to 'bar' can use *only* evidence stored in the Wrap
constructor.
> Previously GHC gave an error message at this point, but some
collection of
> users persuaded me that the behaviour below is the "right" one.  As
you
> say, it's not altogether clear!
> 
> Simon
> 
> | -Original Message-
> | From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-
> [EMAIL PROTECTED]
> | On Behalf Of Ralf Lammel
> | Sent: 24 July 2006 09:53
> | To: glasgow-haskell-bugs@haskell.org
> | Subject: FW: incoherent instance selection when it should be still
> coherent
> |
> | Repro contained in forwarded email.
> |
> | Here is a bit more reasoning. I guess *always* selecting the generic
> | instance is really incoherent, and then best called a bug. Since
more
> | specific instance selection does not make sense w/o violating the
> | contract of existential types, I also feel like concluding that the
> | program must not typecheck in the first place. I do agree that
> | "-fallow-incoherent-instances" could admit this program, if the
option
> | was chosen (even though I generally fail to understand the use of
this
> | option anyway :-).
> |
> | Thanks,
> | Ralf
> |
> | -Original Message-
> | From: Ralf Lammel
> | Sent: Friday, July 21, 2006 5:37 PM
> | To: 'haskell-cafe@haskell.org'
> | Subject: incoherent instance selection when it should be still
coherent
> |
> | The following pain is sort of ghc (6.4.2) specific.
> | (The same behavior is achievable with hugs -98 +O which is Ok in so
far
> | that +O (as opposed to +o) is not strongly supposed to be coherent.)
> |
> | Note the following GHC options preceding the code.
> | They do not contain -fallow-incoherent-instances.
> |
> | -
> |
> | {-# OPTIONS -fglasgow-exts #-}
> |
> | {-# OPTIONS -fallow-undecidable-instances #-}
> |
> | {-# OPTIONS -fallow-overlapping-instances #-}
> |
> |
> | -- A single parameter class with two silly instances
> |
> | class Foo x where foo :: x -> (); foo = const ()
> |
> | instance Foo ()
> |
> | instance Foo Bool
> |
> |
> | -- A two-parameter class with a generic and a non-generic instance
> |
> | class (Foo x, Foo y) => Bar x y where bar :: x -> y -> String
> |
> | instance (Foo x, Foo y) => Bar x y where bar _ _ = "generic
instance"
> |
> | instance Foo z => Bar () z where bar _ _ = "non-generic instance"
> |
> |
> | -- An existential wrapper around foos
> |
> | data Wrap = forall x. Foo x => Wrap x
> |
> |
> | -- A wrapper-based variation on the type-class member bar
> |
> | uuh :: Wrap -> Wrap -> String
> |
> | uuh (Wrap x) (Wrap y) = bar x y
> |
> |
> | -- Let's try all unwrapped and wrapped combinations of bar and uuh
> |
> | t1 = ()
> |
> | t2 = True
> |
> | w1 = Wrap t1
> |
> | w2 = Wrap t2
> |
> | main = do
> |   print $ bar t1 t1
> |   print $ uuh w1 w1 -- uuh!
> |   print $ bar t1 t2
> |   print $ uuh w1 w2 -- uuh!
> |   print $ bar t2 t1
> |   print $ uuh w2 w1
> |   print $ bar t2 t2
> |   print $ uuh w2 w2
> |
> | 
> |
> | We get:
> |
> | {-
> |
> | "non-generic instance"
> | "generic instance"
> | "non-generic instance"
> | "generic instance"
> | "generic instance"
> | "generic instance"
> | "generic instance"
> | "generic instance"
> |
> | -}
> |
> | This means that the generic instance is consistently chosen by uuh.
> | This is clearly incoherent.
> | I would also complain that uuh type-checks in the first place.
> | Opinions?
> |
> | Regards,
> | Ralf
> |
> | ___
> | Glasgow-haskell-bugs mailing list
> | Glasgow-haskell-bugs@haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

RE: incoherent instance selection when it should be still coherent

[Simon Peyton-Jones]

It's clear that the type checker cannot do better, because in 
uuh (Wrap x) (Wrap y) = bar x y
the call to 'bar' can use *only* evidence stored in the Wrap
constructor.   Previously GHC gave an error message at this point, but
some collection of users persuaded me that the behaviour below is the
"right" one.  As you say, it's not altogether clear!

Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
| On Behalf Of Ralf Lammel
| Sent: 24 July 2006 09:53
| To: glasgow-haskell-bugs@haskell.org
| Subject: FW: incoherent instance selection when it should be still
coherent
| 
| Repro contained in forwarded email.
| 
| Here is a bit more reasoning. I guess *always* selecting the generic
| instance is really incoherent, and then best called a bug. Since more
| specific instance selection does not make sense w/o violating the
| contract of existential types, I also feel like concluding that the
| program must not typecheck in the first place. I do agree that
| "-fallow-incoherent-instances" could admit this program, if the option
| was chosen (even though I generally fail to understand the use of this
| option anyway :-).
| 
| Thanks,
| Ralf
| 
| -Original Message-
| From: Ralf Lammel
| Sent: Friday, July 21, 2006 5:37 PM
| To: 'haskell-cafe@haskell.org'
| Subject: incoherent instance selection when it should be still
coherent
| 
| The following pain is sort of ghc (6.4.2) specific.
| (The same behavior is achievable with hugs -98 +O which is Ok in so
far
| that +O (as opposed to +o) is not strongly supposed to be coherent.)
| 
| Note the following GHC options preceding the code.
| They do not contain -fallow-incoherent-instances.
| 
| -
| 
| {-# OPTIONS -fglasgow-exts #-}
| 
| {-# OPTIONS -fallow-undecidable-instances #-}
| 
| {-# OPTIONS -fallow-overlapping-instances #-}
| 
| 
| -- A single parameter class with two silly instances
| 
| class Foo x where foo :: x -> (); foo = const ()
| 
| instance Foo ()
| 
| instance Foo Bool
| 
| 
| -- A two-parameter class with a generic and a non-generic instance
| 
| class (Foo x, Foo y) => Bar x y where bar :: x -> y -> String
| 
| instance (Foo x, Foo y) => Bar x y where bar _ _ = "generic instance"
| 
| instance Foo z => Bar () z where bar _ _ = "non-generic instance"
| 
| 
| -- An existential wrapper around foos
| 
| data Wrap = forall x. Foo x => Wrap x
| 
| 
| -- A wrapper-based variation on the type-class member bar
| 
| uuh :: Wrap -> Wrap -> String
| 
| uuh (Wrap x) (Wrap y) = bar x y
| 
| 
| -- Let's try all unwrapped and wrapped combinations of bar and uuh
| 
| t1 = ()
| 
| t2 = True
| 
| w1 = Wrap t1
| 
| w2 = Wrap t2
| 
| main = do
|   print $ bar t1 t1
|   print $ uuh w1 w1 -- uuh!
|   print $ bar t1 t2
|   print $ uuh w1 w2 -- uuh!
|   print $ bar t2 t1
|   print $ uuh w2 w1
|   print $ bar t2 t2
|   print $ uuh w2 w2
| 
| 
| 
| We get:
| 
| {-
| 
| "non-generic instance"
| "generic instance"
| "non-generic instance"
| "generic instance"
| "generic instance"
| "generic instance"
| "generic instance"
| "generic instance"
| 
| -}
| 
| This means that the generic instance is consistently chosen by uuh.
| This is clearly incoherent.
| I would also complain that uuh type-checks in the first place.
| Opinions?
| 
| Regards,
| Ralf
| 
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #834: bogus gcc option used when compiling ghc-6.4.2

[GHC]

#834: bogus gcc option used when compiling ghc-6.4.2
-+--
  Reporter:  [EMAIL PROTECTED]  |  Owner: 
  Type:  bug | Status:  closed 
  Priority:  normal  |  Milestone: 
 Component:  Compiler|Version:  6.4.2  
  Severity:  trivial | Resolution:  invalid
  Keywords:  | Os:  Linux  
Difficulty:  Easy (1 hr) |   Architecture:  x86
-+--
Changes (by [EMAIL PROTECTED]):

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

Comment:

 This bug is only occurs on Gentoo because of options used in older
 versions of Gentoo's ghc-bin ebuild.

 See Gentoo bug [http://bugs.gentoo.org/show_bug.cgi?id=129891#c2 #129891].

 It is for reasons like this that we recommend Gentoo users to report bugs
 in Gentoo's bugzilla before bothering upstream developers. :-)

 The real cause of this bug is that supporting a wide range of versions of
 gcc is rather tricky. We had tried to support the 'hardened' gcc versions.
 'Hardened' gcc automatically builds with -pie -fstack-protector but these
 options cause gcc to produce output that ghc does not understand (ie it
 breaks every via-C compile). So we tried using -nopie and -fno-stack-
 protector. This made everything work for vanilla gcc-3.x and hardened
 gcc-3.x. Then it turned out that gcc-4.x didn't support the same options.
 So we made the ebuild only add the options if they were supported. Sadly
 that did not work for the -nopie option since gcc doesn't reject it with
 an non-zero return code, it just prints a warning. This has subsequently
 been fixed but it explains why you get the warnings - because the version
 of the ghc ebuild you started with had that issue when used with gcc-4.x.

 So the solution is to do just what you have done, to rebuild ghc using the
 latest version of the ebuild. The version you build should not have the
 problem when building anything else.

 So I'm closing this bug as invalid, because it's not an upstream 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