Re: [GHC] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
-+--
 Reporter:  nimnul   |  Owner: 
 Type:  feature request  | Status:  closed 
 Priority:  normal   |  Milestone: 
Component:  Compiler |Version:  6.8.3  
 Severity:  normal   | Resolution:  invalid
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  x86
   Os:  Windows  |  
-+--
Comment (by nimnul):

 Replying to [comment:7 dons]:
 > Ah, much clearer.
 >
 > So what we have is not a bug, but rather a feature request: you would
 like the strictness analyser extended in some way such that foldl is
 always equivalent to foldl'.

 No no. foldl and foldl' are different functions. While foldl performs
 extra graph node allocations, compared to foldl', when op is strict,
 foldl' performs extra reductions if op is not strict. For tight loops like
 this foldl' is better than foldl. But if op is not strict and a lot of
 computations can be saved by not evaluating certain intermediate r, foldl
 can be better. Am I wrong?

 I don't want foldl to be always equivalent to foldl'. I only want them to
 be equivalent if op is strict in r.

 The problem is complex - while foldA and foldB differ only by a strictness
 annotation, the reason why compiler fails to insert the annotation may be
 not related to the strictness analyzer at all. It can be specializer
 failure (does ghc has one?), inliner failure, missing rewrite rules in the
 optimizer, anything.

 And it is not necessary to fix the problem by fixing optimizer - a
 workaround could be provided so one can use pragmas to achieve the result.

 Now INLINE pragma doesn't work because foldA is recursive, and that's ok,
 but the SPECIALIZE pragma is somewhat limited and can be improved - for
 example, I cannot tell the compiler to specialize foldA by inlining its
 first argument. Such specialization is not my invention - it has been used
 for years in C++ to avoid indirect calls when a function object is passed
 to a template function. And modern c++ compilers such as Microsoft's and
 GCC can even instantiate functions accepting function pointers.

 While automated instantiation and inlining is cumbersome to implement, and
 both inlining/specializing everything and inlining/specializing nothing
 can lead to poor performance, a developer should be able to hint - such
 tuning may be beneficial for libraries. And better "self-optimizing"
 libraries like Stream Fusion make life better for library users like me,
 as high-performance libraries reduce the need for performance profiling
 and optimizations in client code.

 So there can be very different ways to improve compilation of code
 fragments like foldA. And it's not just a narrow problem of programmers
 trying to reimplement foldl - I believe there are other scenarios when
 recursive definitions fail to optimize because they cannot be inlined.

 I cannot suggest exactly what the problem is, and how is better to fix it
 - I have a faint idea what happens inside of GHC optimizer. I'm merely
 reporting code which is problematic for current optimizer.

-- 
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] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
-+--
 Reporter:  nimnul   |  Owner: 
 Type:  feature request  | Status:  closed 
 Priority:  normal   |  Milestone: 
Component:  Compiler |Version:  6.8.3  
 Severity:  normal   | Resolution:  invalid
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  x86
   Os:  Windows  |  
-+--
Comment (by igloo):

 Replying to [comment:6 nimnul]:
 > Replying to [comment:4 dons]:
 > > nimul, this might explain the behaviour you see:
 > >
 > > {{{
 > > -- We write foldl as a non-recursive thing, so that it
 > > -- can be inlined, (skipped)
 > }}}
 >
 > foldC is recursive, but is optimized correctly. So recursion in foldA is
 not an argument.

 Right, the strictness analyser understand recursion, that's not the
 problem.

 Let me try and explain the differences. With `foldl`:
 {{{
 foldl:: (a -> b -> a) -> a -> [b] -> a
 foldl f z0 xs0 = lgo z0 xs0
  where
 lgo z [] =  z
 lgo z (x:xs) = lgo (f z x) xs
 }}}
 if you have a use
 {{{
 main = print $ foldl (+) 0 l
 }}}
 then GHC inlines the definition of `foldl` where it is used. The `(+)` is
 then inlined for `f` in this copy of `foldl`, the strictness analyser can
 tell that it is strict, and you get the behaviour that you want.

 If you use `foldA` instead:
 {{{
 foldA :: (a -> e -> a) -> a -> [e] -> a
 foldA _  r []  = r
 foldA op r (x:xs) = foldA op (op r x) xs
 }}}
 then the definition won't be inlined, because GHC deliberately doesn't
 inline recursive definitions. Instead, you get a call to the generic
 `foldA` code, which can't assume that `op` is strict in its first
 argument, so you get the large thunk built.

 If you use `foldC`:
 {{{
 foldC r [] = r
 foldC r (x:xs) = foldC ((+) r x) xs
 }}}
 then the strictness analyser can again see that the function you are using
 (`(+)`) is strict and so you get the behaviour that you want. (actually,
 this is only because you end up with a version specialised for `Int`; if
 you define foldC in a different module then I suspect you'll get a large
 thunk built again).

 > Is there any reason why my case is not a failing simple test case for
 GHC optimizer, and thus cannot be accepted as an enhancement request? The
 current behaviour (not inlining op) and the desired behaviour (to inline
 op if it's known to be strict and then proceed with already implemented
 optimizations) are clear.

 You could certainly make changes to the optimiser that make this case
 better, but there would be other cases that those changes would make
 worse.

 This (`foldl (+)`) is a well-known example, and I don't think that having
 this ticket open would be useful. I'm sure that if Simon disagrees then he
 well re-open it.

