public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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



  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).