http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #14 from Alexandre Oliva 2012-06-28
07:39:34 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:25 2012
New Revision: 189036
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189036
Log:
PR debug/53740
PR debug/52983
PR debug/48866
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #13 from Alexandre Oliva 2012-06-13
20:42:00 UTC ---
Author: aoliva
Date: Wed Jun 13 20:41:55 2012
New Revision: 188527
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188527
Log:
PR debug/52983
PR debug/48866
* dce.c (word_dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #12 from Alexandre Oliva 2012-04-13
15:56:29 UTC ---
Author: aoliva
Date: Fri Apr 13 15:56:21 2012
New Revision: 186422
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186422
Log:
PR debug/48866
* df.h (enum debug_temp_where):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #11 from Jakub Jelinek 2011-05-07
06:15:23 UTC ---
locstats program, the above URL just gives the repo. Not sure if it has been
adjusted already for typed DWARF stack though, if not, perhaps for the testing
you could temporarily disa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #10 from Jakub Jelinek 2011-05-07
06:13:35 UTC ---
Please test it with
http://git.fedorahosted.org/git/?p=elfutils.git;a=shortlog;h=refs/heads/dwarf
on something large (say cc1plus) too, build stage3 cc1plus from either the
vanilla or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
Alexandre Oliva changed:
What|Removed |Added
Attachment #24189|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #8 from Alexandre Oliva 2011-05-06
14:43:45 UTC ---
I don't see how it would. Except for some very particular cases (that do not
include the expansion of addresses AFAICT) we just expand each of the
replaceable stmts at the time thei
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #7 from Jakub Jelinek 2011-05-05
13:54:18 UTC ---
Why are you changing TER for that though? Won't that affect also real code
generation rather than just debug insns? I mean there are targets e.g. with
MEM MEM addressing. With SSA e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #5 from Alexandre Oliva 2011-05-05
11:54:12 UTC ---
I think the problem is that the debug stmts are being expanded into debug insns
*before* the code that should precede them. If we expanded the stmts in the
natural, expended order,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #4 from Jakub Jelinek 2011-05-04
14:21:28 UTC ---
The problem is the MEMs nested in other MEM addresses, cselib isn't prepared to
handle it efficiently.
So, either we should break very deep MEM nests using extra DEBUG_INSNs and
debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #3 from Jakub Jelinek 2011-05-04
12:07:42 UTC ---
cselib actually. Shorter testcase:
struct S { struct S *d[2]; };
struct S *
foo (struct S *x)
{
struct S *y, *z;
y =
x->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
Richard Guenther changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
14 matches
Mail list logo
