This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt] Change std::sort to llvm::sort in response to r327219
AbandonedPublic

Authored by mgrang on Mar 10 2018, 7:41 PM.

Details

Summary

r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.

To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.

Diff Detail

Event Timeline

mgrang created this revision.Mar 10 2018, 7:41 PM
Herald added subscribers: Restricted Project, dberris, kubamracek. · View Herald TranscriptMar 10 2018, 7:41 PM
mgrang updated this revision to Diff 137967.Mar 11 2018, 6:45 PM

Fixed indentation.

Please regenerate the diffs with context

mgrang updated this revision to Diff 138289.Mar 13 2018, 6:37 PM

Reproduced patch with more context.

RKSimon added inline comments.Mar 16 2018, 8:28 AM
lib/asan/tests/asan_mem_test.cc
85

Is there any point to checking integer type sorts like this and some of the others in this patch?

efriedma added inline comments.
lib/asan/tests/asan_mem_test.cc
85

"<" for integers forms a strict weak ordering, so yes, it'll always return the same result... but it's simpler to just uniformly use llvm::sort everywhere, rather than forcing developers to consider for each call to sort() whether the element type has a user-defined "operator<".

I agree with @efriedma on this. It's better to uniformly use llvm::sort rather than assuming that developers will always use the "correct" sort.

RKSimon accepted this revision.Mar 18 2018, 6:51 AM

I agree with @efriedma on this. It's better to uniformly use llvm::sort rather than assuming that developers will always use the "correct" sort.

Thanks, just wanted to make sure - LGTM.

This revision is now accepted and ready to land.Mar 18 2018, 6:51 AM
This revision was automatically updated to reflect the committed changes.

@kcc @mgrang I'm almost certain this needs to be rolled back: it is breaking the build, and libFuzzer by design can not have LLVM dependencies.

Definitely. Compiler-rt can be built standalone, outside of llvm source tree.
Please revert.

Definitely. Compiler-rt can be built standalone, outside of llvm source tree.
Please revert.

Thanks! r327936 reverts the patch.

Also: this change has been committed w/o an approval from any of the
owners.
please try to avoid this in future.

--kcc

RKSimon reopened this revision.Mar 20 2018, 4:12 AM
This revision is now accepted and ready to land.Mar 20 2018, 4:12 AM
RKSimon requested changes to this revision.Mar 20 2018, 4:13 AM
This revision now requires changes to proceed.Mar 20 2018, 4:13 AM
In D44360#1042816, @kcc wrote:

Also: this change has been committed w/o an approval from any of the
owners.
please try to avoid this in future.

--kcc

Sure. I would keep that in mind. Thanks!

Also, since compiler-rt can be built outside of the llvm tree, I guess we cannot depend on the invocation of llvm::sort. So I guess compiler-rt cannot use the "shuffle before sort" infrastructure of llvm? Could you please comment on whether this is correct? Is there any way we can use llvm::sort for compiler-rt?

RKSimon resigned from this revision.Jun 29 2018, 7:12 AM
mgrang abandoned this revision.Jun 29 2018, 10:51 AM

Need to abandon this since compiler-rt cannot depend on llvm includes.