[RFC] UBSan unsafely uses VRP

[Yury Gribov]

On 11/12/2014 04:26 PM, Jakub Jelinek wrote:
> On Wed, Nov 12, 2014 at 12:58:37PM +0300, Yury Gribov wrote:
>> On 11/12/2014 11:45 AM, Marek Polacek wrote:
>>> On Wed, Nov 12, 2014 at 11:42:39AM +0300, Yury Gribov wrote:
>>>> On 11/11/2014 05:15 PM, Jakub Jelinek wrote:
>>>>>> There are also some unsafe code in functions
>>>>>> ubsan_expand_si_overflow_addsub_check, ubsan_expand_si_overflow_mul_check
>>>>>> which uses get_range_info to reduce checks number. As seen before vrp usage
>>>>>> for sanitizers may decrease quality of error detection.
>>>>>
>>>>> Using VRP is completely intentional there, we don't want to generate too
>>>>> slow code if you decide you want to optimize your code (for -O0 VRP isn't
>>>>> performed of course).
>>>>
>>>> On the other hand detection quality is probably more important than
>>>> important regardless of optimization level. When I use a checker, I don't
>>>> want it to miss bugs due to overly aggressive optimization.
>>>
>>> Yes, but as said above, VRP is only run with >-O2 and -Os.
>>
>> Hm, I must be missing something.  99% of users will only run their code
>> under -O2 because it'll be too slow otherwise.  Why should we penalize them
>> for this by lowering analysis quality?  Isn't error detection the main goal
>> of sanitizers (performance being the secondary at best)?
>
> But, if -O0 isn't too slow for them, having unnecessary bloat even at -O2
> is bad the same.  But not using VRP at all, you are giving up all the cases
> where you know something won't overflow because you e.g. sign extend
> or zero extend from some smaller type, sum op such values, and something
> with constant, or you can use a cheaper code to multiply etc.
> Turning off -faggressive-loop-optimizations is certainly the right thing for
> -fsanitize=undefined (any undefined I'd say), so are perhaps selected other
> optimizations.
>
> 	Jakub
>