https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- >> --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- >> Does the committed patch fix the issue on Solaris? > > I'll see after tonight's bootstrap. The original one attached to the PR > fixed only a few of the failures: > > -FAIL: libgomp.c/../libgomp.c-c++-common/for-1.c execution test > > -FAIL: libgomp.c/../libgomp.c-c++-common/for-2.c execution test > > -FAIL: libgomp.c/../libgomp.c-c++-common/for-7.c execution test > -FAIL: libgomp.c/../libgomp.c-c++-common/for-8.c execution test The committed version is the same: quite a number of the previous failures remain. E.g. even with OMP_NUM_THREADS=8, for-3.c starts a large number of threads (200+), then hangs under gdb, but if I let it run directly, it SEGVs again and the core dump shows the same unaligned access (with dbx, gdb cannot interpret the core dump): t@198 (l@198) terminated by signal SEGV (no mapping at the fault address) 0xfe5d7fb8: gomp_loop_ull_guided_start+0x01a8: movaps %xmm0,0x00000010(%esi) (dbx) print $esi $esi = 134981864
