public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Iain Sandoe <iain@sandoe.co.uk>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Uros Bizjak <ubizjak@gmail.com>, Jan Hubicka <jh@suse.cz>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] x86: Make stringop_algs::stringop_strategy ctor constexpr [PR100246]
Date: Thu, 4 Nov 2021 12:39:34 +0000	[thread overview]
Message-ID: <1D4624AF-2516-4834-ACF6-043DE359B3BB@sandoe.co.uk> (raw)
In-Reply-To: <20211104100528.GS304296@tucnak>

Hi Jakub,

> On 4 Nov 2021, at 10:05, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> On Tue, Jul 06, 2021 at 11:17:55AM +0100, Iain Sandoe wrote:
>>>> 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.
> 
> Unfortunately, as mentioned in my
> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583289.html
> mail, without the new dyninit pass this causes dynamic initialization of
> many variables, 6.5KB _GLOBAL__sub_I_* on x86_64 and 12.5KB on i686.
> 
> The following so far only lightly tested patch makes the ctor constexpr
> so that already the FE is able to statically initialize all those.
> 
> I don't have access to Darwin nor to the broken versions of clang, do you
> think you could test bootstrap there with this too?

Bootstrap succeeded with Apple clang-503.0.40 (Xcode 5.1.1) on macOS 10.8
which is the earliest version I expect to work (previous xcode impl. have more
C++11 incompatibilities).   So OK from a Darwin PoV.

The other reported toolchain with the issue was GCC-4.9.2 as discussed on
IRC - this also seems OK.

Iain

> Especially because 11.x is not going to have the dyninit optimization for
> sure, it would be nice to do this on the 11 branch too.
> 
> 2021-11-04  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR bootstrap/100246
> 	* config/i386/i386.h
> 	(stringop_algs::stringop_strategy::stringop_strategy): Make the ctor
> 	constexpr.
> 
> --- gcc/config/i386/i386.h.jj	2021-09-28 23:18:35.282563395 +0200
> +++ gcc/config/i386/i386.h	2021-11-04 10:48:47.165086806 +0100
> @@ -78,8 +78,9 @@ struct stringop_algs
>        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)
> +    constexpr stringop_strategy(int _max = -1,
> +				enum stringop_alg _alg = libcall,
> +				int _noalign = false)
>       : max (_max), alg (_alg), noalign (_noalign) {}
> #endif
>     const int max;
> 
> 	Jakub
> 


  reply	other threads:[~2021-11-04 12:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-04 20:03 [PATCH] X86: Provide a CTOR for stringop_algs [PR100246] 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
2021-11-04 10:05         ` [PATCH] x86: Make stringop_algs::stringop_strategy ctor constexpr [PR100246] Jakub Jelinek
2021-11-04 12:39           ` Iain Sandoe [this message]
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=1D4624AF-2516-4834-ACF6-043DE359B3BB@sandoe.co.uk \
    --to=iain@sandoe.co.uk \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jh@suse.cz \
    --cc=ubizjak@gmail.com \
    /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).