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