Re: [GHC] #967: Simplifier in HEAD is iterating too much
#967: Simplifier in HEAD is iterating too much
--+-
Reporter: simonmar | Owner: simonpj
Type: bug | Status: closed
Priority: normal| Milestone: 6.8.3
Component: Compiler |Version: 6.7
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase:| Architecture: Unknown
Os: Unknown |
--+-
Changes (by simonpj):
* status: new = closed
* resolution: = fixed
Comment:
This patch at least improves matters a lot
{{{
Mon Dec 3 07:00:39 PST 2007 [EMAIL PROTECTED]
* Improve eta reduction, to reduce Simplifier iterations
}}}
So I'm closing this bug fo rnow.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/967#comment:2
GHC http://www.haskell.org/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] #1048: Add forkIO that starts in 'block' mode
#1048: Add forkIO that starts in 'block' mode
-+--
Reporter: ChrisKuklewicz | Owner: simonmar
Type: feature request | Status: new
Priority: normal | Milestone: 6.10 branch
Component: libraries/base |Version: 6.6
Severity: normal | Resolution:
Keywords: concurrency | Difficulty: Easy (1 hr)
Testcase: | Architecture: Multiple
Os: Multiple |
-+--
Comment (by simonmar):
Partially done:
{{{
Tue Dec 4 03:09:47 PST 2007 Simon Marlow [EMAIL PROTECTED]
* forkIO starts the new thread blocked if the parent is blocked (#1048)
}}}
I needed to fix various Ctrl-C problems in 6.8.1, and this seemed the
least invasive way to do it.
forkOS is not done, so leaving the ticket open for now.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1048#comment:4
GHC http://www.haskell.org/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] #1583: GHCi + large Integer arithmetic + Ctrl-C = bad
#1583: GHCi + large Integer arithmetic + Ctrl-C = bad --+- Reporter: Isaac Dupree | Owner: simonmar Type: bug | Status: closed Priority: normal| Milestone: 6.8.3 Component: GHCi |Version: 6.6.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Architecture: Multiple Os: Linux | --+- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Fixed, I think. See also #1922 and #1946. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1583#comment:3 GHC http://www.haskell.org/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] #1947: Segmentation fault/access violation in generated code
#1947: Segmentation fault/access violation in generated code
--+-
Reporter: NeilMitchell | Owner: igloo
Type: merge | Status: new
Priority: normal| Milestone: 6.8.3
Component: Compiler |Version: 6.8.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: x86
Os: Windows |
--+-
Changes (by simonpj):
* owner: = igloo
* type: bug = merge
Comment:
Fixed, thank you.
{{{
Tue Dec 4 14:58:03 GMT 2007 [EMAIL PROTECTED]
* Make eta reduction check more carefully for bottoms (fix Trac #1947)
}}}
Ian: please merge. And could you make this program into a test? (Compile
with -O2 and run as above.) Thanks
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1947#comment:3
GHC http://www.haskell.org/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] #1547: Arity can decrease with -prof
#1547: Arity can decrease with -prof
---+
Reporter: igloo | Owner:
Type: bug| Status: new
Priority: high | Milestone: 6.10 branch
Component: Profiling |Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: stm package/tests/conc052 | Architecture: Unknown
Os: Unknown|
---+
Comment (by simonpj):
I had a half-done change in `SimplUtils` which I'm just going to dump here
for now. The actual code change (which I am not sure is right) is this:
{{{
hunk ./compiler/simplCore/SimplUtils.lhs 827
- any isRuntimeVar bndrs
+ any isRuntimeVar bndrs || not (exprIsTrivial body)
+ -- Note [RHS eta expansion]
}}}
and the note is this:
{{{
Note [RHS eta expansion]
The basic idea is to transform
f = \x1..xn - N == f = \x1..xn y1..ym - N y1..ym
(n = 0)
where (in both cases)
* The xi can include type variables
* The yi are all value variables
* N is a NORMAL FORM (i.e. no redexes anywhere)
wanting a suitable number of extra args.
This is OK even if n=0; for example:
let g=\xs. x:xs in (\ys. map g ys)
Here we can eta expand to
\ys. let g=\xs. x:xs in map g ys
You might think the f-binding woudl have floated, but it may not when
we are profiling:
f = scc foo (let g=\xs. x:xs in (\xs. map g ys))
Furthermore, f's arity might have been 1 before, if it originally looked
like
h g ys = map g ys
f = scc foo (h (\xs. x:xs))
and we do not expect like the arity to decrease so that it now looks
like zero (to the cheap-and-cheerful exprArity).
However, we must be careful not to undo the effect of eta-reduction, hence
the check for `(not (exprIsTrivial body))`.
}}}
I just want to capture the state of play because I can't finish this
today.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1547#comment:2
GHC http://www.haskell.org/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] #1110: Setting PATH needed in Windows Vista
#1110: Setting PATH needed in Windows Vista -+-- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.1 Component: Driver |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | -+-- Changes (by bchallenor): * status: closed = reopened * version: 6.6 = 6.8.1 * resolution: fixed = Comment: I'm seeing this bug in Vista using Version 6.8.1, for Haskell 98, stage 3 booted by GHC version 6.6. I try to compile a file generated using Alex that needs the preprocessor and get the following error: gcc: installation problem, cannot exec `cc1': No such file or directory. As suggested, adding gcc-lib to the Path fixes it, but that's a bad hack. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1110#comment:12 GHC http://www.haskell.org/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] #1110: Setting PATH needed in Windows Vista
#1110: Setting PATH needed in Windows Vista -+-- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.1 Component: Driver |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | -+-- Comment (by bchallenor): Sorry, I should have mentioned that this is on x86 (Intel). I hope this is a good place to file the bug. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1110#comment:13 GHC http://www.haskell.org/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] #1922: getChar + Ctrl-C on Windows in GHCi breaks
#1922: getChar + Ctrl-C on Windows in GHCi breaks
-+--
Reporter: guest| Owner: igloo
Type: merge| Status: new
Priority: normal | Milestone: 6.8.3
Component: GHCi |Version: 6.8.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Windows |
-+--
Changes (by simonmar):
* owner: simonmar = igloo
* type: bug = merge
Comment:
Ok, several issues here.
1) happens because when you hit `^C` in a console, Windows apprently
causes a blocked `read()` on `stdin` to return 0, which the runtime
interprets as EOF. I haven't done anything about this yet, it seems
fairly harmless.
2) is the same as (1), just that the real `^C` exception gets delivered
during the reporting of the EOF.
3) happens due to a race condition in GHCi, which I've fixed.
Interestingly, the fix required also fixing #1048 (make `forkIO` inherit
`block` from the parent).
4) happens due to another race condition, this time on the console
handler, which is a global pointer to a `StablePtr`. Under the right
(wrong?) conditions, someone could free the `StablePtr` before it was
dereferenced, leading to a crash. I've fixed this.
To merge, in GHC:
{{{
Tue Dec 4 03:09:47 PST 2007 Simon Marlow [EMAIL PROTECTED]
* forkIO starts the new thread blocked if the parent is blocked (#1048)
Tue Dec 4 03:44:44 PST 2007 Simon Marlow [EMAIL PROTECTED]
* fix race conditions in sandboxIO (#1583, #1922, #1946)
Tue Dec 4 07:39:18 PST 2007 Simon Marlow [EMAIL PROTECTED]
* protect console handler against concurrent access (#1922)
}}}
(note the first change needs documenting in the release notes, and I need
in `libraries/base`:
{{{
Tue Dec 4 03:08:17 PST 2007 Simon Marlow [EMAIL PROTECTED]
* protect against concurrent access to the signal handlers (#1922)
Tue Dec 4 07:39:40 PST 2007 Simon Marlow [EMAIL PROTECTED]
* protect console handler against concurrent access (#1922)
}}}
in `libraries/unix`:
{{{
Tue Dec 4 03:08:39 PST 2007 Simon Marlow [EMAIL PROTECTED]
* protect against concurrent access to the signal handlers (#1922)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1922#comment:3
GHC http://www.haskell.org/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] #1110: Setting PATH needed in Windows Vista
#1110: Setting PATH needed in Windows Vista -+-- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.1 Component: Driver |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | -+-- Comment (by simonmar): urgh, I think I know what the problem is. Can you confirm that using the `-cpp` option causes the failure? Try compiling a small source file with and without `-cpp`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1110#comment:14 GHC http://www.haskell.org/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] #1110: Setting PATH needed in Windows Vista
#1110: Setting PATH needed in Windows Vista -+-- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.3 Component: Driver |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | -+-- Changes (by simonmar): * milestone: 6.8.1 = 6.8.3 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1110#comment:15 GHC http://www.haskell.org/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] #1954: Incorrect Defined but not used warning when using GeneralizedNewtypeDeriving
#1954: Incorrect Defined but not used warning when using
GeneralizedNewtypeDeriving
-+--
Reporter: magnus| Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 6.8.1
Severity: normal|Keywords:
Difficulty: Unknown |Testcase:
Architecture: Unknown | Os: Unknown
-+--
When compiling
{{{
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -Wall -Werror #-}
module Bug(P, runP) where
import Control.Monad.Identity(Identity, runIdentity)
newtype P a = P { unP :: Identity a } deriving Monad
runP :: P a - a
runP = runIdentity . unP
}}}
I get
{{{
Bug.hs:7:14: Warning: Defined but not used: data constructor `P'
}}}
although the constructor is used in the derived Monad instance. This is
obviously not a show stopper, but it forces me to rewrite what to me looks
like an OK program if I want to stick to the given OPTIONS_GHC.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1954
GHC http://www.haskell.org/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] #1944: round function causes cblas NaNs
#1944: round function causes cblas NaNs
---+
Reporter: SevenThunders | Owner:
Type: bug| Status: new
Priority: normal | Milestone: 6.8.2
Component: Compiler |Version: 6.8.1
Severity: critical | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Windows|
---+
Comment (by SevenThunders):
Replying to [comment:2 igloo]:
I thought I had replied to this, but I will do so again.
Here is what I get using my binary atlas cblas
{{{
rounded base = 0
C[0] = -1.#IND
C[1] = 2
C[2] = 2
C[3] = -1.#IND
}}}
This is on my AMD athlon x2 processor running windows xp 64 (the library
is still 32 bit).
I get similar results running it on an Intel core duo processor with a
different atlas compiled blas.
Both blas's were compiled with threads turned on so in theory they are
multi-threaded if that makes any difference.
One question I have is does the code works correctly on your box if you
compile it using the older ghc, but with my supplied atlas.dll binary, say
ghc 6.6.1? On my box it runs just fine with the older ghc.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1944#comment:3
GHC http://www.haskell.org/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] #1956: panic on runhaskell Setup configure on base
#1956: panic on runhaskell Setup configure on base
-+--
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 6.8.1
Severity: normal|Keywords:
Difficulty: Unknown |Testcase:
Architecture: Unknown | Os: Windows
-+--
{{{
C:\Documents\Uni\contrib\basedarcs pull
Pulling from http://darcs.haskell.org/packages/base;...
No remote changes to pull in!
C:\Documents\Uni\contrib\baserunhaskell Setup configure
interactive:1:22:
attempting to use module `System.IO' (System/IO.hs) which is not
loaded
interactive:1:22: Not in scope: `System.IO.stderr'
interactive:1:22: Not in scope: `System.IO.stdin'
ghc.exe: panic! (the 'impossible' happened)
(GHC version 6.8.1 for i386-unknown-mingw32):
interactiveUI:setBuffering
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
Not sure what this should do, but it shouldn't panic.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1956
GHC http://www.haskell.org/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] #1957: Program that runs slower with optimizations on
#1957: Program that runs slower with optimizations on -+-- Reporter: clanehin | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 6.8.1 Severity: normal|Keywords: Difficulty: Unknown |Testcase: Architecture: x86 | Os: Linux -+-- This program runs significantly slower with optimization than without. I need two modules to manifest this bug. Is this a duplicate of 917/1945? Using -fno-full-laziness does not mitigate the problem. This seems to be the opposite of 1945. Without optimizations, there is a long delay and then all 10 results print at once. With optimizations, there is a shorter delay between each print statement. module Main (main) where import NaiveFib import Control.Monad main :: IO () main = replicateM_ 10 (printFib 37) module NaiveFib (printFib,naiveFib) where printFib :: Integer - IO () printFib = print . naiveFib naiveFib :: Integer - Integer naiveFib 0 = 0 naiveFib 1 = 1 naiveFib n = naiveFib (n-1) + naiveFib (n-2) [EMAIL PROTECTED]:~/test/optimizer-bug$ make main-O0 ghc-6.8.1 -O0 --make Main.hs -o main-O0 [1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking main-O0 ... [EMAIL PROTECTED]:~/test/optimizer-bug$ time ./main-O0 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 real0m34.491s user0m25.982s sys 0m0.564s [EMAIL PROTECTED]:~/test/optimizer-bug$ make main-O2 ghc-6.8.1 -O2 --make Main.hs -o main-O2 [1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking main-O2 ... [EMAIL PROTECTED]:~/test/optimizer-bug$ time ./main-O2 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 real1m50.331s user1m23.641s sys 0m1.008s -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1957 GHC http://www.haskell.org/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] #1957: Program that runs slower with optimizations on
#1957: Program that runs slower with optimizations on
--+-
Reporter: clanehin | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.8.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: x86
Os: Linux |
--+-
Comment (by clanehin):
Forgot to preview. Sorry.
{{{
[EMAIL PROTECTED]:~/test/optimizer-bug$ more Main.hs NaiveFib.hs
::
Main.hs
::
module Main
(main)
where
import NaiveFib
import Control.Monad
main :: IO ()
main = replicateM_ 10 (printFib 37)
::
NaiveFib.hs
::
module NaiveFib
(printFib,naiveFib)
where
printFib :: Integer - IO ()
printFib = print . naiveFib
naiveFib :: Integer - Integer
naiveFib 0 = 0
naiveFib 1 = 1
naiveFib n = naiveFib (n-1) + naiveFib (n-2)
[EMAIL PROTECTED]:~/test/optimizer-bug$ make main-O0
ghc-6.8.1 -O0 --make Main.hs -o main-O0
[1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking main-O0 ...
[EMAIL PROTECTED]:~/test/optimizer-bug$ time ./main-O0
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
real0m34.491s
user0m25.982s
sys 0m0.564s
[EMAIL PROTECTED]:~/test/optimizer-bug$ make clean
rm -f *.hi
rm -f *.o
rm -f main-O2
rm -f main-O0
[EMAIL PROTECTED]:~/test/optimizer-bug$ make main-O2
ghc-6.8.1 -O2 --make Main.hs -o main-O2
[1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking main-O2 ...
[EMAIL PROTECTED]:~/test/optimizer-bug$ time ./main-O2
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
real1m50.331s
user1m23.641s
sys 0m1.008s
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1957#comment:1
GHC http://www.haskell.org/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] #1957: Program that runs slower with optimizations on
#1957: Program that runs slower with optimizations on
--+-
Reporter: clanehin | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.8.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: x86
Os: Linux |
--+-
Comment (by dons):
Looks like the printFib is messing with the inlining:
Across 2 modules, -O2 and -O are 5x slower than -Onot.
In a single module, -O2 wins easily.
Something fishy going on.
Looking at the unfolding in the .hi file for NaiveFib.hs:
{{{
interface main:NaiveFib 3 608120071117 where
export main:NaiveFib naiveFib printFib
module dependencies:
package dependencies: base
orphans: base:GHC.Base
family instance modules:
3 printFib :: GHC.Num.Integer - GHC.IOBase.IO ()
{- Arity: 2 Strictness: LL
Unfolding: (NaiveFib.a
`cast`
(GHC.Num.Integer - sym ((GHC.IOBase.:CoIO) ( -}
3 naiveFib :: GHC.Num.Integer - GHC.Num.Integer
{- Arity: 1 HasNoCafRefs Strictness: S -}
3 a :: GHC.Num.Integer
- GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
{- Arity: 2 Strictness: LL
Unfolding: (\ x :: GHC.Num.Integer eta :: GHC.Prim.State#
GHC.Prim.RealWorld -
case @ (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
GHC.IO.a24
GHC.Handle.stdout
(GHC.Num.$wshowsPrec
0
(NaiveFib.naiveFib x)
(GHC.Base.[] @ GHC.Base.Char))
eta of wild { (# new_s, a59 #) -
GHC.IO.$wa9 GHC.Handle.stdout '\n' new_s }) -}
vectorised variables:
vectorised tycons:
vectorised reused tycons:
}}}
Looks like the print is mucking up the optimiser a bit?
Let's try moving the printFib line into Main.hs:
{{{
$ time ./Main-O2
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
./Main-O2 2.99s user 0.01s system 99% cpu 3.028 total
}}}
And, its fixed if we inline printFib too:
{{{
printFib = print . naiveFib
{-# INLINE printFib #-}
}}}
Simon, what's going on with the optimiser here?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1957#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
