[PATCH][PR sanitizer/64354] Define __SANITIZE_THREAD__ and __SANITIZE_UNDEFINED__ macros if corresponding switches are enabled.

Yuri Gribov tetra2005@gmail.com
Wed May 18 17:38:00 GMT 2016


On Wed, May 18, 2016 at 8:36 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, May 18, 2016 at 08:33:53PM +0300, Maxim Ostapenko wrote:
>> when compiling with -fsanitize=address we define __SANITIZE_ADDRESS__
>> macros, but we don't do this for -fsanitize=thread and -fsanitize=undefined.
>> Perhaps we should be more symmetric here and define corresponding
>> __SANITIZE_THREAD__ and __SANITIZE_UNDEFINED__ macros respectively?
>>
>> I added two simple test cases to c-c++-common/{ub, t}san/ directories that
>> just verify if __SANITIZE_THREAD__ (__SANITIZE_UNDEFINED__) is defined. Is
>> that a proper way how we check that the macros defined correctly? Does this
>> patch looks reasonable?
>
> I can understand __SANITIZE_THREAD__, but I fail to see what
> __SANITIZE_UNDEFINED__ would be good for, especially when it is not just
> a single sanitizer, but dozens of them.

Some low-level codes do nasty things like unaligned or NULL memory
accesses. This would allow them to selectively disable UBSan. Good
point about different UB checks though.

-Y



More information about the Gcc-patches mailing list