Re: Interest in Contributing to OpenACC Support & Code Offloading Projects for GSOC

ware Engineer at Qualcomm > Wireless R&D. I recently discovered your organization and the exciting GSOC > projects you are proposing, namely "Offloading to a separate process on the > same host" and "Enhance OpenACC support." I am writing to express my > enthusi

Interest in Contributing to OpenACC Support & Code Offloading Projects for GSOC

d the exciting GSOC projects you are proposing, namely "Offloading to a separate process on the same host" and "Enhance OpenACC support." I am writing to express my enthusiastic interest in potentially contributing to either of these projects and to inquire about the next steps to

[OpenACC] cheking the status of AMD GPU offloading performance

Hi everyone, I have a general question regarding the GPU offloading support on AMD GPUs using OpenACC or OpenMP. I am doing some tests by compiling the new version of GCC (13 and 14), following the instructions online (https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC

Re: GCC and OpenACC

Dear Mikel, thanks for the example. I have now filled a tracking issue at https://gcc.gnu.org/PR103988. Currently, GCC only supports OpenACC 2.6. As GCC mainline is in feature-freeze Stage 3, this feature will surely miss GCC 12, unfortunately. At the moment, the OpenACC work is mostly

Re: GCC and OpenACC

Dear Richard, Thanks a lot for the fast response. Here I send you a self contained example. I took it from openACC tutorial in [1]. I modified the code and added a dummy vector of size 1, lines 140-160 in the attached file (jsolvef_mikel.F90). The dummy vector (residual_v) is the array form

Re: GCC and OpenACC

On Tue, Jan 11, 2022 at 1:52 PM Mikel Mendizabal via Gcc wrote: > > Dear GCC developers, > > In the past year we started the offload of our software to GPUs. We decided > to go with OpenACC. The program we are trying to offload is Millepede2 (MP2), > a tracker alignment soft

GCC and OpenACC

Dear GCC developers, In the past year we started the offload of our software to GPUs. We decided to go with OpenACC. The program we are trying to offload is Millepede2 (MP2), a tracker alignment software used to align the CMS experiment tracker at the large hadron collider. We are using gcc

[Patch, committed] Update MAINTAINERS (was: OpenACC maintainer)

On 8/26/20 5:17 PM, Joseph Myers wrote: The SC has approved Tobias Burnus as an additional OpenACC maintainer. Tobias, please add yourself as OpenACC maintainer to the MAINTAINERS file. Thanks to the SC for the trust; I also have now updated that file. Tobias - Mentor

OpenACC maintainer

The SC has approved Tobias Burnus as an additional OpenACC maintainer. Tobias, please add yourself as OpenACC maintainer to the MAINTAINERS file. -- Joseph S. Myers jos...@codesourcery.com

Re: OpenACC with AMD Radeon GPU offloading

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

OpenACC with AMD Radeon GPU offloading

Hi! On 2020-04-07T00:12:41+0430, MAHDI LOTFI via Gcc wrote: > I am a researcher from Jam Petrochemical company I want to use OpenACC with > GCC compiler(FORTRAN language). Thanks for your interest. Please, use a proper Subject for your emails (see how I changed it), and include any re

Re: OpenACC

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 y

Re: OpenACC

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

Re: OpenACC

at 08:44, MAHDI LOTFI via Gcc wrote: > > > > Hello > > I am a researcher from Jam Petrochemical company I want to use OpenACC > with > > GCC compiler. I have a question about your compiler. > > Does your compiler support OpenACC in windows OS or not? > > &

Re: OpenACC

ical company I want to use OpenACC with > GCC compiler. I have a question about your compiler. > Does your compiler support OpenACC in windows OS or not? > > Thanks very much > -- > Mahdi Lotfi > Student at Sharif University of Technology

OpenACC

Hello I am a researcher from Jam Petrochemical company I want to use OpenACC with GCC compiler. I have a question about your compiler. Does your compiler support OpenACC in windows OS or not? Thanks very much -- Mahdi Lotfi Student at Sharif University of Technology

devel/omp/gcc-9 branch (was: [wwwdocs] Document existence of openacc-gcc-9-branch)

- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter --- Begin Message --- Hi! On 2019-06-04T23:05:53+0100, Julian Brown wrote: > I've pushed a new branch

OpenACC regression and development pace

-9]+\\]\\) map\\(alloc:cpo_f_p\\.data \\[pointer assign, bias: [^\\]]+\\]\\) finalize$" 1 Regarding what is currently going on with OpenACC: I do not claim to understand this area of the compiler, but it certainly seems that the current development is too hasty - too many patches flying around,

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 05, 2019 at 10:37:33PM +, Jonathan Wakely wrote: > On Thu, 5 Dec 2019 at 22:19, Segher Boessenkool wrote: > > Or you could write > > > > auto __c = (__builtin_memcmp(&*__first1, &*__first2, __len) <=> 0); > > if (__c) > > return __c; > > > > which is much easier to rea

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, 5 Dec 2019 at 22:19, Segher Boessenkool wrote: > Or you could write > > auto __c = (__builtin_memcmp(&*__first1, &*__first2, __len) <=> 0); > if (__c) > return __c; > > which is much easier to read, to my eyes anyway. And it is exactly the > same for the compiler. In this ca

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, 5 Dec 2019 at 22:19, Segher Boessenkool wrote: > > On Thu, Dec 05, 2019 at 08:56:35PM +, Jonathan Wakely wrote: > > On Thu, 5 Dec 2019 at 20:07, Segher Boessenkool > > wrote: > > > On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote: > > > > C++17 introduces a nice feature,

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 05, 2019 at 08:56:35PM +, Jonathan Wakely wrote: > On Thu, 5 Dec 2019 at 20:07, Segher Boessenkool > wrote: > > On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote: > > > C++17 introduces a nice feature, with rationale similar to declaring > > > variables in a for-loop

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 05, 2019 at 03:38:15PM -0500, Marek Polacek wrote: > On Thu, Dec 05, 2019 at 02:06:50PM -0600, Segher Boessenkool wrote: > > > When you're forced to uglify every variable with a leading __ you run > > > out of characters pretty damn quickly. > > > > If using this "nice feature" forces

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, 5 Dec 2019 at 20:07, Segher Boessenkool wrote: > > Hi! > > On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote: > > C++17 introduces a nice feature, with rationale similar to declaring > > variables in a for-loop init-statement: > > > > if (auto var = foo(); bar(var)) > > Simil

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 5, 2019 at 11:51 AM Michael Matz wrote: > Hello, > > (oh a flame bait :) ) > > On Thu, 5 Dec 2019, Thomas Schwinge wrote: > > > So, I formally propose that we lift this characters per line restriction > > from IBM punch card (80) to mainframe line printer (132). > > > > Tasks: > > > >

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 05, 2019 at 02:06:50PM -0600, Segher Boessenkool wrote: > Hi! > > On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote: > > C++17 introduces a nice feature, with rationale similar to declaring > > variables in a for-loop init-statement: > > > > if (auto var = foo(); bar(var

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 05, 2019 at 05:04:12PM +0100, Jakub Jelinek wrote: > On Thu, Dec 05, 2019 at 04:46:45PM +0100, Thomas Schwinge wrote: > > On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote: > > > [...] much more indented though, but you could > > > use a temporary, like: > > > tree nulla

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 05, 2019 at 04:44:21PM +, Michael Matz wrote: > (oh a flame bait :) ) I will blissfully ignore that warning. > On Thu, 5 Dec 2019, Thomas Schwinge wrote: > I object to cluttering code in excuse for using sensible function names or > temporaries that otherwise can help clearing up

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Hi! On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote: > C++17 introduces a nice feature, with rationale similar to declaring > variables in a for-loop init-statement: > > if (auto var = foo(); bar(var)) Similar to GNU C statement expressions, which are *also* only a good idea to u

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote: > On Thu, 5 Dec 2019 at 16:44, Michael Matz wrote: > > > > Hello, > > > > (oh a flame bait :) ) > > > > On Thu, 5 Dec 2019, Thomas Schwinge wrote: > > > > > So, I formally propose that we lift this characters per line restriction > >

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Dec 5 2019, Michael Matz wrote: (oh a flame bait :) ) Quite. I shall try not to make it too much worse, but there's another point that needs mentioning. I find long names hard to read, with either short or long lines, especially when combined with variants like negotiate_twisty_little_pas

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, 5 Dec 2019 at 16:44, Michael Matz wrote: > > Hello, > > (oh a flame bait :) ) > > On Thu, 5 Dec 2019, Thomas Schwinge wrote: > > > So, I formally propose that we lift this characters per line restriction > > from IBM punch card (80) to mainframe line printer (132). > > > > Tasks: > > > >

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Hello, (oh a flame bait :) ) On Thu, 5 Dec 2019, Thomas Schwinge wrote: > So, I formally propose that we lift this characters per line restriction > from IBM punch card (80) to mainframe line printer (132). > > Tasks: > > - Discussion. I object to cluttering code in excuse for using sensibl

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On 12/5/19 9:24 AM, Paul Koning wrote: > > >> On Dec 5, 2019, at 11:17 AM, Joseph Myers >> wrote: >> >> On Thu, 5 Dec 2019, Thomas Schwinge wrote: >> >>> In the relevant session at the GNU Tools Cauldron 2019, Michael >>> Meissner stated that even he is not using a 80 x 24 terminal >>> anymore

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

