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