-- 
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] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
-+--
 Reporter:  nimnul   |  Owner: 
 Type:  feature request  | Status:  closed 
 Priority:  normal   |  Milestone: 
Component:  Compiler |Version:  6.8.3  
 Severity:  normal   | Resolution:  invalid
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  x86
   Os:  Windows  |  
-+--
Changes (by dons):

  * type:  run-time performance bug => feature request

Comment:

 Ah, much clearer.

 So what we have is not a bug, but rather a feature request: you would like
 the strictness analyser extended in some way such that foldl is always
 equivalent to foldl'.

-- 
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] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
--+-
 Reporter:  nimnul|  Owner: 
 Type:  run-time performance bug  | Status:  closed 
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.8.3  
 Severity:  normal| Resolution:  invalid
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Windows   |  
--+-
Comment (by nimnul):

 Replying to [comment:4 dons]:
 > nimul, this might explain the behaviour you see:
 >
 > {{{
 > -- We write foldl as a non-recursive thing, so that it
 > -- can be inlined, (skipped)
 }}}

 foldC is recursive, but is optimized correctly. So recursion in foldA is
 not an argument.

 > If I remember correctly from the discussion with nimul in #haskell, his
 view was that the strictness analyser wasn't sufficiently powerful: it
 doesn't do magic.

 No optimizer does magic. But optimizers do evolve, and new versions of say
 gcc perform more and more optimizations. GCC team at least accepts cases
 when GCC optimizer fails to produce optimal code as enhancement requests.
 You can find a lot of such requests in the  GCC bug tracker, for example,
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364.

 Is there any reason why GHC team don't follow them and don't accept such
 requests?

 Is there any reason why my case is not a failing simple test case for GHC
 optimizer, and thus cannot be accepted as an enhancement request? The
 current behaviour (not inlining op) and the desired behaviour (to inline
 op if it's known to be strict and then proceed with already implemented
 optimizations) are clear.

-- 
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] #2764: gen_contents_index generates links with package.haddock in the path

[GHC]

#2764: gen_contents_index generates links with package.haddock in the path
-+--
Reporter:  juhpetersen   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Component:  Documentation   
 Version:  6.10.1|Severity:  normal  
Keywords:|Testcase:  
Architecture:  Unknown/Multiple  |  Os:  Unknown/Multiple
-+--
 If one runs gen_contents_index in libraries/ it generates broken links to
 the documentation for packages.

 I will attach a simple patch to fix 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] #1872: Extensible Records

[GHC]

#1872: Extensible Records
---+
Reporter:  gidyn   |Owner:  
Type:  feature request |   Status:  new 
Priority:  normal  |Milestone:  6.10 branch 
   Component:  Compiler|  Version:  6.11
Severity:  normal  |   Resolution:  
Keywords:  Extensible Records  | Testcase:  
Architecture:  Unknown/Multiple|   Os:  Unknown/Multiple
---+
Changes (by guest):

  * version:  => 6.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

[GHC] #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2

[GHC]

#2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2
-+--
Reporter:  guest |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Component:  Compiler
 Version:  6.8.2 |Severity:  normal  
