Re: [BUILDROBOT] RISC-V: ‘profile_probability’ has not been declared

Hi Jeff! On Thu, 2017-07-13 14:43:52 -0600, Jeff Law wrote: > On 07/13/2017 02:39 PM, Jan-Benedict Glaw wrote: > > On Thu, 2017-06-29 14:27:41 +0200, Jan Hubicka wrote: > >> this is second step of the profile maintenance revamp. It implements > >>

Re: [BUILDROBOT] RISC-V: ‘profile_probability’ has not been declared

On Thu, 13 Jul 2017 13:43:52 PDT (-0700), l...@redhat.com wrote: > On 07/13/2017 02:39 PM, Jan-Benedict Glaw wrote: >> Hi Jan, >> hi Kito, Palmer and Andrew! >> >> On Thu, 2017-06-29 14:27:41 +0200, Jan Hubicka wrote: >>> this is second step of the profile maintenance revamp. It

Re: [BUILDROBOT] RISC-V: ‘profile_probability’ has not been declared

On 07/13/2017 02:39 PM, Jan-Benedict Glaw wrote: > Hi Jan, > hi Kito, Palmer and Andrew! > > On Thu, 2017-06-29 14:27:41 +0200, Jan Hubicka wrote: >> this is second step of the profile maintenance revamp. It implements >> profile_probability type which is pretty much symmetric

[BUILDROBOT] RISC-V: ‘profile_probability’ has not been declared (was: Convert profile probabilities to new type)

Hi Jan, hi Kito, Palmer and Andrew! On Thu, 2017-06-29 14:27:41 +0200, Jan Hubicka wrote: > this is second step of the profile maintenance revamp. It implements > profile_probability type which is pretty much symmetric to profile_count > except that it implements fixed point

Re: [BUILDROBOT] error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ (was: [PATCH] [ARC] Recognise add_n and sub_n in combine again)

