adding direct *.c -> object code (*.o/so/dylib) support to compilation driver

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

Trac metadata

Trac field	Value
Version	7.7
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture