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