Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Kirill Yukhin]

Hello,

Support of OpenMP 4.0 offloading to future Xeon Phi was fully checked in to main
trunk.

Thanks everybody who helped w/ development and review.

--
Thanks, K

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Tobias Burnus]

Kirill Yukhin wrote:
> Support of OpenMP 4.0 offloading to future Xeon Phi was
> fully checked in to main trunk.

Thanks. If I understood it correctly:

* GCC 5 supports code generation for Xeon Phi (Knights Landing, KNL)
* KNL (the hardware) is not yet available [mid 2015?]
* liboffloadmic supports offloading in an emulation mode (executed on
  the host) but does not (yet) support offloading to KNL; i.e. one
  would need an updated version of it, once one gets hold of the
  actual hardware.
* The current hardware (Xeon Phi Knights Corner, KNC) is and will not
  be supported by GCC.

* Details for building GCC for offloading and running code on an
accelerator is at https://gcc.gnu.org/wiki/Offloading

Question: Is the latter up to date - and the item above correct?
BTW: you could update gcc.gnu.org ->news and gcc.gnu.org/gcc-5/changes.html

Otherwise:
* OpenACC support is about to be merged (as alternative to OpenMP 4)
* Support for offloading to NVidia GPUs via PTX is also about to be merged.

Tobias

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Jakub Jelinek]

On Thu, Nov 13, 2014 at 04:15:48PM +0100, Tobias Burnus wrote:
> Question: Is the latter up to date - and the item above correct?

Will leave that to Kirill.

> BTW: you could update gcc.gnu.org ->news and gcc.gnu.org/gcc-5/changes.html

Indeed, that should be updated.

> Otherwise:
> * OpenACC support is about to be merged (as alternative to OpenMP 4)

I hope so.

> * Support for offloading to NVidia GPUs via PTX is also about to be merged.

Ditto.

Then the question is how hard will it be to get OpenACC offloading to
XeonPhi (real hw or emulation) - I guess it is a matter of whether the
plugin needs to implement some extra hooks for OpenACC, and also
whether we can get OpenMP offloading to PTX (dunno if Thomas or his
collegues have actually tried it on simple testcases, I bet the hardest part
will be porting libgomp away from pthread_* to optionally be supported
by the limited nvptx target and use its threading model; whether __thread
is already supported by nvptx etc.).  I'm willing to help with this once I
have some hw, but some help from people familiar with PTX would be certainly
appreciated.  Because without libgomp ported to nvptx-*-* target (or some
way to inline all the GOMP_*/omp_* calls in offloading regions for nvptx,
but the latter might be too hard), I guess one could offload very simple
target regions, but not anything using #pragma omp inside of them.

	Jakub

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Kirill Yukhin]

Hi Tobias,
On 13 Nov 16:15, Tobias Burnus wrote:
> Kirill Yukhin wrote:
> > Support of OpenMP 4.0 offloading to future Xeon Phi was
> > fully checked in to main trunk.
> 
> Thanks. If I understood it correctly:
> 
> * GCC 5 supports code generation for Xeon Phi (Knights Landing, KNL)
Right.

> * KNL (the hardware) is not yet available [mid 2015?]
Yes, but I don't know the date.

> * liboffloadmic supports offloading in an emulation mode (executed on
>   the host) but does not (yet) support offloading to KNL; i.e. one
>   would need an updated version of it, once one gets hold of the
>   actual hardware.
Yes, it supports emulation mode. Also, current scheme is the same as
for KNC (however we have no code generator in GCC main trunk for KNC).
We're going to keep liboffloadmic up-to-date.

> * The current hardware (Xeon Phi Knights Corner, KNC) is and will not
>   be supported by GCC.
Currently GCC main trunk doesn't support KNC code gen.

> * Details for building GCC for offloading and running code on an
> accelerator is at https://gcc.gnu.org/wiki/Offloading
> 
> Question: Is the latter up to date - and the item above correct?
Correct.

> BTW: you could update gcc.gnu.org ->news and gcc.gnu.org/gcc-5/changes.html
Thanks, I'll post a patch.

--
Thanks, K

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Kirill Yukhin]

<Reposting to gcc@gcc.gnu.org>

Hi Tobias,
On 13 Nov 16:15, Tobias Burnus wrote:
> Kirill Yukhin wrote:
> > Support of OpenMP 4.0 offloading to future Xeon Phi was
> > fully checked in to main trunk.
> 
> Thanks. If I understood it correctly:
> 
> * GCC 5 supports code generation for Xeon Phi (Knights Landing, KNL)
Right.

