From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id B4F123858D38 for ; Wed, 6 Dec 2023 10:28:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B4F123858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B4F123858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701858547; cv=none; b=fO/v6+SFjuf2CfCywQF9QhZoYpDvXwh+HpshaqxeHrqWq5gcglZf93qOPuVk8IF6I1Rs1zOJahd/bjXD2ePIBS8fyBxc49MBmiIyMhxPiN7I8N/PlVxGzbbEPxkjFLx31rTPdAoJRCsilClF/+nqHNYDpcraO+96cYo3bK8iOzs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701858547; c=relaxed/simple; bh=yNp0+nsxhbiwCg4zokF1TRMeHce3zCKCHOJD8BPnlHY=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=Ric2NMGPO8s/C8nB+VHW6gQu9gEaXImTNgryjyfN6jZKqn5C4vd3Fgk4qfjyXJGbkq1d23WRBfawSa/Vym4hp5SE1KU9sYUL/se61VAJAjPlIrDhdltKAlrT2PkxhAQhxOaK7PL06NJL6UTeshdFFhL2V1+6It6oRzLC79tzy1I= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id A63EB1FD03; Wed, 6 Dec 2023 10:28:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1701858535; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aKS4PfU4gWitpFyr3s0DwJR8FG7YkrmTslG9xbmJYjw=; b=EgX9Yq23eXGYLMkT/3jG+6IJWsdq9j7gt1oZsK++vagGfWzkIVYSjsBfCI60xvgtrOTQ9L Gc/sW4v7VJVG51ajYqywDP/9n+cZ3V0zRwkj/JfGkx5B6gXI0NTdv7pgJRH/PSsD01Juob qwXAscg5jN6TcvAKjVqJbFrr3UGWp8A= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1701858535; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aKS4PfU4gWitpFyr3s0DwJR8FG7YkrmTslG9xbmJYjw=; b=8Zz1SpcN5gdzTmY5TFd3HABWNVL+jZBLScNrXY7hoTNGb/pJPG5/vBRmuqifCub+GCQJmk gbPimD/bUl/2j8BQ== Date: Wed, 6 Dec 2023 11:25:10 +0100 (CET) From: Richard Biener To: Jakub Jelinek cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] libgcc: Avoid -Wbuiltin-declaration-mismatch warnings in emutls.c In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spamd-Result: default: False [-4.30 / 50.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[codesourcery.com:email,suse.de:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-3.00)[100.00%] X-Spam-Score: -4.30 Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 > Jakub Jelinek > > 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 > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)