From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Suspicious warning in W64 build Date: Sun, 17 Sep 2017 17:31:00 +0300 Message-ID: <83bmm9jt23.fsf@gnu.org> References: <1017454172.910810.1504618695244@mail.libero.it> <837ex9x7vf.fsf@gnu.org> <83tw0cwcle.fsf@gnu.org> <83h8wcw3td.fsf@gnu.org> <83377vx3d0.fsf@gnu.org> <83ingnq01t.fsf@gnu.org> <83fubrpxsv.fsf@gnu.org> <83r2v9masw.fsf@gnu.org> <86a81xrndl.fsf@gmail.com> <83a81wmijy.fsf@gnu.org> <83vakkklto.fsf@gnu.org> <83poarlrcj.fsf@gnu.org> <83h8w3krx1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1505658707 27537 195.159.176.226 (17 Sep 2017 14:31:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 17 Sep 2017 14:31:47 +0000 (UTC) Cc: fabrice.popineau@centralesupelec.fr, andrewjmoreton@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 17 16:31:35 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dtabe-0006hk-6W for ged-emacs-devel@m.gmane.org; Sun, 17 Sep 2017 16:31:34 +0200 Original-Received: from localhost ([::1]:60818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dtabl-0005yh-HL for ged-emacs-devel@m.gmane.org; Sun, 17 Sep 2017 10:31:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dtab1-0005xu-68 for emacs-devel@gnu.org; Sun, 17 Sep 2017 10:30:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dtaaw-0008Ll-M2 for emacs-devel@gnu.org; Sun, 17 Sep 2017 10:30:55 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dtaaw-0008Lf-Dn; Sun, 17 Sep 2017 10:30:50 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3239 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dtaav-0004gE-Vp; Sun, 17 Sep 2017 10:30:50 -0400 In-reply-to: (message from Paul Eggert on Sun, 17 Sep 2017 00:01:09 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:218404 Archived-At: > Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org > From: Paul Eggert > Date: Sun, 17 Sep 2017 00:01:09 -0700 > > Why was the attached patch needed? What warning did it suppress? I wrote about that in http://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00448.html The warning is this: ../../emacs/src/data.c: In function 'minmax_driver': ../../emacs/src/data.c:3022:9: warning: 'accum.i' may be used uninitialized in this function [-Wmaybe-uninitialized] return accum; ^~~~~ Which seems to mean that even eassume is sometimes not enough to convince GCC 7 that the code is correct: static Lisp_Object minmax_driver (ptrdiff_t nargs, Lisp_Object *args, enum Arith_Comparison comparison) { eassume (0 < nargs); <<<<<<<<<<<<<<<<<<<<<<< Lisp_Object accum; for (ptrdiff_t argnum = 0; argnum < nargs; argnum++) { Lisp_Object val = args[argnum]; CHECK_NUMBER_OR_FLOAT_COERCE_MARKER (val); if (argnum == 0 || !NILP (arithcompare (val, accum, comparison))) accum = val; else if (FLOATP (accum) && isnan (XFLOAT_DATA (accum))) return accum; } return accum; } Since nargs > 0, the loop is always entered, but GCC seems to miss that. > As you may recall, I prefer using UNINIT to suppress uninitialized-variable warnings because it is more automatable (e.g., it is easier to automate removing it later once GCC gets fixed). If UNINIT does not work I would like to know why. UNINIT looked inappropriate to initialize a Lisp_Object which is supposed to be a number. Even initializing with Qnil didn't look right to me (it could raise some brows), and using UNINIT is only equivalent to Qnil under the current representation of Qnil, and so is insufficiently future-proof. E.g., it could become an invalid Lisp object if we decide to change representation at some future point. By contrast, args[0] was available, of the right data type, and the comment I added makes it clear what was the reason for the initialization. So using args[0] sounds like a better solution here than UNINIT. In any case, it's a valid solution.