This is the mail archive of the gcc-bugs@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]
Other format: [Raw text]

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398



------- Comment #20 from rob1weld at aol dot com  2009-01-28 06:23 -------
(In reply to comment #17)
> Subject: Re:  [4.3/4.4 Regression] ICE in set_value_range,
> On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:
> 
> > > It's very clear to me by now that HOST_WIDE_INT should only depend on the 
> > > target (probably only on the target architecture), not the host; that's 
> > > the only way to ensure consistency between hosts for the same target.  
Yes.

> > But the (sub)problem here is that the same target architecture (32-bit i386)
> > has different HOST_WIDE_INT size depending on whether GCC is a 32-bit
> > single-arch or a 32-/64-bit bi-arch compiler.
> 
> My claim is that we should stop doing this: it should always be 64-bit for 
> x86 and ARM, rather than depending on whether the target is biarch (x86) 
> or whether it is EABI (ARM), just as it is for other targets that may or 
> may not be biarch (MIPS, Power, SPARC).

(In reply to comment #18)
>The problem on ix86 is I believe that on such a register starved host, using
>long long in many places will mean very noticeable performance degradation.

Whether the value ought to be 64 or 32 bit depends on the "boot mode" of the
Target and which size code runs fastest. Register usage may be considered
but memory usage is usually not considered since ram (or HD space) is cheap.

In the event that the Target has an abnormally small amount of memory
(Picochip?) or is truly short of registers (386) then you ought to go 32 
bit even if 64 bit were quicker due to this being a bigger win in the end.


In architectures where you could be in either boat a compiler switch
would be a great feature. A Pragma with the ability to set mode on
a function by function basis would be great for writing Drivers.

If I had a Desktop computer with a MIPS or Arm uP I would likely want 
64 bits but if I was trying to cross-compile for my Router (MIPS Linux 
2.6 with 64 M) or my Cell Phone (Arm Symbian with 96 M) then I would
likely want 32 bit as the memory available is scarce.


In Fedora 10 this seems to be well handled by the OS's header's:

/usr/include/inttypes.h

#if __WORDSIZE == 64

/* We have to define the `uintmax_t' type using `ldiv_t'.  */
typedef struct
  {
    long int quot;              /* Quotient.  */
    long int rem;               /* Remainder.  */
  } imaxdiv_t;

#else

/* We have to define the `uintmax_t' type using `lldiv_t'.  */
typedef struct
  {
    long long int quot;         /* Quotient.  */
    long long int rem;          /* Remainder.  */
  } imaxdiv_t;

#endif


Make it fast, make it practical, make it work,

Rob


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934


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