Re: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS
#4934: threadWaitRead works incorrectly on nonthreaded RTS ---+ Reporter: slyfox |Owner: simonmar Type: bug | Status: infoneeded Priority: normal |Milestone: _|_ Component: Runtime System | Version: 7.0.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime ---+ Changes (by simonmar): * priority: high = normal * milestone: 7.0.3 = _|_ Comment: Replying to [comment:12 tibbe]: `poll` sets `POLLNVAL` per FD so that should be possible. Ok. In that case we could declare it to be a bug in the non-threaded RTS that could be fixed by using `poll()` instead of `select()` and generating correct error returns from `waitRead#`. Fixing it won't be a high priority, though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4934#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] #4828: ghci fails to load fat binary archives on OS X
#4828: ghci fails to load fat binary archives on OS X
-+--
Reporter: gwright |Owner: igloo
Type: bug | Status: patch
Priority: normal|Milestone: 7.2.1
Component: Runtime System| Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: MacOS X | Blocking:
Architecture: Unknown/Multiple | Failure: GHCi crash
-+--
Comment(by hesselink):
I think I've run into this bug, but not using GHCi. I'm building a package
which uses HDBC-postgresql. During building, it tries to load a postgresql
archive, and fails:
{{{
Loading package HDBC-postgresql-2.2.3.3 ... ghc: internal error:
loadArchive: Not an archive: `/Library/PostgreSQL/8.4/lib/libpq.a'
(GHC version 7.0.1 for i386_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
Examining the file in question shows it is a universal binary with two
architectures:
{{{
$ file /Library/PostgreSQL/8.4/lib/libpq.a
/Library/PostgreSQL/8.4/lib/libpq.a: Mach-O universal binary with 2
architectures
/Library/PostgreSQL/8.4/lib/libpq.a (for architecture ppc): current ar
archive random library
/Library/PostgreSQL/8.4/lib/libpq.a (for architecture i386):current ar
archive
}}}
If I read this ticket correctly, it seems this means HDBC-postgresql will
remain unusable with GHC 7.0, and thus with the coming haskell platform.
It that correct?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4828#comment:17
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] #4081: Strict constructor fields inspected in loop
#4081: Strict constructor fields inspected in loop
-+--
Reporter: rl|Owner:
Type: bug | Status: new
Priority: normal|Milestone: 7.0.2
Component: Compiler | Version: 6.13
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Comment(by simonpj):
I'm pretty certain we can fix this. My plan is simply to extend the let-
floater to float out `(case x of I# y - ...)`, where x is known to be
evaluated. (Of course, for any product type, not just Int.)
How might x be known to be evaluated? The usual way is by an enclosing
'case', but that won't happen here because the inner case would simply
vanish. No, it'll be because you pattern match on a strict constructor
{{{
case v of
C x - (case x of I# y - ...) ...
}}}
where
{{{
data C a = C !a
}}}
I believe that these strict constructors are the cases you are concerned
about, correct?
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4081#comment:7
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] #4081: Strict constructor fields inspected in loop
#4081: Strict constructor fields inspected in loop -+-- Reporter: rl|Owner: Type: bug | Status: new Priority: normal|Milestone: 7.0.2 Component: Compiler | Version: 6.13 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by rl): That sounds like a good plan. Yes, it's precisely the strict constructors I'm interested in. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4081#comment:8 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] #4958: Ambiguous module name `Prelude' (base haskell98-1.1.0.0)
#4958: Ambiguous module name `Prelude' (base haskell98-1.1.0.0) ---+ Reporter: EvgenijM86| Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Prelude |Version: 7.1 Resolution: wontfix | Keywords: haskell-src Prelude Testcase:| Blockedby: Difficulty:| Os: Linux Blocking:| Architecture: x86_64 (amd64) Failure: None/Unknown | ---+ Changes (by simonmar): * status: new = closed * resolution: = wontfix Comment: GHC starting with version 7.2.1 will not support using the `haskell98` package and the `base` package at the same time. The `haskell-src` package has both of these in its `build-depends`, so it will need to be modified. Most of the time, what you want to do is remove `haskell98` from build-depends, and fix up any imports of Haskell 98 modules to point to their `base` equivalents. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4958#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] #4828: ghci fails to load fat binary archives on OS X
#4828: ghci fails to load fat binary archives on OS X
-+--
Reporter: gwright |Owner: igloo
Type: bug | Status: patch
Priority: normal|Milestone: 7.2.1
Component: Runtime System| Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: MacOS X | Blocking:
Architecture: Unknown/Multiple | Failure: GHCi crash
-+--
Comment(by igloo):
No, it'll work due to this patch:
{{{
Mon Dec 13 12:49:30 GMT 2010 Ian Lynagh ig...@earth.li
* GHCi linker: Assume non-Haskell libraries are dynamic libs
Ignore-this: aa153a8f6e309c7b3dae7e46bb7a9583
This works around a segfault we get when trying to load libiconv.a on
some platforms.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4828#comment:18
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] #4828: ghci fails to load fat binary archives on OS X
#4828: ghci fails to load fat binary archives on OS X
-+--
Reporter: gwright |Owner: igloo
Type: bug | Status: patch
Priority: normal|Milestone: 7.2.1
Component: Runtime System| Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: MacOS X | Blocking:
Architecture: Unknown/Multiple | Failure: GHCi crash
-+--
Comment(by gwright):
Replying to [comment:17 hesselink]:
I think I've run into this bug, but not using GHCi. I'm building a
package which uses HDBC-postgresql. During building, it tries to load a
postgresql archive, and fails:
{{{
Loading package HDBC-postgresql-2.2.3.3 ... ghc: internal error:
loadArchive: Not an archive: `/Library/PostgreSQL/8.4/lib/libpq.a'
(GHC version 7.0.1 for i386_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
Examining the file in question shows it is a universal binary with two
architectures:
{{{
$ file /Library/PostgreSQL/8.4/lib/libpq.a
/Library/PostgreSQL/8.4/lib/libpq.a: Mach-O universal binary with 2
architectures
/Library/PostgreSQL/8.4/lib/libpq.a (for architecture ppc): current ar
archive random library
/Library/PostgreSQL/8.4/lib/libpq.a (for architecture i386): current ar
archive
}}}
If I read this ticket correctly, it seems this means HDBC-postgresql
will remain unusable with GHC 7.0, and thus with the coming haskell
platform. It that correct?
As igloo noted, this bug isn't you're problem. I've not finished testing
my patches for this issue because it's been pushed back to 7.2.1 and there
have been more urgent issues with the OS X linker (e.g., #4867).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4828#comment:19
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] #4945: Another SpecConstr infelicity
#4945: Another SpecConstr infelicity -+-- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.0.2 Component: Compiler|Version: 7.0.1 Resolution: fixed | Keywords: Testcase: simplCore/should_compile/T4945 | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Runtime performance bug | -+-- Changes (by igloo): * status: merge = closed * resolution: = fixed Comment: Only performance, and not a regression since 7.0.1 at least, so not merging at this stage of the release cycle. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4945#comment:7 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] #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file
#4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file -+-- Reporter: igloo |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 7.0.3 Component: Compiler | Version: 6.13 Keywords:| Testcase: Blockedby:| Difficulty: Os: MacOS X | Blocking: Architecture: x86 | Failure: Building GHC failed -+-- Comment(by gwright): Replying to [comment:19 igloo]: Is there a canonical example of this bug? If you can tell me which ghc version shows it I can look at it, since I have access to both 10.5 (x86_64) and 10.6 (x86/x86_64) systems. If you'd like, I can take this bug since I've been thinkin' about linkin'. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4013#comment:20 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] #4957: Simplifier failes to eliminate redundant boxing/unboxing
#4957: Simplifier failes to eliminate redundant boxing/unboxing
-+--
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler|Version: 7.0.1
Resolution: fixed | Keywords:
Testcase: simplCore/should_compile/T4957 | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Changes (by simonpj):
* status: new = closed
* testcase: = simplCore/should_compile/T4957
* resolution: = fixed
Comment:
Fixed by
{{{
Mon Feb 14 03:11:51 PST 2011 simo...@microsoft.com
* Better case-of-case transformation
The ThunkSplitting idea in WorkWrap wasn't working at all,
leading to Trac #4957. The culprit is really the simplifier
which was combining the wrong case continuations. See
Note [Fusing case continuations] in Simplify.
M ./compiler/simplCore/Simplify.lhs -10 +48
M ./compiler/stranal/WorkWrap.lhs +5
}}}
Test added also.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4957#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] #4941: SpecConstr generates functions that do not use their arguments
#4941: SpecConstr generates functions that do not use their arguments -+-- Reporter: simonpj |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by simonpj): OK I've fixed #4957. Would you like to try the effect of strictness analysis following `SpecContr` now? Is it always a win? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4941#comment:8 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] #4941: SpecConstr generates functions that do not use their arguments
#4941: SpecConstr generates functions that do not use their arguments
-+--
Reporter: simonpj |Owner:
Type: task | Status: new
Priority: normal|Milestone: _|_
Component: Compiler | Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Comment(by batterseapower):
Headline numbers for this change after your #4957 fix:
{{{
Min +0.0% -3.2% -4.4% -2.5% +0.0%
Max +0.3% +4.0% +4.5% +4.9% +0.0%
Geometric Mean +0.0% -0.0% +0.2% +0.2% -0.0%
}}}
So a solid reduction in allocations for a few benchmarks (knights,
parstof, simple and sphere are the biggest winners). However, some
benchmarks get worse. I looked at the worst offender (crypytarithm2) and
saw something pretty odd. It looks like the transformation is working
correctly but the output code (post simplification) contains dead let-
bindings for SpecConstr specialisations that have been worker/wrappered,
and those workers have been subsequently inlined into all use sites.
For example, we have a local specialisation within the final body of
permute1:
{{{
sgo_s1lg [InlPrag=INLINE[0], Occ=LoopBreaker!]
:: Main.Digits
- Main.Digits
- [(Main.Digits, Main.Digits)]
- [(GHC.Types.Int, Main.Digits)]
[LclId,
Arity=3,
Str=DmdType U(SL)LL,
Unf=Unf{Src=Worker=$w$sgo_s1mv, TopLvl=False, Arity=3, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=False)
Tmpl= \ (w_s1lD [Occ=Once!] :: Main.Digits)
(w1_s1lI [Occ=Once] :: Main.Digits)
(w2_s1lJ [Occ=Once] :: [(Main.Digits,
Main.Digits)]) -
case w_s1lD
of _ { Main.Digits ww_s1lF [Occ=Once] ww1_s1lG
[Occ=Once] -
$w$sgo_s1mv ww_s1lF ww1_s1lG w1_s1lI w2_s1lJ
}}]
$sgo_s1lg =
\ (w_s1lD :: Main.Digits)
(w1_s1lI :: Main.Digits)
(w2_s1lJ :: [(Main.Digits, Main.Digits)]) -
case w_s1lD of _ { Main.Digits ww_s1lF ww1_s1lG -
$w$sgo_s1mv ww_s1lF ww1_s1lG w1_s1lI w2_s1lJ
};
$w$sgo_s1mv [Occ=LoopBreaker]
:: [GHC.Types.Int]
- [(GHC.Types.Char, GHC.Types.Int)]
- Main.Digits
- [(Main.Digits, Main.Digits)]
- [(GHC.Types.Int, Main.Digits)]
[LclId, Arity=4, Str=DmdType SLLL]
$w$sgo_s1mv = ... big ...
}}}
But $sgo_s1lg does not occur anywhere in the code! These bindings are
probably the source of the increased allocation as their closures will be
allocated anew for each application of permute1.
I found that changing the final simplification phase to use at least 3
iterations (just like the main simplification phase) did not eliminate
these. Is there any obvious explanation for this behaviour?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4941#comment:9
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] #4958: Ambiguous module name `Prelude' (base haskell98-1.1.0.0)
#4958: Ambiguous module name `Prelude' (base haskell98-1.1.0.0) ---+ Reporter: EvgenijM86| Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Prelude |Version: 7.1 Resolution: wontfix | Keywords: haskell-src Prelude Testcase:| Blockedby: Difficulty:| Os: Linux Blocking:| Architecture: x86_64 (amd64) Failure: None/Unknown | ---+ Comment(by EvgenijM86): Yes, removing haskell98 from .cabal file seems to have fixed it - it did compile without errors. It looks like it didn't have any imports to haskell98, because according to comment in .cabal file: -- The dependency on Haskell 98 is only because -- Happy generates a parser that imports Array thank you for your help. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4958#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
[GHC] #4961: Make the Timeout exception a newtype instead of a datatype
#4961: Make the Timeout exception a newtype instead of a datatype
-+--
Reporter: basvandijk| Owner:
Type: task | Status: new
Priority: normal| Component: libraries/base
Version: 7.0.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
The attached patch simply replaces the `data` with a `newtype` for the
`Timeout` exception in
[http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-
Timeout.html System.Timeout]:
{{{
-dataTimeout = Timeout Unique deriving Eq
+newtype Timeout = Timeout Unique deriving Eq
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4961
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] #4941: SpecConstr generates functions that do not use their arguments
#4941: SpecConstr generates functions that do not use their arguments -+-- Reporter: simonpj |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by batterseapower): I think I see the problem. preInlineUnconditionally/PostInlineUnconditionally prevents dead let- bindings from being inlined if they have a stable unfolding. IMHO they should unconditionally inline bindings with IAmDead occurrence information. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4941#comment:10 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] #4941: SpecConstr generates functions that do not use their arguments
#4941: SpecConstr generates functions that do not use their arguments -+-- Reporter: simonpj |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by batterseapower): Er, no - I was wrong as usual. The issue is right there in the code: $sgo_s1lg is a LoopBreaker for some reason. Weird. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4941#comment:11 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] #4941: SpecConstr generates functions that do not use their arguments
#4941: SpecConstr generates functions that do not use their arguments -+-- Reporter: simonpj |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by batterseapower): I'm being particularly slow today. The issue was obvious once I looked at the simplified output rather than the tidied core - there is a non-dead function later in that letrec (go_s1gC) that has a RULE that rewrites to $sgo_s1lg. It is sort of unfortunate that this is keeping the thing it refers to alive even after core tidying, where rules cannot possibly apply any more. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4941#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] #4941: SpecConstr generates functions that do not use their arguments
#4941: SpecConstr generates functions that do not use their arguments -+-- Reporter: simonpj |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by simonpj): Well, if `go_s1gC` was externally visible (via the interface file), then its RULE ''could'' still fire. But if it's not exported, it can't. So * `CoreTidy` could discard RULES and unfoldings for non-externally- visible things * `CoreTidy` could run the occurrence analyser to drop code thereby shown to be dead But that still doesn't account for some programs allocating more and running slower. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4941#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
