wide-int, fortran

[Tobias Burnus]

Am 24.11.2013 13:56, schrieb Kenneth Zadeck:
>
> On 11/24/2013 05:50 AM, Tobias Burnus wrote:
>> - if (hi || low < 0
>> ...
>> + if (((!as || as->type != AS_ASSUMED_RANK)
>> + && wi::geu_p (bound, GFC_TYPE_ARRAY_RANK (TREE_TYPE (desc))))
>> + || wi::gtu_p (bound, GFC_MAX_DIMENSIONS))
>> gfc_error ("'dim' argument of %s intrinsic at %L is not a valid "
>> "dimension index", upper ? "UBOUND" : "LBOUND",
>> &expr->where);
>>
>> I don't see what happened to the "low < 0" check. (Ditto for the next 
>> chunk in conv_intrinsic_cobound).
>> Otherwise, it looks okay to me.
>>
> This is the magic of using the correct representation. All this code 
> really wanted to check is that bound is a small positive integer.

I think one of the problems I had with reviewing the patch – as others – 
that there is no documentation for the functions provided by the patch 
itself. I found the bits in the patch wide-int-wide.diffs.txt.bz2. (The 
.bz2 successfully prevents that it is found by search engines, but 
admittedly, I haven't tried to find it.)

Nice – albeit a bit intransparent – use of two's complement numbers and 
casting to an unsigned number.

+/* Return true if X > Y when both are treated as unsigned values. */
+template <typename T1, typename T2>
+inline bool
+wi::gtu_p (const T1 &x, const T2 &y)
+{
+ return ltu_p (y, x);

Thus, the patch is okay from my side.

* * *

>>> + *logical = wi::eq_p (t, 0) ? 0 : 1; 
>>
>> I can't find the meaning of :: in n1256.pdf. What does this do? 
> wi:: eq_p means the function eq_p inside the wi struct.

I have to admit that I didn't quite understand the discussion about ISO 
C/ISO C++11 as my impression is that wide-int-wide.diffs.txt.bz2 and not 
the ISO standards matter here.

Also the discussion about unlimited-width types seems to be a bit off as 
it is "only" about the use within the compiler (when the host lacks an 
integer type the target has) and not about support for compiled code on 
the target.

But maybe I have missed some fine print.

> But at both ends of the compiler there are still limits. It is 
> expected that with this patch in place, that a back end maintainer can 
> now, for the first time, support architectures that support integers 
> wider than 128 bits. We have several public ports that appear to have 
> tried to support some operations on 256 bits but when we tried this on 
> our private port, we found an intolerable number of ices and incorrect 
> code issues. They are now gone.
>
> To the extent that this patch touches the front ends, this patch is 
> strictly plumbing. The front ends now use the new wide-int class, or 
> the new int-cst to pass integer constants around and do constant prop 
> on them. Beyond that, it is up to the front end maintainers to decide 
> how or even if they will expose this to the users of the language. C 
> and C++ currently allow the back end to tell it that they can use 
> wider types but actually specifying a large integer constant is at 
> best painful. 

I think the gfortran code currently implicitly assumes that the largest 
integer is 128bits wide; adding basic support for larger integer kinds 
is probably not difficult. However, the real work is to fully support it 
with all intrinsics. Already for 128bit integers, some work is needed as 
there for some of the intrinsics, a suitable builtin is lacking. (I 
think gfortran is the only Fortran compiler which supports 
128-bits/16-byte integers; at least all compilers I tried do not support 
it.) – I think when GCC starts to get some better support for 256-bit 
integers, gfortran will follow suite. (Or when someone explicitly 
demands it.)

> One could imagine that this is not good enough if a front end wanted 
> to say that it supports everything up to 256 bits no matter what the 
> hardware can do natively, much the way that java said that every host 
> had to do 64 bit math, even if it was just a 32 bit host. However, 
> that would require a lot more work than was done here. In particular, 
> at some level someone would have to sniff the port and break the math 
> into pieces that could be implemented on the port.

In particular, that requires some run-time support – probably both in 
libgcc and in the handling of the backend itself. On x86-64, __float128 
support already works that way. (And requires libquadmath to be fully 
usable; for integers, it should be somewhat easier.)

Tobias