This is the mail archive of the
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR20541 - allocatable components (TR15541)
- From: "Paul Biggar" <paul dot biggar at gmail dot com>
- To: "Tobias SchlÃter" <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: "Paul Thomas" <paulthomas2 at wanadoo dot fr>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, patch <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 6 Oct 2006 16:12:17 +0100
- Subject: Re: [Patch, fortran] PR20541 - allocatable components (TR15541)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tBtH3BMbfy+aciJQt7sNkYG5Q0hc1Em32ilnrjAgDZ4gyDNLuOy63GGR0n6btNJjKDBTidv95LSGTBUfoJqDAkYvpFPwPWjt0FXroMNYBShx8TKbYfmO9PWRcyKUyMhXdNlDYuZehK2UTeWDIUAKJTzT/wAjxD7waeXFmjEz1RQ=
- References: <452490A3.firstname.lastname@example.org> <email@example.com> <4525DC86.firstname.lastname@example.org> <email@example.com>
As an aside, I'm starting to look at this sort of thing for escape
analysis for stack allocation. As is, I'm using alloca. However, I
believe that there is no specfic requirement to dynamically allocate
on the stack using alloca, and that doing so would hinder the use of
I'm afraid I don't understand this patch too well, nor the problem
it's solving, but I'm wondering are you preallocating space on the
stack by increasing the frame size at compile time, or are you
fiddling with the frame pointer at run time, or some other way? If the
former, it seems this has benefits over using alloca.
On 10/6/06, Tobias SchlÃter <firstname.lastname@example.org> wrote:
Paul Thomas <email@example.com> wrote on Fri, 06 Oct 2006:
>> Out of curiousity, why didn't you use alloca instead of doing all
>> this bookkeeping? Maybe because you would have needed bookkeeping
>> anyway for the case where the allocatable component would have
>> been > -fmax-stack-var-size? Or is there a simpler reason?
> Having looked at the spec. for alloca, you are right, we would have had
> to branch for > -fmax-stack-var-size; otherwise the warnings in the
> gcc manual would hold good. I will put a TODO in the code somewhere.
> It would simplify the code considerably - take a look for some of the
For the record, I don't think a size restriction on the allocated
components would render a patch for the TR unacceptable. Nor do I
think that your patch is any less acceptable because you decided to
manually allocate and deallocate the memory.
OTOH I think it would be a good thing if you could estimate the
probable savings in terms of code size and complexity a patch with
alloca (or whatever one calls it when one means the portable
equivalent) would bring.
One thing that may render this more difficult than one expects, is
that C has no notion of contained procedures, which may interfere with
stack-based memory allocation. I.e. __builtin_alloca may not be well
tested in all circumstance that are interesting to us. Maybe a
middle-end person can weigh in on this?
(As an aside, I wonder if we should allocate temporaries on the stack
instead of the heap, as we do currently. Going via a compiler builtin
may be more transparent to the optimizers.)
This message was sent using IMP, the Internet Messaging Program.