Re: [PATCH] Better comparison of BINFOs in IPA-CP

[Richard Guenther]

On Sun, Sep 4, 2011 at 12:39 AM, Martin Jambor  wrote:
> Hi,
>
> the patch below improves the comparisons of BINFOs in IPA-CP.  The
> problem is that we can read different BINFOs for the same type (or a
> base type component) from the LTO summaries because BINFOs coming from
> different compilation units are not unified.  Because we now have the
> BINFO_VTABLE available, we can compare those instead since the VMT
> variables are unified.
>
> Bootstrapped and tested on x86_64-linux, also tested by LTO-building
> Firefox and 483.xalancbmk on the same platform (I lost the actual
> numbers but the new test returned true hundreds of times in both
> these cases).  OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
>
> Martin
>
>
> 2011-09-02  Martin Jambor  
>
>        * ipa-cp.c (values_equal_for_ipcp_p): When comparing BINFOs, compare
>        their BINFO_VTABLE,
>
> Index: src/gcc/ipa-cp.c
> ===
> --- src.orig/gcc/ipa-cp.c
> +++ src/gcc/ipa-cp.c
> @@ -800,6 +800,33 @@ values_equal_for_ipcp_p (tree x, tree y)
>   if (x == y)
>     return true;
>
> +  if (TREE_CODE (x) == TREE_BINFO && TREE_CODE (y) == TREE_BINFO)
> +    {
> +      unsigned HOST_WIDE_INT ox, oy;
> +      tree vx = BINFO_VTABLE (x);
> +      tree vy = BINFO_VTABLE (y);
> +
> +      if (!vx || !vy
> +         || TREE_CODE (vx) != POINTER_PLUS_EXPR
> +         || TREE_CODE (vy) != POINTER_PLUS_EXPR)
> +       return false;
> +
> +      ox = tree_low_cst (TREE_OPERAND (vx, 1), 1);
> +      oy = tree_low_cst (TREE_OPERAND (vx, 1), 1);
> +
> +      if (ox != oy)
> +       return false;
> +
> +      vx = TREE_OPERAND (vx, 0);
> +      vy = TREE_OPERAND (vy, 0);
> +      if (TREE_CODE (vx) != ADDR_EXPR
> +         || TREE_CODE (vy) != ADDR_EXPR)
> +       return false;
> +
> +      if (TREE_OPERAND (vx, 0) == TREE_OPERAND (vy, 0))
> +       return true;
> +    }
> +
>   if (TREE_CODE (x) == TREE_BINFO || TREE_CODE (y) == TREE_BINFO)
>     return false;
>
>

Re: [PATCH] Move versionable flag from inline summary to cgraph_node.local

[Richard Guenther]