> On Dec 5, 2019, at 11:17 AM, Joseph Myers wrote: > > On Thu, 5 Dec 2019, Thomas Schwinge wrote: > >> In the relevant session at the GNU Tools Cauldron 2019, Michael Meissner >> stated that even he is not using a 80 x 24 terminal anymore, and that >> should tell us something. ;-) >> >> So,

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, 5 Dec 2019, Thomas Schwinge wrote: > In the relevant session at the GNU Tools Cauldron 2019, Michael Meissner > stated that even he is not using a 80 x 24 terminal anymore, and that > should tell us something. ;-) > > So, I formally propose that we lift this characters per line restricti

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On Thu, Dec 05, 2019 at 04:46:45PM +0100, Thomas Schwinge wrote: > Hi! > > ;-P Jakub, thanks for furnishing me a fit occasion here: > > On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote: > > [...] much more indented though, but you could > > use a temporary, like: > > tree nulla

[RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Hi! ;-P Jakub, thanks for furnishing me a fit occasion here: On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote: > [...] much more indented though, but you could > use a temporary, like: > tree nullarg = null_pointer_node; I object to cluttering the code by introducing tempora

Re: For libgomp OpenACC entry points, redefine the "device" argument to "flags"

Hi! On Wed, 19 Dec 2018 22:56:05 +0100, I wrote: > On Wed, 19 Dec 2018 15:18:12 +0100, Jakub Jelinek wrote: > > On Wed, Dec 19, 2018 at 03:03:42PM +0100, Jakub Jelinek wrote: > > > On Wed, Dec 19, 2018 at 02:59:54PM +0100, Thomas Schwinge wrote: > > > > Right. F

For libgomp OpenACC entry points, redefine the "device" argument to "flags"

Hi Jakub! On Wed, 19 Dec 2018 15:18:12 +0100, Jakub Jelinek wrote: > On Wed, Dec 19, 2018 at 03:03:42PM +0100, Jakub Jelinek wrote: > > On Wed, Dec 19, 2018 at 02:59:54PM +0100, Thomas Schwinge wrote: > > > Right. For OpenACC, there's no "device" clause

Re: For OpenACC libgomp entry points, redefine the "int device" argument to "unsigned int flags"

On Wed, Dec 19, 2018 at 03:03:42PM +0100, Jakub Jelinek wrote: > On Wed, Dec 19, 2018 at 02:59:54PM +0100, Thomas Schwinge wrote: > > Right. For OpenACC, there's no "device" clause, so we only ever passed > > in "GOMP_DEVICE_ICV" (default), or "GOMP_D

Re: For OpenACC libgomp entry points, redefine the "int device" argument to "unsigned int flags"

On Wed, Dec 19, 2018 at 02:59:54PM +0100, Thomas Schwinge wrote: > Right. For OpenACC, there's no "device" clause, so we only ever passed > in "GOMP_DEVICE_ICV" (default), or "GOMP_DEVICE_HOST_FALLBACK" ("if > (false)" clause). Therefore,

Re: For OpenACC libgomp entry points, redefine the "int device" argument to "unsigned int flags"

e "if_present" flag through the > > > "int device" argument of "GOACC_data_start" (making sure that old > > > executables continue to function as before). For OpenACC, that argument > > > is only ever set to "GOMP_DEVICE_ICV" or "GOMP_

Re: For OpenACC libgomp entry points, redefine the "int device" argument to "unsigned int flags" (was: OpenACC 2.6 "host_data" construct, "if_present" clause)

ment of "GOACC_data_start" (making sure that old > > executables continue to function as before). For OpenACC, that argument > > is only ever set to "GOMP_DEVICE_ICV" or "GOMP_DEVICE_HOST_FALLBACK" (for > > "if" clause evaluating to "false"), so

For OpenACC libgomp entry points, redefine the "int device" argument to "unsigned int flags" (was: OpenACC 2.6 "host_data" construct, "if_present" clause)

Hi! On Wed, 19 Dec 2018 00:24:00 +0100, I wrote: > OpenACC 2.6 adds a new clause to the "host_data" construct: > 2.8.3. "if_present clause". Gergő (in CC) is working on that. > > When an 'if_present' clause appears on the directive, the compiler

OpenACC 2.6 "host_data" construct, "if_present" clause

Hi Jakub! OpenACC 2.6 adds a new clause to the "host_data" construct: 2.8.3. "if_present clause". Gergő (in CC) is working on that. When an 'if_present' clause appears on the directive, the compiler will only change the address of any variable or array w

Re: Thomas Schwinge appointed OpenACC Maintainer

Hi! On Thu, 20 Sep 2018 10:11:36 -0400, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Thomas Schwinge as OpenACC Maintainer. Thanks for your trust, after all these years. I'm happy to accept, and will of course (continue to) w

Thomas Schwinge appointed OpenACC Maintainer

I am pleased to announce that the GCC Steering Committee has appointed Thomas Schwinge as OpenACC Maintainer. Please join me in congratulating Thomas on his new role. Thomas, please update your listing in the MAINTAINERS file. Happy hacking! David

Re: OpenACC maintainership

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

FW: OpenACC maintainership

Oops, forgot to copy the list. From: Moore, Catherine Sent: Monday, September 10, 2018 4:20 PM To: dje@gmail.com Cc: Schwinge, Thomas ; Philippidis, Cesar ; 'Jakub Jelinek' Subject: OpenACC maintainership Hi David, Following up various conversations that took place at Cauldro

[og8] New Git-only development branch: openacc-gcc-8-branch

Hi! There is a new Git-only development branch: openacc-gcc-8-branch, <https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/openacc-gcc-8-branch>, <https://github.com/gcc-mirror/gcc/tree/openacc-gcc-8-branch>. This branch is for collaborative development of OpenACC

Re: [og7] Git branch "openacc-gcc-7-branch"

t;GIMPLE Front End page for details. - gomp-4_0-branch - The original purpose of this branch has been to update - the https://gcc.gnu.org/wiki/openmp";>OpenMP support to version - 4.0, including development - of https://gcc.gnu.org/wiki/Offloading";>offloading support in

Re: [og7] Git branch "openacc-gcc-7-branch"

On Tue, 18 Jul 2017, Thomas Schwinge wrote: > This being a Git-only branch, should it nevertheless be listed on > , in the "Active Development Branches" > section, replacing "gomp-4_0-branch" there? I would say so (with an according note). Thanks for thinking of that

[og7] Git branch "openacc-gcc-7-branch"

Hi! There is a new Git-only branch: "openacc-gcc-7-branch", <https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/openacc-gcc-7-branch>, <https://github.com/gcc-mirror/gcc/tree/openacc-gcc-7-branch>. This is a non-subdirectory branch for collaborative development

[PR tree-optimization/78024] Clear basic block flags before using BB_VISITED for OpenACC loops processing

Hi! On Wed, 19 Oct 2016 12:07:13 +0200, Richard Biener wrote: > On Tue, Oct 18, 2016 at 9:52 PM, Thomas Schwinge > wrote: > > can I at > > least commit the OpenACC loops processing fix? Here is the latest > > version, simplified after your r241296 IRA vs. BB_VIS

Re: Clear basic block flags before using BB_VISITED for OpenACC loops processing

te: >> > >> >> On Fri, Oct 14, 2016 at 1:00 PM, Nathan Sidwell >> > >> >> wrote: >> > >> >> > On 10/14/16 05:28, Richard Biener wrote: >> > >> >> > >> > >> >> >> The BB_VISITED flag

Re: Clear basic block flags before using BB_VISITED for OpenACC loops processing

rote: > > >> >> > On 10/14/16 05:28, Richard Biener wrote: > > >> >> > > > >> >> >> The BB_VISITED flag has indetermined state at the beginning of a > > >> >> >> pass. > > >> >> >> You

Re: Clear basic block flags before using BB_VISITED for OpenACC loops processing

;> The BB_VISITED flag has indetermined state at the beginning of a > >> >> >> pass. > >> >> >> You have to ensure it is cleared yourself. > >> >> > > >> >> > > >> >> > In that case the openacc (

Re: Clear basic block flags before using BB_VISITED for OpenACC loops processing

wrote: >> >> On Fri, Oct 14, 2016 at 1:00 PM, Nathan Sidwell wrote: >> >> > On 10/14/16 05:28, Richard Biener wrote: >> >> > >> >> >> The BB_VISITED flag has indetermined state at the beginning of a pass. >> >> >> You hav

Re: Clear basic block flags before using BB_VISITED for OpenACC loops processing

> On 10/14/16 05:28, Richard Biener wrote: > >> > > >> >> The BB_VISITED flag has indetermined state at the beginning of a pass. > >> >> You have to ensure it is cleared yourself. > >> > > >> > > >> > In that ca

Re: Clear basic block flags before using BB_VISITED for OpenACC loops processing (was: basic_block flags, BB_VISITED)

he BB_VISITED flag has indetermined state at the beginning of a pass. >> >> You have to ensure it is cleared yourself. >> > >> > >> > In that case the openacc (&nvptx?) passes should be modified to clear the >> > flags at their start, rather than at

Clear basic block flags before using BB_VISITED for OpenACC loops processing (was: basic_block flags, BB_VISITED)

to ensure it is cleared yourself. > > > > > > In that case the openacc (&nvptx?) passes should be modified to clear the > > flags at their start, rather than at their end. The gcc/config/nvptx/nvptx.c handling seems fine -- it explicitly clears BB_VISITED for all basic b

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

Jeff Law writes: >> We don't need to change the final approval step being from a >> maintainer to be able to spread the workload. > Amen. There's a few folks doing this right now outside their areas of > official maintainership and those comments are always very helpful to > me. > > And note tha

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 08/05/2016 10:27 AM, Ian Lance Taylor wrote: I believe that Diego tried setting up an alternative patch review system using Reitveld, but it did not catch on. And there were some before that :-) For Go development I have been using Gerrit, an instance hosted at Google (https://go-review.go

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

I'm not going to reply to any specific points, but I do want to comment that I've come to believe that e-mail based patch review is a problem. Unfortunately, I do not foresee the GCC maintainers moving away from it. I believe that Diego tried setting up an alternative patch review system using Re

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

that is, most of the commits are done by smaller fraction of the total. If that smaller percentage is also responsible for doing most of the review work for the rest... * Numbers for other years might shed more light. 2010, 2013 and 2015 might have been especial in one sense or another. &g

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 08/04/2016 04:49 PM, Thomas Schwinge wrote: Global Reviewers are welcome to review OpenACC/OpenMP/offloading patches. But that doesn't help if that's then not happening in reality. (With the exception of Bernd, who then did review such patches for a while, but also seems to have st

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 08/05/2016 06:10 AM, Jonathan Wakely wrote: On 4 August 2016 at 21:12, Manuel López-Ibáñez wrote: d) Delegate hierarchically. Module owners should seek and delegate to people with svn-write powers and ask for reviews in exchange of reviews. Advantages: No loss in quality, distribute work, cr

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

ttps://gcc.gnu.org/ml/gcc-patches/2016-08/msg00093.html > > They will never bother to send an email like this and just silently > go away. People do give up and move somewhere else based on this > problem only. (And nowadays, this decision is quite easy to make or > sell to one's b

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 4 August 2016 at 21:12, Manuel López-Ibáñez wrote: > d) Delegate hierarchically. Module owners should seek and delegate to people > with svn-write powers and ask for reviews in exchange of reviews. > > Advantages: No loss in quality, distribute work, creates an economy of > reviews. > > Disadvan

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 5 August 2016 at 12:16, Janne Blomqvist wrote: > - a "2-week rule"; if a patch by a reviewer goes unreviewed for 2 > weeks, the reviewer can commit it without review. A bit like your > option a). > > > The 2-week rule, in particular, came about due to frustration with > lack of reviews. Two we

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On Thu, Aug 4, 2016 at 11:12 PM, Manuel López-Ibáñez wrote: > At least half of the global reviewers in MAINTAINERS never review any > patches. Most of them are not active any more and presumably do not read GCC > emails. > > I'm not sure how to address this problem, but there is definitely a probl

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 4 August 2016 at 22:01, DJ Delorie wrote: > > Manuel Lpez-Ibñez writes: >> I don't see how that helps. Neither my message nor Thomas's is a >> criticism of people. The question is how to get more people to help >> and how to improve the situation. For sure, everybody is doing the >> best that

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

