Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote: > On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote: > > On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote: > > > To be constructive here - the above case is from within a > > > GIMPLE_ASSIGN case label > > > and thus

Re: How is libtool updated in GCC?

2014-11-10 Thread Joseph Myers
On Mon, 10 Nov 2014, FX wrote: > How is libtool handled in GCC? Do we import from upstream, or merge the > changes that we need? It looks like it’s done manually and selectively, > but I’d like confirmation of that. If you import rather than selectively merging one change you need (I think) to

RE: arm/thumb broken on head

2014-11-10 Thread Terry Guo
> -Original Message- > From: Richard Earnshaw > Sent: Tuesday, November 11, 2014 1:08 AM > To: Joel Sherrill; GCC Mailing List > Cc: Terry Guo > Subject: Re: arm/thumb broken on head > > On 10/11/14 15:26, Joel Sherrill wrote: > > Hi > > > > With gcc, newlib, and binutils head, arm-rtems

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

2014-11-10 Thread Andrew Pinski
On Mon, Nov 10, 2014 at 2:27 PM, David Malcolm wrote: > On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote: >> On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote: >> > To be constructive here - the above case is from within a >> > GIMPLE_ASSIGN case label >> > and thus I'd have exp

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

2014-11-10 Thread David Malcolm
On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote: > On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote: > > To be constructive here - the above case is from within a > > GIMPLE_ASSIGN case label > > and thus I'd have expected > > > > case GIMPLE_ASSIGN: > > { > >

Re: Match-and-simplify and COND_EXPR

2014-11-10 Thread Andrew Pinski
On Fri, Nov 7, 2014 at 2:23 AM, Richard Biener wrote: > On Thu, 6 Nov 2014, Andrew Pinski wrote: > >> On Thu, Nov 6, 2014 at 2:40 AM, Richard Biener wrote: >> > On Thu, 6 Nov 2014, Richard Biener wrote: >> > >> >> On Wed, 5 Nov 2014, Andrew Pinski wrote: >> >> >> >> > Hi, >> >> > I was trying t

How is libtool updated in GCC?

