http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51878
Bug #: 51878
Summary: ICE or OOM with decltype + variadic templates +
"indirect" function call
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com
Created attachment 26347
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26347
testcase that is probably minimal
(Bugzilla is suggesting lots of duplicates for me, but they all seem to be old
...)
While trying to work around what may or may not be bug 44175, I tried not
calling the function directly. I hit compile and my computer became
unresponsive. With a little investigation, I discovered GCC was trying to
allocate an infinite amount of memory. Running gcc with niceness 19, my system
was responsive enough for me to watch 'top' until it consumed all my swap and
got OOM'ed.
Interestingly, after reducing my testcase, it allocates a lot of memory, but
eventually ICEs instead (SEGV in cc1plus). I swear I didn't change anything in
the testcase since the last time I got an OOM. Nonetheless, I've left an #error
for your safety.
Also, at least in some variants (including the original), the memory explosion
can happen after an Error. Sadly, reproducing this bug with after an error has
occurred is not possible with this minimal testcase. (The particular error was
caused by forgetting to include the pack in one of my if-branches, so it was
calling the functor with too few arguments, leading to "no match found for
apply, candidates are" and then listed the one candidate.)
Expected result:
The following code works (but is admittedly unnecessary if other GCC bugs are
fixed)
template<class F, class... T>
auto indirect_call(F f, T... t) -> decltype(f(t...))
{
return f(t...);
}
Actual result:
If you're lucky, ICE. Else, an unresponsive system and eventually OOM.
Versions:
Here's where it gets interesting ...
* gcc <= 4.6.0 fail for various reasons unrelated to this bug.
* 4.6.1 and 4.6.2 from Gentoo, and svn branch 4.6 r183147, and whatever svn
snapshot Debian is using, have the effect described in this bug report, but
work if the call is made directly.
* svn trunk (r182728 and r183173) has some sort of regression such that even
the direct call ICEs. My gut says that should probably file a separate bug
about whatever causes that (if there isn't one already), but I don't feel I
know enough.
(My workaround for bug 44175 that works in 4.6 is also broken on trunk. I don't
know if that is the same regression that makes this one fail)
