Waldek Hebisch wrote:
Frank Heckenbach wrote:
I found that this is (indirectly) due to build_range_type (tree.c) not setting
TREE_UNSIGNED (itype) = TREE_UNSIGNED (type);
Waldek, do you think this should be changed in the backend, or should we work around it in the frontend?
Logically `build_range_type' should set `TREE_UNSIGNED'. However, I suspect that some places in the compiler expect `build_range_type' to return signed type (like `build_index_2_type').
When I tried it with the backend change, I got no regressions.
Our use of build_index_2_type should be uncritical as well, since the range (only used for string literals) is always positive. Still I'm turning it into `build_range_type (pascal_integer_type_node, ...)' to avoid issues with TYPE_IS_SIZETYPE (and possibly to get a larger range, though this might not likely be necessary for string literals ;-).
The two uses of build_range_type in the C frontend (c-decl.c) look suspicious (strange things about "zero-leng arrays" and "flexible array members", whatever that is). I haven't tested how the change would affect them (i.e., if I didn't make it `#ifdef GPC'), but perhaps changing sizetype to ssizetype there might resolve the problems, if any. (In both cases, the lower bound is the constant 0, and the upper bound is NULL_TREE, so unsignedness might not actually be a problem at all.)
I haven't looked at other frontends.
Still, I would change `build_range_type' and then fix places depending on old behaviour.
I'm doing this now (adding it to the backend diffs).
Frank