> On 14 Jan 2025, at 20:45, Iain Buclaw wrote:
>
> Excerpts from Iain Sandoe's message of Januar 14, 2025 9:10 pm:
>> Tested on x86_64, i686 darwin17 and aarch64 darwin21,
>> OK for trunk, or alternate solution?
>> thanks,
>> Iain
>>
> Could a pull request be made upstream here?
>
> https:/
Excerpts from Iain Sandoe's message of Januar 14, 2025 9:10 pm:
> Tested on x86_64, i686 darwin17 and aarch64 darwin21,
> OK for trunk, or alternate solution?
> thanks,
> Iain
>
Thank Iain,
Could a pull request be made upstream here?
https://github.com/dlang/dmd/pulls
Location of this module i
Tested on x86_64, i686 darwin17 and aarch64 darwin21,
OK for trunk, or alternate solution?
thanks,
Iain
--- 8< ---
Recent merges from libphobos have broken bootstrap on many/most Darwin
version (those with 32bit multilibs, 32bit hosts, aarch64 and powerpc).
This is because the thread data are no
On Thu, Aug 8, 2024 at 10:28 AM Roger Sayle wrote:
>
>
> This minor patch, very similar to one posted and approved previously at
> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657229.html is
> required to restore builds on systems using gcc 4.8 as a host compiler.
> Using the enumeration co
This minor patch, very similar to one posted and approved previously at
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657229.html is
required to restore builds on systems using gcc 4.8 as a host compiler.
Using the enumeration constants E_SFmode and E_DFmode avoids issues with
SFmode and DFm
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
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 '
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 ho
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 requires
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 do
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 optimizat
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 c
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 x86_6
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 "
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
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
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 w
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 bu
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
>
> --
>
>
>
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
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' [-Werr
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:
* confi
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.
Committed to mainline.
Ia
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
=
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.
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 @@ extern void hook_void_
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 !__has_trivial_destructor
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
AS
All,
I committed the below as obvious.
Andreas
2015-05-04 Andreas Tobler
* config/arm/arm.c: Restore bootstrap.
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 222767)
+++ config/arm/arm.c(working
On Mar 8, 2015, at 10:38 AM, Iain Sandoe 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 for the config frag
Iain Sandoe 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 projects that
use li
+Ian
+ ping
On 11 Feb 2015, at 14:37, Iain Sandoe wrote:
> Hi Jeff,
>
> On 9 Feb 2015, at 14:47, Jeff Law 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 b
Hi Jeff,
On 9 Feb 2015, at 14:47, Jeff Law 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 awaiting rev
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, Rainer
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 writes:
>
>>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
>>>
On 26 Jan 2015, at 14:13, Rainer Orth wrote:
> FX 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
FX 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 relocs.
>
> config
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 (j
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 a écrit :
>
> Bootstrap just finished with the patch.
>
> Thanks,
>
> Dominique
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 o
Bootstrap just finished with the patch.
Thanks,
Dominique
> Le 5 déc. 2014 à 23:47, Jakub Jelinek 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, then perh
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
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 goi
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 fo
> 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'
ma
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
> > ...
>
> The patch does not work for x86_64-apple-darwin14.0.0. Howe
> ...
> Can you please test it on Darwin (or whatever other target has similar
> issues with bootstrapping libcc1)?
>
> 2014-12-05 Jakub Jelinek
> ...
The patch does not work for x86_64-apple-darwin14.0.0. However the following
patch does:
--- ../_clean/Makefile.in 2014-11-26 23:09:14.0
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
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
> 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/
-B/Users/fx/devel/gcc/i2/i386-appl
On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
> Hi Rainer,
>
> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>
>> FX 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.
On Thu, Dec 4, 2014 at 2:52 PM, FX 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 being built
> 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 tha
On Thu, Dec 4, 2014 at 2:48 PM, Richard Biener
wrote:
> On Thu, Dec 4, 2014 at 2:47 PM, Richard Biener
> wrote:
>> On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
>>> Hi Rainer,
>>>
>>> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>>>
FX writes:
> 10-days ping
> This restore
On Thu, Dec 4, 2014 at 2:47 PM, Richard Biener
wrote:
> On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
>> Hi Rainer,
>>
>> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>>
>>> FX writes:
>>>
10-days ping
This restores bootstrap on a secondary target, target maintainer is OK with
FX 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 PR
bootstrap/
Hi Rainer,
On 4 Dec 2014, at 13:32, Rainer Orth wrote:
> FX 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-appl
> 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
FX 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 (i386-apple-darwin14.0.0)
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
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 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 l
On 25/11/14 20:37, Mike Stump wrote:
> On Nov 23, 2014, at 4:06 PM, FX 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 looks fine. As
On Nov 23, 2014, at 4:06 PM, FX 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.
>> 2014-11-24 Rohit
>>
>> 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 confirmations
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 b
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
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 th
On 07/29/2014 07:01 PM, Mike Stump wrote:
On Jul 29, 2014, at 2:10 AM, Martin Liška 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 enhancement, to
a separat
On Jul 29, 2014, at 2:10 AM, Martin Liška wrote:
> I am not a configure script guru, but what do you think about suggested
> patch?
Looks exactly like what I would do.
On 07/28/2014 05:24 PM, Mike Stump wrote:
On Jul 28, 2014, at 3:29 AM, Gerald Pfeifer 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
On Jul 28, 2014, at 3:29 AM, Gerald Pfeifer 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 sense.
>> I
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'
On 07/25/2014 03:51 AM, Ian Lance Taylor wrote:
On Thu, Jul 24, 2014 at 12:21 PM, Martin Liška wrote:
On 07/24/2014 07:57 PM, Uros Bizjak wrote:
Hello!
2014-07-24 Uros Bizjak
* go/go-gcc.cc (Gcc_backend::global_variable_set_init): Rename
symtab_get_node to symtab_node::get.
On Thu, Jul 24, 2014 at 12:21 PM, Martin Liška wrote:
> On 07/24/2014 07:57 PM, Uros Bizjak wrote:
>>
>> Hello!
>>
>> 2014-07-24 Uros Bizjak
>>
>> * go/go-gcc.cc (Gcc_backend::global_variable_set_init): Rename
>> symtab_get_node to symtab_node::get.
>>
>> Tested on x86_64-linux-gnu an
On 07/24/2014 07:57 PM, Uros Bizjak wrote:
Hello!
2014-07-24 Uros Bizjak
* 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 your fix. As I se
Hello!
2014-07-24 Uros Bizjak
* 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
===
--- g
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
We've accumulated some warnings - fixed below.
Richard.
2014-06-26 Richard Biener
* genmatch.c (c_expr::gen_transform): Fix unused parameter.
(dt_simplify::gen_gimple): Mark captures as possibly unused.
(dt_simplify::gen_generic): Likewise.
(decision_tree::gen
The following patche is necessary to get to stage2 target library
building.
Bootstrapped until that point, applied.
Richard.
2014-06-04 Richard Biener
* genmatch.c (error_cb, fatal_at): Annotate with printf
format attribute to silence warning.
* gimple-match-head.c (
The obvious fix.
commit 36d5e6eace0697b2f8613ab5c24bc23ea359d347
Author: law
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.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk
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
* except.c (sjlj_emit_function_enter): Remove unused variable.
--
Eric BotcazouIndex: except.c
===
On May 2, 2012, Michael Matz 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 test, an
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 anywh
Hello!
2011-11-11 Uros Bizjak
* config/alpha/elf.h (ELF_ASCII_ESCAPES): Rename from ESCAPES.
(ELF_STRING_LIMIT): Rename from STRING_LIMIT.
Tested on alphaev68-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: elf.h
=
On Wed, May 18, 2011 at 10:44 PM, Toon Moene 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 A-O
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 isn
On Wed, May 18, 2011 at 10:17 PM, Toon Moene wrote:
> On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:
>
>> On Tue, May 17, 2011 at 2:46 PM, Toon Moene wrote:
>
>>> On 05/17/2011 08:32 PM, Uros Bizjak wrote:
>>>
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committe
On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:
On Tue, May 17, 2011 at 2:46 PM, Toon Moene 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
On Tue, May 17, 2011 at 2:46 PM, Toon Moene 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++
> bootst
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 intrica
Hello!
2011-05-17 Uros Bizjak
* 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 {, m32} with --e
Richard Sandiford writes:
| Gabriel Dos Reis 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 declarat
Gabriel Dos Reis 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 definitely ag
Richard Sandiford writes:
| Gabriel Dos Reis writes:
| > Andrew Pinski writes:
| >
| > | On Wed, Apr 27, 2011 at 6:48 PM, Gabriel Dos Reis
wrote:
| > | > A local `extern' declaration does not give the entity an external
linkage
| > | > -- irrespective of the linkage of the function enclosing
Gabriel Dos Reis writes:
> Andrew Pinski writes:
>
> | On Wed, Apr 27, 2011 at 6:48 PM, Gabriel Dos Reis 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
Andrew Pinski writes:
| On Wed, Apr 27, 2011 at 6:48 PM, Gabriel Dos Reis 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 looku
On Wed, Apr 27, 2011 at 6:48 PM, Gabriel Dos Reis 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 variable declar
Andrew Pinski writes:
| On Wed, Apr 27, 2011 at 6:30 PM, Gabriel Dos Reis 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 rules. Fixed thusly. Applied
On Wed, Apr 27, 2011 at 6:30 PM, Gabriel Dos Reis 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 rules. Fixed thusly. Applied as obvious.
Can you explain some more
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
* internal-fn.h (internal_fn_name_array): De
100 matches
Mail list logo
