This is an archive of the discontinued LLVM Phabricator instance.

Add tests to reproduce pointer/index width confusion crashes
ClosedPublic

Authored by krzysz00 on Feb 23 2023, 1:50 PM.

Details

Summary

Some calls to GEPOperator::accumulateConstantOffset(APInt) passed the
pointer bitwidth as the width of the APInt, while the function asserts
that the width of its argument is equal to the index width of the GEP
pointer input. These values are almost always the same, so mixing up
which call to use doesn't usually cause issues. However, when dealing
with data layouts where these values are different, the passes tested
here can crash.

This will be fixed in D143437 .

Diff Detail

Event Timeline

krzysz00 created this revision.Feb 23 2023, 1:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 23 2023, 1:50 PM
Herald added a subscriber: arphaman. · View Herald Transcript
krzysz00 requested review of this revision.Feb 23 2023, 1:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 23 2023, 1:50 PM
krzysz00 updated this revision to Diff 499978.Feb 23 2023, 2:15 PM

Switch an XFAIL to a not --crash

This revision was not accepted when it landed; it landed in state Needs Review.Feb 23 2023, 2:50 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.

Do they really crash in -Asserts?

dyung added a subscriber: dyung.Feb 23 2023, 7:55 PM

Do they really crash in -Asserts?

We are also seeing the test fail on our internal builds without asserts. Running the opt command this makes sense because the crash is due to an assertion failure. Please fix the test to work both with/without asserts or require asserts when running the test.

Will fix logical tomorrow (feel free to revert until then)

How do I test for tripping an assertion reliably here? The point of these
tests is to confirm that another patch makes the assertion failure go away.

yozhu added a subscriber: yozhu.Feb 24 2023, 12:59 AM

We also saw failures on these three tests in our internal rolling noassert build/test.

nikic added a subscriber: nikic.Feb 24 2023, 1:10 AM

You would have to add REQUIRES: asserts.

Though really, you should just include these as passing tests in the patch that fixes them. There is no pre-commit requirement for tests that crash.

Sorry everyone, I reverted this change in https://github.com/llvm/llvm-project/commit/736e788c58f946f236bd5c80e17eb4a5448056d5.

Will fix logical tomorrow (feel free to revert until then)

I'd like to ask you to revert yourself immediately next time you're notified that a change broke builds. See the policy at https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

When should you revert your own change?

Any time you learn of a serious problem with a change, you should revert it. We strongly encourage “revert to green” as opposed to “fixing forward”.

There are many people in the community who depend on the health of the codebase. If everyone was leaving the code broken until they have time to commit a proper fix, the builds would be permanently broken.

Re filing my own reverts: I agree, and I know that it's reasonable to revert my own breaking changes so as to not break other people.

In this specific circumstance, the first I learned of the breaking was around my 1 AM when I saw y'all's comments about how the tests were failing with assertions off, and I wasn't in a position where I could do the revert at that time. So, rather than having everyone wait on me getting in to work the next day, I commented that it'd be fine to revert this.

On the subject of precommit tests, in the underlying diff, @arichardson recommend precommitting not --crash tests, so I went for that without realizing the impact on assertions-off builds.

Apologies for all the trouble.