public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jason Merrill <jason@redhat.com>,
	       "Joseph S. Myers" <joseph@codesourcery.com>,
	       "Carlos O'Donell" <carlos@redhat.com>,
	       Siddhesh Poyarekar <siddhesh@redhat.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>,
	       GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
Date: Wed, 09 Jul 2014 11:09:00 -0000	[thread overview]
Message-ID: <20140709110850.GV31640@tucnak.redhat.com> (raw)
In-Reply-To: <CAFiYyc1nLt97fdJ6gOWNkVWEZn13ocKgjtd94kWtgNXod5F58w@mail.gmail.com>

On Wed, Jul 09, 2014 at 12:51:32PM +0200, Richard Biener wrote:
> At least it shouldn't (they are not required to be shared and usually are not
> if they've gone a transition from TREE_OVERFLOW to !TREE_OVERFLOW).
> 
> Well, still feels ugly to me - but it's Jasons call in the end.

Another possibility is to keep that info on the side, something e.g.
the C FE already does.  There, c_parser_expr_list fills for the first 3
arguments (if requested by the caller) info about whether the argument used
to be originally a sizeof, and then the caller can look at this info.
For the literal zeros, it can be stored as a bitmask in a single char.

All of these warnings (-Wsizeof-pointer-memaccess, -Wsizeof-array-argument
and -Wmemset-transposed-args) are implemented in a hackish way, because we
fold everything too early.  Perhaps for such analysis we want a FOLDED_EXPR
which would have arguments what it has been folded to and the original tree,
for the purposes of code generation the first argument would be used and 
the second one only for the analysis.  We don't have that many spots where
we need the original trees to be analyzed yet for it to be worth it though
IMHO.

	Jakub

  reply	other threads:[~2014-07-09 11:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-08 12:50 Jakub Jelinek
2014-07-08 19:25 ` Jason Merrill
2014-07-08 19:38   ` Carlos O'Donell
2014-07-08 20:32   ` Jakub Jelinek
2014-07-08 22:33     ` Jason Merrill
2014-07-09 10:26       ` Richard Biener
2014-07-09 10:33         ` Jakub Jelinek
2014-07-09 10:51           ` Richard Biener
2014-07-09 11:09             ` Jakub Jelinek [this message]
2014-07-08 19:34 ` Carlos O'Donell
2014-07-09 14:40 Manuel López-Ibáñez
2014-07-09 21:28 ` Jason Merrill

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=20140709110850.GV31640@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=carlos@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=richard.guenther@gmail.com \
    --cc=siddhesh@redhat.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).