On Wed, 4 Sep 2013, Bernd Edlinger wrote: > How about this for a compromise: Let's make the > default of -fstrict-volatile-bitfields an optional > configure argument for gcc 4.9, that can be used for every > target, even for X86_64 of you want ?
I think it's generally a bad idea for semantic options, such as --param allow-store-data-races=1, to depend on configure options like that (as opposed to non-semantic options such as what architecture variant is optimized for by default). Of course, *if* the user passes --param allow-store-data-races=1, then -fstrict-volatile-bitfields becomes non-semantic at the C/C++ language level and it's reasonable for an architecture to default it to on. Any configure option related to this should maybe be a stronger version of --disable-threads, meaning that not only is no thread library support to be included in any of GCC's libraries but that the compiler will never be used to build any code for which any concurrency or data race issues arise (including through signals) and so --param allow-store-data-races=1 can be the default (along with any target-specific consequences of that default). Call it --enable-data-races and require it to be used along with --disable-threads, or something like that. -- Joseph S. Myers jos...@codesourcery.com