Keywords:  cabal ghc ubuntu  |Testcase:  
Architecture:  x86_64 (amd64)|  Os:  Linux   
-+--
 I can't build cabal 1.4.0.2, cabal from darcs and cabal 1.6.0.1

 Running ubuntu 8.04, running ghc that comes with it

 [EMAIL PROTECTED]:~/projects/haskell/Cabal-1.4.0.2# ghc -v
 Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by
 GHC version 6.8.2
 Using package config file: /usr/lib/ghc-6.8.2/package.conf
 Using package config file: /home/abez/.ghc/x86_64-linux-6.8.2/package.conf
 hiding package mtl-1.1.0.0 to avoid conflict with later version
 mtl-1.1.0.1
 wired-in package base mapped to base-3.0.1.0
 wired-in package rts mapped to rts-1.0
 wired-in package haskell98 mapped to haskell98-1.0.1.0
 wired-in package template-haskell mapped to template-haskell-2.2.0.0
 wired-in package ndp not found.
 Hsc static flags: -static
 *** Deleting temp files:
 Deleting:
 *** Deleting temp dirs:
 Deleting:
 ghc-6.8.2: no input files
 Usage: For basic information, try the `--help' option.
 [EMAIL PROTECTED]:~/projects/haskell/Cabal-1.4.0.2# ghc -v
 Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by
 GHC version 6.8.2
 Using package config file: /usr/lib/ghc-6.8.2/package.conf
 Using package config file: /home/abez/.ghc/x86_64-linux-6.8.2/package.conf
 hiding package mtl-1.1.0.0 to avoid conflict with later version
 mtl-1.1.0.1
 wired-in package base mapped to base-3.0.1.0
 wired-in package rts mapped to rts-1.0
 wired-in package haskell98 mapped to haskell98-1.0.1.0
 wired-in package template-haskell mapped to template-haskell-2.2.0.0
 wired-in package ndp not found.
 Hsc static flags: -static
 *** Deleting temp files:
 Deleting:
 *** Deleting temp dirs:
 Deleting:
 ghc-6.8.2: no input files
 Usage: For basic information, try the `--help' option.
 [EMAIL PROTECTED]:~/projects/haskell/Cabal-1.4.0.2# uname -a
 Linux burn 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64
 GNU/Linux



 [EMAIL PROTECTED]:~/projects/haskell/Cabal-1.4.0.2# ./Setup build
 Preprocessing library Cabal-1.4.0.2...
 Building Cabal-1.4.0.2...
 [13 of 45] Compiling Distribution.Simple.Utils (
 Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o )
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for x86_64-unknown-linux):
 applyTypeToArgs
 unix-2.3.0.0:System.Posix.Signals.a38{v rBu} [gid]
   (unix-2.3.0.0:System.Posix.Signals.a5{v rBt} [gid]
`cast` (base:GHC.Prim.sym{(w) tc 34v}
  (base:Foreign.C.Types.:CoCInt{tc ryy})
:: base:GHC.Int.Int32{tc 3V}
   ~
 base:Foreign.C.Types.CInt{tc rz9}))
   unix-2.3.0.0:System.Posix.Signals.Ignore{v rBs} [gid]
   (base:Data.Maybe.Nothing{v r6a} [gid]
  @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr})
   eta{v a2Rl} [lid]
 (# base:GHC.Prim.State#{(w) tc 32q}
  base:GHC.Prim.RealWorld{(w) tc 31E},
unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr} #)

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


 Another one:
 @burn:~/projects/haskell/cabal$ ./Setup build
 Preprocessing library Cabal-1.6.0.1...
 Building Cabal-1.6.0.1...
 [ 1 of 50] Compiling Distribution.Simple.GHC.Makefile (
 Distribution/Simple/GHC/Makefile.hs,
 dist/build/Distribution/Simple/GHC/Makefile.o )
 [ 2 of 50] Compiling Distribution.Compat.Permissions (
 Distribution/Compat/Permissions.hs,
 dist/build/Distribution/Compat/Permissions.o )
 [ 3 of 50] Compiling Distribution.Compat.Exception (
 Distribution/Compat/Exception.hs,
 dist/build/Distribution/Compat/Exception.o )
 [ 4 of 50] Compiling Distribution.Compat.TempFile (
 Distribution/Compat/TempFile.hs, dist/build/Distribution/Compat/TempFile.o
 )
 [ 5 of 50] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs,
 dist/build/Distribution/GetOpt.o )
 [ 6 of 50] Compiling Distribution.Compat.ReadP (
 Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o )
 [ 7 of 50] Compiling Distribution.Text ( Distribution/Text.hs,
 dist/build/Distribution/Text.o )
 [ 8 of 50] Compiling Distribution.Version ( Distribution/Version.hs,
 dist/build/Distribution/Version.o )
 [ 9 of 50] Compiling Language.Haskell.Extension (
 Language/Haskell/Extension.hs, dist/build/Language/Haskell/Extension.o )
 [10 of 50] Compiling Distribution.System ( Distribution/System.hs,
 dist/build/Distribution/System.o )
 [11 of 50] Compiling Distribution.Simple.PreProcess.Unlit (
 Distributi

Re: [GHC] #2761: type checker bug

[GHC]

#2761: type checker bug
-+--
 Reporter:  guest|  Owner:  
 Type:  bug  | Status:  closed  
 Priority:  normal   |  Milestone:  
Component:  Compiler (Type checker)  |Version:  6.8.3   
 Severity:  normal   | Resolution:  invalid 
 Keywords:   | Difficulty:  Unknown 
 Testcase:   |   Architecture:  Unknown/Multiple
   Os:  Unknown/Multiple |  
-+--
Changes (by sclv):

 * cc: sclv (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] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows

[GHC]

#2189: hSetBuffering stdin NoBuffering doesn't work on Windows
+---
 Reporter:  FalconNL|  Owner: 
 Type:  bug | Status:  new
 Priority:  high|  Milestone:  6.10.2 
Component:  libraries/base  |Version:  6.8.2  
 Severity:  normal  | Resolution: 
 Keywords:  hsetbuffering buffering buffer  | Difficulty:  Unknown
 Testcase:  |   Architecture:  x86
   Os:  Windows |  
+---
Changes (by Deewiant):

 * cc: Deewiant (added)
  * summary:  hSetBuffer stdin NoBuffering doesn't seem to work in ghc
  6.8.2 on Windows XP => hSetBuffering stdin
  NoBuffering doesn't work on Windows

Comment:

 Unfortunately conio doesn't mix with ordinary IO, as I demonstrated in a
 response to that thread on glasgow-haskell-users.

 As for the original problem, I think this'd take some work to solve: GHC
 would have to convert to the Win32 API for all of its IO on Windows.
 (That'd also help with #806.)

 What currently happens is the following call chain, starting from
 `hGetChar` (a bit of documentation for any would-be fixers):
 {{{
 System.IO.hGetChar stdin

 -- meanings of numbers: stdin FD, not a socket, offset 0, length 1
 GHC.Handle.readRawBuffer "hGetChar" 0 0  0 1

 GHC.Handle.asyncReadRawBuffer 0 0  0 1

 GHC.Conc.asyncReadBA 0 0 1 0 

 -- offset got applied
 GHC.Conc.asyncRead 0 0 1 

 -- asyncReadzh_fast in rts/PrimOps.cmm
 asyncRead# 0 0 1 

 -- in rts/win32/AsyncIO.c
 -- the new 0 signifies that this is a read and not a write
 addIORequest(0, 0, 0, 1, )
 }}}
 From there it ends up into the asynchronous IO work queue, whence it
 eventually gets picked up by `IOWorkerProc` (in rts/win32/IOManager.c). It
 notices that the `workKind` is `WORKER_READ` but not `WORKER_FOR_SOCKET`,
 so it does a plain `read()` call.

 In the current situation that's basically fine, since the `hSetBuffering`
 never did anything and we're still in line buffered mode. In unbuffered
 mode, that'd be a problem, as the comment from System.Posix.Internals
 (which judah posted above) asserts: enter needs to be pressed twice. The
 fact that it gives '\r' instead of '\n' isn't such a big problem since it
 can be easily modified.

 I'm attaching a C program which shows how the problem is avoided by using
 the Win32 API directly (in this case, `ReadFile` is fine) instead of the
 POSIX `read`: the latter requires two presses of enter, the former only
 one.

 Since there seems to be no way of getting a Win32 `HANDLE` object from a C
 `FILE*` let alone a POSIX file descriptor, I believe that the only
 reasonable way of getting this and #806 to work reliably is to convert the
 whole IO subsystem to use the Windows API directly—starting from changing
 `GHC.IOBase.Handle__.haFD` from an `FD` to a `HANDLE` on Windows.

-- 
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] #2761: type checker bug

[GHC]

#2761: type checker bug
-+--
 Reporter:  guest|  Owner:  
 Type:  bug  | Status:  closed  
 Priority:  normal   |  Milestone:  
Component:  Compiler (Type checker)  |Version:  6.8.3   
 Severity:  normal   | Resolution:  invalid 
 Keywords:   | Difficulty:  Unknown 
 Testcase:   |   Architecture:  Unknown/Multiple
   Os:  Unknown/Multiple |  
-+--
Changes (by igloo):

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

Comment:

 Thanks for the report! However, the types are not equivalent, e.g. this
 fails to typecheck:
 {{{
 foo :: forall b. (b -> String, Int)
 foo = undefined

 x :: (String, String)
 x = case foo of
 (f, _) -> (f 'a', f True)
 }}}
 with:
 {{{
 Couldn't match expected type `Char' against inferred type `Bool'
 In the first argument of `f', namely `True'
 In the expression: f True
 In the expression: (f 'a', f True)
 }}}
 but this does typecheck:
 {{{
 bar :: (forall b. b -> String, Int)
 bar = undefined

 x :: (String, String)
 x = case bar of
 (f, _) -> (f 'a', f True)
 }}}
 (with `-XImpredicativeTypes -XRank2Types`)

-- 
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] #2761: type checker bug

