This is an archive of the discontinued LLVM Phabricator instance.

add __attribute__ no_uninitialized_checks. Map no_uninitialized_checks/no_thread_safety_analysis to LLVM function attributes.
Needs ReviewPublic

Authored by kcc on Feb 11 2013, 2:21 AM.

Details

Summary
  • Adding attribute((no_uninitialized_checks))
  • Mapping attribute((no_uninitialized_checks)) to llvm::Attribute::UninitializedChecks (under MSAN)
  • Mapping attribute((no_thread_safety_analysis)) llvm::Attribute::ThreadSafety (under TSAN)
  • Updating Docs & Tests

Diff Detail

Event Timeline

gribozavr added inline comments.Feb 11 2013, 5:07 AM
lib/Sema/SemaDeclAttr.cpp
655–656

Can we promote this to an error? There's no existing code that (mis)uses this attribute, so there should be no compatibility concerns.

Please also add tests for this warning or error, and for checkAttributeNumArgs() condition above.

kcc added inline comments.Feb 11 2013, 6:54 AM
lib/Sema/SemaDeclAttr.cpp
655–656

I copy-pasted the code from the pre-existing code for no_thread_safety_analysis
and I did not fund such tests for that one.
I guess we need tests for all 3 (+ no_address_safety_analysis).
Where is the best place for them? Do you know similar existing tests?

Yes, I guess we can make it an error. Will do the change tomorrow.

gribozavr added inline comments.Feb 11 2013, 7:04 AM
lib/Sema/SemaDeclAttr.cpp
655–656

There are tests for no_address_safety_analysis in test/SemaCXX/warn-thread-safety-parsing.cpp (lines 93-121).

For this attribute, tests should probably go into test/SemaCXX/attr-no-uninitialized-checks.cpp (because we don't do static analysis, it is attr- instead of warn-).

kcc updated this revision to Unknown Object (????).Feb 12 2013, 2:41 AM

Promoted warnings to errors for no_uninitialized_checks and no_address_safety_analysis and added tests

gribozavr added inline comments.Feb 12 2013, 8:44 AM
test/SemaCXX/attr-no-address-safety-analysis.cpp
19 ↗(On Diff #951)

Extra semicolon here.

test/SemaCXX/attr-no-uninitialized-checks.cpp
19 ↗(On Diff #951)

Extra semicolon here.

kcc updated this revision to Unknown Object (????).Feb 12 2013, 9:10 PM

removed redundant ';'

chandlerc accepted this revision.Feb 13 2013, 10:29 AM

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?

docs/LanguageExtensions.rst
1609

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?

docs/MemorySanitizer.rst
83

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?

kcc added a comment.Feb 13 2013, 10:46 PM

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.

kcc added a comment.Feb 15 2013, 4:09 AM

Any other thoughts, suggestions?

Looks like patch was not committed.

This revision now requires review to proceed.Oct 5 2016, 4:26 PM
void removed a reviewer: void.Apr 17 2018, 2:31 PM