GHC:1375c0a78d6e786fa70e483597f93143baa5d65a commitshttps://gitlab.haskell.org/ghc/ghc/-/commits/1375c0a78d6e786fa70e483597f93143baa5d65a2006-05-22T19:25:32+00:00https://gitlab.haskell.org/ghc/ghc/-/commit/1375c0a78d6e786fa70e483597f93143baa5d65aPrune imports2006-05-22T19:25:32+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/2c969eccaa815888434143c9084b8ab855586dc6Add deShadowBinds2006-05-22T19:24:04+00:00simonpj@microsoft.comunknown
Add CoreSubst.deShadowBinds, which removes shadowing from
a Core term. I thought we wanted it for SpecConstr, but in
fact decided not to use it. Nevertheless, it's a useful sort
of function to have around, and it has a particularly simple
definition!
https://gitlab.haskell.org/ghc/ghc/-/commit/a2c92cccbdfdf295901e6c367c35bd4b2b0288e0Inline in a call argument if the caller has RULES2006-05-22T16:32:55+00:00simonpj@microsoft.comunknown
This is an experimental change suggested by Roman. Consider
{-# INLINE f #-}
f x y = ...
....(g (f a b))...
where g has RULES. Then we'd like to inline f, even though the context of
the call is otherwise 100% boring -- g is lazy and we know nothing about
x and y.
This patch just records in the continuation that f has rules. And does so
somewhat recursively...e.g.
...(g (h (f a b)))...
where g has rules.
https://gitlab.haskell.org/ghc/ghc/-/commit/b7d8dffaf1fefdf2f6b52fcf039a06843a28d586Add idHasRules2006-05-22T16:31:09+00:00simonpj@microsoft.comunknown
Add Id.idHasRules :: Id -> Bool, with the obvious semantics.
This patch makes sense by itself, but it's just a tidy-up.
https://gitlab.haskell.org/ghc/ghc/-/commit/39dd1943735841b6cc62c91134189371ba571f38Transmit inline pragmas faithfully2006-05-22T11:02:56+00:00simonpj@microsoft.comunknown
*** WARNING: you will need to recompile your libraries
*** when you pull this patch (make clean; make)
The inline pragma on wrapper-functions was being lost; this patch
makes it be transmitted faithfully.
The reason is that we don't write the full inlining for a wrapper into
an interface file, because it's generated algorithmically from its strictness
info. But previously the inline pragma as being written out only when we
wrote out an unfolding, and hence it was lost for a wrapper.
This makes a particular difference when a function has a NOINLINE[k] pragma.
Then it may be w/w'd, and we must retain the pragma. It's the only consistent
thing to do really.
The change does change the binary format of interface files, slightly.
So you need to recompile all your libraries.
https://gitlab.haskell.org/ghc/ghc/-/commit/5a8a219c131b56c75dbb3110da3ab5ae3715ff66Improved RULE lhs typechecking; less dictionary sharing2006-05-19T10:34:33+00:00simonpj@microsoft.comunknown
See long comment with Simplify.tcSimplifyRuleLhs.
Here's the key example:
RULE "g" forall x y z. g (x == y) (y == z) = ...
Here, the two dictionaries are *identical*, but we do NOT WANT to
generate the rule
RULE forall x::a, y::a, z::a, d1::Eq a
f ((==) d1 x y) ((>) d1 y z) = ...
Instead we want
RULE forall x::a, y::a, z::a, d1::Eq a, d2:Eq a
f ((==) d1 x y) ((>) d2 y z) = ...
https://gitlab.haskell.org/ghc/ghc/-/commit/cbc86d748d5f7b5ad5503c9e87c0b5c0402f27bcBug-fix for infix function definitions (parse/rename)2006-05-19T09:50:22+00:00simonpj@microsoft.comunknown
Fix a crash provoked by
x `op` y = x
op = True
The trouble was that there is currently a single 'infix' flag for the
whole group; and RnTypes.checkPrecMatch was therefore expecting the
second eqn to have two args.
This fixes the crash, and also or-s the infix flags for the various
eqns together; previously it was just taken from the first eqn, which
was wrong.
https://gitlab.haskell.org/ghc/ghc/-/commit/c2a3f5861959f9b80ee65c16212447788217223dRemove misleading comments2006-05-19T09:49:36+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/b812bfb914a0164f5ce3b206cb9769dc70253374Fix a nasty continuation-duplication bug2006-05-18T16:36:17+00:00simonpj@microsoft.comunknown
For a long-time mkDupableCont has had a bug that allows it to duplicate
an arbitrary continuation, which it should not do, of course.
The bug was that in the Select case of mkDupableCont we were calling
prepareCaseCont, which did not duplicate the continuation if there is
but a single alternative. This is quite right in the case of the call
in rebuildCase, but quite wrong in mkDupableCont.
The bug manifest as follows. In the expression
f (case ... of { ..several alts.. })
(when f is strict), we should transform to
f (...transformed arg...)
The application of f should not be pushed down (see notes with the
ArgOf case of mkDupableCont. But that was not happening in an example
like this (see how the call to f is pushed inwards).
f (a `div` abs (b::Int))
--->
case b_afT of wild_aHa { GHC.Base.I# x_aHc ->
let {
$j_sIe :: GHC.Prim.Int# -> GHC.Base.Int
[]
$j_sIe =
\ (ds1_aHr [Nothing OneShot] :: GHC.Prim.Int#) ->
Foo7.f
(case ds1_aHr of ds2_aHq {
__DEFAULT ->
case a_afS of wild1_aHM { GHC.Base.I# x_aHO ->
GHC.Base.I# (GHC.Base.divInt# x_aHO ds2_aHq)
};
0 -> GHC.Err.divZeroError @ GHC.Base.Int
})
} in
case GHC.Prim.>=# x_aHc 0 of wild1_aHe [Dead Nothing] {
GHC.Base.False ->
let {
ds1_aHr :: GHC.Prim.Int#
[]
ds1_aHr = GHC.Prim.negateInt# x_aHc
} in $j_sIe ds1_aHr;
GHC.Base.True -> $j_sIe x_aHc
}
}
https://gitlab.haskell.org/ghc/ghc/-/commit/647546977c3b6869c027b33c3de841ff13afc912Make simplifier report which phase it is doing in -ddump output2006-05-18T16:34:48+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/ae019a20d2db44c52767f5cd6291f3276067446bComments only2006-05-18T16:34:25+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/291acff508eccd0a2ad510d48114bf3f8987c7dbtake parsec out of $(GhcBootLibs)2006-05-18T13:15:06+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/317da78a27cda0c07fce325953f096453bcef477Improve documentation of INLINE pragmas2006-05-18T11:32:12+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/0d186bf9557df7c7babe4ed09eac8e1cf1116deca couple of additions2006-05-18T10:40:25+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/b4ee9a92737e40ac0133f833781d01a8589f2cb7#define _REENTRANT 1 (needed to get the right errno on some OSs)2006-05-18T10:37:15+00:00Simon Marlowsimonmar@microsoft.comPartial fix for hanging problems on Solaris and possibly *BSD.
A similar fix is also required to libraries/base/includes/HsBase.h.https://gitlab.haskell.org/ghc/ghc/-/commit/db6ac78e2be25a5c8c44d50e073df25653dc0039Declare this file to be POSIX2006-05-18T10:28:58+00:00Simon Marlowsimonmar@microsoft.comThis is simpler than using _POSIX_THREAD_SEMANTICS on Solaris to get
the right version of ctime_r().https://gitlab.haskell.org/ghc/ghc/-/commit/1c8acc1564a5ba2d340c62966e7409f001601553somewhere to keep track of release notes for 6.62006-05-18T07:44:15+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/307ea550bfa8fb9146f07c0dc103e53a31f4436cNewtype data constructors get a compulsory unfolding2006-05-17T15:50:09+00:00simonpj@microsoft.comunknown
With this change, newtype data constructors get a "compulsory" unfolding,
which means that they *must* be inlined, and no top-level definition of
the constructor is provided at all. Since these constructors are no-ops,
I'm not sure why this wasn't the case all along.
https://gitlab.haskell.org/ghc/ghc/-/commit/5abdfc854aab09057bad26a5fe41828ea4968e5dWhite space only2006-05-17T15:49:36+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/c55bcbdea7b8122956853c90f680a59808889b95Retain InlinePragInfo on wrappers2006-05-17T15:47:25+00:00simonpj@microsoft.comunknown
For some reason, when doing the worker/wrapper split, we transferred the
InlinePragInfo from the original function, but expunging it from the wrapper.
This meant, for example, that a NOINLINE function would have its wrapper
inlined, which isn't sensible.
For a change, fixing a bug involves only deleting code!
https://gitlab.haskell.org/ghc/ghc/-/commit/27497880e4386b42cd078c15f82e1b02a92aae92Spelling correction2006-05-17T15:47:10+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/5902b3d706a4892a2e9265f5cc53fe2950bdb27bRetain INLINE pragma information during indirection-shorting2006-05-17T15:44:49+00:00simonpj@microsoft.comunknown
During indirection-shorting, we were dropping the InlinePragInfo,
although were were carefully retaining strictness info etc.
I think this is a long-standing bug.
https://gitlab.haskell.org/ghc/ghc/-/commit/c6fc542f101a039265c4d22c06ccdaabe7ec7485Improve pretty-printing2006-05-17T15:43:49+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/7653e16d0afab8e25eb5015aa4d0c1d03d6ab4a3Comments only2006-05-17T15:43:04+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/c02a62c0b822fcf1a7abb46a430cdea754647114Improve pretty-printing slightly2006-05-17T15:42:04+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/82807c2121870bd2458a29037c5518b2bc90007cLet GHCi work with with Sparc32+/V8+ .o files2006-05-16T09:04:30+00:00Duncan Couttsduncan.coutts@worc.ox.ac.ukCurrently the GHCi linker looks exclusively for V7 ABI .o files.
You can generate V8+ ABI .o files using flags to gcc such as:
-optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
Note that this allows gcc to generate hardware integer division and
hardware floating point instructions rather than using software emulation.
All recent sparc hardware is V8+ or later. Perhaps we should check for the
cpu generation in configure and use the later ABI if possible.
Tested briefly on a SunBlade 100 (TI UltraSparc IIe) sparc-unknown-linuxhttps://gitlab.haskell.org/ghc/ghc/-/commit/f0c000ef6c996a3654f64f97b39e58d3b3d68dd6match up more closely with compiler/main/DynFlags.hs:machdepCCOpts2006-05-15T09:00:31+00:00Simon Marlowsimonmar@microsoft.comIn particular, add -fno-builtin to x86 and x86_64, which was missing.https://gitlab.haskell.org/ghc/ghc/-/commit/3a7fa9bb3cee6c1b4c26bc5ba91f9afe97fa502fset $(GhcVersion) and $(GhcPatchLevel) correctly when $(UseStage1)==YES2006-05-10T12:46:21+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/575ed809babbcbcbdb6324d82bf23a8ac973dff8.raw_s and .s live in $(odir), not the source dir2006-05-10T12:15:24+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/a3e027a34f5e956da3875ab629aa2427e520f879additions from Reilly Hayes2006-05-10T12:00:00+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/4f7abbdceb83d96ac400488a665245a4b67820basome tweaks to the HC bootstrapping instructions2006-05-10T11:52:36+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/7446fa8a9c9781ee4c56ef1b55c7a5309fa0c3c5Ignore unboxed values in breakpoints.2006-05-10T07:27:22+00:00Lemmihlemmih@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/4409628fbb7925eccf9fe0784809fa2eb8d790dcDon't read ~/.ghci on breakpoints.2006-05-09T22:34:55+00:00Lemmihlemmih@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/03803f88cccbee0d2a4180015fffa02a803c20d6make it possible to define an alias for :quit2006-05-09T08:31:24+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/ef61cbbcbf819e7e5930b60de59fb5d550f66e83Do not put wired-in things in interface files2006-05-08T14:29:46+00:00simonpj@microsoft.comunknown
There is no need for wired-in things to go into interface files; the compiler
knows about them anyway. Worse, it turns ou that if they are in an interface
file, they may get read in with not-quite-right type info (e.g. GHC.Err.error),
and the not-quite-right thing gets into the type envt. Than it gets used
instead of the wired in thing.
Best all round never to put them into interface files. This is the way
it used to be, but it looks as if it rotted away some time ago.
(I noticed this when fixing unsafePerformIO stuff, becuase 'lazy' was getting
an unfolding when it shouldn't.)
https://gitlab.haskell.org/ghc/ghc/-/commit/302265d525004c7870864549f7a07a5759d32912Remove NOINLINE strictness hack2006-05-08T14:28:34+00:00simonpj@microsoft.comunknown
The stricteness analyser used to have a HACK which ensured that NOINLNE things
were not strictness-analysed. The reason was unsafePerformIO. Left to itself,
the strictness analyser would discover this strictness for unsafePerformIO:
unsafePerformIO: C(U(AV))
But then consider this sub-expression
unsafePerformIO (\s -> let r = f x in
case writeIORef v r s of (# s1, _ #) ->
(# s1, r #)
The strictness analyser will now find that r is sure to be eval'd,
and may then hoist it out. This makes tests/lib/should_run/memo002
deadlock.
Solving this by making all NOINLINE things have no strictness info is overkill.
In particular, it's overkill for runST, which is perfectly respectable.
Consider
f x = runST (return x)
This should be strict in x.
So the new plan is to define unsafePerformIO using the 'lazy' combinator:
unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r)
Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is
magically NON-STRICT, and is inlined after strictness analysis. So
unsafePerformIO will look non-strict, and that's what we want.
Now we don't need the hack in the strictness analyser.
https://gitlab.haskell.org/ghc/ghc/-/commit/36b27193c994b4a267c8dfdbf833d73b455130aaTrim imports2006-05-08T14:18:04+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/bbf41467d3466310431594516d88b1400aef245dTrim imports2006-05-08T14:17:13+00:00simonpj@microsoft.comunknownhttps://gitlab.haskell.org/ghc/ghc/-/commit/02de51da7604e493cce555004e82b8bc95e64e15GHC_MANGLER-->MANGLER2006-05-08T11:12:06+00:00Simon Marlowsimonmar@microsoft.comhttps://gitlab.haskell.org/ghc/ghc/-/commit/3104fac16e61a23b368749b16e4b796501af8b69Fix bug #763: Breakpoint mechanism crashes when there's a type error.2006-05-05T23:21:58+00:00Lemmihlemmih@gmail.com