GCC build failed with your patch on 2001-01-09T11:35:00Z.

[Geoff Keating]

> cc: Richard Henderson <rth@redhat.com>, Alexandre Oliva <aoliva@redhat.com>,
>         Geoff Keating <geoffk@redhat.com>, gcc@gcc.gnu.org,
>         gcc-regression@gcc.gnu.org, grahams@redhat.com, jsm28@cam.ac.uk,
>         mhayes@redhat.com, neil@daikokuya.demon.co.uk, osk@hem.passagen.se,
>         Mark Mitchell <mark@codesourcery.com>
> Reply-To: law@redhat.com
> From: Jeffrey A Law <law@redhat.com>
> Date: Tue, 09 Jan 2001 14:30:42 -0700
> 
> 
>   In message < 200101092020.PAA25574@mal-ach.watson.ibm.com >you write:
>   > 	It's not just slowing down a 32-bit target, it is slowing down a
>   > 32x64 cross when the developer does not want it.
> For proper 32x64 HOST_WIDE_INT must be a 64bit type.  Yes, things appear to
> mostly work if it isn't, but eventually it's going to break if you stress
> the tools enough.

It seems to work OK on AIX.  (Recall, AIX has a 32-bit and 64-bit
compiler in the same 32-bit executable---that's the reason that the
patch believes it needs a 64-bit HOST_WIDE_INT.)

I do know that there are certain things that don't work, though, like
creating > 2G objects or using TImode.

> I'm not arguing for or against Alex's patch right now (I'm still reading
> the thread), but I wanted to make sure that everyone knows there are
> correctness issues this patch is trying to address.

I don't think anyone believes that this should _not_ work; it's just
that it may not be the best choice, and even if it is this isn't the
time to switch now.

-- 
- Geoffrey Keating <geoffk@geoffk.org>