Re: C++ PATCH to integrate c++-delayed-folding branch

[Jason Merrill]

On 11/17/2015 04:09 AM, Andreas Schwab wrote:

Can we please get trunk back to bootstrap land?


Which target isn't bootstrapping for you?

Jason

Re: C++ PATCH to integrate c++-delayed-folding branch

[David Edelsohn]

On Mon, Nov 16, 2015 at 10:47 PM, Jason Merrill  wrote:
> On 11/16/2015 09:39 PM, David Edelsohn wrote:
>>
>> The PPC port seems to be bootstrapping again, but I'm not sure why.
>> Mike Meissner's patch only should have affected long double.
>
>
>> It's hard to know if there is a latent bug that has gone back into hiding.
>
>
> The problem was twofold:
>
> 1) VSX_L included IFmode, but VSa didn't, so expanding various patterns over
> VSX_L generated an IFmode insn that still had  scattered around.
> Mike's patch fixed this.
>
> 2) The delayed folding merge changed
>
>   __builtin_constant_p (non-constant-expr && false)
>
> to be false because the operand is not a C++ constant expression. Previously
> we had seen that the IFmode insn was inactive because its test was known to
> be false, but with this change we needed to evaluate its test at runtime, so
> we had to parse the insn itself, so we ran into problem #1.
>
> I have a patch to fix the __builtin_constant_p regression which I will be
> checking in shortly.

Thanks for debugging and fixing this!

- David

Re: C++ PATCH to integrate c++-delayed-folding branch

[Andreas Schwab]

Jason Merrill  writes:

> On 11/17/2015 04:09 AM, Andreas Schwab wrote:
>> Can we please get trunk back to bootstrap land?
>
> Which target isn't bootstrapping for you?

PR68346, PR68361

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: C++ PATCH to integrate c++-delayed-folding branch

[Alan Lawrence]

On 14/11/15 00:07, Jason Merrill wrote:

And here's the final patch integrating the delayed folding branch.  The general
idea is to mostly avoid folding until the end of the function, at which point we
fold everything as part of genericization.  Since many warnings rely on looking
at folded trees, we fold the arguments that we pass to the various warning
functions.  To avoid issues with combinatorial explosion, we cache the results
of folding in a hash_map.

In the future we probably want to move many of these warnings into
language-independent code so we can avoid folding for them in the front end; we
also shouldn't need to fold during genericization, but apparently not doing that
leads to optimization regressions.

This is mostly Kai's work; I just cleaned it up a bit to get it ready for the
merge.  Marek also helped some.  The largest change is hooking into the GTY
machinery to handle throwing away the folding cache rather than trying to do it
manually in various places.

Tested x86_64-pc-linux-gnu, applying to trunk.


Also PR68385 (arm-none-eabi).

Re: C++ PATCH to integrate c++-delayed-folding branch

[Andreas Schwab]

Can we please get trunk back to bootstrap land?

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: C++ PATCH to integrate c++-delayed-folding branch

[Jeff Law]

On 11/16/2015 04:12 PM, Joseph Myers wrote:

On Fri, 13 Nov 2015, Jason Merrill wrote:


In the future we probably want to move many of these warnings into
language-independent code so we can avoid folding for them in the front end;
we also shouldn't need to fold during genericization, but apparently not doing
that leads to optimization regressions.


We have similar issues for C: various places in the C front end call
c_fully_fold because folded trees are needed for warnings rather than any
language semantics needing folding.  (Others call it when a tree is about
to be wrapped in something that c_fully_fold doesn't unwrap, which could
be avoided by handling more C-specific trees at genericization time.)
Right.  The plan certainly includes pushing folding back for the C 
front-end as well.


Interestingly enough this issue has come up in the context of the kernel 
security hardening discussion as well.  Presumably the early folding in 
the C front-end is causing them to lose information they want to see in 
their plugins.


jeff

Re: C++ PATCH to integrate c++-delayed-folding branch

[Joseph Myers]

On Fri, 13 Nov 2015, Jason Merrill wrote:

> In the future we probably want to move many of these warnings into
> language-independent code so we can avoid folding for them in the front end;
> we also shouldn't need to fold during genericization, but apparently not doing
> that leads to optimization regressions.

