From patchwork Wed Mar 30 14:11:58 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 88924 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 111EAB6EE8 for ; Thu, 31 Mar 2011 01:12:06 +1100 (EST) Received: (qmail 5828 invoked by alias); 30 Mar 2011 14:12:05 -0000 Received: (qmail 5819 invoked by uid 22791); 30 Mar 2011 14:12:04 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, TW_BW, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Mar 2011 14:11:59 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2UEBxW2015744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 10:11:59 -0400 Received: from houston.quesejoda.com (vpn-231-143.phx2.redhat.com [10.3.231.143]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p2UEBwv0014477; Wed, 30 Mar 2011 10:11:59 -0400 Message-ID: <4D933A2E.9030105@redhat.com> Date: Wed, 30 Mar 2011 09:11:58 -0500 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Richard Guenther CC: gcc-patches , Jakub Jelinek Subject: Re: [cxx-mem-model] bitfield tests References: <4D92103E.90100@redhat.com> In-Reply-To: Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org > The memory model is not implementable on strict-alignment targets > that do not have a byte store operation. But we previously said that ;) Yes. I think we should issue an error when we have such a target and the user tries -fmemory-model=c++0x. However, how many strict-alignment targets are not byte addressable nowadays? > Also consider global vars > > char a; > char b; > > accessing them on strict-align targets may access adjacent globals > (that's a problem anyway, also with alias analysis). Good point. I am adding a test to that effect (see attached patch). BTW, I assume you mean strict-align targets WITHOUT byte-addressability as above. I have spot-checked your scenario on a handful of important targets that have strict alignment, and all of them work without touching adjacent global vars: arm-elf OK sparc-linux OK ia64-linux OK alpha-linux OK, but only with -mbwx (byte addressability) rth tells me that we shouldn't worry about ancient non-byte addressable Alphas, so the last isn't an issue. So... do you have any important targets in mind, because I don't see this being a problem for most targets? As can be expected, I am only interested in x86*, powerpc*, and s390, especially since a cursory glance on other important targets didn't exhibit any problems. However, given my target bias, I am willing to look into any important targets that are problematic (I'm hoping none :)). Let me know if you see anything else, and please take a quick peek at the attached patch below, which I will be committing shortly. As usual, thanks. Aldy Index: testsuite/gcc.dg/memmodel/strict-align-global.c =================================================================== --- testsuite/gcc.dg/memmodel/strict-align-global.c (revision 0) +++ testsuite/gcc.dg/memmodel/strict-align-global.c (revision 0) @@ -0,0 +1,46 @@ +/* { dg-do link } */ +/* { dg-options "-O2 --param allow-packed-store-data-races=0" } */ +/* { dg-final { memmodel-gdb-test } } */ + +#include +#include "memmodel.h" + +/* This test verifies writes to globals do not write to adjacent + globals. This mostly happens on strict-align targets that are not + byte addressable (old Alphas, etc). */ + +char a = 0; +char b = 77; + +void memmodel_other_threads() +{ +} + +int memmodel_step_verify() +{ + if (b != 77) + { + printf("FAIL: Unexpected value. is %d, should be 77\n", b); + return 1; + } + return 0; +} + +/* Verify that every variable has the correct value. */ +int memmodel_final_verify() +{ + int ret = memmodel_step_verify (); + if (a != 66) + { + printf("FAIL: Unexpected value. is %d, should be 66\n", a); + return 1; + } + return ret; +} + +int main () +{ + a = 66; + memmodel_done(); + return 0; +}