This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: private static object construction bug?
- From: Fergus Henderson <fjh at cs dot mu dot OZ dot AU>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Joe Buck <Joe dot Buck at synopsys dot com>, "joseph dot buehler at spirentcom dot com" <joseph dot buehler at spirentcom dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 6 Aug 2002 08:51:28 +1000
- Subject: Re: private static object construction bug?
- References: <200208051648.JAA22947@atrus.synopsys.com> <43960000.1028581098@warlock.codesourcery.com>
On 05-Aug-2002, Mark Mitchell <mark@codesourcery.com> wrote:
>
>
> --On Monday, August 05, 2002 09:48:49 AM -0700 Joe Buck
> <Joe.Buck@synopsys.com> wrote:
>
> >
> >> I entered a bug report on this (7458) that was promptly closed by
> >> a Cygwin developer, but I believe incorrectly so, so I am posting here.
> >
> > I've squashed the example a bit, but here it is:
> >
> > struct the_struct {
> > int i;
> > the_struct() { i = 0;}
> > ~the_struct() { i = 1;}
> > };
> >
> > void function() {
> > static the_struct temporary;
> > }
> >
> > The decision to close the bug report was correct.
>
> Actually, I think it was only sort-of correct.
>
> The ABI specifies functions a compiler can use to get thread safe
> construction of local temporaries.
Did you mean to say "local statics"?
I don't see what would be non-thread-safe about constructing
local temporaries, since temporaries have automatic storage
duration and get constructed on the thread's stack.
> The compiler can choose not to
> use them. G++ makes that choice, but partly due to not getting
> around to calling the functions. The intended code sequence is
> not really any slower after the object has been constructed.
>
> Right now, we do this approximately (there are exceptions to worry
> about!):
>
> if (!guard) {
> guard = 1;
> // Construct variable.
> }
>
> The new sequence would be:
>
> if (!guard) {
> __cxa_guard_acquire (&guard); // I forget the exact name.
> // Construct variable.
> __cxa_guard_release (&guard):
> }
Hmm. I don't understand how this would solve the problem.
It would prevent simultaneous construction, but the
variable could still get constructed twice, couldn't it?
That could still lead to problems.
A slightly different code sequence could solve the double-construction
problem.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.