[vxworks] make wint_t and wchar_t the same distinct type
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t, headers got included in the test that declared functions that
take wint_t parameters, and those conflicted with the builtin
declarations that had wint_t mapped to the underlying integral type.
The problem is that, in C++, wchar_t is a distinct type. Having
wint_t be a typedef to wchar_t in the headers, but a typedef to
wchar_t's underlying integral type in builtins, makes for mismatches
between the declarations.
This patch defines WINT_TYPE to "wchar_t" for vxworks, and adjusts the
fallout, namely:
- since wchar_t may not have been defined yet when
c_common_nodes_and_builtins runs, use the node already reserved for
wchar_t for wint_t when WINT_TYPE is defined to wchar_t.
- for the same reason, when WINT_TYPE is wchar_t and we're not
compiling C++ where wchar_t is a compiler built-in, define
__WINT_TYPE__ to WCHAR_TYPE rather than WINT_TYPE, because wchar_t
may not even be defined in the translation unit.
- recognize and handle wchar_type_node when type_suffix is called for
wint_type_node.
for gcc/ChangeLog
* config/vx-common.h (WINT_TYPE): Alias to "wchar_t".
for gcc/c-family/ChangeLog
* c-common.cc (c_common_nodes_and_builtins): Take
wchar_type_node for wint_type_node when aliased.
(c_stddef_cpp_builtins): Define __WINT_TYPE__, when aliased to
wchar_t, to the underlying type rather than wchar_t in
non-C++.
* c-cppbuiltin.cc (type_suffix): Handle wchar_type_node.