https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121977
Bug ID: 121977
Summary: gomp/member-1.C ICE with -ftrivial-auto-var-init=zero
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
I'm working now on a patch for PR114457 which will kind of enable
-ftrivial-auto-var-init=zero for -std=c++26 by default.
I've run into ICE on g++.dg/gomp/member-1.C, which is also reproduceable on
vanilla trunk with
RUNTESTFLAGS="--target_board=unix\{,-ftrivial-auto-var-init=zero\}
gomp.exp=member-1.C"
FAIL: g++.dg/gomp/member-1.C -std=c++17 (internal compiler error: Segmentation
fault)
FAIL: g++.dg/gomp/member-1.C -std=c++17 (test for excess errors)
FAIL: g++.dg/gomp/member-1.C -std=c++98 (internal compiler error: Segmentation
fault)
FAIL: g++.dg/gomp/member-1.C -std=c++98 (test for excess errors)
FAIL: g++.dg/gomp/member-1.C -std=c++26 (internal compiler error: Segmentation
fault)
FAIL: g++.dg/gomp/member-1.C -std=c++26 (test for excess errors)
>From what I can see, the difference between
-ftrivial-auto-var-init=uninitialized and -ftrivial-auto-var-init=zero is that
i = .DEFERRED_INIT (4, 2, &"i"[0]);
stmt is added in the latter case to for_pre_body (and nothing otherwise), so
gimple_seq *for_pre_p = (gimple_seq_empty_p (for_pre_body)
? pre_p : &for_pre_body);
in the OMP_TASKLOOP handling then works differently too and in one case the
D.2893 = a;
stmt (where
int a [value-expr: ((struct S *) this)->a];
) is added to pre_p and therefore before the taskloop, while in the other case
it is added to gimple_omp_for_pre_body of the taskloop.
And in the latter case for some reason we ICE when trying to regimplify the
stmt
into D.2893 = ((struct S *) this)->a;
- this is mapped to NULL.
