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: "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Mar 2005 19:25:46 -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 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