[LLVMbugs] [Bug 20894] New: clang-cl doesn't properly handle the -o flag

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20894

            Bug ID: 20894
           Summary: clang-cl doesn't properly handle the -o flag
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ehsan at mozilla.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I know that clang-cl ignores -o completely, but now I'm running into a weird
situation that I can't fig myself out of.  Here, we're passing the ASAN
libraries on the command line to clang-cl without -c.  It gets the output
filename wrong by thinking that it should be derived from the input library,
and it passes the wrong -out: flag to the linker which completely confuses it:

$ clang-cl -o conftest -Z7 -fallback -fsanitize=address 
clang_rt.asan_dynamic-i386.lib clang_rt.asan_uar_thunk-i386.lib conftest.c
clang-cl.exe: warning: argument unused during compilation: '-o conftest'
LINK : fatal error LNK1149: output filename matches input filename
'c:\moz\fallback\clang_rt.asan_dynamic-i386.lib'
clang-cl.exe: error: linker command failed with exit code 1149 (use -v to see
invocation)

$ clang-cl -o conftest -Z7 -fallback -fsanitize=address 
clang_rt.asan_dynamic-i386.lib clang_rt.asan_uar_thunk-i386.lib conftest.c -###
clang version 3.6.0
Target: i686-pc-windows-msvc
Thread model: posix
clang-cl.exe: warning: argument unused during compilation: '-o conftest'
 "c:\\moz\\llvm-objdir\\bin\\clang-cl.exe" "-cc1" "-triple"
"i686-pc-windows-msvc" "-emit-obj" "-mrelax-all" "-disable-free"
"-main-file-name" "conftest.c" "-mrelocation-model" "static"
"-mdisable-fp-elim" "-relaxed-aliasing" "-fmath-errno" "-masm-verbose"
"-mconstructor-aliases" "-munwind-tables" "-target-cpu" "pentium4" "-D_MT"
"--dependent-lib=libcmt" "--dependent-lib=oldnames" "-fdiagnostics-format"
"msvc-fallback" "-gline-tables-only" "-dwarf-column-info" "-resource-dir"
"c:\\moz\\llvm-objdir\\bin\\..\\lib\\clang\\3.6.0" "-internal-isystem"
"c:\\moz\\llvm-objdir\\bin\\..\\lib\\clang\\3.6.0\\include" "-internal-isystem"
"C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\INCLUDE"
"-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio
11.0\\VC\\ATLMFC\\INCLUDE" "-internal-isystem" "C:\\Program Files
(x86)\\Windows Kits\\8.0\\include\\shared" "-internal-isystem" "C:\\Program
Files (x86)\\Windows Kits\\8.0\\include\\um" "-internal-isystem" "C:\\Program
Files (x86)\\Windows Kits\\8.0\\include\\winrt" "-fdebug-compilation-dir"
"c:\\moz\\fallback" "-ferror-limit" "19" "-fmessage-length" "152"
"-fsanitize=address"
"-fsanitize-blacklist=c:\\moz\\llvm-objdir\\bin\\..\\lib\\clang\\3.6.0\\asan_blacklist.txt"
"-mstackrealign" "-fms-extensions" "-fms-compatibility"
"-fms-compatibility-version=17.00" "-fdelayed-template-parsing"
"-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o"
"C:/Users/EHSANA~1/AppData/Local/Temp\\conftest-0ff154.obj" "-x" "c"
"conftest.c" || "c:\\Program Files (x86)\\Microsoft Visual Studio
11.0\\VC\\BIN\\cl.exe" "/nologo" "/c" "/W0" "/Z7" "/Tc" "conftest.c"
"/FoC:/Users/EHSANA~1/AppData/Local/Temp\\conftest-0ff154.obj"
 "c:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\BIN\\link.exe"
"-out:clang_rt.asan_dynamic-i386.exe" "-nologo" "-debug" "-debug"
"-incremental:no"
"c:\\moz\\llvm-objdir\\bin\\..\\lib\\clang\\3.6.0\\lib\\windows\\clang_rt.asan-i386.lib"
"c:\\moz\\llvm-objdir\\bin\\..\\lib\\clang\\3.6.0\\lib\\windows\\clang_rt.asan_cxx-i386.lib"
"clang_rt.asan_dynamic-i386.lib" "clang_rt.asan_uar_thunk-i386.lib"
"C:/Users/EHSANA~1/AppData/Local/Temp\\conftest-0ff154.obj"


Should we add proper support for -o?  Or somehow differentiate between .lib and
.c files, and don't construct -out: arguments to the linker from the former?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140910/a762eabf/attachment.html>