public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Chris Demetriou <cgd@google.com>
To: Andrew Pinski <pinskia@gmail.com>
Cc: Diego Novillo <dnovillo@google.com>,
	reply@codereview.appspotmail.com,        gcc-patches@gcc.gnu.org
Subject: Re: [google][RFA] add extra text to stack frame warnings (issue4479046)
Date: Fri, 06 May 2011 08:53:00 -0000	[thread overview]
Message-ID: <BANLkTi=x=x6epKSrJAH=6ZgQGB4v8Cudbw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTin7bURWJG7+NajxJMi6YwXjK_xxFQ@mail.gmail.com>

On Thu, May 5, 2011 at 12:19, Andrew Pinski <pinskia@gmail.com> 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

  reply	other threads:[~2011-05-06  8:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05 18:39 Chris Demetriou
2011-05-05 19:09 ` Diego Novillo
2011-05-05 19:23   ` Andrew Pinski
2011-05-06  8:53     ` Chris Demetriou [this message]
2011-05-06 17:09       ` Andrew Pinski
     [not found]         ` <BANLkTimMdjRDwC7Z-xsAbV4GdJn8gP+QgA@mail.gmail.com>
2011-06-10  8:35           ` Chris Demetriou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTi=x=x6epKSrJAH=6ZgQGB4v8Cudbw@mail.gmail.com' \
    --to=cgd@google.com \
    --cc=dnovillo@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=pinskia@gmail.com \
    --cc=reply@codereview.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).