On Fri, 2011-08-19 at 08:44 -0400, Andrew MacLeod wrote: > On 08/19/2011 04:57 AM, Torvald Riegel wrote: > > On Wed, 2011-08-17 at 11:39 -0400, Andrew MacLeod wrote: > >> That would be quite ugly, and you get what you deserve if you do that. > >> I changed the builtins so that if you dont specify a compile time > >> constant in the memory model parameter, it will simply default to > >> __SYNC_MEM_SEQ_CST, which will always be safe. That is standard > >> compliant (verified), and if anyone is really unhappy about it, then the > >> c++ headers can be really uglified by adding a bunch of switch > >> statements to handle this twisted case. > > IMHO this behavior should be documented so that users will be aware of > > it, and it would be best if this would raise a warning. Note that I also > > cannot see any reason why a programmer might want to make barriers > > runtime-configurable, but silently adding overhead (perhaps the > > parameter was supposed to be a constant, but wasn't?) can lead to more > > confusion than necessary. > > > > The problem with issuing a warning is that anytime the compiler creates > a C++ atomic class and you use a method with a memory order, it usually > leaves an externally call-able method which has to take a runtime > value... so you'd see the warning on basically every compilation... > which in turn defeats the purpose of the warning.
Hmm. I would have assumed that the check that would raise warnings would be for actual calls, not for the instantiations. But that would probably require special handling of calls to the atomics class for all the integers and pointers (can atomic<T*> be handled as one thing?). So, if that's too much work, at least document the constraint somewhere? Torvald
