[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            |   Milestone:                  
   Component:  Compiler          |     Version:  7.7             
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:  #7904             |  
---------------------------------+------------------------------------------

Comment(by carter):

 {{{
 carter code/test » gcc -m64 -fno-stack-protector -m64 -x c -c cbits/daft.c
 -fno-common -Wimplicit -march=native -O2
 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T//ccBZdtfA.s:6:no such
 instruction: `vmovupd (%rdi), %xmm0'
 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T//ccBZdtfA.s:7:no such
 instruction: `vaddpd %xmm0, %xmm0,%xmm0'
 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T//ccBZdtfA.s:8:no such
 instruction: `vmovupd %xmm0, (%rsi)'
 }}}


 funnily enough, i accidently ran it as cc (which is apparently an alias
 for the apple dev tools  clang on my machine / all macs) instead of gcc
 before i pasted i correctly with gcc, and it worked fine that way.

 ie, the same invocation, with cc (apple dev tools clang) or clang (llvm
 3.4) instead of gcc, works / generates object code.

 heres the .s generated  generated when i invoke clang with those arguments
 plus a {{{ -S }}}
 {{{
         .section        __TEXT,__text,regular,pure_instructions
         .globl  _myVAdd
         .align  4, 0x90
 _myVAdd:                                ## @myVAdd
         .cfi_startproc
 ## BB#0:                                ## %entry
         pushq   %rbp
 Ltmp2:
         .cfi_def_cfa_offset 16
 Ltmp3:
         .cfi_offset %rbp, -16
         movq    %rsp, %rbp
 Ltmp4:
         .cfi_def_cfa_register %rbp
         vmovapd (%rdi), %xmm0
         vaddpd  %xmm0, %xmm0, %xmm0
         vmovapd %xmm0, (%rsi)
         popq    %rbp
         ret
         .cfi_endproc


 .subsections_via_symbols


 }}}


 just for comparison heres the gcc .s output
 {{{
         .text
         .align 4,0x90
         .globl _myVAdd
 _myVAdd:
 LFB802:
         vmovupd (%rdi), %xmm0
         vaddpd  %xmm0, %xmm0, %xmm0
         vmovupd %xmm0, (%rsi)
         ret
 LFE802:
         .section
 __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
 EH_frame1:
         .set L$set$0,LECIE1-LSCIE1
         .long L$set$0
 LSCIE1:
         .long   0
         .byte   0x1
         .ascii "zR\0"
         .byte   0x1
         .byte   0x78
         .byte   0x10
         .byte   0x1
         .byte   0x10
         .byte   0xc
         .byte   0x7
         .byte   0x8
         .byte   0x90
         .byte   0x1
         .align 3
 LECIE1:
 LSFDE1:
         .set L$set$1,LEFDE1-LASFDE1
         .long L$set$1
 LASFDE1:
         .long   LASFDE1-EH_frame1
         .quad   LFB802-.
         .set L$set$2,LFE802-LFB802
         .quad L$set$2
         .byte   0
         .align 3
 LEFDE1:
         .subsections_via_symbols

 }}}

 maybe gcc uses the system {{{as}}} and clang doesn't because it goes via
 the llvm backend. or maybe i'm just tired and I need to revisit how got
 get gcc to work here later.

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