This is an archive of the discontinued LLVM Phabricator instance.

[libc++][test] Mark ranges.transform.pass.cpp UNSUPPORTED for AIX
ClosedPublic

Authored by jloser on Jun 4 2022, 9:30 AM.

Details

Summary

The ranges.transform.pass.cpp often times out on CI for AIX (32-bit and 64-bit)
only. Mark the test as UNSUPPORTED for AIX for now. It should be looked into in
the future.

Diff Detail

Event Timeline

jloser created this revision.Jun 4 2022, 9:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 4 2022, 9:30 AM
jloser requested review of this revision.Jun 4 2022, 9:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 4 2022, 9:30 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
philnik requested changes to this revision.Jun 4 2022, 3:40 PM

The test is just long. So either the test should be made shorted somehow or the timeout for AIX should be longer. XFAILing it doesn't solve the problem in any way. It's just the 50/50 chance of passing reversed to a 50/50 chance of failing.

This revision now requires changes to proceed.Jun 4 2022, 3:40 PM
jloser added a comment.Jun 4 2022, 5:06 PM

The test is just long. So either the test should be made shorted somehow or the timeout for AIX should be longer. XFAILing it doesn't solve the problem in any way. It's just the 50/50 chance of passing reversed to a 50/50 chance of failing.

I see. So, we could bump the timeout set by run-buildbot to bump it up from the current 1200 seconds, but that's awfully high already. Have you already looked into why it's taking so long (and only on AIX?)? Is it spending so much time compiling (can look with -ftime-trace and ClangBuildAnalyzer), or something else?

The test is just long. So either the test should be made shorted somehow or the timeout for AIX should be longer. XFAILing it doesn't solve the problem in any way. It's just the 50/50 chance of passing reversed to a 50/50 chance of failing.

I see. So, we could bump the timeout set by run-buildbot to bump it up from the current 1200 seconds, but that's awfully high already. Have you already looked into why it's taking so long (and only on AIX?)? Is it spending so much time compiling (can look with -ftime-trace and ClangBuildAnalyzer), or something else?

The test always takes a long time to run. On my machine it's 47 seconds. I think the average test takes more like one to two seconds. The problem is that we instantiate the actual test with 7 * 7 * 7 ( = 343) iterator combinations. I don't know why it takes twenty minutes on AIX though. I guess something isn't well optimized in the compiler and that gets multiplied 343 times. That's probably something someone from AIX should look into. @DanielMcIntosh-IBM @SeanP @daltenty

I would prefer to have the test fixed for AIX. However due to the recent number of false positive CI failures I don't mind to disable it temporary on one platform.

libcxx/test/std/algorithms/alg.modifying.operations/alg.transform/ranges.transform.pass.cpp
11

This won't work, now the CI will fail when the test finishes within 1200s. Instead use UNSUPPORTED.
Please add a comment why the test is disabled.

jloser updated this revision to Diff 434325.Jun 5 2022, 6:25 AM
jloser retitled this revision from [libc++][test] Mark ranges.transform.pass.cpp XFAIL for AIX to [libc++][test] Mark ranges.transform.pass.cpp UNSUPPORTED for AIX.
jloser edited the summary of this revision. (Show Details)

Make the test UNSUPPORTED instead of XFAIL

jloser updated this revision to Diff 434326.Jun 5 2022, 6:26 AM

Add comment explaining why it's UNSUPPORTED

Mordante added inline comments.Jun 5 2022, 7:11 AM
libcxx/test/std/algorithms/alg.modifying.operations/alg.transform/ranges.transform.pass.cpp
11

This fails to build due to the explanation comment being part of the code parsed by lit.
Please move the comment on its own line. While your at it please make it a complete sentence.

jloser updated this revision to Diff 434328.Jun 5 2022, 7:36 AM

Fix the comment

jloser updated this revision to Diff 434329.Jun 5 2022, 7:37 AM

Reword comment based on Mordante's suggestion

Mordante accepted this revision as: Mordante.Jun 5 2022, 11:47 AM

LGTM, but agree with @philnik that the underlying issue should be fixed.
So I leave the final approval to him.

philnik accepted this revision.Jun 5 2022, 12:02 PM

I think this has to be fixed by IBM, so I'm Ok with it for now.

This revision is now accepted and ready to land.Jun 5 2022, 12:02 PM

I don't think we want to do this -- I increased the timeout on our CI bots to try to avoid this issue. I think we should revert this now that I've bumped the timeout duration (hopefully enough to get rid of these spurious failures).