[GHC]

#2761: type checker bug
-+--
 Reporter:  guest|  Owner:  
 Type:  bug  | Status:  new 
 Priority:  normal   |  Milestone:  
Component:  Compiler (Type checker)  |Version:  6.8.3   
 Severity:  normal   | Resolution:  
 Keywords:   | Difficulty:  Unknown 
 Testcase:   |   Architecture:  Unknown/Multiple
   Os:  Unknown/Multiple |  
-+--
Changes (by igloo):

  * difficulty:  => Unknown

Old description:

> This causes a type error:
>
> foo :: forall b. (b -> String, Int)
> foo = (const "hi", 0)
>
> bar :: (forall b. b -> String, Int)
> bar = foo
>
> This should compile fine since the types are equivalent.

New description:

 This causes a type error:
 {{{
 foo :: forall b. (b -> String, Int)
 foo = (const "hi", 0)

 bar :: (forall b. b -> String, Int)
 bar = foo
 }}}
 This should compile fine since the types are equivalent.

-- 
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] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
--+-
 Reporter:  nimnul|  Owner: 
 Type:  run-time performance bug  | Status:  closed 
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.8.3  
 Severity:  normal| Resolution:  invalid
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Windows   |  
--+-
Changes (by igloo):

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

Comment:

 Right, `foldA` is only strict in `r` if `op` is strict in its first
 argument. Depending on how you write `foldA`, and what other optimisations
 (such as inlining) happen, GHC might be able to tell that `op` is indeed
 strict in its first argument, but otherwise it must assume that it is not.

