From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id F1B4A3858C5E for ; Mon, 4 Dec 2023 10:42:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F1B4A3858C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F1B4A3858C5E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701686524; cv=none; b=gsk2UPH/z67Qj3coXj/JfgWUKwxpM309Ko5sOsL/W/JCjd24LD0p5iWtW/ldiuL0mgKMGGQc3MDAMNpxargTn//h/gQ9dXyEJVO+QMHIunxeFKIsku9x91x1ekEwsBYAuNjB+0WbVcuiMxdSRaAFMOLFQhFL2lg50XolKoLsGe4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701686524; c=relaxed/simple; bh=DMihAtdRY4Xx12ZN2RH91dsx49dCeqIgyrc8mbBo+Ig=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=b2ZM1AIhZ5l4GFT+V/4bUjV657cQQgrCvmWlwnSmd1OrKJpZqBWiYXhyLwEnDHLmCD+qBa4C9XbLNmTBFBRAvWkaIUkjCPprwd2HuFkZ+3LpmYErBJPWuiGfRExp4304AF1+VsgUE1nxSkBpYustZWUsIo4qW7YqPqKT5/hHMUc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C54A9106F; Mon, 4 Dec 2023 02:42:47 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 138133F6C4; Mon, 4 Dec 2023 02:41:59 -0800 (PST) From: Richard Sandiford To: "Roger Sayle" Mail-Followup-To: "Roger Sayle" ,, richard.sandiford@arm.com Cc: Subject: Re: [PATCH] Workaround array_slice constructor portability issues (with older g++). References: <006601da263f$d455aa30$7d00fe90$@nextmovesoftware.com> Date: Mon, 04 Dec 2023 10:41:58 +0000 In-Reply-To: <006601da263f$d455aa30$7d00fe90$@nextmovesoftware.com> (Roger Sayle's message of "Sun, 3 Dec 2023 23:24:12 -0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-16.2 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: "Roger Sayle" writes: > The recent change to represent language and target attribute tables using > vec.h's array_slice template class triggers an issue/bug in older g++ > compilers, specifically the g++ 4.8.5 system compiler of older RedHat > distributions. This exhibits as the following compilation errors during > bootstrap: > > ../../gcc/gcc/c/c-lang.cc:55:2661: error: could not convert '(const > scoped_attribute_specs* const*)(& c_objc_attribute_table)' from 'const > scoped_attribute_specs* const*' to 'array_slice scoped_attribute_specs* const>' > struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER; > > ../../gcc/gcc/c/c-decl.cc:4657:1: error: could not convert '(const > attribute_spec*)(& std_attributes)' from 'const attribute_spec*' to > 'array_slice' > > Here the issue is with constructors of the from: > > static const int table[] = { 1, 2, 3 }; > array_slice t = table; It's array_slice rather than array_slice. The above would be invalid even with functioning compilers. > Perhaps there's a fix possible in vec.h (an additional constructor?), but > the patch below fixes this issue by using one of array_slice's constructors > (that takes a size) explicitly, rather than rely on template resolution. > In the example above this looks like: > > array_slice t (table, 3); > > or equivalently > > array_slice t = array_slice(table, 3); > > or equivalently > > array_slice t = array_slice(table, ARRAY_SIZE (table)); Taking c-decl.cc as an arbitrary example, it seems to be enough to change: const scoped_attribute_specs std_attribute_table = { nullptr, std_attributes }; to: const scoped_attribute_specs std_attribute_table = { nullptr, { std_attributes } }; which seems less ugly than the explicit constructors. But if we're going to do this, we should do it across the board, not just for x86. I think it's getting a bit ridiculous though. Let's just accept that 4.8.5 is not a fully functioning C++11 compiler and move on. People who are still using that as their host compiler will need to upgrade soon anyway, so we're just putting off the inevitable. It's unlikely that these workarounds that we keep adding will ever fully be removed. Thanks, Richard > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap, > where these changes allow the bootstrap to complete. Ok for mainline? > This fix might not by ideal, but it both draws attention to the problem > and restores bootstrap whilst better approaches are investigated. For > example, an ARRAY_SLICE(table) macro might be appropriate if there isn't > an easy/portable template resolution solution. Thoughts? > > > 2023-12-03 Roger Sayle > > gcc/c-family/ChangeLog > * c-attribs.cc (c_common_gnu_attribute_table): Use an explicit > array_slice constructor with an explicit size argument. > (c_common_format_attribute_table): Likewise. > > gcc/c/ChangeLog > * c-decl.cc (std_attribute_table): Use an explicit > array_slice constructor with an explicit size argument. > * c-objc-common.h (LANG_HOOKS_ATTRIBUTE_TABLE): Likewise. > > gcc/ChangeLog > * config/i386/i386-options.cc (ix86_gnu_attribute_table): Use an > explicit array_slice constructor with an explicit size argument. > * config/i386/i386.cc (TARGET_ATTRIBUTE_TABLE): Likewise. > > gcc/cp/ChangeLog > * cp-objcp-common.h (LANG_HOOKS_ATTRIBUTE_TABLE): Use an > explicit array_slice constructor with an explicit size argument. > * tree.cc (cxx_gnu_attribute_table): Likewise. > (std_attribute_table): Likewise. > > gcc/lto/ChangeLog > * lto-lang.cc (lto_gnu_attribute_table): Use an explicit > array_slice constructor with an explicit size argument. > (lto_format_attribute_table): Likewise. > (LANG_HOOKS_ATTRIBUTE_TABLE): Likewise. > > > Thanks in advance, > Roger > --