public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* VEC re-write [patch 01/25]
@ 2012-11-15 21:53 Diego Novillo
       [not found] ` <50A61414.8070908@redhat.com>
                   ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Diego Novillo @ 2012-11-15 21:53 UTC (permalink / raw)
  To: joern.rennecke, nathan, gingold, nickc, dje.gcc, law,
	rdsandiford, dj, wilson, rth, echristo, bernds, mikestump, aph,
	iant, paul, jason, joseph, ebotcazou, laurynas.biveinis,
	rguenther, gcc-patches

I have split the VEC rewrite into 25 patches.  The only patches that
make actual changes are #1 (vec.c and vec.h) and #2 (gengtype).  All
the others are mechanical side-effects from the first patch.

I will still appreciate if maintainers can take a look at the other
patches to make sure I have not introduced anything strange.  Some of
the changes were done with sed.  I've fixed up the formatting
manually, but I may have missed the odd thing.

All the folks in the CC list: expect to receive at least one of the
patches in the patchset.  The changes in every area other than
vec.[ch] are mechanical, so I am not really looking for an approval.
But, if you spot something fishy, please let me know.

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'm now doing build-time comparisons, but I do not expect changes.

I've documented the changes from a user's perspective on
http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec.  This should help
reading te new vec code for the first time.

We no longer access the vectors via VEC_* macros.  The pattern is
"VEC_operation (T, A, V, args)" becomes "V.operation (args)".

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).

This means that creation and destruction must be explicit.  There is a
new method vec<type, allocation, layout>::create() and another vec<type,
allocation, layout>::destroy() to allocate the internal vector.

For vectors that must be pointers, there is a family of free functions
that implement the operations that need to tolerate NULL vectors.
These functions all start with the prefix 'vec_safe_'.  See the wiki
page for details.

I would like to commit the patch this weekend.  This will increase the
chances of not conflicting with any other patches going in.  I do not
expect any breakage to occur, but the patch is massive.  Once the
patch is in, please CC me on any bug reports that are caused by vec
changes.

Typical problems include:

- An ICE inside a vec function member because 'this' is NULL.  These
  are the easiest to fix.  You simply look in the backtrace for the
  first entry that is outside of vec.h.  That's the line you need to
  modify to use one of the 'vec_safe_*' functions.

- A syntax error in calling a vec function member.  These should not
  occur, as I have pruned all the ones that occurred in
  config-list.mk, but if it happens this is often a vector that was a
  pointer and its function is being accessed with '.'.  If the vector
  is a GC vector, then it may need to be accessed with 'vec_safe_*'

In any case, just forward me the failure and I will deal with it.

Richi, I've added vec::quick_grow and vec::quick_grow_cleared.  This
will let you change that FIXME comment in PRE, I think.


Thanks.  Diego.

[ The patch is too big for e-mail.  It's available at http://www.airs.com/~dnovillo/pub/vec-rewrite/01vec.diff ]

2012-11-15  Diego Novillo  <dnovillo@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.

	(vec<T, A = va_heap, L = typename A::default_layout>): Declare
	empty vec template.
	(vec<T, A, vl_embed>): Partial specialization for embedded
	layout.
	(vec<T, A, vl_embed>::allocated): New.
	(vec<T, A, vl_embed>::length): New.
	(vec<T, A, vl_embed>::is_empty): New.
	(vec<T, A, vl_embed>::address): New.
	(vec<T, A, vl_embed>::operator[]): New.
	(vec<T, A, vl_embed>::last New.
	(vec<T, A, vl_embed>::space): New.
	(vec<T, A, vl_embed>::iterate): New.
	(vec<T, A, vl_embed>::iterate): New.
	(vec<T, A, vl_embed>::copy): New.
	(vec<T, A, vl_embed>::splice): New.
	(vec<T, A, vl_embed>::quick_push New.
	(vec<T, A, vl_embed>::pop New.
	(vec<T, A, vl_embed>::truncate): New.
	(vec<T, A, vl_embed>::quick_insert): New.
	(vec<T, A, vl_embed>::ordered_remove): New.
	(vec<T, A, vl_embed>::unordered_remove): New.
	(vec<T, A, vl_embed>::block_remove): New.
	(vec<T, A, vl_embed>::qsort): New.
	(vec<T, A, vl_embed>::lower_bound): New.
	(vec<T, A, vl_embed>::embedded_size): New.
	(vec<T, A, vl_embed>::embedded_init): New.
	(vec<T, A, vl_embed>::quick_grow): New.
	(vec<T, A, vl_embed>::quick_grow_cleared): New.
	(vec_safe_space): New.
	(vec_safe_length): New.
	(vec_safe_address): New.
	(vec_safe_is_empty): New.
	(vec_safe_reserve): New.
	(vec_safe_reserve_exact): New.
	(vec_alloc): New.
	(vec_free): New.
	(vec_safe_grow): New.
	(vec_safe_grow_cleared): New.
	(vec_safe_iterate): New.
	(vec_safe_push): New.
	(vec_safe_insert): New.
	(vec_safe_truncate): New.
	(vec_safe_copy): New.
	(vec_safe_splice): New.

	(vec<T, A, vl_ptr>): New partial specialization for the space
	efficient layout.
	(vec<T, A, vl_embed>::exists): New.
	(vec<T, A, vl_embed>::is_empty): New.
	(vec<T, A, vl_embed>::length): New.
	(vec<T, A, vl_embed>::address): New.
	(vec<T, A, vl_embed>::operator[]): New.
	(vec<T, A, vl_embed>::operator!=): New.
	(vec<T, A, vl_embed>::operator==): New.
	(vec<T, A, vl_embed>::last New.
	(vec<T, A, vl_embed>::space): New.
	(vec<T, A, vl_embed>::iterate): New.
	(vec<T, A, vl_embed>::copy): New.
	(vec<T, A, vl_embed>::reserve): New.
	(vec<T, A, vl_embed>::reserve_exact): New.
	(vec<T, A, vl_embed>::splice): New.
	(vec<T, A, vl_embed>::safe_splice): New.
	(vec<T, A, vl_embed>::quick_push): New.
	(vec<T, A, vl_embed>::safe_push): New.
	(vec<T, A, vl_embed>::pop New.
	(vec<T, A, vl_embed>::truncate): New.
	(vec<T, A, vl_embed>::safe_grow): New.
	(vec<T, A, vl_embed>::safe_grow_cleared): New.
	(vec<T, A, vl_embed>::quick_grow): New.
	(vec<T, A, vl_embed>::quick_grow_cleared): New.
	(vec<T, A, vl_embed>::quick_insert): New.
	(vec<T, A, vl_embed>::safe_insert): New.
	(vec<T, A, vl_embed>::ordered_remove): New.
	(vec<T, A, vl_embed>::unordered_remove): New.
	(vec<T, A, vl_embed>::block_remove): New.
	(vec<T, A, vl_embed>::qsort): New.
	(vec<T, A, vl_embed>::lower_bound): New.
	(vec_stack_alloc): Define.
	(FOR_EACH_VEC_SAFE_ELT): Define.
	* vecir.h: Remove.  Update all users.
	* vecprim.h: Remove.  Update all users.
	Move uchar to coretypes.h.

	* Makefile.in (VEC_H): Add $(GGC_H).
	Remove vecir.h and vecprim.h dependencies everywhere.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
       [not found] ` <50A61414.8070908@redhat.com>