Manuel Lpez-Ibñez writes: > Another question is how to help existing maintainers such that they > are more motivated to review patches. Is it a lack of time? lack of > Interest in the project? do patches simply fall through the cracks? is > it a dead-lock of people waiting for each other to comme

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

Manuel Lpez-Ibñez writes: > I don't see how that helps. Neither my message nor Thomas's is a > criticism of people. The question is how to get more people to help > and how to improve the situation. For sure, everybody is doing the > best that they can with the time that they have. You complaine

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 4 August 2016 at 21:34, Manuel López-Ibáñez wrote: > On 4 August 2016 at 21:27, DJ Delorie wrote: >> Manuel Lpez-Ibñez writes: >> >>> none? for libiberty, no regular maintainer for build machinery, >> >> Perhaps this is a sign that I should step down as maintainers for those? > > I don't see

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 4 August 2016 at 21:27, DJ Delorie wrote: > Manuel Lpez-Ibñez writes: > >> none? for libiberty, no regular maintainer for build machinery, > > Perhaps this is a sign that I should step down as maintainers for those? I don't see how that helps. Neither my message nor Thomas's is a criticism of

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

Manuel Lpez-Ibñez writes: > none? for libiberty, no regular maintainer for build machinery, Perhaps this is a sign that I should step down as maintainers for those?

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

