On Mon, May 14, 2018 at 11:11 PM, Prathamesh Kulkarni
wrote:
> On 12 January 2018 at 18:26, Richard Biener wrote:
>> On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote:
>>
>>> On 12 January 2018 at 05:02, Jeff Law wrote:
>>> > On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
>>> >> On 11 January 2
On Thu, May 17, 2018 at 1:25 PM Prathamesh Kulkarni <
prathamesh.kulka...@linaro.org> wrote:
> On 15 May 2018 at 12:20, Richard Biener wrote:
> > On Tue, 15 May 2018, Prathamesh Kulkarni wrote:
> >
> >> On 12 January 2018 at 18:26, Richard Biener wrote:
> >> > On Fri, 12 Jan 2018, Prathamesh Kul
On 15 May 2018 at 12:20, Richard Biener wrote:
> On Tue, 15 May 2018, Prathamesh Kulkarni wrote:
>
>> On 12 January 2018 at 18:26, Richard Biener wrote:
>> > On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote:
>> >
>> >> On 12 January 2018 at 05:02, Jeff Law wrote:
>> >> > On 01/10/2018 10:04 PM, Pr
On Tue, 15 May 2018, Prathamesh Kulkarni wrote:
> On 12 January 2018 at 18:26, Richard Biener wrote:
> > On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote:
> >
> >> On 12 January 2018 at 05:02, Jeff Law wrote:
> >> > On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
> >> >> On 11 January 2018 at 0
On 12 January 2018 at 18:26, Richard Biener wrote:
> On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote:
>
>> On 12 January 2018 at 05:02, Jeff Law wrote:
>> > On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
>> >> On 11 January 2018 at 04:50, Jeff Law wrote:
>> >>> On 01/09/2018 05:57 AM, Pratham
On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote:
> On 12 January 2018 at 05:02, Jeff Law wrote:
> > On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
> >> On 11 January 2018 at 04:50, Jeff Law wrote:
> >>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>
> As Jakub pointed out for
On 12 January 2018 at 05:02, Jeff Law wrote:
> On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
>> On 11 January 2018 at 04:50, Jeff Law wrote:
>>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_mallo
On 01/11/2018 01:27 AM, Richard Biener wrote:
> On Thu, 11 Jan 2018, Marc Glisse wrote:
>
>> On Tue, 9 Jan 2018, Prathamesh Kulkarni wrote:
>>
>>> As Jakub pointed out for the case:
>>> void *f()
>>> {
>>> return __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would set f() to malloc.
On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
> On 11 January 2018 at 04:50, Jeff Law wrote:
>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>>
>>> As Jakub pointed out for the case:
>>> void *f()
>>> {
>>> return __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would set f
On 01/11/2018 01:32 PM, Jan Hubicka wrote:
As long as the marked definition still satisfies the assumptions
GCC makes about the function it won't be harmful. I don't know
all the nuances of pointer aliasing in GCC that might rely on it
but assuming they faithfully reflect the standard requireme
>
> As long as the marked definition still satisfies the assumptions
> GCC makes about the function it won't be harmful. I don't know
> all the nuances of pointer aliasing in GCC that might rely on it
> but assuming they faithfully reflect the standard requirements
> it will be safe.
>
> The oth
On 01/11/2018 12:22 PM, Jeff Law wrote:
On 01/11/2018 11:56 AM, Martin Sebor wrote:
On 01/10/2018 04:20 PM, Jeff Law wrote:
On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_malloc (0);
}
The malloc propagation would set f()
On 01/11/2018 11:56 AM, Martin Sebor wrote:
> On 01/10/2018 04:20 PM, Jeff Law wrote:
>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>>
>>> As Jakub pointed out for the case:
>>> void *f()
>>> {
>>> return __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would set f() to malloc.
On 01/10/2018 04:20 PM, Jeff Law wrote:
On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_malloc (0);
}
The malloc propagation would set f() to malloc.
However AFAIU, malloc(0) returns NULL (?) and the function shouldn't
be mar
On Thu, 11 Jan 2018, Marc Glisse wrote:
> On Tue, 9 Jan 2018, Prathamesh Kulkarni wrote:
>
> > As Jakub pointed out for the case:
> > void *f()
> > {
> > return __builtin_malloc (0);
> > }
> >
> > The malloc propagation would set f() to malloc.
> > However AFAIU, malloc(0) returns NULL (?) and
On Tue, 9 Jan 2018, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_malloc (0);
}
The malloc propagation would set f() to malloc.
However AFAIU, malloc(0) returns NULL (?) and the function shouldn't
be marked as malloc ?
Why not? Even for
void*f(){r
On 11 January 2018 at 10:34, Prathamesh Kulkarni
wrote:
> On 11 January 2018 at 04:50, Jeff Law wrote:
>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>>
>>> As Jakub pointed out for the case:
>>> void *f()
>>> {
>>> return __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would
On 11 January 2018 at 04:50, Jeff Law wrote:
> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>
>> As Jakub pointed out for the case:
>> void *f()
>> {
>> return __builtin_malloc (0);
>> }
>>
>> The malloc propagation would set f() to malloc.
>> However AFAIU, malloc(0) returns NULL (?) and
On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>
> As Jakub pointed out for the case:
> void *f()
> {
> return __builtin_malloc (0);
> }
>
> The malloc propagation would set f() to malloc.
> However AFAIU, malloc(0) returns NULL (?) and the function shouldn't
> be marked as malloc ?
This se
On 3 January 2018 at 18:58, Jan Hubicka wrote:
>
>> diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
>> index 09ca3590039..0406d5588d2 100644
>> --- a/gcc/ipa-pure-const.c
>> +++ b/gcc/ipa-pure-const.c
>> @@ -910,7 +910,8 @@ malloc_candidate_p (function *fun, bool ipa)
>> #define DUMP_AND
On 01/02/2018 11:03 PM, Prathamesh Kulkarni wrote:
> Hi,
> malloc_candidate_p() in ipa-pure-const misses detecting that a
> function is malloc-like if the return value is result of PHI and one
> of the arguments of PHI is 0.
> For example:
>
> void g(unsigned n)
> {
> return (n) ? __builtin_mal
> diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
> index 09ca3590039..0406d5588d2 100644
> --- a/gcc/ipa-pure-const.c
> +++ b/gcc/ipa-pure-const.c
> @@ -910,7 +910,8 @@ malloc_candidate_p (function *fun, bool ipa)
> #define DUMP_AND_RETURN(reason) \
> { \
>if (dump_file && (dump_
> On Wed, Jan 03, 2018 at 10:05:30AM +0100, Richard Biener wrote:
> > >One concern I have is that with the patch, malloc_candidate_p will
> > >return true if all the args to PHI are NULL:
> > >retval = PHI<0, 0>
> > >return retval
> > >
> > >However I expect that PHI with all 0 args would be consta
On Wed, Jan 03, 2018 at 10:05:30AM +0100, Richard Biener wrote:
> >One concern I have is that with the patch, malloc_candidate_p will
> >return true if all the args to PHI are NULL:
> >retval = PHI<0, 0>
> >return retval
> >
> >However I expect that PHI with all 0 args would be constant folded to
>
On January 3, 2018 7:03:26 AM GMT+01:00, Prathamesh Kulkarni
wrote:
>Hi,
>malloc_candidate_p() in ipa-pure-const misses detecting that a
>function is malloc-like if the return value is result of PHI and one
>of the arguments of PHI is 0.
>For example:
>
>void g(unsigned n)
>{
> return (n) ? __b
25 matches
Mail list logo
