Page MenuHomePhabricator
Feed Advanced Search

Yesterday

melver added a comment to D107085: tsan: introduce New/Alloc/Free helpers.

I've stared at this change more, but don't see anything that could have caused the failure. I am out of ideas now.
We could try:

  • race = New<ExpectRace>(); + race = Alloc(sizeof(ExpectRace));

but I don't see why it would help.

Fri, Jul 30, 11:03 AM · Restricted Project
melver accepted D107152: tsan: introduce Tid and StackID typedefs.
Fri, Jul 30, 8:56 AM · Restricted Project
melver added a comment to D107167: tsan: add new vector clock.

Review incomplete -- I'll need to look a bit at the rest of the (uncommitted) changes to understand the requirements. But if there are special requirements that aren't obvious, do let us know.

Fri, Jul 30, 8:42 AM · Restricted Project
melver added inline comments to D107152: tsan: introduce Tid and StackID typedefs.
Fri, Jul 30, 6:52 AM · Restricted Project
melver added inline comments to D107152: tsan: introduce Tid and StackID typedefs.
Fri, Jul 30, 6:50 AM · Restricted Project
melver committed rG4ab766591984: tsan: Support constructor arguments via New (authored by melver).
tsan: Support constructor arguments via New
Fri, Jul 30, 3:51 AM
melver closed D107147: tsan: Support constructor arguments via New.
Fri, Jul 30, 3:51 AM · Restricted Project
melver accepted D107149: tsan: fix another latent race size bug in test.
Fri, Jul 30, 3:46 AM · Restricted Project
melver added inline comments to D107085: tsan: introduce New/Alloc/Free helpers.
Fri, Jul 30, 3:40 AM · Restricted Project
melver added reviewers for D107147: tsan: Support constructor arguments via New: dvyukov, vitalybuka.
Fri, Jul 30, 3:32 AM · Restricted Project
melver requested review of D107147: tsan: Support constructor arguments via New.
Fri, Jul 30, 3:27 AM · Restricted Project
melver accepted D107131: tsan: fix latent race size bug in test.
Fri, Jul 30, 1:42 AM · Restricted Project
melver accepted D107085: tsan: introduce New/Alloc/Free helpers.
Fri, Jul 30, 1:20 AM · Restricted Project

Thu, Jul 29

melver accepted D107072: tsan: introduce LazyInitialize.
Thu, Jul 29, 8:12 AM · Restricted Project
melver accepted D107071: tsan: s/CHECK/DCHECK/ in tsan_interface_java.cpp.
Thu, Jul 29, 7:55 AM · Restricted Project
melver accepted D107069: tsan: restore Initialize call in Java entry points.
Thu, Jul 29, 7:13 AM · Restricted Project
melver accepted D107055: tsan: add another test for atomics.
Thu, Jul 29, 7:04 AM · Restricted Project
melver accepted D107050: tsan: add intrusive doubly-linked list.
Thu, Jul 29, 6:51 AM · Restricted Project
melver accepted D107043: sanitizer_common: remove BlockingMutex and RWMutex.
Thu, Jul 29, 3:06 AM · Restricted Project
melver accepted D107053: tsan: rename deadlock detector Mutex to UserMutex.
Thu, Jul 29, 3:05 AM · Restricted Project
melver accepted D107045: tsan: store ThreadRegistry in Context by value.

In that case, this makes sense.

Thu, Jul 29, 2:57 AM · Restricted Project
melver added inline comments to D107045: tsan: store ThreadRegistry in Context by value.
Thu, Jul 29, 2:44 AM · Restricted Project
melver added inline comments to D107043: sanitizer_common: remove BlockingMutex and RWMutex.
Thu, Jul 29, 2:29 AM · Restricted Project

Wed, Jul 28

melver added inline comments to D106953: tsan: increase max number of threads supported by test-only barrier.
Wed, Jul 28, 8:16 AM · Restricted Project
melver accepted D106954: tsan: improve lots_of_threads test.
Wed, Jul 28, 8:02 AM · Restricted Project
melver accepted D106953: tsan: increase max number of threads supported by test-only barrier.
Wed, Jul 28, 7:56 AM · Restricted Project
melver accepted D106952: tsan: extend signal_malloc test.
Wed, Jul 28, 7:40 AM · Restricted Project
melver accepted D106951: tsan: fix warnings in tests.
Wed, Jul 28, 7:36 AM · Restricted Project
melver accepted D106936: sanitizer_common: replace RWMutex/BlockingMutex with Mutex.
Wed, Jul 28, 5:58 AM · Restricted Project
melver accepted D106945: sanitizer_common: prohibit Mutex(LINKER_INITIALIZED).
Wed, Jul 28, 5:54 AM · Restricted Project
melver accepted D106944: sanitizers: switch BlockingMutex(LINKER_INITIALIZED) to Mutex.
Wed, Jul 28, 5:53 AM · Restricted Project
melver added inline comments to D106936: sanitizer_common: replace RWMutex/BlockingMutex with Mutex.
Wed, Jul 28, 2:45 AM · Restricted Project

