[og7] Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2018-05-20 Thread Thomas Schwinge
Hi! (This whole idea/patch still needs an overall re-work, as discussed, but here is a small incremental improvement/bug fix.) On Thu, 20 Aug 2015 22:52:58 +, Joseph Myers wrote: > On Tue, 18 Aug 2015, Thomas Schwinge wrote: > > [...] here is my current messy WIP patch [...] > +/* List of

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-10-20 Thread Jakub Jelinek
On Tue, Oct 20, 2015 at 01:45:37PM +0200, Bernd Schmidt wrote: > Both of you can ignore me if you feel I'm not making sense, but what exactly > is the use case for -foffload=disable? Isn't it slightly redundant with > -fno-openacc? IMO it's not an option that alters the available devices, > that's

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-10-20 Thread Jakub Jelinek
On Tue, Oct 20, 2015 at 01:17:45PM +0200, Thomas Schwinge wrote: > Always creating (dummy) GOMP_offload_register_ver constructors has been > another suggestion that I had voiced much earlier in this thread (months > ago), but everyone (including me) taking part in the discussion agreed > that it'd

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-10-20 Thread Bernd Schmidt
On 10/20/2015 01:17 PM, Thomas Schwinge wrote: As explained a few times already: GOMP_offload_register_ver constructors will only be generated if there actually are offloaded code regions, but for example: #include int main() { __builtin_printf("%d\n", acc_get_num_devices

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-10-20 Thread Thomas Schwinge
Hi Jakub! Thanks for the review. On Tue, 20 Oct 2015 12:02:45 +0200, Jakub Jelinek wrote: > On Mon, Oct 19, 2015 at 06:44:40PM +0200, Thomas Schwinge wrote: > > > How's the following (complete patch instead of incremental patch; the > > > driver changes are still the same as before)? The change

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-10-20 Thread Bernd Schmidt
On 10/20/2015 12:02 PM, Jakub Jelinek wrote: I'd like to defer review of the driver bits, can Joseph or Bernd please have a look at those? Last time around I think I asked for some minor changes, like updated documentation for give_switch. Other than that, I'm ok with the patch iff you are ha

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-10-20 Thread Jakub Jelinek
On Mon, Oct 19, 2015 at 06:44:40PM +0200, Thomas Schwinge wrote: > > How's the following (complete patch instead of incremental patch; the > > driver changes are still the same as before)? The changes are: > > > > * libgomp/target.c:gomp_target_init again loads all the plugins. > > * libgomp/

Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-10-19 Thread Thomas Schwinge
Hi! Ping... On Wed, 30 Sep 2015 17:54:07 +0200, I wrote: > On Tue, 29 Sep 2015 10:18:14 +0200, Jakub Jelinek wrote: > > On Mon, Sep 28, 2015 at 11:39:10AM +0200, Thomas Schwinge wrote: > > > On Fri, 11 Sep 2015 17:43:49 +0200, Jakub Jelinek > > > wrote: > > > > So, do I understand well that yo

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-25 Thread Joseph Myers
On reviewing in more detail the changes to pass offloading targets from the driver to libgomp at link time to identify the minimal self-contained pieces that can go to trunk, I found that the use of fnmatch to match against target names was completely unnecessary; the ISO C90 functions strstr and s

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-24 Thread Nathan Sidwell
On 08/24/15 18:22, Joseph Myers wrote: On Mon, 24 Aug 2015, Joseph Myers wrote: I'm testing this patch to default the offload targets after the original command line is processed (and before extra options from these specs are processed, so before the assertion is executed), and will commit it i

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-24 Thread Joseph Myers
On Mon, 24 Aug 2015, Joseph Myers wrote: > I'm testing this patch to default the offload targets after the > original command line is processed (and before extra options from > these specs are processed, so before the assertion is executed), and > will commit it if tests are OK. Now committed to

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-24 Thread Joseph Myers
On Fri, 21 Aug 2015, Joseph Myers wrote: > On Fri, 21 Aug 2015, Nathan Sidwell wrote: > > > this appears to cause an ICE in add_omp_infile_spec_func at; > > gcc_assert (offload_targets != NULL); > > > > when you use something like -foffload='-save-temps -v -fdump-rtl-all > > -fdump-tree-all -f

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-21 Thread Joseph Myers
On Fri, 21 Aug 2015, Nathan Sidwell wrote: > this appears to cause an ICE in add_omp_infile_spec_func at; > gcc_assert (offload_targets != NULL); > > when you use something like -foffload='-save-temps -v -fdump-rtl-all > -fdump-tree-all -fno-verbose-asm' > > Is that use ill-formed? I'll need

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-21 Thread Nathan Sidwell
On 08/20/15 18:52, Joseph Myers wrote: On Tue, 18 Aug 2015, Thomas Schwinge wrote: This is what I've committed to gomp-4_0-branch, with the driver changes substantially cleaned up and smaller changes to the other bits of the patch. gcc: 2015-08-20 Thomas Schwinge Joseph Myers

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-20 Thread Joseph Myers
On Tue, 18 Aug 2015, Thomas Schwinge wrote: > So, back to modifying the driver; here is my current messy WIP patch with > still a lot of TODOs in it -- but it appears to work at last. :-) > > Maybe somebody else is able to continue with that task while I'm out of > office. This has been develop

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-18 Thread Thomas Schwinge
Hi! On Fri, 14 Aug 2015 22:56:30 +, Joseph Myers wrote: > On Fri, 14 Aug 2015, Thomas Schwinge wrote: > > > Can you suggest off-hand where you'd expect this option filtering to > > happen? Should this be during specs parsing in the driver; something > > like adding a lang_mask to gcc/gcc.c

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-17 Thread Martin Jambor
Hi, On Fri, Aug 14, 2015 at 03:19:26PM +0200, Ilya Verbin wrote: > 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

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-14 Thread Joseph Myers
On Fri, 14 Aug 2015, Thomas Schwinge wrote: > Can you suggest off-hand where you'd expect this option filtering to > happen? Should this be during specs parsing in the driver; something > like adding a lang_mask to gcc/gcc.c:struct switchstr, and then in > gcc/gcc.c:give_switch ignore any switche

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

2015-08-14 Thread Thomas Schwinge
Hi! On Fri, 14 Aug 2015 16:56:25 +, Joseph Myers wrote: > On Fri, 14 Aug 2015, Thomas Schwinge wrote: > > > This function »generate[s] a C source file containing a constructor call > > to GOMP_set_offload_targets [...], and adds that as an infile«. This > > "basically" works ;-) -- but rea

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 Thread Joseph Myers
On Fri, 14 Aug 2015, Thomas Schwinge wrote: > This function »generate[s] a C source file containing a constructor call > to GOMP_set_offload_targets [...], and adds that as an infile«. This > "basically" works ;-) -- but really only for C source code, and for C++ > and Fortran it fails if there a

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 Thread Ilya Verbin
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, hostaddrs); >> > > >> > >void *fn_addr = gomp

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 Thread Thomas Schwinge
Hi! Assuming that the overall approach (my option a) is fine, this is now primarily a question about how to teach the driver to "the right thing". (Joseph CCed as driver reviewer.) On Wed, 5 Aug 2015 18:09:04 +0300, Ilya Verbin wrote: > On Wed, Aug 05, 2015 at 10:40:44 +0200, Richard Biener wrot