#7929: -pgma and -pgmc flags dont work as expected on mac -------------------------+-------------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: 7678 Blocking: | Related: 7922,7678 -------------------------+-------------------------------------------------- This is a bug report version of a related ticket. As I discuss in [http://hackage.haskell.org/trac/ghc/ticket/7922#comment:23 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 [http://hackage.haskell.org/trac/ghc/ticket/7678 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. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7929 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler