Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)

On Mon, Mar 30, 2015 at 18:42:02 +0200, Jakub Jelinek wrote: > Shouldn't either this function, or gomp_offload_image_to_device lock > also devicep->lock mutex and unlock at the end? > Where exactly I guess depends on if the devicep->* hook calls should be > guarded with the mutex or not. If yes, i

Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)

On Tue, Mar 31, 2015 at 19:10:36 +0300, Ilya Verbin wrote: > Ok, thanks for the clarification! Here is the new patch with variables. > > Unfortunately I see 4 fails in make check-target-libgomp with PTX patch > applied > on top, but with disabled offloading to PTX. > Julian,

Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)

On Wed, Apr 01, 2015 at 07:21:47 +0200, Jakub Jelinek wrote: > On Wed, Apr 01, 2015 at 02:53:28AM +0300, Ilya Verbin wrote: > > +/* Similar to gomp_fatal, but release mutexes before. */ > > + > > +static void > > +gomp_fatal_unlock (const char *fmt, ...) > > +{

Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)

On Wed, Apr 01, 2015 at 15:20:25 +0200, Jakub Jelinek wrote: > On Wed, Apr 01, 2015 at 04:14:05PM +0300, Ilya Verbin wrote: > > I was worried about the following scenario: > > 1. Thread 1 in GOMP_target locks device 1. > > 2. Thread 2 in GOMP_target locks device 2 and ca

Re: Silence merge warnings on artificial types

On Tue, Mar 31, 2015 at 09:51:21 +0200, Jan Hubicka wrote: > this patch adds the ARTIFICIAL flag check to avoid ODR merging to these. > I oriignally tested DECL_ARTIFICIAL (decl) (that is TYPE_NAME) that randomly > dropped type names on some classes but not all. > > Jason, please do you know what

Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)

On Wed, Apr 01, 2015 at 15:20:25 +0200, Jakub Jelinek wrote: > LGTM with proper ChangeLog entry. I've commited this patch into trunk. Julian, you probably want to update the nvptx plugin. gcc/ * config/i386/intelmic-mkoffload.c (generate_host_descr_file): Call GOMP_offload_unreg

Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)

On Wed, Apr 08, 2015 at 15:31:42 +0100, Julian Brown wrote: > This version is mostly the same as the last posted version but has a > tweak in GOACC_parallel to account for the new splay tree arrangement > for target functions: > > - tgt_fn = (void (*)) tgt_fn_key->tgt->tgt_start; > + tgt

Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing

On Wed, Apr 29, 2015 at 14:06:44 +0200, Jakub Jelinek wrote: > [...] The draft requires only alloc or to > (or always, variants) for enter data and only from or delete (or always, > variants) for exit data, so in theory it is possible to figure that from > the call without extra args, but not so fo

[gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

Hi, This patch introduces new versions of GOMP_target{,_data,_update} for OpenMP 4.1 with unsigned short for map kinds, but without new async arguments yet. make check-target-libgomp and bootstrap passed, ok for gomp-4_1-branch? gcc/ * builtin-types.def (BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_

Re: [gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

On Mon, Jun 15, 2015 at 15:06:09 +0200, Jakub Jelinek wrote: > On Mon, Jun 15, 2015 at 03:20:37PM +0300, Ilya Verbin wrote: > > This patch introduces new versions of GOMP_target{,_data,_update} for > > OpenMP 4.1 > > with unsigned short for map kinds, but without new async

Re: [gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

On Mon, Jun 15, 2015 at 18:25:28 +0200, Jakub Jelinek wrote: > On Mon, Jun 15, 2015 at 07:18:27PM +0300, Ilya Verbin wrote: > > On Mon, Jun 15, 2015 at 15:06:09 +0200, Jakub Jelinek wrote: > > > On Mon, Jun 15, 2015 at 03:20:37PM +0300, Ilya Verbin wrote: > > > > This

Re: [gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

Given that a mapped variable in 4.1 can have different kinds across nested data regions, we need to store map-type not only for each var, but also for each structured mapping. Here is my WIP patch, is it sane? :) Attached testcase works OK on the device with non-shared memory. diff --git a/inclu

Re: [gomp4.1] Handle linear clause on worksharing loop

On Thu, Jun 18, 2015 at 15:15:21 +0200, Jakub Jelinek wrote: > This patch adds support for linear clause on OpenMP 4.1 worksharing loops. > > 2015-06-18 Jakub Jelinek > > * gimplify.c (gimplify_scan_omp_clauses): For linear clause > on worksharing loop combined with parallel add sh

Re: [gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

On Sat, Jun 20, 2015 at 00:35:14 +0300, Ilya Verbin wrote: > Given that a mapped variable in 4.1 can have different kinds across nested > data > regions, we need to store map-type not only for each var, but also for each > structured mapping. Here is my WIP patch, is it sane? :

Re: [gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

On Tue, Jun 23, 2015 at 13:51:39 +0200, Jakub Jelinek wrote: > > + /* Set dd on target to 0 for the further check. */ > > + #pragma omp target map(always to: dd) > > + { dd; } > > This reminds me that: > if (ctx->region_type == ORT_TARGET && !(n->value & GOVD_SEEN)) >

Re: [gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

On Wed, Jun 24, 2015 at 13:39:03 +0200, Jakub Jelinek wrote: > Thinking about this more, for always modifier this isn't really sufficient. > Consider: > void > foo (int *p) > { > #pragma omp target data (alloc:p[0:32]) > { > #pragma omp target data (always, from:p[7:9]) > { > ...

Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing

On Tue, Jun 09, 2015 at 22:24:26 +0200, Jakub Jelinek wrote: > On Tue, Jun 09, 2015 at 09:36:08PM +0300, Ilya Verbin wrote: > > I don't quite understand from "If a depend clause is present, then it is > > treated > > as if it had appeared on the implicit t

[gomp4.1] Support #pragma omp target {enter,exit} data

Hi! This patch implements GOMP_target_enter_exit_data in libgomp, also it fixes a bug in gomp_map_vars_existing. make check-target-libgomp passed. However, I am afraid that there may be some hard-to-find issues (like memory leaks) in cases of mixed (structured+unstructured) data mappings... OK for

Re: [gomp4.1] Support #pragma omp target {enter,exit} data

On Tue, Jun 30, 2015 at 14:57:02 +0200, Jakub Jelinek wrote: > On Tue, Jun 30, 2015 at 03:19:30PM +0300, Ilya Verbin wrote: > > --- a/libgomp/target.c > > +++ b/libgomp/target.c > > @@ -580,10 +581,16 @@ gomp_unmap_vars (struct target_mem_desc *tgt, bool > > do_copyfro

Re: [gomp4.1] Support #pragma omp target {enter,exit} data

On Tue, Jun 30, 2015 at 18:10:44 +0200, Jakub Jelinek wrote: > The thing is whether it is actually a good idea to allocate the enter data > allocated objects together. > In OpenMP 4.0, generally objects would be allocated and deallocated at the > same times, except for multiple host threads trying

Re: [gomp4.1] Support #pragma omp target {enter,exit} data

On Thu, Jul 02, 2015 at 00:06:58 +0300, Ilya Verbin wrote: > On Tue, Jun 30, 2015 at 18:10:44 +0200, Jakub Jelinek wrote: > > The thing is whether it is actually a good idea to allocate the enter data > > allocated objects together. > > In OpenMP 4.0, generally objects w

Re: [gomp4.1] Support #pragma omp target {enter,exit} data

On Mon, Jul 06, 2015 at 19:25:09 +0200, Jakub Jelinek wrote: > On Mon, Jul 06, 2015 at 06:34:25PM +0300, Ilya Verbin wrote: > > On Thu, Jul 02, 2015 at 00:06:58 +0300, Ilya Verbin wrote: > > > The patch is not ready though, I don't know how to unmap GOMP_MAP_POINTE

Re: Tests for libgomp based on OpenMP Examples 4.0.2.

On Tue, Jul 07, 2015 at 20:17:48 +0200, Jakub Jelinek wrote: > On Tue, Jul 07, 2015 at 08:08:16PM +0300, Maxim Blumental wrote: > > > Added 16 tests for simd construct and 10 for depend clause. > > Any new tests that aren't in Examples 4.0.* document should go one level > higher, to libgomp.{c,c++

Re: [PATCH 3/4] Add libgomp plugin for Intel MIC

> On 8 июля 2015 г., at 17:16, Thomas Schwinge wrote: > > Hi! > >> On Tue, 21 Oct 2014 21:24:13 +0400, Ilya Verbin wrote: >> This patch contains a plugin for libgomp and appropriate changes for >> makefiles. >> >> The plugin uses liboffloadmic_host.

Re: [PATCH] testsuite/lib/target-supports.exp: Fix check_effective_target_lto

On 12 Jan 14:30, Jeff Law wrote: > On 01/11/15 12:26, Ilya Verbin wrote: > >On 09 Jan 10:29, Thomas Schwinge wrote: > >>As this was the only use of ENABLE_LTO in the testsuite, I suggest to > >>also remove it from the gcc/Makefile.in:site.exp rule. > > > >D

[PATCH] Fix PR testsuite/64605

Hi! This patch fixes 'make check-target-libatomic'. The problem is that gcc-dg.exp calls check_effective_target_lto, which calls libatomic_target_compile. Therefore gcc-dg.exp should be loaded only after the definition of libatomic_target_compile. However, a similar exp file in other tree (libi

Re: [PATCH] Fix PR testsuite/64605

On 15 Jan 09:40, Mike Stump wrote: > On Jan 15, 2015, at 8:14 AM, Ilya Verbin wrote: > > The problem is that gcc-dg.exp calls check_effective_target_lto, which calls > > libatomic_target_compile. Therefore gcc-dg.exp should be loaded only after > > the > > definition

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

On 22 Dec 13:35, Jakub Jelinek wrote: > On Mon, Dec 22, 2014 at 12:48:08PM +0100, Thomas Schwinge wrote: > > In my understanding, we'd like to support the modes that either all > > compilers are installed (which is what a user will be using), or all are > > tested from their build trees. Or, do we

Re: [PATCH] Fix PR testsuite/64605

On 15 Jan 11:20, Mike Stump wrote: > On Jan 15, 2015, at 9:53 AM, Ilya Verbin wrote: > > If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is > > done > > in libitm.exp, it will not work: > > Ok, original patch is fine. Oh, I see, it&

Re: [PATCH] Fix PR testsuite/64605

On 16 Jan 11:57, Gerald Pfeifer wrote: > For a few days now I see the following in my daily test runs: > > The error code is NONE > The info on the error is: > invalid command name "libatomic_target_compile" > while executing > "::tcl_unknown libatomic_target_compile lto67385.c lto67

Re: [patch] update function comments for lto_symtab_encoder_encode_*

On 15 Jan 09:40, Richard Biener wrote: > Note that we still have the issue that we want to exercise both > WHOPR and non-WHOPR in the testsuite but all testcases are so > small that we'd automagically would use non-WHOPR mode (if > such automatism was implemented...). Several tests in libgomp test

Re: [PR libgomp/64625] Remove __OFFLOAD_TABLE__ variable/formal parameter (was: Merge current set of OpenACC changes from gomp-4_0-branch)

On 16 Jan 21:34, Thomas Schwinge wrote: > On Thu, 15 Jan 2015 21:20:07 +0100, I wrote: > Here is a patch to remove the __OFFLOAD_SYMBOL__ variable/formal > parameter, as discussed in . > > But -- I now wonder whether that's actually the issue that has been > reported i

Re: Merge current set of OpenACC changes from gomp-4_0-branch

Hi! On 15 Jan 21:20, Thomas Schwinge wrote: > In r219682, I have committed to trunk our current set of OpenACC changes, > which we had prepared on gomp-4_0-branch. Thanks to everyone who has > been contributing! Unfortunately, it broke offloading from shared libraries (I mean common libs with NE

Re: [PR libgomp/64625] Remove __OFFLOAD_TABLE__ variable/formal parameter (was: Merge current set of OpenACC changes from gomp-4_0-branch)

sn't even contain the _GLOBAL_OFFSET_TABLE_ > symbol. > > On Fri, Jan 16, 2015 at 5:40 PM, Ilya Verbin wrote: > > Why do you think so? __OFFLOAD_TABLE__ symbol lives in > > libgcc/offloadstuff.c > > since November without regressions. That's correct. 1. offloadstuff.c isn't

Re: [PR libgomp/64625] Remove __OFFLOAD_TABLE__ variable/formal parameter (was: Merge current set of OpenACC changes from gomp-4_0-branch)

On 16 Jan 19:23, Jack Howarth wrote: > As I read https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625#c3, the > requirement for __OFFLOAD_TABLE__ was not longer present and the > residual usages of it just had to be removed. The weak symbol on > darwin is fragile and seems to trip up on the existing

Re: Merge current set of OpenACC changes from gomp-4_0-branch

On 17 Jan 02:16, Ilya Verbin wrote: > Hi! > > Unfortunately, it broke offloading from shared libraries (I mean common libs > with NEEDED entries, not dlopened). Such things are not covered by the > testsuite, that's why you missed this issue. Here is a simple testcase: &g

Re: Merge current set of OpenACC changes from gomp-4_0-branch

On 26 Jan 14:44, Thomas Schwinge wrote: > On 17 Jan 02:16, Ilya Verbin wrote: > > Such things are not covered by the > > testsuite, that's why you missed this issue. Here is a simple testcase: > > <http://news.gmane.org/find-root.php?message_id=%3C201501

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

On 15 Jan 19:58, Jakub Jelinek wrote: > On Thu, Jan 15, 2015 at 09:55:40PM +0300, Ilya Verbin wrote: > > This patch enables 'make check-target-libgomp' with noninstalled offloading > > compilers. It creates gcc/accel// directory in the build tree of > > the >

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

On 28 Jan 17:15, Jakub Jelinek wrote: > On Wed, Jan 28, 2015 at 07:02:59PM +0300, Ilya Verbin wrote: > > + = XNEWVEC (char, len + sizeof ("-B" "../" DEFAULT_TARGET_MACHINE > > + "/libgomp/")); >

Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions

Stage 1. [ ] Completely remove. On 12 Jan 00:22, Ilya Verbin wrote: > Currently if a target* pragma appears within a target region, GCC successfully > compiles such code (with a warning). But the binary fails at run-time, since > it > tries to call GOMP_target* functions on target. &

Re: nvptx offloading patches [4/n]

On 28 Jan 18:05, Thomas Schwinge wrote: > + fprintf (out, "#define PTX_ID 1\n"); > + fprintf (out, "static __attribute__((constructor)) void init (void)\n{\n"); > + fprintf (out, " GOMP_offload_register (__OPENMP_TARGET__, PTX_ID,\n"); The file include/gomp-constants.h already contains: #defin

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

On 28 Jan 19:20, Ilya Verbin wrote: > On 28 Jan 17:15, Jakub Jelinek wrote: > > On Wed, Jan 28, 2015 at 07:02:59PM +0300, Ilya Verbin wrote: > > > + = XNEWVEC (char, len + sizeof ("-B" "../" DEFAULT_TARGET_MACHINE > > > +

Re: Merge current set of OpenACC changes from gomp-4_0-branch

Hi Julian! On 27 Jan 14:07, Julian Brown wrote: > On Mon, 26 Jan 2015 17:34:26 +0300 > Ilya Verbin wrote: > > Here is my current patch, it works for OpenMP->MIC, but obviously > > will not work for PTX, since it requires symmetrical changes in the > > plugin. C

Re: Merge current set of OpenACC changes from gomp-4_0-branch

On 03 Feb 13:00, Julian Brown wrote: > On Tue, 3 Feb 2015 14:28:44 +0300 > Ilya Verbin wrote: > > On 27 Jan 14:07, Julian Brown wrote: > > > On Mon, 26 Jan 2015 17:34:26 +0300 > > > Ilya Verbin wrote: > > > > Here is my current patch, it works for OpenMP

Re: [PATCH 2/4] Add liboffloadmic

Hi, On 12 Dec 11:46, Thomas Schwinge wrote: > On Tue, 21 Oct 2014 21:20:34 +0400, Ilya Verbin wrote: > > This patch contains liboffloadmic library. > > > liboffloadmic/ > > Initial commit. Imported from upstream: > > https://www.openmprtl.org/sites/de

Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions

On 02 Feb 13:15, Jakub Jelinek wrote: > On Mon, Jan 12, 2015 at 12:22:44AM +0300, Ilya Verbin wrote: > > Currently if a target* pragma appears within a target region, GCC > > successfully > > compiles such code (with a warning). But the binary fails at run-time, > >

Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions

On Tue, Feb 10, 2015 at 11:20:24 +0100, Jakub Jelinek wrote: > So, what we can do is e.g. ignore the nested #pragma omp target* regions > inside of #pragma omp target, or turn them into __builtin_trap (). I like this idea to ignore them at compile-time, but how to be with declare target functions?

Re: [PATCH][OpenMP] Forbid usage of non-target functions in target regions

On Mon, Feb 02, 2015 at 13:10:19 +0100, Jakub Jelinek wrote: > [...] Generally, the solution if something goes > wrong during the offloading compilation should be just to give up on the > offloading to the particular offloading target (i.e. fill in the sections > libgomp reads in a way that will r

Re: OMP builtins in offloading (was: [PATCH 1/4] Add mkoffload for Intel MIC)

On Thu, Jan 08, 2015 at 16:49:40 +0100, Jakub Jelinek wrote: > BTW, today when looking at the TARGET_OPTION_NODE streaming caused > regressions, I've discovered that it is very hard to debug issues in the > offloading compiler. Would be nice if > -save-temps -v > printed enough information that it

Re: nvptx offloading patches [3/n], RFD

On Mon, Feb 16, 2015 at 22:08:12 +0100, Jakub Jelinek wrote: > Anyway, the question is if for offloading we use wpa stage at all these days > or not at all, if there is a way for ACCEL_COMPILER to differentiate > somehow between LTO sections written by the host compiler and LTO sections > perhaps c

Re: [PATCH 1/4] Add mkoffload for Intel MIC

On Wed, Feb 18, 2015 at 12:48:21 +0100, Thomas Schwinge wrote: > What is the rationale for the insn-modes.h order-only prerequisites for > mkoffload.o? Is this simply to get past the build issue which, for > example, Jakub also reported for the nvptx mkoffload, >

Re: Merge current set of OpenACC changes from gomp-4_0-branch

On Wed, Feb 04, 2015 at 15:05:45 +, Julian Brown wrote: > This (WIP) patch is based on top of a version of your patch that I > merged to our internal branch: that's still the easiest way for me to > test the PTX backend (with unloading support) at present, and it passes > libgomp testing that w

Re: [PATCH 1/n] OpenMP 4.0 offloading infrastructure

On Thu, Feb 19, 2015 at 12:37:10 +0100, Thomas Schwinge wrote: > On Fri, 26 Sep 2014 16:36:21 +0400, Ilya Verbin wrote: > > gcc/ > > * Makefile.in > > > (install-cpp, install-common, install_driver, install-gcc-ar): Do not > > install for the o

Re: Offloading compilers' support libraries

On Thu, Feb 19, 2015 at 13:17:37 +0100, Thomas Schwinge wrote: > My asumption is that it is always safe to install non-native (that is > cross) GCC installations into the same prefix. (Which would resolve this > problem of clashing file names for target and offloading compilers for > good.) > > S

Re: Offloading compilers' libgcc installation (was: nvptx offloading patches [3/n], RFD)

On Fri, Feb 20, 2015 at 10:27:26 +0100, Thomas Schwinge wrote: > On Thu, 19 Feb 2015 10:28:46 +0100, Bernd Schmidt > wrote: > > issue when trying to > > get at the libgcc for the nvptx accel compiler after it's been > > installed. The libgcc Makefile puts it in the wrong place - > > gcc/nvptx-

Re: Offloading compilers' support libraries

On Fri, Feb 20, 2015 at 18:05:01 +0300, Ilya Verbin wrote: > On Thu, Feb 19, 2015 at 13:17:37 +0100, Thomas Schwinge wrote: > > My asumption is that it is always safe to install non-native (that is > > cross) GCC installations into the same prefix. (Which would resolve this

Re: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming

On 24 Oct 16:20, Jakub Jelinek wrote: > Can't you do that when creating the cgraph or varpool nodes? > I'd expect the attribute to be already present on the decls at those spots. I cached "omp declare target" attribute in a symtab node. Is this patch better? OpenMP tests passed, make check in pro

Re: [PATCH 2/4] Add liboffloadmic

On 22 Oct 23:21, Ilya Verbin wrote: > On 22 Oct 10:54, Jakub Jelinek wrote: > > On Tue, Oct 21, 2014 at 09:20:34PM +0400, Ilya Verbin wrote: > > > This patch contains liboffloadmic library. > > > > > > It is used by ICC for offloading. The sources are

[PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

load targets it appends paths to liboffloadmic lib. Is it ok for trunk? Thanks, -- Ilya 2014-10-30 Andrey Turetskiy Ilya Verbin libgomp/ * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Set up offload_add

Re: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming

On 03 Nov 10:24, Jakub Jelinek wrote: > On Tue, Oct 28, 2014 at 10:30:47PM +0300, Ilya Verbin wrote: > > @@ -474,6 +475,13 @@ cgraph_node::create (tree decl) > >gcc_assert (TREE_CODE (decl) == FUNCTION_DECL); > > > >node->decl = decl; > > + >

Re: [PATCH 3/n] OpenMP 4.0 offloading infrastructure: offload tables

On 08 Oct 11:23, Jakub Jelinek wrote: > LGTM, with the requested var/section renames. > Would like if Honza and/or Richard had a look at the cgraph/LTO stuff > in the patch though. Since patch 2 was updated, this patch also should be updated. Now the offload_vars array is filled in varpool_node::g

Re: [gomp4] Use GOMP_OFFLOAD_ prefix for (OpenACC) plugin hooks

Hi, On 05 Nov 17:56, Julian Brown wrote: > +GOMP_OFFLOAD_register_image (void *host_table, void *target_data) > +GOMP_OFFLOAD_get_table (struct mapping_table **table) FYI, these interfaces may change in the near future. Currently GOMP_OFFLOAD_get_table returns a joint table for all images, offloa

Re: [gomp4] Use GOMP_OFFLOAD_ prefix for (OpenACC) plugin hooks

2014-11-06 0:28 GMT+03:00 Julian Brown : > I made some changes to table initialisation on the gomp4 branch also -- > probably not enough to genuinely support multiple devices, but > hopefully some of the way there. Have you seen those? I haven't > considered dlopened libs though. > > Similarly, I a

Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper

On 16 Oct 13:22, Jakub Jelinek wrote: > Can you please extract the configure{,.ac}, langhooks.c and varasm.c > bits into a separate patch? That is preapproved for trunk right now, that > isn't dependent on anything else. Done. > The rest LGTM, but please run it through LTO review (Richard/Honza)

Re: [PATCH 3/4] Add libgomp plugin for Intel MIC

Makefile.am new file mode 100644 index 000..0baf70d --- /dev/null +++ b/liboffloadmic/plugin/Makefile.am @@ -0,0 +1,123 @@ +# Plugin for offload execution on Intel MIC devices. +# +# Copyright (C) 2014 Free Software Foundation, Inc. +# +# Contributed by Ilya Verbin and +# Andrey Turetskiy . +#

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

On 06 Nov 18:55, Jakub Jelinek wrote: > Looks mostly good, but: > > > +# We need more things in site.exp, but automake completely controls the > > +# creation of that file; there's no way to append to it without messing up > > +# the dependancy chains. So we overrule automake. This rule is exact

Re: [patch] OpenACC fortran front end

Hi, On 11 Nov 08:10, Jakub Jelinek wrote: > For the middle-end and libgomp changes, can you talk to the Intel folks to > update their git branch to latest trunk (so that you have the nvptx bits in > there) and send middle-end and libgomp diffs against that? > As far as I remember, most of the chan

Re: [PATCH 2/4] Add liboffloadmic

On 06 Nov 19:21, Jakub Jelinek wrote: > I'm still seeing various unhandled malloc failures, e.g.: > ... > would crash if malloc returns NULL. Similarly for realloc: Fixed in the branch: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=534b201fadf0af05ca509dc3f8e13ef26ee719a2 > Also, I see you heavi

Re: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming

On 12 Nov 15:34, Richard Biener wrote: > > > Seems like Vlad introduced the conflicting type with > > Okay, we're going to test our changes with patch in the bottom applied > > both to kyukhin/gomp4-offload and trunk. > > > > * gcc/lra-lives.c (struct bb_data): Rename to ... > > (struct

[PATCH, AVX-512, committed] Fix detection of AVX512IFMA in host_detect_local_cpu

Hi! I've committed this patch as obvious. gcc/ * config/i386/driver-i386.c (host_detect_local_cpu): Fix detection of AVX512IFMA. Index: gcc/config/i386/driver-i386.c === --- gcc/config/i386/driver-i386.c (revision 239907) +++ gcc/

Re: [PATCH, i386, AVX-512] Add vectorizer support builtins

On Mon, May 23, 2016 at 19:11:53 +0300, Ilya Verbin wrote: > This patch adds missed 512-bit rounding builtins for vectorization. > Regtested on x86_64-linux and i686-linux. OK for trunk? > > gcc/ > * config/i386/i386-builtin-types.def: Add V16SI_FTYPE_V16SF, > V8D

Re: Cilk Plus testsuite needs massive cleanup (PR testsuite/70595)

On Fri, Apr 29, 2016 at 11:19:47 -0700, Mike Stump wrote: > On Apr 29, 2016, at 5:41 AM, Rainer Orth > wrote: > > diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h > > --- a/gcc/config/darwin.h > > +++ b/gcc/config/darwin.h > > @@ -179,6 +179,7 @@ extern GTY(()) int darwin_ms_struct; > >

[PATCH, i386, AVX-512ER] vrcp28ps auto generation

Hi! This patch emits vrcp28ps and vmulps istructions for ix86_emit_swdivsf. The relative error is < 2^-23, so no additional iteration is necessary. Regtested using various benchmarks on a AVX-512ER machine. OK for trunk? gcc/ * config/i386/i386.c (ix86_emit_swdivsf): Emit vrcp28ps. gcc/

[PATCH, i386, AVX-512ER] vrsqrt28ps auto generation

Hi! This patch emits vrsqrt28ps instruction in ix86_emit_swsqrtsf for recip case and vrcp28ps(vrsqrt28ps(a)) for !recip. Regtested using various benchmarks on a AVX-512ER machine. OK for trunk? gcc/ * config/i386/i386.c (ix86_emit_swsqrtsf): Emit vrsqrt28ps. * config/i386/sse.md

[PATCH][CilkPlus] Allow parenthesized initialization in for-loops

Hi! www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm says: In C++, the control variable shall be declared and initialized within the initialization clause of the _Cilk_for loop. The variable shall have automatic storage duration. The variable shall b

Re: [PATCH][CilkPlus] Allow parenthesized initialization in for-loops

On Mon, Mar 21, 2016 at 15:58:18 +0100, Jakub Jelinek wrote: > On Mon, Mar 21, 2016 at 05:45:52PM +0300, Ilya Verbin wrote: > > www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm > > says: > > In C++, the control variable shall be dec

Re: FW: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C

Hi Thomas! Do you plan to commit this patch? :) On Mon, Sep 29, 2014 at 09:24:40 -0600, Jeff Law wrote: > On 09/29/14 08:26, Thomas Schwinge wrote: > >On Mon, 29 Sep 2014 13:58:31 +, "Tannenbaum, Barry M" > > wrote: > >>In a nutshell, add the following code to main() before the call to f3():

Re: FW: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C

On Tue, Mar 29, 2016 at 17:15:11 +0200, Thomas Schwinge wrote: > On Mon, 28 Mar 2016 19:40:22 +0300, Ilya Verbin wrote: > > Do you plan to commit this patch? :) > > Well, I'm also still waiting for you guys to merge (via the upstream > Intel sources repository) my GNU H

Re: [PATCH][CilkPlus] Fix PR69363

On Wed, Feb 17, 2016 at 15:46:00 +0100, Jakub Jelinek wrote: > On Wed, Feb 17, 2016 at 05:32:58PM +0300, Ilya Verbin wrote: > > This patch fixes <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69363> > > Bootstrap and make check passed. OK for... stage 1? > > Ok

Re: Allow redefinition of libcilkrts debug macros

Hi Rainer! On Fri, Apr 29, 2016 at 10:58:25 +0200, Rainer Orth wrote: > > On 04/26/2016 08:04 AM, Rainer Orth wrote: > >> When working on a couple of Cilk Plus issues lately (PRs target/60290, > >> target/68945), I noticed that you have to modify the libcilkplus sources > >> to enable various debu

Re: [PATCH] Apply fix for PR68463 to RS6000

On Tue, May 10, 2016 at 11:48:53 -0400, David Edelsohn wrote: > On Tue, May 10, 2016 at 11:39 AM, James Norris > wrote: > > The fix for PR68463 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463) > > was missing code that prevented the fix from working on RS6000. The > > attached patch adds the

Re: [PATCH][CilkPlus] Merge libcilkrts from upstream

On Mon, May 09, 2016 at 11:39:51 +0200, Matthias Klose wrote: > >well, it breaks the build for many multilib configurations where multilib > >binaries cannot be run on the current environment, e.g. building x32 > >multilibs > >on a kernel which doesn't have x32 enabled. > > > >The reason is again

Re: [PATCH][CilkPlus] Merge libcilkrts from upstream

On Tue, May 10, 2016 at 14:36:36 +0100, Ramana Radhakrishnan wrote: > On Tue, May 10, 2016 at 2:02 PM, Christophe Lyon > wrote: > > On 9 May 2016 at 15:34, Christophe Lyon wrote: > >> On 9 May 2016 at 15:29, Jeff Law wrote: > >>> On 05/09/2016 01:37 AM, Christophe Lyon wrote: > After this m

Re: [PATCH][CilkPlus] Allow parenthesized initialization in for-loops

On Fri, Mar 25, 2016 at 18:23:23 +0300, Ilya Verbin wrote: > On Mon, Mar 21, 2016 at 15:58:18 +0100, Jakub Jelinek wrote: > > On Mon, Mar 21, 2016 at 05:45:52PM +0300, Ilya Verbin wrote: > > > www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_

Re: [PATCH][CilkPlus] Merge libcilkrts from upstream

On Wed, May 11, 2016 at 10:47:49 +0100, Ramana Radhakrishnan wrote: > > > I've looked at the generated code in more details, and for armv6 this > > generates > > mcr p15, 0, r0, c7, c10, 5 > > which is not what __cilkrts_fence uses currently (CP15DSB vs CP15DMB) > > Wow I hadn't noticed that

[PATCH][Testsuite] Force testing of vectorized builtins rather than inlined i387 asm

Hi! In some cases the i387 version of a math function may be inlined from math.h, and the testcase (like gcc.target/i386/sse4_1-ceil-vec.c) will actually test inlined asm instead of vectorized builtin. To fix this I've created a new file gcc.dg/mathfunc.h (similar to gcc.dg/strlenopt.h) and chang

Re: [PATCH][Testsuite] Force testing of vectorized builtins rather than inlined i387 asm

On Sat, May 21, 2016 at 09:51:36 +0200, Uros Bizjak wrote: > On Fri, May 20, 2016 at 8:01 PM, Ilya Verbin wrote: > > In some cases the i387 version of a math function may be inlined from > > math.h, > > and the testcase (like gcc.target/i386/sse4_1-ceil-vec.c) will actually

[PATCH, i386, AVX-512] Add vectorizer support builtins

Hi! This patch adds missed 512-bit rounding builtins for vectorization. Regtested on x86_64-linux and i686-linux. OK for trunk? gcc/ * config/i386/i386-builtin-types.def: Add V16SI_FTYPE_V16SF, V8DF_FTYPE_V8DF_ROUND, V16SF_FTYPE_V16SF_ROUND, V16SI_FTYPE_V16SF_ROUND. * co

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) (was: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming)

2015-08-14 11:47 GMT+02:00 Thomas Schwinge : > On Wed, 5 Aug 2015 18:09:04 +0300, Ilya Verbin wrote: >> > > @@ -1095,6 +1092,8 @@ GOMP_target (int device, void (*fn) (void *), >> > > const void *unused, >> > > return gomp_target_fallback (fn, hos

Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing

On Mon, Aug 24, 2015 at 14:26:57 +0200, Jakub Jelinek wrote: > On Mon, Jul 20, 2015 at 09:53:42PM +0300, Ilya Verbin wrote: > > Latest liboffloadmic (I'm preparing an update for trunk) can take some > > pointer > > *ptr* as argument of __offload_offload, which is u

[PATCH] Import liboffloadmic from upstream

Hi! This patch contains an update for liboffloadmic, imported from , version 20150803. Two major new features are: 1. Unloading of loaded images from target device. 2. Callback support for asynchronous execution. make check passed. Is it ok for trunk? liboffload

Re: [PATCH] Import liboffloadmic from upstream

On Mon, Aug 31, 2015 at 16:49:53 +0200, Jakub Jelinek wrote: > 1) Is the library backwards ABI compatible? Can you run e.g. >libabigail abidiff in between the unpatched and patched version? It should be in theory, and I've successfully tested an old binary with old libgomp plugin and with new

Re: Fix intelmic-mkoffload.c if the temp path contains a '-'

On Tue, Sep 01, 2015 at 11:35:15 +, Hahnfeld, Jonas wrote: > > during my test of OpenMP 4.0 offloading features I have found a bug in > > intelmic-mkoffload.c when the temp path contains a '-'. > > objcopy will in this case replace it with a '_' which wasn't reflected in > > the original code a

Re: [PATCH] Import liboffloadmic from upstream

On Tue, Sep 01, 2015 at 09:58:22 +0200, Dodji Seketeli wrote: > Woops. can you send me the exact two libraries so that I can see what's > going wrong? You can quickly file an issue to > https://sourceware.org/bugzilla/enter_bug.cgi?product=libabigail or just > send me the two binaries by email. I

Re: [gomp4.1] Structure element mapping support

On Mon, Aug 31, 2015 at 17:07:53 +0200, Jakub Jelinek wrote: > * gimplify.c (gimplify_scan_omp_clauses): Handle > struct element GOMP_MAP_FIRSTPRIVATE_POINTER. Have you seen this? gcc/gimplify.c: In function ‘void gimplify_scan_omp_clauses(tree_node**, gimple_statement_base**, omp_re

Re: Fix intelmic-mkoffload.c if the temp path contains a '-'

On Fri, Sep 04, 2015 at 11:10:13 +, Hahnfeld, Jonas wrote: > *ping* > I don't have write access to the repository... I've committed it to trunk: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227489 What about gcc-5-branch? -- Ilya

Re: [gomp4.1] Various accelerator updates from OpenMP 4.1

Hi! It seems that there is a bug some here: On Wed, Jul 29, 2015 at 19:19:07 +0200, Jakub Jelinek wrote: > @@ -12918,6 +12989,28 @@ lower_omp_target (gimple_stmt_iterator * > var = var2; > } > > + if (offloaded > + && OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVAT

Re: Fix intelmic-mkoffload.c if the temp path contains a '-'

2015-09-04 22:27 GMT+03:00 Mike Stump : > On Sep 4, 2015, at 4:10 AM, Hahnfeld, Jonas > wrote: >* intelmic-mkoffload.c (prepare_target_image): Fix if the temp path >contains a '-‘. > > So, out of curiosity, did you test all characters other than null? If - > doesn’t work, there

Re: Fix intelmic-mkoffload.c if the temp path contains a '-'

2015-09-05 1:50 GMT+03:00 Mike Stump : > > On Sep 4, 2015, at 2:45 PM, Ilya Verbin wrote: > >> 2015-09-04 22:27 GMT+03:00 Mike Stump : >>> On Sep 4, 2015, at 4:10 AM, Hahnfeld, Jonas >>> wrote: >>>>>>> * intelmic-mkoffload.c (prepare_ta

Re: Fix intelmic-mkoffload.c if the temp path contains a '-'

On Sat, Sep 05, 2015 at 00:45:36 +0300, Ilya Verbin wrote: > 2015-09-04 22:27 GMT+03:00 Mike Stump : > > On Sep 4, 2015, at 4:10 AM, Hahnfeld, Jonas > > wrote: > >>>>>* intelmic-mkoffload.c (prepare_target_image): Fix if the temp path > >>>>&

<    1   2   3   4   >