On Mon, Jun 22, 2015 at 08:55:03 -0500, JohnT wrote:
> I am wondering why it appears that GCC has started drastically raising its
> major version number for minor changes, instead of spending several years
> on version 3 and 4. 4.0.1, 4.1.1 and 4.12, 4.2.3, 4.3.2, 4.4.5, up through
> 4.7.0, 4.7.1,
2016-04-21 7:09 GMT+03:00 Hal Ashburner :
> Another cilk plus question:
> Is op_ostream also considered to be outside of cilk plus?
> https://www.cilkplus.org/docs/doxygen/include-dir/group___reducers_ostream.html
> I am trying to compile the basic "Cilk Plus Tutorial Sources" code as
> supplied at
On Fri, Jun 10, 2016 at 11:31:33 +0200, Jakub Jelinek wrote:
> On Fri, Jun 10, 2016 at 09:39:02AM +0200, Thomas Schwinge wrote:
> > But I'm actually confused as to seeing libgomp.so in that list -- given
> > the conflict of which compiler installations' libgomp.so "wins", I wonder
> > how it can be
Hi Jakub,
I discovered an issue related to global variables.
In this testcase the 'omp target' child fn uses the local copy of glob_var.
But the 'omp parallel' child fn tries to use the glob_var directly and therefore
crashes.
int glob_var;
void
foo (void)
{
glob_var = 1;
#pragma omp target
2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
>> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
>
> What is the benefit of making this an environment variable that the user
> set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
> somewhere inside the GCC installation directory ([...]/l
Hi,
I've created a wiki page about offloading. Any improvements are welcome.
https://gcc.gnu.org/wiki/Offloading
Thanks,
-- Ilya
2014-08-21 11:39 GMT+04:00 Dominik Vogt :
> One can define mode iterators for
>
> (define_mode_iterator ITER1 [DI SI HI])
> (define_mode_iterator ITER2 [SI HI QI])
>
> Is it possible to write something like this:
>
> (define_insn "foo"
> [(set (match_operand:ITER1 0 ...)
> ...
>
Yeah, I got that all these prefixes are not working with modified
DESTDIR. I’ll fix mkoffload.
2014-09-17 20:30 GMT+04:00 Bernd Schmidt :
> That's also a solved problem in nvptx mkoffload - you do need to unset these
> environment variables when invoking the target compiler. I've posted the
> sou
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, erro
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?
Tha
On 13 Nov 2014, at 23:11, H.J. Lu wrote:
>
> Section Headers:
> [Nr] Name TypeAddress OffSize
> ES Flg Lk Inf Al
> [ 0] NULL 00
> 00 00 0 0 0
> [ 1] .text PROGBITS000
Hi,
This patch fixes recent regressions in libgomp testsuite:
https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00343.html
They are reproducible only with ld from trunk, ld 2.24 works fine.
When GCC emits sections with offload IR, it should not emit "__gnu_lto_slim"
symbol, otherwise linker plugin
Hi,
On Wed, Feb 11, 2015 at 21:33:47 -0800, Nicholas Yue wrote:
> I would like to find out if this is the correct forum to
> ask/discuss about GCC 5's OpenMP 4.0 implementation, in particular
> the new accelerator feature which from what I understand, allows the
> compute to be offloaded to ex
Hi All,
I've discovered a strange behaviour on trunk gcc, here is the reproducer:
inline int foo ()
{
return 0;
}
int main ()
{
return foo ();
}
$ gcc main.c
/tmp/ccD1LeXo.o: In function `main':
main.c:(.text+0xa): undefined reference to `foo'
collect2: error: ld returned 1 exit status
Is
Hi Jakub,
I have one more question :)
This testcase seems to be correct... or not?
#pragma omp declare target
extern int G;
#pragma omp end declare target
int G;
int main ()
{
#pragma omp target update to(G)
return 0;
}
If yes, then we have a problem that the decl of G in varpool_node::ge
On Tue, Mar 10, 2015 at 19:52:52 +0300, Ilya Verbin wrote:
> Hi Jakub,
>
> I have one more question :)
> This testcase seems to be correct... or not?
>
> #pragma omp declare target
> extern int G;
> #pragma omp end declare target
>
> int G;
>
> int main ()
On Thu, Mar 19, 2015 at 14:47:44 +0100, Jakub Jelinek wrote:
> Here is untested patch. I'm going to check it in after bootstrap/regtest.
Thanks.
> > I am investigating run-fails on some benchmark, and have found a second
> > questionable place, where a function argument overrides a global array.
On Thu, Mar 19, 2015 at 15:57:10 +0100, Jakub Jelinek wrote:
> On Thu, Mar 19, 2015 at 05:49:47PM +0300, Ilya Verbin wrote:
> > If I understand correctly, it's not allowed to map global target arrays this
> > way, since it's already present in the initial device data envir
Hi Hongtao,
I have left Intel 3 years ago. If you have any questions regarding MIC
offloading, you can reach me by iver...@gmail.com
Hongtao Liu :
> I don't konw this guy ilya.ver...@intel.com.
> Do you know him/her, H.J?
>
> --
> BR,
> Hongtao
|| Ilya
2017-02-03 16:00 GMT+03:00 Jakub Jelinek :
>
> On Fri, Feb 03, 2017 at 02:50:37PM +0200, Angel Dimitrov wrote:
> > Can I compile on Linux with gfortran code and to run it on Phi
> > co-processor? Or it is better to use Intel FORTRAN compiler?
>
> Depends on which XeonPhi do you have. GCC doesn't
gcc and ld for target, without
performing any LTO optimizations for host?
Suggestions?
----
Thanks,
Ilya Verbin,
Software Engineer
Intel Corporation
Jakub, Richard, Uday,
Thanks for your answers.
On 15 Aug 20:59, Richard Biener wrote:
> Alternatively you make lto-wrapper aware of this which means that WPA stage
> would emit extra partitions that it marks for lto-wrapper.
>
> That sounds better than another plugin to me. Of course WPA time m
On 23 Aug 13:17, Jakub Jelinek wrote:
> I don't think we should stream into more than one target section.
> There should be just .gnu.target_lto section (or whatever other suitable
> name) and should stream into it:
> 1) all functions and variables with "omp declare target" attribute
> 2) the outli
Hi Richard,
On 23 Aug 14:24, Richard Biener wrote:
> Ilya Verbin wrote:
> >I'm trying to implement the approach with modified lto-wrapper.
> >Suppose we have a bytecode of the routine foo, streamed during ompexp
> >pass into some section, say .gnu.omp
On 17 Sep 10:12, Richard Biener wrote:
> It looks more like a hack ;) It certainly doesn't look scalable to multiple
> target ISAs. You also unconditionally invoke the target compiler (well, you
> invoke the same compiler ...)
Yes, I currently call the "target" compiler unconditionally, but it c
On 18 Sep 10:38, Jakub Jelinek wrote:
> and what test5.c should print I have no idea (does ICC already support this
> and can you see what it prints?).
>
> test5.c:
> #include
> #include
>
> int
> main ()
> {
> omp_set_dynamic (0);
> omp_set_nested (1);
> #pragma omp parallel num_threads
On 17 Sep 14:12, Jakub Jelinek wrote:
> On Tue, Sep 17, 2013 at 01:56:39PM +0200, Richard Biener wrote:
> >
> > Are you sure we have the same IL for all targets and the same targets
> > for all functions? That would certainly simplify things, but you still need
> > a way to tell the target compil
Hi Jakub,
We have a MIC offload runtime library (liboffload), which is an abstraction over
COI. Currently it is a part of ICC, but there are plans of open sourcing it.
However, liboffload requires somewhat different tables comparing to what we have
agreed on. The liboffload tables serve to assoc
Hi Jakub,
I have 2 questions concerning OpenMP 4.0 specification.
1. Do I understand correctly that every "declare target" directive should be
closed with "end declare target"? E.g. in this example GCC marks both foo1 and
foo2 with "omp declare target" attribute:
#pragma omp declare target
in
2014/1/22 Jakub Jelinek :
> This can print 3 (if doing host fallback or device shares address space
> with host), or 2 (otherwise). It shouldn't print 1 ever, and yes,
> the target update is then well defined. All variables from omp declare
> target are allocated on the device sometime before
> t
One more question. Is it valid to use arr[MAX/2..MAX] on target?
#define MAX 20
void foo ()
{
int arr[MAX];
#pragma omp target map(from: arr[0:MAX/2])
{
int i;
for (i = 0; i < MAX; i++)
arr[i] = i;
}
}
In this case GOMP_target gets sizes[0]==40 as input. Due to t
Looks like there is a bug (in GOMP_target lowering? or in
gomp_map_vars_existing?)
The reproducer:
#define N 1000
void foo ()
{
int *a = malloc (N * sizeof (int));
printf ("1: %p\n", a);
#pragma omp target data map(tofrom: a[0:N])
{
printf ("2: %p\n", a);
#pragma omp target
{
2014-01-31 Jakub Jelinek :
> I'd suggest just using map(tofrom: a[0:N]) also on the #pragma omp target,
> then it is clear what should happen.
>
> Jakub
I agree that this will be clearer. But there is an example #49.1 in
the document [1] with the same case. And it crashes because the
poi
2014-01-31 22:03 GMT+04:00 Jakub Jelinek :
> Implicit map(tofrom: a) on #pragma omp target is what the standard
> requires, so I don't see a bug on the compiler side.
> Jakub
There is an exception in the standard (page 177, lines 17-21):
> If a corresponding list item of the original list
On 14 Feb 16:43, Jakub Jelinek wrote:
> So, perhaps we should just stop for now oring the copyfrom in and just use
> the copyfrom from the very first mapping only, and wait for what the committee
> actually agrees on.
>
> Jakub
Like this?
@@ -171,11 +171,16 @@ gomp_map_vars_existing (splay
Hi All,
I discovered a strange behavior of SPEC CPU2006 436.cactusADM
benchmark. It’s performance depends on the length of $LD_LIBRARY_PATH
variable.
The benchmark was compiled with "-O3 -funroll-loops -ffast-math
-march=core-avx2 -mtune=core-avx2" using gcc version 4.8.0 20130218.
I used Intel So
36 matches
Mail list logo
