This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jason Merrill <jason at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 9 Jul 2014 13:08:50 +0200
- Subject: Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
- Authentication-results: sourceware.org; auth=none
- References: <20140708125017 dot GN31640 at tucnak dot redhat dot com> <p35hitgbscyj3xuum5kryq1g dot 1404847489032 at email dot android dot com> <20140708203151 dot GP31640 at tucnak dot redhat dot com> <53BC71CE dot 6000504 at redhat dot com> <CAFiYyc13k2cQT7mrrzBYpOvLLghPRLbiy-byMmvVn9tmEpmvbA at mail dot gmail dot com> <20140709103255 dot GS31640 at tucnak dot redhat dot com> <CAFiYyc1nLt97fdJ6gOWNkVWEZn13ocKgjtd94kWtgNXod5F58w at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot 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