Jakub Jelinek wrote:
>Hi!
>
>On the gomp4 branch I've noticed a miscompilation of the simd-3.C
>testcase I'm adding there, but even say
>int a[1024] __attribute__((aligned (32))) = { 1 };
>int b[1024] __attribute__((aligned (32))) = { 1 };
>unsigned short c[1024] __attribute__((aligned (32))) = {
Hi!
On the gomp4 branch I've noticed a miscompilation of the simd-3.C
testcase I'm adding there, but even say
int a[1024] __attribute__((aligned (32))) = { 1 };
int b[1024] __attribute__((aligned (32))) = { 1 };
unsigned short c[1024] __attribute__((aligned (32))) = { 1 };
__attribute__((noinline
On Fri, 1 Mar 2013, Jakub Jelinek wrote:
> Hi!
>
> The first two hunks are similar issue to what I've posted for
> vect_permute_load_chain two days ago, the remaining issue is that
> if ncopies > 1, we'd leak the result_chain vector too.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux a
On 03/01/2013 01:23 PM, Jakub Jelinek wrote:
Hi!
The first two hunks are similar issue to what I've posted for
vect_permute_load_chain two days ago, the remaining issue is that
if ncopies > 1, we'd leak the result_chain vector too.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-l
Hi!
The first two hunks are similar issue to what I've posted for
vect_permute_load_chain two days ago, the remaining issue is that
if ncopies > 1, we'd leak the result_chain vector too.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-03-01 Jakub Jelinek
