public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>,
	gcc Patches <gcc-patches@gcc.gnu.org>,
	Richard Biener <rguenther@suse.de>
Subject: Re: PR80806
Date: Mon, 22 May 2017 04:50:00 -0000	[thread overview]
Message-ID: <bdd67844-6a27-5807-47ac-076db8d5695d@redhat.com> (raw)
In-Reply-To: <CAAgBjMkiA6FwzYYVDBA7vymvRDhd_a08vamPf_42JQ5DV5SQ8g@mail.gmail.com>

On 05/18/2017 12:55 PM, Prathamesh Kulkarni wrote:
> Hi,
> The attached patch tries to fix PR80806 by warning when a variable is
> set using memset (and friends) but not used. I chose to warn in dse
> pass since dse would detect if the variable passed as 1st argument is
> a dead store. Does this approach look OK ?
> 
> There were following fallouts observed during bootstrap build:
> 
> * double-int.c (div_and_round_double):
> Warning emitted 'den' set but not used for following call to memset:
> memset (den, 0, sizeof den);
> 
> I assume the warning is correct since there's immediately call to:
> encode (den, lden, hden);
> 
> and encode overwrites all the contents of den.
> Should the above call to memset be removed from the source ?
Unsure.  Yes, it's dead, but from a readability standpoint should it
stay?  I don't know.  This one isn't very clear.


> 
> * tree-streamer.c (streamer_check_handled_ts_structures)
> The function defines a local array bool handled_p[LAST_TS_ENUM];
> and the warning is emitted for:
> memset (&handled_p, 0, sizeof (handled_p));
> 
> That's because the function then initializes each element of the array
> handled_p to true
> making the memset call redundant.
> I am not sure if warning for the above case is a good idea ? The call
> to memset() seems deliberate, to initialize all elements to 0, and
> later assert checks if all the elements were explicitly set to true.
This one looks like it should stay to me.  It's there for defensive
purposes to catch cases if programming errors.


> 
> * value-prof.c (free_hist):
> Warns for the call to memset:
> 
> static int
> free_hist (void **slot, void *data ATTRIBUTE_UNUSED)
> {
>   histogram_value hist = *(histogram_value *) slot;
>   free (hist->hvalue.counters);
>   if (flag_checking)
>     memset (hist, 0xab, sizeof (*hist));
>   free (hist);
>   return 1;
> }
> 
> Assuming flag_checking was true, the call to memset would be dead
> anyway since it would be immediately freed ? Um, I don't understand
> the purpose of memset in the above function.
It's been like that from the day the code was introduced (initially
surrounded with an ENABLE_CHECKING.  Given the call to free, the memset
is going to get removed.    This one probably falls into the "should
just be removed" bucket.


> 
> * testsuite fallout
> I verified regressing test-cases were not false positives and added
> -Wno-unused-but-set-variable.
I think the real question is do we want to warn here.   I can certainly
see both sides of the issue.

jeff

  reply	other threads:[~2017-05-22  4:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 18:56 PR80806 Prathamesh Kulkarni
2017-05-22  4:50 ` Jeff Law [this message]
2017-05-23 13:50   ` PR80806 Prathamesh Kulkarni
2017-05-23 15:59 ` PR80806 Martin Sebor
2017-05-24  5:42   ` PR80806 Martin Sebor
2017-06-29 17:57   ` PR80806 Jeff Law
2017-06-29 18:05     ` PR80806 Jeff Law
2017-06-29 21:45       ` PR80806 Martin Sebor
2017-06-29 18:20 ` PR80806 Jeff Law
2017-06-30  8:25   ` PR80806 Richard Biener
2017-06-30  8:33     ` PR80806 Jakub Jelinek

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=bdd67844-6a27-5807-47ac-076db8d5695d@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=prathamesh.kulkarni@linaro.org \
    --cc=rguenther@suse.de \
    /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).