21 GCC HEAD regressions, 14 new, with your patch on 2004-05-14T06:33:11Z.

Ziemowit Laski zlaski@apple.com
Fri May 14 20:02:00 GMT 2004


On 14 May, 2004, at 12.48, Andrew Pinski wrote:

> Some analysis of the problems of the new failures:
>
> Known gcov problems (no CFG at -O0):
>> native g++.sum g++.dg/gcov/gcov-1.C
>> native g++.sum g++.dg/gcov/gcov-2.C
>> native gcc.sum gcc.misc-tests/gcov-4b.c
>
>
> No warnings for no return statements (need CFG at -O0, there is a PR  
> for it):
>> native g++.sum g++.old-deja/g++.brendan/crash13.C
>> native g++.sum g++.old-deja/g++.bugs/900205_03.C
>> native g++.sum g++.old-deja/g++.law/friend5.C
>> native g++.sum g++.old-deja/g++.mike/p646.C
>
>
> Labels after the return are being removed even though they are  
> referenced
> (there is a PR for this):
>> native gcc.sum gcc.c-torture/compile/20021108-1.c
>> native gcc.sum gcc.c-torture/compile/labels-1.c
>> native gcc.sum gcc.c-torture/compile/labels-2.c
>
> /Users/pinskia/src/gcc-checkin/src/gcc/testsuite/gcc.dg/altivec- 
> varargs-1.c:22: warning: second parameter of `va_start' not last named  
> argument:
>
> The issue I think here is that the vector is being copied into a
> temp before it is passed to va_start and it is a generic bug which
> should be filed and fixed.
>> native gcc.sum gcc.dg/altivec-varargs-1.c
>
>
> I do not get this failure on my system at all as it is just a timeout:
>> native gcc.sum gcc.dg/c99-intconst-1.c
>
>
> The following two are due to that the constant Objective-C strings
> not being the same I do not know how to fix this bug at all, I think
> it is a bug in the Objective-C front-end not caching the constructors:
>> native objc.sum objc.dg/const-str-3.m
>> native objc.sum objc.dg/const-str-4.m

This is a bug in the new inliner, which I ran into in my constant  
CFString work
on the apple-ppc-branch.  CONSTRUCTOR nodes get cloned (and assigned to  
temp
variables) all over the place.  In the constant CFString case, I did  
cache
the CONSTRUCTORs as you suggest.  The ObjC string machinery currently  
does not
cache the CONSTRUCTORs, which did not prevent previous incarnations of  
the
compiler from successfully uniquing them. :-)

Inliner temp variable madness is also responsible for the  
g++.dg/ext/altivec*.C,
where integer literal arguments get turned into temp variables, from  
which I
was unsuccessful in extracting the value they're initialized to.

It would be good if someone knowledgable with inliner internals could  
fix this. :-)

Thanks,

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477



More information about the Gcc-regression mailing list