https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Sun Feb 24 22:49:47 2019
New Revision: 269179
URL: https://gcc.gnu.org/viewcvs?rev=269179&root=gcc&view=rev
Log:
2019-02-24 Thomas Koenig
PR fortran/89174
* trans-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #10 from Thomas Koenig ---
This seems to work:
Index: trans-expr.c
===
--- trans-expr.c(Revision 269161)
+++ trans-expr.c(Arbeitskopie)
@@ -352,7 +352,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #9 from Thomas Koenig ---
FWITW, there is a difference when handling the MOLD expression
in gfc_find_and_cut_at_last_class_ref.
In the version that calls gfc_expr_to_initialize, we see
(gdb) call debug(base_expr)
push:this % mold (C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #8 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #7)
> This patch makes the test case work again:
This also introduces numerous regressions, so this is not recommended
as a fix :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #7 from Thomas Koenig ---
This patch makes the test case work again:
===
--- trans-expr.c(Revision 265171)
+++ trans-expr.c(Arbeitskopie)
@@ -394,7 +394,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #6 from Thomas Koenig ---
And on my AMD system, it does indeed pass with r265170. OK.
Looking at the diff of the tree dumps between the two versions,
the difference is
--- a.r265170 2019-02-24 10:56:39.138713129 +0100
+++ a.r26517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #5 from Thomas Koenig ---
The problem is with the subroutine, not with the call from
the main program.
If you split the module and main program into a separate file
and compile the modlue with r264951 (a random version which works)
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #4 from Thomas Koenig ---
Just tried out r265170 on powerpc64le (because that machine
boots faster :-), and the test case also segfaults.
Hmm...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #3 from Neil Carlson ---
r265171 is the commit that broke the 9.0 trunk; r265171 segfaults but r265170
works correctly. I haven't been able to pinpoint where this stuff was
back-ported to the 8 branch, but it definitely was. This exam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.3 |8.4
--- Comment #2 from Jakub Jelinek -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
12 matches
Mail list logo
