http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #21 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-11-10
18:22:50 UTC ---
(In reply to comment #20)
>
> The documentation is wrong, so following patch removes all the blurb about
> handling of constants.
>
> Index: doc/md.texi
> ===================================================================
> --- doc/md.texi (revision 181258)
> +++ doc/md.texi (working copy)
> @@ -1001,16 +1001,7 @@
>
> Predicates written with @code{define_predicate} automatically include
> a test that @var{mode} is @code{VOIDmode}, or @var{op} has the same
> -mode as @var{mode}, or @var{op} is a @code{CONST_INT} or
> -@code{CONST_DOUBLE}. They do @emph{not} check specifically for
> -integer @code{CONST_DOUBLE}, nor do they test that the value of either
> -kind of constant fits in the requested mode. This is because
> -target-specific predicates that take constants usually have to do more
> -stringent value checks anyway. If you need the exact same treatment
> -of @code{CONST_INT} or @code{CONST_DOUBLE} that the generic predicates
> -provide, use a @code{MATCH_OPERAND} subexpression to call
> -@code{const_int_operand}, @code{const_double_operand}, or
> -@code{immediate_operand}.
> +mode as @var{mode}.
But this is not quite true either. genpreds will *omit* generation of
the explicit test (mode == VOIDmode || mode == GET_MODE (op)) if the
predicate has as a sub-test a call to one of the standard predicates,
arguing that "the standard predicate already did the test, so we don't
have to repeat it". But the test performed by the standard predicates
*does* comply with the more elaborate rule spelled out in the docs ...
