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 -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8