On 8/20/18 4:49 PM, Joseph Myers wrote:
> On Mon, 20 Aug 2018, Jeff Law wrote:
>
>>> If you do that, probably you want to move
>>> fortran/trans-types.c:get_typenode_from_name (which converts the strings
>>> used in target macros such as WCHAR_TYPE to the corresponding types) into
>>> generic code.
>> I think we ultimately have to go down that path. Or we have to make the
>> wchar types language independent.
>>
>> My initial fooling around does something like this:
>>
>> count_by = 1;
>> if (dir.specifier == 'S' || dir.modifier == FMT_LEN_l)
>> {
>> tree node = get_identifier (MODIFIED_WCHAR_TYPE);
>
> I expect this get_identifier use may only work properly in C-family
> languages.
>
> (There's another version of that get_typenode_from_name logic in
> tree.c:build_common_tree_nodes for SIZE_TYPE and PTRDIFF_TYPE, which only
> considers types of the right signedness in those cases, but does handle
> __intN types.)
[ Finally returning to this ]
get_typenode_from_name from the Fortran front-end is a better fit. We
pass in the type as a string and we get back a tree node. So we just
pass in MODIFIED_WCHAR_TYPE and it just works. So we just move that
routine into tree.c so its generally available and we're good to go.
The danger would be a port that defines WCHAR_TYPE to a string that
isn't recognized by get_typenode_from_name. I did some grepping in
config/ and it doesn't look like any of them use forms where the "int"
is implicit ie "short" or "short unsigned" or cases where the basic type
and signedness are reversed like "unsigned short". Similarly for cases
using "long".
jeff
