Re: VEC re-write [patch 01/25]

2012-11-25 Thread Richard Biener
On Sun, Nov 18, 2012 at 6:12 PM, Diego Novillo dnovi...@google.com wrote:
 On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson h...@bitrange.com 
 wrote:
 On Sat, 17 Nov 2012, Diego Novillo wrote:
 I have now committed all 25 parts of this patch as rev 193595.  Please
 CC me on any problems that you think may be related to this rewrite.

 That seems to have trigged some bug in gcc-4.4-era.  See
 PR55381.  There are a lot of suspicious warnings from vec.h.
 It smells a bit like a host gcc bug, but I'll have to find a
 newer version where it builds to confirm.  (If so, hopefully
 it's as simple as upping the minimum host gcc version or
 blacklisting gcc-4.4.x.)

 Yeah, I got those warnings in my sparc and hppa builds, but they are
 harmless.  Strictly speaking offsetof cannot be applied to non-PODs.
 The only thing that makes that class non-POD is the protected
 attribute, but that does not alter the physical layout.  So the
 compiler is emitting a harmless warning (newer versions have
 tightened the check to warn when you are using offsetof on a non-base
 class).

Doesn't that mean that a non-GCC host compiler might fail to build
4.8 during stage1?

Richard.

 My cris-elf builds worked fine, but config-list.mk only builds stage
 1, it does not build libgfortran.  Can you give me instructions on how
 to build your target on my x86 workstation?


 Thanks.  Diego.


Re: VEC re-write [patch 01/25]

2012-11-25 Thread Diego Novillo
On Sun, Nov 25, 2012 at 8:11 AM, Richard Biener
richard.guent...@gmail.com wrote:

 Doesn't that mean that a non-GCC host compiler might fail to build
 4.8 during stage1?

Yes.  Fixed last week.  vec needed to become a pure POD.  So sad.


Diego.


Re: VEC re-write [patch 01/25]

2012-11-20 Thread Ulrich Weigand
Diego Novillo wrote:
 On Thu, Nov 15, 2012 at 4:53 PM, Diego Novillo dnovi...@google.com wrote:
 
  I have tested the patch pretty extensively:
 
  - Regular bootstraps on x86_64, ppc, ia64, sparc and hppa.
  - Bootstraps with --enable-checking=release
  - Bootstraps with --enable-checking=gc,gcac
  - Basic builds on all targets (using contrib/config-list.mk).
 
 I have now committed all 25 parts of this patch as rev 193595.  Please
 CC me on any problems that you think may be related to this rewrite.

This breaks an spu-elf cross-compiler built on a powerpc64-linux host
using a gcc 4.1.2 host compiler  (i.e. RHEL5.x, which is the latest RHEL
distro that still supports running on Cell/B.E.).

I'm getting errors along the lines of:

/home/uweigand/fsf/gcc-head/gcc/tree-data-ref.c: In function 
'conflict_function* conflict_fn(unsigned int, ...)':
/home/uweigand/fsf/gcc-head/gcc/tree-data-ref.c:1599: warning: cannot receive 
objects of non-POD type 'class affine_fn' through '...'; call will abort at 
runtime

And indeed it does then abort at runtime when building libgfortran
(with -ftree-vectorize enabled).

affine_fn is defined in tree-data-ref.h as:
typedef vectree affine_fn;
which apparently is no longer a POD type?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com



Re: VEC re-write [patch 01/25]

2012-11-19 Thread David Edelsohn
On Sun, Nov 18, 2012 at 10:18 PM, Ian Lance Taylor i...@google.com wrote:
 On Sun, Nov 18, 2012 at 5:14 PM, David Edelsohn dje@gmail.com wrote:

 The problem is AIX stdlib.h defines

 #define vec_free free

 Ouch.

 I am not sure where

 #undef vec_free

 should be placed.  In vec.h or system.h?

 I think system.h.

Committing as obvious.

Thanks, David

* system.h (vec_free): Undef.

