On Tue, Jan 17, 2017 at 09:22:52AM -0500, Aldy Hernandez wrote:
This is the same as pr70565 but it fails in an entirely different manner in
the C front-end.
The problem here is that the parser builds an ARRAY_NOTATION_REF with a type
of ptrdiff for length and stride. Later in cilkplus_extract_an_triplets we
convert convert length and stride to an integer_type_node. This causes
create_array_refs() to use a stride of integer_type, while the start is
still a ptrdiff (verify_gimple ICE, boom).
The attached patch converts `start' to an integer_type to match the length
and stride. We could either do this, or do a fold_convert if
!useless_type_conversion_p in create_array_refs. I didn't want to look into
cilkplus too deeply as to why we have different types, because (a) I don't
care (b) we're probably going to deprecate Cilk Plus, no?
Conceptually, using integer_type_node for these things is complete wrong,
unless the Cilk+ specification says that all the array notation expressions
are converted to int. Because forcing the int there means that it will
misbehave on very large arrays (over 2GB elements).
So much better would be to have the expressions converted to sizetype or
something similar that the middle-end works with (yes, it is unsigned, so
if it needs to be signed somewhere, we'd need corresponding signed type for
that).
The question is where all is the integer_type_node in the Cilk+ lowering
hardcoded and how hard would it be to fix it up.
If it is too hard, I guess I can live with this patch, but there should be a
PR that it needs to be fixed not to hardcode int type which is inappropriate
for sizes/lengths.
And the more important question is if Intel is willing to maintain Cilk+ in
GCC, or if we should deprecate it (and, if the latter, if already in GCC7
deprecate, remove in GCC8, or deprecate in GCC8, remove in GCC9).
There are various Cilk+ related PRs around on which nothing has been done
for many months.