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

[Pedro Alves <palves@redhat.com>]

On 04/24/2018 09:23 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> Shouldn't we test "long double"?  Patch #1 handles it.
> Pedro> Not sure all GCC ports support it, may require separate compilation.
> 
> I thought C didn't have long double (it's tested in the C++ test), but I
> see it does.  I will add that.
> 
> Pedro> Also, I'm wondering about "__int128" if the target
> Pedro> supports it.
> 
> I have bad feelings about trying to detect this in the test.

My thought was to simply support compiling a separate testcase
binary for a given type instead of mixing all types in
the same program.  So if a type is not supported, the program
won't compile and we'd skip the testing that type.  It'd basically
require moving the body of the testing code to a procedure that
is passed a list of types to compile & test in group.  So the
basic types that must be supported by all C/C++ implementations
would be one single group.  While other types like __int128 and
any other we add in future would be in separate groups / passes.

> 
> Pedro> In C++, do we get the alignment of non-standard layout classes right?
> Pedro> Likewise arrays, bitfields and typedefs?
> Pedro> What do we do with _Alignof(void)?
> 
> I will add these.
> 
> Pedro> I didn't spot any test for the
> Pedro>  "could not determine alignment of type"
> Pedro> case to make that that works gracefully without crashing.  
> 
> I think this one is maybe hard to test without some kind of bug (so far
> I've only seen it when some part of the patch was buggy), but I will see
> what I can do.
> 
> Pedro> Finally, for completeness, GCC allows _Alignof applied to
> Pedro> expressions, so I guess we should to.  Does the series allow that?
> Pedro> I.e., can we do _Alignof(1 + 1)?  Does the parser handle that?
> 
> No, and this is hard to do.  I've left the door open a bit by the way
> the new expression emits a new OP instead of simply writing out a
> constant (and this allows alignof(typeof(..)) to work as well).
> However, I think the way the parser is written makes this difficult,

OOC, can you expand a bit on what you mean here?  I would have assumed
that at the parser level, we'd just copy exactly what is done for
supporting expressions with sizeof.

> which is one reason that sizeof requires or does not require parens
> depending on whether the argument is an expression or a type.

Not clear what you mean here.  I know that sizeof with an expression
requires parenthesis in C/C++, but I'm not connecting the dots with
the above comments.

> It would be possible to write "alignof expression", but I didn't want to
> add an extension, 

Oh, you mean, you would want to make gdb require the parens when
given an expression as prerequisite for supporting expressions?

I wouldn't think that as a blocker, since AFAICS, we already have
that "extension" for sizeof:

 (gdb) p sizeof 1 + 1
 $1 = 5

so I wouldn't see it as a problem to make alignof work the same way,
and then if/when somebody wants to make gdb require the parens,
he'd just do it to both sizeof/alignof.

Anyway, I'll take alignof/_Alignof with no expressions over
no alignof/_Alignof, for sure.  :-)

> especially since "alignof(typeof(expression))" is
> pretty easy.

Ah, if that works, then yeah, that's a good escape hatch.

Should we have a test for that?

> 
> Pedro> Shouldn't we test _Alignof applied to the structure fields too?
> 
> It seems to me that this would necessarily be an expression, not a type.

Yeah.  I think the main complication here would be related to how the
expression machinery returns values and types, and then how to
distinguish a struct field of type X with a standalone variable of
type X, for alignof purposes (given x86's funny alignments).

Thanks,
Pedro Alves