[Bug c++/21135] [4.0/4.1 Regression] a[-2] ICE at the top level

2005-08-25 Thread pinskia at gcc dot gnu dot org 

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-25 
22:49 ---
This happens in Jikes 1.2.2.

-- 
   What|Removed |Added

   Severity|normal  |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135

[Bug c++/21135] [4.0/4.1 Regression] a[-2] ICE at the top level

2005-08-25 Thread pinskia at gcc dot gnu dot org 

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-26 
03:48 ---
Here is an interesting thing:
if we do:
int f[3];

int *h(void)
{
  return f[-1];
}
---
The C front-end expands it like:
(insn 10 9 11 (set (reg:SI 60)
(const_int -4 [0xfffc])) -1 (nil)
(nil))

(insn 11 10 12 (parallel [
(set (reg:SI 59)
(plus:SI (reg:SI 60)
(symbol_ref:SI (f) var_decl 0xb7c630b0 f)))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

(insn 12 11 13 (set (reg:SI 58 [ result ])
(reg:SI 59)) -1 (nil)
(nil))

But the C++ front-end does:
(insn 10 9 11 (set (reg:SI 60)
(symbol_ref:SI (f) [flags 0x2] var_decl 0xb7cbb1b8 f)) -1 (nil)
(nil))

(insn 11 10 12 (parallel [
(set (reg:SI 59)
(plus:SI (reg:SI 60)
(const_int -4 [0xfffc])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

(insn 12 11 13 (set (reg:SI 58 [ result ])
(reg:SI 59)) -1 (nil)
(nil))

Notice how the the order of the plus happens.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135

[Bug c++/21135] [4.0/4.1 Regression] a[-2] ICE at the top level

2005-08-06 Thread pinskia at gcc dot gnu dot org 

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-06 
13:32 ---
*** Bug 23260 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||jakub at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135

[Bug c++/21135] [4.0/4.1 Regression] a[-2] ICE at the top level

2005-07-06 Thread mmitchel at gcc dot gnu dot org 

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-06 
17:02 ---
Postponed until 4.0.2.

-- 
   What|Removed |Added

   Target Milestone|4.0.1   |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135

[Bug c++/21135] [4.0/4.1 Regression] a[-2] ICE at the top level

2005-05-31 Thread pinskia at gcc dot gnu dot org 

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:17 ---
: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135

[Bug c++/21135] [4.0/4.1 Regression] a[-2] ICE at the top level

2005-05-30 Thread mmitchel at gcc dot gnu dot org 

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-05-30 
17:18 ---
I'm not sure this is really a C++ bug.

The C++ front end provides the same representation to the middle end for
a[-2] as it does for a[2].  It would be wrong for the middle end to say
that this expression is not a valid constant initializer, at least on platforms
where it *is* valid.

The difference in the handling of these two expressions is that
get_inner_reference sets the offset out-parameter for a[-2], but not for
a[2].  That's at odds with its documentation, which says that offset is only set
if the offset is not a constant.  Furthermore, the out-parameter bitpos is
signed, which suggests that negative values should be acceptable.

Changing get_inner_reference to use ssizetype and sbitsizetype throughout fixes
the problems -- but I'm not sure if that's 100% correct.

-- 
   What|Removed |Added

 CC||kenner at vlsi1 dot ultra
   ||dot nyu dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135

[Bug c++/21135] [4.0/4.1 Regression] a[-2] ICE at the top level

2005-05-30 Thread kenner at vlsi1 dot ultra dot nyu dot edu 

--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu  
2005-05-30 18:36 ---
Subject: Re:   [4.0/4.1 Regression] a[-2] ICE at the top level

The difference in the handling of these two expressions is that
get_inner_reference sets the offset out-parameter for a[-2], but
not for a[2].  That's at odds with its documentation, which says that
offset is only set if the offset is not a constant.

Is this because the value doesn't fit in some type?  I don't understand
why it's doing that.

Furthermore, the out-parameter bitpos is signed, which suggests that
negative values should be acceptable.

I think this is just consistency: bitpos is signed all over the place.
But, actually, I think there are some cases where the are negative bit
positions: the object a thin pointer in Ada points to comes to mind.

Changing get_inner_reference to use ssizetype and sbitsizetype
throughout fixes the problems -- but I'm not sure if that's 100%
correct.

Nor am I, but I can't offhand think of anything it would breajk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135

[Bug c++/21135] [4.0/4.1 Regression] a[-2] ICE at the top level

2005-04-20 Thread pinskia at gcc dot gnu dot org 

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-20 
23:46 ---
Confirmed as a regression.

I think this was caused by the C++ front-end no longer lowering a[const] to a 
+ const.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
  Known to fail||4.0.0 4.1.0
  Known to work||3.3.3 3.4.0
   Last reconfirmed|-00-00 00:00:00 |2005-04-20 23:46:17
   date||
Summary|a[-2] ICE at the top level |[4.0/4.1 Regression] a[-2]
   ||ICE at the top level
   Target Milestone|--- |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135