On Sat, Nov 6, 2010 at 8:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?
Yeah, I think it might be a good idea. Crashing is bad.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company