From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id A1cbBPGI819PJwAAWB0awg (envelope-from ) for ; Mon, 04 Jan 2021 16:30:25 -0500 Received: by simark.ca (Postfix, from userid 112) id 070F61F0AA; Mon, 4 Jan 2021 16:30:25 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 273531E965 for ; Mon, 4 Jan 2021 16:30:24 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 510A138930F7; Mon, 4 Jan 2021 21:30:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 510A138930F7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1609795823; bh=Cm5W84nteAERduS1kvbMBkhPgb2PRr0UzaQOqd+wr3Q=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=cfOwbkKCpM2u0AyPfRYpY6DYPu7+UCPnVLJHTIN7tRz085OB4VOE8ttVyWGKa5eMA Mrh1F+DoawEkHL1vSaDjPZUl9aYqzj2uO3n2OC+sQvPIPoQkNOI4pIV0+GrV5CAcXf CTbacVZcjTRVlOdG6YOa6GiSnAP+UnGcehwk2cn8= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id E82EC38930F2 for ; Mon, 4 Jan 2021 21:30:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E82EC38930F2 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 104LUCAV017438 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Jan 2021 16:30:17 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 104LUCAV017438 Received: from [10.0.0.213] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 3E6F81E965; Mon, 4 Jan 2021 16:30:12 -0500 (EST) Subject: Re: [PATCH] Fix building gdb with gcc-4.x To: Bernd Edlinger , "gdb-patches@sourceware.org" , Luis Machado References: Message-ID: <13ad5646-78f6-27dc-2e26-f250bb4b8c52@polymtl.ca> Date: Mon, 4 Jan 2021 16:30:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 4 Jan 2021 21:30:12 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-04 3:57 p.m., Bernd Edlinger wrote: > Hi, > > with Luis' commit of today the trunk is no longer able to > be compiled with gcc-4.x. > > The problem is std::is_trivially_default_constructible is > not defined before gcc-5 although the compiler supports C++11 > > I am not sure about what's the best approach for conditionally > enabling the code, especially for compilers other than g++. > > > This fixes the build for me. > Is it OK for trunk? > > > Thanks > Bernd. > We have other instances of this, I'd suggest inspiring yourself from: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/unittests/enum-flags-selftests.c;h=e3b6cf81d07f1eaefec72bce131d1c75ce00ef82;hb=HEAD#l66 These defines are defined here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/traits.h;h=f545edbb0d93e95f65e954fbf54cbc8843e5239a;hb=HEAD#l28 As you see, we already have a HAVE_IS_TRIVIALLY_CONSTRUCTIBLE, we could use it. The code in trad-frame.c could be changed to use std::is_trivially_constructible instead of std::is_trivially_default_constructible, I believe it's the same when passing no Args... to is_trivially_constructible. See "Possible implementation" in: https://en.cppreference.com/w/cpp/types/is_default_constructible Simon