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 attached
Hi!
On Fri, 14 Nov 2014 18:08:32 +0100, Bernd Schmidt
wrote:
> New patch below, [...]
... got committed. I now committed the following in r221363:
commit 83ba0e65833dd081db921f8c2b3277316590753c
Author: tschwinge
Date: Wed Mar 11 21:42:56 2015 +
libgfortran LIBGFOR_MINIMAL enhance
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 t
On Fri, Nov 14, 2014 at 11:28 PM, Tobias Burnus 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.
>>
>>
>> pri
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 function.
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 wra
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" m
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 w
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 nvptx
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 expe
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
> 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
som
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
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
> 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 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 whi
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 do
> 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: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'
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 (exclu
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).
21 matches
Mail list logo
