On 2014-11-21 at 06:09:06 +0100, Bardur Arantsson wrote:
[...]
> Does this mean that any code compiling against the current release of
> old-locale (1.0.0.6) will fail to compile with GHC 7.10.x? I ask because
> I note that old-locale (1.0.0.6) depends on
>
> base >= 4.2 && < 4.8
>
> and presum
Whoops, that's my fault; it shouldn't have slipped into the patch -- this is
required for LLVM 3.6 (which I was using to work on my ARM64 patch), but
clearly isn't backwards compatible.
I wonder what's best to do for this? Would it be correct to switch on LLVM
versions or should this be considered
2014-11-20 9:36 GMT+01:00 Joachim Breitner :
> [...] With your extensions it will have to read the directory contents. In
> most situations, that should be fine, but it might cause minor
> inconveniences with very large directories, many search paths (-i flags)
> and/or very weird file systems (com
Hi,
Tests fail on master when run the optllvm way, e.g.:
/usr/bin/opt: /tmp/ghc16190_0/ghc16190_2.ll:611:25: error: expected 'global' or
'constant'
@newCAF$alias = private alias i8* @newCAF
I think it's the change in d87fa34:
index 7307725..cdc407c 100644
--- a/compiler/llvmGen/Llvm/PpLlvm.hs
Hi Merjin,
there is one possible problem with this approach. Currently, the
compiler never has to read the contents of the directory (or at least
that’s what I assume; is that correct?) but only has to probe the
existence of a fixed finite set of files.
With your extensions it will have to read t
