On Wed, Jul 1, 2015 at 1:43 PM, Tom de Vries <tom_devr...@mentor.com> wrote:
> Hi,
>
> I.
>
> When running test libgomp.c/appendix-a/a.29.1.c with '--target_board
> unix/-O2/-g', we run into this failure:
> ...
> FAIL: libgomp.c/appendix-a/a.29.1.c (test for excess errors)
> Excess errors:
> src/libgomp/testsuite/libgomp.c/appendix-a/a.29.1.c:6:1: error: type
> mismatch between an SSA_NAME and its symbol
> ...
>
> Without -g, the testcase passes.
>
>
> II.
>
> The scenario for the failure is as follows:
>
> At fnsplit, we split off f.part.0 from f, which at source level looks like
> this:
> ...
> void
> f (int n, int B[n][n], int C[])
> {
> int D[2][2] = { 1, 2, 3, 4 };
> int E[n][n];
> assert (n >= 2);
> E[1][1] = 4;
> #pragma omp parallel firstprivate(B, C, D, E)
> {
> assert (sizeof (B) == sizeof (int (*)[n]));
> assert (sizeof (C) == sizeof (int *));
> assert (sizeof (D) == 4 * sizeof (int));
> assert (sizeof (E) == n * n * sizeof (int));
> /* Private B and C have values of original B and C. */
> assert (&B[1][1] == &A[1][1]);
> assert (&C[3] == &A[1][1]);
> assert (D[1][1] == 4);
> assert (E[1][1] == 4);
> }
> }
> ...
>
> The split introduces a debug_insn and ssa-name that references param B in f:
> ...
> # DEBUG D#4ptD.0 => B_3(D)
> ..
>
> And a debug_insn that references param B in f.part.0:
> ...
> # DEBUG D#7ptD.0 s=> BD.1846
> ...
>
> At this point, the type of the ssa name and the param are the same.
With the same PARM_DECL? I think that's the bug.
> Then at inline, we decide to inline f.part.0 back into function f.
>
> For inlining, we rewrite the body of inlined function f.part.0. While
> rewriting the debug insn mentioned above, we hit this code for param B:
> ...
> if (TREE_CODE (*tp) != OMP_CLAUSE)
> TREE_TYPE (*tp) = remap_type (TREE_TYPE (*tp), id);
> ...
> And since it's a variable-sized type, the type of param is changed.
The param of the inlined body but that should be unrelated to that refered to by
# DEBUG D#4ptD.0 => B_3(D)
in f.
> Now the type of the ssa name and the param are no longer the same, and a bit
> later we hit the ICE.
>
>
> III.
>
> Attached patch fixes the ICE by handling PARM_DECL in remap_gimple_op_r.
> [ I'm not confident though this is the right fix ]
>
> Bootstrapped and reg-tested on x86_64.
>
> OK for trunk, or to be fixed otherwise?
>
> Thanks,
> - Tom
