wide-int, fortran

[N.M. Maclaren]

On Nov 23 2013, Andrew Pinski wrote:
>On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl
><sgk@troutmask.apl.washington.edu> wrote:
>> On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
>>>
>>> Richi has asked the we break the wide-int patch so that the individual 
>>> port and front end maintainers can review their parts without have to 
>>> go through the entire patch. This patch covers the fortran front end.
>>>
>>> Ok?
>>>
>>> +  *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.

But you can't tell that from the code - wi might be a namespace, and
eq_p might be a class.  If there is a clear description of the subset
of C++ that the front-end is allowed to use, a pointer to it for the
benefit of Fortran/C/Ada/whatever people would be useful.  But that's
an aside from this thread.

>> Also, given the complete lack of a description of what this
>> patch does and no pointer to a discussion of what this
>> patch does, and no description of its benefit to gfortran,
>> I vote "no".
>
>The general description was in a different email:
>http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02877.html
>
>The main benefit is it allows for targets to support wider integer
>than two times HOST_WIDE_INT.  So gfortran, is that it connects to the
>rest of the middle-end of GCC.

Hmm.  Looking at that makes me none the wiser, and even a web search
doesn't do more than tell me the same aspects.  Given that Fortran has
somewhat different constraints on type widths than C, it would be very
useful to know exactly what you mean by that.  C++ is almost entirely
irrelevant here.

Now, obviously to an implementor, it doesn't mean unlimited-width types,
but does it (a) allow implementations to use hardware/firmware/emulated
built-in types however wide they are, (b) allow arbitrary-width types,
or (c) something else?  In all cases, I can see implementation issues
in gfortran that do not arise in gcc, but they are different between
those models.

So I agree that some clarification would be a good idea, to avoid
introducing secondary problems by accident.  Quite likely there will be
none, but it's hard to tell.


Regards,
Nick Maclaren.