Re: [PING #2][PATCH] enable ranger and caching in pass_waccess
On Mon, Aug 30, 2021 at 4:27 PM Martin Sebor wrote:
>
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578135.html
>
> Are there any further comments on the patch?
>
> Richard, you were kind enough to review the first two patches in this
> series. Would you mind doing the same for this one? It continues in
> the same vein.
OK.
Richard.
> Martin
>
> On 8/25/21 3:26 PM, Martin Sebor wrote:
> > On 8/25/21 10:14 AM, Andrew MacLeod wrote:
> >> On 8/25/21 11:20 AM, Martin Sebor wrote:
> >>> Ping: Andrew, did I answer your questions? Do you (or anyone else)
> >>> have any other comments on the latest patch below?
> >>>
> >>> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html
> >>
> >>
> >> I wasn't attempting to block it, its outside my review purview..
> >>
> >> I was merely commenting that you should not need a pointer to a
> >> range_query at all anymore
> >>
> >>
> >>>
>
> >
> > Are you planning to transition to using the get_range_query()
> > interface instead of keeping a range_query pointer in the
> > pointer_query class?
>
> This pass and to a smaller extent the pointer_query class that's
> used by it and the strlen pass are still a work in progress.
> I also still need to convert the strlen pass to use Ranger and
> I expect it will take some changes to pointer_query. So at that
> point, if going through get_range_query (cfun) everywhere is what
> you recommend, I'm happy to do it.
>
> >> absolutely. you should not need to even know whether you have a ranger
> >> instance running or not. get_range_query will give you whichever is
> >> active, and there is ALWAYS something active.. defaulting to the
> >> global version.
> >>
> >> the code in get_range() seems to be the end of the call chain which
> >> uses the pointer and should be consolidated to something much simpler
> >>
> >> if (rvals && stmt)
> >> {
> >>if (!rvals->range_of_expr (vr, val, stmt))
> >> return NULL_TREE;
> >>
> >> <...>
> >>
> >>// ?? This entire function should use get_range_query or
> >> get_global_range_query (),
> >>// instead of doing something different for RVALS and global
> >> ranges.
> >>
> >>if (!get_global_range_query ()->range_of_expr (vr, val) ||
> >> vr.undefined_p ())
> >> return NULL_TREE;
> >>
> >>
> >> This entire section can boil down to something like
> >>
> >> if (!get_range_query (cfun)->range_of_expr (vr, val, stmt))
> >>return NULL;
> >
> > So get_range_query (cfun) will never be null? And no special handling
> > of INTEGER_CST is needed, or checking for SSA_NAME. Nice. Attached
> > is another revision of the same patch with this function simplified.
> >
> > (FYI: I expect the whole function to eventually go away, and to make
> > other similar simplifications, but I'm not there yet.)
> >
> PS There has been an effort to get rid of global variables from GCC,
> or, as the first step, to avoid accessing them directly(*). If and
> when that happens, it seems like each pass will have to store either
> the ranger instance as a member (directly or indirectly, via a member
> of a class that stores it) or the function passed to pass::execute()
> if it wants to access either.
>
> [*] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573975.html
> The patch at the link above wasn't approved but IIUC removing globals
> from GCC is still a goal.
> >>>
> >> I have no idea what direction that is going, but the net effect will
> >> be the same in the end. You'll be calling get_range_query() with
> >> either the function pointer, or the pass pointer, or something.. but
> >> you should never need to pass around a pointer to either a ranger or
> >> range-query. As I said earlier, this will likely be a pass property
> >> and accessed thru the pass eventually... but until then, use what we
> >> have.. cfun. It'll be trivial to transition down the road to whatever
> >> the ultimate solution is.
> >
> > Okay, I'll do that in my future changes.
> >
> > Martin
>
[PING #2][PATCH] enable ranger and caching in pass_waccess
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578135.html
Are there any further comments on the patch?
Richard, you were kind enough to review the first two patches in this
series. Would you mind doing the same for this one? It continues in
the same vein.
Martin
On 8/25/21 3:26 PM, Martin Sebor wrote:
On 8/25/21 10:14 AM, Andrew MacLeod wrote:
On 8/25/21 11:20 AM, Martin Sebor wrote:
Ping: Andrew, did I answer your questions? Do you (or anyone else)
have any other comments on the latest patch below?
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html
I wasn't attempting to block it, its outside my review purview..
I was merely commenting that you should not need a pointer to a
range_query at all anymore
Are you planning to transition to using the get_range_query()
interface instead of keeping a range_query pointer in the
pointer_query class?
This pass and to a smaller extent the pointer_query class that's
used by it and the strlen pass are still a work in progress.
I also still need to convert the strlen pass to use Ranger and
I expect it will take some changes to pointer_query. So at that
point, if going through get_range_query (cfun) everywhere is what
you recommend, I'm happy to do it.
absolutely. you should not need to even know whether you have a ranger
instance running or not. get_range_query will give you whichever is
active, and there is ALWAYS something active.. defaulting to the
global version.
the code in get_range() seems to be the end of the call chain which
uses the pointer and should be consolidated to something much simpler
if (rvals && stmt)
{
if (!rvals->range_of_expr (vr, val, stmt))
return NULL_TREE;
<...>
// ?? This entire function should use get_range_query or
get_global_range_query (),
// instead of doing something different for RVALS and global
ranges.
if (!get_global_range_query ()->range_of_expr (vr, val) ||
vr.undefined_p ())
return NULL_TREE;
This entire section can boil down to something like
if (!get_range_query (cfun)->range_of_expr (vr, val, stmt))
return NULL;
So get_range_query (cfun) will never be null? And no special handling
of INTEGER_CST is needed, or checking for SSA_NAME. Nice. Attached
is another revision of the same patch with this function simplified.
(FYI: I expect the whole function to eventually go away, and to make
other similar simplifications, but I'm not there yet.)
PS There has been an effort to get rid of global variables from GCC,
or, as the first step, to avoid accessing them directly(*). If and
when that happens, it seems like each pass will have to store either
the ranger instance as a member (directly or indirectly, via a member
of a class that stores it) or the function passed to pass::execute()
if it wants to access either.
[*] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573975.html
The patch at the link above wasn't approved but IIUC removing globals
from GCC is still a goal.
I have no idea what direction that is going, but the net effect will
be the same in the end. You'll be calling get_range_query() with
either the function pointer, or the pass pointer, or something.. but
you should never need to pass around a pointer to either a ranger or
range-query. As I said earlier, this will likely be a pass property
and accessed thru the pass eventually... but until then, use what we
have.. cfun. It'll be trivial to transition down the road to whatever
the ultimate solution is.
Okay, I'll do that in my future changes.
Martin
Re: [PING][PATCH] enable ranger and caching in pass_waccess
On 8/25/21 10:14 AM, Andrew MacLeod wrote:
On 8/25/21 11:20 AM, Martin Sebor wrote:
Ping: Andrew, did I answer your questions? Do you (or anyone else)
have any other comments on the latest patch below?
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html
I wasn't attempting to block it, its outside my review purview..
I was merely commenting that you should not need a pointer to a
range_query at all anymore
Are you planning to transition to using the get_range_query()
interface instead of keeping a range_query pointer in the
pointer_query class?
This pass and to a smaller extent the pointer_query class that's
used by it and the strlen pass are still a work in progress.
I also still need to convert the strlen pass to use Ranger and
I expect it will take some changes to pointer_query. So at that
point, if going through get_range_query (cfun) everywhere is what
you recommend, I'm happy to do it.
absolutely. you should not need to even know whether you have a ranger
instance running or not. get_range_query will give you whichever is
active, and there is ALWAYS something active.. defaulting to the global
version.
the code in get_range() seems to be the end of the call chain which uses
the pointer and should be consolidated to something much simpler
if (rvals && stmt)
{
if (!rvals->range_of_expr (vr, val, stmt))
return NULL_TREE;
<...>
// ?? This entire function should use get_range_query or
get_global_range_query (),
// instead of doing something different for RVALS and global ranges.
if (!get_global_range_query ()->range_of_expr (vr, val) ||
vr.undefined_p ())
return NULL_TREE;
This entire section can boil down to something like
if (!get_range_query (cfun)->range_of_expr (vr, val, stmt))
return NULL;
So get_range_query (cfun) will never be null? And no special handling
of INTEGER_CST is needed, or checking for SSA_NAME. Nice. Attached
is another revision of the same patch with this function simplified.
(FYI: I expect the whole function to eventually go away, and to make
other similar simplifications, but I'm not there yet.)
PS There has been an effort to get rid of global variables from GCC,
or, as the first step, to avoid accessing them directly(*). If and
when that happens, it seems like each pass will have to store either
the ranger instance as a member (directly or indirectly, via a member
of a class that stores it) or the function passed to pass::execute()
if it wants to access either.
[*] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573975.html
The patch at the link above wasn't approved but IIUC removing globals
from GCC is still a goal.
I have no idea what direction that is going, but the net effect will be
the same in the end. You'll be calling get_range_query() with either
the function pointer, or the pass pointer, or something.. but you should
never need to pass around a pointer to either a ranger or range-query.
As I said earlier, this will likely be a pass property and accessed thru
the pass eventually... but until then, use what we have.. cfun. It'll
be trivial to transition down the road to whatever the ultimate solution is.
Okay, I'll do that in my future changes.
Martin
Enable ranger and caching in pass_waccess.
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (get_size_range): Add argument.
(check_access): Pass additional argument.
(check_memop_access): Remove template and make a member function.
(maybe_check_dealloc_call): Make a pass_waccess member function.
(class pass_waccess): Add, rename, and remove members.
(pass_waccess::pass_waccess): Adjust to name change.
(pass_waccess::~pass_waccess): Same.
(check_alloca): Make a member function.
(check_alloc_size_call): Same.
(check_strcat): Same.
(check_strncat): Same.
(check_stxcpy): Same.
(check_stxncpy): Same.
(check_strncmp): Same.
(maybe_warn_rdwr_sizes): Rename...
(pass_waccess::maybe_check_access_sizes): ...to this.
(pass_waccess::check_call): Adjust to name changes.
(pass_waccess::maybe_check_dealloc_call): Make a pass_waccess member
function.
(pass_waccess::execute): Adjust to name changes.
* gimple-ssa-warn-access.h (check_memop_access): Remove.
* pointer-query.cc (access_ref::phi): Handle null pointer.
(access_ref::inform_access): Same.
(pointer_query::put_ref): Modify a cached value, not a copy of it.
(pointer_query::dump): New function.
(compute_objsize_r): Avoid overwriting access_ref::bndrng. Cache
more results.
* pointer-query.h (pointer_query::dump): Declare.
* tree-ssa-strlen.c (get_range): Simplify. Use function query.
(dump_strlen_info): Use function query.
(printf_strlen_execute): Factor code out into pointer_query::put_ref.
gcc/testsuite/ChangeLog:
* gcc.dg/Wstringop-overflow-11.c: Remove xfails.
* gcc.dg/Wstringop-overflow-12.c: Same.
* gcc.dg/Wstringop-overflow-43.c: Add xfails.
* gcc.dg/Wstringop-overflow-73.c: New
Re: [PING][PATCH] enable ranger and caching in pass_waccess
On 8/25/21 11:20 AM, Martin Sebor wrote:
Ping: Andrew, did I answer your questions? Do you (or anyone else)
have any other comments on the latest patch below?
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html
I wasn't attempting to block it, its outside my review purview..
I was merely commenting that you should not need a pointer to a
range_query at all anymore
Are you planning to transition to using the get_range_query()
interface instead of keeping a range_query pointer in the
pointer_query class?
This pass and to a smaller extent the pointer_query class that's
used by it and the strlen pass are still a work in progress.
I also still need to convert the strlen pass to use Ranger and
I expect it will take some changes to pointer_query. So at that
point, if going through get_range_query (cfun) everywhere is what
you recommend, I'm happy to do it.
absolutely. you should not need to even know whether you have a ranger
instance running or not. get_range_query will give you whichever is
active, and there is ALWAYS something active.. defaulting to the global
version.
the code in get_range() seems to be the end of the call chain which uses
the pointer and should be consolidated to something much simpler
if (rvals && stmt)
{
if (!rvals->range_of_expr (vr, val, stmt))
return NULL_TREE;
<...>
// ?? This entire function should use get_range_query or
get_global_range_query (),
// instead of doing something different for RVALS and global ranges.
if (!get_global_range_query ()->range_of_expr (vr, val) ||
vr.undefined_p ())
return NULL_TREE;
This entire section can boil down to something like
if (!get_range_query (cfun)->range_of_expr (vr, val, stmt))
return NULL;
PS There has been an effort to get rid of global variables from GCC,
or, as the first step, to avoid accessing them directly(*). If and
when that happens, it seems like each pass will have to store either
the ranger instance as a member (directly or indirectly, via a member
of a class that stores it) or the function passed to pass::execute()
if it wants to access either.
[*] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573975.html
The patch at the link above wasn't approved but IIUC removing globals
from GCC is still a goal.
I have no idea what direction that is going, but the net effect will be
the same in the end. You'll be calling get_range_query() with either
the function pointer, or the pass pointer, or something.. but you should
never need to pass around a pointer to either a ranger or range-query.
As I said earlier, this will likely be a pass property and accessed thru
the pass eventually... but until then, use what we have.. cfun. It'll
be trivial to transition down the road to whatever the ultimate solution is.
Andrew
[PING][PATCH] enable ranger and caching in pass_waccess
Ping: Andrew, did I answer your questions? Do you (or anyone else) have any other comments on the latest patch below? https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html On 8/20/21 4:16 PM, Martin Sebor wrote: On 8/20/21 7:09 AM, Andrew MacLeod wrote: On 8/19/21 7:09 PM, Martin Sebor via Gcc-patches wrote: The attached patch changes the new access warning pass to use the per-function ranger instance. To do that it makes a number of the global static functions members of the pass (that involved moving one to a later point in the file, increasing the diff; the body of the function hasn't changed otherwise). Still more functions remain. At the same time, the patch also enables the simple pointer_query cache to avoid repeatedly recomputing the properties of related pointers into the same objects, and makes the cache more effective (trunk fails to cache a bunch of intermediate results). Finally, the patch enhances the debugging support for the cache. Other than the ranger/caching the changes have no user-visible effect. Why are you calling enable/disable ranger if you are passing a ranger instance around instead of using the get_range_query (cfun)->range* calls? The pass stores an instance of the pointer_query class which in turn stores a pointer to range_query (which is a copy of the ranger). So storing it also in pass_waccess isn't necessary and can be removed. I've made that change in the attached update. I'm not sure the corresponding pointer should at some point also be removed from the pointer_query class and replaced by calls to get_range_query (cfun). If so, that would take some surgery to the strlen pass which also uses pointer_query and isn't quite ready to make this switch. Are you planning to transition to using the get_range_query() interface instead of keeping a range_query pointer in the pointer_query class? This pass and to a smaller extent the pointer_query class that's used by it and the strlen pass are still a work in progress. I also still need to convert the strlen pass to use Ranger and I expect it will take some changes to pointer_query. So at that point, if going through get_range_query (cfun) everywhere is what you recommend, I'm happy to do it. Anyway, attached is an updated revision with the m_ranger member removed and a few helpers changed to take a range_query argument to use the pointer_query member instead. It was retested on x86_64-linux. Martin PS There has been an effort to get rid of global variables from GCC, or, as the first step, to avoid accessing them directly(*). If and when that happens, it seems like each pass will have to store either the ranger instance as a member (directly or indirectly, via a member of a class that stores it) or the function passed to pass::execute() if it wants to access either. [*] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573975.html The patch at the link above wasn't approved but IIUC removing globals from GCC is still a goal.
Re: [PATCH] enable ranger and caching in pass_waccess
On 8/20/21 7:09 AM, Andrew MacLeod wrote:
On 8/19/21 7:09 PM, Martin Sebor via Gcc-patches wrote:
The attached patch changes the new access warning pass to use
the per-function ranger instance. To do that it makes a number
of the global static functions members of the pass (that involved
moving one to a later point in the file, increasing the diff;
the body of the function hasn't changed otherwise). Still more
functions remain. At the same time, the patch also enables
the simple pointer_query cache to avoid repeatedly recomputing
the properties of related pointers into the same objects, and
makes the cache more effective (trunk fails to cache a bunch of
intermediate results). Finally, the patch enhances the debugging
support for the cache.
Other than the ranger/caching the changes have no user-visible
effect.
Why are you calling enable/disable ranger if you are passing a ranger
instance around instead of using the get_range_query (cfun)->range* calls?
The pass stores an instance of the pointer_query class which in
turn stores a pointer to range_query (which is a copy of the ranger).
So storing it also in pass_waccess isn't necessary and can be
removed. I've made that change in the attached update. I'm not
sure the corresponding pointer should at some point also be removed
from the pointer_query class and replaced by calls to get_range_query
(cfun). If so, that would take some surgery to the strlen pass which
also uses pointer_query and isn't quite ready to make this switch.
Are you planning to transition to using the get_range_query() interface
instead of keeping a range_query pointer in the pointer_query class?
This pass and to a smaller extent the pointer_query class that's
used by it and the strlen pass are still a work in progress.
I also still need to convert the strlen pass to use Ranger and
I expect it will take some changes to pointer_query. So at that
point, if going through get_range_query (cfun) everywhere is what
you recommend, I'm happy to do it.
Anyway, attached is an updated revision with the m_ranger member
removed and a few helpers changed to take a range_query argument
to use the pointer_query member instead. It was retested on
x86_64-linux.
Martin
PS There has been an effort to get rid of global variables from GCC,
or, as the first step, to avoid accessing them directly(*). If and
when that happens, it seems like each pass will have to store either
the ranger instance as a member (directly or indirectly, via a member
of a class that stores it) or the function passed to pass::execute()
if it wants to access either.
[*] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573975.html
The patch at the link above wasn't approved but IIUC removing globals
from GCC is still a goal.
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (get_size_range): Add argument.
(check_access): Pass additional argument.
(check_memop_access): Remove template and make a member function.
(maybe_check_dealloc_call): Make a pass_waccess member function.
(class pass_waccess): Add, rename, and remove members.
(pass_waccess::pass_waccess): Adjust to name change.
(pass_waccess::~pass_waccess): Same.
(check_alloca): Make a member function.
(check_alloc_size_call): Same.
(check_strcat): Same.
(check_strncat): Same.
(check_stxcpy): Same.
(check_stxncpy): Same.
(check_strncmp): Same.
(maybe_warn_rdwr_sizes): Rename...
(pass_waccess::maybe_check_access_sizes): ...to this.
(pass_waccess::check_call): Adjust to name changes.
(pass_waccess::maybe_check_dealloc_call): Make a pass_waccess member
function.
(pass_waccess::execute): Adjust to name changes.
* gimple-ssa-warn-access.h (check_memop_access): Remove.
* pointer-query.cc (access_ref::phi): Handle null pointer.
(access_ref::inform_access): Same.
(pointer_query::put_ref): Modify a cached value, not a copy of it.
(pointer_query::dump): New function.
(compute_objsize_r): Avoid overwriting access_ref::bndrng. Cache
more results.
* pointer-query.h (pointer_query::dump): Declare.
* tree-ssa-strlen.c (get_range): Simplify. Use function query.
(dump_strlen_info): Use function query.
(printf_strlen_execute): Factor code out into pointer_query::put_ref.
gcc/testsuite/ChangeLog:
* gcc.dg/Wstringop-overflow-11.c: Remove xfails.
* gcc.dg/Wstringop-overflow-12.c: Same.
* gcc.dg/Wstringop-overflow-43.c: Add xfails.
* gcc.dg/Wstringop-overflow-73.c: New test.
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 4a2dd9ade77..68dcf06804a 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -1172,10 +1172,11 @@ warn_for_access (location_t loc, tree func, tree expr, int opt,
by BNDRNG if nonnull and valid. */
static void
-get_size_range (tree bound, tree range[2], const offset_int bndrng[2])
+get_size_range (range_query *query, tree bound, tree range[2],
+ const offset_int bndrng[2])
{
if (bound)
-get_size_range (bound, range);
+get_size_range (query,
Re: [PATCH] enable ranger and caching in pass_waccess
On 8/19/21 7:09 PM, Martin Sebor via Gcc-patches wrote: The attached patch changes the new access warning pass to use the per-function ranger instance. To do that it makes a number of the global static functions members of the pass (that involved moving one to a later point in the file, increasing the diff; the body of the function hasn't changed otherwise). Still more functions remain. At the same time, the patch also enables the simple pointer_query cache to avoid repeatedly recomputing the properties of related pointers into the same objects, and makes the cache more effective (trunk fails to cache a bunch of intermediate results). Finally, the patch enhances the debugging support for the cache. Other than the ranger/caching the changes have no user-visible effect. Why are you calling enable/disable ranger if you are passing a ranger instance around instead of using the get_range_query (cfun)->range* calls? Are you planning to transition to using the get_range_query() interface instead of keeping a range_query pointer in the pointer_query class? Andrew
[PATCH] enable ranger and caching in pass_waccess
The attached patch changes the new access warning pass to use
the per-function ranger instance. To do that it makes a number
of the global static functions members of the pass (that involved
moving one to a later point in the file, increasing the diff;
the body of the function hasn't changed otherwise). Still more
functions remain. At the same time, the patch also enables
the simple pointer_query cache to avoid repeatedly recomputing
the properties of related pointers into the same objects, and
makes the cache more effective (trunk fails to cache a bunch of
intermediate results). Finally, the patch enhances the debugging
support for the cache.
Other than the ranger/caching the changes have no user-visible
effect.
Tested on x86_64-linux.
Martin
Previous patches in this series:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577526.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576821.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575377.html
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (check_memop_access): Remove template and
make a member function.
(maybe_check_dealloc_call): Make a pass_waccess member function.
(class pass_waccess): Add and rename members.
(pass_waccess::pass_waccess): Adjust to name change.
(pass_waccess::~pass_waccess): Same.
(check_alloca): Make a member function.
(check_alloc_size_call): Same.
(check_strcat): Same.
(check_strncat): Same.
(check_stxcpy): Same.
(check_stxncpy): Same.
(check_strncmp): Same.
(maybe_warn_rdwr_sizes): Rename...
(pass_waccess::maybe_check_access_sizes): ...to this.
(pass_waccess::check_call): Adjust to name changes.
(pass_waccess::maybe_check_dealloc_call): Make a pass_waccess member
function.
(pass_waccess::execute): Adjust to name changes.
* gimple-ssa-warn-access.h (check_memop_access): Remove.
* pointer-query.cc (access_ref::phi): Handle null pointer.
(access_ref::inform_access): Same.
(pointer_query::put_ref): Modify a cached value, not a copy of it.
(pointer_query::dump): New function.
(compute_objsize_r): Avoid overwriting access_ref::bndrng. Cache
more results.
* pointer-query.h (pointer_query::dump): Declare.
* tree-ssa-strlen.c (printf_strlen_execute): Factor code out into
pointer_query::put_ref.
gcc/testsuite/ChangeLog:
* gcc.dg/Wstringop-overflow-73.c: New test.
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 4a2dd9ade77..4473b093f88 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -1511,41 +1511,6 @@ check_access (tree expr, tree dstwrite,
mode, pad);
}
-/* Helper to determine and check the sizes of the source and the destination
- of calls to __builtin_{bzero,memcpy,mempcpy,memset} calls. EXP is the
- call expression, DEST is the destination argument, SRC is the source
- argument or null, and LEN is the number of bytes. Use Object Size type-0
- regardless of the OPT_Wstringop_overflow_ setting. Return true on success
- (no overflow or invalid sizes), false otherwise. */
-
-template
-static bool
-check_memop_access (GimpleOrTree expr, tree dest, tree src, tree size)
-{
- /* For functions like memset and memcpy that operate on raw memory
- try to determine the size of the largest source and destination
- object using type-0 Object Size regardless of the object size
- type specified by the option. */
- access_data data (expr, access_read_write);
- tree srcsize = src ? compute_objsize (src, 0, ) : NULL_TREE;
- tree dstsize = compute_objsize (dest, 0, );
-
- return check_access (expr, size, /*maxread=*/NULL_TREE,
- srcsize, dstsize, data.mode, );
-}
-
-bool
-check_memop_access (gimple *stmt, tree dest, tree src, tree size)
-{
- return check_memop_access(stmt, dest, src, size);
-}
-
-bool
-check_memop_access (tree expr, tree dest, tree src, tree size)
-{
- return check_memop_access(expr, dest, src, size);
-}
-
/* A convenience wrapper for check_access above to check access
by a read-only function like puts. */
@@ -2093,135 +2058,6 @@ warn_dealloc_offset (location_t loc, gimple *call, const access_ref )
return true;
}
-/* Issue a warning if a deallocation function such as free, realloc,
- or C++ operator delete is called with an argument not returned by
- a matching allocation function such as malloc or the corresponding
- form of C++ operatorn new. */
-
-static void
-maybe_check_dealloc_call (gcall *call)
-{
- tree fndecl = gimple_call_fndecl (call);
- if (!fndecl)
-return;
-
- unsigned argno = fndecl_dealloc_argno (fndecl);
- if ((unsigned) call_nargs (call) <= argno)
-return;
-
- tree ptr = gimple_call_arg (call, argno);
- if (integer_zerop (ptr))
-return;
-
- access_ref aref;
- if (!compute_objsize (ptr, 0, ))
-return;
-
- tree ref = aref.ref;
- if (integer_zerop (ref))
-return;
-
- tree dealloc_decl = fndecl;
- location_t loc = gimple_location (call);
-
- if (DECL_P (ref) || EXPR_P (ref))
-{
- /*
