1. 18 May, 2006 7 commits
  2. 17 May, 2006 8 commits
  3. 16 May, 2006 1 commit
    • duncan.coutts@worc.ox.ac.uk's avatar
      Let GHCi work with with Sparc32+/V8+ .o files · 82807c21
      duncan.coutts@worc.ox.ac.uk authored
      Currently 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-linux
      82807c21
  4. 15 May, 2006 1 commit
  5. 10 May, 2006 5 commits
  6. 09 May, 2006 2 commits
  7. 08 May, 2006 5 commits
    • simonpj@microsoft.com's avatar
      Do not put wired-in things in interface files · ef61cbbc
      simonpj@microsoft.com authored
      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.)
      ef61cbbc
    • simonpj@microsoft.com's avatar
      Remove NOINLINE strictness hack · 302265d5
      simonpj@microsoft.com authored
      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.
      302265d5
    • simonpj@microsoft.com's avatar
      Trim imports · 36b27193
      simonpj@microsoft.com authored
      36b27193
    • simonpj@microsoft.com's avatar
      Trim imports · bbf41467
      simonpj@microsoft.com authored
      bbf41467
    • Simon Marlow's avatar
      GHC_MANGLER-->MANGLER · 02de51da
      Simon Marlow authored
      02de51da
  8. 05 May, 2006 1 commit
  9. 02 May, 2006 1 commit
  10. 05 May, 2006 9 commits