------- 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. I think it is too late to fix the problem in the tree inliner because it would be tricky to detect there whether a CALL_EXPR is mentioned more than once. 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? > 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
