From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6191 invoked by alias); 13 Oct 2004 09:19:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6102 invoked from network); 13 Oct 2004 09:19:49 -0000 Received: from unknown (HELO he304war.uk.vianw.net) (195.102.244.167) by sourceware.org with SMTP; 13 Oct 2004 09:19:49 -0000 Received: from [217.204.252.50] (helo=llama.elixent.com) by he304war.uk.vianw.net with asmtp (Exim 4.20) id 1CHfIS-0004Dg-VQ; Wed, 13 Oct 2004 10:19:49 +0100 Content-Disposition: inline Content-transfer-encoding: quoted-printable MIME-Version: 1.0 Cc: gcc@gcc.gnu.org, Florian Weimer Subject: Re: Optimizing of explicit temporary storage In-Reply-To: <416B8127.4050903@codesourcery.com> from Mark Mitchell on Tue, 12 Oct 2004 00:00:55 -0700 References: <41698B8A.4050702@tat.physik.uni-tuebingen.de><416B47AA.3010106@codesourcery.com> <87sm8k1orb.fsf@deneb.enyo.de><416B8127.4050903@codesourcery.com> Content-type: text/plain; charset="UTF-8" To: mark@codesourcery.com Message-Id: <20041013091948.4367.3@llama.elixent.com> Date: Wed, 13 Oct 2004 11:45:00 -0000 From: Nick Ing-Simmons Reply-To: Nick Ing-Simmons X-SW-Source: 2004-10/txt/msg00486.txt.bz2 Mark Mitchell writes: >> >Yes, but that's rather a different situation due to the nature of Scheme. > >In C, even given just: > > (void) malloc(16); > >it would be surprising to most programmers to optimize away the call=20 >because malloc *does* have side-effects on real systems. For example,=20 >on UNIX, it is likely to call sbrk, which result in observable changes=20 >in the process state. Indeed! - I have actually written=20 free(malloc(estimated_total_need)); To get expensive sbrk() call out of the way with one big one rather than many smaller ones.