libtool inspects the output of $CC -v to detect what object files and libraries are linked in by default. When clang is built as a native windows executable, all paths are formatted with backslashes, and the backslashes cause each argument to be enclosed in quotes. The backslashes and quotes break further processing within libtool (which is implemented in shell script, running in e.g. msys) pretty badly.
Between unix style pathes (that only work in tools that are linked to the msys runtime, essentially the same as cygwin) and proper windows style paths (with backslashes, that can easily break shell scripts and msys environments), the best compromise is to use windows style paths (starting with e.g. c:) but with forward slashes, which both msys based tools, shell scripts and native windows executables can cope with. This incidentally turns out to be the form of paths that GCC prints out when run with -v on windows as well.
This change potentially makes the output from clang -v a bit more inconsistent, but it is isn't necessarily very consistent to begin with.
This is blindly treating every argument as if it were a path. I can imagine someone wanting to define a macro to a string value containing backslashes, such as: -DAWESOME_MACRO="\"asdf\""
Given that this is used for -### and crash diagnostic printing, I'm hesitant to do this here. I think it might be better to, in a cygming environment, try to convert all our paths to forward slashes before we add them to the command line.