This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs-971105 config.guess and gcc/config.guess have diverged
- To: law at cygnus dot com, rth at cygnus dot com
- Subject: Re: egcs-971105 config.guess and gcc/config.guess have diverged
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Thu, 13 Nov 1997 17:58:13 -0500 (EST)
- Cc: egcs at cygnus dot com, ghazi at caip dot rutgers dot edu, wilson at cygnus dot com
> From: Richard Henderson <rth@dot.cygnus.com>
>
> On Wed, Nov 12, 1997 at 04:48:23PM -0500, Kaveh R. Ghazi wrote:
> > I don't think the problem is, as you imply above, that support
> > is missing. The issue is that ev5* support is there and broken. At
> > least I couldn't bootstrap my ev5 with egcs out of the box.
>
> It's not ev5 thats the problem but ev56 (since it is ev5's that I have),
> almost certainly caused by the relatively untested byte-word extension.
>
> We should probably not enable MASK_BYTE_OPS by default in configure.in
> until we've got it fixed.
> r~
> From: Jeffrey A Law <law@cygnus.com>
>
> In message <19971112150154.29821@dot.cygnus.com>you write:
> > On Wed, Nov 12, 1997 at 04:48:23PM -0500, Kaveh R. Ghazi wrote:
> > > I don't think the problem is, as you imply above, that support
> > > is missing. The issue is that ev5* support is there and broken. At
> > > least I couldn't bootstrap my ev5 with egcs out of the box.
> >
> > It's not ev5 thats the problem but ev56 (since it is ev5's that I have),
> > almost certainly caused by the relatively untested byte-word extension.
> >
> > We should probably not enable MASK_BYTE_OPS by default in configure.in
> > until we've got it fixed.
> Kaveh -- can you try removing MASK_BYTE_OPS in gcc/{configure,configure,in}
> for the alpha56 target, then try to bootstrap the ev56?
>
> If that works we can use it for the release; for the mainline we've already
> sucked in the work from ev56 work from the FSF tree.
> jeff
Gentlemen,
I am still not convinced when you say I am using an ev56. (I
know it sounds kind of silly that I can't identify what system I am
using. I am logging in remotely to a guest account so I can't actually
look at the physical box to check anything.)
From "sizer -c" I get:
> cpu "DEC_KN20AA"
in case that helps ID the chip.
How do you explain the discrepancy between
testgcc-971104/config.guess (which says alphaev5-dec-osf4.0b) and
egcs/config.guess (which says alphaev56-dec-osf4.0)?
In a message from rth:
(http://www.cygnus.com/ml/egcs/1997-Nov/0434.html) I was told that the
gcc2 config.guess gets it right. So I say the entire problem lies in
the fact that egcs/config.guess gets my chip wrong which of course
causes the bootstrap to fail.
Regarding testing without setting MASK_BYTE_OPS, I think I've
already verified that avoiding setting this works, in a round about way.
What I did was bootstrap with "configure alphaev5-dec-osf4.0b" to test
if that worked (it did) since I suspected that my system was in fact an
ev5, not an ev56 as egcs claimed.
Looking in configure, the difference between alphaev5 and ev56
is only the MASK_BYTE_OPS. So having a successful bootstrap
configured as alphaev5-dec-osf4.0b should give us confidence that
taking out the MASK_BYTE_OPS makes it work on my system.
However I don't think this looking at the problem this way is
the right issue to examine, as I explained above.
--Kaveh
--
Kaveh R. Ghazi Project Manager
ghazi@caip.rutgers.edu ICon CMT Corp.