> * KNL (the hardware) is not yet available [mid 2015?]
Yes, but I don't know the date.

> * liboffloadmic supports offloading in an emulation mode (executed on
>   the host) but does not (yet) support offloading to KNL; i.e. one
>   would need an updated version of it, once one gets hold of the
>   actual hardware.
Yes, it supports emulation mode. Also, current scheme is the same as
for KNC (however we have no code generator in GCC main trunk for KNC).
We're going to keep liboffloadmic up-to-date.

> * The current hardware (Xeon Phi Knights Corner, KNC) is and will not
>   be supported by GCC.
Currently GCC main trunk doesn't support KNC code gen.

> * Details for building GCC for offloading and running code on an
> accelerator is at https://gcc.gnu.org/wiki/Offloading
> 
> Question: Is the latter up to date - and the item above correct?
Correct.

> BTW: you could update gcc.gnu.org ->news and gcc.gnu.org/gcc-5/changes.html
Thanks, I'll post a patch.

--
Thanks, K

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[H.J. Lu]

On Thu, Nov 13, 2014 at 6:14 AM, Kirill Yukhin <kirill.yukhin@gmail.com> wrote:
> Hello,
>
> Support of OpenMP 4.0 offloading to future Xeon Phi was fully checked in to main
> trunk.
>
> Thanks everybody who helped w/ development and review.
>

I noticed many libgomp test failures:

https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00309.html

Have you seen them?

-- 
H.J.

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Ilya Verbin]

On 13 Nov 09:17, H.J. Lu wrote:
> I noticed many libgomp test failures:
> 
> https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00309.html
> 
> Have you seen them?

Hi H.J.,

I do not see these regressions on i686-linux and x86_64-linux.
Could you please provide more details? (configure options, error log)

Thanks,
  -- Ilya

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[H.J. Lu]

On Thu, Nov 13, 2014 at 10:37 AM, Ilya Verbin <iverbin@gmail.com> wrote:
> On 13 Nov 09:17, H.J. Lu wrote:
>> I noticed many libgomp test failures:
>>
>> https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00309.html
>>
>> Have you seen them?
>
> Hi H.J.,
>
> I do not see these regressions on i686-linux and x86_64-linux.
> Could you please provide more details? (configure options, error log)
>
> Thanks,
>   -- Ilya

GCC is configured with

--prefix=/usr/5.0.0 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld i686-linux --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto,objc

I got

spawn -ignore SIGHUP
/export/project/git/gcc-regression/master/217501/bld/gcc/xgcc
-B/export/project/git/gcc-regression/master/217501/bld/gcc/
/export/project/git/gcc-regression/gcc/libgomp/testsuite/libgomp.c/examples-4/e.50.1.c
-B/export/project/git/gcc-regression/master/217501/bld/x86_64-unknown-linux-gnu/./libgomp/
-B/export/project/git/gcc-regression/master/217501/bld/x86_64-unknown-linux-gnu/./libgomp/.libs
-I/export/project/git/gcc-regression/master/217501/bld/x86_64-unknown-linux-gnu/./libgomp
-I/export/project/git/gcc-regression/gcc/libgomp/testsuite/..
-fmessage-length=0 -fno-diagnostics-show-caret
-fdiagnostics-color=never -fopenmp -O2
-L/export/project/git/gcc-regression/master/217501/bld/x86_64-unknown-linux-gnu/./libgomp/.libs
-lm -o ./e.50.1.exe^M
/usr/local/bin/ld: /tmp/ccA8cExp.o: plugin needed to handle lto object^M
output is:
/usr/local/bin/ld: /tmp/ccA8cExp.o: plugin needed to handle lto object^M


-- 
H.J.

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Ilya Verbin]

On 13 Nov 10:48, H.J. Lu wrote:
> /usr/local/bin/ld: /tmp/ccA8cExp.o: plugin needed to handle lto object^M

Looks like we should set flag_fat_lto_objects while compilation with offloading.
I'll investigate this issue tomorrow.

Could you please also show a version and configure options for ld?

Thanks,
  -- Ilya

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[H.J. Lu]

