Re: c++/10776: [3.3 regression] Large aggregate initializers cause GCC to fail

Re: c++/10776: [3.3 regression] Large aggregate initializers cause GCC to fail

[Pete Gonzalez]

The following reply was made to PR c++/10776; it has been noted by GNATS.

From: Pete Gonzalez <gonz@ratloop.com>
To: gcc-prs@gcc.gnu.org,gcc-bugs@gcc.gnu.org,gcc-gnats@gcc.gnu.org,
 Dara Hazeghi <dhazeghi@yahoo.com>
Cc:  
Subject: Re: c++/10776: [3.3 regression] Large aggregate initializers
  cause GCC to fail
Date: Wed, 14 May 2003 10:40:59 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10776 
 
 
 The problem seems to be the "&data::tex::tackytexture" expression
 inside the array, i.e. if I replace all instances with "0", the
 code compiles successfully:
 
 >static const TOutdoorMapData::TTriangleItem data_triangleItems[2382] = {
 >   {
 >     0, // &data::tex::tackytexture,
 >     0,
 >     { { 87, 104, 0, -778 },
 >       { 95, 106, 21, -799 },
 >       { 89, 109, 0, -799 } }
 >   },
 
 However, this crashes:
 
 >const TBitmap *nullBmp = 0;
 >
 >static const TOutdoorMapData::TTriangleItem data_triangleItems[2382] = {
 >   {
 >     nullBmp,
 >     0,
 >     { { 87, 104, 0, -778 },
 >       { 95, 106, 21, -799 },
 >       { 89, 109, 0, -799 } }
 >   },
 
 I'll let you know if I find anything else.  Thanks for the quick response.
 
 -Pete
 

Re: c++/10776: [3.3 regression] Large aggregate initializers cause GCC to fail

[Dara Hazeghi]

The following reply was made to PR c++/10776; it has been noted by GNATS.

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: Pete Gonzalez <gonz@ratloop.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/10776: [3.3 regression] Large aggregate initializers   cause GCC to fail
Date: Wed, 14 May 2003 15:01:45 -0700 (PDT)

 --- Pete Gonzalez <gonz@ratloop.com> wrote:
 > At 01:28 PM 5/14/2003, Dara Hazeghi wrote:
 > >Well thank you for the report, and the analysis.
 > I'm
 > >not certain how likely this is to get fixed in
 > 3.3.X,
 > >but it certainly doesn't hurt to have the report.
 > 
 > We've worked around it.  The larger cause is that,
 > in an aggregate
 > initializer, referencing an external pointer causes
 > a
 > "__static_initialization_and_destruction" function
 > to be generated.
 > GCC implements this with a bunch of assignment
 > instructions, and
 > with 2,500 entries in the array, I guess it
 > translates into more
 > code than the optimizer can handle.  The general
 > solution would be
 > to replace this with a memcpy() -- maybe that's what
 > 3.4 does?
 > For my specific problem, I redesigned the data types
 > so that the
 > initialization function is not created, which is
 > much more efficient
 > in both speed and size.
 > 
 > In this light, the bug becomes obscure and can
 > probably be closed.
 > My suggestion is to add some documentation
 > explaining the rules
 > behind the compiler's decision to create
 > initialization functions.
 > This is particularly important for embedded systems,
 > where the
 > initializers cause const data to end up in RAM.
 
 Well, as long as the bug is present on an active
 branch, I think we should keep it open. But it would
 definitely be good to document this behavior
 somewhere... Perhaps in a comment in the functions in
 the compiler which do this...
 
 Dara
 
 __________________________________
 Do you Yahoo!?
 The New Yahoo! Search - Faster. Easier. Bingo.
 http://search.yahoo.com

Re: c++/10776: [3.3 regression] Large aggregate initializers cause GCC to fail

[Pete Gonzalez]

The following reply was made to PR c++/10776; it has been noted by GNATS.

From: Pete Gonzalez <gonz@ratloop.com>
To: Dara Hazeghi <dhazeghi@yahoo.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/10776: [3.3 regression] Large aggregate initializers 
  cause GCC to fail
Date: Wed, 14 May 2003 17:35:29 -0400

 At 01:28 PM 5/14/2003, Dara Hazeghi wrote:
 >Well thank you for the report, and the analysis. I'm
 >not certain how likely this is to get fixed in 3.3.X,
 >but it certainly doesn't hurt to have the report.
 
 We've worked around it.  The larger cause is that, in an aggregate
 initializer, referencing an external pointer causes a
 "__static_initialization_and_destruction" function to be generated.
 GCC implements this with a bunch of assignment instructions, and
 with 2,500 entries in the array, I guess it translates into more
 code than the optimizer can handle.  The general solution would be
 to replace this with a memcpy() -- maybe that's what 3.4 does?
 For my specific problem, I redesigned the data types so that the
 initialization function is not created, which is much more efficient
 in both speed and size.
 
 In this light, the bug becomes obscure and can probably be closed.
 My suggestion is to add some documentation explaining the rules
 behind the compiler's decision to create initialization functions.
 This is particularly important for embedded systems, where the
 initializers cause const data to end up in RAM.
 
 Thanks again for your help,
 -Pete