Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Dominique Dhumieres]

Tom,

After these changes I have the following regressions on x86_64-apple-darwin1[04]*:

FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
FAIL: gcc.dg/uninit-19.c (test for excess errors)
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1

I can prepare and test a fix for darwin unless you beat me!

Cheers,

Dominique

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Tom de Vries]

On 09-02-15 18:23, Dominique Dhumieres wrote:
> Tom,
>
> After these changes I have the following regressions on x86_64-apple-darwin1[04]*:
>
> FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
> FAIL: gcc.dg/uninit-19.c (test for excess errors)
> FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1
>
> I can prepare and test a fix for darwin unless you beat me!
>

Dominique,

thanks for finding this.

I don't understand why this breaks. Why is fpic supposed to be different for darwin?

Thanks,
- Tom

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Dominique d'Humières]

> Le 9 févr. 2015 à 20:01, Dominique d'Humières <dominiq@lps.ens.fr> a écrit :
> 
> 
>> Le 9 févr. 2015 à 19:10, Tom de Vries <Tom_deVries@mentor.com> a écrit :
>> 
>> On 09-02-15 18:23, Dominique Dhumieres wrote:
>>> Tom,
>>> 
>>> After these changes I have the following regressions on x86_64-apple-darwin1[04]*:
>>> 
>>> FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
>>> FAIL: gcc.dg/uninit-19.c (test for excess errors)
>>> FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1
>>> 
>>> I can prepare and test a fix for darwin unless you beat me!
>>> 
>> 
>> Dominique,
>> 
>> thanks for finding this.
>> 
>> I don't understand why this breaks. Why is fpic supposed to be different for darwin?
> 
> I don’t either, but the tests succeeds on darwin with the following patch
> 
> --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c	2015-02-09 11:38:40.000000000 +0100
> +++ gcc/testsuite/gcc.dg/uninit-19.c	2015-02-09 19:52:26.000000000 +0100
> @@ -22,5 +22,5 @@ fn2 ()
>    fn1 (l, &d, &e, &g, &i, &h, &k, n);  /* 22.  */
>  }
>  
> -/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
> -/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 } */
> +/* { dg-warning "may be used uninitialized" "" { target { nonpic || x86_64-apple-darwin1[0-9]* } } 13 } */
> +/* { dg-warning "may be used uninitialized" "" { target { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } 22 } */
> --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c	2015-02-09 11:38:40.000000000 +0100
> +++ gcc/testsuite/gcc.dg/graphite/scop-19.c	2015-02-09 19:55:38.000000000 +0100
> @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct 
>    if (need > dgs->alc)
>      d_growable_string_resize (dgs, need);
>  }
> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target nonpic } } } */
> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target { ! nonpic } } } } */
> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
>  /* { dg-final { cleanup-tree-dump "graphite" } } */
>  
> Cheers,
> 
> Dominique
> 
>> Thanks,
>> - Tom
> 

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Jack Howarth]

This appears to be the first instance where 'target' and 'nonpic' have
been used in a dg-warning.

