From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2067.outbound.protection.outlook.com [40.107.94.67]) by sourceware.org (Postfix) with ESMTPS id 5BCC0385CC92 for ; Thu, 5 Oct 2023 14:26:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5BCC0385CC92 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=amd.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=amd.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=meHR5wuYPQdiX6yEQKhIkm4xwZLy+5K+jQ9JLoAQ93OC0PxHplVlj/5HhmgWIqySthaLcczAxDlgxMjwOlQjS8qZW33CMkKstBzknns663LsSfUtUS3hdhmn7eCwpZAVdKluXGO3nk9j1KJKBw9SqyteeZ4+Uvu7tS92z1fUjdddwxONOOnTE/m6eCphdHmZRbmqFVWK29R6o6rDoylEOuANR8uJvuuYNFz4wfYeSQzKB8b4uwSuTOHjXQifwrNKRmfcpWS44A6cDBMtE2dx/JbRJEEKvFwPUBdV0inW5biwzHnqNN9r6CEqpvkTfgDPmayLit41u9vFXfSYgjQwYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rBi9J0vqzWeBNK7wFbQ9FGA4zX8pP+BlY0ZqAzRJ4PY=; b=aAbePArFKWmoc0S9roQ4D4wFRjInJN49xx/Mqf35EeRC505JfUaPZIqKxYxNVixAtGEXT5euh4qtZixaKBsrhR6VKaGhJ5yQa1rdvCalNR046KwUHZ20VdK6SzVGiA5u3UwT6qrXBVG3kDxC3N3rjzWrDu5lrPGyj1h1xxLCADxA4FqeSH7+v57C1stR1iv4C+qI0HyRwkjcebIMEkRcFkMDMYrPCEExi0ll5kr+Kh8LpsVn3BbDHhpPAAzHFPtpuKThtLlIFohKegnI5Aba+6TK9zJHiz/331JYz0gTePjBZb2Y34RX2XAvTMUw0DRDfqkpql+x9K+hjG9LQcAgUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rBi9J0vqzWeBNK7wFbQ9FGA4zX8pP+BlY0ZqAzRJ4PY=; b=xolEAu/9nnz4nFDdy/6BUQV2emrWlQUpUHjzm5m/8qbLT8ZIgy0F8uZjNkDfoRHDfTMFWnKk2XJjrZftrkNqi7Xu8dUYfuPa04cTVV3DvFu/zqMfBcZ2BKuCU/FJRp8U+ik2i9qMjfKp23iGjJ6jEnc8Es20yDSvgFv7XkF3tTM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH3PR12MB9079.namprd12.prod.outlook.com (2603:10b6:610:1a1::9) by SN7PR12MB7370.namprd12.prod.outlook.com (2603:10b6:806:299::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.27; Thu, 5 Oct 2023 14:26:35 +0000 Received: from CH3PR12MB9079.namprd12.prod.outlook.com ([fe80::3120:8014:c770:9f8f]) by CH3PR12MB9079.namprd12.prod.outlook.com ([fe80::3120:8014:c770:9f8f%7]) with mapi id 15.20.6838.033; Thu, 5 Oct 2023 14:26:34 +0000 Message-ID: Date: Thu, 5 Oct 2023 15:26:27 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC] Require c++17 compiler To: Andrew Burgess , Tom de Vries Cc: gdb-patches@sourceware.org References: <20231005065449.32643-1-tdevries@suse.de> <20231005103354.5loeki67slszfrcy@hpe6u-23> <87h6n5tfu9.fsf@redhat.com> Content-Language: en-US From: Lancelot SIX In-Reply-To: <87h6n5tfu9.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VI1PR0502CA0013.eurprd05.prod.outlook.com (2603:10a6:803:1::26) To CH3PR12MB9079.namprd12.prod.outlook.com (2603:10b6:610:1a1::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PR12MB9079:EE_|SN7PR12MB7370:EE_ X-MS-Office365-Filtering-Correlation-Id: dbddbfb5-37a3-4e3b-4ef4-08dbc5af13be X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: n9ffcKgcEcNO0dH5kR64Jk4Hb9HW0KBGsc3t5S82BJ6suj5e+HG1/FQ4tXpLxA0iRAfy+Ax1WouYbueBXKiLWWjDfgIl4FYvDacBh+I+KuAofYa7PG0lcPef1vrQYWC6tNVE9rCDL7GG1NB82mhObcM+ddluWmu/LG5idMTV0whspN4L6psixRkOj0IryQs758MaMWDPbVlIqfndm1Ntjttusee9R37dVIDr/IwUppOl7KWl3YPP3hYhJKH2Ux2BUI1nbkqMvnOHwUejfVD2KfkSU/2ArXykp+1x6witiw6SAX6XJiXcG4oJ7kBk558AUHlkyZIIxTRjaOFxmuac36DANWTuFiv4uM7OOp+aU76VURXyf5NXAP6hvxXNvhhhuhGqQbPSWqu2CcevU2zV7fGl0n30tO+Qe44DP5nFVGi9wW7t36WnvI+geQsbm0j0fn+6D6FFyv726tOMpMfoK8o0DCw7ct7kXhiCS1br9JNJV1P1La2tv7ANaIDOdhdRIlmHAqx+hzBqpOVFIzrX9YOcHbpyDsYOUCMP8DwH3sQo8wIjA8UWofgIZ59hzxCwxr9BuxiFg9o3sRyf2iN2w/gg6VpmQQI2ZW5PM7ZJ7o5kfNN5/on/H39G5kc3r/7k7e+dJh2YsdrN19X+PideIxWhnM8QL9nw6m8c+QJG/sL13W+suI2aJzGWX8BVreJM X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB9079.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(376002)(346002)(396003)(39860400002)(366004)(230922051799003)(64100799003)(1800799009)(186009)(451199024)(316002)(41300700001)(6486002)(2616005)(6512007)(6666004)(26005)(53546011)(83380400001)(86362001)(478600001)(966005)(38100700002)(31696002)(6506007)(36756003)(66476007)(66556008)(66946007)(110136005)(2906002)(8936002)(31686004)(4326008)(8676002)(5660300002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N0hGQ0ZLcGRvVTBOZWJ3ZGdrL1lRNUVXL002aEZMMW5wVTAzRnlFd3BHUTRT?= =?utf-8?B?MWVPRWptcTJERGY0NU5mWFVNNWRmTks0MXQzY3ZDNm44WWhkdEVrMzhXS1pa?= =?utf-8?B?THNHWndmaTh5bFZTTitIbHZUZVhYS0pnVy8yL2tLVmNvcGVKbXcrbUpLY25h?= =?utf-8?B?Yy9BSW1mSXhocUhGYnlJRnNDcnhRMFJMLzlxS3NJNUVnb1czc0ZCMDY2NXI3?= =?utf-8?B?ZEllQ2VtQ1E3WmR3S3ZPWXFlazJhUDNUcHNLdTVHRmcyK0pBbWFReHFTY2Fh?= =?utf-8?B?WGY2ZFA0RUFLY1AxczhHRjg5c0FOWCtNV3hZb1RtK2JQTmlkU0dHSHFQelhH?= =?utf-8?B?WXNnTXhjbTJiUzBxSmVhOVVGTTlnN25tY3R5Qm9XUHBKZmlpaFVkajNtbGRB?= =?utf-8?B?ZC8wV3NkSURBcHh5Z0Y0U0Z5Z2NPdFhUY2hCYmh0NEVIN05uRG5zMisxQm5m?= =?utf-8?B?UUs2Tis5ZXBhdTM0V1JCVzFKUTlPb0RCbGlnVGJpemU2OUJJYWs0ZlorRDJX?= =?utf-8?B?RDFlMElxRjVWWFQ2VVU3NjAxMm1wb0dXWFQwaEw1RElpdy9DZUNISlV2eFBG?= =?utf-8?B?RDJuRWQ5M2NsNUM2SGF5TWkzTjduRC9pL2VJNXlmRTlueENDdTNCZlFScDEw?= =?utf-8?B?Y1k3am9NdVVtVnM2d2NhcXVUU3FHNW5STG1kUUNhem1LY05HdDZnUTZDT3BX?= =?utf-8?B?NHliT3loMVBHSnd2SkVQSVA3Q2xHZ1IyZWRUdmJTUXhRK0JtcURuUlNadEVG?= =?utf-8?B?Wm1jdDhnc3U5dWtkUVZNNXRHUXBCbkFvcGVSM2k2UWtpWlBvU1J2akZPSlYw?= =?utf-8?B?bkd5MHZZRkl5Q2V5bmpvVFk4SnBaemNseXFJc2xaOHU2aWdEdzJTaXcrTDJG?= =?utf-8?B?V1Y4cnpra1VsR2s0Y0hadFZIY3dYcnRSUTlUQnNEZ08zZnA5cnpSbWRpUVNH?= =?utf-8?B?Z09qdlVFSGNwREJabzU3UmdOaHdVNXNMV1dGRU1uenpDdHpWaVJTb0hNSzli?= =?utf-8?B?bFQ3bjdHNTJJUTZFZ0NHZlk4b2MvMlpzbi9tZk1UWjJNSUZvaDRtSkpMN1Bh?= =?utf-8?B?dlZJbWEzaGZyd0hyRUdTUElxRDN3clpIK2pZNGQ4ZUlGTXJoWVBQY2RKMEVP?= =?utf-8?B?MGF5RXhpZGR3ZGFuOW9LUWFFZ3BBbjl4TnBFNjhsSFNBM2lwVmx0S0hYdjNX?= =?utf-8?B?dmN1djdxaTFEM0h1VjBQZm1PSXBrMjlzUURCcVo5dVpDMWlKaEU5djUzdi9U?= =?utf-8?B?ZS80TlFPaEVrZGdCMUZiMFR1VjRGNHpic1crRmJ1ZnhrWi93d2N2T2h3cWZS?= =?utf-8?B?cDJrNmFRMFBiUEw2SGlQTi9jS2ZjM0l0WndrZ0s3Mk9iUjQ5QXhxS0ZteW1H?= =?utf-8?B?SFJLNHZEd3NwWFlwck1aVTZyNXhrT0xrNGpqaTZZK1JPelhnVmNNSkdNUEFo?= =?utf-8?B?OVBmRVZXZjJTTGFSZ2szNExwVHFhejVaTi8vbENzMHJUMnNvOFFYMzc2bzFW?= =?utf-8?B?andSUkNRUXM2eTZacXYwbWtLQlhicmNWRUtRei8ybFlwT3BoZkl3cTdxRCtz?= =?utf-8?B?TnVDSEVlZnVYd2hIUE1MMkdHSUw5MWU4VDcwYzlaaEYwUFQ1Y2NUc3kzcUFV?= =?utf-8?B?SnJIcDFYU3o1TmhIOVFWd0lnQ2t2TzF2eTlzNXJENzV1U1BWOW1EVnpSY1VD?= =?utf-8?B?TmJDM0pKT1JvUjM3bkhyalE4WHZrblI1c09rYmRPSXp1bnNLMzVCR3U5aEhZ?= =?utf-8?B?ek1acGVNKzFrWlMyc3ZGdW50ajEyWlB6L2VYSDRNRnVKTmR0YmtlNHNYNnFs?= =?utf-8?B?bnRZdnhGZlJmOWhUL09jLzNIdnVQQ1BzaERjZ2JDRkR1dmdEQkFPWk5hRS9N?= =?utf-8?B?cmV3U0lDZy9JU1BrVWhnSnJlWmtxUnR1V2VjWVF1VDkvd3BrUmVTaDNuVVFG?= =?utf-8?B?UWFCWHEvVUtzNUtzQmtQaVZyNkhaUU05RGM0cGovWnBVZTRjdTNrMDVnc0ZT?= =?utf-8?B?UDF0YUpmWnNzUldUWmxOU3RjYVBnRzcrTDJ1WjA2L2w5NXVzOThrL1haeVM4?= =?utf-8?B?d253U2pMOUdMZUZBWVpkYTRPSldRbU4rY21CaWdBbDNXcWlQWEtJc2pIN1NE?= =?utf-8?Q?VxHDbJJ4db9tNGp2gs0CWGr6d?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: dbddbfb5-37a3-4e3b-4ef4-08dbc5af13be X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB9079.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2023 14:26:34.6416 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DEByirrE9e0MZpoa5CwObbAq3ujkj5PK717tq/ZJC+oANt89wi0J8DKCokcGejUsyx7VKIdhCe2850kdzOFn8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7370 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 05/10/2023 13:26, Andrew Burgess wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > Lancelot SIX via Gdb-patches writes: > >> Hi Tom, >> >> Thanks for putting this together! As you know, I am in favor of such >> change (for GDB-15 probably, GDB-14 branching is probably too close)! >> >> I do have a really similar patch available on a local branch. One >> difference though is that my branch uses a preparatory patch to upgrade >> gdb/ax_cxx_compile_stdcxx.m4 to follow upstream changes to this file. >> This upgrade gives some improvements in the C++17 compiler detection. >> We keep this in the GDB tree because it has some local changes to set >> CXX_DIALECT. This preparatory patch should be included in this reply. >> >> On Thu, Oct 05, 2023 at 08:54:49AM +0200, Tom de Vries wrote: >>> Since gdb 8.0, we've required a c++11 compiler. >>> >>> That allowed gdb to be compiled with gcc releases as far back as gcc 4.8, >>> using an explicit -std=c++11 to override the default. >>> >>> [ Gcc has the following defaults: >>> - before gcc 6: c++98, and >>> - for gcc 6-10: c++14, and >>> - since gcc 11: c++17. ] >>> >>> There are two arguments in favor of moving to requiring a newer c++ standard: >>> - benefits can be had from using newer c++ features. We're already using some >>> of those features using gdb-specific implementations. >>> - when developing gdb on modern platforms with system compiler gcc >= 6, >>> people can accidentally use c++14/c++17 features in a patch, only to find out >>> post-commit that it breaks the build on a system with a compiler that only >>> supports c++11, which is inconvenient and takes time to fix. >>> [ This could be partially mitigated by if possible also forcing -std=c++11 >>> for such compilers. ] >> >> Thanks for pointing this out, this was one trigger for me to start >> looking into this! >> >>> >>> The need to keep requiring c++11 comes from porting new gdb releases to older >>> systems with older system compilers. >>> >>> A review of some relevant distros has shown that in case that requiring c++17 >>> results in no longer being able to use the system compiler, an alternative, >>> newer compiler that does support c++17 is readily available. >>> >>> With nothing holding back the change, require a c++17 compiler to build gdb. >> >> Just for the record, it might be worth mentioning here the general >> policy of the project regarding bumping the C++ required version: >> https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F >> >>> >>> The gcc documentation ( https://gcc.gnu.org/projects/cxx-status.html ) states >>> that "Some C++17 features are available since GCC 5, but support was >>> experimental and the ABI of C++17 features was not stable until GCC 9". >>> >>> Consequently, the NEWS item mentions gcc 9 as an example compiler to use. >>> >>> My understanding of using gcc 5-8 is that it works as long as gdb doesn't use >>> not yet available language features. Of course the set of used language >>> features may change in time, so what compiler still works may change. >>> >>> Problems can arise when shared libs starts to have C++17 based APIs (or >>> somehow expose instantiations of such classes). If compiled with a compiler >>> in which c++17 support was still experimental, it may be incompatible when >>> linking with: >>> - code compiled with a compiler with non-experimental c++17 support, or >>> - code compiled with a different compiler with experimental c++17 support. >>> >>> Looking at the current implementation of our only shared lib: >>> libinproctrace.so, I couldn't spot any c++ usage in the API, so I'm assuming >>> this problem is not likely to happen. >>> >>> Requiring c++17 means we can drop some code: >>> ... >>> $ find gdb* -type f \ >>> | egrep -v "/configure|\.m4" \ >>> | xargs grep "# *if.*__cplusplus.*2014" >>> gdb/cp-support.c:#if __cplusplus >= 201402L >>> gdb/dwarf2/cooked-index.c:#if __cplusplus >= 201402L >>> gdbsupport/gdb_optional.h:#if defined(_GLIBCXX_DEBUG) && __cplusplus >= 201402L >>> gdbsupport/gdb_optional.h:#if defined(_GLIBCXX_DEBUG) && __cplusplus >= 201402L >>> gdbsupport/gdb_unique_ptr.h:#if __cplusplus >= 201402L >>> gdbsupport/array-view.h:#if defined(_GLIBCXX_DEBUG) && __cplusplus >= 201402L >>> gdbsupport/array-view.h:#if defined(_GLIBCXX_DEBUG) && __cplusplus >= 201402L >>> gdbsupport/array-view.h:#if defined(_GLIBCXX_DEBUG) && __cplusplus >= 201402L >>> $ find gdb* -type f \ >>> | egrep -v "/configure|\.m4" \ >>> | xargs grep "# *if.*__cplusplus.*2017" >>> gdb/unittests/string_view-selftests.c:#if __cplusplus < 201703L >>> gdb/disasm.h:#if __cplusplus >= 201703L >>> gdbsupport/invoke-result.h:#if __cplusplus >= 201703L >>> gdbsupport/gdb_string_view.h:#if __cplusplus >= 201703L >>> ... >>> but that's not yet included in this patch. >> >> If this patch is accepted, one change I'd like is to do is drop >> gdb::make_unique, because 1) the current fallback we have for C++11 >> compilers is not entirely compatible with std::make_unique (the T[] case >> is not supported properly I think), and 2) it is not widely used yet, so >> "it's not too late" :D > > For my own education, is there something which we can write using > gdb::make_unique, which compiles, and does something useful, but which > isn't supported with std::make_unique > > Or something that behaves differently with std::make_unique vs > gdb::make_unique? > > You mention the T[] case isn't supported, but that doesn't feel like > something we might be "too late" for -- that would just mean when we > switch to std::make_unique we can do more... Hi Andrew I don't think something like gdb::make_unique(2) would compile with a c++11 compiler. So I don't expect that a given statement would compile fine in both C++11 and C++17 but with different semantics. The difference can be fixed, we can have a complete implementation with c++11. It is just that the current state of things, gdb::make_unique is not 100% equivalent to std::make_unique. By "not too late", I mean that we currently have ~20 places using gdb::make_unique. It is still easy to replace them all and just use the standard library if available. If we have a standard version, I don't see the point in keeping the gdb:: version. If you take something like gdb::optional for example, it is used quite extensively in the codebase, and I don't think it would be easy to remove the it in favor of the standard C++ version any time soon. We can have gdb::optional be an alias to std::optional, but the codebase will still continue to use "gdb::optional" independently of how this is implemented. I hope that this clarifies my position regarding gdb::make_unique. Best, Lancelot. > > Thanks, > Andrew >