[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm

["mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From mark at codesourcery dot com  2005-03-03 19:34 -------
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 19:25 -------
> 
>>It really seems like the C++ front end is doing the right thing, 
>>abstractly -- these functions don't have side-effects!  So, either the 
>>inliner or stabilize reference seems like it needs fixing.  Maybe the 
>>latter should recognize CALL_EPRs?
> 
> 
> I agree that the C++ FE is theoritically right, but other FEs appear to already
> have realized that the implementation constraints trumpet the theory here: on
> mainline, the C, Java and Fortran 95 FEs set TREE_SIDE_EFFECTS on CALL_EXPRs.

Interesting.  So, we have some checks in gcc/tree.c to try to avoid 
setting TREE_SIDE_EFFECTS, and then the FEs all set it anyhow. :-(

> Special-casing CALL_EXPRs in stabilize_reference could indeed be the solution. 
> We could even be clever and check whether tree inlining is enabled and, if so,
> whether it has already occurred.  Does that sound plausible?

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.

(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.)

>>If it's not possible to fix this, then what we should do is modify 
>>build3 to mark CALL_EXPRs as having side-effects.  Right now, it makrs 
>>them based on the flags for the function, so this problem isn't really 
>>C++-specific; it probably effects all languages except those whose front 
>>ends set TREE_SIDE_EFFECTS additionally themselves.  (Unless C++ is 
>>changing out the operands to the CALL_EXPR after its created.)
> 
> Right.

OK, that's the fallback.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972