Tue, Jul 27

melver accepted D106855: Revert "sanitizer_common: split LibIgnore into fast/slow paths".
Tue, Jul 27, 2:40 AM · Restricted Project

Fri, Jul 23

melver accepted D106638: tsan: fix SANITIZER_DEBUG build.
Fri, Jul 23, 1:54 AM · Restricted Project
melver accepted D106637: sanitizer_common: don't use [[no_unique_address]].

Right, this is only guaranteed to exist with C++20 or later. I guess we're not there yet.

Fri, Jul 23, 1:52 AM · Restricted Project

Thu, Jul 22

melver accepted D106546: sanitizer_common: add deadlock detection to the Mutex2.
Thu, Jul 22, 12:12 PM · Restricted Project
melver added inline comments to D106546: sanitizer_common: add deadlock detection to the Mutex2.
Thu, Jul 22, 11:06 AM · Restricted Project
melver added inline comments to D106546: sanitizer_common: add deadlock detection to the Mutex2.
Thu, Jul 22, 11:00 AM · Restricted Project
melver accepted D106379: tsan: switch to the new sanitizer_common mutex.
Thu, Jul 22, 10:53 AM · Restricted Project
melver accepted D106558: tsan: ignore interceptors in few more places.
Thu, Jul 22, 10:51 AM · Restricted Project
melver accepted D106547: tsan: rename test Mutex to UserMutex.
Thu, Jul 22, 10:51 AM · Restricted Project
melver added inline comments to D106546: sanitizer_common: add deadlock detection to the Mutex2.
Thu, Jul 22, 10:48 AM · Restricted Project
melver added inline comments to D106546: sanitizer_common: add deadlock detection to the Mutex2.
Thu, Jul 22, 10:47 AM · Restricted Project
melver accepted D106548: tsan: disable thread safety analysis in more functions.
Thu, Jul 22, 10:00 AM · Restricted Project
melver added inline comments to D106546: sanitizer_common: add deadlock detection to the Mutex2.
Thu, Jul 22, 9:53 AM · Restricted Project
melver accepted D106436: sanitizers: increase .clang-format columns to 100.
Thu, Jul 22, 12:17 AM · Restricted Project

Mon, Jul 19

melver accepted D106231: sanitizer_common: add new mutex.
Mon, Jul 19, 11:08 PM · Restricted Project
melver accepted D106275: tsan: add pragma line to buildgo.sh.
Mon, Jul 19, 8:27 AM · Restricted Project
melver accepted D106274: tsan: remove duplicate arch switch in buildgo.sh.
Mon, Jul 19, 8:11 AM · Restricted Project
melver accepted D106231: sanitizer_common: add new mutex.
Mon, Jul 19, 8:08 AM · Restricted Project
melver added inline comments to D106231: sanitizer_common: add new mutex.
Mon, Jul 19, 4:56 AM · Restricted Project
melver accepted D106046: tsan: make obtaining current PC faster.

Given this is x86-only now, hopefully there won't be any new surprises.

Mon, Jul 19, 2:48 AM · Restricted Project

Fri, Jul 16

melver accepted D106071: sanitizer_common: add Semaphore.
Fri, Jul 16, 9:45 AM · Restricted Project

Thu, Jul 15

melver added inline comments to D106078: sanitizer_common: allow multiple GET_CURRENT_PC() in a function.
Thu, Jul 15, 11:08 AM · Restricted Project
melver accepted D106078: sanitizer_common: allow multiple GET_CURRENT_PC() in a function.
Thu, Jul 15, 9:52 AM · Restricted Project
melver accepted D106048: tsan: lock ScopedErrorReportLock around fork.
Thu, Jul 15, 9:09 AM · Restricted Project
melver added inline comments to D106048: tsan: lock ScopedErrorReportLock around fork.
Thu, Jul 15, 6:06 AM · Restricted Project
melver accepted D106046: tsan: make obtaining current PC faster.
Thu, Jul 15, 5:56 AM · Restricted Project