We have similar issues for C: various places in the C front end call 
c_fully_fold because folded trees are needed for warnings rather than any 
language semantics needing folding.  (Others call it when a tree is about 
to be wrapped in something that c_fully_fold doesn't unwrap, which could 
be avoided by handling more C-specific trees at genericization time.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: C++ PATCH to integrate c++-delayed-folding branch

[Jason Merrill]

On 11/16/2015 09:39 PM, David Edelsohn wrote:

The PPC port seems to be bootstrapping again, but I'm not sure why.
Mike Meissner's patch only should have affected long double.



It's hard to know if there is a latent bug that has gone back into hiding.


The problem was twofold:

1) VSX_L included IFmode, but VSa didn't, so expanding various patterns 
over VSX_L generated an IFmode insn that still had  scattered 
around.  Mike's patch fixed this.


2) The delayed folding merge changed

  __builtin_constant_p (non-constant-expr && false)

to be false because the operand is not a C++ constant expression. 
Previously we had seen that the IFmode insn was inactive because its 
test was known to be false, but with this change we needed to evaluate 
its test at runtime, so we had to parse the insn itself, so we ran into 
problem #1.


I have a patch to fix the __builtin_constant_p regression which I will 
be checking in shortly.


Jason

Re: C++ PATCH to integrate c++-delayed-folding branch

[David Edelsohn]

The PPC port seems to be bootstrapping again, but I'm not sure why.
Mike Meissner's patch only should have affected long double.

It's hard to know if there is a latent bug that has gone back into hiding.

- David


On Sat, Nov 14, 2015 at 1:47 AM, Jason Merrill  wrote:
> On 11/13/2015 11:46 PM, David Edelsohn wrote:
>>
>> This seems to have broken bootstrap on PowerPC.  I originally saw it
>> on AIX, but duplicated it on PPC64LE Linux.
>
>
> Was this a clean build?  The gtfiles change doesn't propagate to the
> Makefile unless config.status is regenerated.
>
> Jason
>

C++ PATCH to integrate c++-delayed-folding branch

[Jason Merrill]

And here's the final patch integrating the delayed folding branch.  The 
general idea is to mostly avoid folding until the end of the function, 
at which point we fold everything as part of genericization.  Since many 
warnings rely on looking at folded trees, we fold the arguments that we 
pass to the various warning functions.  To avoid issues with 
combinatorial explosion, we cache the results of folding in a hash_map.


In the future we probably want to move many of these warnings into 
language-independent code so we can avoid folding for them in the front 
end; we also shouldn't need to fold during genericization, but 
apparently not doing that leads to optimization regressions.