@ 2012-11-16 12:13   ` Diego Novillo
  2012-11-16 12:22     ` Pedro Alves
  0 siblings, 1 reply; 24+ messages in thread
From: Diego Novillo @ 2012-11-16 12:13 UTC (permalink / raw)
  To: Pedro Alves
  Cc: joern.rennecke, nathan, gingold, nickc, dje.gcc, law,
	rdsandiford, dj, wilson, rth, echristo, bernds, mikestump, aph,
	iant, paul, jason, joseph, ebotcazou, laurynas.biveinis,
	rguenther, gcc-patches

On Fri, Nov 16, 2012 at 5:23 AM, Pedro Alves <palves@redhat.com> wrote:

> Was this considered?

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


Diego.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-16 12:13   ` Diego Novillo
@ 2012-11-16 12:22     ` Pedro Alves
  0 siblings, 0 replies; 24+ messages in thread
From: Pedro Alves @ 2012-11-16 12:22 UTC (permalink / raw)
  To: Diego Novillo; +Cc: gcc-patches

On 16-11-2012 12:13, Diego Novillo wrote:
> On Fri, Nov 16, 2012 at 5:23 AM, Pedro Alves <palves@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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-15 21:53 VEC re-write [patch 01/25] Diego Novillo
       [not found] ` <50A61414.8070908@redhat.com>
@ 2012-11-16 23:16 ` Ian Lance Taylor
  2012-11-18  2:57 ` Diego Novillo
  2 siblings, 0 replies; 24+ messages in thread
From: Ian Lance Taylor @ 2012-11-16 23:16 UTC (permalink / raw)
  To: Diego Novillo
  Cc: joern.rennecke, nathan, gingold, nickc, dje.gcc, law,
	rdsandiford, dj, wilson, rth, echristo, bernds, mikestump, aph,
	paul, jason, joseph, ebotcazou, laurynas.biveinis, rguenther,
	gcc-patches

On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo <dnovillo@google.com> wrote:
>
> 2012-11-15  Diego Novillo  <dnovillo@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.
>
>         (vec<T, A = va_heap, L = typename A::default_layout>): Declare
>         empty vec template.
>         (vec<T, A, vl_embed>): Partial specialization for embedded
>         layout.
>         (vec<T, A, vl_embed>::allocated): New.
>         (vec<T, A, vl_embed>::length): New.
>         (vec<T, A, vl_embed>::is_empty): New.
>         (vec<T, A, vl_embed>::address): New.
>         (vec<T, A, vl_embed>::operator[]): New.
>         (vec<T, A, vl_embed>::last New.
>         (vec<T, A, vl_embed>::space): New.
>         (vec<T, A, vl_embed>::iterate): New.
>         (vec<T, A, vl_embed>::iterate): New.
>         (vec<T, A, vl_embed>::copy): New.
>         (vec<T, A, vl_embed>::splice): New.
>         (vec<T, A, vl_embed>::quick_push New.
>         (vec<T, A, vl_embed>::pop New.
>         (vec<T, A, vl_embed>::truncate): New.
>         (vec<T, A, vl_embed>::quick_insert): New.
>         (vec<T, A, vl_embed>::ordered_remove): New.
>         (vec<T, A, vl_embed>::unordered_remove): New.
>         (vec<T, A, vl_embed>::block_remove): New.
>         (vec<T, A, vl_embed>::qsort): New.
>         (vec<T, A, vl_embed>::lower_bound): New.
>         (vec<T, A, vl_embed>::embedded_size): New.
>         (vec<T, A, vl_embed>::embedded_init): New.
>         (vec<T, A, vl_embed>::quick_grow): New.
>         (vec<T, A, vl_embed>::quick_grow_cleared): New.
>         (vec_safe_space): New.
>         (vec_safe_length): New.
>         (vec_safe_address): New.
>         (vec_safe_is_empty): New.
>         (vec_safe_reserve): New.
>         (vec_safe_reserve_exact): New.
>         (vec_alloc): New.
>         (vec_free): New.
>         (vec_safe_grow): New.
>         (vec_safe_grow_cleared): New.
>         (vec_safe_iterate): New.
>         (vec_safe_push): New.
>         (vec_safe_insert): New.
>         (vec_safe_truncate): New.
>         (vec_safe_copy): New.
>         (vec_safe_splice): New.
>
>         (vec<T, A, vl_ptr>): New partial specialization for the space
>         efficient layout.
>         (vec<T, A, vl_embed>::exists): New.
>         (vec<T, A, vl_embed>::is_empty): New.
>         (vec<T, A, vl_embed>::length): New.
>         (vec<T, A, vl_embed>::address): New.
>         (vec<T, A, vl_embed>::operator[]): New.
>         (vec<T, A, vl_embed>::operator!=): New.
>         (vec<T, A, vl_embed>::operator==): New.
>         (vec<T, A, vl_embed>::last New.
>         (vec<T, A, vl_embed>::space): New.
>         (vec<T, A, vl_embed>::iterate): New.
>         (vec<T, A, vl_embed>::copy): New.
>         (vec<T, A, vl_embed>::reserve): New.
>         (vec<T, A, vl_embed>::reserve_exact): New.
>         (vec<T, A, vl_embed>::splice): New.
>         (vec<T, A, vl_embed>::safe_splice): New.
>         (vec<T, A, vl_embed>::quick_push): New.
>         (vec<T, A, vl_embed>::safe_push): New.
>         (vec<T, A, vl_embed>::pop New.
>         (vec<T, A, vl_embed>::truncate): New.
>         (vec<T, A, vl_embed>::safe_grow): New.
>         (vec<T, A, vl_embed>::safe_grow_cleared): New.
>         (vec<T, A, vl_embed>::quick_grow): New.
>         (vec<T, A, vl_embed>::quick_grow_cleared): New.
>         (vec<T, A, vl_embed>::quick_insert): New.
>         (vec<T, A, vl_embed>::safe_insert): New.
>         (vec<T, A, vl_embed>::ordered_remove): New.
>         (vec<T, A, vl_embed>::unordered_remove): New.
>         (vec<T, A, vl_embed>::block_remove): New.
>         (vec<T, A, vl_embed>::qsort): New.
>         (vec<T, A, vl_embed>::lower_bound): New.
>         (vec_stack_alloc): Define.
>         (FOR_EACH_VEC_SAFE_ELT): Define.
>         * vecir.h: Remove.  Update all users.
>         * vecprim.h: Remove.  Update all users.
>         Move uchar to coretypes.h.
>
>         * Makefile.in (VEC_H): Add $(GGC_H).
>         Remove vecir.h and vecprim.h dependencies everywhere.

This looks OK to me.

Ian

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-15 21:53 VEC re-write [patch 01/25] Diego Novillo
       [not found] ` <50A61414.8070908@redhat.com>
  2012-11-16 23:16 ` Ian Lance Taylor
@ 2012-11-18  2:57 ` Diego Novillo
  2012-11-18 17:05   ` Hans-Peter Nilsson
  2012-11-20 13:57   ` Ulrich Weigand
  2 siblings, 2 replies; 24+ messages in thread