Index: system.h
===
--- system.h(revision 193623)
+++ system.h(working copy)
@@ -228,6 +228,9 @@
 # include stdlib.h
 #endif

+/* Undef vec_free from AIX stdlib.h header which conflicts with vec.h.  */
+#undef vec_free
+
 /* If we don't have an overriding definition, set SUCCESS_EXIT_CODE and
FATAL_EXIT_CODE to EXIT_SUCCESS and EXIT_FAILURE respectively,
or 0 and 1 if those macros are not defined.  */


Re: VEC re-write [patch 01/25]

2012-11-19 Thread Jack Howarth
On Sun, Nov 18, 2012 at 11:15:22AM -0800, Andrew Pinski wrote:
 On Sun, Nov 18, 2012 at 9:12 AM, Diego Novillo dnovi...@google.com wrote:
  On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson h...@bitrange.com 
  wrote:
  On Sat, 17 Nov 2012, Diego Novillo wrote:
  I have now committed all 25 parts of this patch as rev 193595.  Please
  CC me on any problems that you think may be related to this rewrite.
 
  That seems to have trigged some bug in gcc-4.4-era.  See
  PR55381.  There are a lot of suspicious warnings from vec.h.
  It smells a bit like a host gcc bug, but I'll have to find a
  newer version where it builds to confirm.  (If so, hopefully
  it's as simple as upping the minimum host gcc version or
  blacklisting gcc-4.4.x.)
 
  Yeah, I got those warnings in my sparc and hppa builds, but they are
  harmless.  Strictly speaking offsetof cannot be applied to non-PODs.
  The only thing that makes that class non-POD is the protected
  attribute, but that does not alter the physical layout.  So the
  compiler is emitting a harmless warning (newer versions have
  tightened the check to warn when you are using offsetof on a non-base
  class).
 
 But then we are no longer writing in C++.   Is there a reason why this
 warning does not break the build?  We should not be using offsetof
 with non-PODs.
 
 Thanks,
 Andrew Pinski

The changes to tree-data-ref.c have broken the bootstrap on 
x86_64-apple-darwin11/12
using the Apple clang 4.1 compiler...

clang++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
-I. -I../../gcc-4.8-20121119/gcc -I../../gcc-4.8-20121119/gcc/. 
-I../../gcc-4.8-20121119/gcc/../include 
-I../../gcc-4.8-20121119/gcc/../libcpp/include -I/sw/include -I/sw/include  
-I../../gcc-4.8-20121119/gcc/../libdecnumber 
-I../../gcc-4.8-20121119/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc-4.8-20121119/gcc/../libbacktrace -DCLOOG_INT_GMP -I/sw/include 
-I/sw/include -I/sw/include ../../gcc-4.8-20121119/gcc/tree-data-ref.c -o 
tree-data-ref.o
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is 
deprecated
../../gcc-4.8-20121119/gcc/tree-data-ref.c:1599:31: error: second argument to 
'va_arg' is of non-POD type 'affine_fn' (aka 'vectree') [-Wnon-pod-varargs]
ret-fns[i] = va_arg (ap, affine_fn);
  ^~
/usr/bin/../lib/clang/4.1/include/stdarg.h:35:50: note: expanded from macro 
'va_arg'
#define va_arg(ap, type)__builtin_va_arg(ap, type)
 ^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:1665:34: error: cannot pass object 
of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
will abort at runtime [-Wnon-pod-varargs]
  *overlaps_a = conflict_fn (1, affine_fn_cst (integer_zero_node));
^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:1666:34: error: cannot pass object 
of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
will abort at runtime [-Wnon-pod-varargs]
  *overlaps_b = conflict_fn (1, affine_fn_cst (integer_zero_node));
^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:1812:37: error: cannot pass object 
of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
will abort at runtime [-Wnon-pod-varargs]
  *overlaps_a = conflict_fn (1, affine_fn_cst (integer_zero_node));
