[C++] document order of C++ ctors and attribute constructor is unspecified

Submitted by Martin Sebor on March 15, 2017, 10:59 p.m.

Details

Message ID e2e8e82b-dec3-5b9e-2766-74f61b94ff83@gmail.com
State New
Headers show

Commit Message

Martin Sebor March 15, 2017, 10:59 p.m.
In bug 52477 - Wrong initialization order?  attribute constructor
vs static data access, the reporter expects C++ objects with static
storage duration to have their ctors called in the same order as
those of functions declared with attribute constructor interleaved
with them.

In his comment on the bug Richard opines that relying on the order
is undefined.  The attached patch updates the manual to make this
clear.

Jason, can you please review it for 7.0?

Martin

Comments

Jason Merrill March 16, 2017, 4:49 a.m.
On Wed, Mar 15, 2017 at 6:59 PM, Martin Sebor <msebor@gmail.com> wrote:
> In bug 52477 - Wrong initialization order?  attribute constructor
> vs static data access, the reporter expects C++ objects with static
> storage duration to have their ctors called in the same order as
> those of functions declared with attribute constructor interleaved
> with them.
>
> In his comment on the bug Richard opines that relying on the order
> is undefined.  The attached patch updates the manual to make this
> clear.

I disagree with that comment, and have added one of my own, but I
think your patch is appropriate for GCC 7 since we aren't going to fix
it in this release.

Jason
Martin Sebor March 16, 2017, 3:22 p.m.
On 03/15/2017 10:49 PM, Jason Merrill wrote:
> On Wed, Mar 15, 2017 at 6:59 PM, Martin Sebor <msebor@gmail.com> wrote:
>> In bug 52477 - Wrong initialization order?  attribute constructor
>> vs static data access, the reporter expects C++ objects with static
>> storage duration to have their ctors called in the same order as
>> those of functions declared with attribute constructor interleaved
>> with them.
>>
>> In his comment on the bug Richard opines that relying on the order
>> is undefined.  The attached patch updates the manual to make this
>> clear.
>
> I disagree with that comment, and have added one of my own, but I
> think your patch is appropriate for GCC 7 since we aren't going to fix
> it in this release.

Okay, thanks.  In that case I should probably word it slightly
differently.  I've added "at present" below to imply (hint) that
this might change in the future.  I'll go with this unless you
have a different suggestion.

However, <ins>at present, </ins>the order in which constructors
for C++ objects with static storage duration and functions decorated
with attribute @code{constructor} are invoked is unspecified.  In
mixed declarations, attribute @code{init_priority} can be used to
impose a specific ordering.

Martin
Jason Merrill March 16, 2017, 6:49 p.m.
On Thu, Mar 16, 2017 at 11:22 AM, Martin Sebor <msebor@gmail.com> wrote:
> On 03/15/2017 10:49 PM, Jason Merrill wrote:
>>
>> On Wed, Mar 15, 2017 at 6:59 PM, Martin Sebor <msebor@gmail.com> wrote:
>>>
>>> In bug 52477 - Wrong initialization order?  attribute constructor
>>> vs static data access, the reporter expects C++ objects with static
>>> storage duration to have their ctors called in the same order as
>>> those of functions declared with attribute constructor interleaved
>>> with them.
>>>
>>> In his comment on the bug Richard opines that relying on the order
>>> is undefined.  The attached patch updates the manual to make this
>>> clear.
>>
>> I disagree with that comment, and have added one of my own, but I
>> think your patch is appropriate for GCC 7 since we aren't going to fix
>> it in this release.
>
> Okay, thanks.  In that case I should probably word it slightly
> differently.  I've added "at present" below to imply (hint) that
> this might change in the future.  I'll go with this unless you
> have a different suggestion.
>
> However, <ins>at present, </ins>the order in which constructors
> for C++ objects with static storage duration and functions decorated
> with attribute @code{constructor} are invoked is unspecified.  In
> mixed declarations, attribute @code{init_priority} can be used to
> impose a specific ordering.

Sounds good.

Jason

Patch hide | download patch | download mbox

PR c++/52477 - Wrong initialization order? __attribute__((constructor)) vs static data access

gcc/ChangeLog:

	PR c++/52477
	* doc/extend.texi (attribute constructor): Mention order of C++ ctors.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 143a7b7..159f1be 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2510,7 +2510,11 @@  if you have a constructor that allocates a resource and a destructor
 that deallocates the same resource, both functions typically have the
 same priority.  The priorities for constructor and destructor
 functions are the same as those specified for namespace-scope C++
-objects (@pxref{C++ Attributes}).
+objects (@pxref{C++ Attributes}).  However, the order in which
+constructors for C++ objects with static storage duration and functions
+decorated with attribute @code{constructor} are invoked is unspecified.
+In mixed declarations, attribute @code{init_priority} can be used to
+impose a specific ordering.
 
 @item deprecated
 @itemx deprecated (@var{msg})