[tree-ssa-20020619-branch] current status report on i386-*-freebsd4*

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

Since [tree-ssa] is one big pending patch against mainline...

>> I was recruited to get tree-ssa-20020619-branch working on
>> *-*-freebsd* before the mainline merge.  As committed to solve
>> currently known bootstrap problem on i386-unknown-freebsd4.9.  Also
>> testing: alpha-unknown-freebsd5.2 and sparc64-unknown-freebsd5.2.

An i386-unknown-freebsd4.9 bootstrap and check cycle completed over
the weekend.  Here is my summary of current status; it appears to
match what Linus Sjo"berg has been posting for this port
[http://gcc.gnu.org/ml/gcc-testresults/2004-02/msg00602.html].
Automatic daily reporting [to gcc-testresults] from
alpha-unknown-freebsd5.2 and sparc64-unknown-freebsd5.2 should start
tomorrow unless bootstraps fail for any reason (I will try to fix ASAP).

1. On i386-unknown-freebsd4.9: C, C++, objC test results look ~OK.
Appears to match current failure profile of i686-pc-linux-gnu
[http://gcc.gnu.org/ml/gcc-testresults/2004-02/msg00771.html] plus
some extra per-port known FP failures.  There is one extra EH cleanup
failure which might be the root cause for...

2. For reasons I'm still investigating, many libstdc++-v3 execution
tests are failing with "terminate called after throwing an instance of
'std::runtime_error' [junk]".  Many reports from the system malloc
implementation that "X is already free" are also seen (sometimes
without causing the test to fail).  Since that is under my purview, I
will take responsibility for fixing it, or posting whatever I find if
it escape.

3. Most libjava tests appear busted...

4. All mudflap link tests fail with:

../.libs/libmudflap.so: warning: this program uses gets(), which is unsafe.
../.libs/libmudflap.so: undefined reference to `memrchr'
../.libs/libmudflap.so: undefined reference to `memmem'
../.libs/libmudflap.so: undefined reference to `strnlen'

This appears to be a simple portability issue (e.g. attempting to wrap
stuff not in our -lc; or in the case of gets(), stuff already flagged
by our -lc at link time).  I can fix this myself over time.

5. All gfortran link tests fail with:

[...]/libgfortran/.libs/libgfortran.so: undefined reference to `round'
[...]/libgfortran/.libs/libgfortran.so: undefined reference to `roundf'

Our -lm has no round or roundf; also, no idea why the builtins defined
within gfortran aren't being used here, if they were suppose to be
used.  Help from the g95 guys would be much appreciated.

Regards,
Loren