From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81131 invoked by alias); 24 Apr 2018 20:23:07 -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 81120 invoked by uid 89); 24 Apr 2018 20:23:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=feelings X-HELO: gateway33.websitewelcome.com Received: from gateway33.websitewelcome.com (HELO gateway33.websitewelcome.com) (192.185.146.87) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Apr 2018 20:23:04 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway33.websitewelcome.com (Postfix) with ESMTP id E9D6A232431 for ; Tue, 24 Apr 2018 15:23:01 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id B4Srf6kxyy2aLB4SrfSh8O; Tue, 24 Apr 2018 15:23:01 -0500 X-Authority-Reason: nr=8 Received: from 97-122-176-117.hlrn.qwest.net ([97.122.176.117]:53276 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fB4Sr-0035JG-N5; Tue, 24 Apr 2018 15:23:01 -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> Date: Tue, 24 Apr 2018 20:23:00 -0000 In-Reply-To: (Pedro Alves's message of "Tue, 24 Apr 2018 20:17:33 +0100") Message-ID: <87bme88icb.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: 1fB4Sr-0035JG-N5 X-Source-Sender: 97-122-176-117.hlrn.qwest.net (pokyo) [97.122.176.117]:53276 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-04/txt/msg00488.txt.bz2 >>>>> "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. 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, which is one reason that sizeof requires or does not require parens depending on whether the argument is an expression or a type. It would be possible to write "alignof expression", but I didn't want to add an extension, especially since "alignof(typeof(expression))" is pretty easy. 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. Pedro> There was a snippet in the patch that made me wonder if the patch Pedro> handles alignof of a no-debug-info variable and and the return-type Pedro> of a no-debug-info function correctly (instead of e.g., crashing). Pedro> I'd be nice to add a couples test to gdb.base/nodebug.exp Pedro> to make sure. E.g.: Pedro> p _Alignof (dataglobal64_1) Pedro> p _Alignof (middle())" Pedro> Also, please add intro comments to the testcase .exp files, so Pedro> that later on people can find out what the testcase is Pedro> about easily. Ok to all. Tom