^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:1813:37: error: cannot pass object 
of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
will abort at runtime [-Wnon-pod-varargs]
  *overlaps_b = conflict_fn (1, affine_fn_cst (integer_zero_node));
^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:1858:39: error: cannot pass object 
of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
will abort at runtime [-Wnon-pod-varargs]
  *overlaps_a = conflict_fn (1, affine_fn_cst 
(integer_zero_node));
^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:1862:39: error: cannot pass object 
of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
will abort at runtime [-Wnon-pod-varargs]
  *overlaps_b = conflict_fn (1, affine_fn_cst (tmp));
^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:1938:39: error: cannot pass object 
of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
will abort at runtime [-Wnon-pod-varargs]
  *overlaps_a = conflict_fn (1, affine_fn_cst 
(integer_zero_node));
^

Re: VEC re-write [patch 01/25]

2012-11-19 Thread Jack Howarth
On Mon, Nov 19, 2012 at 02:57:08PM -0500, Jack Howarth wrote:
 On Sun, Nov 18, 2012 at 11:15:22AM -0800, Andrew Pinski wrote:
  On Sun, Nov 18, 2012 at 9:12 AM, Diego Novillo dnovi...@google.com wrote:
   On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson h...@bitrange.com 
   wrote:
   On Sat, 17 Nov 2012, Diego Novillo wrote:
   I have now committed all 25 parts of this patch as rev 193595.  Please
   CC me on any problems that you think may be related to this rewrite.
  
   That seems to have trigged some bug in gcc-4.4-era.  See
   PR55381.  There are a lot of suspicious warnings from vec.h.
   It smells a bit like a host gcc bug, but I'll have to find a
   newer version where it builds to confirm.  (If so, hopefully
   it's as simple as upping the minimum host gcc version or
   blacklisting gcc-4.4.x.)
  
   Yeah, I got those warnings in my sparc and hppa builds, but they are
   harmless.  Strictly speaking offsetof cannot be applied to non-PODs.
   The only thing that makes that class non-POD is the protected
   attribute, but that does not alter the physical layout.  So the
   compiler is emitting a harmless warning (newer versions have
   tightened the check to warn when you are using offsetof on a non-base
   class).
  
  But then we are no longer writing in C++.   Is there a reason why this
  warning does not break the build?  We should not be using offsetof
  with non-PODs.
  
  Thanks,
  Andrew Pinski
 
 The changes to tree-data-ref.c have broken the bootstrap on 
 x86_64-apple-darwin11/12
 using the Apple clang 4.1 compiler...
 
 clang++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti 
 -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
 -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long 
 -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
 -I. -I../../gcc-4.8-20121119/gcc -I../../gcc-4.8-20121119/gcc/. 
 -I../../gcc-4.8-20121119/gcc/../include 
 -I../../gcc-4.8-20121119/gcc/../libcpp/include -I/sw/include -I/sw/include  
 -I../../gcc-4.8-20121119/gcc/../libdecnumber 
 -I../../gcc-4.8-20121119/gcc/../libdecnumber/dpd -I../libdecnumber 
 -I../../gcc-4.8-20121119/gcc/../libbacktrace -DCLOOG_INT_GMP -I/sw/include 
 -I/sw/include -I/sw/include ../../gcc-4.8-20121119/gcc/tree-data-ref.c -o 
 tree-data-ref.o
 clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
 is deprecated
 ../../gcc-4.8-20121119/gcc/tree-data-ref.c:1599:31: error: second argument to 
 'va_arg' is of non-POD type 'affine_fn' (aka 'vectree') [-Wnon-pod-varargs]
 ret-fns[i] = va_arg (ap, affine_fn);
   ^~
 /usr/bin/../lib/clang/4.1/include/stdarg.h:35:50: note: expanded from macro 
 'va_arg'
 #define va_arg(ap, type)__builtin_va_arg(ap, type)
  ^
 ../../gcc-4.8-20121119/gcc/tree-data-ref.c:1665:34: error: cannot pass object 
 of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
 will abort at runtime [-Wnon-pod-varargs]
   *overlaps_a = conflict_fn (1, affine_fn_cst (integer_zero_node));
 ^
 ../../gcc-4.8-20121119/gcc/tree-data-ref.c:1666:34: error: cannot pass object 
 of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
 will abort at runtime [-Wnon-pod-varargs]
   *overlaps_b = conflict_fn (1, affine_fn_cst (integer_zero_node));
 ^
 ../../gcc-4.8-20121119/gcc/tree-data-ref.c:1812:37: error: cannot pass object 
 of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
 will abort at runtime [-Wnon-pod-varargs]
   *overlaps_a = conflict_fn (1, affine_fn_cst (integer_zero_node));
 ^
 ../../gcc-4.8-20121119/gcc/tree-data-ref.c:1813:37: error: cannot pass object 
 of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
 will abort at runtime [-Wnon-pod-varargs]
   *overlaps_b = conflict_fn (1, affine_fn_cst (integer_zero_node));
 ^
 ../../gcc-4.8-20121119/gcc/tree-data-ref.c:1858:39: error: cannot pass object 
 of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
 will abort at runtime [-Wnon-pod-varargs]
   *overlaps_a = conflict_fn (1, affine_fn_cst 
 (integer_zero_node));
 ^
 ../../gcc-4.8-20121119/gcc/tree-data-ref.c:1862:39: error: cannot pass object 
 of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
 will abort at runtime [-Wnon-pod-varargs]
   *overlaps_b = conflict_fn (1, affine_fn_cst (tmp));
 ^
 ../../gcc-4.8-20121119/gcc/tree-data-ref.c:1938:39: error: cannot pass object 
 of non-POD type 'affine_fn' (aka 'vectree') through variadic function; call 
 will abort at runtime [-Wnon-pod-varargs]

