This is the mail archive of the
mailing list for the GCC project.
Re: wide-int, fortran
- From: "N.M. Maclaren" <nmm1 at cam dot ac dot uk>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Andrew Pinski <pinskia at gmail dot com>, Steve Kargl <sgk at troutmask dot apl dot washington dot edu>, Mike Stump <mikestump at comcast dot net>, "gcc-patches at gcc dot gnu dot org Patches" <gcc-patches at gcc dot gnu dot org>, gfortran List <fortran at gcc dot gnu dot org>
- Date: 24 Nov 2013 13:38:00 +0000
- Subject: Re: wide-int, fortran
- Authentication-results: sourceware.org; auth=none
- References: <DDF8569C-14AF-4E64-AA91-0EA50A49E043 at comcast dot net> <20131123201618 dot GA31525 at troutmask dot apl dot washington dot edu> <CA+=Sn1nS7QG6MyZjjAO4yR5LhfUWRE3H=CwrKnKZC_QmK459Hw at mail dot gmail dot com> <Prayer dot 1 dot 3 dot 5 dot 1311241016280 dot 23162 at hermes-2 dot csi dot cam dot ac dot uk> <5291F5B6 dot 8070503 at naturalbridge dot com>
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 :-(
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 ....