On Wed, Jul 22, 2015 at 07:26:22PM +0200, Marek Polacek wrote:
> In this testcase we were generating an uninitialized variable when doing
> -fsanitize=shift,bounds sanitization. The shift instrumentation is done
> first; after that, the IR looks like
>
> res[i] = (m > 31) ? __ubsan (... tab[i]
On Thu, Jul 23, 2015 at 02:39:05PM +0200, Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 02:20:51PM +0200, Marek Polacek wrote:
> > > So isn't the bug instead that the UBSAN_BOUNDS generating code doesn't
> > > unshare? Of course, these two functions use op0 and/or op1 sometimes
> > > multiple tim
On Thu, Jul 23, 2015 at 02:20:51PM +0200, Marek Polacek wrote:
> > So isn't the bug instead that the UBSAN_BOUNDS generating code doesn't
> > unshare? Of course, these two functions use op0 and/or op1 sometimes
> > multiple times too and thus they might want to unshare too, but I'd have
> > expect
On Wed, Jul 22, 2015 at 07:43:23PM +0200, Jakub Jelinek wrote:
> On Wed, Jul 22, 2015 at 07:26:22PM +0200, Marek Polacek wrote:
> > In this testcase we were generating an uninitialized variable when doing
> > -fsanitize=shift,bounds sanitization. The shift instrumentation is done
> > first; after
On Wed, Jul 22, 2015 at 07:26:22PM +0200, Marek Polacek wrote:
> In this testcase we were generating an uninitialized variable when doing
> -fsanitize=shift,bounds sanitization. The shift instrumentation is done
> first; after that, the IR looks like
>
> res[i] = (m > 31) ? __ubsan (... tab[i]
In this testcase we were generating an uninitialized variable when doing
-fsanitize=shift,bounds sanitization. The shift instrumentation is done
first; after that, the IR looks like
res[i] = (m > 31) ? __ubsan (... tab[i] ...) ? 0, ... tab[i] ...;
where tab[i] are identical. That means that w
