aboutsummaryrefslogtreecommitdiff
path: root/flang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorNico Weber <thakis@chromium.org>2022-10-04 15:53:18 -0400
committerNico Weber <thakis@chromium.org>2022-10-04 16:47:07 -0400
commit062c660dbfa81a742440cec49446fe81fc7d0114 (patch)
treede6622a6f38c0838af11d8411c201b4e2b4b0e57 /flang/lib/Frontend/CompilerInvocation.cpp
parent2e91a5f546ad0d934e9619222983efe230b344b6 (diff)
downloadllvm-062c660dbfa81a742440cec49446fe81fc7d0114.zip
llvm-062c660dbfa81a742440cec49446fe81fc7d0114.tar.gz
llvm-062c660dbfa81a742440cec49446fe81fc7d0114.tar.bz2
[lld/mac] With -demangle, strip leading _ from non-mangled names
For void f(); int main() { f(); } `lld -demangle` now produces ld64.lld: error: undefined symbol: f >>> referenced by path/to/main.o:(symbol main+0x8) instead of ld64.lld: error: undefined symbol: _f >>> referenced by path/to/main.o:(symbol _main+0x8) previously. (Without `-demangle`, it still prints `_f` and `_main`.) This does *not* match ld64's behavior, but it does match e.g. lld/COFF's behaviour. This is arguably easier to understand: clang prepends symbol names with `_` on macOS, so it seems friendly if the linker removes it again in its diagnostics. It also makes the `extern "C"` insertion diagnostics we added recently look more self-consistent. Differential Revision: https://reviews.llvm.org/D135189
Diffstat (limited to 'flang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions