public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "tom at honermann dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/115658] char16_t and char32_t aliasing is conserative
Date: Fri, 28 Jun 2024 19:52:06 +0000	[thread overview]
Message-ID: <bug-115658-4-2SBzbgPUwa@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-115658-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658

--- Comment #3 from Tom Honermann <tom at honermann dot net> ---
In retrospect, I think I misunderstood Andrew's motivation for filing this
issue.

There is a difference of behavior between gcc and clang with regard to aliasing
of `char16_t` and `char32_t` with respect to other types. This is illustrated
by the following example as demonstrated at
https://www.godbolt.org/z/PsMsPMa73.

Please note that (at least) `-O2` is necessary to reliably demonstrate
differences in behavior. Additionally, the use of `-fshort-wchar` to influence
the size of `wchar_t` affects behavior.

```
template<typename T, typename U>
U f(T *p, U *q) {
  *p = 1;
  U u = *q;
  *p = 2;
  return u;
}
template wchar_t f(char16_t*, wchar_t*);
template unsigned short f(char16_t*, unsigned short*);
template wchar_t f(char32_t*, wchar_t*);
template unsigned int f(char32_t*, unsigned int*);
```

The test case exercises dead store elimination in the presence of aliasing
types. If `T` may alias `U`, then the write of `1` to `*p` is observable by
`*q`, but may otherwise be eliminated due to the later write of `2` to `*p`.

For Clang, there is no aliasing between any of these types and the store of `1`
to `*p` is always eliminated.

For MSVC, it appears that either dead store elimination is not performed at
all, or aliasing is permitted across all of these types (even when the size
differs).

For gcc with `-fshort-wchar`, there appear to be two alias sets:
- `wchar_t`, `char16_t`, and `unsigned short`.
- `char32_t` and `unsigned int`.

For gcc without `-fshort-wchar`, there are also two alias sets, but they are
not symmetric in the presence of that option. Note that `char32_t` never
aliases with `wchar_t` even when they have the same size. This asymmetry is
explainable in consideration of compatibility with MSVC (where `wchar_t` is
always 16-bit).
- `char16_t` and `unsigned short`.
- `char32_t` and `unsigned int`.

Adding the following explicit template instantiations demonstrates that all of
gcc, clang, and MSVC permit aliasing between the set of `char`, `unsigned
char`, and `char8_t` (because `char` and `unsigned char` are permitted to alias
all types). https://www.godbolt.org/z/Pjxb661Y7.

```
template char f(char8_t*, char*);
template unsigned char f(char8_t*, unsigned char*);
```

To reiterate, I think the current gcc behavior is correct and defensible given
two goals:
- A desire to match MSVC behavior in the limited context of a 16-bit `wchar_t`
type.
- A desire to match C behavior with respect to `char16_t` and `char32_t`
aliasing the underlying types of `uint_least16_t` and `uint_least32_t` (the
former are typedefs in C).

      parent reply	other threads:[~2024-06-28 19:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-26  4:13 [Bug c++/115658] New: " pinskia at gcc dot gnu.org
2024-06-26  4:15 ` [Bug c++/115658] " pinskia at gcc dot gnu.org
2024-06-26 20:12 ` tom at honermann dot net
2024-06-28 19:52 ` tom at honermann dot net [this message]

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=bug-115658-4-2SBzbgPUwa@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).