Re: ping: [gcc patch] libcc1: '@' GDB array operator

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Sat, 30 May 2015 07:42:35 +0200, Jeff Law wrote:
> We're still digging out a
> bit from the patches queued while preparing for the gcc5 release.
                                                      gcc6

> So I guess at some level it's not clear to me why we need to support the @
> operator in libcc1.  So perhaps starting with a justification for
> wanting/needed that capability would be helpful.

It is not a simple /@[0-9]+$/ regex, the expression can be for example
	(*vararray@(3+1))
Parentheses still could be parsed by GDB, though.

But a statement expression could not be parsed by GDB:
	compile print ({ __auto_type ptr=vararray+1; *ptr@3; })
But I have found now it does not work - it prints just a pointer, not an array
- due to:
1	int main (void) { typeof (({ int a[]={1,2,3,4,5}; a; })) *ptr_type; return 0; }
(gdb) ptype ptr_type
type = int **
It is in DWARF really just:
	DW_TAG_pointer_type -> DW_TAG_pointer_type -> DW_TAG_base_type

With future C++ support it also would not work:
1	int array[]={1,2,3,4,5};
2	auto copy(array);
(gdb) ptype copy
type = int *


I have found now GDB can do also
	*vararray@somevar
while this GCC patch cannot:
	gdb command line:1:39: error: second parameter of operator '@' requires constant integer
I did not realize that myself before.  I do not think there is an easy fix for
the GCC patch, is it?  But I do not think it matters too much, IMO GDB users
usually put there just constant numbers, at least I do.


So all the currently working cases can be implemented also just in GDB.
I still find more correct to do it in GCC than to implement new kind of
expression parsing in GDB - which the 'compile' project tries to avoid.
But sure up to you whether it fits in GCC or not.


> As for the patch itself, you noted you weren't sure if copy_node was right,
> it would help if you'd describe what problem you were having that's solved
> by copying the node. I wonder if you should be building up a node from
> scratch here.

I have removed it and it works.  But there are many statements I do not
understand and I only guess they should be copying similar code around.
The block of code can be replaced just by:
    case ATSIGN_EXPR:
      op0 = TREE_OPERAND (expr, 0);
      op1 = TREE_OPERAND (expr, 1);
      ret = op0;
      TREE_TYPE (ret) = build_array_type_nelts (TREE_TYPE (op0),
                                                tree_to_uhwi (op1));
      TREE_READONLY (ret) = TREE_READONLY (expr);
      TREE_SIDE_EFFECTS (ret) = TREE_SIDE_EFFECTS (expr);
      TREE_THIS_VOLATILE (ret) = TREE_THIS_VOLATILE (expr);
      goto out;
which also works for me.  But I guess one could find some countercases for this
simplified block.


> In general, please use C style comments rather than C++.

Done.


Jan