le do give up and move somewhere else based on this problem only. (And nowadays, this decision is quite easy to make or sell to one's boss) OpenACC/OpenMP/offloading patches. I'm certainly not going in any way to disapprove Jakub's help, skills and experience, but I'm mo

[GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to test

erally, I think it's a bad situation that apparently Jakub (who I acknowledge is always very busy with all kinds of tasks) has de facto become the single reviewer of OpenACC/OpenMP/offloading patches. I'm certainly not going in any way to disapprove Jakub's help, skills and experience,

Re: GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)

On Jul 25, 2016, at 9:37 AM, Joseph Myers wrote: > > On Fri, 15 Jul 2016, Thomas Schwinge wrote: > >>> No, we want to have as little churn as possible in existing tests, the >>> general policy is to add new tests (not just for OpenACC/OpenMP, but for >>> al

Re: GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)

On Fri, 15 Jul 2016, Thomas Schwinge wrote: > > No, we want to have as little churn as possible in existing tests, the > > general policy is to add new tests (not just for OpenACC/OpenMP, but for > > all functionality). > > Hmm, that's something I had not been aw

GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)

roblem I have with this specific and similar other test cases is, that when coming back to such a test case in a few weeks' time, it is not obvious at all what this is testing, whereas if this were inside a file that generally/already tests all kinds of "!$acc parallel loop" vari

