From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33431 invoked by alias); 28 Oct 2016 08:17:53 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 33251 invoked by uid 89); 28 Oct 2016 08:17:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=indicator, hides, recommendation, HX-Received:Fri X-HELO: mail-yb0-f193.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2UgyPqtxHvt+VCoQCgQi6sQTeerdzw535cZzd2uXu/s=; b=HVQWWlBcnwd5UeB9RhzFE+xsqPrelWJ39VST8Ba0PqsdaeCGR5wqxW8iZxDEpD9sLc A40RoEucFwQQJEvAqCDSUTu1gybO06MJcKW9F5IgiBvnpWTraj7Pl62onLCjqOjYtJqx +WRXQnGi2dnrwXuncmps9b1l/F2li0QvTelaxoiev5JCSLpTX6PsQMBRg8mpSAA1DB/1 mmYuJ/Dpn++kC7ZNZPJYkawnQO0q84lykx4oUavTtRGwQZ8aMNm9F9qbq0JXWmoDw6NC K4tZbIxdZyKOoOTn50r6+unuN+IPFptOsGtXwLrsUyjEYvGerHh/DZib0QoQ4ucHkZaA bohg== X-Gm-Message-State: ABUngvcd3A0/+TR0WHWoyVW8j/KDyKlKmznpuz6YrFznp4CTCWHlZR3wmR2yfxrA08Xp/kecp/jcqtLD+jv+6A== X-Received: by 10.37.113.132 with SMTP id m126mr6607572ybc.128.1477642659708; Fri, 28 Oct 2016 01:17:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20863164.XNWC5rYB1g@wuerfel> References: <6eac682f-26fa-6a47-9497-357206266ba1@redhat.com> <6be7dce5-bfa7-32c7-5bac-6c3b79776683@redhat.com> <9d58289e-07fb-4bae-d7d3-8055a6c96a3a@redhat.com> <20863164.XNWC5rYB1g@wuerfel> From: Andrew Pinski Date: Fri, 28 Oct 2016 08:17:00 -0000 Message-ID: Subject: Re: [PATCH] Fix -Os related -Werror failures. To: Arnd Bergmann Cc: GNU C Library , Jeff Law , Florian Weimer , "Carlos O'Donell" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-10/txt/msg00512.txt.bz2 On Fri, Oct 28, 2016 at 1:12 AM, Arnd Bergmann wrote: > On Friday, October 28, 2016 12:44:32 AM CEST Jeff Law wrote: >> On 10/28/2016 12:32 AM, Florian Weimer wrote: >> > On 10/28/2016 06:46 AM, Carlos O'Donell wrote: >> >> +/* With GCC 5.3 when compiling with -Os the compiler emits a warning >> >> + that buf[0] and buf[1] may be used uninitialized. This can only >> >> + happen in the case where tmpbuf[3] is used, and in that case the >> >> + write to the tmpbuf[1] and tmpbuf[2] was assured because >> >> + ucs4_to_cns11643 would have filled in those entries. The difficulty >> >> + is in getting the compiler to see this logic because tmpbuf[0] is >> >> + involved in determining the code page and is the indicator that >> >> + tmpbuf[2] is initialized. */ >> >> +DIAG_PUSH_NEEDS_COMMENT; >> >> +DIAG_IGNORE_NEEDS_COMMENT (5.3, "-Wmaybe-uninitialized"); >> > >> > This hides the warning for -O2 builds as well, so I don't think this is >> > a good idea. >> > >> > Those who want to build with -Os or other special compiler flags should >> > just configure with --disable-werror. We can't account for every >> > optimization someone might want to disable in their build. >> That'd be my recommendation. >> >> What often happens in these cases is the compiler in its default mode of >> operation is able to statically eliminate a conditional branch on a >> particular path. However, to do so the compiler has to duplicate code. >> >> Not surprisingly, there's a cost/benefit tradeoff here and the >> heuristics are largely driven by the real or estimated profile data as >> well as the coarser "optimize for code space". So changing flags >> changes the output of those heuristics and ultimately can result in >> leaving paths in the CFG that can not be executed -- and that often >> leads to false positive may-be-uninitialized warnings and such. >> >> Long term I would like to find a good way to mark paths that are not >> executable, but are not profitable to eliminate, then utilize that >> information to prune various "may" warnings. That would make those kind >> of warnings more stable across different optimization levels as well as >> more stable release-to-release. But that's definitely in the "future >> work" area. > > I've spent a lot of time trying to eliminate -Wmaybe-uninitialized > warnings from the Linux kernel. Here are some data points that you > may find useful too: > > - Building with -Os causes many false positives starting with gcc-4.9, > and I have disabled the warning for this specific flag. I believe > this is due to the lack of the "-fschedule-insns" optimization step No this is false. It is usually due to jump threading is not as aggressive at -O2 than -Os due to -Os not wanting to increase code size. Thanks, Andrew > - Building with -O3 apparently also causes some false positives, but > we don't normally do that in the kernel, and the only architecture > port that does it also disables the warnings > - Two more gcc options that cause false positives are -fprofile-arcs > and some of the -fsanitize=... options > - overall, gcc-4.9 improved much over gcc-4.8 in these warnings, > but they have a different set of false-positives. As gcc-4.8 is > getting old, I'm pushing a patch to also disable the warning > for all 4.8 builds. Prior to v4.8, there was no option to disable > maybe-uninitialized warnings. > - gcc-5 and gcc-6 appear to be slightly better than gcc-4.9 but also > introduce a small number of additional false-positive warnings, > apparently this happens mostly because they make different > inlining decisions, not because something fundamentally changed. > Generally speaking, if any of 4.9, 4.x or 5.x produce a warning > in some configurations, it's likely that the other ones will > do the same, depending on a combination target architecture and > optimization flags that impact inlining. > - I found that most often when gcc is confused about whether a > variable is uninitialized or not, the source code tends to be > confusing to a human reader as well and rewriting it differently > results in better readability and better object code while > avoiding the warning. There are always other cases in which > this is not possible though. > > Arnd