This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [test] Avoid huge main() functions and huge arrays.
ClosedPublic

Authored by STL_MSFT on Jun 14 2016, 2:11 PM.

Details

Summary

Avoid huge main() functions and huge arrays.

Fixes MSVC warning C6262 "Function uses '62000' bytes of stack: exceeds /analyze:stacksize '16384'. Consider moving some data to heap."

Several random distribution tests featured huge main() functions. Even though they have artificial blocks in order to keep variables locally scoped, this gives MSVC's /analyze a headache, because it views main() as consuming an enormous amount of stack space (it doesn't reuse stack, at least for analysis). Splitting main() up into numbered test functions is slightly friendlier to humans and massively friendlier to /analyze.

Additionally, is_swappable_include_order.pass.cpp had a busted comment, and a 42 * 50 multidim array of doubles (actually two of them). That's a lot of stack space: 42 * 50 * 8 * 2 = 33600. As the actual size isn't important, I've reduced this to 17 by 29, which fits comfortably within /analyze's default stack (7888 bytes is less than 16K).

Diff Detail

Event Timeline

STL_MSFT updated this revision to Diff 60745.Jun 14 2016, 2:11 PM
STL_MSFT retitled this revision from to [libcxx] [test] Avoid huge main() functions and huge arrays..
STL_MSFT updated this object.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.
bcraig added a subscriber: bcraig.Jun 14 2016, 2:20 PM

Even though they have artificial blocks in order to keep variables locally scoped, this gives MSVC's /analyze a headache, because it views main() as consuming an enormous amount of stack space (it doesn't reuse stack, at least for analysis). Splitting main() up into numbered test functions is slightly friendlier to humans and massively friendlier to /analyze.

The optimizer tends to not reuse the stack space either, at least for Clang 3.8, MSVC 2010 (I know, ancient history), and various older GCCs. I'm not sure if modern GCCs or MSVCs do a better job of shrinking stacks when this scoping pattern is used, or when lots of statement-lifetime temporaries are involved. Both patterns have caused me considerable grief on small stack systems.

You may want to look at test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp and test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp. They involve giant functions with lots of scoping, and they have both caused me stack pain that I haven't specifically tried to solve yet.

LGTM. I don't see anything controversial here. If you want to wait for @EricWF or @mclow.lists though, that's fine.

I gotta wait for them, I don't have commit access. :-> (Nor do I need it at the moment)

Haven't encountered problems with those locale tests yet, although I'm still processing 670-ish compiletime and runtime failures.

EricWF accepted this revision.Jun 21 2016, 6:19 PM
EricWF edited edge metadata.
This revision is now accepted and ready to land.Jun 21 2016, 6:19 PM
EricWF closed this revision.Jun 21 2016, 6:20 PM

r273354.