From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101407 invoked by alias); 27 Oct 2017 15:13:39 -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 101377 invoked by uid 89); 27 Oct 2017 15:13:38 -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,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=corners, ground, dusty, balancing X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Oct 2017 15:13:37 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5B3B28047F; Fri, 27 Oct 2017 15:13:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5B3B28047F Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-112-16.phx2.redhat.com [10.3.112.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8C76880E10; Fri, 27 Oct 2017 15:13:35 +0000 (UTC) Subject: Re: [09/nn] Add a fixed_size_mode_pod class To: Richard Biener , Jakub Jelinek Cc: GCC Patches , Richard Sandiford References: <87wp3mxgir.fsf@linaro.org> <87tvyqw1ki.fsf@linaro.org> <87y3ny14rf.fsf@linaro.org> <20171026194356.GV14653@tucnak> From: Jeff Law Message-ID: <8c8cb46e-1bbb-92a5-2c1e-2b6d8e2bd00c@redhat.com> Date: Fri, 27 Oct 2017 15:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg02085.txt.bz2 On 10/27/2017 02:35 AM, Richard Biener wrote: > On Thu, Oct 26, 2017 at 9:43 PM, Jakub Jelinek wrote: >> On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote: >>> On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford >>> wrote: >>>> Richard Biener writes: >>>>> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford >>>>> wrote: >>>>>> This patch adds a POD version of fixed_size_mode. The only current use >>>>>> is for storing the __builtin_apply and __builtin_result register modes, >>>>>> which were made fixed_size_modes by the previous patch. >>>>> >>>>> Bah - can we update our host compiler to C++11/14 please ...? >>>>> (maybe requiring that build with GCC 4.8 as host compiler works, >>>>> GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). >>>> >>>> That'd be great :-) It would avoid all the poly_int_pod stuff too, >>>> and allow some clean-up of wide-int.h. >>> >>> Can you figure what oldest GCC release supports the C++11/14 POD handling >>> that would be required? >> >> I think it is too early for that, we aren't LLVM or Rust that don't really >> care about what build requirements they impose on users. > > That's true, which is why I asked. For me requiring sth newer than GCC 4.8 > would be a blocker given that's the system compiler on our latest server > (and "stable" OSS) product. > > I guess it depends on the amount of pain we have going forward with C++ > use in GCC. Given that gdb already requires C++11 people building > GCC are likely already experiencing the "issue". It's always going to be a balancing act. Clearly we don't want to go to something like the Rust model. But we also don't want to limit ourselves to such old tools that we end up hacking around compiler bugs or avoiding features that can make the codebase easier to maintain and improve or end up depending on dusty corners of C++98/C++03 implementations that nobody else uses/tests anymore because they've moved on to C++11. To be more concrete, if I had to put a stake in the ground. I'd want to pick a semi- recent version of Sun, IBM and Clang/LLVM as well as GCC. Ideally it'd be something that supports C++11 as a language, even if the runtime isn't fully compliant. I suspect anything older than GCC 4.8 wouldn't have enough C++11 and anything newer to not work well for the distros (Red Hat included). Jeff