On 05/30/2015 03:47 AM, Jan Kratochvil wrote:
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.
Is your assertion here that you want to be able to handle more complex
operands on the LHS/RHS of the @ and that adding a general expression
parser to GDB for that would be painful/wasteful?
But a statement expression could not be parsed by GDB:
compile print ({ __auto_type ptr=vararray+1; *ptr@3; })
But how important is this kind of usage?
I have found now GDB can do also
*vararray@somevar
Yea. I've used this occasionally, but...
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.
99% of the time I've used a constant with the @ syntax in gdb. Doesn't
this conflict with the goal of supporting an arbitrary C expression on
the LHS/RHS of the @? If most uses for the RHS are just constants, then
why do we need the enhancement?
Accepting the syntax where the RHS doesn't fold down to a constant is
easy. And as long as there's some kind of reasonable capture mechanism
(and there must be since you want to access variables from in the
inferior fragment), then it ought to "just work" if you relax the test
in c-typeck.c part of your patch and use build_array_type rather than
build_array_type_nelts in that case.
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.
My worry is that without the copy_node we're changing things inside op0.
ISTM that we should be generating a new node (ie, a new VAR_DECL)
using the type returned by build_array_type_nelts as its type.
Jeff
