On Fri, 10 Apr 2020, Thomas Schwinge wrote:
> > I run mu code with :
> > gfortran -fopenacc -fno-automatic -s Test.f90 -o Test
>
> I don't know off-hand what '-s' means here, but otherwise that should be
> good -- assuming GCC has been built with AMD GPU offloading support, has
> been properly in
Thanks for your answer.
On Thu, Mar 26, 2020 at 6:00 PM Thomas Schwinge
wrote:
> Hi!
>
> On 2020-03-26T12:14:53+0430, MAHDI LOTFI via Gcc wrote:
> > I am a researcher from Jam Petrochemical company I want to use OpenACC
> with
> > GCC compiler. I have a question about your compiler.
>
> Thanks
Hi!
On 2020-03-26T12:14:53+0430, MAHDI LOTFI via Gcc wrote:
> I am a researcher from Jam Petrochemical company I want to use OpenACC with
> GCC compiler. I have a question about your compiler.
Thanks for your interest in this.
> Does your compiler support OpenACC in windows OS or not?
As far a
Thanks a lot.
On Thu, Mar 26, 2020 at 2:32 PM Jonathan Wakely
wrote:
> Please don't cross-post to both the gcc and gcc-help mailing lists.
> Either your question is about GCC development, or it's about help
> using GCC, not both. Pick one list.
>
> On Thu, 26 Mar 2020 at 08:44, MAHDI LOTFI via G
Please don't cross-post to both the gcc and gcc-help mailing lists.
Either your question is about GCC development, or it's about help
using GCC, not both. Pick one list.
On Thu, 26 Mar 2020 at 08:44, MAHDI LOTFI via Gcc wrote:
>
> Hello
> I am a researcher from Jam Petrochemical company I want to
On Mon, Sep 10, 2018 at 08:20:02PM +, Moore, Catherine wrote:
> Following up various conversations that took place at Cauldron over the
> weekend: There is a need for a dedicated OpenACC maintainer. Thomas
> Schwinge has a long history with the OpenACC project and is willing to
> take on this
On Fri, Oct 16, 2015 at 11:44:17AM +0200, Thomas Schwinge wrote:
> But: working on getting our changes into trunk, for example, when we make
> an effort to extract from gomp-4_0-branch self-contained, individual
> patches, but it then takes weeks to get commit approval or review
> comments, I don't
On 10/16/2015 11:44 AM, Thomas Schwinge wrote:
Lately, Bernd has
stepped up a few times to review OMP patches (many thanks, Bernd!), but
also he sometimes stated that even though a patch appears fine to him,
he'd like "Jakub to have a look".
I'll just comment on this briefly. In general I'll tr
On 11/21/13 14:42, Jerome Glisse wrote:
What worries me is that no one is thinking about how to bundle the
end result ie do you add a new elf section that has ptx code that
can then be lower at runtime and also provide fallback CPU code for
all those function so that program can start running wi
* Nathan Sidwell:
> Targeting PTX, an ISA for use with a single manufacturer's devices, is
> not different from targeting the other single-manufacturer ISAs that
> GCC already supports.
The GCC licensing exception explicitly permits targeting virtual
instruction sets, which (to me at least) stron
> I came across a news about gcc will support OpenACC/OpenMP target
> directive. How can i download this version?
There some action should be done to get sources:
git clone git://gcc.gnu.org/git/gcc.git
cd gcc
git config --add remote.origin.fetch
refs/remotes/openacc-1_0-branch:refs/remotes/origi
Güray Özen wrote:
I came across a news about gcc will support OpenACC/OpenMP target
directive. How can i download this version?
Well, the support is at an early stage, targetting several different
backends. The work is done by several teams and, hence, not always very
well coordinated. I thin
On 11/16/13 22:22, Jeff Law wrote:
On 11/16/13 21:58, Alec Teal wrote:
Now while great, is this true!? Nvidia (IIRC, this was like a year ago
though) don't even give out the instruction set for their GPUs, can we
have GCC targeting closed things? Also there (must be and is) a Cuda
runtime, would
On 11/17/13 07:32, Jeff Hammond wrote:
On Nov 16, 2013, at 11:22 PM, Jeff Law wrote:
On 11/16/13 21:58, Alec Teal wrote:
Now while great, is this true!? Nvidia (IIRC, this was like a year ago
though) don't even give out the instruction set for their GPUs, can we
have GCC targeting closed thing
> On Nov 16, 2013, at 11:22 PM, Jeff Law wrote:
>
>> On 11/16/13 21:58, Alec Teal wrote:
>> Now while great, is this true!? Nvidia (IIRC, this was like a year ago
>> though) don't even give out the instruction set for their GPUs, can we
>> have GCC targeting closed things? Also there (must be and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Alec,
> Nvidia (IIRC, this was like a year ago though) don't even give out
the instruction set for their GPUs
I understand you don't want to bound to PTX virtual assembler, as it
conversion to GPU native assembler relies on proprietary component.
On 11/16/13 21:58, Alec Teal wrote:
Now while great, is this true!? Nvidia (IIRC, this was like a year ago
though) don't even give out the instruction set for their GPUs, can we
have GCC targeting closed things? Also there (must be and is) a Cuda
runtime, wouldn't we need an open runtime to link
Hi!
On Mon, 30 Sep 2013 09:30:47 +0200, Jakub Jelinek wrote:
> On Mon, Sep 30, 2013 at 12:05:55AM +0200, Thomas Schwinge wrote:
> > Is my understanding correct that the GCC policy regarding extensions such
> > as support for OpenACC or OpenMP 4 is: first develop and polish this on a
> > branch (s
Hi, Thomas!
>
> Unfortunately, even with that in place, I'm getting ICEs in LTO
> streaming (that is, the test cases specifying -flto GCC's testsuite),
> and also for trivial OpenACC code with -fopenacc, both for Fortran and
> C code.
This was fixed yesterday with exception of LTO which was not t
On Mon, Sep 30, 2013 at 12:05:55AM +0200, Thomas Schwinge wrote:
> Is my understanding correct that the GCC policy regarding extensions such
> as support for OpenACC or OpenMP 4 is: first develop and polish this on a
> branch (such as openacc-1_0-branch or gomp-4_0-branch), and once
> *everything*
Hi!
On Thu, 26 Sep 2013 22:19:31 +0400, Evgeny Gavrin wrote:
> My colleagues and I shared our current implementation of OpenACC 1.0
> to the [openacc-1_0-branch].
Many thanks for posting this; I had a first look at your patch. I'm
still learning my share of GCC internals in this area; thi
Dinar Temirbulatov wrote:
>Another interesting use-case for OpenACC and OpenMP is mixing both
>standard
>annotations for the same loop:
> // Compute matrix multiplication.
>#pragma omp parallel for default(none) shared(A,B,C,size)
>#pragma acc kernels pcopyin(A[0:size][0:size],B[0:size][0:size])
Another interesting use-case for OpenACC and OpenMP is mixing both
standard annotations for the same loop:
// Compute matrix multiplication.
#pragma omp parallel for default(none) shared(A,B,C,size)
#pragma acc kernels pcopyin(A[0:size][0:size],B[0:size][0:size]) \
pcopyout(C[0:size][0:size])
Jakub Jelinek wrote:
[Fallback generation of CPU code]
If one uses the OpenMP 4.0 accelerator pragmas, then that is the required
behavior, if the code is for whatever reason not possible to run on the
accelerator, it should be executed on host [...]
(I haven't checked, but is this a compile time
On Fri, May 10, 2013 at 11:00:29AM +0200, Richard Biener wrote:
> >> Which
> >> means changing the GOMP runtime in a way to be able to pass a descriptor
> >> which eventually has accelerator code (and a fallback regular function so
> >> you can disable accelerator usage at runtime).
> >
> > It prob
On Wed, May 8, 2013 at 10:25 PM, Torvald Riegel wrote:
> On Tue, 2013-05-07 at 12:46 +0200, Richard Biener wrote:
>> On Tue, May 7, 2013 at 12:42 PM, Richard Biener
>> wrote:
>> > On Tue, May 7, 2013 at 11:02 AM, Tobias Burnus wrote:
>> >> Richard Biener wrote:
>> >>>
>> >>> We're going to look
On Wed, May 8, 2013 at 10:12 PM, Torvald Riegel wrote:
> On Tue, 2013-05-07 at 10:27 +0200, Richard Biener wrote:
>> On Mon, May 6, 2013 at 5:16 PM, Jeff Law wrote:
>> > On 05/06/2013 07:41 AM, Tobias Burnus wrote:
>> >>
>> >> Evgeny Gavrin wrote:
>> >>>
>> >>> What do you think about support of
On Tue, 2013-05-07 at 12:46 +0200, Richard Biener wrote:
> On Tue, May 7, 2013 at 12:42 PM, Richard Biener
> wrote:
> > On Tue, May 7, 2013 at 11:02 AM, Tobias Burnus wrote:
> >> Richard Biener wrote:
> >>>
> >>> We're going to look at supporting HSA from GCC (which would make it more
> >>> or le
On Tue, 2013-05-07 at 10:27 +0200, Richard Biener wrote:
> On Mon, May 6, 2013 at 5:16 PM, Jeff Law wrote:
> > On 05/06/2013 07:41 AM, Tobias Burnus wrote:
> >>
> >> Evgeny Gavrin wrote:
> >>>
> >>> What do you think about support of OpenACC 1.0
> >>> (http://www.openacc-standard.org/) in gcc?
> >
On Tue, 2013-05-07 at 17:34 +0200, Jakub Jelinek wrote:
> On Tue, May 07, 2013 at 11:02:08AM +0200, Tobias Burnus wrote:
> > Richard Biener wrote:
> > >We're going to look at supporting HSA from GCC (which would make
> > >it more or less trivial to also target openCL I think)
> >
> > For the frien
On Tue, 2013-05-07 at 13:00 +0400, Evgeny Gavrin wrote:
> Hi, all!
>
> > Which accelerators do you intent to handle? "Accelerator" is a rather
> > broad term, covering DSPs, GPUs, Intel's MIC, ...
> The idea is to emit OpenCL from high-GIMPLE, for know. So, any device
> that has OpenCL support
On Tue, May 07, 2013 at 11:02:08AM +0200, Tobias Burnus wrote:
> Richard Biener wrote:
> >We're going to look at supporting HSA from GCC (which would make
> >it more or less trivial to also target openCL I think)
>
> For the friends of link-time optimization (LTO):
>
> Unless I missed some fine p
On Tue, May 7, 2013 at 12:42 PM, Richard Biener
wrote:
> On Tue, May 7, 2013 at 11:02 AM, Tobias Burnus wrote:
>> Richard Biener wrote:
>>>
>>> We're going to look at supporting HSA from GCC (which would make it more
>>> or less trivial to also target openCL I think)
>>
>>
>> For the friends of l
On Tue, May 7, 2013 at 11:02 AM, Tobias Burnus wrote:
> Richard Biener wrote:
>>
>> We're going to look at supporting HSA from GCC (which would make it more
>> or less trivial to also target openCL I think)
>
>
> For the friends of link-time optimization (LTO):
>
> Unless I missed some fine point
Richard Biener wrote:
We're going to look at supporting HSA from GCC (which would make it
more or less trivial to also target openCL I think)
For the friends of link-time optimization (LTO):
Unless I missed some fine point in OpenACC and OpenMP's target, they
only work with directives which a
Hi, all!
> Which accelerators do you intent to handle? "Accelerator" is a rather
> broad term, covering DSPs, GPUs, Intel's MIC, ...
The idea is to emit OpenCL from high-GIMPLE, for know. So, any device
that has OpenCL support can be utilized by ACC.
Maybe, we'll be able to reuse some parts from
On Mon, May 6, 2013 at 5:16 PM, Jeff Law wrote:
> On 05/06/2013 07:41 AM, Tobias Burnus wrote:
>>
>> Evgeny Gavrin wrote:
>>>
>>> What do you think about support of OpenACC 1.0
>>> (http://www.openacc-standard.org/) in gcc?
>>
>>
>> I like the idea - though, I wonder whether OpenMP 4.0's "target"*
On Mon, 2013-05-06 at 16:17 +0400, Evgeny Gavrin wrote:
> What do you think about support of OpenACC 1.0
> (http://www.openacc-standard.org/) in gcc?
Is there a specific reason for targeting 1.0 instead of 2.0 (besides 2.0
still being declared as a draft)?
Also, adding to Tobias' question: Which
On 05/06/2013 07:41 AM, Tobias Burnus wrote:
Evgeny Gavrin wrote:
What do you think about support of OpenACC 1.0
(http://www.openacc-standard.org/) in gcc?
I like the idea - though, I wonder whether OpenMP 4.0's "target"* would
be the better choice as it looks a bit more flexible and better de
Evgeny Gavrin wrote:
What do you think about support of OpenACC 1.0
(http://www.openacc-standard.org/) in gcc?
I like the idea - though, I wonder whether OpenMP 4.0's "target"* would
be the better choice as it looks a bit more flexible and better defined.
(Conceptually, they are very similar;
40 matches
Mail list logo