Re: VEC re-write [patch 01/25]

2012-11-18 Thread Hans-Peter Nilsson
On Sat, 17 Nov 2012, Diego Novillo wrote:
 I have now committed all 25 parts of this patch as rev 193595.  Please
 CC me on any problems that you think may be related to this rewrite.

That seems to have trigged some bug in gcc-4.4-era.  See
PR55381.  There are a lot of suspicious warnings from vec.h.
It smells a bit like a host gcc bug, but I'll have to find a
newer version where it builds to confirm.  (If so, hopefully
it's as simple as upping the minimum host gcc version or
blacklisting gcc-4.4.x.)

brgds, H-P


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Diego Novillo
On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
 On Sat, 17 Nov 2012, Diego Novillo wrote:
 I have now committed all 25 parts of this patch as rev 193595.  Please
 CC me on any problems that you think may be related to this rewrite.

 That seems to have trigged some bug in gcc-4.4-era.  See
 PR55381.  There are a lot of suspicious warnings from vec.h.
 It smells a bit like a host gcc bug, but I'll have to find a
 newer version where it builds to confirm.  (If so, hopefully
 it's as simple as upping the minimum host gcc version or
 blacklisting gcc-4.4.x.)

Yeah, I got those warnings in my sparc and hppa builds, but they are
harmless.  Strictly speaking offsetof cannot be applied to non-PODs.
The only thing that makes that class non-POD is the protected
attribute, but that does not alter the physical layout.  So the
compiler is emitting a harmless warning (newer versions have
tightened the check to warn when you are using offsetof on a non-base
class).

My cris-elf builds worked fine, but config-list.mk only builds stage
1, it does not build libgfortran.  Can you give me instructions on how
to build your target on my x86 workstation?


Thanks.  Diego.


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Hans-Peter Nilsson
On Sun, 18 Nov 2012, Diego Novillo wrote:
 My cris-elf builds worked fine, but config-list.mk only builds stage
 1, it does not build libgfortran.  Can you give me instructions on how
 to build your target on my x86 workstation?

