[PATCH, ARM] iWMMXT maintenance

[Xinyu Qi]

Hi,

This patch maintains iWMMXT intrinsics code,
adds WMMX pipeline description
and supports iWMMXT auto-vectorization.
Ran Arm testsuite on arm-linux-gnueabi.

*gcc/config/arm/elf.h: Add option -mwmmxt.
*gcc/config/arm/arm.opt: Same.
*gcc/config/arm/arm.c (arm_option_override): Same.
 (arm_coproc_mem_operand2): Add/fix iWMMXT/iWMMXT2 intrinsic.
 (enum arm_builtins): Same.
 (builtin_description bdesc_2arg): Same.
 (builtin_description bdesc_1arg): Same.
 (arm_init_iwmmxt_builtins): Same.
 (arm_expand_binop_builtin): Same.
 (arm_expand_builtin): Same.
 (arm_output_load_gr): Same.
 (arm_output_iwmmxt_shift_immediate): New function. Same.
 (arm_output_iwmmxt_tinsr): New function. Same.
 (iwmmxt_expand_vector_init): New function. Serving for iWMMXT 
auto-vectorization.
 (iwmmxt_expand_vector_mov): New function. Same.
*gcc/config/arm/mmintrin.h: Add/fix iWMMXT/iWMMXT2 intrinsic.
*gcc/config/arm/constraints.md: Same.
*gcc/config/arm/predicates.md: Same.
*gcc/config/arm/iterators.md: Same.
*gcc/config/arm/iwmmxt.md: Same.
*gcc/config/arm/iwmmxt2.md: New file. Same.
*gcc/config/arm/arm-protos.h: Add new functions protos.
*gcc/config/arm/marvell-f-iwmmxt.md: New file. 
 Add Marvell WMMX pipeline description.
*gcc/config/arm/arm.md: Fix iWMMXT/iWMMXT2 intrinsic. 
 Add wtype for Marvell WMMX pipeline description. 
*gcc/config/arm/iwmmxt-autovec.md: New file. Support iWMMXT auto-vectorization.
*gcc/config/arm/vec-common.md: Make iWMMXT and NEON co-exist.
*gcc/config/arm/neon.md: Same.


iWMMXT_maintenance.patch.gz
Description: iWMMXT_maintenance.patch.gz

Re: [PATCH] parallelize gcc, gfortran and libstdc++ testing some more

[Jason Merrill]

OK.

Jason

C++ PATCH for c++/49216 (problems with new T[1]{})

[Jason Merrill]

The reported problem was due to creating a CONSTRUCTOR with pointer 
type, expecting it to be an array; now we only build a CONSTRUCTOR for 
array type.  While I was looking at this issue I noticed that the 
user-defined type case also had problems, because it was still using T() 
instead of {} to initialize an aggregate element without an explicit 
initializer.  And then after fixing that I needed to fix substitution 
failure recovery in convert_like_real.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit c4c9a3c2114d65faf23819ab9efdb9fdc4d650f1
Author: Jason Merrill 
Date:   Mon Jun 20 17:14:39 2011 -0400

	PR c++/49216
	* init.c (build_vec_init): Don't try to use a CONSTRUCTOR when
	base is a pointer.
	* typeck2.c (process_init_constructor_array): Use {} for classes,
	too.
	* call.c (convert_like_real): Handle substitution failure.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index e9d6e7e..caf95b0 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5621,7 +5621,7 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum,
 	expr = build_cplus_new (totype, expr, complain);
 
 	/* Remember that this was list-initialization.  */
-	if (convs->check_narrowing)
+	if (convs->check_narrowing && expr != error_mark_node)
 	  TARGET_EXPR_LIST_INIT_P (expr) = true;
 	  }
 
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 140e064..3c347a4 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -3082,8 +3082,9 @@ build_vec_init (tree base, tree maxindex, tree init,
   unsigned HOST_WIDE_INT idx;
   tree field, elt;
   /* Should we try to create a constant initializer?  */
-  bool try_const = (literal_type_p (inner_elt_type)
-			|| TYPE_HAS_CONSTEXPR_CTOR (inner_elt_type));
+  bool try_const = (TREE_CODE (atype) == ARRAY_TYPE
+			&& (literal_type_p (inner_elt_type)
+			|| TYPE_HAS_CONSTEXPR_CTOR (inner_elt_type)));
   bool saw_non_const = false;
   bool saw_const = false;
   /* If we're initializing a static array, we want to do static
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 6d6267e..ff2949c 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1051,14 +1051,9 @@ process_init_constructor_array (tree type, tree init,
 	if (type_build_ctor_call (TREE_TYPE (type)))
 	  {
 	/* If this type needs constructors run for default-initialization,
-	  we can't rely on the back end to do it for us, so build up
-	  TARGET_EXPRs.  If the type in question is a class, just build
-	  one up; if it's an array, recurse.  */
-	if (MAYBE_CLASS_TYPE_P (TREE_TYPE (type)))
-  next = build_functional_cast (TREE_TYPE (type), NULL_TREE,
-complain);
-	else
-	  next = build_constructor (init_list_type_node, NULL);
+	  we can't rely on the back end to do it for us, so make the
+	  initialization explicit by list-initializing from {}.  */
+	next = build_constructor (init_list_type_node, NULL);
 	next = digest_init (TREE_TYPE (type), next, complain);
 	  }
 	else if (!zero_init_p (TREE_TYPE (type)))
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist53.C b/gcc/testsuite/g++.dg/cpp0x/initlist53.C
new file mode 100644
index 000..750ebba
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist53.C
@@ -0,0 +1,20 @@
+// PR c++/49216
+// { dg-options -std=c++0x }
+// { dg-do run }
+
+#include 
+extern "C" void abort();
+
+bool constructed;
+
+struct A
+{
+  A(std::initializer_list) { constructed = true; }
+};
+
+int main() {
+  new A[1]{};
+  int *p = new int[1]{};
+  if (p[0] != 0 || !constructed)
+abort();
+}

Re: C++ PATCH for c++/48138 (losing __attribute ((aligned)) on template argument)

[Jason Merrill]

On 06/20/2011 10:23 AM, Jason Merrill wrote:

strip_typedefs needs to propagate DECL_USER_ALIGN as well as attributes
in the attribute list.


...except that we don't want to retain attributes on template type 
arguments, since they aren't part of mangling, so you could get a class 
template instantiation that is the same type regardless of the alignment 
of the argument, but the effective argument varies depending on which 
alignment was first used to instantiate it.


The PR suggests a warning when we drop the attributes, which makes 
sense.  This patch does not yet provide the warning in the case of 
function templates, but does for class templates.  Warning for function 
templates will wait until after Nathan's patch to improve template 
overloading diagnostics.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit d4813fc54ee69f5880e588e8b9edf97baa0ad6cc
Author: Jason Merrill 
Date:   Mon Jun 20 14:37:05 2011 -0400

	PR c++/48138
	* pt.c (canonicalize_type_argument): New.
	(convert_template_argument, unify): Use it.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 6f15101..4d2caa8 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -5916,6 +5916,28 @@ template_template_parm_bindings_ok_p (tree tparms, tree targs)
   return ret;
 }
 
+/* Since type attributes aren't mangled, we need to strip them from
+   template type arguments.  */
+
+static tree
+canonicalize_type_argument (tree arg, tsubst_flags_t complain)
+{
+  tree mv;
+  if (!arg || arg == error_mark_node || arg == TYPE_CANONICAL (arg))
+return arg;
+  mv = TYPE_MAIN_VARIANT (arg);
+  arg = strip_typedefs (arg);
+  if (TYPE_ALIGN (arg) != TYPE_ALIGN (mv)
+  || TYPE_ATTRIBUTES (arg) != TYPE_ATTRIBUTES (mv))
+{
+  if (complain & tf_warning)
+	warning (0, "ignoring attributes on template argument %qT", arg);
+  arg = build_aligned_type (arg, TYPE_ALIGN (mv));
+  arg = cp_build_type_attribute_variant (arg, TYPE_ATTRIBUTES (mv));
+}
+  return arg;
+}
+
 /* Convert the indicated template ARG as necessary to match the
indicated template PARM.  Returns the converted ARG, or
error_mark_node if the conversion was unsuccessful.  Error and
@@ -6092,7 +6114,7 @@ convert_template_argument (tree parm,
 	 the typedef, which is confusing if those future uses do not
 	 themselves also use the typedef.  */
   if (TYPE_P (val))
-	val = strip_typedefs (val);
+	val = canonicalize_type_argument (val, complain);
 }
   else
 {
@@ -6136,8 +6158,9 @@ convert_template_argument (tree parm,
   if (TREE_CODE (val) == SCOPE_REF)
 	{
 	  /* Strip typedefs from the SCOPE_REF.  */
-	  tree type = strip_typedefs (TREE_TYPE (val));
-	  tree scope = strip_typedefs (TREE_OPERAND (val, 0));
+	  tree type = canonicalize_type_argument (TREE_TYPE (val), complain);
+	  tree scope = canonicalize_type_argument (TREE_OPERAND (val, 0),
+		   complain);
 	  val = build_qualified_name (type, scope, TREE_OPERAND (val, 1),
   QUALIFIED_NAME_IS_TEMPLATE (val));
 	}
@@ -15479,7 +15502,7 @@ unify (tree tparms, tree targs, tree parm, tree arg, int strict)
 	return 1;
 
 	  /* Strip typedefs as in convert_template_argument.  */
-	  arg = strip_typedefs (arg);
+	  arg = canonicalize_type_argument (arg, tf_none);
 	}
 
   /* If ARG is a parameter pack or an expansion, we cannot unify
diff --git a/gcc/testsuite/g++.dg/ext/attr-aligned01.C b/gcc/testsuite/g++.dg/ext/attr-aligned01.C
index a051c6e..c8ec07d 100644
--- a/gcc/testsuite/g++.dg/ext/attr-aligned01.C
+++ b/gcc/testsuite/g++.dg/ext/attr-aligned01.C
@@ -1,20 +1,25 @@
 // PR c++/48138
-// { dg-options -std=c++0x }
 
 #define ALIGNED(x) __attribute__((aligned(x)))
-#define SA(X) static_assert ((X),#X)
+#define SA(X) int ar[(X)?1:-1];
 
 template
 void type_alignment(const T&) {
   struct { char c; T t; } s;
-  SA((char*)&s.t - (char*)&s.c == 8);
+  SA((char*)&s.t - (char*)&s.c == 1);
 }
 
+template  struct A { char c; T t; };
+
 int main() {
   typedef char unaligned[15];
   typedef char aligned[15] ALIGNED(8);
 
+  A a;			// { dg-warning "ignoring attributes" }
+
+  SA((char*)&a.t - (char*)&a.c == 1);
+
   aligned z;
-  type_alignment(z);
-  type_alignment(z);
+  type_alignment(z);		// { dg-warning "ignoring attributes" "" { xfail *-*-* } }
+  type_alignment(z); // { dg-warning "ignoring attributes" "" { xfail *-*-* } }
 }

Mark variables addressable if they are copied using libcall in RTL expander

[Easwaran Raman]

This fixes bugs introduced by r175063. OK for trunk if there are no
test regressions?

-Easwaran


2011-06-20  Easwaran Raman  

PR rtl-optimization/49429
* expr.c (emit_block_move_hints):  Mark MEM_EXPR(x) and
MEM_EXPR(y) addressable if emit_block_move_via_libcall is
used to copy y into x.

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 175081)
+++ gcc/expr.c  (working copy)
@@ -1181,8 +1181,19 @@ emit_block_move_hints (rtx x, rtx y, rtx size, enu
   else if (may_use_call
   && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x))
   && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (y)))
-retval = emit_block_move_via_libcall (x, y, size,
- method == BLOCK_OP_TAILCALL);
+{
+  /* Since x and y are passed to a libcall, mark the corresponding
+ tree EXPR as addressable.  */
+  tree y_expr = MEM_EXPR (y);
+  tree x_expr = MEM_EXPR (x);
+  if (y_expr)
+mark_addressable (y_expr);
+  if (x_expr)
+mark_addressable (x_expr);
+  retval = emit_block_move_via_libcall (x, y, size,
+   method == BLOCK_OP_TAILCALL);
+}
+
   else
 emit_block_move_via_loop (x, y, size, align);

Re: [Patch, Fortran, OOP] PR 49112: [4.6/4.7 Regression] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

[Steve Kargl]

On Tue, Jun 21, 2011 at 12:29:01AM +0200, Janus Weil wrote:
> Hi all,
> 
> while I continue working on some of the yet unsolved parts of this PR,
> I'm already posting a simple patch which fixes the part with
> "duplicate save" warnings on CLASS variables (which is a regression on
> 4.6 and trunk). The warnings are silenced by making the vtab and
> default initialization symbols SAVE_IMPLICIT (right now they falsely
> are SAVE_EXPLICIT). This is a pretty obvious fix, and rather safe to
> apply to trunk, I think.
> 
> However, I would also like to apply it to the 4.6 branch (which was
> frozen a few hours ago). Is there any chance to get approval by the
> RM's for this?
> 
> In any case, the patch was regtested on x86_64-unknown-linux-gnu. I'll
> commit to trunk as obvious tomorrow.
> 

Janus,

