This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: egcs-971105 config.guess and gcc/config.guess have diverged



 > 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]