https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Tim Turner changed:
What|Removed |Added
CC||timturnerc at yahoo dot com
--- Comment #55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #54 from Tomas Kalibera ---
(In reply to Jakub Jelinek from comment #53)
> Backported to 7.x, please test it.
Thanks! I tested the default behavior with DPOSV and reference LAPACK, where it
worked fine. Also with all of CRAN+BIOC R p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #52 from Jakub Jelinek ---
Author: jakub
Date: Fri Aug 30 12:41:43 2019
New Revision: 275153
URL: https://gcc.gnu.org/viewcvs?rev=275153&root=gcc&view=rev
Log:
Backported from mainline
2019-05-29 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #51 from Jakub Jelinek ---
Yes, I just didn't have time for that yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #50 from Janne Blomqvist ---
Jakub, should your fix be backported to the gcc-7 branch as well, considering
that the PR 87689 fix was applied to that branch as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #49 from Jakub Jelinek ---
(In reply to Kaz Kylheku from comment #48)
> That's the thing I'm keenly curious about: if that value is fortuitously the
> right one, in the right place on the stack, where is the crash?
>
> (Of course, we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #48 from Kaz Kylheku ---
(In reply to Thomas Koenig from comment #47)
> I see two problems with this suggestion, one minor and one major.
>
> First, there may well be a value > 1 on the stack for a regular
> call, see comment #15.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #47 from Thomas Koenig ---
(In reply to Kaz Kylheku from comment #45)
> Hi everyone.
>
> Pardon my ignorance of C-Fortran bridging matters, but does any of the
> following make sense?
>
> The Fortran subroutine has no idea whether t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #46 from Kaz Kylheku ---
C pseudocode in light of previous comment:
double abused_fortran_fn(double x, double y, char str[1], int len)
{
if (len != 1)
return abused_fortran_fn(x, y, str, 1); /* full call, not tail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Kaz Kylheku changed:
What|Removed |Added
CC||kkylheku at gmail dot com
--- Comment #45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #44 from Jakub Jelinek ---
Workaround added for 8.4+, 9.2+ and 10.1+ so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #43 from Jakub Jelinek ---
Author: jakub
Date: Wed May 29 16:02:56 2019
New Revision: 271744
URL: https://gcc.gnu.org/viewcvs?rev=271744&root=gcc&view=rev
Log:
PR fortran/90329
* lto-streamer.h (LTO_minor_version): Bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #42 from Jakub Jelinek ---
Author: jakub
Date: Wed May 29 15:55:12 2019
New Revision: 271743
URL: https://gcc.gnu.org/viewcvs?rev=271743&root=gcc&view=rev
Log:
PR fortran/90329
* lto-streamer.h (LTO_minor_version): Bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #41 from Jakub Jelinek ---
Author: jakub
Date: Wed May 29 14:08:57 2019
New Revision: 271738
URL: https://gcc.gnu.org/viewcvs?rev=271738&root=gcc&view=rev
Log:
PR fortran/90329
* lang.opt (fbroken-callers): Remove.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #40 from Jakub Jelinek ---
I must say I don't like -fbroken-callers option name too much, can we use
instead something like -ftail-call-workaround={0,1,2} /
-f{,no-}tail-call-workaround
where -ftail-call-workaround == -ftail-call-work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #39 from Conrad S ---
> A better question might be: Are you going to fix your code?
Yes [1], but that's besides the point here. I can certainly fix my code, but
that leaves 99% of other software.
Backports to gcc 8.x and 9.x would b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #38 from Steve Kargl ---
On Wed, May 22, 2019 at 04:38:40AM +, conradsand.arma at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
>
> --- Comment #37 from Conrad S ---
> Thanks for the workaround.
> Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #37 from Conrad S ---
Thanks for the workaround.
Will the patches be backported to gcc 8.x and 9.x ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #36 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 08:22:41 2019
New Revision: 271376
URL: https://gcc.gnu.org/viewcvs?rev=271376&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/90329
* invoke.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #35 from Jakub Jelinek ---
One more thing, if I add to start of the DTRTRI function
INTERFACE
SUBROUTINE DTRTI2( UPLO, DIAG, N, A, LDA, INFO )
CHARACTER DIAG, UPLO
INTEGERINFO, LDA, N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #34 from Jakub Jelinek ---
Even the
subroutine foo (a, b, c, d, e, f)
integer :: c, e, f
character(len=1) :: a, b
double precision :: d (e, *)
call bar (a, b, c, d, e, f)
end subroutine foo
is tail call optimized by both older
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #33 from Jakub Jelinek ---
Author: jakub
Date: Thu May 16 09:37:43 2019
New Revision: 271285
URL: https://gcc.gnu.org/viewcvs?rev=271285&root=gcc&view=rev
Log:
PR fortran/90329
* tree-core.h (struct tree_decl_common):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #32 from Jakub Jelinek ---
BTW, as can be seen on https://fortran.godbolt.org/z/ckMt1t
it is a pure luck that these bogus C/C++ wrappers seem to work, if one tries
simple
subroutine foo (a, b, c, d, e, f, g, h)
integer :: b, c, d, e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #31 from Jakub Jelinek ---
(In reply to Thomas Koenig from comment #30)
> Hi Jakub,
>
> > Untested workaround that isn't a too big hammer. This should just avoid
> > tail calls in functions where the hidden string arguments for
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #30 from Thomas Koenig ---
Hi Jakub,
> Untested workaround that isn't a too big hammer. This should just avoid
> tail calls in functions where the hidden string arguments for
> character(len=constant) dummy arguments are passed part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #29 from Jakub Jelinek ---
Created attachment 46359
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46359&action=edit
gcc10-pr90329.patch
Untested workaround that isn't a too big hammer. This should just avoid tail
calls in fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Conrad S changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #27 from Jakub Jelinek ---
Note that both ifort and xlc fortran have the hidden string length arguments as
well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #26 from Jakub Jelinek ---
It could even allow tailcalls in the character(len=*) cases because in those
cases if the caller omits the string length hidden argument, I see no reason to
try to workaround that, it will simply never work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #24 from Thomas Koenig ---
Author: tkoenig
Date: Thu May 9 17:40:30 2019
New Revision: 271038
URL: https://gcc.gnu.org/viewcvs?rev=271038&root=gcc&view=rev
Log:
2019-05-09 Thomas Koenig
Backport from trunk
PR fortran/903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Thomas Koenig changed:
What|Removed |Added
See Also||https://github.com/Referenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #22 from Thomas Koenig ---
Author: tkoenig
Date: Wed May 8 21:55:13 2019
New Revision: 271018
URL: https://gcc.gnu.org/viewcvs?rev=271018&root=gcc&view=rev
Log:
2019-05-08 Thomas Koenig
PR fortran/90351
PR fortran/90329
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #21 from Janne Blomqvist ---
I filed https://github.com/Reference-LAPACK/lapack/issues/339 to start a
discussion about fixing CBLAS and LAPACKE in upstream LAPACK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #20 from Tomas Kalibera ---
(In reply to rguent...@suse.de from comment #19)
> I don't see how -fno-optimize-sibling-calls helps in a systematic way.
> It might obfuscate a specific example enough to make it work, but...?
There is o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #19 from rguenther at suse dot de ---
On Tue, 7 May 2019, jb at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
>
> --- Comment #18 from Janne Blomqvist ---
> (In reply to Thomas Koenig from comment #15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #18 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #15)
> Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9,
> I would suggest that we make -fno-optimize-sibling-calls
> the default on these branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #17 from Steve Kargl ---
On Mon, May 06, 2019 at 04:40:08PM +, kargl at gcc dot gnu.org wrote:
> > Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9,
> > I would suggest that we make -fno-optimize-sibling-calls
> > t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #15 from Thomas Koenig ---
Hi Tomas,
> I understand the compiler may not know and typically does not whether the
> called function accepts "character(len=1)" or "character(len=*)", so it may
> have to pass the 1. But the situation wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #14 from rguenther at suse dot de ---
On Mon, 6 May 2019, tomas.kalibera at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
>
> --- Comment #13 from Tomas Kalibera ---
> I understand the compiler may not k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #13 from Tomas Kalibera ---
I understand the compiler may not know and typically does not whether the
called function accepts "character(len=1)" or "character(len=*)", so it may
have to pass the 1. But the situation where I suggest no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #12 from Janne Blomqvist ---
(In reply to Tomas Kalibera from comment #11)
> At least in the case I debugged, I think gfortran could do better by not
> writing the 1 as string length to the place on the stack where the compiler
> know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #11 from Tomas Kalibera ---
Even restoring the state that LAPACK/BLAS works but without providing
guarantees would help short-term, and I think this could be in line with the
goal of best performance within the standard.
At least in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Richard Biener changed:
What|Removed |Added
Keywords||ABI
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #9 from Toon Moene ---
> So with this suggestion, this procedure would be generated without the hidden
> length argument. The brokenness comes from
> call foo("ab")
> which would generate a call to a procedure WITH the hidden strin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #8 from Janne Blomqvist ---
(In reply to Janne Blomqvist from comment #3)
> 1) When compiling an external procedure, for character(len=1) arguments we
> don't generate the hidden string length argument. And similarly when calling
> an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #7 from Paul Thomas ---
(In reply to Thomas Koenig from comment #6)
> (In reply to Janne Blomqvist from comment #5)
> > (In reply to Thomas Koenig from comment #4)
> > > Currently, I am leaning towards using an option with a mandatory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #6 from Thomas Koenig ---
(In reply to Janne Blomqvist from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Currently, I am leaning towards using an option with a mandatory
> > warning (no way to turn it off) which does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #5 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #4)
> (In reply to Janne Blomqvist from comment #3)
> > 1) When compiling an external procedure, for character(len=1) arguments we
> > don't generate the hidden strin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #4 from Thomas Koenig ---
(In reply to Janne Blomqvist from comment #3)
> Ooof!
>
> (Just for the record, I don't think we should revert to the previous
> behavior. Whatever we do should be robust in the face of LTO etc.)
I concur.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Thomas Koenig changed:
What|Removed |Added
CC||toon at moene dot org
--- Comment #1 fro
56 matches
Mail list logo
