On Tue, Jan 12, 2016 at 06:51:31PM +0100, Martin Jambor wrote:
> On Tue, Jan 12, 2016 at 06:36:21PM +0100, Martin Jambor wrote:
> > > remap_decl (old_var, id);
> > > }
> > > - phase 2 - do the full remap_decls, but during that arrange that
> > > remap_decl for non-zero id->remapping_type_de
On Tue, Jan 12, 2016 at 06:36:21PM +0100, Martin Jambor wrote:
> > remap_decl (old_var, id);
> > }
> > - phase 2 - do the full remap_decls, but during that arrange that
> > remap_decl for non-zero id->remapping_type_depth if (!n) just returns
> > decl
>
> ...they would not be copied he
Hi,
On Mon, Jan 11, 2016 at 05:38:47PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 11, 2016 at 09:41:31AM +0100, Richard Biener wrote:
> > Hum. Can't you check id->remapping_type_depth?
For some reason, last week I reached the conclusion that no. But I
must have done something wrong because I hav
On Mon, Jan 11, 2016 at 09:41:31AM +0100, Richard Biener wrote:
> Hum. Can't you check id->remapping_type_depth? That said, how do
> we end up recursing into remap_decl when copying the variable length
> decl/type? Can't we avoid the recursion (basically avoid remapping
> variable-size types at
On Fri, Jan 8, 2016 at 3:59 PM, Martin Jambor wrote:
> Hi,
>
> I ran into an ICE when compiling the following function on the HSA branch:
>
> foo (int n, int m, int o, int (*a)[m][o])
> {
> int i, j, k;
> #pragma omp target teams distribute parallel for shared(a) firstprivate(n, m,
> o) private
Hi,
I ran into an ICE when compiling the following function on the HSA branch:
foo (int n, int m, int o, int (*a)[m][o])
{
int i, j, k;
#pragma omp target teams distribute parallel for shared(a) firstprivate(n, m,
o) private(i,j,k)
for (i = 0; i < n; i++)
for (j = 0; j < m; j++)
fo