Better see the PR for cc1 command-line and preprocessed C-file.

brgds, H-P


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Diego Novillo
On Sun, Nov 18, 2012 at 12:43 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
 On Sun, 18 Nov 2012, Diego Novillo wrote:
 My cris-elf builds worked fine, but config-list.mk only builds stage
 1, it does not build libgfortran.  Can you give me instructions on how
 to build your target on my x86 workstation?

 Better see the PR for cc1 command-line and preprocessed C-file.

Ah, I had missed that.  Thanks.


Diego.


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Andreas Tobler
On 18.11.12 18:05, Hans-Peter Nilsson wrote:
 On Sat, 17 Nov 2012, Diego Novillo wrote:
 I have now committed all 25 parts of this patch as rev 193595.  Please
 CC me on any problems that you think may be related to this rewrite.
 
 That seems to have trigged some bug in gcc-4.4-era.  See
 PR55381.  There are a lot of suspicious warnings from vec.h.
 It smells a bit like a host gcc bug, but I'll have to find a
 newer version where it builds to confirm.  (If so, hopefully
 it's as simple as upping the minimum host gcc version or
 blacklisting gcc-4.4.x.)

Is there a minimum gcc to bootstrap current trunk?
I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
succeeds. I see similar warnings as in the PR. But here on x86_64
FreeBSD genautomata gives a bus error.

build/genautomata
/export/devel/net/src/gcc/head/gcc/gcc/config/i386/i386.md \
  insn-conditions.md  tmp-automata.c
gmake[3]: *** [s-automata] Bus error (core dumped)

Andreas


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Hans-Peter Nilsson
On Sun, 18 Nov 2012, Andreas Tobler wrote:
 Is there a minimum gcc to bootstrap current trunk?
 I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
 succeeds.

A gcc-4.1.2 has worked for me in the past, before this recent
vec.h change.  I think that's the minimum version reportedly
working.

brgds, H-P


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Andrew Pinski
On Sun, Nov 18, 2012 at 9:12 AM, Diego Novillo dnovi...@google.com wrote:
 On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson h...@bitrange.com 
 wrote:
 On Sat, 17 Nov 2012, Diego Novillo wrote:
 I have now committed all 25 parts of this patch as rev 193595.  Please
 CC me on any problems that you think may be related to this rewrite.

 That seems to have trigged some bug in gcc-4.4-era.  See
 PR55381.  There are a lot of suspicious warnings from vec.h.
 It smells a bit like a host gcc bug, but I'll have to find a
 newer version where it builds to confirm.  (If so, hopefully
 it's as simple as upping the minimum host gcc version or
 blacklisting gcc-4.4.x.)

 Yeah, I got those warnings in my sparc and hppa builds, but they are
 harmless.  Strictly speaking offsetof cannot be applied to non-PODs.
 The only thing that makes that class non-POD is the protected
 attribute, but that does not alter the physical layout.  So the
 compiler is emitting a harmless warning (newer versions have
 tightened the check to warn when you are using offsetof on a non-base
 class).

But then we are no longer writing in C++.   Is there a reason why this
warning does not break the build?  We should not be using offsetof
with non-PODs.

Thanks,
Andrew Pinski


 My cris-elf builds worked fine, but config-list.mk only builds stage
 1, it does not build libgfortran.  Can you give me instructions on how
 to build your target on my x86 workstation?


 Thanks.  Diego.


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Andreas Tobler
On 18.11.12 20:11, Hans-Peter Nilsson wrote:
 On Sun, 18 Nov 2012, Andreas Tobler wrote:
 Is there a minimum gcc to bootstrap current trunk?
 I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
 succeeds.
 
 A gcc-4.1.2 has worked for me in the past, before this recent
 vec.h change.  I think that's the minimum version reportedly
 working.

Up to 193594 a 4.2.1 did it fine on most of my platforms. But with
193595 it seems that I have to use a more recent gcc to bootstrap.

Andreas