On Mon, Feb 9, 2015 at 2:40 PM, Dominique d'Humières <dominiq@lps.ens.fr> wrote:
>
>> Le 9 févr. 2015 à 20:01, Dominique d'Humières <dominiq@lps.ens.fr> a écrit :
>>
>>
>>> Le 9 févr. 2015 à 19:10, Tom de Vries <Tom_deVries@mentor.com> a écrit :
>>>
>>> On 09-02-15 18:23, Dominique Dhumieres wrote:
>>>> Tom,
>>>>
>>>> After these changes I have the following regressions on x86_64-apple-darwin1[04]*:
>>>>
>>>> FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
>>>> FAIL: gcc.dg/uninit-19.c (test for excess errors)
>>>> FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1
>>>>
>>>> I can prepare and test a fix for darwin unless you beat me!
>>>>
>>>
>>> Dominique,
>>>
>>> thanks for finding this.
>>>
>>> I don't understand why this breaks. Why is fpic supposed to be different for darwin?
>>
>> I don’t either, but the tests succeeds on darwin with the following patch
>>
>> --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c        2015-02-09 11:38:40.000000000 +0100
>> +++ gcc/testsuite/gcc.dg/uninit-19.c  2015-02-09 19:52:26.000000000 +0100
>> @@ -22,5 +22,5 @@ fn2 ()
>>    fn1 (l, &d, &e, &g, &i, &h, &k, n);  /* 22.  */
>>  }
>>
>> -/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
>> -/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 } */
>> +/* { dg-warning "may be used uninitialized" "" { target { nonpic || x86_64-apple-darwin1[0-9]* } } 13 } */
>> +/* { dg-warning "may be used uninitialized" "" { target { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } 22 } */
>> --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c 2015-02-09 11:38:40.000000000 +0100
>> +++ gcc/testsuite/gcc.dg/graphite/scop-19.c   2015-02-09 19:55:38.000000000 +0100
>> @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
>>    if (need > dgs->alc)
>>      d_growable_string_resize (dgs, need);
>>  }
>> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target nonpic } } } */
>> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target { ! nonpic } } } } */
>> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
>> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
>>  /* { dg-final { cleanup-tree-dump "graphite" } } */
>>
>> Cheers,
>>
>> Dominique
>>
>>> Thanks,
>>> - Tom
>>
>

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Jack Howarth]

Also, aren't we pretty much the only target to default to PIC? So if
the 'target' and 'nonpic'  testing is failing when used in the context
of dg-warning, wouldn't that appear functional on the nonpic targets?
That is, since the nonpic test is to check for __PIC__, if that fails
in dg-warning, wouldn't it 'appear' functional on nonpic targets, no?

On Mon, Feb 9, 2015 at 3:51 PM, Jack Howarth <howarth.at.gcc@gmail.com> wrote:
> This appears to be the first instance where 'target' and 'nonpic' have
> been used in a dg-warning.
>
> On Mon, Feb 9, 2015 at 2:40 PM, Dominique d'Humières <dominiq@lps.ens.fr> wrote:
>>
>>> Le 9 févr. 2015 à 20:01, Dominique d'Humières <dominiq@lps.ens.fr> a écrit :
>>>
>>>
>>>> Le 9 févr. 2015 à 19:10, Tom de Vries <Tom_deVries@mentor.com> a écrit :
>>>>
>>>> On 09-02-15 18:23, Dominique Dhumieres wrote:
>>>>> Tom,
>>>>>
>>>>> After these changes I have the following regressions on x86_64-apple-darwin1[04]*:
>>>>>
>>>>> FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
>>>>> FAIL: gcc.dg/uninit-19.c (test for excess errors)
>>>>> FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1
>>>>>
>>>>> I can prepare and test a fix for darwin unless you beat me!
>>>>>
>>>>
>>>> Dominique,
>>>>
>>>> thanks for finding this.
>>>>
>>>> I don't understand why this breaks. Why is fpic supposed to be different for darwin?
>>>
>>> I don’t either, but the tests succeeds on darwin with the following patch
>>>
>>> --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c        2015-02-09 11:38:40.000000000 +0100
>>> +++ gcc/testsuite/gcc.dg/uninit-19.c  2015-02-09 19:52:26.000000000 +0100
>>> @@ -22,5 +22,5 @@ fn2 ()
>>>    fn1 (l, &d, &e, &g, &i, &h, &k, n);  /* 22.  */
>>>  }
>>>
>>> -/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
>>> -/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 } */
>>> +/* { dg-warning "may be used uninitialized" "" { target { nonpic || x86_64-apple-darwin1[0-9]* } } 13 } */
>>> +/* { dg-warning "may be used uninitialized" "" { target { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } 22 } */
>>> --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c 2015-02-09 11:38:40.000000000 +0100
>>> +++ gcc/testsuite/gcc.dg/graphite/scop-19.c   2015-02-09 19:55:38.000000000 +0100
>>> @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
>>>    if (need > dgs->alc)
>>>      d_growable_string_resize (dgs, need);
>>>  }
>>> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target nonpic } } } */
>>> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target { ! nonpic } } } } */
>>> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
>>> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
>>>  /* { dg-final { cleanup-tree-dump "graphite" } } */
>>>
>>> Cheers,
>>>
>>> Dominique
>>>
>>>> Thanks,
>>>> - Tom
>>>
>>

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Tom de Vries]

