- 24 Jul, 2010 3 commits
-
-
Ian Lynagh authored
We now first collect the option instructions (from the commandline, from pragmas in source files, etc), and then later flatten them into the list of enabled options. This will enable us to use different standards (H98, H2010, etc) as a base upon which to apply the instructions, when we don't know what the base will be when we start collecting instructions.
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 23 Jul, 2010 4 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 21 Jul, 2010 1 commit
-
-
Ian Lynagh authored
-
- 19 Jul, 2010 1 commit
-
-
Ian Lynagh authored
-
- 22 Jul, 2010 1 commit
-
-
dterei authored
-
- 21 Jul, 2010 4 commits
-
-
dterei authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
This was discombobulated by a patch a week ago; now fixed, quite straightforwardly. See Note [Default methods and instances]
-
simonpj@microsoft.com authored
It turns out that TH.Syntax is rich enough to express even GADTs, provided we express them in equality-predicate form. So for example data T a where MkT1 :: a -> T [a] MkT2 :: T Int will appear in TH syntax like this data T a = forall b. (a ~ [b]) => MkT1 b | (a ~ Int) => MkT2 While I was at it I also improved the reification of types, so that we use TH.TupleT and TH.ListT when we can.
-
- 20 Jul, 2010 4 commits
-
-
Simon Marlow authored
-
dterei authored
Currently, many programs compiled with GHC at -O2 and LLVM set to -O3 will segfault (only under OSX). Until this issue is fixed I have simply 'solved' the segfault by lowering the max opt level for LLVM used to -O2 under OSX. All these recent changes to OSX should mean its finally as stable as Linux and Windows.
-
dterei authored
-
dterei authored
-
- 16 Jul, 2010 1 commit
-
-
Simon Marlow authored
In GHC 6.12.x I found a rare deadlock caused by this lock-order-reversal: AQ cap->lock startWorkerTask newTask AQ sched_mutex scheduleCheckBlackHoles AQ sched_mutex unblockOne_ wakeupThreadOnCapabilty AQ cap->lock so sched_mutex and cap->lock are taken in a different order in two places. This doesn't happen in the HEAD because we don't have scheduleCheckBlackHoles, but I thought it would be prudent to make this less likely to happen in the future by using a different mutex in newTask. We can clearly see that the all_tasks mutex cannot be involved in a deadlock, becasue we never call anything else while holding it.
-
- 15 Jul, 2010 1 commit
-
-
Simon Marlow authored
-
- 19 Jul, 2010 2 commits
- 18 Jul, 2010 1 commit
-
-
dterei authored
-
- 15 Jul, 2010 1 commit
-
-
illissius@gmail.com authored
-
- 17 Jul, 2010 5 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
This way it gets the defines for the right platform when cross-compiling
-
Ian Lynagh authored
-
- 16 Jul, 2010 6 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
Now that we are trying to support cross compilation, we can't use "$(TARGETPLATFORM)" != "$(HOSTPLATFORM)" as a test for HC-porting.
-
Ian Lynagh authored
-
- 15 Jul, 2010 5 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
When we ask make to run "a | b", if a fails then the pipeline might still exit successfuly.
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-