From: Diego Novillo @ 2012-11-18  2:57 UTC (permalink / raw)
  To: joern.rennecke, nathan, gingold, nickc, dje.gcc, law,
	rdsandiford, dj, wilson, rth, echristo, bernds, mikestump, aph,
	iant, paul, jason, joseph, ebotcazou, laurynas.biveinis,
	rguenther, gcc-patches

On Thu, Nov 15, 2012 at 4:53 PM, Diego Novillo <dnovillo@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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18  2:57 ` Diego Novillo
@ 2012-11-18 17:05   ` Hans-Peter Nilsson
  2012-11-18 17:12     ` Diego Novillo
  2012-11-18 18:25     ` Andreas Tobler
  2012-11-20 13:57   ` Ulrich Weigand
  1 sibling, 2 replies; 24+ messages in thread
From: Hans-Peter Nilsson @ 2012-11-18 17:05 UTC (permalink / raw)
  To: Diego Novillo; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 17:05   ` Hans-Peter Nilsson
@ 2012-11-18 17:12     ` Diego Novillo
  2012-11-18 17:43       ` Hans-Peter Nilsson
                         ` (2 more replies)
  2012-11-18 18:25     ` Andreas Tobler
  1 sibling, 3 replies; 24+ messages in thread
From: Diego Novillo @ 2012-11-18 17:12 UTC (permalink / raw)
  To: Hans-Peter Nilsson; +Cc: gcc-patches