On Thu, Nov 13, 2014 at 11:20 AM, Ilya Verbin <iverbin@gmail.com> wrote:
> On 13 Nov 10:48, H.J. Lu wrote:
>> /usr/local/bin/ld: /tmp/ccA8cExp.o: plugin needed to handle lto object^M
>
> Looks like we should set flag_fat_lto_objects while compilation with offloading.
> I'll investigate this issue tomorrow.
>
> Could you please also show a version and configure options for ld?
>
> Thanks,
>   -- Ilya

I am using binutils 20141107 trunk, which was configured with

--with-sysroot=/ \
--enable-gold --enable-plugins --enable-threads --enable-targets=x86_64-linux \
--prefix=/usr/local \
--with-local-prefix=/usr/local


-- 
H.J.

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[H.J. Lu]

On Thu, Nov 13, 2014 at 11:20 AM, Ilya Verbin <iverbin@gmail.com> wrote:
> On 13 Nov 10:48, H.J. Lu wrote:
>> /usr/local/bin/ld: /tmp/ccA8cExp.o: plugin needed to handle lto object^M
>
> Looks like we should set flag_fat_lto_objects while compilation with offloading.
> I'll investigate this issue tomorrow.
>
> Could you please also show a version and configure options for ld?
>


Section Headers:
  [Nr] Name              Type            Address          Off    Size
 ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000
000000 00      0   0  0
  [ 1] .text             PROGBITS        0000000000000000 000040
000204 00  AX  0   0 16
  [ 2] .rela.text        RELA            0000000000000000 001a60
0000d8 18   I 29   1  8
  [ 3] .data             PROGBITS        0000000000000000 000260
000040 00  WA  0   0 32
  [ 4] .bss              NOBITS          0000000000000000 0002a0
000000 00  WA  0   0  1
  [ 5] .gnu.offload_lto_.profile.50035f9931394ed4 PROGBITS
0000000000000000 0002a0 000013 00   E  0   0  1
  [ 6] .gnu.offload_lto_.icf.50035f9931394ed4 PROGBITS
0000000000000000 0002b3 00001e 00   E  0   0  1
  [ 7] .gnu.offload_lto_.jmpfuncs.50035f9931394ed4 PROGBITS
0000000000000000 0002d1 000019 00   E  0   0  1
  [ 8] .gnu.offload_lto_.inline.50035f9931394ed4 PROGBITS
0000000000000000 0002ea 00006c 00   E  0   0  1
  [ 9] .gnu.offload_lto_.pureconst.50035f9931394ed4 PROGBITS
0000000000000000 000356 000013 00   E  0   0  1
  [10] .gnu.offload_lto_vec_mult._omp_fn.1.50035f9931394ed4 PROGBITS
     0000000000000000 000369 0004ab 00   E  0   0  1
  [11] .gnu.offload_lto_vec_mult._omp_fn.0.50035f9931394ed4 PROGBITS
     0000000000000000 000814 00035d 00   E  0   0  1
  [12] .gnu.offload_lto_.symbol_nodes.50035f9931394ed4 PROGBITS
0000000000000000 000b71 000055 00   E  0   0  1
  [13] .gnu.offload_lto_.refs.50035f9931394ed4 PROGBITS
0000000000000000 000bc6 000014 00   E  0   0  1
  [14] .gnu.offload_lto_.offload_table.50035f9931394ed4 PROGBITS
 0000000000000000 000bda 000011 00   E  0   0  1
  [15] .gnu.offload_lto_.decls.50035f9931394ed4 PROGBITS
0000000000000000 000beb 00043d 00   E  0   0  1
  [16] .gnu.offload_lto_.symtab.50035f9931394ed4 PROGBITS
0000000000000000 001028 000000 00   E  0   0  1
  [17] .gnu.offload_lto_.opts PROGBITS        0000000000000000 001028
0000a9 00   E  0   0  1

Don't you need another plugin to claim those offload IR sections?

-- 
H.J.

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Ilya Verbin]

On 13 Nov 2014, at 23:11, H.J. Lu <hjl.tools@gmail.com> wrote:
> 
> Section Headers:
>  [Nr] Name              Type            Address          Off    Size
> ES Flg Lk Inf Al
>  [ 0]                   NULL            0000000000000000 000000
> 000000 00      0   0  0
>  [ 1] .text             PROGBITS        0000000000000000 000040
> 000204 00  AX  0   0 16
>  [ 2] .rela.text        RELA            0000000000000000 001a60
> 0000d8 18   I 29   1  8
>  [ 3] .data             PROGBITS        0000000000000000 000260
> 000040 00  WA  0   0 32
>  [ 4] .bss              NOBITS          0000000000000000 0002a0
> 000000 00  WA  0   0  1
>  [ 5] .gnu.offload_lto_.profile.50035f9931394ed4 PROGBITS
> 0000000000000000 0002a0 000013 00   E  0   0  1
>  [ 6] .gnu.offload_lto_.icf.50035f9931394ed4 PROGBITS
> 0000000000000000 0002b3 00001e 00   E  0   0  1
>  [ 7] .gnu.offload_lto_.jmpfuncs.50035f9931394ed4 PROGBITS
> 0000000000000000 0002d1 000019 00   E  0   0  1
>  [ 8] .gnu.offload_lto_.inline.50035f9931394ed4 PROGBITS
> 0000000000000000 0002ea 00006c 00   E  0   0  1
>  [ 9] .gnu.offload_lto_.pureconst.50035f9931394ed4 PROGBITS
> 0000000000000000 000356 000013 00   E  0   0  1
>  [10] .gnu.offload_lto_vec_mult._omp_fn.1.50035f9931394ed4 PROGBITS
>     0000000000000000 000369 0004ab 00   E  0   0  1
>  [11] .gnu.offload_lto_vec_mult._omp_fn.0.50035f9931394ed4 PROGBITS
>     0000000000000000 000814 00035d 00   E  0   0  1
>  [12] .gnu.offload_lto_.symbol_nodes.50035f9931394ed4 PROGBITS
> 0000000000000000 000b71 000055 00   E  0   0  1
>  [13] .gnu.offload_lto_.refs.50035f9931394ed4 PROGBITS
> 0000000000000000 000bc6 000014 00   E  0   0  1
>  [14] .gnu.offload_lto_.offload_table.50035f9931394ed4 PROGBITS
> 0000000000000000 000bda 000011 00   E  0   0  1
>  [15] .gnu.offload_lto_.decls.50035f9931394ed4 PROGBITS
> 0000000000000000 000beb 00043d 00   E  0   0  1
>  [16] .gnu.offload_lto_.symtab.50035f9931394ed4 PROGBITS
> 0000000000000000 001028 000000 00   E  0   0  1
>  [17] .gnu.offload_lto_.opts PROGBITS        0000000000000000 001028
> 0000a9 00   E  0   0  1
> 
> Don't you need another plugin to claim those offload IR sections?

No, the plan was that a regular plugin will just ignore offload IR sections by default.  In your configuration ld detects a __gnu_lto_slim symbol and decided that the object file contains only LTO IR without asm.  I am going to investigate where is the difference with my configuration and fix the bug.

  -- Ilya

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Jakub Jelinek]

On Thu, Nov 13, 2014 at 11:53:53PM +0300, Ilya Verbin wrote:
> > Don't you need another plugin to claim those offload IR sections?
> 
> No, the plan was that a regular plugin will just ignore offload IR
> sections by default.  In your configuration ld detects a __gnu_lto_slim
> symbol and decided that the object file contains only LTO IR without asm. 
> I am going to investigate where is the difference with my configuration
> and fix the bug.

FYI, I'm getting
+WARNING: program timed out.
+FAIL: libgomp.c/examples-4/e.54.2.c execution test
on both x86_64-linux and i686-linux (normal --enable-checking=yes,rtl
bootstrap, no offloading configure options).
binutils-2.24, ld.bfd.

	Jakub

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Richard Biener]

On Thu, Nov 13, 2014 at 10:47 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Nov 13, 2014 at 11:53:53PM +0300, Ilya Verbin wrote:
>> > Don't you need another plugin to claim those offload IR sections?
>>
>> No, the plan was that a regular plugin will just ignore offload IR
>> sections by default.  In your configuration ld detects a __gnu_lto_slim
>> symbol and decided that the object file contains only LTO IR without asm.
>> I am going to investigate where is the difference with my configuration
>> and fix the bug.
>
> FYI, I'm getting
> +WARNING: program timed out.
> +FAIL: libgomp.c/examples-4/e.54.2.c execution test
> on both x86_64-linux and i686-linux (normal --enable-checking=yes,rtl
> bootstrap, no offloading configure options).
> binutils-2.24, ld.bfd.

Me too, with default checking (timeouts are really annoying....).

Richard.

>         Jakub

[committed] Improve e.54.2.c testcase

[Jakub Jelinek]

On Fri, Nov 14, 2014 at 11:14:59AM +0100, Richard Biener wrote:
> On Thu, Nov 13, 2014 at 10:47 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Thu, Nov 13, 2014 at 11:53:53PM +0300, Ilya Verbin wrote:
> >> > Don't you need another plugin to claim those offload IR sections?
> >>
> >> No, the plan was that a regular plugin will just ignore offload IR
> >> sections by default.  In your configuration ld detects a __gnu_lto_slim
> >> symbol and decided that the object file contains only LTO IR without asm.
> >> I am going to investigate where is the difference with my configuration
> >> and fix the bug.
> >
> > FYI, I'm getting
> > +WARNING: program timed out.
> > +FAIL: libgomp.c/examples-4/e.54.2.c execution test
> > on both x86_64-linux and i686-linux (normal --enable-checking=yes,rtl
> > bootstrap, no offloading configure options).
> > binutils-2.24, ld.bfd.
> 
> Me too, with default checking (timeouts are really annoying....).

So, it turns out that the problem is in heavily parallel testing that
these two testcases spawn just way too many #pragma omp parallels in
sequence (32768), unnecessarily so.  And, with the default partial busy
waiting (something in between OMP_WAIT_POLICY=passive and active) if too
often when some threads busy wait on some barrier big amounts of other jobs
(other tests) contend for the CPUs, it means the test can run for minutes,
while normally it takes 0.5s.  Fixed thusly, committed to trunk.

