From: Iain Sandoe <iain@sandoe.co.uk>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] X86: Provide a CTOR for stringop_algs [PR100246].
Date: Tue, 6 Jul 2021 11:17:55 +0100 [thread overview]
Message-ID: <2AF05BB0-7510-4B7B-8702-8AE76EC622E6@sandoe.co.uk> (raw)
In-Reply-To: <CAFiYyc0YZ-CWo_z7X-UeV04_-pBBkSvJJZYPoGoN3mvcHK89=g@mail.gmail.com>
> On 5 Jul 2021, at 14:23, Richard Biener <richard.guenther@gmail.com> wrote:
>
> On Mon, Jul 5, 2021 at 3:04 PM Iain Sandoe <iain@sandoe.co.uk> wrote:
>>
>> Hi Richard,
>>
>>> On 5 Jul 2021, at 11:50, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>>
>>> On Sun, Jul 4, 2021 at 10:04 PM Iain Sandoe <iain@sandoe.co.uk> wrote:
>>
>>>> Several older compilers fail to build modern GCC because of missing
>>>> or incomplete C++11 support.
>>>>
>>>> (although the PR mentions clang, specifically, this has also been reported
>>>> for some GCC versions within the range that should be able to bootstrap
>>>> GCC)
>>>>
>>>> There are several possible solutions proposed in the PR, this one seems
>>>> the least invasive.
>>>>
>>>> The header is pulled into the gcov code that builds with C, so we have to
>>>> make the CTOR conditional on C++.
>>>>
>>>> tested on Darwin12 with xcode-6, bootstrapped on x86_64-darwin and linux.
>>>> OK for master / GCC-11?
>>>
>>> Hmm, what is specifically built with a C compiler? gcov.c not, I think.
>>
>> any C compilation that includes tm.h
>>
>> well, libgcc2 fails too on a quick check here - but ISTR there was something in
>> libgcov and I checked with Martin that it was intentionally compiled with C compiler.
>>
>>> Instead of commenting the CTOR, does it work to comment the whole stringop_algs
>>> type?
>>
>> I don’t think that will work because it’s in a header that’s transitively included by tm.h
>> which is then included loads of places.
>>
>>> Also it seems on trunk this CTOR is no more?
>>
>> The addition of the CTOR is the fix for the C++ compile fail in the PR, the conditional is
>> only there because the same header is compiled by C and C++.
>
> Whoops sorry - I was confused. The patch looks OK to me if you add a comment
> before the CTOR why it was added (maybe quoting the error that happens)
Thanks, pushed as below.
Iain
-------
X86: Provide a CTOR for stringop_algs [PR100246].
Several older compilers fail to build modern GCC because of missing
or incomplete C++11 support.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR bootstrap/100246 - [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
PR bootstrap/100246
gcc/ChangeLog:
* config/i386/i386.h (struct stringop_algs): Define a CTOR for
this type.
---
gcc/config/i386/i386.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 6e0340a4b60..03d176143fe 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -73,6 +73,15 @@ struct stringop_algs
{
const enum stringop_alg unknown_size;
const struct stringop_strategy {
+ /* Several older compilers delete the default constructor because of the
+ const entries (see PR100246). Manually specifying a CTOR works around
+ this issue. Since this header is used by code compiled with the C
+ compiler we must guard the addition. */
+#ifdef __cplusplus
+ stringop_strategy(int _max = -1, enum stringop_alg _alg = libcall,
+ int _noalign = false)
+ : max (_max), alg (_alg), noalign (_noalign) {}
+#endif
const int max;
const enum stringop_alg alg;
int noalign;
--
2.24.1
next prev parent reply other threads:[~2021-07-06 10:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-04 20:03 Iain Sandoe
2021-07-05 10:50 ` Richard Biener
2021-07-05 13:04 ` Iain Sandoe
2021-07-05 13:23 ` Richard Biener
2021-07-06 10:17 ` Iain Sandoe [this message]
2021-11-04 10:05 ` [PATCH] x86: Make stringop_algs::stringop_strategy ctor constexpr [PR100246] Jakub Jelinek
2021-11-04 12:39 ` Iain Sandoe
2021-11-04 12:45 ` Jakub Jelinek
2021-11-05 9:58 ` Jakub Jelinek
2021-11-05 10:33 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2AF05BB0-7510-4B7B-8702-8AE76EC622E6@sandoe.co.uk \
--to=iain@sandoe.co.uk \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).