On 11/04/14 09:11, Jakub Jelinek wrote:
On Tue, Nov 04, 2014 at 07:41:42AM -0800, Steve Kargl wrote:
On Tue, Nov 04, 2014 at 03:34:43PM +0100, Bernd Schmidt wrote:
The ptx port by its nature is lacking features that are expected on
"normal" machines, such as alloca and indirect jumps. We have a subset
of the C library which contains functions that can be implemented on the
target (excluding things like file I/O other than printf which is a ptx
builtin).
It would be good to be able to also build as much of libgfortran as
possible, and the following patch is what I've been using so far. It
recognizes the target at configure time and restricts the list of
compiled files, as well as providing a LIBGFOR_MINIMAL define for #ifdef
tests. There's also a new file minimal.c which contains alternative
implementations of some functionality (using printf to write error
messages rather than fprintf and such). Constructors are currently
unimplemented on ptx and therefore the init function is commented out.
Comments on the approach, do the Fortran maintainers have a preference
how this should look? The whole thing is good enough to substantially
reduce the number of failures when trying to run the Fortran testsuites
on nvptx (although many remain).
It is unclear to me from reading the diff whether this patch
cause gfortran on ptx to knowingly violate the fortran standard.
If the answer is "yes, this patch causes gfortran on ptx to
violate the standard", then the patch is IMHO unacceptable.
The point is, if the target can implement just a subset of the Fortran (or
C or C++) standards, then ideally if you use anything that is not supported
would just cause always host fallback, the code will still work, but will
not be offloaded. So even supporting a subset of the standard is
worthwhile, usually one will just offload the most performance critical
parts of his code.
Also note there's a reasonable chance that the GPUs will continue to
evolve and will be able to support more of the standard language
features. Not sure if they'll ever do the IO side of Fortran, but they
could always surprise us.
jeff
