From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31613 invoked by alias); 18 Nov 2016 17:39:03 -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 31561 invoked by uid 89); 18 Nov 2016 17:39:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=fno-foo, fmoo, AFAICS, radix X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Nov 2016 17:39:00 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1c7n7r-0004u1-G1 from Sandra_Loosemore@mentor.com ; Fri, 18 Nov 2016 09:38:59 -0800 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 18 Nov 2016 09:38:57 -0800 Subject: Re: PING [PATCH] enable -fprintf-return-value by default To: Martin Sebor , Gcc Patch List References: <1e7776ca-c7f6-4d93-6b33-2c51dc5a8689@gmail.com> <582E92FA.8070800@codesourcery.com> <69e6094e-0ff3-0f2e-83da-e41061008a10@gmail.com> From: Sandra Loosemore Message-ID: <582F3CAF.2000306@codesourcery.com> Date: Fri, 18 Nov 2016 17:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <69e6094e-0ff3-0f2e-83da-e41061008a10@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-SW-Source: 2016-11/txt/msg01978.txt.bz2 On 11/18/2016 09:01 AM, Martin Sebor wrote: > 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. Well, how about the rule is that you look at the convention of the specific list you are adding something to? At least that way we retain local consistency and don't mess up those parts of the documentation that we have already tried to organize in some way. There's so much material in the command-line options chapter that it would be hard to figure out how to present it even if the content were completely static, much less when people are adding/renaming/modifying options all the time. -Sandra