Re: [x86 PATCH] Tweak i386-expand.cc to restore bootstrap on RHEL.

On Sun, Jul 14, 2024 at 3:42 PM Roger Sayle wrote: > > > This is a minor change to restore bootstrap on systems using gcc 4.8 > as a host compiler. The fatal error is: > > In file included from gcc/gcc/coretypes.h:471:0, > from gcc/gcc/config/i386/i386-ex

[x86 PATCH] Tweak i386-expand.cc to restore bootstrap on RHEL.

This is a minor change to restore bootstrap on systems using gcc 4.8 as a host compiler. The fatal error is: In file included from gcc/gcc/coretypes.h:471:0, from gcc/gcc/config/i386/i386-expand.cc:23: gcc/gcc/config/i386/i386-expand.cc: In function 'void

Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.

On 14/06/24 11:42 +0100, Jonathan Wakely wrote: On 14/06/24 11:37 +0100, Jonathan Wakely wrote: On 14/06/24 11:26 +0100, Jonathan Wakely wrote: On 14/06/24 10:36 +0100, Jonathan Wakely wrote: On 07/06/24 19:40 +0100, Roger Sayle wrote: This patch restores bootstrap when using g++ 4.8 as a

Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.

On 14/06/24 11:37 +0100, Jonathan Wakely wrote: On 14/06/24 11:26 +0100, Jonathan Wakely wrote: On 14/06/24 10:36 +0100, Jonathan Wakely wrote: On 07/06/24 19:40 +0100, Roger Sayle wrote: This patch restores bootstrap when using g++ 4.8 as a host compiler. Returning a std::unique_ptr

Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.

On 14/06/24 11:26 +0100, Jonathan Wakely wrote: On 14/06/24 10:36 +0100, Jonathan Wakely wrote: On 07/06/24 19:40 +0100, Roger Sayle wrote: This patch restores bootstrap when using g++ 4.8 as a host compiler. Returning a std::unique_ptr requires a std::move on C++ compilers (pre-C++17) that

Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.

On 14/06/24 10:36 +0100, Jonathan Wakely wrote: On 07/06/24 19:40 +0100, Roger Sayle wrote: This patch restores bootstrap when using g++ 4.8 as a host compiler. Returning a std::unique_ptr requires a std::move on C++ compilers (pre-C++17) that don't guarantee copy elision/return value

Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.

On 07/06/24 19:40 +0100, Roger Sayle wrote: This patch restores bootstrap when using g++ 4.8 as a host compiler. Returning a std::unique_ptr requires a std::move on C++ compilers (pre-C++17) that don't guarantee copy elision/return value optimization. It doesn't though. The C++17 guaranteed

Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.

On Fri, 2024-06-07 at 19:40 +0100, Roger Sayle wrote: > > This patch restores bootstrap when using g++ 4.8 as a host compiler. > Returning a std::unique_ptr requires a std::move on C++ compilers > (pre-C++17) that don't guarantee copy elision/return value > optimization. > > Bootstrapped on

[analyzer PATCH] Restore bootstrap with g++ 4.8.

This patch restores bootstrap when using g++ 4.8 as a host compiler. Returning a std::unique_ptr requires a std::move on C++ compilers (pre-C++17) that don't guarantee copy elision/return value optimization. Bootstrapped on x86_64-pc-linux-gnu using both gcc 4.8.5 (system) and gcc 10.2.1 (using

Re: [PATCH] m68k: restore bootstrap

On Sun, 2024-02-18 at 08:42 -0700, Jeff Law wrote: > > On 2/18/24 02:18, Mikael Pettersson wrote: > > m68k fails to bootstrap since -ffold-mem-offsets was introduced, > > in what looks like wrong-code during stage2. > > > > To restore bootstrap this disables -ffold

Re: [PATCH] m68k: restore bootstrap

On 2/18/24 02:18, Mikael Pettersson wrote: m68k fails to bootstrap since -ffold-mem-offsets was introduced, in what looks like wrong-code during stage2. To restore bootstrap this disables -ffold-mem-offsets on m68k. It's not ideal, but better than keeping bootstraps broken until the root

[PATCH] m68k: restore bootstrap

