From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kaveh R. Ghazi" To: law@cygnus.com, rth@cygnus.com Cc: egcs@cygnus.com, ghazi@caip.rutgers.edu, wilson@cygnus.com Subject: Re: egcs-971105 config.guess and gcc/config.guess have diverged Date: Thu, 13 Nov 1997 14:58:00 -0000 Message-id: <199711132258.RAA04169@caip.rutgers.edu> X-SW-Source: 1997-11/msg00492.html > From: Richard Henderson > > 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 > > 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.