From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11724 invoked by alias); 6 May 2011 08:52:44 -0000 Received: (qmail 11704 invoked by uid 22791); 6 May 2011 08:52:42 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 May 2011 08:52:26 +0000 Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p468qOkk031230 for ; Fri, 6 May 2011 01:52:25 -0700 Received: from vxk20 (vxk20.prod.google.com [10.241.35.148]) by hpaq2.eem.corp.google.com with ESMTP id p468qMFA027768 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 6 May 2011 01:52:23 -0700 Received: by vxk20 with SMTP id 20so4786010vxk.14 for ; Fri, 06 May 2011 01:52:22 -0700 (PDT) Received: by 10.220.200.131 with SMTP id ew3mr83153vcb.49.1304671942112; Fri, 06 May 2011 01:52:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.146 with HTTP; Fri, 6 May 2011 01:52:02 -0700 (PDT) In-Reply-To: References: <20110505182734.5CC6A1E819C@cgda.mtv.corp.google.com> From: Chris Demetriou Date: Fri, 06 May 2011 08:53:00 -0000 Message-ID: Subject: Re: [google][RFA] add extra text to stack frame warnings (issue4479046) To: Andrew Pinski Cc: Diego Novillo , reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true 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 X-SW-Source: 2011-05/txt/msg00488.txt.bz2 On Thu, May 5, 2011 at 12:19, Andrew Pinski wrote: > Is there a reason why this cannot be an option that someone passes on > the command line of GCC instead of a configure option? I don't think we ever considered that approach. That's actually a great idea, I think better for our purposes than a configuration option. (Previously, it didn't much matter, since in our tree this was a small local patch directly to final.c.) Thank you, I'm going to do over taking the approach you suggested. > Also can you > show an example of why this message would be changed? We use the stack frame size warning on some of our internal code. (Obvious, I guess -- otherwise, why would I be messing with it. 8-) In summary, -Wframe-larger-than does not always produce obvious results. 8-) There are common questions, e.g.: * why we care about this warning at all (i.e., "why does stack frame size matter?!"). * how to identify the cause of the warning (since it's not necessarily obvious what's causing stack growth, and because the warning is somewhat ... finicky thanks to inlining and thanks to sometimes-less-than-great reuse of stack space from dead variables in optimized and especially unoptimized code). * how to work around, or if absolutely necessary disable the warning. So, to help, when we output the frame-size warning, we also provide a link to an internal documentation page to help with the stuff mentioned above. Of necessity, the doc link we provide explains our internal circumstances and workarounds. (Generic documentation wouldn't help with a number of the questions.) In theory, a more general warning-text-addition mechanism could be useful. e.g. a flag that said "when outputting a warning about flag 'foo', output this additional text" could be useful. However, we haven't felt the need to do this for other warnings. IMO, a general solution along these lines would be solving a problem that ~nobody has. 8-) If one wanted to dive into warning message changes, there are other, more substantial changes IMO that would be generally useful and would enable this type of functionality via external tools. E.g., structured warnings with fixed identifiers (numbers, words, whatever), blah blah blah. If there were support for *that*, then people could write wrapper tools that automatically annotate warnings with additional information as necessary. (it would also make parsing errors/warnings a lot easier. 8-) Anyway, thanks for the suggestion. 8-) chris