From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52866 invoked by alias); 20 Dec 2016 16:48:45 -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 52851 invoked by uid 89); 20 Dec 2016 16:48:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:ad3c151, H*MI:sk:ad3c151, H*f:sk:ad3c151 X-HELO: mail-yw0-f196.google.com Received: from mail-yw0-f196.google.com (HELO mail-yw0-f196.google.com) (209.85.161.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Dec 2016 16:48:43 +0000 Received: by mail-yw0-f196.google.com with SMTP id s68so11041804ywg.0 for ; Tue, 20 Dec 2016 08:48:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bWzO0FEH01nxLumZITgBs84wtlS951oyTl3An9Oipb4=; b=iaatrh4gR92xOkrDvXac9Yk8P2Auc9nPEmaAL4MQLyJxOWjbsI/4RyCF7K77PT6c/J nNgSk7gy9Fl4htCHwHIRdMz7ocoSwOv1JAzlV/wNt95nbmngsGXpS/PYYIQdZuorV31X HQwpwEewtYA957cVD1BoUzbiWViMo1SfpXd1w4zW6DvDY/DBIICojzm5CVJFQfuvvenn pcRJe694TdS+Pp0nPryZQHCSrui489yyH+SBNxpg53Z3miD33D55PSu2UuL1Iyg7Dnhy BJ0Bn/K+HmrfQdTUHqupiPG49fL7e4C/4ReAKpMTbVaFwREM7cgtCXE5An9s7wbKnOKb MiOA== X-Gm-Message-State: AIkVDXKl61Rf65Hf1UqRNNuLJ7tR5m5d7HhJZfHihkoGcQKlHP1kLFQCMaz2JJxAem0ILQ== X-Received: by 10.13.219.9 with SMTP id d9mr207164ywe.206.1482252521413; Tue, 20 Dec 2016 08:48:41 -0800 (PST) Received: from ?IPv6:2620:10d:c0a3:20fb:f6d0:5ac5:64cd:f102? ([2620:10d:c091:200::9:e608]) by smtp.googlemail.com with ESMTPSA id r204sm9389727ywr.32.2016.12.20.08.48.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Dec 2016 08:48:40 -0800 (PST) Subject: Re: [PR c++/78572] handle array self references in intializers To: Aldy Hernandez , jason merrill , gcc-patches References: From: Nathan Sidwell Message-ID: <5d83a71e-c451-1bb6-8886-e762c64a9395@acm.org> Date: Tue, 20 Dec 2016 17:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-12/txt/msg01725.txt.bz2 On 12/20/2016 11:25 AM, Aldy Hernandez wrote: > The problem in this PR is that we're trying to initialize an array with > members of itself: > Jakub has even gone further to show that for the following: > > ... = { array[3]=5, array[7]=3, array[7]=8, array[7] = 9 }; > > things get even worse, because we generate code to write twice into [3]: > > {[3]=5, [0]=5, [7]=9, [1]=3, [2]=8, [3]=9} I looked at this a couple of weeks ago, and got confused. It wasn't very clear to me how the side-effect assignments interact with any implict zero assignments. (Especially if one then tries to support C-style designated initializers). IIUC the side effects of an initializer are evaluated before the storage of the initializer itself (separated by a sequence point). further it seems that default zero initialization of non-explicitly initialized elements happens after any side-effected store to that element (and hence zaps the sideeffect). The rules for non-aggregates appear to be as-if one builds a temporary object and then copy-constructs it into the object -- clearly zapping any and all side-effects. However for aggregate initializations it looked like elements were initialized in order -- so the side effect on a later element could overwrite the initialization of an earlier element. It wasn't entirely clear. nathan -- Nathan Sidwell