public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Dara Hazeghi <dhazeghi@yahoo.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: c++/10776: [3.3 regression] Large aggregate initializers cause GCC to fail
Date: Wed, 14 May 2003 22:06:00 -0000 [thread overview]
Message-ID: <20030514220601.20079.qmail@sources.redhat.com> (raw)
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
next reply other threads:[~2003-05-14 22:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-14 22:06 Dara Hazeghi [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-05-14 21:36 Pete Gonzalez
2003-05-14 14:46 Pete Gonzalez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030514220601.20079.qmail@sources.redhat.com \
--to=dhazeghi@yahoo.com \
--cc=gcc-prs@gcc.gnu.org \
--cc=nobody@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).