-- 
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] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
--+-
 Reporter:  nimnul|  Owner: 
 Type:  run-time performance bug  | Status:  new
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.8.3  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Windows   |  
--+-
Comment (by dons):

 nimul, this might explain the behaviour you see:

 {{{
 -- We write foldl as a non-recursive thing, so that it
 -- can be inlined, and then (often) strictness-analysed,
 -- and hence the classic space leak on foldl (+) 0 xs

 foldl:: (a -> b -> a) -> a -> [b] -> a
 foldl f z0 xs0 = lgo z0 xs0
  where
 lgo z [] =  z
 lgo z (x:xs) = lgo (f z x) xs

 }}}

 If I remember correctly from the discussion with nimul in #haskell, his
 view was that the strictness analyser wasn't sufficiently powerful: it
 doesn't do magic.

-- 
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] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP

[GHC]

#2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows
XP
+---
 Reporter:  FalconNL|  Owner: 
 Type:  bug | Status:  new
 Priority:  high|  Milestone:  6.10.2 
Component:  libraries/base  |Version:  6.8.2  
 Severity:  normal  | Resolution: 
 Keywords:  hsetbuffering buffering buffer  | Difficulty:  Unknown
 Testcase:  |   Architecture:  x86
   Os:  Windows |  
+---
Comment (by camio):

 Alistar Bayley noted this workaround in haskell-cafe
 {{{
 {-# LANGUAGE ForeignFunctionInterface #-}
 import Data.Char
 import Control.Monad (liftM)
 import Foreign.C.Types

 getHiddenChar = liftM (chr.fromEnum) c_getch
 foreign import ccall unsafe "conio.h getch"
   c_getch :: IO CInt
 }}}

-- 
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] #2762: Excessive heap usage

[GHC]

#2762: Excessive heap usage
-+--
Reporter:  igloo |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  6.10.2  
   Component:  Compiler  | Version:  6.11
Severity:  normal|Keywords:  
  Difficulty:  Unknown   |Testcase:  