Tue, Jul 13

melver accepted D105778: sanitizer_common: optimize memory drain.
Tue, Jul 13, 12:51 AM · Restricted Project

Mon, Jul 12

melver added a reviewer for D105829: sanitizer_common: Fix build for tests: vitalybuka.
Mon, Jul 12, 11:37 AM · Restricted Project
melver added inline comments to D105829: sanitizer_common: Fix build for tests.
Mon, Jul 12, 11:37 AM · Restricted Project
melver updated the diff for D105829: sanitizer_common: Fix build for tests.

Use temporary to build space-separated string of flags.

Mon, Jul 12, 11:36 AM · Restricted Project
melver added a comment to D105808: sanitizer_common: fix 32-bit build.

The same happened on another build bot:

https://lab.llvm.org/buildbot/#/builders/8/builds/1550

We need something like this:

diff --git a/compiler-rt/CMakeLists.txt b/compiler-rt/CMakeLists.txt
index 1610bbd2312a..21a36799ba30 100644
--- a/compiler-rt/CMakeLists.txt
+++ b/compiler-rt/CMakeLists.txt
@@ -366,7 +366,8 @@ if(CMAKE_CXX_COMPILER_ID MATCHES Clang)
       "-Werror=thread-safety-beta"
   )
   list(APPEND SANITIZER_COMMON_CFLAGS ${THREAD_SAFETY_FLAGS})
-  list(APPEND COMPILER_RT_TEST_COMPILER_CFLAGS ${THREAD_SAFETY_FLAGS})
+  string(APPEND COMPILER_RT_TEST_COMPILER_CFLAGS " ${THREAD_SAFETY_FLAGS}")
+  string(REPLACE ";" " " COMPILER_RT_TEST_COMPILER_CFLAGS "${COMPILER_RT_TEST_COMPILER_CFLAGS}")
 endif()

 # If we're using MSVC,

Because COMPILER_RT_TEST_COMPILER_CFLAGS is a string that is being appended to and not a list per usage elsewhere in the file.

Mon, Jul 12, 11:24 AM · Restricted Project
melver requested review of D105829: sanitizer_common: Fix build for tests.
Mon, Jul 12, 11:23 AM · Restricted Project
melver added a comment to D105808: sanitizer_common: fix 32-bit build.

The same happened on another build bot:

https://lab.llvm.org/buildbot/#/builders/8/builds/1550

Mon, Jul 12, 11:13 AM · Restricted Project
melver accepted D105778: sanitizer_common: optimize memory drain.
Mon, Jul 12, 10:13 AM · Restricted Project
melver added inline comments to D105778: sanitizer_common: optimize memory drain.
Mon, Jul 12, 10:09 AM · Restricted Project
melver accepted D105778: sanitizer_common: optimize memory drain.
Mon, Jul 12, 8:45 AM · Restricted Project
melver accepted D105808: sanitizer_common: fix 32-bit build.
Mon, Jul 12, 5:00 AM · Restricted Project
melver added inline comments to D105777: sanitizer_common: remove debugging logic from the internal allocator.
Mon, Jul 12, 3:21 AM · Restricted Project
melver accepted D105777: sanitizer_common: remove debugging logic from the internal allocator.
Mon, Jul 12, 3:20 AM · Restricted Project
melver accepted D105776: sanitizer_common: use 0 for empty stack id.

How did this not result in errors before?

Mon, Jul 12, 3:09 AM · Restricted Project
melver accepted D105775: sanitizer_common: make sem_trywait as non-blocking.
Mon, Jul 12, 2:58 AM · Restricted Project
melver accepted D105774: sanitizer_common: allow COMMON_INTERCEPTOR_ENTER to use labels.
Mon, Jul 12, 2:53 AM · Restricted Project
melver accepted D105773: sanitizer_common: rename Mutex to MutexState.
Mon, Jul 12, 1:19 AM · Restricted Project
melver accepted D105716: sanitizer_common: add thread safety annotations.
Mon, Jul 12, 1:08 AM · Restricted Project

Jun 29 2021

melver accepted D104810: [Inline] prevent inlining on noprofile mismatch.
Jun 29 2021, 5:06 AM · Restricted Project

Jun 18 2021

melver accepted D104491: [Docs][Clang][Attr] mark no_stack_protector+no_sanitize GCC compatible.