Re: VEC re-write [patch 01/25]

2012-11-18 Thread Hans-Peter Nilsson
On Sun, 18 Nov 2012, Andreas Tobler wrote:

 On 18.11.12 20:11, Hans-Peter Nilsson wrote:
  On Sun, 18 Nov 2012, Andreas Tobler wrote:
  Is there a minimum gcc to bootstrap current trunk?
  I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
  succeeds.
 
  A gcc-4.1.2 has worked for me in the past, before this recent
  vec.h change.  I think that's the minimum version reportedly
  working.

 Up to 193594 a 4.2.1 did it fine on most of my platforms. But with
 193595 it seems that I have to use a more recent gcc to bootstrap.

Yes, that's the vec.h-change revision.  I hope we can revert
that behavior (the *behavior*, not the patch).

brgds, H-P


Re: VEC re-write [patch 01/25]

2012-11-18 Thread David Edelsohn
Files were changed in gcc/c-family with no associated ChangeLog entry.
 And now bootstrap fails on AIX using GCC 4.6.3 with the error:

/nasfarm/dje/src/src/gcc/c-family/c-lex.c: In function 'c_fileinfo*
get_fileinfo(const char*)':
/nasfarm/dje/src/src/gcc/c-family/c-lex.c:107:39: error: overloaded
function with no contextual type information

which is

file_info_tree = splay_tree_new ((splay_tree_compare_fn) strcmp,
 0,
 (splay_tree_delete_value_fn) free);

- David


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Diego Novillo
On Sun, Nov 18, 2012 at 4:28 PM, David Edelsohn dje@gmail.com wrote:
 Files were changed in gcc/c-family with no associated ChangeLog entry.

*gasp*

I mistakenly put them in c/ChangeLog.  Not that they carry any useful
information, but I'll move them.

  And now bootstrap fails on AIX using GCC 4.6.3 with the error:

 /nasfarm/dje/src/src/gcc/c-family/c-lex.c: In function 'c_fileinfo*
 get_fileinfo(const char*)':
 /nasfarm/dje/src/src/gcc/c-family/c-lex.c:107:39: error: overloaded
 function with no contextual type information

 which is

 file_info_tree = splay_tree_new ((splay_tree_compare_fn) strcmp,
  0,
  (splay_tree_delete_value_fn) free);


Odd.  The patch did not touch c-lex.c.


Diego.


Re: VEC re-write [patch 01/25]

2012-11-18 Thread David Edelsohn
On Sun, Nov 18, 2012 at 8:03 PM, Diego Novillo dnovi...@google.com wrote:

  And now bootstrap fails on AIX using GCC 4.6.3 with the error:

 /nasfarm/dje/src/src/gcc/c-family/c-lex.c: In function 'c_fileinfo*
 get_fileinfo(const char*)':
 /nasfarm/dje/src/src/gcc/c-family/c-lex.c:107:39: error: overloaded
 function with no contextual type information

 which is

 file_info_tree = splay_tree_new ((splay_tree_compare_fn) strcmp,
  0,
  (splay_tree_delete_value_fn) free);


 Odd.  The patch did not touch c-lex.c.

I opened PR 55384 to track this

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384

The problem is AIX stdlib.h defines

#define vec_free free

and vec.h

defines two functions named vec_free()

With the VEC changes, these now are renamed free and lead to
ambiguous name resolution.

I am not sure where

#undef vec_free

should be placed.  In vec.h or system.h?

Thanks, David


Re: VEC re-write [patch 01/25]

2012-11-18 Thread Ian Lance Taylor
On Sun, Nov 18, 2012 at 5:14 PM, David Edelsohn dje@gmail.com wrote:

 The problem is AIX stdlib.h defines

 #define vec_free free

Ouch.

 I am not sure where

 #undef vec_free

 should be placed.  In vec.h or system.h?

I think system.h.

Ian


Re: VEC re-write [patch 01/25]

