From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130629 invoked by alias); 18 Nov 2016 16:01:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 130583 invoked by uid 89); 18 Nov 2016 16:01:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-qk0-f178.google.com Received: from mail-qk0-f178.google.com (HELO mail-qk0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Nov 2016 16:01:28 +0000 Received: by mail-qk0-f178.google.com with SMTP id n204so268959936qke.2 for ; Fri, 18 Nov 2016 08:01:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=JdHRCVUlf2/w1ICS8UGj+gDJqsI2J0LCiSH3/DF05AY=; b=IGIEviK5tGeUgpZKhAoEFKasqK7e4EpLpArmUa5S/FxBMdTgs4IWFB0+lZ2WgO/tc8 oKhNWAJPYBodU4p5cv8EkA3GZUDzcOCqnBu96D99z02aoCQJ1/kULFWURaLNf//zZklZ nbobZDO8hmwVQktXocHBpudavxGvVzWt1a3lxDlQhy+8ZJic+lOfdrQrbki40OeVbo26 +UfEVugEVtPq2jPG14V7j2VFgi+O+nf0a3akSRS/xjj6oA2ZgFBKZBYAHzob1DvTW938 c6GqKPGuN18e5RqZ/fCV+RldwskJ8jNjdgWLGbNJveqzhvy6TaTAInVQu/iiYheuyAfL QFww== X-Gm-Message-State: AKaTC002o/YP1hhmGXrdpKDyOCuyJBIDTW/EdyDNmqfM/NyIIQqWpxivb8PoGe4o76wdoQ== X-Received: by 10.55.8.20 with SMTP id 20mr545907qki.3.1479484886966; Fri, 18 Nov 2016 08:01:26 -0800 (PST) Received: from [192.168.0.26] (75-166-206-79.hlrn.qwest.net. [75.166.206.79]) by smtp.gmail.com with ESMTPSA id 6sm4322672qke.18.2016.11.18.08.01.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 08:01:26 -0800 (PST) Subject: Re: PING [PATCH] enable -fprintf-return-value by default To: Sandra Loosemore , Gcc Patch List References: <1e7776ca-c7f6-4d93-6b33-2c51dc5a8689@gmail.com> <582E92FA.8070800@codesourcery.com> From: Martin Sebor Message-ID: <69e6094e-0ff3-0f2e-83da-e41061008a10@gmail.com> Date: Fri, 18 Nov 2016 16:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <582E92FA.8070800@codesourcery.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg01948.txt.bz2 On 11/17/2016 10:34 PM, Sandra Loosemore wrote: > On 11/16/2016 09:49 AM, Martin Sebor wrote: >> I'm looking for an approval of the attached patch. >> >> I've adjusted the documentation based on Sandra's input (i.e., >> documented the negative of the option rather than the positive; >> thank you for the review, btw.) >> >> On 11/08/2016 08:13 PM, Martin Sebor wrote: >>> The -fprintf-return-value optimization has been disabled since >>> the last time it caused a bootstrap failure on powerpc64le. With >>> the underlying problems fixed GCC has bootstrapped fine on all of >>> powerpc64, powerpc64le and x86_64 and tested with no regressions. >>> I'd like to re-enable the option. The attached patch does that. >> >> [snip] >> >> Index: gcc/doc/invoke.texi >> =================================================================== >> --- gcc/doc/invoke.texi (revision 242500) >> +++ gcc/doc/invoke.texi (working copy) >> @@ -384,7 +384,7 @@ Objective-C and Objective-C++ Dialects}. >> -fno-toplevel-reorder -fno-trapping-math -fno-zero-initialized-in-bss >> @gol >> -fomit-frame-pointer -foptimize-sibling-calls @gol >> -fpartial-inlining -fpeel-loops -fpredictive-commoning @gol >> --fprefetch-loop-arrays -fprintf-return-value @gol >> +-fprefetch-loop-arrays -fno-printf-return-value @gol >> -fprofile-correction @gol >> -fprofile-use -fprofile-use=@var{path} -fprofile-values @gol >> -fprofile-reorder-functions @gol > > Please keep this list alphabetized -- the other "-fno-*" options are > sorted as such. The documentation parts of the patch are OK with that > fixed, but I can't approve changing the default for the option. I kept the option in the same place on the assumption that it was the "printf" radix of the name, not the "no-" prefix, that these were alphabetized by. But now that you point it out and I've looked more carefully at some of the other options, I see that in some sections they are listed strictly alphabetically (-fno-foo after -fmoo) while in others it's the way you suggest. AFAICS, the former style looks prevalent in the C++ Language Options and the in Warning Options, for example. The latter seems to be more popular in the Optimization Options section (though there are counterexamples). I'm happy to follow either of these conventions as long as its consistent. Otherwise, without both kinds of examples to choose from, I don't think I can trust my brain to remember yet another rule. Martin