Re: [CilkPlus] fix issues when cilk_spawn is used with nontrivial expressions

2016-01-07 Thread Jeff Law
On 01/06/2016 01:11 PM, Ryan Burn wrote: I could additionally check that the language is c++ before checking those flags, but I'm not sure I see a way around using them. For c++, the cilk_spawn expression can be nested within implicit conversion operators or constructors as in this case: str

Re: [CilkPlus] fix issues when cilk_spawn is used with nontrivial expressions

2016-01-06 Thread Mike Stump
On Jan 6, 2016, at 12:11 PM, Ryan Burn wrote: > I could additionally check that the language is c++ before checking > those flags, Please, no. Objective-C++ isn’t C++ and the string that names the language won’t strcmp with the name of the C++ language.

Re: [CilkPlus] fix issues when cilk_spawn is used with nontrivial expressions

2016-01-06 Thread Ryan Burn
On Tue, Jan 5, 2016 at 2:35 PM, Jeff Law wrote: > On 12/25/2015 09:08 AM, Ryan Burn wrote: >> >> This patch fixes issues with cilk_spawn where bad diagnostics are >> emitted for expressions invoking conversion operators or constructor >> calls (PR69024, PR68997). >> >> It also fixes an issue with

Re: [CilkPlus] fix issues when cilk_spawn is used with nontrivial expressions

2016-01-05 Thread Jeff Law
On 12/25/2015 09:08 AM, Ryan Burn wrote: This patch fixes issues with cilk_spawn where bad diagnostics are emitted for expressions invoking conversion operators or constructor calls (PR69024, PR68997). It also fixes an issue with a missing CLEANUP_POINT_EXPR that causes an ICE when gimplifying c

[CilkPlus] fix issues when cilk_spawn is used with nontrivial expressions

2015-12-25 Thread Ryan Burn
This patch fixes issues with cilk_spawn where bad diagnostics are emitted for expressions invoking conversion operators or constructor calls (PR69024, PR68997). It also fixes an issue with a missing CLEANUP_POINT_EXPR that causes an ICE when gimplifying code containing a temporary with a destructo