On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson <hp@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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 17:12     ` Diego Novillo
@ 2012-11-18 17:43       ` Hans-Peter Nilsson
  2012-11-18 17:48         ` Diego Novillo
  2012-11-18 19:15       ` Andrew Pinski
  2012-11-25 13:11       ` Richard Biener
  2 siblings, 1 reply; 24+ messages in thread
From: Hans-Peter Nilsson @ 2012-11-18 17:43 UTC (permalink / raw)
  To: Diego Novillo; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 17:43       ` Hans-Peter Nilsson
@ 2012-11-18 17:48         ` Diego Novillo
  0 siblings, 0 replies; 24+ messages in thread
From: Diego Novillo @ 2012-11-18 17:48 UTC (permalink / raw)
  To: Hans-Peter Nilsson; +Cc: gcc-patches

On Sun, Nov 18, 2012 at 12:43 PM, Hans-Peter Nilsson <hp@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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 17:05   ` Hans-Peter Nilsson
  2012-11-18 17:12     ` Diego Novillo
@ 2012-11-18 18:25     ` Andreas Tobler
  2012-11-18 19:12       ` Hans-Peter Nilsson
  1 sibling, 1 reply; 24+ messages in thread
From: Andreas Tobler @ 2012-11-18 18:25 UTC (permalink / raw)
  To: Hans-Peter Nilsson, Diego Novillo; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 18:25     ` Andreas Tobler
