On Wed, Jun 25, 2014 at 03:47:37PM +0200, Jakub Jelinek wrote:
> Please don't invoke undefined behavior in the asm statements.
> So, "r" (&c[5]) is fine, but not &c[5][2][2] is not, &x[-1] is not, etc.
> I'd say it should be ok to always just take address of the base
> variable in the asm. Otherwi
Hi!
On Wed, Jun 25, 2014 at 03:36:38PM +0200, Marek Polacek wrote:
> static void __attribute__ ((noinline, noclone))
> fn7 (void)
> {
> - int n = 5, i;
> + int n = 5;
> + volatile int i;
>volatile int c[n][n][n];
> - c[5][2][2] = 2;
> - c[2][5][2] = 2;
> - c[2][2][5] = 2;
> + asm (""
On Wed, Jun 25, 2014 at 02:49:56PM +0200, Jakub Jelinek wrote:
> On Wed, Jun 25, 2014 at 02:40:40PM +0200, Marek Polacek wrote:
> > On IRC Ramana reported that on ARM ubsan/bounds-2.c test fails with -O0,
> > since we write to out-of-bounds location and probably rewrite the
> > frame pointer stored
On Wed, Jun 25, 2014 at 02:40:40PM +0200, Marek Polacek wrote:
> On IRC Ramana reported that on ARM ubsan/bounds-2.c test fails with -O0,
> since we write to out-of-bounds location and probably rewrite the
> frame pointer stored in the stack. This patch removes such stores
> and adds some asm magi
On IRC Ramana reported that on ARM ubsan/bounds-2.c test fails with -O0,
since we write to out-of-bounds location and probably rewrite the
frame pointer stored in the stack. This patch removes such stores
and adds some asm magic so the compiler doesn't optimize loads away as
uninitialized memory r