This is mostly Kai's work; I just cleaned it up a bit to get it ready 
for the merge.  Marek also helped some.  The largest change is hooking 
into the GTY machinery to handle throwing away the folding cache rather 
than trying to do it manually in various places.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit e17023cb8994b6d70cf10f34242b032b551fa0dc
Author: Jason Merrill 
Date:   Fri Nov 13 17:55:50 2015 -0500

	Merge C++ delayed folding branch.

	* call.c (build_conditional_expr_1, convert_like_real)
	(convert_arg_to_ellipsis, convert_for_arg_passing): Don't fold.
	(build_new_op_1, build_over_call, build_cxx_call): Fold for warnings.
	* class.c (build_base_path, determine_primary_bases)
	(update_vtable_entry_for_fn, check_bitfield_decl)
	(layout_nonempty_base_or_field, layout_empty_base)
	(propagate_binfo_offsets, include_empty_classes)
	(layout_class_type, build_vbase_offset_vtbl_entries): Use
	fold_convert.
	* constexpr.c (cxx_eval_builtin_function_call): Fold away the NOP_EXPR.
	(cxx_eval_call_expression): Handle MEM_REF.
	(cxx_eval_pointer_plus_expression): Fold the second operand.
	(cxx_eval_constant_expression): Handle MEM_REF, UNARY_PLUS_EXPR.
	(fold_simple_1, fold_simple): New.
	(maybe_constant_value_1): Factor out from maybe_constant_value.
	(cv_cache, maybe_constant_value): Cache results.
	(maybe_constant_init): Handle null input.
	(potential_constant_expression_1): Handle RESULT_DECL, EMPTY_CLASS_EXPR.
	* cp-array-notation.c (build_array_notation_ref): Fold operands.
	* cp-gimplify.c (cp_fold_r, cp_fold): New.
	(cp_genericize_r): Use fold_convert.  Don't fold SIZEOF_EXPR.
	(cp_genericize): Fold everything.
	(contains_label_1, contains_label_p): New.
	(cp_fold, cp_fully_fold): New.
	* cp-tree.h (class cache_map): New.
	* cvt.c (cp_convert_to_pointer, ocp_convert): Use convert_to_*_nofold.
	(cp_convert_and_check): Use cp_fully_fold.
	(convert, convert_force): Don't fold.
	* decl.c (fold_sizeof_expr): Change from fold_sizeof_expr_r.
	(compute_array_index_type): Use cp_fully_fold.
	(build_enumerator): Use fold_convert.
	* decl2.c (get_guard_cond, set_guard): Use fold_convert.
	* init.c (build_zero_init_1): Fold zero-initializers.
	(build_new_1): Fold nelts calculations.
	(build_vec_delete_1): Fold conversions.
	(build_vec_init): Fold maxindex.
	* parser.c (cp_parser_binary_expression): Fold LHS of || and &&.
	(cp_parser_question_colon_clause): Fold LHS.
	* pt.c (convert_nontype_argument): Fold nullptr conversion.
	* semantics.c (finish_unary_op_expr): Fold for warnings.
	(handle_omp_array_sections_1): Fold length and low bound.
	(handle_omp_for_class_iterator): Fold various things.
	* tree.c (builtin_valid_in_constant_expr_p): Add
	BUILT_IN_ATOMIC_ALWAYS_LOCK_FREE.
	(convert_bitfield_to_declared_type): Don't fold.
	(handle_init_priority_attribute): Fold.
	(fold_if_not_in_template): Remove.
	* typeck.c (decay_conversion, build_class_member_access_expr)
	(build_simple_component_ref, cp_build_array_ref, build_vec_cmp)
	(cp_pointer_int_sum, pointer_diff): Don't fold.
	(cp_build_binary_op): Fold for warnings and PMF ops.
	(cp_build_unary_op): Fold negation of a constant, nothing else.
	(expand_ptrmemfunc_cst): Fold operations.
	* typeck2.c (split_nonconstant_init): Fold initializer.
	(store_init_value): Likewise.
	(check_narrowing): Try folding.
	* config-lang.in (gtfiles): Add cp-gimplify.c.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index a860e46..77c2936 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4748,7 +4748,7 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree arg2, tree arg3,
 	  tree cmp_type = build_same_sized_truth_vector_type (arg1_type);
 	  arg1 = build2 (NE_EXPR, cmp_type, arg1, build_zero_cst (arg1_type));
 	}
-  return fold_build3 (VEC_COND_EXPR, arg2_type, arg1, arg2, arg3);
+  return build3_loc (loc, VEC_COND_EXPR, arg2_type, arg1, arg2, arg3);
 }
 
   /* [expr.cond]
@@ -5152,9 +5152,6 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree arg2, tree arg3,
 
  valid_operands:
   result = build3_loc (loc, 

Re: C++ PATCH to integrate c++-delayed-folding branch

[David Edelsohn]

This seems to have broken bootstrap on PowerPC.  I originally saw it
on AIX, but duplicated it on PPC64LE Linux.

The failure is genoutput seems to be miscompiled by stage1 and
produces error messages implying that it did not parse rs6000/vsx.md
correctly.  I don't know if the miscompilation is genoutput sources or
libstdc++.

/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sr>,?"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 0
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 0
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 1
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 1
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 2
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 2
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 3
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 3
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sr>,?"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 0
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 0
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 1
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 1
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 2
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 2
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 3
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 3

Thanks, David

Re: C++ PATCH to integrate c++-delayed-folding branch

[Jason Merrill]

On 11/13/2015 11:46 PM, David Edelsohn wrote:

This seems to have broken bootstrap on PowerPC.  I originally saw it
on AIX, but duplicated it on PPC64LE Linux.


Was this a clean build?  The gtfiles change doesn't propagate to the 
Makefile unless config.status is regenerated.


Jason