Pushed as obvious.
* gcse.cc (pass_hardreg_pre::gate): Wrap possibly unused
fun argument.
---
gcc/gcse.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcse.cc b/gcc/gcse.cc
index 3f3f7fe15b0..4ae19f28430 100644
--- a/gcc/gcse.cc
+++ b/gcc/gcse.cc
@@ -435
On Mon, 17 Jul 2023, Richard Biener wrote:
> > > > > OK. Btw, while I didn't spot this during review I would appreciate
> > > > > if the code could use vec.[q]sort, this should work with a lambda as
> > > > > well I think.
> > > >
> > > > That was my first use, but that hits
> > > > https://gc
Sent: Monday, July 17, 2023 7:19 AM
> > > > To: Roger Sayle
> > > > Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> > > >
> > > > Subject: Re: [PATCH] Fix bootstrap failure (with g++ 4.8.5) in tree-if-
> > conv.cc.
> > > >
> >
patches@gcc.gnu.org; Tamar Christina
> > >
> > > Subject: Re: [PATCH] Fix bootstrap failure (with g++ 4.8.5) in tree-if-
> conv.cc.
> > >
> > > On Fri, Jul 14, 2023 at 8:56 PM Roger Sayle
> > >
> > > wrote:
> > > >
> > >
On Mon, Jul 17, 2023 at 12:21 AM Tamar Christina via Gcc-patches
wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, July 17, 2023 7:19 AM
> > To: Roger Sayle
> > Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> > Subject: Re
> -Original Message-
> From: Richard Biener
> Sent: Monday, July 17, 2023 7:19 AM
> To: Roger Sayle
> Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> Subject: Re: [PATCH] Fix bootstrap failure (with g++ 4.8.5) in
> tree-if-conv.cc.
>
> On Fri, Jul 14,
On Fri, Jul 14, 2023 at 8:56 PM Roger Sayle wrote:
>
>
>
> This patch fixes the bootstrap failure I'm seeing using gcc 4.8.5 as
>
> the host compiler. Ok for mainline? [I might be missing something]
OK. Btw, while I didn't spot this during review I would appreciate
if the code could use vec.[
On Fri, Jul 14, 2023 at 11:56 AM Roger Sayle wrote:
>
>
>
> This patch fixes the bootstrap failure I'm seeing using gcc 4.8.5 as
>
> the host compiler. Ok for mainline? [I might be missing something]
I think adding const here makes this well defined C++20 too.
See http://cplusplus.github.io/LWG
This patch fixes the bootstrap failure I'm seeing using gcc 4.8.5 as
the host compiler. Ok for mainline? [I might be missing something]
2023-07-14 Roger Sayle
gcc/ChangeLog
* tree-if-conv.cc (predicate_scalar_phi): Make the arguments
to the std::sort comparison
On 12/21/20 11:19 AM, Gerald Pfeifer wrote:
We explicitly need to inlude netinet.h, (despite what happened on my test
systems)
libcody/
* netclient.cc: Add netinet.h.
Note, though, that my patch also fixed libcody/netserver.cc, which still
failed. Seeing t
On Mon, 21 Dec 2020, Nathan Sidwell wrote:
> On 12/20/20 6:28 PM, Gerald Pfeifer wrote:
>> libcody as originally added to GCC fails to build on *-unknown-freebsd11.4
>> and presumably others:
>>
>>c++ -std=c++11 -g -include config.h -I ... -MMD -MP -MF netclient.d -c
>> -o netclient.o
>>
On 12/20/20 6:28 PM, Gerald Pfeifer wrote:
libcody as originally added to GCC fails to build on *-unknown-freebsd11.4
and presumably others:
c++ -std=c++11 -g -include config.h -I ... -MMD -MP -MF netclient.d -c
-o netclient.o
.../libcody/netclient.cc:114:3: error: unknown type sockad
On 21/12/2020 00:28, Gerald Pfeifer wrote:
libcody as originally added to GCC fails to build on *-unknown-freebsd11.4
and presumably others:
I experienced the same issue with FreeBSD 12 building a cross-compiler.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
libcody as originally added to GCC fails to build on *-unknown-freebsd11.4
and presumably others:
c++ -std=c++11 -g -include config.h -I ... -MMD -MP -MF netclient.d -c
-o netclient.o
.../libcody/netclient.cc:114:3: error: unknown type sockaddr_in6 addr;
This fixes a typo in the TREE_CODE compare which should
compare against TYPE_DECL, not TYPE_NAME.
Pushed as obvious.
2020-11-19 Richard Biener
* fold-const.c (operand_compare::hash_operand): Fix typo.
---
gcc/fold-const.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On Thu, 29 Aug 2019, Richard Biener wrote:
> On Thu, 29 Aug 2019, Jakub Jelinek wrote:
>
> > On Thu, Aug 29, 2019 at 12:04:53PM +0200, Richard Biener wrote:
> > > + else
> >
> > Perhaps use
> > else if (MAY_HAVE_DEBUG_BIND_INSNS)
> > instead so that you don't walk it once again if there can'
On Thu, 29 Aug 2019, Uros Bizjak wrote:
> On Thu, Aug 29, 2019 at 12:04 PM Richard Biener wrote:
> >
> >
> > The following fixes the bootstrap-debug miscompare caused by STV
> > where we ended up with chain-to-scalar copies just because of
> > debug uses. Instead we have to avoid that, eventuall
On Thu, 29 Aug 2019, Jakub Jelinek wrote:
> On Thu, Aug 29, 2019 at 12:04:53PM +0200, Richard Biener wrote:
> > + else
>
> Perhaps use
> else if (MAY_HAVE_DEBUG_BIND_INSNS)
> instead so that you don't walk it once again if there can't be DEBUG_INSNs?
Sure - will do as followup to unbreak
On Thu, Aug 29, 2019 at 12:04:53PM +0200, Richard Biener wrote:
> + else
Perhaps use
else if (MAY_HAVE_DEBUG_BIND_INSNS)
instead so that you don't walk it once again if there can't be DEBUG_INSNs?
Jakub
On Thu, Aug 29, 2019 at 12:04 PM Richard Biener wrote:
>
>
> The following fixes the bootstrap-debug miscompare caused by STV
> where we ended up with chain-to-scalar copies just because of
> debug uses. Instead we have to avoid that, eventually substituting
> into debug uses or resetting debug s
The following fixes the bootstrap-debug miscompare caused by STV
where we ended up with chain-to-scalar copies just because of
debug uses. Instead we have to avoid that, eventually substituting
into debug uses or resetting debug stmts when there are reaching
defs from both inside and outside of
Jakub Jelinek writes:
> Hi!
>
> Attached are two different fixes, each of which fixes the build.
> The first one arranges gencondmd to be linked against build/errors.o,
> so that it links fine, the second one instead doesn't define the function
> and method which requires that, as it is only calle
On 6/7/19 5:13 PM, Jakub Jelinek wrote:
Ok for trunk? Which one?
Thank you Jakub for the fix. I'm fine with both.
Martin
Hi!
Attached are two different fixes, each of which fixes the build.
The first one arranges gencondmd to be linked against build/errors.o,
so that it links fine, the second one instead doesn't define the function
and method which requires that, as it is only called from #if CHECKING_P
guarded code
On Tue, Dec 18, 2018 at 10:39:27AM +1030, Alan Modra wrote:
> On Mon, Dec 17, 2018 at 11:05:57AM -0600, Segher Boessenkool wrote:
> > Hi!
> >
> > On Mon, Dec 17, 2018 at 10:40:01AM +1030, Alan Modra wrote:
> > > Since I broke powerpc*-freebsd and the other non-linux powerpc
> > > targets, I guess
On Tue, Dec 18, 2018 at 11:18:03PM +1030, Alan Modra wrote:
> On Tue, Dec 18, 2018 at 03:20:02AM -0600, Segher Boessenkool wrote:
> > Hi Alan,
> >
> > On Tue, Dec 18, 2018 at 10:39:27AM +1030, Alan Modra wrote:
> > > On Mon, Dec 17, 2018 at 11:05:57AM -0600, Segher Boessenkool wrote:
> > > > On Mo
On Tue, Dec 18, 2018 at 03:20:02AM -0600, Segher Boessenkool wrote:
> Hi Alan,
>
> On Tue, Dec 18, 2018 at 10:39:27AM +1030, Alan Modra wrote:
> > On Mon, Dec 17, 2018 at 11:05:57AM -0600, Segher Boessenkool wrote:
> > > On Mon, Dec 17, 2018 at 10:40:01AM +1030, Alan Modra wrote:
> > > > Since I b
Hi Alan,
On Tue, Dec 18, 2018 at 10:39:27AM +1030, Alan Modra wrote:
> On Mon, Dec 17, 2018 at 11:05:57AM -0600, Segher Boessenkool wrote:
> > On Mon, Dec 17, 2018 at 10:40:01AM +1030, Alan Modra wrote:
> > > Since I broke powerpc*-freebsd and the other non-linux powerpc
> > > targets, I guess I o
On Mon, Dec 17, 2018 at 11:05:57AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Dec 17, 2018 at 10:40:01AM +1030, Alan Modra wrote:
> > Since I broke powerpc*-freebsd and the other non-linux powerpc
> > targets, I guess I ought to fix them. The following is a variation on
> > your first pat
Hi!
On Mon, Dec 17, 2018 at 10:40:01AM +1030, Alan Modra wrote:
> Since I broke powerpc*-freebsd and the other non-linux powerpc
> targets, I guess I ought to fix them. The following is a variation on
> your first patch, that results in -mcall-linux for powerpc-freebsd*
> providing the 32-bit pow
On Sun, Dec 16, 2018 at 07:46:18PM +0100, Andreas Tobler wrote:
> On 12.12.18 21:32, Andreas Tobler wrote:
>
> > this patch fixes bootstrap for my powerpc*-unknown-freebsd* targets.
> > The definition of GNU_USER_DYNAMIC_LINKER was recently moved to linux.h.
Sorry about the breakage.
> > But the
On 12.12.18 21:32, Andreas Tobler wrote:
this patch fixes bootstrap for my powerpc*-unknown-freebsd* targets.
The definition of GNU_USER_DYNAMIC_LINKER was recently moved to linux.h.
But the GNU_USER_DYNAMIC_LINKER is still used in rs6000/sysv4.h.
So I add an empty definition with guard to cure
Hi all,
this patch fixes bootstrap for my powerpc*-unknown-freebsd* targets.
The definition of GNU_USER_DYNAMIC_LINKER was recently moved to linux.h.
But the GNU_USER_DYNAMIC_LINKER is still used in rs6000/sysv4.h.
So I add an empty definition with guard to cure the bootstrap issue.
Ok for trun
On Wed, 14 Nov 2018, Richard Biener wrote:
On Wed, 14 Nov 2018, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, with GCC before 4.3 one can't instantiate std::pair
where one or both of the template parameters are reference types, because
the std::pair constructor has arguments references to
On 14/11/18 09:25 +0100, Richard Biener wrote:
On Wed, 14 Nov 2018, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, with GCC before 4.3 one can't instantiate std::pair
where one or both of the template parameters are reference types, because
the std::pair constructor has arguments references
On Wed, 14 Nov 2018, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, with GCC before 4.3 one can't instantiate std::pair
> where one or both of the template parameters are reference types, because
> the std::pair constructor has arguments references to the template parameter
> types and th
Hi!
As mentioned in the PR, with GCC before 4.3 one can't instantiate std::pair
where one or both of the template parameters are reference types, because
the std::pair constructor has arguments references to the template parameter
types and the CWG that resolved hasn't been applied to those compil
PR libstdc++/86447
* src/c++11/cow-stdexcept.cc [_GLIBCXX_FULLY_DYNAMIC_STRING]
(logic_error::logic_error(logic_error&&))
(logic_error::operator=(logic_error&&))
(runtime_error::runtime_error(runtime_error&&))
(runtime_error::operator=(runtime_error&
On 07/03/2018 07:32 PM, Jakub Jelinek wrote:
> On Tue, Jul 03, 2018 at 07:22:19PM +0200, Martin Liška wrote:
>> In order to make GCC 4.1 happy and build current tip, we need to define
>> static constants out of a class definition.
>>
>> Ready for trunk?
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
On Tue, Jul 03, 2018 at 07:22:19PM +0200, Martin Liška wrote:
> In order to make GCC 4.1 happy and build current tip, we need to define
> static constants out of a class definition.
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-03 Martin Liska
>
> * tree-switch
Hi.
In order to make GCC 4.1 happy and build current tip, we need to define
static constants out of a class definition.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-07-03 Martin Liska
* tree-switch-conversion.h (struct jump_table_cluster): Define
constant values outs
On 06/26/2018 02:06 AM, Richard Biener wrote:
> On Tue, Jun 26, 2018 at 2:21 AM David Malcolm wrote:
>>
>> I ran into this bootstrap failure (with r262092):
>>
>> ../../../src/gcc/tree-vect-loop.c: In function ‘_loop_vec_info*
>> vect_analyze_loop(loop*, loop_vec_info, vec_info_shared*)’:
>> ../.
On Tue, Jun 26, 2018 at 2:21 AM David Malcolm wrote:
>
> I ran into this bootstrap failure (with r262092):
>
> ../../../src/gcc/tree-vect-loop.c: In function ‘_loop_vec_info*
> vect_analyze_loop(loop*, loop_vec_info, vec_info_shared*)’:
> ../../../src/gcc/tree-vect-loop.c:1946:25: error: ‘n_stmts
I ran into this bootstrap failure (with r262092):
../../../src/gcc/tree-vect-loop.c: In function ‘_loop_vec_info*
vect_analyze_loop(loop*, loop_vec_info, vec_info_shared*)’:
../../../src/gcc/tree-vect-loop.c:1946:25: error: ‘n_stmts’ may be used
uninitialized in this function [-Werror=maybe-unin
On Tue, May 08, 2018 at 10:37:04AM +0200, Richard Biener wrote:
> > OK for trunk?
>
> Ping.
>
> Richard.
>
> > Thanks,
> > Richard.
> >
> > 2018-05-02 Richard Biener
> >
> > PR bootstrap/85571
> > config/
> > * bootstrap-lto-noplugin.mk: Disable compare.
> > * bootstrap-lto.
On Wed, 2 May 2018, Richard Biener wrote:
>
> The following fixes the LTO part of the -f[no-]checking miscompare issue.
> I introduce a compare-lto script similar to compare-debug where I strip
> the LTO option section and re-compare. I have no easy way to test
> the nonplugin path and at least
The following fixes the LTO part of the -f[no-]checking miscompare issue.
I introduce a compare-lto script similar to compare-debug where I strip
the LTO option section and re-compare. I have no easy way to test
the nonplugin path and at least for targets using simple-object to
wrap all LTO secti
Hi!
On Sat, Feb 17, 2018 at 10:08:48AM +0100, Jakub Jelinek wrote:
> Note, this doesn't work, as G++ <= 4.2 rejects:
> template
> struct S
> {
> char __attribute__ ((__aligned__ (__alignof__ (value_type buf[sizeof
> (value_type)];
> };
>
> S s;
>
> with:
> error: requested alignment is n
On Mon, Feb 26, 2018 at 01:15:45PM +0100, Richard Biener wrote:
> > I'd like to ping this patch, or if it isn't acceptable, at least the vec.h
> > part of it which isn't really more complex than what we have right now.
>
> So BROKEN_VALUE_INITIALIZATION doesn't really mean it's "broken" but
> that
On Mon, 26 Feb 2018, Jakub Jelinek wrote:
> On Mon, Feb 26, 2018 at 01:15:45PM +0100, Richard Biener wrote:
> > > I'd like to ping this patch, or if it isn't acceptable, at least the vec.h
> > > part of it which isn't really more complex than what we have right now.
> >
> > So BROKEN_VALUE_INITIA
On Mon, 26 Feb 2018, Jakub Jelinek wrote:
> Hi!
>
> On Sat, Feb 17, 2018 at 10:08:48AM +0100, Jakub Jelinek wrote:
> > Note, this doesn't work, as G++ <= 4.2 rejects:
> > template
> > struct S
> > {
> > char __attribute__ ((__aligned__ (__alignof__ (value_type buf[sizeof
> > (value_type)]
On February 16, 2018 9:44:33 PM GMT+01:00, Jakub Jelinek
wrote:
>On Fri, Feb 16, 2018 at 09:25:30PM +0100, Richard Biener wrote:
>> But the broken compilers will overwrite the memset data with possibly
>uninitialized fields of a TARGET_EXPR.
>
>Perhaps for hash-table.h we could use:
>#ifndef BRO
On Fri, Feb 16, 2018 at 02:14:09PM -0700, Martin Sebor wrote:
> On 02/16/2018 01:44 PM, Jakub Jelinek wrote:
> > On Fri, Feb 16, 2018 at 09:25:30PM +0100, Richard Biener wrote:
> > > But the broken compilers will overwrite the memset data with possibly
> > > uninitialized fields of a TARGET_EXPR.
On Fri, Feb 16, 2018 at 02:14:09PM -0700, Martin Sebor wrote:
> On 02/16/2018 01:44 PM, Jakub Jelinek wrote:
> > On Fri, Feb 16, 2018 at 09:25:30PM +0100, Richard Biener wrote:
> > > But the broken compilers will overwrite the memset data with possibly
> > > uninitialized fields of a TARGET_EXPR.
On 02/16/2018 01:44 PM, Jakub Jelinek wrote:
On Fri, Feb 16, 2018 at 09:25:30PM +0100, Richard Biener wrote:
But the broken compilers will overwrite the memset data with possibly
uninitialized fields of a TARGET_EXPR.
Perhaps for hash-table.h we could use:
#ifndef BROKEN_VALUE_INITIALIZATION
On Fri, Feb 16, 2018 at 09:25:30PM +0100, Richard Biener wrote:
> But the broken compilers will overwrite the memset data with possibly
> uninitialized fields of a TARGET_EXPR.
Perhaps for hash-table.h we could use:
#ifndef BROKEN_VALUE_INITIALIZATION
for ( ; size; ++entries, --size)
On Fri, Feb 16, 2018 at 09:25:30PM +0100, Richard Biener wrote:
> But the broken compilers will overwrite the memset data with possibly
> uninitialized fields of a TARGET_EXPR.
For the vec.h case no, there is no temporary involved, it is constructed
directly into the memory.
For the hash-table.
On February 16, 2018 8:52:18 PM GMT+01:00, Jakub Jelinek
wrote:
>On Fri, Feb 16, 2018 at 12:47:31PM -0700, Martin Sebor wrote:
>> hoping it can be revisited in stage 1. Ultimately, we need
>> to decide if vec really needs to be a POD (or trivial or
>
>Yes, definitely. This has been discussed se
On February 16, 2018 7:05:10 PM GMT+01:00, Jakub Jelinek
wrote:
>On Fri, Feb 16, 2018 at 10:36:27AM -0700, Martin Sebor wrote:
>> The deeper problem is that vec wants to be a POD but GCC
>> instantiates the template on non-POD types. For example
>> genrecog.c instantiates it on struct parameter
On Fri, Feb 16, 2018 at 12:47:31PM -0700, Martin Sebor wrote:
> hoping it can be revisited in stage 1. Ultimately, we need
> to decide if vec really needs to be a POD (or trivial or
Yes, definitely. This has been discussed several times.
Jakub
On Fri, Feb 16, 2018 at 10:36:27AM -0700, Martin Sebor wrote:
> The deeper problem is that vec wants to be a POD but GCC
> instantiates the template on non-POD types. For example
> genrecog.c instantiates it on struct parameter that has
> a default ctor.
>
> A number of ipa-*.c files instantiate
On 02/16/2018 11:05 AM, Jakub Jelinek wrote:
On Fri, Feb 16, 2018 at 10:36:27AM -0700, Martin Sebor wrote:
The deeper problem is that vec wants to be a POD but GCC
instantiates the template on non-POD types. For example
genrecog.c instantiates it on struct parameter that has
a default ctor.
A
On 02/16/2018 01:38 AM, Jakub Jelinek wrote:
Hi!
As the system.h comment says, it took us years to get value initialization
right, and unfortunately we've started hitting it in GCC codebase now.
There are various related PRs, 4.2.[0-3] are most broken in this regard,
value initialization of non-
On Fri, Feb 16, 2018 at 11:31:15AM +0100, Richard Biener wrote:
>
> After Jakubs fixes we can restore bootstrap with GCC 4.2.1 as provided
> by older Darwin hosts with the following patch.
>
> Bootstrap using a GCC 4.2.1 host compiler on x86_64-unknown-linux-gnu
> is now in stage2.
>
> Ok for tr
On Fri, Feb 16, 2018 at 09:48:25AM +0100, Richard Biener wrote:
> Ok. I'll see if fixing libcpp makes GCC 4.2.[0-3] usable as well.
Looking through r249234, dump_file_info is ok, because it is a POD,
ipcp_value/ipa_edge_args too, because it has a user provided ctor that
initializes everything, wi
After Jakubs fixes we can restore bootstrap with GCC 4.2.1 as provided
by older Darwin hosts with the following patch.
Bootstrap using a GCC 4.2.1 host compiler on x86_64-unknown-linux-gnu
is now in stage2.
Ok for trunk?
Thanks,
Richard.
2018-02-16 Richard Biener
PR bootstrap/82939
Hi!
As the system.h comment says, it took us years to get value initialization
right, and unfortunately we've started hitting it in GCC codebase now.
There are various related PRs, 4.2.[0-3] are most broken in this regard,
value initialization of non-PODs doesn't actually initialize there anything
On Fri, 16 Feb 2018, Jakub Jelinek wrote:
> Hi!
>
> As the system.h comment says, it took us years to get value initialization
> right, and unfortunately we've started hitting it in GCC codebase now.
> There are various related PRs, 4.2.[0-3] are most broken in this regard,
> value initialization
On Wed, Nov 08, 2017 at 08:43:43AM +0100, Jakub Jelinek wrote:
> Hi!
>
> The upstream libubsan in the name of behaving more similarly between
> all the other sanitizers turned the library from a lightweight set of a few
> helper routines that print errors if something goes wrong into yet another
>
On Wed, 8 Nov 2017, Jakub Jelinek wrote:
> Hi!
>
> The upstream libubsan in the name of behaving more similarly between
> all the other sanitizers turned the library from a lightweight set of a few
> helper routines that print errors if something goes wrong into yet another
> library that overrid
Hi!
The upstream libubsan in the name of behaving more similarly between
all the other sanitizers turned the library from a lightweight set of a few
helper routines that print errors if something goes wrong into yet another
library that overrides various functions.
In particular, it now overrides
On October 19, 2017 9:22:09 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>The PR claims a bootstrap failure because we link lsan_preinit.cc that
>contains .preinit_array section item into the liblsan shared library.
>
>Of course, this object isn't meant to be linked into the library, but
>rather han
Hi!
The PR claims a bootstrap failure because we link lsan_preinit.cc that
contains .preinit_array section item into the liblsan shared library.
Of course, this object isn't meant to be linked into the library, but
rather handled like libasan_preinit.o - linked directly into executables.
The poin
On Tue, 4 Jul 2017, Jakub Jelinek wrote:
> Hi!
>
> Seems tree-cfg.h now requires profile-count.h (or some header that includes
> it like basic-block.h) to be included first (the flattened headers without
> including their dependencies and without aggregate headers are really terrible
> idea), so
Hi!
Seems tree-cfg.h now requires profile-count.h (or some header that includes
it like basic-block.h) to be included first (the flattened headers without
including their dependencies and without aggregate headers are really terrible
idea), so right now bootstrap fails in brig FE.
Fixed thusly, b
On 25/05/17 14:35 +0200, Richard Biener wrote:
On May 25, 2017 1:38:36 PM GMT+02:00, Nathan Sidwell wrote:
On 05/25/2017 07:21 AM, Jonathan Wakely wrote:
I don't mind removing the warning again if preferred. I thought it
was
useful (as we already warn for ignored const in return types).
O
On May 25, 2017 1:38:36 PM GMT+02:00, Nathan Sidwell wrote:
>On 05/25/2017 07:21 AM, Jonathan Wakely wrote:
>
>> I don't mind removing the warning again if preferred. I thought it
>was
>> useful (as we already warn for ignored const in return types).
>
>Oh yeah, I recall noticing we did that (and
On 05/25/2017 07:21 AM, Jonathan Wakely wrote:
I don't mind removing the warning again if preferred. I thought it was
useful (as we already warn for ignored const in return types).
Oh yeah, I recall noticing we did that (and noting we didn't warn
elsewhere). This new warning seems consistent
On 25/05/17 12:19 +0100, Jonathan Wakely wrote:
On 25/05/17 06:54 -0400, Nathan Sidwell wrote:
On 05/25/2017 01:29 AM, Richard Biener wrote:
On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote:
On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 25/05/17 06:54 -0400, Nathan Sidwell wrote:
On 05/25/2017 01:29 AM, Richard Biener wrote:
On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote:
On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
On 05/25/2017 01:29 AM, Richard Biener wrote:
On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote:
On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obv
On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote:
>On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
>> On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
>>> On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obvious to fix
>bootstrap.
>>>
>>> And thi
On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obvious to fix bootstrap.
And this fixes c-common.c
And fix auto-profile.c
and lto-streamer-out.c, sigh
-
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obvious to fix bootstrap.
And this fixes c-common.c
And fix auto-profile.c
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
* auto-profile.c (afdo
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obvious to fix bootstrap.
And this fixes c-common.c
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
* c=common.c (field_decl_cmp, resort_field_decl_cmp): Adjust T
const casts to avoid warning.
We now warn on casts to T const. Applied as obvious to fix bootstrap.
nathan
--
Nathan Sidwell
Index: ChangeLog
===
--- ChangeLog (revision 248441)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2017-05-24 Nathan Sidwell
+
+ * lib
> >> It is due to a -Werror warning when passing GNAT_EXCEPTION_CLASS
> >> which is a string constant to exception_class_eq, but C++ forbids to
> >> cast
> >> that to "char*".
> >>
> >> Not sure what is the smartest solution, I tried the following and it
> >> seems to work for x86_64-pc-linux-gnu a
On 05/09/17 15:10, Arnaud Charlet wrote:
>>
>> since a few days the bootstrap of ada fails on a native arm target.
>>
>> It is due to a -Werror warning when passing GNAT_EXCEPTION_CLASS
>> which is a string constant to exception_class_eq, but C++ forbids to cast
>> that to "char*".
>>
>> Not sure w
>
> since a few days the bootstrap of ada fails on a native arm target.
>
> It is due to a -Werror warning when passing GNAT_EXCEPTION_CLASS
> which is a string constant to exception_class_eq, but C++ forbids to cast
> that to "char*".
>
> Not sure what is the smartest solution, I tried the foll
Hi,
since a few days the bootstrap of ada fails on a native arm target.
It is due to a -Werror warning when passing GNAT_EXCEPTION_CLASS
which is a string constant to exception_class_eq, but C++ forbids to cast
that to "char*".
Not sure what is the smartest solution, I tried the following and it
On Thu, Jan 12, 2017 at 02:10:39PM -0700, Jeff Law wrote:
> > 2017-01-12 Jakub Jelinek
> >
> > PR bootstrap/79069
> > * cfgrtl.c (rtl_tidy_fallthru_edge): For any_uncondjump_p that can't
> > be removed due to side-effects, don't remove following barrier nor
> > turn the successo
On 01/12/2017 01:24 PM, Jakub Jelinek wrote:
Hi!
The RTL verification in rtl_verify_edges as well as various other routines
in cfgrtl.c etc. require that any_uncondjump_p jumps never have fallthru
edges - even if their destination is right after them, there still needs to
be barrier in between t
Hi!
The RTL verification in rtl_verify_edges as well as various other routines
in cfgrtl.c etc. require that any_uncondjump_p jumps never have fallthru
edges - even if their destination is right after them, there still needs to
be barrier in between them and code_label after that.
rtl_tidy_fallthr
On 10/27/2016 05:00 AM, Rainer Orth wrote:
Hi Jeff,
On 10/19/2016 06:13 AM, Rainer Orth wrote:
Hi Jakub,
2016-10-01 Rainer Orth
* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
This is incomple
Hi Jeff,
> On 10/19/2016 06:13 AM, Rainer Orth wrote:
>> Hi Jakub,
>>
2016-10-01 Rainer Orth
* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
>>>
>>> This is incomplete. I guess it can be com
Hi Jeff,
> On 10/19/2016 06:13 AM, Rainer Orth wrote:
>> Hi Jakub,
>>
2016-10-01 Rainer Orth
* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
>>>
>>> This is incomplete. I guess it can be com
Hi Jeff,
> On 10/19/2016 06:13 AM, Rainer Orth wrote:
>> Hi Jakub,
>>
2016-10-01 Rainer Orth
* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
>>>
>>> This is incomplete. I guess it can be com
Hi Jeff,
> On 10/19/2016 06:13 AM, Rainer Orth wrote:
>> Hi Jakub,
>>
2016-10-01 Rainer Orth
* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
>>>
>>> This is incomplete. I guess it can be com
On 10/19/2016 06:13 AM, Rainer Orth wrote:
Hi Jakub,
2016-10-01 Rainer Orth
* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
This is incomplete. I guess it can be committed as is, but should be
f
Hi Jakub,
>> 2016-10-01 Rainer Orth
>>
>> * configure.ac (target_libraries): Readd target-boehm-gc.
>> Restore --enable-objc-gc handling.
>> * configure: Regenerate.
>
> This is incomplete. I guess it can be committed as is, but should be
> followed by re-addition of:
> bfin-
1 - 100 of 198 matches
Mail list logo
