Gcc fix to make sh3 cross-buildable on 64bit build hosts (toolchain/34549)

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?nu
mber=34549
  htt
p://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.

SY, Uwe
-- 
uwestderr.spb.ru                       |       Zu Grunde
kommen
http://snark.ptc.spbu.
ru/~uwe/          |       Ist zu Grunde gehen

On Apr 17, 2008, at 4:21 PM, Valeriy E. Ushakov wrote:
> 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?nu
mber=34549
>  htt
p://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.

This looks sane to me.

James