https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #15 from Jeffrey A. Law law at gcc dot gnu.org ---
Author: law
Date: Mon Jun 2 19:12:08 2014
New Revision: 211142
URL: http://gcc.gnu.org/viewcvs?rev=211142root=gccview=rev
Log:
PR rtl-optimization/61094
* ree.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org ---
I vaguely remember it has been seen in the wild, not sure how often, but there
were several bugreports about that.
In any case, I'd say it is a pitty to stop optimizing this case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #14 from Jeffrey A. Law law at redhat dot com ---
I'm not talking about restricting the general case where we've got cascaded
extensions. Just the case where one of the insns in the cascade has a
source/dest that are not the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #12 from Jeffrey A. Law law at redhat dot com ---
I think the cascading problem can be pretty easily addressed.
The problematical sequence of insns would look something like this:
A (set (r0) (expression))
B (set (r1) (extend (r0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #9 from Jeffrey A. Law law at redhat dot com ---
Just starting to look at this, but my first thought is to validate the copy in
combine_set_extension. We can still abort the transformation at that point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
Sure, there, or merge_def_and_ext, or combine_reaching_defs.
In any case, what I'm afraid of is that when there are two extensions, you in
the first round verify that a copy is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #11 from Jeffrey A. Law law at redhat dot com ---
Right, and that's the case I'm still pondering.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 32768
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32768action=edit
partly reduced
I stopped reducing, it's very slow (because compiling the testcase is so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
template typename struct A {
unsigned _width, _height, _depth, _spectrum;
template typename t A(t p1) {
int a = p1.size();
if (a) {
_width = p1._width;
_depth =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||hjl.tools at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
13 matches
Mail list logo