m68k fails to bootstrap since -ffold-mem-offsets was introduced, in what looks like wrong-code during stage2. To restore bootstrap this disables -ffold-mem-offsets on m68k. It's not ideal, but better than keeping bootstraps broken until the root cause is debugged and fixed. Tested

[committed] Restore bootstrap by removing unused variable in tree-ssa-loop-ivcanon.cc

Hi, This restores bootstrap by removing the variable causing: /home/mjambor/gcc/trunk/src/gcc/tree-ssa-loop-ivcanon.cc: In function ‘bool try_peel_loop(loop*, edge, tree, bool, long int)’: /home/mjambor/gcc/trunk/src/gcc/tree-ssa-loop-ivcanon.cc:1170:17: error: variable ‘entry_count’ set

Re: [PATCH] Restore bootstrap on x86_64-pc-linux-gnu

strap the compiler. > > > 2022-02-22 Roger Sayle > > > > gcc/ChangeLog > > * config/i386/i386-expand.cc (ix86_expand_cmpxchg_loop): Restore > > bootstrap. OK. Thanks, Uros. > > > > Cheers, > > Roger > > -- > > >

[PATCH] Restore bootstrap on x86_64-pc-linux-gnu

This patch resolves the bootstrap failure on x86_64-pc-linux-gnu. Is this sufficiently "obvious" in stage4, or should I wait for the bootstrap and regression testing to complete? 2022-02-22 Roger Sayle gcc/ChangeLog * config/i386/i386-expand.cc (ix86_expand_cmpxchg_loop

Re: [PATCH] powerpc: Restore bootstrap for PPC Darwin.

Hi! On Wed, Jun 24, 2020 at 04:15:53PM +0100, Iain Sandoe wrote: > Darwin has signed chars and the fields in the insn_data > struct are const char, which leads to a bootstrap fail with > > "error: comparison of integer expressions of different signedness: 'unsigned > int' and 'const char'

[PATCH] powerpc: Restore bootstrap for PPC Darwin.

Hi, Darwin has signed chars and the fields in the insn_data struct are const char, which leads to a bootstrap fail with "error: comparison of integer expressions of different signedness: 'unsigned int' and 'const char' [-Werror=sign-compare]” OK for master? Iain gcc/ChangeLog: *

Re: [PATCH, alpha, go]: Remove PtraceRegs definition to restore bootstrap

On Mon, Jun 26, 2017 at 12:24 AM, Uros Bizjak wrote: > > libgo is now able to automatically determine PtraceRegs. Attached > patch removes duplicate manual definition from system dependent > source. > > Bootstrapped and regression tested on alphaev68-linux-gnu. Thanks.

[PATCH, alpha, go]: Remove PtraceRegs definition to restore bootstrap

Hello! libgo is now able to automatically determine PtraceRegs. Attached patch removes duplicate manual definition from system dependent source. Bootstrapped and regression tested on alphaev68-linux-gnu. Uros. Index: go/syscall/syscall_linux_alpha.go

[patch, libfortran, committed] Restore bootstrap on non-x86* systems

Hello world, I have committed the attached patch as obvious as r248519 after testing that it does indeed work on powerpc64-unknown-linux-gnu and that it passes regression-test on that machine. Sorry for the breakage. I'll use the gcc compile farm machines in the future to test any such changes.

[PATCH] Restore bootstrap

Committed as obvious. 2016-09-23 Richard Biener * hooks.h (hook_uint_uintp_false): Declare. Index: gcc/hooks.h === --- gcc/hooks.h (revision 240386) +++ gcc/hooks.h (working copy) @@ -76,6 +76,7 @@

Re: [PATCH]: Restore bootstrap with gcc < 4.3

On Mon, Jun 13, 2016 at 11:23 AM, Uros Bizjak wrote: > Hello! > > The new test finalization self tests fail wigh gcc < 4.3 due to the > way need_finalization_p is defined: > > template > static inline bool > need_finalization_p () > { > #if GCC_VERSION >= 4003 > return

[PATCH]: Restore bootstrap with gcc < 4.3

Hello! The new test finalization self tests fail wigh gcc < 4.3 due to the way need_finalization_p is defined: template static inline bool need_finalization_p () { #if GCC_VERSION >= 4003 return !__has_trivial_destructor (T); #else return true; #endif } It is obvious that checking for

[Committed] Restore bootstrap for ARM

All, I committed the below as obvious. Andreas 2015-05-04 Andreas Tobler andre...@gcc.gnu.org * config/arm/arm.c: Restore bootstrap. Index: config/arm/arm.c === --- config/arm/arm.c(revision 222767) +++ config/arm

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Mar 8, 2015, at 10:38 AM, Iain Sandoe i...@codesourcery.com wrote: +Ian + ping So, all the darwinness of the patch looks fine to me. One maintainer down, just need libiberty approval. If the work becomes too bothersome, the comment out the line and say, # does’t work with libcc1 approach

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

+Ian + ping On 11 Feb 2015, at 14:37, Iain Sandoe wrote: Hi Jeff, On 9 Feb 2015, at 14:47, Jeff Law l...@redhat.com wrote: On 02/01/15 09:42, Iain Sandoe wrote: This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a PR if that is considered necessary). Has this

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

Iain Sandoe i...@codesourcery.com writes: +Ian + ping The patch is missing the change to maint-tool to generate the rules at the bottom of libiberty/Makefile.in. Right now the libiberty Makefile does not require GNU make, and it's not clear to me that we want to push that dependency onto all

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

Hi Jeff, On 9 Feb 2015, at 14:47, Jeff Law l...@redhat.com wrote: On 02/01/15 09:42, Iain Sandoe wrote: This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a PR if that is considered necessary). Has this been addressed or is it still pending? I believe it's still

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 02/01/15 09:42, Iain Sandoe wrote: This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a PR if that is considered necessary). Has this been addressed or is it still pending? In fact it is not libcc1, but libiberty that is the cause - On 26 Jan 2015, at 14:13,

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a PR if that is considered necessary). In fact it is not libcc1, but libiberty that is the cause - On 26 Jan 2015, at 14:13, Rainer Orth wrote: FX fxcoud...@gmail.com writes: The default BOOT_CFLAGS are: -O2 -g

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

