From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30704 invoked by alias); 22 Nov 2013 19:47:41 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 30694 invoked by uid 89); 22 Nov 2013 19:47:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_40,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-oa0-f52.google.com Received: from Unknown (HELO mail-oa0-f52.google.com) (209.85.219.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 22 Nov 2013 19:47:39 +0000 Received: by mail-oa0-f52.google.com with SMTP id h16so1896623oag.11 for ; Fri, 22 Nov 2013 11:47:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EqID6peXhrf8Razu6rZofCWtmjwmKFIhVX7t2ipt/tw=; b=EMpZR1SkNoa5GPGSYA5XwMytGxDeb8VcEzofQMrCHlqclKVwXZ01iZjZsB8hIIgv2v z/CUOVSRc6OAgCIF3UmtWKQ7Z4R8KObs/UJfLunOEXnaOPDuOAlKF5Doy6CEjL5S2Fyg MaLxMEhVhJV4Q6QsprUCooHJ0dw8kMa0Pw3pPVPfFA60UZF5b8j3WU9lAyDcAbmz2YHN 6r+uCF1ScBykoTkNB+E7luQSw5DNg/8xkTSfHdhfAw9vBbRbT8s9CUh/JqKVRQmBLS+8 RwKWwC3hNEsX7gv/nX42mn7ipLzU4EsHhXvylzE2mI7KCNCItPGBYZBK5gbEtrzWecxV YpVA== X-Gm-Message-State: ALoCoQnkvieDZEUPVtNmk6X4k4a9pMg+9w2Id9wwEhD+vcGasZptinuVKf4YmzCKqVCOzDq1mxUWrsXNEICIiZsmE2EnKB+q71SKmetoXLF5xBRQrbfKpubI/V1HcjXjW7eNPtnmGpA2VA7+hkkPTOrfZ33jeArET1u7T6sENPm7j9gx0XzSvTfUaEcBl0H2FPvxxjT7QexI MIME-Version: 1.0 X-Received: by 10.60.125.138 with SMTP id mq10mr112906oeb.90.1385149651686; Fri, 22 Nov 2013 11:47:31 -0800 (PST) Received: by 10.60.145.144 with HTTP; Fri, 22 Nov 2013 11:47:31 -0800 (PST) In-Reply-To: References: <1385018681.2093.3.camel@corvax> Date: Sat, 23 Nov 2013 02:48:00 -0000 Message-ID: Subject: Re: how to disable optimization for particular assignment statements? From: Ian Lance Taylor To: "gcc-help@gcc.gnu.org" Cc: Andrew Makhorin Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00188.txt.bz2 On Thu, Nov 21, 2013 at 12:55 AM, Marc Glisse wrote: > On Thu, 21 Nov 2013, Marc Glisse wrote: > >> On Thu, 21 Nov 2013, Andrew Makhorin wrote: >> >>> Hello, >>> >>> I have a C code like this: >>> >>> int foo(void) >>> { int phase; >>> . . . >>> phase = 1; >>> phase = 2; >>> phase = 3; >>> . . . >>> } >>> >>> In case of -O0 gcc generates machine instructions for every >>> assignment 'phase = ...'. But in case of -O2 gcc does not generate >>> instructions for some assigments. Of course, this is correct. However, >>> is there any way to tell gcc that 'phase' object is inspected by another >>> thread, so it should not remove such statements? >> >> >> volatile > > > Well, volatile will prevent the operations from being removed. For proper > synchronization with other threads, using atomic operations with the right > synchronization parameter sounds better. Basic rule of thumb: if code is not thread-safe, adding volatile will never make it thread-safe. That rule of thumb applies here. Adding volatile will not work, because it will not make the changes to the value visible to other processors. > http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html Yes, if you have decided that this is what you really want to do, using the atomic (or sync) builtins is the only viable approach. Ian