update on gcc 3.0 CVS on embedded targets

[Joel Sherrill]

Jim Wilson wrote:

> I've spent a little time looking at i960 issues.  I can't do much at this
> time though.  My primary concern is IA-64, and that takes up most of the time
> I spend on gcc and binutils.  Plus the rules for working on gcc-3.0 have gotten
> so involved that I don't have the time and energy to deal with them.


Thanks for looking at this.  It looks like you put in some time. 

> 
> In general, I think you are going off on the wrong tack here.  It is a lot
> easier to get a port working before we make a release than after we make a
> release.  It would be a much better use of our time to get embedded cross
> compiler ports working on the trunk, and keep them working, so that they will
> be ready for gcc-3.1 and following releases.  We are likely to make a gcc-3.1
> in 6 months or so, so this is only a temporary setback.

The cynic in me hears "gcc 3.0 is broken for embedded target and won't 
get fixed." :(

I certainly understand your position and tried a number of snapshots 
prior to the release reporting
problems along the way.  It is hard to fix a lot of problems without 
breaking other things. And it
is supposedly a frozen release branch.  It is just  shame that so many 
targets were broken
and there is no hope in getting them fixed.  The gcc 2.95.x series now 
looks very important.

As a side-note, I was also hoping that gcc 3.0 would be useable since I 
wanted to
get cross-GNAT tested as soon as it was merged.  The general state makes 
that
nearly impossible.

I am chedcking out the gcc CVS mainline and will repeat this effort as a 
point of comparison.
I will likely try the same exercise on gcc 2.95.3 over the next week or so.

> 
> We simply don't have enough resources to try to fix every possible problem
> with gcc-3.0.  It has been too long since the last release.  There are too
> many new features, too much bit-rot, etc.  We need to prioritize our efforts.
> We should concentrate on resolving all GNU/Linux system issues first.  This
> will probably take several months alone.  Then we can worry about the
> embedded cross compiler ports.  By then, we will be thinking about a gcc-3.1
> release, so it would be best if we were fixing them on the trunk now.

OK.  <beaten down acceptance>

It would help some if people fixing problems on the mainline would also 
fix them on the trunk.  At least
some of these problems reported are not on the trunk.  I know one of my 
earlier PRs for a configure
problem was specifically against the 3.0 branch, the fix was merged onto 
the trunk, and the PR closed. :(

> 
> As for the i960, it builds on the trunk.  However, it isn't working.  There
> is one very serious problem, function return values are broken.  There are
> also various problems with non-local gotos and hence exception handling.
> All of these problems seem to be related to the mondo C++ EH rewrite.


<sigh>  I will rebuild all the targets using the trunk but this only 
highlights that some of the problems
have fixes that are not improving the release.  I understand the 
resource problem.  But having a solution
and not getting it into both paths is different from not having a solution.

Once I got enough targets building, I had planned to move on to running 
the test suite on simulators.
That was why I was focusing on *-coff and *-elf not *-rtems. 

> 
> i960 defines a "return" pattern in the md file.  This doesn't work anymore.
> What happens is that when we convert trees to RTL, we emit a return insn
> for the RETURN_EXPR.  Then, after we are done with the trees, we emit code
> to load the return value into the hard return register, and then we emit
> another return.  The optimizer then deletes the dead code and the result is
> that functions never return values.  I think this broke as part of the mondo
> C++ EH rewrite, but haven't spent enough time looking to figure out where the
> bit-rot occurred.  This can be worked around by disabling the return pattern
> for now.
> 
> This gets the i960 port mostly working, except that non-local gotos and C++ EH
> still don't work.  There is something funny going on here.  The middle-end
> is passing the wrong values to the non-local goto pattern in the i960.md file.
> This is obvisouly a result of the mondo C++ EH patch, but I haven't spent
> enough time looking at it yet to figure out what is wrong.


Boy this is very ugly and very broken. :(

> 
> We will probably find similar issues with other embedded cross compilers
> once we get past the cosmetic problems preventing them from building.
> 
>> i960-coff	PR3179 may still apply (undefined ref to c_lex when linking f771)
> 
> 
> This one has been answered several times.  It is simply a matter of someone
> merging a patch from the trunk to the gcc-3.0 branch.
> 
>> 		PR3365 still applies
> 
> 
> I haven't seen this one answered, but again, this can be fixed by merging a
> patch from the trunk to the gcc-3.0 branch.

> 
>> i960-elf	PR3366 may or may not apply
>> 		  since it now fails differently
> 
> 
> I haven't seen this, but then I haven't tried to build i960-elf in a very
> long time.


Thanks, Jim.

> 
> Jim


-- 
-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985