[GHC] #7929: -pgma and -pgmc flags dont work as expected on mac

[GHC]

#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