https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #17 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Nov 6 11:48:06 2015
New Revision: 229843
URL: https://gcc.gnu.org/viewcvs?rev=229843&root=gcc&view=rev
Log:
Revert "Add IFN_GOACC_DATA_END_WITH_ARG"
2015-11-06 Tom de Vr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #15 from vries at gcc dot gnu.org ---
(In reply to vries from comment #3)
> [ There's a problem with the matching. The rs in "..rrr" were supposed to
> match the PTR_PTR_PTR arguments. But that's not the case, since we need to
> add a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #14 from vries at gcc dot gnu.org ---
Author: vries
Date: Thu May 28 14:18:19 2015
New Revision: 223832
URL: https://gcc.gnu.org/viewcvs?rev=223832&root=gcc&view=rev
Log:
Add IFN_GOACC_DATA_END_WITH_ARG
2015-05-28 Tom de Vries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #13 from vries at gcc dot gnu.org ---
(In reply to vries from comment #9)
> The GOACC_parallel is more tricky. I don't see what kind of fnspec for
> GOACC_parallel could fix this. The only other potential solution I see
> besides postp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #12 from vries at gcc dot gnu.org ---
Created attachment 35642
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35642&action=edit
Updated tentative patch
(In reply to Jakub Jelinek from comment #11)
> (In reply to vries from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #11 from Jakub Jelinek ---
(In reply to vries from comment #10)
> Created attachment 35639 [details]
> tentative patch for GOACC_data_end
That is a bad idea, as void GOACC_data_end (void) is already exported out of
libgomp, so this i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #10 from vries at gcc dot gnu.org ---
Created attachment 35639
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35639&action=edit
tentative patch for GOACC_data_end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #9 from vries at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> IMNSHO it is much better to accurately describe the builtins to the aliasing
> code etc. over adding ugly hacks like the tailcall one, or postponing
> e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #8 from Jakub Jelinek ---
IMNSHO it is much better to accurately describe the builtins to the aliasing
code etc. over adding ugly hacks like the tailcall one, or postponing expansion
till later etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 35636
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35636&action=edit
gcc/testsuite/c-c++-common/goacc/kernels-parallel-loop-data-enter-exit-2.c
(In reply to cesar from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #6 from cesar at gcc dot gnu.org ---
Isn't GOACC_parallel likely to have the same problem because hostaddrs may be
written to?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #5 from vries at gcc dot gnu.org ---
This patch fixes it, but it's a bit of a hack:
...
diff --git a/gcc/tree-tailcall.c b/gcc/tree-tailcall.c
index 013972d..0cb73a7 100644
--- a/gcc/tree-tailcall.c
+++ b/gcc/tree-tailcall.c
@@ -499,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #4 from vries at gcc dot gnu.org ---
When removing the fn spec from GOACC_data_start, we run into the problem that
this example doesn't get parallelized anymore:
...
#include
#define N (1024 * 512)
#define COUNTERTYPE unsigned int
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
15 matches
Mail list logo
