https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #16 from Stefan Schulze Frielinghaus ---
Fixed in mainline. Fine for me to close this now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #15 from CVS Commits ---
The master branch has been updated by Stefan Schulze Frielinghaus
:
https://gcc.gnu.org/g:452db716d8debb6e09b85e4a0c0e73a047ed5c1d
commit r13-5964-g452db716d8debb6e09b85e4a0c0e73a047ed5c1d
Author: Stefan Sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #14 from Stefan Schulze Frielinghaus ---
I'm still working on this and currently test a new patch which should fix the
scheduler handling in the backend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #13 from Matthias Klose ---
this isn't seen anymore with current trunk. close as worksforme?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #12 from Stefan Schulze Frielinghaus ---
The culprit seems to be that s390_sched_init is not called in one particular
case. We have the following basic blocks and edges:
6 --> 12 --> 13 --> 14
The edges from 12 to 13 and 13 to 14 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #11 from Stefan Schulze Frielinghaus ---
Please find attached a reduced version of the initial problem. If compiled
with
g++ -O2 -march=arch13 -fno-exceptions (-g)
there is still a difference whether build with debug information o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #10 from Stefan Schulze Frielinghaus ---
Created attachment 54279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54279&action=edit
RTL dump of sched2 if compiled with debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #9 from Stefan Schulze Frielinghaus
---
Created attachment 54278
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54278&action=edit
RTL dump of sched2 if compiled without debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #8 from Stefan Schulze Frielinghaus
---
Created attachment 54277
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54277&action=edit
reduced version of the initial problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #7 from Stefan Schulze Frielinghaus
---
The difference in the assembly output shown in comment 2 happens in function
void
AssociatedImplTrait::setup_associated_types (
const TyTy::BaseType *self, const TyTy::TypeBoundPredicate &b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #6 from Stefan Schulze Frielinghaus
---
Created attachment 54154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54154&action=edit
preprocessed rust-hir-trait-resolve.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #5 from Andrew Pinski ---
(In reply to Stefan Schulze Frielinghaus from comment #4)
> and the current working directory was most likely /devel/gcc/build/gcc.
> Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #4 from Stefan Schulze Frielinghaus
---
I was playing around with this and was wondering how can I actually execute the
stageN compiler? From the output of make I see two compilations for object
rust-hir-trait-resolve.o. Thus the fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
15 matches
Mail list logo
