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

Reply via email to