http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #22 from Martin Jambor 2011-01-14
11:59:10 UTC ---
Author: jamborm
Date: Fri Jan 14 11:59:07 2011
New Revision: 168778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168778
Log:
2011-01-14 Martin Jambor
PR middle-end/4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #21 from Jan Hubicka 2011-01-13 16:49:42
UTC ---
> Err - I'm not sure what this
>
> /* Turn forward declarations into real ones. */
> fn = cgraph_node (fn)->decl;
>
> is about at all. At least the comment doesn't make any sens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #20 from Martin Jambor 2011-01-13
11:00:52 UTC ---
Based on Honza's comment #17 I proposed a different patch, making sure
we update the statement as expected, like I described in comment #18
and I have already posted it to the mailing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #19 from Richard Guenther 2011-01-13
10:35:33 UTC ---
(In reply to comment #16)
> The problem seems to be a different one. During IPA decision making
> we decide to clone a function and the call graph node of the original
> one is th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #18 from Martin Jambor 2011-01-12
13:50:11 UTC ---
You're right, however in fact all redirections and updates should be
taking place already. Either in inline_transform() for calls that are
in the function from the beginning of inlin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #17 from Jan Hubicka 2011-01-11
13:29:58 UTC ---
I believed that we are supposed to update the statement first and only then try
to inline it. Otherwise we would get into problem with inliner not skipping the
args.
Anyway lookup base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #16 from Martin Jambor 2011-01-10
20:34:14 UTC ---
The problem seems to be a different one. During IPA decision making
we decide to clone a function and the call graph node of the original
one is then removed as unreachable an unnece
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #15 from Jan Hubicka 2011-01-08
00:35:03 UTC ---
OK, both decl and e->callee->former_clone_of points to decls that are not
clones.
(gdb) p debug_tree (decl->decl_with_vis.assembler_name)
local bindings <(nil)>>
$14 = void
(gdb) p de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #14 from Jan Hubicka 2011-01-08
00:24:34 UTC ---
huh, -O2 instead of -O3. It reproduces for me now. Sorry for noise.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #13 from Jan Hubicka 2011-01-08
00:23:28 UTC ---
I tested only the reduced testcase, but it still seems to work for me
j...@gcc10:~/trunk/build/gcc$ ./xgcc -B ./ -O2 a.cc -S -frounding-math
a.cc:68:19: warning: inline function 'bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #12 from Marc Glisse 2011-01-07
23:47:35 UTC ---
(In reply to comment #11)
> It does not reproduce for me, perhaps it was fixed by the recursive inliner
> fix?
Did you try with a.cc? ouin.cc hasn't reproduced for a while. I just chec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #11 from Jan Hubicka 2011-01-07
21:01:53 UTC ---
It does not reproduce for me, perhaps it was fixed by the recursive inliner
fix?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #10 from Jan Hubicka 2011-01-07 18:13:33
UTC ---
> Basically what happens that cgraph_node (decl) and e->callee have the
> same former_clone_of one is not clone of each other. I am now about
> to investigate how exactly this appears
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #9 from Martin Jambor 2011-01-07
16:57:45 UTC ---
Please disregard the previous comment, I thought that was the case
because of a typo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #7 from Martin Jambor 2011-01-03
17:40:57 UTC ---
The aforementioned patch did not do type comparisons correctly and so
only hid the problem. I have already committed a subsequent patch
that addresses this (http://gcc.gnu.org/ml/gcc-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #6 from Martin Jambor 2010-12-16
17:55:34 UTC ---
Hm, somehow I must have made a mistake when looking into this last
week but it seems that my dynamic type change detection patches fix
this problem too. The last version of them is at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #5 from Martin Jambor 2010-12-09
13:28:32 UTC ---
I could not reproduce the ICE with the ouin.cc source but I did with
a.cc.
So far I have no clue whatsoever how IPA-SRA comes into this (but it
is true that switching it off makes the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #4 from Martin Jambor 2010-12-07
13:28:58 UTC ---
ehm, sorry, wrong bug, this is a test case for PR 46734. Of course, I will
have a look at this one soon too, so it can stay assigned to me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #3 from Martin Jambor 2010-12-07
13:14:51 UTC ---
Simple testcase (to be run with -O -fipa-sra):
struct A
{
int *p;
A() {p = (int *) -1;}
~A() {if (p && p != (int *) -1) *p = 0;}
};
struct B
{
A a;
char data[23];
B() : a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
24 matches
Mail list logo
