From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71880 invoked by alias); 7 Apr 2017 20:22:29 -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 71862 invoked by uid 89); 7 Apr 2017 20:22:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy= X-HELO: mail-it0-f46.google.com Received: from mail-it0-f46.google.com (HELO mail-it0-f46.google.com) (209.85.214.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Apr 2017 20:22:27 +0000 Received: by mail-it0-f46.google.com with SMTP id y18so371484itc.1 for ; Fri, 07 Apr 2017 13:22:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TcqcFDMLpvIpTiolH1qFRxPHxkJV8a9aNQdr9daiRx8=; b=h+3Fw0+DuyTkFRNk0vOe65NpsCiwhKOwReNf+P4pALYxz0+o6oOrcy9ortCDvkTPLP +yldKpwuZdUulxXA5iaJPbGILqcJbHzPGcPPB31HmbRRvl6/wrRp+N2R5Lzddu7dwC3s B5xVfQWSQugtcsAKXXSetttLyUvMcEmzi1fgr52p6ID4JhXwlSlPGA5tmes9H3M3+V7w L/MQVDg6UfclZkFeM/7ybGknnRJKA9UQ8/lSY6DaPTI+b7p1x2WS3fOeAVvlpbb/5K7k R6WngyFricY5k+joctRaVN8VD44nLwYkNRMAGlKbhPxACH9CE52UntFmH+/ZyADcY18h KKKw== X-Gm-Message-State: AN3rC/6uB2Cx1woq59tlwE3qHeFXLTkEy/4cl+5nv89rAFZ96WEKH79EmGOS92X1iM6r1h5bOnJH3J9yN4BDG0A5 X-Received: by 10.36.54.149 with SMTP id l143mr1359407itl.38.1491596547331; Fri, 07 Apr 2017 13:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.136.194 with HTTP; Fri, 7 Apr 2017 13:22:06 -0700 (PDT) In-Reply-To: References: <6a5109d6-81fb-c36c-e525-b2ed984760dc@redhat.com> <21E940B5-C8C4-4A86-8C15-49A86547DD87@suse.de> <20170405160333.GR4425@redhat.com> <20170405160849.GV17461@tucnak> From: Jason Merrill Date: Fri, 07 Apr 2017 20:22:00 -0000 Message-ID: Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) To: Bernd Edlinger Cc: Richard Biener , Jakub Jelinek , Jonathan Wakely , Florian Weimer , GCC Patches , Jeff Law Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00406.txt.bz2 On Fri, Apr 7, 2017 at 11:32 AM, Bernd Edlinger wrote: > On 04/07/17 17:10, Richard Biener wrote: >> On April 7, 2017 3:37:30 PM GMT+02:00, Bernd Edlinger wrote: >>> On 04/07/17 08:54, Richard Biener wrote: >>>> On Thu, 6 Apr 2017, Bernd Edlinger wrote: >>>>> I think get_alias_set(t) will return 0 for typeless_storage >>>>> types, and therefore has_zero_child will be set anyway. >>>>> I think both mean the same thing in the end, but it depends on >>>>> what typeless_storage should actually mean, and we have >>>>> not yet the same idea about it. >>>> >>>> But has_zero_child does not do what we like it to because otherwise >>>> in the PR using the char[] array member would have worked! >>>> >>>> has_zero_child doesn't do that on purpose of course, but this means >>>> returing alias-set zero for the typeless storage _member_ doesn't >>>> suffice. >>>> >>> >>> I see you have a certain idea how to solve the C++17 issue. >>> And yes, I apologize, if I tried to pee on your tree :) >> >> We do have the need to support this part of the C++ standard. For other= user code may_alias suffices and I see no reason to haste inventing sth ne= w without a single convincing testcase. GCC/Language extensions should not= be added without a good reason. >> >> I didn't propose to expose the type flag to users at all. >> >> Richard. >> > > Well, actually you did: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D79671#c100 > > But I won't argue if you prefer to do it as you like, > after all TBAA is your area. So that is fine for me. > > Attached is the latest version of my patch, I fixed > the issue with the type-flag conversion, and it is > already fully functional. I agree that we don't want a new attribute. This should not be limited to C++17 mode; std::aligned_storage is in C++11 and we might as well have the same behavior in C++98 mode. Jason