On 16/08/18 23:12, Luc Van Oostenryck wrote:
> There is a potential problem when the second side of the OR
second side? Do you mean right-hand side (RHS)?
> is simplified away.
>
> Add 2 testcases to catch possible regressions here.
>
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx>
> ---
> validation/optim/and-or-crash.c | 5 +++++
> validation/optim/and-or-mask.c | 18 ++++++++++++++++++
> 2 files changed, 23 insertions(+)
> create mode 100644 validation/optim/and-or-crash.c
> create mode 100644 validation/optim/and-or-mask.c
>
> diff --git a/validation/optim/and-or-crash.c b/validation/optim/and-or-crash.c
> new file mode 100644
> index 000000000..49440963c
> --- /dev/null
> +++ b/validation/optim/and-or-crash.c
> @@ -0,0 +1,5 @@
> +static int a(int b, unsigned c) { (c << 1 | b & 1 << 1) >> 1; }
Is the mix of signed and unsigned int significant?
It caused me to pause and try to remember my 'usual arithmetic
conversions'. If I have remembered correctly, this seems to
be equivalent to (int)(((unsigned int) | (int)) >> 1), leading to
(int)((unsigned int) >> 1)), then (int)(unsigned int), finally (int).
Hmm, so no. :-D
ATB,
Ramsay Jones
> +
> +/*
> + * check-name: catch crashes during AND-OR simplifications
> + */
> diff --git a/validation/optim/and-or-mask.c b/validation/optim/and-or-mask.c
> new file mode 100644
> index 000000000..468037895
> --- /dev/null
> +++ b/validation/optim/and-or-mask.c
> @@ -0,0 +1,18 @@
> +int foo(int a, int b)
> +{
> + return ((a & 7) | (b & 3)) & 8;
> +}
> +
> +/*
> + * check-name: and-or-mask
> + * check-command: test-linearize -Wno-decl $file
> + *
> + * check-output-start
> +foo:
> +.L0:
> + <entry-point>
> + ret.32 $0
> +
> +
> + * check-output-end
> + */
>
