This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: wide-int, fortran


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 ....


Regards,
Nick Maclaren.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]