date:20090420

[GHC] #3181: Regression in unboxing

2009-04-20 Thread GHC

#3181: Regression in unboxing
-+--
Reporter:  dolio |  Owner:
Type:  run-time performance bug  | Status:  new   
Priority:  normal|  Component:  Compiler  
 Version:  6.10.2|   Severity:  normal
Keywords:  unboxing boxing   |   Testcase:
  Os:  Linux |   Architecture:  x86_64 (amd64)
-+--
 Greetings,

 Finally having added some benchmarking to my uvector-algorithms package, I
 came across a regression in performance in the heap sort implementation.
 With 6.10.2, it did significantly more allocation than I'd remembered, and
 looking at the core, I spotted a boxed type that I have since determined
 to be the culprit. I'll attach the relevant portion of the algorithm as a
 test case (I apologize that it's rather large, but I haven't yet figured
 out how to make a smaller example that works).

 The key lines are:

 {{{
 do (child' :*: ac) <- maximumChild cmp a off child len
case cmp val ac of
  LT -> writeMU a (root + off) ac >> sift val child' len
  _  -> writeMU a (root + off) val
 }}}

 The monadic (ST) pattern match against the strict pair gets compiled to a
 function that accepts the arguments of the pair (as well as the ST state
 parameter) like so:

 {{{
 $w$j_s118 :: State# RealWorld
  -> Int
  -> Int#
  -> (# State# RealWorld, () #)
 [Arity 3

 $w$j_s118 =
   \ (w_s108 :: State# RealWorld)
 (ww_s10b :: Int)
 (ww1_s10e :: Int#) ->
 case <# sc3_s11t ww1_s10e of wild11_aY2 {
   False ->
 case writeIntArray#
@ RealWorld
marr#_aVT
(+# sc2_s11s 40)
sc3_s11t
w_s108
 of s2#1_aX6 { __DEFAULT ->
 (# s2#1_aX6, () #)
 };
   True ->
 case writeIntArray#
@ RealWorld
marr#_aVT
(+# sc2_s11s 40)
ww1_s10e
w_s108
 of s2#1_aX6 { __DEFAULT ->
 case ww_s10b of w1_X10F { I# ww2_X11k ->
 $s$wa_s11D s2#1_aX6 sc1_s11r ww2_X11k sc3_s11t
 }
 }
 }
 }}}

 As can be seen, all that is done with the boxed Int is that it is taken
 apart in one branch (this identifies the boxed argument as the `child'`
 variable, the `Int` being returned by `maximumChild`; I verified this by
 modifying the code to use a custom type:

 {{{
 data IP e = IP {-# UNPACK #-} !Int !e
 }}}

 this results in the desired unboxing behavior). Further, all calls to this
 function look like:

 {{{
 $w$j_s118 s2#3_XZ1 (I# x_aTU) r#_aXD
 }}}

 So this seems to be unnecessary boxing. Further, I have reports that 6.8.2
 *did* spot this unboxing opportunity, which would explain why my algorithm
 wasn't performing as well as I had remembered, since the last time I'd
 seriously inspected the performance was in the 6.8 series.

 One theory I had was that the fact that the value was only used in one
 branch of the case was causing it to look non-strict somehow, despite the
 pair being strict in its fields (perhaps the pair was eliminated before
 strictness analysis was done?). However, I've added bang patterns to the
 `child'` match, and changed the case statement to:

 {{{
 case child' `seq` cmp val ac of ...
 }}}

 without it making a difference. So I am a bit stumped as to why exactly
 GHC isn't eliminating this box.

 As noted, I can get the desired unboxing with a custom unpacked type, but
 fixing the regression would be preferable. Thanks for your time and help!

-- 
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] #3175: hpc should not mark otherwise as "always true"

2009-04-20 Thread GHC

#3175: hpc should not mark otherwise as "always true"
--+-
 Reporter:  ezyang|  Owner:  a...@galois.com 
 Type:  bug   | Status:  closed  
 Priority:  normal|  Milestone:  
Component:  Code Coverage |Version:  6.8.2   
 Severity:  normal| Resolution:  wontfix 
 Keywords:|   Testcase:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
--+-
Changes (by AndyGill):

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

Comment:

 This was a design choice, not a 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: [GHC] #3180: TcTyFuns.flattenType: unexpected PredType

2009-04-20 Thread GHC

#3180: TcTyFuns.flattenType: unexpected PredType
--+-
 Reporter:  guest |  Owner:  
 Type:  bug   | Status:  closed  
 Priority:  normal|  Milestone:  
Component:  Compiler  |Version:  6.10.1  
 Severity:  normal| Resolution:  duplicate   
 Keywords:|   Testcase:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
--+-
Changes (by chak):

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

Comment:

 You didn't provide any code for us to reproduce the bug.  I'll assume that
 this is a duplicate of #3125, which has already been fixed in the
 development version.  I'll close the bug for now.  If you re-run you
 example with the current development version and still find an issue,
 please re-open the ticket.

-- 
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] #3180: TcTyFuns.flattenType: unexpected PredType

2009-04-20 Thread GHC

#3180: TcTyFuns.flattenType: unexpected PredType
--+-
 Reporter:  guest |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Milestone:  
Component:  Compiler  |Version:  6.10.1  
 Severity:  normal| Resolution:  
 Keywords:|   Testcase:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
--+-
Comment (by guest):

 Oops, let's try that again.

 {{{
 lguapo:inez cmoore$ ghci
 GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
 Loading package ghc-prim ... linking ... done.
 Loading package integer ... linking ... done.
 Loading package base ... linking ... done.
 Prelude> :m +NLP.WordNet
 Prelude NLP.WordNet> runWordNet
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.10.1 for i386-apple-darwin):
 TcTyFuns.flattenType: unexpected PredType

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

 Prelude NLP.WordNet>
 }}}

-- 
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] #3180: TcTyFuns.flattenType: unexpected PredType

2009-04-20 Thread GHC

#3180: TcTyFuns.flattenType: unexpected PredType
-+--
Reporter:  guest |  Owner:  
Type:  bug   | Status:  new 
Priority:  normal|  Component:  Compiler
 Version:  6.10.1|   Severity:  normal  
Keywords:|   Testcase:  
  Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
-+--
 lguapo:inez cmoore$ ghci
 GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
 Loading package ghc-prim ... linking ... done.
 Loading package integer ... linking ... done.
 Loading package base ... linking ... done.
 Prelude> :m +NLP.WordNet
 Prelude NLP.WordNet> runWordNet
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.10.1 for i386-apple-darwin):
 TcTyFuns.flattenType: unexpected PredType

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

 Prelude NLP.WordNet>

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

testing 6.10.2 on X_64

2009-04-20 Thread Serge D. Mechveliani

Dear GHC team,

I am trying  ghc-6.10.2  оn a 64-bit matchine:

 [mech...@node-1 t]$ uname -a
 Linux node-1.localdomain 2.6.18-hpc-alt1.M41.1.mm1 #1 SMP 
 Mon Dec 8 14:58:04 MSK 2008 x86_64 GNU/Linux
 ,
 16 Gb RAM machine,  Intel(R) Xeon(R) CPU  E5472, 3 GHz.


First we have installed there  ghc-6.8.3  (from Linux distribution).

Then, I `made'  ghc-6.10.2  from source by  ghc-6.8.3: 

   ./configure --prefix=/home/mechvel/ghc/6.10.2/inst0
   make 
   make install

Everything looks all right.
Then, I try processing long lists:

  -- Test64.hs 
  main = putStr (shows res "\n")
   where
   e = 30
   list  = [1 .. (2^e)]  :: [Integer]
   rList = reverse list
   res   = myMin $ zipWith (\ n m -> rem (n+m) 3) list rList

  myMin [] = error "\nmyMin []\n"
  myMin [x]= x
  myMin (x: y: xs) = if  x > y  then  myMin (y: xs)  else  myMin (x: xs)
  ---

For  e = 20,  it runs as

  [mech...@node-1 t]$ ./Test64
  2

-- all right.

For  e = 30,  it runs as

  [mech...@node-1 t]$ ./Test64  
  Killed

Who has killed it? Is this by the local administrator's restriction ? 
Another attempt:

  [mech...@node-1 t]$ ./Test64 +RTS -M4000m -RTS

  Test64: internal error: get_threaded_info
(GHC version 6.10.2 for x86_64_unknown_linux)
Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
  Aborted

Qestion aside
-
List.minimum  again, performs badly in  ghc-6.10.2,  so I used  myMin.
Is  List.minimum (and similar functions)  being compiled by default 
with -O0 ?

Regards,

-
Serge Mechveliani
mech...@botik.ru



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

Re: [GHC] #3162: Windows users can't compile time package

2009-04-20 Thread GHC

#3162: Windows users can't compile time package
-+--
Reporter:  NeilMitchell  |Owner:  
Type:  bug   |   Status:  closed  
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.10.2  
Severity:  normal|   Resolution:  invalid 
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Comment (by simonmar):

 Maybe we could make an MSI of the time package using Sigbjorn's new tool?

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

glasgow-haskell-bugs@haskell.org

2009-04-20 Thread GHC

#2152: bogus inlining of foreign import "foo.h &foo"
-+--
Reporter:  simonmar  |Owner:  simonpj 
Type:  bug   |   Status:  closed  
Priority:  normal|Milestone:  6.10.1  
   Component:  Compiler  |  Version:  6.8.2   
Severity:  normal|   Resolution:  fixed   
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  6.12 branch => 6.10.1

Comment:

 This was fixed in 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] #912: Build system is missing various dependencies

2009-04-20 Thread GHC

#912: Build system is missing various dependencies
-+--
Reporter:  simonmar  |Owner:  
Type:  bug   |   Status:  new 
Priority:  high  |Milestone:  6.12.1  
   Component:  Build System  |  Version:  6.5 
Severity:  normal|   Resolution:  
Keywords:|   Difficulty:  Unknown 
Testcase:  N/A   |   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

  * priority:  low => high
  * milestone:  _|_ => 6.12.1

Comment:

 I believe most, if not all, of these issues are fixed in the new build
 system.

-- 
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] #2107: "make install" doesn't install local copy of manual

2009-04-20 Thread GHC

#2107: "make install" doesn't install local copy of manual
-+--
Reporter:  tim   |Owner:  
Type:  feature request   |   Status:  new 
Priority:  high  |Milestone:  6.12.1  
   Component:  Build System  |  Version:  6.9 
Severity:  minor |   Resolution:  
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

  * priority:  normal => high

Comment:

 The new build system 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] #1886: GHC API should preserve and provide access to comments

2009-04-20 Thread GHC

#1886: GHC API should preserve and provide access to comments
--+-
Reporter:  claus  |
Owner:  
Type:  bug|   
Status:  closed  
Priority:  normal |
Milestone:  6.12 branch 
   Component:  GHC API|  
Version:  6.9 
Severity:  normal |   
Resolution:  fixed   
Keywords:  GHC API, comments, program transformation, layout  |   
Difficulty:  Unknown 
Testcase: |   
Os:  Unknown/Multiple
Architecture:  Unknown/Multiple   |  
--+-
Changes (by simonmar):

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

Comment:

 We now have

 {{{
 getRichTokenStream :: GhcMonad m => Module -> m [(Located Token, String)]
 showRichTokenStream :: [(Located Token, String)] -> String
 }}}

 amongst other thing, thanks to Jedai.  If this isn't enough, please re-
 open.

-- 
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] #3167: Segmentation fault with compacting GC, and multiple threads

2009-04-20 Thread GHC

#3167: Segmentation fault with compacting GC, and multiple threads
-+--
Reporter:  guest |Owner:  
Type:  bug   |   Status:  closed  
Priority:  normal|Milestone:  
   Component:  Runtime System|  Version:  6.8.2   
Severity:  major |   Resolution:  fixed   
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

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

Comment:

 We fixed some serious parallel execution bugs since 6.8.2.  Please re-open
 if you can reproduce it with 6.10.x.

-- 
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] #3166: recompilation checking too optimistic about infix ops

2009-04-20 Thread GHC

#3166: recompilation checking too optimistic about infix ops
-+--
Reporter:  roland|Owner:  
Type:  bug   |   Status:  new 
Priority:  high  |Milestone:  6.12.1  
   Component:  Compiler  |  Version:  6.10.1  
Severity:  minor |   Resolution:  
Keywords:|   Difficulty:  Easy (1 hr) 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

  * priority:  normal => high
  * difficulty:  => Easy (1 hr)
  * milestone:  => 6.12.1

Comment:

 This should be pretty easy to fix.

-- 
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] #1633: Improve error message for kind mismatches

2009-04-20 Thread GHC

#1633: Improve error message for kind mismatches
-+--
Reporter:  guest |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  6.12 branch 
   Component:  Documentation |  Version:  6.6.1   
Severity:  normal|   Resolution:  
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

  * summary:  Now where does this error come from => Improve error message
  for kind mismatches

Comment:

 Adding a more descriptive description

-- 
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] #1645: {-# SPECIALIZE #-} doesn't

2009-04-20 Thread GHC

#1645: {-# SPECIALIZE #-} doesn't
-+--
Reporter:  guest |Owner:  
Type:  bug   |   Status:  closed  
Priority:  normal|Milestone:  6.12.1  
   Component:  Compiler  |  Version:  6.7 
Severity:  normal|   Resolution:  fixed   
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

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

Comment:

 Took a quick look: seems ok now.  There's a remaining reference to an Ord
 dictionary with 6.10.2, but that's gone in the HEAD.

-- 
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] #2692: ghc-6.10.0.20081007 seg faults on Sparc

2009-04-20 Thread GHC

#2692: ghc-6.10.0.20081007 seg faults on Sparc
-+--
Reporter:  maeder|Owner:  benl   
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone:  6.12.1 
   Component:  Compiler  |  Version:  6.9
Severity:  normal|   Resolution:  fixed  
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Solaris
Architecture:  sparc |  
-+--
Changes (by benl):

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

Comment:

 The GC gets miscompiled when the register variable is used because names
 like %l1 and %i1 are just offsets into the register window. In C land,
 when a function call takes place the window moves, so we lose the value of
 gct. We can't use any of the global regs %g0 - %g7 either because their
 either reserved for other purposes or caller-saves.

-- 
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] #3174: decodeFloat (0.0/0.0) = undefined

2009-04-20 Thread GHC

#3174: decodeFloat (0.0/0.0) = undefined
-+--
Reporter:  crutcher  |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  libraries/base|  Version:  
Severity:  normal|   Resolution:  
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonpj):

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

Comment:

 !NaNs are an area where it's easy for someone ignorant to screw up.  Would
 some of you guys who know and care about numerics like to come up with a
 concrete code change -- maybe it's only one line in the definition of
 `decodeFloat` -- and then we'll apply it?  Ideally a patch, but it'd be
 good enough to say "change this line to say that".

 Oh, and please give us a test or two with expected output.

 Thanks

 Simon

-- 
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] #3181: Regression in unboxing

Re: [GHC] #3175: hpc should not mark otherwise as "always true"

Re: [GHC] #3180: TcTyFuns.flattenType: unexpected PredType

Re: [GHC] #3180: TcTyFuns.flattenType: unexpected PredType

[GHC] #3180: TcTyFuns.flattenType: unexpected PredType

testing 6.10.2 on X_64

Re: [GHC] #3162: Windows users can't compile time package

glasgow-haskell-bugs@haskell.org

Re: [GHC] #912: Build system is missing various dependencies

Re: [GHC] #2107: "make install" doesn't install local copy of manual

Re: [GHC] #1886: GHC API should preserve and provide access to comments

Re: [GHC] #3167: Segmentation fault with compacting GC, and multiple threads

Re: [GHC] #3166: recompilation checking too optimistic about infix ops

Re: [GHC] #1633: Improve error message for kind mismatches

Re: [GHC] #1645: {-# SPECIALIZE #-} doesn't

Re: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc

Re: [GHC] #3174: decodeFloat (0.0/0.0) = undefined

17 matches

Site Navigation

Mail list logo

Footer information