My first example is not correct --- according to the standard, the
lifetime of the temporary should be extended. The second example is an
user error.
C++ standard says this in 12.2.5:
"
The second context is when a reference is bound to a temporary. The
temporary to which the reference is
bound
Hello David,
Sorry to come so late into the discussion, but...
On 21/06/12 00:50, Xinliang David Li wrote:
> One of the most common runtime errors we have seen in gcc-4_7 is
> caused by dangling references to temporaries whole life time have
> ended
>
> e.g,
>
> const A& a = foo();
>
> or
> f
This looks fine to me, if nobody has any more objections.
Jason
Ping ..
On Wed, Jul 4, 2012 at 8:01 AM, Xinliang David Li wrote:
> Comment?
>
> David
>
> On Mon, Jul 2, 2012 at 4:30 PM, Xinliang David Li wrote:
>> I extended the patch a little so that the option can be used to set
>> multiple stack reuse levels: -fstack-reuse=[all|name_vars|none]
>>
>> all:
Comment?
David
On Mon, Jul 2, 2012 at 4:30 PM, Xinliang David Li wrote:
> I extended the patch a little so that the option can be used to set
> multiple stack reuse levels: -fstack-reuse=[all|name_vars|none]
>
> all: enable stack reuse for all local vars (named vars and compiler
> generated temp
I extended the patch a little so that the option can be used to set
multiple stack reuse levels: -fstack-reuse=[all|name_vars|none]
all: enable stack reuse for all local vars (named vars and compiler
generated temporaries) which live in memory;
name_vars: enable stack reuse only for user declared
(re-post in plain text)
Moving this to cfgexpand time is simple and it can also be extended to
handle scoped variables. However Jakub raised a good point about this
being too late as stack space overlay is not the only way to cause
trouble when the lifetime of a stack object is extended beyond the
> As do I. The intent was for Ada and every other language with things like
> temporaries and cleanups to reuse the backend constructs, so that instead
> of writing optimizers, one for each language, to instead share the
> optimizer across languages. To me, the middle end and the backend are the
On Jun 26, 2012, at 9:07 AM, Michael Matz wrote:
> I agree with Jason. TARGET_EXPR and CLEANUP_POINT_EXPR might currently be
> used only for C++, but I think they are sensible general constructs to be
> supported by the gimplifier.
As do I. The intent was for Ada and every other language with
On Tue, Jun 26, 2012 at 06:07:09PM +0200, Michael Matz wrote:
> I agree with Jason. TARGET_EXPR and CLEANUP_POINT_EXPR might currently be
> used only for C++, but I think they are sensible general constructs to be
> supported by the gimplifier.
>
> But I also think that the option to disable st
Hi,
On Tue, 26 Jun 2012, Jason Merrill wrote:
> > (the gimplifier code should be in Frontend code that lowers to GENERIC
> > really and the WITH_CLEANUP_EXPR code should be C++ frontend specific
> > ...).
>
> TARGET_EXPR has been a back-end code since the dawn of GCC version
> control; if it'
On 06/26/2012 04:28 AM, Richard Guenther wrote:
No - the fact that the flag is C++ specific but in common.opt is odd enough
and -ftemp-reuse-stack sounds very very generic - which in fact it is not,
it's a no-op in C. Is there a more formal phrase for the temporary kind that
is affected?
Not t
On Mon, Jun 25, 2012 at 6:25 PM, Xinliang David Li wrote:
> Are there any more concerns about this patch? If not, I'd like to check it in.
No - the fact that the flag is C++ specific but in common.opt is odd enough
and -ftemp-reuse-stack sounds very very generic - which in fact it is not,
it's a
Are there any more concerns about this patch? If not, I'd like to check it in.
thanks,
David
On Fri, Jun 22, 2012 at 8:51 AM, Xinliang David Li wrote:
> On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther
> wrote:
>> On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote:
>>> On 06/22/2012 01:30
Yes.
Original Message
From: Richard Guenther
Sent: Fri, Jun 22, 2012 02:39 AM
To: Jason Merrill
CC: Xinliang David Li ; GCC Patches
; Michael Matz
Subject: Re: New option to turn off stack reuse for temporaries
On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote
On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther
wrote:
> On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote:
>> On 06/22/2012 01:30 AM, Richard Guenther wrote:
What other issues? It enables more potential code motion, but on the
other hand, causes more conservative stack reuse
On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote:
> On 06/22/2012 01:30 AM, Richard Guenther wrote:
>>>
>>> What other issues? It enables more potential code motion, but on the
>>> other hand, causes more conservative stack reuse. As far I can tell,
>>> the handling of temporaries is added in
On 06/22/2012 01:30 AM, Richard Guenther wrote:
What other issues? It enables more potential code motion, but on the
other hand, causes more conservative stack reuse. As far I can tell,
the handling of temporaries is added independently after the clobber
for scoped variables are introduced. This
On Thu, Jun 21, 2012 at 8:27 PM, Xinliang David Li wrote:
> On Thu, Jun 21, 2012 at 2:21 AM, Richard Guenther
> wrote:
>> On Thu, Jun 21, 2012 at 7:28 AM, Xinliang David Li
>> wrote:
>>> I modified the documentation and it now looks like this:
>>>
>>> @item -ftemp-stack-reuse
>>> @opindex ftemp
On Thu, Jun 21, 2012 at 5:53 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 21 Jun 2012, Richard Guenther wrote:
>
>> The flag is not restricted to the C++ compiler and applies to all
>> automatic variables.
>
> The use of that flag in the gimplifier (->in_cleanup_expr) makes it
> actually c++ specific
On Thu, Jun 21, 2012 at 2:21 AM, Richard Guenther
wrote:
> On Thu, Jun 21, 2012 at 7:28 AM, Xinliang David Li wrote:
>> I modified the documentation and it now looks like this:
>>
>> @item -ftemp-stack-reuse
>> @opindex ftemp_stack_reuse
>> This option enables stack space reuse for temporaries. T
On 06/21/2012 02:21 AM, Richard Guenther wrote:
The flag is not restricted to the C++ compiler and applies to all automatic
variables.
This only affects the clobbers for C++ temporary objects, not clobbers
for automatic variables going out of scope.
Also with this patch you remove code moti
Hi,
On Thu, 21 Jun 2012, Richard Guenther wrote:
> The flag is not restricted to the C++ compiler and applies to all
> automatic variables.
The use of that flag in the gimplifier (->in_cleanup_expr) makes it
actually c++ specific.
> Also even with this flag there is no guarantee we cannot fig
On Thu, Jun 21, 2012 at 7:28 AM, Xinliang David Li wrote:
> I modified the documentation and it now looks like this:
>
> @item -ftemp-stack-reuse
> @opindex ftemp_stack_reuse
> This option enables stack space reuse for temporaries. The default is on.
> The lifetime of a compiler generated temporar
OK.
Jason
I modified the documentation and it now looks like this:
@item -ftemp-stack-reuse
@opindex ftemp_stack_reuse
This option enables stack space reuse for temporaries. The default is on.
The lifetime of a compiler generated temporary is well defined by the C++
standard. When a lifetime of a temporary
The documentation needs to explain more what the option controls, and
why you might want it on or off. Other than that it looks fine.
Jason
One of the most common runtime errors we have seen in gcc-4_7 is
caused by dangling references to temporaries whole life time have
ended
e.g,
const A& a = foo();
or
foo (A());// where temp's address is saved and used after foo.
Of course this is user error according to the standard, triaging o
28 matches
Mail list logo
