[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

https://github.com/eugenis closed https://github.com/llvm/llvm-project/pull/72933 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

@@ -973,11 +973,58 @@ // RUN: not %clang --target=x86_64-sie-ps5 -fsanitize=kcfi %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-KCFI // RUN: not %clang --target=x86_64-sie-ps5 -fsanitize=function -fsanitize=kcfi %s -### 2>&1 | FileCheck %s

[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

@@ -491,3 +491,26 @@ void baremetal::Linker::ConstructJob(Compilation , const JobAction , JA, *this, ResponseFileSupport::AtFileCurCP(), Args.MakeArgString(TC.GetLinkerPath()), CmdArgs, Inputs, Output)); } + +SanitizerMask BareMetal::getSupportedSanitizers() const

[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

https://github.com/eugenis updated https://github.com/llvm/llvm-project/pull/72933 >From f665e96f5a941c45591281d66c69f289aa641985 Mon Sep 17 00:00:00 2001 From: Evgenii Stepanov Date: Mon, 20 Nov 2023 16:54:24 -0800 Subject: [PATCH 1/2] Allow multiple sanitizers on baremetal targets.

[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

https://github.com/eugenis created https://github.com/llvm/llvm-project/pull/72933 Baremetal targets tend to implement their own runtime support for sanitizers. Clang driver gatekeeping of allowed sanitizer types is counter productive. This change allows anything that does not crash and burn

[clang] 8d3c960 - Revert "[clang][dataflow] Store DeclContext of block being analysed in Environment if available."

Author: Evgenii Stepanov Date: 2022-08-10T14:22:04-07:00 New Revision: 8d3c9602959df4caadfade1f40512231f7d6bbe8 URL: https://github.com/llvm/llvm-project/commit/8d3c9602959df4caadfade1f40512231f7d6bbe8 DIFF:

[clang] 7587065 - Revert "[clang][dataflow] Analyze constructor bodies"

Author: Evgenii Stepanov Date: 2022-08-10T14:21:56-07:00 New Revision: 75870650433de9e7bfbe86adc1bef2f2a23fe7a3 URL: https://github.com/llvm/llvm-project/commit/75870650433de9e7bfbe86adc1bef2f2a23fe7a3 DIFF:

[clang] 26089d4 - Revert "[clang][dataflow] Don't crash when caller args are missing storage locations"

Author: Evgenii Stepanov Date: 2022-08-10T14:21:46-07:00 New Revision: 26089d4da489dc17711213f917779e480a78ed51 URL: https://github.com/llvm/llvm-project/commit/26089d4da489dc17711213f917779e480a78ed51 DIFF:

[clang] a730b6a - [NFC] clang-format one function.

Author: Evgenii Stepanov Date: 2022-02-11T15:00:29-08:00 New Revision: a730b6a41ad7e57a015c4a310850b14513ecb70c URL: https://github.com/llvm/llvm-project/commit/a730b6a41ad7e57a015c4a310850b14513ecb70c DIFF:

[clang] 66cf68e - [docs] Update ControlFlowIntegrity.rst.

Author: Evgenii Stepanov Date: 2020-10-02T12:01:05-07:00 New Revision: 66cf68ed46789217a8382bb419a0bda1c4e97650 URL: https://github.com/llvm/llvm-project/commit/66cf68ed46789217a8382bb419a0bda1c4e97650 DIFF:

[clang] b4aa71e - Allow -fsanitize-minimal-runtime with memtag sanitizer.

Author: Evgenii Stepanov Date: 2020-05-07T13:07:46-07:00 New Revision: b4aa71e1bd9aaee377e0ea22cf60a5857e570733 URL: https://github.com/llvm/llvm-project/commit/b4aa71e1bd9aaee377e0ea22cf60a5857e570733 DIFF:

[clang] 2a3723e - [memtag] Plug in stack safety analysis.

Author: Evgenii Stepanov Date: 2020-03-16T16:35:25-07:00 New Revision: 2a3723ef114d467179d463539dd73974b87ccf85 URL: https://github.com/llvm/llvm-project/commit/2a3723ef114d467179d463539dd73974b87ccf85 DIFF:

Re: [clang] 522ee29 - Allow newlines in AST Matchers in clang-query files

Reverted in https://github.com/llvm/llvm-project/commit/5ca97d0defeed38feec2352692f6bb80297d6712 On Thu, Dec 26, 2019 at 12:41 PM Stephen Kelly via cfe-commits wrote: > > > Author: Stephen Kelly > Date: 2019-12-26T20:40:33Z > New Revision: 522ee29a4fb3814db604b585c8637247477ec057 > > URL: >

[clang-tools-extra] 5ca97d0 - Revert "Allow newlines in AST Matchers in clang-query files" + 1

Author: Evgenii Stepanov Date: 2019-12-26T18:07:20-08:00 New Revision: 5ca97d0defeed38feec2352692f6bb80297d6712 URL: https://github.com/llvm/llvm-project/commit/5ca97d0defeed38feec2352692f6bb80297d6712 DIFF:

Re: r372919 - [clang-format] Modified SortIncludes and IncludeCategories to priority for sorting #includes within the Group Category.

Hi, this change breaks the build with /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/clang/lib/Format/Format.cpp:737:44: error: missing field 'SortPriority' initializer [-Werror,-Wmissing-field-initializers] {"^\"(llvm|llvm-c|clang|clang-c)/", 2},

Re: r372903 - [Mangle] Add flag to asm labels to disable '\01' prefixing

FYI I've fixed a memory leak in the new test in r372925. On Wed, Sep 25, 2019 at 10:58 AM Vedant Kumar via cfe-commits wrote: > > Author: vedantk > Date: Wed Sep 25 11:00:31 2019 > New Revision: 372903 > > URL: http://llvm.org/viewvc/llvm-project?rev=372903=rev > Log: > [Mangle] Add flag to asm

Re: r366123 - ARM MTE stack sanitizer.

I could not reproduce this on Linux nor on Mac. I wonder if triggering a clean build would help? I don't see a way to do that though. On Tue, Jul 16, 2019 at 10:50 AM Evgenii Stepanov wrote: > > Hi, > > thanks for letting me know! Is this reproducible on Linux? It is > possible to extract a

Re: r366123 - ARM MTE stack sanitizer.

Hi, thanks for letting me know! Is this reproducible on Linux? It is possible to extract a reproducer from the bot? On Mon, Jul 15, 2019 at 9:30 PM Amara Emerson wrote: > > Hi Evgeniy, > > This commit looks like it broke the lldb bot: > http://green.lab.llvm.org/green/job/lldb-cmake/31011/ > >

Re: r349054 - Make -Wstring-plus-int warns even if when the result is not out of bounds

Hi, this broke Clang :: SemaCXX/constant-expression-cxx1y.cpp: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/9144 error: 'warning' diagnostics seen but not expected: File

Re: r336590 - [libclang] evalute compound statement cursors before trying to evaluate

Reverting... On Mon, Jul 9, 2018 at 8:18 PM, Vlad Tsyrklevich wrote: > The ASan bot is failing with a LeakSanitizer failure that appears related to > one of your libclang changes: > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/6282/steps/check-clang%20asan/logs/stdio

Re: r334650 - Implement constexpr __builtin_*_overflow

Discovered by MemorySanitizer, btw. On Tue, Jul 3, 2018 at 12:59 PM, Evgenii Stepanov wrote: > Hi, > > with this change, the following compiles to "ret i32 undef": > > int main(int argc, char **argv) { > > constexpr int x = 1; > > constexpr int y = 2; > > int z; > > > >

Re: r334650 - Implement constexpr __builtin_*_overflow

Hi, with this change, the following compiles to "ret i32 undef": int main(int argc, char **argv) { constexpr int x = 1; constexpr int y = 2; int z; __builtin_sadd_overflow(x, y, ); return z; } On Wed, Jun 13, 2018 at 1:43 PM, Erich Keane via cfe-commits <

Re: [clang-tools-extra] r331905 - [tools] Updating PPCallbacks::InclusionDirective calls

HI, ASan says there is a use-after-free after this change: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/5410/steps/check-clang%20asan/logs/stdio MSan also sees a problem, but ASan's is likely closer to the root cause:

Re: [clang-tools-extra] r320486 - [clangd] Introduce a "Symbol" class.

Hi, this does not compile for me because of a tag mismatch: clang-tools-extra/clangd/index/Index.h:52:10: error: class 'DenseMapInfo' was previously declared as a struct [-Werror,-Wmismatched-tags] friend class llvm::DenseMapInfo; On Tue, Dec 12, 2017 at 7:42 AM, Haojian Wu via cfe-commits

Re: r312467 - Implement Itanium name mangling support for C++ Modules TS.

Hi Richard, this change has triggered a bunch of leak reports on the sanitizer bots: Direct leak of 1824 byte(s) in 1 object(s) allocated from: #0 0xb48430 in operator new(unsigned long)

Re: r309226 - Headers: improve ARM EHABI coverage of unwind.h

No. I don't have a easy way of reproducing this. On Tue, Aug 22, 2017 at 11:10 AM, Hans Wennborg wrote: > Is there a bug filed? Since this was merged to 5.0.0, I'd like to know > if we broke something and if that is something that needs to be fixed. > > On Tue, Aug 22, 2017 at

Re: r309226 - Headers: improve ARM EHABI coverage of unwind.h

As I understand, using compiler-rt as libgcc replacement on ARM is currently broken because of this change, but I have not looked since my last message. On Mon, Aug 21, 2017 at 4:56 PM, Hans Wennborg wrote: > Is there something we need for 5.0.0 here? > > On Sat, Aug 12, 2017

Re: [clang-tools-extra] r311020 - [clang-tidy] Use CloexecCheck as base class.

Hi, this change breaks build: clang-tools-extra/clang-tidy/android/CloexecSocketCheck.cpp:20:30: error: unused variable 'SOCK_CLOEXEC' [-Werror,-Wunused-const-variable] static constexpr const char *SOCK_CLOEXEC = "SOCK_CLOEXEC"; Please test with LLVM_ENABLE_WERROR=ON before submitting! On Wed,

Re: r309226 - Headers: improve ARM EHABI coverage of unwind.h

Hi, I've noticed that the code in compiler-rt/lib/builtins/gcc_personality_v0.c refers to _Unwind_Exception as "struct _Unwind_Exception". With this change, it is not a struct anymore on ARM. Should that code be fixed, or is it a problem in this change?

Re: r306692 - Initialize variable and silence potentially uninitialized warning.

This change broke clang/ubsan bot. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/6047/steps/check-clang%20ubsan/logs/stdio It looks like the value you are initializing SavedAK with may itself be uninitialized? I see a few constructors that do not mention it. On Thu, Jun

Re: r305087 - support operator keywords used in Windows SDK

Hi, http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5571/steps/check-clang%20ubsan/logs/stdio tools/clang/lib/Parse/ParseExprCXX.cpp:383:26: runtime error: reference binding to null pointer of type 'clang::IdentifierInfo' #0 0x5313046 in

Re: r304935 - Revert r304929 [mips] Add runtime options to enable/disable madd/sub.fmt

You've left an empty file in test/CodeGen/mips-madd4.c On Wed, Jun 7, 2017 at 11:57 AM, Petar Jovanovic via cfe-commits wrote: > Author: petarj > Date: Wed Jun 7 13:57:56 2017 > New Revision: 304935 > > URL: http://llvm.org/viewvc/llvm-project?rev=304935=rev > Log: >

Re: r304726 - Rather than rejecting attempts to run preprocessor-only actions on AST files,

This change leaks memory: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5453/steps/check-clang%20asan/logs/stdio On Mon, Jun 5, 2017 at 11:10 AM, Richard Smith via cfe-commits wrote: > Author: rsmith > Date: Mon Jun 5 13:10:11 2017 > New

Re: r304017 - CodeGen: Define Swift's legal vector types for AArch64, ARM

But I do not even have this change in my local checkout. Must be something else. On Fri, May 26, 2017 at 2:33 PM, Evgenii Stepanov wrote: > I've got the same failure locally w/o MSan, in a regular > release+assertions build on linux x86_64. > > On Fri, May 26, 2017 at

Re: r304017 - CodeGen: Define Swift's legal vector types for AArch64, ARM

I've got the same failure locally w/o MSan, in a regular release+assertions build on linux x86_64. On Fri, May 26, 2017 at 2:15 PM, Vitaly Buka via cfe-commits wrote: > Could this be the patch >

Re: [libcxx] r302723 - XFAIL is_trivially_copyable test for compilers that don't implement Core 2094

No, sorry, this is not ToT. This is r298531, which already self identifies as clang-5.0, but, apparently, does not implement Core 2094. I'll just upgrade. On Fri, May 19, 2017 at 1:27 PM, Evgenii Stepanov wrote: > Hi, > > this test is failing for me with ToT clang

Re: [libcxx] r302723 - XFAIL is_trivially_copyable test for compilers that don't implement Core 2094

Hi, this test is failing for me with ToT clang (clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn). All the failing static_assert's mention volatile one way or the other. On Wed, May 10, 2017 at 1:19 PM, Eric Fiselier via cfe-commits wrote: > Author: ericwf > Date:

Re: r301449 - PPCallbacks::MacroUndefined, change signature and add test.

Please change the signature of all overriding definitions as well. /code/llvm/tools/clang/lib/CodeGen/MacroPPCallbacks.h:114:50: error: non-virtual member function marked 'override' hides virtual member function const MacroDefinition ) override;

Re: r297298 - [ubsan] Detect UB loads from bitfields

Thank you, that was quick! On Wed, Mar 8, 2017 at 4:31 PM, Vedant Kumar wrote: > Reverted in r297331. > > vedant > >> On Mar 8, 2017, at 4:25 PM, Evgenii Stepanov >> wrote: >> >> This is crashing ubsan bootstrap: >> >>

Re: r297298 - [ubsan] Detect UB loads from bitfields

This is crashing ubsan bootstrap: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/962/steps/build%20clang%2Fubsan/logs/stdio clang-5.0: /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Instructions.h:1110: void

Re: [libunwind] r292721 - DWARF: convert error logs to _LIBUNWIND_LOG

Actually, the bot has been red since Jan 21 with this exact error. On Thu, Jan 26, 2017 at 2:27 PM, Evgenii Stepanov wrote: > Hi, > > I'm not sure why we only see this now, but this change is breaking > llvm bootstrap with -Werror: >

Re: [libunwind] r292721 - DWARF: convert error logs to _LIBUNWIND_LOG

Hi, I'm not sure why we only see this now, but this change is breaking llvm bootstrap with -Werror: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/732/steps/bootstrap%20clang/logs/stdio llvm/projects/libunwind/src/config.h:90:41: error: token pasting of ',' and __VA_ARGS__ is a

Re: r291179 - Add vec_insert4b and vec_extract4b functions to altivec.h

Tests on linux/x86_64 are failing with: fatal error: error in backend: Cannot select: intrinsic %llvm.ppc.vsx.xxinsertw On Thu, Jan 5, 2017 at 1:43 PM, Sean Fertile via cfe-commits wrote: > Author: sfertile > Date: Thu Jan 5 15:43:30 2017 > New Revision: 291179 > >

Re: [libcxx] r289963 - [CMake] Put headers relative to clang

FTR, buildbot logs: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/2585/steps/test%20tsan%20in%20debug%20compiler-rt%20build/logs/stdio External project cmake error log: CMake Error at include/CMakeLists.txt:15 (file): file COPY cannot make directory

Re: [libcxx] r289963 - [CMake] Put headers relative to clang

Hi, this is using LLVM_BINARY_DIR when NOT LIBCXX_USING_INSTALLED_LLVM. HandleOutOfTreeLLVM.cmake defines LLVM_BINARY_DIR only when LIBCXX_USING_INSTALLED_LLVM. Is it supposed to come from the user cmake arguments? This broke sanitizer tests on Linux (check-tsan, check-msan). See

Re: [PATCH] D26422: Revert "Define __ANDROID_API__ for all Android builds."

Yes, some bots don't build all the targets. I think the test should go into Preprocessor/init.c. On Tue, Nov 8, 2016 at 2:07 PM, Stephen Hines wrote: > srhines added a comment. > > Reverted because this broke builds: > > clang-hexagon-elf >

Re: r284960 - [analyzer] Add StdLibraryFunctions checker.

This code also fails with UBSan: tools/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:285:62: runtime error: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long' #0 0x5e1642f in (anonymous

Re: [PATCH] D20561: Warn when taking address of packed member

On Mon, Jun 13, 2016 at 4:12 PM, Aaron Ballman wrote: > On Mon, Jun 13, 2016 at 6:30 PM, Evgeniy Stepanov wrote: >> eugenis added a subscriber: eugenis. >> eugenis added a comment. >> >> In http://reviews.llvm.org/D20561#446031, @aaron.ballman wrote:

Re: r270039 - [Sema] Allow an external sema source to handle delayed typo corrections.

Looks like this commit broke the bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux- bootstrap/builds/11738/steps/check-clang%20ubsan/logs/stdio On Thu, May 19, 2016 at 3:52 AM, Benjamin Kramer via cfe-commits wrote: > Author: d0k > Date: Thu May 19

Re: r266005 - Allow simultaneous safestack and stackprotector attributes.

Thanks, fixed in r266095 On Tue, Apr 12, 2016 at 10:15 AM, Robinson, Paul wrote: > > >> -Original Message- >> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of >> Evgeniy Stepanov via cfe-commits >> Sent: Monday, April 11, 2016

Re: r263429 - [Frontend] Disable value name discarding for all sanitizers.

On Mon, Mar 14, 2016 at 8:48 AM, Benjamin Kramer wrote: > On Mon, Mar 14, 2016 at 3:59 PM, David Blaikie wrote: >> Yeah - how are they relying on them in a non-asserts build anyway? (were we >> naming certain things regardless of +/-Asserts? (well, I know

Re: [libcxx] r260431 - Recommit r260012 - Cleanup node-type handling in the unordered containers.

Thank you! On Wed, Feb 17, 2016 at 9:23 PM, Eric Fiselier wrote: > Hopefully fixed in r261180. > > On Sat, Feb 13, 2016 at 2:08 PM, Evgenii Stepanov > wrote: >> >> Hi, >> >> this is my error message: >> >> In file included from z.cc:1: >>

Re: [libcxx] r260431 - Recommit r260012 - Cleanup node-type handling in the unordered containers.

Hi, this is my error message: In file included from z.cc:1: /code/build-llvm/bin/../include/c++/v1/ext/hash_map:213:5: warning: Use of the header is deprecated. Migrate to [-W#warnings] # warning Use of the header is deprecated. Migrate to ^

Re: [libcxx] r260431 - Recommit r260012 - Cleanup node-type handling in the unordered containers.

Hi, hash_map still looks broken to me. I don't have a simple reproducer, but these declarations in __hash_table: template class _LIBCPP_TYPE_VIS_ONLY __hash_map_iterator; template class _LIBCPP_TYPE_VIS_ONLY __hash_map_const_iterator; should not they be prefixed with __gnu_cxx:: ? Clang

Re: r258128 - Add -Wexpansion-to-undefined: warn when using `defined` in a macro definition.

This broke all WERROR bots. Sounds like this warning should be disabled by default. On Tue, Jan 19, 2016 at 8:15 AM, Krzysztof Parzyszek via cfe-commits wrote: > This generates hundreds of warnings when doing check-all. > > Here's the offending code: > > >

Re: [libcxx] r255177 - Remove visibility attributes from out-of-class method definitions in iostreams.

Reverted in r257193. On Fri, Jan 8, 2016 at 11:12 AM, Evgenii Stepanov wrote: > On Fri, Jan 8, 2016 at 11:02 AM, Duncan P. N. Exon Smith > wrote: >> >>> On 2016-Jan-08, at 10:49, Nico Weber via cfe-commits >>> wrote:

Re: [libcxx] r255177 - Remove visibility attributes from out-of-class method definitions in iostreams.

On Fri, Jan 8, 2016 at 11:02 AM, Duncan P. N. Exon Smith wrote: > >> On 2016-Jan-08, at 10:49, Nico Weber via cfe-commits >> wrote: >> >> On OS X 10.8, __ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc >> (and others) are a hidden

Re: Some buildbot statistics for the last week

Permanently failing bots are way better that 50/50 flaky bots, but still not good. As for the sanitizer-x86_64-linux-bootstrap, it shows some legitimate failures in different parts of llvm that no one bothered to fix. That's kinda understandable because MSan failures are hard to reproduce locally

Re: [libcxx] r250256 - Workaround -pedantic flag added by LLVM

Guess what this does to the -Wno-pedantic flag added by MSan? :) On Tue, Oct 13, 2015 at 4:56 PM, Eric Fiselier via cfe-commits wrote: > Author: ericwf > Date: Tue Oct 13 18:56:33 2015 > New Revision: 250256 > > URL: http://llvm.org/viewvc/llvm-project?rev=250256=rev

Re: [libcxx] r250256 - Workaround -pedantic flag added by LLVM

It looks like, since libc++ removes -pedantic, we don't need to add -Wno-pedantic, so I can just fix it in MSan. It would probably make sense for libc++ to remove -Wno-pedantic before removing -pedantic. On Thu, Oct 15, 2015 at 12:57 PM, Evgenii Stepanov wrote: >

Re: r247494 - Always_inline codegen rewrite.

Thanks! On Mon, Sep 14, 2015 at 10:50 AM, Samuel F Antao wrote: > Hi Evgeniy, > > I commit a small change to one of the regression tests to allow a signext to > be generated: http://reviews.llvm.org/rL247584. > > It was causing an error in Power8 targets. In my view is an

Re: [PATCH] D12087: always_inline codegen rewrite

Thanks. I just reproduced it on release w/o asserts build and fixed locally. The other problem is fixed as well, I'll try re-landing now. I'll keep an eye on the bot later today and will revert again if necessary. On Fri, Sep 11, 2015 at 6:02 PM, H.J. Lu wrote: > On Fri,