| Message ID | B933DF7C-5188-473C-AC9A-1DD9EBF0E573@sandoe.co.uk |
|---|---|
| State | New |
| Headers | show |
| Series | X86: Provide a CTOR for stringop_algs [PR100246]. | expand |
On Sun, Jul 4, 2021 at 10:04 PM Iain Sandoe <iain@sandoe.co.uk> wrote: > > Hi, > > 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. Instead of commenting the CTOR, does it work to comment the whole stringop_algs type? Also it seems on trunk this CTOR is no more? > thanks > Iain > > 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 | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h > index 6e0340a4b60..84151156999 100644 > --- a/gcc/config/i386/i386.h > +++ b/gcc/config/i386/i386.h > @@ -73,6 +73,11 @@ struct stringop_algs > { > const enum stringop_alg unknown_size; > const struct stringop_strategy { > +#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 > >
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++. thanks Iain > >> thanks >> Iain >> >> 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 | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h >> index 6e0340a4b60..84151156999 100644 >> --- a/gcc/config/i386/i386.h >> +++ b/gcc/config/i386/i386.h >> @@ -73,6 +73,11 @@ struct stringop_algs >> { >> const enum stringop_alg unknown_size; >> const struct stringop_strategy { >> +#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
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) Richard. > thanks > Iain > > > >> thanks > >> Iain > >> > >> 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 | 5 +++++ > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h > >> index 6e0340a4b60..84151156999 100644 > >> --- a/gcc/config/i386/i386.h > >> +++ b/gcc/config/i386/i386.h > >> @@ -73,6 +73,11 @@ struct stringop_algs > >> { > >> const enum stringop_alg unknown_size; > >> const struct stringop_strategy { > >> +#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 >
> 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;
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h index 6e0340a4b60..84151156999 100644 --- a/gcc/config/i386/i386.h +++ b/gcc/config/i386/i386.h @@ -73,6 +73,11 @@ struct stringop_algs { const enum stringop_alg unknown_size; const struct stringop_strategy { +#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;
Hi, 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? thanks Iain 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 | 5 +++++ 1 file changed, 5 insertions(+)