On 08/22/2013 09:19 AM, Jan Hubicka wrote:
- I tried to track functions that lead to terminate() and not mark them
as ECF_LEAF. This is because user can set handler. If the handler
can resonably expect the static vars defined in its unit to be
in the final form, we can not conside
On Mon, Aug 26, 2013 at 8:17 PM, Jason Merrill wrote:
> On 08/26/2013 10:45 AM, Gabriel Dos Reis wrote:
>>
>> Hmm, let's not make it a default. Replacing global operator new (e.g. for
>> tracing purposes) is a valid C++ programming idiom.
>
>
> Absolutely. What strikes me as vanishingly unlikely
On 08/26/2013 10:45 AM, Gabriel Dos Reis wrote:
Hmm, let's not make it a default. Replacing global operator new (e.g. for
tracing purposes) is a valid C++ programming idiom.
Absolutely. What strikes me as vanishingly unlikely is the idea that
the replacement operator new would expose pointer
On Mon, Aug 26, 2013 at 9:07 AM, Jason Merrill wrote:
> On 08/22/2013 12:45 PM, Gabriel Dos Reis wrote:
>>
>> If the user-supplied operator new returns &a, then it must
>> also ensure that 'a' is not used anywhere else -- e.g. I you can't
>> do lvalue-to-value conversion on 'a' to see what is writ
On Mon, Aug 26, 2013 at 9:38 AM, Jan Hubicka wrote:
>> On 08/22/2013 12:45 PM, Gabriel Dos Reis wrote:
>> >If the user-supplied operator new returns &a, then it must
>> >also ensure that 'a' is not used anywhere else -- e.g. I you can't
>> >do lvalue-to-value conversion on 'a' to see what is writt
> On 08/22/2013 12:45 PM, Gabriel Dos Reis wrote:
> >If the user-supplied operator new returns &a, then it must
> >also ensure that 'a' is not used anywhere else -- e.g. I you can't
> >do lvalue-to-value conversion on 'a' to see what is written there.
> >Because its storage has been reused. That i
On 08/22/2013 12:45 PM, Gabriel Dos Reis wrote:
If the user-supplied operator new returns &a, then it must
also ensure that 'a' is not used anywhere else -- e.g. I you can't
do lvalue-to-value conversion on 'a' to see what is written there.
Because its storage has been reused. That is, aliasing
On Mon, Aug 26, 2013 at 2:44 AM, Mike Stump wrote:
> but I fear you won't understand this and how it applies.
You must be right. I cannot match the entertaining value of your
message, so you win.
-- Gaby
On Aug 23, 2013, at 9:36 PM, Gabriel Dos Reis
wrote:
> You made a statement. It was not clear whether it was what you want
> or whether it is what the standards mandate.
Both.
>>> (2) what you believe the standards mandate, with appropriate quote; and
>>
>> The life of the original object doe
On Fri, Aug 23, 2013 at 10:34 PM, Mike Stump wrote:
> On Aug 23, 2013, at 5:53 PM, Gabriel Dos Reis
> wrote:
>> If you quoted the standard to back up your assertions, I would have been
>> able to "feel free to point this out" :-)
>>
>> The thing is I am still trying to figure out what (1) what y
On Aug 23, 2013, at 5:53 PM, Gabriel Dos Reis
wrote:
> If you quoted the standard to back up your assertions, I would have been
> able to "feel free to point this out" :-)
>
> The thing is I am still trying to figure out what (1) what you would have
> liked;
I've directly stated it, not sure h
On Fri, Aug 23, 2013 at 7:32 PM, Mike Stump wrote:
> On Aug 22, 2013, at 7:16 PM, Gabriel Dos Reis
> wrote:
>> But even so, in light of this, I don't think you original assertion is
>> definitive.
>
> Nothing is ever definitive. Now, if you want to say I quoted something
> wrong, or that I a
On Aug 22, 2013, at 7:16 PM, Gabriel Dos Reis
wrote:
>>> My reasoning (for C++98, but the same is true for C++11) is based
>>> on 3.8/1:
>>> […]
>>> The lifetime of an object of type T ends when:
>>> -- if T is a class type with a non-trivial destructor (12.4),
>>> the destructor call st
On Thu, Aug 22, 2013 at 8:51 PM, Mike Stump wrote:
> On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis
> wrote:
>> I think we must distinguish what is "wrong" according to the standards
>> we are implementing from what is "wrong" from a QoI point of view.
>
> Not if they match, we don't.
In abstrac
On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis
wrote:
> I think we must distinguish what is "wrong" according to the standards
> we are implementing from what is "wrong" from a QoI point of view.
Not if they match, we don't.
> My reasoning (for C++98, but the same is true for C++11) is based
> o
On Thu, Aug 22, 2013 at 6:16 PM, Mike Stump wrote:
> On Aug 22, 2013, at 2:28 PM, Gabriel Dos Reis
> wrote:
>> On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote:
>>> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
>>> wrote:
> I.e. can I have something like
>
> int a;
> test()
>
On Aug 22, 2013, at 2:28 PM, Gabriel Dos Reis
wrote:
> On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote:
>> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
>> wrote:
I.e. can I have something like
int a;
test()
{
int *b=new (int);
}
with custom imp
On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote:
> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
> wrote:
>>> I.e. can I have something like
>>>
>>> int a;
>>> test()
>>> {
>>> int *b=new (int);
>>> }
>>>
>>> with custom implementation of new that returns &a?
>>
>> If the user-supplied operat
On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
wrote:
>> I.e. can I have something like
>>
>> int a;
>> test()
>> {
>> int *b=new (int);
>> }
>>
>> with custom implementation of new that returns &a?
>
> If the user-supplied operator new returns &a, then it must
> also ensure that 'a' is not us
On Thu, Aug 22, 2013 at 11:08 AM, Jan Hubicka wrote:
>>
>> This should be a C++ front-end bug. The specific operator new
>> from used in this placement-new should be folded,
>> even if -fno-inline. Jason, is this something easily fixable?
>>
>> After overload resolution, we know exactly which o
On Thu, Aug 22, 2013 at 11:16 AM, Jan Hubicka wrote:
>> On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka wrote:
>> >> >
>> >> > So the existing program needs to overwrite libsup++ symbol like we do
>> >> > with malloc?
>> >> > Of course with user defineed malloc function we should not propagate
>>
> On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka wrote:
> >> >
> >> > So the existing program needs to overwrite libsup++ symbol like we do
> >> > with malloc?
> >> > Of course with user defineed malloc function we should not propagate the
> >> > attribute,
> >> > but I think we could have it whe
>
> This should be a C++ front-end bug. The specific operator new
> from used in this placement-new should be folded,
> even if -fno-inline. Jason, is this something easily fixable?
>
> After overload resolution, we know exactly which operator new
> we are picking, and we know it is the one co
On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka wrote:
>> >
>> > So the existing program needs to overwrite libsup++ symbol like we do with
>> > malloc?
>> > Of course with user defineed malloc function we should not propagate the
>> > attribute,
>> > but I think we could have it when we end up ca
On Thu, Aug 22, 2013 at 10:38 AM, Alexander Monakov wrote:
> On Thu, 22 Aug 2013, Jan Hubicka wrote:
>
>> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > > > - I would like to recall issue if we can make NEW_EXPR annotated with
>> > > >MALLOC attribute. Without it, it is basically imposs
>
>
> On Thu, 22 Aug 2013, Jan Hubicka wrote:
>
> > > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > > > > - I would like to recall issue if we can make NEW_EXPR annotated with
> > > > >MALLOC attribute. Without it, it is basically impossible to track
> > > > >any dynamically allocat
On Thu, 22 Aug 2013, Jan Hubicka wrote:
> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > > > - I would like to recall issue if we can make NEW_EXPR annotated with
> > > >MALLOC attribute. Without it, it is basically impossible to track
> > > >any dynamically allocated objects in th
> >
> > So the existing program needs to overwrite libsup++ symbol like we do with
> > malloc?
> > Of course with user defineed malloc function we should not propagate the
> > attribute,
> > but I think we could have it when we end up calling the runtime.
>
> I suspect the question is whether ou
On Thu, Aug 22, 2013 at 10:21 AM, Jan Hubicka wrote:
>> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > > - I would like to recall issue if we can make NEW_EXPR annotated with
>> > >MALLOC attribute. Without it, it is basically impossible to track
>> > >any dynamically allocated object
On Thu, Aug 22, 2013 at 9:56 AM, Jakub Jelinek wrote:
> On Thu, Aug 22, 2013 at 09:53:35AM -0500, Gabriel Dos Reis wrote:
>> On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov
>> wrote:
>> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> >> > - I would like to recall issue if we can make NEW_E
> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > > - I would like to recall issue if we can make NEW_EXPR annotated with
> > >MALLOC attribute. Without it, it is basically impossible to track
> > >any dynamically allocated objects in the middle-end
> >
> > operator new is replaceable b
On Thu, Aug 22, 2013 at 09:53:35AM -0500, Gabriel Dos Reis wrote:
> On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov wrote:
> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> >> > - I would like to recall issue if we can make NEW_EXPR annotated with
> >> >MALLOC attribute. Without it, it i
On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov wrote:
> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > - I would like to recall issue if we can make NEW_EXPR annotated with
>> >MALLOC attribute. Without it, it is basically impossible to track
>> >any dynamically allocated objects
On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > - I would like to recall issue if we can make NEW_EXPR annotated with
> >MALLOC attribute. Without it, it is basically impossible to track
> >any dynamically allocated objects in the middle-end
>
> operator new is replaceable by user progr
On Thu, Aug 22, 2013 at 8:19 AM, Jan Hubicka wrote:
>
> Hi,
> this patch started as a work to make cxa_pure_virtual as noreturn. This
> is good for middle-end to figure out that it should not care about
> devirtualizing to it and it should devirtualize speculative where there
> is only one varian
Hi,
this patch started as a work to make cxa_pure_virtual as noreturn. This
is good for middle-end to figure out that it should not care about
devirtualizing to it and it should devirtualize speculative where there
is only one variant. I ended up switching the function building
stuff to use ecf_
36 matches
Mail list logo
