From: Cesar Philippidis
Eventually, we want the nvptx BE to use a common shared memory buffer
for both worker and vector state propagation (albeit using different
partitions of shared memory for each logical thread). This patch
renames the worker_bcast variables into a more generic oacc_bcast
From: Cesar Philippidis
This patch series contains various cleanups and structural
reorganizations to the NVPTX BE in preparation for the forthcoming
variable length vector length enhancements. Tom, in order to make
these changes easier for you to review, I broke these patches into
logical
From: Cesar Philippidis
Besides for updating the macros for the NVPTX OpenACC dims, this patch
also renames PTX_GANG_DEFAULT to PTX_DEFAULT_RUNTIME_DIM. I had
originally included the PTX_GANG_DEFAULT hunk in an earlier libgomp
patch, but going forward it makes sense to isolate the nvptx and
From: Cesar Philippidis
This patch introduces a new struct offload_attrs, which contains the
details regarding the offload function launch geometry. In addition to
its current usage to neuter worker and vector threads, it will
eventually by used to validate the compile-time launch geometry
From: Cesar Philippidis
This patch renames various state propagation functions into somewhat
that reflects their usage in generic worker and vector contexts. E.g.,
whereas before nvptx_wpropagate used to be used exclusively for worker
state propagation, it will eventually be used for any state
From: Tom de Vries
This patch only adjusts white space.
2018-XX-YY Cesar Philippidis
gcc/
* config/nvptx/nvptx.c (nvptx_single): Fix whitespace.
(nvptx_neuter_pars): Likewise.
(cherry picked from openacc-gcc-7-branch commit
10f697dfcdaa77b842de6e9a62c68b33a49d3c16
From: Tom de Vries
This patch introduces an axis_dim member to the machine_function
struct. The launch geometry will be queried frequently enough so that
its justified to store that information with each cfun.
2018-XX-YY Tom de Vries
Cesar Philippidis
gcc
From: Cesar Philippidis
This patch teaches nvptx_single to always use barrier '0' for CTA
synchronization. This started off as a cosmetic change, but later on
each large vector (i.e. one that larger than a PTX warp) will need to
use its own unique thread barrier to avoid thread
Cesar Philippidis
gcc/
* config/nvptx/nvptx.md (nvptx_barsync): Add and handle operand.
* config/nvptx/nvptx.c (nvptx_cta_sync): Change arguments to take in a
lock and thread count. Update call to gen_nvptx_barsync.
(nvptx_single, nvptx_process_pars): Update
From: Tom de Vries
This patch replaces the confusing, in-lined min, max and rounding code
sprinkled throughout the nvptx BE with calls to MIN, MAX, and ROUND_UP
macros.
2018-XX-YY Tom de Vries
Cesar Philippidis
gcc/
* config/nvptx/nvptx.c
From: Cesar Philippidis
Chung-Lin had originally defined TARGET_SET_CURRENT_FUNCTION as part
of his gang-local variable patch. But I intend to introduce those
changes at a later time. Eventually the state propagation code will
utilize nvptx_set_current_function to reset the reduction buffer
Tom de Vries
Cesar Philippidis
gcc/
* config/nvptx/nvptx.c (oacc_bcast_partition): Declare.
(nvptx_option_override): Init oacc_bcast_partition.
(nvptx_init_oacc_workers): New function.
(nvptx_declare_function_name): Call
On 07/02/2018 07:14 AM, Tom de Vries wrote:
> On 06/21/2018 03:58 PM, Cesar Philippidis wrote:
>> On 06/20/2018 03:15 PM, Tom de Vries wrote:
>>> On 06/20/2018 11:59 PM, Cesar Philippidis wrote:
>>>> Now it follows the formula contained in
>>>> the &quo
On 07/02/2018 07:14 AM, Tom de Vries wrote:
> On 06/21/2018 03:58 PM, Cesar Philippidis wrote:
>> On 06/20/2018 03:15 PM, Tom de Vries wrote:
>>> On 06/20/2018 11:59 PM, Cesar Philippidis wrote:
>>>> Now it follows the formula contained in
>>>> the &quo
gt;
I bootstrapped and regtested on x86_64/nvptx. Is it OK for trunk?
Thanks,
Cesar
>From 3a58144cfaca8f6e3a889346e736e68a9ed17e6a Mon Sep 17 00:00:00 2001
From: Cesar Philippidis
Date: Thu, 18 Aug 2016 01:12:15 +
Subject: [PATCH 1/5] Fix PR70828s "broken array-type subarrays inside acc da
rapped and regtested on x86_64/nvptx. Is it OK for trunk?
Thanks,
Cesar
>From b0e7fb09bf3a3f853e77c2712b6f85ad21472e72 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Tue, 5 Sep 2017 22:09:34 +0800
Subject: [PATCH 2/5] [OpenACC] Add support for making maps 'private' inside
offload
apped and regtested on x86_64/nvptx. Is it OK for trunk?
Thanks,
Cesar
>From a4753e2b40cf3d707aabd7c9d5bad7d8f9be8b6f Mon Sep 17 00:00:00 2001
From: Cesar Philippidis
Date: Fri, 26 Jan 2018 08:30:13 -0800
Subject: [PATCH 3/5] Privatize independent OpenACC reductions
2018-XX-YY Cesar Phi
uction variable as firstprivate in OpenACC parallel regions,
if the are in an inner loop. This matches the behavior of reductions in
OpenACC 2.6.
Is this patch OK for trunk? I bootstrapped and regtested on x86_64/nvptx.
Thanks,
Cesar
>From 035be51a795ad8bed5342ba181220bf3102bcd6d Mon Sep 17
/nvptx. Is it OK for trunk?
Thanks,
Cesar
>From fb743d8a45193c177cb0082400d140949e8c1e6d Mon Sep 17 00:00:00 2001
From: Cesar Philippidis
Date: Wed, 24 Aug 2016 00:02:50 +
Subject: [PATCH 5/5] [libgomp, OpenACC] Adjust offsets for present data
clauses
2018-XX-YY Cesar Philippidis
nvptx offloading.
Thanks,
Cesar
2018-XX-YY Cesar Philippidis
gcc/fortran/
* trans-openmp.c (gfc_trans_oacc_combined_directive): Set the
location of combined acc loops.
(cherry picked from gomp-4_0-branch r245653)
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-ope
in this series are independent from one
another. Patches 1 and 2 fix diagnostics bugs involving incorrect line
numbers. Patch 3 is responsible for generating the actual diagnostics.
Cesar
able to resolve a couple of
long standing diagnostics discrepancies between the c/c++ FEs in the
test suite.
Is this patch OK for trunk? I bootstrapped and regtested using x86_64
with nvptx offloading.
Thanks,
Cesar
2018-XX-YY Cesar Philippidis
gcc/cp/
* par
distinguish which parallelism was specified by the user and which was
assigned by the compiler. But that can be added in a follow up patch.
Is this patch OK for trunk? I bootstrapped and regtested it for x86_64
with nvptx offloading.
Thanks,
Cesar
2018-XX-YY Cesar Philippidis
gcc
On 07/25/2018 08:32 AM, Marek Polacek wrote:
> On Wed, Jul 25, 2018 at 08:29:17AM -0700, Cesar Philippidis wrote:
>> The fortran FE incorrectly records the line locations of combined acc
>> loop directives when it lowers the construct to gimple. Usually this
>> isn't a p
On 07/24/2018 01:47 PM, ce...@codesourcery.com wrote:
> From: Cesar Philippidis
>
> This patch series contains various cleanups and structural
> reorganizations to the NVPTX BE in preparation for the forthcoming
> variable length vector length enhancements. Tom, in order to make
On 07/26/2018 01:33 AM, Richard Biener wrote:
> On Wed, Jul 25, 2018 at 5:30 PM Cesar Philippidis
> wrote:
>>
>> This patch teaches GCC to inform the user how it assigned parallelism
>> to each OpenACC loop at compile time using the -fopt-info-note-omp
>> fla
Hi Tom,
I see that you're reviewing the libgomp changes. Please disregard the
following hunk:
On 07/11/2018 12:13 PM, Cesar Philippidis wrote:
> @@ -1199,12 +1202,59 @@ nvptx_exec (void (*fn), size_t mapnum, void
> **hostaddrs, void **devaddrs,
>
be
your email address, however, it really wants it to be in of the form
Full Name
This is not a huge deal because the email went through, but it was
something that wasn't immediately obvious to me.
Cesar
ng per-device default dimensions.
Neat, thanks!
I wonder if it's worthwhile to optimize the case where a system has more
than one identical GPU.
Cesar
existing defaults. Maybe the og8 thread
occupancy would make a better default for older versions of CUDA, but
that's a patch for another day.
Is this patch OK for trunk? I bootstrapped and regression tested it
using x86_64 with nvptx offloading.
Thanks,
Cesar
[nvptx] Use CUDA driver API to se
This is an old patch which removes the struct map from the nvptx plugin.
I believe at one point this was supposed to be used to manage async data
mappings, but in practice that never worked out.
Is this OK for trunk? I bootstrapped and regtested on x86_64 with nvptx
offloading.
Thanks,
Cesar
s this patch OK for trunk? I bootstrapped and regression tested it for
x86_64 with nvptx offloading.
Thanks,
Cesar
[PATCH] [nvptx] Remove use of CUDA unified memory in libgomp
2018-XX-YY Cesar Philippidis
libgomp/
* plugin/plugin-nvptx.c (struct cuda_map): New.
(struct ptx_stream): Replac
bootstrapped and regtested for x86_64 with nvptx
offloading.
Thanks,
Cesar
[PATCH] [libgomp] Truncate config/nvptx/oacc-parallel.c
2018-XX-YY Cesar Philippidis
Thomas Schwinge
libgomp/
* config/nvptx/oacc-parallel.c: Truncate.
(cherry picked from gomp-4_0-branch r228836)
---
libgomp
I've committed this patch to og8 which backports the first of Tom's
goacc_parlevel patches from mainline. I'll post of a followup patch
which contains various bug fixes. I believe that this patch was
originally introduced in PR82428, or at least it resolves that PR.
27;ll need to fix PR86757 before we push the gangprivate
changes upstream.
Julian, I'm not sure if the GCN port supports gangprivate memory. If it
does, you might be hit by this failure at -O0. But those tests have
already been xfailed, so you should be OK.
Cesar
[og8] More goacc_parlevel enh
and no regressions showed up.
Thanks,
Cesar
2013-10-10 Cesar Philippidis
gcc/
* regs.h (REG_N_GROW): New function.
* combine.c (combine_split_insns): Call REG_N_GROW when
new registers are created.
Index: gcc/regs.h
but instead the df stuff.
I was thinking about converting that array to a vec. But I don't want to
touch more code than I have to right now. Is this OK as a stopgap?
Thanks for the review!
Cesar
2013-10-11 Cesar Philippidis
gcc/
* regs.h (REG_N_GROW): New function.
On 10/15/13 12:16 PM, Jeff Law wrote:
> On 10/10/13 10:25, Jakub Jelinek wrote:
>> On Thu, Oct 10, 2013 at 07:26:43AM -0700, Cesar Philippidis wrote:
>>> This patch addresses an ICE when building qemu for a Mips target in
>>> Yocto. Both gcc-trunk, gcc-4.8 and all of
On 6/20/13 9:49 AM, Mike Stump wrote:
> On May 30, 2013, at 12:59 PM, Cesar Philippidis
> wrote:
>> Here is a patch from our backlog at Mentor Graphics that addresses a
>> libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following
>> error with dejagnu
ot;-g -O2" at minimum when no other optimization flags
are specified. The testsuite used to set those flags prior to Benjamin's
patch to remove duplicate cxxflags here
<http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01572.html>.
Is this OK for trunk? If so, please apply.
Thanks,
Cesar
20
On 01/20/2016 07:46 PM, Cesar Philippidis wrote:
> I've applied this patch to gomp-4_0-branch which fixes of problems
> involving reference type variables in openacc data clauses. The first
> problem was, the c++ front end was incorrectly handling reference types
> in general in
in trunk, but the c++ changes
don't apply cleanly. I'll need to work on that later.
Cesar
u add more
test coverage or tell me what should be included?
Is this patch ok for trunk?
Cesar
2016-02-01 Cesar Philippidis
gcc/c/
* c-typeck.c (c_finish_omp_clauses): Report OMP_CLAUSE_MAP errors
as data clause errors for OpenACC.
gcc/cp/
* cp-tree.h (finish_omp_clauses): Update
On 02/01/2016 09:57 AM, Cesar Philippidis wrote:
> This patch fixes a couple of bugs preventing c++ reference-typed
> variables from working in openacc data clauses. These fixes include:
>
> * Teach the gimplifier to filter out pointer data mappings for
>OACC_DATA,
. Without those separate pointers, I'd get SSA
validation errors because those pointers get deferenced multiple times.
I didn't investigate that problem further.
Is this patch ok for trunk?
Cesar
2016-02-09 Cesar Philippidis
gcc/
* omp-low.c (is_oacc_parallel
ue;
>> +
>> + return false;
>> +}
>> +
Thanks for catching that. Those are artifacts from when this code used
to be located exclusively in scan_sharing_clauses. I've updated the
patch with those changes.
Cesar
2016-02-09 Cesar Philippidis
gcc/
On 02/09/2016 07:00 AM, Cesar Philippidis wrote:
> On 02/01/2016 09:57 AM, Cesar Philippidis wrote:
>
>> > This patch fixes a couple of bugs preventing c++ reference-typed
>> > variables from working in openacc data clauses. These fixes include:
>> >
>>
end should be able to broadcast the origin u32 register directly.
Is there a better way to resolve this issue, or is this patch OK for
trunk as-is?
Cesar
2016-02-22 Cesar Philippidis
gcc/
* config/nvptx/nvptx.c (nvptx_gen_shuffle): Add support for QImode
and HImode register.
libgomp/
*
Ping. This patch still needs a review.
Cesar
On 02/09/2016 08:17 AM, Cesar Philippidis wrote:
> On 02/09/2016 07:33 AM, Nathan Sidwell wrote:
>> While I've not looked at the rest of the patch, this bit stood out:
>>
>>> +static bool
>>> +is_oacc_parallel
Ping.
Cesar
On 02/09/2016 09:05 AM, Cesar Philippidis wrote:
> On 02/09/2016 07:00 AM, Cesar Philippidis wrote:
>> On 02/01/2016 09:57 AM, Cesar Philippidis wrote:
>>
>>>> This patch fixes a couple of bugs preventing c++ reference-typed
>>>> variables from
On 10/16/13, 11:03 AM, Jeff Law wrote:
> On 10/16/13 09:34, Cesar Philippidis wrote:
>> On 10/15/13 12:16 PM, Jeff Law wrote:
>>> On 10/10/13 10:25, Jakub Jelinek wrote:
>>>> On Thu, Oct 10, 2013 at 07:26:43AM -0700, Cesar Philippidis wrote:
>>>>> This
On 07/14/2015 02:20 PM, Ilmir Usmanov wrote:
> Ping
Sorry, I thought I had already approved this. It's fine for gomp-4_0-branch.
Cesar
> On 07.07.2015 14:27, Ilmir Usmanov wrote:
>> Ping
>>
>> 30.06.2015, 03:43, "Ilmir Usmanov" :
>>> Hi Cesar!
&g
e welcome. Is this
reduction scheme too nvptx-specific?
I'll post the test cases in a follow up patch because the patch would be
too big for the mailing list otherwise.
Thanks,
Cesar
2015-07-17 Cesar Philippidis
gcc/
* config/nvptx/nvptx.c (nvptx_generate_vector_shuffle): New fun
too confusing too debug. The fortran tests are a bit
of a lost clause, unless someone knows how to use the preprocessor with
!$acc loops.
Cesar
2015-07-17 Cesar Philippidis
libgomp/
* testsuite/libgomp.oacc-c-c++-common/reduction.h: New file.
* testsuite/libgomp.oacc-c-c++-common/reduction-1
Tom noticed that one of my firstprivate test cases in libgomp had an omp
pragma. That pragma shouldn't be there. I probably forgot to remove that
pragma when I integrated that test into the libgomp test suite. This
patch corrects that test.
I applied this patch to gomp-4_0-branch.
Cesar
20
27;m expanding those calls using target machine hooks. This
pass will run after lto on the target compiler.
Thanks,
Cesar
2015-07-21 Cesar Philippidis
gcc/
* omp-low.c (execute_oacc_transform): New function.
(class pass_oacc_transform): New function.
(make_pass_oacc_transform): New function
nd
MEM_REFs. I suspect that I may be missing some, but these are the only
ones that were triggered gcc_unreachable during testing.
As Tom mentioned in PR66714, this bug is present on trunk, specifically
in code using omp targets. Is this patch OK for trunk? I bootstrapped
and tested on x86_64-li
On 07/23/2015 08:32 AM, Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote:
>> The attached patch does just that; it teaches
>> replace_block_vars_by_duplicates to replace the decls inside the
>> value-exprs with a duplicate too. It'
On 07/23/2015 03:11 PM, Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 03:01:25PM -0700, Cesar Philippidis wrote:
>> On 07/23/2015 08:32 AM, Jakub Jelinek wrote:
>>> On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote:
>>>> The attached pa
ves
having two compilers present. I wonder if it's ok to have libgomp check
for compiler expected compiler errors? However, that's more of a
gcc/testsuite type of check.
I don't think trunk has much support for acc routines just yet, so I
applied this patch to gomp-4_0-branch for
On 07/24/2015 08:21 AM, Ilya Verbin wrote:
> On Fri, Jul 24, 2015 at 08:05:00 -0700, Cesar Philippidis wrote:
>> The second point is interesting. Offloaded functions require the "omp
>> target" attribute or that function won't reach the lto compiler. That's
On 07/28/2015 02:21 AM, Thomas Schwinge wrote:
> Cesar, please address the following compiler diagnostig:
>
>> 2015-07-21 Cesar Philippidis
>>
>> gcc/
>> * omp-low.c (execute_oacc_transform): New function.
>> (clas
On 08/06/2015 01:41 AM, Nathan Sidwell wrote:
> I've committed this to fix the spinlock problem Cesar fell over. While
> there I added more checking on the worker dimension.
I hit a couple of more bugs with the spinlocks. First, the address space
argument to membar wasn't being
oacc_fn_attrib, it appears that const values are also
considered dynamic. See the attached test case more more info. Is that
the expected behavior? If not, I could take a look at this after I
finished my reduction patch.
Cesar
#include
const int vl = 32;
int
main ()
{
unsigned int red = 0;
#pragm
wred.c: In function ‘main._omp_fn.0’:
wred.c:9:9: error: unrecognizable insn:
#pragma acc parallel loop vector_length (32) num_workers (32) worker
reduction (+:red) copy (red)
^
(insn 28 27 29 2 (set (reg:DI 59)
(plus:DI (symbol_ref:DI ("__worker_red"))
(const
On 09/18/2015 01:39 AM, Thomas Schwinge wrote:
> On Tue, 1 Sep 2015 18:29:55 +0200, Tom de Vries
> wrote:
>> On 27/08/15 03:37, Cesar Philippidis wrote:
>>> - ctx->ganglocal_size_host = align_and_expand (&gl_host, host_size, align);
>>
>> I
, /* todo_flags_start */
> + TODO_update_ssa | TODO_cleanup_cfg, /* todo_flags_finish */
> +};
Cesar
2015-09-21 Cesar Philippidis
gcc/
* doc/invoke.texi: Document -fdump-tree-oacc_xforms.
* omp-low.c (pass_data_oacc_transform): Rename the tree dump for
oacc_transform as oacc_xforms.
diff --git a/gcc/
as-is because I'm not that
familiar with how non-OpenMP target regions get lowered.
Is this patch OK for trunk?
Thanks,
Cesar
2015-09-22 Cesar Philippidis
gcc/
* fortran/trans-openmp.c (gfc_omp_finish_clause): Don't cast ptr
into a character pointer.
(gfc_trans_omp_clauses_1)
pping. This patch teaches the gimplifier to do that. This
corrects a bug where a dummy array gets implicitly transferred as
firstprivate instead of pcopy.
I've applied patch has been committed to gomp-4_0-branch.
Cesar
2015-09-22 Cesar Philippidis
gcc/
* gimplify.c (oacc_default_clause
efore, the only problematic case is when the the
optional expression is just a decl, e.g. gang(static:foo).
I've applied this patch to gomp-4_0-branch.
Cesar
On 09/23/2015 10:42 AM, Cesar Philippidis wrote:
> I've applied this patch to gomp-4_0-branch.
This patch, that is.
Cesar
2015-09-23 Cesar Philippidis
gcc/
* omp-low.c (lower_omp_for): Remap any variables present in
OMP_CLAUSE_GANG, OMP_CLAUSE_WORKER, OMP_CLAUSE_VE
On 09/23/2015 11:26 AM, Thomas Schwinge wrote:
> On Wed, 23 Sep 2015 10:57:40 -0700, Cesar Philippidis
> wrote:
>> On 09/23/2015 10:42 AM, Cesar Philippidis wrote:
>> | Gang, worker, vector and collapse all contain optional arguments which
>> | may be used during lo
outer))
ref_to_res = build_receiver_ref (orig, false, outer);
That's going to ICE inside a routine.
> 2) Create a local private instance for all cases of reference var
> reductions, not just those in vector & worker loops
Good. I was about to make a similar change to fix a gang reduction bug.
Cesar
On 09/25/2015 03:57 AM, Nathan Sidwell wrote:
> On 09/24/15 16:32, Cesar Philippidis wrote:
>> On 09/22/2015 08:29 AM, Nathan Sidwell wrote:
>>
>>> 1) Don't have a fake gang reduction outside of worker & vector loops.
>>> Deal with the receiver object
is kind of long. Let me know if it should be revised.
Cesar
2015-09-28 Cesar Philippidis
gcc/
* omp-low.c (check_omp_nesting_restrictions): Check for acc loops not
associated with acc regions or routines.
gcc/testsuite/
* c-c++-common/goacc/non-routine.c: New test.
* c-c++-common/goacc-gomp
Ping.
In the meantime, I'll apply this patch to gomp-4_0-branch.
Cesar
On 09/22/2015 08:24 AM, Cesar Philippidis wrote:
> In both OpenACC and OpenMP, each subarray has at least two data mappings
> associated with them, one for the pointer and another for the data in
> the array s
On 09/29/2015 02:48 AM, Thomas Schwinge wrote:
> On Mon, 28 Sep 2015 10:08:34 -0700, Cesar Philippidis
> wrote:
>> I've applied this patch to gomp-4_0-branch which teaches omplower how to
>> error when it detects acc loops which aren't nested inside an acc
>
ed in omplow.
I've applied this patch to gomp-4_0-branch.
Cesar
2015-09-30 Cesar Philippidis
gcc/fortran/
* openmp.c (resolve_oacc_loop_blocks): Represent astrisk tile
arguments as -1.
gcc/testsuite/
* gfortran.dg/goacc/loop-5.f95: New test.
diff --git a/gcc/fortran/openmp.c b/g
atches the enum in gfortran.h because I couldn't figure out how things
were ordered before.
I've applied this patch to gomp-4_0-branch.
Cesar
2015-10-01 Cesar Philippidis
gcc/fortran/
* dump-parse-tree.c (show_omp_clauses): Add missing omp list_types
and reorder the switch cases
reason why only certain arrays have array descriptors? The
arrays with descriptors don't have this problem. It's only the ones
without descriptors that leak new internal variables that cause errors
with default(none).
Cesar
2015-10-13 Cesar Philippidis
gcc/fortr
On 10/13/2015 01:29 PM, Jakub Jelinek wrote:
> On Tue, Oct 13, 2015 at 01:12:25PM -0700, Cesar Philippidis wrote:
>> Arrays in fortran have a couple of internal variables associated with
>> them, e.g. stride, lbound, ubound, size, etc. Depending on how and where
>> the arra
h 06/14, to copy omp_data_o to shared memory. I
>> don't see
>> any other sane approach.
>
> There is an alternative - decorate anything you'd like to go to shared
> memory with a special attribute, then handled that attribute in
> nvptx_addr_space_from_addr
gth:] int-expr )]
where gang-arg is one of:
[num:] int-expr
static: size-expr
and gang-arg-list may have at most one num and one static argument,
and where size-expr is one of:
*
int-expr
So I've interpreted that as a requirement that length and num must be
followed by an int-expr, whatever that is.
I've been meaning to cleanup to up the c and c++ front ends for a while
now, but I've been bogged down by other things. This is next on my todo
list.
Cesar
On 10/22/2015 08:00 AM, Jakub Jelinek wrote:
> On Thu, Oct 22, 2015 at 07:47:01AM -0700, Cesar Philippidis wrote:
>>> But it is unclear from the parsing what from these is allowed:
>>
>> int v, w;
>> ...
>> gang(26) // equivalent to gang(num:26)
>> gan
accurate.
I've also split off the check for variables appearing in multiple
clauses into a separate function. It's a little overkill for trunk right
now, but it is used quite a bit in gomp4 for oacc declare.
I've tested these changes on x86_64. Is this ok for trunk?
Cesar
2015-10
On 10/22/2015 01:22 AM, Jakub Jelinek wrote:
> On Wed, Oct 21, 2015 at 03:16:20PM -0400, Nathan Sidwell wrote:
>> 2015-10-20 Cesar Philippidis
>> Thomas Schwinge
>> James Norris
>> Joseph Myers
>> Julia
MP's 'num_threads' clause. One change to num_threads is the
>> augmentation of a diagnostic to add %<...%> markers to the clause name.
>
> Indeed, lots of older OpenMP diagnostics is missing %<...%> markers around
> keywords. Something to fix eventually.
On 10/22/2015 08:00 AM, Jakub Jelinek wrote:
> On Thu, Oct 22, 2015 at 07:47:01AM -0700, Cesar Philippidis wrote:
>>> But it is unclear from the parsing what from these is allowed:
>>
>> int v, w;
>> ...
>> gang(26) // equivalent to gang(num:26)
>> gan
On 10/23/2015 01:31 PM, Jakub Jelinek wrote:
> On Fri, Oct 23, 2015 at 01:17:07PM -0700, Cesar Philippidis wrote:
>> Good idea, thanks. This patch also corrects the problems parsing weird
>> combinations of num, static and length arguments that you mentioned
>> elsewhere.
On 10/23/2015 02:31 PM, Cesar Philippidis wrote:
> On 10/23/2015 01:31 PM, Jakub Jelinek wrote:
>> On Fri, Oct 23, 2015 at 01:17:07PM -0700, Cesar Philippidis wrote:
>>> Good idea, thanks. This patch also corrects the problems parsing weird
>>> combinations of num, stati
On 10/23/2015 01:25 PM, Cesar Philippidis wrote:
> On 10/22/2015 01:52 AM, Jakub Jelinek wrote:
>> On Wed, Oct 21, 2015 at 03:18:55PM -0400, Nathan Sidwell wrote:
>>> This patch is the C++ changes matching the C ones of patch 4. In
>>> finish_omp_clauses, the gang, w
On 10/23/2015 01:29 PM, Cesar Philippidis wrote:
> On 10/22/2015 08:00 AM, Jakub Jelinek wrote:
>> On Thu, Oct 22, 2015 at 07:47:01AM -0700, Cesar Philippidis wrote:
>>>> But it is unclear from the parsing what from these is allowed:
>>>
>>> int v, w;
>
On 10/24/2015 01:03 AM, Jakub Jelinek wrote:
> On Fri, Oct 23, 2015 at 07:31:51PM -0700, Cesar Philippidis wrote:
>
>> +static tree
>> +c_parser_oacc_shape_clause (c_parser *parser, omp_clause_code kind,
>> +const char *str, tree list)
>>
On 10/23/2015 07:37 PM, Cesar Philippidis wrote:
> On 10/23/2015 01:25 PM, Cesar Philippidis wrote:
>> On 10/22/2015 01:52 AM, Jakub Jelinek wrote:
>>> On Wed, Oct 21, 2015 at 03:18:55PM -0400, Nathan Sidwell wrote:
>>>> This patch is the C++ changes match
On 10/26/2015 01:59 AM, Jakub Jelinek wrote:
> Ok for trunk with those changes fixed.
Here's the patch with those changes. Nathan will commit this patch the
rest of the openacc execution model patches.
Thanks,
Cesar
2015-10-26 Cesar Philippidis
Thomas Schwinge
Jame
On 10/26/2015 03:20 AM, Jakub Jelinek wrote:
> On Sat, Oct 24, 2015 at 02:11:41PM -0700, Cesar Philippidis wrote:
>> --- a/gcc/cp/semantics.c
>> +++ b/gcc/cp/semantics.c
>> @@ -5911,6 +5911,31 @@ finish_omp_clauses (tree clauses, bool allow_fields,
(was "Re: more accurate omp in fortran"
Ping.
Cesar
On 10/22/2015 08:21 AM, Cesar Philippidis wrote:
> Currently, for certain omp and oacc errors the fortran will inaccurately
> report exactly where in the omp/acc construct the error has occurred. E.g.
>
>!$acc par
struct goacc_thread *thr = goacc_thread ();
>> +
>> + if ((thr->dev->capabilities & GOMP_OFFLOAD_CAP_SHARED_MEM) == 0)
>> +{
>> + n = lookup_host (thr->dev, h, 1);
>
> What is supposed to be the behavior when the h pointer points at object
> boundary, rather than into the middle of existing mapped object?
Probably undefined with the way that OpenACC is defined.
> Say you have:
> char a[16], b[0], c[16]; // b is GCC extension
> Now, char *p = &a[5]; is unambiguous, either a is mapped, or not.
> But, if p = &a[16];, then it could be either the one-past-last byte in a,
> or it could be the start of b (== one-past-last byte in b) or it could be
> the pointer to start of c.
>
> In OpenMP 4.5, I had endless discussions about this and the end result is
> that one-past-last byte addresses are unspecified behavior
OK.
Thanks for you feedback.
Cesar
ch in my source tree.
Cesar
2015-10-27 Cesar Philippidis
gcc/c/
* c-parser.c (c_parser_oacc_shape_clause): Backport from trunk.
(c_parser_omp_simple_clause): Likewise.
(c_parser_oacc_all_clauses): Likewise.
gcc/cp/
* parser.c (cp_parser_oacc_shape_clause): Backport from trunk.
(cp_par
On 10/28/2015 04:00 AM, Thomas Schwinge wrote:
> Hi Cesar!
>
> On Tue, 27 Oct 2015 11:36:10 -0700, Cesar Philippidis
> wrote:
>> This patch contains the following:
>>
>> * C front end changes from trunk:
>> https://gcc.gnu.org/ml/gcc-patches/2015-10/m
1 - 100 of 637 matches
Mail list logo