FX fxcoud...@gmail.com writes: The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] This means that the PIC library is being built with non-pic

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 26 Jan 2015, at 14:13, Rainer Orth wrote: FX fxcoud...@gmail.com writes: The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] This means that

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 05/12/2014 23:47, Jakub Jelinek wrote: On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too, then perhaps: ... Sorry but it does not work: Sorry, make that (just removed 4x

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

This was for x86_64-apple-darwin14. The patch also works for x86_64-apple-darwin10. Dominique Le 6 déc. 2014 à 01:49, Dominique d'Humières domi...@lps.ens.fr a écrit : Bootstrap just finished with the patch. Thanks, Dominique

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

Hi Jeff, On 5 Dec 2014, at 22:40, Jeff Law wrote: On 12/05/14 15:34, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too, then perhaps: ... Sorry but it does not work: BTW, thanks for working with Jakub on this. We're

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Mon, Nov 24, 2014 at 01:06:45AM +0100, FX wrote: tl;dr: One question to build maintainers, and one patch submitted to toplevel configure.ac --- I’m looked into the issue some more, and am comparing two builds of trunk (exact same source), one configured with system

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

... Can you please test it on Darwin (or whatever other target has similar issues with bootstrapping libcc1)? 2014-12-05 Jakub Jelinek ja...@redhat.com ... The patch does not work for x86_64-apple-darwin14.0.0. However the following patch does: --- ../_clean/Makefile.in 2014-11-26

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Fri, Dec 05, 2014 at 08:11:53PM +0100, Dominique Dhumieres wrote: ... Can you please test it on Darwin (or whatever other target has similar issues with bootstrapping libcc1)? 2014-12-05 Jakub Jelinek ja...@redhat.com ... The patch does not work for x86_64-apple-darwin14.0.0.

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too, then perhaps: ... Sorry but it does not work: true DO=all multi-do # make make[4]: Leaving directory '/opt/gcc/build_w/libbacktrace' make[3]: Leaving directory '/opt/gcc/build_w/libbacktrace'

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 12/05/14 15:34, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too, then perhaps: ... Sorry but it does not work: BTW, thanks for working with Jakub on this. We're going to be getting a Darwin box for Jakub and other

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 05/12/14 22:40, Jeff Law wrote: On 12/05/14 15:34, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too, then perhaps: ... Sorry but it does not work: BTW, thanks for working with Jakub on this. We're going to be

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too, then perhaps: ... Sorry but it does not work: Sorry, make that (just removed 4x ' in each file): 2014-12-05 Jakub Jelinek

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

Bootstrap just finished with the patch. Thanks, Dominique Le 5 déc. 2014 à 23:47, Jakub Jelinek ja...@redhat.com a écrit : On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too,

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

10-days ping This restores bootstrap on a secondary target, target maintainer is OK with it. I think I need build maintainers approval, so please review. when the freshly built g++ is used, we need to pass the appropriate -B options. As I understand it, the appropriate place for that is in

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

FX fxcoud...@gmail.com writes: 10-days ping This restores bootstrap on a secondary target, target maintainer is OK with it. I think I need build maintainers approval, so please review. While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0) now bootstraps, but 32-bit

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0) now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not: Is it due to my patch, or pre-existing bootstrap failure? How do you configure this 32-bit compiler? target/build/host/CFLAGS/CXXFLAGS/etc FX

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

