[compiler-rt] r210346 - tsan: fix clang warning:

David Blaikie dblaikie at gmail.com
Fri Jun 6 13:50:41 PDT 2014


Ted - any thoughts/context here?

On Fri, Jun 6, 2014 at 1:45 PM, Richard Trieu <rtrieu at google.com> wrote:
> On Fri, Jun 6, 2014 at 1:28 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> On Fri, Jun 6, 2014 at 1:21 PM, Richard Trieu <rtrieu at google.com> wrote:
>> > Looking at the code for tautological compares against zero, there
>> > already is
>> > an exception for macros and enum constants.
>>
>> Any particular gut feeling/stats/logic behind excepting enum constants
>> but not other constants? It doesn't seem to me like one would be more
>> likely to be a cause of false positives as the other.
>
>
> I'm just stating what the code says.  The code for that actually predates
> me.  It was added in r114695 by Ted Kremenek and references the bug
> rdar://problem/8414119
>>
>>
>> > I think adding an exception for
>> > being defined in an #if block would be a good addition, however I am not
>> > sure if that information is propagated past the preprocessor.
>> >
>> >
>> >
>> > On Fri, Jun 6, 2014 at 9:18 AM, David Blaikie <dblaikie at gmail.com>
>> > wrote:
>> >>
>> >> Not sure - but I know we're going to have to figure some of these
>> >> things out for -Wunreachable-code and similar things (I know some of
>> >> these heuristics have already been implemented in -Wunreachable-code,
>> >> perhaps we could reuse them for other things like this)
>> >>
>> >> I'd wager that even just "the constant is not a literal" (either a
>> >> global constant, or a macro, etc) might be enough signal in this case.
>> >> Perhaps Richard (cc'd) has some idea about how many of the hits on
>> >> this warning in google were with literals versus not.
>> >>
>> >> On Fri, Jun 6, 2014 at 9:15 AM, Dmitry Vyukov <dvyukov at google.com>
>> >> wrote:
>> >> > how would it figure out that something is implementation-defined?
>> >> >
>> >> >
>> >> > On Fri, Jun 6, 2014 at 8:13 PM, David Blaikie <dblaikie at gmail.com>
>> >> > wrote:
>> >> >> Should we try to fix the Clang warning so it doesn't fire on
>> >> >> possibly-implementation-defined constants like this?
>> >> >>
>> >> >> On Fri, Jun 6, 2014 at 8:51 AM, Dmitry Vyukov <dvyukov at google.com>
>> >> >> wrote:
>> >> >>> Author: dvyukov
>> >> >>> Date: Fri Jun  6 10:51:20 2014
>> >> >>> New Revision: 210346
>> >> >>>
>> >> >>> URL: http://llvm.org/viewvc/llvm-project?rev=210346&view=rev
>> >> >>> Log:
>> >> >>> tsan: fix clang warning:
>> >> >>> comparison of unsigned expression >= 0 is always true
>> >> >>>
>> >> >>>
>> >> >>> Modified:
>> >> >>>     compiler-rt/trunk/lib/tsan/rtl/tsan_platform.h
>> >> >>>
>> >> >>> Modified: compiler-rt/trunk/lib/tsan/rtl/tsan_platform.h
>> >> >>> URL:
>> >> >>>
>> >> >>> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_platform.h?rev=210346&r1=210345&r2=210346&view=diff
>> >> >>>
>> >> >>>
>> >> >>> ==============================================================================
>> >> >>> --- compiler-rt/trunk/lib/tsan/rtl/tsan_platform.h (original)
>> >> >>> +++ compiler-rt/trunk/lib/tsan/rtl/tsan_platform.h Fri Jun  6
>> >> >>> 10:51:20
>> >> >>> 2014
>> >> >>> @@ -131,6 +131,8 @@ static inline bool IsAppMem(uptr mem) {
>> >> >>>  #if defined(TSAN_COMPAT_SHADOW) && TSAN_COMPAT_SHADOW
>> >> >>>    return (mem >= kLinuxAppMemBeg && mem < kAppMemGapBeg) ||
>> >> >>>           (mem >= kAppMemGapEnd   && mem <= kLinuxAppMemEnd);
>> >> >>> +#elif defined(TSAN_GO)
>> >> >>> +  return mem <= kLinuxAppMemEnd;
>> >> >>>  #else
>> >> >>>    return mem >= kLinuxAppMemBeg && mem <= kLinuxAppMemEnd;
>> >> >>>  #endif
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> llvm-commits mailing list
>> >> >>> llvm-commits at cs.uiuc.edu
>> >> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>> >
>
>



More information about the llvm-commits mailing list