On 18/07/2014 12:34, Roman Gareev wrote:
I suggest you use the largest available integer mode via
>mode = mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0);
>type = build_nonstandard_integer_type (GET_MODE_PRECISION (mode), [01]);
Thank you for the suggestion!
>Roman, can you give this a shot?
> I suggest you use the largest available integer mode via
> mode = mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0);
> type = build_nonstandard_integer_type (GET_MODE_PRECISION (mode), [01]);
Thank you for the suggestion!
> Roman, can you give this a shot?
Maybe, we could use the following code
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 yo
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 have regtested graphite.exp for gcc/g++/gfortran/libgomp without
regression. So your patch seems a safe fix.
Dominique
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
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.
--
Cheers, Roman Gareev.
Index: gcc/graphite-isl-ast-to-gimple.c
On x86_64-apple-darwin13, the test gcc.dg/graphite/isl-codegen-loop-dumping.c
gives an ICE with -m32 after r212455. The backtrace is
* thread #1: tid = 0xdac306, 0x000100523c52 cc1`fold_binary_loc(loc=0,
code=MINUS_EXPR, type=0x, op0=0x000142c09bd0,
op1=0x000142c1b048
On 11/07/2014 15:41, Roman Gareev wrote:
I've attached an improved version of the patch and the ChangeLog
entry. Are they fine for trunk?
LGTM.
Thank you!
Tobias
I've attached an improved version of the patch and the ChangeLog
entry. Are they fine for trunk?
--
Cheers, Roman Gareev.
2014-07-11 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c (gmp_cst_to_tree):
New function.
(graphite_ve
On 11/07/2014 13:11, Roman Gareev wrote:
The struct now contains only a single element such that there seems to be no
need for it anymore. Should we remove it? (We could still use a typedef if
you believe the datatype is too long).
I don't mind removing it. However I think that we should choose
> The struct now contains only a single element such that there seems to be no
> need for it anymore. Should we remove it? (We could still use a typedef if
> you believe the datatype is too long).
I don't mind removing it. However I think that we should choose the
way of transferring of sese regio
I tried to incorporate all your comments in the attached patch.
Nice. It looks now very good to me. One final and last detail:
+/* TREE_FROM_ISL_ID maps ISL's scattering and parameter identifiers
+ to corresponding trees. */
+
+typedef struct ivs_params {
+ std::map tree_from_isl_id;
+} *i
> I would use -x to see the headers. This should tell you if it is defined
> or only used there.
It gives the following output:
roman@roman-System-Product-Name:~/isl-0.12.2/lib$ objdump -x
libisl.so.10.2.2 | grep isl_ast_expr_get_val
00060380 g F .text 0053
isl_ast_expr_ge
On 08/07/2014 14:47, Roman Gareev wrote:
Surprising. Is the symbol defined in libisl.so? You could use objdump to
>check?
If I am not mistaken, objdump shows that libisl.so contains it.
objdump -d libisl.so.10.2.2 | grep isl_ast_expr_get_val
00060380 :
60383: 74 4b j
> Surprising. Is the symbol defined in libisl.so? You could use objdump to
> check?
If I am not mistaken, objdump shows that libisl.so contains it.
objdump -d libisl.so.10.2.2 | grep isl_ast_expr_get_val
00060380 :
60383: 74 4b je 603d0
60389: 75 0d
16 matches
Mail list logo
