[Bug preprocessor/96952] New: __builtin_thread_pointer support cannot be probed

[Bug preprocessor/96952] New: __builtin_thread_pointer support cannot be probed

[sorear at fastmail dot com]

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

            Bug ID: 96952
           Summary: __builtin_thread_pointer support cannot be probed
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sorear at fastmail dot com
  Target Milestone: ---

I would like to use __builtin_thread_pointer instead of inline asm to access
the thread pointer (concretely, in kernel or libc code for risc-v), but it's
only supported by extremely recent versions of gcc and clang.  So, I would like
to detect it at compile time, but this does not work:

#if __has_builtin(__builtin_thread_pointer)
void *get_tp() { return __builtin_thread_pointer(); }
#else
/* inline asm fallback */
#endif

x.c: In function 'get_tp':
x.c:2:25: error: '__builtin_thread_pointer' is not supported on this target
    2 | void *get_tp() { return __builtin_thread_pointer(); }
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~

__has_builtin seems to be falsely returning true?

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[fw at gcc dot gnu.org]

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

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=96200

--- Comment #1 from Florian Weimer <fw at gcc dot gnu.org> ---
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
__has_builtin does what is documented:

The special operator @code{__has_builtin (@var{operand})} may be used in
constant integer contexts and in preprocessor @samp{#if} and @samp{#elif}
expressions to test whether the symbol named by its @var{operand} is
recognized as a built-in function by GCC in the current language and
conformance mode.  It evaluates to a constant integer with a nonzero
value if the argument refers to such a function, and to zero otherwise.

__builtin_thread_pointer is recognized as a built-in function by GCC, so you
get 1 from __has_builtin.  It is not feasible to have at preprocessing time
complete knowledge of the details how the builtin will be lowered (if at all),
expanded (if at all), whether it needs any optabs etc.  A lot of those details
are also dependent on the builtin arguments and other details (e.g. from which
function it is called, what function specific options are enabled etc.).

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[bugdal at aerifal dot cx]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
This answer does not seem satisfactory. Whether it will be optimized is not the
question. Just whether it's semantically defined. That should either be
universally true on GCC versions that offer the builtin (via a libgcc function
if nothing else is available) or target-specific (which is known at
preprocessing time).

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-09-29
     Ever confirmed|0                           |1
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
What about detecting the support at configure time and defining a macro during
the compilation?  Everyone has been doing this for more that 3 decades...

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[bugdal at aerifal dot cx]

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

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> ---
The whole point of __has_builtin is to let you avoid the configure-time checks
on compilers that support __has_builtin. If __has_builtin doesn't actually
work, it's pointless that it even exists and indeed everyone should just
pretend it doesn't exist and keep using configure-time checks for everything.

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The whole point of __has_builtin is to let you avoid the configure-time
> checks on compilers that support __has_builtin. If __has_builtin doesn't
> actually work, it's pointless that it even exists and indeed everyone should
> just pretend it doesn't exist and keep using configure-time checks for
> everything.

That would certainly restore the portability that __has_builtin has broken.

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #4)
> What about detecting the support at configure time and defining a macro
> during the compilation?  Everyone has been doing this for more that 3
> decades...

Sorry, but it doesn't work. How do you suggest libstdc++ should use
configure-time checks to find out what features are present in the compiler
including the libstdc++ headers later? I don't know what that compiler is at
configure time.

For example, installed libstdc++ headers might get included by the GCC release
that they belong to, or by unknown releases of Clang or ICC with different
feature sets and levels of standard conformance. Checking anything at configure
time is useless for code in headers.

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Sorry, but it doesn't work. How do you suggest libstdc++ should use
> configure-time checks to find out what features are present in the compiler
> including the libstdc++ headers later? I don't know what that compiler is at
> configure time.

I'm surprising by that: are you saying that none of the  _GLIBCXX_* values
tested in the libstdc++ headers come from the libstdc++ configure machinery?

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
No, I didn't say none of them come from configure. What I meant by "checking
anything at configure time" is anything related to the properties of the
compiler that ends up including the header. Not *anything* at all.

Most of the _GLIBCXX macros relate to properties of the OS, which doesn't
change when you include the headers with a different C++ compiler.

But see
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/c%2B%2Bconfig;h=860bf6dbcb3de8500555c95148f4fc6ad44cf0dd;hb=HEAD#l665
which uses __has_builtin. How would you do that in configure? The compiler that
ends up consuming the libstdc++ headers might not even have existed when
configure was run.

[Bug c/96952] __builtin_thread_pointer support cannot be probed

[hpa at zytor dot com]

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

H. Peter Anvin <hpa at zytor dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hpa at zytor dot com

--- Comment #10 from H. Peter Anvin <hpa at zytor dot com> ---
Is this bug still relevant? RISC-V doesn't even seem to support disabling tls
support, and __builtin_thread_pointer() appears to be properly supported. So it
would presumably be up to any remaining target that doesn't have
__builtin_thread_pointer() (or not in all configurations) to verify that
__has_builtin(__builtin_thread_pointer) evaluates to false?