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
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
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
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
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
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
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
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
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
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
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
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
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
> >> 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
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
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-
On 10/03/2016 06:53 AM, Rainer Orth wrote:
Andrew Haley writes:
On 30/09/16 23:16, Rainer Orth wrote:
me too, though mostly to have maximum test coverage (primarily on
Solaris). As expected, a x86_64-apple-darwin16 bootstrap with
--enable-objc-gc just failed for me. I'm testing the followin
On Sat, Oct 01, 2016 at 12:16:20AM +0200, Rainer Orth wrote:
> Hi Eric,
>
> >> I haven't tried to readd the boehm-gc objc support that has also been
> >> disabled, don't know about anybody using that.
> >
> > I always configure with --enable-objc-gc. The only reason Apple
> > deprecated garbage co
Andrew Haley writes:
> On 30/09/16 23:16, Rainer Orth wrote:
>> me too, though mostly to have maximum test coverage (primarily on
>> Solaris). As expected, a x86_64-apple-darwin16 bootstrap with
>> --enable-objc-gc just failed for me. I'm testing the following patch
>> (on top of Jakub's).
>>
On 30/09/16 23:16, Rainer Orth wrote:
> me too, though mostly to have maximum test coverage (primarily on
> Solaris). As expected, a x86_64-apple-darwin16 bootstrap with
> --enable-objc-gc just failed for me. I'm testing the following patch
> (on top of Jakub's).
>
> Rainer
>
>
> 2016-10
Jakub Jelinek writes:
> 2016-09-30 Jakub Jelinek
>
> * configure.ac: Add target-libffi to target_libraries.
> Readd libgcj target disablings, modified to only target-libffi.
> Readd target addition of go to unsupported languages.
> * configure: Regenerated.
This is OK.
Hi Eric,
>> I haven't tried to readd the boehm-gc objc support that has also been
>> disabled, don't know about anybody using that.
>
> I always configure with --enable-objc-gc. The only reason Apple
> deprecated garbage collection for Objective C is because they replaced
> it with Automated Refer
On 9/30/16, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Sep 30, 2016 at 01:48:12PM +0100, Andrew Haley wrote:
>> On 30/09/16 11:27, Marek Polacek wrote:
>> > Can we move forward with this patch, then?
>>
>> I've been travelling for several weeks. However, I'm back at my desk
>> now, so I can move this
On 05/20/2016 12:09 PM, John David Anglin wrote:
On 2016-05-18 2:20 AM, Jakub Jelinek wrote:
On Tue, May 17, 2016 at 08:31:00PM -0400, John David Anglin wrote:
>r235550 introduced the use of long long, and the macros LLONG_MIN
and LLONG_MAX. These macros
>are not defined by default and we need
On Mon, Jun 13, 2016 at 03:39:21PM +, Bernd Edlinger wrote:
> On 06/13/16 17:27, David Malcolm wrote:
> > On Mon, 2016-06-13 at 14:41 +, Bernd Edlinger wrote:
> >> Hi,
> >>
> >> as noted in PR bootstrap/71481, comment#4 currently
> >> the trunk fails to bootstrap if the current language is
On 06/13/16 17:27, David Malcolm wrote:
> On Mon, 2016-06-13 at 14:41 +, Bernd Edlinger wrote:
>> Hi,
>>
>> as noted in PR bootstrap/71481, comment#4 currently
>> the trunk fails to bootstrap if the current language is
>> not english. A workaround is possible by setting LANG=C,
>> but OTOH it
On Mon, 2016-06-13 at 14:41 +, Bernd Edlinger wrote:
> Hi,
>
> as noted in PR bootstrap/71481, comment#4 currently
> the trunk fails to bootstrap if the current language is
> not english. A workaround is possible by setting LANG=C,
> but OTOH it is rather easy to fix, by translating the strin
On 2016-05-18 2:20 AM, Jakub Jelinek wrote:
On Tue, May 17, 2016 at 08:31:00PM -0400, John David Anglin wrote:
>r235550 introduced the use of long long, and the macros LLONG_MIN and
LLONG_MAX. These macros
>are not defined by default and we need to include when compiling
with c++ to define t
On Tue, May 17, 2016 at 08:31:00PM -0400, John David Anglin wrote:
> r235550 introduced the use of long long, and the macros LLONG_MIN and
> LLONG_MAX. These macros
> are not defined by default and we need to include when compiling
> with c++ to define them.
IMNSHO we should get rid of those l
On Sun, May 01, 2016 at 11:05:29AM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > + if test "x$enable_checking" = x && \
> > + test -d ${srcdir}/gcc && \
> > + test x"`cat ${srcdir}/gcc/DEV-PHASE`" = xexperimental; then
> > +stage1_checking=yes,types,extra
>
> s/=/=--ena
Jakub Jelinek writes:
> + if test "x$enable_checking" = x && \
> + test -d ${srcdir}/gcc && \
> + test x"`cat ${srcdir}/gcc/DEV-PHASE`" = xexperimental; then
> +stage1_checking=yes,types,extra
s/=/=--enable-checking=/
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fing
Looks good to me.
Jason
On Mon, Apr 25, 2016 at 3:30 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, some checking code, in particular the one
> in C++ FE's build_non_dependent_expr, may affect code generation, as it can
> instantiate templates that aren't instantiated otherwise, whic
On Mon, Feb 22, 2016 at 09:15:29AM -0700, Jeff Law wrote:
> Yea, as it's currently written, it's a bit vague. I think your suggesting
> of saying that VOIDmode should not be used is what we need. I'll leave the
> final word-smithing to you.
Here is what I've committed.
2016-02-22 Jakub Jelinek
On 02/22/2016 07:28 AM, Jakub Jelinek wrote:
On Mon, Feb 22, 2016 at 07:09:41AM -0700, Jeff Law wrote:
On 02/22/2016 06:08 AM, Jakub Jelinek wrote:
Hi!
Supposedly my recent invalid shift count expansion changes broke
m68k bootstrap, we now really require that the shift expanders
have some non-
Jakub Jelinek writes:
> Would you like to somehow stress that operand 2's mode must be specified
> in the instruction pattern or expander? As it says that the compiler will
> convert it to that mode, I'd kind of say that VOIDmode should not be used
> there.
Perhaps a warning could be emitted by
On Mon, Feb 22, 2016 at 07:09:41AM -0700, Jeff Law wrote:
> On 02/22/2016 06:08 AM, Jakub Jelinek wrote:
> >Hi!
> >
> >Supposedly my recent invalid shift count expansion changes broke
> >m68k bootstrap, we now really require that the shift expanders
> >have some non-VOIDmode, so that we can convert
On 02/22/2016 06:08 AM, Jakub Jelinek wrote:
Hi!
Supposedly my recent invalid shift count expansion changes broke
m68k bootstrap, we now really require that the shift expanders
have some non-VOIDmode, so that we can convert_mode it to that
mode. But m68k didn't specify mode. For valid shift co
On 01/28/2016 12:17 PM, Jakub Jelinek wrote:
> The recent lra-remat.c change broke bootstrap for me on i686,
> with comparison failure on simplify-rtx.o.
> Below is a reduced testcase. debug insns really should not affect
> remat decisions, before the recent changes set_bb_regs should be always a
On Tue, 19 Jan 2016, Jakub Jelinek wrote:
> On Tue, Jan 19, 2016 at 03:19:17PM +0100, Richard Biener wrote:
> >
> > It also seems we're wrongly using values defined for the host while
> > looking at GIMPLE IL for the target.
> >
> > Bootstrap / regtest running on x86_64-unknown-linux-gnu.
> >
>
On Tue, Jan 19, 2016 at 03:19:17PM +0100, Richard Biener wrote:
>
> It also seems we're wrongly using values defined for the host while
> looking at GIMPLE IL for the target.
>
> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
>
> Ok?
>
> Richard.
>
> 2016-01-19 Richard Biener
>
>
On Thu, Aug 27, 2015 at 3:19 PM, Andreas Tobler wrote:
> Hi all,
>
> I think this is obvious?
Yes. Sorry for missing testing without ISL.
I have committed a similar patch just after I got pinged that my patch
broke builds without ISL.
Sebastian
>
> Thanks,
> Andreas
>
> 2015-08-27 Andreas Tobl
On Mon, 2015-06-01 at 17:07 +0200, Andreas Tobler wrote:
> > This patch worked for me. I am curious about why you use
> > '!HAVE_DECL_ATOLL' in read-rtl.c instead of '!defined(HAVE_DECL_ATOLL)'.
> > The use of !defined seems more common and is used in the HAVE_ATOQ check
> > in the same #if state
On 01.06.15 16:43, Steve Ellcey wrote:
On Sat, 2015-05-30 at 11:27 +0200, Andreas Tobler wrote:
I'm sorry. I totally forgot about autoheader...
I'm testing this one now. Would you mind giving it a try?
Thanks,
Andreas
This patch worked for me. I am curious about why you use
'!HAVE_DECL_AT
On Sat, 2015-05-30 at 11:27 +0200, Andreas Tobler wrote:
>
> I'm sorry. I totally forgot about autoheader...
>
> I'm testing this one now. Would you mind giving it a try?
>
> Thanks,
> Andreas
This patch worked for me. I am curious about why you use
'!HAVE_DECL_ATOLL' in read-rtl.c instead of
> I come that far on Sparc Solaris 10:
>
> Comparing stages 2 and 3
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap comparison failure!
> gcc/fortran/symbol.o differs
> gcc/builtins.o differs
> gcc/real.o differs
> gcc/ubsan.o differs
> libdecnumber/deci
OK, thanks.
Jason
1 - 100 of 137 matches
Mail list logo
