[llvm-bugs] [Bug 51997] New: clang-cl /clang: flag causes incorrect crash reproducer comments

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51997

            Bug ID: 51997
           Summary: clang-cl /clang: flag causes incorrect crash
                    reproducer comments
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

$ cat crash.c
#pragma clang __debug crash
$ rm /tmp/crash*
$ out/gn/bin/clang-cl /clang:-ffp-contract=off -c crash.c -Werror
...
$ grep Driver /tmp/crash-*.sh
# Driver args: "--driver-mode=cl" "/clang:-ffp-contract=off" "-c" "crash.c"
"-Werror" "-ffp-contract=off"


Note that "-ffp-contract=off" is present twice, once as (correct) /clang: flag
and once without it. Running this driver command as-is errors out like you'd
expect:

$ out/gn/bin/clang -Werror "--driver-mode=cl" "/clang:-ffp-contract=off" "-c"
"crash.c" "-Werror" "-ffp-contract=off"
clang: error: unknown argument ignored in clang-cl: '-ffp-contract=off'
[-Werror,-Wunknown-argument]


The reason for this bug is that clang/lib/Driver/Driver.cpp implements
OPT__SLASH_clang by appending flags to the argument list. That causes this bug
(the crash report code just writes out the argument list), and possibly others
issues (bug 41308, bug 42501).


Maybe a better approach for implementing /clang: is to make it replace the
/clang: flag with a new Arg object that points to the original /clang: flag as
an alias. Then everything should work with the existing alias infrastructure.

ArgList doesn't have a replaceArg() method yet, but that should be reasonably
easy to add.

It'd mean we'd want to interpret each /clang: flag standalone, so things like
`/clang:-fdebug-compilation-dir /clang:.` wouldn't work, you'd have to say
`'/clang:-fdebug-compilation-dir .'`. But that seems like it should be fine.

It'd also have the effect that /clang: flags would take effect at the place
where they are in the command line, and not after all non clang-flags. That is,
`/clang:-fsanitize=address -fno-sanitize` would result in sanitizers being off
instead of it being on like currently. That even seems like a progresion.

-- 
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/20210928/fd09350c/attachment.html>