There might be subtle inconsistencies between values accepted by our no_sanitize and GCC's no_sanitize, because of internal naming differences, but I couldn't say what those are right now (I think no_sanitize("coverage") only works with Clang, and GCC wants no_sanitize_coverage which we don't have due to not allowing new no_sanitize_*).

Jun 18 2021, 1:27 AM · Restricted Project

Jun 17 2021

melver added a comment to D104475: [Clang][Codegen] Add GNU function attribute 'no_profile' and lower it to noprofile.

So if we don't want to offer guarantee for IR/C/C++ attributes, we can document that users may need to additionally specify __attribute__((noinline)) to suppress inlining.

I don't generally like that approach:

  1. it's not easy for developers to validate their call call chains to ensure that a caller with a restrictive function attribute doesn't have unrestricted callers inlined into the restricted caller.
  2. that behavior opposes the principle of least surprise.
  3. We don't have a statement attribute for call sites to say "please don't inline this call" which would be fine grain. noinline is a course-grain hammer; what if we want to inline a callee into most callers but not this one caller that has such a restricted function attribute?

See also D91816 where I took the conservative approach for no_stack_protector and simply chose not to perform such inline substitution on caller and callee function attribute mismatch. I find this behavior to be the least surprising, and the developer is provided with introspection as to why the compile did not perform such inlining via -Rpass=inline flag.

Jun 17 2021, 3:02 PM · Restricted Project
melver added a comment to D104475: [Clang][Codegen] Add GNU function attribute 'no_profile' and lower it to noprofile.

Should no_profile specify the inlining behavior? Though no_sanitize_* don't specify that, either.

I think it's somehow implicit, but I can't quite say how. There are some tests that check this, e.g.
compiler-rt/test/asan/TestCases/inline.cpp
[...]
noinstr does add noinline, but other uses of the attribute alone might not. But in the end inlining is a red herring, it just seems to be the easiest way to enforce the promised contract. See https://lore.kernel.org/lkml/CANpmjNNRz5OVKb6PE7K6GjfoGbht_ZhyPkNG9aD+KjNDzK7hGg@mail.gmail.com/
[...]

Thanks for the comments. Recently there is a discussion about LLVM IR function attribute nointeropt (similar to a debugging-only GCC function attribute noipa).
People tend to think attributes should be orthogonal. I think not suppressing inlining for the IR attribute no_profile is nice.
Ideally the GNU function attribute (C/C++) does not diverge much from the IR semantics.
So if we don't want to offer guarantee for IR/C/C++ attributes, we can document that users may need to additionally specify __attribute__((noinline)) to suppress inlining.

Jun 17 2021, 2:59 PM · Restricted Project
melver added a comment to D104475: [Clang][Codegen] Add GNU function attribute 'no_profile' and lower it to noprofile.

Should no_profile specify the inlining behavior? Though no_sanitize_* don't specify that, either.

Jun 17 2021, 2:19 PM · Restricted Project

Jun 14 2021

melver added a comment to D104253: [Clang][Codegen] emit noprofile IR Fn Attr for no_instrument_function Fn Attr.

What are your thoughts on adding a noprofile function attribute in the FE? @MaskRay suggested filing a bug with gcov (below) to get their take on it.

https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&component=gcov-profile&list_id=304970&product=gcc
Jun 14 2021, 12:24 PM · Restricted Project

Jun 11 2021

melver abandoned D103958: [WIP] Support MustControl conditional control attribute.
Jun 11 2021, 10:35 AM · Restricted Project, Restricted Project

Jun 10 2021

melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

Defining the value used to establish a control dependency, e.g. the load later writes depend on (kernel only defines writes to be ctrl-dependently ordered).

[[mustcontrol]] also has this problem.

At the LLVM IR level, if just want to split the load from the control dependency intrinsic, we could define a special kind of load that produces a LLVM IR "token". The control dependency intrinsic then takes the token as an operand, and optimizations understand that they aren't allowed to touch the token.

The problem at that point is, how does clang emit LLVM IR? It would have to do some sort of dataflow analysis to connect the load to the control dependency. And we'd need to define rules for what sort of data/control flow are allowed. That's not impossible, but it's complicated.

  1. Defining later ops that are control-dependent. With an expression like the __builtin, this could be any operation after, or it becomes too hard to define:

I don't think this is a problem we need to solve. If the user sticks the builtin in some weird location that doesn't have a branch immediately following it, that's fine. Any branch that depends on a value can enforce a control dependency, so in general, we just insert a no-op branch at the point of the call to the builtin. Like I mentioned before, we can think of removing that no-op branch as an optimization.


Whatever we end up doing, I really don't want to mark up LLVM IR branches. I don't want to add more constraints to CFG transforms at the LLVM IR level. The rules are already hard to understand; I don't want to add more weird edge cases. And I don't think it's necessary here.

Jun 10 2021, 1:19 PM · Restricted Project, Restricted Project
melver updated the diff for D103958: [WIP] Support MustControl conditional control attribute.

As promised, some cleanups, docs, and updated test for the current version (no
other major changes yet).

Jun 10 2021, 11:59 AM · Restricted Project, Restricted Project
melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

You could break __builtin_load_with_control_dependency(x) into something like __builtin_control_dependency(READ_ONCE(x)). I don't think any transforms will touch that in practice, even if it isn't theoretically sound. The rest of my suggestion still applies to that form, I think. They key point is that the compiler just needs to ensure some branch consumes the loaded value; it doesn't matter which branch it is.

Jun 10 2021, 5:32 AM · Restricted Project, Restricted Project

Jun 9 2021

melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

I don't like using metadata like this. Dropping metadata should generally preserve the semantics of the code.

Anything better for this without introducing new instructions? Would an argument be reasonable?

If we really want to make it part of the branch, maybe add an intrinsic that can be used with callbr. Not something we've done before, but the infrastructure should be mostly there.

That said, I'm not sure this is the best approach. Alternative proposal:

We could add a regular intrinsic. Just ignore the control flow at the IR level, and come up with a straight-line blob that just does the right thing. I think we'd want to actually perform the load as part of the intrinsic, to avoid worrying about the consume dependency. So we'd have an intrinsic "__builtin_load_with_control_dependency()". It would lower to something along the lines of asm("ldr %0, [%1]; cbnz %0, .+4":"=r"(dest):"r"(x):"memory"); on AArch64. The differences between the intrinsic and just using the asm I wrote:

  1. We weaken the "memory" clobber to something that more accurately matches what we need.
  2. We add a compiler transform to check if the branch is redundant, late in the optimization pipeline, and remove it if it is.

I think this produces the code you want, and it should be easier to understand and maintain.

Jun 9 2021, 4:45 PM · Restricted Project, Restricted Project
melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

Please bear with me, I'm updating examples and documentation. I didn't think anybody would look at this while [WIP]. :-)