@ 2012-11-18 19:12       ` Hans-Peter Nilsson
  2012-11-18 19:32         ` Andreas Tobler
  0 siblings, 1 reply; 24+ messages in thread
From: Hans-Peter Nilsson @ 2012-11-18 19:12 UTC (permalink / raw)
  To: Andreas Tobler; +Cc: Diego Novillo, gcc-patches

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 17:12     ` Diego Novillo
  2012-11-18 17:43       ` Hans-Peter Nilsson
@ 2012-11-18 19:15       ` Andrew Pinski
  2012-11-19 19:57         ` Jack Howarth
  2012-11-25 13:11       ` Richard Biener
  2 siblings, 1 reply; 24+ messages in thread
From: Andrew Pinski @ 2012-11-18 19:15 UTC (permalink / raw)
  To: Diego Novillo; +Cc: Hans-Peter Nilsson, gcc-patches

On Sun, Nov 18, 2012 at 9:12 AM, Diego Novillo <dnovillo@google.com> wrote:
> On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson <hp@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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 19:12       ` Hans-Peter Nilsson
@ 2012-11-18 19:32         ` Andreas Tobler
  2012-11-18 19:50           ` Hans-Peter Nilsson
  0 siblings, 1 reply; 24+ messages in thread
From: Andreas Tobler @ 2012-11-18 19:32 UTC (permalink / raw)
  To: Hans-Peter Nilsson; +Cc: Diego Novillo, gcc-patches

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 19:32         ` Andreas Tobler
@ 2012-11-18 19:50           ` Hans-Peter Nilsson
  0 siblings, 0 replies; 24+ messages in thread