How to rewrite call targets (OpenACC bind clause)

Hi! I have tried a few things, and got things somewhat working, but I'm not satisfied with my results so far, so I'd like to ask for help. OpenACC specifics are not relevant to my question, which I'm thus formulating in a very generic way. (But find an illustrative example at

Re: OpenACC (gomp-4_0-branch) patch review (was: Merge from gomp-4_1-branch to trunk)

1. I'm sorry for the delays in patch review, and will try to arrange an hour or two daily for OpenACC/OpenMP/HSA patch review for the remainder of stage1 (and still work on the missing OpenMP 4.5 features or fixes during the rest of the days). The PTX changes Nathan can review himself, or

Re: OpenACC (gomp-4_0-branch) patch review

if they're then not handled quickly), would you maybe prefer to do a "whole-branch" review? It might be good to start with a relatively high-level overview of the current approach, also documenting which parts of OpenACC the changes implement and which ones they don't. would it

OpenACC (gomp-4_0-branch) patch review (was: Merge from gomp-4_1-branch to trunk)

e something to do with changes that affect handling of the OpenACC async clause. I guess you're not set up for nvptx offloading testing; I'll try to figure it out. More generally, "as you've committed first", the burden of merging your gomp-4_1-branch merge (trunk r22877

Re: [gomp4] Basic -misa support for nvptx (was: How to use old GPU (Fermi) in gcc with OpenACC?)

ng) when I compile my target code with OpenACC pragma? (in other words... How to change the target "sm"? Can I change target "sm"?) -- View this message in context: http://gcc.1065356.n5.nabble.com/How-to-use-old-GPU-Fermi-in-gcc-with-OpenACC-tp1147463p1160093.html Sent from the

