libgcc2.h:99: no data type for mode `TI'
Jeffrey A Law
law@redhat.com
Mon Jan 8 18:48:00 GMT 2001
In message <20001003160931.A7279@sunsite.ms.mff.cuni.cz>you write:
> On Sat, Sep 30, 2000 at 12:20:58PM +0200, Gerald Pfeifer wrote:
> > On Fri, 29 Sep 2000, Kaveh R. Ghazi wrote:
> > > I get the same on solaris2.7. The following patch fixes it.
> > > Should I install?
> > >
> > > 2000-09-29 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
> > >
> > > * sparc.h (MIN_UNITS_PER_WORD): Revert last change.
> >
> > On a related note I realized that Jakub failed to specify whether he
> > did a full bootstrap and testsuite run and on which platform for his
> > original patch.
>
> I bootstrapped it on sparc64-redhat-linux, regression tested there as well.
> The issue is that this comes up on 32->64bit crosses only, while I was
> building a native 64->64bit compiler.
> Without the MIN_UNITS_PER_WORD change, you cannot e.g. link sparc64 glibc
> at -O0 (or even the provided testcase at -O0) because __modti3 is undefined
> .
> At -O1 and above it is optimized out, so no TImode multiplication happens.
>
> Richard pointed out 2 possible ways how to deal with it, disabling 32->64bi
> t
> crosses or using arbitrary precision math, I think there is a 3rd option I
> use quite regularly for building 32->64bit crosses:
> compile with
> -DHOST_BITS_PER_WIDE_INT=64 -DHOST_WIDE_INT=long\ long
> (of course provided that your system compiler has long long).
> It can be even part of xm files, e.g. I use in RH gcc this one:
>
> 2000-06-19 Jakub Jelinek <jakub@redhat.com>
>
> * config/sparc/xm-sp64.h (HOST_WIDE_INT): Define if compiling
> with 32bit compiler for 64bit target.
> (HOST_BITS_PER_WIDE_INT): Likewise.
I don't know the state of this problem, but I do know that Alex Oliva has
a patch which auto-detects cases when we need to use long long for
HOST_WIDE_INT. That's probably a cleaner solution than hacking up the
xm files to do this.
jeff
More information about the Gcc-patches
mailing list