From: Jason Merrill <jason@redhat.com>
To: Alexandre Oliva <oliva@adacore.com>, gcc-patches@gcc.gnu.org
Cc: hainque@adacore.com, joseph@codesourcery.com, nathan@acm.org
Subject: Re: [PATCH] [vxworks] make wint_t and wchar_t the same distinct type
Date: Fri, 17 Feb 2023 12:08:08 -0500 [thread overview]
Message-ID: <340c8b27-a042-43b5-4151-2341114da87a@redhat.com> (raw)
In-Reply-To: <orsff4srfy.fsf@lxoliva.fsfla.org>
On 2/17/23 23:04, Alexandre Oliva wrote:
>
> 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
And fixing that isn't an option? Do the integer builtins work properly
if we force them to use wchar_t instead of an integer type?
> 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.
>
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install?
>
> 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.
> ---
> gcc/c-family/c-common.cc | 16 +++++++++++++---
> gcc/c-family/c-cppbuiltin.cc | 2 ++
> gcc/config/vx-common.h | 2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
> index ae92cd5adaf5e..a92597c2f544f 100644
> --- a/gcc/c-family/c-common.cc
> +++ b/gcc/c-family/c-common.cc
> @@ -4576,8 +4576,11 @@ c_common_nodes_and_builtins (void)
> char32_array_type_node
> = build_array_type (char32_type_node, array_domain_type);
>
> - wint_type_node =
> - TREE_TYPE (identifier_global_value (get_identifier (WINT_TYPE)));
> + if (strcmp (WINT_TYPE, "wchar_t") == 0)
> + wint_type_node = wchar_type_node;
> + else
> + wint_type_node =
> + TREE_TYPE (identifier_global_value (get_identifier (WINT_TYPE)));
>
> intmax_type_node =
> TREE_TYPE (identifier_global_value (get_identifier (INTMAX_TYPE)));
> @@ -5359,7 +5362,14 @@ c_stddef_cpp_builtins(void)
> builtin_define_with_value ("__SIZE_TYPE__", SIZE_TYPE, 0);
> builtin_define_with_value ("__PTRDIFF_TYPE__", PTRDIFF_TYPE, 0);
> builtin_define_with_value ("__WCHAR_TYPE__", MODIFIED_WCHAR_TYPE, 0);
> - builtin_define_with_value ("__WINT_TYPE__", WINT_TYPE, 0);
> + /* C++ has wchar_t as a builtin type, C doesn't, so if WINT_TYPE
> + maps to wchar_t, define it to the underlying WCHAR_TYPE in C, and
> + to wchar_t in C++, so the desired type equivalence holds. */
> + if (!c_dialect_cxx ()
> + && strcmp (WINT_TYPE, "wchar_t") == 0)
> + builtin_define_with_value ("__WINT_TYPE__", WCHAR_TYPE, 0);
> + else
> + builtin_define_with_value ("__WINT_TYPE__", WINT_TYPE, 0);
> builtin_define_with_value ("__INTMAX_TYPE__", INTMAX_TYPE, 0);
> builtin_define_with_value ("__UINTMAX_TYPE__", UINTMAX_TYPE, 0);
> if (flag_char8_t)
> diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
> index b333f97fd3237..98f5aef2af95d 100644
> --- a/gcc/c-family/c-cppbuiltin.cc
> +++ b/gcc/c-family/c-cppbuiltin.cc
> @@ -1903,6 +1903,8 @@ type_suffix (tree type)
> systems use it anyway. */
> || type == char_type_node)
> is_long = 0;
> + else if (type == wchar_type_node)
> + return type_suffix (underlying_wchar_type_node);
> else
> gcc_unreachable ();
>
> diff --git a/gcc/config/vx-common.h b/gcc/config/vx-common.h
> index 83580d0dec288..9733c90fe4c6f 100644
> --- a/gcc/config/vx-common.h
> +++ b/gcc/config/vx-common.h
> @@ -69,7 +69,7 @@ along with GCC; see the file COPYING3. If not see
> #undef WINT_TYPE_SIZE
> #define WINT_TYPE_SIZE WCHAR_TYPE_SIZE
> #undef WINT_TYPE
> -#define WINT_TYPE WCHAR_TYPE
> +#define WINT_TYPE "wchar_t"
>
> /* ---------------------- Debug and unwind info formats ------------------ */
>
>
next prev parent reply other threads:[~2023-02-17 17:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 7:04 Alexandre Oliva
2023-02-17 17:08 ` Jason Merrill [this message]
2023-02-22 15:23 ` Alexandre Oliva
2023-02-28 16:07 ` Jason Merrill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=340c8b27-a042-43b5-4151-2341114da87a@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hainque@adacore.com \
--cc=joseph@codesourcery.com \
--cc=nathan@acm.org \
--cc=oliva@adacore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).