I wrote:
> I don't know why icc is so much worse than gcc on this measure of
> stack depth consumption, but clearly the combination of that and
> the 100kB max_stack_depth explains why dugong is failing to do
> very many levels of recursion before erroring out.
I figured out why icc looked so much worse here: I had accidentally
built with optimization disabled. Selecting -O2 causes its numbers
to come a lot closer to gcc's. In particular, it flips around from
using more normal stack than register stack to using more register
stack than normal. (This might be the case for gcc as well; I did
not test an unoptimized gcc build.)
This means that, at least for icc, *an optimized build is unsafe*
without code to check for register stack growth. It turns out that
buildfarm member dugong has been building without optimization all
along, which is why we'd not noticed the issue.
I think it'd be a good idea for dugong to turn on optimization
so it's testing something closer to a production build. However,
at this moment only HEAD is likely to pass regression tests with
that turned on. We'd have to back-patch the just-committed code
for checking register stack growth before the back branches would
survive that.
I'm normally hesitant to back-patch code that might create portability
issues, but in this case perhaps it's a good idea. Comments?
regards, tom lane
