From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73581 invoked by alias); 25 Mar 2015 18:49:18 -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 73563 invoked by uid 89); 25 Mar 2015 18:49:17 -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-Spam-User: qpsmtpd, 2 recipients 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, 25 Mar 2015 18:49:17 +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 (8.14.4/8.14.4) with ESMTP id t2PInFqG029623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Mar 2015 14:49:15 -0400 Received: from localhost (ovpn-116-96.ams2.redhat.com [10.36.116.96]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2PInEZn028578; Wed, 25 Mar 2015 14:49:14 -0400 Date: Wed, 25 Mar 2015 18:49:00 -0000 From: Jonathan Wakely To: Richard Henderson Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Andrew MacLeod Subject: Re: [libstdc++/65033] Give alignment info to libatomic Message-ID: <20150325184913.GH9755@redhat.com> References: <54DD19B7.6060401@redhat.com> <20150218121512.GI3360@redhat.com> <20150325162244.GF9755@redhat.com> <5513003D.3040107@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5513003D.3040107@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-03/txt/msg01316.txt.bz2 On 25/03/15 11:36 -0700, Richard Henderson wrote: >On 03/25/2015 09:22 AM, Jonathan Wakely wrote: >> private: >> - _Tp _M_i; >> + // Align 1/2/4/8/16-byte types the same as integer types of that size. >> + // This matches the alignment effects of the C11 _Atomic qualifier. >> + static constexpr int _S_alignment >> + = sizeof(_Tp) == sizeof(char) ? alignof(char) >> + : sizeof(_Tp) == sizeof(short) ? alignof(short) >> + : sizeof(_Tp) == sizeof(int) ? alignof(int) >> + : sizeof(_Tp) == sizeof(long) ? alignof(long) >> + : sizeof(_Tp) == sizeof(long long) ? alignof(long long) >> +#ifdef _GLIBCXX_USE_INT128 >> + : sizeof(_Tp) == sizeof(__int128) ? alignof(__int128) >> +#endif >> + : alignof(_Tp); >> + >> + alignas(_S_alignment) _Tp _M_i; > > >Surely not by reducing a larger alignment applied to _Tp. >I.e. > > static constexpr int _S_min_alignment > = sizeof(_Tp) == sizeof(char) ? alignof(char) > : sizeof(_Tp) == sizeof(short) ? alignof(short) > : sizeof(_Tp) == sizeof(int) ? alignof(int) > : sizeof(_Tp) == sizeof(long) ? alignof(long) > : sizeof(_Tp) == sizeof(long long) ? alignof(long long) >#ifdef _GLIBCXX_USE_INT128 > : sizeof(_Tp) == sizeof(__int128) ? alignof(__int128) >#endif > : 0; > > static constexpr int _S_alignment > = _S_min_alignment > alignof(_Tp) ? _S_min_alignment : alignof(_Tp); Doh, good catch. I'll make that change and add a test with a type that has alignof(X) > sizeof(X). On 25/03/15 11:39 -0700, Richard Henderson wrote: >On 03/25/2015 09:22 AM, Jonathan Wakely wrote: >> +static_assert( alignof(std::atomic) > alignof(int), >> + "std::atomic not suitably aligned" ); > >This is only true if int64_t has alignment larger than int32_t, >which is unfortunately not always the case. Huh, didn't realise that. I could change the tests to check it's alignof(std::int64_t) as the next assertion does, but is it safe to assume that struct twoints { int a; int b; } is exactly 64 bits everywhere? I'd prefer not to have the test say "if sizeof(twoints) == sizeof(long), test this, otherwise if sizeof(twoints) == ..."