Bug 66172 - -fno-threadsafe-statics suppresses guard functions but not guard variables
Summary: -fno-threadsafe-statics suppresses guard functions but not guard variables
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.9.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 66173 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-05-16 05:17 UTC by Marc Singer
Modified: 2015-05-16 06:11 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Source file demonstrating that the guard variable isn't suppressed. (203 bytes, text/plain)
2015-05-16 05:17 UTC, Marc Singer 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Singer 2015-05-16 05:17:27 UTC 
The use of the -fno-threadsafe-statics eliminates the function references to the guard functions,

__cxa_guard_acquire
__cxa_guard_release


but it doesn't eliminate the variables used to guard the initialization.  A compiled version of the attached file using the g++ command line therein generated no references to the guard functions, but the guard variable remains.

# nm -C guard | grep guard
0000000000600a88 b guard variable for f()::a
Comment 1 Marc Singer 2015-05-16 05:37:14 UTC 
I neglected to include the version information:

# g++ --version
g++ (Debian 4.9.2-10) 4.9.2
Comment 2 Andrew Pinski 2015-05-16 05:59:02 UTC 
You need the variable even without thread safe ones because calling the function twice means it gets initlized only once rather twice. There is no other way around this because the variable only gets initialized if the function is called.
Comment 3 Marc Singer 2015-05-16 06:06:54 UTC 
I've come to the same conclusion.  My hope was that I could eliminate the guard and force the compiler to initialize block scoped statics at the start of execution.  It looks like the standard stands in the way of this simplification.
Comment 4 Andrew Pinski 2015-05-16 06:11:05 UTC 
*** Bug 66173 has been marked as a duplicate of this bug. ***