This is the mail archive of the 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]

Re: IA64 bootstrap problem for Ada

Geert Bosch <> writes:

> It seems that the cleanest way to solve the issue is to "register"
> all available modes, and their properties such as int/float,
> complex or not, scalar or vector, precision, size and alignment
> with the front end. Then the front end can use that table to
> select the right type for a given declaration. This would also
> give us a clean path to using vector types where available.
> Trying to communicate everything through a single "size" property
> isn't right, and too much knowledge about available types is now
> built into the front end.

Yes, I agree.  The C front end has some appalling code in it that
could be cleaned up by this, too.

> The one thing that still bothers me though, is that for floating
> point types, we'd really need to know the mantissa width of a
> floating point type. Right now, we "know" that a type with a precision
> of 96 in reality is a 80-bit IEEE extended double precision type
> with 64 bits of mantissa. Even when Zack fixes GCC to report a
> "precision" of 80 or 82 bits for certain IA-64 floating-point types,
> we'd still need to build in knowledge into the front end about the
> size of the mantissa.

I see two ways forward on this problem.  The "precision" of floating
types could be defined to be the mantissa width, not the total number
of value bits.  Or, we could add more information to the float_format
structures defined in real.h, such that front ends could look there
for mantissa width, exponent width, etc.  I think the latter plan is
better, because it allows front ends to find out everything they need
to know about float modes, while keeping "precision" meaning "total
number of value bits" for all modes."  However, it may be more work.

I should say that my time to work on this issue right now is very
limited.  I'm going to be on vacation and completely offline for two
weeks starting Nov 9, and I must complete work for paying CodeSourcery
clients first.  But after I return (Nov 24) I hope to be able to
assist more extensively with these problems.


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