On Wed, 03 Jun 2015 16:55:24 +0200, Jeff Law wrote: > 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?
Yes. > > 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? Currently it is not because it does not work as I wrote. Otherwise I think it could have some (marginal) use so that some custom printing command can accept arbitrary expression and executing such ({...}) code with the given expression. But nothing too important. > > I have found now GDB can do also > > *vararray@somevar > Yea. I've used this occasionally, but... [...] > Accepting the syntax where the RHS doesn't fold down to a constant is easy. OK, I would extend the patch for non-constant RHS, in the case this patch would be approved in general. > 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? In general parsing LHS vs. RHS is not so trivial: *array1@10 expression wrapped into -> (*array2+"a@c"[1]+'@'+'\''@(*array1@10)[5])[2] > 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. OK, thanks for the advice. I would update the patch in the case this patch would be approved in general. On Wed, 03 Jun 2015 20:10:23 +0200, Manuel López-Ibáñez wrote: > It should be possible to arrange the inferior code in such a way that GCC > parses each side of @ independently As I illustrate above I do not find it completely trivial and personally I find more clean the patch to GCC than such a parsing in GDB. In the end the GCC patch is very short. But sure everything is possible. While for most of use cases it is probably enough to just strrchr(expression,'@'), still compared to current c-exp.y parsing it would mean for 'compile code' a regression for the remaining few possible use cases. So it means to parse strings, backslashes, parentheses. > Parsing correctly arbitrary programs that may contain @ at arbitrary places > seems a can full of gigantic were-worms. Currently GCC parses '@' only for objc and I think it is OK for GCC/GDB to make array@size syntax unsupported for objc. So I do not see gigantic were-worms anywhere myself. Jan