[linuxsh-dev] Re: Floating point problem

[kaz K. <kk...@rr...>]

"M. R. Brown" <mr...@0x...> wrote:
>> I can't reproduce your problem on my platforms. It works with
>> gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though
>> my environment will differ from yours in libraries.
>> Which version of glibc are you using? If it was compiled by
>> yourself, which gcc was used for?
>> 
> 
> Hmm, you got broken gcc-3.1 to build?  How?  Mine bricks when building
> libgcc (internal compiler error in flow.c).

I'll put the patch for current cvs

  http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-010814.diff
  http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-010515-2add.tar.gz

though it's really broken.
The regression test by make check for stage1 compiler reports only 3
non essential FAILs, but gcc doesn't bootstrap. The stage2 compiler
can't compile any program. It seems that there is a weird bug which
happens only for big funtions, at least, in SH. This is too bad.
So the patch is only for reference. Never use it for the real work.

I'd like to report again about the status of gcc.
GCC-3.0 seems to be fairly stable and almost essential compiler patches
are sent to the GCC mailing list.  Some of them are reviewed already
and some patches waiting to review. You can see our 3.0 patch is still
big. Almost of them are the configury patches for the non-multilib
configurations such sh3-unknown-linux-gnu. Niibe-san sent it to the GCC
mailing list already. This part was the target of arguments, repeatedly.
We tried first to fix config.sub which is the root of such configury,
but many people usually think that four (i.e. sh[34](eb)) is "too many".
The change of config.sub is approved and the argument is continued about
the configury problem in GCC mailing list.

There are some ad hoc ones in our 3.0 patch, which will be never sent
main stream. They are not the Right Thing or solved by the complete
other way in 3.1. The former cases are wired. For example, some correct
SH specific part added in 3.0 are reverted. This is totally wrong, but
if not to do so, gcc-3.0 stage 3 compiler will die. Such part is correct
itself but reveals the another dark problem. Unfortunately, I couldn't
even make an appropriate testcase.
Anyways, I don't think gcc-3.0 is more stable than 20001120 version or
Abe-san's version.
Yes, gcc-3.x has many attractive features, but don't forget it isn't so
stable even for x86.

	kaz