Re: Checker support refinements, bugfixes, test cases

[Jeffrey A Law <law at cygnus dot com>]

  In message <199810030146.VAA10610@cujo.cygnus.com>you write:
  > 
  > For your approval:
  > 
  > These patches and files are combined from three I sent in for gcc2,
  > plus some new stuff.  But after six weeks of waiting (since I sent the
  > first patch), I'm giving up and submitting here also, rather than
  > hoping it'd get in via a gcc2 merge any time soon.
  > 
  > The changes are, briefly:
  > 
  >  * function-level control over -fcheck-memory-usage instrumentation
  >    with an attribute
  >  * bugfix: create symbols with Pmode, not VOIDmode (avoids crash on
  >    powerpc target)
  >  * bugfix: do check static VAR_DECL nodes, in case no memory
  >    management available, bad memcpy clobbers storage, etc
  >  * bugfix: don't abort dealing with BLKmode function arguments
  >    constructed on the stack (crashes for MIPS and Alpha targets,
  >    probably all others, with GNU C constructor syntax)
  >  * 10 C test cases for -fcheck-memory-usage (multiplied by
  >    optimization and multilib options), including one with BLKmode etc,
  >    in a new subdirectory of gcc.c-torture/execute
  > 
  > Currently, on alpha-linux, one of the test cases does fail (the
  > BLKmode one, which just aborted in the compiler before), when function
  > inlining is enabled.  One out of 120 isn't bad, when we weren't even
  > testing it before....
  > 
  > (Jim Wilson, I think you've seen all of this before, except for the
  > BLKmode bits; see gcc/17622.  Tristan Gingold, I don't remember if
  > I've sent you the test cases before, but I think you've seen the rest,
  > with the patch earlier today.)
  > 
  > Ken
  > 
  > 
  > Fri Oct  2 20:28:23 1998  Ken Raeburn  <raeburn@cygnus.com>
  > 
  > 	* tree.h (DECL_NO_CHECK_MEMORY_USAGE): New macros.
  > 	(struct tree_decl): New fields no_check_memory_usage.
  > 	* c-common.c (enum attrs): Add A_NO_CHECK_MEMORY_USAGE.
  > 	(init_attributes): Register it as a new attribute.
  > 	(decl_attributes): Set flags on functions given that attribute.
  > 	* c-decl.c (duplicate_decls): Merge new attribute.
  > 	* expr.h (current_function_check_memory_usage): Declare new var.
  > 	* calls.c, expr.c, function.c, stmt.c, alpha.c, clipper.c, m88k.c,
  > 	pa.c, sparc.c: Replace uses of flag_check_memory_usage with
  > 	current_function_check_memory_usage.
  > 	* function.h: Add field to struct function.
  > 	* function.c (current_function_check_memory_usage): Define it.
  > 	(push_function_context_to, pop_function_context_from): Save and
  > 	restore it.
  > 	(expand_function_start): Set it, based on global flag and function
  > 	attribute.
  > 
  > 	* expr.c (expand_expr, case VAR_DECL): In memory-checking code, do
  > 	check non-automatic variables, to permit detection of writes to
  > 	read-only locations in embedded systems without memory management.
  > 	* calls.c (store_one_arg): Use ARGS_SIZE_RTX to get size of argument
  > 	when emitting chkr_set_right_libfunc call, even if the argument is
  > 	BLKmode or variable-sized; don't abort.
  > 
  > 	* optabs.c (init_optabs): Create Checker and __cyg_profile_*
  > 	symbols in Pmode, not VOIDmode.
  > 
  > 1998-10-02  Ken Raeburn  <raeburn@cygnus.com>
  > 
  > 	* execute/memcheck: New directory of tests for
  > 	-fcheck-memory-usage.
Looks pretty reasonable to me.  Did you ever get any feedback from Tristan?

Presumably the BLKmode stuff doesn't actually pass a BLKmode value as an
argument to emit_library_call, you just need address and length info right?

[ I don't think emit_library_call can handle BLKmode arguments. ]

How does the testsuite work?  Don't you need library support for it to
function correctly?  Or is the checker support code totally self-contained
within the compiler and libgcc.a?

If checker relies on special library support, then we'll need some way to 
indicate what systems have such library support to avoid running the testsuite
on unsupported targets.

It might be interesting to be able to control checking of stuff in the static
store.  Then again, it might not :-)  I don't think we should hold up the patch
for something like that.


jeff