From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99440 invoked by alias); 27 Apr 2018 18:02:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 99374 invoked by uid 89); 27 Apr 2018 18:02:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=buggy, complication, hed, connecting X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Apr 2018 18:02:33 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9B0A8406C760; Fri, 27 Apr 2018 18:02:31 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id DDE57215CDCB; Fri, 27 Apr 2018 18:02:30 +0000 (UTC) Subject: Re: [RFA 2/6] Handle alignof and _Alignof To: Tom Tromey References: <20180424152222.8053-1-tom@tromey.com> <20180424152222.8053-3-tom@tromey.com> <87bme88icb.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <0a567678-2138-4634-d472-44c170f47f93@redhat.com> Date: Fri, 27 Apr 2018 18:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87bme88icb.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00571.txt.bz2 On 04/24/2018 09:23 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves 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