Hi Reid, thanks for the very useful feedback and sorry for the late reply...
On Tue, Apr 1, 2014 at 4:18 AM, Reid Kleckner <[email protected]> wrote: > Whoops, missed this over vacation. My intention was to conditionalize this > on the driver mode, i.e. clang-cl or gcc-style, but that computation happens > further down, so I never got to this. > > The big question is, which syntax does mingw gcc understand? If it's the > libiberty style escaping, then the ifdef won't work, since clang could be > either mingw gcc or MSVC's cl depending on argv[0]. So, I just tried mingw (mingw32-gcc - gcc version 4.8.1) on a windows host. Unfortunately, when expanding response files, mingw seems to understand a different syntax than MSVC's cl. Example 1: //----- test.c -- int a; //----- //-- response.txt -- -I.\ //----- c:\> mingw32-gcc.exe -v @response.txt test.c produces the following verbose output: COLLECT_GCC_OPTIONS='-v' '-I' '. ' Example 2: //-- response.txt -- -I.\ -I.\ //----- I get the following output: COLLECT_GCC_OPTIONS='-v' '-I' '. -I.' Example 3: //-- response.txt -- -I.\ test.c //----- c:\> mingw32-gcc.exe @response.txt mingw32-g++.exe: fatal error: no input files compilation terminated. Instead, MSVC correctly compiles this last example. In conclusion, my solution based on the ifdef LLVM_ON_WIN32 would only be compliant with what MSVC's cl does; it would not work if we want to be compliant with mingw. -Andrea > > > On Mon, Mar 31, 2014 at 6:54 PM, Andrea Di Biagio > <[email protected]> wrote: >> >> ping. >> >> Any feedback would be appreciated. >> Thanks! >> >> On Thu, Mar 20, 2014 at 3:04 PM, Andrea Di Biagio >> <[email protected]> wrote: >> > ping. >> > >> > On Fri, Mar 14, 2014 at 11:14 AM, Andrea Di Biagio >> > <[email protected]> wrote: >> >> Hi, >> >> >> >> This patch teaches the driver how to use function >> >> 'llvm::cl::TokenizeWindowsCommandLine' to correctly parse response >> >> files on Windows. >> >> >> >> Microsoft defines specific rules for parsing c/c++ command-line >> >> arguments here: http://msdn.microsoft.com/en-us/library/17w5ykft.aspx >> >> . >> >> Those rules are currently implemented by function >> >> TokenizeWindowsCommandLine in llvm "lib/Support/CommandLine.cpp". >> >> >> >> However, the clang driver doesn't call that method when the host is >> >> WIN32. Instead, we always call function >> >> llvm::cl::TokenizeGNUCommandLine. >> >> >> >> This is problematic, for example, when we have backslashes in a >> >> response file (see test backslash-in-response-file.c in the patch). >> >> >> >> This patch also adds XFAIL win32 to the driver test Driver/at_file.c. >> >> That test verifies that the driver correctly expands arguments >> >> surrounded by single quotes. On Windows, that test would start failing >> >> because, single quotation marks cannot be used to identify single >> >> arguments. >> >> >> >> The fix for Driver/at_file.c is probably not ideal. Adding XFAIL win32 >> >> means that the test would be an expected failure if the target triple >> >> contains 'win32'. This is ok in general if both host and target are >> >> the same (i.e. we are not testing a cross-compiler). This is a problem >> >> however for cross compilers where the host is win32 but the target is >> >> not win32. >> >> >> >> At the moment there is no way to tell lit that the test should fail >> >> based on the information of the host platform (and not only on the >> >> target triple). I have an idea about how to improve LIT and >> >> consequently test Driver/at_file.c. If ok, I plan to send another >> >> patch for improving it. >> >> >> >> Please let me know if this patch is ok to submit. >> >> >> >> Thanks in advance, >> >> >> >> Andrea Di Biagio >> >> SN Systems - Sony Computer Entertainment Group >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
