From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id F37CD3858CD1 for ; Wed, 10 Apr 2024 04:48:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F37CD3858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F37CD3858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::102a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712724509; cv=none; b=PUtZpcngbkkKAzYXzmGo4Fp33dv/9N5uku9AO8boeUEuUFIjtHRE1CLtUIhPfCVy8XUo+PU4PJMO100qA5XEHHPdeKoNW5/IFZQx7kHuVo51y7bMhN3lRmHjisWtwd9Xn7TL4C45WookyGzSUpEvvOT1OI8w9EBrEw7wsI0I5SM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712724509; c=relaxed/simple; bh=Px0SclvbTHPOTtjSI0niAI2nlBLo2MC9Z9Bs5IxiJsk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=hOKrXZVXWgxwIboljB0FetGu2ux8MWwD+UqV8eBsGGChicFoCWoxvB09pF+tZEK6yc3a5W94OdvBBf0/Q/3Ac5b4EScicrSgbK5Rm5YGCLxlzihld3dQWcYHqgMLudOvNXfaF9Z/Qu64oC1f74ecplYVKQtTS6+Ip6/ci2raF/E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-2a4df5d83c7so1991250a91.0 for ; Tue, 09 Apr 2024 21:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712724506; x=1713329306; darn=sourceware.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Uhc1Ub9XtyMuwewc+64Zu+ecPN9sUwdF6DJby//88Bg=; b=fLgfPLHDnxCbDxnS+oUL3XbP6nFbyrOtGWvjaXwZu0QiGRov6cUoSmnoHuq+2jm07s e7MrX+9AX5ofjopcKutRfLPE6XeH8di9oiiSY5fyKxeQTYZaniq3WBnJmFLzZeQDvciM asdDbrhNCELwcRL4qbtSUnxyXkmfs6wGT7py+nSj4WUQ7DXr8JhiqzpXvM0YbOXngAIk HbOG5MQ+IGE5JlXBGMYrJZUXQTKsMtac6kbwG5n01Ye36ac8BKGO3qXraGFhO3e8IoqF xn0HfVlegAncq+g9OOnABxBs5CZr8774wvk5ZLFMXWY3FauYZPFybKcHUw94yrfGCZp+ nDBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712724506; x=1713329306; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Uhc1Ub9XtyMuwewc+64Zu+ecPN9sUwdF6DJby//88Bg=; b=PW7PwVrRfYLpoH16cEQZYboZqb4CKSzgeZfyvmjbRpWZhJyP1NDuK97cXsvF5T6zA/ QXRYMVY/ZtewC7I+3dQrzLwus0r8+WyC+sjnBAizsdrVgZSrXO9L0dXrue0Nh8ziGti3 BSR9ooRbqSUuFzgs+WilVyJlhPXTfmEUHKrrSRF6jtEGZR3pumKR0f3TEU0FOPmb/zwO DEh7v/NJR3mcdreh+a4IoKaV27E5QlOD4E8b3eDGsijvQMkYsedfTGBYo2ncBwyEHiX0 ddtYALk8d2JXO0/49wEEg1Fq9Rq5E8RkS6mJv4HH7gkf54OxeY+dzVnkWgRrcYGu9vPc Rdzg== X-Gm-Message-State: AOJu0Yx6met2I9QOI8gFHXVz931afQvc42JB7BukmXEPxXAKHWcDtPMC TyszC6w5Pr9CaAIV1/zTrGCsJYfa7/Pg1NHVsToVxPiBD9Byd0Qw X-Google-Smtp-Source: AGHT+IFlJx3sylYEsPpAU/z5yIWQKd8+4lX8SigfftfjD/AXasjKHIZRCwksDmWQ9/GbTIHPhbWE6Q== X-Received: by 2002:a17:90a:17c6:b0:2a0:5f10:990c with SMTP id q64-20020a17090a17c600b002a05f10990cmr1649382pja.10.1712724505730; Tue, 09 Apr 2024 21:48:25 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id ns1-20020a17090b250100b002a261d1da0dsm510058pjb.24.2024.04.09.21.48.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Apr 2024 21:48:25 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id DC3731140035; Wed, 10 Apr 2024 14:18:22 +0930 (ACST) Date: Wed, 10 Apr 2024 14:18:22 +0930 From: Alan Modra To: Nick Alcock Cc: binutils@sourceware.org Subject: Re: libctf warnings Message-ID: References: <87o7ai9wxe.fsf@esperi.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87o7ai9wxe.fsf@esperi.org.uk> X-Spam-Status: No, score=-3033.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 Tue, Apr 09, 2024 at 08:07:57PM +0100, Nick Alcock wrote: > On 9 Apr 2024, Alan Modra said: > > > Seen with every compiler I have: > > home/alan/src/binutils-gdb/libctf/ctf-create.c: In function ‘ctf_add_encoded’: > > /home/alan/src/binutils-gdb/libctf/ctf-create.c:555:3: warning: ‘encoding’ may be used uninitialized [-Wmaybe-uninitialized] > > 555 | memcpy (dtd->dtd_vlen, &encoding, sizeof (encoding)); > > Never seen this one. Does it apply to prehistoric compilers only? No, but I neglected to mention this was bulding with -O1 -fno-inlines. To be honest, I'd forgotten that was the way I was building.. (-O1 -fno-inlines can help quite a bit when debugging.) > *waves objection flag* though honestly the only bit that's really Heh. > objectionable is the bit that's actually broken, below (the rest is just > me wondering why on earth anyone would care about warnings seen only > with decade-old compilers). Because people build binutils on older systems with decades-old compilers. > > > diff --git a/libctf/ctf-create.c b/libctf/ctf-create.c > > index d0255e5ba7f..99ff4882fd9 100644 > > --- a/libctf/ctf-create.c > > +++ b/libctf/ctf-create.c > > @@ -551,6 +551,10 @@ ctf_add_encoded (ctf_dict_t *fp, uint32_t flag, > > case CTF_K_FLOAT: > > encoding = CTF_FP_DATA (ep->cte_format, ep->cte_offset, ep->cte_bits); > > break; > > + default: > > + /* ctf_assert is opaque to compilers. This dead code avoids a > > + warning about "encoding" being used uninitialized. */ > > Hmm. Do you know of any way to make it *less* opaque? :/ Um, my comment is wrong. ctf_assert is only opague with -fno-inlines. I'd forgotten I was using that option. Sorry. > > diff --git a/libctf/ctf-link.c b/libctf/ctf-link.c > > index d5433b9d9bd..360bc1a0e63 100644 > > --- a/libctf/ctf-link.c > > +++ b/libctf/ctf-link.c > > @@ -762,7 +762,7 @@ ctf_link_deduplicating_open_inputs (ctf_dict_t *fp, ctf_dynhash_t *cu_names, > > ctf_link_input_t *one_input; > > ctf_dict_t *one_fp; > > ctf_dict_t *parent_fp = NULL; > > - uint32_t parent_i; > > + uint32_t parent_i = 0; > > ctf_next_t *j = NULL; > > /* If we are processing CU names, get the real input. All the inputs > > Again, if this is only seen with GCC 4.5, I'm tempted to just ignore > warnings from a compiler this prehistoric. It also might be seen with newer compilers and some optimisation options other than plain -O2. > > diff --git a/libctf/ctf-serialize.c b/libctf/ctf-serialize.c > > index 8645f32ab20..11cbe75601e 100644 > > --- a/libctf/ctf-serialize.c > > +++ b/libctf/ctf-serialize.c > > @@ -202,17 +202,15 @@ symtypetab_density (ctf_dict_t *fp, ctf_dict_t *symfp, ctf_dynhash_t *symhash, > > } > > > > ctf_dynhash_remove (linker_known, name); > > - } > > - *unpadsize += sizeof (uint32_t); > > - (*count)++; > > > > - if (!(flags & CTF_SYMTYPETAB_FORCE_INDEXED)) > > - { > > if (*max < sym->st_symidx) > > *max = sym->st_symidx; > > } > > else > > (*max)++; > > + > > + *unpadsize += sizeof (uint32_t); > > + (*count)++; > > I think this is a change in semantics. (That (*max++) branch is no > longer executed when sym->st_type != STT_FUNC, whether or not (flags & > CTF_SYMTYPETAB_EMIT_FUNCTION) is turned on. I think you may be reading the patch wrong. The "else" now belongs to the earlier "if (!(flags & CTF_SYMTYPETAB_FORCE_INDEXED))". The only semantic change is that *max now changes before *unpadsize and *count. > > I think just initializing sym to NULL to quiet the warning would be > safer. > > > diff --git a/libctf/swap.h b/libctf/swap.h > > index d004dc14348..2dd20a27390 100644 > > --- a/libctf/swap.h > > +++ b/libctf/swap.h > > @@ -67,6 +67,7 @@ bswap_64 (uint64_t v) > > /* < C11? define away static assertions. */ > > > > #if !defined (__STDC_VERSION__) || __STDC_VERSION__ < 201112L > > +#undef _Static_assert > > #define _Static_assert(cond, err) > > #endif > > I do wish there was some way to say 'use the compiler's _Static_assert' > if available', but there's no requirement it's a macro... Right, but in the case I hit, it *is* a macro. Would you prefer #ifndef instead? -- Alan Modra Australia Development Lab, IBM