[Bug middle-end/93576] [8/9/10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7276dd4c7480dd952f0d4a9322ca04ca29f5126f commit r9-8227-g7276dd4c7480dd952f0d4a9322ca04ca29f5126f Author: Jakub Jelinek Date: Thu Feb 13 21:00:09 2020 +0100 c: Fix ICE with cast to VLA [93576] The following testcase ICEs, because the PR84305 changes try to evaluate the size earlier. If size has side-effects, that is desirable, and the side-effects will actually be wrapped in a SAVE_EXPR. The problem on this testcase is that there are no side-effects, and c_fully_fold doesn't fold those COMPOUND_EXPRs to constant, and while before gimplification we unshare trees found in the expressions, the unsharing doesn't involve TYPE_SIZE etc. of used types. Gimplification is destructive though, so when we gimplify the two nested COMPOUND_EXPRs and then try to gimplify it the second time for the TYPE_SIZEs, we ICE. Now, we could use unshare_expr in what we push to *expr, SAVE_EXPRs and their operands in there aren't unshared, but I really don't see a point of evaluating expressions that don't have side-effects before, so instead this just pushes there expressions that do have side-effects. 2020-02-13 Jakub Jelinek PR c/93576 * c-decl.c (grokdeclarator): If this_size_varies, only push size into *expr if it has side effects. * gcc.dg/pr93576.c: New test.
[Bug middle-end/93576] [8/9/10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bacdd5e978dad84e9c547b0d5c7fed14b8d75157 commit r10-6625-gbacdd5e978dad84e9c547b0d5c7fed14b8d75157 Author: Jakub Jelinek Date: Thu Feb 13 21:00:09 2020 +0100 c: Fix ICE with cast to VLA [93576] The following testcase ICEs, because the PR84305 changes try to evaluate the size earlier. If size has side-effects, that is desirable, and the side-effects will actually be wrapped in a SAVE_EXPR. The problem on this testcase is that there are no side-effects, and c_fully_fold doesn't fold those COMPOUND_EXPRs to constant, and while before gimplification we unshare trees found in the expressions, the unsharing doesn't involve TYPE_SIZE etc. of used types. Gimplification is destructive though, so when we gimplify the two nested COMPOUND_EXPRs and then try to gimplify it the second time for the TYPE_SIZEs, we ICE. Now, we could use unshare_expr in what we push to *expr, SAVE_EXPRs and their operands in there aren't unshared, but I really don't see a point of evaluating expressions that don't have side-effects before, so instead this just pushes there expressions that do have side-effects. 2020-02-13 Jakub Jelinek PR c/93576 * c-decl.c (grokdeclarator): If this_size_varies, only push size into *expr if it has side effects. * gcc.dg/pr93576.c: New test.
[Bug middle-end/93576] [8/9/10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 47836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47836=edit gcc10-pr93576.patch Untested fix.
[Bug middle-end/93576] [8/9/10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576
Jakub Jelinek changed:
What|Removed |Added
Keywords|error-recovery, |ice-on-valid-code
|ice-on-invalid-code |
Priority|P3 |P2
CC||jakub at gcc dot gnu.org
Target Milestone|10.0|8.4
Summary|[10 Regression] internal|[8/9/10 Regression]
|compiler error: |internal compiler error:
|Segmentation fault (in |Segmentation fault (in
|gimplify.c) |gimplify.c)
--- Comment #7 from Jakub Jelinek ---
Started with r8-6733-gd74641bdd752306ad41b4cd3b2f747ec046cb391
Reduced testcase:
void
foo (void)
{
int b[] = { 0 };
(char (*)[(1, 7, 2)]) 0;
}