From: Hans-Peter Nilsson @ 2012-11-18 19:50 UTC (permalink / raw)
  To: Andreas Tobler; +Cc: Diego Novillo, gcc-patches

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 19:15       ` Andrew Pinski
@ 2012-11-19 19:57         ` Jack Howarth
  2012-11-19 20:16           ` Jack Howarth
  0 siblings, 1 reply; 24+ messages in thread
From: Jack Howarth @ 2012-11-19 19:57 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: Diego Novillo, Hans-Peter Nilsson, gcc-patches

On Sun, Nov 18, 2012 at 11:15:22AM -0800, Andrew Pinski wrote:
> On Sun, Nov 18, 2012 at 9:12 AM, Diego Novillo <dnovillo@google.com> wrote:
> > On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson <hp@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 'vec<tree>') [-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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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:1941:39: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2203:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
      *overlaps_a = conflict_fn (2, ova1, ova2);
                                    ^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:2203:43: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
      *overlaps_a = conflict_fn (2, ova1, ova2);
                                          ^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:2204:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
      *overlaps_b = conflict_fn (1, ovb);
                                    ^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:2208:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2209:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2404:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2405:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2462:34: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
          *overlaps_a = conflict_fn (1, ova);
                                        ^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:2463:34: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
          *overlaps_b = conflict_fn (1, ovb);
                                        ^
../../gcc-4.8-20121119/gcc/tree-data-ref.c:2604:11: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
                               affine_fn_univar (build_int_cst (NULL_TREE, x1),
                               ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

> 
> >
> > 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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-19 19:57         ` Jack Howarth
@ 2012-11-19 20:16           ` Jack Howarth
  0 siblings, 0 replies; 24+ messages in thread
From: Jack Howarth @ 2012-11-19 20:16 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: Diego Novillo, Hans-Peter Nilsson, gcc-patches

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 <dnovillo@google.com> wrote:
> > > On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson <hp@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 'vec<tree>') [-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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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 'vec<tree>') 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:1941:39: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2203:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
>       *overlaps_a = conflict_fn (2, ova1, ova2);
>                                     ^
> ../../gcc-4.8-20121119/gcc/tree-data-ref.c:2203:43: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
>       *overlaps_a = conflict_fn (2, ova1, ova2);
>                                           ^
> ../../gcc-4.8-20121119/gcc/tree-data-ref.c:2204:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
>       *overlaps_b = conflict_fn (1, ovb);
>                                     ^
> ../../gcc-4.8-20121119/gcc/tree-data-ref.c:2208:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2209:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2404:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2405:37: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') 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:2462:34: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
>           *overlaps_a = conflict_fn (1, ova);
>                                         ^
> ../../gcc-4.8-20121119/gcc/tree-data-ref.c:2463:34: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
>           *overlaps_b = conflict_fn (1, ovb);
>                                         ^
> ../../gcc-4.8-20121119/gcc/tree-data-ref.c:2604:11: error: cannot pass object of non-POD type 'affine_fn' (aka 'vec<tree>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
>                                affine_fn_univar (build_int_cst (NULL_TREE, x1),
>                                ^
> fatal error: too many errors emitted, stopping now [-ferror-limit=]
> 20 errors generated.
> 

The same failures are also seen under x86_64-apple-darwin12 when using the llvm.org's 3.2 release branch clang compilers
to bootstrap gcc trunk (so it isn't limited to Apple's clang compilers).

> > 
> > >
> > > 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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18  2:57 ` Diego Novillo
  2012-11-18 17:05   ` Hans-Peter Nilsson
@ 2012-11-20 13:57   ` Ulrich Weigand
  1 sibling, 0 replies; 24+ messages in thread
From: Ulrich Weigand @ 2012-11-20 13:57 UTC (permalink / raw)
  To: Diego Novillo
  Cc: joern.rennecke, nathan, gingold, nickc, dje.gcc, law,
	rdsandiford, dj, wilson, rth, echristo, gcc-patches

Diego Novillo wrote:
> On Thu, Nov 15, 2012 at 4:53 PM, Diego Novillo <dnovillo@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 vec<tree> 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.Weigand@de.ibm.com

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 17:12     ` Diego Novillo
  2012-11-18 17:43       ` Hans-Peter Nilsson
  2012-11-18 19:15       ` Andrew Pinski
@ 2012-11-25 13:11       ` Richard Biener
  2012-11-25 15:25         ` Diego Novillo
  2 siblings, 1 reply; 24+ messages in thread
From: Richard Biener @ 2012-11-25 13:11 UTC (permalink / raw)
  To: Diego Novillo; +Cc: Hans-Peter Nilsson, gcc-patches

On Sun, Nov 18, 2012 at 6:12 PM, Diego Novillo <dnovillo@google.com> wrote:
> On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson <hp@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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-25 13:11       ` Richard Biener
@ 2012-11-25 15:25         ` Diego Novillo
  0 siblings, 0 replies; 24+ messages in thread
From: Diego Novillo @ 2012-11-25 15:25 UTC (permalink / raw)
  To: Richard Biener; +Cc: Hans-Peter Nilsson, gcc-patches

On Sun, Nov 25, 2012 at 8:11 AM, Richard Biener
<richard.guenther@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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-19  3:18     ` Ian Lance Taylor
@ 2012-11-19 14:46       ` David Edelsohn
  0 siblings, 0 replies; 24+ messages in thread
From: David Edelsohn @ 2012-11-19 14:46 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: Diego Novillo, GCC Patches

On Sun, Nov 18, 2012 at 10:18 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Sun, Nov 18, 2012 at 5:14 PM, David Edelsohn <dje.gcc@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.  */

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-19  1:14   ` David Edelsohn
@ 2012-11-19  3:18     ` Ian Lance Taylor
  2012-11-19 14:46       ` David Edelsohn
  0 siblings, 1 reply; 24+ messages in thread
From: Ian Lance Taylor @ 2012-11-19  3:18 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Diego Novillo, GCC Patches

On Sun, Nov 18, 2012 at 5:14 PM, David Edelsohn <dje.gcc@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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-19  1:04 ` Diego Novillo
@ 2012-11-19  1:14   ` David Edelsohn
  2012-11-19  3:18     ` Ian Lance Taylor
  0 siblings, 1 reply; 24+ messages in thread
From: David Edelsohn @ 2012-11-19  1:14 UTC (permalink / raw)
  To: Diego Novillo; +Cc: GCC Patches

On Sun, Nov 18, 2012 at 8:03 PM, Diego Novillo <dnovillo@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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
  2012-11-18 21:28 David Edelsohn
@ 2012-11-19  1:04 ` Diego Novillo
  2012-11-19  1:14   ` David Edelsohn
  0 siblings, 1 reply; 24+ messages in thread
From: Diego Novillo @ 2012-11-19  1:04 UTC (permalink / raw)
  To: David Edelsohn; +Cc: GCC Patches

On Sun, Nov 18, 2012 at 4:28 PM, David Edelsohn <dje.gcc@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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: VEC re-write [patch 01/25]
@ 2012-11-18 21:28 David Edelsohn
  2012-11-19  1:04 ` Diego Novillo
  0 siblings, 1 reply; 24+ messages in thread
From: David Edelsohn @ 2012-11-18 21:28 UTC (permalink / raw)
  To: Diego Novillo; +Cc: GCC Patches

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2012-11-25 15:25 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-15 21:53 VEC re-write [patch 01/25] Diego Novillo
     [not found] ` <50A61414.8070908@redhat.com>
2012-11-16 12:13   ` Diego Novillo
2012-11-16 12:22     ` Pedro Alves
2012-11-16 23:16 ` Ian Lance Taylor
2012-11-18  2:57 ` Diego Novillo
2012-11-18 17:05   ` Hans-Peter Nilsson
2012-11-18 17:12     ` Diego Novillo
2012-11-18 17:43       ` Hans-Peter Nilsson
2012-11-18 17:48         ` Diego Novillo
2012-11-18 19:15       ` Andrew Pinski
2012-11-19 19:57         ` Jack Howarth
2012-11-19 20:16           ` Jack Howarth
2012-11-25 13:11       ` Richard Biener
2012-11-25 15:25         ` Diego Novillo
2012-11-18 18:25     ` Andreas Tobler
2012-11-18 19:12       ` Hans-Peter Nilsson
2012-11-18 19:32         ` Andreas Tobler
2012-11-18 19:50           ` Hans-Peter Nilsson
2012-11-20 13:57   ` Ulrich Weigand
2012-11-18 21:28 David Edelsohn
2012-11-19  1:04 ` Diego Novillo
2012-11-19  1:14   ` David Edelsohn
2012-11-19  3:18     ` Ian Lance Taylor
2012-11-19 14:46       ` David Edelsohn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).