[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
>