2012-11-17 Thread Diego Novillo
On Thu, Nov 15, 2012 at 4:53 PM, Diego Novillo dnovi...@google.com wrote:

 I have tested the patch pretty extensively:

 - Regular bootstraps on x86_64, ppc, ia64, sparc and hppa.
 - Bootstraps with --enable-checking=release
 - Bootstraps with --enable-checking=gc,gcac
 - Basic builds on all targets (using contrib/config-list.mk).

I have now committed all 25 parts of this patch as rev 193595.  Please
CC me on any problems that you think may be related to this rewrite.


Thanks.  Diego.


Re: VEC re-write [patch 01/25]

2012-11-16 Thread Diego Novillo
On Fri, Nov 16, 2012 at 5:23 AM, Pedro Alves pal...@redhat.com wrote:

 Was this considered?

Yup.  I just did not implement it.  Would be a good follow up, though.


Diego.


Re: VEC re-write [patch 01/25]

2012-11-16 Thread Pedro Alves
On 16-11-2012 12:13, Diego Novillo wrote:
 On Fri, Nov 16, 2012 at 5:23 AM, Pedro Alves pal...@redhat.com wrote:
 
 Was this considered?
 
 Yup.  I just did not implement it.  Would be a good follow up, though.

Ah, good to know.  Thanks.

For the archives, cause gcc-patches@ bounced my mail for not being subscribed
with this address (too many recipients) what I had sent was:

On 15-11-2012 21:53, Diego Novillo wrote:
 The only thing I could not do is create proper ctors and dtors for the
 vec class.  Since these vectors are stored in unions, we
 have to keep them as PODs (C++03 does not allow non-PODs in unions).

How many cases are there of vecs in unions vs not in unions?
It would seem natural to me to extend the POD vec type with a
class that just adds the ctors and dtors, and call that new type
the vec that is used mostly everywhere.  The base POD vec (suggest
struct vec_pod, and then struct vec : vec_pod {}) would then only
be used in unions, and then only the code that needs to worry about
initializing/releasing the unions would need to care about this.  Was
this considered?

-- 
Pedro Alves


Re: VEC re-write [patch 01/25]

