https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #22 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #20)
> Unfortunately the following doesn't reproduce the issue.
>
> #include <vector>
> #include <algorithm>
>
> void g();
>
> void f(int nBands, double maxZErr) {
> for (int iBand = 0; iBand < nBands; iBand++)
> {
> g();
> std::vector<signed char> noDataCandVec;
> std::vector<signed char> distCandVec = {0, 1, 10, 100, 5, 6};
> for (signed char dist : distCandVec)
> noDataCandVec.push_back(1);
> std::sort(noDataCandVec.begin(), noDataCandVec.end(),
> std::greater<double>());
> }
> }
>
> I'll add the preprocessed source.
Yes it depends on some definitions not to be inlined, even the original code
had a check on typeinfo which dependedent on the `operator==` not being inlined
but that was able to change to the simple call of `g()` with no definition. I
didn't try to figure out which functions needed to be inlined or not when I was
reducing the code. This is also why it originally needed LTO to hit the ICE
because the usage across different TUs caused slightly different inlining
decisions and then as definitions were able to be removed; you could hit it
without LTO.
