From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34032 invoked by alias); 27 Apr 2018 20:53:21 -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 34022 invoked by uid 89); 27 Apr 2018 20:53:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=switching, offhand X-HELO: gateway24.websitewelcome.com Received: from gateway24.websitewelcome.com (HELO gateway24.websitewelcome.com) (192.185.51.228) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Apr 2018 20:53:18 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 9A9E9D26E for ; Fri, 27 Apr 2018 15:53:17 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id CAMnf6bGE5CKDCAMnfe632; Fri, 27 Apr 2018 15:53:17 -0500 X-Authority-Reason: nr=8 Received: from 97-122-176-117.hlrn.qwest.net ([97.122.176.117]:35518 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fCAMn-0020vs-D2; Fri, 27 Apr 2018 15:53:17 -0500 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA 2/6] Handle alignof and _Alignof References: <20180424152222.8053-1-tom@tromey.com> <20180424152222.8053-3-tom@tromey.com> <87bme88icb.fsf@tromey.com> <0a567678-2138-4634-d472-44c170f47f93@redhat.com> Date: Fri, 27 Apr 2018 20:53:00 -0000 In-Reply-To: <0a567678-2138-4634-d472-44c170f47f93@redhat.com> (Pedro Alves's message of "Fri, 27 Apr 2018 19:02:30 +0100") Message-ID: <87604c5q2r.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1fCAMn-0020vs-D2 X-Source-Sender: 97-122-176-117.hlrn.qwest.net (pokyo) [97.122.176.117]:35518 X-Source-Auth: tom+tromey.com X-Email-Count: 6 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-04/txt/msg00583.txt.bz2 >>>>> "Pedro" == Pedro Alves 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