https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #20 from Dominik Vogt ---
(In reply to Eric Botcazou from comment #19)
> I think that the patch is simply incorrect and should be reverted, it very
> likely breaks other ports than PowerPC and SPARC and the failure more is
> quite nas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #19 from Eric Botcazou ---
> Another approach may be to make the middleend ask the backend for the actual
> value of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM). Since on Sparc
> the address is always 4 mod 8, we'd get an addi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #18 from Dominik Vogt ---
Another approach may be to make the middleend ask the backend for the actual
value of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM). Since on Sparc
the address is always 4 mod 8, we'd get an additional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #17 from Eric Botcazou ---
> In emit-rtl.c:init_emit(), the alignment of the virtual_stack_dynamic
> pointer is hard coded to STACK_BOUNDARY:
>
> REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY;
>
> The backen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #16 from Dominik Vogt ---
In emit-rtl.c:init_emit(), the alignment of the virtual_stack_dynamic pointer
is hard coded to STACK_BOUNDARY:
REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY;
The backend must make s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #14 from Dominik Vogt ---
Is the dynamic variable stack area properly aligned? Since sparc.h does not
define STACK_DYNAMIC_OFFSET it should be aligned to STACK_BONDARY, i.e. 64
bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #13 from Jakub Jelinek ---
Yes, sure, there are 2 alloca uses in the parallel region, one is for y
variable, which uses __builtin_alloca_with_align ((p4 - 1 + 1) * 4, 32) and the
other is for a, which uses __builtin_alloca_with_align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
rdapp at linux dot vnet.ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot vnet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #11 from Dominik Vogt ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> > 2) Replace "p7" in foo with just "7". If it still fails we know the bug is
> > not
> > triggered by the dynamic allocation of a or b.
>
> ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #10 from Rainer Orth ---
Created attachment 40141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40141&action=edit
reduced testcase and assembler output
I've managed at least some reduction of the testcase: as you can see, one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Dominik Vogt ---
> Some things to try with reduction-10.c:
>
> 1) Remove all OMP pragmas from the code. If it still fails it's not a
> limbgomp
> bug.
The failur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #8 from Dominik Vogt ---
Some things to try with reduction-10.c:
1) Remove all OMP pragmas from the code. If it still fails it's not a limbgomp
bug.
2) Replace "p7" in foo with just "7". If it still fails we know the bug is not
tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #7 from Dominik Vogt ---
The dumps show some differences I'd expect, but debugging libgomp testcases is
awkward because they are so complicated. In the pre-patched era, Gcc's dynamic
allocation on the stack was a bit too large most o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #6 from Rainer Orth ---
Created attachment 40116
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40116&action=edit
assembler output @ r242590
Assembler output with culprit patch applied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #5 from Rainer Orth ---
Created attachment 40115
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40115&action=edit
assembler output @ r242589
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #4 from Dominik Vogt ---
Could you provide assembly dumps of the function foo() in the testcase, both,
with and without the "culprit" patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #3 from Dominik Vogt ---
That very liekely means that libgomp has a buffer overflow in memory allocated
dynamically on the stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
Rainer Orth changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #1 from Jakub Jelinek ---
Can you please bisect it? Not aware of any recent changes that could cause
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |7.0
21 matches
Mail list logo
