--- Comment #43 from rguenth at gcc dot gnu dot org 2007-06-19 09:24
---
Subject: Bug 30252
Author: rguenth
Date: Tue Jun 19 09:24:35 2007
New Revision: 125844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125844
Log:
2007-06-19 Richard Guenther [EMAIL PROTECTED]
--- Comment #44 from rguenth at gcc dot gnu dot org 2007-06-19 09:45
---
Fixed on the 4.2 branch. Danny will fix this in a different way on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #41 from rguenther at suse dot de 2007-06-06 08:49 ---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0
based code with -fstrict-aliasing
On Wed, 5 Jun 2007, dberlin at dberlin dot org wrote:
q_2 = q_1 + 1
q_3 = q_2 + 1
q_4 = q_3 + 1
q_5 = q_4 + 1
p2 = q_5
--- Comment #42 from dberlin at gcc dot gnu dot org 2007-06-06 15:52
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 6 Jun 2007 08:49:50 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #41 from rguenther
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-06-05 09:27
---
See this testcase (reduced from spec2k6 dealII by Micha):
struct I {
int ix;
struct II {
int j,i;
void *ptr;
} ii;
};// inner;
struct O : public I {
// int x;
int y;
};
static int
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-06-05 12:05
---
The problem in this PR is, that the structure we mess up points-to info has no
fields in its lower half, but only two varinfos (D.2860, offset 128 size 64
and D.2860.visited_, offset 192 size 64 -- the first one
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-06-05 15:01
---
Created an attachment (id=13657)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13657action=view)
patch
Patch in testing. It makes sure to create fields for all addressable
components
(such as empty bases)
--- Comment #33 from rguenth at gcc dot gnu dot org 2007-06-05 15:57
---
Actually,
+ if (minoffset != 0)
must be changed to
+ if (minoffset != 0 count != 0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
--- Comment #34 from dberlin at gcc dot gnu dot org 2007-06-05 16:20
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 09:27:34 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #30 from
--- Comment #35 from rguenther at suse dot de 2007-06-05 16:30 ---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0
based code with -fstrict-aliasing
On Tue, 5 Jun 2007, dberlin at dberlin dot org wrote:
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based
--- Comment #36 from dberlin at gcc dot gnu dot org 2007-06-05 17:45
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 16:30:32 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #35 from rguenther
--- Comment #37 from matz at gcc dot gnu dot org 2007-06-05 18:24 ---
We are pointing to cell, and using that to access cell.i
No. We are pointing to cell.ii, and use that pointer to access cell.ii.i
(via in-i). Hence of course the points-to set of 'in' needs to include
cell.in.i
--- Comment #38 from dberlin at gcc dot gnu dot org 2007-06-05 19:07
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 18:24:54 -, matz at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #37 from matz at
--- Comment #39 from rguenther at suse dot de 2007-06-05 19:59 ---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0
based code with -fstrict-aliasing
On Tue, 5 Jun 2007, dberlin at dberlin dot org wrote:
--- Comment #38 from dberlin at gcc dot gnu dot org 2007-06-05
--- Comment #40 from dberlin at gcc dot gnu dot org 2007-06-05 22:44
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 19:59:32 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #39 from rguenther
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-06-04 15:28
---
solution_set_add () looks like the culprit (thx micha). So, the following will
fix it in case we have offsets only from COMPONENT_REFs, not from regular
pointer arithmetic (which is not true):
Index:
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-06-04 15:45
---
We can make it safe if we only really handle + in pointer arithmetic. Like
with
@@ -3258,7 +3255,7 @@ handle_ptr_arith (VEC (ce_s, heap) *lhsc
unsigned int i = 0;
unsigned int j = 0;
VEC (ce_s, heap)
--- Comment #27 from rguenth at gcc dot gnu dot org 2007-05-15 08:59
---
Yes, that's a (part of!) a diff of a -details dump with the following patch
Index: passes.c
===
--- passes.c(revision 124501)
+++ passes.c
--- Comment #25 from dberlin at gcc dot gnu dot org 2007-05-14 20:01
---
which should be the most interesting parts of the diff (apart from the
extra vops that prevent the DCE).
Danny? Any hints on what can go wrong here?
The first pass is obviously generating wrong answers,
--- Comment #26 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25
---
Will not be fixed in 4.2.0; retargeting at 4.2.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-05-13 11:34
---
There are no overlapping fields created from push_fields_onto_fieldstack, so my
pointing to PR22488 may be wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-05-13 13:02
---
That leaves aliasing and DCE.
The following statement connects to the initializing of the function pointer.
# SFT.78D.2952_55 = V_MAY_DEF SFT.78D.2952_31;
# VUSE D.2838_29;
thisD.2828_22-functor_D.2399
--- Comment #22 from ismail at pardus dot org dot tr 2007-05-13 01:43
---
This problem also breaks inkscape, it segfaults on startup when compiled with
gcc 4.2.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
--- Comment #19 from mmitchel at gcc dot gnu dot org 2007-05-02 21:59
---
If this is a valid program, as we seem to think it is, then this is a serious
bug. However, if it's the front-end bug that Richard suspects, there's not
much we can do about it in the near term. The ball is
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-05-01 14:05
---
So my guess is this is related to PR22488 which is rotting since some time...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
25 matches
Mail list logo
