[v2,PR,gdb/19820] gdb: allow enumeration constants as second operand of BINOP_REPEAT

  This patch adds support for TYPE_CODE_ENUM values to be supplied
as right-hand side operand of the BINOP_REPEAT (@) operator. The
following should now work:

enum {
  sz = 17
};

int
main ()
{
  int arr[sz + 1] = { 0 };
  return 0; /* line 9 here */
}

(gdb) b 9
(gdb) r
(gdb) p arr@sz
$1 = {0 <repeats 17 times>}
(gdb)

A couple of tests is also included in this patch to demonstrate that it is
working as intended.

gdb/Changelog:

2016-03-23  Artemiy Volkov  <artemiyv@acm.org>

	PR gdb/19820
	* eval.c (evaluate_subexp_standard): Allow TYPE_CODE_ENUM to be
        the type of BINOP_REPEAT's second operand.

gdb/testsuite/Changelog:

2016-03-23  Artemiy Volkov  <artemiyv@acm.org>

	PR gdb/19820
	* gdb.base/printcmds.exp: Add artificial arrays tests.
---

v1 -> v2: Add PR # information to the changelog entries.

 gdb/eval.c                           | 3 ++-
 gdb/testsuite/gdb.base/printcmds.exp | 5 +++++
 2 files changed, 7 insertions(+), 1 deletion(-)
  

On Thu, Mar 24, 2016 at 12:02 AM, Artemiy Volkov <artemiyv@acm.org> wrote:
> This patch adds support for TYPE_CODE_ENUM values to be supplied
> as right-hand side operand of the BINOP_REPEAT (@) operator. The
> following should now work:
>
> enum {
>   sz = 17
> };
>
> int
> main ()
> {
>   int arr[sz + 1] = { 0 };
>   return 0; /* line 9 here */
> }
>
> (gdb) b 9
> (gdb) r
> (gdb) p arr@sz
> $1 = {0 <repeats 17 times>}
> (gdb)
>
> A couple of tests is also included in this patch to demonstrate that it is
> working as intended.
>
> gdb/Changelog:
>
> 2016-03-23  Artemiy Volkov  <artemiyv@acm.org>
>
>         PR gdb/19820
>         * eval.c (evaluate_subexp_standard): Allow TYPE_CODE_ENUM to be
>         the type of BINOP_REPEAT's second operand.
>
> gdb/testsuite/Changelog:
>
> 2016-03-23  Artemiy Volkov  <artemiyv@acm.org>
>
>         PR gdb/19820
>         * gdb.base/printcmds.exp: Add artificial arrays tests.
> ---
>
> v1 -> v2: Add PR # information to the changelog entries.
>
>  gdb/eval.c                           | 3 ++-
>  gdb/testsuite/gdb.base/printcmds.exp | 5 +++++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/eval.c b/gdb/eval.c
> index 78ad946..5d32a3c 100644
> --- a/gdb/eval.c
> +++ b/gdb/eval.c
> @@ -2427,7 +2427,8 @@ evaluate_subexp_standard (struct type *expect_type,
>        if (noside == EVAL_SKIP)
>         goto nosideret;
>        type = check_typedef (value_type (arg2));
> -      if (TYPE_CODE (type) != TYPE_CODE_INT)
> +      if (TYPE_CODE (type) != TYPE_CODE_INT
> +          && TYPE_CODE (type) != TYPE_CODE_ENUM)
>         error (_("Non-integral right operand for \"@\" operator."));
>        if (noside == EVAL_AVOID_SIDE_EFFECTS)
>         {
> diff --git a/gdb/testsuite/gdb.base/printcmds.exp b/gdb/testsuite/gdb.base/printcmds.exp
> index 3c78a53..d599a70 100644
> --- a/gdb/testsuite/gdb.base/printcmds.exp
> +++ b/gdb/testsuite/gdb.base/printcmds.exp
> @@ -643,6 +643,11 @@ proc test_artificial_arrays {} {
>      gdb_test_escape_braces "p int1dim\[0\]${ctrlv}@2${ctrlv}@3" \
>         "({{0, 1}, {2, 3}, {4, 5}}|\[Cc\]annot.*)" \
>         {p int1dim[0]@2@3}
> +    gdb_test_escape_braces "p int1dim\[0\]${ctrlv}@TWO" " = {0, 1}" \
> +        {p int1dim[0]@TWO}
> +    gdb_test_escape_braces "p int1dim\[0\]${ctrlv}@TWO${ctrlv}@three" \
> +       "({{0, 1}, {2, 3}, {4, 5}}|\[Cc\]annot.*)" \
> +       {p int1dim[0]@TWO@three}
>      gdb_test_escape_braces {p/x (short [])0x12345678} \
>         " = ({0x1234, 0x5678}|{0x5678, 0x1234})"
>  }
> --
> 2.7.3
>

Ping. Is v2 good enough to go in?

Thanks,
Artemiy
  

Artemiy Volkov <artemiyv@acm.org> writes:

> Ping. Is v2 good enough to go in?

Yes, it is.  I thought you've pushed v2 in because it was pre-approved
in my review.  Sorry for the confusion.
  

On Fri, Apr 1, 2016 at 4:09 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
> Artemiy Volkov <artemiyv@acm.org> writes:
>
>> Ping. Is v2 good enough to go in?
>
> Yes, it is.  I thought you've pushed v2 in because it was pre-approved
> in my review.  Sorry for the confusion.
>

I do not have write access to the tree. That's why I was waiting for
you or someone else to pick it up.

Thanks,
Artemiy
  

Artemiy Volkov <artemiyv@acm.org> writes:

> I do not have write access to the tree. That's why I was waiting for
> you or someone else to pick it up.

Done.