Message ID | CABGF_gdnkzJ9a7OfVQnD9xVjvwt6t0mofhy-wjkECSCtVmKt2Q@mail.gmail.com |
---|---|
State | New |
Headers | show |
Hi Roman,
Thanks for the quick answer.
> Please report back if it fixes the problem.
I have not yet done a full regtest, but a manual testing suggest that
the patch fixes the problem.
Dominique
I have regtested graphite.exp for gcc/g++/gfortran/libgomp without regression. So your patch seems a safe fix. Dominique
On 13/07/2014 12:34, Roman Gareev wrote: > Hi Dominique, > > thank you for the message! I've attached a patch, that may fix the issue. > > Please report back if it fixes the problem. Roman, this patch is OK to commit, but please include a correct changelog file. Tobias
I've found out that int128_integer_type_node and long_long_integer_type_node are NULL at the moment of definition of the graphite_expression_size_type. Maybe we should use long_long_integer_type_node, because, as you said before, using of signed 64 has also been proved to be very robust. What do you think about this? -- Cheers, Roman Gareev.
Index: gcc/graphite-isl-ast-to-gimple.c =================================================================== --- gcc/graphite-isl-ast-to-gimple.c (revision 212491) +++ gcc/graphite-isl-ast-to-gimple.c (working copy) @@ -65,7 +65,9 @@ /* We always use signed 128, until isl is able to give information about types */ -static tree *graphite_expression_size_type = &int128_integer_type_node; +static tree *graphite_expression_size_type = int128_integer_type_node ? + &int128_integer_type_node : + &long_long_integer_type_node; /* Converts a GMP constant VAL to a tree and returns it. */