On 02/17/2014 06:50 PM, Roman Gareev wrote:
Hi Tobias, thanks for the answer!
Hi Roman, sorry for missing this mail.
I think that the segfault is being caused by NULL arguments being passedto compute_deps by loop_level_carries_dependences. *This is **causing **an* *assignment of** NULL values to the following parameters of **compute_deps:* must_raw_no_source, may_raw_no_source, must_war_no_source, may_war_no_source, must_waw_no_source, may_waw_no_source. They are being passed to subtract_commutative_associative_deps and dereferenced in the following statements: *must_raw_no_source = isl_union_map_subtract (*must_raw_no_source, x_must_raw_no_source); *may_raw_no_source = isl_union_map_subtract (*may_raw_no_source, x_may_raw_no_source); *must_war_no_source = isl_union_map_subtract (*must_war_no_source, x_must_war_no_source); *may_war_no_source = isl_union_map_subtract (*may_war_no_source, x_may_war_no_source); *must_waw_no_source = isl_union_map_subtract (*must_waw_no_source, x_must_waw_no_source); *may_waw_no_source = isl_union_map_subtract (*may_waw_no_source, x_may_waw_no_source); This is the reason of segfault. (All functions mentioned above are located in gcc/graphite-dependences.c)
Interesting analysis.
I think that this can be solved by the addition to subtract_commutative_associative_deps of NULL checking of the following variables: must_raw_no_source, may_raw_no_source, must_war_no_source, may_war_no_source, must_waw_no_source, may_waw_no_source. I've implemented this in the patch, which can be found below.
Yes, this would be a 'solution'. However, I am in fact surprised that those variables are NULL at all. Do you have an idea why this is the case? Understanding this would help to understand if the patch you propose is actually the right solution or if it is just hiding a previous bug.
Cheers, Tobias