Re: [gomp4] Basic -misa support for nvptx (was: How to use old GPU (Fermi) in gcc with OpenACC?)

On Wed, 13 May 2015, Thomas Schwinge wrote: > * config/nvptx/nvptx.opt (ptx_isa, sm_30, sm_35): New enum and its > values. > (misa=): New option. New options do of course need documenting in invoke.texi. -- Joseph S. Myers jos...@codesourcery.com

[gomp4] Basic -misa support for nvptx (was: How to use old GPU (Fermi) in gcc with OpenACC?)

Hi! On Sat, 9 May 2015 10:26:22 -0700, Satoshi_OHSHIMA wrote: > I'm trying to use and evaluate gcc with OpenACC on some NVIDIA GPUs. > I succeeded to build gcc with OpenACC by using > http://scelementary.com/2015/04/25/openacc-in-gcc.html as a reference. Heh, their build instruct

How to use old GPU (Fermi) in gcc with OpenACC?

Hi, I'm trying to use and evaluate gcc with OpenACC on some NVIDIA GPUs. I succeeded to build gcc with OpenACC by using http://scelementary.com/2015/04/25/openacc-in-gcc.html as a reference. Then, I succeeded to use Kepler GPU. However, I tried to use it on old GPUs (Fermi), and I fail

Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4 - an exception for OpenACC 2.0, nvptx and KNL offloading support?