Architecture:  Unknown/Multiple  |  Os:  Unknown/Multiple
-+--
 With `Main.hs`:
 {{{
 module Main (main) where

 import InputOutput

 main :: IO ()
 main = do
   let content1 = concat (replicate 100 "1x") ++ "0"
   let i1 = fst $ input content1
   view i1

   let content2 = concat (replicate 101 "1y") ++ "0"
   let i2 = fst $ input content2
   view i2

 view :: [Char] -> IO ()
 view [] = return ()
 view (i : is) = i `seq` view is
 }}}
 and `InputOutput.hs`:
 {{{
 module InputOutput (input) where

 class InputOutput a where
 input :: String -> (a, String)

 instance InputOutput Char where
 input (x : bs) = (x, bs)

 instance InputOutput a => InputOutput [a] where
 input ('0':bs) = ([], bs)
 input ('1':bs) = case input bs of
  (x, bs') ->
  case input bs' of
  ~(xs, bs'') -> (x : xs, bs'')
 }}}
 according to
 {{{
 ghc -O -prof -auto-all --make Main.hs -fforce-recomp
 ./Main +RTS -h
 }}}
 heap usage goes up to about 20M with the HEAD, but only about 200 bytes
 with 6.8.2.

 This is with 6.11.20081108, but I started investigating with the HEAD when
 I saw similar problems with more-or-less 6.10.1.

-- 
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] #2761: type checker bug

[GHC]

#2761: type checker bug
+---
Reporter:  guest|Owner:  
Type:  bug  |   Status:  new 
Priority:  normal   |Milestone:  
   Component:  Compiler (Type checker)  |  Version:  6.8.3   
Severity:  normal   |   Resolution:  
Keywords:   | Testcase:  
Architecture:  Unknown/Multiple |   Os:  Unknown/Multiple
+---
Comment (by guest):

 Sorry about bad formatting before...

 This produces a type error:

 {{{
 foo :: forall b. (b -> String, Int)
 foo = (const "hi", 0)

 bar :: (forall b. b -> String, Int)
 bar = foo
 }}}

 But the types are equivalent.

-- 
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] #2761: type checker bug

[GHC]

#2761: type checker bug
-+--
Reporter:  guest |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Component:  Compiler (Type checker)
 Version:  6.8.3 |Severity:  normal 
Keywords:|Testcase: 
Architecture:  Unknown/Multiple  |  Os:  Unknown/Multiple   
-+--
 This causes a type error:

 foo :: forall b. (b -> String, Int)
 foo = (const "hi", 0)

 bar :: (forall b. b -> String, Int)
 bar = foo

 This should compile fine since the types are equivalent.

-- 
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] #2760: Data.Generics.Basics.mkNoreptype spelled wrong

[GHC]

#2760: Data.Generics.Basics.mkNoreptype spelled wrong
-+--
Reporter:  guest |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Component:  Compiler
 Version:  6.10.1|Severity:  minor   
Keywords:|Testcase:  
Architecture:  Unknown/Multiple  |  Os:  Unknown/Multiple
-+--
 To be consistent with the constructor name NoRep this function should be
 mkNoRepType.

-- 
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] #2759: Data.Generics.ConstrRep isn't general enough

[GHC]

#2759: Data.Generics.ConstrRep isn't general enough
-+--
Reporter:  guest |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Component:  Compiler
 Version:  6.10.1|Severity:  minor   
Keywords:|Testcase:  
Architecture:  Unknown/Multiple  |  Os:  Unknown/Multiple
-+--
 The type ConstrRep in Data.Generics is used to represent constructors for
 types.
 The FloatConstr constructor is the one used for all kinds of floating
 point primitives.
 But FloatConstr has an argument of type Double.  This limits the primitive
 floating point types to those that are accurately representable as a
 Double.
 In other places in Haskell where an accurate and generic floating point
 value is needed the type Rational is used.  It should be used here 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

Re: [GHC] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
--+-
 Reporter:  nimnul|  Owner: 
 Type:  run-time performance bug  | Status:  new
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.8.3  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Windows   |  
--+-
Comment (by nimnul):

 You just replace foldl with foldA and foldB. The test code fragments are
 {{{ main = print $ foldA (+) 0 l }}} and {{{ main = print $ foldB (+) 0 l
 }}}

 First of all, {{{foldl}}} works - it takes my pc about a second to
 calculate the correct answer - {{{987459712}}}, without excessive heap or
 stack usage.

 While {{{foldA}}} is semantically equivalent to {{{foldl}}}, it has
 different spatial complexity than current implementation of {{{foldl}}} in
 {{{Prelude}}} - I get heap overflow with such a big list {{{l}}}.

 The bug is that ghc generates inefficient code for a naive implementation
 of {{{foldl}}}.

 This behavior is strange, because in similar cases the optimizer works
 perfectly. Even if you just "inline {{{op}}}", I mean substitute {{{op}}}
 for its value {{{(+)}}}, memory is not eaten up any more:
 {{{
 foldC r [] = r
 foldC r (x:xs) = foldC ((+) r x) xs
 }}}

-- 
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] #2756: state hack causes unneeded value to be evaluated

[GHC]

#2756: state hack causes unneeded value to be evaluated
--+-
 Reporter:  int-e |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Milestone:  6.10.2  
