[Bug testsuite/64605] [5 Regression] ERROR: (DejaGnu) proc "libatomic_target_compile lto1738.c lto1738.o object additional_flags=-flto" does not exist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64605
Ilya Verbin changed:
What|Removed |Added
CC||iverbin at gmail dot com
--- Comment #1 from Ilya Verbin ---
This issue can be fixed by loading gcc-dg.exp after the definition of
libatomic_target_compile:
diff --git a/libatomic/testsuite/lib/libatomic.exp
b/libatomic/testsuite/lib/libatomic.exp
index 28cbaa8..07a5543 100644
--- a/libatomic/testsuite/lib/libatomic.exp
+++ b/libatomic/testsuite/lib/libatomic.exp
@@ -40,7 +40,6 @@ load_gcc_lib torture-options.exp
load_gcc_lib timeout.exp
load_gcc_lib timeout-dg.exp
load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
set dg-do-what-default run
@@ -219,3 +218,5 @@ proc libatomic_option_proc { option } {
return 0
}
}
+
+load_gcc_lib gcc-dg.exp
[Bug other/63979] [openacc] undefined reference to main._omp_fn.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63979 --- Comment #9 from Ilya Verbin --- (In reply to vries from comment #8) > (In reply to Ilya Verbin from comment #5) > > (In reply to vries from comment #4) > > > But I think the main difference is that the offload table and main (using > > > the offload table) are now in the same partition. I don't know whether > > > that's by design or accident. > > What do you mean by "main (using the offload table)"? > It's used like this, in main: > movl$__OFFLOAD_TABLE__, %esi Ah, I see, this is something OpenACC specific, for some reason it passes __OFFLOAD_TABLE__ to all functions. Anyway, this is just a weak symbol, which points to the start of the offload table. It's defined by mkoffload when all partitions are ready. I don't think that it could somehow affect the LTO partitioning and the functions' visibility.
[Bug other/63979] [openacc] undefined reference to main._omp_fn.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63979 --- Comment #5 from Ilya Verbin --- (In reply to vries from comment #4) > But I think the main difference is that the offload table and main (using > the offload table) are now in the same partition. I don't know whether > that's by design or accident. What do you mean by "main (using the offload table)"? The design was to have the offload table in the first partition (number zero), and the table should be used only in libgomp through the GOMP_offload_register function.
[Bug other/63979] [openacc] undefined reference to main._omp_fn.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63979 --- Comment #2 from Ilya Verbin --- I tried to reproduce this issue using trunk gcc and OpenMP: gcc -fopenmp -flto -flto-partition=balanced -lgfortran -save-temps libgomp/testsuite/libgomp.fortran/target2.f90 But all functions are privatized, e.g. __target2_MOD_foo._omp_fn.3.lto_priv.5, it's exported as global hidden in partition 1, and referenced in the offload table in partition 0 as it was planned. We should figure out why in your case main._omp_fn.19 and main._omp_fn.20 were not marked as global...
[Bug libgomp/63868] [5 Regression] Multiple failures in the libgomp test suite between r217458 and r217501.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63868 --- Comment #4 from Ilya Verbin --- It seems that support of offload sections in Mach-O will require substantial changes to gcc/config/darwin.c, like it was done for LTO. I'm going to disable the generation of any offload sections when a compiler is configured without --enable-offload-targets, i.e. when ENABLE_OFFLOADING is not defined. Is this change ok?
[Bug libgomp/63868] [5 Regression] Multiple failures in the libgomp test suite between r217458 and r217501.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63868 Ilya Verbin changed: What|Removed |Added CC||iverbin at gmail dot com --- Comment #3 from Ilya Verbin --- (In reply to Dominique d'Humieres from comment #2) > > Perhaps we should just disable all offloading for Darwin, at least unless > > some Darwin maintainer steps up and adds the needed support for that. > > Well, this won't solve the failures on linux! Failures on linux ( https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00309.html ) are caused by another issue (not by errors during assembling), I'm investigating them. I agree to disable generation of offload IR sections temporary for darwin.
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #15 from Ilya Verbin --- (In reply to Dominique d'Humieres from comment #14) > Thanks for the commit. Any plan to take into account the Jakub's remarks in > comment 11? Yes, I added them to my TODO list.
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #5 from Ilya Verbin --- So, I'll implement strchrnul in libiberty, ok?
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 Ilya Verbin changed: What|Removed |Added CC||iverbin at gmail dot com --- Comment #1 from Ilya Verbin --- Oops, I removed strchrnul from mkoffload, but it remains in lto-wrapper. I will fix it.
[Bug fortran/62107] libgomp.fortran/target2.f90 error while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107 --- Comment #4 from Ilya Verbin --- Great! Now all fortran tests pass with separate memory.
[Bug fortran/62107] libgomp.fortran/target2.f90 error while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107 Ilya Verbin changed: What|Removed |Added CC||iverbin at gmail dot com --- Comment #2 from Ilya Verbin --- This patch causes internal compiler errors on target2.f90 and target3.f90: libgomp/testsuite/libgomp.fortran/target2.f90: In function ‘foo’: libgomp/testsuite/libgomp.fortran/target2.f90:11:0: error: incorrect sharing of tree nodes *f.659 #pragma omp target map(to:MEM[(c_char *)D.5393] [len: D.5392]) map(alloc:d [pointer assign, bias: D.5398]) map(to:*n.562 [len: 4]) map(alloc:n [pointer assign, bias: 0]) map(tofrom:r [len: 4]) map(tofrom:*(c_char *) k.data [len: D.5825]) map(to:k [pointer set, len: 48]) map(alloc:(integer(kind=4)[0:] *) k.data [pointer assign, bias: 0]) map(tofrom:*j [len: 4]) map(alloc:j [pointer assign, bias: 0]) map(tofrom:ubound.12 [len: 8]) map(tofrom:*i [len: D.3148]) map(alloc:i [pointer assign, bias: 0]) map(tofrom:h [len: 4]) map(tofrom:offset.10 [len: 8]) map(tofrom:stride.9 [len: 8]) map(tofrom:ubound.8 [len: 8]) map(tofrom:stride.7 [len: 8]) map(tofrom:ubound.6 [len: 8]) map(tofrom:*e.0 [len: D.3155]) map(alloc:e.0 [pointer assign, bias: 0]) map(tofrom:offset.4 [len: 8]) map(tofrom:stride.3 [len: 8]) map(tofrom:ubound.2 [len: 8]) map(tofrom:*c.0 [len: D.3159]) map(alloc:c.0 [pointer assign, bias: 0]) map(tofrom:ubound.0 [len: 8]) map(tofrom:*(c_char *) g.633->data [len: D.5813]) map(to:*g.633 [pointer set, len: 48]) map(alloc:(integer(kind=4)[0:] *) g.633->data [pointer assign, bias: 0]) map(alloc:g [pointer assign, bias: 0]) map(tofrom:**f.659 [len: 4]) map(alloc:*f.659 [pointer assign, bias: 0]) map(alloc:f [pointer assign, bias: 0]) map(tofrom:*b [len: D.3162]) map(alloc:b [pointer assign, bias: 0]) map(tofrom:*a [len: 4]) map(alloc:a [pointer assign, bias: 0]) [child fn: __target2_MOD_foo._omp_fn.4] libgomp/testsuite/libgomp.fortran/target2.f90:11:0: internal compiler error: verify_gimple failed 0xa79975 verify_gimple_in_cfg(function*, bool) ../../gcc/tree-cfg.c:4994 0x97fec1 execute_function_todo ../../gcc/passes.c:1749 0x981383 execute_todo ../../gcc/passes.c:1806
[Bug middle-end/62092] libgomp.c++/target-2.C FAIL while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62092 --- Comment #2 from Ilya Verbin --- Yes, this fixes the issue. Thank you.
[Bug other/62092] New: libgomp.c++/target-2.C FAIL while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62092
Bug ID: 62092
Summary: libgomp.c++/target-2.C FAIL while compiling for OpenMP
4.0 offload target
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: iverbin at gmail dot com
To reproduce using trunk gcc:
g++ -fopenmp libgomp/testsuite/libgomp.c++/target-2.C
testsuite/libgomp.c++/target-2-aux.cc
GIMPLE after ompexp phase:
double fn2(...)
{
br.21_76 = &b; /* Ok. */
.omp_data_arr.33.br = &br;
__builtin_GOMP_target (-1, _Z3fn2iRA1024_dRPd._omp_fn.0, &__OPENMP_TARGET__,
22, &.omp_data_arr.33, &.omp_data_sizes.34, &.omp_data_kinds.35);
}
_Z3fn2iRA1024_dRPd._omp_fn.0 (struct .omp_data_t.30 * .omp_data_i)
{
__builtin_GOMP_parallel (_Z3fn2iRA1024_dRPd._omp_fn.1, &.omp_data_o.32, 0,
0);
}
_Z3fn2iRA1024_dRPd._omp_fn.1 (struct .omp_data_s.31 * .omp_data_i)
{
br.22_22 = &b; /* Error: trying to use global var b. */
}
Reduced testcase is here: https://gcc.gnu.org/ml/gcc/2014-07/msg00076.html
