This is the mail archive of the gcc-patches@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]

Re: [PATCH] Don't always instrument shifts (PR sanitizer/58413)


On Mon, 16 Sep 2013, Marek Polacek wrote:

> On Fri, Sep 13, 2013 at 07:18:24PM +0000, Joseph S. Myers wrote:
> > On Fri, 13 Sep 2013, Marek Polacek wrote:
> > 
> > > This is kind of fugly, but don't have anything better at the moment.
> > > 2013-09-13  Marek Polacek  <polacek@redhat.com>
> > > 
> > > 	PR sanitizer/58413
> > > c-family/
> > > 	* c-ubsan.c (ubsan_instrument_shift): Don't instrument
> > > 	an expression if we can prove it is correct.
> > 
> > Shouldn't the conditions used here for an expression being proved correct 
> > match those for instrumentation, i.e. depend on flag_isoc99 and on 
> > (cxx_dialect == cxx11 || cxx_dialect == cxx1y)?
> 
> I don't think so: for the unsigned case we could restrict it to C
> only, but it doesn't hurt doing it even for C++; in the signed case
> we care only about C, but we can't restrict it to flag_isoc99 only,
> since we need to prove the correctnes even for ANSI C.

I don't understand how this answers my question.

* The following principle applies: for any command-line options, with 
ubsan enabled, if an integer operation with particular (non-constant) 
operands is accepted by the sanitization code at runtime, the same 
operation with the same operand values (and types) as constants should be 
accepted at compile time (and at runtime) in contexts where an integer 
constant expression is required.  Does this patch make the compiler meet 
this principle, for all the different command-line options that vary what 
is accepted at runtime?

* The following principle also applies: for any command-line options, with 
ubsan enabled, if an integer operation with particular (non-constant) 
operands is rejected by the sanitization code at runtime, the same 
operation with the same operand values (and types) as constants should be 
rejected at compile time (or at runtime) in contexts where an integer 
constant expression is required.  Does this patch make the compiler meet 
this principle, for all the different command-line options that vary what 
is accepted at runtime?

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]