Component:  Compiler  |Version:  6.10.1  
 Severity:  normal| Resolution:  
 Keywords:| Difficulty:  Unknown 
 Testcase:|   Architecture:  Unknown/Multiple
   Os:  Unknown/Multiple  |  
--+-
Changes (by simonmar):

  * difficulty:  => Unknown
  * milestone:  => 6.10.2

Comment:

 Good bug.  I don't think this is caused by `-fno-state-hack`.  The code
 coming out of the simplifier is fine; this is `newX`:

 {{{
 a_rus =
   \ (n_afy :: ()) (eta_ssU :: GHC.Prim.State# GHC.Prim.RealWorld) ->
 (# eta_ssU,
Main.X
  (let {
 value_sub [NEVER Just S] :: ()
 [Str: DmdType]
 value_sub = n_afy } in
   value_sub) #)
 }}}

 The prep phase lifts out that `let`, but doesn't reset its strictness
 annotation, which changes the meaning of the program:

 {{{
 a_rus =
   \ (n_suA :: ()) (eta_suy :: GHC.Prim.State# GHC.Prim.RealWorld) ->
 let {
   sat_suE :: Main.X
   []
   sat_suE =
 case n_suA of value_suC [NEVER Just S] { __DEFAULT ->
 Main.X value_suC
 } } in
 (# eta_suy, sat_suE #)
 }}}

-- 
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] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0

[GHC]

#2753: GHC 6.10.1 cannot compile Crypto-4.1.0
--+-
 Reporter:  thoughtpolice |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Milestone:  6.10.2  
Component:  Compiler  |Version:  6.10.1  
 Severity:  critical  | Resolution:  
 Keywords:| Difficulty:  Unknown 
 Testcase:|   Architecture:  Unknown/Multiple
   Os:  Unknown/Multiple  |  
--+-
Changes (by simonmar):

  * difficulty:  => Unknown
  * os:  MacOS X => Unknown/Multiple
  * milestone:  => 6.10.2

Comment:

 I don't think it was ever fixed, it may have just stopped happening for a
 while for unrelated reasons.

 The problem is that the spill code in the linear register allocator is
 pretty stupid and doesn't try to re-use spill slots.  Also, we only have a
 fixed number of spill slots, because we have a fixed-size frame on the C
 stack in which to spill into, which is currently 2048 words.  We could
 certainly bump the size of this without any serious adverse effects
 (`includes/Constants.h`, `RESERVED_C_STACK_BYTES`).  I suggest that as a
 workaround for 6.10.2.

-- 
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] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
--+-
 Reporter:  nimnul|  Owner: 
 Type:  run-time performance bug  | Status:  new
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.8.3  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Windows   |  
--+-
Comment (by simonmar):

 Could you be more clear about what behaviour you claim is wrong here?  The
 example code doesn't use `foldA` or `foldB`.  `foldA` is just `foldl`,
 which has well-known performance issues, and `foldB` is the same as
 `foldl'`, available from the `Data.List` module.

-- 
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] #2754: Strictness analyzer fails on an implementation of foldl

[GHC]

#2754: Strictness analyzer fails on an implementation of foldl
--+-
 Reporter:  nimnul|  Owner: 
 Type:  run-time performance bug  | Status:  new
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.8.3  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Windows   |  
--+-
Changes (by simonmar):

  * difficulty:  => Unknown

Old description:

> foldB has O(1) complexity, but foldA O(N). Looks like a strictness
> analyzer failure.
>
> module Main where
>
> foldA :: (a -> e -> a) -> a -> [e] -> a
> foldA _  r []  = r
> foldA op r (x:xs) = foldA op (op r x) xs
>
> foldB :: (a -> e -> a) -> a -> [e] -> a
> foldB _  r []  = r
> foldB op r (x:xs) = r' `seq` foldB op r' xs where r' = op r x
>
> l :: [Int]
> l = [1..100*1000*1000]
>
> main = print $ foldl (+) 0 l

New description:

 foldB has O(1) complexity, but foldA O(N). Looks like a strictness
 analyzer failure.

 {{{
 module Main where

 foldA :: (a -> e -> a) -> a -> [e] -> a
 foldA _  r []  = r
 foldA op r (x:xs) = foldA op (op r x) xs

 foldB :: (a -> e -> a) -> a -> [e] -> a
 foldB _  r []  = r
 foldB op r (x:xs) = r' `seq` foldB op r' xs where r' = op r x

 l :: [Int]
 l = [1..100*1000*1000]

 main = print $ foldl (+) 0 l
 }}}

-- 
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] #2752: Parse error in STM.c

[GHC]

#2752: Parse error in STM.c
--+-
 Reporter:  jputcu|  Owner:  simonmar
 Type:  bug   | Status:  new 
 Priority:  normal|  Milestone:  6.10.2  
Component:  Build System  |Version:  6.10.1  
 Severity:  blocker   | Resolution:  
 Keywords:| Difficulty:  Unknown 
 Testcase:|   Architecture:  x86 
   Os:  Linux |  
--+-
Changes (by simonmar):

  * owner:  => simonmar
  * difficulty:  => Unknown
  * milestone:  => 6.10.2

Comment:

 Thanks for the report.  I see what the bug is, so I can fix that, but
 unfortunately I don't have a way to test with gcc 2.95 here.  If you can
 test the patch, that would be most helpful - I wouldn't be surprised if
 there are other problems to be found.

 {{{
 diff -rN -u old-ghc-testing/rts/STM.c new-ghc-testing/rts/STM.c
 --- old-ghc-testing/rts/STM.c   2008-11-10 10:33:06.0 +
 +++ new-ghc-testing/rts/STM.c   2008-11-10 10:33:07.0 +
 @@ -388,8 +388,8 @@

  static void unpark_waiters_on(Capability *cap, StgTVar *s) {
StgTVarWatchQueue *q;
 -  TRACE("unpark_waiters_on tvar=%p", s);
StgTVarWatchQueue *trail;
 +  TRACE("unpark_waiters_on tvar=%p", s);
// unblock TSOs in reverse order, to be a bit fairer (#2319)
for (q = s -> first_watch_queue_entry, trail = q;
 q != END_STM_WATCH_QUEUE;
 }}}

-- 
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] #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04.

[GHC]

#2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04.
-+--
 Reporter:  guest|  Owner: 
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone: 
Component:  Build System |Version:  6.10.1 
 Severity:  normal   | Resolution: 
 Keywords:  build enable-shared  | Difficulty:  Unknown
 Testcase:   |   Architecture:  x86
   Os:  Linux|  
-+--
Comment (by ttmrichter):

 It may be best, then, to remove the option from the build scripts until it
 is supported, or at least to document somewhere prominent (like in
 ./configure --help) that this is not yet fully supported, etc.

-- 
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] #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04.

[GHC]

#2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04.
-+--
 Reporter:  guest|  Owner: 
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone: 
Component:  Build System |Version:  6.10.1 
 Severity:  normal   | Resolution: 
 Keywords:  build enable-shared  | Difficulty:  Unknown
 Testcase:   |   Architecture:  x86
   Os:  Linux|  
-+--
Changes (by simonmar):

 * cc: clemens (added)
  * difficulty:  => Unknown

Comment:

 Note `--enable-shared` is not fully supported yet - see #1876.  There are
 probably patches in HEAD that fix this bug.  I think we should probably
 close it, but I'll leave the decision to Clemens who is working on the
 shared lib support at the moment.

-- 
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] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3)

[GHC]

#2743: GHC 6.10.1 Win32 release is unusable (on XP SP3)
--+-
 Reporter:  guest |  Owner:  simonmar
 Type:  bug   | Status:  new 
 Priority:  normal|  Milestone:  6.10.2  
Component:  Compiler  |Version:  6.10.1  
 Severity:  blocker   | Resolution:  
 Keywords:| Difficulty:  Unknown 
 Testcase:|   Architecture:  x86 
   Os:  Windows   |  
--+-
Changes (by simonmar):

  * owner:  => simonmar
  * difficulty:  => Unknown
  * milestone:  => 6.10.2

Comment:

 I'll validate and commit, thanks.  The runghc bugs have been separately
 ticketed as #2757 and #2758.

-- 
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] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed

[GHC]

#2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed
-+--
Reporter:  simonmar  |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  6.10.2  
   Component:  Compiler  | Version:  6.8.3   
Severity:  normal|Keywords:  
  Difficulty:  Unknown   |Testcase:  
Architecture:  Unknown/Multiple  |  Os:  Unknown/Multiple
-+--
 Moved from #2743.

-- 
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] #2757: runghc doesn't respond to --help

[GHC]

#2757: runghc doesn't respond to --help
-+--
Reporter:  simonmar  |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  6.10.2  
   Component:  Compiler  | Version:  6.8.3   
Severity:  normal|Keywords:  
  Difficulty:  Easy (1 hr)   |Testcase:  
Architecture:  Unknown/Multiple  |  Os:  Unknown/Multiple
-+--
 Should be an easy one.  (moved from #2743)

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