This is the mail archive of the
mailing list for the GCC project.
- From: Richard Sandiford <richard at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Wed, 10 Jan 2007 10:30:22 +0000
- Subject: ColdFire submission
I'm about to submit the ColdFire 4.3 project:
As usual with this sort of thing, a single patch would be too big
to review as a unit. I've therefore tried to split it into smaller,
more managable, pieces. There ended up being 63 in all.
It isn't really feasible to run regression tests for each individual
patch, as it would take an order of months, and mainline would have
changed a great deal by the time I'd finished. I therefore ran some
simple compile-only tests for the individual patches and did the
main testing on the series as a whole.
Specifically, to test the patches individually, I compiled a
baseline xgcc and cc1 for the following targets:
m68k-aout m68k-coff m68020-unknown-elf m68k-elf
m68010-unknown-netbsdelf m68k-netbsdelf m68k-openbsd
m68k-uclinux m68k-linux m68k-rtems
and saved the make logs. Then, for each patch in the series,
I built the tools again and compared the new make logs with the
last ones. I checked these diffs to make sure there were no
To test the series as a whole, I ran tests for these configuration
and option combinations:
These tests weren't regression tests because the support is new.
However, the results were as expected, and tie in with those for
the original 4.1 sources.
There are some target-independent changes, so I bootstrapped and
regression-tested the series on x86_64-linux-gnu. One of the
patches also steals code from MIPS; I'll describe the MIPS testing
when I get to that patch.
CodeSourcery don't have access to 680x0 hardware, so I didn't do
normal regression tests on 680x0 systems. However, as a sanity check,
I compiled gcc.c-torture, gcc.dg and g++.dg for the above targets
using the options:
-O0 -O2 -msep-data -mid-shared-library -mpcrel -fpic -fPIC
-O/-m68000 -O/-m68020 -O/-m68020-40 -O/-m68020-60
-O/-m68040 -O/-m68060 -O/-mcpu32 -O/-m68881
Not all these options make sense for all targets, but it was easier to
automate the test this way. I then compared the logs for the unpatched
compiler with those for the patched compiler, and there seemed to be no
new build failures. I also spot-checked some of the assembly code
differences. Those that I saw seemed benign.
Sorry for the upcoming deluge...