[LLVMbugs] [Bug 21589] New: clang-cl.exe does not reproduce semantic of cl.exe's /Fo switch correctly

[bugzilla-daemon at llvm.org]

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

            Bug ID: 21589
           Summary: clang-cl.exe does not reproduce semantic of cl.exe's
                    /Fo switch correctly
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: frerich.raabe+llvmbug at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Overview
--------
The clang-cl.exe driver as shipped with clang version 3.6.0 (221592) does not
reproduce the semantic of the /Fo switch correctly.

How to Reproduce
----------------
1. Create a source file 'x.cpp' containing just

    void f() {}

2. Compile the source file by running

    clang-cl /c /Fo x.cpp

Actual Results
--------------
clang-cl.exe prints an error message saying

  clang-cl.exe: error: argument to '/Fo' is missing (expected 1 value)

Expected Results
----------------
clang does not print any output. Instead, it compiles the given source file,
and writes an object file with the default name -- x.obj

Build Date & Platform
---------------------
clang version 3.6.0 (221592)
Target: i686-pc-windows-msvc
Thread model: posix

Additional Information
----------------------
Contrary to what the MSDN documentation and the "cl.exe /help" output says, the
/Fo switch (which can be used to define the name of the output file) does *not*
require an argument. If no argment is given, the default name will be used
(i.e. it appears to behave as if /Fo was not specified at all).

This differene in behaviour unfortunately breaks using clang-cl as a drop-in
replacement for cl for setups which rely on compiler invocations to work even
if no argument to /Fo is given.

-- 
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/20141117/bde69447/attachment.html>