From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 42BEC3858D33 for ; Fri, 22 Dec 2023 03:43:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 42BEC3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 42BEC3858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703216619; cv=none; b=MzhSGTI8UAEuAIRLNxXjZbUtiuwswDElAi7zsJnqIEaQ1HFQOWNru3hXMYTrNTDkHfzys0lit8TmCX8R8YBnIYjVJtvmeQRQWZwluSpy388rOJUhlzoiEpfv4mDrFsO7gKVNBwW5pjZEgfuHYAgXv2TSwpDuOAfLkA7a2qPgaGU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703216619; c=relaxed/simple; bh=fCSx/cGsR7UeeNxB55sbKRkZq0/LRURkHCsJ4/voy94=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=TQVjT9VLyxDK1sOxkeH7Dx8hrkL2tCGcUTYkV9H57lrQvXKTdcWHe0DqgaXuBnQkBPMY3tZjA38qvGal0qJW5Mqtc7/9Csct7OwNRCFsZvK/dgC4bCHY7mQc89mE5Rw6DhWjSgKRe5CH2VlAs4gKIJFHJD0q9l+XD/KEyCsP4+w= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1703216617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qp4KVCZdFDSacoaMmhoTje8U+D8vybnXgfCwuIB4O78=; b=Qeq91OWlo9q9OIXLyX+VDRPscsy+7gZI8+eIfenMZbCI/rsJMClAEa404W9s/4bgPqC1AE 9Ug2IaiwCapju3jYGOfKZ34ntpf8LqT3DmnR/wlXauFZshgbpbl9zzjCoX5FEULHw1BMlD prZZkdpVilN4DLzVzYnV9vxOfRagIjo= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-272-Q70CThQ1PHuNkDPFz1fz_Q-1; Thu, 21 Dec 2023 22:43:36 -0500 X-MC-Unique: Q70CThQ1PHuNkDPFz1fz_Q-1 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-67f694c649dso15149216d6.1 for ; Thu, 21 Dec 2023 19:43:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703216615; x=1703821415; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qp4KVCZdFDSacoaMmhoTje8U+D8vybnXgfCwuIB4O78=; b=e+Ud9Mr5s6QeY4sau8WYCXzXRdWoruqRe+TwkLHP+EaZstvl8ihqGRpsufnoScaebu 5CjA/dYpzO+sT3hjCdV9NWw2Vt7M4Ti0SD66nbzZWVlMjlR+eJJXPPnYDjaEWLZhaCxK 0jkPUz8OzRG+EW9VjYanwYBu+qD8OIPkpQjbqZv8SKAGRotoBoBHszOGv/iSZUGR1pay s+LwrK88drfAJU3QAvjy8tYqn6GamTW9EJw6un8HHhoYMZ7Hzp0nPvstOgLBfUdJJVhD 716LNYytdOeXj2rWnPtrycAfJnfgl6ZGz1eoFEf+KiN7FW+Dy/zq/sOTDXsb0JJ5EfhE X/SQ== X-Gm-Message-State: AOJu0Yz/cegWiQOHtbv9E5vbFw07N5mtI3hAxUQGTMON9hSBOc8jtbGJ 1A4Qo+mMIdYiwdbm87Go94XrIahkYoX6Z5G4FR/dojOYmNunHEHkYFpUryBLY5J7LQO2I8AkRSa Dx/NNGph6mBWo0b8= X-Received: by 2002:a05:6214:2343:b0:67f:225b:f346 with SMTP id hu3-20020a056214234300b0067f225bf346mr746127qvb.70.1703216615696; Thu, 21 Dec 2023 19:43:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IFKFtaUtVeHMYDcbpJ1zM6RPtEhpw8JYIxuwWZ+1fGvYxjFb8CUDNylctyCuFZk+geZYdj4OA== X-Received: by 2002:a05:6214:2343:b0:67f:225b:f346 with SMTP id hu3-20020a056214234300b0067f225bf346mr746118qvb.70.1703216615346; Thu, 21 Dec 2023 19:43:35 -0800 (PST) Received: from t14s.localdomain (c-76-28-97-5.hsd1.ma.comcast.net. [76.28.97.5]) by smtp.gmail.com with ESMTPSA id o8-20020a0cecc8000000b0067f37d9196esm1077168qvq.93.2023.12.21.19.43.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Dec 2023 19:43:34 -0800 (PST) Message-ID: <8c605c042acb7ea3de38fdb7f953969a1560fd19.camel@redhat.com> Subject: Re: Expected warning maybe-uninitialized does not appear using g++13.2.0? From: David Malcolm To: Eric Batchelor , gcc@gcc.gnu.org Date: Thu, 21 Dec 2023 22:43:33 -0500 In-Reply-To: <31bdc2a5-3556-4ccb-8a91-723ccd71652c@bookmanager.com> References: <31bdc2a5-3556-4ccb-8a91-723ccd71652c@bookmanager.com> User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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, 2023-12-20 at 11:16 -0800, Eric Batchelor wrote: > Hello, I unintentionally stumbled upon some strange behaviour that=20 > occurred due to a typo. > I reproduced the behaviour where an object (std::string in my case) > can=20 > be passed to a function by reference, uninitialized, WITHOUT a > compiler=20 > warning. > Changing the code to pass the object by value DOES emit the warning. > I don't think the compiled code is incorrect, it segfaults presumably > due to uninitialized members. > I understand there may seldom be a reason to use uninitialized > objects,=20 > so "don't do that," but as I said this was unintentional and it seems > that it should have generated a warning, which have saved some=20 > head-scratching. >=20 > Code to reproduce: >=20 > #include > std::string f(std::string &s) { > =C2=A0=C2=A0 s.append("x"); > =C2=A0=C2=A0 return s; > } > int main() { > =C2=A0=C2=A0 std::string a =3D f(a); > } >=20 > Compile and run (no warning): >=20 > $ g++ -o uninit_obj uninit_obj.cpp -std=3Dc++23 -Wall -Wpedantic - > Wextra=20 > && ./uninit_obj > Segmentation fault (core dumped) >=20 > No difference whether using -O0 (or 1 2 3) As I understand it, -Wmaybe-uninitialized is purely intraprocedural i.e. it works within each individual function, without considering the interactions *between* functions. FWIW, -fanalyzer does attempt to model interprocedural interactions, but doesn't yet work properly on C++ code. For your example, it happens to generate some warnings, but the wording is really vague; see: https://godbolt.org/z/a1q7xYMjb and it might well be getting other things wrong (as I said, it doesn't yet properly work on C++). Dave >=20 > If I change the function to pass by value, std::string f(std::string > s),=20 > and rerun, I get the expected compiler warning: >=20 > $ g++ -o uninit_obj uninit_obj.cpp -std=3Dc++23 -Wall -Wpedantic - > Wextra=20 > && ./uninit_obj > uninit_obj.cpp: In function 'int main()': > uninit_obj.cpp:7:22: warning: 'a' may be used uninitialized=20 > [-Wmaybe-uninitialized] > =C2=A0=C2=A0=C2=A0=C2=A0 7 |=C2=A0=C2=A0 std::string a =3D f(a); > [...] > terminate called after throwing an instance of 'std::bad_alloc' > =C2=A0=C2=A0 what():=C2=A0 std::bad_alloc > Aborted (core dumped) >=20 > Output from g++ -v: >=20 > Using built-in specs. > COLLECT_GCC=3Dg++ > COLLECT_LTO_WRAPPER=3D/usr/local/gcc13/libexec/gcc/x86_64-pc-linux- > gnu/13.2.0/lto-wrapper > Target: x86_64-pc-linux-gnu > Configured with: ../gcc-13.2.0/configure --disable-multilib=20 > --enable-languages=3Dc,c++ --prefix=3D/usr/local/gcc13 --program-suffix= =3D- > 13=20 > --enable-libstdcxx-backtrace=3Dyes > Thread model: posix > Supported LTO compression algorithms: zlib > gcc version 13.2.0 (GCC) >=20 > Thanks >=20