2012-11-16 Thread Ian Lance Taylor
On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo dnovi...@google.com wrote:

 2012-11-15  Diego Novillo  dnovi...@google.com

 * vec.c (register_overhead): Convert it into
 member function of vec_prefix.
 (release_overhead): Likewise.
 (calculate_allocation): Likewise.
 (vec_heap_free): Remove.
 (vec_gc_o_reserve_1): Remove.
 (vec_heap_o_reserve_1): Remove.
 (vec_stack_o_reserve_1): Remove.
 (vec_stack_o_reserve_exact): Remove.
 (register_stack_vec): New.
 (stack_vec_register_index): New.
 (unregister_stack_vec): New.
 (vec_assert_fail): Remove.
 * vec.h: Conditionally include ggc.h.  Document conditional
 hackery.
 Update top-level documentation.
 (ALONE_VEC_CHECK_INFO): Remove.
 (VEC_CHECK_INFO): Remove.
 (ALONE_VEC_CHECK_DECL): Remove.
 (VEC_CHECK_DECL): Remove.
 (ALONE_VEC_CHECK_PASS): Remove.
 (VEC_CHECK_PASS): Remove.
 (VEC_ASSERT): Remove.
 (vec_prefix): Add friends va_gc, va_gc_atomic, va_heap and
 va_stack.
 Mark fields alloc_ and num_ as protected.
 (struct vec_t): Remove.  Remove all function members.
 (struct vl_embed): Declare.
 (struct vl_ptr): Declare.
 (free): Remove.
 (reserve_exact): Remove.
 (reserve): Remove.
 (safe_splice): Remove.
 (safe_push): Remove.
 (safe_grow): Remove.
 (safe_grow_cleared): Remove.
 (safe_insert): Remove.
 (DEF_VEC_I): Remove.
 (DEF_VEC_ALLOC_I): Remove.
 (DEF_VEC_P): Remove.
 (DEF_VEC_ALLOC_P): Remove.
 (DEF_VEC_O): Remove.
 (DEF_VEC_ALLOC_O): Remove.
 (DEF_VEC_ALLOC_P_STACK): Remove.
 (DEF_VEC_ALLOC_O_STACK): Remove.
 (DEF_VEC_ALLOC_I_STACK): Remove.
 (DEF_VEC_A): Remove.
 (DEF_VEC_ALLOC_A): Remove.
 (vec_stack_p_reserve_exact_1): Remove.
 (vec_stack_o_reserve): Remove.
 (vec_stack_o_reserve_exact): Remove.
 (VEC_length): Remove.
 (VEC_empty): Remove.
 (VEC_address): Remove.
 (vec_address): Remove.
 (VEC_last): Remove.
 (VEC_index): Remove.
 (VEC_iterate): Remove.
 (VEC_embedded_size): Remove.
 (VEC_embedded_init): Remove.
 (VEC_free): Remove.
 (VEC_copy): Remove.
 (VEC_space): Remove.
 (VEC_reserve): Remove.
 (VEC_reserve_exact): Remove.
 (VEC_splice): Remove.
 (VEC_safe_splice): Remove.
 (VEC_quick_push): Remove.
 (VEC_safe_push): Remove.
 (VEC_pop): Remove.
 (VEC_truncate): Remove.
 (VEC_safe_grow): Remove.
 (VEC_replace): Remove.
 (VEC_quick_insert): Remove.
 (VEC_safe_insert): Remove.
 (VEC_ordered_remove): Remove.
 (VEC_unordered_remove): Remove.
 (VEC_block_remove): Remove.
 (VEC_lower_bound): Remove.
 (VEC_alloc): Remove.
 (VEC_qsort): Remove.

 (va_heap): Declare.
 (va_heap::default_layout): New typedef to vl_ptr.
 (va_heap::reserve): New.
 (va_heap::release): New.
 (va_gc): Declare.
 (va_gc::default_layout): New typedef to vl_embed.
 (va_gc::reserve): New.
 (va_gc::release): New.
 (va_gc_atomic): Declare.  Inherit from va_gc.
 (va_stack): Declare.
 (va_stack::default_layout): New typedef to vl_ptr.
 (va_stack::alloc): New.
 (va_stack::reserve): New.
 (va_stack::release): New.
 (register_stack_vec): Declare.
 (stack_vec_register_index): Declare.
 (unregister_stack_vec): Declare.

 (vecT, A = va_heap, L = typename A::default_layout): Declare
 empty vec template.
 (vecT, A, vl_embed): Partial specialization for embedded
 layout.
 (vecT, A, vl_embed::allocated): New.
 (vecT, A, vl_embed::length): New.
 (vecT, A, vl_embed::is_empty): New.
 (vecT, A, vl_embed::address): New.
 (vecT, A, vl_embed::operator[]): New.
 (vecT, A, vl_embed::last New.
 (vecT, A, vl_embed::space): New.
 (vecT, A, vl_embed::iterate): New.
 (vecT, A, vl_embed::iterate): New.
 (vecT, A, vl_embed::copy): New.
 (vecT, A, vl_embed::splice): New.
 (vecT, A, vl_embed::quick_push New.
 (vecT, A, vl_embed::pop New.
 (vecT, A, vl_embed::truncate): New.
 (vecT, A, vl_embed::quick_insert): New.
 (vecT, A, vl_embed::ordered_remove): New.
 (vecT, A, vl_embed::unordered_remove): New.
 (vecT, A, vl_embed::block_remove): New.
 (vecT, A, vl_embed::qsort): New.
 (vecT, A, vl_embed::lower_bound): New.
 (vecT, A, vl_embed::embedded_size): New.
 (vecT, A, vl_embed::embedded_init): New.
 (vecT, A, vl_embed::quick_grow): New.