This is an archive of the discontinued LLVM Phabricator instance.

[llvm][FileCheck] Fix unit tests failures with EXPENSIVE_CHECKS
ClosedPublic

Authored by DavidSpickett on Jul 21 2022, 8:40 AM.

Details

Summary

EXPENSIVE_CHECKS enables _GLIBCXX_DEBUG, which makes std::sort
check that the compare function is implemented correctly.

To do this it calls it with the first item as both sides.
Which trips the assert here because we think they're
2 capture ranges that overlap, when it's just the same range twice.

Check up front for the two sides being the same item
(same address, not just ==).

Diff Detail

Event Timeline

DavidSpickett created this revision.Jul 21 2022, 8:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2022, 8:40 AM
DavidSpickett requested review of this revision.Jul 21 2022, 8:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2022, 8:40 AM

To give some context, this small example demos what I mean:

#define _GLIBCXX_DEBUG
#include <algorithm>
#include <array>
#include <stdio.h>

int main()
{
    std::array<int, 1> s = {5};
    std::sort(s.begin(), s.end(), [](int a, int b) {
        printf("comparator called!\n");
        return a < b;
    });
}

On a couple of systems I have access to, that will print even though there's only 1 item.

There is a buildbot for EXPENSIVE_CHECKS but it is release mode and on Debian. So it's possible that changes if you hit this or not.

Anyway, hopefully the logic makes sense.

kazu added a comment.Jul 21 2022, 10:17 AM

I am inclined to having the check unconditionally to be more robust. It is super cheap. The condition always evaluates to false without EXPENSIVE_CHECKS, so it gets along with the branch predictor. Plus, it would be nice not to rely on the fact that EXPENSIVE_CHECKS enables _GLIBCXX_DEBUG. Thoughts?

Always do the check.

I am inclined to having the check unconditionally to be more robust.

Sounds good to me, done.

DavidSpickett edited the summary of this revision. (Show Details)Jul 22 2022, 2:08 AM
kazu accepted this revision.Jul 22 2022, 10:06 AM

LGTM. Thank you for updating the patch!

This revision is now accepted and ready to land.Jul 22 2022, 10:06 AM
This revision was landed with ongoing or failed builds.Jul 25 2022, 1:19 AM
This revision was automatically updated to reflect the committed changes.