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: GCC build failed with your patch on 2001-01-09T11:35:00Z.


  In message <200101091939.OAA28600@mal-ach.watson.ibm.com>you write:
  > >>>>> Alexandre Oliva writes:
  > 
  > Alexandre> Besides, there's a number of tests that fail unless HOST_WIDE_IN
  > T is
  > Alexandre> at least as wide as size_t or ptrdiff_t (I don't recall for sure
  > Alexandre> which; maybe both).  This is what motivated me to write this pat
  > ch,
  > Alexandre> and it's working fine on a number of other 32/64-bit targets.
  > 
  > 	This patch isn't even an optimization, it is a trade-off.
But fundamentally, you need HOST_WIDE_INT to be at least as wide as size_t
or ptdiff_t for the target.  That's a correctness issue.  [ HOST_WIDE_INT must
also be no less than 1/2 the size of the largest integer type the target is
supporting. ]

One way to deal with it is to make HOST_WIDE_INT be a larger type.  That
seems pretty simple.  Furthermore, targets can't handle that are broken.
Of course we don't want to widen HOST_WIDE_INT unless it's really 
necessary for correct operation on the target we're compiling for.

Another way to deal with this is to remove the assumption that HOST_WIDE_INT
is as wide as size_t or ptrdiff_t.  This may be a better long term solution,
then again it may not.  I would think this carries more risk than widening
HOST_WIDE_INT.

The former solution would at first glance seem to be the safer and simpler
solution and would be my choice were I in Alex's position right now.

Now it turns out we've got a broken port.  So what is the best way to 

  1. Fix Alex's problem  -- and --
  2. Get the PPC work working again.


?

jeff


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