* Problem with integer caching and inlining
@ 2004-09-22 20:46 Richard Kenner
2004-09-23 2:12 ` Richard Henderson
0 siblings, 1 reply; 5+ messages in thread
From: Richard Kenner @ 2004-09-22 20:46 UTC (permalink / raw)
To: gcc
When given an INTEGER_CST, tree-inline.c:copy_body_r calls copy_tree_r to
make a copy of the INTEGER_CST and then updates the type in the "new" node
using remap_type.
However, copy_body_r actually doesn't copy INTEGER_CST, assuming they are
shared. So the type remapping is destroying the type of an existing tree
node. In this case, the node is in the value cache of the type.
This occurs compiling ada/uintp.adb with -gnatpgn -O2.
Should copy_body_r actually copy an INTEGER_CST or REAL_CST if the type
has variable bounds?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem with integer caching and inlining
2004-09-22 20:46 Problem with integer caching and inlining Richard Kenner
@ 2004-09-23 2:12 ` Richard Henderson
0 siblings, 0 replies; 5+ messages in thread
From: Richard Henderson @ 2004-09-23 2:12 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
On Wed, Sep 22, 2004 at 03:12:15PM -0400, Richard Kenner wrote:
> Should copy_body_r actually copy an INTEGER_CST or REAL_CST if the type
> has variable bounds?
Yes, but the condition is better specified as any time that
the type gets remapped.
r~
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem with integer caching and inlining
@ 2004-09-23 7:54 Richard Kenner
0 siblings, 0 replies; 5+ messages in thread
From: Richard Kenner @ 2004-09-23 7:54 UTC (permalink / raw)
To: rth; +Cc: gcc
> I think INTEGER_NODE should cause a new one to be made via
> build_int_cst_wide so caching is done in the new type and the rest
> should be done via copy_node. Does that sound right to you?
Yep.
OK, thanks for your help. That indeed seems to fix the problem. If it
passes testing, I'll post the patch and check it in.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem with integer caching and inlining
2004-09-23 2:50 Richard Kenner
@ 2004-09-23 3:45 ` Richard Henderson
0 siblings, 0 replies; 5+ messages in thread
From: Richard Henderson @ 2004-09-23 3:45 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
On Wed, Sep 22, 2004 at 09:35:13PM -0400, Richard Kenner wrote:
> I think INTEGER_NODE should cause a new one to be made via build_int_cst_wide
> so caching is done in the new type and the rest should be done via copy_node.
> Does that sound right to you?
Yep.
r~
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem with integer caching and inlining
@ 2004-09-23 2:50 Richard Kenner
2004-09-23 3:45 ` Richard Henderson
0 siblings, 1 reply; 5+ messages in thread
From: Richard Kenner @ 2004-09-23 2:50 UTC (permalink / raw)
To: rth; +Cc: gcc
Yes, but the condition is better specified as any time that
the type gets remapped.
Funny you should answer this at this moment: I was just in the process of
editing a change to copy_body_r that did just that ...
I think INTEGER_NODE should cause a new one to be made via build_int_cst_wide
so caching is done in the new type and the rest should be done via copy_node.
Does that sound right to you?
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-09-23 1:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-22 20:46 Problem with integer caching and inlining Richard Kenner
2004-09-23 2:12 ` Richard Henderson
2004-09-23 2:50 Richard Kenner
2004-09-23 3:45 ` Richard Henderson
2004-09-23 7:54 Richard Kenner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).