public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Alexandre Duret-Lutz <adl@lrde.epita.fr>
Cc: gcc-help@gcc.gnu.org
Subject: Re: missing warning about parameter set bug no longer used
Date: Sat, 07 Jan 2012 02:56:00 -0000	[thread overview]
Message-ID: <mcrr4zc995x.fsf@dhcp-172-18-216-180.mtv.corp.google.com> (raw)
In-Reply-To: <CA+Xfj9QouiA-fUupJhacmf4cayJ2zie3HX=DkOkuovSBZHbQXg@mail.gmail.com>	(Alexandre Duret-Lutz's message of "Fri, 6 Jan 2012 11:57:01 +0100")

Alexandre Duret-Lutz <adl@lrde.epita.fr> writes:

> The following file foo.c is a simplified version of a subtler bug I
> found in my code.
> int b;void bar(int a);void foo(int a){  bar(a);  a = 42;}
>
> The line a = 42 is in fact a typo in my code: I meant b = 42. I do
> *not* expect the compiler to detect that I made a typo, but I would
> like the get a warning that I am assigning to a local variable (or a
> function parameter) that is not going to be used anymore. If I compile
> this file with
> % gcc-4.6 -Wall -Wextra -pedantic -O3 -c foo.c
> I get absolutely no warning. Inspecting the generated code shows that
> the assignment a = 42 is not performed, so gcc is perfectly well aware
> that this instruction is useless (hence potentially bogus). Commenting
> the call to bar(a); does produce a "warning: parameter ‘a’ set but not
> used [-Wunused-but-set-parameter]", so it seems like gcc will not warn
> as long as variable a is used somewhere in the function, even if it is
> before the assignment.
> My questions:
> 1. Is there a way to tell gcc to produce a warning for such case?2. Is
> there a reason for the actual behavior? I.e, some cases were it is
> actually desirable to assign to local variables that will be thrown
> away by the optimizer?

As far as I know way there is no way to get a warning for this case at
present.

GCC does not currently have a framework for tracking sets and uses which
is independent of the optimizers.  And warnings that are dependent on
the optimizers are troublesome for many reasons.  GCC does have some
warnings like that today, and there are perennial sources of compliant.
So there is unlikely to be an easy way to implement this warning.

Ian

      reply	other threads:[~2012-01-06 14:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-06 11:02 Alexandre Duret-Lutz
2012-01-07  2:56 ` Ian Lance Taylor [this message]

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=mcrr4zc995x.fsf@dhcp-172-18-216-180.mtv.corp.google.com \
    --to=iant@google.com \
    --cc=adl@lrde.epita.fr \
    --cc=gcc-help@gcc.gnu.org \
    /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).