https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #28 from Xi Ruoyao ---
Created attachment 41028
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41028&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #27 from Xi Ruoyao ---
Created attachment 41027
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41027&action=edit
patch proposal
Now I've prepared a patch. It reverted r227423 (but preserved its testcase)
and used a more confor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #26 from Xi Ruoyao ---
Reverting r227423 makes both Florent's and NumericMonoid code work. But it
reintroduced pr60586. Trying to solve it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #25 from Xi Ruoyao ---
I confirmed that r227423 broke NumericMonoid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #24 from Xi Ruoyao ---
The cilkplus spec described an "unsymmetrical" construct/destruct of temp
variables. It seems difficult to implement in GCC. I'm trying to find a
solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #23 from Xi Ruoyao ---
Sorry. I was too tired so I misunderstood r227423.
Now I am not sure whether it introduced the bug. I'll test it with
NumericMonoid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #22 from Xi Ruoyao ---
PR 60586 is a false PR to an expected behaviour... Unfortunately nobody
noticed that and someone "fixed" it.
But without r227423 GCC just ICE on the testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #21 from Xi Ruoyao ---
Start from r227423.
Fix spawned function with lambda function
Make sure that the spawned function's arguments will not be pushed
into lambda function.
gcc/c-family/
2015-09-02 Balaji V. Iyer
PR m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #20 from Xi Ruoyao ---
On 2017-03-16 12:31 +, cont...@edgar-fournival.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
>
> --- Comment #19 from Edgar Fournival ---
> Thanks for your explanations. I will investigate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #19 from Edgar Fournival ---
Thanks for your explanations. I will investigate on my side and check the
generated assembly of our project. Please keep us posted with the results of
your bisection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #18 from Xi Ruoyao ---
> Compile with '-fcilkplus -S'. According to cilkplus spec, x() should be
> evaluated in the child (for the asm produced by GCC, in _cilk_spn_0).
> If you find "call x" in the asm of "z" instead of "_cilk_spn_0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #17 from Xi Ruoyao ---
A simple test case for bisecting:
extern "C" {
int x();
int y(int);
int z();
}
int z()
{
int ret = _Cilk_spawn y(x());
return ret;
}
Compile with '-fcilkplus -S'. According to cilkplus spec, x() should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #16 from Xi Ruoyao ---
On 2017-03-16 10:16 +, cont...@edgar-fournival.fr wrote:
> Bisection?
I am bisecting now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #15 from Edgar Fournival ---
(In reply to Xi Ruoyao from comment #14)
> Although I don't understand all the code in the Github repo, but GCC 6 indeed
> moved the temporary construction (initialization) and destruction code to the
> pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #14 from Xi Ruoyao ---
(In reply to Florent Hivert from comment #13)
> I've not yet been able to find a small example that shows the regression due
> to GCC5 ICE. In particular, I'm not sure the problem mentioned by Fournival
> is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #13 from Florent Hivert ---
I've not yet been able to find a small example that shows the regression due to
GCC5 ICE. In particular, I'm not sure the problem mentioned by Fournival is not
due to a bug in my code (See my question of
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #12 from Xi Ruoyao ---
(In reply to Edgar Fournival from comment #11)
> It is also interesting to note that GCC 5.x is not impacted.
>
> Even if the given example code will not compile on GCC 5 (ICE in lower_stmt,
> at gimple-low.c:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #11 from Edgar Fournival ---
It is also interesting to note that GCC 5.x is not impacted.
Even if the given example code will not compile on GCC 5 (ICE in lower_stmt, at
gimple-low.c:397 for the line "cilk_spawn walk(vnew, size);"),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #10 from Xi Ruoyao ---
(In reply to Richard Biener from comment #3)
> which means the spawned copies use a shared vnew and a single destructor
> is run "afterwards". If there's no synchronization then all threads will
> call the dest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
Xi Ruoyao changed:
What|Removed |Added
CC||ryxi at stu dot xidian.edu.cn
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #8 from Jeffrey A. Law ---
It's unfortunate and directly related to the maintenance effort involved.
The deprecation plan for Cilk+ would have code in gcc-7, but the code would be
removed prior to the gcc-8 release. Unless someone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #7 from Florent Hivert ---
(In reply to Jeffrey A. Law from comment #6)
> Also note it is likely Cilk+ will be deprecated in gcc-7
That's a huge pity from my point of view. For recursive exploration like the
code I put here, I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #5 from Florent Hivert ---
(In reply to Richard Biener from comment #3)
> Don't know Cilk+ but yes, try
>
>for (int i=0; i<8; i++) {
> std::vector vnew(v);
> vnew.push_back(i);
> cilk_spawn walk(vnew, size);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #4 from Richard Biener ---
It might be that GCC is in error and that the ctor/dtor need to be arranged to
run per thread. Who knows...
You might want to check a competing Cilk+ implementation for this (I think the
Intel compiler has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #3 from Richard Biener ---
Don't know Cilk+ but yes, try
for (int i=0; i<8; i++) {
std::vector vnew(v);
vnew.push_back(i);
cilk_spawn walk(vnew, size);
cilk_sync;
}
with appropriate syntax.
We expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #2 from Florent Hivert ---
Thanks for your quick answer ! I'm not sure to understand what you mean by
"Thus insert a blocking primitive?" Do you suggest to add a cilk_sync somewhere
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
28 matches
Mail list logo