You should ping richi or jakub on IRC (#gcc channel).  That
being said, I think that it is too late in the process to 
include it in 4.6.1.

-- 
Steve

[pph] Fix binding_level's names_size streaming (issue4634071)

[Gabriel Charette]

We were streaming out the original names_size which includes the
built-in names which are not streamed out.

This only streams out the actual number of streamed names as names_size.

It appears names_size is not even used anywhere in the code
(or at least I couldn't find any use of it with `grep "names_size" -R gcc/`.
Should we just remove it?

This doesn't fix any currently failing pph tests.

Tested with bootstrap build and pph regression testing.

2011-06-20  Gabriel Charette  

* gcc/cp/pph-streamer-out.c (pph_count_filter_match): Added.
(pph_out_chain_filtered): Use pph_count_filter_match.
(pph_out_binding_level): Use pph_count_filter_match.
(pph_out_lang_specific): Fixed space typo.
(pph_write_tree): Fixed space typo.

diff --git a/gcc/cp/pph-streamer-out.c b/gcc/cp/pph-streamer-out.c
index 49847a9..1f9ae1d 100644
--- a/gcc/cp/pph-streamer-out.c
+++ b/gcc/cp/pph-streamer-out.c
@@ -383,6 +383,34 @@ pph_out_label_binding (pph_stream *stream, 
cp_label_binding *lb, bool ref_p)
 }
 
 
+/* Returns the number of nodes matching FILTER in chain
+   starting with FIRST.  */
+
+static unsigned
+pph_count_filter_match (tree first, enum chain_filter filter)
+{
+  unsigned count;
+  tree t;
+
+  switch (filter)
+{
+case NO_BUILTINS:
+  for (t = first, count = 0; t; t = TREE_CHAIN (t))
+   {
+ if (filter == NO_BUILTINS && DECL_P (t) && DECL_IS_BUILTIN (t))
+   continue;
+ count++;
+   }
+  break;
+
+default:
+  internal_error ("unknown chain_filter used in pph_count_filter_match");
+}
+
+  return count;
+}
+
+
 /* Output a chain of nodes to STREAM starting with FIRST.  Skip any
nodes that do not match FILTER.  REF_P is true if nodes in the chain
should be emitted as references.  */
@@ -402,13 +430,7 @@ pph_out_chain_filtered (pph_stream *stream, tree first, 
bool ref_p,
   return;
 }
 
-  /* Count all the nodes that match the filter.  */
-  for (t = first, count = 0; t; t = TREE_CHAIN (t))
-{
-  if (filter == NO_BUILTINS && DECL_P (t) && DECL_IS_BUILTIN (t))
-   continue;
-  count++;
-}
+  count = pph_count_filter_match (first, filter);
   pph_out_uint (stream, count);
 
   /* Output all the nodes that match the filter.  */
@@ -439,7 +461,7 @@ static void
 pph_out_binding_level (pph_stream *stream, struct cp_binding_level *bl,
bool ref_p)
 {
-  unsigned i;
+  unsigned i, streamed_names_size;
   cp_class_binding *cs;
   cp_label_binding *sl;
   struct bitpack_d bp;
@@ -448,7 +470,8 @@ pph_out_binding_level (pph_stream *stream, struct 
cp_binding_level *bl,
 return;
 
   pph_out_chain_filtered (stream, bl->names, ref_p, NO_BUILTINS);
-  pph_out_uint (stream, bl->names_size);
+  streamed_names_size = pph_count_filter_match (bl->names, NO_BUILTINS);
+  pph_out_uint (stream, streamed_names_size);
   pph_out_chain_filtered (stream, bl->namespaces, ref_p, NO_BUILTINS);
 
   pph_out_tree_vec (stream, bl->static_decls, ref_p);
@@ -714,7 +737,7 @@ pph_out_lang_specific (pph_stream *stream, tree decl, bool 
ref_p)
   ld = DECL_LANG_SPECIFIC (decl);
   if (!pph_start_record (stream, ld))
 return;
-
+
   /* Write all the fields in lang_decl_base.  */
   ldb = &ld->u.base;
   pph_out_ld_base (stream, ldb);
@@ -1080,7 +1103,7 @@ pph_write_tree (struct output_block *ob, tree expr, bool 
ref_p)
   TI_TYPEDEFS_NEEDING_ACCESS_CHECKING (expr), ref_p);
   break;
 
-case TEMPLATE_PARM_INDEX: 
+case TEMPLATE_PARM_INDEX:
   {
 template_parm_index *p = TEMPLATE_PARM_INDEX_CAST (expr);
 pph_out_tree_common (stream, expr, ref_p);

--
This patch is available for review at http://codereview.appspot.com/4634071

Re: [x32] PATCH: Remove ix86_promote_function_mode

[H. Peter Anvin]

Richard Henderson  wrote:

>On 06/20/2011 04:39 PM, H. Peter Anvin wrote:
>> sys_foo:
>>  cmpl$10, %edi
>>  jae .L1
>> 
>>  movqfoo_table(,%rdi,3), %rax
>>  retq
>> .L1:
>>  movq$-EINVAL, %rax
>>  retq
>> 
>> Enter this function with a non-normalized %rdi and you have a
>security
>> hole even though the C is perfectly fine.
>
>Yes, I get that.  Isn't it already the case that x86_64 defines the
>upper half of 32-bit inputs as garbage?  Assuming you're never
>intending
>to run an x32 kernel, but always an x32 environment within an x86_64
>kernel, where does the talk of security holes wrt non-pointers come
>from?
>
>
>r~

H.J. was proposing an ABI change.  I wanted to explain that the current ABI is 
the way it is for a reason.  x32 pointers, however, can and should be 
zero-extended since they will be 64 bits in the kernel, as you correctly point 
out.
-- 
Sent from my mobile phone. Please excuse my brevity and lack of formatting.

Re: [RFC] Fix unwind info for sparc -mflat

[Richard Henderson]

On 06/20/2011 05:33 PM, Richard Henderson wrote:
> The current code generation for -mflat uses 3 insn patterns
> which emit up two three insns (sort of) emulating the save

Lest I get sent back for remedial English, that was supposed
to be "emit two or three" but fingers got ahead of brain.


r~

[RFC] Fix unwind info for sparc -mflat

[Richard Henderson]

The current code generation for -mflat uses 3 insn patterns
which emit up two three insns (sort of) emulating the save
instruction.

The problem is that the unwind info is only produced at the
end of any pattern, leaving a 1 or 2 insn hole for which the
unwind info is not correct.

I tried to figure out why things had been done in this
slightly convoluted manner and failed.  It seems to me that
this is easily represented with the individual instructions.
A comment indicated that there had been problems with the
copy to %o7 being deleted.  Elsewhere we have successfully
used a naked USE pattern to keep such things from being
deleted.

Unfortunately, I can't seem to get -mflat to bootstrap on
gcc62 (as sparc-linux, not sparc64) either before or after
this patch, so I'm not sure what sort of pre-requisite I'm
missing in order to be able to test it...

Comments?


r~
commit 7c9f3f4fa56b6603007d254afad18c47009bc5af
Author: Richard Henderson 
Date:   Mon Jun 20 16:42:14 2011 -0700

sparc: Fix -mflat unwind info.

The old definition left a 2 instruction hole in which
unwind info was out-of-date.

diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index e50d2f1..7d83dd6 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -4617,39 +4617,6 @@ emit_save_register_window (rtx increment)
   return insn;
 }
 
-/* Generate a create_flat_frame_1 insn.  */
-
-static rtx
-gen_create_flat_frame_1 (rtx increment)
-{
-  if (TARGET_ARCH64)
-return gen_create_flat_frame_1di (increment);
-  else
-return gen_create_flat_frame_1si (increment);
-}
-
-/* Generate a create_flat_frame_2 insn.  */
-
-static rtx
-gen_create_flat_frame_2 (rtx increment)
-{
-  if (TARGET_ARCH64)
-return gen_create_flat_frame_2di (increment);
-  else
-return gen_create_flat_frame_2si (increment);
-}
-
-/* Generate a create_flat_frame_3 insn.  */
-
-static rtx
-gen_create_flat_frame_3 (rtx increment)
-{
-  if (TARGET_ARCH64)
-return gen_create_flat_frame_3di (increment);
-  else
-return gen_create_flat_frame_3si (increment);
-}
-
 /* Generate an increment for the stack pointer.  */
 
 static rtx
@@ -4793,7 +4760,6 @@ sparc_flat_expand_prologue (void)
 {
   HOST_WIDE_INT size;
   rtx insn;
-  int i;
 
   sparc_leaf_function_p = optimize > 0 && current_function_is_leaf;
 
@@ -4811,103 +4777,64 @@ sparc_flat_expand_prologue (void)
 
   if (size == 0)
 ; /* do nothing.  */
-  else if (frame_pointer_needed)
+  else
 {
-  if (size <= 4096)
-   {
- if (return_addr_reg_needed_p (sparc_leaf_function_p))
-   insn = emit_insn (gen_create_flat_frame_1 (GEN_INT (-size)));
- else
-   insn = emit_insn (gen_create_flat_frame_2 (GEN_INT (-size)));
- RTX_FRAME_RELATED_P (insn) = 1;
- for (i=0; i < XVECLEN (PATTERN (insn), 0); i++)
-   RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, i)) = 1;
-   }
-  else
-   {
- rtx reg = gen_rtx_REG (Pmode, 1), note;
- emit_move_insn (reg, GEN_INT (-size));
- if (return_addr_reg_needed_p (sparc_leaf_function_p))
-   {
- insn = emit_insn (gen_create_flat_frame_1 (reg));
- note
-   = gen_rtx_PARALLEL (VOIDmode,
-   gen_rtvec
-   (3, copy_rtx
-   (XVECEXP (PATTERN (insn), 0, 0)),
-   gen_stack_pointer_inc
-   (GEN_INT (-size)),
-   copy_rtx
-   (XVECEXP (PATTERN (insn), 0, 2;
-   }
- else
-   {
- insn = emit_insn (gen_create_flat_frame_2 (reg));
- note
-   = gen_rtx_PARALLEL (VOIDmode,
-   gen_rtvec
-   (2, copy_rtx
-   (XVECEXP (PATTERN (insn), 0, 0)),
-   gen_stack_pointer_inc
-   (GEN_INT (-size;
-   }
+  rtx size_int_rtx, size_rtx;
+
+  size_rtx = size_int_rtx = GEN_INT (-size);
 
- RTX_FRAME_RELATED_P (insn) = 1;
- add_reg_note (insn, REG_FRAME_RELATED_EXPR, note);
- for (i=0; i < XVECLEN (note, 0); i++)
-   RTX_FRAME_RELATED_P (XVECEXP (note, 0, i)) = 1;
-   }
-}
-  else if (return_addr_reg_needed_p (sparc_leaf_function_p))
-{
   if (size <= 4096)
+   insn = emit_insn (gen_stack_pointer_inc (size_int_rtx));
+  else if (size <= 8192 && !frame_pointer_needed)
{
- insn = emit_insn (gen_create_flat_frame_3 (GEN_INT (-size)));
+ insn = emit_insn (gen_stack_pointer_inc (GEN_INT (-4096)));
  RTX_FRAME_RELATED_P (insn) = 1;
- for (i=0; i < XVECLEN (PATTERN (insn), 0); i++)
-   RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, i)) = 1

Re: [patch] Improve detection of widening multiplication in the vectorizer

[H.J. Lu]

On Tue, Jun 7, 2011 at 1:50 PM, H.J. Lu  wrote:
> On Wed, Jun 1, 2011 at 2:23 AM, Ira Rosen  wrote:
>> Hi,
>>
>> The vectorizer expects widening multiplication pattern to be:
>>
>>     type a_t, b_t;
>>     TYPE a_T, b_T, prod_T;
>>
>>     a_T = (TYPE) a_t;
>>     b_T = (TYPE) b_t;
>>     prod_T = a_T * b_T;
>>
>> where type 'TYPE' is double the size of type 'type'. This works fine
>> when the types are signed. For the unsigned types the code looks like:
>>
>>     unsigned type a_t, b_t;
>>     unsigned TYPE u_prod_T;
>>     TYPE a_T, b_T, prod_T;
>>
>>      a_T = (TYPE) a_t;
>>      b_T = (TYPE) b_t;
>>      prod_T = a_T * b_T;
>>      u_prod_T = (unsigned TYPE) prod_T;
>>
>> i.e., the multiplication is done on signed, followed by a cast to unsigned.
>> This patch adds a support of such patterns and generates
>> WIDEN_MULT_EXPR for the unsigned type.
>>
>> Another unsupported case is multiplication by a constant (e.g., b_T is
>> a constant). This patch checks that the constant fits the smaller type
>> 'type' and recognizes such cases as widening multiplication.
>>
>> Bootstrapped and tested on powerpc64-suse-linux. Tested the
>> vectorization testsuite on arm-linux-gnueabi.
>> I'll commit the patch shortly if there are no comments/objections.
>>
>> Ira
>>
>> ChangeLog:
>>
>>       * tree-vectorizer.h (vect_recog_func_ptr): Make last argument to be
>>       a pointer.
>>       * tree-vect-patterns.c (vect_recog_widen_sum_pattern,
>>       vect_recog_widen_mult_pattern, vect_recog_dot_prod_pattern,
>>       vect_recog_pow_pattern): Likewise.
>>       (vect_pattern_recog_1): Remove declaration.
>>       (widened_name_p): Remove declaration.  Add new argument to specify
>>       whether to check that both types are either signed or unsigned.
>>       (vect_recog_widen_mult_pattern): Update documentation.  Handle
>>       unsigned patterns and multiplication by constants.
>>       (vect_pattern_recog_1): Update vect_recog_func references.  Use
>>       statement information from the statement returned from pattern
>>       detection functions.
>>       (vect_pattern_recog): Update vect_recog_func reference.
>>       * tree-vect-stmts.c (vectorizable_type_promotion): For widening
>>       multiplication by a constant use the type of the other operand.
>>
> .
>
> This caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49318
>

This also caused:

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


-- 
H.J.

Re: [x32] PATCH: Remove ix86_promote_function_mode

[Richard Henderson]

On 06/20/2011 04:39 PM, H. Peter Anvin wrote:
> sys_foo:
>   cmpl$10, %edi
>   jae .L1
> 
>   movqfoo_table(,%rdi,3), %rax
>   retq
> .L1:
>   movq$-EINVAL, %rax
>   retq
> 
> Enter this function with a non-normalized %rdi and you have a security
> hole even though the C is perfectly fine.

Yes, I get that.  Isn't it already the case that x86_64 defines the
upper half of 32-bit inputs as garbage?  Assuming you're never intending
to run an x32 kernel, but always an x32 environment within an x86_64
kernel, where does the talk of security holes wrt non-pointers come from?


r~

Re: [x32] PATCH: Remove ix86_promote_function_mode

[H. Peter Anvin]

On 06/20/2011 03:49 PM, Richard Henderson wrote:
>>
>> As I have already stated, if we *cannot* require pointers to be
>> zero-extended on entry to the kernel, we're going to have to have
>> special entry points for all the x32 system calls except the ones that
>> don't take pointers.
> 
> If it's a security concern, surely you have to do it in the kernel
> anyway, lest someone call into the kernel via their own assembly
> rather than something controlled by the compiler...
> 

That was the point... right now we rely on the ABI to not have any
invalid representations (except, as far as I know, on s390).  This means
any arbitrary register image presented to the kernel will be a set of
valid C objects; we then accept or reject them as being semantically
valid using normal C code in the kernel.

The issue occurs when the kernel can be entered with something in the
register that is invalid according to the calling convention, and not
have it rejected.

The current x86-64 ABI rules, for example, imply that if
%rdi = 0x3fb8c9119537d37d and the type of the first argument is
uint32_t, that is a valid argument with the value 0x9537d37d.  The extra
upper bits are ignored, and so no security issue arises.

The issue with requiring the upper bits to be normalized occurs with
code like:

static const long foo_table[10] = { ... };

long sys_foo(unsigned int bar)
{
if (bar >= 10)
return -EINVAL;

return foo_table[bar];
}


If the upper bits are required to be zero, gcc could validly translate
that to:

sys_foo:
cmpl$10, %edi
jae .L1

movqfoo_table(,%rdi,3), %rax
retq
.L1:
movq$-EINVAL, %rax
retq

Enter this function with a non-normalized %rdi and you have a security
hole even though the C is perfectly fine.

-hpa

Re: SRA generates uninitialized var use

[Xinliang David Li]

Good point -- but why does SRA have to be so complicated? If it just
do structure expansion and let subsequent phases to clean it up, would
it be simpler? Anyway this is off the topic.

Thanks,

David


On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther
 wrote:
> On Mon, Jun 20, 2011 at 6:15 PM, Xinliang David Li  wrote:
>> It is used to indicate the fact the var decl needs to have a memory
>> home (addressable) -- is there another way to do this? this is to
>> avoid the following situation:
>>
>> 1) after SRA before update SSA, the IR looks like:
>>
>>   MEM[ &SR_123] = ...
>>
>>   other_var = SR_123;   < (x)
>>
>>
>> In this case, SR_123 is not of aggregate type, and it is not
>> addressable, update_ssa won't assign a VUSE for (x), leading to
>
> The point is, SRA should never have created the above
>
>  MEM[ &SR_123] = ...
>
> Martin, why would it even create new _memory_ backed decls?
>
> Richard.
>
>> 2) final IR after SRA:
>>
>>   MEM[..., &SR_123] = ..
>>   other_var = SR_123_yyy(D);
>>
>>
>> David
>>
>> On Mon, Jun 20, 2011 at 4:13 AM, Richard Guenther
>>  wrote:
>>> On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li  
>>> wrote:
 Compiling the test case in the patch with -O2 -m32 without the fix,
 the program will abort. The problem is a var decl whose address is
 taken is not marked as addressable leading to bad SSA update (missing
 VUSE).  (the triaging used the the .after and .after_cleanup dump diff
 and found the problem).

 the test is on going. Ok after testing?
>>>
>>> That doesn't make sense.  SRA shouldn't generate anything that has
>>> its address taken.  So, where do we take its address?
>>>
>>> Richard.
>>>
 Thanks,

 David

>>>
>>
>

RE: Backport AVX256 load/store split patches to gcc 4.6 for performance boost on latest AMD/Intel hardware.

[Lu, Hongjiu]

> 
> The patch that disables default setting of unaligned load splitting
> for bdver1 has been committed
> to trunk as revision 175230.
> 
> Here is the patch: http://gcc.gnu.org/ml/gcc-patches/2011-
> 06/msg01518.html.
> 
> H. J., is there anything else that is pending to fix at this moment
> regarding avx256 load/store splitting?
> 
> If no, can we backport the set of patches to 4.6 branch now?
> 

I have no problems with backporting now.

Thanks.

H.J.

Re: __sync_swap* with acq/rel/full memory barrier semantics

[Richard Henderson]

On 06/20/2011 03:53 PM, Andrew MacLeod wrote:
> On 06/20/2011 06:33 PM, Richard Henderson wrote:
> If you want to standardize it with SYNC_  for all cases, I will create all 
> the new ones that way.

I do think the name of all the bits related to handling a builtin
function should match the builtin function itself.  It's less
confusing that way.

> I'm trying to avoid unnecessary noise on the branch. I'm bringing the
> cxx-mem-model branch up to mainline revision now, so I can go and
> submit a patch to fix the existing ones right now on mainline if you
> want... turn them all into BUILT_IN_SYNC_LOCK_TEST_AND_SET or
> whatever they need to be to match... then it will be right and wont
> affect me at all :-)

If you'd like to rename the existing stuff on mainline while you're
waiting for something else to run, please do.


r~

Re: __sync_swap* with acq/rel/full memory barrier semantics

[Andrew MacLeod]

On 06/20/2011 06:33 PM, Richard Henderson wrote:

On 06/20/2011 09:22 AM, Andrew MacLeod wrote:

builtins.c:expand_builtin_lock_test_and_set (enum machine_mode mode, tree exp,
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_1:
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_2:
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_4:

whereas everything else is 'sync_lock_test_and_set'..

So i guess it falls to prior art... I assume Aldy just cut-and-pasted
for his new routine and just changed the names in the same format.

Heh.  So this is really my fault.  Ah well.


yeah, from 2005 :-)it seems to be localized to bultins.c, 
sync-builtins.def, and c-family/c-common.c.


If you want to standardize it with SYNC_  for all cases, I will create 
all the new ones that way.


I'm trying to avoid unnecessary noise on the branch.   I'm bringing the 
cxx-mem-model branch up to mainline revision now, so I can go and submit 
a patch to fix the existing ones right now on mainline if you want...  
turn them all into BUILT_IN_SYNC_LOCK_TEST_AND_SET  or whatever they 
need to be to match...  then it will be right and wont affect me at all :-)


Andrew

Re: [x32] PATCH: Remove ix86_promote_function_mode

[Richard Henderson]

On 06/20/2011 07:33 AM, H. Peter Anvin wrote:
> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt  
>> wrote:
>>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
 Promote pointers to Pmode when passing/returning in registers is
 a security concern.
> 
> No.  Promoting *NON*-pointers (or rather, requiring non-pointers to
> having already been zero extended) is a security concern.  I thought I'd
> made that point clear already.  This is a hideously critical distinction.
> 
>> Peter, do you think it is safe to assume upper 32bits are zero in
>> user space for x32? Kernel isn't a problem since pointer is 64bit
>> in kernel and we don't pass pointers on stack to kernel.
> 
> As I have already stated, if we *cannot* require pointers to be
> zero-extended on entry to the kernel, we're going to have to have
> special entry points for all the x32 system calls except the ones that
> don't take pointers.

If it's a security concern, surely you have to do it in the kernel
anyway, lest someone call into the kernel via their own assembly
rather than something controlled by the compiler...


r~

Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

[Nicola Pero]

This patch speeds up the C/C++/ObjC/ObjC++ compiler a little bit by optimizing
lookup_attribute() and is_attribute_p().  The main change is that these 
functions
are now inline.

Benchmarking the C compiler (--enable-checking=release) compiling postgresql 
from
source shows that total compilation times are reduced by about 0.4% with this 
patch
(saving about 1 second over an average compilation time of 167 seconds).  
Benchmarking
the C++ compiler compiling gold from source shows a similar speedup (about 
0.5%).
Not a huge speedup, but a real one.

The original version of the patch was meant to speed up the Objective-C compiler
and used preprocessor macros and some hacks to get a similar performance benefit
in an uglier way.  I prefer this new version because inline functions make the 
code
neat and easy to read/understand, while providing similar performance benefits.

The patch contains the following changes:

 * a tiny tweak in attribs.c to avoid looking up the attribute specs
   for the "naked" attribute for each and every function.  If the
   function has no attributes whatsoever, the lookup is pointless.

 * a tiny tweak in tree.c to speed up attribute_list_equal() which is
   almost always called with two identical pointers.

 * inling of lookup_attribute() and is_attribute_p().  Most of the speedup
   (at least for the C/ObjC compiler, I haven't really studied the C++ one;
   it's probably the same) comes from the inling of lookup_attribute().
   The reason inlining these functions is a winner is not just because we save
   a function call each time they are used, but also because the
   inlining allows further optimizations to be applied; in particular,
   the first argument (the attribute name) is almost always a fixed
   string (eg, lookup_attribute ("visibility", attrs)) and inlining
   allows the compiler to optimize the strlen() of the first argument.
   In the case of lookup_attribute(), the attribute list argument is
   also almost always NULL; before this patch, even with a NULL attribute
   argument, you'd still perform at least the function call to 
lookup_attribute()
   and then the strlen() of the first argument.  With this patch, if
   the attribute list argument is NULL and the first argument is a string 
constant,
   which is the most likely case, nothing (expensive) should usually happen.

 * changes to lookup_attribute(), is_attribute_p() and remove_attribute()
   to require the first const char* argument to be in the form "text",
   disallowing the form "__text__" (the form "__text__" is still allowed
   in the attribute list; changing that is another simplification I'd like
   to make, but requires another wave of work).  The only place in the compiler
   where the form "__text__" was required was inside tree.c, precisely inside
   functions that are comparing/merging attribute lists.  There I
   replaced lookup_attribute() with a new static lookup_ident_attribute()
   which closely matches what is required there. I couldn't find any other 
place in the
   compiler where the form "__text__" would be required for the first argument,
   so it seemed pointless to allow it (particularly as, with the inlining, it
   would now bloat the code).  I did document this change, and added asserts to
   catch cases that may have been missed (and, of course, it all still
   bootstraps with checking enabled, and works fine for me after the change).  I
   also added an assert in attribs.c where attribute specs are registered
   to make sure that the names do not start with "_".

 * some tidyups in tree.c (in particular, the removal of 
is_attribute_with_length_p(),
   and the addition of lookup_ident_attribute(), which are internal details, 
consequences
   of the changes above).

OK to commit ?

Thanks

PS: The next steps would be:

 - move all the "attribute list" functions from tree.h/tree.c (ie, 
lookup_attribute(), remove_attribute(),
   merge_attributes(), etc) into a separate .h/.c file ?  Presumably 
attribs.h/attribs.c ?

 - see if we can manage to normalize attributes (eg, from '__text__' to 'text') 
when storing them in attribute
   lists; this would simplify/speedup the lookup_attribute() inline call.  I 
expect that would result in faster
   compilation, but obviously would need to benchmark.

I'll submit these as separate patches if I work on them; this one is big enough.

PS2: While doing benchmarks, I accidentally benchmarked an older trunk and 
couldn't but notice that compiling
 gold with the C++ compiler regressed, in terms of performance, by 1.5% 
from 2011-05-19 to 2011-06-20.


Index: ChangeLog
===
--- ChangeLog   (revision 173917)
+++ ChangeLog   (working copy)
@@ -1,3 +1,24 @@
+2011-06-19  Nicola Pero  
+
+   * attribs.c (register_attribute): Added assert to check that all
+   attribute specs are registered with a name that is not empty and
+   does not start with '_'.
+   (decl_attributes

Re: __sync_swap* with acq/rel/full memory barrier semantics

[Richard Henderson]

On 06/20/2011 09:22 AM, Andrew MacLeod wrote:
> builtins.c:expand_builtin_lock_test_and_set (enum machine_mode mode, tree exp,
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_1:
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_2:
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_4:
> 
> whereas everything else is 'sync_lock_test_and_set'..
> 
> So i guess it falls to prior art... I assume Aldy just cut-and-pasted
> for his new routine and just changed the names in the same format.

Heh.  So this is really my fault.  Ah well.

> Ah, even better. For some reason I thought I saw somewhere that it
> wasn't a full barrier. Might have just been the documentation for
> lock_test_and_set.

Very likely.


r~

[Patch, Fortran, OOP] PR 49112: [4.6/4.7 Regression] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

[Janus Weil]

Hi all,

while I continue working on some of the yet unsolved parts of this PR,
I'm already posting a simple patch which fixes the part with
"duplicate save" warnings on CLASS variables (which is a regression on
4.6 and trunk). The warnings are silenced by making the vtab and
default initialization symbols SAVE_IMPLICIT (right now they falsely
are SAVE_EXPLICIT). This is a pretty obvious fix, and rather safe to
apply to trunk, I think.

However, I would also like to apply it to the 4.6 branch (which was
frozen a few hours ago). Is there any chance to get approval by the
RM's for this?

In any case, the patch was regtested on x86_64-unknown-linux-gnu. I'll
commit to trunk as obvious tomorrow.

Cheers,
Janus


2011-06-21  Janus Weil  

PR fortran/49112
* class.c (gfc_find_derived_vtab): Make vtab and default initialization
symbols SAVE_IMPLICIT.

2011-06-21  Janus Weil  

PR fortran/49112
* gfortran.dg/class_44.f03: New.
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c	(revision 175227)
+++ gcc/fortran/class.c	(working copy)
@@ -428,7 +428,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 	  &gfc_current_locus) == FAILURE)
 	goto cleanup;
 	  vtab->attr.target = 1;
-	  vtab->attr.save = SAVE_EXPLICIT;
+	  vtab->attr.save = SAVE_IMPLICIT;
 	  vtab->attr.vtab = 1;
 	  vtab->attr.access = ACCESS_PUBLIC;
 	  gfc_set_sym_referenced (vtab);
@@ -516,7 +516,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 		  sprintf (name, "__def_init_%s", tname);
 		  gfc_get_symbol (name, ns, &def_init);
 		  def_init->attr.target = 1;
-		  def_init->attr.save = SAVE_EXPLICIT;
+		  def_init->attr.save = SAVE_IMPLICIT;
 		  def_init->attr.access = ACCESS_PUBLIC;
 		  def_init->attr.flavor = FL_VARIABLE;
 		  gfc_set_sym_referenced (def_init);


class_44.f03
Description: Binary data

RE: Remove TARGET_HELP hook

[Weddington, Eric]

> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Monday, June 20, 2011 4:03 PM
> To: Weddington, Eric
> Cc: Georg-Johann Lay; gcc-patches@gcc.gnu.org; cherty...@gmail.com;
> ae...@post.ru
> Subject: RE: Remove TARGET_HELP hook
> 
> On Mon, 20 Jun 2011, Weddington, Eric wrote:

> > Right. So, as I understand it, when we add a new device, we run the
> > shell script to regenerate the .opt file and commit the updated file,
> > correct?
> 
> Yes - and the makefile rules will regenerate the .opt file without you
> needing to run the script manually, but you do need to commit the updated
> file.

Thanks for the explanation.

Eric

RE: Backport AVX256 load/store split patches to gcc 4.6 for performance boost on latest AMD/Intel hardware.

[Fang, Changpeng]

The patch that disables default setting of unaligned load splitting for bdver1 
has been committed
to trunk as revision 175230.

Here is the patch: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01518.html.

H. J., is there anything else that is pending to fix at this moment regarding 
avx256 load/store splitting?

If no, can we backport the set of patches to 4.6 branch now?

Thanks,

Changpeng 






From: Jagasia, Harsha
Sent: Monday, June 20, 2011 12:03 PM
To: 'H.J. Lu'
Cc: 'gcc-patches@gcc.gnu.org'; 'hubi...@ucw.cz'; 'ubiz...@gmail.com'; 
'hongjiu...@intel.com'; Fang, Changpeng
Subject: RE: Backport AVX256 load/store split patches to gcc 4.6 for 
performance boost on latest AMD/Intel hardware.

> On Mon, Jun 20, 2011 at 9:58 AM,   wrote:
> > Is it ok to backport patches, with Changelogs below, already in trunk
> to gcc
> > 4.6? These patches are for AVX-256bit load store splitting. These
> patches
> > make significant performance difference >=3% to several CPU2006 and
> > Polyhedron benchmarks on latest AMD and Intel hardware. If ok, I will
> post
> > backported patches for commit approval.
> >
> > AMD plans to submit additional patches on AVX-256 load/store
> splitting to
> > trunk. We will send additional backport requests for those later once
> they
> > are accepted/comitted to trunk.
> >
>
> Since we will make some changes on trunk, I would prefer to to do
> the backport after trunk change is finished.

Ok, thanks. Adding Changpeng who is working on the trunk changes.

Harsha

RE: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on bdver1 and generic

[Fang, Changpeng]

Thanks,
Patch has been committed to trunk as revision 175230.

Changpeng


From: Uros Bizjak [ubiz...@gmail.com]
Sent: Monday, June 20, 2011 1:38 PM
To: Fang, Changpeng
Cc: H.J. Lu; gcc-patches@gcc.gnu.org; hubi...@ucw.cz; rguent...@suse.de
Subject: Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on 
bdver1 and generic

On Mon, Jun 20, 2011 at 8:03 PM, Fang, Changpeng  wrote:

>  I modified the patch as H.J. suggested (patch attached).
>
> Is it OK to commit to trunk now?

Yes, this is OK for trunk.

Thanks,
Uros.

RE: Remove TARGET_HELP hook

[Joseph S. Myers]

On Mon, 20 Jun 2011, Weddington, Eric wrote:

> > > As it's auto-generated: must it reside in repository?
> > 
> > The machinery for selecting .opt files to use and for using them (both in
> > the compiler and in .pot generation) expects them all to be in the source
> > directory.
> 
> Right. So, as I understand it, when we add a new device, we run the 
> shell script to regenerate the .opt file and commit the updated file, 
> correct?

Yes - and the makefile rules will regenerate the .opt file without you 
needing to run the script manually, but you do need to commit the updated 
file.

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

Re: [Patch, Fortran] (coarray) Add LOCK_TYPE

[Tobias Burnus]

Dear Paul,

Paul Richard Thomas wrote:

I have checked out the code for any obvious style or other minor
errors and all looks well.  However, I had a look at 8.5.6 "LOCK and
UNLOCK statements" in the standard and can only confess to feeling
very stupid tonight because I could not make head nor tail of the
example.  Thus, I can offer no judgement on the functionality of your
patch.


Well, for a single image - and more the current patch does not support - 
it is very simple: LOCK and UNLOCK do not do anything. If there is a 
STAT=, it is set to 0 and if there is a LOCK_ACQUIRED= it is set to true.


But in general, a LOCK/UNLOCK pair allows to create a critical section, 
where only one process at a time processes a certain block. Mostly one 
image (process) can hold a lock at any given time.


The simplest case for LOCK is a CRITICAL block where only one process 
(image) at a time can execute code in the block. However, LOCK allows more:
* With LOCK_ACQUIRED, it allows to perform some alternative action when 
it cannot get the lock (otherwise, LOCK waits until it can obtain the lock)
* As the example in the standard shows: One can use one lock (variable) 
to lock different section of the code.


In the example (Example 8.45): Each image (process) has a work queue. 
This queue is filled (remotely) by its neighbour, i.e. "this_image()-1", 
which is possible as the work queue is a coarray. In the first block, 
each process checks whether there is a new item in its own 
("this_image()") workqueue - in the second block, it adds a new item to 
the neighbouring queue. While an item is being added or removed from the 
queue, no parallel access should be happen - thus the access is guarded 
via a lock. The lock is also a coarray, thus, there are num_image() locks.
In the example "work_queue" is the local arrays and thus semantically 
identical to "work_queue[this_image()]" while "work_queue[me+1]" refers 
to the remote coarray on image "me+1".



OK for trunk


Thanks for the review! And good that you asked about the trans part. 
There was actually a bug in it:


+  if (stat != NULL_TREE)
+gfc_add_modify (&se.pre, lock_acquired,
+   build_int_cst (TREE_TYPE (lock_acquired), 0));

The check in "if" should be "lock_acquired" not "stat". Corrected in the 
committed version (Rev. 175228). I have now also added a run-test (cf. 
attachment) to make sure that it actually works.



PS Please give me a co-array tutorial sometime!


I will, though I think for the real fun, one needs to have a working 
mult-image support.


Tobias
! { dg-do run }
!
! LOCK/UNLOCK check
!
! PR fortran/18918
!

use iso_fortran_env
implicit none

type(lock_type) :: lock[*]
integer :: stat
logical :: acquired

LOCK(lock)
UNLOCK(lock)

stat = 99
LOCK(lock, stat=stat)
if (stat /= 0) call abort()
stat = 99
UNLOCK(lock, stat=stat)
if (stat /= 0) call abort()

if (this_image() == 1) then
  acquired = .false.
  LOCK (lock[this_image()], acquired_lock=acquired)
  if (.not. acquired) call abort()
  UNLOCK (lock[1])
end if
end

Index: trans-stmt.c
===
--- trans-stmt.c	(Revision 175227)
+++ trans-stmt.c	(Arbeitskopie)
@@ -653,6 +653,48 @@ gfc_trans_stop (gfc_code *code, bool error_stop)
 
 
 tree
+gfc_trans_lock_unlock (gfc_code *code, gfc_exec_op type ATTRIBUTE_UNUSED)
+{
+  gfc_se se, argse;
+  tree stat = NULL_TREE, lock_acquired = NULL_TREE;
+
+  /* Short cut: For single images without STAT= or LOCK_ACQUIRED
+ return early. (ERRMSG= is always untouched for -fcoarray=single.)  */
+  if (!code->expr2 && !code->expr4 && gfc_option.coarray != GFC_FCOARRAY_LIB)
+return NULL_TREE; 
+
+  gfc_init_se (&se, NULL);
+  gfc_start_block (&se.pre);
+
+  if (code->expr2)
+{
+  gcc_assert (code->expr2->expr_type == EXPR_VARIABLE);
+  gfc_init_se (&argse, NULL);
+  gfc_conv_expr_val (&argse, code->expr2);
+  stat = argse.expr;
+}
+
+  if (code->expr4)
+{
+  gcc_assert (code->expr4->expr_type == EXPR_VARIABLE);
+  gfc_init_se (&argse, NULL);
+  gfc_conv_expr_val (&argse, code->expr4);
+  lock_acquired = argse.expr;
+}
+
+  if (stat != NULL_TREE)
+gfc_add_modify (&se.pre, stat, build_int_cst (TREE_TYPE (stat), 0));
+
+  if (lock_acquired != NULL_TREE)
+gfc_add_modify (&se.pre, lock_acquired,
+		fold_convert (TREE_TYPE (lock_acquired),
+  boolean_true_node));
+
+  return gfc_finish_block (&se.pre);
+}
+
+
+tree
 gfc_trans_sync (gfc_code *code, gfc_exec_op type)
 {
   gfc_se se, argse;
Index: resolve.c
===
--- resolve.c	(Revision 175227)
+++ resolve.c	(Arbeitskopie)
@@ -6235,7 +6235,7 @@ gfc_resolve_iterator (gfc_iterator *iter, bool rea
   == FAILURE)
 return FAILURE;
 
-  if (gfc_check_vardef_context (iter->var, false, _("iterator variable"))
+  if (gfc_check_vardef_context (iter->var, false, false, _("iterator variable"))
   == FAILURE)
 r

[PATCH] parallelize gcc, gfortran and libstdc++ testing some more

[Jakub Jelinek]

On Mon, Jun 20, 2011 at 03:54:59PM +0200, Jakub Jelinek wrote:
> On Mon, Jun 20, 2011 at 09:28:56AM -0400, Jason Merrill wrote:
> > On 06/17/2011 08:20 PM, Mike Stump wrote:
> > >On Jun 17, 2011, at 10:47 AM, Nathan Froyd wrote:
> > >>I've done a lot of g++-only testsuite runs lately
> > >
> > >I think it is reasonable to have even more of them, say, if you have 16 
> > >cores and just test c++...  I wonder what the scaling is like as we 
> > >approach larger N.  :-)
> > 
> > In my test runs, one of the libstdc++ batches (normal3) takes longer
> > than any of the g++ batches, so breaking that up would be more
> > effective for me.  :)
> 
> Yeah, certainly, libstdc++ needs more parallelization most.
> But, as I wrote already to Rainer in Autumn, the methodology
> for splitting things up should be on a fast box look at
> the time spent in each of the parts as reported by dejagnu
> in the log files, and split it to make the jobs roughly even
> sized with not overcomplicated patterns.

So, here is a patch that parallelizes the longest test chunks
on x86_64-linux some more.

libstdc++ testing is now split into 10 jobs, roughly equally sized
(used to be 4), check-gcc testing is now split into 10 jobs too (used to
be 7, but the new division attempts to be more balanced, fastest
job takes for me 8 minutes and longest job takes 11), and check-gfortran
is now run in 7 jobs instead of 4.  This should make these more comparable
e.g. to check-g++ chunks etc.

Regtested on x86_64-linux, verified the merged *.sum files are identical.
Ok for trunk?

2011-06-20  Jakub Jelinek  

* Makefile.in (dg_target_exps): Set.
(check_gcc_parallelize): Parallelize gcc testing into 10 jobs
instead of 7, try to divide it more evenly.

* Make-lang.in (check_gfortran_parallelize): Parallelize dg.exp
into 6 jobs instead of 3.

* testsuite/Makefile.am (check_DEJAGNU_normal_targets): Add
check-DEJAGNUnormal[4-9].
(check-DEJAGNU): Split into 10 jobs for parallel testing instead of 4.
* testsuite/Makefile.in: Regenerated.

--- gcc/Makefile.in.jj  2011-06-15 11:54:43.0 +0200
+++ gcc/Makefile.in 2011-06-20 19:12:06.593450989 +0200
@@ -501,6 +501,10 @@ xm_include_list=@xm_include_list@
 xm_defines=@xm_defines@
 lang_checks=check-gcc
 lang_checks_parallelized=check-gcc
+dg_target_exps:=alpha.exp,arm.exp,avr.exp,bfin.exp,cris.exp,frv.exp
+dg_target_exps:=$(dg_target_exps),i386.exp,ia64.exp,m68k.exp,microblaze.exp
+dg_target_exps:=$(dg_target_exps),mips.exp,powerpc.exp,rx.exp,s390.exp,sh.exp
+dg_target_exps:=$(dg_target_exps),sparc.exp,spu.exp,xstormy16.exp
 # This lists a couple of test files that take most time during check-gcc.
 # When doing parallelized check-gcc, these can run in parallel with the
 # remaining tests.  Each word in this variable stands for work for one
@@ -514,10 +518,14 @@ lang_checks_parallelized=check-gcc
 # */ prefixed to it in runtest_file_p, it is usually desirable to include
 # a subdirectory name.
 check_gcc_parallelize=execute.exp=execute/2* \
- execute.exp=execute/\[013-9a-zA-Z\]* \
- compile.exp dg.exp \
- dg-torture.exp,builtins.exp \
- struct-layout-1.exp,unsorted.exp,stackalign.exp,i386.exp
+ execute.exp=execute/\[013-9a-fA-F\]* \
+ execute.exp=execute/\[pP\]*,dg.exp \
+ 
execute.exp=execute/\[g-oq-zG-OQ-Z\]*,compile.exp=compile/2* \
+ compile.exp=compile/\[9pP\]*,builtins.exp \
+ compile.exp=compile/\[013-8a-oq-zA-OQ-Z\]* \
+ dg-torture.exp,ieee.exp \
+ vect.exp,guality.exp,unsorted.exp \
+ struct-layout-1.exp,stackalign.exp,$(dg_target_exps)
 lang_opt_files=@lang_opt_files@ $(srcdir)/c-family/c.opt $(srcdir)/common.opt
 lang_specs_files=@lang_specs_files@
 lang_tree_files=@lang_tree_files@
--- gcc/fortran/Make-lang.in.jj 2011-05-24 23:59:28.0 +0200
+++ gcc/fortran/Make-lang.in2011-06-20 20:29:29.986808197 +0200
@@ -171,9 +171,12 @@ check-fortran-subtargets : check-gfortra
 lang_checks += check-gfortran
 lang_checks_parallelized += check-gfortran
 # For description see comment above check_gcc_parallelize in gcc/Makefile.in.
-check_gfortran_parallelize = dg.exp=gfortran.dg/\[a-cA-C\]* \
-dg.exp=gfortran.dg/\[d-mD-M\]* \
-dg.exp=gfortran.dg/\[n-zN-Z0-9\]*
+check_gfortran_parallelize = dg.exp=gfortran.dg/\[adAD\]* \
+dg.exp=gfortran.dg/\[bcBC\]* \
+dg.exp=gfortran.dg/\[nopNOP\]* \
+dg.exp=gfortran.dg/\[isuvISUV\]* \
+dg.exp=gfortran.dg/\[efhkqrxzEFHKQRXZ\]* \
+dg.exp=gfortran.dg/\[0-9gjlmtwyGJLMTWY\]*
 
 # GFORTRAN documentation.
 GFORTRAN_TEXI = \
--- libstdc++-v3/testsuite/Makefile.am.jj   

RE: Remove TARGET_HELP hook

[Weddington, Eric]

> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Monday, June 20, 2011 1:20 PM
> To: Georg-Johann Lay
> Cc: gcc-patches@gcc.gnu.org; cherty...@gmail.com; ae...@post.ru;
> Weddington, Eric
> Subject: Re: Remove TARGET_HELP hook
> 
> On Mon, 20 Jun 2011, Georg-Johann Lay wrote:
> 
> > > Index: gcc/config/avr/avr-tables.opt
> > > ===
> > > --- gcc/config/avr/avr-tables.opt (revision 0)
> > > +++ gcc/config/avr/avr-tables.opt (revision 0)
> >
> > As it's auto-generated: must it reside in repository?
> 
> The machinery for selecting .opt files to use and for using them (both in
> the compiler and in .pot generation) expects them all to be in the source
> directory.

Right. So, as I understand it, when we add a new device, we run the shell 
script to regenerate the .opt file and commit the updated file, correct?

Re: [PATCH][RFC][1/2] Bitfield lowering, add BIT_FIELD_EXPR

[Andrew Pinski]

On Mon, Jun 20, 2011 at 1:54 PM, Richard Guenther
 wrote:
> Yeah, well.  We have mostly no target dependency in those gimple
> statement speed/size cost metric, so the above 3 is matching
> how the expansion to gimple shift/mask stmts would measure.

Except RTH has mentioned there is already a way to expand it using
that one instruction (insv and such). So I think you can measure it
without a target hook really.

Thanks,
Andrew Pinski

Re: [PATCH][RFC][1/2] Bitfield lowering, add BIT_FIELD_EXPR

[Richard Guenther]

On Mon, Jun 20, 2011 at 8:43 PM, Andrew Pinski  wrote:
> On Mon, Jun 20, 2011 at 7:19 AM, William J. Schmidt
>  wrote:
>> On Thu, 2011-06-16 at 09:49 -0700, Richard Henderson wrote:
>>> On 06/16/2011 04:35 AM, Richard Guenther wrote:
>>> >
>>> > +     /* Bit-field insertion needs several shift and mask operations.  */
>>> > +     case BIT_FIELD_EXPR:
>>> > +       return 3;
>>>
>>> ... depending on the target, of course.
>>>
>>
>> Agreed -- this is a single-instruction operation on PowerPC.  Probably
>> need some target-specific weights here.
>
> It is also a single instruction on MIPS32R2 and MIPS64R2.  So a target
> hook is the best here rather than a constant number in the target hook
> field.

Yeah, well.  We have mostly no target dependency in those gimple
statement speed/size cost metric, so the above 3 is matching
how the expansion to gimple shift/mask stmts would measure.

Richard.

> Thanks,
> Andrew Pinski
>

Re: SRA generates uninitialized var use

[Richard Guenther]

On Mon, Jun 20, 2011 at 6:15 PM, Xinliang David Li  wrote:
> It is used to indicate the fact the var decl needs to have a memory
> home (addressable) -- is there another way to do this? this is to
> avoid the following situation:
>
> 1) after SRA before update SSA, the IR looks like:
>
>   MEM[ &SR_123] = ...
>
>   other_var = SR_123;   < (x)
>
>
> In this case, SR_123 is not of aggregate type, and it is not
> addressable, update_ssa won't assign a VUSE for (x), leading to

The point is, SRA should never have created the above

  MEM[ &SR_123] = ...

Martin, why would it even create new _memory_ backed decls?

Richard.

> 2) final IR after SRA:
>
>   MEM[..., &SR_123] = ..
>   other_var = SR_123_yyy(D);
>
>
> David
>
> On Mon, Jun 20, 2011 at 4:13 AM, Richard Guenther
>  wrote:
>> On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li  
>> wrote:
>>> Compiling the test case in the patch with -O2 -m32 without the fix,
>>> the program will abort. The problem is a var decl whose address is
>>> taken is not marked as addressable leading to bad SSA update (missing
>>> VUSE).  (the triaging used the the .after and .after_cleanup dump diff
>>> and found the problem).
>>>
>>> the test is on going. Ok after testing?
>>
>> That doesn't make sense.  SRA shouldn't generate anything that has
>> its address taken.  So, where do we take its address?
>>
>> Richard.
>>
>>> Thanks,
>>>
>>> David
>>>
>>
>

[testsuite] scan-assembler variants to use 'unresolved' for missing file

[Janis Johnson]

Variants of scan-assembler, used in the dg-final steps of a test, do
not check that the output file exists, so it's reported as an error.
With this patch, if the file is missing then the check is reported as
unresolved using the same message as for pass/fail, and the reason for
the unresolved test is reported in the log file.  This matches recent
changes for scan-dump and object-size.

OK for trunk, and later for 4.6?

Janis
2011-06-20  Janis Johnson  

Re: Add __builtin_clrsb, similar to clz/ctz

[Richard Henderson]

On 06/20/2011 12:38 PM, Bernd Schmidt wrote:
> D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this
> showed a problem with some of the existing simplify_const_unop cases:
> for ffs/clz/ctz/clrsb/parity/popcount, we should look at the mode of the
> operand, rather than the mode of the operation. This limits what we can
> do in that function, since op_mode is sometimes VOIDmode - we really
> should add builtin folders for these at some point.
> 
> New patch below. Retested on i686 and bfin.
> 

Ok.

I'm not going to bike-shed the function name.  If, at some point
before 4.7 is released we agree on another name, we can change it.


r~

Re: Add __builtin_clrsb, similar to clz/ctz

[Bernd Schmidt]

On 06/16/2011 06:25 PM, Richard Henderson wrote:
> On 06/16/2011 05:44 AM, Bernd Schmidt wrote:
>> +@deftypefn {Built-in Function} int __builtin_clrsb (unsigned int x)
>> +Returns the number of leading redundant sign bits in @var{x}, starting
>> +at the most significant bit position.
>> +@end deftypefn
> 
> Do we want a signed argument, since we're talking about signs?

Err, yes. It's signed everywhere else (builtins.def etc.).

> It would seem that unlike clz, this function is not undefined for zero.
> What about INT_MIN?  Do all cpus handle those edge cases the same way?

-1 and zero should both produce the same value, 31 (for a 32 bit
integer). I don't see why INT_MIN should be special - the return value
is zero. This is true for C6X and Blackfin; ARM documentation suggests
it's also true for their VCLS instruction. I've not found proper
picochip documentation but some other documents that suggest it's also
implemented this way.

> Do you get smaller code in general from
> 
>   if (x < 0)
> x = ~x;
>   if (x == 0)
> return W_TYPE_SIZE - 1;
>   count_leading_zeros(ret, x);
>   return ret - 1;

Probably.

>> -(define_insn "signbitssi2"
>> +(define_insn "clrsbsi2"
>>[(set (match_operand:HI 0 "register_operand" "=d")
>>  (if_then_else:HI
>>   (lt (match_operand:SI 1 "register_operand" "d") (const_int 0))
> 
> No use of the new rtx code?

D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this
showed a problem with some of the existing simplify_const_unop cases:
for ffs/clz/ctz/clrsb/parity/popcount, we should look at the mode of the
operand, rather than the mode of the operation. This limits what we can
do in that function, since op_mode is sometimes VOIDmode - we really
should add builtin folders for these at some point.

New patch below. Retested on i686 and bfin.


Bernd
libgcc/
* Makefile.in (lib2funcs): Add _clrsbsi2 and _clrsbdi2.
* libgcc-std.ver.in (GCC_4.7.0): New section.

gcc/
* doc/extend.texi (__builtin_clrsb, __builtin_clrsbl,
__builtin_clrsbll): Document.
* doc/rtl.texi (clrsb): New entry.
* optabs.c (widen_leading): Renamed from widen_clz.  New argument
UNOPTAB.  All callers changed.  Use UNOPTAB instead of clz_optab.
(expand_unop): Handle clrsb_optab.
(init_optabs): Initialize it.
* optabs.h (enum optab_index): New entry OTI_clrsb.
(clrsb_optab): Define.
* genopinit.c (optabs): Add an entry for it.
* builtins.c (expand_builtin): Handle clrsb builtin functions.
* builtins.def (BUILT_IN_CLRSB, BUILT_IN_CLRSBIMAX, BUILT_IN_CLRSBL,
BUILT_IN_CLRSBLL): New.
* rtl.def (CLRSB): New code.
* dwarf2out.c (mem_loc_descriptor): Handle it.
* simplify-rtx.c (simplify_const_unary_operation): Likewise.
Use op_mode rather than mode when optimizing ffs, clz, ctz, parity
and popcount.
* libgcc2.c (__clrsbSI2, __clrsbDI2): New functions.
* libgcc2.h (__clrsbSI2, __clrsbDI2): Define and declare.
(__ctzDI2): Move declaration.
* config/bfin/bfin.md (clrsbsi2): New expander.
(signbitssi2): Use the CLRSB rtx.
(clrsbhi2): Renamed from signbitshi2.  Use the CLRSB rtx.
* config/bfin/bfin.c (bdesc_1arg): Changed accordingly.

gcc/testsuite/
* gcc.c-torture/excute/builtin-bitops-1.c (MAKE_FUNS): Make
my_clrsb test functions.
(main): Test clrsb.
* gcc.dg/builtin-protos-1.c (test_s, test_u, test_sl, test_ul,
test_sll, test_ull): Add clrsb tests.
* gcc.dg/torture/builtin-attr-1.c: Add tests for clrsb, clrsbl,
clrsbll.

Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in  (revision 174339)
+++ libgcc/Makefile.in  (working copy)
@@ -320,7 +320,7 @@ lib2funcs = _muldi3 _negdi2 _lshrdi3 _as
_ctzsi2 _ctzdi2 _popcount_tab _popcountsi2 _popcountdi2\
_paritysi2 _paritydi2 _powisf2 _powidf2 _powixf2 _powitf2  \
_mulsc3 _muldc3 _mulxc3 _multc3 _divsc3 _divdc3 _divxc3\
-   _divtc3 _bswapsi2 _bswapdi2
+   _divtc3 _bswapsi2 _bswapdi2 _clrsbsi2 _clrsbdi2
 
 # The floating-point conversion routines that involve a single-word integer.
 # XX stands for the integer mode.
Index: libgcc/libgcc-std.ver.in
===
--- libgcc/libgcc-std.ver.in(revision 174339)
+++ libgcc/libgcc-std.ver.in(working copy)
@@ -1920,3 +1920,10 @@ GCC_4.6.0 {
   __morestack_initial_sp
   __splitstack_find
 }
+
+%inherit GCC_4.7.0 GCC_4.6.0
+GCC_4.7.0 {
+  __PFX__clrsbsi2
+  __PFX__clrsbdi2
+  __PFX__clrsbti2
+}
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 174339)
+++ gcc/doc/extend.texi (working copy)
@@ -7828,6 +7828,12 @@ Returns the number of trailing 0-bi

Re: patch trunk: seek plugin also in a language specific directory when given a short name

[Basile Starynkevitch]

Hello All,

Reference http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00477.html - I
am essentially pinging it, but improving the ChangeLog entry.

The attached patch to trunk 175201 makes cc1, cc1plus, ... lto1 also
search a language specific subdirectory.

# gcc/ChangeLog entry ##
2011-06-20  Basile Starynkevitch  

* plugin.c: Update copyright year.
(PLUGIN_FILE_SUFFIX): New macro.
(add_new_plugin): Short-named plugins are also searched in a
language-specific sub-directory.

* doc/plugins.texi (Loading Plugins): Document how short-named
plugins are searched in a language-specific sub-directory.
(Plugin callbacks): Remind that PLUGIN_PRAGMAS event is not
possible from lto1.


Ok for trunk? With what changes?

Regards.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi	(revision 175201)
+++ gcc/doc/plugins.texi	(working copy)
@@ -23,10 +23,16 @@ plugins as key-value pairs. Multiple plugins can b
 specifying multiple @option{-fplugin} arguments.
 
 A plugin can be simply given by its short name (no dots or
-slashes). When simply passing @option{-fplugin=@var{name}}, the plugin is
-loaded from the @file{plugin} directory, so @option{-fplugin=@var{name}} is
-the same as @option{-fplugin=`gcc -print-file-name=plugin`/@var{name}.so},
-using backquote shell syntax to query the @file{plugin} directory.
+slashes). When simply passing @option{-fplugin=@var{name}}, the plugin
+is loaded from the @file{plugin} directory, or one of its front-end
+specific subdirectories, so @option{-fplugin=@var{name}} is the same
+as @option{-fplugin=`gcc
+-print-file-name=plugin`/@var{program}/@var{name}.so} or
+@option{-fplugin=`gcc -print-file-name=plugin`/@var{name}.so}, using
+backquote shell syntax to query the @file{plugin} directory, where
+@var{program} is one of @code{cc1}, @code{cc1plus}, @code{lto1} etc.
+Therefore, a plugin can be made available only to some front-ends,
+or can have language-specific variants.
 
 @section Plugin API
 
@@ -207,10 +213,11 @@ For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PL
 and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
 null, and the @code{user_data} is specific.
 
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the PLUGIN_PRAGMAS event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas using functions
+like @code{c_register_pragma} or
+@code{c_register_pragma_with_expansion}. This is not possible in
+plugins run from @code{lto1}.
 
 @section Interacting with the pass manager
 
Index: gcc/plugin.c
===
--- gcc/plugin.c	(revision 175201)
+++ gcc/plugin.c	(working copy)
@@ -1,5 +1,5 @@
 /* Support for GCC plugin mechanism.
-   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
+   Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -117,6 +117,12 @@ get_plugin_base_name (const char *full_name)
 }
 
 
+/* FIXME: the ".so" suffix is currently builtin, since plugins
+   only work on ELF host systems like e.g. Linux or Solaris.  
+   When plugins shall be available on non ELF systems such as
+   Windows or MacOS, this code has to be greatly improved.  */
+#define PLUGIN_FILE_SUFFIX ".so"
+
 /* Create a plugin_name_args object for the given plugin and insert it
to the hash table. This function is called when
-fplugin=/path/to/NAME.so or -fplugin=NAME option is processed.  */
@@ -140,17 +146,43 @@ add_new_plugin (const char* plugin_name)
 
   if (name_is_short)
 {
+  char *plugpath;
+  char* foundpath = NULL;
   base_name = CONST_CAST (char*, plugin_name);
-  /* FIXME: the ".so" suffix is currently builtin, since plugins
-	 only work on ELF host systems like e.g. Linux or Solaris.
-	 When plugins shall be available on non ELF systems such as
-	 Windows or MacOS, this code has to be greatly improved.  */
-  plugin_name = concat (default_plugin_dir_name (), "/",
-			plugin_name, ".so", NULL);
-  if (access (plugin_name, R_OK))
-	fatal_error
-	  ("inacessible plugin file %s expanded from short plugin name %s: %m",
-	   plugin_name, base_name);
+
+  /* Look for PLUGINDIR/PROGNAME/NAME.so.  This is useful for
+	 front-end specific plugins.  */
+  if (!foundpath)
+	plugpath = concat (default_plugin_dir_name (), "/",
+			   progname, "/",
+			   plugin_name, PLUGIN_FILE_SUFFIX, NULL);
+  if (!access (

Re: Remove TARGET_HELP hook

[Joseph S. Myers]

On Mon, 20 Jun 2011, Georg-Johann Lay wrote:

> > Index: gcc/config/avr/avr-tables.opt
> > ===
> > --- gcc/config/avr/avr-tables.opt   (revision 0)
> > +++ gcc/config/avr/avr-tables.opt   (revision 0)
> 
> As it's auto-generated: must it reside in repository?

The machinery for selecting .opt files to use and for using them (both in 
the compiler and in .pot generation) expects them all to be in the source 
directory.

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

Re: [Patch, Fortran] (coarray) Add LOCK_TYPE

[Paul Richard Thomas]

Dear Tobias,

I have checked out the code for any obvious style or other minor
errors and all looks well.  However, I had a look at 8.5.6 "LOCK and
UNLOCK statements" in the standard and can only confess to feeling
very stupid tonight because I could not make head nor tail of the
example.  Thus, I can offer no judgement on the functionality of your
patch.

In light of this and the rather thorough protection of the core F95
compiler from co-arrays, I would just go ahead and commit the patch,
if I were you.

OK for trunk

Paul

PS Please give me a co-array tutorial sometime!

On Mon, Jun 20, 2011 at 4:45 PM, Tobias Burnus  wrote:
> *PING*
>
> On 06/16/2011 08:27 AM, Tobias Burnus wrote:
>>
>> This patch adds ISO_Fortran_Env's LOCK_TYPE, tons of constraint checks and
>> a simple implementation for -fcoarray=single.
>>
>> With the implementation of LOCK_TYPE and (UN)LOCK, gfortran can now parse
>> all coarrays constructs of Fortran 2008. (However, there are still known
>> deficits and bugs in the resolving/code-producing stage; for instance,
>> allocatable scalar coarrays are not yet implemented.)
>>
>> Build and regtested on x86-64-linux.
>> OK for the trunk?
>>
>> Tobias
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Backport patches that are either bug fixes or make reasonably significant performance impact for latest AMD/Intel hardware

[harsha.jagasia]

Is it ok to backport patches, with Changelogs below, already in trunk to gcc
4.6? These patches are significant enough bugs fror recent AMD and Intel
hardware. If ok and unless the individual authors want to backport, I will
post backported patches for commit approval.

[PATCH] Handle misaligned TFmode load/store.
gcc/
2011-05-30  H.J. Lu  
PR target/49168
* config/i386/i386.md (*movtf_internal): Handle misaligned
load/store.
gcc/testsuite/
2011-05-30  H.J. Lu  
PR target/49168
 * gcc.target/i386/pr49168-1.c: New.

[PATCH] Fix FMA cost computation
2011-05-31  Alexandre Oliva  
* config/i386/i386.c (ix86_rtx_costs): Drop NEG from sub for FMA.
* config/i386/sse.md: Add n to negated FMA pattern names.

Re: [PATCH][RFC][1/2] Bitfield lowering, add BIT_FIELD_EXPR

[Andrew Pinski]

On Mon, Jun 20, 2011 at 7:19 AM, William J. Schmidt
 wrote:
> On Thu, 2011-06-16 at 09:49 -0700, Richard Henderson wrote:
>> On 06/16/2011 04:35 AM, Richard Guenther wrote:
>> >
>> > +     /* Bit-field insertion needs several shift and mask operations.  */
>> > +     case BIT_FIELD_EXPR:
>> > +       return 3;
>>
>> ... depending on the target, of course.
>>
>
> Agreed -- this is a single-instruction operation on PowerPC.  Probably
> need some target-specific weights here.

It is also a single instruction on MIPS32R2 and MIPS64R2.  So a target
hook is the best here rather than a constant number in the target hook
field.

Thanks,
Andrew Pinski

Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on bdver1 and generic

[Uros Bizjak]

On Mon, Jun 20, 2011 at 8:03 PM, Fang, Changpeng  wrote:

>  I modified the patch as H.J. suggested (patch attached).
>
> Is it OK to commit to trunk now?

Yes, this is OK for trunk.

Thanks,
Uros.

RE: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on bdver1 and generic

[Fang, Changpeng]

Hi,

  I modified the patch as H.J. suggested (patch attached).

Is it OK to commit to trunk now?

Thanks,

Changpeng



From: H.J. Lu [hjl.to...@gmail.com]
Sent: Friday, June 17, 2011 5:44 PM
To: Fang, Changpeng
Cc: Richard Guenther; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on 
bdver1 and generic

On Fri, Jun 17, 2011 at 3:18 PM, Fang, Changpeng  wrote:
> Hi,
>
>  I added AVX256_SPLIT_UNALIGNED_STORE to ix86_tune_indices
> and put m_COREI7, m_BDVER1 and m_GENERIC as the targets that
> enable it.
>
> Is this OK?

Can you do something similar to how MASK_ACCUMULATE_OUTGOING_ARGS
is handled?

Thanks.

H.J.

From 50310fc367348b406fc88d54c3ab54d1a304ad52 Mon Sep 17 00:00:00 2001
From: Changpeng Fang 
Date: Mon, 13 Jun 2011 13:13:32 -0700
Subject: [PATCH 2/2] pr49089: enable avx256 splitting unaligned load/store only when beneficial

	* config/i386/i386.c (avx256_split_unaligned_load): New definition.
	  (avx256_split_unaligned_store): New definition.
	  (ix86_option_override_internal): Enable avx256 unaligned load(store)
	  splitting only when avx256_split_unaligned_load(store) is set.
---
 gcc/config/i386/i386.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 7b266b9..3bc0b53 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2121,6 +2121,12 @@ static const unsigned int x86_arch_always_fancy_math_387
   = m_PENT | m_ATOM | m_PPRO | m_AMD_MULTIPLE | m_PENT4
 | m_NOCONA | m_CORE2I7 | m_GENERIC;
 
+static const unsigned int x86_avx256_split_unaligned_load
+  = m_COREI7 | m_GENERIC;
+
+static const unsigned int x86_avx256_split_unaligned_store
+  = m_COREI7 | m_BDVER1 | m_GENERIC;
+
 /* In case the average insn count for single function invocation is
lower than this constant, emit fast (but longer) prologue and
epilogue code.  */
@@ -4194,9 +4200,11 @@ ix86_option_override_internal (bool main_args_p)
 	  if (flag_expensive_optimizations
 	  && !(target_flags_explicit & MASK_VZEROUPPER))
 	target_flags |= MASK_VZEROUPPER;
-	  if (!(target_flags_explicit & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
+	  if ((x86_avx256_split_unaligned_load & ix86_tune_mask)
+	  && !(target_flags_explicit & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
 	target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;
-	  if (!(target_flags_explicit & MASK_AVX256_SPLIT_UNALIGNED_STORE))
+	  if ((x86_avx256_split_unaligned_store & ix86_tune_mask)
+	  && !(target_flags_explicit & MASK_AVX256_SPLIT_UNALIGNED_STORE))
 	target_flags |= MASK_AVX256_SPLIT_UNALIGNED_STORE;
 	}
 }
-- 
1.7.0.4

[Patch, AVR]: Fix PR33049 (implement extzv)

[Georg-Johann Lay]

This is an optimization patch that implements extzv for 1-bit extracts.

The nice thing is that AVR can do this easily with a BLD/CLR/BST
sequence, without putting pressure on d-regs and without the
requirement of source being in the same register as destination.

extzv can also be seen in conjunction with zero_extend which, without
this patch, will lead to a 16-bit loop just to get one bit from a
position with a known offset.  So there are two splits to split the
high-part away.

Tested without regression.

Johann

PR target/33049
* config/avr/avr.md (extzv): New expander.
(*extzv, *extzv.qihi1, *extzv.qihi2): New insn-and-split.
Index: config/avr/avr.md
===
--- config/avr/avr.md	(revision 175201)
+++ config/avr/avr.md	(working copy)
@@ -3540,3 +3540,75 @@ (define_insn_and_split "*iorqi.byt
 int byteno = INTVAL(operands[2]) / BITS_PER_UNIT;
 operands[4] = simplify_gen_subreg (QImode, operands[0], mode, byteno);
   })
+
+(define_expand "extzv"
+  [(set (match_operand:QI 0 "register_operand" "")
+(zero_extract:QI (match_operand:QI 1 "register_operand"  "")
+ (match_operand:QI 2 "const1_operand" "")
+ (match_operand:QI 3 "const_0_to_7_operand" "")))]
+  ""
+  "")
+
+(define_insn_and_split "*extzv"
+  [(set (match_operand:QI 0 "register_operand"   "=*d,*d,*d,r")
+(zero_extract:QI (match_operand:QI 1 "register_operand" "0,r,0,r")
+ (const_int 1)
+ (match_operand:QI 2 "const_0_to_7_operand" "L,L,P,n")))]
+  ""
+  "@
+	andi %0,1
+	mov %0,%1\;andi %0,1
+	lsr %0\;andi %0,1
+	bst %1,%2\;clr %0\;bld %0,0"
+  "reload_completed
+   && INTVAL (operands[2]) == 4
+   && REGNO (operands[0]) == REGNO (operands[1])
+   && REGNO (operands[0]) >= 16"
+  [(set (match_dup 0)
+(rotate:QI (match_dup 0)
+   (const_int 4)))
+   (set (match_dup 0)
+(and:QI (match_dup 0)
+(const_int 1)))]
+  ""
+  [(set_attr "length" "1,2,2,3")
+   (set_attr "cc" "set_zn,set_zn,set_zn,clobber")])
+
+(define_insn_and_split "*extzv.qihi1"
+  [(set (match_operand:HI 0 "register_operand"   "=*d,*d,*d,r")
+(zero_extract:HI (match_operand:QI 1 "register_operand" "0,r,0,r")
+ (const_int 1)
+ (match_operand:QI 2 "const_0_to_7_operand" "L,L,P,n")))]
+  ""
+  "#"
+  ""
+  [(set (match_dup 3)
+(zero_extract:QI (match_dup 1)
+ (const_int 1)
+ (match_dup 2)))
+   (set (match_dup 4)
+(const_int 0))]
+  {
+operands[3] = simplify_gen_subreg (QImode, operands[0], HImode, 0);
+operands[4] = simplify_gen_subreg (QImode, operands[0], HImode, 1);
+  })
+
+(define_insn_and_split "*extzv.qihi2"
+  [(set (match_operand:HI 0 "register_operand""=*d,*d,*d,r")
+(zero_extend:HI 
+ (zero_extract:QI (match_operand:QI 1 "register_operand" "0,r,0,r")
+  (const_int 1)
+  (match_operand:QI 2 "const_0_to_7_operand" "L,L,P,n"]
+  ""
+  "#"
+  ""
+  [(set (match_dup 3)
+(zero_extract:QI (match_dup 1)
+ (const_int 1)
+ (match_dup 2)))
+   (set (match_dup 4)
+(const_int 0))]
+  {
+operands[3] = simplify_gen_subreg (QImode, operands[0], HImode, 0);
+operands[4] = simplify_gen_subreg (QImode, operands[0], HImode, 1);
+  })

Re: Remove TARGET_HELP hook

[Georg-Johann Lay]

Joseph S. Myers schrieb:
> When moving hooks used in opts.c to the common hooks structure so they
> can be called from the driver, I did not move the TARGET_HELP hook
> because this hook is obsoleted by the generic Enum .opt facility (only
> being used to print list of enumerated arguments to options).
> Instead, this patch converts the one remaining target with a
> TARGET_HELP implementation, AVR, to use Enum for the relevant option
> (with a .def file in the same style as various other targets), and
> removes and poisons the hook.
> 
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu, and
> tested building cc1 and xgcc for cross to avr-elf.  Will common to
> trunk in the absence of target maintainer objections.
> 
[...]
> Index: gcc/config/avr/avr-tables.opt
> ===
> --- gcc/config/avr/avr-tables.opt (revision 0)
> +++ gcc/config/avr/avr-tables.opt (revision 0)

As it's auto-generated: must it reside in repository?

Johann

Re: [patch fold-const.c]: Add some missing optimizations about binary and and truth-not

[Mike Stump]

On Jun 20, 2011, at 8:38 AM, Jeff Law wrote:
>> "do not need" != "cannot"
>> 
>>> This has been discussed several times.  So no, this noise isn't at all
>>> useful nor welcome.
>> 
>> useful or welcome TO YOU.  Obviously, it's useful to us.
> Umm, it's neither welcome nor useful to many folks -- that's why the
> guidelines are there.
> 
> They do not belong on gcc-patches.

Agreed.  svn log will tell you if a patch was committed and it is very 
reliable, unlike email.

Simplify Solaris configuration

[Rainer Orth]

I had long meant to do another round of cleanups of the Solaris
configuration, which has much duplication and inconsistencies between
the SPARC and x86 versions.

The following patch is the result of this work.  It consists of several
parts:

* Move the common Solaris parts in config.gcc to the *-*-solaris2* case.

* Since the Solaris/SPARC port is pure bi-arch by now, there's no point
  to have separate sparc/sol2.h and sparc/sol2-bi.h (and similar gas and
  gld) headers where the latter sometimes just override definitions in
  the former.

* We already use USE_GAS to conditionally define GNU as or Sun
  as-specific stuff.  I'm introducing usegld.h and USE_GLD for the same
  purpose, replacing the Solaris/x86-only TARGET_GNU_LD.  I'm merging
  all the sol2-gas*.h and sol2-gld*.h headers into the base headers
  since it is far easier to see what's going on if the variants are
  close.

* I do introduce a new config/sol2-bi.h since while the SPARC port is
  bi-arch only, the x86 port only is since Solaris 10.  Many of the
  previous SPARC-only definitions are really generic or can easily be
  made so, so this removes duplication between the two and paves the way
  for an eventual 64-bit-default Solaris/x86 configuration.

* The ordering of definitions in the headers often seemed pretty
  random.  I've reordered them to appear a little more logical.
  Unfortunately, this makes the patch harder to read; it's easier to see
  what's going on in the patched files.

* I've completely removed the -compat-bsd support.  /usr/ucblib is gone
  in Solaris 11, and has only been a migration aid in the early Solaris
  2.0 days, with all coding guidelines warning against its use.

* config/sol2.h defined PREFERRED_DEBUGGING_TYPE DBX_DEBUG, only to have
  it overridden by tm-dwarf2.h in config.gcc.  This is completely
  pointless, so I'm removing both the sol2.h definition and the
  tm-dwarf2.h include since DWARF2_DEBUG is the elfos.h default already.

* I'm removing -rpath-link /usr/lib resp. /usr/lib/sparcv9 from
  LINK_ARCH{32,64}_SPEC.  All other ports have already removed it, it's
  the default and the Solaris/x86 port has worked fine without.

There are a couple of open questions and FIXMEs right now:

* In config/sol2-bi.h, LINK_ARCH64_SPEC contains

  "%{mcmodel=medlow:-M /usr/lib/ld/" ARCH64_SUBDIR "/map.below4G} "

  Except for the name of the code models, there's nothing SPARC-specific
  here.  I think at least -mcmodel=small on x86 needs the same linker
  map, maybe even -mcmodel=medium.

* CPP_SUBTARGET_SPEC still has -D_PTHREADS.  This is unused in the tree;
  only libstdc++-v3/acinclude.m4 defines it for all targets.  I suppose
  this can go?

* One might want to simplify the different ASM_SPECs.  I may do this
  before checkin or as a followup.

Bootstrapped without regressions on i386-pc-solaris2.11 (Sun as/ld, GNU
as/Sun ld, GNU as, ld), i386-pc-solaris2.10 (Sun as/ld), and
sparc-sun-solaris2.11 (Sun as/ld) so far.  Bootstraps on
i386-pc-solaris2.[89], sparc-sun-solaris2.8, sparc-sun-solaris2.10 and
the remaining tool combinations are still running.

Will commit unless Eric sees problems or the bootstraps reveal
regressions.

Rainer


2011-06-19  Rainer Orth  

gcc:
* config/usegld.h: New file.
* config/sol2.h (PREFERRED_DEBUGGING_TYPE): Remove.
(CPP_SUBTARGET_SPEC): Remove -compat-bsd support.
(LIB_SPEC): Likewise.
Search /lib.
(LINK_ARCH32_SPEC_BASE): Remove -compat-bsd support.
(RDYNAMIC_SPEC): Handle GNU ld.
[HAVE_LD_EH_FRAME_HDR && TARGET_DL_ITERATE_PHDR] (LINK_EH_SPEC): Define.
(SUPPORTS_INIT_PRIORITY): Only disable for Sun ld.
(SUBTARGET_INSERT_ATTRIBUTES, SUBTARGET_ATTRIBUTE_TABLE): Define.
[!USE_GAS] (NO_DBX_BNSYM_ENSYM): Redefine.
(STACK_CHECK_STATIC_BUILTIN): Define.

* config/sol2.opt (compat-bsd): Remove.
* config/sol2-10.h (TARGET_C99_FUNCTIONS): Remove undef.
* config/sol2-bi.h: New file.
* config/sol2-gld.h: Remove.
* config/i386/sol2.h (TLS_COMMON_ASM_OP): Only define if !USE_GAS.
(NO_DBX_BNSYM_ENSYM): Remove.
(SUBTARGET_INSERT_ATTRIBUTES, SUBTARGET_ATTRIBUTE_TABLE): Remove.
(STACK_CHECK_STATIC_BUILTIN): Remove.
Test USE_GLD instead of TARGET_GNU_LD.
* config/i386/sol2-10.h: Rename to ...
* config/i386/sol2-bi.h .. this.
(SUBTARGET_EXTRA_SPECS): Redefine.
(WCHAR_TYPE, WCHAR_TYPE_SIZE, WINT_TYPE, WINT_TYPE_SIZE): Remove.
(MULTILIB_DEFAULTS): Remove.
(DEFAULT_ARCH32_P): Define.
(LINK_ARCH64_SPEC_BASE, LINK_ARCH64_SPEC): Remove.
(ARCH64_SUBDIR): Define.
Test USE_GLD instead of TARGET_GNU_LD.
(I386_EMULATION): Rename to ...
(ARCH32_EMULATION): ... this.
(X86_64_EMULATION): Rename to ...
(ARCH64_EMULATION): ... this.
(TARGET_LD_EMULATION): Remove.
(LINK_ARCH_SPEC): Remove.
* config/i386/

[x32] PATCH: Also allow x32 for gcc.dg/pr44194-1.c

[H.J. Lu]

Hi,

I checked this patch into x32 branch.

H.J.
---
commit f68fa52c0474cbacd8c2e0cf41d2f472baebdf7c
Author: H.J. Lu 
Date:   Wed Jun 15 11:26:28 2011 -0700

Also allow x32 for gcc.dg/pr44194-1.c.

diff --git a/gcc/testsuite/ChangeLog.x32 b/gcc/testsuite/ChangeLog.x32
index 43af9dd..ab8dd76 100644
--- a/gcc/testsuite/ChangeLog.x32
+++ b/gcc/testsuite/ChangeLog.x32
@@ -1,3 +1,7 @@
+2011-06-15  H.J. Lu  
+
+   * gcc.dg/pr44194-1.c: Also allow x32.
+
 2011-05-30  H.J. Lu  
 
* gcc.target/i386/pr49095.c: Require ia32 instead of ilp32.
diff --git a/gcc/testsuite/gcc.dg/pr44194-1.c b/gcc/testsuite/gcc.dg/pr44194-1.c
index 4804d83..e9f8bf1 100644
--- a/gcc/testsuite/gcc.dg/pr44194-1.c
+++ b/gcc/testsuite/gcc.dg/pr44194-1.c
@@ -1,6 +1,5 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { x32 || lp64 } } } */
 /* { dg-options "-O2 -fdump-rtl-dse1" } */
-/* { dg-require-effective-target lp64 } */
 /* Restricting to 64-bit targets since 32-bit targets return
structures in memory.  */
 

Re: [PATCH 0/4] Docs: extend.texi

[Michael Witten]

On Thu, Apr 28, 2011 at 01:20, Michael Witten  wrote:

> See the following emails for a few inlined patches
> to /trunk/gcc/doc/extend.texi (revision 172911):
>
>  [1] Docs: extend.texi: Add missing semicolon for consistency
>  [2] Docs: extend.texi: Remove trailing blanks from lines
>  [3] Docs: extend.texi: Rearrange nodes; no text was removed or added
>  [4] Docs: extend.texi: Reword and rearrange attribute node introductions
>
>  trunk/gcc/doc/extend.texi | 5449 
> +++--
>  1 files changed, 2730 insertions(+), 2719 deletions(-)
>
> CHANGELOG
>
> Essentially, I think it would be easiest to squash all of these patches
> together into one revision; here is a ChangeLog entry for such a revision:
>
> 2011-04-27  Michael Witten 
>
>* gcc/doc/extend.texi: Add a `;', remove trailing whitespace,
>and reorganize nodes to group the discussion of attributes more
>logically.
>
> --
> 1.7.4.18.g68fe8

Please commit these patches, starting here:

 http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html
 Message-ID: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com

Sincerely,
Michael Witten

RE: Backport AVX256 load/store split patches to gcc 4.6 for performance boost on latest AMD/Intel hardware.

[Jagasia, Harsha]

> On Mon, Jun 20, 2011 at 9:58 AM,   wrote:
> > Is it ok to backport patches, with Changelogs below, already in trunk
> to gcc
> > 4.6? These patches are for AVX-256bit load store splitting. These
> patches
> > make significant performance difference >=3% to several CPU2006 and
> > Polyhedron benchmarks on latest AMD and Intel hardware. If ok, I will
> post
> > backported patches for commit approval.
> >
> > AMD plans to submit additional patches on AVX-256 load/store
> splitting to
> > trunk. We will send additional backport requests for those later once
> they
> > are accepted/comitted to trunk.
> >
> 
> Since we will make some changes on trunk, I would prefer to to do
> the backport after trunk change is finished.

Ok, thanks. Adding Changpeng who is working on the trunk changes.

Harsha

Re: [PATCH] Fix ICEs with out of range immediates in SSE*/AVX*/XOP* intrinsics (PR target/49411)

[Kirill Yukhin]

Folks,
I think that implementation of the patch is not as good. It introduces
working with specific instructions in ix86_expand_multi_arg_builtin(),
however before it was really generic.
It operated only on abstract insns, only number/type of arguments was
matter. But now there’re INSN_CODE switches, gotos …

Thanks, Kirill

On Fri, Jun 17, 2011 at 5:01 PM, Jakub Jelinek  wrote:
> On Fri, Jun 17, 2011 at 01:31:14AM +0200, Jakub Jelinek wrote:
>> Not here, those are handled by  ix86_expand_args_builtin
>> instead of ix86_expand_multi_arg_builtin.  Furthermore, only
>> CODE_FOR_vcvtps2ph and CODE_FOR_vcvtps2ph256 have CONST_INT argument.
>> And I believe ix86_expand_args_builtin handles it fine, what's wrong
>> is the actual predicates those insns use.
>
> Ok, had a deeper look into this and it seems there are other issues,
> some of them even without test coverage regressed since 4.6.
> Some problems result in ICEs, other fail to assemble.  Had to revert
> the blendbits removal patch, because that removal results in out of
> range immediates not to be reported as predicate failures, but instead
> as ICEs.
>
> So here is an updated patch that adds test coverage.  Regtested
> on x86_64-linux {-m32,-m64}, ok for trunk (and backport for 4.6)?
>
> There are still a couple of things I'm unsure about (not tested
> by the testcases, compile fine):
> #include 
> __m128i i1, i2, i3, i4;
> __m128 a1, a2, a3, a4;
> __m128d d1, d2, d3, d4;
> __m256i l1, l2, l3, l4;
> __m256 b1, b2, b3, b4;
> __m256d e1, e2, e3, e4;
> __m64 m1, m2, m3, m4;
> int k1, k2, k3, k4;
> float f1, f2, f3, f4;
> void
> foo (void)
> {
>  /* 8 bit imm only?  This compiles fine, but one ends up with
>     number modulo 256 in the insn.  To make it error out
>     const_0_to_255_operand would need to be used.  */
>  e1 = _mm256_shuffle_pd (e2, e3, 256);
>  b1 = _mm256_shuffle_ps (b2, b3, 256);
>  i1 = _mm_shuffle_epi32 (i2, 256);
>  i1 = _mm_shufflehi_epi16 (i2, 256);
>  i1 = _mm_shufflelo_epi16 (i2, 256);
>  d1 = _mm_shuffle_pd (d2, d3, 256);
>  m1 = _mm_shuffle_pi16 (m2, 256);
>  a1 = _mm_shuffle_ps (a2, a3, 256);
>  /* What about these?  Similarly to the above, they result
>     in imm modulo 16 resp. imm modulo 4.  */
>  e1 = _mm256_permute_pd (e2, 16);
>  d1 = _mm_permute_pd (d2, 4);
> }
>
> 2011-06-17  Jakub Jelinek  
>
>        PR target/49411
>        * config/i386/i386.c (ix86_expand_multi_arg_builtins): If
>        last_arg_constant and last argument doesn't match its predicate,
>        for xop_vpermil23 error out and for xop_rotl3
>        if it is CONST_INT, mask it, otherwise expand using rotl3.
>        (ix86_expand_sse_pcmpestr, ix86_expand_sse_pcmpistr): Fix
>        spelling of error message.
>        * config/i386/sse.md (sse4a_extrqi, sse4a_insertqi,
>        vcvtps2ph, *vcvtps2ph, *vcvtps2ph_store, vcvtps2ph256): Use
>        const_0_to_255_operand instead of const_int_operand.
>
>        Revert:
>        2011-05-09  Uros Bizjak  
>
>        * config/i386/sse.md (blendbits): Remove mode attribute.
>        (_blend): Use const_int_operand
>        instead of const_0_to__operand for operand 3 predicate.
>        Check integer value of operand 3 in insn constraint.
>
>        * gcc.target/i386/testimm-1.c: New test.
>        * gcc.target/i386/testimm-2.c: New test.
>        * gcc.target/i386/testimm-3.c: New test.
>        * gcc.target/i386/testimm-4.c: New test.
>        * gcc.target/i386/testimm-5.c: New test.
>        * gcc.target/i386/testimm-6.c: New test.
>        * gcc.target/i386/testimm-7.c: New test.
>        * gcc.target/i386/testimm-8.c: New test.
>        * gcc.target/i386/xop-vpermil2px-2.c: New test.
>        * gcc.target/i386/xop-rotate1-int.c: New test.
>        * gcc.target/i386/xop-rotate2-int.c: New test.
>
> --- gcc/config/i386/i386.c.jj   2011-06-17 11:02:11.0 +0200
> +++ gcc/config/i386/i386.c      2011-06-17 13:35:26.0 +0200
> @@ -25566,16 +25566,61 @@ ix86_expand_multi_arg_builtin (enum insn
>       int adjust = (comparison_p) ? 1 : 0;
>       enum machine_mode mode = insn_data[icode].operand[i+adjust+1].mode;
>
> -      if (last_arg_constant && i == nargs-1)
> +      if (last_arg_constant && i == nargs - 1)
>        {
> -         if (!CONST_INT_P (op))
> +         if (!insn_data[icode].operand[i + 1].predicate (op, mode))
>            {
> -             error ("last argument must be an immediate");
> -             return gen_reg_rtx (tmode);
> +             enum insn_code new_icode = icode;
> +             switch (icode)
> +               {
> +               case CODE_FOR_xop_vpermil2v2df3:
> +               case CODE_FOR_xop_vpermil2v4sf3:
> +               case CODE_FOR_xop_vpermil2v4df3:
> +               case CODE_FOR_xop_vpermil2v8sf3:
> +                 error ("the last argument must be a 2-bit immediate");
> +                 return gen_reg_rtx (tmode);
> +               case CODE_FOR_xop_rotlv2di3:
> +                 new_icode = CODE_FOR_rotlv2di3;
> +                 goto xop_rotl;

Re: Backport AVX256 load/store split patches to gcc 4.6 for performance boost on latest AMD/Intel hardware.

[H.J. Lu]

On Mon, Jun 20, 2011 at 9:58 AM,   wrote:
> Is it ok to backport patches, with Changelogs below, already in trunk to gcc
> 4.6? These patches are for AVX-256bit load store splitting. These patches
> make significant performance difference >=3% to several CPU2006 and
> Polyhedron benchmarks on latest AMD and Intel hardware. If ok, I will post
> backported patches for commit approval.
>
> AMD plans to submit additional patches on AVX-256 load/store splitting to
> trunk. We will send additional backport requests for those later once they
> are accepted/comitted to trunk.
>

Since we will make some changes on trunk, I would prefer to to do
the backport after trunk change is finished.

Thanks.


-- 
H.J.

Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

[Joseph S. Myers]

On Mon, 20 Jun 2011, Hans-Peter Nilsson wrote:

> It seems none in approval capacity have any objection to
> (figuratively) s/target-libiberty//g in toplevel/configure.ac on
> all branches.  Is an --enable-target-libiberty or
> --with-target-libiberty needed?  (I'd just rather not.)

There should be no such option.  It should just be a matter of removing 
"target_modules = { module= libiberty; };" and everything that references 
target-libiberty.

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

Backport AVX256 load/store split patches to gcc 4.6 for performance boost on latest AMD/Intel hardware.

[harsha.jagasia]

Is it ok to backport patches, with Changelogs below, already in trunk to gcc
4.6? These patches are for AVX-256bit load store splitting. These patches
make significant performance difference >=3% to several CPU2006 and
Polyhedron benchmarks on latest AMD and Intel hardware. If ok, I will post
backported patches for commit approval.

AMD plans to submit additional patches on AVX-256 load/store splitting to
trunk. We will send additional backport requests for those later once they
are accepted/comitted to trunk.

[PATCH] Split 32-byte AVX unaligned load/store.
gcc/
2011-03-27  H.J. Lu  
* config/i386/i386.c (flag_opts): Add -mavx256-split-unaligned-load
and -mavx256-split-unaligned-store.
(ix86_option_override_internal): Split 32-byte AVX unaligned
load/store by default.
(ix86_avx256_split_vector_move_misalign): New.
(ix86_expand_vector_move_misalign): Use it.

* config/i386/i386.opt: Add -mavx256-split-unaligned-load and
-mavx256-split-unaligned-store.

* config/i386/sse.md (*avx_mov_internal): Verify unaligned
256bit load/store.  Generate unaligned store on misaligned memory
operand.
(*avx_movu): Verify unaligned
256bit load/store.
(*avx_movdqu): Likewise.

* doc/invoke.texi: Document -mavx256-split-unaligned-load and
-mavx256-split-unaligned-store.
gcc/testsuite/
2011-03-27  H.J. Lu  
* gcc.target/i386/avx256-unaligned-load-1.c: New.
* gcc.target/i386/avx256-unaligned-load-2.c: Likewise.
* gcc.target/i386/avx256-unaligned-load-3.c: Likewise.
* gcc.target/i386/avx256-unaligned-load-4.c: Likewise.
* gcc.target/i386/avx256-unaligned-load-5.c: Likewise.
* gcc.target/i386/avx256-unaligned-load-6.c: Likewise.
* gcc.target/i386/avx256-unaligned-load-7.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-1.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-2.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-3.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-4.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-5.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-6.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-7.c: Likewise.

[PATCH] Don't assert unaligned 256bit load/store.
2011-03-27  H.J. Lu  
* config/i386/sse.md (*avx_mov_internal): Don't assert
unaligned 256bit load/store.
(*avx_movu): Likewise.
(*avx_movdqu): Likewise.

[PATCH] Fix a typo in -mavx256-split-unaligned-store.
2011-03-28  H.J. Lu  
* config/i386/i386.c (flag_opts): Fix a typo in
-mavx256-split-unaligned-store.

[PATCH] * config/i386/i386.c (ix86_reorg): Run move_or_delete_vzeroupper first.
2011-05-04  Uros Bizjak  
* config/i386/i386.c (ix86_reorg): Run move_or_delete_vzeroupper first.

[PATCH] Save the initial options after checking vzeroupper.
gcc/
2011-05-23  H.J. Lu  
PR target/47315
* config/i386/i386.c (ix86_option_override_internal): Save the
initial options after checking vzeroupper.
gcc/testsuite/
2011-05-23  H.J. Lu  
PR target/47315
* gcc.target/i386/pr47315.c: New test.

RE: Remove TARGET_HELP hook

[Joseph S. Myers]

On Mon, 20 Jun 2011, Weddington, Eric wrote:

> I assume that this new method still prints out the avr mcu list in a 
> similar fashion?

Yes.  Any enumerated options get such lists printed as long as there is a 
help text on the Enum entry in the .opt file.

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

Re: Remove TARGET_HELP hook

[Denis Chertykov]

2011/6/20 Weddington, Eric :
>
>
>> -Original Message-
>> From: Joseph Myers [mailto:jos...@codesourcery.com]
>> Sent: Monday, June 20, 2011 9:47 AM
>> To: gcc-patches@gcc.gnu.org
>> Cc: cherty...@gmail.com; ae...@post.ru; Weddington, Eric
>> Subject: Remove TARGET_HELP hook
>>
>> When moving hooks used in opts.c to the common hooks structure so they
>> can be called from the driver, I did not move the TARGET_HELP hook
>> because this hook is obsoleted by the generic Enum .opt facility (only
>> being used to print list of enumerated arguments to options).
>> Instead, this patch converts the one remaining target with a
>> TARGET_HELP implementation, AVR, to use Enum for the relevant option
>> (with a .def file in the same style as various other targets), and
>> removes and poisons the hook.
>>
>> Bootstrapped with no regressions on x86_64-unknown-linux-gnu, and
>> tested building cc1 and xgcc for cross to avr-elf.  Will common to
>> trunk in the absence of target maintainer objections.
>
> I assume that this new method still prints out the avr mcu list in a similar 
> fashion?
>
> I have no overwhelming objections. Though I'd rather wait a little to see if 
> either Denis or Anatoly have any objections.
>
> Thanks for doing this work, Joseph.

I can not object to this patch.

Denis.

Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

[Hans-Peter Nilsson]

On Wed, 18 May 2011, Joseph S. Myers wrote:
> On Wed, 18 May 2011, DJ Delorie wrote:
>
> > At this point, though, I'm tempted to say "there's no such thing as a
> > target libiberty" and rip all the target-libiberty rules out, and let
>
> Yes please.  I've been arguing for that for some time.
>
> http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html
> http://gcc.gnu.org/ml/gcc/2010-03/msg2.html
> http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01231.html
> http://gcc.gnu.org/ml/gcc-bugs/2011-03/msg00206.html
> http://gcc.gnu.org/ml/gcc/2011-03/msg00465.html
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02304.html

I thought you had the ball on this, but I don't see anything
happened since the above was written.  I could just add clauses
for my own targets, but I want this to happen, so I'll pick it
up if it's on the floor.

It seems none in approval capacity have any objection to
(figuratively) s/target-libiberty//g in toplevel/configure.ac on
all branches.  Is an --enable-target-libiberty or
--with-target-libiberty needed?  (I'd just rather not.)

What would be an approvable test procedure?
Is it enough to test it on native x86_64-linux and cris-axis-elf
(a newlib target) with old and new/breaking newlib?

At a glance this would partially fix PR47836, and completely fix
PR23656, PR47733, PR49247.

brgds, H-P

RE: Remove TARGET_HELP hook

[Weddington, Eric]

> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Monday, June 20, 2011 9:47 AM
> To: gcc-patches@gcc.gnu.org
> Cc: cherty...@gmail.com; ae...@post.ru; Weddington, Eric
> Subject: Remove TARGET_HELP hook
> 
> When moving hooks used in opts.c to the common hooks structure so they
> can be called from the driver, I did not move the TARGET_HELP hook
> because this hook is obsoleted by the generic Enum .opt facility (only
> being used to print list of enumerated arguments to options).
> Instead, this patch converts the one remaining target with a
> TARGET_HELP implementation, AVR, to use Enum for the relevant option
> (with a .def file in the same style as various other targets), and
> removes and poisons the hook.
> 
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu, and
> tested building cc1 and xgcc for cross to avr-elf.  Will common to
> trunk in the absence of target maintainer objections.

I assume that this new method still prints out the avr mcu list in a similar 
fashion?

I have no overwhelming objections. Though I'd rather wait a little to see if 
either Denis or Anatoly have any objections.

Thanks for doing this work, Joseph.

Eric

Re: [Patch, AVR]: QI builtins for parity, popcount, 1<< n

[Georg-Johann Lay]

Richard Henderson schrieb:
> On 06/20/2011 07:20 AM, Georg-Johann Lay wrote:
>> A libcall could be added in TARGET_INIT_LIBCALLS, so a new hook is not
>> needed.  All that's needed is that optabs tests for presence of such
>> an entry and prefers it over inline expansion (and prefers insn over
>> libcall).  It appears that + and - are assumed to be cheaps or inline
>> expansion is always cheap.
> 
> No, we assume that if the inline pattern is present and enabled, it
> is to be preferred over the libcall.  All you have to do to get 
> __adddi3 called is remove/disable the adddi3 pattern.

There is no adddi3 in avr backend to disable.

--

Johann

Re: __sync_swap* with acq/rel/full memory barrier semantics

[Andrew MacLeod]

On 06/17/2011 02:12 PM, Andrew MacLeod wrote:

--- machmode.h  (working copy)
*** extern enum machine_mode ptr_mode;
*** 275,278 
--- 275,291 
   /* Target-dependent machine mode initialization - in insn-modes.c.  */
   extern void init_adjust_machine_modes (void);

+ /* Memory model types for the __sync_mem* builtins.
+This must match the order in libstdc++-v3/include/bits/atomic_base.h.  */
+ enum memmodel
+ {
+   MEMMODEL_RELAXED = 0,
+   MEMMODEL_CONSUME = 1,
+   MEMMODEL_ACQUIRE = 2,
+   MEMMODEL_RELEASE = 3,
+   MEMMODEL_ACQ_REL = 4,
+   MEMMODEL_SEQ_CST = 5,
+   MEMMODEL_LAST = 6
+ };

This isn't a very machine mode sort of define.
I think coretypes.h is a better choice.


cool that seems to work fine.  As long as its somewhere common.


+ static rtx
+ expand_builtin_mem_exchange (enum machine_mode mode, tree exp, rtx target)

Some names include "sync" and some don't?


Well, I was going to blame Aldy :-)  but then I went to look at this, 
and thats the same way *all* the other __sync instructions seem to be.


ie:

builtins.c:expand_builtin_lock_test_and_set (enum machine_mode mode, 
tree exp,

builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_1:
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_2:
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_4:

whereas everything else is 'sync_lock_test_and_set'..

So i guess it falls to prior art... I assume Aldy just cut-and-pasted 
for his new routine and just changed the names in the same format.



+ 

The xchg instruction is a full barrier; no need for anything extra here.
Indeed, you needn't define UNSPECV_MEM_XCHG either.  This could be as
simple as


Ah, even better.  For some reason I thought I saw somewhere that it 
wasn't a full barrier.  Might have just been the documentation for 
lock_test_and_set.


Andrew

Re: SRA generates uninitialized var use

[Xinliang David Li]

It is used to indicate the fact the var decl needs to have a memory
home (addressable) -- is there another way to do this? this is to
avoid the following situation:

1) after SRA before update SSA, the IR looks like:

   MEM[ &SR_123] = ...

   other_var = SR_123;   < (x)


In this case, SR_123 is not of aggregate type, and it is not
addressable, update_ssa won't assign a VUSE for (x), leading to

2) final IR after SRA:

   MEM[..., &SR_123] = ..
   other_var = SR_123_yyy(D);


David

On Mon, Jun 20, 2011 at 4:13 AM, Richard Guenther
 wrote:
> On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li  
> wrote:
>> Compiling the test case in the patch with -O2 -m32 without the fix,
>> the program will abort. The problem is a var decl whose address is
>> taken is not marked as addressable leading to bad SSA update (missing
>> VUSE).  (the triaging used the the .after and .after_cleanup dump diff
>> and found the problem).
>>
>> the test is on going. Ok after testing?
>
> That doesn't make sense.  SRA shouldn't generate anything that has
> its address taken.  So, where do we take its address?
>
> Richard.
>
>> Thanks,
>>
>> David
>>
>

Remove TARGET_HELP hook

[Joseph S. Myers]

When moving hooks used in opts.c to the common hooks structure so they
can be called from the driver, I did not move the TARGET_HELP hook
because this hook is obsoleted by the generic Enum .opt facility (only
being used to print list of enumerated arguments to options).
Instead, this patch converts the one remaining target with a
TARGET_HELP implementation, AVR, to use Enum for the relevant option
(with a .def file in the same style as various other targets), and
removes and poisons the hook.

Bootstrapped with no regressions on x86_64-unknown-linux-gnu, and
tested building cc1 and xgcc for cross to avr-elf.  Will common to
trunk in the absence of target maintainer objections.

contrib:
2011-06-20  Joseph Myers  

* gcc_update (gcc/config/avr/avr-tables.opt): New dependencies.

gcc:
2011-06-20  Joseph Myers  

* config/avr/avr-mcus.def, config/avr/genopt.sh: New files.
* config/avr/avr-tables.opt: New file (generated).
* config.gcc (avr-*-*): Use avr/avr-tables.opt.
* config/avr/avr-devices.c (avr_mcu_types): Move contents to
avr-mcus.def.
* config/avr/avr.c (avr_help, TARGET_HELP): Remove.
(avr_option_override): Don't process -mmcu= argument here.  Set
avr_current_device using avr_mcu_index.
(avr_file_start): Use avr_current_device->name instead of
avr_mcu_name.
* config/avr/avr.opt (mmcu=): Use Enum.
* config/avr/t-avr (avr-devices.o): Update dependencies.
($(srcdir)/config/avr/avr-tables.opt): New.
* target.def (help): Remove.
* doc/tm.texi.in (TARGET_HELP): Remove.
* doc/tm.texi: Regenerate.
* opts.c: Don't include target.h.
(common_handle_option): Don't call targetm.help.
* system.h (TARGET_HELP): Poison.
* Makefile.in (opts.o): Update dependencies.

Index: contrib/gcc_update
===
--- contrib/gcc_update  (revision 175148)
+++ contrib/gcc_update  (working copy)
@@ -81,6 +81,7 @@ gcc/config.in: gcc/cstamp-h.in
 gcc/fixinc/fixincl.x: gcc/fixinc/fixincl.tpl gcc/fixinc/inclhack.def
 gcc/config/arm/arm-tune.md: gcc/config/arm/arm-cores.def 
gcc/config/arm/gentune.sh
 gcc/config/arm/arm-tables.opt: gcc/config/arm/arm-arches.def 
gcc/config/arm/arm-cores.def gcc/config/arm/arm-fpus.def 
gcc/config/arm/genopt.sh
+gcc/config/avr/avr-tables.opt: gcc/config/avr/avr-mcus.def 
gcc/config/avr/genopt.sh
 gcc/config/m68k/m68k-tables.opt: gcc/config/m68k/m68k-devices.def 
gcc/config/m68k/m68k-isas.def gcc/config/m68k/m68k-microarchs.def 
gcc/config/m68k/genopt.sh
 gcc/config/mips/mips-tables.opt: gcc/config/mips/mips-cpus.def 
gcc/config/mips/genopt.sh
 gcc/config/rs6000/rs6000-tables.opt: gcc/config/rs6000/rs6000-cpus.def 
gcc/config/rs6000/genopt.sh
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 175148)
+++ gcc/doc/tm.texi (working copy)
@@ -766,13 +766,6 @@ Set target-dependent initial values of f
 Set target-dependent default values for @option{--param} settings, using calls 
to @code{set_default_param_value}.
 @end deftypefn
 
-@deftypefn {Target Hook} void TARGET_HELP (void)
-This hook is called in response to the user invoking
-@option{--target-help} on the command line.  It gives the target a
-chance to display extra information on the target specific command
-line options found in its @file{.opt} file.
-@end deftypefn
-
 @defmac SWITCHABLE_TARGET
 Some targets need to switch between substantially different subtargets
 during compilation.  For example, the MIPS target has one subtarget for
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in  (revision 175148)
+++ gcc/doc/tm.texi.in  (working copy)
@@ -754,13 +754,6 @@ options are changed via @code{#pragma GC
 
 @hook TARGET_OPTION_DEFAULT_PARAMS
 
-@hook TARGET_HELP
-This hook is called in response to the user invoking
-@option{--target-help} on the command line.  It gives the target a
-chance to display extra information on the target specific command
-line options found in its @file{.opt} file.
-@end deftypefn
-
 @defmac SWITCHABLE_TARGET
 Some targets need to switch between substantially different subtargets
 during compilation.  For example, the MIPS target has one subtarget for
Index: gcc/target.def
===
--- gcc/target.def  (revision 175148)
+++ gcc/target.def  (working copy)
@@ -1021,13 +1021,6 @@ DEFHOOK
  void, (void),
  hook_void_void)
 
-/* Display extra, target specific information in response to a
-   --target-help switch.  */
-DEFHOOK
-(help,
- "",
- void, (void), NULL)
-
 DEFHOOK_UNDOC
 (eh_return_filter_mode,
  "Return machine mode for filter value.",
Index: gcc/opts.c
===
--- gcc/opts.c  (revision 175148)
+++ gcc/opts.c  (working copy)
@@ -34

Re: [patch fold-const.c]: Add some missing optimizations about binary and and truth-not

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/20/11 09:34, NightStrike wrote:
> On Mon, Jun 20, 2011 at 10:47 AM, Jakub Jelinek  wrote:
>> On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
>>> On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek  wrote:
 On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
> Applied at revision 175206 to trunk.

 There is no need to post such notices to gcc-patches, we have the gcc-cvs
 mailing list where this is automatically posted to.
 On gcc-patches it just adds unnecessary noise.
>>>
>>> Until there is some way to easily map an email on gcc-patches to an
>>> email on gcc-cvs, or a legitimate patch tracker instead of just
>>> mailing lists, then it is very useful "noise".  I've found at least a
>>> hundred dropped patches so far for our project alone.  You can always
>>> just delete the email instead of reading it.
>>
>> No, our guidelines say that such mails shouldn't be sent:
>>
>> http://gcc.gnu.org/svnwrite.html
>> "When you have checked in a patch exactly as it has been approved, you do
>> not need to tell that to people -- including the approver. People
>> interested in when a particular patch is committed can check SVN or the
>> gcc-cvs list."
> 
> "do not need" != "cannot"
> 
>>
>> This has been discussed several times.  So no, this noise isn't at all
>> useful nor welcome.
> 
> useful or welcome TO YOU.  Obviously, it's useful to us.
Umm, it's neither welcome nor useful to many folks -- that's why the
guidelines are there.

If you want commit acks, then extract them from the gcc-cvs list.  They
do not belong on gcc-patches.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN/2mHAAoJEBRtltQi2kC72HMH/AjsQQ4sZheMXP5rzRzrpWKG
o6PnRDpTpo2ImjnfpSCUZdKgqBax9vRFRnR2mcrEnjZipVM4vIlRkQj93QVFfXTX
3KLTDdQX1+/1F+SADqAZ8ifGJWrdyArwWiB4qEvHmlYNbu2OjeJDxgeyE7WOYP5F
R+wnQzJpsfwBcmi0o8+Wm8R9KtV6CEhgIyAES7A9LSLiFsc/YAVUlA7e2dPXDGOU
kozUrQIUhPcg1NL9AMBFyDNLEDAP7sfdrxfe5+FOoGCj0yMvRR6D4ghrrvH2nUm/
fwCGOSUwHVexTHFlg0ZZTTabyjomLNq+ofjz+7VWgss8Or2+Wy/HcVR6z9T80ag=
=POMm
-END PGP SIGNATURE-

Re: [build] Move unwinder to toplevel libgcc

[Rainer Orth]

[Dropping the target maintainers from the Cc: since this isn't relevant
to the patch at hand.]

"Joseph S. Myers"  writes:

> On Mon, 20 Jun 2011, Rainer Orth wrote:
>
>> Certainly: your wiki entry gives a good overview.  For the moment, I'll
>> probably concentrate on the build side of things, though.  I may attack
>> gthr* stuff and fp-bit.[ch] next, both of which I can at least partially
>> test on my targets.
>
> fp-bit.[ch] has the interesting issue of FLOAT_BIT_ORDER_MISMATCH and 
> FLOAT_WORD_ORDER_MISMATCH being defined by makefile rules when it ought to 
> be possible to deduce that information from macros predefined by the 
> compiler.  (See what I said in 
>  about the 
> meanings of those macros.)

Thanks for the pointer.  Those makefile rules are messy indeed, and what
prompted me to consider looking into this stuff: I just had a
mips-sgi-irix6.5 bootstrap break for me because the generated tp-bit.c
was corrupted, most likely because both multilibs created the file
quasi-simultaneously, mangling it in the process.

> dfp-bit.* and fixed-bit.* can probably move along with fp-bit.* (or 
> before, or after), and I don't think there are any complicated issues 
> around those files.

I'll have a look.  I may move them together if I have to touch many of
the same t-* files for that anyway.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [Patch, AVR]: QI builtins for parity, popcount, 1<< n

[Richard Henderson]

On 06/20/2011 07:20 AM, Georg-Johann Lay wrote:
> A libcall could be added in TARGET_INIT_LIBCALLS, so a new hook is not
> needed.  All that's needed is that optabs tests for presence of such
> an entry and prefers it over inline expansion (and prefers insn over
> libcall).  It appears that + and - are assumed to be cheaps or inline
> expansion is always cheap.

No, we assume that if the inline pattern is present and enabled, it
is to be preferred over the libcall.  All you have to do to get 
__adddi3 called is remove/disable the adddi3 pattern.


r~

Re: [patch fold-const.c]: Add some missing optimizations about binary and and truth-not

[NightStrike]

On Mon, Jun 20, 2011 at 10:47 AM, Jakub Jelinek  wrote:
> On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
>> On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek  wrote:
>> > On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
>> >> Applied at revision 175206 to trunk.
>> >
>> > There is no need to post such notices to gcc-patches, we have the gcc-cvs
>> > mailing list where this is automatically posted to.
>> > On gcc-patches it just adds unnecessary noise.
>>
>> Until there is some way to easily map an email on gcc-patches to an
>> email on gcc-cvs, or a legitimate patch tracker instead of just
>> mailing lists, then it is very useful "noise".  I've found at least a
>> hundred dropped patches so far for our project alone.  You can always
>> just delete the email instead of reading it.
>
> No, our guidelines say that such mails shouldn't be sent:
>
> http://gcc.gnu.org/svnwrite.html
> "When you have checked in a patch exactly as it has been approved, you do
> not need to tell that to people -- including the approver. People
> interested in when a particular patch is committed can check SVN or the
> gcc-cvs list."

"do not need" != "cannot"

>
> This has been discussed several times.  So no, this noise isn't at all
> useful nor welcome.

useful or welcome TO YOU.  Obviously, it's useful to us.

>        Jakub
>

Re: [build] Move unwinder to toplevel libgcc

[Joseph S. Myers]

On Mon, 20 Jun 2011, Rainer Orth wrote:

> Certainly: your wiki entry gives a good overview.  For the moment, I'll
> probably concentrate on the build side of things, though.  I may attack
> gthr* stuff and fp-bit.[ch] next, both of which I can at least partially
> test on my targets.

fp-bit.[ch] has the interesting issue of FLOAT_BIT_ORDER_MISMATCH and 
FLOAT_WORD_ORDER_MISMATCH being defined by makefile rules when it ought to 
be possible to deduce that information from macros predefined by the 
compiler.  (See what I said in 
 about the 
meanings of those macros.)

dfp-bit.* and fixed-bit.* can probably move along with fp-bit.* (or 
before, or after), and I don't think there are any complicated issues 
around those files.

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

Re: Improve DSE in the presence of calls

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/18/11 03:10, Ramana Radhakrishnan wrote:
> This seems to have triggered
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
> 
> on arm-linux-gnueabi
> 
> Might well be a DUP of PR49429 but I haven't looked at it yet.
It is effectively a duplicate; with the notable difference that instead
of an explicit memcpy call, the memcpy appears in the RTL


> > (insn 38 37 39 2 (set (mem:BLK (scratch) [0 A8])
> (unspec:BLK [
> (reg/f:SI 13 sp)
> (reg/f:SI 11 fp)
> ] UNSPEC_PRLG_STK))
> /home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
> -1
>  (nil))


Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN/2XQAAoJEBRtltQi2kC7c0wIALgHpwr8NavWMAgKU6DPQlIe
HrSgYgE3wQxSYq0OGsYOyhIxEqIezkuyW4NeeicqN1QX/f62CKrAn8zocVJqbzm1
afhNu9hQeKAlzQNkCVx1pQ9tfcKQrSBZ+iZkqZ/94PmqcZp9iP3sB14+QIieZ5yO
cUx1JY2vj0mkWqhG2YBydWmLgS1EEN/lS1nGoD1ET+EWZSQxVDYRSxiE/u0xXD9p
QHExtYd9CR/qu99f2Xe+j4pSzZvIOk6T9Xn7iPfoBhp3zF9Djet2df38gPMJCtRW
oSOcrTAakEVWsm942Nc9WF3+86gqMYry+VQjAdEwik4MmydAwsSFSGnxHDNtXe8=
=66C9
-END PGP SIGNATURE-

Re: [x32] PATCH: Remove ix86_promote_function_mode

[H. Peter Anvin]

On 06/20/2011 07:43 AM, H.J. Lu wrote:
> On Mon, Jun 20, 2011 at 7:33 AM, H. Peter Anvin  wrote:
>> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt  
>>> wrote:
 On 06/20/2011 03:51 PM, H.J. Lu wrote:
> Promote pointers to Pmode when passing/returning in registers is
> a security concern.
>>
>> No.  Promoting *NON*-pointers (or rather, requiring non-pointers to
>> having already been zero extended) is a security concern.  I thought I'd
>> made that point clear already.  This is a hideously critical distinction.
> 
> I can promote pointers then.
> 

Yes.  The issue comes when promoting non-pointers, like "unsigned int".
 Pointers are the opposite because pointers in the kernel are 64 bits
and we'd like them to be pre-promoted.

>>> Peter, do you think it is safe to assume upper 32bits are zero in
>>> user space for x32? Kernel isn't a problem since pointer is 64bit
>>> in kernel and we don't pass pointers on stack to kernel.
>>
>> As I have already stated, if we *cannot* require pointers to be
>> zero-extended on entry to the kernel, we're going to have to have
>> special entry points for all the x32 system calls except the ones that
>> don't take pointers.
> 
> 32bit pointers are zero-extended to 64bit when passing in registers to
> kernel.

Excellent, sounds like we have converged.

I saw you posted something about pointers on the stack, but it sounds
like you already realized that we don't point any stack arguments
whatsoever to the kernel.

-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [build] Move unwinder to toplevel libgcc

[Rainer Orth]

"Joseph S. Myers"  writes:

> On Mon, 20 Jun 2011, Rainer Orth wrote:
>
>> * Move all remaining unwinder-only macros to libgcc: UNW_IVMS_MODE,
>>   MD_UNW_COMPATIBLE_PERSONALITY_P, MD_FROB_UPDATE_CONTEXT.
>
> I don't see any sign of macros being poisoned in system.h.  For macros 
> used in target-independent unwinder code - at least MD_FROB_UPDATE_CONTEXT 
> - that used to be defined in the host tm.h but now no longer should be, I 
> think poisoning in system.h is appropriate.

Good point: I simply had forgotten about this.

>> * The only unwinder-related macro I haven't moved is
>>   LIBGCC2_UNWIND_ATTRIBUTE.  It is only defined gcc/config/mips/mips.h.
>>   I suppose we would need a libgcc equivalent of tm.h for that,
>>   something I didn't want to attack at this point.
>
> What about DWARF_ZERO_REG and PRE_GCC3_DWARF_FRAME_REGISTERS?  
> DWARF_REG_TO_UNWIND_COLUMN may be more complicated because it's used on 
> the host in rs6000.c (although not in target-independent host code) as 
> well as on the target - I suspect that will be a case where duplicating 
> the definition (with a comment in one place pointing to the other place as 
> needing to be kept consistent, and with the host-side copy renamed to 
> facilitate poisoning) may make sense.  And all three are defined in 
> .h headers so your reason for moving them separately may apply.

I guess.  For the moment, I've concentrated on moving the sources
themselves and the build logic since I've experienced the gcc side
getting in the way of the libgcc side here.

> (There are lots more macros used in the unwinder and on the host for which 
> macros predefined with -fbuilding-libgcc may be appropriate in a later 
> patch.)

Certainly: your wiki entry gives a good overview.  For the moment, I'll
probably concentrate on the build side of things, though.  I may attack
gthr* stuff and fp-bit.[ch] next, both of which I can at least partially
test on my targets.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [patch, 4.6/4.7] fix installation of plugin header files

[Joseph S. Myers]

On Mon, 20 Jun 2011, Matthias Klose wrote:

>  - PR45078; vxworks-dummy.h is included for cpu_type in arm,
>i386, mips, sh and sparc but only installed when it's i386; copy it
>manually anytime.

I don't think you should list particular config/ headers in PLUGIN_HEADERS 
in Makefile.in; provide a way for targets to specify their additions to 
this list in config.gcc instead.  Is the issue headers that are directly 
#included from tm.h headers (for whatever reason) rather than listed in 
tm_file?  (Some of those #includes may be avoidable, but the .def ones 
probably do need listing explicitly.)

The aim should be to get the extra files in tm_file_list, which is 
included in PLUGIN_HEADERS, so that they appear in $(TM_H) dependencies as 
well.

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

Re: [build] Move unwinder to toplevel libgcc

[Joseph S. Myers]

On Mon, 20 Jun 2011, Rainer Orth wrote:

> * Move all remaining unwinder-only macros to libgcc: UNW_IVMS_MODE,
>   MD_UNW_COMPATIBLE_PERSONALITY_P, MD_FROB_UPDATE_CONTEXT.

I don't see any sign of macros being poisoned in system.h.  For macros 
used in target-independent unwinder code - at least MD_FROB_UPDATE_CONTEXT 
- that used to be defined in the host tm.h but now no longer should be, I 
think poisoning in system.h is appropriate.

> * The only unwinder-related macro I haven't moved is
>   LIBGCC2_UNWIND_ATTRIBUTE.  It is only defined gcc/config/mips/mips.h.
>   I suppose we would need a libgcc equivalent of tm.h for that,
>   something I didn't want to attack at this point.

What about DWARF_ZERO_REG and PRE_GCC3_DWARF_FRAME_REGISTERS?  
DWARF_REG_TO_UNWIND_COLUMN may be more complicated because it's used on 
the host in rs6000.c (although not in target-independent host code) as 
well as on the target - I suspect that will be a case where duplicating 
the definition (with a comment in one place pointing to the other place as 
needing to be kept consistent, and with the host-side copy renamed to 
facilitate poisoning) may make sense.  And all three are defined in 
.h headers so your reason for moving them separately may apply.

(There are lots more macros used in the unwinder and on the host for which 
macros predefined with -fbuilding-libgcc may be appropriate in a later 
patch.)

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

Re: powerpc64 large-toc vs. reload

[Alan Modra]

On Sun, Jun 19, 2011 at 11:04:12PM -0400, David Edelsohn wrote:
> On Sun, Jun 19, 2011 at 10:03 AM, Alan Modra  wrote:
> >* config/rs6000/rs6000.c (create_TOC_reference): Wrap high part
> >of toc-relative address in CONST.
> >(rs6000_delegitimize_address): Recognize changed address.
> >(rs6000_legitimize_reload_address): Likewise.
> >(rs6000_emit_move): Don't force these constants to memory.
> >* config/rs6000/rs6000.md (tls_gd, tls_gd_high): Wrap high part of
> >toc-relative address in CONST.
> >(tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high): Likewise.
> >(tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewise.
> 
> Okay.

I applied this after boostrapping c,c++,fortran,lto and finding no
regressions, both on mainline and gcc-4.6.  Then I did the same for
gcc-4.6-ibm and gcc-4.5-ibm, and discovered an internal compiler error
on the gcc-4.5-ibm branch in one fortran testcase.  Arrgh!  This was
due to reload putting one of the new CONST patterns in the constant
pool.  I'm almost certain this can happen on mainline and 4.6 too but
just doesn't trigger on the testsuite or during bootstrap.

So I need to make a followup patch and match the new CONST pattern in
rs6000_cannot_force_const_mem.  reload.c:CONST_POOL_OK_P will then
prevent reload putting these constants into memory.

Bootstrapped and regression tested all over again.  This is what I'm
about to commit.

* config/rs6000/rs6000.c (rs6000_cannot_force_const_mem): Match
CONST high part large-toc address.
(rs6000_tls_referenced_p): Make static.
* config/rs6000/rs6000-protos.h (rs6000_tls_referenced_p): Delete.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 175200)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6045,7 +6045,7 @@ rs6000_legitimize_tls_address (rtx addr,
 
 /* Return 1 if X contains a thread-local symbol.  */
 
-bool
+static bool
 rs6000_tls_referenced_p (rtx x)
 {
   if (! TARGET_HAVE_TLS)
@@ -6059,6 +6059,11 @@ rs6000_tls_referenced_p (rtx x)
 static bool
 rs6000_cannot_force_const_mem (enum machine_mode mode ATTRIBUTE_UNUSED, rtx x)
 {
+  if (GET_CODE (x) == CONST
+  && GET_CODE (XEXP (x, 0)) == PLUS
+  && GET_CODE (XEXP (XEXP (x, 0), 1)) == HIGH)
+return true;
+
   return rs6000_tls_referenced_p (x);
 }
 
Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   (revision 175200)
+++ gcc/config/rs6000/rs6000-protos.h   (working copy)
@@ -171,7 +171,6 @@ extern unsigned int rs6000_dbx_register_
 extern void rs6000_emit_epilogue (int);
 extern void rs6000_emit_eh_reg_restore (rtx, rtx);
 extern const char * output_isel (rtx *);
-extern bool rs6000_tls_referenced_p (rtx);
 
 extern void rs6000_aix_asm_output_dwarf_table_ref (char *);
 

The 4.6 patch is a little different due to 4.5 not already having
rs6000_cannot_force_const_mem.

* config/rs6000/rs6000.c (rs6000_cannot_force_const_mem): New func.
(TARGET_CANNOT_FORCE_CONST_MEM): Update definition.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 175201)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1212,6 +1212,7 @@ static enum machine_mode rs6000_eh_retur
 static bool rs6000_can_eliminate (const int, const int);
 static void rs6000_conditional_register_usage (void);
 static void rs6000_trampoline_init (rtx, tree, rtx);
+static bool rs6000_cannot_force_const_mem (rtx);
 
 /* Hash table stuff for keeping track of TOC entries.  */
 
@@ -1382,7 +1383,7 @@ static const struct default_options rs60
 #define TARGET_HAVE_TLS HAVE_AS_TLS
 
 #undef TARGET_CANNOT_FORCE_CONST_MEM
-#define TARGET_CANNOT_FORCE_CONST_MEM rs6000_tls_referenced_p
+#define TARGET_CANNOT_FORCE_CONST_MEM rs6000_cannot_force_const_mem
 
 #undef TARGET_DELEGITIMIZE_ADDRESS
 #define TARGET_DELEGITIMIZE_ADDRESS rs6000_delegitimize_address
@@ -6651,6 +6663,19 @@ rs6000_tls_referenced_p (rtx x)
   return for_each_rtx (&x, &rs6000_tls_symbol_ref_1, 0);
 }
 
+/* Implement TARGET_CANNOT_FORCE_CONST_MEM.  */
+
+static bool
+rs6000_cannot_force_const_mem (rtx x)
+{
+  if (GET_CODE (x) == CONST
+  && GET_CODE (XEXP (x, 0)) == PLUS
+  && GET_CODE (XEXP (XEXP (x, 0), 1)) == HIGH)
+return true;
+
+  return rs6000_tls_referenced_p (x);
+}
+
 /* Return 1 if *X is a thread-local symbol.  This is the same as
rs6000_tls_symbol_ref except for the type of the unused argument.  */
 

-- 
Alan Modra
Australia Development Lab, IBM

Re: [x32] PATCH: Remove ix86_promote_function_mode

[H.J. Lu]

On Mon, Jun 20, 2011 at 7:40 AM, Jeff Law  wrote:
>
>>> Peter, do you think it is safe to assume upper 32bits are zero in
>>> user space for x32? Kernel isn't a problem since pointer is 64bit
>>> in kernel and we don't pass pointers on stack to kernel.
>>
>> As I have already stated, if we *cannot* require pointers to be
>> zero-extended on entry to the kernel, we're going to have to have
>> special entry points for all the x32 system calls except the ones that
>> don't take pointers.asdfasfd
> BTW (and feel free to respond off-list), what's the rationale behind
> zero-extending values in x32 from 32 bits to 64 bits rather than the
> more traditional sign-extending?
>

Since hardware zero-extends 32-bit result to 64-bit in the destination
general-purpose register, we can load addresses into 32bit (ptr_mode)
register and use the full 64bit (Pmode) register without any additional
instructions. As far as the processor is concerned, x32 process is the
same as x86-64 process.  The only difference is x32 won't go over
4GB.

-- 
H.J.

Re: [patch fold-const.c]: Add some missing optimizations about binary and and truth-not

[Jakub Jelinek]

On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
> On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek  wrote:
> > On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
> >> Applied at revision 175206 to trunk.
> >
> > There is no need to post such notices to gcc-patches, we have the gcc-cvs
> > mailing list where this is automatically posted to.
> > On gcc-patches it just adds unnecessary noise.
> 
> Until there is some way to easily map an email on gcc-patches to an
> email on gcc-cvs, or a legitimate patch tracker instead of just
> mailing lists, then it is very useful "noise".  I've found at least a
> hundred dropped patches so far for our project alone.  You can always
> just delete the email instead of reading it.

No, our guidelines say that such mails shouldn't be sent:

http://gcc.gnu.org/svnwrite.html
"When you have checked in a patch exactly as it has been approved, you do
not need to tell that to people -- including the approver. People
interested in when a particular patch is committed can check SVN or the
gcc-cvs list."

This has been discussed several times.  So no, this noise isn't at all
useful nor welcome.

Jakub

Re: [Patch, Fortran] (coarray) Add LOCK_TYPE

[Tobias Burnus]

*PING*

On 06/16/2011 08:27 AM, Tobias Burnus wrote:
This patch adds ISO_Fortran_Env's LOCK_TYPE, tons of constraint checks 
and a simple implementation for -fcoarray=single.


With the implementation of LOCK_TYPE and (UN)LOCK, gfortran can now 
parse all coarrays constructs of Fortran 2008. (However, there are 
still known deficits and bugs in the resolving/code-producing stage; 
for instance, allocatable scalar coarrays are not yet implemented.)


Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

Re: Cgraph alias reorg 15/14 (New infrastructure for same body aliases)

[Hans-Peter Nilsson]

On Mon, 20 Jun 2011, Richard Guenther wrote:

> On Sun, Jun 19, 2011 at 2:51 PM, Jan Hubicka  wrote:
> >> > On Sat, 11 Jun 2011, Jan Hubicka wrote:
> >> >
> >> > > Hi,
> >> > > this patch complettes the same body alias rework by removing the old 
> >> > > same body
> >> > > alias code and adding new representation.  Same body aliases are now 
> >> > > separate
> >> > > function nodes that have IPA_REF_ALIAS reference to the node they are 
> >> > > alias of.
> >> > >
> >> > > I am still getting one failure:
> >> > > FAIL: g++.dg/torture/pr43879-1_1.C
> >> > >
> >> > > It tests IPA PTA in presence of same body aliases.  I honestly have no 
> >> > > idea
> >> > > what is wrong there.  I decided to go ahead with the patch anyway, 
> >> > > given the
> >> > > current state of affair of aliases and IPA-PTA. Hope Richard will help 
> >> > > me
> >> > > fixing this on Monday.
> >> >
> >> > Still there, see again PR49373.  Anything better than a xfail in the 
> >> > works?
> >>
> >> Yes, we discussed the problem with Richi and the issue is that ipa-pta gets
> >> confused by inliner redirecting edge from alias to the real inline clone.
> >> The proper fix is to teach passmanager to do small ipa passes before final
> >> compilation.  I am currently at the GCC gathering, so I plan to implement
> >> this day after tomorrow after returning.
> > But for sure we can xfail it.
> > (It was prevoiusly latent problem and richi did quicker fix but that just
> > uncovered another problems. Sorry for the delays here).
>
> If you xfail it please open a regression bugreport.

Anything wrong with the already open PR49373 where it's
mentioned?

>
> Richard.
>
> > Honza
> >
>

Re: [x32] PATCH: Remove ix86_promote_function_mode

[H.J. Lu]

On Mon, Jun 20, 2011 at 7:33 AM, H. Peter Anvin  wrote:
> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt  
>> wrote:
>>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
 Promote pointers to Pmode when passing/returning in registers is
 a security concern.
>
> No.  Promoting *NON*-pointers (or rather, requiring non-pointers to
> having already been zero extended) is a security concern.  I thought I'd
> made that point clear already.  This is a hideously critical distinction.

I can promote pointers then.

>> Peter, do you think it is safe to assume upper 32bits are zero in
>> user space for x32? Kernel isn't a problem since pointer is 64bit
>> in kernel and we don't pass pointers on stack to kernel.
>
> As I have already stated, if we *cannot* require pointers to be
> zero-extended on entry to the kernel, we're going to have to have
> special entry points for all the x32 system calls except the ones that
> don't take pointers.
>

32bit pointers are zero-extended to 64bit when passing in registers to
kernel.

-- 
H.J.

Re: [x32] PATCH: Remove ix86_promote_function_mode

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/20/11 08:33, H. Peter Anvin wrote:
> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt  
>> wrote:
>>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
 Promote pointers to Pmode when passing/returning in registers is
 a security concern.
> 
> No.  Promoting *NON*-pointers (or rather, requiring non-pointers to
> having already been zero extended) is a security concern.  I thought I'd
> made that point clear already.  This is a hideously critical distinction.
> 
>> Peter, do you think it is safe to assume upper 32bits are zero in
>> user space for x32? Kernel isn't a problem since pointer is 64bit
>> in kernel and we don't pass pointers on stack to kernel.
> 
> As I have already stated, if we *cannot* require pointers to be
> zero-extended on entry to the kernel, we're going to have to have
> special entry points for all the x32 system calls except the ones that
> don't take pointers.asdfasfd
BTW (and feel free to respond off-list), what's the rationale behind
zero-extending values in x32 from 32 bits to 64 bits rather than the
more traditional sign-extending?

If it's already been discussed, feel free to point me at the thread.
It's not hugely important, but I get this nagging feeling I'm missing
something.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN/1vpAAoJEBRtltQi2kC7XEUH/0XkfWpqjp3ry/GHsLEYn+8/
bKbd8x5gcrdBKenxkqKrDOqhTGUvttRxN4JClafzWSGFdrDiYxIwJAR4NAvuyYWa
rRzSgMRl7VBmPAO+CmEyy2LZ7zEHn4j+iGPWrVQLToAjkIxlSO91Tu/8bimXocC6
FymxVe1Zj9+sCDTmirQnc+TtwnQwVIsNfXWk1e1tKO2bXaUQzfX3YaUKW/B1jw1V
5Xfong0y6XTCDAZQ4sNkCqVYaQBZuMfCLHVX8WP/kA0jMRycvgHWM823YFfFEU+P
UHGgrVQeJX5GS1yoCXNrvvBLtDLIbnyYSAjosCIgje7hskBIqKqSdr146q1CTfY=
=lUfw
-END PGP SIGNATURE-

Re: [patch fold-const.c]: Add some missing optimizations about binary and and truth-not

[NightStrike]

On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek  wrote:
> On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
>> > Ok.
>> > Richard.
>>
>> Applied at revision 175206 to trunk.
>
> There is no need to post such notices to gcc-patches, we have the gcc-cvs
> mailing list where this is automatically posted to.
> On gcc-patches it just adds unnecessary noise.
>
>        Jakub
>

Until there is some way to easily map an email on gcc-patches to an
email on gcc-cvs, or a legitimate patch tracker instead of just
mailing lists, then it is very useful "noise".  I've found at least a
hundred dropped patches so far for our project alone.  You can always
just delete the email instead of reading it.

Re: [x32] PATCH: Remove ix86_promote_function_mode

[H. Peter Anvin]

On 06/20/2011 07:01 AM, H.J. Lu wrote:
> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt  
> wrote:
>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
>>> Promote pointers to Pmode when passing/returning in registers is
>>> a security concern.

No.  Promoting *NON*-pointers (or rather, requiring non-pointers to
having already been zero extended) is a security concern.  I thought I'd
made that point clear already.  This is a hideously critical distinction.

> Peter, do you think it is safe to assume upper 32bits are zero in
> user space for x32? Kernel isn't a problem since pointer is 64bit
> in kernel and we don't pass pointers on stack to kernel.

As I have already stated, if we *cannot* require pointers to be
zero-extended on entry to the kernel, we're going to have to have
special entry points for all the x32 system calls except the ones that
don't take pointers.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

C++ PATCH for c++/43831 (missing diagnostics for redundant captures)

[Jason Merrill]

Apparently it's ill-formed to explicitly specify a capture for a 
variable that would be captured the same way by default, so I've added 
this as a pedwarn.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit ec4717b67c17d8970828f4f9c81ac8794f65a44f
Author: Jason Merrill 
Date:   Sat Jun 18 15:03:12 2011 -0400

	PR c++/43831
	* parser.c (cp_parser_lambda_introducer): Complain about redundant
	captures.
	* semantics.c (add_capture): Likewise.
	(register_capture_members): Clear IDENTIFIER_MARKED.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 49aa35e..75dac6a 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7485,6 +7485,10 @@ cp_parser_lambda_introducer (cp_parser* parser, tree lambda_expr)
   /* Possibly capture `this'.  */
   if (cp_lexer_next_token_is_keyword (parser->lexer, RID_THIS))
 	{
+	  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
+	  if (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr) == CPLD_COPY)
+	pedwarn (loc, 0, "explicit by-copy capture of % redundant "
+		 "with by-copy capture default");
 	  cp_lexer_consume_token (parser->lexer);
 	  add_capture (lambda_expr,
 		   /*id=*/this_identifier,
@@ -7568,6 +7572,21 @@ cp_parser_lambda_introducer (cp_parser* parser, tree lambda_expr)
 	capture_init_expr
 	  = unqualified_name_lookup_error (capture_init_expr);
 
+  if (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr) != CPLD_NONE
+	  && !explicit_init_p)
+	{
+	  if (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr) == CPLD_COPY
+	  && capture_kind == BY_COPY)
+	pedwarn (capture_token->location, 0, "explicit by-copy capture "
+		 "of %qD redundant with by-copy capture default",
+		 capture_id);
+	  if (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr) == CPLD_REFERENCE
+	  && capture_kind == BY_REFERENCE)
+	pedwarn (capture_token->location, 0, "explicit by-reference "
+		 "capture of %qD redundant with by-reference capture "
+		 "default", capture_id);
+	}
+
   add_capture (lambda_expr,
 		   capture_id,
 		   capture_init_expr,
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 76c1862..1f683c7 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -8516,8 +8516,8 @@ tree
 add_capture (tree lambda, tree id, tree initializer, bool by_reference_p,
 	 bool explicit_init_p)
 {
-  tree type;
-  tree member;
+  char *buf;
+  tree type, member, name;
 
   type = lambda_capture_field_type (initializer);
   if (by_reference_p)
@@ -8527,18 +8527,31 @@ add_capture (tree lambda, tree id, tree initializer, bool by_reference_p,
 	error ("cannot capture %qE by reference", initializer);
 }
 
+  /* Add __ to the beginning of the field name so that user code
+ won't find the field with name lookup.  We can't just leave the name
+ unset because template instantiation uses the name to find
+ instantiated fields.  */
+  buf = (char *) alloca (IDENTIFIER_LENGTH (id) + 3);
+  buf[1] = buf[0] = '_';
+  memcpy (buf + 2, IDENTIFIER_POINTER (id),
+	  IDENTIFIER_LENGTH (id) + 1);
+  name = get_identifier (buf);
+
+  /* If TREE_TYPE isn't set, we're still in the introducer, so check
+ for duplicates.  */
+  if (!TREE_TYPE (lambda))
+{
+  if (IDENTIFIER_MARKED (name))
+	{
+	  pedwarn (input_location, 0,
+		   "already captured %qD in lambda expression", id);
+	  return NULL_TREE;
+	}
+  IDENTIFIER_MARKED (name) = true;
+}
+
   /* Make member variable.  */
-  {
-/* Add __ to the beginning of the field name so that user code
-   won't find the field with name lookup.  We can't just leave the name
-   unset because template instantiation uses the name to find
-   instantiated fields.  */
-char *buf = (char *) alloca (IDENTIFIER_LENGTH (id) + 3);
-buf[1] = buf[0] = '_';
-memcpy (buf + 2, IDENTIFIER_POINTER (id),
-	IDENTIFIER_LENGTH (id) + 1);
-member = build_lang_decl (FIELD_DECL, get_identifier (buf), type);
-  }
+  member = build_lang_decl (FIELD_DECL, name, type);
 
   if (!explicit_init_p)
 /* Normal captures are invisible to name lookup but uses are replaced
@@ -8548,6 +8561,9 @@ add_capture (tree lambda, tree id, tree initializer, bool by_reference_p,
always visible.  */
 DECL_NORMAL_CAPTURE_P (member) = true;
 
+  if (id == this_identifier)
+LAMBDA_EXPR_THIS_CAPTURE (lambda) = member;
+
   /* Add it to the appropriate closure class if we've started it.  */
   if (current_class_type && current_class_type == TREE_TYPE (lambda))
 finish_member_declaration (member);
@@ -8555,13 +8571,6 @@ add_capture (tree lambda, tree id, tree initializer, bool by_reference_p,
   LAMBDA_EXPR_CAPTURE_LIST (lambda)
 = tree_cons (member, initializer, LAMBDA_EXPR_CAPTURE_LIST (lambda));
 
-  if (id == this_identifier)
-{
-  if (LAMBDA_EXPR_CAPTURES_THIS_P (lambda))
-error ("already captured % in lambda expression");
-  LAMBDA_EXPR_THIS_CAPTURE (lambda) = member;
-}
-
   if (TREE_TYPE (lambda))
 retur

C++ PATCH for c++/43321 (error on valid C++0x auto)

[Jason Merrill]

Here describable_type thought that a particular INDIRECT_REF was 
describable, but it really wasn't.  Fixed by removing describable_type 
entirely; we can just try to deduce, and defer until instantiation if it 
doesn't work.


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

commit 9ffe8ed0665020e00f7923314fe2e9aa99a155b1
Author: Jason Merrill 
Date:   Sat Jun 18 15:35:45 2011 -0400

	PR c++/43321
	* semantics.c (describable_type): Remove.
	* cp-tree.h: Likewise.
	* decl.c (cp_finish_decl): Don't call it.
	* init.c (build_new): Likewise.
	* parser.c (cp_parser_omp_for_loop): Likewise.
	* pt.c (tsubst_decl): Likewise.
	(do_auto_deduction): If we fail in a template, try again
	at instantiation time.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 2773e34..904e44c 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5445,7 +5445,6 @@ extern bool cxx_omp_create_clause_info		(tree, tree, bool, bool, bool);
 extern tree baselink_for_fns(tree);
 extern void finish_static_assert(tree, tree, location_t,
  bool);
-extern tree describable_type			(tree);
 extern tree finish_decltype_type(tree, bool, tsubst_flags_t);
 extern tree finish_trait_expr			(enum cp_trait_kind, tree, tree);
 extern tree build_lambda_expr   (void);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 59c4a4c..85249f1 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5944,13 +5944,10 @@ cp_finish_decl (tree decl, tree init, bool init_const_expr_p,
 	d_init = build_x_compound_expr_from_list (d_init, ELK_INIT,
 		  tf_warning_or_error);
   d_init = resolve_nondeduced_context (d_init);
-  if (describable_type (d_init))
-	{
-	  type = TREE_TYPE (decl) = do_auto_deduction (type, d_init,
-		   auto_node);
-	  if (type == error_mark_node)
-	return;
-	}
+  type = TREE_TYPE (decl) = do_auto_deduction (type, d_init,
+		   auto_node);
+  if (type == error_mark_node)
+	return;
 }
 
   if (!ensure_literal_type_for_constexpr_object (decl))
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 3b92665..140e064 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2600,8 +2600,7 @@ build_new (VEC(tree,gc) **placement, tree type, tree nelts,
 	{
 	  tree d_init = VEC_index (tree, *init, 0);
 	  d_init = resolve_nondeduced_context (d_init);
-	  if (describable_type (d_init))
-	type = do_auto_deduction (type, d_init, auto_node);
+	  type = do_auto_deduction (type, d_init, auto_node);
 	}
 }
 
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 75dac6a..856a8a7 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -24504,7 +24504,7 @@ cp_parser_omp_for_loop (cp_parser *parser, tree clauses, tree *par_clauses)
 		&is_direct_init,
 		&is_non_constant_init);
 
-		  if (auto_node && describable_type (init))
+		  if (auto_node)
 			{
 			  TREE_TYPE (decl)
 			= do_auto_deduction (TREE_TYPE (decl), init,
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 85f2749..6f15101 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10122,11 +10122,8 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
 	if (auto_node && init)
 	  {
 		init = resolve_nondeduced_context (init);
-		if (describable_type (init))
-		  {
-		type = do_auto_deduction (type, init, auto_node);
-		TREE_TYPE (r) = type;
-		  }
+		TREE_TYPE (r) = type
+		  = do_auto_deduction (type, init, auto_node);
 	  }
 	  }
 	else
@@ -19302,6 +19299,12 @@ do_auto_deduction (tree type, tree init, tree auto_node)
   tree decl;
   int val;
 
+  if (processing_template_decl
+  && (TREE_TYPE (init) == NULL_TREE
+	  || BRACE_ENCLOSED_INITIALIZER_P (init)))
+/* Not enough information to try this yet.  */
+return type;
+
   /* The name of the object being declared shall not appear in the
  initializer expression.  */
   decl = cp_walk_tree_without_duplicates (&init, contains_auto_r, type);
@@ -19331,6 +19334,9 @@ do_auto_deduction (tree type, tree init, tree auto_node)
 			   DEDUCE_CALL, LOOKUP_NORMAL);
   if (val > 0)
 {
+  if (processing_template_decl)
+	/* Try again at instantiation time.  */
+	return type;
   if (type && type != error_mark_node)
 	/* If type is error_mark_node a diagnostic must have been
 	   emitted by now.  Also, having a mention to ''
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 1f683c7..cfe3959 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -4803,65 +4803,6 @@ finish_static_assert (tree condition, tree message, location_t location,
 }
 }
 
-/* Returns the type of EXPR for cases where we can determine it even though
-   EXPR is a type-dependent expression.  */
-
-tree
-describable_type (tree expr)
-{
-  tree type = NULL_TREE;
-
-  if (! type_dependent_expression_p (expr)
-  && ! type_unknown_p (expr))
-{
-  type = unlowered_expr_type (expr);
-  if (real_lvalue_p (expr))
-	type = build_

Re: [Patch, AVR]: QI builtins for parity, popcount, 1<< n

[Georg-Johann Lay]

Joseph S. Myers schrieb:
> On Fri, 17 Jun 2011, Georg-Johann Lay wrote:
> 
>> So here is my question: Would it be big deal to teach optabs to
>> expand plus:di, minus:di as libcall?  Maybe even compare is
>> feasible? Like so:
> 
> I don't know what the best approach would be, but for just about
> any operation supported by GCC it makes sense to support expanding
> it as a libcall if that's the most efficient approach for a given
> target.

Using a libcall for + resp. + would we way more efficient than
expanding all the carry computations inline.

> Some of the generic optabs code could probably do with having
> target hooks added to make it work better for the less common
> targets.

A libcall could be added in TARGET_INIT_LIBCALLS, so a new hook is not
needed.  All that's needed is that optabs tests for presence of such
an entry and prefers it over inline expansion (and prefers insn over
libcall).  It appears that + and - are assumed to be cheaps or inline
expansion is always cheap.

It might already help if optabs expanded to SImode and the target
could chose if expansion of some op uses word_mode or some other, more
efficient mode.

The big targets do not need that complexity, and who cares for tiny
targets...?

Johann

libiberty PATCH for c++/37089 (wrong demangling of reference to reference)

[Jason Merrill]

C++0x specifies that a reference to reference produced by template 
argument substitution collapses to a single reference.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit b66f8ede160d3f3375d7cd68988f3d498d51cc41
Author: Jason Merrill 
Date:   Sun Jun 19 10:01:02 2011 -0400

	PR c++/37089
	* cp-demangle.c (d_print_comp): Handle reference smashing.

diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 3fc5266..d664e5f 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -3554,6 +3554,10 @@ static void
 d_print_comp (struct d_print_info *dpi, int options,
   const struct demangle_component *dc)
 {
+  /* Magic variable to let reference smashing skip over the next modifier
+ without needing to modify *dc.  */
+  const struct demangle_component *mod_inner = NULL;
+
   if (dc == NULL)
 {
   d_print_error (dpi);
@@ -3869,16 +3873,37 @@ d_print_comp (struct d_print_info *dpi, int options,
 	  }
 	  }
   }
+  goto modifier;
+
+case DEMANGLE_COMPONENT_REFERENCE:
+case DEMANGLE_COMPONENT_RVALUE_REFERENCE:
+  {
+	/* Handle reference smashing: & + && = &.  */
+	const struct demangle_component *sub = d_left (dc);
+	if (sub->type == DEMANGLE_COMPONENT_TEMPLATE_PARAM)
+	  {
+	struct demangle_component *a = d_lookup_template_argument (dpi, sub);
+	if (a && a->type == DEMANGLE_COMPONENT_TEMPLATE_ARGLIST)
+	  a = d_index_template_argument (a, dpi->pack_index);
+	sub = a;
+	  }
+
+	if (sub->type == DEMANGLE_COMPONENT_REFERENCE
+	|| sub->type == dc->type)
+	  dc = sub;
+	else if (sub->type == DEMANGLE_COMPONENT_RVALUE_REFERENCE)
+	  mod_inner = d_left (sub);
+  }
   /* Fall through.  */
+
 case DEMANGLE_COMPONENT_RESTRICT_THIS:
 case DEMANGLE_COMPONENT_VOLATILE_THIS:
 case DEMANGLE_COMPONENT_CONST_THIS:
 case DEMANGLE_COMPONENT_VENDOR_TYPE_QUAL:
 case DEMANGLE_COMPONENT_POINTER:
-case DEMANGLE_COMPONENT_REFERENCE:
-case DEMANGLE_COMPONENT_RVALUE_REFERENCE:
 case DEMANGLE_COMPONENT_COMPLEX:
 case DEMANGLE_COMPONENT_IMAGINARY:
+modifier:
   {
 	/* We keep a list of modifiers on the stack.  */
 	struct d_print_mod dpm;
@@ -3889,7 +3914,10 @@ d_print_comp (struct d_print_info *dpi, int options,
 	dpm.printed = 0;
 	dpm.templates = dpi->templates;
 
-	d_print_comp (dpi, options, d_left (dc));
+	if (!mod_inner)
+	  mod_inner = d_left (dc);
+
+	d_print_comp (dpi, options, mod_inner);
 
 	/* If the modifier didn't get printed by the type, print it
 	   now.  */
diff --git a/libiberty/testsuite/demangle-expected b/libiberty/testsuite/demangle-expected
index c94eb3c..bbd418c 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -3957,6 +3957,9 @@ decltype (({parm#1}.(operator-))()) h(A)
 _Z1fDn
 f(decltype(nullptr))
 --format=gnu-v3
+_Z1fIRiEvOT_b
+void f(int&, bool)
+--format=gnu-v3
 _ZN5a6bb5cIN23ddd3eeeENS2_416ENS0_9hES6_S6_S6_S6_S6_S6_S6_EE
 a::bb::c
 --format=gnu-v3
@@ -4118,4 +4121,4 @@ DFA
 # http://sourceware.org/bugzilla/show_bug.cgi?id=11572
 --format=auto
 _ZN3Psi7VariantIIcPKcEE5visitIIRZN11VariantTest9TestVisit11test_methodEvEUlS2_E0_RZNS6_11test_methodEvEUlcE1_RZNS6_11test_methodEvEUlNS_4NoneEE_EEENS_13VariantDetail19SelectVisitorResultIIDpT_EE4typeEDpOSG_
-Psi::VariantDetail::SelectVisitorResult::type Psi::Variant::visit((VariantTest::TestVisit::test_method()::{lambda(Psi::None)#1}&&&)...)
+Psi::VariantDetail::SelectVisitorResult::type Psi::Variant::visit((VariantTest::TestVisit::test_method()::{lambda(Psi::None)#1}&)...)

C++ PATCH for c++/47635 (ICE after error with enum scoped function)

[Jason Merrill]

If we see an enum as a scope for a declarator-id, we should avoid 
setting ctype in the first place as it can't possibly be right.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5800b6d699b10f0c15355b8f37fa9beb7957ea72
Author: Jason Merrill 
Date:   Sun Jun 19 22:38:46 2011 -0400

	PR c++/47635
	* decl.c (grokdeclarator): Don't set ctype to an ENUMERAL_TYPE.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 85249f1..263ab3f 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -8338,10 +8338,15 @@ grokdeclarator (const cp_declarator *declarator,
 		else if (TYPE_P (qualifying_scope))
 		  {
 		ctype = qualifying_scope;
-		if (innermost_code != cdk_function
-			&& current_class_type
-			&& !UNIQUELY_DERIVED_FROM_P (ctype,
-		 current_class_type))
+		if (!MAYBE_CLASS_TYPE_P (ctype))
+		  {
+			error ("%q#T is not a class or a namespace", ctype);
+			ctype = NULL_TREE;
+		  }
+		else if (innermost_code != cdk_function
+			 && current_class_type
+			 && !UNIQUELY_DERIVED_FROM_P (ctype,
+			  current_class_type))
 		  {
 			error ("type %qT is not derived from type %qT",
 			   ctype, current_class_type);
@@ -9350,7 +9355,7 @@ grokdeclarator (const cp_declarator *declarator,
  would not have exited the loop above.  */
   if (declarator
   && declarator->u.id.qualifying_scope
-  && TYPE_P (declarator->u.id.qualifying_scope))
+  && MAYBE_CLASS_TYPE_P (declarator->u.id.qualifying_scope))
 {
   tree t;
 
@@ -10156,13 +10161,6 @@ grokdeclarator (const cp_declarator *declarator,
 		   "declared out of global scope", name);
 	  }
 
-	if (ctype != NULL_TREE
-	&& TREE_CODE (ctype) != NAMESPACE_DECL && !MAYBE_CLASS_TYPE_P (ctype))
-	  {
-	error ("%q#T is not a class or a namespace", ctype);
-	ctype = NULL_TREE;
-	  }
-
 	if (ctype == NULL_TREE)
 	  {
 	if (virtualp)
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum20.C b/gcc/testsuite/g++.dg/cpp0x/enum20.C
new file mode 100644
index 000..e5dc186
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum20.C
@@ -0,0 +1,5 @@
+// PR c++/47635
+// { dg-options -std=c++0x }
+
+enum A { };
+void A::f() { }			// { dg-error "not a class" }

C++ PATCH for c++/49205 (failure to use variadic template constructor as default constructor)

[Jason Merrill]

A variadic template can take no arguments, so it's a default constructor.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9f50baae331019464a94de275ae370cfebb30600
Author: Jason Merrill 
Date:   Sun Jun 19 21:55:11 2011 -0400

	PR c++/49205
	* call.c (sufficient_parms_p): Allow parameter packs too.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 05bf983..09d73d0 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -534,15 +534,16 @@ null_ptr_cst_p (tree t)
   return false;
 }
 
-/* Returns nonzero if PARMLIST consists of only default parms and/or
-   ellipsis.  */
+/* Returns nonzero if PARMLIST consists of only default parms,
+   ellipsis, and/or undeduced parameter packs.  */
 
 bool
 sufficient_parms_p (const_tree parmlist)
 {
   for (; parmlist && parmlist != void_list_node;
parmlist = TREE_CHAIN (parmlist))
-if (!TREE_PURPOSE (parmlist))
+if (!TREE_PURPOSE (parmlist)
+	&& !PACK_EXPANSION_P (TREE_VALUE (parmlist)))
   return false;
   return true;
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-default.C b/gcc/testsuite/g++.dg/cpp0x/variadic-default.C
new file mode 100644
index 000..2625e25
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-default.C
@@ -0,0 +1,12 @@
+// PR c++/49205
+// { dg-options -std=c++0x }
+
+#include 
+
+struct A {
+  template A(T...);
+  A(std::initializer_list);
+  A(std::initializer_list);
+};
+
+A a{};

C++ PATCH for c++/48138 (losing __attribute ((aligned)) on template argument)

[Jason Merrill]

strip_typedefs needs to propagate DECL_USER_ALIGN as well as attributes 
in the attribute list.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit fd43d02986ccbd7c43014ea093fe06f94d3d0af7
Author: Jason Merrill 
Date:   Sun Jun 19 22:20:03 2011 -0400

	PR c++/48138
	* tree.c (strip_typedefs): Use build_aligned_type.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index c1824b4..3100508 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1167,6 +1167,16 @@ strip_typedefs (tree t)
 
   if (!result)
   result = TYPE_MAIN_VARIANT (t);
+  if (TYPE_USER_ALIGN (t) != TYPE_USER_ALIGN (result)
+  || TYPE_ALIGN (t) != TYPE_ALIGN (result))
+{
+  gcc_assert (TYPE_USER_ALIGN (t));
+  if (TYPE_ALIGN (t) == TYPE_ALIGN (result))
+	result = build_variant_type_copy (result);
+  else
+	result = build_aligned_type (result, TYPE_ALIGN (t));
+  TYPE_USER_ALIGN (result) = true;
+}
   if (TYPE_ATTRIBUTES (t))
 result = cp_build_type_attribute_variant (result, TYPE_ATTRIBUTES (t));
   return cp_build_qualified_type (result, cp_type_quals (t));
diff --git a/gcc/testsuite/g++.dg/ext/attr-aligned01.C b/gcc/testsuite/g++.dg/ext/attr-aligned01.C
new file mode 100644
index 000..a051c6e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/attr-aligned01.C
@@ -0,0 +1,20 @@
+// PR c++/48138
+// { dg-options -std=c++0x }
+
+#define ALIGNED(x) __attribute__((aligned(x)))
+#define SA(X) static_assert ((X),#X)
+
+template
+void type_alignment(const T&) {
+  struct { char c; T t; } s;
+  SA((char*)&s.t - (char*)&s.c == 8);
+}
+
+int main() {
+  typedef char unaligned[15];
+  typedef char aligned[15] ALIGNED(8);
+
+  aligned z;
+  type_alignment(z);
+  type_alignment(z);
+}

Re: [PATCH][RFC][1/2] Bitfield lowering, add BIT_FIELD_EXPR

[William J. Schmidt]

On Thu, 2011-06-16 at 09:49 -0700, Richard Henderson wrote:
> On 06/16/2011 04:35 AM, Richard Guenther wrote:
> > 
> > + /* Bit-field insertion needs several shift and mask operations.  */
> > + case BIT_FIELD_EXPR:
> > +   return 3;
> 
> ... depending on the target, of course.
> 

Agreed -- this is a single-instruction operation on PowerPC.  Probably
need some target-specific weights here.

> 
> 
> r~

C++ PATCH for c++/47080 (limits on explicit conversion operators)

[Jason Merrill]

The PR pointed out that explicit conversion operators are more 
restricted than normal ones even in direct-initialization; the return 
type must be convertible to the target type with no more than a 
qualification conversion.


Tested x86_64-pc-linux-gnu, applying to trunk
commit 8f60db54d602164cda13a5f8c763f569b70c5e40
Author: Jason Merrill 
Date:   Mon Jun 20 00:09:37 2011 -0400

	PR c++/47080
	* call.c (rejection_reason_code): Add rr_explicit_conversion.
	(print_z_candidate): Handle it.
	(explicit_conversion_rejection): New.
	(build_user_type_conversion_1): Reject an explicit conversion
	function that requires more than a qualification conversion.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 09d73d0..e9d6e7e 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -429,6 +429,7 @@ struct candidate_warning {
 enum rejection_reason_code {
   rr_none,
   rr_arity,
+  rr_explicit_conversion,
   rr_arg_conversion,
   rr_bad_arg_conversion
 };
@@ -608,6 +609,16 @@ bad_arg_conversion_rejection (tree first_arg, int n_arg, tree from, tree to)
   return r;
 }
 
+static struct rejection_reason *
+explicit_conversion_rejection (tree from, tree to)
+{
+  struct rejection_reason *r = alloc_rejection (rr_explicit_conversion);
+  r->u.conversion.n_arg = 0;
+  r->u.conversion.from_type = from;
+  r->u.conversion.to_type = to;
+  return r;
+}
+
 /* Dynamically allocate a conversion.  */
 
 static conversion *
@@ -3153,6 +3164,12 @@ print_z_candidate (const char *msgstr, struct z_candidate *candidate)
 	case rr_bad_arg_conversion:
 	  print_conversion_rejection (loc, &r->u.bad_conversion);
 	  break;
+	case rr_explicit_conversion:
+	  inform (loc, "  return type %qT of explicit conversion function "
+		  "cannot be converted to %qT with a qualification "
+		  "conversion", r->u.conversion.from_type,
+		  r->u.conversion.to_type);
+	  break;
 	case rr_none:
 	default:
 	  /* This candidate didn't have any issues or we failed to
@@ -3429,9 +3446,10 @@ build_user_type_conversion_1 (tree totype, tree expr, int flags)
 
   for (cand = candidates; cand != old_candidates; cand = cand->next)
 	{
+	  tree rettype = TREE_TYPE (TREE_TYPE (cand->fn));
 	  conversion *ics
 	= implicit_conversion (totype,
-   TREE_TYPE (TREE_TYPE (cand->fn)),
+   rettype,
    0,
    /*c_cast_p=*/false, convflags);
 
@@ -3453,14 +3471,23 @@ build_user_type_conversion_1 (tree totype, tree expr, int flags)
 
 	  if (!ics)
 	{
-	  tree rettype = TREE_TYPE (TREE_TYPE (cand->fn));
 	  cand->viable = 0;
 	  cand->reason = arg_conversion_rejection (NULL_TREE, -1,
 		   rettype, totype);
 	}
+	  else if (DECL_NONCONVERTING_P (cand->fn)
+		   && ics->rank > cr_exact)
+	{
+	  /* 13.3.1.5: For direct-initialization, those explicit
+		 conversion functions that are not hidden within S and
+		 yield type T or a type that can be converted to type T
+		 with a qualification conversion (4.4) are also candidate
+		 functions.  */
+	  cand->viable = -1;
+	  cand->reason = explicit_conversion_rejection (rettype, totype);
+	}
 	  else if (cand->viable == 1 && ics->bad_p)
 	{
-	  tree rettype = TREE_TYPE (TREE_TYPE (cand->fn));
 	  cand->viable = -1;
 	  cand->reason
 		= bad_arg_conversion_rejection (NULL_TREE, -1,
@@ -5513,7 +5540,18 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum,
 
   for (; t; t = convs->u.next)
 	{
-	  if (t->kind == ck_user || !t->bad_p)
+	  if (t->kind == ck_user && t->cand->reason)
+	{
+	  permerror (input_location, "invalid user-defined conversion "
+			 "from %qT to %qT", TREE_TYPE (expr), totype);
+	  print_z_candidate ("candidate is:", t->cand);
+	  expr = convert_like_real (t, expr, fn, argnum, 1,
+	/*issue_conversion_warnings=*/false,
+	/*c_cast_p=*/false,
+	complain);
+	  return cp_convert (totype, expr);
+	}
+	  else if (t->kind == ck_user || !t->bad_p)
 	{
 	  expr = convert_like_real (t, expr, fn, argnum, 1,
 	/*issue_conversion_warnings=*/false,
diff --git a/gcc/testsuite/g++.dg/cpp0x/explicit6.C b/gcc/testsuite/g++.dg/cpp0x/explicit6.C
new file mode 100644
index 000..0d620be
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/explicit6.C
@@ -0,0 +1,11 @@
+// PR c++/47080
+// { dg-options -std=c++0x }
+
+struct A {
+  explicit operator int();	// { dg-message "qualification conversion" }
+};
+
+int main() {
+  bool b((A()));		// { dg-error "invalid user-defined" }
+  !A();// { dg-error "" }
+}

Re: [Ada] Fix bugs with volatile and components of aggregate types

[Michael Matz]

Hi,

On Sun, 19 Jun 2011, Mike Stump wrote:

> >> if T is a non-volatile composite type with volatile components, and O 
> >> is an object of type T, are the optimizers allowed to remove the 
> >> assignment "O := O"?
> > 
> > Good question, that I'm not really qualified to answer.  Any language 
> > lawyer?
> 
> I'd like to think that the optimizers are not allowed to remove the 
> assignment (unless they synthesize of up the assignment of all volatile 
> fields).  For unions, head explodes.  I think for unions, it can.  I 
> could check the standard to ensure I have it right, but, well, that's 
> annoying.  :-)  This answer is for the answer for C and C++, but, the 
> middle end, _could_ decide to differ, if it had a compelling reason to.  
> I don't know of any reason.  Now, before someone tries to optimize 
> structures, please be very careful.  Unions, transparent unions, 
> frontend synthed structures with multiple offsets at the same location 
> and the like come to mind.

The middle end really can't decide.  See also PR45472, from comment #7:

---
This all points to a deeper problem IMO, one we need to decide how to 
solve before tackling the details of this bug, namely: how are 
non-volatile objects containing volatile subobjects handled?  I don't know 
if the language standard says anything about this.

We have several possibilities:
1) make all objects containing volatile subobjects volatile itself
2) make instructions touching such objects volatile
3) make instructions touching the volatile components volatile

The first has the problem that volatile objects with aggregate type
implicitely contain only volatile subobjects, that is for such object:
  struct {int a; volatile int b;} half_volatile;
with solution (1) this would be equivalent to
  volatile struct {int a; volatile int b;} half_volatile;
and hence halt_volatile.a would be volatile too, probably unlike the
author intended.

The other two solutions are more work, especially because the
half-volatility wouldn't be reflected in the objects type.
---

Downwards we decided that it's really the languages business to define
half-volatility, so it either needs to or doesn't need to emit volatile
mem_refs according to its standard.


Ciao,
Michael.

Re: [x32] PATCH: Remove ix86_promote_function_mode

[H.J. Lu]

On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt  wrote:
> On 06/20/2011 03:51 PM, H.J. Lu wrote:
>> Promote pointers to Pmode when passing/returning in registers is
>> a security concern.
>
> Whuh?
>

Peter, do you think it is safe to assume upper 32bits are zero in
user space for x32? Kernel isn't a problem since pointer is 64bit
in kernel and we don't pass pointers on stack to kernel.


-- 
H.J.

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Christian Bruel]

On 06/20/2011 03:41 PM, Rainer Orth wrote:

Christian Bruel  writes:


2011-06-16  Christian Bruel

PR 49139/43654


Please use the correct PR number format here:

PR middle-end/49139
 PR middle-end/43654

Otherwise the check-in notices don't get into the PRs.


OK thanks, in fact I was referring to the file gcc.dg/pr43564.c (there 
was a typo in the number btw). But good indeed to send the notice into 
the original PR as well.


Cheers

Christian



Thanks.
 Rainer

Re: [PATCH] parallelize g++ testing a bit more

[Jakub Jelinek]

On Mon, Jun 20, 2011 at 09:28:56AM -0400, Jason Merrill wrote:
> On 06/17/2011 08:20 PM, Mike Stump wrote:
> >On Jun 17, 2011, at 10:47 AM, Nathan Froyd wrote:
> >>I've done a lot of g++-only testsuite runs lately
> >
> >I think it is reasonable to have even more of them, say, if you have 16 
> >cores and just test c++...  I wonder what the scaling is like as we approach 
> >larger N.  :-)
> 
> In my test runs, one of the libstdc++ batches (normal3) takes longer
> than any of the g++ batches, so breaking that up would be more
> effective for me.  :)

Yeah, certainly, libstdc++ needs more parallelization most.
But, as I wrote already to Rainer in Autumn, the methodology
for splitting things up should be on a fast box look at
the time spent in each of the parts as reported by dejagnu
in the log files, and split it to make the jobs roughly even
sized with not overcomplicated patterns.

Here are some numbers from my last x86_64-linux regtest.

>From these numbers, I'd say the first parallelization changes
should be split gcc/execute.exp testing from 2 to 4 parallel jobs,
gcc/compile.exp from one to 2, gfortran/dg.exp from 3 to 6 and
libstdc++-v3/conformance.exp from 4 to 8 or 10.
Everything else is much less important.

gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/bprob/bprob.exp completed in 23 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/charset/charset.exp completed in 9 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/compat/compat.exp completed in 49 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/compat/struct-layout-1.exp completed in 271 
seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/debug/debug.exp completed in 156 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp completed in 7 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/dfp/dfp.exp completed in 25 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/gcov/gcov.exp completed in 3 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/gomp/gomp.exp completed in 16 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/graphite/graphite.exp completed in 0 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/guality/guality.exp completed in 11 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/lto/lto.exp completed in 176 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/pch/pch.exp completed in 18 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/plugin/plugin.exp completed in 5 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/special/ecos.exp completed in 2 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/tls/tls.exp completed in 1 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/torture/dg-torture.exp completed in 469 
seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/torture/stackalign/stackalign.exp completed 
in 52 seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/tree-prof/tree-prof.exp completed in 22 
seconds
gcc/testsuite/g++/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/vect/vect.exp completed in 1 seconds
gcc/testsuite/g++1/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.old-deja/old-deja.exp completed in 662 seconds
gcc/testsuite/g++2/g++.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/g++.dg/dg.exp completed in 704 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp completed in 227 
seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/autopar/autopar.exp completed in 9 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/charset/charset.exp completed in 4 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/compat/compat.exp completed in 87 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/cpp.exp completed in 31 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/trad/trad.exp completed in 5 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/debug/debug.exp completed in 201 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf2.exp completed in 6 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/dfp/dfp.exp completed in 28 seconds
gcc/testsuite/gcc/gcc.log.sep:testcase 
/usr/src/gcc/gcc/testsuite/gcc.dg/fixed-point/fixed-point.exp completed in 0 
seconds
gcc/testsuite/gcc/gcc.log.sep:te

Re: [x32] PATCH: Remove ix86_promote_function_mode

[Bernd Schmidt]

On 06/20/2011 03:51 PM, H.J. Lu wrote:
> Promote pointers to Pmode when passing/returning in registers is
> a security concern.

Whuh?

>   * combine.c (cant_combine_insn_p): Check zero/sign extended
>   hard registers.

This part is OK.


Bernd

[x32] PATCH: Remove ix86_promote_function_mode

[H.J. Lu]

Promote pointers to Pmode when passing/returning in registers is
a security concern.  This patch removes ix86_promote_function_mode,
which exposes:

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

There are 2 different patches for PR 47725:

http://gcc.gnu.org/ml/gcc-patches/2011-02/threads.html#01018

One checks zero/sign extended hard registers in cant_combine_insn_p
and the other changes assign_parm_setup_reg to copy the hard register
first before extending it.  This patch changes cant_combine_insn_p.


H.J.

commit 6202f3601f5b2a5a41b60425f1206681823ecaa9
Author: H.J. Lu 
Date:   Sun Jun 19 19:24:11 2011 -0700

Remove ix86_promote_function_mode.

2011-06-19  H.J. Lu  

PR middle-end/47725
PR target/48085
* calls.c (precompute_register_parameters): Don't convert
pointer to TLS symbol if needed.

* combine.c (cant_combine_insn_p): Check zero/sign extended
hard registers.

* config/i386/i386.c (ix86_promote_function_mode): Removed.
(TARGET_PROMOTE_FUNCTION_MODE): Likewise.

diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
index 564e123..6619f2f 100644
--- a/gcc/ChangeLog.x32
+++ b/gcc/ChangeLog.x32
@@ -1,3 +1,16 @@
+2011-06-19  H.J. Lu  
+
+   PR middle-end/47725
+   PR target/48085
+   * calls.c (precompute_register_parameters): Don't convert
+   pointer to TLS symbol if needed.
+
+   * combine.c (cant_combine_insn_p): Check zero/sign extended
+   hard registers.
+
+   * config/i386/i386.c (ix86_promote_function_mode): Removed.
+   (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
+
 2011-06-15  H.J. Lu  
 
PR middle-end/48016
diff --git a/gcc/calls.c b/gcc/calls.c
index 5a00d95..3d9a03f 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -706,13 +706,7 @@ precompute_register_parameters (int num_actuals, struct 
arg_data *args,
   pseudo now.  TLS symbols sometimes need a call to resolve.  */
if (CONSTANT_P (args[i].value)
&& !targetm.legitimate_constant_p (args[i].mode, args[i].value))
- {
-   if (GET_MODE (args[i].value) != args[i].mode)
- args[i].value = convert_to_mode (args[i].mode,
-  args[i].value,
-  args[i].unsignedp);
-   args[i].value = force_reg (args[i].mode, args[i].value);
- }
+ args[i].value = force_reg (args[i].mode, args[i].value);
 
/* If we are to promote the function arg to a wider mode,
   do it now.  */
diff --git a/gcc/combine.c b/gcc/combine.c
index d3574a3..5512649 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -2168,6 +2168,12 @@ cant_combine_insn_p (rtx insn)
 return 0;
   src = SET_SRC (set);
   dest = SET_DEST (set);
+  if (GET_CODE (src) == ZERO_EXTEND
+  || GET_CODE (src) == SIGN_EXTEND)
+src = XEXP (src, 0);
+  if (GET_CODE (dest) == ZERO_EXTEND
+  || GET_CODE (dest) == SIGN_EXTEND)
+dest = XEXP (dest, 0);
   if (GET_CODE (src) == SUBREG)
 src = SUBREG_REG (src);
   if (GET_CODE (dest) == SUBREG)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index fa5ae97..104767b 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7050,23 +7050,6 @@ ix86_function_value (const_tree valtype, const_tree 
fntype_or_decl,
   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
 }
 
-/* Pointer function arguments and return values are promoted to
-   Pmode.  */
-
-static enum machine_mode
-ix86_promote_function_mode (const_tree type, enum machine_mode mode,
-   int *punsignedp, const_tree fntype,
-   int for_return)
-{
-  if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type))
-{
-  *punsignedp = POINTERS_EXTEND_UNSIGNED;
-  return Pmode;
-}
-  return default_promote_function_mode (type, mode, punsignedp, fntype,
-   for_return);
-}
-
 rtx
 ix86_libcall_value (enum machine_mode mode)
 {
@@ -35132,9 +35115,6 @@ ix86_autovectorize_vector_sizes (void)
 #undef TARGET_FUNCTION_VALUE_REGNO_P
 #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p
 
-#undef TARGET_PROMOTE_FUNCTION_MODE
-#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
-
 #undef TARGET_SECONDARY_RELOAD
 #define TARGET_SECONDARY_RELOAD ix86_secondary_reload
 

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Mike Stump]

On Jun 20, 2011, at 6:41 AM, Rainer Orth wrote:
> Christian Bruel  writes:
> 
>> 2011-06-16  Christian Bruel  
>>  
>>  PR 49139/43654
> 
> Please use the correct PR number format here:
> 
>   PR middle-end/49139
>PR middle-end/43654
> 
> Otherwise the check-in notices don't get into the PRs.

Also, I think there is a preference to pick the best bug report to make this a 
fix for, and list just one number, and then close the second as a dup of the 
first, after the first is fixed.

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Richard Guenther]

On Mon, Jun 20, 2011 at 3:32 PM, Christian Bruel  wrote:
> In addition to the approved part of the patch, I finally got the testsuite
> and a full Linux distribution to build without false warnings, with the
> additional following changes:
>
> * two false warnings detected during a Linux distrib rebuild
>
>  - __typeof (__error) doesn't propagate the inline keyword. even if the
> function had attribute always_inline.
>  - extern inline function redefinition would inherit the attribute, even if
> they are not inline
>
>  DECL_UNINLINABLE is set for redefining extern inline functions. (commented
> in c-decl.c:2340). So indeed testing this flags in the cgraphunit.c part
> fixed both.
>  I checked that this doesn't conflict with other DECL_UNINLINABLE warning
> emitted from ree_inlinable_function_p. (which is called after)
>
> * One silent bug revealed, undetected in the GCC testuite:
>
>  - PR43564.c compiled in -O0, the "__clz" function was silently not inlined.
> Fixed in ipa-inline.c:inline_forbidden_p_stmt

-  if ((caller_opt->x_optimize > callee_opt->x_optimize)
- || (caller_opt->x_optimize_size != callee_opt->x_optimize_size))
+  if (((caller_opt->x_optimize > callee_opt->x_optimize)
+  || (caller_opt->x_optimize_size != callee_opt->x_optimize_size))
+ /* gcc.dg/pr43564.c.  look at forced inline even in -O0.  */
+ && !lookup_attribute ("always_inline", DECL_ATTRIBUTES 
(e->callee->decl)))

please check DECL_DISREGARD_INLINE_LIMITS instead.

> * LTO pitfall: It's OK to not have a body to inline when generating the LTO
> Gimple. Enforced by PR20090218-1_0.c

I'm not 100% sure here ;)  At least as we still output a regular object
file without the function being inlined.  But as we're going towars
slim-LTO (hopefully) I guess it's ok.

> * In addition to the parts of the patch that was approved, I had to fix the
> tests that didn't use the inline keyword but enforced the always_inline
> attribute to pass without the warning
>  I choose to add -Wno-attributes to the option list. Could as well fix the
> test by adding the inline keyword, but I preferred to not modify the
> original test when possible.
>
> * A minor code optimization in ipa-inline-transform.c: Don't call
> optimize_inline_calls if there is not callee.
>
> Comments, OK to apply ?

Ok with the above change and the PRs mentioned in the changelog
properly (see Rainers comment).

Thanks,
Richard.

> Many thanks
>
> Christian
>
> 2011-06-16  Christian Bruel  
>
>        PR 49139/43654
>        * cgraphunit.c (process_function_and_variable_attributes): warn
>        for always_inline functions that are not inline.
>        * ipa-inline-transform.c (inline_transform): Always call
>        optimize_inline.
>        * ipa-inline.c (can_inline_edge_p): Check always_inline.
>        * tree-inline.c (tree_inlinable_function_p): Call error instead
>        of sorry.
>        (expand_call_inline): Likewise.
>
> 2011-06-16  Christian Bruel  
>
>        * gcc.dg/always_inline.c: Removed -Winline. Update checks
>        * gcc.dg/always_inline2.c: Likewise.
>        * gcc.dg/always_inline3.c: Likewise.
>        * gcc.dg/debug/pr41264-1.c: Add -Wno-attributes.
>        * gcc.dg/inline_1.c: Likewise.
>        * gcc.dg/inline_2.c: Likewise.
>        * gcc.dg/inline_3.c: Likewise.
>        * gcc.dg/inline_4.c: Likewise.
>        * gcc.dg/20051201-1.c: Likewise.
>        * gcc.dg/torture/pta-structcopy-1.c: Likewise.
>        * gcc.dg/inline-22.c: Likewise.
>        * gcc.dg/lto/20090218-1_0.c: Set inline keyword.
>        * gcc.dg/lto/20090218-1_1.c: Likewise.
>        * g++.dg/ipa/devirt-7.C: Likewise.
>        * gcc.dg/uninit-pred-5_a.c: Likewise.
>        * gcc.dg/uninit-pred-5_b.c: Likewise.
>        * gcc.dg/fail_always_inline.c: New.
>

[Patch, AVR]: Fix PR34734

[Georg-Johann Lay]

PR34734 produces annoying, false warnings if __attribute__((progmem))
is used in conjunction with C++.  DECL_INITIAL is not yet set up in
avr_handle_progmem_attribute.

Johann

PR target/34734
* config/avr/avr.c (avr_handle_progmem_attribute): Move warning
about uninitialized data attributed 'progmem' from here...
(avr_encode_section_info): ...to this new function.
(TARGET_ENCODE_SECTION_INFO): New define.
(avr_section_type_flags): For data in ".progmem.data", remove
section flag SECTION_WRITE.
Index: config/avr/avr.c
===
--- config/avr/avr.c	(revision 175201)
+++ config/avr/avr.c	(working copy)
@@ -109,6 +109,7 @@ static void avr_function_arg_advance (cu
 static void avr_help (void);
 static bool avr_function_ok_for_sibcall (tree, tree);
 static void avr_asm_named_section (const char *name, unsigned int flags, tree decl);
+static void avr_encode_section_info (tree, rtx, int);
 
 /* Allocate registers from r25 to r8 for parameters for function calls.  */
 #define FIRST_CUM_REG 26
@@ -200,6 +201,8 @@ static const struct attribute_spec avr_a
 
 #undef TARGET_ASM_INIT_SECTIONS
 #define TARGET_ASM_INIT_SECTIONS avr_asm_init_sections
+#undef TARGET_ENCODE_SECTION_INFO
+#define TARGET_ENCODE_SECTION_INFO avr_encode_section_info
 
 #undef TARGET_REGISTER_MOVE_COST
 #define TARGET_REGISTER_MOVE_COST avr_register_move_cost
@@ -5088,12 +5091,7 @@ avr_handle_progmem_attribute (tree *node
 	}
   else if (TREE_STATIC (*node) || DECL_EXTERNAL (*node))
 	{
-	  if (DECL_INITIAL (*node) == NULL_TREE && !DECL_EXTERNAL (*node))
-	{
-	  warning (0, "only initialized variables can be placed into "
-		   "program memory area");
-	  *no_add_attrs = true;
-	}
+  *no_add_attrs = false;
 	}
   else
 	{
@@ -5308,10 +5306,35 @@ avr_section_type_flags (tree decl, const
 		 ".noinit section");
 }
 
+  if (0 == strncmp (name, ".progmem.data", strlen (".progmem.data")))
+flags &= ~SECTION_WRITE;
+  
   return flags;
 }
 
 
+/* Implement `TARGET_ENCODE_SECTION_INFO'.  */
+
+static void
+avr_encode_section_info (tree decl, rtx rtl ATTRIBUTE_UNUSED,
+ int new_decl_p)
+{
+  /* In avr_handle_progmem_attribute, DECL_INITIAL is not yet
+ readily available, see PR34734.  So we postpone the warning
+ about uninitialized data in program memory section until here.  */
+   
+  if (new_decl_p
+  && decl && DECL_P (decl)
+  && NULL_TREE == DECL_INITIAL (decl)
+  && avr_progmem_p (decl, DECL_ATTRIBUTES (decl)))
+{
+  warning (OPT_Wuninitialized,
+   "uninitialized variable %q+D put into "
+   "program memory area", decl);
+}
+}
+
+
 /* Implement `TARGET_ASM_FILE_START'.  */
 /* Outputs some appropriate text to go at the start of an assembler
file.  */

[patch, 4.6/4.7] fix installation of plugin header files

[Matthias Klose]

Two issues with the installation of plugin header files.

 - the c-family/* headers are used with the the c-family/ prefix
   in include directives. therefore they must not installed into
   the flattened plugin include dir, but kept in the subdir.

 - PR45078; vxworks-dummy.h is included for cpu_type in arm,
   i386, mips, sh and sparc but only installed when it's i386; copy it
   manually anytime.

Ok for the trunk and the 4.6 branch?

  Matthias

	PR plugin/45078
	* Makefile.in (PLUGIN_HEADERS): Add config/arm/arm-cores.def,
	config/vxworks-dummy.h.
	(install-plugin): Install c-family headers into a c-family subdir.

--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -4503,6 +4503,7 @@
   $(EXCEPT_H) tree-ssa-sccvn.h real.h output.h $(IPA_UTILS_H) \
   $(C_PRAGMA_H)  $(CPPLIB_H)  $(FUNCTION_H) \
   cppdefault.h flags.h $(MD5_H) params.def params.h prefix.h tree-inline.h \
+  config/arm/arm-cores.def config/vxworks-dummy.h \
   $(IPA_PROP_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) version.h
 
 # generate the 'build fragment' b-header-vars
@@ -4527,7 +4528,7 @@
 	  else continue; \
 	  fi; \
 	  case $$path in \
-	  "$(srcdir)"/config/* | "$(srcdir)"/*.def ) \
+	  "$(srcdir)"/config/* | "$(srcdir)"/c-family/* | "$(srcdir)"/*.def ) \
 	base=`echo "$$path" | sed -e "s|$$srcdirstrip/||"`;; \
 	  *) base=`basename $$path` ;; \
 	  esac; \

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Rainer Orth]

Christian Bruel  writes:

> 2011-06-16  Christian Bruel  
>   
>   PR 49139/43654

Please use the correct PR number format here:

PR middle-end/49139
PR middle-end/43654

Otherwise the check-in notices don't get into the PRs.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH][RFC][1/2] Bitfield lowering, add BIT_FIELD_EXPR

[Michael Matz]

Hi,

On Sun, 19 Jun 2011, William J. Schmidt wrote:

> At the risk of being obvious...it seems you could easily combine C1 and 
> C2 into a single "bitfield descriptor" TREE_INT_CST operand by using 
> both the high and low portions of the constant.  Accessor macros could 
> be used to hide the slight hackishness of the solution.  I didn't see 
> anything in either patch where this would look particularly ugly.

Agreed.  I don't even see it as hackish, it's quite normal that the 
implementation of data structures actually uses a different layout than a 
completely orthogonal one.  As long as the accessors are looking 
orthogonal.


Ciao,
Michael.