Custom Query

Reported by JasonGross, 9 hours ago.

cabal-dev install haskell-src-exts-1.13.5 fails with a missing happy:

$ cabal-dev install haskell-src-exts-1.13.5 Resolving dependencies... [1 of 1] Compiling Main ( /tmp/haskell-src-exts-1.13.5-24348/haskell-src-exts-1.13.5/Setup.hs, /tmp/haskell-src-exts-1.13.5-24348/haskell-src-ext s-1.13.5/dist/setup/Main.o )

/tmp/haskell-src-exts-1.13.5-24348/haskell-src-exts-1.13.5/Setup.hs:1:1:

Warning: In the use of `runTests'

(imported from Distribution.Simple, but defined in Distribution.Simple.UserHooks?): Deprecated: "Please use the new testing interface instead!"

Linking /tmp/haskell-src-exts-1.13.5-24348/haskell-src-exts-1.13.5/dist/setup/setup ... Configuring haskell-src-exts-1.13.5... setup: The program happy version >=1.17 is required but it could not be found. Failed to install haskell-src-exts-1.13.5 cabal: Error: some packages failed to install: haskell-src-exts-1.13.5 failed during the configure step. The exception was: ExitFailure? 1

Reported by carter, 33 hours ago.

This is a bug report version of a related ticket.

As I discuss in  this ticket, the Assembler available on the Mac OS X platform does not support AVX instructions, though the operating system/ platform does.

Clang, because it uses LLVM as a backend, supports AVX, and can generate AVX simd ops in the object code directly, or AVX assembly, or assemble assembly that uses AVX. Clang will select AVX instructions on SandyBridge? or newer macs when given the -march=native flag.

There is another subtlety: the Apple Developer tools version of gcc 4.2 is old enough that it doesn't understand -march=native / doesn't support avx, and while newer versions of gcc (eg gcc 4.8), understand -march=native, and can choose -march=corei7-avx as appropriate (which corresponds to most new macs of the past 2 years), and while these newer gcc's can generate assembly that uses AVX instructions, these newer gcc's still seem to try to use the system assembler.

Now, one would think/hope that passing -pgma clang -pgmc clang to ghc would resolve this build problem, however, this does not seem to work,

though as documented in the related ticket, calling clang directly with the flags that ghc would generate DOES work correctly, (but calling clang by hand is no substitute for a compilation driver)

clang -march=native -mavx $flags -S foo.c
clang -march=native -mavx $flags -c foo.s

what *does* work is change the settings file that gets installed with ghc (for me this file is at /user/local/lib/ghc-7.6.2/settings) to have clang as the default ghc compiler rather than gcc. This makes the build work on the toy test case, but because of the  clang cpp problem ticket, clang is not a viable default compiler setting for ghc as yet.

The fact that changing the settings file compiler from gcc -> clang worked, but doing -pgma clang -pgmc clang does not, suggest either those flags are incorrectly implemented for OS X ghcs, or there is some switch that isn't toggled by the currently exposed compiler passes.

I can work around these corner cases, at the cost of some complexity in my build tooling, but the fact that the -pgma clang -pgmc clang bits didn't work, but changing the settings file did work (something that really isn't a good idea given how clang and ghc interact wrt c pre processor), suggests that some part of the build process for the c -> object code path in the ghc driver isn't being configured properly by the standard program flags, but is changed by the settings file.

So this suggests that semantically there is some bug in the driver, or a part of the build process that doesn't have a flag exposed yet, but which behaves different subject to change the compiler choice in the ghc settings file. This seems like a misfeature.

Reported by MitchellSalad, 38 hours ago.

import Control.Monad.Trans.Class (lift)
import Control.Monad.Trans.Maybe (MaybeT)

foo :: MaybeT IO ()
foo = lift putStrLn "foo"

This code caused the following output from GHC:

Couldn't match kind `* -> *' with `*'
    Expected type: [Char] -> MaybeT IO ()
      Actual type: [Char] -> MaybeT IO ()
    Kind incompatibility when matching types:
      [Char] :: * -> *
      [Char] :: *
    The function `lift'ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.3 for x86_64-unknown-linux):
	kindFunResult
<<details unavailable>>

The line should of course be lift $ putStrLn "foo". Apologies if this is a duplicate bug.