With all the additions to the libgomp test, seems even on a fast box (but
with heavy contention) libgomp testing now takes already 30 minutes or so,
I guess I should play with the possibility to set OMP_WAIT_POLICY=passive
for libgomp testing in the environment of the tests, e.g. if make -jN
was used (and keep the default wait policy if it wasn't).

2014-11-14  Jakub Jelinek  <jakub@redhat.com>

	* libgomp.c/examples-4/e.54.2.c (main): Use N / 8 instead
	of 32 as block_size.
	* libgomp.fortran/examples-4/e.54.2.f90 (e_54_1): Use n / 8
	instead of 32 as block_size.

--- libgomp/testsuite/libgomp.c/examples-4/e.54.2.c.jj	2014-11-13 15:13:18.000000000 +0100
+++ libgomp/testsuite/libgomp.c/examples-4/e.54.2.c	2014-11-14 15:07:07.428485712 +0100
@@ -61,7 +61,7 @@ int main ()
   init (v1, v2, N);
 
   p1 = dotprod_ref (v1, v2, N);
-  p2 = dotprod (v1, v2, N, 32, 2, 8);
+  p2 = dotprod (v1, v2, N, N / 8, 2, 8);
 
   check (p1, p2);
 
--- libgomp/testsuite/libgomp.fortran/examples-4/e.54.2.f90.jj	2014-11-13 15:13:17.000000000 +0100
+++ libgomp/testsuite/libgomp.fortran/examples-4/e.54.2.f90	2014-11-14 15:08:41.471776859 +0100
@@ -59,7 +59,7 @@ program e_54_1
   allocate (B(n), C(n))
   call init (B, C, n)
   ref = dotprod_ref (B, C, n)
-  d = dotprod (B, C, n, 32, 2, 8)
+  d = dotprod (B, C, n, n / 8, 2, 8)
   call check (ref, d)
   deallocate (B, C)
 end program

	Jakub

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[H.J. Lu]

On Thu, Nov 13, 2014 at 12:53 PM, Ilya Verbin <iverbin@gmail.com> wrote:
> On 13 Nov 2014, at 23:11, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> Section Headers:
>>  [Nr] Name              Type            Address          Off    Size
>> ES Flg Lk Inf Al
>>  [ 0]                   NULL            0000000000000000 000000
>> 000000 00      0   0  0
>>  [ 1] .text             PROGBITS        0000000000000000 000040
>> 000204 00  AX  0   0 16
>>  [ 2] .rela.text        RELA            0000000000000000 001a60
>> 0000d8 18   I 29   1  8
>>  [ 3] .data             PROGBITS        0000000000000000 000260
>> 000040 00  WA  0   0 32
>>  [ 4] .bss              NOBITS          0000000000000000 0002a0
>> 000000 00  WA  0   0  1
>>  [ 5] .gnu.offload_lto_.profile.50035f9931394ed4 PROGBITS
>> 0000000000000000 0002a0 000013 00   E  0   0  1
>>  [ 6] .gnu.offload_lto_.icf.50035f9931394ed4 PROGBITS
>> 0000000000000000 0002b3 00001e 00   E  0   0  1
>>  [ 7] .gnu.offload_lto_.jmpfuncs.50035f9931394ed4 PROGBITS
>> 0000000000000000 0002d1 000019 00   E  0   0  1
>>  [ 8] .gnu.offload_lto_.inline.50035f9931394ed4 PROGBITS
>> 0000000000000000 0002ea 00006c 00   E  0   0  1
>>  [ 9] .gnu.offload_lto_.pureconst.50035f9931394ed4 PROGBITS
>> 0000000000000000 000356 000013 00   E  0   0  1
>>  [10] .gnu.offload_lto_vec_mult._omp_fn.1.50035f9931394ed4 PROGBITS
>>     0000000000000000 000369 0004ab 00   E  0   0  1
>>  [11] .gnu.offload_lto_vec_mult._omp_fn.0.50035f9931394ed4 PROGBITS
>>     0000000000000000 000814 00035d 00   E  0   0  1
>>  [12] .gnu.offload_lto_.symbol_nodes.50035f9931394ed4 PROGBITS
>> 0000000000000000 000b71 000055 00   E  0   0  1
>>  [13] .gnu.offload_lto_.refs.50035f9931394ed4 PROGBITS
>> 0000000000000000 000bc6 000014 00   E  0   0  1
>>  [14] .gnu.offload_lto_.offload_table.50035f9931394ed4 PROGBITS
>> 0000000000000000 000bda 000011 00   E  0   0  1
>>  [15] .gnu.offload_lto_.decls.50035f9931394ed4 PROGBITS
>> 0000000000000000 000beb 00043d 00   E  0   0  1
>>  [16] .gnu.offload_lto_.symtab.50035f9931394ed4 PROGBITS
>> 0000000000000000 001028 000000 00   E  0   0  1
>>  [17] .gnu.offload_lto_.opts PROGBITS        0000000000000000 001028
>> 0000a9 00   E  0   0  1
>>
>> Don't you need another plugin to claim those offload IR sections?
>
> No, the plan was that a regular plugin will just ignore offload IR sections by default.  In your configuration ld detects a __gnu_lto_slim symbol and decided that the object file contains only LTO IR without asm.  I am going to investigate where is the difference with my configuration and fix the bug.
>

You may need to install the current binutils to see it.

-- 
H.J.

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[David Edelsohn]

Kirill,

The patches have broken bootstrap on AIX and probably on other non-GNU
platforms.  strchrnul() is a GNU extension.

/nasfarm/edelsohn/src/src/gcc/lto-wrapper.c: In function 'unsigned int
parse_env_var(const char*, char***, const char*)':
/nasfarm/edelsohn/src/src/gcc/lto-wrapper.c:427:35: error: 'strchrnul'
was not declared in this scope
   nextval = strchrnul (curval, ':');
                                   ^
/nasfarm/edelsohn/src/src/gcc/lto-wrapper.c: In function 'void
append_offload_options(obstack*, const char*, cl_decoded_option*,
unsigned int)':
/nasfarm/edelsohn/src/src/gcc/lto-wrapper.c:584:34: error: 'strchrnul'
was not declared in this scope
        next = strchrnul (cur, ',');

/nasfarm/edelsohn/src/src/gcc/gcc.c: In function 'void
handle_foffload_option(const char*)':
/nasfarm/edelsohn/src/src/gcc/gcc.c:3378:28: error: 'strchrnul' was
not declared in this scope
   end = strchrnul (arg, '=');
                            ^
Thanks, David


On Thu, Nov 13, 2014 at 9:14 AM, Kirill Yukhin <kirill.yukhin@gmail.com> wrote:
> Hello,
>
> Support of OpenMP 4.0 offloading to future Xeon Phi was fully checked in to main
> trunk.
>
> Thanks everybody who helped w/ development and review.
>
> --
> Thanks, K

Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC

[Gerald Pfeifer]

On Thursday 2014-11-13 12:41, David Edelsohn wrote:
> The patches have broken bootstrap on AIX and probably on other non-GNU
> platforms.  strchrnul() is a GNU extension.

Yep, FreeBSD 8 is broken as well.

The failure rate of my nightly testers over the last two weeks
must be around 50%.

Gerald