--- Comment #26 from danglin at gcc dot gnu dot org 2005-12-19 15:47
---
*** Bug 23954 has been marked as a duplicate of this bug. ***
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2005-11-03 11:34
---
Subject: Bug 23585
Author: ebotcazou
Date: Thu Nov 3 11:34:55 2005
New Revision: 106428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106428
Log:
PR rtl-optimization/23585
* rtlanal.c (
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2005-11-03 11:31
---
Subject: Bug 23585
Author: ebotcazou
Date: Thu Nov 3 11:31:46 2005
New Revision: 106427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106427
Log:
PR rtl-optimization/23585
* rtlanal.c (
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2005-10-20 12:20
---
See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00883.html
Thanks for the reduced testcase.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #22 from cvs-commit at gcc dot gnu dot org 2005-10-20 12:18
---
Subject: Bug 23585
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-20 12:18:05
Modified files:
gcc: ChangeLog functio
--- Comment #21 from cvs-commit at gcc dot gnu dot org 2005-10-20 12:14
---
Subject: Bug 23585
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-20 12:14:30
Modified files:
gcc: ChangeLog function.c reorg.c rtl.h rtlanal.c
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2005-10-12 06:39
---
Mark, do you have an opinion on the following implementation detail? We don't
want to duplicate the code of may_trap_p and rtx_addr_can_trap_p, so the new
predicate will essentially piggyback on it, simply bypas
--- Comment #19 from giovannibajo at libero dot it 2005-10-11 22:57 ---
(In reply to comment #16)
> > Probably. But what if the problem with dereferencing p was that it is NULL,
> > instead of a misalignment? Would that case be caught in reorg by something
> > else?
> Well, then the co
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-10-11 22:21
---
> Sorry -- my idea about fixing this in the front end is bogus. It's OK to
> dereference a pointer-to-member to a virtual function member even if the base
> class doesn't have any virtual functions;
Too bad. :-
--- Comment #17 from mmitchel at gcc dot gnu dot org 2005-10-11 22:05
---
Eric --
Sorry -- my idea about fixing this in the front end is bogus. It's OK to
dereference a pointer-to-member to a virtual function member even if the base
class doesn't have any virtual functions; c.f., g++.
--- Comment #16 from mark at codesourcery dot com 2005-10-11 17:31 ---
Subject: Re: [4.0 regression] mem_fun* code fine
with -O1, bus error with -O2
giovannibajo at libero dot it wrote:
> --- Comment #15 from giovannibajo at libero dot it 2005-10-11 17:16
> ---
> Probably. B
--- Comment #15 from giovannibajo at libero dot it 2005-10-11 17:16 ---
Probably. But what if the problem with dereferencing p was that it is NULL,
instead of a misalignment? Would that case be caught in reorg by something
else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2005-10-11 16:24
---
> Ah. I think that would best be fixed in the front-end, then. If the
> class doesn't have a virtual pointer, then there's no need to generate
> the conditional expression; avoiding that will not only fix this b
--- Comment #13 from mark at codesourcery dot com 2005-10-11 14:47 ---
Subject: Re: [4.0 regression] mem_fun* code fine
with -O1, bus error with -O2
ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-10-11 14:41
> ---
>
>>Th
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-10-11 14:41
---
> This certainly is a bug in the back-end, not a bug in the default
> location of the v-bit. You shouldn't need to break the C++ ABI on SPARC
> to fix this bug.
Right, I was confused, I thought __pfn was derefe
--- Comment #11 from mark at codesourcery dot com 2005-10-11 14:22 ---
Subject: Re: [4.0 regression] mem_fun* code fine
with -O1, bus error with -O2
ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:59
> ---
>
>>ma
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:59
---
> may_trap_p is the correct thing as it should detect this instruction as
> trapping:
>
> /* Memory ref can trap unless it's a static var or a stack slot. */
> case MEM:
>if (MEM_NOTRAP_P (x))
>
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 13:55 ---
Subject: Re: [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote:
>
>
> --- Comment #8 from ebotcazou at gcc dot gnu dot org 2
On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11
13:51 ---
Yes, I think the problem is in delay slot scheduling too. COND_EXPR
means that
either branch must not be evaluated because it could be ille
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:51
---
> Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that
> either branch must not be evaluated because it could be illegal; if you hoist
> a
> mem from a branch into the delay slot of the
--- Comment #7 from giovannibajo at libero dot it 2005-10-11 13:43 ---
Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that
either branch must not be evaluated because it could be illegal; if you hoist a
mem from a branch into the delay slot of the condition, yo
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-10-11 10:54
---
> The only approach to fixing this I can think of is to modify the selection
> logic of TARGET_PTRMEMFUNC_VBIT_LOCATION: if the target has strict alignment
> and delay slots, the macro should be set to ptrmemfunc_
22 matches
Mail list logo
