From: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>
To: Jeff Law <law@redhat.com>
Cc: gcc Patches <gcc-patches@gcc.gnu.org>,
Richard Biener <rguenther@suse.de>
Subject: Re: PR80806
Date: Tue, 23 May 2017 13:50:00 -0000 [thread overview]
Message-ID: <CAAgBjMk22Wyv0Unu66kLqzKOHnJ90SRDiw=PR=v64QacqhwmXA@mail.gmail.com> (raw)
In-Reply-To: <bdd67844-6a27-5807-47ac-076db8d5695d@redhat.com>
On 22 May 2017 at 10:03, Jeff Law <law@redhat.com> wrote:
> 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.
Hi Jeff,
Thanks for the suggestions. I agree that warning for the above cases
in tree-streamer.c and double-int.c may not be ideal.
Should we perhaps only warn if there's a single use of the pointer in
the call to memset (and friends) like in the test-case
reported in PR ? But then I fear the warning may end up being a bit artificial.
Thanks,
Prathamesh
>
> jeff
>
next prev parent reply other threads:[~2017-05-23 13:50 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 ` PR80806 Jeff Law
2017-05-23 13:50 ` Prathamesh Kulkarni [this message]
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='CAAgBjMk22Wyv0Unu66kLqzKOHnJ90SRDiw=PR=v64QacqhwmXA@mail.gmail.com' \
--to=prathamesh.kulkarni@linaro.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=law@redhat.com \
--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).