On Sun, Sep 4, 2011 at 1:09 AM, Martin Jambor  wrote:
> Hi,
>
> we have agreed on this list recently that the versionable flag should
> be moved from the inline summary to the local part of struct
> cgraph_node because it has nothing to do with inlining and is computed
> by ipa-prop and used only by ipa-cp.  This patch does exactly that.
>
> Bootstrapped and tested on x86_64-linux.  I have LTO-built Firefox
> with it too.  OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
>
> Martin
>
>
> 2011-09-03  Martin Jambor  
>
>        * ipa-inline.h (struct inline_summary): Move versionable flag...
>        * cgraph.h (struct cgraph_local_info): ...here
>        * ipa-cp.c (determine_versionability): Use the new versionable flag.
>        (determine_versionability): Likewise.
>        (ipcp_versionable_function_p): Likewise.
>        (ipcp_generate_summary): Likewise.
>        * ipa-inline-analysis.c (dump_inline_summary): Do not dump the
>        versionable flag.
>        (compute_inline_parameters): Do not clear the versionable flag.
>        (inline_read_section): Do not stream the versionable flag.
>        (inline_write_summary): Likewise.
>        * lto-cgraph.c (lto_output_node): Stream the versionable flag.
>        (input_overwrite_node): Likewise.
>
>
> Index: src/gcc/cgraph.h
> ===
> --- src.orig/gcc/cgraph.h
> +++ src/gcc/cgraph.h
> @@ -84,10 +84,13 @@ struct GTY(()) cgraph_local_info {
>
>   /* Set when function is visible by other units.  */
>   unsigned externally_visible : 1;
> -
> +
>   /* Set once it has been finalized so we consider it to be output.  */
>   unsigned finalized : 1;
>
> +  /* False when there is something makes versioning impossible.  */
> +  unsigned versionable : 1;
> +
>   /* False when function calling convention and signature can not be changed.
>      This is the case when __builtin_apply_args is used.  */
>   unsigned can_change_signature : 1;
> Index: src/gcc/ipa-cp.c
> ===
> --- src.orig/gcc/ipa-cp.c
> +++ src/gcc/ipa-cp.c
> @@ -367,7 +367,7 @@ determine_versionability (struct cgraph_
>      present.  */
>   if (node->alias || node->thunk.thunk_p)
>     reason = "alias or thunk";
> -  else if (!inline_summary (node)->versionable)
> +  else if (!node->local.versionable)
>     reason = "not a tree_versionable_function";
>   else if (cgraph_function_body_availability (node) <= AVAIL_OVERWRITABLE)
>     reason = "insufficient body availability";
> @@ -376,7 +376,7 @@ determine_versionability (struct cgraph_
>     fprintf (dump_file, "Function %s/%i is not versionable, reason: %s.\n",
>             cgraph_node_name (node), node->uid, reason);
>
> -  inline_summary (node)->versionable = (reason == NULL);
> +  node->local.versionable = (reason == NULL);
>  }
>
>  /* Return true if it is at all technically possible to create clones of a
> @@ -385,7 +385,7 @@ determine_versionability (struct cgraph_
>  static bool
>  ipcp_versionable_function_p (struct cgraph_node *node)
>  {
> -  return inline_summary (node)->versionable;
> +  return node->local.versionable;
>  }
>
>  /* Structure holding accumulated information about callers of a node.  */
> @@ -2476,14 +2476,11 @@ ipcp_generate_summary (void)
>     fprintf (dump_file, "\nIPA constant propagation start:\n");
>   ipa_register_cgraph_hooks ();
>
> -  /* FIXME: We could propagate through thunks happily and we could be
> -     even able to clone them, if needed.  Do that later.  */
>   FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
>       {
>        /* Unreachable nodes should have been eliminated before ipcp.  */
>        gcc_assert (node->needed || node->reachable);
> -
> -       inline_summary (node)->versionable = tree_versionable_function_p 
> (node->decl);
> +       node->local.versionable = tree_versionable_function_p (node->decl);
>        ipa_analyze_node (node);
>       }
>  }
> Index: src/gcc/ipa-inline-analysis.c
> ===
> --- src.orig/gcc/ipa-inline-analysis.c
> +++ src/gcc/ipa-inline-analysis.c
> @@ -986,8 +986,6 @@ dump_inline_summary (FILE * f, struct cg
>        fprintf (f, " always_inline");
>       if (s->inlinable)
>        fprintf (f, " inlinable");
> -      if (s->versionable)
> -       fprintf (f, " versionable");
>       fprintf (f, "\n  self time:       %i\n",
>               s->self_time);
>       fprintf (f, "  global time:     %i\n", s->time);
> @@ -1642,7 +1640,7 @@ compute_inline_parameters (struct cgraph
>       struct inline_edge_summary *es = inline_edge_summary (node->callees);
>       struct predicate t = true_predicate ();
>
> -      info->inlinable = info->versionable = 0;
> +      info->inlinable = 0;
>       node->callees->call_stmt_cannot_inline_p = true;
>       node->local.can_change_signature = false;
>       es->call_stmt_time = 1;
> @@ -2408,7 +2406,6 @@ inline_read_section (struct lto_file_dec
>
>       bp

[PATCH, PR50251] set DRAP type stack realignment for stack_restore

[Tom de Vries]

Hi,

this patch fixes PR50251, which was caused by r178353.

The patch was bootstrapped and reg-tested on i686 and x86_64.
On i686, the test-cases reported failing in PR50251 pass again.

The patch selects the DRAP type stack realignment method in case a stack_restore
is used. If that is not done, the presence of the stack_restore at reload leaves
FRAME_POINTER without an elimination rule for i386 port.

OK for trunk?

Thanks,
- Tom


2011-09-03  Tom de Vries  

* explow.c (emit_stack_restore): Set crtl->need_drap if
stack_restore is emitted.
Index: gcc/explow.c
===
--- gcc/explow.c (revision 178145)
+++ gcc/explow.c (working copy)
@@ -1062,6 +1062,20 @@ emit_stack_restore (enum save_level save
   /* The default is that we use a move insn.  */
   rtx (*fcn) (rtx, rtx) = gen_move_insn;
 
+  /* If stack_realign_drap, the x86 backend emits a prologue that aligns both
+ STACK_POINTER and HARD_FRAME_POINTER.
+ If stack_realign_fp, the x86 backend emits a prologue that aligns only
+ STACK_POINTER. This renders the HARD_FRAME_POINTER unusable for accessing
+ aligned variables, which is reflected in ix86_can_eliminate.
+ We normally still have the realigned STACK_POINTER that we can use.
+ But if there is a stack restore still present at reload, it can trigger 
+ mark_not_eliminable for the STACK_POINTER, leaving no way to eliminate
+ FRAME_POINTER into a hard reg.
+ To prevent this situation, we force need_drap if we emit a stack
+ restore.  */
+  if (SUPPORTS_STACK_ALIGNMENT)
+crtl->need_drap = true;
+
   /* See if this machine has anything special to do for this kind of save.  */
   switch (save_level)
 {

Re: [PATCH, PR50251] set DRAP type stack realignment for stack_restore

[Richard Guenther]

On Sun, Sep 4, 2011 at 11:00 AM, Tom de Vries  wrote:
> Hi,
>
> this patch fixes PR50251, which was caused by r178353.
>
> The patch was bootstrapped and reg-tested on i686 and x86_64.
> On i686, the test-cases reported failing in PR50251 pass again.
>
> The patch selects the DRAP type stack realignment method in case a 
> stack_restore
> is used. If that is not done, the presence of the stack_restore at reload 
> leaves
> FRAME_POINTER without an elimination rule for i386 port.
>
> OK for trunk?

Shouldn't we eventually simply set cfun->calls_alloca when expanding either
stack save or restore?  Similar to how it is set from
allocate_dynamic_stack_space?
I'm not sure we encountered the dead stack save/restore pair before
this new folding,
so, just to make other targets not confused about them as well?

Thanks,
Richard.

> Thanks,
> - Tom
>
>
> 2011-09-03  Tom de Vries  
>
>            * explow.c (emit_stack_restore): Set crtl->need_drap if
>            stack_restore is emitted.
>

[patch] Fix PR tree-optimization/50208

[Ira Rosen]

Hi,

While analyzing def stmt in vectorizer pattern detection, we access
its stmt_vec_info which is initialized only for statements inside the
loop being analyzed. Hence if the def stmt is outside the loop, we get
a segfault. This patch checks that a statement is inside the loop
before accessing its stmt_vec_info.

Bootstrapped and tested on powerpc64-suse-linux.
Committed.

Ira

ChangeLog:

2011-09-04  Jakub Jelinek  
Ira Rosen  

 PR tree-optimization/50208
 * tree-vect-patterns.c (vect_handle_widen_mult_by_const):
 Add an argument.  Check that def_stmt is inside the loop.
(vect_recog_widen_mult_pattern): Update calls to
vect_handle_widen_mult_by_cons.
(vect_operation_fits_smaller_type): Check that def_stmt is
inside the loop.

testsuite/ChangeLog:

2011-09-04  Jakub Jelinek  
Ira Rosen  

 PR tree-optimization/50208
 * gcc.dg/vect/no-fre-pre-pr50208.c: New test.
 * gcc.dg/vect/vect.exp: Run no-fre-pre-*.c tests with
 -fno-tree-fre -fno-tree-pre.

Index: testsuite/gcc.dg/vect/no-fre-pre-pr50208.c
===
--- testsuite/gcc.dg/vect/no-fre-pre-pr50208.c  (revision 0)
+++ testsuite/gcc.dg/vect/no-fre-pre-pr50208.c  (revision 0)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+
+char c;
+int a, b;
+
+void foo (int j)
+{
+  int i;
+  while (--j)
+{
+  b = 3;
+  for (i = 0; i < 2; ++i)
+a = b ^ c;
+}
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */
Index: testsuite/gcc.dg/vect/vect.exp
===
--- testsuite/gcc.dg/vect/vect.exp  (revision 178506)
+++ testsuite/gcc.dg/vect/vect.exp  (working copy)
@@ -263,6 +263,12 @@ lappend DEFAULT_VECTCFLAGS "-fno-tree-fre"
 dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/no-tree-fre-*.\[cS\]]]  \
 "" $DEFAULT_VECTCFLAGS

+# -fno-tree-fre -fno-tree-pre
+set DEFAULT_VECTCFLAGS $SAVED_DEFAULT_VECTCFLAGS
+lappend DEFAULT_VECTCFLAGS "-fno-tree-fre" "-fno-tree-pre"
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/no-fre-pre*.\[cS\]]]  \
+"" $DEFAULT_VECTCFLAGS
+
 # Clean up.
 set dg-do-what-default ${save-dg-do-what-default}
Index: tree-vect-patterns.c
===
--- tree-vect-patterns.c(revision 178506)
+++ tree-vect-patterns.c(working copy)
@@ -344,12 +344,14 @@ vect_recog_dot_prod_pattern (VEC (gimple, heap) **
replace a_T = (TYPE) a_t; with a_it - (interm_type) a_t;  */

 static bool
-vect_handle_widen_mult_by_const (tree const_oprnd, tree *oprnd,
+vect_handle_widen_mult_by_const (gimple stmt, tree const_oprnd, tree *oprnd,
 VEC (gimple, heap) **stmts, tree type,
 tree *half_type, gimple def_stmt)
 {
   tree new_type, new_oprnd, tmp;
   gimple new_stmt;
+  loop_vec_info loop_info = STMT_VINFO_LOOP_VINFO (vinfo_for_stmt (stmt));
+  struct loop *loop = LOOP_VINFO_LOOP (loop_info);

   if (int_fits_type_p (const_oprnd, *half_type))
 {
@@ -359,6 +361,8 @@ static bool
 }

   if (TYPE_PRECISION (type) < (TYPE_PRECISION (*half_type) * 4)
+  || !gimple_bb (def_stmt)
+  || !flow_bb_inside_loop_p (loop, gimple_bb (def_stmt))
   || !vinfo_for_stmt (def_stmt))
 return false;

@@ -527,7 +531,8 @@ vect_recog_widen_mult_pattern (VEC (gimple, heap)
 {
   if (TREE_CODE (oprnd0) == INTEGER_CST
  && TREE_CODE (half_type1) == INTEGER_TYPE
-  && vect_handle_widen_mult_by_const (oprnd0, &oprnd1, stmts, type,
+  && vect_handle_widen_mult_by_const (last_stmt, oprnd0, &oprnd1,
+  stmts, type,
  &half_type1, def_stmt1))
 half_type0 = half_type1;
   else
@@ -537,7 +542,8 @@ vect_recog_widen_mult_pattern (VEC (gimple, heap)
 {
   if (TREE_CODE (oprnd1) == INTEGER_CST
   && TREE_CODE (half_type0) == INTEGER_TYPE
-  && vect_handle_widen_mult_by_const (oprnd1, &oprnd0, stmts, type,
+  && vect_handle_widen_mult_by_const (last_stmt, oprnd1, &oprnd0,
+  stmts, type,
  &half_type0, def_stmt0))
 half_type1 = half_type0;
   else
@@ -868,6 +874,8 @@ vect_operation_fits_smaller_type (gimple stmt, tre
   tree interm_type = NULL_TREE, half_type, tmp, new_oprnd, type;
   gimple def_stmt, new_stmt;
   bool first = false;
+  loop_vec_info loop_info = STMT_VINFO_LOOP_VINFO (vinfo_for_stmt (stmt));
+  struct loop *loop = LOOP_VINFO_LOOP (loop_info);

   *new_def_stmt = NULL;

@@ -898,6 +906,8 @@ vect_operation_fits_smaller_type (gimple stmt, tre
 {
   first = true;
   if (!widened_name_p (oprnd, stmt, &half_type, &def_stmt, false)
+  || !gimple_bb (def_stmt)
+  || !flow_bb_inside_loop_p (loop, gimple_bb (def_stmt))
   || !vinfo

Re: [Patch, Fortran, OOP] PR 50227: [4.7 Regression] ICE-on-valid with allocatable class variable

[Janus Weil]

Committed as r178509.

Cheers,
Janus



2011/9/1 Janus Weil :
> Hi all,
>
> here is a small patch fixing a recent OOP regression. It feels a bit
> like it's only fixing the effect instead of the cause (since I haven't
> really found the cause). But anyway, it does fix the ICE and it is
> obvious enough so that I'll commit it by Sunday if no one protests in
> the meantime.
>
> Regtested on x86_64-unknown-linux-gnu.
>
> Cheers,
> Janus
>
>
> 2011-09-01  Janus Weil  
>
>        PR fortran/50227
>        * trans-types.c (gfc_sym_type): Check for proc_name.
>
> 2011-09-01  Janus Weil  
>
>        PR fortran/50227
>        * gfortran.dg/class_45a.f03: New.
>        * gfortran.dg/class_45b.f03: New.
>

Re: [PATCH, PR50251] set DRAP type stack realignment for stack_restore

[Tom de Vries]

On 09/04/2011 11:10 AM, Richard Guenther wrote:
> On Sun, Sep 4, 2011 at 11:00 AM, Tom de Vries  wrote:
>> Hi,
>>
>> this patch fixes PR50251, which was caused by r178353.
>>
>> The patch was bootstrapped and reg-tested on i686 and x86_64.
>> On i686, the test-cases reported failing in PR50251 pass again.
>>
>> The patch selects the DRAP type stack realignment method in case a 
>> stack_restore
>> is used. If that is not done, the presence of the stack_restore at reload 
>> leaves
>> FRAME_POINTER without an elimination rule for i386 port.
>>
>> OK for trunk?
> 
> Shouldn't we eventually simply set cfun->calls_alloca when expanding either
> stack save or restore?  Similar to how it is set from
> allocate_dynamic_stack_space?
> I'm not sure we encountered the dead stack save/restore pair before
> this new folding,
> so, just to make other targets not confused about them as well?

Setting cfun->calls_alloca will work as well, but doesn't seem necessary to me.
AFAIU, since other targets don't define MAX_STACK_ALIGNMENT, they don't need to
do a realign themselves. If I disable MAX_STACK_ALIGNMENT on i386, the
middle-end handles the realign and the stack_restore causes no problems. So to
me this seems a problem with the i386-specific implementation of realignment.

I'm more worried about other similar cases not working for i386 than about other
ports. Another, more involved way to fix this, would be in reload to:
- calculate which registers we cannot use for elimination (which we already do)
- pass that as context to target.can_eliminate. The i386 target can then
  fulfill its requirement to be able to eliminate the frame pointer by
  setting need_drap if the stack pointer is not available.
I think this way we could remove most if not all of the
'crtl->need_drap = true' snippets, and have a completer solution and perhaps
also more optimal.

Is this simple crtl->need_drap fix ok for now, or should I start testing the
cfun->calls_alloca fix?

Thanks,
- Tom

> 
> Thanks,
> Richard.
> 
>> Thanks,
>> - Tom
>>
>>
>> 2011-09-03  Tom de Vries  
>>
>>* explow.c (emit_stack_restore): Set crtl->need_drap if
>>stack_restore is emitted.
>>

Ping: C-family stack check for threads

[Thomas Klein]

ping

references
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00216.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00281.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00149.html
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01872.html
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01226.html


gcc/ChangeLog

2011-09-04  Thomas Klein 
* opts.c (common_handle_option): introduce new parameters "direct" and
"indirect"
* flag-types.h (enum stack_check_type): Likewise

* explow.c (allocate_dynamic_stack_space):
- suppress stack probing if parameter "direct", "indirect" or if a
stack-limit is given
- do additional read of limit value if parameter "indirect" and a
stack-limit symbol is given
- emit a call to a stack_failure function [as an alternative to a trap
call]
(function probe_stack_range): if allowed to override the range porbe
emit generic_limit_check_stack

* config/arm/arm.c
(stack_check_work_registers): new function to find possible working
registers [only used by "stack check"]
(emit_push_regs): add push RTL instruction without keeping regnumber
and frame memory in mind.
(emit_pop_regs): add pop RTL instruction to revert the above push
(emit_stack_check_insns): new function to write RTL instructions for
stack check at prologue stage.
(arm_expand_prologue): stack check integration for ARM and Thumb-2
(thumb1_output_function_prologue): stack check integration for Thumb-1

* config/arm/arm.md
(cbranchsi4_insn): allow compare and branch using stack pointer
register [at thumb mode]
(arm_cmpsi_insn): allow comparing using stack pointer register [at arm]
(probe_stack): do not emit code when parameters "direct" or "indirect"
is given, emit move code way same as in gcc/explow.c [function
emit_stack_probe]
(probe_stack_done): dummy to make sure probe_stack insns are not
optimized away
(generic_limit_check_stack): if stack-limit and parameter "generic" is
given use the limit the same way as in function
allocate_dynamic_stack_space
(stack_failure): failure call used in stack check functions
emit_stack_check_insns, generic_limit_check_stack or
allocate_dynamic_stack_space [similar to a trap but avoid conflict with
builtin_trap]

Index: gcc/opts.c
===
--- gcc/opts.c  (revision 178508)
+++ gcc/opts.c  (working copy)
@@ -1644,6 +1644,12 @@ common_handle_option (struct gcc_options *opts,
   : STACK_CHECK_STATIC_BUILTIN
 ? STATIC_BUILTIN_STACK_CHECK
 : GENERIC_STACK_CHECK;
+  else if (!strcmp (arg, "indirect"))
+   /* This is an other stack checking method.  */
+   opts->x_flag_stack_check = INDIRECT_STACK_CHECK;
+  else if (!strcmp (arg, "direct"))
+   /* This is an other stack checking method.  */
+   opts->x_flag_stack_check = DIRECT_STACK_CHECK;
   else
warning_at (loc, 0, "unknown stack check parameter \"%s\"", arg);
   break;
Index: gcc/flag-types.h
===
--- gcc/flag-types.h(revision 178508)
+++ gcc/flag-types.h(working copy)
@@ -153,7 +153,15 @@ enum stack_check_type
 
   /* Check the stack and entirely rely on the target configuration
  files, i.e. do not use the generic mechanism at all.  */
-  FULL_BUILTIN_STACK_CHECK
+  FULL_BUILTIN_STACK_CHECK,
+
+  /* Check the stack (if possible) before allocation of local variables at
+ each function entry. The stack limit is directly given e.g. by address
+ of a symbol */
+  DIRECT_STACK_CHECK,
+  /* Check the stack (if possible) before allocation of local variables at
+ each function entry. The stack limit is given by global variable. */
+  INDIRECT_STACK_CHECK
 };
 
 /* Names for the different levels of -Wstrict-overflow=N.  The numeric
Index: gcc/explow.c
===
--- gcc/explow.c(revision 178508)
+++ gcc/explow.c(working copy)
@@ -1372,7 +1372,12 @@ allocate_dynamic_stack_space (rtx size, unsigned s
 
   /* If needed, check that we have the required amount of stack.  Take into
  account what has already been checked.  */
-  if (STACK_CHECK_MOVING_SP)
+  if (  STACK_CHECK_MOVING_SP 
+#ifdef HAVE_generic_limit_check_stack
+ || crtl->limit_stack
+#endif
+ || flag_stack_check == DIRECT_STACK_CHECK
+ || flag_stack_check == INDIRECT_STACK_CHECK)
 ;
   else if (flag_stack_check == GENERIC_STACK_CHECK)
 probe_stack_range (STACK_OLD_CHECK_PROTECT + STACK_CHECK_MAX_FRAME_SIZE,
@@ -1409,19 +1414,32 @@ allocate_dynamic_stack_space (rtx size, unsigned s
   /* Check stack bounds if necessary.  */
   if (crtl->limit_stack)
{
+  rtx limit_rtx;
  rtx available;
  rtx space_available = gen_label_rtx ();
+  if (  GET_

Re: PATCH RFA: Build stages 2 and 3 with C++

[Thomas Schwinge]

Hi!

On Sat, 16 Jul 2011 11:27:46 -0400, Diego Novillo  wrote:
> On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor  wrote:
> 
> > 2011-07-15  Ian Lance Taylor  
> >
> >        * configure.ac: Add --enable-build-poststage1-with-cxx.  If set,
> >        make C++ a boot_language.  Set and substitute
> >        POSTSTAGE1_CONFIGURE_FLAGS.
> >        * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable.
> >        (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS).
> >        * configure, Makefile.in: Rebuild.
> 
> I agree with this change.  For reference, have you measured the
> difference in bootstrap time?  Clearly, it will be slower, but how
> much?

I can provide some data from my GNU/Hurd regression and comparing to
GNU/Linux testing.

This is GCC Git master branch, going from
7c9f953a01d23c6b6885dc908d5b1dba8009efd4 (2011-07-18; ``before'') to
18540031a8b2070a56f5b7e94d6b24e8bd335c57 (2011-07-20; ``after''); which
is shortly before and after the switch to using g++.  For GNU/Hurd, I
have applied a few patches that are minor to this experiment.

kepler is a Xen domU on a AMD Athlon II X2 215 with 2700 MHz, the domU
has 1 GiB of RAM, and is running Debian GNU/Linux testing x86.

coulomb is a AMD Athlon XP with 1466 MHz, has 1 GiB of RAM, and is
running Debian GNU/Hurd unstable x86.

kepler  coulomb
before  2 h 35 min  10 h 50 min
after   3 h 00 min  13 h 00 min

The ``after'' data is averaged from two iterations only, ``before'' data
has seen many more iterations, and has (roughly) been constant over a
long period of time.  Both systems have been idle apart from the GCC
build.  The build was essentially a native ``configure && make''.

So, yes, bootstrap is slower now.  The bootstrap time now is 16 % to 20 %
longer, roughly.


Grüße,
 Thomas


pgparneuDYJvY.pgp
Description: PGP signature

Re: [RFC] Cleanup DW_CFA_GNU_args_size handling

[Gerald Pfeifer]

On Wed, 24 Aug 2011, Eric Botcazou wrote:
>> I've been trying for 2 days to replicate this with various 
>> configurations and none have failed.
> I configure for i586 with --enable-checking=yes,rtl.  And I also have a 
> comparison failure on x86-64 with the same configure options:

Which version of binutils are you using, Eric?  And which ones have
you been using, Richard?


My failures are with binutils 2.17.50 on FreeBSD 9/i386 where this is
the system toolchain.  Using a manual installation of binutils 2.21.1
there makes bootstrap pass for me.

Gerald

Re: [Patch, Fortran, OOP] PR 50227: [4.7 Regression] ICE-on-valid with allocatable class variable

[H.J. Lu]

On Sun, Sep 4, 2011 at 3:51 AM, Janus Weil  wrote:
> Committed as r178509.
>
> Cheers,
> Janus
>
>
>
> 2011/9/1 Janus Weil :
>> Hi all,
>>
>> here is a small patch fixing a recent OOP regression. It feels a bit
>> like it's only fixing the effect instead of the cause (since I haven't
>> really found the cause). But anyway, it does fix the ICE and it is
>> obvious enough so that I'll commit it by Sunday if no one protests in
>> the meantime.
>>
>> Regtested on x86_64-unknown-linux-gnu.
>>
>> Cheers,
>> Janus
>>
>>
>> 2011-09-01  Janus Weil  
>>
>>        PR fortran/50227
>>        * trans-types.c (gfc_sym_type): Check for proc_name.
>>
>> 2011-09-01  Janus Weil  
>>
>>        PR fortran/50227
>>        * gfortran.dg/class_45a.f03: New.
>>        * gfortran.dg/class_45b.f03: New.
>>
>

It caused:

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


-- 
H.J.

[patch, darwin, committed] fix PR49901

[Iain Sandoe]

the following was approved on the PR thread.
cheers,
Iain


gcc:
PR debug/49901
* config/darwin.h (DEBUG_MACRO_SECTION): New macro.

Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 178509)
+++ gcc/config/darwin.h (working copy)
@@ -413,6 +413,7 @@ extern GTY(()) int darwin_ms_struct;
 #define  
DEBUG_PUBTYPES_SECTION	"__DWARF,__debug_pubtypes,regular,debug"

 #define DEBUG_STR_SECTION  "__DWARF,__debug_str,regular,debug"
 #define DEBUG_RANGES_SECTION   "__DWARF,__debug_ranges,regular,debug"
+#define DEBUG_MACRO_SECTION"__DWARF,__debug_macro,regular,debug"

 #define TARGET_WANT_DEBUG_PUB_SECTIONS true

Re: [PATCH, PR50251] set DRAP type stack realignment for stack_restore

[H.J. Lu]

On Sun, Sep 4, 2011 at 6:44 AM, Tom de Vries  wrote:
> On 09/04/2011 11:10 AM, Richard Guenther wrote:
>> On Sun, Sep 4, 2011 at 11:00 AM, Tom de Vries  wrote:
>>> Hi,
>>>
>>> this patch fixes PR50251, which was caused by r178353.
>>>
>>> The patch was bootstrapped and reg-tested on i686 and x86_64.
>>> On i686, the test-cases reported failing in PR50251 pass again.
>>>
>>> The patch selects the DRAP type stack realignment method in case a 
>>> stack_restore
>>> is used. If that is not done, the presence of the stack_restore at reload 
>>> leaves
>>> FRAME_POINTER without an elimination rule for i386 port.
>>>
>>> OK for trunk?
>>
>> Shouldn't we eventually simply set cfun->calls_alloca when expanding either
>> stack save or restore?  Similar to how it is set from
>> allocate_dynamic_stack_space?
>> I'm not sure we encountered the dead stack save/restore pair before
>> this new folding,
>> so, just to make other targets not confused about them as well?
>
> Setting cfun->calls_alloca will work as well, but doesn't seem necessary to 
> me.
> AFAIU, since other targets don't define MAX_STACK_ALIGNMENT, they don't need 
> to
> do a realign themselves. If I disable MAX_STACK_ALIGNMENT on i386, the
> middle-end handles the realign and the stack_restore causes no problems. So to
> me this seems a problem with the i386-specific implementation of realignment.
>
> I'm more worried about other similar cases not working for i386 than about 
> other
> ports. Another, more involved way to fix this, would be in reload to:
> - calculate which registers we cannot use for elimination (which we already 
> do)
> - pass that as context to target.can_eliminate. The i386 target can then
>  fulfill its requirement to be able to eliminate the frame pointer by
>  setting need_drap if the stack pointer is not available.
> I think this way we could remove most if not all of the
> 'crtl->need_drap = true' snippets, and have a completer solution and perhaps
> also more optimal.
>

There are 2 aspects in stack realignments:

1.  Support stack variables with any alignment.
2.  Support register spill with alignment > incoming stack alignment.

You can test #2 on Sandy Bridge Linux by configuring gcc with
--with-arch=corei7-avx.


H.J.

Tweak gnat.dg/specs/debug1.ads

[Eric Botcazou]

Tested on x86_64-suse-linux and powerc-linux, applied on the mainline.


2011-09-04  Eric Botcazou  

* gnat.dg/specs/debug1.ads: Tweak pattern.


-- 
Eric Botcazou
Index: gnat.dg/specs/debug1.ads
===
--- gnat.dg/specs/debug1.ads	(revision 178488)
+++ gnat.dg/specs/debug1.ads	(working copy)
@@ -11,4 +11,4 @@ package Debug1 is
 
 end Debug1;
 
--- { dg-final { scan-assembler-times "byte\t0x1\t# DW_AT_artificial" 4 } }
+-- { dg-final { scan-assembler-times "# DW_AT_artificial" 4 } }

[PATCH] Support -m{cpu,tune}=native on Linux/Sparc

[David Miller]

gcc/

2011-09-04  David S. Miller  

* config.host: Add driver-sparc.o and sparc/x-sparc on
native sparc*-*-linux* builds.
* config/sparc/driver-sparc.c: Correct Linux strings.
* gcc/config/sparc/linux.h: Add DRIVER_SELF_SPECS.
* gcc/config/sparc/linux64.h: Likewise.
* gcc/doc/invoke.texi: Document that Linux also supports
-mcpu=native and -mtune=native on sparc.

diff --git a/gcc/config.host b/gcc/config.host
index 61a00b5..df8ba8f 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -165,6 +165,14 @@ case ${host} in
;;
 esac
 ;;
+  sparc*-*-linux*)
+case ${target} in
+  sparc*-*-linux*)
+   host_extra_gcc_objs="driver-sparc.o"
+   host_xmake_file="${host_xmake_file} sparc/x-sparc"
+   ;;
+esac
+;;
 esac
 
 # Machine-specific settings.
diff --git a/gcc/config/sparc/driver-sparc.c b/gcc/config/sparc/driver-sparc.c
index e5b91bc..f6a4e7c 100644
--- a/gcc/config/sparc/driver-sparc.c
+++ b/gcc/config/sparc/driver-sparc.c
@@ -58,7 +58,21 @@ static const struct cpu_names {
   { "SPARC-T3","niagara2" },
   { "SPARC-T4","niagara2" },
 #else
-  /* FIXME: Provide Linux/SPARC values.  */
+  { "SuperSPARC",  "supersparc" },
+  { "HyperSparc",  "hypersparc" },
+  { "SpitFire","ultrasparc" },
+  { "BlackBird",   "ultrasparc" },
+  { "Sabre",   "ultrasparc" },
+  { "Hummingbird", "ultrasparc" },
+  { "Cheetah", "ultrasparc3" },
+  { "Jalapeno","ultrasparc3" },
+  { "Jaguar",  "ultrasparc3" },
+  { "Panther", "ultrasparc3" },
+  { "Serrano", "ultrasparc3" },
+  { "UltraSparc T1",   "niagara" },
+  { "UltraSparc T2",   "niagara2" },
+  { "UltraSparc T3",   "niagara2" },
+  { "UltraSparc T4",   "niagara2" },
 #endif
   { NULL,  NULL }
   };
@@ -137,7 +151,7 @@ host_detect_local_cpu (int argc, const char **argv)
 return NULL;
 
   while (fgets (buf, sizeof (buf), f) != NULL)
-if (strncmp (buf, "cpu model", sizeof ("cpu model") - 1) == 0)
+if (strncmp (buf, "cpu\t\t:", sizeof ("cpu\t\t:") - 1) == 0)
   {
 for (i = 0; cpu_names [i].name; i++)
   if (strstr (buf, cpu_names [i].name) != NULL)
diff --git a/gcc/config/sparc/linux.h b/gcc/config/sparc/linux.h
index a9b630e..0ad4b34 100644
--- a/gcc/config/sparc/linux.h
+++ b/gcc/config/sparc/linux.h
@@ -39,6 +39,22 @@ along with GCC; see the file COPYING3.  If not see
   "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\
%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}"
 
+/* -mcpu=native handling only makes sense with compiler running on
+   a SPARC chip.  */
+#if defined(__sparc__)
+extern const char *host_detect_local_cpu (int argc, const char **argv);
+# define EXTRA_SPEC_FUNCTIONS  \
+  { "local_cpu_detect", host_detect_local_cpu },
+
+# define MCPU_MTUNE_NATIVE_SPECS   \
+   " %{mcpu=native:%

Re: Add unwind information to mips epilogues

[Richard Henderson]

On 09/01/2011 03:07 AM, Bernd Schmidt wrote:
> On 08/31/11 20:43, Richard Sandiford wrote:
>> Bernd Schmidt  writes:
>>> This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
>>> inconsistent information and aborts.
>>>
>>> Tested on mips64-elf together with the rest of the shrink-wrapping
>>> patches. Ok?
>>
>> It looks like the current code doesn't handle the RESTORE instruction.
>> Could you also test that somehow?  A mipsisa32-elf run with -mips16
>> ought to work, but some sort of spot-checking of shrink-wrapping +
>> RESTORE would be fine if that's easier.
> 
> Will look into that. You mean the mips16e_build_save_restore function?
> 
>> Also, for the frame_pointer_required case, it looks like there's a
>> window between the restoration of the frame pointer and the deallocation
>> of the stack in which the CFA is still defined in terms of the frame
>> pointer register.  Is that significant?  If not (e.g. because we
>> should never need to unwind at that point) then why do we still
>> update the CFA here:
> 
> CC'ing rth, as I'm still not terribly familiar with these issues. I've
> tried to follow alpha.c, which seems to ignore this issue.

Alpha isn't a great example here, because it hasn't been updated to
generate unwind info for epilogues at all.

At the point you restore the frame pointer, you should add a 
REG_{DEF,ADJUST}_CFA note.


r~

Re: Add unwind information to mips epilogues

[Richard Henderson]

On 09/01/2011 12:13 AM, Richard Sandiford wrote:
> Also, for the frame_pointer_required case, it looks like there's a
> window between the restoration of the frame pointer and the deallocation
> of the stack in which the CFA is still defined in terms of the frame
> pointer register.  Is that significant?  If not (e.g. because we
> should never need to unwind at that point) then why do we still
> update the CFA here:

What window are you referring to?

Best I can tell from looking at the patch we restore the CFA to the
stack pointer before anything else.

The patch looks right to me.


r~

[PATCH] Add niagara3 and niagara4 cpu types.

[David Miller]

This provides a framework to optimize for these chips and also
to enable support for several new instructions available on these
processors.

I currently have patches to add VIS2, VIS3, POPC, and FMAF (fused
multiply-add) instruction support.  I also plan on adding support for
the HPC instructions as well, likely via builtin intrinsics.  I will
post them as I finish auditing them and doing full testsuite runs
with those instructions enabled.

For now I schedule Niagara3 like Niagara2, and that's pretty accurate.
Niagara4 will be a different beast scheduling wise, so I've left it
out of the chips niagara2.md matches.

2011-09-04  David S. Miller  

* gcc/config/sparc/sparc-opts.h (PROCESSOR_NIAGARA3,
PROCESSOR_NIAGARA4): New.
* gcc/config/sparc/sparc.opt: Handle new processor types.
* gcc/config/sparc/sparc.md: Add to "cpu" attribute.
* gcc/config/sparc/sparc.h (TARGET_CPU_niagara3,
TARGET_CPU_niagara4): New, treat as niagara2.
* gcc/config/sparc/linux64.h: Handle niagara3 and niagara4
like niagara2.
* gcc/config/sparc/sol2.h: Likewise.
* gcc/config/sparc/niagara2.md: Schedule niagara3 like
niagara2.
* gcc/config/sparc/sparc.c (sparc_option_override): Add
niagara3 and niagara4 handling.
(sparc32_initialize_trampoline): Likewise.
(sparc64_initialize_trampoline): Likewise.
(sparc_use_sched_lookahead): Likewise.
(sparc_issue_rate): Likewise.
(sparc_register_move_cost): Likewise.
* gcc/config/sparc/driver-sparc.c (cpu_names): Use niagara3
and niagara4 as appropriate.
* gcc/doc/invoke.texi: Document new processor types.

diff --git a/gcc/config/sparc/linux64.h b/gcc/config/sparc/linux64.h
index 0ad1a52..c4997bb 100644
--- a/gcc/config/sparc/linux64.h
+++ b/gcc/config/sparc/linux64.h
@@ -35,7 +35,9 @@ along with GCC; see the file COPYING3.  If not see
 || TARGET_CPU_DEFAULT == TARGET_CPU_ultrasparc \
 || TARGET_CPU_DEFAULT == TARGET_CPU_ultrasparc3 \
 || TARGET_CPU_DEFAULT == TARGET_CPU_niagara \
-|| TARGET_CPU_DEFAULT == TARGET_CPU_niagara2
+|| TARGET_CPU_DEFAULT == TARGET_CPU_niagara2 \
+|| TARGET_CPU_DEFAULT == TARGET_CPU_niagara3 \
+|| TARGET_CPU_DEFAULT == TARGET_CPU_niagara4
 /* A 64 bit v9 compiler with stack-bias,
in a Medium/Low code model environment.  */
 
diff --git a/gcc/config/sparc/niagara2.md b/gcc/config/sparc/niagara2.md
index 298ebe0..9d899f2 100644
--- a/gcc/config/sparc/niagara2.md
+++ b/gcc/config/sparc/niagara2.md
@@ -1,5 +1,5 @@
-;; Scheduling description for Niagara-2.
-;;   Copyright (C) 2007 Free Software Foundation, Inc.
+;; Scheduling description for Niagara-2 and Niagara-3.
+;;   Copyright (C) 2007, 2011 Free Software Foundation, Inc.
 ;;
 ;; This file is part of GCC.
 ;;
@@ -17,74 +17,74 @@
 ;; along with GCC; see the file COPYING3.  If not see
 ;; . 
 
-;; Niagara-2 is a single-issue processor.
+;; Niagara-2 and Niagara-3 are single-issue processors.
 
 (define_automaton "niagara2_0")
 
 (define_cpu_unit "niag2_pipe" "niagara2_0")
 
 (define_insn_reservation "niag2_25cycle" 25
-  (and (eq_attr "cpu" "niagara2")
+  (and (eq_attr "cpu" "niagara2,niagara3")
 (eq_attr "type" "flushw"))
   "niag2_pipe*25")
 
 (define_insn_reservation "niag2_5cycle" 5
-  (and (eq_attr "cpu" "niagara2")
+  (and (eq_attr "cpu" "niagara2,niagara3")
 (eq_attr "type" "multi,flushw,iflush,trap"))
   "niag2_pipe*5")
 
 (define_insn_reservation "niag2_6cycle" 4
-  (and (eq_attr "cpu" "niagara2")
+  (and (eq_attr "cpu" "niagara2,niagara3")
 (eq_attr "type" "savew"))
   "niag2_pipe*4")
 
 /* Most basic operations are single-cycle. */
 (define_insn_reservation "niag2_ialu" 1
- (and (eq_attr "cpu" "niagara2")
+ (and (eq_attr "cpu" "niagara2,niagara3")
(eq_attr "type" "ialu,shift,compare,cmove"))
  "niag2_pipe")
 
 (define_insn_reservation "niag2_imul" 5
- (and (eq_attr "cpu" "niagara2")
+ (and (eq_attr "cpu" "niagara2,niagara3")
(eq_attr "type" "imul"))
  "niag2_pipe*5")
 
 (define_insn_reservation "niag2_idiv" 31
- (and (eq_attr "cpu" "niagara2")
+ (and (eq_attr "cpu" "niagara2,niagara3")
(eq_attr "type" "idiv"))
  "niag2_pipe*31")
 
 (define_insn_reservation "niag2_branch" 5
-  (and (eq_attr "cpu" "niagara2")
+  (and (eq_attr "cpu" "niagara2,niagara3")
 (eq_attr "type" "call,sibcall,call_no_delay_slot,uncond_branch,branch"))
   "niag2_pipe*5")
 
 (define_insn_reservation "niag2_3cycle_load" 3
-  (and (eq_attr "cpu" "niagara2")
+  (and (eq_attr "cpu" "niagara2,niagara3")
 (eq_attr "type" "load,fpload"))
   "niag2_pipe*3")
 
 (define_insn_reservation "niag2_1cycle_store" 1
-  (and (eq_attr "cpu" "niagara2")
+  (and (eq_attr "cpu" "niagara2,niagara3")
 (eq_attr "type" "store,fpstore"))
   "niag2_pipe")
 
 (define_insn_reservation "niag2_fp" 3
-  (and (eq_attr "cpu" "niagara2")
+  (and (eq_attr "cpu" "niagara2,niagara3")
 (eq_attr "type" "fpmove,fpcmov

C++ PATCHes for DR 1328, c++/49267, c++/49458

[Jason Merrill]

These two PRs have to do with comparing conversion operators that return 
lvalue or rvalue references.  The fix for 49458 is to consider that 
directly when deciding whether the rvalueness matches the target 
reference, before an rvalue reference to function has decayed to an 
lvalue.  Part of this fixes 49267, but I've also fixed (in the second 
patch) the code that incorrectly decided that an rvalue reference to int 
was an lvalue.


Tested x86_64-pc-linux-gnu, applying to trunk.  Also applying the 
compare_ics hunk to 4.6.


commit e41e0ca96a427873cf7d6d8228358362ca7637ca
Author: Jason Merrill 
Date:   Wed Aug 31 11:22:32 2011 -0400

	DR 1328
	* call.c (reference_binding): Set rvaluedness_matches_p properly
	for reference to function conversion ops.
	(compare_ics): Adjust.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 8421260..1fa5fc8 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -1652,6 +1652,10 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags)
 	/* The top-level caller requested that we pretend that the lvalue
 	   be treated as an rvalue.  */
 	conv->rvaluedness_matches_p = TYPE_REF_IS_RVALUE (rto);
+  else if (TREE_CODE (rfrom) == REFERENCE_TYPE)
+	/* Handle rvalue reference to function properly.  */
+	conv->rvaluedness_matches_p
+	  = (TYPE_REF_IS_RVALUE (rto) == TYPE_REF_IS_RVALUE (rfrom));
   else
 	conv->rvaluedness_matches_p 
   = (TYPE_REF_IS_RVALUE (rto) == !is_lvalue);
@@ -7960,13 +7964,13 @@ compare_ics (conversion *ics1, conversion *ics2)
 
   if (ref_conv1 && ref_conv2)
 {
-  if (!ref_conv1->this_p && !ref_conv2->this_p
-	  && (TYPE_REF_IS_RVALUE (ref_conv1->type)
-	  != TYPE_REF_IS_RVALUE (ref_conv2->type)))
+  if (!ref_conv1->this_p && !ref_conv2->this_p)
 	{
-	  if (ref_conv1->rvaluedness_matches_p)
+	  if (ref_conv1->rvaluedness_matches_p
+	  > ref_conv2->rvaluedness_matches_p)
 	return 1;
-	  if (ref_conv2->rvaluedness_matches_p)
+	  if (ref_conv2->rvaluedness_matches_p
+	  > ref_conv1->rvaluedness_matches_p)
 	return -1;
 	}
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-conv1.C b/gcc/testsuite/g++.dg/cpp0x/rv-conv1.C
new file mode 100644
index 000..3852991
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-conv1.C
@@ -0,0 +1,9 @@
+// PR c++/49267
+// { dg-options -std=c++0x }
+
+struct X {
+  operator int&();
+  operator int&&();
+};
+
+int&&x = X();
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-func3.C b/gcc/testsuite/g++.dg/cpp0x/rv-func3.C
new file mode 100644
index 000..8504682
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-func3.C
@@ -0,0 +1,10 @@
+// DR 1328
+// { dg-options -std=c++0x }
+
+template  struct A {
+  operator T&();  // #1
+  operator T&&(); // #2
+};
+typedef int Fn();
+A a;
+Fn&& f = a;
commit 41e2f64d32ca6f850f2907387285ad0d37e93a25
Author: Jason Merrill 
Date:   Wed Aug 31 16:49:33 2011 -0400

	* call.c (reference_binding): Don't set is_lvalue for an rvalue
	reference rfrom.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 1fa5fc8..c707d66 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -1576,9 +1576,10 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags)
 
   if (TREE_CODE (from) == REFERENCE_TYPE)
 {
-  /* Anything with reference type is an lvalue.  */
-  is_lvalue = clk_ordinary;
   from = TREE_TYPE (from);
+  if (!TYPE_REF_IS_RVALUE (rfrom)
+	  || TREE_CODE (from) == FUNCTION_TYPE)
+	is_lvalue = clk_ordinary;
 }
 
   if (expr && BRACE_ENCLOSED_INITIALIZER_P (expr))

C++ PATCHes for core 1358, 1360, c++/50248 (constexpr, templates, default constructor)

[Jason Merrill]

At the Bloomington C++ meeting we discussed some issues with the 
constexpr specification that the clang team encountered while trying to 
implement it.  Among the issues was a problem that also came up recently 
for us as BZ 50248: if the constexpr-ness of a template instantiation 
depends on its body, we need to instantiate it in order to decide 
whether or not an implicitly-declared function that uses it is 
constexpr.  The resolution of DR 1358 is that an instantiation of a 
constexpr template is constexpr even if it can never produce a constant 
expression.


The second patch is related to DR 1360, where the clang team was 
complaining that deciding whether or not a class is literal requires the 
implicit declaration of the default constructor, which they would like 
to do lazily.  We seem to have agreed that it can be avoided in the 
cases where doing such is useful, but while looking at this I noticed a 
bug in our handling of this stuff: the function 
synthesized_default_constructor_is_constexpr was only right for trivial 
constructors.  So now I've renamed it accordingly, and force the 
implicit declaration for the non-trivial case.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7efc1b17c6bf70cc2c4d12ce912c194f09f2ea17
Author: Jason Merrill 
Date:   Wed Aug 31 10:23:57 2011 -0400

	PR c++/50248
	Core 1358
	* init.c (perform_member_init): Don't diagnose missing inits here.
	(emit_mem_initializers): Or here.
	* method.c (process_subob_fn): Don't instantiate constexpr ctors.
	* semantics.c (cx_check_missing_mem_inits): New.
	(explain_invalid_constexpr_fn): Call it.
	(register_constexpr_fundef): Likewise.  Leave
	DECL_DECLARED_CONSTEXPR_P set when the body is unsuitable.
	(cxx_eval_call_expression): Adjust diagnostics.
	(cxx_eval_constant_expression): Catch use of 'this' in a constructor.

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 847f519..ff1884b 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -606,15 +606,6 @@ perform_member_init (tree member, tree init)
 
 	  core_type = strip_array_types (type);
 
-	  if (DECL_DECLARED_CONSTEXPR_P (current_function_decl)
-	  && !type_has_constexpr_default_constructor (core_type))
-	{
-	  if (!DECL_TEMPLATE_INSTANTIATION (current_function_decl))
-		error ("uninitialized member %qD in % constructor",
-		   member);
-	  DECL_DECLARED_CONSTEXPR_P (current_function_decl) = false;
-	}
-
 	  if (CLASS_TYPE_P (core_type)
 	  && (CLASSTYPE_READONLY_FIELDS_NEED_INIT (core_type)
 		  || CLASSTYPE_REF_FIELDS_NEED_INIT (core_type)))
@@ -962,16 +953,6 @@ emit_mem_initializers (tree mem_inits)
 			OPT_Wextra, "base class %q#T should be explicitly "
 			"initialized in the copy constructor",
 			BINFO_TYPE (subobject));
-
-	  if (DECL_DECLARED_CONSTEXPR_P (current_function_decl)
-	  && !(type_has_constexpr_default_constructor
-		   (BINFO_TYPE (subobject
-	{
-	  if (!DECL_TEMPLATE_INSTANTIATION (current_function_decl))
-		error ("uninitialized base %qT in % constructor",
-		   BINFO_TYPE (subobject));
-	  DECL_DECLARED_CONSTEXPR_P (current_function_decl) = false;
-	}
 	}
 
   /* Initialize the base.  */
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 3d272a3..74a3bdb 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -952,23 +952,14 @@ process_subob_fn (tree fn, bool move_p, tree *spec_p, bool *trivial_p,
   goto bad;
 }
 
-  if (constexpr_p)
+  if (constexpr_p && !DECL_DECLARED_CONSTEXPR_P (fn))
 {
-  /* If this is a specialization of a constexpr template, we need to
-	 force the instantiation now so that we know whether or not it's
-	 really constexpr.  */
-  if (DECL_DECLARED_CONSTEXPR_P (fn) && DECL_TEMPLATE_INSTANTIATION (fn)
-	  && !DECL_TEMPLATE_INSTANTIATED (fn))
-	instantiate_decl (fn, /*defer_ok*/false, /*expl_class*/false);
-  if (!DECL_DECLARED_CONSTEXPR_P (fn))
+  *constexpr_p = false;
+  if (msg)
 	{
-	  *constexpr_p = false;
-	  if (msg)
-	{
-	  inform (0, "defaulted constructor calls non-constexpr "
-		  "%q+D", fn);
-	  explain_invalid_constexpr_fn (fn);
-	}
+	  inform (0, "defaulted constructor calls non-constexpr "
+		  "%q+D", fn);
+	  explain_invalid_constexpr_fn (fn);
 	}
 }
 
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index ce84062..fd96d70 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5775,6 +5775,53 @@ massage_constexpr_body (tree fun, tree body)
   return body;
 }
 
+/* FUN is a constexpr constructor with massaged body BODY.  Return true
+   if some bases/fields are uninitialized, and complain if COMPLAIN.  */
+
+static bool
+cx_check_missing_mem_inits (tree fun, tree body, bool complain)
+{
+  bool bad;
+  tree field;
+  unsigned i, nelts;
+
+  if (TREE_CODE (body) != CONSTRUCTOR)
+return false;
+
+  bad = false;
+  nelts = CONSTRUCTOR_NELTS (body);
+  field = TYPE_FIELDS (DECL_CONTEXT (fun));
+  for (i = 0; i <= nelts; ++i)
+{
+  tre

Re: C++ PATCHes for core 1358, 1360, c++/50248 (constexpr, templates, default constructor)

[Gabriel Dos Reis]

On Sun, Sep 4, 2011 at 11:29 PM, Jason Merrill  wrote:
> At the Bloomington C++ meeting we discussed some issues with the constexpr
> specification that the clang team encountered while trying to implement it.
>  Among the issues was a problem that also came up recently for us as BZ
> 50248: if the constexpr-ness of a template instantiation depends on its
> body, we need to instantiate it in order to decide whether or not an
> implicitly-declared function that uses it is constexpr.  The resolution of
> DR 1358 is that an instantiation of a constexpr template is constexpr even
> if it can never produce a constant expression.

I am lost: so no diagnostic is issued but the function is deemed constexpr?

-- Gaby

Re: C++ PATCHes for core 1358, 1360, c++/50248 (constexpr, templates, default constructor)

[Jason Merrill]

On 09/05/2011 01:04 AM, Gabriel Dos Reis wrote:

On Sun, Sep 4, 2011 at 11:29 PM, Jason Merrill  wrote:

At the Bloomington C++ meeting we discussed some issues with the constexpr
specification that the clang team encountered while trying to implement it.
  Among the issues was a problem that also came up recently for us as BZ
50248: if the constexpr-ness of a template instantiation depends on its
body, we need to instantiate it in order to decide whether or not an
implicitly-declared function that uses it is constexpr.  The resolution of
DR 1358 is that an instantiation of a constexpr template is constexpr even
if it can never produce a constant expression.


I am lost: so no diagnostic is issued but the function is deemed constexpr?


For a template instantiation, correct.  If the function doesn't satisfy 
the constexpr requirements, we don't store it in the hash table and we 
complain about it if it's used in a constant expression.  We don't want 
a function to change constexpr status depending on whether it has been 
instantiated or not, so they should just stay constexpr.


Jason