People try to help so you have early design feedback ;)

Jun 9 2021, 1:48 PM · Restricted Project, Restricted Project
melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

I don't like using metadata like this. Dropping metadata should generally preserve the semantics of the code.

Jun 9 2021, 1:38 PM · Restricted Project, Restricted Project
melver planned changes to D103958: [WIP] Support MustControl conditional control attribute.
Jun 9 2021, 6:51 AM · Restricted Project, Restricted Project
melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

This is missing langref changes, and a RFC to llvm-dev.

Jun 9 2021, 6:48 AM · Restricted Project, Restricted Project
melver requested review of D103958: [WIP] Support MustControl conditional control attribute.
Jun 9 2021, 5:39 AM · Restricted Project, Restricted Project

May 27 2021

melver added a comment to D103159: [Clang] Enable __has_feature(coverage_sanitizer).

Ping.

FWIW, the usual practice is to ping after no activity on the review for about a week.

That said, LGTM!

May 27 2021, 9:36 AM · Restricted Project
melver committed rG4fbc66cd6d90: [Clang] Enable __has_feature(coverage_sanitizer) (authored by melver).
[Clang] Enable __has_feature(coverage_sanitizer)
May 27 2021, 9:25 AM
melver closed D103159: [Clang] Enable __has_feature(coverage_sanitizer).
May 27 2021, 9:25 AM · Restricted Project
melver added a comment to D103159: [Clang] Enable __has_feature(coverage_sanitizer).

To reviewers: Do note the feature vs. extension discussion.
Summary: We think to be consistent with other sanitizers and avoid confusion, we must make this a feature, too.

May 27 2021, 8:09 AM · Restricted Project

May 26 2021

melver added inline comments to D103159: [Clang] Enable __has_feature(coverage_sanitizer).
May 26 2021, 11:19 AM · Restricted Project
melver updated the diff for D103159: [Clang] Enable __has_feature(coverage_sanitizer).

s/Since/Because/

May 26 2021, 10:59 AM · Restricted Project
melver added inline comments to D103159: [Clang] Enable __has_feature(coverage_sanitizer).
May 26 2021, 10:55 AM · Restricted Project
melver updated the diff for D103159: [Clang] Enable __has_feature(coverage_sanitizer).

Documentation wording.

May 26 2021, 5:33 AM · Restricted Project