[GHC] #7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver

[GHC]

#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation
driver
-----------------------------+----------------------------------------------
Reporter:  carter            |          Owner:                  
    Type:  feature request   |         Status:  new             
Priority:  normal            |      Component:  Compiler        
 Version:  7.7               |       Keywords:                  
      Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
 Failure:  None/Unknown      |      Blockedby:                  
Blocking:                    |        Related:  #7904           
-----------------------------+----------------------------------------------
 currently when GHC is used as the compilation driver for C code,  it will
 always compile the C code (*.c)  to assembly  (*.s) and then in a
 subsequent phase map the assembly to the various object formats.

 Thusly: the feature request I have is adding support to ghc  (perhaps via
 indication through a new flag) for running the C compiler as something
 like {{{ gcc source.c -c  }}}  rather than {{{ gcc source.c -s -c }}}

  (these are not necessarily the right flags, but rather a strawman
 representation of the difference).


 on certain operating systems, notable OS X, the system provided Assembler
 (to which there is no, more up to date, alternative) does not support /
 understand all of the instructions that gcc or clang will emit. Notably,
 as a general rule, compiling c code with -march=native flag *should not*
 break. However, on OS X on recent hardware, -march=native will use AVX
 SIMD instructions / registers if available, which the mac os x assembler
 doesn't understand. and thus an end user trying to build some haskell and
 c-code locally will have a very odd error that will take a bit of effort
 to understand.  this took a bit of ef

 Likewise, when doing -fllvm compilation, the  *.c-> *.s phase just slows
 down the compilation process period.

 I'm still learning the ghc compilation driver architecture, but it seems
 like this would be a relatively minimal change, and it'd be valuable along
 a number of atrributes

 This is not

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7922>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler