>> Feel free to submit as-is to get bots green and make progress. See comments below -- we should discuss those separately. I'll >> try to send a cfe-dev email when I can? I'd better commit the final thing. Bots are not a problem, I'll disable the only failing test for now.
>> I actually find it really unfortunate that this attribute and the -Wthread-safety escape hatch attribute are the same. I suspect there >> are many scenarios where users can't accomodate the reduced programming model checked by -Wthread-safety, use this ? >> attribute to escape that analysis, and would still like TSan to point out the actual races. >>Thoughts? There are pros and cons here. If we add yet another attribute to disable tsan we will have two. Users will be confused. They will be adding one instead of another. But yes, we will lose finer granularity. I slightly prefer to to have one attribute here rather than two, but I am open to other suggestions. >> I think we should aim for more consistency across the attribute names. I think that will benefit users more than anything else... >> Is there a reason not to tie these to the 'sanitize' naming scheme? Will we have to rename the existing no_address_safety_analysis then? That's not trivial given that gcc already uses it too. Also, the idea behind these attributes was that we don't tie them to particular tools. http://llvm-reviews.chandlerc.com/D390 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
