From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20334 invoked by alias); 9 Oct 2018 10:34:10 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 16163 invoked by uid 89); 9 Oct 2018 10:33:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sk:gdbscm_ X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Oct 2018 10:33:43 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BDC5585363; Tue, 9 Oct 2018 10:33:41 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8121E10027CE; Tue, 9 Oct 2018 10:33:40 +0000 (UTC) Subject: Re: gcc warning with "some variable may be used uninitialized in this function [-Wmaybe-uninitialized]" when building under msys To: Tom Tromey References: <46b498a8-ba44-3f67-783d-85cd5ac8f0c9@gmail.com> <9aa0ec3d6356d1e0c746697161918576@polymtl.ca> <8305e255-1621-96a7-cf06-3cd1cd27ceae@redhat.com> <87d0spf0au.fsf@tromey.com> Cc: Simon Marchi , asmwarrior , GDB Development From: Pedro Alves Message-ID: Date: Tue, 09 Oct 2018 10:34:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87d0spf0au.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00008.txt.bz2 On 10/05/2018 06:08 AM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> If the warnings confuse people too much, I'd be OK with > Pedro> disabling -Wmaybe-uninitlized completely. I left it as a > Pedro> -Wno-error warning because even though it produces false positives, > Pedro> it also helps catch bugs earlier in the compile-edit cycle, > Pedro> when you're hacking some code, when you're introducing > Pedro> uninitialized uses, and "make" ends up compiling just a few > Pedro> files. > > It caught a bug in the -Wshadow=local series; and I think in most cases > the false reports are easily handled with an initialization. I suppose > in theory these initializations could themselves mask bugs, but I don't > recall that ever actually happening (or at least being noticed). The sort of bug not-initializing prevents is that kind that would be caught during development, via more -Wmaybe-unitialized/-Wuninitialized warnings, or simply GDB crashes/regressions. I.e., the bug caused by reworking the code creating a new path that leads to the variable not being initialized. I do recall that happening to me, but it's of course hard to measure. If we can avoid the forced-initialization, say, by restructuring code, I tend to prefer that. The usual case that leads to false positives is around TRY/CATCH, exception flow. For example, in the guile hunk at , I think the problem is that GDBSCM_HANDLE_GDB_EXCEPTION is defined as: #define GDBSCM_HANDLE_GDB_EXCEPTION(exception) \ do { \ if (exception.reason < 0) \ { \ gdbscm_throw_gdb_exception (exception); \ /*NOTREACHED */ \ } \ } while (0) while the code that is using it is: TRY { gdb::unique_xmalloc_ptr buffer; LA_GET_STRING (value, &buffer, &length, &char_type, &la_encoding); buffer_contents = buffer.release (); } CATCH (except, RETURN_MASK_ALL) { xfree (encoding); GDBSCM_HANDLE_GDB_EXCEPTION (except); } END_CATCH Note how GDBSCM_HANDLE_GDB_EXCEPTION is used inside a CATCH block, where we know that exception.reason is definitely < 0. GCC doesn't know that, so it thinks there could be a path where the catch block doesn't rethrow, leaving buffer_contents uninitialized. So replacing that GDBSCM_HANDLE_GDB_EXCEPTION call with a direct call to gdbscm_throw_gdb_exception makes the warning would go away. So for these types of bugs / warnings, I agree, the warning is useful. It's for the tricker cases, like std::optional, where a variable's initialization depends on the value of some other state (like another variable), where the warning ends up producing false positives. > > It would be good if gcc could recognize std::optional and not issue the > warning when it is used. Perhaps gdb could then just always use > optional for the maybe-not-initialized cases. Really not sure whether that is possible. I think there's hope that GCC value tracking becomes smart enough that these std::optional-related warnings end up disappearing (which usually means the code will optimize better too). Fingers crossed, at least. Thanks, Pedro Alves