On 21.09.2019 16:53, Jakub Jelinek wrote: > On Fri, Sep 20, 2019 at 10:45:42PM +0200, Kamil Rytarowski wrote: >> GCC version of https://reviews.llvm.org/D67719 >> >> From 422827582d84e078df2a8e303d807c830a155ab5 Mon Sep 17 00:00:00 2001 >> From: Kamil Rytarowski <n...@gmx.com> >> Date: Fri, 20 Sep 2019 22:02:09 +0200 >> Subject: [PATCH] 2019-09-20 Kamil Rytarowski <n...@gmx.com> >> >> * cppbuiltin.c (define_builtin_macros_for_compilation_flags): Add new >> builtin __SANITIZE_LEAK__ macros for fsanitize=leak switch. >> * doc/cpp.texi: Document new macros. >> >> * c-c++-common/lsan/sanitize-leak-macro.c: New test. > > And this looks even more pointless. -fsanitize=leak generally isn't a > compiler option, just a linker option,
This is wrong. -fsanitize=leak IS a compiler option. > but a patch like this would make it a > compiler option too. There are no code changes with -fsanitize=leak, just > linking arranges a malloc etc. replacement that traces the leaks. > I am aware about its implementation as I ported LSan to NetBSD. > Jakub > The same argument applies here as in the UBSan patch. Here we have got a special use-case to use standalone LSan on NetBSD we we run whole userland sanitization and ASan is much more fragile (largely due to its incompleteness in interceptors). This ifdef is also scheduled to be included in public system headers.
signature.asc
Description: OpenPGP digital signature