Hi Graham, On Mon, 2017-06-12 11:40:39 +0200, Jan-Benedict Glaw wrote: > On Fri, 2017-05-12 20:14:23 +0100, Graham Markall > wrote: > > Since the combine pass canonicalises shift-add insns using plus and > > ashift (as opposed to plus and mult

Re: [BUILDROBOT] No rule to make target '/home/jbglaw/repos/gcc/gcc/config/rs6000/e500.h', needed by 's-gtype' (was: [PATCH 01/14] rs6000: Remove TARGET_FPRS)

SF,DF}_SPE always false. Many patterns in spe.md > > can now be deleted; which makes it possible to merge e.g. negdd2 with > > *negdd2_fpr. > > > > Finally, e500.h is deleted (it isn't used). > > A Buildrobot build from today for powerpc-rtems still seems t

[BUILDROBOT] No rule to make target '/home/jbglaw/repos/gcc/gcc/config/rs6000/e500.h', needed by 's-gtype' (was: [PATCH 01/14] rs6000: Remove TARGET_FPRS)

makes it possible to merge e.g. negdd2 with > *negdd2_fpr. > > Finally, e500.h is deleted (it isn't used). A Buildrobot build from today for powerpc-rtems still seems to use it, see build http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=704903: g++ -c -g -O2 -DIN_GCC -DCROSS

[BUILDROBOT] error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ (was: [PATCH] [ARC] Recognise add_n and sub_n in combine again)

On Fri, 2017-05-12 20:14:23 +0100, Graham Markall wrote: > Since the combine pass canonicalises shift-add insns using plus and > ashift (as opposed to plus and mult which it previously used to do), it > no longer creates *add_n or *sub_n insns, as the patterns match

Re: [BUILDROBOT] Maybe uninitialized warnings in mips targets

On 03/18/2017 12:20 PM, Jan-Benedict Glaw wrote: Hi Richard, Catherine, Matthew On Thu, 2017-03-02 14:40:46 +0100, Richard Biener wrote: [...] On IRC we decided to wait for the TREE_NO_WARNING issue. So the following is what I committed. Bootstrapped / tested on

Re: [BUILDROBOT] Maybe uninitialized warnings in mips targets

On 03/18/2017 12:20 PM, Jan-Benedict Glaw wrote: Hi Richard, Catherine, Matthew On Thu, 2017-03-02 14:40:46 +0100, Richard Biener wrote: [...] On IRC we decided to wait for the TREE_NO_WARNING issue. So the following is what I committed. Bootstrapped / tested on

[BUILDROBOT] Maybe uninitialized warnings in mips targets (was: [PATCH] Fix PR79345, better uninit warnings for memory)

Hi Richard, Catherine, Matthew On Thu, 2017-03-02 14:40:46 +0100, Richard Biener wrote: [...] > On IRC we decided to wait for the TREE_NO_WARNING issue. So the > following is what I committed. > > Bootstrapped / tested on x86_64-unknown-linux-gnu. [...] > 2017-03-02 Richard

Re: [BUILDROBOT] arm-netbsdelf: Error during -fself-test (was: [PATCH] TS_OPTIMIZATION/TS_TARGET_OPTION need no chain/type)

On Mon, 2017-02-27 09:19:51 +0100, Richard Biener wrote: > On Mon, 27 Feb 2017, Jan-Benedict Glaw wrote: > > On Wed, 2017-01-11 16:28:33 +0100, Richard Biener wrote: > > > On Wed, 11 Jan 2017, Richard Biener wrote: > > > > LTO bootstrapped on

Re: [BUILDROBOT] arm-netbsdelf: Error during -fself-test (was: [PATCH] TS_OPTIMIZATION/TS_TARGET_OPTION need no chain/type)

On Mon, 27 Feb 2017, Jan-Benedict Glaw wrote: > Hi Richard, > > On Wed, 2017-01-11 16:28:33 +0100, Richard Biener wrote: > > On Wed, 11 Jan 2017, Richard Biener wrote: > > > LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > > > > > (most "gross" are

[BUILDROBOT] arm-netbsdelf: Error during -fself-test (was: [PATCH] TS_OPTIMIZATION/TS_TARGET_OPTION need no chain/type)

Hi Richard, On Wed, 2017-01-11 16:28:33 +0100, Richard Biener wrote: > On Wed, 11 Jan 2017, Richard Biener wrote: > > LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > > > (most "gross" are still TS_LIST having a type and TS_VEC having type > > and chain,

Re: [BUILDROBOT] dwarf2out.c:22452:14: error: variable ‘origin_die’ set but not used [-Werror=unused-but-set-variable]

On Tue, Nov 01, 2016 at 11:34:08PM +0100, Jan-Benedict Glaw wrote: > Hi Jakub! > > Seems this patch caused some breakage when building via > config-list.mk with a recent compiler (ie. with itself) : > > +2016-11-01 Jakub Jelinek > + > + * dwarf2out.c

Re: [BUILDROBOT] [Ada] error: alignment of array elements is greater than element size (was: [PATCH] GIMPLE store merging pass)

On 2016.10.29 at 19:56 +0200, Jan-Benedict Glaw wrote: > Hi Kyrill! > > On Mon, 2016-10-24 15:56:48 +0100, Kyrill Tkachov > wrote: > > This is a slight update over [1] with Richard's feedback addressed. > > In terminate_all_aliasing_chains we now terminate the chain

[BUILDROBOT] [Ada] error: alignment of array elements is greater than element size (was: [PATCH] GIMPLE store merging pass)

Hi Kyrill! On Mon, 2016-10-24 15:56:48 +0100, Kyrill Tkachov wrote: > This is a slight update over [1] with Richard's feedback addressed. > In terminate_all_aliasing_chains we now terminate the chain early if > the destination is writing to a base offset by a

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

Hi! On Wed, 5 Oct 2016 16:36:01 +0200, Bernd Schmidt wrote: > On 10/05/2016 04:14 PM, David Malcolm wrote: > > Thanks. I'm not able to formally approve these changes, but FWIW these > > patches look good to me (assuming usual testing). > > LGTM too, so OK. Without

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

On 10/05/2016 04:14 PM, David Malcolm wrote: Thanks. I'm not able to formally approve these changes, but FWIW these patches look good to me (assuming usual testing). LGTM too, so OK. Bernd

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

On Wed, 2016-10-05 at 14:34 +0200, Thomas Schwinge wrote: > Hi! > > I've now also run into this issue, during contrib/config-list.mk > testing; > log/arm-wrs-vxworks-make.out, log/i686-wrs-vxworks-make.out, > log/i686-wrs-vxworksae-make.out, log/mips-wrs-vxworks-make.out, >

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

Hi! I've now also run into this issue, during contrib/config-list.mk testing; log/arm-wrs-vxworks-make.out, log/i686-wrs-vxworks-make.out, log/i686-wrs-vxworksae-make.out, log/mips-wrs-vxworks-make.out, log/powerpc-wrs-vxworks-make.out, log/powerpc-wrs-vxworksae-make.out,

Re: [BUILDROBOT] dwarf2out_do_cfi_startproc(bool)’: may write a terminating nul past the end of the destination

OK. On Sat, Oct 1, 2016 at 4:30 PM, Jakub Jelinek wrote: > On Fri, Sep 30, 2016 at 08:59:52PM +0200, Jakub Jelinek wrote: >> Ok if it passes bootstrap/regtest? > > Passed bootstrap/regtest on x86_64-linux and i686-linux. >> >> 2016-09-30 Jakub Jelinek >> >>

Re: [BUILDROBOT] dwarf2out_do_cfi_startproc(bool)’: may write a terminating nul past the end of the destination

On Fri, Sep 30, 2016 at 08:59:52PM +0200, Jakub Jelinek wrote: > Ok if it passes bootstrap/regtest? Passed bootstrap/regtest on x86_64-linux and i686-linux. > > 2016-09-30 Jakub Jelinek > > * dwarf2out.c (output_fde, output_call_frame_info, >

Re: [BUILDROBOT] dwarf2out_do_cfi_startproc(bool)’: may write a terminating nul past the end of the destination

On Fri, Sep 30, 2016 at 07:07:22PM +0200, Jan-Benedict Glaw wrote: > When building for --target=sparc-leon-elf (using config-list.mk) with > a current GCC, I get this error message (cf. > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=632317): > > g++ -fno-PIE -c -g -O2 -DIN_GCC

Re: [BUILDROBOT] tic6x-uclinux: undefined reference to `gnu_libc_printf_pointer_format(tree_node*, char const**)' (was: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905))

On Tue, Sep 27, 2016 at 12:08:46AM +0200, Jan-Benedict Glaw wrote: > Hi Martin, > > On Thu, 2016-09-08 13:03:12 -0600, Martin Sebor wrote: > > Attached is another update to the patch to address the last round > > of comments and suggestions, most notably to: > [...] > > with

Re: [BUILDROBOT] tic6x-uclinux: undefined reference to `gnu_libc_printf_pointer_format(tree_node*, char const**)'

On 09/26/2016 04:08 PM, Jan-Benedict Glaw wrote: Hi Martin, On Thu, 2016-09-08 13:03:12 -0600, Martin Sebor wrote: Attached is another update to the patch to address the last round of comments and suggestions, most notably to: [...] with the currently committed version,

[BUILDROBOT] tic6x-uclinux: undefined reference to `gnu_libc_printf_pointer_format(tree_node*, char const**)' (was: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905))

Hi Martin, On Thu, 2016-09-08 13:03:12 -0600, Martin Sebor wrote: > Attached is another update to the patch to address the last round > of comments and suggestions, most notably to: [...] with the currently committed version, the tic6x-uclinux target fails, see ie.

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

On 09/19/2016 04:24 PM, Bernd Edlinger wrote: On 09/19/16 23:51, Jeff Law wrote: On 09/17/2016 05:29 PM, Bernd Edlinger wrote: On 09/17/16 22:29, Jan-Benedict Glaw wrote: On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger wrote: Hi, I think it is time to remove

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

On 09/19/16 23:51, Jeff Law wrote: > On 09/17/2016 05:29 PM, Bernd Edlinger wrote: >> On 09/17/16 22:29, Jan-Benedict Glaw wrote: >>> On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger >>> wrote: Hi, I think it is time to remove support for

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

On 09/17/2016 05:29 PM, Bernd Edlinger wrote: On 09/17/16 22:29, Jan-Benedict Glaw wrote: On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger wrote: Hi, I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which is no longer used by any target

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

On 09/17/16 22:29, Jan-Benedict Glaw wrote: > On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger > wrote: >> Hi, >> >> I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which >> is no longer >> used by any target today. This removes a bunch of

[BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope (was: [PATCH] Remove support for INITIAL_FRAME_POINTER_OFFSET)

On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger wrote: > Hi, > > I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which > is no longer > used by any target today. This removes a bunch of conditional code, and > fixes a few bits > in the

Re: [BUILDROBOT] x86_64: Segmentation fault during -fself-test (was: Implement C _FloatN, _FloatNx types [version 6]

On Mon, 22 Aug 2016, Jan-Benedict Glaw wrote: > Between dee8cef0c1c1ebf85fceb5c37996ed12a2bec352 (Fri Aug 19 15:42:11 > 2016 +) and 82c85aba845985e55c27a7a9c448810d433adb17 (Fri Aug 19 > 17:43:26 2016 +), a new build regression for > x86_64-{linux,rtems,elf} showed up and I think this

[BUILDROBOT] x86_64: Segmentation fault during -fself-test (was: Implement C _FloatN, _FloatNx types [version 6]

Hi Joseph! On Wed, 2016-08-17 20:17:07 +, Joseph Myers wrote: [...] > ISO/IEC TS 18661-3:2015 defines C bindings to IEEE interchange and > extended types, in the form of _FloatN and _FloatNx type names with > corresponding fN/FN and fNx/FNx constant suffixes and

Re: [BUILDROBOT] avr broken

On Tue, 2016-08-16 14:26:38 -0400, Nathan Sidwell wrote: > On 08/16/16 13:04, Jan-Benedict Glaw wrote: > > > That'll probably work. But after all, I'm not an AVR maintainer > > (not even an user), but just running the Build Robot. > > Does your robot approve? :) Ohoooh! See

Re: [BUILDROBOT] avr broken

On 08/17/2016 09:20 AM, Denis Chertykov wrote: > 2016-08-16 21:26 GMT+03:00 Nathan Sidwell : >> On 08/16/16 13:04, Jan-Benedict Glaw wrote: >> >>> That'll probably work. But after all, I'm not an AVR maintainer (not >>> even an user), but just running the Build Robot. >> >> >> Does

Re: [BUILDROBOT] avr broken

2016-08-16 21:26 GMT+03:00 Nathan Sidwell : > On 08/16/16 13:04, Jan-Benedict Glaw wrote: > >> That'll probably work. But after all, I'm not an AVR maintainer (not >> even an user), but just running the Build Robot. > > > Does your robot approve? :) > I'm an AVR maintainer. The

Re: [BUILDROBOT] avr broken

On 08/16/16 13:04, Jan-Benedict Glaw wrote: That'll probably work. But after all, I'm not an AVR maintainer (not even an user), but just running the Build Robot. Does your robot approve? :)

Re: [BUILDROBOT] avr broken

On 08/16/16 10:23, Martin Liška wrote: On 08/16/2016 03:36 PM, Nathan Sidwell wrote: On 08/16/16 08:49, Martin Liška wrote: On 08/13/2016 02:14 PM, Jan-Benedict Glaw wrote: This doesn't work for AVR since their LONG_LONG_TYPE_SIZE depents on target flags (see eg. build

Re: [BUILDROBOT] avr broken

On 08/16/16 08:49, Martin Liška wrote: On 08/13/2016 02:14 PM, Jan-Benedict Glaw wrote: This doesn't work for AVR since their LONG_LONG_TYPE_SIZE depents on target flags (see eg. build http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=602648) Hello. Sorry for the breakage, I

[BUILDROBOT] avr broken (was: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch)

On Fri, 2016-08-05 15:43:02 +0200, Martin Liška wrote: [...] > Great, attaching install candidate. > >From 0b3ac8636ef34b02e301f22c86dde0602f9969ef Mon Sep 17 00:00:00 2001 > From: marxin > Date: Thu, 28 Jul 2016 14:32:47 +0200 > Subject: [PATCH 1/4] Cherry-pick

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

On Thu, 2016-06-30 16:09:23 -0400, David Malcolm wrote: > On Thu, 2016-06-30 at 08:38 -0400, Nathan Sidwell wrote: > > > I haven't given it any additional manual testing so far. It's > > > pre-installation though. Maybe I'd just set WIND_BASE to some > > > arbitrary value,

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

On Thu, 2016-06-30 at 08:38 -0400, Nathan Sidwell wrote: > Jan-Benedict, > > > I haven't given it any additional manual testing so far. It's > > pre-installation though. Maybe I'd just set WIND_BASE to some > > arbitrary value, just to make xgcc pass it's initial start-up test > > so > > that it

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

Jan-Benedict, I haven't given it any additional manual testing so far. It's pre-installation though. Maybe I'd just set WIND_BASE to some arbitrary value, just to make xgcc pass it's initial start-up test so that it can continue with self-testing? Or shall we set some value in gcc/Makefile.in

[BUILDROBOT] Selftest failed for i686-wrs-vxworks

Hi Nathan! The recent self-testing fails for i686-wrs-vxworks: /home/jbglaw/build-configlist_mk/i686-wrs-vxworks/build-gcc/mk/i686-wrs-vxworks/./gcc/xgcc -B/home/jbglaw/build-configlist_mk/i686-wrs-vxworks/build-gcc/mk/i686-wrs-vxworks/./gcc/ -xc -S -c /dev/null -fself-test xgcc: fatal error:

Re: [BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

On Sat, Jun 18, 2016 at 9:56 AM, David Malcolm wrote: > On Sat, 2016-06-18 at 15:06 +0200, Jan-Benedict Glaw wrote: >> Hi David, Segher, Aldy! >> >> Davids new selftest code found something for the rs6000-ibm-aix4.3 >> target, maybe you're interested: >> >>

Re: [BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

On Sat, 2016-06-18 at 15:06 +0200, Jan-Benedict Glaw wrote: > Hi David, Segher, Aldy! > > Davids new selftest code found something for the rs6000-ibm-aix4.3 > target, maybe you're interested: > > /home/jbglaw/src/toolchain/build/./gcc/xgcc > -B/home/jbglaw/src/toolchain/build/./gcc/ -xc -S -c

[BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

Hi David, Segher, Aldy! Davids new selftest code found something for the rs6000-ibm-aix4.3 target, maybe you're interested: /home/jbglaw/src/toolchain/build/./gcc/xgcc -B/home/jbglaw/src/toolchain/build/./gcc/ -xc -S -c /dev/null -fself-test : internal compiler error: in altivec_init_builtins,

Re: [BUILDROBOT] MPS430 build problem due to new enum

On 06/13/2016 10:46 AM, Jan Hubicka wrote: > Hmm, namespace conflict. I guess renaming enum items to REASON_* should > solve it easily. > Or we can add a namespace. > > Martin, both variants of fix are pre-approved. > Honza OK, I've just installed (r237370) a patch that prefixes all enum

Re: [BUILDROBOT] MPS430 build problem due to new enum (was: [PATCH 2/2] Add edge predictions pruning)

> Hi Martin, > > On Thu, 2016-06-09 13:24:10 +0200, Martin Liška wrote: > > On 06/08/2016 02:41 PM, Jan Hubicka wrote: > > > Adding hash for this prupose is bit of an overkill (there are > > > definitly cheaper ways of solving so), but it will hardly affect compile > > > time, so

Re: [BUILDROBOT] MPS430 build problem due to new enum

On 06/12/2016 01:55 PM, Jan-Benedict Glaw wrote: > The new `NONE' from your enum clashes with a NONE used in a MSP430 > private enum. > > MfG, JBG Hi. Thanks for having heads up, I've been testing following patch. The patch survives with --target=msp430-elf. Ready after it finishes? Thanks,

[BUILDROBOT] MPS430 build problem due to new enum (was: [PATCH 2/2] Add edge predictions pruning)

Hi Martin, On Thu, 2016-06-09 13:24:10 +0200, Martin Liška wrote: > On 06/08/2016 02:41 PM, Jan Hubicka wrote: > > Adding hash for this prupose is bit of an overkill (there are > > definitly cheaper ways of solving so), but it will hardly affect compile > > time, so the pathc is

RE: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

than Wakely; > gcc-patches > Subject: Re: [BUILDROBOT] "error: null argument where non-null required" > on multiple targets > > On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote: > > On Tue, 2015-12-15 10:43:58 -0700, Jeff Law <l...@redhat.com> wrote: > >&g

config-list.mk and obsoleted configurations (was: [BUILDROBOT] "error: null argument where non-null required" on multiple targets)

On Thu, 2015-12-17 11:05:42 -0700, Jeff Law wrote: > On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote: > > Shall I bisect one of the cases anew, with the "Test value of > > _GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that > > uncovered it, applied? Starting with some

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote: On Tue, 2015-12-15 10:43:58 -0700, Jeff Law wrote: On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote: On Mon, 2015-12-14 18:54:28 +, Moore, Catherine wrote: avr-rtems

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

On Tue, 2015-12-15 10:43:58 -0700, Jeff Law wrote: > On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote: > >On Mon, 2015-12-14 18:54:28 +, Moore, Catherine > > wrote: > >>>avr-rtems >

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote: On Mon, 2015-12-14 18:54:28 +, Moore, Catherine wrote: avr-rtems http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544 mipsel-elf

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

On Mon, 2015-12-14 18:54:28 +, Moore, Catherine wrote: > > avr-rtems > > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544 > > mipsel-elf > > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844 > >

RE: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

akely; gcc-patches > Subject: [BUILDROBOT] "error: null argument where non-null required" on > multiple targets > > Hi! > > I'm not 100% sure, but I *think* that this patch > > 2015-11-15 Jonathan Wakely <jwak...@redhat.com> > >

Re: [BUILDROBOT] ./insn-flags.h:342:7: error: ‘operands’ was not declared in this scope

Jan-Benedict Glaw wrote: > shle-linux breaks with: > > g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute >

[BUILDROBOT] ./insn-flags.h:342:7: error: ‘operands’ was not declared in this scope (was: Add an rsqrt_optab and IFN_RSQRT internal function)

On Thu, 2015-12-03 09:21:03 +, Richard Sandiford wrote: > All current uses of builtin_reciprocal convert 1.0/sqrt into rsqrt. > This patch adds an rsqrt optab and associated internal function for > that instead. We can then pick up the vector forms of rsqrt

[BUILDROBOT] "error: null argument where non-null required" on multiple targets

Hi! I'm not 100% sure, but I *think* that this patch 2015-11-15 Jonathan Wakely PR libstdc++/68353 * include/bits/basic_string.h: Test value of _GLIBCXX_USE_C99_WCHAR not whether it is defined.

Re: [BUILDROBOT] Bootstrap broken in Ada

On 10/11/2015 02:58 PM, Jan-Benedict Glaw wrote: On Thu, 2015-10-08 09:37:03 -0400, Andrew MacLeod wrote: [...] Heres the patch for reordered headers. Building as we speak. Hard to fully verify since Ada doesn't seem to bootstrap on trunk at the moment:

Re: [BUILDROBOT] Bootstrap broken in Ada

> On 10/11/2015 02:58 PM, Jan-Benedict Glaw wrote: > >On Thu, 2015-10-08 09:37:03 -0400, Andrew MacLeod > >wrote: > >[...] > >>Heres the patch for reordered headers. Building as we speak. Hard to fully > >>verify since Ada doesn't seem to bootstrap on trunk at the moment:

[BUILDROBOT] Bootstrap broken in Ada (was: [patch] header file re-ordering.)

On Thu, 2015-10-08 09:37:03 -0400, Andrew MacLeod wrote: [...] > Heres the patch for reordered headers. Building as we speak. Hard to fully > verify since Ada doesn't seem to bootstrap on trunk at the moment: > > +===GNAT BUG

[commit, spu] Re: [BUILDROBOT] spu: left shift of negative value

Jan-Benedict Glaw wrote: > I just noticed that (for config_list.mk builds), current GCC errors > out at spu.c, see eg. build > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=3D469639 : > > g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-excep= > tions

Re: [BUILDROBOT] Go runtime: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe

On 08/03/2015 08:48 AM, Martin Sebor wrote: On 08/03/2015 05:55 AM, Jan-Benedict Glaw wrote: On Sun, 2015-08-02 17:15:27 -0600, Martin Sebor mse...@gmail.com wrote: OK for the trunk. Sorry for the delay. Thank you. Committed in revision 226480. ...und breaks native builds. When doing

Re: [BUILDROBOT] Go runtime: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe

On 08/03/2015 05:55 AM, Jan-Benedict Glaw wrote: On Sun, 2015-08-02 17:15:27 -0600, Martin Sebor mse...@gmail.com wrote: OK for the trunk. Sorry for the delay. Thank you. Committed in revision 226480. ...und breaks native builds. When doing builds using config-list.mk, I first build a GCC

Re: [BUILDROBOT]

, constm1_operand) (constable_operand): Accept vector operands. * config/s390/s390-modes.def: Add supported vector modes. * config/s390/s390-protos.h (s390_cannot_change_mode_class) [...] Starting with this patch, it seems my buildrobot won't be able to build a s390{,x}-linux compiler

Re: [BUILDROBOT] arc-elf: match_code REG matches nothing

Jan-Benedict Glaw jbg...@lug-owl.de writes: On Fri, 2015-05-22 16:42:44 +0100, Richard Sandiford richard.sandif...@arm.com wrote: This patch adjusts the fix for PR target/65689 along the lines suggested in https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01559.html. The idea is to reuse the

Re: [BUILDROBOT] RFA: RL78: Add support for G13 and G14 multiply and divide

Hi Jan-Benedict. ../../../gcc/gcc/config/rl78/rl78.c:390:14: error: enumeration value ‘MUL_RL78’ not handled in switch [-Werror=switch] switch (rl78_mul_type) ../../../gcc/gcc/config/rl78/rl78.c:4649:34: error: unused parameter ‘x’ [-Werror=unused-parameter]

[BUILDROBOT] tilepro-linux/tilegx-linux fallout from flattening (was: [PATCH] Flatten tree.h and tree-core.h (Version 3))

On Sat, 2015-01-10 01:50:42 +0530, Prathamesh Kulkarni prathamesh.kulka...@linaro.org wrote: On 9 January 2015 at 16:21, Richard Biener richard.guent...@gmail.com wrote: On Fri, Jan 9, 2015 at 10:39 AM, Michael Collison michael.colli...@linaro.org wrote: This patch flattens tree.h and

Re: [BUILDROBOT] tilepro-linux/tilegx-linux fallout from flattening

On 12 January 2015 at 11:19, Michael Collison michael.colli...@linaro.org wrote: The issue is that tilegx includes expr.h which includes tree-core.h. A simple solution is to include symtab.h before expr.h in tilegx.c. The port has a unrelated link error after this change. Yes, I am seeing this

Re: [BUILDROBOT] tilepro-linux/tilegx-linux fallout from flattening

The issue is that tilegx includes expr.h which includes tree-core.h. A simple solution is to include symtab.h before expr.h in tilegx.c. The port has a unrelated link error after this change. The second possiblity is to resolve this using Prathmesh latest patch (submitted today) for

Re: [BUILDROBOT, PATCH] config-list.mk: Extract target name correctly

On 12/29/14 13:02, Jan-Benedict Glaw wrote: Hi! With my last change, `sed' is used to cut out the target name from a listed target. Since there may be additional OPTions encoded in the target, I tried to get only the first submatch before an `OPT'. However, `sed' uses longest match, so I'm

[BUILDROBOT, PATCH] config-list.mk: Extract target name correctly

Hi! With my last change, `sed' is used to cut out the target name from a listed target. Since there may be additional OPTions encoded in the target, I tried to get only the first submatch before an `OPT'. However, `sed' uses longest match, so I'm re-writing this using awk. If anybody is like

[BUILDROBOT, PATCH] MSP430: Fix unused arg warning

Hi! The build robot found this: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros

Re: [BUILDROBOT, PATCH] MSP430: Fix unused arg warning

Hi Jan-Benedict, 2014-12-17 Jan-Benedict Glaw jbg...@lug-owl.de * config/msp430/msp430.c (msp430_asm_output_addr_const_extra): Fix unused argument warning. Approved - please apply. Cheers Nick

Re: [BUILDROBOT, PATCH] MSP430: Fix unused arg warning

Hi Nick, On Wed, 2014-12-17 17:05:09 +, Nicholas Clifton ni...@redhat.com wrote: 2014-12-17 Jan-Benedict Glaw jbg...@lug-owl.de * config/msp430/msp430.c (msp430_asm_output_addr_const_extra): Fix unused argument warning. Approved - please apply. Thanks. Committed as

[BUILDROBOT] Fallout for aarch64_be-elf (was: [PATCH] Rename gimple_build_assign_with_ops to gimple_build_assign and swap the first two arguments of it)

On Mon, 2014-12-01 14:52:05 +0100, Jakub Jelinek ja...@redhat.com wrote: On Fri, Nov 28, 2014 at 08:02:23PM +0100, Jakub Jelinek wrote: As possible follow-up, I wonder if gimple_build_assign_with_ops isn't too long and too verbose either, couldn't we just use overloads of

Re: [BUILDROBOT] nios2: build breakage

On 11/15/2014 06:46 PM, Sandra Loosemore wrote: On 11/15/2014 04:49 PM, Jan-Benedict Glaw wrote: Hi, On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka hubi...@ucw.cz wrote: Yep, it is because my code does not handle streaming of arrays into the target optimization nodes. I will take a look on

Re: [BUILDROBOT] nios2: build breakage

Sandra, I can explain why this is needed, at least. The Nios II architecture optionally allows custom instructions that are typically used to implement floating-point operations. The nios2 GCC backend knows to generate these instructions if the user tells it what opcodes implement these

Re: [BUILDROBOT] nios2: build breakage

On 11/19/2014 09:34 PM, Jan Hubicka wrote: [snip] I see three possible fixes: 1) extend the AWk script to recognize arrays and stream them specially (it already recognizes string so it is not hard to do, just bit wasteful) 2) add attribute to .opt file allowing user to specify his own

[BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich enkovich@gmail.com wrote: Hi, This patch adds support of instrumented builtin calls in expand. Calls are mostly expanded as calls. But some of them reuse existing string function calls expand functions (memcpy expand was slightly

Re: [BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote: On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich enkovich@gmail.com wrote: Hi, This patch adds support of instrumented builtin calls in expand. Calls are mostly expanded as calls. But some of them reuse existing string

Re: [BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote: On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich enkovich@gmail.com wrote: [...] It seems this part of the patch series causes some build

Re: [BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

On 17 Nov 16:12, Jan-Benedict Glaw wrote: On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote: On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich enkovich@gmail.com wrote: [...] It seems this

Re: [BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

On Mon, 2014-11-17 19:17:34 +0300, Ilya Enkovich enkovich@gmail.com wrote: On 17 Nov 16:12, Jan-Benedict Glaw wrote: On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote: On Thu, 2014-11-06

Re: [BUILDROBOT] error: �??cl_target_option_stream_in�?? was not declared in this scope (was: LTO streaming of TARGET_OPTIMIZE_NODE)

On Fri, 2014-11-14 19:53:33 +0100, Jan Hubicka hubi...@ucw.cz wrote: Breaks build: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute

[BUILDROBOT] nios2: build breakage (was: Rerog streaming of OPTIMIZATION_NODE)

Hi, On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka hubi...@ucw.cz wrote: Yep, it is because my code does not handle streaming of arrays into the target optimization nodes. I will take a look on why that array is really needed. It seems like a overkill? I am looking into the

Re: [BUILDROBOT] nios2: build breakage

On 11/15/2014 04:49 PM, Jan-Benedict Glaw wrote: Hi, On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka hubi...@ucw.cz wrote: Yep, it is because my code does not handle streaming of arrays into the target optimization nodes. I will take a look on why that array is really needed. It seems like a

[BUILDROBOT] error: ‘cl_target_option_stream_in’ was not declared in this scope (was: LTO streaming of TARGET_OPTIMIZE_NODE)

On Fri, 2014-11-14 01:37:14 +0100, Jan Hubicka hubi...@ucw.cz wrote: Hi, here is upated version with bitfields and also tested on PPC64-linux/aix. I hacked configury to use system awk instead of gawk, so the changes are hopefully safe. OK? Honza * optc-save-gen.awk: Output

Re: [BUILDROBOT] error: �??cl_target_option_stream_in�?? was not declared in this scope (was: LTO streaming of TARGET_OPTIMIZE_NODE)

Breaks build: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros

[PATCH, BUILDROBOT] SH: Fix unused variable warning (was: [SH][committed] PR 53513 - Add __builtin_sh_get_fpscr, __builtin_sh_set_fpscr)

On Sat, 2014-10-18 12:54:33 +0200, Oleg Endo oleg.e...@t-online.de wrote: Hi, As discussed in the PR, this adds two new SH built-in functions __builtin_sh_get_fpscr __builtin_sh_set_fpscr. Tested on r216173 with make -k check RUNTESTFLAGS=--target_board=sh-sim\{-m4/-ml,-m4/-mb} and

Re: [PATCH, BUILDROBOT] SH: Fix unused variable warning (was: [SH][committed] PR 53513 - Add __builtin_sh_get_fpscr, __builtin_sh_set_fpscr)

On 4 Nov 2014, at 11:50, Jan-Benedict Glaw jbg...@lug-owl.de wrote: On Sat, 2014-10-18 12:54:33 +0200, Oleg Endo oleg.e...@t-online.de wrote: Hi, As discussed in the PR, this adds two new SH built-in functions __builtin_sh_get_fpscr __builtin_sh_set_fpscr. Tested on r216173 with

Re: [PATCH, BUILDROBOT] SH: Fix unused variable warning (was: [SH][committed] PR 53513 - Add __builtin_sh_get_fpscr, __builtin_sh_set_fpscr)

On Tue, 2014-11-04 13:21:24 +0100, Oleg Endo oleg.e...@t-online.de wrote: On 4 Nov 2014, at 11:50, Jan-Benedict Glaw jbg...@lug-owl.de wrote: 2014-11-04 Jan-Benedict Glaw jbg...@lug-owl.de * config/sh/sh.c (emit_fpu_switch): Drop unused automatic variable. [...] This should fix

[PATCH] [BUILDROBOT] RX: Mark unused argument

Hi! I noticed that rx_handle_func_attribute() doesn't use it's `args' argument any longer since DJ removed it's a gcc_assert() using it. See eg. this build: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372376 [...] g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE

[BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen zhenqiang.c...@arm.com wrote: Hi, The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4. Bootstrap and no make check regression on X86-64. Will add new test cases after ccmp is enabled. Ok for trunk? This seems to uncover

Re: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

On Mon, Nov 03, 2014 at 11:06:06AM +0100, Jan-Benedict Glaw wrote: On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen zhenqiang.c...@arm.com wrote: Hi, The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4. Bootstrap and no make check regression on X86-64. Will add new test

Re: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

On Mon, 2014-11-03 11:06:06 +0100, Jan-Benedict Glaw jbg...@lug-owl.de wrote: On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen zhenqiang.c...@arm.com wrote: Hi, The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4. Bootstrap and no make check regression on X86-64. Will

  1   2   3   >