public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL
@ 2014-02-07 15:34 ro at gcc dot gnu.org
2014-02-10 9:51 ` [Bug libgomp/60107] " rguenth at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: ro at gcc dot gnu.org @ 2014-02-07 15:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
Bug ID: 60107
Summary: libgomp.c/pr58392.c etc. FAIL
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Host: i386-pc-solaris2.9
Target: i386-pc-solaris2.9
Build: i386-pc-solaris2.9
3 libgomp tests FAIL on Solaris 9/x86 since they were introduced:
FAIL: libgomp.c/pr58392.c execution test
FAIL: libgomp.c/simd-6.c execution test
FAIL: libgomp.c++/simd-8.C execution test
For the first, I find
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2 (LWP 2)]
0x080509f1 in foo._omp_fn ()
at /vol/gcc/src/hg/trunk/local/libgomp/testsuite/libgomp.c/pr58392.c:20
20 c += d[j + l];
(gdb) x/i $pc
=> 0x80509f1 <foo._omp_fn.0+177>: paddd 0x10(%esp),%xmm0
(gdb) p $esp
$1 = (void *) 0xb5aedf64
truss shows
/2: Incurred fault #6, FLTBOUNDS %pc = 0x080509F1
/2: siginfo: SIGSEGV SEGV_MAPERR addr=0x080509F1
/2: Received signal #11, SIGSEGV [default]
/2: siginfo: SIGSEGV SEGV_MAPERR addr=0x080509F1
and <sys/fault.h> has
#define FLTBOUNDS 6 /* Memory bounds (invalid address) */
pmap reveals the following mappings:
08062000 12K rwx-- [ heap ]
B5AED000 4K rwx-R [ anon ]
B5AF0000 108K rw--- [ anon ]
Rainer
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
@ 2014-02-10 9:51 ` rguenth at gcc dot gnu.org
2014-02-10 9:57 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-02-10 9:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Does solaris "properly" align its stack on the entry of main?
0xb5aedf64 + 0x10 isn't aligned for paddd.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
2014-02-10 9:51 ` [Bug libgomp/60107] " rguenth at gcc dot gnu.org
@ 2014-02-10 9:57 ` jakub at gcc dot gnu.org
2014-02-11 11:32 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-02-10 9:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, this isn't about main alignment (and, after all, main realigns the stack
anyway), but about stack alignment upon entering pthread_create callbacks.
If the Solaris libraries don't maintain 16-byte stack alignment, then either
you could arrange to compile parts of libgomp with -mincoming-stack-boundary=2
(or -mstackrealign) on Solaris/i?86 32-bit. Or just make sure the default on
Solaris is -mincoming-stack-boundary=2 or whatever the libraries do guarantee.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
2014-02-10 9:51 ` [Bug libgomp/60107] " rguenth at gcc dot gnu.org
2014-02-10 9:57 ` jakub at gcc dot gnu.org
@ 2014-02-11 11:32 ` ro at CeBiTec dot Uni-Bielefeld.DE
2014-02-11 11:34 ` ro at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2014-02-11 11:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Well, this isn't about main alignment (and, after all, main realigns the stack
> anyway), but about stack alignment upon entering pthread_create callbacks.
> If the Solaris libraries don't maintain 16-byte stack alignment, then either
> you could arrange to compile parts of libgomp with -mincoming-stack-boundary=2
> (or -mstackrealign) on Solaris/i?86 32-bit. Or just make sure the default on
> Solaris is -mincoming-stack-boundary=2 or whatever the libraries do guarantee.
I've checked the Solaris 9 and OpenSolaris sources: on S9, there's just
the 4-byte alignment guaranteed by the i386 psABI. On S10 and up, they
enforce 16-byte alignment for the benefit of SSE.
IMO, the best (most general) solution is to change STACK_REALIGN_DEFAULT
to 1 on Solaris 9/x86. While it comes at a performance and code size
penalty, it's guaranteed to be correct.
I've bootstrapped a patch to do just that and as expected, the libgomp
failures are gone.
Unlike I'm overlooking something important, I'd like to check this patch
into mainline for 4.9.0.
Rainer
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
` (2 preceding siblings ...)
2014-02-11 11:32 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2014-02-11 11:34 ` ro at gcc dot gnu.org
2014-02-11 11:35 ` ro at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ro at gcc dot gnu.org @ 2014-02-11 11:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-02-11
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
` (3 preceding siblings ...)
2014-02-11 11:34 ` ro at gcc dot gnu.org
@ 2014-02-11 11:35 ` ro at gcc dot gnu.org
2014-02-11 11:42 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ro at gcc dot gnu.org @ 2014-02-11 11:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
--- Comment #4 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 32101
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32101&action=edit
proposed patch
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
` (4 preceding siblings ...)
2014-02-11 11:35 ` ro at gcc dot gnu.org
@ 2014-02-11 11:42 ` jakub at gcc dot gnu.org
2014-02-11 12:57 ` ro at gcc dot gnu.org
2014-02-11 12:58 ` ro at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-02-11 11:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>From RM POV this is ok for 4.9.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
` (5 preceding siblings ...)
2014-02-11 11:42 ` jakub at gcc dot gnu.org
@ 2014-02-11 12:57 ` ro at gcc dot gnu.org
2014-02-11 12:58 ` ro at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: ro at gcc dot gnu.org @ 2014-02-11 12:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
--- Comment #6 from Rainer Orth <ro at gcc dot gnu.org> ---
Author: ro
Date: Tue Feb 11 12:56:39 2014
New Revision: 207688
URL: http://gcc.gnu.org/viewcvs?rev=207688&root=gcc&view=rev
Log:
Only assume 4-byte stack alignment on Solaris 9/x86 (PR libgomp/60107)
PR libgomp/60107
* config/i386/sol2-9.h: New file.
* config.gcc (i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*,
*-*-solaris2.9*): Use it.
Added:
trunk/gcc/config/i386/sol2-9.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
` (6 preceding siblings ...)
2014-02-11 12:57 ` ro at gcc dot gnu.org
@ 2014-02-11 12:58 ` ro at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: ro at gcc dot gnu.org @ 2014-02-11 12:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org
--- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
Fixed for 4.9.0.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-02-11 12:58 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-07 15:34 [Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL ro at gcc dot gnu.org
2014-02-10 9:51 ` [Bug libgomp/60107] " rguenth at gcc dot gnu.org
2014-02-10 9:57 ` jakub at gcc dot gnu.org
2014-02-11 11:32 ` ro at CeBiTec dot Uni-Bielefeld.DE
2014-02-11 11:34 ` ro at gcc dot gnu.org
2014-02-11 11:35 ` ro at gcc dot gnu.org
2014-02-11 11:42 ` jakub at gcc dot gnu.org
2014-02-11 12:57 ` ro at gcc dot gnu.org
2014-02-11 12:58 ` ro at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).