[Bug c++/21135] New: &a[-2] ICE at the top level

[Bug c++/21135] New: &a[-2] ICE at the top level

[mrs at apple dot com]

int a[4] = {0,1,2,3};
int *b = &a[-2];

doesn't work, it fails with:

t2.ii:1: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

This ICEes because it is going deep into expand, and there is no cfun, and no insns at that time.

This should be host/target/build independent.

radr://4093122

-- 
           Summary: &a[-2] ICE at the top level
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mrs at apple dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin8
  GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8


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

[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|0000-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

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

[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

[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

[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

[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

[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

[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

[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 [0xfffffffc])) -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 [0xfffffffc])))
            (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 Regression] &a[-2] ICE at the top level

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-09 03:13 -------
Fixed on the mainline by:
2005-09-08  Josh Conner  <jconner@apple.com>

        PR c++/23180
        * expr.c (expand_expr_addr_expr_1): Don't invoke
        expand_simple_binop for EXPAND_INITIALIZER.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.0.0 4.1.0                 |4.0.0
      Known to work|3.3.3 3.4.0                 |3.3.3 3.4.0 4.1.0
            Summary|[4.0/4.1 Regression] &a[-2] |[4.0 Regression] &a[-2] ICE
                   |ICE at the top level        |at the top level


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

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-10 01:03 -------
Subject: Bug 21135

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	jconner@gcc.gnu.org	2005-09-10 01:03:32

Modified files:
	gcc            : ChangeLog expr.c 

Log message:
	PR c++/21135
	* expr.c (expand_expr_addr_expr_1): Don't invoke
	expand_simple_binop for EXPAND_INITIALIZER.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.423&r2=2.7592.2.424
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.778.6.4&r2=1.778.6.5



-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 01:49 -------
Fixed, thanks again Josh.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 01:49 -------
Fixed, thanks again Josh.

-- 


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