Bugs/non-portable assumptions in libstdc++

Chris Lattner sabre@nondot.org
Fri Nov 19 17:31:00 GMT 2004

Hi all,

I've recently had a Truely Horrible Debugging Experience (tm), which I
have tracked down to something that I believe is a libstdc++ bug.  Here's
an example:


    // NB: This class is always a static data member, and thus can be
    // counted on to be zero-initialized.
    /// Constructor.
    id() { }

>From my understanding of the standard, I don't think that this is a legal
optimization to make.  You are assuming that unconstructed memory starts
out zero initialized, which is not always the case.  Granted, this is the
case on unix and many other systems for static members, because the OS
zeros out pages before giving them to the process.  However, I believe it
still is making non-standard assumptions.

If you're curious, this is breaking with llvmg++, because the optimizer
keeps track of uninitialized memory and optimizes based off of that
information.  In this case, it's seeing loads from uninitialized data, and
just deletes them.

With this as background, I have two questions for the list: 1. Do you
agree that this is really a bug/non-portable assumption?  2. Do you know
of any other places in libstdc++ where this 'optimization' (eliding the
initialization) is done?

Thanks for the help, libstdc++ is great work!



More information about the Libstdc++ mailing list