From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71331 invoked by alias); 8 Apr 2015 15:08:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 71316 invoked by uid 89); 8 Apr 2015 15:08:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 08 Apr 2015 15:08:06 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id B5D1A8E799; Wed, 8 Apr 2015 15:08:04 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-58.ams2.redhat.com [10.36.116.58]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t38F82F2029735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2015 11:08:03 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t38F80Ma028398; Wed, 8 Apr 2015 17:08:01 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t38F7xBb028397; Wed, 8 Apr 2015 17:07:59 +0200 Date: Wed, 08 Apr 2015 15:08:00 -0000 From: Jakub Jelinek To: Jason Merrill Cc: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: [C++ PATCH] Fix alignment handling in build_cplus_array_type/cp_build_qualified_type_real (PR c++/65690) Message-ID: <20150408150759.GS19273@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20150408100239.GO19273@tucnak.redhat.com> <55253F73.1000902@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55253F73.1000902@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00323.txt.bz2 On Wed, Apr 08, 2015 at 10:47:15AM -0400, Jason Merrill wrote: > On 04/08/2015 06:02 AM, Jakub Jelinek wrote: > > (cp_build_qualified_type_real): Use check_base_type. Build a > > variant and copy over even TYPE_CONTEXT and > > TYPE_ALIGN/TYPE_USER_ALIGN if any of those are different. > > This seems wrong. If there is an array with the same name, attributes and > element type, it should have the same alignment; if it doesn't, that > probably means that one of the types hasn't been laid out yet. We don't > want to have two variants of the same array that are distinguished only by > whether they've been laid out, especially since later probably both will be > laid out and the two types will be the same. But that is how handle_aligned_attribute works, since forever (checked it back to 3.2). In <= 3.4.x, it used to create it using build_type_copy, since 4.0.0 using build_variant_type_copy, but both those routines behave the same - build a type variant which is linked in the TYPE_NEXT_VARIANT chain, and differs from the other type in there possibly just by TYPE_ALIGN/TYPE_USER_ALIGN. Perhaps it should check TYPE_ALIGN only if at least one of the two types has TYPE_USER_ALIGN set? As for why TYPE_ATTRIBUTES are NULL, the reason for that is that these are attributes on a typedef, so the attributes go into DECL_ATTRIBUTES of the TYPE_DECL instead. Anyway, the P1 regression is just about the first hunk, so if you have issues just with the second hunk and not the first hunk (from either of the patches), I can just comment out the tests for alignof (const T), and open a separate PR for that for later. Jakub