https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #34 from Ajit Kumar Agarwal ---
Sent the patch for review.
Here is the patch:
PATCH] rs6000: Stackoverflow in optimized code on PPC (PR100799)
When using FlexiBLAS with OpenBLAS we noticed corruption of
the parameters passed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #33 from Ajit Kumar Agarwal ---
Sent the patch for review.
Here is the patch:
PATCH] rs6000: Stackoverflow in optimized code on PPC (PR100799)
When using FlexiBLAS with OpenBLAS we noticed corruption of
the parameters passed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
CC||aagarwa at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #31 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #30)
> Either tree parmdef = ssa_default_def (cfun, parm) is NULL, or has_zero_uses
> (parmdef).
> Not sure if has_zero_uses will work properly after some bbs are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #30 from Jakub Jelinek ---
Either tree parmdef = ssa_default_def (cfun, parm) is NULL, or has_zero_uses
(parmdef).
Not sure if has_zero_uses will work properly after some bbs are converted from
GIMPLE to RTL, but maybe it will, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #29 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #28)
> Yes, so it is the backend that told function.cc that there is a parameter
> save area and it should be adding REG_EQUIV notes. So, the idea would be
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #28 from Jakub Jelinek ---
(In reply to Peter Bergner from comment #27)
> So I looked closer at what the failure mode was in this PR (versus the one
> you're seeing with flexiblas). As in your case, there is a mismatch in the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #27 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #26)
> But I still think the workaround is possible on the callee side.
> Sure, if the DECL_HIDDEN_STRING_LENGTH argument(s) is(are) used in the
> function, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #26 from Jakub Jelinek ---
(In reply to Peter Bergner from comment #25)
> CCing Mike and David for possible comments about the possible workarounds
> mentioned in Comment 23 and Comment 24.
Doing the workaround on the caller side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #24 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #23)
> if the PowerPC backend maintainers wanted, there could be a similar workaround
> on the rs6000 backend side, in the decisions whether the callee can use
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Surya Kumari Jangala changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #21 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #19 from Surya Kumari Jangala ---
There is a keyword called BIND(C) which can be specified on a Fortran procedure
to make it interoperable.
I tried this keyword on DGEBAL fortran routine which is a part of the openblas
library and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #18 from Surya Kumari Jangala ---
I git cloned and built flexiblas to see what is the frame size and what is the
assembly code generated for the flexiblas C wrapper routine for dgebal.
The important assembly code snippets for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #17 from Surya Kumari Jangala ---
I analysed the reduced test case specified in comment 15. In the .s file, the
callee decrements r1 by 224, ie, callee’s frame size is 224. But there is an
instruction in the callee that accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #16 from Segher Boessenkool ---
It cannot be -mcpu=power8, that cannot generate isel. -mcpu=power9 comes
closer, but I still do not see exactly the same output, and crucially not
the strange store either.
What the what.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #15 from Surya Kumari Jangala ---
(In reply to Segher Boessenkool from comment #14)
> What is the exact command line (and relevant configuration!) required to
> reproduce this?
The reduced testcase is:
SUBROUTINE DGEBAL(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #14 from Segher Boessenkool ---
What is the exact command line (and relevant configuration!) required to
reproduce this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #13 from Segher Boessenkool ---
(In reply to Alexander Grund from comment #11)
> Some more experiments with GCC 10.3, OpenBLAS 0.3.15 and FlexiBLAS 3.0.4:
>
> Baseline: Broken at -O1, working at -Og
>
> I got it to break with "-Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #12 from Segher Boessenkool ---
(In reply to Alexander Grund from comment #10)
> (In reply to Peter Bergner from comment #2)
> > The failure with GCC 7 and later coincides with the PPC port starting to
> > default to LRA instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #11 from Alexander Grund ---
Some more experiments with GCC 10.3, OpenBLAS 0.3.15 and FlexiBLAS 3.0.4:
Baseline: Broken at -O1, working at -Og
I got it to break with "-Og -fmove-loop-invariants".
Then it worked again by adding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #10 from Alexander Grund ---
(In reply to Peter Bergner from comment #2)
> The failure with GCC 7 and later coincides with the PPC port starting to
> default to LRA instead of reload.
Is there a compiler flag that can switch the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
Assignee|bergner at gcc dot gnu.org |jskumari at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #7 from Alexander Grund ---
Hi,
it's more than 1 year later now. Peter seemingly has a simple reproducer.
Is there anything new on this? Any patch to fix that or at least anything to
try or a workaround like disabling a specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #6 from Kenneth Hoste ---
(In reply to Segher Boessenkool from comment #3)
> Hi Alexander,
>
> You do not say what the actual target you used is? powerpc-linux,
> powerpc64-linux, powerpc64le-linux, something else entirely?
We're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #5 from Peter Bergner ---
So I took dgebal.f and ran delta on it to try and reduce it to something
manageable (I wish creduce worked on fortran files!) and got the following
which still shows us accessing above the stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Alan Modra changed:
What|Removed |Added
Target|powerpc |powerpc64le
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #3 from Segher Boessenkool ---
Hi Alexander,
You do not say what the actual target you used is? powerpc-linux,
powerpc64-linux, powerpc64le-linux, something else entirely?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #1 from Alexander Grund ---
Confirmed to also break with GCC 7.3, 8.2, 8.3 but works with 6.3, 6.4, 6.5
34 matches
Mail list logo