Hi Rainer, On 4 Dec 2014, at 13:32, Rainer Orth wrote: FX fxcoud...@gmail.com writes: 10-days ping This restores bootstrap on a secondary target, target maintainer is OK with it. I think I need build maintainers approval, so please review. While in my testing, 64-bit Mac OS X 10.10.1

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

FX fxcoud...@gmail.com writes: While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0) now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not: Is it due to my patch, or pre-existing bootstrap failure? I can't tell: before your patch, 32-bit bootstrap was broken due to

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Thu, Dec 4, 2014 at 2:47 PM, Richard Biener richard.guent...@gmail.com wrote: On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe i...@codesourcery.com wrote: Hi Rainer, On 4 Dec 2014, at 13:32, Rainer Orth wrote: FX fxcoud...@gmail.com writes: 10-days ping This restores bootstrap on a

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Thu, Dec 4, 2014 at 2:48 PM, Richard Biener richard.guent...@gmail.com wrote: On Thu, Dec 4, 2014 at 2:47 PM, Richard Biener richard.guent...@gmail.com wrote: On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe i...@codesourcery.com wrote: Hi Rainer, On 4 Dec 2014, at 13:32, Rainer Orth wrote:

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] This means that the PIC library is being built with non-pic relocs. config/mh-darwin says that

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Thu, Dec 4, 2014 at 2:52 PM, FX fxcoud...@gmail.com wrote: The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] This means that the PIC library is

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe i...@codesourcery.com wrote: Hi Rainer, On 4 Dec 2014, at 13:32, Rainer Orth wrote: FX fxcoud...@gmail.com writes: 10-days ping This restores bootstrap on a secondary target, target maintainer is OK with it. I think I need build maintainers

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

