Re: [RFA 2/6] Handle alignof and _Alignof

[Tom Tromey <tom@tromey.com>]

>>>>> "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