[Bug c++/69549] Named Address Spaces does not compile in C++

[Bug c++/69549] Named Address Spaces does not compile in C++

[thiago at kde dot org]

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

--- Comment #4 from Thiago Macieira <thiago at kde dot org> ---
And in GCC 11.

gcc version 11.0.1 20210308 (experimental) (GCC)

[Bug c++/69549] Named Address Spaces does not compile in C++

[thiago at kde dot org]

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

--- Comment #5 from Thiago Macieira <thiago at kde dot org> ---
BTW, Clang solved this by making __seg_fs, __seg_gs macros that resolve to
__attribute__:

$ clang -dM -E -xc /dev/null | grep __seg_.s
#define __seg_fs __attribute__((address_space(257)))
#define __seg_gs __attribute__((address_space(256)))

That way, they don't need to be deduced as qualifiers in C, like const,
volatile and _Atomic.

So this compiles with Clang in C++:

void *tid() { auto tib = (void * __seg_fs*)(0); return *tid; }

_Z3tibv:                                # @_Z3tibv
        movq    %fs:0, %rax
        retq

[Bug c++/69549] Named Address Spaces does not compile in C++

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Thiago Macieira from comment #5)
> BTW, Clang solved this by making __seg_fs, __seg_gs macros that resolve to
> __attribute__:
....
> That way, they don't need to be deduced as qualifiers in C, like const,
> volatile and _Atomic.

You still need to handle the attribute like qualifiers ....

> So this compiles with Clang in C++:
> 
> void *tid() { auto tib = (void * __seg_fs*)(0); return *tid; }

The above is not the reason why namespaces are not handled in GCC's C++
front-end.  The reason why they are not handled in C++ is because you need to
handle them in overloads and templates correctly.  Does clang handle those
correctly or does it ignore that issue?

[Bug c++/69549] Named Address Spaces does not compile in C++

[thiago at kde dot org]

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

--- Comment #7 from Thiago Macieira <thiago at kde dot org> ---
(In reply to Andrew Pinski from comment #6)
> The above is not the reason why namespaces are not handled in GCC's C++
> front-end.  The reason why they are not handled in C++ is because you need
> to handle them in overloads and templates correctly.  Does clang handle
> those correctly or does it ignore that issue?

It handles them:

$ clang -O2 -S -o - -include stdint.h -xc++ - <<<'template  <typename T> void
f(T); void f() { auto tib = (void * __seg_fs*)(0); f(tib); }' | c++filt 
        .text
        .file   "-"
        .globl  f()                   # -- Begin function f()
        .p2align        4, 0x90
        .type   f(),@function
f():                                  # @f()
        .cfi_startproc
# %bb.0:
        xorl    %edi, %edi
        jmp     void f<void* AS257*>(void* AS257*)     # TAILCALL

The mangled symbol was _Z1fIPU5AS257PvEvT_. That "AS257" is encoded as U5AS257,
which is an extended qualifier.

<https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.qualified-type>:
5.1.5.1 Qualified types


  <qualified-type>     ::= <qualifiers> <type>

  <qualifiers>         ::= <extended-qualifier>* <CV-qualifiers>
  <extended-qualifier> ::= U <source-name> [<template-args>] # vendor extended
type qualifier
  <CV-qualifiers>      ::= [r] [V] [K]    # restrict (C99), volatile, const

  <ref-qualifier>      ::= R              # & ref-qualifier
  <ref-qualifier>      ::= O              # && ref-qualifier

[Bug c++/69549] Named Address Spaces does not compile in C++

[jwjagersma at gmail dot com]

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

--- Comment #8 from jwjagersma at gmail dot com ---
Created attachment 51808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51808&action=edit
basic implementation

Tentative patch.

Produces working code but could use some (many) checks to diagnose incorrect
usage, eg. AS-qualified struct fields, function parameters, non-type template
parameters.  Assigning an AS-qualified pointer to non-qualified is already
diagnosed correctly, but the inverse is not.

I don't know if mangling address-space-qualified member functions would be
covered by ABI version 10, or if the version number needs to be bumped.

[Bug c++/69549] Named Address Spaces does not compile in C++

[jwjagersma at gmail dot com]

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

--- Comment #9 from jwjagersma at gmail dot com ---
Created attachment 51840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51840&action=edit
diagnostics

This patch adds checks for:
- Top-level AS-qualifiers on fields, local variables, function
  parameters and function return types.
- Assignment of pointers and references to different address spaces.
- Combining AS-qualifiers in template substitution.

An appropriate error message is emitted in each case.

Not detected: AS-qualifiers on non-type template parameters (but they
are stripped and ignored, of course).

I think this covers most invalid uses.  Am I missing anything?

[Bug c++/69549] Named Address Spaces does not compile in C++

[abelay at mit dot edu]

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

Adam Belay <abelay at mit dot edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abelay at mit dot edu

--- Comment #10 from Adam Belay <abelay at mit dot edu> ---
I realize this bug and patch is a couple years old, but I wanted to mention
that my research group is working on a new kernel in C++ and this feature would
be very useful to us. Without it, the FS and GS segment can only be accessed
via inline assembly, which is less convenient and more difficult for GCC to
optimize.

[Bug c++/69549] Named Address Spaces does not compile in C++

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org
           Keywords|                            |patch

--- Comment #11 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Generally a patch should be sent to gcc-patches@gcc.gnu.org.  See
https://gcc.gnu.org/contribute.html.  The patches attached to a Bugzilla ticket
are considered prototypes and for discussion only.

[Bug c++/69549] Named Address Spaces does not compile in C++

[jwjagersma at gmail dot com]

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

--- Comment #12 from jwjagersma at gmail dot com ---
(In reply to Xi Ruoyao from comment #11)
> Generally a patch should be sent to gcc-patches@gcc.gnu.org.  See
> https://gcc.gnu.org/contribute.html.  The patches attached to a Bugzilla
> ticket are considered prototypes and for discussion only.

This patch isn't complete yet, I posted it here in hopes of receiving some
comments.  It works for simple structs that are managed externally (eg, from
inline asm).  But other than that it doesn't integrate with the C++ type system
so well.

There is no way to make AS-qualified ctors/dtors (in fact, calling a dtor on an
AS-qualified ptr/ref is currently allowed - that's very bad), and also no
placement-new for AS-qualified pointers.

Granted, I don't think clang implements that either, but it does provide stuff
like __builtin_memcpy().  That is missing from this patch.

I also recall running into one bug where it generated code to access a stack
variable via fs:[esp].  I think it was something to do with rvalue references?
But it disappeared when I attempted to write a smaller test case, couldn't
figure that one out.

[Bug c++/69549] Named Address Spaces does not compile in C++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement