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
