[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[bangerth at dealii dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |3.5.0
            Version|3.4.1                       |3.5.0


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

[Bug middle-end/16809] New: [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[bangerth at dealii dot org]

Not quite sure about the validity of this code (we take the address 
of a temporary -- I guess it should be valid, but undefined), but 
this nasty error message that is ten times as long as the code in  
question is not appropriate: 
--------------------- 
typedef int I2[2]; 
int main () { 
  int *p = (I2) {1,2}; 
} 
--------------------- 
 
g/x> /home/bangerth/bin/gcc-3.5-pre/bin/c++ -c x.cc 
gimplification failed: 
{1, 2} <constructor 0x401819c0 
    type <array_type 0x40239a6c I2 
        type <integer_type 0x40185488 int SI 
            size <integer_cst 0x40182348 constant invariant 32> 
            unit size <integer_cst 0x401823f0 constant invariant 4> 
            align 32 symtab 0 alias set -1 precision 32 min <integer_cst 
0x401823c0 -2147483648> max <integer_cst 0x401823d8 2147483647> 
            pointer_to_this <pointer_type 0x40191e80>> 
        DI 
        size <integer_cst 0x40182798 constant invariant 64> 
        unit size <integer_cst 0x40182ab0 constant invariant 8> 
        align 32 symtab 0 alias set -1 
        domain <integer_type 0x40239910 type <integer_type 0x40191740 unsigned 
int> 
            SI size <integer_cst 0x40182348 32> unit size <integer_cst 
0x401823f0 4> 
            align 32 symtab 0 alias set -1 precision 32 min <integer_cst 
0x40182c30 0> max <integer_cst 0x40182cf0 1>> 
        pointer_to_this <pointer_type 0x40239ef4>> 
    constant invariant addressable static tree_4 
    arg 0 <tree_list 0x40238a50 
        purpose <integer_cst 0x40182c30 constant invariant 0> 
        value <integer_cst 0x402389f0 constant invariant 1> 
        chain <tree_list 0x40238a68 
            purpose <integer_cst 0x40182cf0 constant invariant 1> 
            value <integer_cst 0x40238a20 constant invariant 2>>>> 
x.cc: In function `int main()': 
x.cc:3: internal compiler error: in gimplify_expr, at gimplify.c:3972 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See <URL:http://gcc.gnu.org/bugs.html> for instructions. 
 
W.

-- 
           Summary: [3.5 regression] ICE in gimplify_expr with initializer
                    of arrays and pointers
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bangerth at dealii dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-28 21:43 -------
ICE came about on the mainline
: Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455).

We started accepting this:
: Search converges between 2004-04-20-trunk (#449) and 2004-05-01-trunk (#450).

Before we errored:
input.cc: In function `int main()':
input.cc:3: error: initializer for scalar variable requires one element

So this is a regression no matter what, either we are ICEing when we should not be or we are accepting 
invalid code when we should not be.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |accepts-invalid
   Last reconfirmed|0000-00-00 00:00:00         |2004-07-28 21:43:32
               date|                            |


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

[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-07-28 21:51 -------
Subject: Re:  New: [3.5 regression] ICE in gimplify_expr
 with initializer of arrays and pointers

On Wed, 28 Jul 2004, bangerth at dealii dot org wrote:

> Not quite sure about the validity of this code (we take the address 
> of a temporary -- I guess it should be valid, but undefined), but 
> this nasty error message that is ten times as long as the code in  
> question is not appropriate: 

The compound literal has automatic storage duration associated with the
enclosing block.  The code looks perfectly reasonable to me.

> --------------------- 
> typedef int I2[2]; 
> int main () { 
>   int *p = (I2) {1,2}; 
> } 
> --------------------- 



-- 


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

[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[bangerth at ices dot utexas dot edu]

------- Additional Comments From bangerth at ices dot utexas dot edu  2004-07-28 21:52 -------
Subject: Re:  [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers


> Before we errored:
> input.cc: In function `int main()':
> input.cc:3: error: initializer for scalar variable requires one element
>
> So this is a regression no matter what, either we are ICEing when we should
> not be or we are accepting invalid code when we should not be.

My naive understanding is that we should accept this. We initialize a pointer 
to int with an array of two integers. The array should simply decay to a 
pointer. icc8 thinks the same, btw. I'm sure JSM can help us here, though.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/



-- 


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

[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[bangerth at ices dot utexas dot edu]

------- Additional Comments From bangerth at ices dot utexas dot edu  2004-07-28 21:53 -------
Subject: Re:  [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers


> The compound literal has automatic storage duration associated with the
> enclosing block.  The code looks perfectly reasonable to me.

Ah, speaking of the devil :-))

Thanks, Joseph, for clarifying the matter!

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/



-- 


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

[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-07-28 22:17 -------
Subject: Re:  [3.5 regression] ICE in gimplify_expr
 with initializer of arrays and pointers

On Wed, 28 Jul 2004, bangerth at ices dot utexas dot edu wrote:

> > The compound literal has automatic storage duration associated with the
> > enclosing block.  The code looks perfectly reasonable to me.
> 
> Ah, speaking of the devil :-))
> 
> Thanks, Joseph, for clarifying the matter!

I should perhaps note that I don't know what state the implementation of
compound literals as an extension for C++ is in, but clearly the semantics
used in C++ ought to follow those in C99 as closely as possible (modulo
C++ differences such as allowing non-constants in those of static storage
duration), meaning this case should work just as it does in C.  The C++
front end may need changing to use COMPOUND_LITERAL_EXPRs like C does
(rather than just CONSTRUCTORs).



-- 


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

[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-07-28 22:26 -------
Forgot to say that: the snippet compiles just fine when one uses the 
C frontend. It is the C++ front end that generates something that 
trips up gimplify_expr. 
 
W. 

-- 


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

[Bug middle-end/16809] [3.5 regression] ICE in gimplify_expr with initializer of arrays and pointers

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-08-25 10:38 -------
Fixed by Andrew's patch
http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01241.html


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|NEW                         |RESOLVED
           Keywords|accepts-invalid             |
         Resolution|                            |FIXED


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