This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] UBSan unsafely uses VRP
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Marat Zakirov <m dot zakirov at samsung dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Yury Gribov <y dot gribov at samsung dot com>
- Date: Tue, 11 Nov 2014 18:04:01 +0100
- 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> <54623587 dot 8060403 at samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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_aggressive_loop_optimizationsno-strict-overflow and
> flag_strict_overflow.
Ah, you're right, we only have:
/* When instrumenting the pointers, we don't want to remove
the null pointer checks. */
if (opts->x_flag_sanitize & (SANITIZE_NULL | SANITIZE_NONNULL_ATTRIBUTE
| SANITIZE_RETURNS_NONNULL_ATTRIBUTE))
opts->x_flag_delete_null_pointer_checks = 0;
and as Joseph said, even that is misplaced, it should be done after all
options are processed, so that it isn't dependent on whether
-fsanitize=undefined or
--fdelete-null-pointer-checks/-faggressive-loop-optimizations come first.
Jakub