This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
- From: "mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Mar 2005 21:19:49 -0000
- Subject: [Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
- References: <20041013124723.17972.mostrows@watson.ibm.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From mark at codesourcery dot com 2005-03-03 21:19 -------
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
> ------- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03 21:12 -------
>
>>I don't think I'd try to be that clever. We might want the
>>stabilization to occur even in other cases. In looking at it more
>>closely, it definitely looks like stabilize_reference should deal with
>>CALL_EXPRs.
>
>
> But then what's the difference with setting TREE_SIDE_EFFECTS on CALL_EXPRs?
> Also for 3.4.x some FE don't use tree inlining at all so I don't think they
> should be penalized because of the C++ FE.
There are other places where TREE_SIDE_EFFECTS matters. (Like, "do we
have to emit this expression at all, if its result is not used?")
The counter to your argument is that I don't see why the C++ front end
should be penalized because other front ends have a workaround for what
seems to be a bug in the middle end.
The stated purpose for stabilize_reference is to make it possible to use
an expression more than once. If CALL_EXPRs can't be used more than
once (which your research would seem to prove), then it seems like
stabilize_reference should handle that.
>>(I guess I was thinking that the problem with the duplicate labels could
>>be avoided in the inliner by generating fresh labels. But, maybe that's
>>not going to work for other reasons.)
>
> How would you do that exactly? In our present case, the inliner inlines exactly
> one CALL_EXPR, but it is referenced twice in another tree.
OK, I'm confused, then -- I think that either we have to fix this
problem in stabilize_reference (which seems better to me) or always set
TREE_SIDE_EFFECTS on CALL_EXPRs in build3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972