This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 2/6] Handle alignof and _Alignof
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
Pedro> My thought was to simply support compiling a separate testcase
Pedro> binary for a given type instead of mixing all types in
Pedro> the same program. So if a type is not supported, the program
Pedro> won't compile and we'd skip the testing that type.
Ok, I can do that. I'll put the "void" test there too -- the problem
with it being that (1) we'd need "nowarnings" and (2) since it isn't
really valid, presumably some other C++ compiler might reject it.
Tom> No, and this is hard to do. I've left the door open a bit by the way
Tom> the new expression emits a new OP instead of simply writing out a
Tom> constant (and this allows alignof(typeof(..)) to work as well).
Tom> However, I think the way the parser is written makes this difficult,
Pedro> OOC, can you expand a bit on what you mean here? I would have assumed
Pedro> that at the parser level, we'd just copy exactly what is done for
Pedro> supporting expressions with sizeof.
Right now we have:
exp : ALIGNOF '(' type_exp ')' %prec UNARY
{ write_exp_elt_opcode (pstate, UNOP_ALIGNOF); }
;
We could add another production like:
exp : ALIGNOF '(' exp ')' ...
... but when I tried this the resulting parser had issues with the tests
-- claiming syntax errors where there were none.
Tom> which is one reason that sizeof requires or does not require parens
Tom> depending on whether the argument is an expression or a type.
Pedro> Not clear what you mean here. I know that sizeof with an expression
Pedro> requires parenthesis in C/C++, but I'm not connecting the dots with
Pedro> the above comments.
For sizeof there are two productions:
exp : SIZEOF exp %prec UNARY
{ write_exp_elt_opcode (pstate, UNOP_SIZEOF); }
;
exp : SIZEOF '(' type ')' %prec UNARY
I don't really know offhand why the latter is taken when a paren is
seen, it seems ambiguous to me.
Debugging this stuff is not very easy or enjoyable. Switching to a
recursive descent parser would eliminate problems like this, because
some of the decisions would be turned into more simple programming
problems.
Tom> especially since "alignof(typeof(expression))" is
Tom> pretty easy.
Pedro> Ah, if that works, then yeah, that's a good escape hatch.
Pedro> Should we have a test for that?
Yeah, I'll add one.
Pedro> Yeah. I think the main complication here would be related to how the
Pedro> expression machinery returns values and types, and then how to
Pedro> distinguish a struct field of type X with a standalone variable of
Pedro> type X, for alignof purposes (given x86's funny alignments).
I think with the new agreed-upon definition of alignof, this is no
longer a concern.
Tom