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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,7bdbcdc23dd9313d
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!feedme.ziplink.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Jeffrey Creem <jeff@thecreems.com>
Newsgroups: comp.lang.ada
Subject: Re: Large arrays passed to arithmetic operators overflows GNAT stack
Date: Sat, 04 Dec 2010 08:27:30 -0500
Organization: A noiseless patient Spider
Message-ID: <07sps7-5ju.ln1@newserver.thecreems.com>
References: 
 <da4fcb09-efa7-46d4-aece-e86b0dcf6674@v17g2000prc.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: mx01.eternal-september.org;
 posting-host="qwC9sxX6083KTsdl5V7dbg";
	logging-data="25715"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19eBTDkILmQZ8AFOBwkdF4uvp7w0iZBqnQ="
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
In-Reply-To: 
 <da4fcb09-efa7-46d4-aece-e86b0dcf6674@v17g2000prc.googlegroups.com>
Cancel-Lock: sha1:Lw1CWtanVxHrORDdN+4laUyDgoM=
Xref: g2news2.google.com comp.lang.ada:16769
Date: 2010-12-04T08:27:30-05:00
List-Id: <comp.lang.ada>

On 12/4/2010 1:32 AM, Jerry wrote:
> For what it's worth, passing large numerical arrays to the arithmetic
> operators in GNAT can cause the stack to overflow (segfault) even when
> the arrays are allocated from the heap. I suppose that indicates that
> they are being copied rather than being passed by reference.
>

In general, GNAT (and most other compilers) don't copy arguments like 
large arrays on the parameters to subprograms. The problem here is 
almost certainly in the return value associated with the subtraction. I 
am not sure I'd say it is impossible but I don't think I have seen any 
Ada implementation that can avoid the creation of the temporary based on 
the internally defined local variable that is generally required to 
construct code the returns an array.

Even if certain cases could be found by the optimizer and made to work, 
there are all sorts of cases where users would end up being surprised 
when temporaries had to be created.

In cases where array slices, assignment and the math involved 'destroy' 
the future values as the current values are being read, the compiler 
would have no choice (given the semantics of the operator) but to 
introduce some temporaries and it would be quite a feat for a compiler 
to figure out how much of a mini-slice temp it would need.

I really think it is a shame that Generic_Real_Arrays was defined the 
way that it was as the pretty code one gets when being able to use infix 
notation is nice but the overhead involved in the resulting copies 
renders the operators useless for all but the smallest of array vectors.