On Thu, Jul 03, 2014 at 12:46:35PM +0200, Jakub Jelinek wrote:
> On Thu, Jul 03, 2014 at 12:41:46PM +0200, Marek Polacek wrote:
> > On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote:
> > > On Fri, 20 Jun 2014, Marek Polacek wrote:
> > > +@item -fsanitize=bounds
> > > +@opindex fsanitiz
On Thu, Jul 03, 2014 at 12:41:46PM +0200, Marek Polacek wrote:
> On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote:
> > On Fri, 20 Jun 2014, Marek Polacek wrote:
> > +@item -fsanitize=bounds
> > +@opindex fsanitize=bounds
> > +
> > +This option enables instrumentation of array bounds.
On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote:
> On Fri, 20 Jun 2014, Marek Polacek wrote:
> +@item -fsanitize=bounds
> +@opindex fsanitize=bounds
> +
> +This option enables instrumentation of array bounds. Various out of bounds
> +accesses are detected. Flexible array members ar
On Fri, 20 Jun 2014, Marek Polacek wrote:
+@item -fsanitize=bounds
+@opindex fsanitize=bounds
+
+This option enables instrumentation of array bounds. Various out of bounds
+accesses are detected. Flexible array members are not instrumented, as well
+as initializers of variables with static storag
On Thu, Jun 19, 2014 at 07:47:54PM +0200, Jakub Jelinek wrote:
> On Thu, Jun 19, 2014 at 04:56:53PM +0200, Marek Polacek wrote:
> > + /* Don't instrument this FMA-like array in non-strict
>
> Also, please don't use FMA to mean flexible member array, it is
> flexible array member, but more import
I don't have any comments on this patch.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, Jun 20, 2014 at 11:39:23AM +0200, Jakub Jelinek wrote:
> On Fri, Jun 20, 2014 at 11:34:26AM +0200, Marek Polacek wrote:
> > On Fri, Jun 20, 2014 at 10:57:47AM +0200, Jakub Jelinek wrote:
> > > On Fri, Jun 20, 2014 at 10:43:04AM +0200, Marek Polacek wrote:
> > > > +
> > > > +/* Internal
On Fri, Jun 20, 2014 at 11:34:26AM +0200, Marek Polacek wrote:
> On Fri, Jun 20, 2014 at 10:57:47AM +0200, Jakub Jelinek wrote:
> > On Fri, Jun 20, 2014 at 10:43:04AM +0200, Marek Polacek wrote:
> > > +
> > > +/* Internal function code. */
> > > +ENUM_BITFIELD(internal_fn) ifn : 5;
> >
>
On Fri, Jun 20, 2014 at 10:57:47AM +0200, Jakub Jelinek wrote:
> On Fri, Jun 20, 2014 at 10:43:04AM +0200, Marek Polacek wrote:
> > +
> > +/* Internal function code. */
> > +ENUM_BITFIELD(internal_fn) ifn : 5;
>
> Any reason for the " : 5" here? I mean, the union also contains
> unsigned
On Fri, Jun 20, 2014 at 10:43:04AM +0200, Marek Polacek wrote:
> +
> +/* Internal function code. */
> +ENUM_BITFIELD(internal_fn) ifn : 5;
Any reason for the " : 5" here? I mean, the union also contains
unsigned int, so it doesn't hurt if you use full 32 bits for it there,
and it should
On Thu, Jun 19, 2014 at 07:19:31PM +0200, Jakub Jelinek wrote:
> > + case IFN_UBSAN_BOUNDS:
> > + ubsan_expand_bounds_btn (&gsi);
> > + break;
> > default:
>
> Why *_btn instead of *_ifn ?
Remnant from when I was using __builtin.ubsan instead of the internal
On Thu, Jun 19, 2014 at 04:56:53PM +0200, Marek Polacek wrote:
> + /* Don't instrument this FMA-like array in non-strict
Also, please don't use FMA to mean flexible member array, it is
flexible array member, but more importantly, FMA is used for fused
multiply-add, so IMHO it is better to spel
Hi!
On Thu, Jun 19, 2014 at 04:56:53PM +0200, Marek Polacek wrote:
Thanks for working on this.
> --- gcc/asan.c
> +++ gcc/asan.c
> @@ -2761,6 +2761,9 @@ pass_sanopt::execute (function *fun)
> case IFN_UBSAN_NULL:
> ubsan_expand_null_ifn (gsi);
> break;
> +
On Thu, Jun 19, 2014 at 04:56:53PM +0200, Marek Polacek wrote:
> Regtested/bootstrapped on x86_64-linux. How does this look?
Now even bootstrap-ubsan passed, with 92258 runtime errors:
index 1 out of bounds for type 'rtunion [1]' - heh.
Marek
On Mon, Jun 16, 2014 at 01:23:04PM +0200, Jakub Jelinek wrote:
> On Mon, Jun 16, 2014 at 12:39:07PM +0200, Marek Polacek wrote:
> > Jason/Joseph, could you please look at the C++/C FE parts?
>
> As mentioned on IRC, you need to differentiate between taking address
> and not taking address.
>
> st
On Mon, Jun 16, 2014 at 12:39:07PM +0200, Marek Polacek wrote:
> Jason/Joseph, could you please look at the C++/C FE parts?
As mentioned on IRC, you need to differentiate between taking address
and not taking address.
struct S { int a; int b; } s[4], *t;
int *a, *b, *c;
void *d;
int e[4][4];
voi
The following is quite large patch for something rather simple as
bounds checking. The idea is to instrument ARRAY_REFs in such a way
that iff the array index is greater than the max value of the TYPE_DOMAIN
of the ARRAY_TYPE, call __ubsan builtin and report error.
My first attempts failed, howev
17 matches
Mail list logo
