--- Comment #39 from gdr at gcc dot gnu dot org 2005-11-21 10:41 ---
Fixed in 4.0.0 and higher.
Won't fix for 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from gdr at gcc dot gnu dot org 2005-11-21 02:21 ---
(In reply to comment #36)
New patch at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00864.html
Eric, do you still consider this problem important to be solved for 3.4.x?
Do you have a new version of your proposed
--- Comment #38 from ebotcazou at gcc dot gnu dot org 2005-11-21 05:16
---
Eric, do you still consider this problem important to be solved for 3.4.x?
As the saying goes in French: ne soyons pas plus royaliste que le roi. The
C++ maintainers apparenty don't care much, then neither do
--
What|Removed |Added
Target Milestone|3.4.4 |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
--
What|Removed |Added
CC||jason at redhat dot com
AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-10
08:04 ---
New patch at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00864.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-07
09:54 ---
An interesting thing in the head comment of unsafe_for_reeval in 3.4.x:
This assumes that CALL_EXPRs and TARGET_EXPRs are never replicated in
an expression tree, so that it safe to unsave them and
--- Additional Comments From mark at codesourcery dot com 2005-03-03 18:47
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
2. The tree-inliner inlines the call. Since the same tree is referenced twice
in the
--- 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.
--- 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 ---
--- 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
--- 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 ---
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
22:02 ---
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?)
OK.
The counter to your argument is that I don't see why the
--- Additional Comments From mostrows at watson dot ibm dot com 2005-02-24
14:18 ---
New test case exhibits same problem.
struct demo {
int s;
};
extern struct demo * const *xd;
static inline struct demo *fn1(void) __attribute__((pure));
static inline struct demo *fn1(void)
{
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-24
15:59 ---
New test case exhibits same problem.
Confirmed. Reduced testcase:
struct demo {
int s;
};
extern struct demo * const *xd;
static inline struct demo *fn1(void) __attribute__((pure));
static
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-24
16:49 ---
Hum... again a consequence of the C++ front-end not setting TREE_SIDE_EFFECTS on
every CALL_EXPR, like the C front-end. The sequence of events is as follows:
1. fn1()-s -= 1 is expanded to the 3-operand
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-15
19:15 ---
Subject: Bug 17972
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-15 19:14:55
Modified files:
gcc: ChangeLog tree-inline.c
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-15
19:19 ---
Patch applied.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-15
19:18 ---
Subject: Bug 17972
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2004-12-15 19:17:57
Modified files:
gcc:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10
03:28 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00722.html.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-07
08:01 ---
I checked again with a current x86 gcc, 3.4.4 20041206, and the problem is
still there. Note that this only happens with cc1plus.
Sorry, you're right, I was able to reproduce on i586-redhat-linux-gnu
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-07
08:30 ---
Investigating.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-06
17:15 ---
Alan, unless I'm mistaken, the testcase you filed doesn't fail on x86.
Moreover, the assembly code you posted contains an infinite loop that can't
reasonably come from the code.
--
What
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-06
23:31 ---
I checked again with a current x86 gcc, 3.4.4 20041206, and the problem is still
there. Note that this only happens with cc1plus. As to why we get the
impossible assembly, what happens is that the
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-01 00:45
---
Postponed until GCC 3.4.4.
--
What|Removed |Added
Target Milestone|3.4.3
--- Additional Comments From amodra at bigpond dot net dot au 2004-10-16 10:58
---
Michal's reduced testcase, in comment #5, fails on powerpc-linux too.
expand_increment is expanding the inline function body twice, at line 9261
op0 = expand_expr (incremented, NULL_RTX, VOIDmode, 0);
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 23:12
---
Never mind you are right Alan, I do need to use cc1plus but why. The RTL is wrong
already at .01.rtl.
So this is 3.4 regression (it might be a 3.3 regression also I don't know). But this
was fixed on
--
What|Removed |Added
Severity|normal |critical
Known to fail||3.4.0
Known to work|
28 matches
Mail list logo
