http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #12 from Jeffrey A. Law ---
Author: law
Date: Fri Jan 10 22:13:18 2014
New Revision: 206545
URL: http://gcc.gnu.org/viewcvs?rev=206545&root=gcc&view=rev
Log:
PR middle-end/59743
* ree.c (combine_reaching_defs): Ensure the defi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #11 from Jeffrey A. Law ---
Thanks. I'm still working through the RTL/source on the full testcase to see
if there are any uninitialized uses. Regardless the patch I have here works
for both the reduced and original testcase. I'll be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #10 from Jakub Jelinek ---
Ah, there is:
/* If the df_live problem is not defined, such as at -O0 and -O1, we
still need to keep the luids up to date. This is normally done
in the df_live problem since this problem has a f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #8 from Jeffrey A. Law ---
/* The logical uid of the insn in the basic block. This is valid
after any call to df_analyze but may rot after insns are added,
deleted or moved. */
int luid;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #7 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #5)
> I think we can just check DF_INSN_LUIDs here to catch this case. My systems
> are busy right now, but I should be able to nail this down as soon as one
> frees u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #6 from Markus Trippelsdorf ---
Created attachment 31791
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31791&action=edit
original testcase
Here's the unreduced original.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #5 from Jeffrey A. Law ---
I think we can just check DF_INSN_LUIDs here to catch this case. My systems
are busy right now, but I should be able to nail this down as soon as one frees
up.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #4 from Jeffrey A. Law ---
I see what's going on.
Basically the code exhibits undefined behaviour (r.s.high is not defined before
its first use in the loop). Thus the first and only reaching def is appearing
after the first use.
Obv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
--- Comment #3 from Jeffrey A. Law ---
No worries Jakub. I'll take it as it's clearly mine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59743
Markus Trippelsdorf changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Com
13 matches
Mail list logo