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 f
On 11/12/2014 04:26 PM, Jakub Jelinek wrote:
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
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_overf
On Wed, Nov 12, 2014 at 01:04:58PM +0300, Marat Zakirov wrote:
>
> On 11/12/2014 11:45 AM, Marek Polacek wrote:
> >Yes, but as said above, VRP is only run with >-O2 and -Os.
> You meant >= -O2?
Yes.
Marek
On 11/12/2014 11:45 AM, Marek Polacek wrote:
Yes, but as said above, VRP is only run with >-O2 and -Os.
You meant >= -O2?
--Marat
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
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 b
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.
On Tue, Nov 11, 2014 at 07:12:55PM +0300, Marat Zakirov wrote:
> It is seems that -fsanitize=something do not set
> flag_aggressive_loop_optimizations to 0 in current GCC version. I made a
> watchpoint on it but changes after init_options_struct weren't found. I will
> make fix for both flag_aggres
On 11/11/2014 05:26 PM, Richard Biener wrote:
On Tue, Nov 11, 2014 at 3:15 PM, Jakub Jelinek wrote:
On Tue, Nov 11, 2014 at 05:02:55PM +0300, Marat Zakirov wrote:
I found that UBSan uses vrp pass to optimize generated checks. Keeping in
mind that vrp pass is about performance not stability I f
On Tue, Nov 11, 2014 at 3:15 PM, Jakub Jelinek wrote:
> On Tue, Nov 11, 2014 at 05:02:55PM +0300, Marat Zakirov wrote:
>> I found that UBSan uses vrp pass to optimize generated checks. Keeping in
>> mind that vrp pass is about performance not stability I found example where
>> UBSan may skip true
On Tue, Nov 11, 2014 at 05:02:55PM +0300, Marat Zakirov wrote:
> I found that UBSan uses vrp pass to optimize generated checks. Keeping in
> mind that vrp pass is about performance not stability I found example where
> UBSan may skip true positive.
>
> Example came from spec2006 perlbench:
>
> in
Hi all!
I found that UBSan uses vrp pass to optimize generated checks. Keeping
in mind that vrp pass is about performance not stability I found example
where UBSan may skip true positive.
Example came from spec2006 perlbench:
int ext;
int
Perl_do_sv_dump()
{
int freq[10];
int i;
13 matches
Mail list logo
