From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46721 invoked by alias); 26 Oct 2017 18:05:28 -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 46711 invoked by uid 89); 26 Oct 2017 18:05:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=camp X-HELO: mail-wm0-f45.google.com Received: from mail-wm0-f45.google.com (HELO mail-wm0-f45.google.com) (74.125.82.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Oct 2017 18:05:26 +0000 Received: by mail-wm0-f45.google.com with SMTP id r196so9575621wmf.2 for ; Thu, 26 Oct 2017 11:05:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=roUA5hJwhxWnXPqP00kMfJdm7At8LDYYiWIhOe99CYA=; b=GKpn/xJ0xkFzzSfDyQCPI5kDhJC1pUzrdhIcylyDBFlS0cUFXX/z8UJykQEVMsELR/ refFVNLK2qpPQ7uG6SFiJRvHtuVfz2zRYeM6Ln37QjwcGSRBiDIadp1JarMYoq7A6sLt dzszn3ETAyvO4y6jOa4s0kdFB85D3sfGW1cseOnJyALw5vyo0B4SxUAlp3PyO249oPu9 SZEoOeS1TBGQuPxpDlWtaEI+hS183dBR+/+lEV2WIC5Ov/fBXl8NoPHooTOZZcOhVmZ6 W84JDXMRMUYXLGW9lN10o1Ni8m0nMMaV6WM2UAxPvJ5Od15NyZtlXFUns05Sv8c/f2Ea ZSew== X-Gm-Message-State: AMCzsaUTYkG+Tp8UasY+vnqrXE74FzEzPGtaDaYn4Mbd2JIg0ttOxdG4 nLsfUBWLcy+6Aw+f9fYE8b1ucA== X-Google-Smtp-Source: ABhQp+Sv6ia3HfAF4ZIgIdU//kb+NwXDAa4qH/o89FOYmITPCoLFF9G6HoWV2mKza7FTMIsGyIARsQ== X-Received: by 10.28.74.193 with SMTP id n62mr2415996wmi.61.1509041124445; Thu, 26 Oct 2017 11:05:24 -0700 (PDT) Received: from [192.168.0.123] (bl17-148-124.dsl.telepac.pt. [188.82.148.124]) by smtp.gmail.com with ESMTPSA id u138sm1946315wmd.17.2017.10.26.11.05.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 11:05:23 -0700 (PDT) Subject: Re: [006/nnn] poly_int: tree constants To: Martin Sebor , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org References: <871sltvm7r.fsf@linaro.org> <878tg1u7cl.fsf@linaro.org> <877evi3oeh.fsf@linaro.org> <8737662tlp.fsf@linaro.org> <2840a6a6-f80c-ca8f-aab2-2729ac598bf6@gmail.com> From: Pedro Alves Message-ID: <6a1236c2-f271-8309-5b7f-ac8723889cc0@redhat.com> Date: Thu, 26 Oct 2017 18:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2840a6a6-f80c-ca8f-aab2-2729ac598bf6@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg01978.txt.bz2 On 10/26/2017 05:37 PM, Martin Sebor wrote: > I agree that the latter use case is more common in GCC, but I don't > see it as a good thing. GCC was written in C and most code still > uses now outdated C practices such as declaring variables at the top > of a (often long) function, and usually without initializing them. > It's been established that it's far better to declare variables with > the smallest scope, and to initialize them on declaration. Compilers > are smart enough these days to eliminate redundant initialization or > assignments. I don't agree that that's established. FWIW, I'm on the "prefer the -Wuninitialized" warnings camp. I've been looking forward to all the VRP and threader improvements hoping that that warning (and -Wmaybe-uninitialized...) will improve along. > My comment is not motivated by convenience. What I'm concerned > about is that defining a default ctor to be a no-op defeats the > zero-initialization semantics most users expect of T(). This sounds like it's a problem because GCC is written in C++98. You can get the semantics you want in C++11 by defining the constructor with "= default;" : struct T { T(int); // some other constructor forcing me to // add a default constructor. T() = default; // give me default construction using // default initialization. int i; }; And now 'T t;' leaves T::i default initialized, i.e., uninitialized, while T() value-initializes T::i, i.e., initializes it to zero. So if that's a concern, maybe you could use "= default" conditionally depending on #if __cplusplus >= C++11, so that you'd get it for stages after stage1. Or just start requiring C++11 already. :-) Thanks, Pedro Alves