This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] handle invalid calls to built-ins with no prototype (PR 83603)


On 01/02/2018 04:29 PM, Jeff Law wrote:
On 01/01/2018 05:58 PM, Martin Sebor wrote:
The -Wrestrict code assumes that built-ins are called with
the correct number of arguments.  When this isn't so it
crashes.  The attached patch avoids the ICE due to this
error.

There are outstanding assumptions that the type of actual
arguments to built-ins declared without a prototype matches
the expected type.  Those will be corrected in a subsequent
patch.

Martin

gcc-83603.diff


PR tree-optimization/83603 - ICE in builtin_memref at gcc/gimple-ssa-warn-restrict.c:238

gcc/ChangeLog:

	PR tree-optimization/83603
	* calls.c (maybe_warn_nonstring_arg): Avoid accessing function
	arguments past the endof the argument list in functions declared
	without a prototype.
	* gimple-ssa-warn-restrict.c (wrestrict_dom_walker::check_call):
	Avoid checking when arguments are null.
OK.

Presumably we're not getting syntax errors precisely because we're
calling these functions without an in-scope prototype?

Right.

I wouldn't at all be surprised to find other passes mis-handling that
case.  The idioms you're using to get the arguments are similar to code
I've seen elsewhere -- it's probably just harder to trigger the failures
because analysis of the mem* or str* call is conditional on surrounding
context.

Other passes may be relying on gimple_call_builtin_p to determine
whether a call is to a built-in.  The function returns false for
calls with incompatible arguments (not just when passing a pointer
where an integer is expected, for example, but also when passing
an int where a size_t is expected, such as in a call to memcpy),
and so it exempts many otherwise correct calls from checking (and
also from the benefits of optimization, which also implies less
thorough checking).

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]