--- Comment #12 from rguenth at gcc dot gnu dot org 2010-07-08 21:44
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-06 13:30
---
Index: tree-inline.c
===
--- tree-inline.c (revision 161865)
+++ tree-inline.c (working copy)
@@ -817,6 +817,12 @@ remap_gimple_op_r (tree
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-06 13:02
---
Reduced testcase:
typedef unsigned short PRUint16;
typedef PRUint16 PRUnichar;
template struct nsCharTraits {
};
class nsAString_internal {
public:
typedef PRUnichar char_type;
};
class nsString : public ns
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-06 12:23 ---
Reducing a testcase to look at it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
--- Comment #8 from rguenther at suse dot de 2010-07-06 12:16 ---
Subject: Re: Mozilla build ICE at Invalid first operand
of MEM_REF.
On Tue, 6 Jul 2010, hubicka at ucw dot cz wrote:
>
>
> --- Comment #7 from hubicka at ucw dot cz 2010-07-06 12:00 ---
> Subject: Re: Mozil
--- Comment #7 from hubicka at ucw dot cz 2010-07-06 12:00 ---
Subject: Re: Mozilla build ICE at Invalid first
operand of MEM_REF.
> Well, that sounds like caused by your needs_to_live_in_memory change.
>
> There is asymmetry wrt caller / callee and DECL_BY_REFERENCE handling.
> Well, that sounds like caused by your needs_to_live_in_memory change.
>
> There is asymmetry wrt caller / callee and DECL_BY_REFERENCE handling.
Hmm, what kind of assymetry? Previously we special cased RESULT_DECL so it was
forced to memory even if it was pointer, no we don't. So things should
--- Comment #6 from rguenther at suse dot de 2010-07-06 11:45 ---
Subject: Re: Mozilla build ICE at Invalid first operand
of MEM_REF.
On Tue, 6 Jul 2010, hubicka at ucw dot cz wrote:
>
>
> --- Comment #5 from hubicka at ucw dot cz 2010-07-06 11:41 ---
> Subject: Re: Mozil
--- Comment #5 from hubicka at ucw dot cz 2010-07-06 11:41 ---
Subject: Re: Mozilla build ICE at Invalid first
operand of MEM_REF.
> What's the patch needed to trigger it?
The DECL_BY_REFERENCE change. THe one I sent to list should be enough. So if
you could look into it, it
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-06 10:39 ---
What's the patch needed to trigger it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-06 08:44 ---
(In reply to comment #2)
> Actually it seems to be fallout of my local DECL_BY_REFERENCE change (so it
> does not reproduce on clean mainline).
> Apprently the result_slot_addr is something that is not allowed in mem
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-07-05 16:45 ---
Actually it seems to be fallout of my local DECL_BY_REFERENCE change (so it
does not reproduce on clean mainline).
Apprently the result_slot_addr is something that is not allowed in mem_ref.
It goes away with:
@@ -90
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-05 16:31 ---
Created an attachment (id=21094)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21094&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
13 matches
Mail list logo