libgcc: Avoid -Wbuiltin-declaration-mismatch warnings in emutls.c

Hi!

When libgcc is being built in --disable-tls configuration or on
a target without native TLS support, one gets annoying warnings:
../../../../libgcc/emutls.c:61:7: warning: conflicting types for built-in function ‘__emutls_get_address’; expected ‘void *(void *)’ [-Wbuiltin-declaration-mismatch]
   61 | void *__emutls_get_address (struct __emutls_object *);
      |       ^~~~~~~~~~~~~~~~~~~~
../../../../libgcc/emutls.c:63:6: warning: conflicting types for built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned int,  unsigned int,  void *)’ [-Wbuiltin-declaration-mismatch]
   63 | void __emutls_register_common (struct __emutls_object *, word, word, void *);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~
../../../../libgcc/emutls.c:140:1: warning: conflicting types for built-in function ‘__emutls_get_address’; expected ‘void *(void *)’ [-Wbuiltin-declaration-mismatch]
  140 | __emutls_get_address (struct __emutls_object *obj)
      | ^~~~~~~~~~~~~~~~~~~~
../../../../libgcc/emutls.c:204:1: warning: conflicting types for built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned int,  unsigned int,  void *)’ [-Wbuiltin-declaration-mismatch]
  204 | __emutls_register_common (struct __emutls_object *obj,
      | ^~~~~~~~~~~~~~~~~~~~~~~~
The thing is that in that case __emutls_get_address and
__emutls_register_common are builtins, and are declared with void *
arguments rather than struct __emutls_object *.
Now, struct __emutls_object is a type private to libgcc/emutls.c and the
middle-end creates on demand when calling the builtins a similar structure
(with small differences, like not having the union in there).

We have a precedent for this e.g. for fprintf or strftime builtins where
the builtins are created with magic fileptr_type_node or const_tm_ptr_type_node
types and then match it with user definition of pointers to some structure,
but I think for this case users should never define these functions
themselves nor call them and having special types for them in the compiler
would mean extra compile time spent during compiler initialization and more
GC data, so I think it is better to keep the compiler as is.

On the library side, there is an option to just follow what the
compiler is doing and do
 EMUTLS_ATTR void
-__emutls_register_common (struct __emutls_object *obj,
+__emutls_register_common (void *xobj,
                           word size, word align, void *templ)
 {
+  struct __emutls_object *obj = (struct __emutls_object *) xobj;
but that will make e.g. libabigail complain about ABI change in libgcc.

So, the patch just turns the warning off.

Tested on x86_64-linux with --disable-tls, ok for trunk?

2023-12-06  Thomas Schwinge  <thomas@codesourcery.com>
	    Jakub Jelinek  <jakub@redhat.com>

	PR libgcc/109289
	* emutls.c: Add GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
	pragma.


	Jakub

On Wed, 6 Dec 2023, Jakub Jelinek wrote:

> Hi!
> 
> When libgcc is being built in --disable-tls configuration or on
> a target without native TLS support, one gets annoying warnings:
> ../../../../libgcc/emutls.c:61:7: warning: conflicting types for built-in function ?__emutls_get_address?; expected ?void *(void *)? [-Wbuiltin-declaration-mismatch]
>    61 | void *__emutls_get_address (struct __emutls_object *);
>       |       ^~~~~~~~~~~~~~~~~~~~
> ../../../../libgcc/emutls.c:63:6: warning: conflicting types for built-in function ?__emutls_register_common?; expected ?void(void *, unsigned int,  unsigned int,  void *)? [-Wbuiltin-declaration-mismatch]
>    63 | void __emutls_register_common (struct __emutls_object *, word, word, void *);
>       |      ^~~~~~~~~~~~~~~~~~~~~~~~
> ../../../../libgcc/emutls.c:140:1: warning: conflicting types for built-in function ?__emutls_get_address?; expected ?void *(void *)? [-Wbuiltin-declaration-mismatch]
>   140 | __emutls_get_address (struct __emutls_object *obj)
>       | ^~~~~~~~~~~~~~~~~~~~
> ../../../../libgcc/emutls.c:204:1: warning: conflicting types for built-in function ?__emutls_register_common?; expected ?void(void *, unsigned int,  unsigned int,  void *)? [-Wbuiltin-declaration-mismatch]
>   204 | __emutls_register_common (struct __emutls_object *obj,
>       | ^~~~~~~~~~~~~~~~~~~~~~~~
> The thing is that in that case __emutls_get_address and
> __emutls_register_common are builtins, and are declared with void *
> arguments rather than struct __emutls_object *.
> Now, struct __emutls_object is a type private to libgcc/emutls.c and the
> middle-end creates on demand when calling the builtins a similar structure
> (with small differences, like not having the union in there).
> 
> We have a precedent for this e.g. for fprintf or strftime builtins where
> the builtins are created with magic fileptr_type_node or const_tm_ptr_type_node
> types and then match it with user definition of pointers to some structure,
> but I think for this case users should never define these functions
> themselves nor call them and having special types for them in the compiler
> would mean extra compile time spent during compiler initialization and more
> GC data, so I think it is better to keep the compiler as is.
> 
> On the library side, there is an option to just follow what the
> compiler is doing and do
>  EMUTLS_ATTR void
> -__emutls_register_common (struct __emutls_object *obj,
> +__emutls_register_common (void *xobj,
>                            word size, word align, void *templ)
>  {
> +  struct __emutls_object *obj = (struct __emutls_object *) xobj;
> but that will make e.g. libabigail complain about ABI change in libgcc.
> 
> So, the patch just turns the warning off.
> 
> Tested on x86_64-linux with --disable-tls, ok for trunk?

Works for me.

Richard.

> 2023-12-06  Thomas Schwinge  <thomas@codesourcery.com>
> 	    Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR libgcc/109289
> 	* emutls.c: Add GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
> 	pragma.
> 
> --- libgcc/emutls.c.jj	2023-01-16 11:52:16.780723793 +0100
> +++ libgcc/emutls.c	2023-12-06 10:49:46.438060090 +0100
> @@ -57,6 +57,14 @@ struct __emutls_array
>  #  define EMUTLS_ATTR
>  #endif
>  
> +/* __emutls_get_address and __emutls_register_common are registered as
> +   builtins, but the compiler struct __emutls_object doesn't have
> +   a union in there and is only created when actually needed for
> +   the calls to the builtins, so the builtins are created with void *
> +   arguments rather than struct __emutls_object *.  Avoid
> +   -Wbuiltin-declaration-mismatch warnings.  */
> +#pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
> +
>  EMUTLS_ATTR
>  void *__emutls_get_address (struct __emutls_object *);
>  EMUTLS_ATTR
> 
> 	Jakub
> 
>

On 12/6/23 03:04, Jakub Jelinek wrote:
> Hi!
> 
> When libgcc is being built in --disable-tls configuration or on
> a target without native TLS support, one gets annoying warnings:
> ../../../../libgcc/emutls.c:61:7: warning: conflicting types for built-in function ‘__emutls_get_address’; expected ‘void *(void *)’ [-Wbuiltin-declaration-mismatch]
>     61 | void *__emutls_get_address (struct __emutls_object *);
>        |       ^~~~~~~~~~~~~~~~~~~~
> ../../../../libgcc/emutls.c:63:6: warning: conflicting types for built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned int,  unsigned int,  void *)’ [-Wbuiltin-declaration-mismatch]
>     63 | void __emutls_register_common (struct __emutls_object *, word, word, void *);
>        |      ^~~~~~~~~~~~~~~~~~~~~~~~
> ../../../../libgcc/emutls.c:140:1: warning: conflicting types for built-in function ‘__emutls_get_address’; expected ‘void *(void *)’ [-Wbuiltin-declaration-mismatch]
>    140 | __emutls_get_address (struct __emutls_object *obj)
>        | ^~~~~~~~~~~~~~~~~~~~
> ../../../../libgcc/emutls.c:204:1: warning: conflicting types for built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned int,  unsigned int,  void *)’ [-Wbuiltin-declaration-mismatch]
>    204 | __emutls_register_common (struct __emutls_object *obj,
>        | ^~~~~~~~~~~~~~~~~~~~~~~~
> The thing is that in that case __emutls_get_address and
> __emutls_register_common are builtins, and are declared with void *
> arguments rather than struct __emutls_object *.
> Now, struct __emutls_object is a type private to libgcc/emutls.c and the
> middle-end creates on demand when calling the builtins a similar structure
> (with small differences, like not having the union in there).
> 
> We have a precedent for this e.g. for fprintf or strftime builtins where
> the builtins are created with magic fileptr_type_node or const_tm_ptr_type_node
> types and then match it with user definition of pointers to some structure,
> but I think for this case users should never define these functions
> themselves nor call them and having special types for them in the compiler
> would mean extra compile time spent during compiler initialization and more
> GC data, so I think it is better to keep the compiler as is.
> 
> On the library side, there is an option to just follow what the
> compiler is doing and do
>   EMUTLS_ATTR void
> -__emutls_register_common (struct __emutls_object *obj,
> +__emutls_register_common (void *xobj,
>                             word size, word align, void *templ)
>   {
> +  struct __emutls_object *obj = (struct __emutls_object *) xobj;
> but that will make e.g. libabigail complain about ABI change in libgcc.
> 
> So, the patch just turns the warning off.
> 
> Tested on x86_64-linux with --disable-tls, ok for trunk?
> 
> 2023-12-06  Thomas Schwinge  <thomas@codesourcery.com>
> 	    Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR libgcc/109289
> 	* emutls.c: Add GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
> 	pragma.
OK
jeff