[fortran] Handle POW/CPOW builtins for all floating-point types

On 08/31/2010 12:20 AM, FX wrote:
> Extension of my previous front-end patch for builtins, which was missing POW/CPOW (and integer pow, i.e. powi and _gfortran_pow_r*_i*).
>
> Bootstrapped and regtesting on x86_64-linux (a really really clean tree this time, I promise!)
> OK to commit?

OK. Thanks for the patch.

Tobias

PS: You wrote for the RFC patch:
"Array intrinsics *do not work at all*. This is a limitation of the 
array descriptor structure, which I cannot overcome by myself."
Wouldn't it work to use a patch as the following - or have I missed some 
fine print? I think we have enough bits to fit 8 DTYPEs - and without 
the following patch I only count 7.

Committed as rev. 163721, thanks for the review.

Regarding array descriptors:

> "Array intrinsics *do not work at all*. This is a limitation of the array descriptor structure, which I cannot overcome by myself."
> Wouldn't it work to use a patch as the following - or have I missed some fine print? I think we have enough bits to fit 8 DTYPEs - and without the following patch I only count 7.

I'll have to check... in your idea, would a real(kind=16) descriptor have only GFC_DTYPE_FLOAT128 set, or (GFC_DTYPE_FLOAT128 | GFC_DTYPE_REAL)?

FX

FX wrote:
> I'll have to check... in your idea, would a real(kind=16) descriptor have only GFC_DTYPE_FLOAT128 set, or (GFC_DTYPE_FLOAT128 | GFC_DTYPE_REAL)?

Well, I think both will be the same: All 3 bits will be set to 1. You 
can only store 8 = 2^3 states in 3 bits, 7 states are currently in use ...

My idea was to use GFC_DTYPE_FLOAT128 for software REAL values. For 
backward compatibility, we still use GFC_DTYPE_REAL for REAL(10) and 
hardware REAL(16). All conditions in libgfortran have to use "==" as OR 
and AND will not work.

Tobias

> Well, I think both will be the same: All 3 bits will be set to 1. You can only store 8 = 2^3 states in 3 bits, 7 states are currently in use ...

Right, sorry. I haven't had my coffee yet.

> My idea was to use GFC_DTYPE_FLOAT128 for software REAL values. For backward compatibility, we still use GFC_DTYPE_REAL for REAL(10) and hardware REAL(16). All conditions in libgfortran have to use "==" as OR and AND will not work.

So everything in libgfortran that checks for (dtype == GFC_DTYPE_REAL) will need to check for (dtype == GFC_DTYPE_REAL || dtype == GFC_DTYPE_FLOAT128).

Before I go and change everything, now that the "end of stage 1" date has been announced (Oct 27th), will there be a push for the array descriptor rework to make it in 4.6, or will it wait for 4.7?

Regards,
FX

On 09/01/2010 10:59 AM, FX wrote:
> So everything in libgfortran that checks for (dtype == GFC_DTYPE_REAL) will need to check for (dtype == GFC_DTYPE_REAL || dtype == GFC_DTYPE_FLOAT128).

Yes.

> Before I go and change everything, now that the "end of stage 1" date has been announced (Oct 27th), will there be a push for the array descriptor rework to make it in 4.6, or will it wait for 4.7?

That's unclear. It still requires some work to get the basic 
implementation regression free, then one needs to agree on the used 
elements - and implement them. I think end of October is possible, but I 
wouldn't be surprised if it takes longer.

Tobias