public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm Date: Thu, 03 Mar 2005 19:34:00 -0000 [thread overview] Message-ID: <20050303193445.13367.qmail@sourceware.org> (raw) In-Reply-To: <20041013124723.17972.mostrows@watson.ibm.com> ------- 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
next prev parent reply other threads:[~2005-03-03 19:34 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-10-13 12:47 [Bug c++/17972] New: " mostrows at watson dot ibm dot com 2004-10-13 14:51 ` [Bug rtl-optimization/17972] " pinskia at gcc dot gnu dot org 2004-10-13 21:45 ` mostrows at watson dot ibm dot com 2004-10-13 22:02 ` pinskia at gcc dot gnu dot org 2004-10-13 22:58 ` amodra at bigpond dot net dot au 2004-10-13 23:04 ` amodra at bigpond dot net dot au 2004-10-13 23:11 ` mostrows at watson dot ibm dot com 2004-10-13 23:25 ` [Bug rtl-optimization/17972] [3.4 Regression] " pinskia at gcc dot gnu dot org 2004-10-13 23:36 ` pinskia at gcc dot gnu dot org 2004-10-13 23:37 ` pinskia at gcc dot gnu dot org 2004-10-14 0:03 ` pinskia at gcc dot gnu dot org 2004-10-14 0:34 ` mostrows at watson dot ibm dot com 2004-10-14 0:43 ` pinskia at gcc dot gnu dot org 2004-10-14 0:59 ` mostrows at watson dot ibm dot com 2004-10-14 1:44 ` [Bug rtl-optimization/17972] [3.3 " pinskia at gcc dot gnu dot org 2004-10-15 6:47 ` amodra at bigpond dot net dot au 2004-10-15 23:12 ` [Bug c++/17972] [3.4 " pinskia at gcc dot gnu dot org 2004-10-16 2:21 ` pinskia at gcc dot gnu dot org 2004-10-16 10:58 ` amodra at bigpond dot net dot au 2004-11-01 0:45 ` mmitchel at gcc dot gnu dot org 2004-12-06 17:15 ` ebotcazou at gcc dot gnu dot org 2004-12-06 23:32 ` amodra at bigpond dot net dot au 2004-12-07 8:01 ` ebotcazou at gcc dot gnu dot org 2004-12-07 8:30 ` ebotcazou at gcc dot gnu dot org 2004-12-10 3:29 ` pinskia at gcc dot gnu dot org 2004-12-15 19:15 ` cvs-commit at gcc dot gnu dot org 2004-12-15 19:18 ` cvs-commit at gcc dot gnu dot org 2004-12-15 19:19 ` ebotcazou at gcc dot gnu dot org 2005-02-24 17:10 ` mostrows at watson dot ibm dot com 2005-02-24 19:59 ` ebotcazou at gcc dot gnu dot org 2005-02-24 21:19 ` ebotcazou at gcc dot gnu dot org 2005-03-03 18:47 ` mark at codesourcery dot com 2005-03-03 19:25 ` ebotcazou at gcc dot gnu dot org 2005-03-03 19:34 ` mark at codesourcery dot com [this message] 2005-03-03 21:12 ` ebotcazou at gcc dot gnu dot org 2005-03-03 21:19 ` mark at codesourcery dot com 2005-03-03 22:02 ` ebotcazou at gcc dot gnu dot org 2005-03-07 9:54 ` ebotcazou at gcc dot gnu dot org 2005-03-10 8:05 ` ebotcazou at gcc dot gnu dot org 2005-03-12 16:06 ` ebotcazou at gcc dot gnu dot org 2005-05-19 17:29 ` mmitchel at gcc dot gnu dot org [not found] <bug-17972-7332@http.gcc.gnu.org/bugzilla/> 2005-11-21 2:21 ` gdr at gcc dot gnu dot org 2005-11-21 5:16 ` ebotcazou at gcc dot gnu dot org 2005-11-21 10:41 ` gdr at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050303193445.13367.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).