This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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)?
I wish we had some test to check that sanitizer optimizations are indeed conservative.I think most of the tests we have are tested with various optimization levels.
Existing tests are really a joke when we consider interblock optimization. Most don't even contain any non-trivial control flow.
-Y
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |