Re: 32->64 bit cross compilers

Re: 32->64 bit cross compilers

[Janis Johnson]

On Tue, 24 Apr 2001, Mark Mitchell wrote:

> PR912 refers to a feature regression from GCC 2.95.x: we were at some
> point unable to cross-compiler from 32-bit machines to 64-bit machines
> to TImode popping up in libgcc2.h.
>
> I know we debated what to do about this, but I do not know how the
> debate ended.  Let's please not have the debate again, if we can help
> it.
>
> Instead, I would appreciate it if someone would:
>
>   - Tell me if the problem still exists.
>
>   - Point me at a summary of the outcome of the debate.
>
> If we haven't fixed this problem yet, we'll have to make a decision
> very soon about what to do, and I would like to be informed by the
> collective wisdom of the earlier discussion.

It's still broken for host ix86 and target ia64.  There was a discussion
of that earlier this month:

On Apr 3, 2001 Alexandre Oliva <aoliva@redhat.com> wrote:

> On Apr  2, 2001, Jim Wilson <wilson@cygnus.com> wrote:
>
> > In the Red Hat tools group, what we do is define HOST_WIDE_INT to
> > "long long" instead of "long" for cross compilers from 32-bit hosts
> > to 64-bit targets.  This is done via an ugly config.gcc hack.  This
> > makes the cross gcc run slower, but the resulting code will be much
> > closer to what you would get with a native compiler. [...] What it
> > really needs is someone to clean it up and make it more presentable
> > so that we can put it in the FSF tree.
>
> FWIW, I've just fixed (but not installed yet; will do momentarily) at
> least some of the bugs in codegen and in the ppc back-end, that
> prevented the adoption of the patch that automatically selected `long
> long' for HOST_WIDE_INT if the target has 64-bits wide longs, which
> obviates the ugly hack we currently have.

Is someone from Red Hat looking at cleaning up the config.gcc hack and
submitting it?

Janis

Re: 32->64 bit cross compilers

[Alexandre Oliva]

On Apr 25, 2001, "Janis Johnson" <janis@us.ibm.com> wrote:

> Is someone from Red Hat looking at cleaning up the config.gcc hack and
> submitting it?

I don't think so.  It's an ugly hack, and one that shouldn't ever be
installed.  I've already submitted a cleaner approach, that revealed
bugs at that time, but I've finally fixed those bugs, so maybe it's
time to try installing the patch again?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: 32->64 bit cross compilers

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> I don't think so.  It's an ugly hack, and one that
    Alexandre> shouldn't ever be installed.  I've already submitted a
    Alexandre> cleaner approach, that revealed bugs at that time, but
    Alexandre> I've finally fixed those bugs, so maybe it's time to
    Alexandre> try installing the patch again?

Would you please repost and retest a current patch, or ask for a
volunteer to do the testing for you, if you don't have an rs6000 box
that runs quickly?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: 32->64 bit cross compilers

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> >>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
> 
>     Alexandre> I don't think so.  It's an ugly hack, and one that
>     Alexandre> shouldn't ever be installed.  I've already submitted a
>     Alexandre> cleaner approach, that revealed bugs at that time, but
>     Alexandre> I've finally fixed those bugs, so maybe it's time to
>     Alexandre> try installing the patch again?
> 
> Would you please repost and retest a current patch, or ask for a
> volunteer to do the testing for you, if you don't have an rs6000 box
> that runs quickly?

Remember, powerpc-eabi has a simulator, so you can use that.

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

Re: 32->64 bit cross compilers

[Mark Mitchell]

>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes:

    Geoff> Remember, powerpc-eabi has a simulator, so you can use
    Geoff> that.

That's a good point.  I think some of the bug were AIX-ABI specific,
but I could be wrong.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: 32->64 bit cross compilers

[Alexandre Oliva]

On Apr 25, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> I don't think so.  It's an ugly hack, and one that
Alexandre> shouldn't ever be installed.  I've already submitted a
Alexandre> cleaner approach, that revealed bugs at that time, but
Alexandre> I've finally fixed those bugs, so maybe it's time to
Alexandre> try installing the patch again?

> Would you please repost and retest a current patch, or ask for a
> volunteer to do the testing for you, if you don't have an rs6000 box
> that runs quickly?

Actually, I've tested the effects of the patch a few days ago,
building ppc-eabi on an alpha box, when I was testing the CONST_INT
sign-extension patches.

Here's the patch, again.  Ok to install?

Note that it only makes sense to install it in mainline, since the
CONST_INT sign-extension patches that get it to work are not in the
3.0 branch.

Re: 32->64 bit cross compilers

[Mark Mitchell]

Yes, this is OK.  Thanks.

What do you suggest doing for the branch?

I think we don't want the CONST_INT sign-extension patches at this
point.

What is required to get us back to 2.95.x behavior?

My recollection was that we originally ran into trouble with some
patches that Kenner checked into libgcc2.  Can we disable those
changes in some ways when doing 32->64 bit crosses?  It is less
important that we get the same code when doing a cross-compile and a
native compile than that we get correct code.  If doing a 32-bit ->
64-bit cross yields slightly different code, or doesn't accept the
complete range of programs accepted natively, we can live with that.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: 32->64 bit cross compilers

[Alexandre Oliva]

On Apr 26, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>	Re-installed 2001-01-09's patch:
>>	* hwint.h (HOST_BITS_PER_WIDE_INT, HOST_WIDE_INT): Use long long
>>	if it's wider than long and the target's long is wider than the
>>	host's.

> Yes, this is OK.  Thanks.

> What do you suggest doing for the branch?

How about installing the CONST_INT sign-extension fixes, but not the
stricter checks?  Then, we could install this patch in the branch too?

> I think we don't want the CONST_INT sign-extension patches at this
> point.

All of them are relatively obvious bug-fixes.  It's only the strict
checks that may expose hidden bugs that we might want to keep hidden
in the branch.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: 32->64 bit cross compilers

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    >> What do you suggest doing for the branch?

    Alexandre> How about installing the CONST_INT sign-extension
    Alexandre> fixes, but not the stricter checks?  Then, we could
    Alexandre> install this patch in the branch too?

Thanks for the information.

Can you point me at the patch you'd like to see applied?  If it has
the "stricter checks", please indicate which pieces these are as well.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: 32->64 bit cross compilers

[Alexandre Oliva]

On May  3, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> Can you point me at the patch you'd like to see applied?  If it has
> the "stricter checks", please indicate which pieces these are as well.

<URL: http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00231.html >, except
for the changes to recog.c, that were overridden
<URL: http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00671.html > but
shouldn't be applied, since they introduce the strict checks;
<URL: http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00999.html >, and
<URL: http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01266.html >.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: 32->64 bit cross compilers

[Mark Mitchell]

Thanks for the references.

I think that we have to support 32->64 bit cross compilers in GCC 3.0,
so I think these patches should go in.  Moreover, I think we should
put in the strict checking patches as well, since it looks to me like
situations where the checks fire probably indicate that we will
otherwise generate bad code.

I'm not happy about having to do this at this point, since there is
definitely risk here.  However, you (Alexandre) didn't create the
problem, and it's great that you're fixing it.  The real problem began
with Kenner's patch way back when, and it's too bad that the problem
wasn't fixed at that point.

I'll merge the changes from the mainline, and then we'll start shaking
out whatever problems occur.  There will likely be some breakage that
we need to sort out.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: 32->64 bit cross compilers

[David Edelsohn]

	I know that Alexandre fixed the PowerPC port well enough that it
does not break with his patches enabled, but I'm not sure how well it
functions with the patches.  These are the patches that use "long long"
for 32->64, right?

	The PowerPC port hasn't been hosted on a 64-bit system and has not
been tuned for 64-bit CONST_INT.  I know that performance is not a
priority for GCC 3.0, but the last time that I was working on 64-bit
hosting, GCC was generating worse code for 64-bit PowerPC than when hosted
in 32-bit mode.  The patch of mine for rs6000_emit_move() that Alexandre
applied along with his patches was the beginning of the fixes.  If 64-bit
PowerPC code generation takes a hit on the branch, we are going to have to
address that before the release.

David

Re: 32->64 bit cross compilers

[Geoff Keating]

David Edelsohn <dje@watson.ibm.com> writes:

> 	I know that Alexandre fixed the PowerPC port well enough that it
> does not break with his patches enabled, but I'm not sure how well it
> functions with the patches.  These are the patches that use "long long"
> for 32->64, right?
> 
> 	The PowerPC port hasn't been hosted on a 64-bit system and has not
> been tuned for 64-bit CONST_INT.  I know that performance is not a
> priority for GCC 3.0, but the last time that I was working on 64-bit
> hosting, GCC was generating worse code for 64-bit PowerPC than when hosted
> in 32-bit mode.  The patch of mine for rs6000_emit_move() that Alexandre
> applied along with his patches was the beginning of the fixes.  If 64-bit
> PowerPC code generation takes a hit on the branch, we are going to have to
> address that before the release.

I think that a lot of those problems were fixed when Red Hat moved to
using 64-bit CONST_INT for x86 (in the past year).  However, it'd be
interesting to run some benchmarks and see what the impact is.

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

Re: 32->64 bit cross compilers

[Alexandre Oliva]

On May  4, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> Moreover, I think we should put in the strict checking patches as
> well, since it looks to me like situations where the checks fire
> probably indicate that we will otherwise generate bad code.

> I'm not happy about having to do this at this point, since there is
> definitely risk here.

I'm not really sure we'd end up generating bad code.  I don't recall
having seen any situation in which we'd generate bad code because of
missing sign-extension in CONST_INTs, but it may be that I just didn't
search enough.  But NOT installing the strict checking patches in the
branch will certainly reduce the overall risk.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: 32->64 bit cross compilers

[Joern Rennecke]

> I'm not really sure we'd end up generating bad code.  I don't recall
> having seen any situation in which we'd generate bad code because of
> missing sign-extension in CONST_INTs, but it may be that I just didn't
> search enough.  But NOT installing the strict checking patches in the
> branch will certainly reduce the overall risk.

I do remember having seen such cases, but they are extremely rare.
Strength reduction failures happen more often.

OTOH, occurences of constants that are not sign-extended according to the
new rules are quite common.  In particular in small modes, like 8 and 16 bit.

Re: 32->64 bit cross compilers

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> Right, but we're talking about the *branch* here, not the
    Richard> mainline.  My point was that this never really worked in
    Richard> the past,

That statement isn't really true.

"Working" is not a binary predicate; it's real-valued.

Because some test-cases didn't work doesn't mean "this never really
worked".  In fact, for many users, it worked just fine, and people got
useful work done.  You comitted a patch that made cross-compilers
cease to work for those people, and that constitutes a regression for
those people.

Fortunately, Jim Wilson has suggested, privately, a solution that
seems likely to solve the problem without having to merge Alexandre's
stuff to the branch.  We all agree that is the right way to go,
eventually, but that it's riskier than we'd like at the moment.

Hopefully, Jim's approach will work out.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: 32->64 bit cross compilers

[Richard Kenner]

    To me it is pretty important to be able to do Linux->Sparc 64 cross
    compilation at least, since this (along with NT->Sparc 64) is a likely
    desired combination.

Right, but we're talking about the *branch* here, not the mainline.
My point was that this never really worked in the past, we shouldn't
risk destabilizing the branch to make it work there now.  I agree this is
important for the mainline.

Re: 32->64 bit cross compilers

[dewar]

<<I think it would be *nice*, but I don't think we "have to".  This never
really worked right due to config files that didn't properly check
the bounds of constants, mostly in the older machines.  So I don't
think it's so terrible if it still doesn't, especially since changes to
fix these things can easily cause instability.
>>

Oops, of course I meant to say GNU/Linux -> 64-bit Sparc cross-compilation
(the inclination to abbreviate when typing in text fast in email mode is
hard to resist :-)

Re: 32->64 bit cross compilers

[dewar]

<<I think it would be *nice*, but I don't think we "have to".  This never
really worked right due to config files that didn't properly check
the bounds of constants, mostly in the older machines.  So I don't
think it's so terrible if it still doesn't, especially since changes to
fix these things can easily cause instability.
>>

To me it is pretty important to be able to do Linux->Sparc 64 cross
compilation at least, since this (along with NT->Sparc 64) is a likely
desired combination.

Re: 32->64 bit cross compilers

[Richard Kenner]

    I think that we have to support 32->64 bit cross compilers in GCC 3.0,
    so I think these patches should go in.

I think it would be *nice*, but I don't think we "have to".  This never
really worked right due to config files that didn't properly check
the bounds of constants, mostly in the older machines.  So I don't
think it's so terrible if it still doesn't, especially since changes to
fix these things can easily cause instability.

Re: 32->64 bit cross compilers

[Mark Mitchell]

Thank you for the information.  

That is suggestive that the bug is fixed, but perhaps someone else
knows for sure.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: 32->64 bit cross compilers

[Bo Thorsen]

On Tue, 24 Apr 2001, Mark Mitchell wrote:

>
> PR912 refers to a feature regression from GCC 2.95.x: we were at some
> point unable to cross-compiler from 32-bit machines to 64-bit machines
> to TImode popping up in libgcc2.h.
>
> I know we debated what to do about this, but I do not know how the
> debate ended.  Let's please not have the debate again, if we can help
> it.
>
> Instead, I would appreciate it if someone would:
>
>   - Tell me if the problem still exists.
>
>   - Point me at a summary of the outcome of the debate.
>
> If we haven't fixed this problem yet, we'll have to make a decision
> very soon about what to do, and I would like to be informed by the
> collective wisdom of the earlier discussion.

I don't know if this is helpful.

I can't comment on sparc64, but we - the x86-64 team - do a x86-64-elf
crosscompilation on a x86 host and this seems to work. I have compiled
binutils, gcc and glibc just last weekend. I didn't actually try running
the binaries, but PR912 says it dies during the buildprocess, so at least
the problem would have changed.

Bo.

-- 

     Bo Thorsen                 |   28 Merton Road
     Free software developer    |   Slough, SL1 1QW
     SuSE Labs                  |   England

32->64 bit cross compilers

[Mark Mitchell]

PR912 refers to a feature regression from GCC 2.95.x: we were at some
point unable to cross-compiler from 32-bit machines to 64-bit machines
to TImode popping up in libgcc2.h.

I know we debated what to do about this, but I do not know how the
debate ended.  Let's please not have the debate again, if we can help
it.

Instead, I would appreciate it if someone would:
 
  - Tell me if the problem still exists.

  - Point me at a summary of the outcome of the debate.

If we haven't fixed this problem yet, we'll have to make a decision
very soon about what to do, and I would like to be informed by the
collective wisdom of the earlier discussion.

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com