Oh sorry. I just checked out the svn again, and see it already merged. Well done! On Tue, Jan 20, 2015 at 11:59 PM, Mark Farnell wrote: > I know that we are already in stage 4, but features such as OpenACC > 2.0, nvptx and KNL (xeon phi) offloading support are so important >

GCC 5 Status Report (2015-01-19), Trunk in Stage 4 - an exception for OpenACC 2.0, nvptx and KNL offloading support?

I know that we are already in stage 4, but features such as OpenACC 2.0, nvptx and KNL (xeon phi) offloading support are so important for GCC, and if they have to be deferred to GCC 6.0, then it would be a great loss to GCC, as OpenACC 2.0 makes heterogeneous manycore programming so much

Re: will openacc 2.0 be merged into trunk?

It is already January 16, I have just seen the notice that OpenMP offloading is already merged into the trunk. However, from SVN, the openacc stuff is still not yet merged. Will it be able to be merged today? Otherwise openacc will not make it to GCC 5.0 Are there any issues that prevents

Re: will openacc 2.0 be merged into trunk?

p-4.0_branch need to approach the gcc release team *immediately* and explain why openacc is essential for gcc 5, and why openacc is ready to merge into the trunk. We need timely intervention from the gcc release team to ensure openacc makes it to gcc 5 On Fri, Jan 9, 2015 at 10:09 PM, Tobias Burnus wrote:

will openacc 2.0 be merged into trunk?

Currently, OpenACC 2.0 is in gomp-4_0-branch, but this email: https://gcc.gnu.org/ml/gcc/2015-01/msg00032.html says that gcc 5.0 will enter stage 4 on Friday 16th January, and from that point onward, only bug fixing patches will be accepted. So will gomp-4_0-branch be able to be merged into the

will openacc be merged into the trunk soon?

>From the svn log, I saw tschwinge did a lot of bug fixing on the gomp-4_0-branch, and recently merged trunk to gomp-4_0-branch without mention of any outstanding conflicts. Does this signify an imminent merge of the gomp-4_0-branch to the trunk? If so, I am really excited to try out open

Re: trying out openacc 2.0

pilers (nvcc etc.) > as that task is done by GCC. > > >>> Also, are other GPUs such as the AMD ATI and the built-in GPUs such as >>> the Intel GPU and AMD fusion supported? > > There was some work underway to support OpenACC with OpenCL as output, > which is

Re: trying out openacc 2.0

g the PTX files. The actual 'assembler' is in the CUDA runtime library. However, GCC (plus the few aux tools) replaces the compilers (nvcc etc.) as that task is done by GCC. >> Also, are other GPUs such as the AMD ATI and the built-in GPUs such as >> the Intel GPU and AMD f

Re: trying out openacc 2.0

the nvptx-tools project mentioned in Tobia's page aiming at replacing the CUDA toolchain? Thanks! Mark On Wed, Dec 17, 2014 at 9:05 AM, Jakub Jelinek wrote: > On Wed, Dec 17, 2014 at 08:54:06AM +1300, Mark Farnell wrote: >> That's good news. Does it mean that if I want

  1   2   >