This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: wide-int, fortran
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: "N.M. Maclaren" <nmm1 at cam dot ac dot uk>, 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: Sun, 24 Nov 2013 22:44:31 +0900
- 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> <Prayer dot 1 dot 3 dot 5 dot 1311241338000 dot 23892 at hermes-2 dot csi dot cam dot ac dot uk>
Hi,
On 2013-11-24 22:38, N.M. Maclaren wrote:
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.
please note that the standard-mandated compile-time evaluation is
handled almost [*] entirely inside the Fortran frontend, viz. arith.c,
resolve.c, simplify.c, intrinsic.c, maybe others, whereas the wide-int
changes deal with the middle-end interface and touches none of these files.
Cheers,
- Tobi
[*] TRANSFER the a special case because it needs to know memory layouts
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.