https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Mon Nov 28 10:00:43 2016
New Revision: 242910
URL: https://gcc.gnu.org/viewcvs?rev=242910&root=gcc&view=rev
Log:
PR lto/78211
* ipa-icf.h (sem_item_optimizer): Add m_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
Jakub Jelinek changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
--- Comment #5 from Jakub Jelinek ---
Ah, I can reproduce even on current trunk with additional
-fno-printf-return-value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
--- Comment #4 from Jakub Jelinek ---
Note -fcompare-debug compares the -fdump-final-insns= dumps, those include RTL,
but not the LTO streams. So while it might not be very useful for -flto, there
is no inherent reason why it wouldn't work.
Of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
--- Comment #2 from Tobias Burnus ---
Hmm, good question whether it makes sense or not; some -fcompare-debug checking
with LTO would be useful, the question is only what to compare.
Simply rejecting -fcompare-debug with -ffat-lto-objects would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
Richard Biener changed:
What|Removed |Added
Keywords|ice-on-valid-code |lto
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
10 matches
Mail list logo
