From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin2!goblin1!goblin.stu.neva.ru!newsfeed.datemas.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 01 Nov 2013 16:04:44 +0100
From: Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: GNAT: Why does a large 'new' allocation blow the stack when an
 initialiser is present ?
References: <d843d1e1-a1ea-4818-b23d-aff833be2186@googlegroups.com>
 <lyk3gsse68.fsf@pushface.org>
In-Reply-To: <lyk3gsse68.fsf@pushface.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <5273c30c$0$9505$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 01 Nov 2013 16:04:44 CET
NNTP-Posting-Host: 12e7e4af.newsspool1.arcor-online.net
X-Trace: 
 DXC=ChFFUM:[C\985[]]\]T081ic==]BZ:af>4Fo<]lROoR1nkgeX?EC@@08WEnDiKGIR2PCY\c7>ejV8>nKe26<7?U85>KB]A=Ib\<
X-Complaints-To: usenet-abuse@arcor.de
X-Original-Bytes: 2202
Xref: number.nntp.dca.giganews.com comp.lang.ada:183775
Date: 2013-11-01T16:04:44+01:00
List-Id: <comp.lang.ada>

On 01/11/13 09:45, Simon Wright wrote:
> Rod Kay <rodakay@internode.on.net> writes:
>
>>
>> procedure bug_Test
>> is
>>     type Integer_array is array (Integer range <>) of Integer;
>>
>>     the_Array_1 : access Integer_array
>>        := new Integer_array  (1 .. 10_000_000);         -- Fine.
>>
>>     the_Array_2 : access Integer_array
>>        := new Integer_array' (1 .. 10_000_000 => <>);   -- Stack overflow.
>>
>> begin
>>     null;
>> end;
>>
>>     It seems that, with the initialiser, GNAT is creating the array on
>>     the stack before copying it to the final heap memory ?
>
> Not sure precisely what the bug is, but something odd is going on.

Looking at the output of -gnatDG, I see that, for the second array,
a fresh one is simply declared, then initialized in a loop, and only
then an allocator creates the final array from the object just
initialized. I don't know whether this output reflects what the code
actually does, but it seems to agree with the above observations.