2014-11-10 Thread FX
Hi, libtool just released a new version to add support for OS X Yosemite (the old libtool had a poorly designed globbing pattern). It really is a one-line change (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610#c7), but we need to incorporate it into the GCC code base and rebuild all our

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

2014-11-10 Thread Jonathan Wakely
On 10 November 2014 16:49, Joel Sherrill wrote: > I just submitted a patch using stdint.h and uintptr_t to gcc-patches. libstdc++ patches must be CCd to the libstdc++ list.

Re: arm/thumb broken on head

2014-11-10 Thread Richard Earnshaw
On 10/11/14 15:26, Joel Sherrill wrote: > Hi > > With gcc, newlib, and binutils head, arm-rtems and arm-eabi both > die building libgcc2.c for the Thumb. I don't know if this is a recent > gcc change or binutils having added some new error checking. Anyone > got any ideas? > > /users/joel/test-gc

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

2014-11-10 Thread Joel Sherrill
On 11/10/2014 10:59 AM, Joseph Myers wrote: > On Mon, 10 Nov 2014, Joel Sherrill wrote: > >> On 11/10/2014 10:32 AM, Joseph Myers wrote: >>> On Sat, 8 Nov 2014, Paolo Carlini wrote: >>> Good. Sorry, if I missed some relatively recent development: is now GCC installing its own stdint.h on

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

2014-11-10 Thread Joseph Myers
On Mon, 10 Nov 2014, Joel Sherrill wrote: > On 11/10/2014 10:32 AM, Joseph Myers wrote: > > On Sat, 8 Nov 2014, Paolo Carlini wrote: > > > >> Good. Sorry, if I missed some relatively recent development: is now GCC > >> installing its own stdint.h on *all* the supported targets, thus we can > >> s

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

2014-11-10 Thread Paolo Carlini
Hi, On 11/10/2014 05:49 PM, Joel Sherrill wrote: On 11/10/2014 10:32 AM, Joseph Myers wrote: On Sat, 8 Nov 2014, Paolo Carlini wrote: Good. Sorry, if I missed some relatively recent development: is now GCC installing its own stdint.h on *all* the supported targets, thus we can safely No; I s

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

2014-11-10 Thread Joel Sherrill
On 11/10/2014 10:32 AM, Joseph Myers wrote: > On Sat, 8 Nov 2014, Paolo Carlini wrote: > >> Good. Sorry, if I missed some relatively recent development: is now GCC >> installing its own stdint.h on *all* the supported targets, thus we can >> safely > No; I sent a list of targets missing the infor

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

2014-11-10 Thread Joseph Myers
On Sat, 8 Nov 2014, Paolo Carlini wrote: > Good. Sorry, if I missed some relatively recent development: is now GCC > installing its own stdint.h on *all* the supported targets, thus we can safely No; I sent a list of targets missing the information in

Re: testing policy for C/C++ front end changes

2014-11-10 Thread Sandra Loosemore
On 11/10/2014 05:03 AM, Richard Biener wrote: On Mon, Nov 10, 2014 at 5:50 AM, Jeff Law wrote: On 11/09/14 16:13, Sandra Loosemore wrote: https://gcc.gnu.org/contribute.html#testing and noticed that the policy is to require a complete bootstrap for C changes, but not for C++. Given that GCC

arm/thumb broken on head

2014-11-10 Thread Joel Sherrill
Hi With gcc, newlib, and binutils head, arm-rtems and arm-eabi both die building libgcc2.c for the Thumb. I don't know if this is a recent gcc change or binutils having added some new error checking. Anyone got any ideas? /users/joel/test-gcc/b-arm-eabi-gcc/./gcc/xgcc -B/users/joel/test-gcc/b-arm

Re: testing policy for C/C++ front end changes

2014-11-10 Thread Richard Biener
On Mon, Nov 10, 2014 at 5:50 AM, Jeff Law wrote: > On 11/09/14 16:13, Sandra Loosemore wrote: >> >> https://gcc.gnu.org/contribute.html#testing >> >> and noticed that the policy is to require a complete bootstrap for C >> changes, but not for C++. Given that GCC's implementation language is >> no

Re: missing warnings with -Warray-bounds

2014-11-10 Thread Martin Uecker
Jakub Jelinek : > On Mon, Nov 10, 2014 at 12:52:02AM -0800, Martin Uecker wrote: > > Jakub Jelinek : ... > > The warning seems very useful to me and can easily be turned off. > > Or one could add -W(no-)warn-struct-hack if really needed. > > > > Another odd case is: > > > > struct h0b { > >

Re: missing warnings with -Warray-bounds

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 12:52:02AM -0800, Martin Uecker wrote: > Jakub Jelinek : > > On Mon, Nov 10, 2014 at 12:20:03AM -0800, Martin Uecker wrote: > > > There is also no warning in the following example > > > when the array is the last element of a struct. > > > > > > struct h3 { > > > in

Re: missing warnings with -Warray-bounds

2014-11-10 Thread Martin Uecker
Jakub Jelinek : > On Mon, Nov 10, 2014 at 12:20:03AM -0800, Martin Uecker wrote: > > There is also no warning in the following example > > when the array is the last element of a struct. > > > > struct h3 { > > int i; > > int j[3]; > > }; > > > > struct h3* h3 = malloc(sizeof(stru

Re: missing warnings with -Warray-bounds

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 12:20:03AM -0800, Martin Uecker wrote: > There is also no warning in the following example > when the array is the last element of a struct. > > struct h3 { > int i; > int j[3]; > }; > > struct h3* h3 = malloc(sizeof(struct h) + 3 * sizeof(int)); > h3->j[4]

missing warnings with -Warray-bounds

2014-11-10 Thread Martin Uecker
I am trying to get more useful warnings for array bounds. In particular I am interested in cases like this: void foo(int (*a)[3], int n, int (*b)[n]) { (*a)[4] = 1; (*b)[n + 1] = 1; } That currently even the first assignment does not produce a warning is a bit disappointing. (cl