[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 Andi Kleen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Andi Kleen --- Should be all fixed now in mainline.
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 --- Comment #11 from ak at gcc dot gnu.org --- Author: ak Date: Tue Nov 11 05:10:58 2014 New Revision: 217336 URL: https://gcc.gnu.org/viewcvs?rev=217336&root=gcc&view=rev Log: Error out for Cilk_spawn or array expression in forbidden places _Cilk_spawn or Cilk array expressions are only allowed on their own, but not in for(), if(), switch, do, while, goto, etc. The C parser didn't always check for that, which lead to ICEs earlier for invalid code. Add a generic helper that checks this and call it where needed in the C frontend. I chose to allow spawn/array for for init and increment expressions. While the Cilk spec could be interpreted to forbid it there too there didn't seem any reason to not allow it. One dark corner is spawn, array in statement expressions not at the end. Right now that's forbidden too. gcc/c-family/: 2014-11-10 Andi Kleen PR c/60804 * c-common.h (check_no_cilk): Declare. * cilk.c (get_error_location): New function. (check_no_cilk): Dito. gcc/c/: 2014-11-10 Andi Kleen PR c/60804 * c-parser.c (c_parser_statement_after_labels): Call check_no_cilk. (c_parser_if_statement): Dito. (c_parser_switch_statement): Dito. (c_parser_while_statement): Dito. (c_parser_do_statement): Dito. (c_parser_for_statement): Dito. * c-typeck.c (c_finish_loop): Dito. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/c-family/cilk.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-typeck.c
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804
--- Comment #10 from ak at gcc dot gnu.org ---
Reduced test case. It's probably invalid cilk, but gcc shouldn't ICE:
fn1() {
if (_Cilk_spawn func_2())
;
}
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 ak at gcc dot gnu.org changed: What|Removed |Added CC||ak at gcc dot gnu.org --- Comment #9 from ak at gcc dot gnu.org --- This still ICEs with gcc version 5.0.0 20140926 (experimental) (GCC)
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 --- Comment #8 from Andi Kleen --- I went through my collection of gimplify:8335 from the generator. Not all of them are special statements. So some more general check would be needed. Some examples: (*l_11) = (g_9 = _Cilk_spawn func_2(l_4)); (*g_682) = _Cilk_spawn func_2(g_5, (g_5 | ((safe_add_func_int32_t_s_s*g_682) = _Cilk_spawn func_8(g_5, _Cilk_spawn func_12(g_5), (l_2841 = l_2841))) != (g_3060 = l_3057)), (safe_mod_func_uint16_t_u_u(g_868.f0, g_2089.f3 && 1UL)) , l_3063) & g_88) | (*l_3057)) , l_3064)); l_1679 ^= _Cilk_spawn func_10safe_lshift_func_int8_t_s_u(*l_1669) ^= (0x4BAFC8D6799626DALL || (((~((*l_1668) = (safe_rshift_func_uint16_t_u_u(((g_3 == (safe_mul_func_int16_t_s_s((safe_rshift_func_uint16_t_u_s(g_3, 2)), ((safe_mul_func_uint8_t_u_u(_Cilk_spawn func_24(&g_3, ((*l_32) &= (safe_rshift_func_int8_t_s_s(g_7, g_6[8][1][3]))), _Cilk_spawn func_34(_Cilk_spawn func_37(((-1L) > (*l_2)), ((*l_925) = _Cilk_spawn func_43(g_6[7][3][2])), &g_198[1][1][7], l_2, (*l_2)), l_5[2][0][1]) && 0x43L) , g_317) ^ l_1665[0]) < g_604), l_2, l_5[4][8][2]), 1UL)) < 0xF63AL <= l_1667), (*l_2) | 2L) , 1L))) > (-1L)) | l_1671[0][4]), 2)) , 1UL) > 0x8FL), l_5[4][3][1], (*l_2)); l_3901 |= (safe_sub_func_int16_t_s_s(safe_div_func_uint64_t_u_u(_Cilk_spawn func_6(l_12[0][3], (safe_add_func_uint64_t_u_u(((safe_sub_func_int32_t_s_s(_Cilk_spawn func_17(g_20[0], (safe_lshift_func_int8_t_s_u(((_Cilk_spawn func_23(((safe_add_func_uint32_t_u_u(((l_12[0][3] | l_12[8][2]) , (((safe_mod_func_int32_t_s_s(_Cilk_spawn func_30(g_20[0], (0x6E31BB00L >= (l_34 & 0L)), (((safe_div_func_uint64_t_u_u(g_20[0], l_12[5][2])) , l_12[0][3]) , l_12[0][3])), l_2523)) , l_12[0][3]) , 0xFC5A8F50L)), l_2523)) < l_12[0][3]), (*g_1492)) > (-1L)) ^ (*g_1492)), l_2690))), l_2690)) | 0xBE8DAE3C6AAFCCBCLL), l_2523)), l_2523, l_12[8][3], l_2523), l_3900)) != (*g_1492)) && l_12[8][4]) , (**g_3267)), l_12[0][3])); (*g_20) = _Cilk_spawn func_2(g_7, l_8, ((*l_3296) = _Cilk_spawn func_9(g_7, ((**g_2525) = (((g_15 = g_7) | (safe_rshift_func_int16_t_s_u(_Cilk_spawn func_18(g_20), 7)) >= (safe_mod_func_int64_t_s_s((safe_mod_func_uint64_t_u_u(l_3288, ((*l_3296) &= ((l_3289 || (safe_mul_func_int16_t_s_s(safe_unary_minus_func_int8_t_s(**g_2282) ^= (&g_528[0][0][1] != l_3293)) , l_3294[3][1][1]) & (***l_3293 , (***g_243)) > (*g_2850)) > (*g_242)), l_3295))) > (***l_3293), (***l_3293 , l_3297) , 1L) > 0x65L)) ^ l_3298)), (*g_242), (***l_3293))), l_3324); (**g_388) = _Cilk_spawn func_8((_Cilk_spawn func_10((g_12 , g_13)) | ((0x439DL || 0L) ^ (((*l_1983) = g_5[g_4]) , (((~((safe_mul_func_uint16_t_u_u(g_5[g_4], g_1613.f6)) , (g_161.f1 , &g_291) == l_1986) , (*l_1983)) != (*l_1983)) || (*g_379 ^ l_1987) | l_1987);
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 --- Comment #7 from Jakub Jelinek --- But then it is not valid in many other places (for/while/do condition, etc.). Perhaps if _Cilk_spawn is allowed in the grammer only in 3 specific cases it might be better to disallow it everywhere and check for it only in the 3 listed cases (whole statement, var initializer and rhs of assignment (but for the last one it has to be only toplevel assignment I guess, a = b = _Cilk_spawn foo (); is presumably also invalid, ditto a + (b = _Cilk_spawn foo ()); etc.
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 --- Comment #6 from Marek Polacek --- The following should disallow this in the C FE. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 5653e49..cbbb272 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -5153,6 +5153,9 @@ c_parser_if_statement (c_parser *parser) /* If the if statement contains array notations, then we expand them. */ if (flag_cilkplus && contains_array_notation_expr (if_stmt)) if_stmt = fix_conditional_array_notations (if_stmt); + /* But Cilk_spawn in controlling expression is invalid. */ + if (flag_cilkplus && contains_cilk_spawn_stmt (cond)) +error_at (loc, "%<_Cilk_spawn%> in if statement is not permitted"); add_stmt (if_stmt); }
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 Stupachenko Evgeny changed: What|Removed |Added CC||evstupac at gmail dot com --- Comment #5 from Stupachenko Evgeny --- Yes it is not valid. Please find latest spec at: https://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 --- Comment #4 from Jakub Jelinek --- According to http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-win/index.htm as well as http://www.cilkplus.org/sites/default/files/open_specifications/cilk_plus_language_specification_0_9.pdf this isn't valid (but we should then diagnose it), but whether these two (and which one of them) are the latest Cilk+ spec is unclear to me.
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
int bar (void);
int
foo ()
{
if (_Cilk_spawn bar ())
return 5;
return 0;
}
Whether this is valid Cilk+ or not, no idea.
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 Andi Kleen changed: What|Removed |Added Attachment #32577|0 |1 is obsolete|| --- Comment #2 from Andi Kleen --- Created attachment 32580 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32580&action=edit this one still fails with current trunk
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-10 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Can't reproduce this, supposedly starting with r208382 when this is rejected as invalid use of _Cilk_spawn. So, do you have any testcases that ICE even with current trunk?
