Hi!
On 2015-03-11T22:48:22+0100, I wrote:
> On Fri, 14 Nov 2014 18:08:32 +0100, Bernd Schmidt
> wrote:
>> New patch below, [...]
>
> ... got committed. I now committed the following in r221363:
> libgfortran LIBGFOR_MINIMAL enhancements.
..., and in r276690 have now committed the
Hi!
On Fri, 14 Nov 2014 18:08:32 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
New patch below, [...]
... got committed. I now committed the following in r221363:
commit 83ba0e65833dd081db921f8c2b3277316590753c
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date:
On 11/14/2014 10:28 PM, Tobias Burnus wrote:
All in all: Okay when tesing succeeded. I still prefer some words what's
excluded (or included) in minimal as comment in configure.ac, but the
patch is also okay without.
I thought you meant something more than adding a comment. I've added
this in
Hi Tobias,
Does printf work? I thought I/O is not supported? Or does it just accept
it for linking and drop it? I think Janne's patch has already dealt with
the issue of stack allocation.
printf (or more accurately vprintf) is supported by ptx as a magic
builtin function. We have a printf
Hi Tobias,
Bernd Schmidt wrote:
Does printf work? I thought I/O is not supported? Or does it just accept
it for linking and drop it? I think Janne's patch has already dealt with
the issue of stack allocation.
printf (or more accurately vprintf) is supported by ptx as a magic
builtin
On Fri, Nov 14, 2014 at 11:28 PM, Tobias Burnus bur...@net-b.de wrote:
Hi Tobias,
Bernd Schmidt wrote:
Does printf work? I thought I/O is not supported? Or does it just accept
it for linking and drop it? I think Janne's patch has already dealt with
the issue of stack allocation.
printf
Hi all,
since everyone seems to agree that it makes in principle sense to have a
reduce libgfortran (even though a full one is nicer, if the system
permits), let's look at the patch itself ;-)
Bernd Schmidt wrote:
The ptx port by its nature is lacking features that are expected on
normal
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).
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
On 11/04/2014 04:41 PM, Steve Kargl wrote:
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.
I don't
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).
I’m afraid I don’t really see the point.
On 11/04/2014 04:59 PM, FX wrote:
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).
I’m afraid I
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
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
On Tue, Nov 04, 2014 at 05:15:52PM +0100, FX wrote:
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
On Tue, Nov 04, 2014 at 04:54:54PM +0100, Bernd Schmidt wrote:
On 11/04/2014 04:41 PM, Steve Kargl wrote:
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
See https://gcc.gnu.org/wiki/Offloading and kyukhin/gomp4-offload and
branches/gomp-4_0-branch branches. Both are in the process of being merged
into trunk these days.
Thanks for the link, I’ll look into it.
I suppose then it makes sense to provide partial libgfortran support, assuming
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
On Tue, Nov 04, 2014 at 10:20:53AM -0700, Jeff Law wrote:
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
On 11/04/14 08:54, Bernd Schmidt wrote:
Note that the intention is not to support Fortran (or any other
language) directly targetting ptx code. The only way it's supposed to be
used is as an accelerator for OpenACC offloading.
Right. To reiterate for everyone, offloading is the goal of the
On Nov 4 2014, Jeff Law wrote:
On 11/04/14 09:11, Jakub Jelinek wrote:
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
21 matches
Mail list logo