Can you try adding it as T_CFLAGS += -mdynamic-no-pic in gcc/config/t-tarwin instead? Nope, doing so fails to link libgcc_s.dylib: /Users/fx/devel/gcc/i/./gcc/xgcc -B/Users/fx/devel/gcc/i/./gcc/ -B/Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/bin/

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 4 Dec 2014, at 15:24, FX wrote: Can you try adding it as T_CFLAGS += -mdynamic-no-pic in gcc/config/t-tarwin instead? -mdynamic-no-pic should be used to build *host* executable stuff for m32 darwin. It is not suitable for building shared libraries (hence the problem with building

Re: [patch] Restore bootstrap on powerpc*-apple-darwin*

2014-11-24 Rohit rohitarul...@freescale.com PR bootstrap/63703 * config/rs6000/darwin.h (REGISTER_NAMES): Update based on 32 newly added GCC hard register numbers for SPE high registers. IMO, it's obvious, and as you say, doesn't touch any other target. After further

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On Nov 23, 2014, at 4:06 PM, FX fxcoud...@gmail.com wrote: One question to build maintainers, and one patch submitted to top-level configure.ac So, not sure who wants to review this. From the darwin perspective, Ok.

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 25/11/14 20:37, Mike Stump wrote: On Nov 23, 2014, at 4:06 PM, FX fxcoud...@gmail.com wrote: One question to build maintainers, and one patch submitted to top-level configure.ac So, not sure who wants to review this. From the darwin perspective, Ok. I mean from my limited viewpoint it

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 11/25/14 13:57, Phil Muldoon wrote: On 25/11/14 20:37, Mike Stump wrote: On Nov 23, 2014, at 4:06 PM, FX fxcoud...@gmail.com wrote: One question to build maintainers, and one patch submitted to top-level configure.ac So, not sure who wants to review this. From the darwin perspective,

[patch] Restore bootstrap on powerpc*-apple-darwin*

Bootstrap is currently broken on ppc-darwin due to PR63703 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703). This is also broken on 4.9, and actually made it into the 4.9.2 release. This patch fixes it, restores bootstrap (well, it gets cc1 to build, at least… I don’t have a ppc to test the

Re: [patch] Restore bootstrap on powerpc*-apple-darwin*

On 24 Nov 2014, at 17:02, FX wrote: Bootstrap is currently broken on ppc-darwin due to PR63703 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703). This is also broken on 4.9, and actually made it into the 4.9.2 release. This patch fixes it, restores bootstrap (well, it gets cc1 to

[patch, build] Restore bootstrap in building libcc1 on darwin

tl;dr: One question to build maintainers, and one patch submitted to toplevel configure.ac --- I’m looked into the issue some more, and am comparing two builds of trunk (exact same source), one configured with system compiler (clang) in PATH, the other with GCC 4.9.2 in PATH. At

Re: [PATCH, go]: Restore bootstrap

On 07/28/2014 05:24 PM, Mike Stump wrote: On Jul 28, 2014, at 3:29 AM, Gerald Pfeifer ger...@pfeifer.com wrote: On Fri, 25 Jul 2014, Martin Liška wrote: Yes, --enable-languages=all is the default, so it only builds the frontends that are enabled by default, so it does not build the Go or Ada

Re: [PATCH, go]: Restore bootstrap

On Jul 29, 2014, at 2:10 AM, Martin Liška mli...@suse.cz wrote: I am not a configure script guru, but what do you think about suggested patch? Looks exactly like what I would do.

Re: [PATCH, go]: Restore bootstrap

On 07/29/2014 07:01 PM, Mike Stump wrote: On Jul 29, 2014, at 2:10 AM, Martin Liška mli...@suse.cz wrote: I am not a configure script guru, but what do you think about suggested patch? Looks exactly like what I would do. All right, I'll send the patch, as well as documentation

Re: [PATCH, go]: Restore bootstrap

On Fri, 25 Jul 2014, Martin Liška wrote: Yes, --enable-languages=all is the default, so it only builds the frontends that are enabled by default, so it does not build the Go or Ada frontends. I know it doesn't make much sense. I would suggest to replace currently used 'all' to 'default'. And

Re: [PATCH, go]: Restore bootstrap

On Jul 28, 2014, at 3:29 AM, Gerald Pfeifer ger...@pfeifer.com wrote: On Fri, 25 Jul 2014, Martin Liška wrote: Yes, --enable-languages=all is the default, so it only builds the frontends that are enabled by default, so it does not build the Go or Ada frontends. I know it doesn't make much

Re: [PATCH, go]: Restore bootstrap

On 07/25/2014 03:51 AM, Ian Lance Taylor wrote: On Thu, Jul 24, 2014 at 12:21 PM, Martin Liška mli...@suse.cz wrote: On 07/24/2014 07:57 PM, Uros Bizjak wrote: Hello! 2014-07-24 Uros Bizjak ubiz...@gmail.com * go/go-gcc.cc (Gcc_backend::global_variable_set_init): Rename

[PATCH, go]: Restore bootstrap

Hello! 2014-07-24 Uros Bizjak ubiz...@gmail.com * go/go-gcc.cc (Gcc_backend::global_variable_set_init): Rename symtab_get_node to symtab_node::get. Tested on x86_64-linux-gnu and committed to mainline SVN. Uros. Index: go-gcc.cc

Re: [PATCH, go]: Restore bootstrap

On 07/24/2014 07:57 PM, Uros Bizjak wrote: Hello! 2014-07-24 Uros Bizjak ubiz...@gmail.com * go/go-gcc.cc (Gcc_backend::global_variable_set_init): Rename symtab_get_node to symtab_node::get. Tested on x86_64-linux-gnu and committed to mainline SVN. Uros. Hello, thank you for

Re: [PATCH, go]: Restore bootstrap

On Thu, Jul 24, 2014 at 12:21 PM, Martin Liška mli...@suse.cz wrote: On 07/24/2014 07:57 PM, Uros Bizjak wrote: Hello! 2014-07-24 Uros Bizjak ubiz...@gmail.com * go/go-gcc.cc (Gcc_backend::global_variable_set_init): Rename symtab_get_node to symtab_node::get. Tested on

[PATCH] Restore bootstrap (PR61757)

The following patch partially reverts r212352 to restore bootstrap on i585-linux (where I reproduced and verified the fix). It makes phicprop honor that loop-depth condition again which doing not seems to cause a latent bug to pop up which miscompiles the stage2 compiler which in turn

[PATCH][match-and-simplify] Restore bootstrap

We've accumulated some warnings - fixed below. Richard. 2014-06-26 Richard Biener rguent...@suse.de * genmatch.c (c_expr::gen_transform): Fix unused parameter. (dt_simplify::gen_gimple): Mark captures as possibly unused. (dt_simplify::gen_generic): Likewise.

[PATCH][match-and-simplify] Restore bootstrap somewhat

The following patche is necessary to get to stage2 target library building. Bootstrapped until that point, applied. Richard. 2014-06-04 Richard Biener rguent...@suse.de * genmatch.c (error_cb, fatal_at): Annotate with printf format attribute to silence warning. *

Restore bootstrap

The obvious fix. commit 36d5e6eace0697b2f8613ab5c24bc23ea359d347 Author: law law@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Oct 24 00:43:24 2012 + * tree-ssa-threadedge.c (thread_across_edge): Remove unused parameter in call to cond_arg_set_in_bb.

Restore bootstrap on IA-64/Linux

An unused variable left in except.c after Easwaran's recent patch. Tested on ia64-suse-linux, applied on the mainline as obvious. 2012-10-18 Eric Botcazou ebotca...@adacore.com * except.c (sjlj_emit_function_enter): Remove unused variable. -- Eric BotcazouIndex: except.c

Re: Restore bootstrap (PR53197)

On May 2, 2012, Michael Matz m...@suse.de wrote: my gimple_seq reshuffling broke boostrap on some machines. In particular on those for which contrib/compare-debug works, meaning that bootstrap-debug is selected as default BUILD_CONFIG (none of my machines pass the respective configure.ac

Restore bootstrap (PR53197)

Hi, my gimple_seq reshuffling broke boostrap on some machines. In particular on those for which contrib/compare-debug works, meaning that bootstrap-debug is selected as default BUILD_CONFIG (none of my machines pass the respective configure.ac test, and hence I wasn't seeing the problem

Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx

On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote: On Tue, May 17, 2011 at 2:46 PM, Toon Moenet...@moene.org wrote: On 05/17/2011 08:32 PM, Uros Bizjak wrote: Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx. Committed to mainline SVN as obvious. Does that mean that I can

Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx

On Wed, May 18, 2011 at 10:17 PM, Toon Moene t...@moene.org wrote: On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote: On Tue, May 17, 2011 at 2:46 PM, Toon Moenet...@moene.org  wrote: On 05/17/2011 08:32 PM, Uros Bizjak wrote: Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.

Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx

On 05/18/2011 10:31 PM, Richard Guenther wrote: Not that I'm too excited to see GCC built with a C++ compiler (or even C++ features being used). Hmmm, you think using false as a value for a pointer-returning function is just A-OK ? Duh, I'm glad I'm using Fortran, where the programmer

Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx

On Wed, May 18, 2011 at 10:44 PM, Toon Moene t...@moene.org wrote: On 05/18/2011 10:31 PM, Richard Guenther wrote: Not that I'm too excited to see GCC built with a C++ compiler (or even C++ features being used). Hmmm, you think using false as a value for a pointer-returning function is just

[PATCH]: Restore bootstrap with --enable-build-with-cxx

Hello! 2011-05-17 Uros Bizjak ubiz...@gmail.com * ipa-inline-analysis.c (inline_node_duplication_hook): Initialize info-entry with 0 * tree-inline.c (maybe_inline_call_in_expr): Initialize id.transform_lang_insert_block with NULL. Tested on x86_64-pc-linux-gnu

Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx

On 05/17/2011 08:32 PM, Uros Bizjak wrote: Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx. Committed to mainline SVN as obvious. Does that mean that I can now remove the --disable-werror from my daily C++ bootstrap run ? It's great that some people understand the

Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx

On Tue, May 17, 2011 at 2:46 PM, Toon Moene t...@moene.org wrote: On 05/17/2011 08:32 PM, Uros Bizjak wrote: Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx. Committed to mainline SVN as obvious. Does that mean that I can now remove the --disable-werror from my daily C++

Re: restore bootstrap with a C++ compiler

Gabriel Dos Reis g...@cs.tamu.edu writes: Andrew Pinski pins...@gmail.com writes: | On Wed, Apr 27, 2011 at 6:48 PM, Gabriel Dos Reis g...@cs.tamu.edu wrote: | A local `extern' declaration does not give the entity an external linkage | -- irrespective of the linkage of the function

Re: restore bootstrap with a C++ compiler

Richard Sandiford richard.sandif...@linaro.org writes: | Gabriel Dos Reis g...@cs.tamu.edu writes: | Andrew Pinski pins...@gmail.com writes: | | | On Wed, Apr 27, 2011 at 6:48 PM, Gabriel Dos Reis g...@cs.tamu.edu wrote: | | A local `extern' declaration does not give the entity an external

Re: restore bootstrap with a C++ compiler

Gabriel Dos Reis g...@cs.tamu.edu writes: | FWIW, I prefer Andrew's patch, but since yours has been applied, | I suppose there's no point changing it. when we come to agree on coding style guidelines for GCC in C++, I hope we recommend against local extern declarations. Oh, for pure C++, I

Re: restore bootstrap with a C++ compiler

Richard Sandiford richard.sandif...@linaro.org writes: | Gabriel Dos Reis g...@cs.tamu.edu writes: | | FWIW, I prefer Andrew's patch, but since yours has been applied, | | I suppose there's no point changing it. | | when we come to agree on coding style guidelines for GCC in C++, I hope we |

restore bootstrap with a C++ compiler

Richard, Your recent patch broke --enable-build-with-cxx because internal-fn.h was using good 'ol C-style name lookup trick that behaves badly with C++ linkage rules. Fixed thusly. Applied as obvious. -- Gaby 2011-04-27 Gabriel Dos Reis g...@integrable-solutions.net *

Re: restore bootstrap with a C++ compiler

Andrew Pinski pins...@gmail.com writes: | On Wed, Apr 27, 2011 at 6:30 PM, Gabriel Dos Reis g...@cs.tamu.edu wrote: | | Richard, | | Your recent patch broke --enable-build-with-cxx because internal-fn.h | was using good 'ol C-style name lookup trick that behaves badly with | C++ linkage

Re: restore bootstrap with a C++ compiler

On Wed, Apr 27, 2011 at 6:48 PM, Gabriel Dos Reis g...@cs.tamu.edu wrote: A local `extern' declaration does not give the entity an external linkage -- irrespective of the linkage of the function enclosing the declaration. It just makes the name locally available for name lookup purpose.   A

Re: restore bootstrap with a C++ compiler

Andrew Pinski pins...@gmail.com writes: | On Wed, Apr 27, 2011 at 6:48 PM, Gabriel Dos Reis g...@cs.tamu.edu wrote: | A local `extern' declaration does not give the entity an external linkage | -- irrespective of the linkage of the function enclosing the declaration. | It just makes the name