There's a bug in gcc (still present on the trunk as far as I can tell
from visual inspection of svn trunk/logs) that prevents cross-building
native sh3 compiler on a 64-bit build machine. I think the problem
affects all build64->host32->target64 setups (superh gcc supports
64-bit sh5, hence target64), but to actually trigger it a machine
description must use large enough constants, which sh3 unfortunately
does.
For details see
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=34549
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
Basically the problem is that gen*.c programs (compiled on the build
host and thus pulling auto-build.h) incorrectly use build host wide
int defines to emit constants in C code (insn-*.c) that will be
compiled for the host, where wide int defines can be different. So
when we cross build on say amd64 where wide int in "long", gen*.c emit
"L" suffix on constants that can be large enough not to fit into
32-bit long of the host. E.g. there's no difference for 1L and 1LL
(hence most other ports survive this mismatch), but e.g. 4294967295L
is too wide for 32-bit long (host wide int is long long).
One organizational fallout from this bug is that, since our releng
autobuild cluster is amd64-only at the moment, sh3 ports haven't been
autobuilt for a long time.
Suggested fix defers suffix choice until insn-*.c are compiled (for
host and thus they see correct auto-host.h defines for wide ints) and
is tiny and unintrusive. But as it potentially affects all ports, I'd
like to get an ok from toolchain folks before committing it to the
netbsd tree.