This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] UBSan unsafely uses VRP
- From: Marat Zakirov <m dot zakirov at samsung dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, Yury Gribov <y dot gribov at samsung dot com>
- Date: Tue, 11 Nov 2014 19:12:55 +0300
- Subject: Re: [RFC] UBSan unsafely uses VRP
- Authentication-results: sourceware.org; auth=none
- References: <5462170F dot 5040102 at samsung dot com> <20141111141521 dot GE5026 at tucnak dot redhat dot com> <CAFiYyc34tHcmZt2eH3rWB-NXL_EDxka=mSn+Lfv3wWAFMPHTDw at mail dot gmail dot com>
On 11/11/2014 05:26 PM, Richard Biener 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
On Tue, Nov 11, 2014 at 3:15 PM, Jakub Jelinek <firstname.lastname@example.org> 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 positive.
Example came from spec2006 perlbench:
int max = 0;
int t = INT_MAX - 20;
if (max < ext)
max = ext;
for (i = 0; i <= max; i++)
ext = 0;
t += i; <<< (*)
vrp pass here sets vrp('i') to [0..10] in assumption that 'freq[i]' wont
violate array bound (vrp uses loop iteration number calculation, see
adjust_range_with_scev in tree-vrp.c). This means that UBSAN_CHECK_ADD build
for (*) should be deleted as redundant (and actually it is deleted by vrp
pass). So if at the execution max = 30, freq != 0 uncaught overflow will
Well, if max is >= 10, then you should get -fsanitize=bounds error already.
-fsanitize=undefined already disables -faggressive-loop-optimizations,
perhaps it can also disable other optimizations (I thought deriving number
of iterations from assuming undefined behavior doesn't occur in loop stmts
is already guarded by -faggressive-loop-optimizations though).
You could use -fno-strict-overflow ...
There are also some unsafe code in functions
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).
Indeed. Note that the strict-overflow warnings are already a bad burden
on VRP quality - a way out to me was always to track two lattices,
one assuming strict-overflow and one assuming wrapping overflow.
For strict-overflow warnings you then can compare simplification outcome
against two lattices and warn if the result differs. Instead of that odd