On 09-02-15 20:01, Dominique d'Humières wrote:
>
>> Le 9 févr. 2015 à 19:10, Tom de Vries <Tom_deVries@mentor.com
>> <mailto:Tom_deVries@mentor.com>> a écrit :
>>
>> On 09-02-15 18:23, Dominique Dhumieres wrote:
>>> Tom,
>>>
>>> After these changes I have the following regressions on
>>> x86_64-apple-darwin1[04]*:
>>>
>>> FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
>>> FAIL: gcc.dg/uninit-19.c (test for excess errors)
>>> FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of
>>> SCoPs: 0" 1
>>>
>>> I can prepare and test a fix for darwin unless you beat me!
>>>
>>
>> Dominique,
>>
>> thanks for finding this.
>>
>> I don't understand why this breaks. Why is fpic supposed to be different for
>> darwin?
>
> I donÂ’t either, but the tests succeeds on darwin with the following patch
>
> --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 11:38:40.000000000 +0100
> +++ gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 19:52:26.000000000 +0100
> @@ -22,5 +22,5 @@ fn2 ()
>     fn1 (l, &d, &e, &g, &i, &h, &k, n);  /* 22.  */
>   }
>
>
> -/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
> -/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 } */
> +/* { dg-warning "may be used uninitialized" "" { target { nonpic ||
> x86_64-apple-darwin1[0-9]* } } 13 } */
> +/* { dg-warning "may be used uninitialized" "" { target { ! { nonpic ||
> x86_64-apple-darwin1[0-9]* } } } 22 } */
> --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09
> 11:38:40.000000000 +0100
> +++ gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09 19:55:38.000000000 +0100
> @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
>     if (need > dgs->alc)
>       d_growable_string_resize (dgs, need);
>   }
> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target
> nonpic } } } */
> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target
> { ! nonpic } } } } */
> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target
> { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target
> { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
>   /* { dg-final { cleanup-tree-dump "graphite" } } */

I think we need to understand first what's going on.

In both test-cases, on Linux with -fpic the inlining of one function into the 
other is not done, because we cannot be sure the function call in one function 
binds to the other function at runtime.

So, is the inlining happening with -fpic for Darwin? If so, is that correct?

Thanks,
- Tom

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Jack Howarth]

Tom,
      At -m32 on x86_64-apple-darwin14, the failing test case executes...

% /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -O
-Wuninitialized -S  -m32  -o uninit-19.s
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:
In function ‘fn2’:
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:13:15:
warning: ‘n’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:19:10:
note: ‘n’ was declared here

which following the following preprocessed source.

# 1 "/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c"



int a, l, m;
float *b;
float c, d, e, g, h;
unsigned char i, k;
void
fn1 (int p1, float *f1, float *f2, float *f3, unsigned char *c1, float *f4,
     unsigned char *c2, float *p10)
{
  if (p1 & 8)
    b[3] = p10[a];
}

void
fn2 ()
{
  float *n;
  if (l & 6)
    n = &c + m;
  fn1 (l, &d, &e, &g, &i, &h, &k, n);
}

Does that help?
                Jack

On Tue, Feb 10, 2015 at 6:42 AM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> On 09-02-15 20:01, Dominique d'Humières wrote:
>>
>>
>>> Le 9 févr. 2015 à 19:10, Tom de Vries <Tom_deVries@mentor.com
>>> <mailto:Tom_deVries@mentor.com>> a écrit :
>>>
>>>
>>> On 09-02-15 18:23, Dominique Dhumieres wrote:
>>>>
>>>> Tom,
>>>>
>>>> After these changes I have the following regressions on
>>>> x86_64-apple-darwin1[04]*:
>>>>
>>>> FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
>>>> FAIL: gcc.dg/uninit-19.c (test for excess errors)
>>>> FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of
>>>> SCoPs: 0" 1
>>>>
>>>> I can prepare and test a fix for darwin unless you beat me!
>>>>
>>>
>>> Dominique,
>>>
>>> thanks for finding this.
>>>
>>> I don't understand why this breaks. Why is fpic supposed to be different
>>> for
>>> darwin?
>>
>>
>> I don’t either, but the tests succeeds on darwin with the following patch
>>
>> --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c2015-02-09
>> 11:38:40.000000000 +0100
>> +++ gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 19:52:26.000000000 +0100
>> @@ -22,5 +22,5 @@ fn2 ()
>>     fn1 (l, &d, &e, &g, &i, &h, &k, n);  /* 22.  */
>>   }
>>
>>
>> -/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
>> -/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22
>> } */
>> +/* { dg-warning "may be used uninitialized" "" { target { nonpic ||
>> x86_64-apple-darwin1[0-9]* } } 13 } */
>> +/* { dg-warning "may be used uninitialized" "" { target { ! { nonpic ||
>> x86_64-apple-darwin1[0-9]* } } } 22 } */
>> --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09
>> 11:38:40.000000000 +0100
>> +++ gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09 19:55:38.000000000
>> +0100
>> @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
>>     if (need > dgs->alc)
>>       d_growable_string_resize (dgs, need);
>>   }
>> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" {
>> target
>> nonpic } } } */
>> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" {
>> target
>> { ! nonpic } } } } */
>> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" {
>> target
>> { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
>> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" {
>> target
>> { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
>>   /* { dg-final { cleanup-tree-dump "graphite" } } */
>
>
> I think we need to understand first what's going on.
>
> In both test-cases, on Linux with -fpic the inlining of one function into
> the other is not done, because we cannot be sure the function call in one
> function binds to the other function at runtime.
>
> So, is the inlining happening with -fpic for Darwin? If so, is that correct?
>
> Thanks,
> - Tom
>

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Dominique d'Humières]

> Le 10 févr. 2015 à 12:42, Tom de Vries <Tom_deVries@mentor.com> a écrit :
> 
> I think we need to understand first what's going on.

Sure, my patch was mainly to silence the failures on my working tree.

> In both test-cases, on Linux with -fpic the inlining of one function into the other is not done, because we cannot be sure the function call in one function binds to the other function at runtime.

I don’t understand why -fpic should change the inlining decision (except register pressure and so on).

> So, is the inlining happening with -fpic for Darwin? If so, is that correct?

The inlining is happening for darwin. I don’t know if that is correct or not. The test has been introduced at r143947 (Thu Feb 5 00:29:48 2009) and the only failures I have seen are due to r 220532 (checked back to r154691).

Dominique

> Thanks,
> - Tom

Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c

[Tom de Vries]

On 11-02-15 10:22, Dominique d'Humières wrote:
>
>> Le 10 févr. 2015 à 12:42, Tom de Vries <Tom_deVries@mentor.com> a écrit :
>>
>> I think we need to understand first what's going on.
>
> Sure, my patch was mainly to silence the failures on my working tree.
>
>> In both test-cases, on Linux with -fpic the inlining of one funct ion into the other is not done, because we cannot be sure the function call in one function binds to the other function at runtime.
>
> I donÂ’t understand why -fpic should change the inlining decision (except register pressure and so on).
>

It's about symbol binding, not inlining heuristics.

>> So, is the inlining happening with -fpic for Darwin? If so, is that correct?
>
> The inlining is happening for darwin. I donÂ’t know if that is correct or not.

I found an explanation.

darwin.c:
...
/* Cross-module name binding.  Darwin does not support overriding
    functions at dynamic-link time, except for vtables in kexts.  */

bool
darwin_binds_local_p (const_tree decl)
{
   return default_binds_local_p_1 (decl,
                                   TARGET_KEXTABI && DARWIN_VTABLE_P (decl));
}
...

i386.c:
...
#if TARGET_MACHO
#undef TARGET_BINDS_LOCAL_P
#define TARGET_BINDS_LOCAL_P darwin_binds_local_p
#endif
...

This is probably the cause for the difference. I guess that means your patch is ok.

Thanks,
- Tom