wide-int, fortran

[Kenneth Zadeck]

On 11/24/2013 08:38 AM, N.M. Maclaren wrote:
> On Nov 24 2013, Kenneth Zadeck wrote:
>
> Thank you for your posting.  That certainly clears up my understanding.
>
>>> 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.
>>
>> There is a saying in the US that "you can always tell the pioneers 
>> because they are the ones with the arrows in their back."   I feel 
>> this way with respect to C++.   When this branch first went public 
>> several months ago, the wide-int class made very modest use of C++.   
>> It has publicly evolved away from that and i would now describe the 
>> usage as somewhat aggressive.     I do not know if i think that this 
>> is good or bad, but i expect that because we are the first big patch 
>> to use C++ aggressively , that we are going to take some arrows.
>
> I think that using C++ even slightly aggressively without first deciding
> the grounds rules is a seriously bad idea.  The trouble about following
> random pioneers is that they are very likely to lead you into a swamp,
> with the loss of the whole expedition.  And, with C++, that is more than
> just likely if you follow an adventurous pioneer rather than a cautious
> one - it's damn-near certain :-(
>
i do not actually disagree with you.    my point is that this was all 
done in the open.
>> A useful way to think about this patch is that it is nothing but 
>> plumbing.    Gcc has had a painful and long evolution from being a 32 
>> bit compiler to a 64 bit compiler and beyond.  ...
>
> Yes, but that's not my point.
>
> The main problem is that integer constant expressions in C are limited to
> the built-in operators, of which the only tricky ones are division and
> remainder (and, occasionally, multiplication) - see C11 6.6#3. Fortran
> is not so limited, and there are much wider requirements for expression
> evaluation at compile time.
>
>> But at both ends of the compiler there are still limits.
>
> And my point is that this is NOT an area that separates cleanly into
> front and back end!
>
> However, from your description, this is one component of any solution
> for gfortran, and it doesn't sound as if it will cause trouble until
> and unless someone wants to extend gfortran to wider types.  They will
> then have to implement the other components ....
>
>
In any event, the problem is not with making the math work correctly, 
which is really the primary point of this patch.   It is as you say how 
the various front ends decide how they wish to exploit that power.


> Regards,
> Nick Maclaren.
>
>
>