[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Macleod --- Yeah, we aren't expecting the parameter and the LHS to be different. Why do we mark this as a builtin function if it doesn't match the parameter list? Regardless, when folding the call we assumed the parameter type matches the LHS. This patch changes it so if the types do not match, we will assume nothing about the function instead.
[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:c86c95edd165d674614516cda0b1fcb6616c1096 commit r12-2826-gc86c95edd165d674614516cda0b1fcb6616c1096 Author: Andrew MacLeod Date: Mon Aug 9 15:53:42 2021 -0400 Ensure toupper and tolower follow the expected pattern. If the parameter is not compatible with the LHS, assume this is not really a builtin function to avoid a trap. gcc/ PR tree-optimization/101741 * gimple-range-fold.cc (fold_using_range::range_of_builtin_call): Check type of parameter for toupper/tolower. gcc/testsuite/ * gcc.dg/pr101741.c: New.
[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #4 from Martin Sebor --- I believe invalid in the keyword means strictly syntactically invalid, not undefined as a result of a semantic constraint (e.g., defining a standard function; GCC normally handles that gracefully).
[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741 --- Comment #3 from Martin Liška --- (In reply to Arseny Solokha from comment #2) > (In reply to Martin Liška from comment #1) > > why is the test-case marked as "invalid"? > > It is definitely well-formed syntactically, but I'm not sure how to classify > a case of redefining a standard function which has a builtin in gcc w/ a > function w/ different return type. Is there any guidance that I could refer > to in the future when telling valid testcases from invalid ones? Ah, that's the reason. I don't know what requirements do we have for such functions..
[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741 --- Comment #2 from Arseny Solokha --- (In reply to Martin Liška from comment #1) > why is the test-case marked as "invalid"? It is definitely well-formed syntactically, but I'm not sure how to classify a case of redefining a standard function which has a builtin in gcc w/ a function w/ different return type. Is there any guidance that I could refer to in the future when telling valid testcases from invalid ones?
[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741 Martin Liška changed: What|Removed |Added CC||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Summary|[12 Regression] ICE in |[12 Regression] ICE in |fold_stmt, at |fold_stmt, at |gimple-range-fold.cc:541|gimple-range-fold.cc:541 ||since ||r12-2517-g1ce0b26e6e1e6c34 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-03 --- Comment #1 from Martin Liška --- Confirmed. Btw. why is the test-case marked as "invalid"?
