"Roger Sayle" <ro...@nextmovesoftware.com> 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<const
> 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<const attribute_spec>'
>
> Here the issue is with constructors of the from:
>
> static const int table[] = { 1, 2, 3 };
> array_slice<int> t = table;
It's array_slice<const int> rather than array_slice<int>. 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<int> t (table, 3);
>
> or equivalently
>
> array_slice<int> t = array_slice<int>(table, 3);
>
> or equivalently
>
> array_slice<int> t = array_slice<int>(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 <ro...@nextmovesoftware.com>
>
> 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
> --
