[gccsdk] GCCSDK GCC 4 status update

John Tytgat John.Tytgat at aaug.net
Tue Jan 2 17:07:31 PST 2007


In message <f08152934e.Jo at hobbes.bass-software.com>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> If not, I'm currently playing with the gcc/g++ testsuite using qemu and its
> results are quite encouraging IMHO:
> 
>               === gcc Summary ===
> 
> # of expected passes          36960
> # of unexpected failures      144
> # of expected failures        77
> # of unresolved testcases     32
> # of untested testcases       28
> # of unsupported tests        332
> 
>               === g++ Summary ===
> 
> # of expected passes          11756
> # of unexpected failures      148
> # of unexpected successes     2
> # of expected failures        67
> # of unresolved testcases     14
> # of unsupported tests        114
> 
> I've solved a couple of issues but don't have a clear overview what the
> remaining issues are.

That was the situation 3 weeks ago.  Now we're down to:

               === gcc Summary === 

# of expected passes            37074 
# of unexpected failures        33 
# of expected failures          77 
# of unresolved testcases       32 
# of untested testcases         28 
# of unsupported tests          332 

and

                 === g++ Summary === 

# of expected passes            11959 
# of unexpected failures        21 
# of unexpected successes       2 
# of expected failures          67 
# of unresolved testcases       16 
# of unsupported tests          114 

(the difference between soft-float and hard-float results are not that
big IMHO and it is gcc.dg/arm-vfp1.c test which confuses the results)

I've tried to make an overview by creating a couple of categories of the
unexpected failures at http://www.riscos.info/index.php/GCCSDK_Development.

The biggest issues are (again IMHO):

1. Static constructor/destructors are not called : I'm not sure what the
   way forward is but it looks to me that the .ctor/.dtor sections are
   correctly populated in the ELF binary but that the ELF loader needs
   to call those ? Or is the runtime library supposed to do that ?
   Suggestions ?
2. C++ exception handling tests are not 100% ok (but already much better
   than 3 weeks ago), it *might* be the fact that the static
   constructors(destructors) not being called.
3. There are a couple of PIC/pic related failures but I guess this is
   because that support is not finished yet.  Lee, you can probably
   evaluate the test results better.
4. Maybe the missing stack chunk support for __builtin_apply(),
   __builtin_apply_args() and __builtin_return() could spoil the support
   for languages like Ada or Java.  I'm not sure where they are typically
   used.
5. Profiling support is clearly not there yet (mcount() and various
   __gcov_*() routines missing).  If someone wants to spend some time
   to get this rolling (and I don't think this would be too difficult),
   that would be great.

Feel free to dissect and investigate this further or even solve a couple
of test cases.

I've also added a small tool to convert a static ELF binary into an
AIF binary (trunk/gcc4/riscos/elf2aif at the moment) avoiding the need
for an ELF loader for those cases.  That might be handy for those who want
to release binaries using the GCCSDK 4.x kit we have right now ;-) Not sure
what will be the role it in the future.

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven




More information about the gcc mailing list