From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28848 invoked by alias); 1 Aug 2012 08:41:02 -0000 Received: (qmail 28834 invoked by uid 22791); 1 Aug 2012 08:41:01 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Aug 2012 08:40:48 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 54841A39D2; Wed, 1 Aug 2012 10:40:47 +0200 (CEST) Date: Wed, 01 Aug 2012 08:41:00 -0000 From: Richard Guenther To: Richard Henderson Cc: uweigand@de.ibm.com, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 0/2] Convert s390 to atomic optabs, v2 In-Reply-To: <5017FD48.8080005@redhat.com> Message-ID: References: <5016C81E.5020709@redhat.com> <1343687574-3244-1-git-send-email-rth@redhat.com> <5017FD48.8080005@redhat.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-SW-Source: 2012-08/txt/msg00003.txt.bz2 On Tue, 31 Jul 2012, Richard Henderson wrote: > On 2012-07-31 02:09, Richard Guenther wrote: > > What do we expect __builtin_compare_exchange to do for > > unaligned inputs? > > At the moment we expect it to SIGBUS, as a rule. > > We'd *like* to defer to the library routine for unaligned, > but we don't do that yet. I see. So your issue is that you don't get the knowledge that the address is even more aligned than required by the builtin. > Too bad about not being able to query addresses/ssa_names > for their alignment; I thought we could do that already. We can - just we cannot rely on type information for addresses, mainly because people write non-conforming C code all the time (and thus we settled on their side for middle-end semantics). On x86_64 it's common to do int foo (int *p) { if ((uintptr_t)p & 3) return 0; return *p; } and if we'd use type information for 'p' then we'd optimize away the alignment test ... So we only use type information when seeing an actual memory reference where we make sure to keep alignment info correct (which we don't bother to do for addresses). Richard.