Re: [PATCH] diagnose unsupported uses of hardware register variables (PR 88000)

[Jakub Jelinek <jakub@redhat.com>]

On Tue, Nov 13, 2018 at 09:11:41PM -0700, Martin Sebor wrote:
> --- gcc/c-family/c-warn.c	(revision 266086)
> +++ gcc/c-family/c-warn.c	(working copy)
> @@ -2609,3 +2609,39 @@ warn_for_multistatement_macros (location_t body_lo
>      inform (guard_loc, "some parts of macro expansion are not guarded by "
>  	    "this %qs clause", guard_tinfo_to_string (keyword));
>  }
> +
> +
> +/* Diagnose unsuported use of explicit hardware register variable ARG
> +   as an argument ARGNO to function FNDECL.  */
> +
> +void
> +warn_hw_reg_arg (tree fndecl, int argno, tree arg)
> +{
> +  if (!fndecl)
> +    return;
> +
> +  /* Avoid diagnosing GCC intrinsics with no library fallbacks.  */
> +  if (fndecl_built_in_p (fndecl)
> +      && DECL_IS_BUILTIN (fndecl)
> +      && !c_decl_implicit (fndecl)
> +      && !DECL_ASSEMBLER_NAME_SET_P (fndecl))
> +    return;
> +
> +  /* Also avoid diagnosing always_inline functions since those are
> +     often used to implement vectorization intrinsics that make use
> +     of hardware register variables.  */
> +  if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (fndecl)))
> +    return;
> +
> +  /* Diagnose uses of local variables declared asm register.  */
> +  STRIP_ANY_LOCATION_WRAPPER (arg);
> +  if (VAR_P (arg)
> +      && !TREE_STATIC (arg)
> +      && DECL_HARD_REGISTER (arg)
> +      && warning_at (input_location, OPT_Wasm_register_var,
> +		     "unsupported use of hardware register %qD as "
> +		     "argument %d of %qD",
> +		     arg, argno, fndecl))
> +    inform (DECL_SOURCE_LOCATION (arg),
> +	    "%qD declared here", arg);
> +}

This makes no sense to me.  There is nothing unsupported in passing
a local hard register variable to a function, that is well defined,
and as your testcase changes show, you broke quite some completely valid
testcases with that.

What doesn't work as the reporter expect is assumption that local hard
register variables that live across function calls must have their values
preserved; they can be modified by the callees.

	Jakub