[PATCH] Fix PR49603

[Richard Guenther]

This fixes PR49603.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2011-07-01  Richard Guenther  

PR tree-optimization/49603
* tree-vect-stmts.c (vectorizable_load): Remove unnecessary
assert.

* gcc.dg/torture/pr49603.c: New testcase.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 175709)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -4574,19 +4574,14 @@ vectorizable_load (gimple stmt, gimple_s
  /* 4. Handle invariant-load.  */
  if (inv_p && !bb_vinfo)
{
+ tree vec_inv;
+ gimple_stmt_iterator gsi2 = *gsi;
  gcc_assert (!strided_load);
- if (j == 0)
-   {
- tree vec_inv;
- gimple_stmt_iterator gsi2 = *gsi;
- gsi_next (&gsi2);
- vec_inv = build_vector_from_val (vectype, scalar_dest);
- new_temp = vect_init_vector (stmt, vec_inv,
-  vectype, &gsi2);
- new_stmt = SSA_NAME_DEF_STMT (new_temp);
-   }
- else
-   gcc_unreachable (); /* FORNOW. */
+ gsi_next (&gsi2);
+ vec_inv = build_vector_from_val (vectype, scalar_dest);
+ new_temp = vect_init_vector (stmt, vec_inv,
+  vectype, &gsi2);
+ new_stmt = SSA_NAME_DEF_STMT (new_temp);
}
 
  if (negative)
Index: gcc/testsuite/gcc.dg/torture/pr49603.c
===
--- gcc/testsuite/gcc.dg/torture/pr49603.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr49603.c  (revision 0)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+
+struct gl_visual {
+float AlphaScale;
+};
+struct gl_context {
+struct gl_visual *Visual;
+};
+void quickdraw_rgb( struct gl_context * ctx,
+   int width, int height)
+{
+  int i, j;
+  unsigned char alpha[1600];
+  for (j=0; jVisual->AlphaScale; 
+  for (i=0; i

Re: C++ PATCH for c++/49418 (lost cv-quals on template parameter type)

[Kirill Yukhin]

Hi Jason,
I've had looked into the problem and I believe, that problem is
somehow connected to FE.
Moreover, it is really look like that it is connected to
array-to-pointer conversion.

I put lots of details in the bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

Here is very short description:
C++ code looks like this:
include/base/thread_management.h:
template 
static inline void do_call (PFun fun_ptr,
C   &obj,
ArgList &arg_list,
internal::return_value &ret_val,
const int2type<4> &)
  {
ret_val.set ((obj.*fun_ptr) (arg_list.template get<0>(),
 arg_list.template get<1>(),
 arg_list.template get<2>(),
 arg_list.template get<3>()));

While after "einline" phase it becomes:
  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167199_17 =
MEM[(struct cons &)arg_list_2(D) + 12].head;
  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167198_18 =
MEM[(struct cons &)arg_list_2(D) + 8].head;
  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167197_19 =
MEM[(struct cons &)arg_list_2(D) + 4].head;
  [step-14.cc : 4271:1] D.167196_20 = MEM[(struct cons &)arg_list_2(D)];
  [include/base/thread_management.h : 1534:13] D.167205_21 =
(sizetype)fun_ptr$__delta_7;
  [include/base/thread_management.h : 1534:13] D.167204_22 = obj_1(D)
+D.167205_21;
  [include/base/thread_management.h : 1534:13] iftmp.53_23
(D.167204_22,D.167196_20, D.167197_19, D.167198_18, D.167199_17);
  [include/base/thread_management.h : 1826:5] return;

Could you please prompt me if this is a correct code? I believe - not

Thanks, K


On Fri, Jun 24, 2011 at 8:23 AM, H.J. Lu  wrote:
> On Thu, Jun 23, 2011 at 8:07 PM, H.J. Lu  wrote:
>> On Thu, Jun 23, 2011 at 7:18 PM, Jason Merrill  wrote:
>>> On 06/23/2011 08:45 PM, H.J. Lu wrote:

 This caused:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
>>>
>>> I'm checking this in as an alternate fix.  Testing hasn't completed yet, but
>>> I'm confident that this version is safe.
>>>
>>
>> I still got the same failure with revision 175368.  The problem is caused by
>> the "While looking at this, I've also changed a few more TYPE_MAIN_VARIANTs
>> to cv_unqualified" change in
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01622.html
>
> Revert this patch:
>
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 4d2caa8..2716f78 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -10246,7 +10246,7 @@ tsubst_arg_types (tree arg_types,
>
>     /* Do array-to-pointer, function-to-pointer conversion, and ignore
>        top-level qualifiers as required.  */
> -    type = TYPE_MAIN_VARIANT (type_decays_to (type));
> +    type = cv_unqualified (type_decays_to (type));
>
>     /* We do not substitute into default arguments here.  The standard
>        mandates that they be instantiated only when needed, which is
>
> seems to fix the crash.
>
> --
> H.J.
>

Re: [PATCH] Handle vectorization of invariant loads (PR46787)

[H.J. Lu]

On Thu, Jun 30, 2011 at 8:24 AM, Richard Guenther  wrote:
> On Wed, 29 Jun 2011, Richard Guenther wrote:
>
>>
>> The following patch makes us handle invariant loads during vectorization.
>> Dependence analysis currently isn't clever enough to disambiguate them
>> thus we insert versioning-for-alias checks.  For the testcase hoisting
>> the load is still always possible though, and for a read-after-write
>> dependence it would be possible for the vectorized loop copy as the
>> may-aliasing write is varying by the scalar variable size.
>>
>> The existing code for vectorizing invariant accesses looks very
>> suspicious - it generates a vector load at the scalar address
>> to then just extract the first vector element.  Huh.  IMHO this
>> can be simplified as done, by just re-using the scalar load result.
>> But maybe this code was supposed to deal with something entirely
>> different?
>>
>> This patch gives a 33% speedup to the phoronix himeno testcase
>> if you bump the maximum alias versioning checks we want to insert.
>>
>> I'm currently re-bootstrapping & testing this but an earlier version
>> was ok on x86_64-unknown-linux-gnu.
>
> FYI, I'm testing the following which cures a fallout seen when
> building SPEC2k6 with the committed patch.  It's suboptimal for
> j != 0 though - is there a way to get to the vectorized stmt
> of the j == 0 iteration?
>
> Thanks,
> Richard.
>
> 2011-06-30  Richard Guenther  
>
>        * tree-vect-stmts.c (vectorizable_load): Remove unnecessary
>        assert.
>

Will this fix

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


-- 
H.J.

Re: [pph] Stream first/weak_object_global_name (issue4641086)

[Gabriel Charette]

notice_global_symbol is actually called in the parser (before we stream out).

I just confirmed this by setting a break point on the function in the
pph generation of c1varoder.pph and hitting the function twice for the
two variables defined in c1varorder.h

It looks like rtl and assembler_name are set BEFORE we stream out...
so that we would need to stream them (looks like assembler_name is
already streamed, but not rtl...).

Not streaming rtl causes it to be recreated later (which i think might
be the cause of the bad ordering).

Now another problem is that when two pph are generated, they are not
aware of each other (and of their respective
first/weak_global_object_name...) so even if we stream those
variables, their could still be conflicts (and/or asm diffs..)

However, I'm not sure about how make_decl_rtl works, but if it can
regenerate the same rtl we had before (and even potentially solve the
conflicts mentioned in the previous paragraph), we may not need to
actually stream the rtl, we would just need to fix the ordering as the
pph rtl's are being regenerated.

(they are regenerated because DECL_RTL(NODE) either returns
(NODE)->decl_with_rtl.rtl or calls make_decl_rtl(NODE) if it's
NULL...)

If we do this, I think we wanna have the first/weak_object_global_name
set to what it should be by streaming it in from the first pph, to
ensure all the rtl and assembler_name choices are made correctly (I'm
not sure I understand all of this, but it seems to rely on those
fields).

Gab

On Thu, Jun 30, 2011 at 4:33 PM, Diego Novillo  wrote:
> On Thu, Jun 30, 2011 at 16:24, Gabriel Charette  wrote:
>> first/weak_global_object_name are part of the global state.
>>
>> This seems to be used to produce the assembler names. They are set only once 
>> as early as possible in the parsing; thus we should define it to be whatever 
>> it was in the first pph (or even in the C file if it was set before any pph 
>> was even loaded.
>>
>> I'm not sure exactly what this does, but trying to find a fix for the asm 
>> diffs this is the first thing that I hit in the compiler logic that was 
>> different in the good compiler vs the pph compiler. With this fix this bit 
>> of logic is now correct.
>> However, this doesn't fix any pph test (nor does it even change any pph asm 
>> (I diff'ed the old bad assemblies (*.s+pph) with the new ones)).
>
> This does not look right to me.  These two symbols are set when
> calling notice_global_symbol, which is done during code generation
> (you will see it called from cgraph_finalize_function,
> cgraph_mark_reachable_node, etc).
>
> You are probably close to the cause of this relative ordering problem,
> but streaming these two globals is not the solution.  They both should
> be set in the same order by both compilers, but not by forcing them
> this way.
>
> One thing that may be happening here is that the order in which we
> call cgraph_finalize_function is different in the two compilers.
> That's what needs to change.  One thing you could do is set a
> breakpoint in notice_global_symbol.  The two compilers should be
> calling it in the same order.
>
>
> Diego.
>

C++ PATCH for c++/49387 (strange error with typeid)

[Jason Merrill]

Here we were winding up in get_tinfo_decl with a template type that was 
still incomplete because nothing else had required it to be complete. 
So we initially decide to treat it as a class with no bases.  But then 
the process of creating the initializer for the type_info node causes 
the type to be complete, so we generate an initializer for a class with 
bases, which doesn't match the type we already gave it.


Fixed by instantiating the type in get_tinfo_decl.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9e18be69b4b6177e94597a20b43ff42f8e8f33bb
Author: Jason Merrill 
Date:   Thu Jun 30 18:52:18 2011 -0400

	PR c++/49387
	* rtti.c (get_pseudo_ti_index): Call complete_type.

diff --git a/gcc/cp/rtti.c b/gcc/cp/rtti.c
index 0feaf07..53404b4 100644
--- a/gcc/cp/rtti.c
+++ b/gcc/cp/rtti.c
@@ -406,6 +406,8 @@ get_tinfo_decl (tree type)
 type = build_function_type (TREE_TYPE (type),
 TREE_CHAIN (TYPE_ARG_TYPES (type)));
 
+  type = complete_type (type);
+
   /* For a class type, the variable is cached in the type node
  itself.  */
   if (CLASS_TYPE_P (type))
diff --git a/gcc/testsuite/g++.dg/rtti/template1.C b/gcc/testsuite/g++.dg/rtti/template1.C
new file mode 100644
index 000..e2a0376
--- /dev/null
+++ b/gcc/testsuite/g++.dg/rtti/template1.C
@@ -0,0 +1,23 @@
+// PR c++/49387
+
+#include 
+
+struct ResourceMonitorClient { };
+
+template  struct ResourcePool : public ResourceMonitorClient {
+  virtual ~ResourcePool() { }
+};
+
+template  struct BaseWriter {
+
+  BaseWriter() {
+typeid(ResourcePool*);
+  }
+
+  virtual void run() {
+ResourcePool pool;
+  }
+
+};
+
+BaseWriter b;

Re: [PATCH,c++] mark EXPR_PACK_EXPANSION as typed only, v2

[Jason Merrill]

On 05/09/2011 07:41 PM, Nathan Froyd wrote:

I present the patch below.  We have a new function,
cp_tree_operand_length, and the code has been retrofitted to use it in
various places.


I've changed iterative_hash_template_arg to use it as well.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9a83e9c63ea02e71cfb9df81478a4aed98a58611
Author: Jason Merrill 
Date:   Thu Jun 30 18:35:10 2011 -0400

	* pt.c (iterative_hash_template_arg): Use cp_tree_operand_length.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc6cd50..4903044 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1609,7 +1609,7 @@ iterative_hash_template_arg (tree arg, hashval_t val)
 default:
   gcc_assert (IS_EXPR_CODE_CLASS (tclass));
   {
-	unsigned n = TREE_OPERAND_LENGTH (arg);
+	unsigned n = cp_tree_operand_length (arg);
 	for (i = 0; i < n; ++i)
 	  val = iterative_hash_template_arg (TREE_OPERAND (arg, i), val);
 	return val;

C++ PATCH for c++/49355 (ICE with new T({""}))

[Jason Merrill]

The problem here was that stabilize_init called from build_new_1 wasn't 
doing anything to stabilize the elements of a CONSTRUCTOR, so the 
allocator argument wasn't preevaluated, and due to the cleanup for the 
data pointer its cleanup wasn't associated with the CLEANUP_POINT_EXPR, 
leading to a crash.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5e42b54f626d5796ecb21ea2c78a7be2699a4c0a
Author: Jason Merrill 
Date:   Thu Jun 30 17:48:10 2011 -0400

	PR c++/49355
	* tree.c (stabilize_init): Handle aggregate initialization.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index c50751f..678c7ef 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3291,10 +3291,18 @@ stabilize_init (tree init, tree *initp)
 t = TARGET_EXPR_INITIAL (t);
   if (TREE_CODE (t) == COMPOUND_EXPR)
 t = expr_last (t);
-  if (TREE_CODE (t) == CONSTRUCTOR
-  && EMPTY_CONSTRUCTOR_P (t))
-/* Default-initialization.  */
-return true;
+  if (TREE_CODE (t) == CONSTRUCTOR)
+{
+  /* Aggregate initialization: stabilize each of the field
+	 initializers.  */
+  unsigned i;
+  tree value;
+  bool good = true;
+  FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (t), i, value)
+	if (!stabilize_init (value, initp))
+	  good = false;
+  return good;
+}
 
   /* If the initializer is a COND_EXPR, we can't preevaluate
  anything.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist54.C b/gcc/testsuite/g++.dg/cpp0x/initlist54.C
new file mode 100644
index 000..cdb2961
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist54.C
@@ -0,0 +1,13 @@
+// PR c++/49355
+// { dg-options -std=c++0x }
+
+#include 
+
+struct T {
+  std::string foobar;
+};
+
+int main()
+{
+  T* x = new T({""});
+}

C++ PATCH for c++/49569 (ICE with implicitly-declared copy constructor)

[Jason Merrill]

If we aren't setting DECL_ARTIFICIAL on the rhs parm of an 
implicitly-declared copy constructor, we need to set DECL_PARM_INDEX for 
the sake of the constexpr expander.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit eae21fea450d9fa1b9fce0544db5cf7fdce8f022
Author: Jason Merrill 
Date:   Thu Jun 30 18:35:25 2011 -0400

	PR c++/49569
	* method.c (implicitly_declare_fn): Set DECL_PARM_LEVEL and
	DECL_PARM_INDEX on rhs parm.

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index f10e846..9b9eb9a 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1528,8 +1528,11 @@ implicitly_declare_fn (special_function_kind kind, tree type, bool const_p)
   /* Note that this parameter is *not* marked DECL_ARTIFICIAL; we
 	 want its type to be included in the mangled function
 	 name.  */
-  DECL_ARGUMENTS (fn) = cp_build_parm_decl (NULL_TREE, rhs_parm_type);
-  TREE_READONLY (DECL_ARGUMENTS (fn)) = 1;
+  tree decl = cp_build_parm_decl (NULL_TREE, rhs_parm_type);
+  TREE_READONLY (decl) = 1;
+  retrofit_lang_decl (decl);
+  DECL_PARM_INDEX (decl) = DECL_PARM_LEVEL (decl) = 1;
+  DECL_ARGUMENTS (fn) = decl;
 }
   /* Add the "this" parameter.  */
   this_parm = build_this_parm (fn_type, TYPE_UNQUALIFIED);
diff --git a/gcc/testsuite/g++.dg/cpp0x/regress/ctor1.C b/gcc/testsuite/g++.dg/cpp0x/regress/ctor1.C
new file mode 100644
index 000..c35d601
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/regress/ctor1.C
@@ -0,0 +1,21 @@
+// PR c++/49569
+// { dg-options -std=c++0x }
+
+struct A
+{
+  virtual void f() = 0;
+};
+
+struct B: A
+{
+  int i;
+  virtual void f() { }
+};
+
+struct C
+{
+  B b;
+  C(): b() { }
+  C(const B& b): b(b) { }
+};
+

Re: [pph] Stream first/weak_object_global_name (issue4641086)

[Diego Novillo]

On Thu, Jun 30, 2011 at 16:24, Gabriel Charette  wrote:
> first/weak_global_object_name are part of the global state.
>
> This seems to be used to produce the assembler names. They are set only once 
> as early as possible in the parsing; thus we should define it to be whatever 
> it was in the first pph (or even in the C file if it was set before any pph 
> was even loaded.
>
> I'm not sure exactly what this does, but trying to find a fix for the asm 
> diffs this is the first thing that I hit in the compiler logic that was 
> different in the good compiler vs the pph compiler. With this fix this bit of 
> logic is now correct.
> However, this doesn't fix any pph test (nor does it even change any pph asm 
> (I diff'ed the old bad assemblies (*.s+pph) with the new ones)).

This does not look right to me.  These two symbols are set when
calling notice_global_symbol, which is done during code generation
(you will see it called from cgraph_finalize_function,
cgraph_mark_reachable_node, etc).

You are probably close to the cause of this relative ordering problem,
but streaming these two globals is not the solution.  They both should
be set in the same order by both compilers, but not by forcing them
this way.

One thing that may be happening here is that the order in which we
call cgraph_finalize_function is different in the two compilers.
That's what needs to change.  One thing you could do is set a
breakpoint in notice_global_symbol.  The two compilers should be
calling it in the same order.


Diego.

PATCH: PR target/49600: Bad SSE2 int->float split in i386.md

[H.J. Lu]

In one SSE2 int->float split, when TARGET_USE_VECTOR_CONVERTS is true,
TARGET_INTER_UNIT_MOVES is false and GENERAL_REG_P (op1) is true. we
will get gcc_unreachable.  This patch removes TARGET_INTER_UNIT_MOVES
check.  OK for trunk?

Thanks.


H.J.
---
2011-06-30  H.J. Lu  

PR target/49600
* config/i386/i386.md (SSE2 int->float split): Don't check
TARGET_INTER_UNIT_MOVES.

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index e4b96bc..96bdfbb 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -5022,7 +5022,7 @@
   if (GET_CODE (op1) == SUBREG)
 op1 = SUBREG_REG (op1);
 
-  if (GENERAL_REG_P (op1) && TARGET_INTER_UNIT_MOVES)
+  if (GENERAL_REG_P (op1))
 {
   operands[4] = simplify_gen_subreg (V4SImode, operands[0], mode, 0);
   emit_insn (gen_sse2_loadld (operands[4],

Remove config.gcc support for *local* configurations

[Joseph S. Myers]

config.gcc has special handling of triplets matching "*local*".  I
don't think this is particularly relevant to how GCC is used and built
today; a good GCC port is expected to include many pieces in different
places that are not covered by this generic code, and adding a
config.gcc stanza is one of the easiest parts of adding a port.  Thus,
this patch removes that code.

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
commit?

gcc:
2011-06-30  Joseph Myers  

* config.gcc (*local*): Remove.
* doc/install-old.texi: Don't mention local configurations.

libgcc:
2011-06-30  Joseph Myers  

* config.host (*local*): Remove.

Index: libgcc/config.host
===
--- libgcc/config.host  (revision 175628)
+++ libgcc/config.host  (working copy)
@@ -222,13 +222,6 @@
 esac
 
 case ${host} in
-# Support site-specific machine types.
-*local*)
-   rest=`echo ${host} | sed -e "s/$cpu_type-//"`
-   if test -f $srcdir/config/${cpu_type}/t-$rest
-   then tmake_file=${cpu_type}/t-$rest
-   fi
-   ;;
 alpha*-*-linux*)
tmake_file="${tmake_file} alpha/t-crtfm"
extra_parts="$extra_parts crtfastmath.o"
Index: gcc/doc/install-old.texi
===
--- gcc/doc/install-old.texi(revision 175628)
+++ gcc/doc/install-old.texi(working copy)
@@ -183,13 +183,3 @@
 @noindent
 Remember that a machine name specifies both the cpu type and the company
 name.
-If you want to install your own homemade configuration files, you can
-use @samp{local} as the company name to access them.  If you use
-configuration @samp{@var{cpu}-local}, the configuration name
-without the cpu prefix
-is used to form the configuration file names.
-
-Thus, if you specify @samp{m68k-local}, configuration uses
-files @file{m68k.md}, @file{local.h}, @file{m68k.c},
-@file{xm-local.h}, @file{t-local}, and @file{x-local}, all in the
-directory @file{config/m68k}.
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 175628)
+++ gcc/config.gcc  (working copy)
@@ -749,17 +749,6 @@
 esac
 
 case ${target} in
-# Support site-specific machine types.
-*local*)
-   rest=`echo ${target} | sed -e "s/$cpu_type-//"`
-   tm_file=${cpu_type}/$rest.h
-   if test -f $srcdir/config/${cpu_type}/xm-$rest.h
-   then xm_file=${cpu_type}/xm-$rest.h
-   fi
-   if test -f $srcdir/config/${cpu_type}/t-$rest
-   then tmake_file=${cpu_type}/t-$rest
-   fi
-   ;;
 alpha*-*-linux*)
tm_file="${tm_file} alpha/elf.h alpha/linux.h alpha/linux-elf.h 
glibc-stdint.h"
extra_options="${extra_options} alpha/elf.opt"

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

Re: [PATCH, SRA] Total scalarization and padding

[Martin Jambor]

Hi,

On Wed, Jun 29, 2011 at 02:52:36PM +0200, Richard Guenther wrote:
> On Tue, 28 Jun 2011, Martin Jambor wrote:
> > On Tue, Jun 28, 2011 at 03:01:17PM +0200, Richard Guenther wrote:
> > > On Tue, Jun 28, 2011 at 2:50 PM, Martin Jambor  wrote:
> > > > Hi,
> > > >
> > > > at the moment SRA can get confused by alignment padding and think that
> > > > it actually contains some data for which there is no planned
> > > > replacement and thus might leave some loads and stores in place
> > > > instead of removing them.  This is perhaps the biggest problem when we
> > > > attempt total scalarization of simple structures exactly in order to
> > > > get rid of these and of the variables altogether.
> > > >
> > > > I've pondered for quite a while how to best deal with them.  One
> > > > option was to make just the total scalarization stronger.  I have also
> > > > contemplated creating phantom accesses for padding I could detect
> > > > (i.e. in simple structures) which would be more general, but this
> > > > would complicate the parts of SRA which are already quite convoluted
> > > > and I was not really sure it was worth it.
> > > >
> > > > Eventually I decided for the total scalarization option.  This patch
> > > > changes it such that the flag is propagated down the access tree but
> > > > also, if it does not work out, is reset on the way up.  If the flag
> > > > survives, the access tree is considered "covered" by scalar
> > > > replacements and thus it is known not to contain unscalarized data.
> > > >
> > > > While changing function analyze_access_subtree I have simplified the
> > > > way we compute the hole flag and also fixed one comparison which we
> > > > currently have the wrong way round but it fortunately does not matter
> > > > because if there is a hole, the covered_to will never add up to the
> > > > total size.  I'll probably post a separate patch against 4.6 just in
> > > > case someone attempts to read the source.
> > > >
> > > > Bootstrapped and tested on x86_64-linux, OK for trunk?
> > > 
> > > So, what will it do for the testcase?
> > > 
> > > The following is what I _think_ it should do:
> > > 
> > > :
> > >   l = *p_1(D);
> > >   l$i_6 = p_1(D)->i;
> > >   D.2700_2 = l$i_6;
> > >   D.2701_3 = D.2700_2 + 1;
> > >   l$i_12 = D.2701_3;
> > >   *p_1(D) = l;
> > >   p_1(D)->i = l$i_12;
> > > 
> > > and let FRE/DSE do their job (which they don't do, unfortunately).
> > > So does your patch then remove the load/store from/to l but keep
> > > the elementwise loads/stores (which are probably cleaned up by FRE)?
> > > 
> > 
> > Well, that is what would happen if no total scalarization was going
> > on.  Total scalarization is a poor-man's aggregate copy-propagation by
> > splitting up small structures to individual fields whenever we can get
> > rid of them this way (i.e. if they are never used in a non-assignment)
> > which I introduced to fix PR 42585 - but unfortunately the padding
> > problem did not occur to me until this winter.
> > 
> > Currently, SRA performs very badly on the testcase, creating:
> > 
> > :
> >   l = *p_1(D);
> >   l$i_6 = p_1(D)->i;
> >   l$f1_8 = p_1(D)->f1;
> >   l$f2_9 = p_1(D)->f2;
> >   l$f3_10 = p_1(D)->f3;
> >   l$f4_11 = p_1(D)->f4;
> >   D.1966_2 = l$i_6;
> >   D.1967_3 = D.1966_2 + 1;
> >   l$i_12 = D.1967_3;
> >   *p_1(D) = l;  <-- this should not be here
> >   p_1(D)->i = l$i_12;
> >   p_1(D)->f1 = l$f1_8;
> >   p_1(D)->f2 = l$f2_9;
> >   p_1(D)->f3 = l$f3_10;
> >   p_1(D)->f4 = l$f4_11;
> >   return;
> > 
> > Unfortunately, this basically survives all the way to the "optimized"
> > dump.  With the patch, the assignment *p_1(D) = l; is removed and
> > copyprop1 and cddce1 turn this into:
> > 
> > :
> >   l$i_6 = p_1(D)->i;
> >   D.1967_3 = l$i_6 + 1;
> >   p_1(D)->i = D.1967_3;
> >   return;
> > 
> > which is then the "optimized" gimple, already before IPA and at -O1.
> 
> Ok, that's certainly better.  Can you file a bugreport for the FRE/DSE
> issue please?
> 
> > For the record, without total scalarization, the "optimized" gimple
> > would be:
> > 
> > :
> >   l = *p_1(D);
> >   l$i_6 = p_1(D)->i;
> >   D.1967_3 = l$i_6 + 1;
> >   *p_1(D) = l;
> >   p_1(D)->i = D.1967_3;
> >   return;
> > 
> > So at the moment FRE/DSE certainly does not help.  Eventually we
> > should do something like that or a real aggregate copy propagation but
> > until then we probably need to live with the total scalarization
> > thingy - I have learned in the PR mentioned above and a few others,
> > there are people who really want at least this functionality now - and
> > it should not perform this badly on unaligned structures.
> 
> The only thing I'm worried about is
> 
> struct X { int i; short s; pad p; int j; };
> struct Y { int i; short s; int j; };
> 
> int main()
> {
>   struct X x = { 1, 2, 3, 4 };
>   struct Y y = *(struct Y)&x;
>   y.s++;
>   *(struct Y)&x = y;
>   if (x->pad != 3)
> abort ();
>   return 0;
> }
> 
> untested, but any variant needs to make sur

Re: [testsuite, libmudflap] Only use --noinhibit-exec with GNU ld (PR libmudflap/49549)

[Mike Stump]

On Jun 30, 2011, at 10:26 AM, Rainer Orth wrote:
> Though I don't nominally need approval for this patch, I'll wait a day
> if Mike or Frank have comments.

Seems fine.

[PATCH] Use ira_reg_class_max_nregs array instead of CLASS_MAX_NREGS macro

[Anatoly Sokolov]

Hello.

  This patch replaces the use of macro CLASS_MAX_NREGS to reading from
ira_reg_class_max_nregs array. The ira_reg_class_max_nregs array is 
initialized from a macro CLASS_MAX_NREGS. This patch  should speed up the 
compiler, a little.

  The patch has been bootstrapped on and regression tested on
x86_64-unknown-linux-gnu for c.

  OK to install?

* ira.h (target_ira): Change type x_ira_reg_class_max_nregs and
x_ira_reg_class_min_nregs arrays to unsigned char.
* ira-conflicts.c (process_regs_for_copy): Use
ira_reg_class_max_nregs array instead of CLASS_MAX_NREGS macro.
Change type rclass and aclass vars to reg_class_t.
* ira-costs.c (record_reg_classes): Use ira_reg_class_max_nregs
array instead of CLASS_MAX_NREGS macro. Change type rclass var to
reg_class_t.
* reload.c (combine_reloads, find_reloads, find_reloads_address_1):
Use ira_reg_class_max_nregs array instead of CLASS_MAX_NREGS macro.

  The ira_reg_class_max_nregs array are using not only the IRA passes as well 
as in scheduling, loop invariant and now in reload passes. I propose to 
rename ira_reg_class_max_nregs and ira_reg_class_min_nregs array in 
reg_class_max_nregs and reg_class_min_nregs, move this declaration from ira.h 
to hard-reg-set.h and initialization from ira.c to reginfo.c. It will call the 
CLASS_MAX_NREGS macro only in one place the GCC. What is your opinion about 
these changes? 

Index: gcc/ira-conflicts.c
===
--- gcc/ira-conflicts.c (revision 175666)
+++ gcc/ira-conflicts.c (working copy)
@@ -393,7 +393,7 @@
   int allocno_preferenced_hard_regno, cost, index, offset1, offset2;
   bool only_regs_p;
   ira_allocno_t a;
-  enum reg_class rclass, aclass;
+  reg_class_t rclass, aclass;
   enum machine_mode mode;
   ira_copy_t cp;
 
@@ -438,7 +438,7 @@
   mode = ALLOCNO_MODE (a);
   aclass = ALLOCNO_CLASS (a);
   if (only_regs_p && insn != NULL_RTX
-  && reg_class_size[rclass] <= (unsigned) CLASS_MAX_NREGS (rclass, mode))
+  && reg_class_size[rclass] <= ira_reg_class_max_nregs [rclass][mode])
 /* It is already taken into account in ira-costs.c.  */
 return false;
   index = ira_class_hard_reg_index[aclass][allocno_preferenced_hard_regno];
Index: gcc/reload.c
===
--- gcc/reload.c(revision 175666)
+++ gcc/reload.c(working copy)
@@ -1769,9 +1769,9 @@
&& rld[i].when_needed != RELOAD_FOR_OUTPUT_ADDRESS
&& rld[i].when_needed != RELOAD_FOR_OUTADDR_ADDRESS
&& rld[i].when_needed != RELOAD_OTHER
-   && (CLASS_MAX_NREGS (rld[i].rclass, rld[i].inmode)
-   == CLASS_MAX_NREGS (rld[output_reload].rclass,
-   rld[output_reload].outmode))
+   && (ira_reg_class_max_nregs [(int) rld[i].rclass][(int) rld[i].inmode]
+   == ira_reg_class_max_nregs [(int) rld[output_reload].rclass]
+  [(int) rld[output_reload].outmode])
&& rld[i].inc == 0
&& rld[i].reg_rtx == 0
 #ifdef SECONDARY_MEMORY_NEEDED
@@ -4544,7 +4544,7 @@
   > GET_MODE_SIZE (rld[i].inmode)))
  ? rld[i].outmode : rld[i].inmode;
 
-  rld[i].nregs = CLASS_MAX_NREGS (rld[i].rclass, rld[i].mode);
+  rld[i].nregs = ira_reg_class_max_nregs [rld[i].rclass][rld[i].mode];
 }
 
   /* Special case a simple move with an input reload and a
@@ -5994,8 +5994,8 @@
  else
{
  enum reg_class rclass = context_reg_class;
- if ((unsigned) CLASS_MAX_NREGS (rclass, GET_MODE (SUBREG_REG (x)))
- > reg_class_size[rclass])
+ if (ira_reg_class_max_nregs [rclass][GET_MODE (SUBREG_REG (x))]
+ > reg_class_size[(int) rclass])
{
  x = find_reloads_subreg_address (x, 0, opnum,
   ADDR_TYPE (type),
Index: gcc/ira.h
===
--- gcc/ira.h   (revision 175666)
+++ gcc/ira.h   (working copy)
@@ -68,8 +68,8 @@
   /* Maps: register class x machine mode -> maximal/minimal number of
  hard registers of given class needed to store value of given
  mode.  */
-  int x_ira_reg_class_max_nregs[N_REG_CLASSES][MAX_MACHINE_MODE];
-  int x_ira_reg_class_min_nregs[N_REG_CLASSES][MAX_MACHINE_MODE];
+  unsigned char x_ira_reg_class_max_nregs[N_REG_CLASSES][MAX_MACHINE_MODE];
+  unsigned char x_ira_reg_class_min_nregs[N_REG_CLASSES][MAX_MACHINE_MODE];
 
   /* Array analogous to target hook TARGET_MEMORY_MOVE_COST.  */
   short x_ira_memory_move_cost[MAX_MACHINE_MODE][N_REG_CLASSES][2];
Index: gcc/ira-costs.c
===
--- gcc/ira-costs.c (revision 175666)
+++ gcc/ira-costs.c (working copy)
@@ -930,15 +930,15 @@
  enum machine_mode mode = GET_MODE (op

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

C++ PATCH to avoid duplicate overload resolution (related to c++/48481)

[Jason Merrill]

While I was looking at 48481 a while back, I noticed that since Doug's 
change to implement DR 164, in a call subject to argument-dependent 
lookup we end up considering every function twice.  This patch avoids 
this by using a pointer set to remember which functions we already have 
in the overload set.  It cuts the compilation time for cases of extreme 
overloading (such as the 48481 testcase) by almost 50%, and has no 
noticeable effect on more normal code such as stdc++.h.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit c501c0ce3b749925475b8d3be0bc52843d37504d
Author: Jason Merrill 
Date:   Thu Jun 30 00:03:40 2011 -0400

	PR c++/48481
	* name-lookup.c (struct arg_lookup): Add fn_set.
	(add_function): Check it.
	(lookup_arg_dependent_1): Initialize it.

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 8bf5f5f..615e177 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -33,6 +33,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "debug.h"
 #include "c-family/c-pragma.h"
 #include "params.h"
+#include "pointer-set.h"
 
 /* The bindings for a particular name in a particular scope.  */
 
@@ -4864,6 +4865,7 @@ struct arg_lookup
   VEC(tree,gc) *namespaces;
   VEC(tree,gc) *classes;
   tree functions;
+  struct pointer_set_t *fn_set;
 };
 
 static bool arg_assoc (struct arg_lookup*, tree);
@@ -4883,16 +4885,11 @@ static bool arg_assoc_template_arg (struct arg_lookup*, tree);
 static bool
 add_function (struct arg_lookup *k, tree fn)
 {
-  /* We used to check here to see if the function was already in the list,
- but that's O(n^2), which is just too expensive for function lookup.
- Now we deal with the occasional duplicate in joust.  In doing this, we
- assume that the number of duplicates will be small compared to the
- total number of functions being compared, which should usually be the
- case.  */
-
   if (!is_overloaded_fn (fn))
 /* All names except those of (possibly overloaded) functions and
function templates are ignored.  */;
+  else if (k->fn_set && pointer_set_insert (k->fn_set, fn))
+/* It's already in the list.  */;
   else if (!k->functions)
 k->functions = fn;
   else if (fn == k->functions)
@@ -5346,6 +5343,23 @@ lookup_arg_dependent_1 (tree name, tree fns, VEC(tree,gc) *args,
  picking up later definitions) in the second stage. */
   k.namespaces = make_tree_vector ();
 
+  /* We used to allow duplicates and let joust discard them, but
+ since the above change for DR 164 we end up with duplicates of
+ all the functions found by unqualified lookup.  So keep track
+ of which ones we've seen.  */
+  if (fns)
+{
+  tree ovl;
+  /* We shouldn't be here if lookup found something other than
+	 namespace-scope functions.  */
+  gcc_assert (DECL_NAMESPACE_SCOPE_P (OVL_CURRENT (fns)));
+  k.fn_set = pointer_set_create ();
+  for (ovl = fns; ovl; ovl = OVL_NEXT (ovl))
+	pointer_set_insert (k.fn_set, OVL_CURRENT (ovl));
+}
+  else
+k.fn_set = NULL;
+
   if (include_std)
 arg_assoc_namespace (&k, std_node);
   arg_assoc_args_vec (&k, args);
@@ -5363,6 +5377,8 @@ lookup_arg_dependent_1 (tree name, tree fns, VEC(tree,gc) *args,
 
   release_tree_vector (k.classes);
   release_tree_vector (k.namespaces);
+  if (k.fn_set)
+pointer_set_destroy (k.fn_set);
 
   return fns;
 }
diff --git a/gcc/testsuite/g++.dg/template/crash37.C b/gcc/testsuite/g++.dg/template/crash37.C
index 6072423..d5167c8 100644
--- a/gcc/testsuite/g++.dg/template/crash37.C
+++ b/gcc/testsuite/g++.dg/template/crash37.C
@@ -11,7 +11,7 @@ struct coperator_stack
 struct helper {};
 
 template
-void bla(F f) // { dg-message "bla|no known conversion" }
+void bla(F f)
 {
 }
 
@@ -20,8 +20,7 @@ struct definition
 {
  definition()
  {
-   bla(coperator_stack::push3); // { dg-error "matching" }
-   // { dg-message "candidate" "candidate note" { target *-*-* } 23 }
+   bla(coperator_stack::push3); // { dg-error "pointer to member" }
  }
 };
 
diff --git a/gcc/testsuite/g++.dg/template/ptrmem4.C b/gcc/testsuite/g++.dg/template/ptrmem4.C
index 62262c4..14f36d4 100644
--- a/gcc/testsuite/g++.dg/template/ptrmem4.C
+++ b/gcc/testsuite/g++.dg/template/ptrmem4.C
@@ -16,6 +16,5 @@ struct SpyExample
 
 void SpyExample::ready()
 {
-  queryAliases(inputs); // { dg-error "matching" }
-  // { dg-message "candidate" "candidate note" { target *-*-* } 19 }
+  queryAliases(inputs); // { dg-error "matching|unresolved" }
 }
diff --git a/gcc/testsuite/g++.old-deja/g++.other/pmf3.C b/gcc/testsuite/g++.old-deja/g++.other/pmf3.C
index 11e648e..448d791 100644
--- a/gcc/testsuite/g++.old-deja/g++.other/pmf3.C
+++ b/gcc/testsuite/g++.old-deja/g++.other/pmf3.C
@@ -3,7 +3,7 @@
 // Bug: g++ was crashing after giving errors.
 
 template
-  void connect_to_method( // { dg-message "connect_to_method|no known conversion" }
+  void connect_to_method(
 T *receiver,
 void (T::*method)())
   {}
@@ -20,7 +20,6 @@ publ

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jan Kratochvil]

On Thu, 30 Jun 2011 00:27:31 +0200, Jason Merrill wrote:
> The earlier output was correct.  We just don't want to print "g(int,
> double)".

OK, understood now.  It got more clear with the new testcase:

_Z1tIlEDTplcvT_Li5EclL_Z1qsELi6EEEv

decltype (((long)(5))+((q(short))(6))) t()
->
decltype (((long)(5))+(q(6))) t()

OK to check it in if the regression testing underway is OK?


Thanks,
Jan


libiberty/
2011-06-30  Jan Kratochvil  

* cp-demangle.c (d_print_comp): Suppress argument list for function
references by the '&' unary operator.  Keep also already processed
variant without the argument list.  Suppress argument list types for
function call used in an expression.
* testsuite/demangle-expected: Fix excessive argument list types in
`test for typed function in decltype'.  New testcase for no argument
list types printed.  3 new testcases for function references by the
'&' unary operator..

--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -4139,7 +4169,46 @@ d_print_comp (struct d_print_info *dpi, int options,
   return;
 
 case DEMANGLE_COMPONENT_UNARY:
-  if (d_left (dc)->type != DEMANGLE_COMPONENT_CAST)
+  if (d_left (dc)->type == DEMANGLE_COMPONENT_OPERATOR
+ && d_left (dc)->u.s_operator.op->len == 1
+ && d_left (dc)->u.s_operator.op->name[0] == '&'
+ && d_right (dc)->type == DEMANGLE_COMPONENT_TYPED_NAME
+ && d_left (d_right (dc))->type == DEMANGLE_COMPONENT_QUAL_NAME
+ && d_right (d_right (dc))->type == DEMANGLE_COMPONENT_FUNCTION_TYPE)
+   {
+ /* Address of a function (therefore in an expression context) must
+have its argument list suppressed.
+
+unary operator ... dc
+  operator & ... d_left (dc)
+  typed name ... d_right (dc)
+qualified name ... d_left (d_right (dc))
+  
+function type ... d_right (d_right (dc))
+  argument list
+  */
+
+ d_print_expr_op (dpi, options, d_left (dc));
+ d_print_comp (dpi, options, d_left (d_right (dc)));
+ return;
+   }
+  else if (d_left (dc)->type == DEMANGLE_COMPONENT_OPERATOR
+  && d_left (dc)->u.s_operator.op->len == 1
+  && d_left (dc)->u.s_operator.op->name[0] == '&'
+  && d_right (dc)->type == DEMANGLE_COMPONENT_QUAL_NAME)
+   {
+ /* Keep also already processed variant without the argument list.
+
+unary operator ... dc
+  operator & ... d_left (dc)
+  qualified name ... d_right (dc)
+  */
+
+ d_print_expr_op (dpi, options, d_left (dc));
+ d_print_comp (dpi, options, d_right (dc));
+ return;
+   }
+  else if (d_left (dc)->type != DEMANGLE_COMPONENT_CAST)
d_print_expr_op (dpi, options, d_left (dc));
   else
{
@@ -4165,7 +4234,21 @@ d_print_comp (struct d_print_info *dpi, int options,
  && d_left (dc)->u.s_operator.op->name[0] == '>')
d_append_char (dpi, '(');
 
-  d_print_subexpr (dpi, options, d_left (d_right (dc)));
+  if (strcmp (d_left (dc)->u.s_operator.op->code, "cl") == 0
+  && d_left (d_right (dc))->type == DEMANGLE_COMPONENT_TYPED_NAME)
+   {
+ /* Function call used in an expression should not have printed types
+of the function arguments.  Values of the function arguments still
+get printed below.  */
+
+ const struct demangle_component *func = d_left (d_right (dc));
+
+ if (d_right (func)->type != DEMANGLE_COMPONENT_FUNCTION_TYPE)
+   d_print_error (dpi);
+ d_print_subexpr (dpi, options, d_left (func));
+   }
+  else
+   d_print_subexpr (dpi, options, d_left (d_right (dc)));
   if (strcmp (d_left (dc)->u.s_operator.op->code, "ix") == 0)
{
  d_append_char (dpi, '[');
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -3920,7 +3920,11 @@ decltype (({parm#1}.(g))()) h, 
double>(A, double)
 # test for typed function in decltype
 --format=gnu-v3
 _ZN1AIiE1jIiEEDTplfp_clL_Z1xvEEET_
-decltype ({parm#1}+((x())())) A::j(int)
+decltype ({parm#1}+(x())) A::j(int)
+# typed function in decltype with an argument list
+--format=gnu-v3
+_Z1tIlEDTplcvT_Li5EclL_Z1qsELi6EEEv
+decltype (((long)(5))+(q(6))) t()
 # test for expansion of function parameter pack
 --format=gnu-v3
 _Z1gIIidEEDTclL_Z1fEspplfp_Li1EEEDpT_
@@ -3990,6 +3994,18 @@ outer(short (*)(int), long)
 _Z6outer2IsEPFilES1_
 outer2(int (*)(long))
 #
+--format=gnu-v3 --no-params
+_ZN1KIXadL_ZN1S1mEiEEE1fEv
+K<&S::m>::f()
+K<&S::m>::f
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1mEiEEE1fEv
+K<1, &S::m>::f()
+# Here the `(int)' argument list of `S::m' is already removed.
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1m1fEv
+K<1, &S::m>::f()
+#
 # Ada (GNAT) tests.
 #
 # Simple test.

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Thu, Jun 30, 2011 at 12:02 PM, Richard Henderson  wrote:
> On 06/30/2011 11:23 AM, H.J. Lu wrote:
>> +#ifdef REG_VALUE_IN_UNWIND_CONTEXT
>> +typedef _Unwind_Word _Unwind_Context_Reg_Val;
>> +/* Signal frame context.  */
>> +#define SIGNAL_FRAME_BIT ((_Unwind_Word) 1 >> 0)
>
> There's absolutely no reason to re-define this.
> So what if the value is most-significant-bit set?
>
> Nor do I see any reason not to continue setting E_C_B.

Done.

>> +#define _Unwind_IsExtendedContext(c) 1
>
> Why is this not still an inline function?

It is defined before _Unwind_Context is declared.  I used
macros so that there can be one less "#ifdef".

>> +
>> +static inline _Unwind_Word
>> +_Unwind_Get_Unwind_Word (_Unwind_Context_Reg_Val val)
>> +{
>> +  return val;
>> +}
>> +
>> +static inline _Unwind_Context_Reg_Val
>> +_Unwind_Get_Unwind_Context_Reg_Val (_Unwind_Word val)
>> +{
>> +  return val;
>> +}
>
> I cannot believe this actually works.  I see nowhere that
> you copy the by-address slot out of the stack frame and
> place it into the by-value slot in the unwind context.

I changed the implantation based on the feedback from
Jason.  Now I use the same reg field for both value and
address.

>>    /* This will segfault if the register hasn't been saved.  */
>>    if (size == sizeof(_Unwind_Ptr))
>> -    return * (_Unwind_Ptr *) ptr;
>> +    return * (_Unwind_Ptr *) (_Unwind_Internal_Ptr) val;
>>    else
>>      {
>>        gcc_assert (size == sizeof(_Unwind_Word));
>> -      return * (_Unwind_Word *) ptr;
>> +      return * (_Unwind_Word *) (_Unwind_Internal_Ptr) val;
>>      }
>
> Indeed, this section is both wrong and belies the change
> you purport to make.
>
> You didn't even test this, did you?
>

Here is the updated patch.  It works on simple tests.
I am running full tests.  I kept config/i386/value-unwind.h
since libgcc/md-unwind-support.h is included too late
in unwind-dw2.c and I don't want to move it to be on
the safe side.

OK for trunk?

Thanks.

-- 
H.J.
---
gcc/

2011-06-30  H.J. Lu  

* config.gcc (libgcc_tm_file): Add i386/value-unwind.h for
Linux/x86.

* system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.

* unwind-dw2.c (_Unwind_Context_Reg_Val): New.
(_Unwind_Get_Unwind_Word): Likewise.
(_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
(_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
(_Unwind_IsExtendedContext): Defined as macro.
(_Unwind_GetGR): Updated.
(_Unwind_SetGR): Likewise.
(_Unwind_GetGRPtr): Likewise.
(_Unwind_SetGRPtr): Likewise.
(_Unwind_SetGRValue): Likewise.
(_Unwind_GRByValue): Likewise.
(__frame_state_for): Likewise.
(uw_install_context_1): Likewise.

* doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
* doc/tm.texi: Regenerated.

libgcc/

2011-06-30  H.J. Lu  

* config/i386/value-unwind.h: New.
gcc/

2011-06-30  H.J. Lu  

* config.gcc (libgcc_tm_file): Add i386/value-unwind.h for
Linux/x86.

* system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.

* unwind-dw2.c (_Unwind_Context_Reg_Val): New.
(_Unwind_Get_Unwind_Word): Likewise.
(_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
(_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
(_Unwind_IsExtendedContext): Defined as macro.
(_Unwind_GetGR): Updated.
(_Unwind_SetGR): Likewise.
(_Unwind_GetGRPtr): Likewise.
(_Unwind_SetGRPtr): Likewise.
(_Unwind_SetGRValue): Likewise.
(_Unwind_GRByValue): Likewise.
(__frame_state_for): Likewise.
(uw_install_context_1): Likewise.

* doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
* doc/tm.texi: Regenerated.

libgcc/

2011-06-30  H.J. Lu  

* config/i386/value-unwind.h: New.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 73c47d7..2702df2 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2630,6 +2651,7 @@ esac
 case ${target} in
 i[34567]86-*-linux* | x86_64-*-linux*)
tmake_file="${tmake_file} i386/t-pmm_malloc i386/t-i386"
+   libgcc_tm_file="${libgcc_tm_file} i386/value-unwind.h"
;;
 i[34567]86-*-* | x86_64-*-*)
tmake_file="${tmake_file} i386/t-gmm_malloc i386/t-i386"
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 341628b..2666716 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -3701,6 +3701,14 @@ return @code{@var{regno}}.
 
 @end defmac
 
+@defmac REG_VALUE_IN_UNWIND_CONTEXT
+
+Define this macro if the target stores register values as
+@code{_Unwind_Word} type in unwind context.  The default is to
+store register values as @code{void *} type.
+
+@end defmac
+
 @node Elimination
 @subsection Eliminating Frame Pointer and Arg Pointer
 
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index f7c16e9..690fa52 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3687,6 +3687,14 @@ return @code{@var{regno}}.
 
 @end 

Re: [testsuite, AVR]: Add some progmem test cases

[Georg-Johann Lay]

Georg-Johann Lay schrieb:

Some runtime and checks for error/warning for C/C++.


...

testsuite/
* gcc.target/avr/torture/progmem.h: New file.
* gcc.target/avr/torture/exit-abort.h: New file.


maybe it's better to have the .h files one level up like so?

* gcc.target/avr/progmem.h: New file.
* gcc.target/avr/exit-abort.h: New file.

For better accessibility in upcoming tests.

Johann

[pph] Stream first/weak_object_global_name (issue4641086)

[Gabriel Charette]

first/weak_global_object_name are part of the global state.

This seems to be used to produce the assembler names. They are set only once as 
early as possible in the parsing; thus we should define it to be whatever it 
was in the first pph (or even in the C file if it was set before any pph was 
even loaded.

I'm not sure exactly what this does, but trying to find a fix for the asm diffs 
this is the first thing that I hit in the compiler logic that was different in 
the good compiler vs the pph compiler. With this fix this bit of logic is now 
correct.
However, this doesn't fix any pph test (nor does it even change any pph asm (I 
diff'ed the old bad assemblies (*.s+pph) with the new ones)).

Tested with bootstrap build and pph regression testing.

2011-06-30  Gabriel Charette  

* Make-lang.in (pph-streamer-out.o): Add dependence on output.h
(pph-streamer-in.o): Add dependence on output.h
* pph-streamer-in.c (pph_read_file_contents): Stream in
first_global_object_name and weak_global_object_name.
* gcc/cp/pph-streamer-out.c (pph_write_file_contents): Stream out
first_global_object_name and weak_global_object_name.

diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 0bb1a15..ec7596a 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -350,8 +350,8 @@ cp/pph-streamer.o: cp/pph-streamer.c $(CONFIG_H) 
$(SYSTEM_H) coretypes.h \
 cp/pph-streamer-out.o: cp/pph-streamer-out.c $(CONFIG_H) $(SYSTEM_H) \
coretypes.h $(TREE_H) tree-pretty-print.h $(LTO_STREAMER_H) \
$(CXX_PPH_STREAMER_H) $(CXX_PPH_H) $(TREE_PASS_H) version.h \
-   cppbuiltin.h tree-iterator.h
+   cppbuiltin.h tree-iterator.h output.h
 cp/pph-streamer-in.o: cp/pph-streamer-in.c $(CONFIG_H) $(SYSTEM_H) \
coretypes.h $(TREE_H) tree-pretty-print.h $(LTO_STREAMER_H) \
$(CXX_PPH_STREAMER_H) $(CXX_PPH_H) $(TREE_PASS_H) version.h \
-   cppbuiltin.h tree-iterator.h
+   cppbuiltin.h tree-iterator.h output.h
diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
index 3ac5243..c341d50 100644
--- a/gcc/cp/pph-streamer-in.c
+++ b/gcc/cp/pph-streamer-in.c
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-pass.h"
 #include "version.h"
 #include "cppbuiltin.h"
+#include "output.h"
 
 /* Wrapper for memory allocation calls that should have their results
registered in the PPH streamer cache.  DATA is the pointer returned
@@ -1309,7 +1310,7 @@ pph_read_file_contents (pph_stream *stream)
 {
   bool verified;
   cpp_ident_use *bad_use;
-  const char *cur_def;
+  const char *cur_def, *pph_fgon, *pph_wgon;
   cpp_idents_used idents_used;
   tree fndecl;
   unsigned i;
@@ -1325,6 +1326,16 @@ pph_read_file_contents (pph_stream *stream)
   /* Re-instantiate all the pre-processor symbols defined by STREAM.  */
   cpp_lt_replay (parse_in, &idents_used);
 
+  /* If first_global_object_name is not set yet, set it to the pph one.  */
+  pph_fgon = pph_in_string (stream);
+  if (!first_global_object_name)
+first_global_object_name = pph_fgon;
+
+  /* If weak_global_object_name is not set yet, set it to the pph one.  */
+  pph_wgon = pph_in_string (stream);
+  if (!weak_global_object_name)
+weak_global_object_name = pph_wgon;
+
   /* Read the bindings from STREAM and merge them with the current bindings.  
*/
   pph_in_scope_chain (stream);
 
diff --git a/gcc/cp/pph-streamer-out.c b/gcc/cp/pph-streamer-out.c
index acc0352..0d29f0b 100644
--- a/gcc/cp/pph-streamer-out.c
+++ b/gcc/cp/pph-streamer-out.c
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-pass.h"
 #include "version.h"
 #include "cppbuiltin.h"
+#include "output.h"
 
 /* FIXME pph.  This holds the FILE handle for the current PPH file
that we are writing.  It is necessary because the LTO callbacks do
@@ -1197,9 +1198,14 @@ static void
 pph_write_file_contents (pph_stream *stream, cpp_idents_used *idents_used)
 { 
   pph_out_identifiers (stream, idents_used);
+
+  pph_out_string (stream, first_global_object_name);
+  pph_out_string (stream, weak_global_object_name);
+
   pph_out_scope_chain (stream, scope_chain, false);
   if (flag_pph_dump_tree)
 pph_dump_namespace (pph_logfile, global_namespace);
+
   pph_out_tree (stream, keyed_classes, false);
   pph_out_tree_vec (stream, unemitted_tinfo_decls, false);
 }

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

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Thu, Jun 30, 2011 at 11:09 AM, Rainer Orth
 wrote:
> "H.J. Lu"  writes:
>
>>> Why all those contortions with i386/value-unwind.h?  It seems far
>>> simpler to me to put this into libgcc/config/i386/linux-unwind.h and be
>>> done with it.
>>
>> I did it this way so that other non-Linux x32 targets can use it.
>
> Such as?  Currently, only Linux, Windows and Solaris have i386/*-unwind.h
> implementations.  I'm pretty sure the latter two are highly unlikely to
> develop an x32 port, so let's cross that bridge when we get there.
>

It doesn't work since md-unwind-support.h was included much too late.

-- 
H.J.

Re: [PATCH] [Annotalysis] Fixes virtual method calls when type is unknown

[Ollie Wild]

On Thu, Jun 30, 2011 at 12:09 PM, Diego Novillo  wrote:
>
> On 11-06-30 13:01 , Delesley Hutchins wrote:
>>
>> Okay for branches/annotalysis and google/main?
>
> OK with some minor formatting nits below.

Please also cherry-pick this into the google/gcc_4-6 branch.  I've
sent you instructions out-of-band for doing so.

Ollie

Re: [patch] Fix oversight in tuplification of DOM

[Eric Botcazou]

> 2011-06-28  Eric Botcazou  
>
>   * tree-ssa-dom.c (initialize_hash_element): Fix oversight.

As reported under PR tree-optimization/49572, using the type of the LHS like in 
the other cases leads to optimization regressions.  The attached patch changes 
this to use the type of RHS instead in the GIMPLE_SINGLE_RHS case.

Tested on x86_64-suse-linux, pre-approved by Richard in the PR, applied.


2011-06-30  Eric Botcazou  

PR tree-optimization/49572
* tree-ssa-dom.c (initialize_hash_element) : Use the
type of the RHS instead of that of the LHS for the expression type.


-- 
Eric Botcazou
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c	(revision 175621)
+++ tree-ssa-dom.c	(working copy)
@@ -208,13 +208,11 @@ initialize_hash_element (gimple stmt, tr
 {
   enum tree_code subcode = gimple_assign_rhs_code (stmt);
 
-  expr->type = NULL_TREE;
-
   switch (get_gimple_rhs_class (subcode))
 {
 case GIMPLE_SINGLE_RHS:
 	  expr->kind = EXPR_SINGLE;
-	  expr->type = TREE_TYPE (gimple_assign_lhs (stmt));
+	  expr->type = TREE_TYPE (gimple_assign_rhs1 (stmt));
 	  expr->ops.single.rhs = gimple_assign_rhs1 (stmt);
 	  break;
 case GIMPLE_UNARY_RHS:

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[Richard Henderson]

On 06/30/2011 11:23 AM, H.J. Lu wrote:
> +#ifdef REG_VALUE_IN_UNWIND_CONTEXT
> +typedef _Unwind_Word _Unwind_Context_Reg_Val;
> +/* Signal frame context.  */
> +#define SIGNAL_FRAME_BIT ((_Unwind_Word) 1 >> 0)

There's absolutely no reason to re-define this.
So what if the value is most-significant-bit set?

Nor do I see any reason not to continue setting E_C_B.

> +#define _Unwind_IsExtendedContext(c) 1

Why is this not still an inline function?

> +
> +static inline _Unwind_Word
> +_Unwind_Get_Unwind_Word (_Unwind_Context_Reg_Val val)
> +{
> +  return val;
> +}
> +
> +static inline _Unwind_Context_Reg_Val
> +_Unwind_Get_Unwind_Context_Reg_Val (_Unwind_Word val)
> +{
> +  return val;
> +}

I cannot believe this actually works.  I see nowhere that 
you copy the by-address slot out of the stack frame and
place it into the by-value slot in the unwind context.

>/* This will segfault if the register hasn't been saved.  */
>if (size == sizeof(_Unwind_Ptr))
> -return * (_Unwind_Ptr *) ptr;
> +return * (_Unwind_Ptr *) (_Unwind_Internal_Ptr) val;
>else
>  {
>gcc_assert (size == sizeof(_Unwind_Word));
> -  return * (_Unwind_Word *) ptr;
> +  return * (_Unwind_Word *) (_Unwind_Internal_Ptr) val;
>  }

Indeed, this section is both wrong and belies the change
you purport to make.

You didn't even test this, did you?


r~

[PATCH] Improve CONSTRUCTOR printing in tree-pretty-print.c

[Jakub Jelinek]

Hi!

As reporteed by Tobias, when printing array ctors the pretty printer would
never print indexes or ranges, which means that e.g.
{[2 ... 71]=7}
ctor was printed as
{7}
and
{[3]=1, [7]=2}
ctor was printed as
{1, 2}
The following patch prints the index (if different from the last index + 1
resp. min value for the first element) or range (always).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2011-06-30  Jakub Jelinek  

* tree-pretty-print.c (dump_generic_code) : Print
[idx]= and [idx1 ... idx2]= before initializers if needed for
array initializers.

--- gcc/tree-pretty-print.c.jj  2011-06-06 19:07:08.0 +0200
+++ gcc/tree-pretty-print.c 2011-06-30 11:51:04.0 +0200
@@ -1250,19 +1250,58 @@ dump_generic_node (pretty_printer *buffe
   {
unsigned HOST_WIDE_INT ix;
tree field, val;
-   bool is_struct_init = FALSE;
+   bool is_struct_init = false;
+   bool is_array_init = false;
+   double_int curidx = double_int_zero;
pp_character (buffer, '{');
if (TREE_CODE (TREE_TYPE (node)) == RECORD_TYPE
|| TREE_CODE (TREE_TYPE (node)) == UNION_TYPE)
- is_struct_init = TRUE;
+ is_struct_init = true;
+else if (TREE_CODE (TREE_TYPE (node)) == ARRAY_TYPE
+&& TYPE_DOMAIN (TREE_TYPE (node))
+&& TYPE_MIN_VALUE (TYPE_DOMAIN (TREE_TYPE (node)))
+&& TREE_CODE (TYPE_MIN_VALUE (TYPE_DOMAIN (TREE_TYPE (node
+   == INTEGER_CST)
+ {
+   tree minv = TYPE_MIN_VALUE (TYPE_DOMAIN (TREE_TYPE (node)));
+   is_array_init = true;
+   curidx = tree_to_double_int (minv);
+ }
FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (node), ix, field, val)
  {
-   if (field && is_struct_init)
+   if (field)
  {
-   pp_character (buffer, '.');
-   dump_generic_node (buffer, field, spc, flags, false);
-   pp_string (buffer, "=");
+   if (is_struct_init)
+ {
+   pp_character (buffer, '.');
+   dump_generic_node (buffer, field, spc, flags, false);
+   pp_character (buffer, '=');
+ }
+   else if (is_array_init
+&& (TREE_CODE (field) != INTEGER_CST
+|| !double_int_equal_p (tree_to_double_int (field),
+curidx)))
+ {
+   pp_character (buffer, '[');
+   if (TREE_CODE (field) == RANGE_EXPR)
+ {
+   dump_generic_node (buffer, TREE_OPERAND (field, 0), spc,
+  flags, false);
+   pp_string (buffer, " ... ");
+   dump_generic_node (buffer, TREE_OPERAND (field, 1), spc,
+  flags, false);
+   if (TREE_CODE (TREE_OPERAND (field, 1)) == INTEGER_CST)
+ curidx = tree_to_double_int (TREE_OPERAND (field, 1));
+ }
+   else
+ dump_generic_node (buffer, field, spc, flags, false);
+   if (TREE_CODE (field) == INTEGER_CST)
+ curidx = tree_to_double_int (field);
+   pp_string (buffer, "]=");
+ }
  }
+if (is_array_init)
+ curidx = double_int_add (curidx, double_int_one);
if (val && TREE_CODE (val) == ADDR_EXPR)
  if (TREE_CODE (TREE_OPERAND (val, 0)) == FUNCTION_DECL)
val = TREE_OPERAND (val, 0);

Jakub

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Thu, Jun 30, 2011 at 11:09 AM, Rainer Orth
 wrote:
> "H.J. Lu"  writes:
>
>>> Why all those contortions with i386/value-unwind.h?  It seems far
>>> simpler to me to put this into libgcc/config/i386/linux-unwind.h and be
>>> done with it.
>>
>> I did it this way so that other non-Linux x32 targets can use it.
>
> Such as?  Currently, only Linux, Windows and Solaris have i386/*-unwind.h
> implementations.  I'm pretty sure the latter two are highly unlikely to
> develop an x32 port, so let's cross that bridge when we get there.
>

Here is the updated patch without config/i386/value-unwind.h.
OK for trunk?

Thanks.

-- 
H.J.
---
2011-06-30  H.J. Lu  

* system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.

* unwind-dw2.c (_Unwind_Context_Reg_Val): New.
(_Unwind_Get_Unwind_Word): Likewise.
(_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
(_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
(SIGNAL_FRAME_BIT): Define if REG_VALUE_IN_UNWIND_CONTEXT is
defined.
(_Unwind_IsExtendedContext): Likewise.
(EXTENDED_CONTEXT_BIT): Don't define if REG_VALUE_IN_UNWIND_CONTEXT
is defined.
(_Unwind_GetGR): Updated.
(_Unwind_SetGR): Likewise.
(_Unwind_GetGRPtr): Likewise.
(_Unwind_SetGRPtr): Likewise.
(_Unwind_SetGRValue): Likewise.
(_Unwind_GRByValue): Likewise.
(__frame_state_for): Likewise.
(uw_install_context_1): Likewise.

* doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
* doc/tm.texi: Regenerated.
2011-06-30  H.J. Lu  

* system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.

* unwind-dw2.c (_Unwind_Context_Reg_Val): New.
(_Unwind_Get_Unwind_Word): Likewise.
(_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
(_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
(SIGNAL_FRAME_BIT): Define if REG_VALUE_IN_UNWIND_CONTEXT is
defined.
(_Unwind_IsExtendedContext): Likewise.
(EXTENDED_CONTEXT_BIT): Don't define if REG_VALUE_IN_UNWIND_CONTEXT
is defined.
(_Unwind_GetGR): Updated.
(_Unwind_SetGR): Likewise.
(_Unwind_GetGRPtr): Likewise.
(_Unwind_SetGRPtr): Likewise.
(_Unwind_SetGRValue): Likewise.
(_Unwind_GRByValue): Likewise.
(__frame_state_for): Likewise.
(uw_install_context_1): Likewise.

* doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
* doc/tm.texi: Regenerated.

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 341628b..2666716 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -3701,6 +3701,14 @@ return @code{@var{regno}}.
 
 @end defmac
 
+@defmac REG_VALUE_IN_UNWIND_CONTEXT
+
+Define this macro if the target stores register values as
+@code{_Unwind_Word} type in unwind context.  The default is to
+store register values as @code{void *} type.
+
+@end defmac
+
 @node Elimination
 @subsection Eliminating Frame Pointer and Arg Pointer
 
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index f7c16e9..690fa52 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3687,6 +3687,14 @@ return @code{@var{regno}}.
 
 @end defmac
 
+@defmac REG_VALUE_IN_UNWIND_CONTEXT
+
+Define this macro if the target stores register values as
+@code{_Unwind_Word} type in unwind context.  The default is to
+store register values as @code{void *} type.
+
+@end defmac
+
 @node Elimination
 @subsection Eliminating Frame Pointer and Arg Pointer
 
diff --git a/gcc/system.h b/gcc/system.h
index e02cbcd..ed39d93 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -764,7 +764,7 @@ extern void fancy_abort (const char *, int, const char *) 
ATTRIBUTE_NORETURN;
 /* Target macros only used for code built for the target, that have
moved to libgcc-tm.h or have never been present elsewhere.  */
  #pragma GCC poison DECLARE_LIBRARY_RENAMES LIBGCC2_GNU_PREFIX \
-   MD_UNWIND_SUPPORT ENABLE_EXECUTE_STACK
+   MD_UNWIND_SUPPORT ENABLE_EXECUTE_STACK REG_VALUE_IN_UNWIND_CONTEXT
 
 /* Other obsolete target macros, or macros that used to be in target
headers and were not used, and may be obsolete or may never have
diff --git a/gcc/unwind-dw2.c b/gcc/unwind-dw2.c
index 19da299..c77265c 100644
--- a/gcc/unwind-dw2.c
+++ b/gcc/unwind-dw2.c
@@ -59,20 +59,56 @@
 #define DWARF_REG_TO_UNWIND_COLUMN(REGNO) (REGNO)
 #endif
 
+#ifdef REG_VALUE_IN_UNWIND_CONTEXT
+typedef _Unwind_Word _Unwind_Context_Reg_Val;
+/* Signal frame context.  */
+#define SIGNAL_FRAME_BIT ((_Unwind_Word) 1 >> 0)
+
+#define _Unwind_IsExtendedContext(c) 1
+
+static inline _Unwind_Word
+_Unwind_Get_Unwind_Word (_Unwind_Context_Reg_Val val)
+{
+  return val;
+}
+
+static inline _Unwind_Context_Reg_Val
+_Unwind_Get_Unwind_Context_Reg_Val (_Unwind_Word val)
+{
+  return val;
+}
+#else
+typedef void *_Unwind_Context_Reg_Val;
+/* Signal frame context.  */
+#define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
+/* Context which has versi

Re: [PATCH] Sign extend before converting constants to GMP values.

[Tobias Grosser]

On 06/30/2011 11:01 AM, Sebastian Pop wrote:

On Thu, Jun 30, 2011 at 10:03, Richard Guenther  wrote:

But what do you do for

  for (unsigned char i = 128; i<  255; ++i)

?  You change 128 to -128 which is wrong.


Yes, 128 gets translated to -128.
And 255 gets translated to -1.
And so the loop iteration domain gets translated in the polyhedral form
as going from -128 to -1 with strides of 1.
So this particular program is not miscompiled by graphite:

int main ()
{
   unsigned char j;
   int x[300];
   for (j = 128; j<  255; j++)
 x[j] = j;

   for (j = 128; j<  255; j++)
 if (x[j] != j)
   __builtin_abort ();

   return 0;
}

I was trying to build a program that fails to attach to the PR.


So yes, you also have to
deal with modulo arithmetic in graphite.


I'm trying to understand where we have to deal with the modulo arithmetic.
Tobias, what are you doing in Polly?
Do you insert the loop iteration domain constraints with the modulo
of the types?


Hi Sebastian,

this is neither handed correctly in Polly.

Just to be able to understand Polly and Graphite:
LLVM has a different way of representing integer arithmetic. GCC uses 
explicit signed and unsigned types, whereas LLVM uses integer types that 
do not specify signedness, but on which either signed or unsigned 
operations are applied (For operations like add, subtract or multiply 
the signed and unsigned operations are actually the same). All 
operations in LLVM follow modulo arithmetics, except when they are 
marked 'no signed overflow' or 'no unsigned overflow'.


For Polly the correct solution is that as long as the operations are 
marked 'no signed overflow' or 'no unsigned overflow' we do not need 
modulo arithmetics. Modulo semantics are needed for operations that can 
have overflow and for most casts. At the moment we do not allow casts in 
Polly and we just assume that no overflow will occur. This is incorrect, 
but, as most C code works on signed integers which have undefined 
overflow semantics, it works most of the time. My next project is to add 
modulo arithmetics to Polly as soon as we cannot prove that no overflow 
will occur. This is the last major bug in Polly.


For Graphite I am not sure. Can overflows occur in the signed types of 
GCC or follow they the C signed types where overflows are undefined? In 
case overflow in signed types is undefined we should be safe as long as 
we disallow typecasts. As soon as unsigned types with defined overflow 
semantics occur, we most probably need modulo semantics to handle this 
correctly.


As a first step to make Graphite correct, I would just bail out if 
overflows can occur. Those games with sign extensions may work for the 
case where 255 is used as a -1, but in general I do not believe they are 
sufficient to express modulo semantics.


Adding real support for modulo semantics is probably the way to go, 
however it might be difficult. The first problem is that I do not know 
of a convenient way to express modulo semantics in PPL. isl provides so 
called existentially quantified dimensions, that allow us to easily 
express modulo semantics. In PPL we can express the same by adding 
additional dimensions. However, these additional dimensions are not 
automatically managed, such that we must ensure manually that they are 
handled correctly in the various polyhedral operations we perform.
Also even if we would be able to express modulo semantics, there is 
still the problem that we will step into untested terrain. Neither CLooG 
nor the other tools have been tested with this. I personally do not 
expect a lot of correctness problems, however due to the introduction of 
large integer constants and additional dimensions we may face compile 
time problems or the creation of non-optimal code. Research wise an 
interesting topic.


So as a first step. Would it be OK to limit Graphite to signed types for 
the moment and remove the sext hack?


Cheers
Tobi

Re: [patch, fortran] Always return malloc(1) for empty arrays in the library

[Thomas Koenig]

Hi Janne,


I'd prefer to add the zero check to runtime/memory.c
(internal_malloc_size), i.e. change

if (size == 0)
   return NULL;

to

if (size == 0)
   size = 1;



Good point.  I have done so in the attached patch, plus removed
all special cases for checking for zero size.

Regression-tested.  OK for trunk?

For 4.6, I would just commit the change to internal_malloc_size
(which would also fix PR 49479), plus the test case for that
PR.

OK?

Regards

Thomas

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[Rainer Orth]

"H.J. Lu"  writes:

>> Why all those contortions with i386/value-unwind.h?  It seems far
>> simpler to me to put this into libgcc/config/i386/linux-unwind.h and be
>> done with it.
>
> I did it this way so that other non-Linux x32 targets can use it.

Such as?  Currently, only Linux, Windows and Solaris have i386/*-unwind.h
implementations.  I'm pretty sure the latter two are highly unlikely to
develop an x32 port, so let's cross that bridge when we get there.

Rainer

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

Re: [Patch, AVR, longlong.h]: Implement __clrsbhi2.

[Denis Chertykov]

2011/6/30 Georg-Johann Lay :
> The new count leading signs is not implemented for HI:
>
> builtin-bitops-1.c:(.text+0xd1e): undefined reference to `__clrsbhi2'
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O0
>
> Extended clz/ctz support in longlong.h
>
> With the patch testcase passes.
>
> Johann
>
> libgcc/
>        * config/avr/t-avr (intfuncs16): Add _clrsbXX2.
>
> gcc/
>        * longlong.h (count_leading_zeros, count_trailing_zeros,
>        COUNT_LEADING_ZEROS_0): Define for target avr if W_TYPE_SIZE is 16
>        resp. 64.

Approved.

Denis.

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Thu, Jun 30, 2011 at 11:03 AM, Rainer Orth
 wrote:
> "H.J. Lu"  writes:
>
>>> gcc/
>>>
>>> 2011-06-30  H.J. Lu  
>>>
>>>        * config.gcc (libgcc_tm_file): Add i386/value-unwind.h for
>>>        Linux/x86.
>>>
>>>        * system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.
>>>
>>>        * unwind-dw2.c (_Unwind_Context_Reg_Val): New.
>>>        (_Unwind_Get_Unwind_Word): Likewise.
>>>        (_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
>>>        (_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
>>>        (SIGNAL_FRAME_BIT): Define if REG_VALUE_IN_UNWIND_CONTEXT is
>>>        defined.
>>>        (_Unwind_IsExtendedContext): Likewise.
>>>        (EXTENDED_CONTEXT_BIT): Don't define if REG_VALUE_IN_UNWIND_CONTEXT
>>>        is defined.
>>>        (_Unwind_GetGR): Updated.
>>>        (_Unwind_SetGR): Likewise.
>>>        (_Unwind_GetGRPtr): Likewise.
>>>        (_Unwind_SetGRPtr): Likewise.
>>>        (_Unwind_SetGRValue): Likewise.
>>>        (_Unwind_GRByValue): Likewise.
>>>        (__frame_state_for): Likewise.
>>>        (uw_install_context_1): Likewise.
>>>
>>>        * doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
>>>        * doc/tm.texi: Regenerated.
>>>
>>> libgcc/
>>>
>>> 2011-06-30  H.J. Lu  
>>>
>>>        * config/i386/value-unwind.h: New.
>
> Why all those contortions with i386/value-unwind.h?  It seems far
> simpler to me to put this into libgcc/config/i386/linux-unwind.h and be
> done with it.
>

I did it this way so that other non-Linux x32 targets can use it.

-- 
H.J.

Re: PATCH [5/n]: Prepare x32: PR middle-end/48016: Inconsistency in non-local goto save area

[H.J. Lu]

On Wed, Jun 29, 2011 at 9:16 AM, Michael Matz  wrote:
> Hi,
>
> On Wed, 29 Jun 2011, H.J. Lu wrote:
>
>> > diff --git a/gcc/function.c b/gcc/function.c
>> > index 81c4d39..131bc09 100644
>> > --- a/gcc/function.c
>> > +++ b/gcc/function.c
>> > @@ -4780,7 +4780,7 @@ expand_function_start (tree subr)
>> >                       cfun->nonlocal_goto_save_area,
>> >                       integer_zero_node, NULL_TREE, NULL_TREE);
>> >       r_save = expand_expr (t_save, NULL_RTX, VOIDmode, EXPAND_WRITE);
>> > -      r_save = convert_memory_address (Pmode, r_save);
>> > +      r_save = adjust_address (r_save, Pmode, 0);
>
> This is actually the same problem as in explow.c.  t_save is built with
> ptr_type_node, where it should have been using
>  TREE_TYPE (TREE_TYPE (cfun->nonlocal_goto_save_area))
>
> Then r_save should have the correct mode already, possibly this could be
> asserted.  You are right that r_save needs to correspond to the
> nonlocal_goto_save_area[0] array-ref, hence pseudos aren't okay, therefore
> convert_memory_address isn't.  Actually I think we might even want to
> assert that indeed the expanded r_save is of Pmode already.
>
>

This patch works for me.  OK for trunk if there are no regressions?

Thanks.


-- 
H.J.
---
2011-06-30  H.J. Lu  

PR middle-end/48016
* explow.c (update_nonlocal_goto_save_area): Use proper mode
for stack save area.
* function.c (expand_function_start): Likewise.
2011-06-30  H.J. Lu  

PR middle-end/48016
* explow.c (update_nonlocal_goto_save_area): Use proper mode
for stack save area.
* function.c (expand_function_start): Likewise.

diff --git a/gcc/explow.c b/gcc/explow.c
index c7d8183..efe6c7e 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -1102,7 +1097,9 @@ update_nonlocal_goto_save_area (void)
  first one is used for the frame pointer save; the rest are sized by
  STACK_SAVEAREA_MODE.  Create a reference to array index 1, the first
  of the stack save area slots.  */
-  t_save = build4 (ARRAY_REF, ptr_type_node, cfun->nonlocal_goto_save_area,
+  t_save = build4 (ARRAY_REF,
+  TREE_TYPE (TREE_TYPE (cfun->nonlocal_goto_save_area)),
+  cfun->nonlocal_goto_save_area,
   integer_one_node, NULL_TREE, NULL_TREE);
   r_save = expand_expr (t_save, NULL_RTX, VOIDmode, EXPAND_WRITE);
 
diff --git a/gcc/function.c b/gcc/function.c
index 5be018a..0b2f5aa 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -4782,11 +4782,12 @@ expand_function_start (tree subr)
   if (!DECL_RTL_SET_P (var))
expand_decl (var);
 
-  t_save = build4 (ARRAY_REF, ptr_type_node,
+  t_save = build4 (ARRAY_REF,
+  TREE_TYPE (TREE_TYPE (cfun->nonlocal_goto_save_area)),
   cfun->nonlocal_goto_save_area,
   integer_zero_node, NULL_TREE, NULL_TREE);
   r_save = expand_expr (t_save, NULL_RTX, VOIDmode, EXPAND_WRITE);
-  r_save = convert_memory_address (Pmode, r_save);
+  gcc_assert (GET_MODE (r_save) == Pmode);
 
   emit_move_insn (r_save, targetm.builtin_setjmp_frame_value ());
   update_nonlocal_goto_save_area ();

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[Rainer Orth]

"H.J. Lu"  writes:

>> gcc/
>>
>> 2011-06-30  H.J. Lu  
>>
>>        * config.gcc (libgcc_tm_file): Add i386/value-unwind.h for
>>        Linux/x86.
>>
>>        * system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.
>>
>>        * unwind-dw2.c (_Unwind_Context_Reg_Val): New.
>>        (_Unwind_Get_Unwind_Word): Likewise.
>>        (_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
>>        (_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
>>        (SIGNAL_FRAME_BIT): Define if REG_VALUE_IN_UNWIND_CONTEXT is
>>        defined.
>>        (_Unwind_IsExtendedContext): Likewise.
>>        (EXTENDED_CONTEXT_BIT): Don't define if REG_VALUE_IN_UNWIND_CONTEXT
>>        is defined.
>>        (_Unwind_GetGR): Updated.
>>        (_Unwind_SetGR): Likewise.
>>        (_Unwind_GetGRPtr): Likewise.
>>        (_Unwind_SetGRPtr): Likewise.
>>        (_Unwind_SetGRValue): Likewise.
>>        (_Unwind_GRByValue): Likewise.
>>        (__frame_state_for): Likewise.
>>        (uw_install_context_1): Likewise.
>>
>>        * doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
>>        * doc/tm.texi: Regenerated.
>>
>> libgcc/
>>
>> 2011-06-30  H.J. Lu  
>>
>>        * config/i386/value-unwind.h: New.

Why all those contortions with i386/value-unwind.h?  It seems far
simpler to me to put this into libgcc/config/i386/linux-unwind.h and be
done with it.

The unwinder are on their way to libgcc, and I don't want to keep some
gcc-side configuration behind.

Rainer

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

[patch tree-optimization]: Fix typo in X bitwise-binary-op CST

[Kai Tietz]

Hello,

this patch fixes a typo in type-sinking for bitwise-binary operation X op CST.

ChangeLog gcc/

2011-06-30  Kai Tietz  

* tree-ssa-forwprop.c (simplify_bitwise_binary): Fix typo.

ChangeLog gcc/testsuite

2011-06-30  Kai Tietz  

* gcc.dg/tree-ssa/bitwise-sink.c: New test.

Bootstrapped and regression tested for all standard languages plus Ada and 
Obj-C++ on x86_64-pc-linux-gnu. Ok for apply?

Regards,
Kai

Index: gcc-head/gcc/testsuite/gcc.dg/tree-ssa/bitwise-sink.c
===
--- /dev/null
+++ gcc-head/gcc/testsuite/gcc.dg/tree-ssa/bitwise-sink.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int
+foo (_Bool x)
+{
+  return (x ^ 1);
+}
+
+/* { dg-final { scan-tree-dump-times "x\[^ \]* \\^ 1" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc-head/gcc/tree-ssa-forwprop.c
===
--- gcc-head.orig/gcc/tree-ssa-forwprop.c
+++ gcc-head/gcc/tree-ssa-forwprop.c
@@ -1946,7 +1946,7 @@ simplify_bitwise_binary (gimple_stmt_ite
   /* Try to fold (type) X op CST -> (type) (X op ((type-x) CST)).  */
   if (TREE_CODE (arg2) == INTEGER_CST
   && CONVERT_EXPR_CODE_P (def1_code)
-  && INTEGRAL_TYPE_P (def1_arg1)
+  && INTEGRAL_TYPE_P (TREE_TYPE (def1_arg1))
   && int_fits_type_p (arg2, TREE_TYPE (def1_arg1)))
 {
   gimple newop;

Use INCOMING_REGNO macro unconditionally in df-scan.c

[Eric Botcazou]

Like in other files, since defaults.h ensures that it is always defined.

Tested on i586-suse-linux, applied on the mainline.


2011-06-30  Eric Botcazou  

* df-scan.c (df_get_entry_block_def_set): Use INCOMING_REGNO macro
unconditionally.


-- 
Eric Botcazou
Index: df-scan.c
===
--- df-scan.c	(revision 175621)
+++ df-scan.c	(working copy)
@@ -3733,14 +3733,8 @@ df_get_entry_block_def_set (bitmap entry
   bitmap_clear (entry_block_defs);
 
   for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
-{
-  if (FUNCTION_ARG_REGNO_P (i))
-#ifdef INCOMING_REGNO
-	bitmap_set_bit (entry_block_defs, INCOMING_REGNO (i));
-#else
-	bitmap_set_bit (entry_block_defs, i);
-#endif
-}
+if (FUNCTION_ARG_REGNO_P (i))
+  bitmap_set_bit (entry_block_defs, INCOMING_REGNO (i));
 
   /* The always important stack pointer.  */
   bitmap_set_bit (entry_block_defs, STACK_POINTER_REGNUM);

Re: [PATCH] Enable IPA-PTA for ltrans stage

[H.J. Lu]

On Thu, Jun 30, 2011 at 7:01 AM, Richard Guenther  wrote:
>
> This patch makes IPA-PTA work during the ltrans stage of LTO.
> It basically makes sure to honor the accessed-from-other-ltrans-unit
> flags for variables and functions where appropriate.
>
> With this patch, IPA-PTA survives LTO bootstrap (with -fipa-pta
> hard-wired to 1 in common.opt).  Before the patch we miscompiled
> the stage2 compiler (unsurprisingly).
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> I hope to get to some of the remaining TODOs for IPA-PTA (basically
> fixup nonlocal handling throughout the compiler ...) and then maybe
> look at compile-time and memory usage issues.
>
> Richard.
>
> 2011-06-29  Richard Guenther  
>
>        * opts.c (finish_options): Do not disable IPA-PTA during ltrans.
>        * tree-ssa-structalias.c (create_variable_info_for): Do not
>        add initial constraints for non-var-decls.  Properly handle
>        globals in other ltrans partitions.
>        (intra_create_variable_infos): Manually create constraints for
>        the fake no-alias parameter.
>        (ipa_pta_execute): Dump the cgraph, handle ltrans partitions properly
>        and assert there are no clones.
>

This caused:

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

-- 
H.J.

[testsuite, AVR]: Add some progmem test cases

[Georg-Johann Lay]

Some runtime and checks for error/warning for C/C++.

Is
  ./testsuite/gcc.target/avr/
realm of avr port maintainers?

Johann

testsuite/
* gcc.target/avr/avr.exp: Run over cpp files, too.
* gcc.target/avr/torture/avr-torture.exp: Ditto.
* gcc.target/avr/progmem-error-1.c: New file.
* gcc.target/avr/progmem-error-1.cpp: New file.
* gcc.target/avr/progmem-warning-1.c: New file.
* gcc.target/avr/torture/progmem-1.c: New file.
* gcc.target/avr/torture/progmem-1.cpp: New file.
* gcc.target/avr/torture/progmem.h: New file.
* gcc.target/avr/torture/exit-abort.h: New file.
Index: gcc.target/avr/avr.exp
===
--- gcc.target/avr/avr.exp	(revision 175628)
+++ gcc.target/avr/avr.exp	(working copy)
@@ -34,7 +34,7 @@ if ![info exists DEFAULT_CFLAGS] then {
 dg-init
 
 # Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cCS\]]] \
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.{\[cCS\],cpp}]] \
 	"" $DEFAULT_CFLAGS
 
 # All done.
Index: gcc.target/avr/torture/exit-abort.h
===
--- gcc.target/avr/torture/exit-abort.h	(revision 0)
+++ gcc.target/avr/torture/exit-abort.h	(revision 0)
@@ -0,0 +1,8 @@
+#ifdef __cplusplus
+extern "C" {
+#endif
+  extern void exit (int);
+  extern void abort (void);
+#ifdef __cplusplus
+}
+#endif
Index: gcc.target/avr/torture/avr-torture.exp
===
--- gcc.target/avr/torture/avr-torture.exp	(revision 175628)
+++ gcc.target/avr/torture/avr-torture.exp	(working copy)
@@ -52,7 +52,7 @@ set-torture-options $AVR_TORTURE_OPTIONS
 
 
 # Main loop.
-gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\]]] $DEFAULT_CFLAGS
+gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.{\[cS\],cpp}]] $DEFAULT_CFLAGS
 
 # Finalize use of torture lists.
 torture-finish
Index: gcc.target/avr/torture/progmem-1.c
===
--- gcc.target/avr/torture/progmem-1.c	(revision 0)
+++ gcc.target/avr/torture/progmem-1.c	(revision 0)
@@ -0,0 +1,30 @@
+/* { dg-do run } */
+
+#include "exit-abort.h"
+#include "progmem.h"
+
+const char strA[] PROGMEM = "@A";
+const char strc PROGMEM = 'c';
+
+unsigned int volatile s = 2;
+
+int main()
+{
+char c;
+
+c = pgm_read_char (&strA[s-1]);
+if (c != 'A')
+abort();
+
+c = pgm_read_char (&PSTR ("@@B")[s]);
+if (c != 'B')
+abort();
+
+c = pgm_read_char (&strc);
+if (c != 'c')
+abort();
+
+exit (0);
+
+return 0;
+}
Index: gcc.target/avr/torture/progmem-1.cpp
===
--- gcc.target/avr/torture/progmem-1.cpp	(revision 0)
+++ gcc.target/avr/torture/progmem-1.cpp	(revision 0)
@@ -0,0 +1,2 @@
+/* { dg-do run } */
+#include "progmem-1.c"
Index: gcc.target/avr/torture/progmem.h
===
--- gcc.target/avr/torture/progmem.h	(revision 0)
+++ gcc.target/avr/torture/progmem.h	(revision 0)
@@ -0,0 +1,14 @@
+#define PROGMEM __attribute__((progmem))
+
+#define PSTR(s) \
+(__extension__({\
+static const char __c[] PROGMEM = (s);  \
+&__c[0];}))
+
+#define pgm_read_char(addr) \
+(__extension__({\
+unsigned int __addr16 = (unsigned int)(addr);   \
+char __result;  \
+__asm__ ("lpm %0, %a1"  \
+ : "=r" (__result) : "z" (__addr16));   \
+__result; }))
Index: gcc.target/avr/progmem-warning-1.c
===
--- gcc.target/avr/progmem-warning-1.c	(revision 0)
+++ gcc.target/avr/progmem-warning-1.c	(revision 0)
@@ -0,0 +1,6 @@
+/* { dg-do compile } */
+/* { dg-options "-Wuninitialized" } */
+
+#include "torture/progmem.h"
+
+const char c PROGMEM; /* { dg-warning "uninitialized variable 'c' put into program memory area" } */
Index: gcc.target/avr/progmem-error-1.c
===
--- gcc.target/avr/progmem-error-1.c	(revision 0)
+++ gcc.target/avr/progmem-error-1.c	(revision 0)
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+
+#include "torture/progmem.h"
+
+char str[] PROGMEM = "Hallo"; /* { dg-error "must be const" } */
Index: gcc.target/avr/progmem-error-1.cpp
===
--- gcc.target/avr/progmem-error-1.cpp	(revision 0)
+++ gcc.target/avr/progmem-error-1.cpp	(revision 0)
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+
+#include "torture/progmem.h"
+
+char str[] PROGMEM = "Hallo"; /* { dg-error "must be const" } */

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Thu, Jun 30, 2011 at 10:37 AM, H.J. Lu  wrote:
> On Thu, Jun 30, 2011 at 9:08 AM, H.J. Lu  wrote:
>> On Thu, Jun 30, 2011 at 8:03 AM, Jason Merrill  wrote:
>>> On 06/30/2011 10:42 AM, H.J. Lu wrote:

 Register may be saved/restored either by address or value. My patch
 doesn't change the reg field.  The other way will be

 #ifdef USE_UNWIND_WORD
     _Unwind_Word reg[DWARF_FRAME_REGISTERS+1];
 #else
      void *reg[DWARF_FRAME_REGISTERS+1];
 #endif

 We need it so that we are binary compatible with the existing
 unwind context.  Once we do that we need many

 #ifdef USE_UNWIND_WORD
 #endif

 whenever the reg field is accessed since the reg field is changed.
>>>
>>> But your patch already changes all but one place where reg is accessed.  And
>>> we can avoid lots of ifdefs by abstraction with macros/inlines so there's
>>> one interface.
>>
>> I can do that.
>>
>>> Also, why change SIGNAL_FRAME_BIT?
>>>
>>
>> The current one is
>>
>>  /* Signal frame context.  */
>> #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
>>
>> It is defined such a strange way to be binary backward compatible.
>> Since there is no such a problem with if REG_VALUE_IN_UNWIND_CONTEXT
>> is defined, I simply define it as
>>
>>  /* Signal frame context.  */
>> #define SIGNAL_FRAME_BIT ((_Unwind_Word) 1 >> 0)
>>
>
> Here is the updated patch.  OK for trunk if there are no regressions?
>
> Thanks.
>
> --
> H.J.
> ---
> gcc/
>
> 2011-06-30  H.J. Lu  
>
>        * config.gcc (libgcc_tm_file): Add i386/value-unwind.h for
>        Linux/x86.
>
>        * system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.
>
>        * unwind-dw2.c (_Unwind_Context_Reg_Val): New.
>        (_Unwind_Get_Unwind_Word): Likewise.
>        (_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
>        (_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
>        (SIGNAL_FRAME_BIT): Define if REG_VALUE_IN_UNWIND_CONTEXT is
>        defined.
>        (_Unwind_IsExtendedContext): Likewise.
>        (EXTENDED_CONTEXT_BIT): Don't define if REG_VALUE_IN_UNWIND_CONTEXT
>        is defined.
>        (_Unwind_GetGR): Updated.
>        (_Unwind_SetGR): Likewise.
>        (_Unwind_GetGRPtr): Likewise.
>        (_Unwind_SetGRPtr): Likewise.
>        (_Unwind_SetGRValue): Likewise.
>        (_Unwind_GRByValue): Likewise.
>        (__frame_state_for): Likewise.
>        (uw_install_context_1): Likewise.
>
>        * doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
>        * doc/tm.texi: Regenerated.
>
> libgcc/
>
> 2011-06-30  H.J. Lu  
>
>        * config/i386/value-unwind.h: New.
>

config.gcc has some extra changes for x32 and missed doc changes.
This one fixed them.  Sorry for that.

-- 
H.J.
gcc/

2011-06-30  H.J. Lu  

* config.gcc (libgcc_tm_file): Add i386/value-unwind.h for
Linux/x86.

* system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.

* unwind-dw2.c (_Unwind_Context_Reg_Val): New.
(_Unwind_Get_Unwind_Word): Likewise.
(_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
(_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
(SIGNAL_FRAME_BIT): Define if REG_VALUE_IN_UNWIND_CONTEXT is
defined.
(_Unwind_IsExtendedContext): Likewise.
(EXTENDED_CONTEXT_BIT): Don't define if REG_VALUE_IN_UNWIND_CONTEXT
is defined.
(_Unwind_GetGR): Updated.
(_Unwind_SetGR): Likewise.
(_Unwind_GetGRPtr): Likewise.
(_Unwind_SetGRPtr): Likewise.
(_Unwind_SetGRValue): Likewise.
(_Unwind_GRByValue): Likewise.
(__frame_state_for): Likewise.
(uw_install_context_1): Likewise.

* doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
* doc/tm.texi: Regenerated.

libgcc/

2011-06-30  H.J. Lu  

* config/i386/value-unwind.h: New.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 73c47d7..2702df2 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2630,6 +2651,7 @@ esac
 case ${target} in
 i[34567]86-*-linux* | x86_64-*-linux*)
tmake_file="${tmake_file} i386/t-pmm_malloc i386/t-i386"
+   libgcc_tm_file="${libgcc_tm_file} i386/value-unwind.h"
;;
 i[34567]86-*-* | x86_64-*-*)
tmake_file="${tmake_file} i386/t-gmm_malloc i386/t-i386"
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 341628b..2666716 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -3701,6 +3701,14 @@ return @code{@var{regno}}.
 
 @end defmac
 
+@defmac REG_VALUE_IN_UNWIND_CONTEXT
+
+Define this macro if the target stores register values as
+@code{_Unwind_Word} type in unwind context.  The default is to
+store register values as @code{void *} type.
+
+@end defmac
+
 @node Elimination
 @subsection Eliminating Frame Pointer and Arg Pointer
 
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index f7c16e9..690fa52 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3687,6 +3687,14 @@ return @code{@var{regno}}.
 
 @end defmac

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Thu, Jun 30, 2011 at 9:08 AM, H.J. Lu  wrote:
> On Thu, Jun 30, 2011 at 8:03 AM, Jason Merrill  wrote:
>> On 06/30/2011 10:42 AM, H.J. Lu wrote:
>>>
>>> Register may be saved/restored either by address or value. My patch
>>> doesn't change the reg field.  The other way will be
>>>
>>> #ifdef USE_UNWIND_WORD
>>>     _Unwind_Word reg[DWARF_FRAME_REGISTERS+1];
>>> #else
>>>      void *reg[DWARF_FRAME_REGISTERS+1];
>>> #endif
>>>
>>> We need it so that we are binary compatible with the existing
>>> unwind context.  Once we do that we need many
>>>
>>> #ifdef USE_UNWIND_WORD
>>> #endif
>>>
>>> whenever the reg field is accessed since the reg field is changed.
>>
>> But your patch already changes all but one place where reg is accessed.  And
>> we can avoid lots of ifdefs by abstraction with macros/inlines so there's
>> one interface.
>
> I can do that.
>
>> Also, why change SIGNAL_FRAME_BIT?
>>
>
> The current one is
>
>  /* Signal frame context.  */
> #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
>
> It is defined such a strange way to be binary backward compatible.
> Since there is no such a problem with if REG_VALUE_IN_UNWIND_CONTEXT
> is defined, I simply define it as
>
>  /* Signal frame context.  */
> #define SIGNAL_FRAME_BIT ((_Unwind_Word) 1 >> 0)
>

Here is the updated patch.  OK for trunk if there are no regressions?

Thanks.

-- 
H.J.
---
gcc/

2011-06-30  H.J. Lu  

* config.gcc (libgcc_tm_file): Add i386/value-unwind.h for
Linux/x86.

* system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.

* unwind-dw2.c (_Unwind_Context_Reg_Val): New.
(_Unwind_Get_Unwind_Word): Likewise.
(_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
(_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
(SIGNAL_FRAME_BIT): Define if REG_VALUE_IN_UNWIND_CONTEXT is
defined.
(_Unwind_IsExtendedContext): Likewise.
(EXTENDED_CONTEXT_BIT): Don't define if REG_VALUE_IN_UNWIND_CONTEXT
is defined.
(_Unwind_GetGR): Updated.
(_Unwind_SetGR): Likewise.
(_Unwind_GetGRPtr): Likewise.
(_Unwind_SetGRPtr): Likewise.
(_Unwind_SetGRValue): Likewise.
(_Unwind_GRByValue): Likewise.
(__frame_state_for): Likewise.
(uw_install_context_1): Likewise.

* doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
* doc/tm.texi: Regenerated.

libgcc/

2011-06-30  H.J. Lu  

* config/i386/value-unwind.h: New.
gcc/

2011-06-30  H.J. Lu  

* config.gcc (libgcc_tm_file): Add i386/value-unwind.h for
Linux/x86.

* system.h (REG_VALUE_IN_UNWIND_CONTEXT): Poisoned.

* unwind-dw2.c (_Unwind_Context_Reg_Val): New.
(_Unwind_Get_Unwind_Word): Likewise.
(_Unwind_Get_Unwind_Context_Reg_Val): Likewise.
(_Unwind_Context): Use _Unwind_Context_Reg_Val on the reg field.
(SIGNAL_FRAME_BIT): Define if REG_VALUE_IN_UNWIND_CONTEXT is
defined.
(_Unwind_IsExtendedContext): Likewise.
(EXTENDED_CONTEXT_BIT): Don't define if REG_VALUE_IN_UNWIND_CONTEXT
is defined.
(_Unwind_GetGR): Updated.
(_Unwind_SetGR): Likewise.
(_Unwind_GetGRPtr): Likewise.
(_Unwind_SetGRPtr): Likewise.
(_Unwind_SetGRValue): Likewise.
(_Unwind_GRByValue): Likewise.
(__frame_state_for): Likewise.
(uw_install_context_1): Likewise.

* doc/tm.texi.in: Document REG_VALUE_IN_UNWIND_CONTEXT.
* doc/tm.texi: Regenerated.

libgcc/

2011-06-30  H.J. Lu  

* config/i386/value-unwind.h: New.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 73c47d7..2702df2 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1277,7 +1277,17 @@ i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | 
i[34567]86-*-knetbsd*-gnu | i
if test x$enable_targets = xall; then
tm_file="${tm_file} i386/x86-64.h i386/gnu-user64.h 
i386/linux64.h"
tm_defines="${tm_defines} TARGET_BI_ARCH=1"
-   tmake_file="${tmake_file} i386/t-linux64"
+   case x${enable_x32}${enable_ia32} in
+   xyesyes)
+   tmake_file="${tmake_file} i386/t-linux-x32"
+   ;;
+   xyesno)
+   tmake_file="${tmake_file} i386/t-linux64-x32"
+   ;;
+   *)
+   tmake_file="${tmake_file} i386/t-linux64"
+   ;;
+   esac
need_64bit_hwint=yes
need_64bit_isa=yes
case X"${with_cpu}" in
@@ -1315,7 +1325,18 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu | 
x86_64-*-knetbsd*-gnu)
x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h 
i386/kfreebsd-gnu64.h" ;;
x86_64-*-knetbsd*-gnu) tm_file="${tm_fi

Re: [PATCH 04/12] vax: Emit prologue as rtl.

[Paul Koning]

On Jun 30, 2011, at 1:21 PM, Richard Henderson wrote:

> On 06/29/2011 04:01 PM, Steven Bosscher wrote:
>> How many TARGET_ASM_FUNCTION_{PRO,EPI}LOGUE targets are left anyway?
> 
> Answering the question that it sounds like you actually asked: 2 or 3.
> Not that it does us that much good because of the other uses.
> ...
> Users of TARGET_ASM_FUNCTION_PROLOGUE
> 
>   Outputs the real prologue
>   pdp11
>   rs6000  if !TARGET_SCHED_PROLOG
> ...

I intend to change pdp11 over to RTL based pro/epilogue in the not too distant 
future.

paul

[testsuite, libmudflap] Only use --noinhibit-exec with GNU ld (PR libmudflap/49549)

[Rainer Orth]

As reported in the PR, libmudflap.cth/cthfrags.exp unconditionally uses
-Wl,--noinhibit-exec, which is a GNU ld option unknown to Sun ld, even
though the Solaris 11 ld has implemented many of the GNU ld options.
This patch addresses this by providing an effective-target check for
gld, similar to the existing gas check, and using it.

I don't distinguish between GNU ld and gold here, which is probably
unnecessary for the most cases.

With this patch, libmudflap make check on sparc-sun-solaris2.11 (both
multilibs) produced the almost perfect results already reported in the
previous message.

Though I don't nominally need approval for this patch, I'll wait a day
if Mike or Frank have comments.

Rainer


2011-06-29  Rainer Orth  

PR libmudflap/49549
* testsuite/lib/libmudflap.exp (load_gcc_lib): Load
target-supports.exp.
* testsuite/libmudflap.cth/cthfrags.exp: Only pass
--noinhibit-exec to GNU ld.

gcc:
PR libmudflap/49549
* doc/sourcebuild.texi (Effective-Target Keywords): Document gld.

gcc/testsuite:
PR libmudflap/49549
* lib/target-supports.exp (check_effective_target_gld): New proc.

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1760,6 +1760,9 @@ Target uses GNU @command{as}.
 @item gc_sections
 Target supports @option{--gc-sections}.
 
+@item gld
+Target uses GNU @command{ld}.
+
 @item keeps_null_pointer_checks
 Target keeps null pointer checks, either due to the use of
 @option{-fno-delete-null-pointer-checks} or hardwired into the target.
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3843,6 +3843,26 @@ proc check_effective_target_gas { } {
 return $use_gas_saved
 }
 
+# Return 1 if GNU ld is used.
+
+proc check_effective_target_gld { } {
+global use_gld_saved
+global tool
+
+if {![info exists use_gld_saved]} {
+   # Check if the ld used by gcc is GNU ld.
+   set gcc_ld [lindex [${tool}_target_compile "-print-prog-name=ld" "" 
"none" ""] 0]
+   set status [remote_exec host "$gcc_ld" "--version"]
+   set ld_output [lindex $status 1]
+   if { [ string first "GNU" $ld_output ] >= 0 } {
+   set use_gld_saved 1
+   } else {
+   set use_gld_saved 0
+   }
+}
+return $use_gld_saved
+}
+
 # Return 1 if the compiler has been configure with link-time optimization
 # (LTO) support.
 
diff --git a/libmudflap/testsuite/lib/libmudflap.exp 
b/libmudflap/testsuite/lib/libmudflap.exp
--- a/libmudflap/testsuite/lib/libmudflap.exp
+++ b/libmudflap/testsuite/lib/libmudflap.exp
@@ -1,4 +1,4 @@
-# Copyright (C) 2001, 2002, 2003, 2004, 2009, 2010
+# Copyright (C) 2001, 2002, 2003, 2004, 2009, 2010, 2011
 # Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
@@ -30,6 +30,7 @@ proc load_gcc_lib { filename } {
 load_lib mfdg.exp
 load_lib libgloss.exp
 load_gcc_lib target-libpath.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib timeout.exp
 load_gcc_lib timeout-dg.exp
 
diff --git a/libmudflap/testsuite/libmudflap.cth/cthfrags.exp 
b/libmudflap/testsuite/libmudflap.cth/cthfrags.exp
--- a/libmudflap/testsuite/libmudflap.cth/cthfrags.exp
+++ b/libmudflap/testsuite/libmudflap.cth/cthfrags.exp
@@ -11,10 +11,15 @@ foreach flags $MUDFLAP_FLAGS {
set bsrc [file tail $srcfile]
setenv MUDFLAP_OPTIONS "-viol-segv"
if {$libmudflapth} then {
-   # --noinhibit-exec works around a ld problem that causes
-   # "Dwarf Error: Invalid or unhandled FORM value: 14"
-   # to fail builds unnecessarily.
-   dg-runtest $srcfile $flags "-fmudflapth -lmudflapth -lpthread 
-Wl,--noinhibit-exec"
+   if [check_effective_target_gld] {
+   # --noinhibit-exec works around a ld problem that causes
+   # "Dwarf Error: Invalid or unhandled FORM value: 14"
+   # to fail builds unnecessarily.
+   set noie_option " -Wl,--noinhibit-exec"
+   } else {
+   set noie_option ""
+   }
+   dg-runtest $srcfile $flags "-fmudflapth -lmudflapth -lpthread 
$noie_option"
} else {
if {$flags != ""} {set f " ($flags)"} {set f ""}
 untested "libmudflap.cth/$bsrc$f"

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

Re: [PATCH 04/12] vax: Emit prologue as rtl.

[Richard Henderson]

On 06/29/2011 04:01 PM, Steven Bosscher wrote:
> How many TARGET_ASM_FUNCTION_{PRO,EPI}LOGUE targets are left anyway?

Answering the question that it sounds like you actually asked: 2 or 3.
Not that it does us that much good because of the other uses.

FWIW, Alpha appears to be the only target that (ab)uses 
ASM_DECLARE_FUNCTION_NAME to output unwind info.  That might have been
a mistake, considering the interference that causes with using elfos.h.

I'm not sure what all the zeroing of backend variables that several 
targets are doing is for.  Better GC at the end of the function maybe?


r~

--


Users of TARGET_ASM_FUNCTION_PROLOGUE

   Outputs the real prologue
pdp11
rs6000  if !TARGET_SCHED_PROLOG

   Outputs assembly comments
arm
m32r
mep
picochip
rx

   Outputs unwind info
ia64(.regstk, .prologue)
microblaze  (.ent, .frame, .mask)
mips(.ent, .frame, .mask)
pa  (.PROC and .CALLINFO)
score   (.ent, .frame, .mask)

   Other
frv renaming of gr3?, frv_pack_insns
mipsmips16 function stub, gp load at function start
microblaze  add _interrupt_handler alias?
mmixinit register renaming?
rs6000  emit .extern as needed before uses?
sparc   emit .register as needed

Users of TARGET_ASM_FUNCTION_EPILOGUE

   Outputs the real epilogue
arm thumb1 only
pdp11
rs6000  if !TARGET_SCHED_PROLOG

   Outputs assembly comments
picochip
mmixactually just a newline?

   Outputs unwind info
microblaze  (.end)
mips(.end)
pa  (.PROCEND and stuff)
rs6000  aix traceback table
score   (.end)

   Other
arm validate some frame offsets?
frv reset variables
i386undo pic register renaming, darwin nop hack
ia64undo register renaming
m32rreset variables
microblaze  finish _interrupt_handler alias, reset variables
mipsundo pic register renaming
rs6000  darwin branch islands
sh  reset variables
sparc   unwind nop, deferred case vectors
xtensa  reset variables

Improve Solaris mudflap support (PR libmudflap/49550)

[Rainer Orth]

This is the first of two patches to get mudflap fully working on
Solaris 11, both with Sun ld and GNU ld.

It addresses a couple of testsuite failures:

* Several tests fail with 3 unexpected register violations:

***
mudflap violation 1 (register): time=1309356076.070433 ptr=21680 size=16
pc=7fa07a64
  
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/.libs/libmudflap.so.0.0.0'__mf_register+0x2c
 [0x7fa07a64]
  
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/.libs/libmudflap.so.0.0.0'__wrap_main+0x194
 [0x7fa07c18]
  
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/testsuite/heap-scalestress.exe'_start+0x5c
 [0x10afc]
Nearby object 1: checked region begins 0B into and ends 15B into
mudflap object a2aa8: name=`/usr/include/iso/stdio_iso.h:163:15 __iob'
bounds=[21680,217bf] size=320 area=static check=0r/0w liveness=0
alloc time=1309356076.069900 pc=7fa07a64
number of nearby objects: 1

  All 3 are 0, 16, or 32 bytes __iob[].  The error goes away with
  -no-heur-stdlib.

  If running the test with -trace-calls, I find:

mf: register ptr=21680 size=16 type=4 name='stdin'
mf: violation pc=7fa07b94 location= type=3 ptr=21680 size=16
***
mudflap violation 1 (register): time=1309365780.121411 ptr=21680 size=16
pc=7fa07b94
  
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/.libs/libmudflap.so.0.0.0'__mf_register+0x2c
 [0x7fa07b94]
  /var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/.l
ibs/libmudflap.so.0.0.0'__wrap_main+0x194 [0x7fa07d48]
  /var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/te
stsuite/heap-scalestress.exe'_start+0x5c [0x10afc]
Nearby object 1: checked region begins 0B into and ends 15B into
mudflap object a2aa8: name=`/usr/include/iso/stdio_iso.h:163:15 __iob'
bounds=[21680,217bf] size=320 area=static check=0r/0w liveness=0
alloc time=1309365780.077107 pc=7fa07b94
number of nearby objects: 1

  The conflict is between

mf: register ptr=21680 size=320 type=4 
name='/usr/include/iso/stdio_iso.h:163:15 __iob'

  and

mf: register ptr=21680 size=16 type=4 name='stdin'
mf: violation pc=7fa07260 location= type=3 ptr=21680 size=16

  where the registration of __iob has been done automatically by the
  compiler.  I avoid this problem by not registering stdin, stdout, and
  stderr separately on Solaris.

* Some tests were failing while calling unregister in munmap.  It turned
  out that there had been no corresponding mmap registration before.
  This occurs because Solaris has mmap64 for largefile-aware programs
  instead.  Fixed by wrapping mmap64, too.  What I don't know is if
  mmap64 needs to be added to MFWRAP_SPEC in gcc.c?  If so, I'd rather
  do it by adding some MFWRAP_OS_SPEC to avoid having to duplicate the
  whole spec in the Solaris config headers.

* As noted in the last patch, the getmntent signature differs in
  Solaris.  This patch implements a wrapper for the Solaris version.

* libmudflap.cth/pass37-frag.c would fail like this:

***
mudflap violation 1 (unregister): time=1309444614.922185 ptr=7f9e90a4 size=4
pc=7fa07e78
  
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/.libs/libmudflapth.so.0.0.0'__mf_unregister+0xec
 [0x7fa07e78]
  
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/.libs/libmudflapth.so.0.0.0'__mf_pthread_cleanup+0x4c
 [0x7fa277dc]
  
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libmudflap/.libs/libmudflapth.so.0.0.0'__mf_pthread_spawner+0x14c
 [0x7fa27938]
Nearby object 1: checked region begins 0B into and ends 3B into
mudflap object a43b8: name=`errno area'
bounds=[7f9e90a4,7f9e90a7] size=4 area=static check=0r/0w liveness=0
alloc time=1309444614.909941 pc=7fa077e8 thread=1
number of nearby objects: 1
FAIL: libmudflap.cth/pass37-frag.c execution test

  Investigating with -trace-calls reveals that all registrations and
  unregistrations of errno are for the same address, which is wrong for
  multithreaded programs which access errno via an accessor function.
  To enable that,  needs to be included with _REENTRANT
  defined.  It turned out that it suffices to do this in mf-hooks3.c.

* libmudflap.c/heap-scalestress.c always timed out on my SPARC test
  system: on a 1.2 GHz UltraSPARC-T2, it takes

real8:47.06
user  43.12
sys 8:03.77

  which is way over the limit.  On my laptop (1.6 GHz Core i7), it takes

real  37.35
user   5.06
sys   32.23

  I've divided SCALE by 10 to account for this.

* I've replaced all the __FreeBSD__ && ... tests in
  libmudflap.c/pass-stratcliff.c with appropriate autoconf macros, and
  also define MIN which can be missing.

* libmudflap.c/pass47-frag.c originally failed like this:

FAIL: libmudflap.c/pass47-frag.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/libmudflap/testsuite/libmudflap.c/pass47-frag.c:10:1:
 warning: mudfl

Re: [PATCH] [Annotalysis] Fixes virtual method calls when type is unknown

[Diego Novillo]

On 11-06-30 13:01 , Delesley Hutchins wrote:

This bug fixes a failure in annotalysis that is caused when gcc does
not return the correct static type for the callee of a virtual method.

Bootstrapped and passed GCC regression testsuite on x86_64-unknown-linux-gnu.

Okay for branches/annotalysis and google/main?


OK with some minor formatting nits below.


2011-06-30   DeLesley Hutchins
 * tree-threadsafe-analyze.c (handle_call_gs): Fixes case where
the virtual
 method callee has unknown type.


Blank line after address line.
Watch for line wrapping past 80 columns.



tree objtype = TREE_TYPE (TREE_TYPE (OBJ_TYPE_REF_OBJECT (callee)));
-  fdecl = lang_hooks.get_virtual_function_decl (callee, objtype);
+  /* Check to make sure objtype is a valid type.
+   * OBJ_TYPE_REF_OBJECT does not always return the correct
static type of the callee.
+   * For example:  Given  foo(void* ptr) { ((Foo*)
ptr)->doSomething(); }
+   * objtype will be void, not Foo.  Whether or not this
happens depends on the details
+   * of how a particular call is lowered to GIMPLE, and there
is no easy fix that works
+   * in all cases.  For now, we simply rely on gcc's type
information; if that information
+   * is not accurate, then the analysis will be less precise.
+   */


Don't use leading '*' in multi-line comments.
s/gcc/GCC/


+  if (TREE_CODE(objtype) == RECORD_TYPE)  /* if objtype is an
object type... */


Comments at the end of a line are rarely used.  No need to add one in 
this case.



+{
+  fdecl = lang_hooks.get_virtual_function_decl (callee, objtype);
+}


No need to add braces here.


Thanks.  Diego.

Re: [PATCH] Add support on powerpc to change CASE_VALUES_THRESHOLD

[Michael Meissner]

On Thu, Jun 30, 2011 at 12:31:44PM +0200, Richard Guenther wrote:
> On Thu, Jun 30, 2011 at 12:34 AM, Michael Meissner
>  wrote:
> > On the powerpc, switch statements can be expensive, and we would like to be
> > able to tune the threshold of when the compiler generates if statements
> > vs. using a table jump operation (and different processors within the 
> > powerpc
> > have different limits).  This patch adds a powerpc tuning option to control
> > this.
> >
> > I've done bootstraps and make checks with no regressions.  Is this ok to 
> > apply
> > to the trunk?  At this time, I am not changing the default value (4).  With 
> > the
> > option, I've seen a few spec 2006 benchmarks run faster, and a few run 
> > slower.
> 
> Hmm.  This hook looks like it could be turned into a --param.  In fact
> it doesn't get whatever context information, so I wonder if any target
> does something fancy.

I've done it also as a --param.  I tend to think it is better as a param, and
then other people can tune their code.  One slight problem is the default for
CASE_VALUES_THRESHOLD depends on whether you have a named casesi pattern that
is active (HAVE_casesi ? 4 : 5).  Either we need two separate parameters, or we
have just one parameter, and if that is 0, fall back to the 4 or 5 value.

This patch swtiches to use --param to set the value.  Is it acceptable to check
in?  I've done a bootstrap and I'm about to do a make check.

[gcc]
2011-06-30  Michael Meissner  

* params.def (PARAM_CASE_VALUES_THRESHOLD): New parameter to
override CASE_VALUES_THRESHOLD.

* stmt.c (toplevel): Include params.h.
(case_values_threshold): Use the --param case-values-threshold
value if non-zero, otherwise use machine dependent value.
(expand_case): Use case_values_threshold.

* Makefile.in (stmt.o): Add $(PARAMS_H) dependency.

* doc/invoke.texi (--param case-values-threshold): Document.

[gcc/testsuite]
2011-06-30  Michael Meissner  

* gcc.target/powerpc/ppc-switch-1.c: New test for
-mcase-values-threshold.
* gcc.target/powerpc/ppc-switch-2.c: Ditto.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 175662)
+++ gcc/doc/invoke.texi (working copy)
@@ -9026,6 +9026,11 @@ The maximum number of conditional stores
 if either vectorization (@option{-ftree-vectorize}) or if-conversion
 (@option{-ftree-loop-if-convert}) is disabled.  The default is 2.
 
+@item case-values-threshold
+The smallest number of different values for which it is best to use a
+jump-table instead of a tree of conditional branches.  If the value is
+0, use the default for the machine.  The default is 0.
+
 @end table
 @end table
 
Index: gcc/testsuite/gcc.target/powerpc/ppc-switch-1.c
===
--- gcc/testsuite/gcc.target/powerpc/ppc-switch-1.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/ppc-switch-1.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-options "-O2 --param case-values-threshold=2" } */
+/* { dg-final { scan-assembler "mtctr" } } */
+/* { dg-final { scan-assembler "bctr" } } */
+
+/* Force using a dispatch table even though by default we would generate
+   ifs.  */
+
+extern long call (long);
+
+long
+test_switch (long a, long b)
+{
+  long c;
+
+  switch (a)
+{
+case 0:  c = -b;   break;
+case 1:  c = ~b;   break;
+case 2:  c = b+1;  break;
+default: c = b & 9;break;
+}
+
+  return call (c) + 1;
+}
Index: gcc/testsuite/gcc.target/powerpc/ppc-switch-2.c
===
--- gcc/testsuite/gcc.target/powerpc/ppc-switch-2.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/ppc-switch-2.c (revision 0)
@@ -0,0 +1,32 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-options "-O2 --param case-values-threshold=20" } */
+/* { dg-final { scan-assembler-not "mtctr" } } */
+/* { dg-final { scan-assembler-not "bctr" } } */
+
+/* Force using if tests, instead of a dispatch table.  */
+
+extern long call (long);
+
+long
+test_switch (long a, long b)
+{
+  long c;
+
+  switch (a)
+{
+case 0:  c = -b;   break;
+case 1:  c = ~b;   break;
+case 2:  c = b+1;  break;
+case 3:  c = b-2;  break;
+case 4:  c = b*3;  break;
+case 5:  c = b/4;  break;
+case 6:  c = b<<5; break;
+case 7:  c = b>>6; break;
+case 8:  c = b|7;  break;
+case 9:  c = b^8;  break;
+default: c = b&9;  break;
+}
+
+  return call (c) + 1;
+}
Index: gcc/Makefile.in
==

[PATCH] [Annotalysis] Fixes virtual method calls when type is unknown

[Delesley Hutchins]

This bug fixes a failure in annotalysis that is caused when gcc does
not return the correct static type for the callee of a virtual method.

Bootstrapped and passed GCC regression testsuite on x86_64-unknown-linux-gnu.

Okay for branches/annotalysis and google/main?

  -DeLesley


2011-06-30   DeLesley Hutchins  
* tree-threadsafe-analyze.c (handle_call_gs): Fixes case where
the virtual
method callee has unknown type.


Index: gcc/testsuite/g++.dg/thread-ann/thread_annot_lock-79.C
===
--- gcc/testsuite/g++.dg/thread-ann/thread_annot_lock-79.C  (revision 0)
+++ gcc/testsuite/g++.dg/thread-ann/thread_annot_lock-79.C  (revision 0)
@@ -0,0 +1,54 @@
+// Test virtual method calls in cases where the static type is unknown
+// This is a "good" test case that should not incur any thread safety warning.
+// { dg-do compile }
+// { dg-options "-Wthread-safety -O" }
+
+#include "thread_annot_common.h"
+
+class Foo {
+public:
+  Mutex m;
+
+  Foo();
+  virtual ~Foo();
+  virtual void doSomething() EXCLUSIVE_LOCKS_REQUIRED(m) = 0;
+};
+
+
+class FooDerived : public Foo {
+public:
+  FooDerived();
+  virtual ~FooDerived();
+  virtual void doSomething();
+};
+
+
+/**
+ * This is a test case for a bug wherein annotalysis would crash when
analyzing
+ * a virtual method call.
+ *
+ * The following three functions represent cases where gcc loses the static
+ * type of foo in the expression foo->doSomething() when it drops down to
+ * gimple.  Annotalysis should technically issue a thread-safe
warning in these
+ * cases, but because the type is missing, it should silently accept them
+ * instead.  See tree-threadsafe-analyze.c::handle_call_gs.
+ */
+
+// reinterpret_cast
+void foo1(void* ptr)
+{
+  reinterpret_cast(ptr)->doSomething();
+}
+
+// C-style cast
+void foo2(int* buf)
+{
+  ((Foo*) buf)->doSomething();
+}
+
+// new expression, with no local variable
+void foo3()
+{
+  (new FooDerived)->doSomething();
+}
+
Index: gcc/tree-threadsafe-analyze.c
===
--- gcc/tree-threadsafe-analyze.c   (revision 175385)
+++ gcc/tree-threadsafe-analyze.c   (working copy)
@@ -2446,7 +2446,18 @@
   if (TREE_CODE (callee) == OBJ_TYPE_REF)
 {
   tree objtype = TREE_TYPE (TREE_TYPE (OBJ_TYPE_REF_OBJECT (callee)));
-  fdecl = lang_hooks.get_virtual_function_decl (callee, objtype);
+  /* Check to make sure objtype is a valid type.
+   * OBJ_TYPE_REF_OBJECT does not always return the correct
static type of the callee.
+   * For example:  Given  foo(void* ptr) { ((Foo*)
ptr)->doSomething(); }
+   * objtype will be void, not Foo.  Whether or not this
happens depends on the details
+   * of how a particular call is lowered to GIMPLE, and there
is no easy fix that works
+   * in all cases.  For now, we simply rely on gcc's type
information; if that information
+   * is not accurate, then the analysis will be less precise.
+   */
+  if (TREE_CODE(objtype) == RECORD_TYPE)  /* if objtype is an
object type... */
+{
+  fdecl = lang_hooks.get_virtual_function_decl (callee, objtype);
+}
 }
 }

Re: [Patch] Fix objc/48109

[Iain Sandoe]

Hi Richard(s),

thanks for the reviews.

before re-jigging - a couple of questions / points below.

On 30 Jun 2011, at 16:12, Richard Henderson wrote:


On 06/30/2011 03:56 AM, Richard Guenther wrote:
It is only used by darwin at present - so nothing is split out  
for any other

target (the default hook is simply 'false').
Yes, I've seen that.  Still a hook like this should be generally  
useful,

and you still process through some pieces of assemble_variable
while you choose to skip some other piece - it should probably be
documented which part of assemble_variable is supposed to be handled
by the hook.


Yes, in order to avoid duplication of code, I placed the hook after  
all the set-up actions had been completed, but before any actual output.


Perhaps it would be better just to make the hook the first line of  
assemble_variable () and let the target take a (hopefully small) hit  
on replication of some of the actions of the varasm.c code.


Otherwise, noted about doc.


I'll defer to Richard for this (and the approval).



I definitely want to see better documentation.  I don't know how to
review the patch at the moment.  Some background for us non-darwin
programmers would help as well; I don't know what's legal and what
isn't when it comes to these sorts of odd non-definitions.


I guess, we new chaps assume you gurus know all... ;-) sorry...

An explanation here - as to what the hook is used for in this case.

I am not sure as to where the explanation needs to go (it doesn't seem  
appropriate for the hook, since that might be used for other purposes  
by other targets).


===

m32 Objective C (NeXT runtime) makes use of  anonymous meta-data,  
generated by the FE;
These data can be found by the runtime initialization - because they  
have a known organization and are placed in known sections.


However, because they are anonymous, there are no definitions or  
references to force the linker to include modules which only contain  
classes.


To cater for this, we have a class of symbols that are recognized by  
the darwin ld (ones beginning with ".objc_class_name_").  Satisfying  
linkage of these symbols is what ensures that appropriate modules are  
bound into the exe.


--

we arrange for the definitions to be emitted by asm like:

.objc_class_name_MyClass = 0

.. and we arrange for the references to be generated by emitting:

.lazy_reference .objc_class_name_MyClass

in neither case is any memory allocated for the entities represented.

In fact, one cannot allocate real memory and make a global  
objc_class_name_MyClass pointing to it - (which is essentially what  
GNU runtime does)  because, darwin's ld will recognize that it is not  
what's expected and fail (I tried that early on in seeking a solution)


The use of the hook is to allow us to generate 'real' variables for  
these items - and yet still intercept them and output the necessary asm.


That's the explanation - I think that it's present in darwin.c (in a  
shorter form) already.  I could expand on that and also replicate the  
discussion in objc-next-runtime-abi-01.c.


- would that be suitable?


You're changing the set of variables emitted for non-darwin here
too, as far as I can tell.  Is that actually desired?  I can't
imagine what these variables are intended to achieve, given that
they're byte sized and DECL_INITIAL = error_mark_node.


At present, non-NeXT targets (OK, that means non-mach-o as well,  
but..) the only real requirements are:


(a) that objc-next-runtime-abi-01.c should compile cleanly.
(b) that if someone invoked the function by some mistake elsewhere  
within ObjC, the result should be an error.


So, yes, if a non-darwin target were to call handle_next_impent () or  
handle_next_class_ref () the idea would be to cause a fail.
(perhaps there's a better way to do this - but it seemed reasonable at  
the time).


---

I'll address the other points as I re-jig.

thanks again,
Iain

Re: [PATCH, PR 49094] Refrain from creating misaligned accesses in SRA

[Martin Jambor]

Hi,

On Thu, Jun 30, 2011 at 03:39:55PM +0200, Martin Jambor wrote:
> Hi,
> 
> I had to add a test that the analyzed expression is not an SSA name.
> This has been approved by Rchi on IRC yesterday.  Thus, I have
> committed the following as revision 175703 after successful run of c
> and c++ testsuite on sparc64 (and a bootstrap and test with another
> patch on x86_64-linux).

I also tested fortran on sparc64 but missed a regression there
(gfortran.dg/pr25923.f90).  The problem is that *arg_1(D) is also
scrutinized, get_object_alignment returns 8 for it and that is
obviously not enough for SImode required alignment.

I assume such loads have to be aligned for the mode on strict aligned
targets and therefore they are OK.  The question is, is that true for
all MEM_REFs or only for those with zero offset?  Since the original
problem was that the expander expanded

MEM[(struct ip *)ip_3 + 7B].s_addr;

as if it was aligned, I suppose that MEM_REFs are generally fine and
we can avoid this issue by skipping them just like the SSA_NAMEs.  Is
my reasoning correct?

Thanks,

Martin


> 
> Thanks,
> 
> Martin
> 
> 
> 2011-06-30  Martin Jambor  
> 
>   PR tree-optimization/49094
>   * tree-sra.c (tree_non_mode_aligned_mem_p): New function.
>   (build_accesses_from_assign): Use it.
> 
>   * testsuite/gcc.dg/tree-ssa/pr49094.c: New test.
> 
> 
> Index: src/gcc/tree-sra.c
> ===
> --- src.orig/gcc/tree-sra.c
> +++ src/gcc/tree-sra.c
> @@ -1050,6 +1050,26 @@ disqualify_ops_if_throwing_stmt (gimple
>return false;
>  }
>  
> +/* Return true iff type of EXP is not sufficiently aligned.  */
> +
> +static bool
> +tree_non_mode_aligned_mem_p (tree exp)
> +{
> +  enum machine_mode mode = TYPE_MODE (TREE_TYPE (exp));
> +  unsigned int align;
> +
> +  if (TREE_CODE (exp) == SSA_NAME
> +  || mode == BLKmode
> +  || !STRICT_ALIGNMENT)
> +return false;
> +
> +  align = get_object_alignment (exp, BIGGEST_ALIGNMENT);
> +  if (GET_MODE_ALIGNMENT (mode) > align)
> +return true;
> +
> +  return false;
> +}
> +
>  /* Scan expressions occuring in STMT, create access structures for all 
> accesses
> to candidates for scalarization and remove those candidates which occur in
> statements or expressions that prevent them from being split apart.  
> Return
> @@ -1074,7 +1094,10 @@ build_accesses_from_assign (gimple stmt)
>lacc = build_access_from_expr_1 (lhs, stmt, true);
>  
>if (lacc)
> -lacc->grp_assignment_write = 1;
> +{
> +  lacc->grp_assignment_write = 1;
> +  lacc->grp_unscalarizable_region |= tree_non_mode_aligned_mem_p (rhs);
> +}
>  
>if (racc)
>  {
> @@ -1082,6 +1105,7 @@ build_accesses_from_assign (gimple stmt)
>if (should_scalarize_away_bitmap && !gimple_has_volatile_ops (stmt)
> && !is_gimple_reg_type (racc->type))
>   bitmap_set_bit (should_scalarize_away_bitmap, DECL_UID (racc->base));
> +  racc->grp_unscalarizable_region |= tree_non_mode_aligned_mem_p (lhs);
>  }
>  
>if (lacc && racc
> Index: src/gcc/testsuite/gcc.dg/tree-ssa/pr49094.c
> ===
> --- /dev/null
> +++ src/gcc/testsuite/gcc.dg/tree-ssa/pr49094.c
> @@ -0,0 +1,38 @@
> +/* { dg-do run } */
> +/* { dg-options "-O" } */
> +
> +struct in_addr {
> + unsigned int s_addr;
> +};
> +
> +struct ip {
> + unsigned char ip_p;
> + unsigned short ip_sum;
> + struct  in_addr ip_src,ip_dst;
> +} __attribute__ ((aligned(1), packed));
> +
> +struct ip ip_fw_fwd_addr;
> +
> +int test_alignment( char *m )
> +{
> +  struct ip *ip = (struct ip *) m;
> +  struct in_addr pkt_dst;
> +  pkt_dst = ip->ip_dst ;
> +  if( pkt_dst.s_addr == 0 )
> +return 1;
> +  else
> +return 0;
> +}
> +
> +int __attribute__ ((noinline, noclone))
> +intermediary (char *p)
> +{
> +  return test_alignment (p);
> +}
> +
> +int
> +main (int argc, char *argv[])
> +{
> +  ip_fw_fwd_addr.ip_dst.s_addr = 1;
> +  return intermediary ((void *) &ip_fw_fwd_addr);
> +}

Re: [PATCH][PING] Backport PR42333 fix to gcc 4.5

[Mike Stump]

On Jun 19, 2011, at 7:07 PM, Jack Howarth wrote:
>   I requested a backport to gcc-4_5-branch of the fix for PR42333 awhile
> back...
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01098.html
> 
> Can we get that committed?

Yes.  Applied for 4.5.4.  Thanks for your dedication.

Re: [trans-mem] Beginning of refactoring

[Torvald Riegel]

On Thu, 2011-06-30 at 07:59 -0700, Richard Henderson wrote:
> I'm not sure what to make of your first two examples above, but
> let's suppose that the third example is the real one.  In which
> case you don't actually need concatenation.  Remove the ## from
> the macro and then you can pass in
> 
>   GTM::abi_disp()->
> and
>   GTM::serial_dispatch::
> 
> which require no more than adjacency.

Good point, thanks. Fixed it, and will commit this and the others to the
branch.

Torvald

Re: [PATCH][Revised] Pass -no_pie on SYSTEMSPEC for darwin11

[Mike Stump]

On Jun 19, 2011, at 4:55 PM, Jack Howarth wrote:
>>> This is definitely a problem in current gcc-4_5-branch without the backport 
>>> of the SYSTEMSPEC fix...
>> 
>> Excellent...  and does the patch fix it?
> 
> Yes...

Ok, applied to the 4.5 branch.  Scream loud and soon if for any reason you 
notice anything that isn't release quality.  I think we have enough bake time 
on 4.6 and mainline to avoid any downsides, but, also nice to be careful with 
the release branches.  Thanks for all your help.

Index: configure.ac
===
--- configure.ac(revision 175709)
+++ configure.ac(working copy)
@@ -882,8 +882,13 @@ case "${host}" in
 SYSTEMSPEC="-lunicows $SYSTEMSPEC"
   fi
 ;;
-*-*-darwin[[912]]*)
-  SYSTEMSPEC="-allow_stack_execute"
+*-*-darwin9*)
+  SYSTEMSPEC="%{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}"
+;;
+*-*-darwin[[12]]*)
+  # Something is incompatible with pie, would be nice to fix it and
+  # remove -no_pie.  PR49461
+  SYSTEMSPEC="-no_pie %{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}"
 ;;
 *)
   SYSTEMSPEC=
Index: ChangeLog
===
--- ChangeLog   (revision 175709)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2011-06-30  Jack Howarth 
+
+   PR target/49461
+   * libjava/configure.ac (SYSTEMSPEC): Pass -no_pie for darwin11.
+   * libjava/configure: Regenerate.
+
 2011-04-28  Release Manager
 
* GCC 4.5.3 released.
Index: configure
===
--- configure   (revision 175709)
+++ configure   (working copy)
@@ -19754,8 +19754,13 @@ case "${host}" in
 SYSTEMSPEC="-lunicows $SYSTEMSPEC"
   fi
 ;;
-*-*-darwin[912]*)
-  SYSTEMSPEC="-allow_stack_execute"
+*-*-darwin9*)
+  SYSTEMSPEC="%{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}"
+;;
+*-*-darwin[12]*)
+  # Something is incompatible with pie, would be nice to fix it and
+  # remove -no_pie.  PR49461
+  SYSTEMSPEC="-no_pie %{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}"
 ;;
 *)
   SYSTEMSPEC=

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Thu, Jun 30, 2011 at 8:03 AM, Jason Merrill  wrote:
> On 06/30/2011 10:42 AM, H.J. Lu wrote:
>>
>> Register may be saved/restored either by address or value. My patch
>> doesn't change the reg field.  The other way will be
>>
>> #ifdef USE_UNWIND_WORD
>>     _Unwind_Word reg[DWARF_FRAME_REGISTERS+1];
>> #else
>>      void *reg[DWARF_FRAME_REGISTERS+1];
>> #endif
>>
>> We need it so that we are binary compatible with the existing
>> unwind context.  Once we do that we need many
>>
>> #ifdef USE_UNWIND_WORD
>> #endif
>>
>> whenever the reg field is accessed since the reg field is changed.
>
> But your patch already changes all but one place where reg is accessed.  And
> we can avoid lots of ifdefs by abstraction with macros/inlines so there's
> one interface.

I can do that.

> Also, why change SIGNAL_FRAME_BIT?
>

The current one is

  /* Signal frame context.  */
#define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)

It is defined such a strange way to be binary backward compatible.
Since there is no such a problem with if REG_VALUE_IN_UNWIND_CONTEXT
is defined, I simply define it as

  /* Signal frame context.  */
#define SIGNAL_FRAME_BIT ((_Unwind_Word) 1 >> 0)

Thanks.

-- 
H.J.

Re: [PATCH] Sign extend before converting constants to GMP values.

[Sebastian Pop]

On Thu, Jun 30, 2011 at 10:03, Richard Guenther  wrote:
> But what do you do for
>
>  for (unsigned char i = 128; i < 255; ++i)
>
> ?  You change 128 to -128 which is wrong.

Yes, 128 gets translated to -128.
And 255 gets translated to -1.
And so the loop iteration domain gets translated in the polyhedral form
as going from -128 to -1 with strides of 1.
So this particular program is not miscompiled by graphite:

int main ()
{
  unsigned char j;
  int x[300];
  for (j = 128; j < 255; j++)
x[j] = j;

  for (j = 128; j < 255; j++)
if (x[j] != j)
  __builtin_abort ();

  return 0;
}

I was trying to build a program that fails to attach to the PR.

> So yes, you also have to
> deal with modulo arithmetic in graphite.

I'm trying to understand where we have to deal with the modulo arithmetic.
Tobias, what are you doing in Polly?
Do you insert the loop iteration domain constraints with the modulo
of the types?

Sebastian

Re: [PATCH] Fix empty .debug_abbrev handling (PR debug/49364)

[Rainer Orth]

Jakub,

> the label in that case at all.  Rainer, does this make SGI tools
> happy?

to try this, I'll have to do a full rebuild which is quite slow.  I'll
see during the next bootstrap this weekend.

Thanks.
Rainer

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

Re: [PATCH] Handle vectorization of invariant loads (PR46787)

[Richard Guenther]

On Wed, 29 Jun 2011, Richard Guenther wrote:

> 
> The following patch makes us handle invariant loads during vectorization.
> Dependence analysis currently isn't clever enough to disambiguate them
> thus we insert versioning-for-alias checks.  For the testcase hoisting
> the load is still always possible though, and for a read-after-write
> dependence it would be possible for the vectorized loop copy as the
> may-aliasing write is varying by the scalar variable size.
> 
> The existing code for vectorizing invariant accesses looks very
> suspicious - it generates a vector load at the scalar address
> to then just extract the first vector element.  Huh.  IMHO this
> can be simplified as done, by just re-using the scalar load result.
> But maybe this code was supposed to deal with something entirely
> different?
> 
> This patch gives a 33% speedup to the phoronix himeno testcase
> if you bump the maximum alias versioning checks we want to insert.
> 
> I'm currently re-bootstrapping & testing this but an earlier version
> was ok on x86_64-unknown-linux-gnu.

FYI, I'm testing the following which cures a fallout seen when
building SPEC2k6 with the committed patch.  It's suboptimal for
j != 0 though - is there a way to get to the vectorized stmt
of the j == 0 iteration?

Thanks,
Richard.

2011-06-30  Richard Guenther  

* tree-vect-stmts.c (vectorizable_load): Remove unnecessary
assert.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 175709)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -4574,19 +4574,14 @@ vectorizable_load (gimple stmt, gimple_s
  /* 4. Handle invariant-load.  */
  if (inv_p && !bb_vinfo)
{
+ tree vec_inv;
+ gimple_stmt_iterator gsi2 = *gsi;
  gcc_assert (!strided_load);
- if (j == 0)
-   {
- tree vec_inv;
- gimple_stmt_iterator gsi2 = *gsi;
- gsi_next (&gsi2);
- vec_inv = build_vector_from_val (vectype, scalar_dest);
- new_temp = vect_init_vector (stmt, vec_inv,
-  vectype, &gsi2);
- new_stmt = SSA_NAME_DEF_STMT (new_temp);
-   }
- else
-   gcc_unreachable (); /* FORNOW. */
+ gsi_next (&gsi2);
+ vec_inv = build_vector_from_val (vectype, scalar_dest);
+ new_temp = vect_init_vector (stmt, vec_inv,
+  vectype, &gsi2);
+ new_stmt = SSA_NAME_DEF_STMT (new_temp);
}
 
  if (negative)

Re: [Patch] Fix objc/48109

[Richard Henderson]

On 06/30/2011 03:56 AM, Richard Guenther wrote:
>> > It is only used by darwin at present - so nothing is split out for any 
>> > other
>> > target (the default hook is simply 'false').
> Yes, I've seen that.  Still a hook like this should be generally useful,
> and you still process through some pieces of assemble_variable
> while you choose to skip some other piece - it should probably be
> documented which part of assemble_variable is supposed to be handled
> by the hook.
> 
> I'll defer to Richard for this (and the approval).
> 

I definitely want to see better documentation.  I don't know how to
review the patch at the moment.  Some background for us non-darwin
programmers would help as well; I don't know what's legal and what
isn't when it comes to these sorts of odd non-definitions.

You're changing the set of variables emitted for non-darwin here
too, as far as I can tell.  Is that actually desired?  I can't
imagine what these variables are intended to achieve, given that
they're byte sized and DECL_INITIAL = error_mark_node.

I can say that you need to watch the formatting.  There are missing
spaces after commas, and incorrect indentation.

> +  if (DECL_ATTRIBUTES (decl)
> +  && (meta = lookup_attribute ("OBJC1META", DECL_ATTRIBUTES (decl 

Do not assign to variables inside if conditions.  No need to check
for DECL_ATTRIBUTES non-null before calling lookup_attribute.

Re: [PATCH] Sign extend before converting constants to GMP values.

[Richard Guenther]

On Thu, 30 Jun 2011, Sebastian Pop wrote:

> On Thu, Jun 30, 2011 at 09:57, Sebastian Pop  wrote:
> >> Canonically extended according to TYPE_UNSIGNED I mean.  So what you
> >> do is always create signed mpzs - that should simply work without
> >> doing anything to the double-int.  Thus, why not do
> >>
> >> static inline void
> >> tree_int_to_gmp (tree t, mpz_t res)
> >> {
> >>  double_int di = tree_to_double_int (t);
> >>  mpz_set_double_int (res, di, false);
> >> }
> >>
> >> ?
> 
> I tried that and just passing false does not fix PR47653.
> You still have the problem of the unsigned decrementing induction variable
> that I described.

Well, you have to properly translate unsigned (modulo arithmetic)
IVs to signed mpz arithmetic.  Which isn't possible in all cases
(where modulo arithmetic matters).  I don't think that
tree_int_to_gmp is the place where this translation should happen.

Esp. because it then no longer is tree_int_to_gmp.

Richard.

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[Jason Merrill]

On 06/30/2011 10:42 AM, H.J. Lu wrote:

Register may be saved/restored either by address or value. My patch
doesn't change the reg field.  The other way will be

#ifdef USE_UNWIND_WORD
 _Unwind_Word reg[DWARF_FRAME_REGISTERS+1];
#else
  void *reg[DWARF_FRAME_REGISTERS+1];
#endif

We need it so that we are binary compatible with the existing
unwind context.  Once we do that we need many

#ifdef USE_UNWIND_WORD
#endif

whenever the reg field is accessed since the reg field is changed.


But your patch already changes all but one place where reg is accessed. 
 And we can avoid lots of ifdefs by abstraction with macros/inlines so 
there's one interface.


Also, why change SIGNAL_FRAME_BIT?

Jason

[PATCH] Address lowering [3/3] Test suite additions and changes

[William J. Schmidt]

Here is the third patch related to address lowering.  It contains the
changes to the test suite:  13 new tests, and 18 tests that needed to be
modified.  The latter occur because of specific patterns expected in
tree dumps; for example, a field reference x.f might now be expected to
be a MEM_REF instead.  In a couple of cases, I found it preferable to
disable address lowering for the test.

Thanks,
Bill

2011-06-30  Bill Schmidt  

PR rtl-optimization/46556
* testsuite/gcc.target/powerpc/ppc-loweraddr-1.c: New.
* testsuite/gcc.target/powerpc/ppc-loweraddr-2.c: New.
* testsuite/gcc.target/powerpc/ppc-loweraddr-3.c: New.
* testsuite/gcc.target/powerpc/ppc-loweraddr-4.c: New.
* testsuite/gcc.target/powerpc/ppc-loweraddr-5.c: New.
* testsuite/gcc.target/powerpc/extract-3.c: New.
* testsuite/gcc.target/powerpc/extract-3a.c: New.
* testsuite/gcc.target/i386/pr24178.c: Disable address lowering.
* testsuite/gfortran.dg/reassoc_3.f90: Change expected pattern.
* testsuite/gcc.dg/union-4a.c: New.
* testsuite/gcc.dg/pr38984.c: Change expected pattern.
* testsuite/gcc.dg.torture/pr42898-2.c: Disable for -O0; change
expected pattern.
* testsuite/gcc.dg.torture/pr42898.c: Likewise.
* testsuite/gcc.dg/tree-ssa/sra-7.c: Change expected pattern.
* testsuite/gcc.dg/tree-ssa/pr47286.c: Likewise.
* testsuite/gcc.dg/tree-ssa/pr16721.c: Likewise.
* testsuite/gcc.dg/tree-ssa/20030709-2.c: Likewise.
* testsuite/gcc.dg/tree-ssa/loweraddr-1.c: New.
* testsuite/gcc.dg/tree-ssa/loweraddr-2.c: New.
* testsuite/gcc.dg/tree-ssa/loweraddr-3.c: New.
* testsuite/gcc.dg/tree-ssa/loweraddr-4.c: New.
* testsuite/gcc.dg/tree-ssa/loweraddr-5.c: New.
* testsuite/gcc.dg/tree-ssa/loweraddr-6.c: New.
* testsuite/gcc.dg/tree-ssa/alias_bug.c: Change expected pattern.
* testsuite/gcc.dg/tree-ssa/alias-6.c: Likewise.
* testsuite/gcc.dg/tree-ssa/alias-11.c: Likewise.
* testsuite/g++.dg/opt/pr30965.C: Likewise.
* testsuite/g++.dg/tree-ssa/pr27090.C: Likewise.
* testsuite/g++.dg/tree-ssa/tmmti-2.C: Likewise.
* testsuite/g++.dg/tree-ssa/pointer-reference-alias.C: Likewise.
* testsuite/g++.dg/tree-ssa/uninit-17.c: Disable address lowering.

Index: gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-2.c
===
--- gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-2.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-2.c  (revision 0)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-loweraddr" } */
+struct x
+{
+  int a[16];
+  int b[16];
+  int c[16];
+};
+
+extern void foo (int, int, int);
+
+void
+f (struct x *p, unsigned int n)
+{
+  foo (p->a[n], p->c[n], p->b[n]);
+  if (n > 3)
+foo (p->a[n], p->c[n], p->b[n]);
+  if (n > 89)
+foo (p->b[n], p->a[n], p->c[n]);
+}
+
+/* { dg-final { scan-tree-dump-times "= MEM\\\[\\(struct x 
\\*\\)D\.\[0-9_\]\+\\\];" 3 "loweraddr" } } */
+/* { dg-final { cleanup-tree-dump "loweraddr" } } */
Index: gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-3.c
===
--- gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-3.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-3.c  (revision 0)
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-loweraddr" } */
+struct x
+{
+  int a[16];
+  int b[16];
+  int c[16];
+};
+
+void
+f (struct x *p, unsigned int n)
+{
+  p->a[n] = n;
+  p->c[n] = n + 2;
+  p->b[n] = n + 1;
+  if (n > 3)
+{
+  p->a[n] = n + 3;
+  p->c[n] = n + 9;
+  p->b[n] = n + 6;
+}
+  if (n < 89)
+{
+  p->b[n] = n + 5;
+  p->a[n] = n + 15;
+  p->c[n] = n + 10;
+}
+}
+
+/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct x 
\\*\\)D\.\[0-9_\]\+\\\] =" 3 "loweraddr" } } */
+/* { dg-final { cleanup-tree-dump "loweraddr" } } */
Index: gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-4.c
===
--- gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-4.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/ppc-loweraddr-4.c  (revision 0)
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-loweraddr" } */
+struct x
+{
+  int a[16];
+  int b[16];
+  int c[16];
+};
+
+void
+f (struct x *p, struct x *q, struct x *r, struct x *s, unsigned int n)
+{
+  p->a[n] = q->a[n];
+  p->c[n] = q->c[n];
+  p->b[n] = q->b[n];
+  if (n > 3)
+{
+  p->a[n] = r->a[n];
+  p->c[n] = r->c[n];
+  p->b[n] = r->b[n];
+}
+  if (n < 89)
+{
+  p->b[n] = s->b[n];
+  p->a[n] = s->a[n];
+  p->c[n] = s->c[n];
+}
+}
+
+/* { dg-final { scan-tree-dump-times "= MEM\\\[\\(struct x 
\\*\\)D\.\[0-9_\]\+\\\];" 3 "loweraddr" } } */
+/* { dg-final { scan-tr

Re: [PATCH] Sign extend before converting constants to GMP values.

[Richard Guenther]

On Thu, 30 Jun 2011, Sebastian Pop wrote:

> On Thu, Jun 30, 2011 at 09:46, Richard Guenther  wrote:
> > On Thu, 30 Jun 2011, Sebastian Pop wrote:
> >
> >> On Thu, Jun 30, 2011 at 05:19, Richard Guenther  wrote:
> >> > That looks odd.  So you given -1U as input you sign-extend that to -1
> >>
> >> correct
> >>
> >> > and then set the mpz to -1ULLL.
> >>
> >> and then it sets the mpz to signed -1, given that I'm passing false to UNS:
> >>
> >> /* Sets RESULT to VAL, taken unsigned if UNS is true and as signed
> >>    otherwise.  */
> >>
> >> void
> >> mpz_set_double_int (mpz_t result, double_int val, bool uns)
> >>
> >> > In fact it looks like you either
> >> > have non-canoncial INTEGER_CSTs from the start or the type of the
> >> > integer constants is wrong.
> >>
> >> I don't know what a canonical INTEGER_CST is.
> >
> > Canonically extended according to TYPE_UNSIGNED I mean.  So what you
> > do is always create signed mpzs - that should simply work without
> > doing anything to the double-int.  Thus, why not do
> >
> > static inline void
> > tree_int_to_gmp (tree t, mpz_t res)
> > {
> >  double_int di = tree_to_double_int (t);
> >  mpz_set_double_int (res, di, false);
> > }
> >
> > ?  I don't see why you'd want to sign-extend unsigned values
> > (for example an unsigned char 255 would get sign-extended to -1).
> > As double_ints are always correctly extended according to the
> > sign of the INTEGER_CST they come from (iff they are properly
> > canonical) you can embed all INTEGER_CSTs with precision of max.
> > HOST_BITS_PER_WISE_INT * 2 into a signed mpz with precision
> > HOST_BITS_PER_WISE_INT * 2 + 1.
> >
> >> Here are the cases that can occur:
> >> - translating to mpz a -1U as the upper bound of an unsigned type,
> >> in which case I do not want it to be sign extended,
> >> - translating to mpz a -1U constant in an unsigned expression "x + -1U"
> >> in which I do want it to be sign extended.
> >
> > I don't think you want the 2nd.
> 
> Supposing that we have a loop iterating over unsigned char
> for (unsigned char i = 100; i > 0; i--)
> that would have a decrement "i = i + -1U", then the -1U would end up
> translated as 255 in mpz, and that would be really interpreted as a stride
> of 255 in the rest of graphite.
> 
> > I think you want to preserve the value.
> 
> Then we should also deal with the modulo arithmetic in graphite.

But what do you do for

 for (unsigned char i = 128; i < 255; ++i)

?  You change 128 to -128 which is wrong.  So yes, you also have to
deal with modulo arithmetic in graphite.

Richard.

Re: [PATCH] Sign extend before converting constants to GMP values.

[Sebastian Pop]

On Thu, Jun 30, 2011 at 09:57, Sebastian Pop  wrote:
>> Canonically extended according to TYPE_UNSIGNED I mean.  So what you
>> do is always create signed mpzs - that should simply work without
>> doing anything to the double-int.  Thus, why not do
>>
>> static inline void
>> tree_int_to_gmp (tree t, mpz_t res)
>> {
>>  double_int di = tree_to_double_int (t);
>>  mpz_set_double_int (res, di, false);
>> }
>>
>> ?

I tried that and just passing false does not fix PR47653.
You still have the problem of the unsigned decrementing induction variable
that I described.

Sebastian

Re: [trans-mem] Beginning of refactoring

[Richard Henderson]

On 06/30/2011 04:15 AM, Torvald Riegel wrote:
> On Wed, 2011-06-29 at 16:01 -0700, Richard Henderson wrote:
>> On 05/25/2011 02:10 PM, Torvald Riegel wrote:
>>> Patch 2: _ITM_dropReferences is not sufficiently defined in the ABI. It
>>> seems to target some form of open nesting for txnal wrappers, but the
>>> prose in the ABI specification is unclear. Thus, disable this for now
>>> (aka fatal runtime error), and expect the related tests to fail. Pick it
>>> up again once that the ABI has been improved and the use cases are
>>> clear.
>>
>> Sure, but please actually delete the code rather than just comment it out.
> 
> Fixed in updated patch2.

This patch is ok.

> How it works is that in a TM-method-specific dispatch class we would add
>   CREATE_DISPATCH_METHODS(static, _static)
> in addition to the 
>   CREATE_DISPATCH_METHODS(virtual, )
> that is currently there. In barrier.cc we can then do
>   CREATE_DISPATCH_FUNCTIONS(GTM::serial_dispatch::_, _static)
> and thus bypass the virtual functions, but still keep one implementation
> of the TM method (in the static template functions). This example would
> create functions that just use the serial-mode accesses.

Ah yes, I remember discussing this.

> The trailing underscore at the end of the first param is to make the
> preprocessor happen. Is there a better way to let it accept
> "GTM::abi_disp()->" as argument?

It depends on what else you're passing to the other methods above.

It does seem odd, though, that you're passing some bit of global
state to the virtual dispatch methods (the result of abi_disp())
whereas you're arranging to pass nothing but a name concatenation
to the others.

I'm not sure what to make of your first two examples above, but
let's suppose that the third example is the real one.  In which
case you don't actually need concatenation.  Remove the ## from
the macro and then you can pass in

  GTM::abi_disp()->
and
  GTM::serial_dispatch::

which require no more than adjacency.

>> Why?  We're already in a header that's clearly marked "internal".
> 
> I moved these macros to a common header so libitm_i.h doesn't have to be
> included everywhere. There was some circular dependency after the
> changes (I think in via the barrier definitions for SSE etc.). What's
> the issue that you see with this change?

Not really an issue, it just seemed odd.

> Are the attached updated patches okay for the branch?

Yeah, we can iterate on the points above without re-sending
the entire patch3 again.


r~

Re: [PATCH] Sign extend before converting constants to GMP values.

[Sebastian Pop]

On Thu, Jun 30, 2011 at 09:46, Richard Guenther  wrote:
> On Thu, 30 Jun 2011, Sebastian Pop wrote:
>
>> On Thu, Jun 30, 2011 at 05:19, Richard Guenther  wrote:
>> > That looks odd.  So you given -1U as input you sign-extend that to -1
>>
>> correct
>>
>> > and then set the mpz to -1ULLL.
>>
>> and then it sets the mpz to signed -1, given that I'm passing false to UNS:
>>
>> /* Sets RESULT to VAL, taken unsigned if UNS is true and as signed
>>    otherwise.  */
>>
>> void
>> mpz_set_double_int (mpz_t result, double_int val, bool uns)
>>
>> > In fact it looks like you either
>> > have non-canoncial INTEGER_CSTs from the start or the type of the
>> > integer constants is wrong.
>>
>> I don't know what a canonical INTEGER_CST is.
>
> Canonically extended according to TYPE_UNSIGNED I mean.  So what you
> do is always create signed mpzs - that should simply work without
> doing anything to the double-int.  Thus, why not do
>
> static inline void
> tree_int_to_gmp (tree t, mpz_t res)
> {
>  double_int di = tree_to_double_int (t);
>  mpz_set_double_int (res, di, false);
> }
>
> ?  I don't see why you'd want to sign-extend unsigned values
> (for example an unsigned char 255 would get sign-extended to -1).
> As double_ints are always correctly extended according to the
> sign of the INTEGER_CST they come from (iff they are properly
> canonical) you can embed all INTEGER_CSTs with precision of max.
> HOST_BITS_PER_WISE_INT * 2 into a signed mpz with precision
> HOST_BITS_PER_WISE_INT * 2 + 1.
>
>> Here are the cases that can occur:
>> - translating to mpz a -1U as the upper bound of an unsigned type,
>> in which case I do not want it to be sign extended,
>> - translating to mpz a -1U constant in an unsigned expression "x + -1U"
>> in which I do want it to be sign extended.
>
> I don't think you want the 2nd.

Supposing that we have a loop iterating over unsigned char
for (unsigned char i = 100; i > 0; i--)
that would have a decrement "i = i + -1U", then the -1U would end up
translated as 255 in mpz, and that would be really interpreted as a stride
of 255 in the rest of graphite.

> I think you want to preserve the value.

Then we should also deal with the modulo arithmetic in graphite.

Sebastian

Re: [PATCH 4/6] Fix computation of precision.

[Tobias Grosser]

On 06/30/2011 09:50 AM, Sebastian Pop wrote:

On Wed, Jun 29, 2011 at 18:16, Tobias Grosser  wrote:

why do we continue to call low 'low' and up 'up', if we actually just have
two values v1 and v2 where we do not know which one is larger? I think this
wrong and probably comes because we pass the lower loop bound to val_one and
the upper loop bound to val_two.

What about:

+/* Return a type that could represent all values between VAL_ONE and
+   VAL_TWO including VAL_ONE and VAL_TWO itself.  There is no
+   constraint on which of the two values is larger.  */

  static tree
- gcc_type_for_interval (mpz_t low, mpz_t up)
+ gcc_type_for_interval (mpz_t val_one, mpz_t val_two)
   {



Sounds good.  I will change the patch.


-  bool unsigned_p = true;
-  int precision, prec_up, prec_int;
+  bool unsigned_p;
tree type;
enum machine_mode mode;
-
-  gcc_assert (mpz_cmp (low, up)<= 0);
-
-  prec_up = precision_for_value (up);
-  prec_int = precision_for_interval (low, up);
-  precision = MAX (prec_up, prec_int);
+  int precision = MAX (mpz_sizeinbase (low, 2),
+  mpz_sizeinbase (up, 2));

if (precision>BITS_PER_WORD)
  {
@@ -452,14 +397,10 @@ gcc_type_for_interval (mpz_t low, mpz_t up)
return integer_type_node;
  }

-  if (mpz_sgn (low)<= 0)
-unsigned_p = false;
-
-  else if (precision= 0);
+  else
+unsigned_p = (mpz_sgn (up)>= 0);


What about?

   unsigned_p = value_min(low, up)>= 0;


Ok.



(You need to move the implementation of value_min to this patch)



mode = smallest_mode_for_size (precision, MODE_INT);
precision = GET_MODE_PRECISION (mode);


In general the new implementation looks a lot more elegant as the old one.
What was the problem with the old one? That low could be larger than up and


I don't think that could happen, given that we have a
gcc_assert (mpz_cmp (low, up)<= 0);


that the calculation in precision_for_interval was incorrect (or at least
not understandable for me)?


There was an off by one problem in the computation of precision exposed
by the patch "Compute LB and UB of a CLAST expression".


OK. From my side this patch is fine.

Tobi

Re: [PATCH 4/6] Fix computation of precision.

[Sebastian Pop]

On Wed, Jun 29, 2011 at 18:16, Tobias Grosser  wrote:
> why do we continue to call low 'low' and up 'up', if we actually just have
> two values v1 and v2 where we do not know which one is larger? I think this
> wrong and probably comes because we pass the lower loop bound to val_one and
> the upper loop bound to val_two.
>
> What about:
>
> +/* Return a type that could represent all values between VAL_ONE and
> +   VAL_TWO including VAL_ONE and VAL_TWO itself.  There is no
> +   constraint on which of the two values is larger.  */
>
>  static tree
> - gcc_type_for_interval (mpz_t low, mpz_t up)
> + gcc_type_for_interval (mpz_t val_one, mpz_t val_two)
>   {
>

Sounds good.  I will change the patch.

>> -  bool unsigned_p = true;
>> -  int precision, prec_up, prec_int;
>> +  bool unsigned_p;
>>    tree type;
>>    enum machine_mode mode;
>> -
>> -  gcc_assert (mpz_cmp (low, up)<= 0);
>> -
>> -  prec_up = precision_for_value (up);
>> -  prec_int = precision_for_interval (low, up);
>> -  precision = MAX (prec_up, prec_int);
>> +  int precision = MAX (mpz_sizeinbase (low, 2),
>> +                      mpz_sizeinbase (up, 2));
>>
>>    if (precision>  BITS_PER_WORD)
>>      {
>> @@ -452,14 +397,10 @@ gcc_type_for_interval (mpz_t low, mpz_t up)
>>        return integer_type_node;
>>      }
>>
>> -  if (mpz_sgn (low)<= 0)
>> -    unsigned_p = false;
>> -
>> -  else if (precision<  BITS_PER_WORD)
>> -    {
>> -      unsigned_p = false;
>> -      precision++;
>> -    }
>> +  if (mpz_cmp (low, up)<= 0)
>> +    unsigned_p = (mpz_sgn (low)>= 0);
>> +  else
>> +    unsigned_p = (mpz_sgn (up)>= 0);
>
> What about?
>
>       unsigned_p = value_min(low, up) >= 0;

Ok.

>
> (You need to move the implementation of value_min to this patch)
>
>>
>>    mode = smallest_mode_for_size (precision, MODE_INT);
>>    precision = GET_MODE_PRECISION (mode);
>
> In general the new implementation looks a lot more elegant as the old one.
> What was the problem with the old one? That low could be larger than up and

I don't think that could happen, given that we have a
gcc_assert (mpz_cmp (low, up)<= 0);

> that the calculation in precision_for_interval was incorrect (or at least
> not understandable for me)?

There was an off by one problem in the computation of precision exposed
by the patch "Compute LB and UB of a CLAST expression".

Sebastian

[PATCH] Address lowering [2/3] Constrain forward propagator

[William J. Schmidt]

Here is the second patch related to address lowering.  It looks for a
specific pattern where replacement of a reg in a mem rtx is not
profitable, and constrains it from occurring.

Thanks,
Bill

2011-06-30  Bill Schmidt  

* fwprop.c (fwprop_bb_aux_d): New struct.
(record_mem_plus_reg): New.
(record_mem_plus_regs): New.
(single_def_use_enter_block): Allocate storage; add call to
record_mem_plus_regs; add dump logic.
(build_single_def_use_links): Allocate storage.
(locally_poor_mem_replacement): New.
(forward_propagate_and_simplify): Add call to
locally_poor_mem_replacement.
(fwprop_done): Free storage.

Index: gcc/fwprop.c
===
--- gcc/fwprop.c(revision 175664)
+++ gcc/fwprop.c(working copy)
@@ -131,6 +131,15 @@ static VEC(df_ref,heap) *reg_defs_stack;
 static bitmap local_md;
 static bitmap local_lr;
 
+/* Auxiliary information for each block for this pass.  */
+typedef struct GTY(()) fwprop_bb_aux_d
+{
+  /* Registers appearing in (mem (plus (reg ... patterns in this block.  */
+  bitmap mem_plus_regs;
+} fwprop_bb_aux, *fwprop_bb_aux_t;
+
+#define MEM_PLUS_REGS(BB) ((fwprop_bb_aux_t) ((BB)->aux))->mem_plus_regs
+
 /* Return the only def in USE's use-def chain, or NULL if there is
more than one def in the chain.  */
 
@@ -212,7 +221,43 @@ process_uses (df_ref *use_rec, int top_flag)
 }
 
 
+/* Record whether EXPR in block BB is of the form (mem (plus (reg ...  */
 static void
+record_mem_plus_reg (basic_block bb, rtx expr)
+{
+  rtx addr, reg;
+
+  if (GET_CODE (expr) != MEM)
+return;
+
+  addr = XEXP (expr, 0);
+  if (GET_CODE (addr) != PLUS)
+return;
+
+  reg = XEXP (addr, 0);
+  if (!REG_P (reg))
+return;
+
+  (void)bitmap_set_bit (MEM_PLUS_REGS (bb), REGNO (reg));
+}
+
+
+/* Record whether INSN in block BB contains any patterns of the form
+   (mem (plus (reg ...  */
+static void
+record_mem_plus_regs (basic_block bb, rtx insn)
+{
+  rtx insn_set = single_set (insn);
+
+  if (insn_set)
+{
+  record_mem_plus_reg (bb, SET_DEST (insn_set));
+  record_mem_plus_reg (bb, SET_SRC (insn_set));
+}
+}
+
+
+static void
 single_def_use_enter_block (struct dom_walk_data *walk_data ATTRIBUTE_UNUSED,
basic_block bb)
 {
@@ -230,6 +275,8 @@ single_def_use_enter_block (struct dom_walk_data *
   process_uses (df_get_artificial_uses (bb_index), DF_REF_AT_TOP);
   process_defs (df_get_artificial_defs (bb_index), DF_REF_AT_TOP);
 
+  MEM_PLUS_REGS (bb) = BITMAP_ALLOC (NULL);
+
   /* We don't call df_simulate_initialize_forwards, as it may overestimate
  the live registers if there are unused artificial defs.  We prefer
  liveness to be underestimated.  */
@@ -242,8 +289,15 @@ single_def_use_enter_block (struct dom_walk_data *
 process_uses (DF_INSN_UID_EQ_USES (uid), 0);
 process_defs (DF_INSN_UID_DEFS (uid), 0);
df_simulate_one_insn_forwards (bb, insn, local_lr);
+   record_mem_plus_regs (bb, insn);
   }
 
+  if (dump_file)
+{
+  fprintf (dump_file, "mem_plus_regs (%d): ", bb->index);
+  dump_bitmap (dump_file, MEM_PLUS_REGS (bb));
+}
+
   process_uses (df_get_artificial_uses (bb_index), 0);
   process_defs (df_get_artificial_defs (bb_index), 0);
 }
@@ -295,6 +349,8 @@ build_single_def_use_links (void)
   local_md = BITMAP_ALLOC (NULL);
   local_lr = BITMAP_ALLOC (NULL);
 
+  alloc_aux_for_blocks (sizeof (fwprop_bb_aux));
+
   /* Walk the dominator tree looking for single reaching definitions
  dominating the uses.  This is similar to how SSA form is built.  */
   walk_data.dom_direction = CDI_DOMINATORS;
@@ -1205,6 +1261,69 @@ forward_propagate_asm (df_ref use, rtx def_insn, r
   return true;
 }
 
+/* We are proposing to replace a USE of REG in USE_SET.  Determine
+   whether we have a situation where two storage uses of REG occur
+   in the same block as follows.  Each use can be either a memory
+   store or a memory load.
+
+ ... (mem (reg REG))
+
+ ... (mem (plus (reg REG)
+(...)))
+
+   The problem is that it will look profitable to propagate something
+   like
+
+ (set (reg REG)
+  (plus (reg X)
+(reg Y)))
+
+   into the first use, but not into the second one.  This breaks a 
+   CSE opportunity and raises register pressure by extending the
+   lifetimes of X and Y.  To avoid this, don't propagate into the
+   first use when this very specific situation arises.  */
+static bool
+locally_poor_mem_replacement (df_ref use, rtx use_set, rtx reg, rtx def_set)
+{
+  rtx rhs, addend, mem, base;
+  unsigned i;
+
+  /* We're only concerned if the RHS of def_set is the sum of two
+ registers.  */
+  rhs = SET_SRC (def_set);
+
+  if (GET_CODE (rhs) != PLUS)
+return false;
+
+  for (i = 0; i < 2; i++)
+{
+  addend = XEXP (rhs, i);
+  if (!REG_P (addend))
+   return f

Re: [PATCH] Sign extend before converting constants to GMP values.

[Richard Guenther]

On Thu, 30 Jun 2011, Sebastian Pop wrote:

> On Thu, Jun 30, 2011 at 05:19, Richard Guenther  wrote:
> > That looks odd.  So you given -1U as input you sign-extend that to -1
> 
> correct
> 
> > and then set the mpz to -1ULLL.
> 
> and then it sets the mpz to signed -1, given that I'm passing false to UNS:
>
> /* Sets RESULT to VAL, taken unsigned if UNS is true and as signed
>otherwise.  */
> 
> void
> mpz_set_double_int (mpz_t result, double_int val, bool uns)
> 
> > In fact it looks like you either
> > have non-canoncial INTEGER_CSTs from the start or the type of the
> > integer constants is wrong.
> 
> I don't know what a canonical INTEGER_CST is.

Canonically extended according to TYPE_UNSIGNED I mean.  So what you
do is always create signed mpzs - that should simply work without
doing anything to the double-int.  Thus, why not do

static inline void
tree_int_to_gmp (tree t, mpz_t res)
{
  double_int di = tree_to_double_int (t);
  mpz_set_double_int (res, di, false);
}

?  I don't see why you'd want to sign-extend unsigned values
(for example an unsigned char 255 would get sign-extended to -1).
As double_ints are always correctly extended according to the
sign of the INTEGER_CST they come from (iff they are properly
canonical) you can embed all INTEGER_CSTs with precision of max.
HOST_BITS_PER_WISE_INT * 2 into a signed mpz with precision
HOST_BITS_PER_WISE_INT * 2 + 1.

> Here are the cases that can occur:
> - translating to mpz a -1U as the upper bound of an unsigned type,
> in which case I do not want it to be sign extended,
> - translating to mpz a -1U constant in an unsigned expression "x + -1U"
> in which I do want it to be sign extended.

I don't think you want the 2nd.  I think you want to preserve the
value.

Richard.

Re: [PATCH] Sign extend before converting constants to GMP values.

[Sebastian Pop]

On Thu, Jun 30, 2011 at 05:19, Richard Guenther  wrote:
> That looks odd.  So you given -1U as input you sign-extend that to -1

correct

> and then set the mpz to -1ULLL.

and then it sets the mpz to signed -1, given that I'm passing false to UNS:

/* Sets RESULT to VAL, taken unsigned if UNS is true and as signed
   otherwise.  */

void
mpz_set_double_int (mpz_t result, double_int val, bool uns)

> In fact it looks like you either
> have non-canoncial INTEGER_CSTs from the start or the type of the
> integer constants is wrong.

I don't know what a canonical INTEGER_CST is.

Here are the cases that can occur:
- translating to mpz a -1U as the upper bound of an unsigned type,
in which case I do not want it to be sign extended,
- translating to mpz a -1U constant in an unsigned expression "x + -1U"
in which I do want it to be sign extended.

In my opinion there is not enough information to decide whether
to sign extend or not the value in tree_int_to_gmp.

Sebastian

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Thu, Jun 30, 2011 at 7:08 AM, Jason Merrill  wrote:
> On 06/28/2011 02:53 PM, H.J. Lu wrote:
>>
>> This updated patch.  It allows multiple unwind contexts.  It replaces
>>
>> char by_value[DWARF_FRAME_REGISTERS+1];
>>
>> with
>>
>> _Unwind_Word value[DWARF_FRAME_REGISTERS+1];
>>
>> The code is cleaner than conditionally replacing
>>
>> void *reg[DWARF_FRAME_REGISTERS+1];
>>
>> with
>>
>> _Unwind_Word reg[DWARF_FRAME_REGISTERS+1];
>>
>> with a bigger unwind context.
>
> It doesn't seem cleaner to me.

Register may be saved/restored either by address or value. My patch
doesn't change the reg field.  The other way will be

#ifdef USE_UNWIND_WORD
_Unwind_Word reg[DWARF_FRAME_REGISTERS+1];
#else
 void *reg[DWARF_FRAME_REGISTERS+1];
#endif

We need it so that we are binary compatible with the existing
unwind context.  Once we do that we need many

#ifdef USE_UNWIND_WORD
#endif

whenever the reg field is accessed since the reg field is changed.

-- 
H.J.

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[Jason Merrill]

On 06/28/2011 02:53 PM, H.J. Lu wrote:

This updated patch.  It allows multiple unwind contexts.  It replaces

char by_value[DWARF_FRAME_REGISTERS+1];

with

_Unwind_Word value[DWARF_FRAME_REGISTERS+1];

The code is cleaner than conditionally replacing

void *reg[DWARF_FRAME_REGISTERS+1];

with

_Unwind_Word reg[DWARF_FRAME_REGISTERS+1];

with a bigger unwind context.


It doesn't seem cleaner to me.


But it is more flexible if we
want to extend unwind context later, like saving/restoring
128bit or vector registers which may be bigger than the current
_Unwind_Word.


I don't see that, either; with either approach, supporting larger 
registers would require a change to the the unwind context.


Jason

[PATCH] Enable IPA-PTA for ltrans stage

[Richard Guenther]

This patch makes IPA-PTA work during the ltrans stage of LTO.
It basically makes sure to honor the accessed-from-other-ltrans-unit
flags for variables and functions where appropriate.

With this patch, IPA-PTA survives LTO bootstrap (with -fipa-pta
hard-wired to 1 in common.opt).  Before the patch we miscompiled
the stage2 compiler (unsurprisingly).

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

I hope to get to some of the remaining TODOs for IPA-PTA (basically
fixup nonlocal handling throughout the compiler ...) and then maybe
look at compile-time and memory usage issues.

Richard.

2011-06-29  Richard Guenther  

* opts.c (finish_options): Do not disable IPA-PTA during ltrans.
* tree-ssa-structalias.c (create_variable_info_for): Do not
add initial constraints for non-var-decls.  Properly handle
globals in other ltrans partitions.
(intra_create_variable_infos): Manually create constraints for
the fake no-alias parameter.
(ipa_pta_execute): Dump the cgraph, handle ltrans partitions properly
and assert there are no clones.

Index: gcc/opts.c
===
*** gcc/opts.c.orig 2011-06-30 15:25:53.0 +0200
--- gcc/opts.c  2011-06-30 15:27:47.0 +0200
*** finish_options (struct gcc_options *opts
*** 766,776 
maybe_set_param_value (PARAM_STACK_FRAME_GROWTH, 40,
 opts->x_param_values, opts_set->x_param_values);
  }
-   if (opts->x_flag_wpa || opts->x_flag_ltrans)
- {
-   /* These passes are not WHOPR compatible yet.  */
-   opts->x_flag_ipa_pta = 0;
- }
  
if (opts->x_flag_lto)
  {
--- 766,771 
Index: gcc/tree-ssa-structalias.c
===
*** gcc/tree-ssa-structalias.c.orig 2011-06-30 15:26:07.0 +0200
--- gcc/tree-ssa-structalias.c  2011-06-30 15:55:02.0 +0200
*** create_variable_info_for (tree decl, con
*** 5450,5455 
--- 5450,5458 
  
insert_vi_for_tree (decl, vi);
  
+   if (TREE_CODE (decl) != VAR_DECL)
+ return id;
+ 
/* Create initial constraints for globals.  */
for (; vi; vi = vi->next)
  {
*** create_variable_info_for (tree decl, con
*** 5463,5499 
  || vi->only_restrict_pointers)
make_constraint_from_restrict (vi, "GLOBAL_RESTRICT");
  
!   /* For escaped variables initialize them from nonlocal.  */
if (!in_ipa_mode
! || DECL_EXTERNAL (decl) || TREE_PUBLIC (decl))
make_copy_constraint (vi, nonlocal_id);
  
!   /* If this is a global variable with an initializer and we are in
!IPA mode generate constraints for it.  In non-IPA mode
!the initializer from nonlocal is all we need.  */
!   if (in_ipa_mode
! && DECL_INITIAL (decl))
{
! VEC (ce_s, heap) *rhsc = NULL;
! struct constraint_expr lhs, *rhsp;
! unsigned i;
! get_constraint_for_rhs (DECL_INITIAL (decl), &rhsc);
! lhs.var = vi->id;
! lhs.offset = 0;
! lhs.type = SCALAR;
! FOR_EACH_VEC_ELT (ce_s, rhsc, i, rhsp)
!   process_constraint (new_constraint (lhs, *rhsp));
! /* If this is a variable that escapes from the unit
!the initializer escapes as well.  */
! if (DECL_EXTERNAL (decl) || TREE_PUBLIC (decl))
{
! lhs.var = escaped_id;
  lhs.offset = 0;
  lhs.type = SCALAR;
  FOR_EACH_VEC_ELT (ce_s, rhsc, i, rhsp)
process_constraint (new_constraint (lhs, *rhsp));
}
- VEC_free (ce_s, heap, rhsc);
}
  }
  
--- 5466,5509 
  || vi->only_restrict_pointers)
make_constraint_from_restrict (vi, "GLOBAL_RESTRICT");
  
!   /* In non-IPA mode the initializer from nonlocal is all we need.  */
if (!in_ipa_mode
! || DECL_HARD_REGISTER (decl))
make_copy_constraint (vi, nonlocal_id);
  
!   else
{
! struct varpool_node *vnode = varpool_get_node (decl);
! 
! /* For escaped variables initialize them from nonlocal.  */
! if (!varpool_all_refs_explicit_p (vnode))
!   make_copy_constraint (vi, nonlocal_id);
! 
! /* If this is a global variable with an initializer and we are in
!IPA mode generate constraints for it.  */
! if (DECL_INITIAL (decl))
{
! VEC (ce_s, heap) *rhsc = NULL;
! struct constraint_expr lhs, *rhsp;
! unsigned i;
! get_constraint_for_rhs (DECL_INITIAL (decl), &rhsc);
! lhs.var = vi->id;
  lhs.offset = 0;
  lhs.type = SCALAR;
  FOR_EACH_VEC_ELT (ce_s, rhsc, i, rhsp)
process_constraint (new_constraint (lhs, *rhsp));
+ /* If this is a variable that escapes 

Re: PATCH] PR 49580

[Razya Ladelsky]

Zdenek Dvorak  wrote on 30/06/2011 15:21:43:

> From: Zdenek Dvorak 
> To: Razya Ladelsky/Haifa/IBM@IBMIL
> Cc: gcc-patches@gcc.gnu.org, Richard Guenther 

> Date: 30/06/2011 15:21
> Subject: Re: PATCH] PR 49580
> 
> Hi,
> 
> > This patch fixes the build failure of gcc spec2006 benchmark.
> > The change is in  gimple_duplicate_sese_tail(), where we need to 
subtract 
> > 1 from the loop's number of iterations.
> > The stmt created to change the rhs of the loop's condition, used to be 

> > inserted right after the defining stmt of the rhs (an ssa name).
> > This requires special handling of different cases of the defining 
stmt:
> > 1.gimple_stmt
> > 2.gimple_phi
> > 3.default_def
> > 
> > Instead of handling each case separately, if we insert the new stmt at 
the 
> > begining of the loop's preheader, we're sure that 
> > it's already been defined.
> > 
> > Bootstrap and testsuite pass successfully (as autopar is not enabled 
by 
> > default).
> > No new regressions when the testsuite is run with autopar enabled.
> > No new regressions for the run of spec2006 with autopar enabled, and 
gcc 
> > benchmark now passes successfully.. 
> > 
> > OK for trunk? 
> 
> actually, I think a better approach would be not to have this kind 
> of pass-specific
> adjustments in gimple_duplicate_sese_tail at all.  The code 
> decreasing the number of
> iterations in gimple_duplicate_sese_tail only works because parloops
> does induction
> variable canonicalization first; should we need it to be used 
> anywhere else, it will break.
> I.e., parloops should first transform the condition so that it does 
> the comparison with
> the adjusted value, and then gimple_duplicate_sese_tail could do 
> just code copying
> and cfg changes,
> 

Ok, working on it.
Thanks,
Razya

> Zdenek

Re: Ping #1: [Patch, AVR]: Fix PR34734

[Georg-Johann Lay]

Weddington, Eric wrote:
>> -Original Message-

>>> You can backport it if you want.
>>> 
>>> I'm usually didn't backport such patches.
>>> 
>>> Denis.
>> Ok, maybe Eric or Anatoly have some preference for 4.5/4.6.
> 
> I would like it for the 4.6 series, if possible. I think that the
> next releases of the various avr toolchain distributions will very
> probably be moving up to 4.6.x.
> 
> Eric

http://gcc.gnu.org/viewcvs/branches/gcc-4_6-branch/gcc/config/avr/avr.c?r1=175706&r2=175704&pathrev=175706

Backported to 4.6 and set PR34734 milestone to 4.6.2.

Johann

Re: [PATCH] ARM fixed-point support [4/6]: allow overriding of fixed-point helper function names

[Bernd Schmidt]

On 05/13/11 15:58, Julian Brown wrote:
> This patch allows the decoration of helper function names for
> fixed-point support to be changed from the default "__foo" to a
> different scheme, as required by the ARM EABI (these are
> "vendor-specific" helpers, so should go in a particular namespace).
> These are only the machine-independent changes: the ARM-specific bits
> come later.

I think you'll find that this no longer applies. However, there's
support for renaming these to __gnu_foo, and looking at your patch 6/6
that's exactly what you need? You'll probably have to change the
granularity so that a target can choose to apply it only to the
fixed-point functions.


Bernd

Re: [PATCH] ARM fixed-point support [6/6]: target-specific parts

[Richard Earnshaw]

On 26/05/11 17:45, Julian Brown wrote:
> On Fri, 13 May 2011 17:31:18 +0100
> Julian Brown  wrote:
> 
>> On Fri, 13 May 2011 14:54:47 + (UTC)
>> "Joseph S. Myers"  wrote:
>>
>>> On Fri, 13 May 2011, Julian Brown wrote:
>>>
 although Joseph's comments have (hopefully) all been addressed.
 One must now configure with "--enable-fixed-point" to enable the
 fixed-point support.
>>>
>>> No, that's not how this configure logic works; it enables fixed
>>> point by default for the given targets.  The bit that enables it by
>>> default for MIPS (and that you're changing to cover ARM as well) is
>>> the code that is called if the user *doesn't* pass
>>> --enable-fixed-point or --disable-fixed-point.
>>
>> Yes, you're quite right: I had forgotten to run autoconf after
>> changing configure.ac whilst testing. Sorry for the misinformation!
> 
> This is a new version of the patch, which fixes a couple of issues
> discovered on our internal branch since the last version was posted.
> This version handles "long long" fixed point types in the same way as
> 32-bit MIPS: basically the sizes of those types are clamped to 64 bits.
> 
> This means the testsuite changes in:
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00969.html
> 
> are no longer required.
> 
> Another couple of problems have also been fixed, relating to big-endian
> mode. One was the use of simplify_gen_subreg with a hard-wired offset in
> a several of the insn expanders, where I should have just used
> gen_highpart -- which works in either endianness, and makes the intent
> clearer anyway.
> 
> The other issue is ABI-related. My previous assertion that fixed-point
> types (smaller than word size) should be passed to and returned from
> functions "like integers" doesn't really work out very well after all
> in big-endian mode, so needs re-thinking. The problem is basically that
> such fixed-point types are incorrectly padded in big-endian mode, so
> the data ends up in a different part of the passed word than expected.
> 
> The way chars and shorts is handled is as follows: when those types are
> passed to a function, they are promoted to word-size ints, which is a
> nop-op: the values can simply be reinterpreted as ints, and that works
> fine in either endianness. We might hope to be able to do the same thing
> for smaller-than-word-size fixed-point types, but unfortunately we
> can't: e.g. a "short fract" or "fract" can't just be reinterpreted as a
> "long fract" (the 32-bit fractional type), because the fixed-point is
> in a different place for the wider type (and performing conversions
> would itself require libcalls at present). It also doesn't work to
> promote small fixed-point types to SImode: as well as being
> conceptually messy, we hit ICEs very quickly attempting that.
> 
> So instead, I think that small fixed-point types should be handled the
> same way as small aggregates or small complex-valued types. This means
> effectively no change in little-endian mode, but in big-endian mode:
> 
> * for register arguments, fixed-point types are passed in the
>   most-significant end of the register.
> 
> * for stack arguments, fixed-point types are passed in lower memory
>   addresses.
> 
> * for return values, fixed-point types are again in the
>   most-significant end of the return register (r0).
> 
> This is quite easy to set up in the backend code, but unfortunately I
> hit a snag in libcall expansion in calls.c: padding of arguments and
> return values is not properly supported, as it is for regular function
> calls. I've implemented that, and will post it as a separate patch.
> 
> OK to apply? Tested alongside the rest of the patch series, in both big
> & little-endian mode.
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * configure.ac (fixed-point): Add ARM support.
> * configure: Regenerate.
> * config/arm/arm.c (arm_fixed_mode_set): New struct.
> (arm_set_fixed_optab_libfunc): New.
> (arm_set_fixed_conv_libfunc): New.
> (arm_init_libfuncs): Initialise fixed-point helper libfuncs with
> ARM-specific names.
> (aapcs_libcall_value): Return sub-word-size fixed-point libcall
> return values in SImode.
> (arm_return_in_msb): Return fixed-point types in the msb.
> (arm_pad_reg_upwards, arm_pad_arg_upwards): Pad fixed-point types
> upwards.
> (arm_scalar_mode_supported_p): Support fixed-point modes.
> (arm_vector_mode_supported_p): Support vector fixed-point modes.
> * config/arm/arm.h (SHORT_FRACT_TYPE_SIZE, FRACT_TYPE_SIZE)
> (LONG_FRACT_TYPE_SIZE, LONG_LONG_FRACT_TYPE_SIZE)
> (SHORT_ACCUM_TYPE_SIZE, ACCUM_TYPE_SIZE, LONG_ACCUM_TYPE_SIZE)
> (LONG_LONG_ACCUM_TYPE_SIZE, MAX_FIXED_MODE_SIZE): Define.
> * config/arm/arm-modes.def (FRACT, UFRACT, ACCUM, UACCUM): Declare
> vector modes.
> * config/arm/predicates.md (sat_shift_operator): New predicate.
> * config/arm/arm-fixed.md: New.
> * config/arm/arm.md: Include arm-fixed.md.
> * config/arm/t-arm

Re: [PATCH, PR 49094] Refrain from creating misaligned accesses in SRA

[Martin Jambor]

Hi,

I had to add a test that the analyzed expression is not an SSA name.
This has been approved by Rchi on IRC yesterday.  Thus, I have
committed the following as revision 175703 after successful run of c
and c++ testsuite on sparc64 (and a bootstrap and test with another
patch on x86_64-linux).

Thanks,

Martin


2011-06-30  Martin Jambor  

PR tree-optimization/49094
* tree-sra.c (tree_non_mode_aligned_mem_p): New function.
(build_accesses_from_assign): Use it.

* testsuite/gcc.dg/tree-ssa/pr49094.c: New test.


Index: src/gcc/tree-sra.c
===
--- src.orig/gcc/tree-sra.c
+++ src/gcc/tree-sra.c
@@ -1050,6 +1050,26 @@ disqualify_ops_if_throwing_stmt (gimple
   return false;
 }
 
+/* Return true iff type of EXP is not sufficiently aligned.  */
+
+static bool
+tree_non_mode_aligned_mem_p (tree exp)
+{
+  enum machine_mode mode = TYPE_MODE (TREE_TYPE (exp));
+  unsigned int align;
+
+  if (TREE_CODE (exp) == SSA_NAME
+  || mode == BLKmode
+  || !STRICT_ALIGNMENT)
+return false;
+
+  align = get_object_alignment (exp, BIGGEST_ALIGNMENT);
+  if (GET_MODE_ALIGNMENT (mode) > align)
+return true;
+
+  return false;
+}
+
 /* Scan expressions occuring in STMT, create access structures for all accesses
to candidates for scalarization and remove those candidates which occur in
statements or expressions that prevent them from being split apart.  Return
@@ -1074,7 +1094,10 @@ build_accesses_from_assign (gimple stmt)
   lacc = build_access_from_expr_1 (lhs, stmt, true);
 
   if (lacc)
-lacc->grp_assignment_write = 1;
+{
+  lacc->grp_assignment_write = 1;
+  lacc->grp_unscalarizable_region |= tree_non_mode_aligned_mem_p (rhs);
+}
 
   if (racc)
 {
@@ -1082,6 +1105,7 @@ build_accesses_from_assign (gimple stmt)
   if (should_scalarize_away_bitmap && !gimple_has_volatile_ops (stmt)
  && !is_gimple_reg_type (racc->type))
bitmap_set_bit (should_scalarize_away_bitmap, DECL_UID (racc->base));
+  racc->grp_unscalarizable_region |= tree_non_mode_aligned_mem_p (lhs);
 }
 
   if (lacc && racc
Index: src/gcc/testsuite/gcc.dg/tree-ssa/pr49094.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/tree-ssa/pr49094.c
@@ -0,0 +1,38 @@
+/* { dg-do run } */
+/* { dg-options "-O" } */
+
+struct in_addr {
+   unsigned int s_addr;
+};
+
+struct ip {
+   unsigned char ip_p;
+   unsigned short ip_sum;
+   struct  in_addr ip_src,ip_dst;
+} __attribute__ ((aligned(1), packed));
+
+struct ip ip_fw_fwd_addr;
+
+int test_alignment( char *m )
+{
+  struct ip *ip = (struct ip *) m;
+  struct in_addr pkt_dst;
+  pkt_dst = ip->ip_dst ;
+  if( pkt_dst.s_addr == 0 )
+return 1;
+  else
+return 0;
+}
+
+int __attribute__ ((noinline, noclone))
+intermediary (char *p)
+{
+  return test_alignment (p);
+}
+
+int
+main (int argc, char *argv[])
+{
+  ip_fw_fwd_addr.ip_dst.s_addr = 1;
+  return intermediary ((void *) &ip_fw_fwd_addr);
+}

Re: [PATCH] ARM fixed-point support [5.5/6]: argument & return padding for libcalls

[Richard Earnshaw]

On 26/05/11 17:56, Julian Brown wrote:
> This patch allows padding to be specified per-target for libcalls. This
> hasn't been traditionally important, because libcalls haven't accepted
> quantities which might need padding, but that's no longer true with the
> new(-ish) fixed-point support helper functions.
> 
> Tested (alongside other fixed-point support patches) with cross to ARM
> EABI in both big & little-endian mode (the target-specific part is to
> avoid a behaviour change for half-float types on ARM). OK to apply?
> 
> Thanks,
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * calls.c (emit_library_call_value_1): Support padding for libcall
> arguments and return values.
> * config/arm/arm.c (arm_pad_arg_upward): Pad half-float values
> downwards in big-endian mode.
> 

OK if no generic RTL maintainer objects in the next 24 hours.

R.

Re: [PATCH] ARM fixed-point support [4/6]: allow overriding of fixed-point helper function names

[Richard Earnshaw]

On 13/05/11 14:58, Julian Brown wrote:
> This patch allows the decoration of helper function names for
> fixed-point support to be changed from the default "__foo" to a
> different scheme, as required by the ARM EABI (these are
> "vendor-specific" helpers, so should go in a particular namespace).
> These are only the machine-independent changes: the ARM-specific bits
> come later.
> 
> Tested alongside other patches in the series. OK to apply?
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * config/fixed-bit.h (fixed-bit-machine.h): Include.
> (DECORATE_FIXED_NAME): Conditionally define if undefined. Use
> throughout file to decorate function names.
> * config/fixed-bit-mach-generic.h: New.
> 
> libgcc/
> * Makefile.in (FIXED_BIT_MACHINE): New rule. Include
> target-specific or generic fixed_bit_machine_header to decorate the
> names of fixed-point helper functions.
> * fixed-obj.mk ($(o)_s$(objext)): Depend on $(FIXED_BIT_MACHINE).
> 
> 

OK.

R.

Re: [PATCH] ARM fixed-point support [3/6]: missing FIXED_CST in tree-ssa-sccvn.c:copy_reference_ops_from_ref

[Richard Earnshaw]

On 13/05/11 14:57, Julian Brown wrote:
> This patch adds FIXED_CST to copy_reference_ops_from_ref in
> tree-ssa-sccvn.c. Some test code (using fixed-point constants) failed
> for me without it. This looks obvious to me, unless there's some
> particular reason fixed-point constants need to be handled differently
> (or not at all) in that function.
> 
> Tested alongside other patches in the series. OK to apply?
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Support FIXED_CST.
> 

OK (provide that no tree-ssa maintainer objects in the next 24 hours).

R.

Re: [PATCH] ARM fixed-point support [2/6]: assembler format for fixed-point constants

[Richard Earnshaw]

On 13/05/11 14:57, Julian Brown wrote:
> This patch changes the format used to print fixed-point constants from
> hex to decimal. For instance a negative "short fract" fixed-point
> constant may be represented as a signed HOST_WIDE_INT from -1 to -128,
> which would currently be printed as e.g. 0xfffffxx, resulting in a
> "bignum truncated to fit" warning from the assembler. This trouble is
> avoided if we just print using integers instead, similarly to the way
> signed character-constants are emitted elsewhere in the compiler.
> 
> Tested along with the rest of the patch series. OK to apply?
> 
> Julian
> 
> ChangeLog
> 
> * final.c (output_addr_const): Print fixed-point constants as
> decimal not hex (avoiding an assembler overflow warning for
> negative byte constants).
> 

OK (but remove the parenthetical part of the ChangeLog).

R.

Re: [pph] Fixing string streaming functions and their comments (issue4654076)

[dnovillo]

On 2011/06/30 01:37:59, Gabriel Charette wrote:


2011-06-29  Gabriel Charette  



* pph-streamer.h (struct pph_stream): Fix comment of data_in field.
(pph_out_string_with_length): lto_output_string_with_length now

handles

NULL strings, call it directly.
(pph_in_string): Fix comment.


OK.


Diego.

http://codereview.appspot.com/4654076/

Re: [PATCH] ARM fixed-point support [1/6]: comparison optab biasing

[Richard Earnshaw]

On 13/05/11 14:57, Julian Brown wrote:
> As per Joseph's suggestion here:
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00846.html
> 
> I am re-posting machine-independent parts of my ARM fixed-point support
> patches, with explanations as to why each part is necessary.
> 
> This is the first: on ARM, TARGET_LIB_INT_CMP_BIASED is false for
> TARGET_BPABI targets (i.e. most currently-interesting cases --
> EABI comparison helper functions return -1/0/1 for lt/eq/gt rather than
> 0/1/2). However the fixed-point helper library uses biased comparisons
> unconditionally. So, this patch just makes comparisons between
> fixed-point quantities use the biasing rather than not. (Grepping
> config/, in practice, this will only affect ARM.)
> 
> Tested in a series with other fixed-point patches. OK to apply?
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * optabs.c (prepare_cmp_insn): Use correct biasing for fixed-point
> comparison helpers.
> 

OK.

R.

Re: [PATCH, ARM] Avoid element-order-dependent operations for quad-word vectors in big-endian mode for NEON

[Richard Earnshaw]

On 12/01/11 17:38, Julian Brown wrote:
> On Thu, 9 Dec 2010 14:56:39 +
> Julian Brown  wrote:
> 
>> On Thu, 9 Dec 2010 14:40:59 + (UTC)
>> "Joseph S. Myers"  wrote:
>>
>>> On Thu, 9 Dec 2010, Julian Brown wrote:
>>>
 Unfortunately for C only, since building C++ was broken at the
 time I started testing. Some tests fail to vectorize post-patch
 in BE mode (predictably, since fewer things end up vectorizable),
 but many execution tests transition from FAIL to PASS.
>>>
>>> Do any tests (scan, not execution) now fail for big endian in ways
>>> that indicate some of the check_effective_target_vect_* functions
>>> in target-supports.exp should be updated to know that certain
>>> features are only supported for little endian?
>>
>> Possibly, yes: I suspect a few of those may need updating, really. One
>> awkward bit is that I'm still allowing some of the operations for
>> double-word registers only -- I don't think the
>> check_effective_target_* tests will suffice to distinguish between
>> D-reg & Q-reg cases.
> 
> This version of the patch tweaks target-supports.exp to say that
> various operations are not available in big-endian mode (removing some
> of the FAILs from the previous version -- though in big-endian mode
> without -mvectorize-with-neon-quad, some tests have transitioned from
> PASS to XPASS. I'm not sure that's worth worrying about).
> 
> The main part of the patch remains unchanged.
> 
> OK to apply?
> 
> Cheers,
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * config/arm/neon.md (vec_shr_, vec_shl_): Disable in
> big-endian mode.
> (reduc_splus_, reduc_uplus_, reduc_smin_)
> (reduc_smax_, reduc_umin_, reduc_umax_)
> (neon_vec_unpack_lo_, neon_vec_unpack_hi_)
> (vec_unpack_hi_, vec_unpack_lo_)
> (neon_vec_mult_lo_, vec_widen_mult_lo_)
> (neon_vec_mult_hi_, vec_widen_mult_hi_)
> (vec_pack_trunc_, neon_vec_pack_trunc_): Disable for Q
> registers in big-endian mode.
> 
> gcc/testsuite/
> * lib/target-supports.exp
> (check_effective_target_arm_little_endian): New.
> (check_effective_target_vect_pack_trunc): Use above.
> (check_effective_target_vect_unpack): Likewise.
> (check_effective_target_vect_element_align): Test
> check_effective_target_arm_vect_no_misalign for ARM.
> 
> 

OK.

R.

[Patch, AVR, longlong.h]: Implement __clrsbhi2.

[Georg-Johann Lay]

The new count leading signs is not implemented for HI:

builtin-bitops-1.c:(.text+0xd1e): undefined reference to `__clrsbhi2'
FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O0

Extended clz/ctz support in longlong.h

With the patch testcase passes.

Johann

libgcc/
* config/avr/t-avr (intfuncs16): Add _clrsbXX2.

gcc/
* longlong.h (count_leading_zeros, count_trailing_zeros,
COUNT_LEADING_ZEROS_0): Define for target avr if W_TYPE_SIZE is 16
resp. 64.
Index: libgcc/config/avr/t-avr
===
--- libgcc/config/avr/t-avr	(revision 175628)
+++ libgcc/config/avr/t-avr	(working copy)
@@ -1,5 +1,5 @@
 # Extra 16-bit integer functions.
-intfuncs16 = _absvXX2 _addvXX3 _subvXX3 _mulvXX3 _negvXX2 
+intfuncs16 = _absvXX2 _addvXX3 _subvXX3 _mulvXX3 _negvXX2 _clrsbXX2
 
 hiintfuncs16 = $(subst XX,hi,$(intfuncs16))
 siintfuncs16 = $(subst XX,si,$(intfuncs16))
Index: gcc/longlong.h
===
--- gcc/longlong.h	(revision 175628)
+++ gcc/longlong.h	(working copy)
@@ -250,11 +250,27 @@ UDItype __umulsidi3 (USItype, USItype);
 #define COUNT_LEADING_ZEROS_0 32
 #endif
 
-#if defined (__AVR__) && W_TYPE_SIZE == 32
+#if defined (__AVR__)
+
+#if W_TYPE_SIZE == 16
+#define count_leading_zeros(COUNT,X)  ((COUNT) = __builtin_clz (X))
+#define count_trailing_zeros(COUNT,X) ((COUNT) = __builtin_ctz (X))
+#define COUNT_LEADING_ZEROS_0 16
+#endif /* W_TYPE_SIZE == 16 */
+
+#if W_TYPE_SIZE == 32
 #define count_leading_zeros(COUNT,X)  ((COUNT) = __builtin_clzl (X))
 #define count_trailing_zeros(COUNT,X) ((COUNT) = __builtin_ctzl (X))
 #define COUNT_LEADING_ZEROS_0 32
-#endif /* defined (__AVR__) && W_TYPE_SIZE == 32 */
+#endif /* W_TYPE_SIZE == 32 */
+
+#if W_TYPE_SIZE == 64
+#define count_leading_zeros(COUNT,X)  ((COUNT) = __builtin_clzll (X))
+#define count_trailing_zeros(COUNT,X) ((COUNT) = __builtin_ctzll (X))
+#define COUNT_LEADING_ZEROS_0 64
+#endif /* W_TYPE_SIZE == 64 */
+
+#endif /* defined (__AVR__) */
 
 #if defined (__CRIS__) && __CRIS_arch_version >= 3
 #define count_leading_zeros(COUNT, X) ((COUNT) = __builtin_clz (X))

Re: PATCH] PR 49580

[Zdenek Dvorak]

Hi,

> This patch fixes the build failure of gcc spec2006 benchmark.
> The change is in  gimple_duplicate_sese_tail(), where we need to subtract 
> 1 from the loop's number of iterations.
> The stmt created to change the rhs of the loop's condition, used to be 
> inserted right after the defining stmt of the rhs (an ssa name).
> This requires special handling of different cases of the defining stmt:
> 1.gimple_stmt
> 2.gimple_phi
> 3.default_def
> 
> Instead of handling each case separately, if we insert the new stmt at the 
> begining of the loop's preheader, we're sure that 
> it's already been defined.
> 
> Bootstrap and testsuite pass successfully (as autopar is not enabled by 
> default).
> No new regressions when the testsuite is run with autopar enabled.
> No new regressions for the run of spec2006 with autopar enabled, and gcc 
> benchmark now passes successfully.. 
> 
> OK for trunk? 

actually, I think a better approach would be not to have this kind of 
pass-specific
adjustments in gimple_duplicate_sese_tail at all.  The code decreasing the 
number of
iterations in gimple_duplicate_sese_tail only works because parloops does 
induction
variable canonicalization first; should we need it to be used anywhere else, it 
will break.
I.e., parloops should first transform the condition so that it does the 
comparison with
the adjusted value, and then gimple_duplicate_sese_tail could do just code 
copying
and cfg changes,

Zdenek

Re: [PATCH 00/12] Eliminate the text-based dwarf2out interface

[Bernd Schmidt]

On 06/29/11 23:49, Richard Henderson wrote:
> In preparation for the changes required to support shrink-wrapping,
> it makes things Much Easier if we no longer have to handle seeing
> new unwind states being introduced during pass_final, while emitting
> the actual assembly.  Thus we want to convert everything that used
> the text-based interfaces to use the REG_CFA_* notes instead.
> 
> The following set has been tested on i386-linux, x86_64-linux,
> ia64-linux, arm-elf, arm-eabi, and a cross-compile to vax-linux.
> 
> 
> r~
> 
> 
> Richard Henderson (12):
>   dwarf2out: Convert regs_saved_in_regs to VEC.
>   dwarf2out: Handle pc_rtx as return column in REG_CFA_OFFSET too.
>   dwarf2out: Add REG_CFA_FLUSH_QUEUE.
>   vax: Emit prologue as rtl.
>   arm: Use REG_CFA_REGISTER instead of UNSPEC_STACK_ALIGN.
>   ia64: Issue REG_CFA_REGISTER for ar.pfs at alloc insn.
>   ia64: Remove ia64_dwarf2out_def_steady_cfa.
>   ia64: Use pc_rtx to save the return address.
>   ia64: Remove dead code in process_epilogue.
>   ia64: Remove TARGET_DWARF_HANDLE_FRAME_UNSPEC hook.
>   i386: Always use TARGET_DEEP_BRANCH_PREDICTION.
>   dwarf2out: Remove unused text-based unwind entry points.

Thanks so much for working on this. Ok for the dwarf2out parts, and I
guess the other bits as well absent any target maintainer objections in
a day or two.


Bernd

Re: PATCH] PR 49580

[Richard Guenther]

On Thu, Jun 30, 2011 at 2:00 PM, Razya Ladelsky  wrote:
> Hi,
>
> This patch fixes the build failure of gcc spec2006 benchmark.
> The change is in  gimple_duplicate_sese_tail(), where we need to subtract
> 1 from the loop's number of iterations.
> The stmt created to change the rhs of the loop's condition, used to be
> inserted right after the defining stmt of the rhs (an ssa name).
> This requires special handling of different cases of the defining stmt:
> 1.gimple_stmt
> 2.gimple_phi
> 3.default_def
>
> Instead of handling each case separately, if we insert the new stmt at the
> begining of the loop's preheader, we're sure that
> it's already been defined.
>
> Bootstrap and testsuite pass successfully (as autopar is not enabled by
> default).
> No new regressions when the testsuite is run with autopar enabled.
> No new regressions for the run of spec2006 with autopar enabled, and gcc
> benchmark now passes successfully..
>
> OK for trunk?

+   preheader = loop_preheader_edge(orig_loop)->src;

space after loop_preheader_edge.

Otherwise ok.
Thanks,
Richard.

> Thanks,
> Razya
>
>

PATCH] PR 49580

[Razya Ladelsky]

Hi,

This patch fixes the build failure of gcc spec2006 benchmark.
The change is in  gimple_duplicate_sese_tail(), where we need to subtract 
1 from the loop's number of iterations.
The stmt created to change the rhs of the loop's condition, used to be 
inserted right after the defining stmt of the rhs (an ssa name).
This requires special handling of different cases of the defining stmt:
1.gimple_stmt
2.gimple_phi
3.default_def

Instead of handling each case separately, if we insert the new stmt at the 
begining of the loop's preheader, we're sure that 
it's already been defined.

Bootstrap and testsuite pass successfully (as autopar is not enabled by 
default).
No new regressions when the testsuite is run with autopar enabled.
No new regressions for the run of spec2006 with autopar enabled, and gcc 
benchmark now passes successfully.. 

OK for trunk? 
Thanks,
Razya

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 174166)
+++ gcc/tree-cfg.c  (working copy)
@@ -5401,7 +5401,6 @@ gimple_duplicate_sese_tail (edge entry ATTRIBUTE_U
   gimple cond_stmt;
   edge sorig, snew;
   basic_block exit_bb;
-  basic_block iters_bb;
   tree new_rhs;
   gimple_stmt_iterator psi;
   gimple phi;
@@ -5501,11 +5500,10 @@ gimple_duplicate_sese_tail (edge entry ATTRIBUTE_U
 
 if (TREE_CODE (gimple_cond_rhs (cond_stmt)) == SSA_NAME)
   {
-   iters_bb = gimple_bb (SSA_NAME_DEF_STMT (gimple_cond_rhs (cond_stmt)));
-   for (gsi1 = gsi_start_bb (iters_bb); !gsi_end_p (gsi1); gsi_next 
(&gsi1))
- if (gsi_stmt (gsi1) == SSA_NAME_DEF_STMT (gimple_cond_rhs 
(cond_stmt)))
-   break;
+   basic_block preheader;
 
+   preheader = loop_preheader_edge(orig_loop)->src;
+   gsi1 = gsi_after_labels (preheader);
new_rhs = force_gimple_operand_gsi (&gsi1, new_rhs, true,

NULL_TREE,false,GSI_CONTINUE_LINKING);
   }
=
22-12-2009  Razya Ladelsky  

* tree-cfg.c (gimple_duplicate_sese_tail): Insert the stmt caclculating 
the new rhs
 of the loop's condition stmt to the preheader instead of iters_bb.
=

Re: [patch tree-optimization]: Do bitwise operator optimizations for X op !X patterns

[Richard Guenther]

On Wed, Jun 29, 2011 at 3:00 PM, Kai Tietz  wrote:
> - Original Message -
> From: "Kai Tietz" 
> To: "Richard Guenther" 
> Cc: gcc-patches@gcc.gnu.org
> Sent: Wednesday, June 29, 2011 1:33:30 PM
> Subject: Re: [patch tree-optimization]: Do bitwise operator optimizations for 
> X op !X patterns
>
> - Original Message -
> From: "Richard Guenther" 
> To: "Kai Tietz" 
> Cc: gcc-patches@gcc.gnu.org
> Sent: Wednesday, June 29, 2011 12:14:10 PM
> Subject: Re: [patch tree-optimization]: Do bitwise operator optimizations for 
> X op !X patterns
>
> On Tue, Jun 28, 2011 at 5:05 PM, Kai Tietz  wrote:
>> Hello,
>>
>> this patch implements the X op !X patterns within tree-ssa-forwprop.c 
>> without using here const-fold routines.  Additionally it does some trivial 
>> folding for X op X.  Implementation
>> also looks through [(type)] X op [(type)] !X, if type of X is integral and 
>> precision is suitable
>> for operation.
>>
>> ChangeLog gcc/
>>
>> 2011-06-28  Kai Tietz  
>>
>>        * tree-ssa-forwprop.c (operand_precision_onep): New
>>        function.
>>        (find_possible_not_expr_argument): Likewise.
>>        (simplify_bitwise_binary_1): Likewise.
>>        (simplify_bitwise_binary): Use simplify_bitwise_binary_1
>>        for detecting various X op !X optimizations.
>>
>> ChangeLog gcc/testsuite
>>
>> 2011-06-28  Kai Tietz  
>>
>>        * gcc.dg/binop-notand1a.c: New test.
>>        * gcc.dg/binop-notand2a.c: New test.
>>        * gcc.dg/binop-notand3a.c: New test.
>>        * gcc.dg/binop-notand4a.c: New test.
>>        * gcc.dg/binop-notand5a.c: New test.
>>        * gcc.dg/binop-notand6a.c: New test.
>>        * gcc.dg/binop-notor1.c: New test.
>>        * gcc.dg/binop-notor2.c: New test.
>>        * gcc.dg/binop-notxor1.c: New test.
>>        * gcc.dg/binop-notxor2.c: New test.
>>
>> Bootstrapped and regression tested for all languages plus Ada and Obj-C for 
>> x86_64-pc-linux-gnu. Ok for apply?
>
> I can't follow the code in find_possible_not_expr_argument or its uses
> at all.  Please try to produce patches that look more obvious in what
> they are doing - don't try to solve every testcase you can come up with
> in a single patch.  Especially don't write functions like
> find_possible_not_expr_argument which seems to have evolved a lot
> after you wrote the overall function comment.
>
> Thanks,
> Richard.
>
>> Regards,
>> Kai
>>
>
> Well, I added some comments to these functions and renamed the 
> find_possible_not_expr_argument function to detect_not_expr_operand, which 
> hits its use better.
> The cause for this function is, that there are more then one variant of 
> expressing a logical-not and all of them are used.
> This routine simply tries to detect different variants used for not. Eg ~X == 
> !X and (X ^ 1) == !X for integral type of X with precision one. For X with 
> integral type, (X == 0) == !X.
>
> The folding for the three different bitwise-operations is pretty easy and it 
> makes sense to implement them at once.  I see here no good point to separate 
> them into different patches.  To separate them might even lead to questions 
> about abstracting some code-pieces out of the main function.
> I didn't added testcases for all variants I am aware now. Just those, which 
> are now handled.
>
> So hope you can read and understand logic of patch better by updated patch.
>
> Regards,
> Kai
>
> I found that in version I've sent there is an unclosed comment.  So here is 
> updated patch, which additionally simplify some code to ease reading.

Ok, I'm going to comment on a few things in the patch.

+/* Checks if expression has type of one-bit precision, or is result of
+   a known boolean expression.  */
+static bool
+operand_precision_onep (tree expr)
+{
+  enum tree_code code;
+  gimple def_stmt;
+
+  do
+{
+  code = TREE_CODE (expr);
+  if (!INTEGRAL_TYPE_P (TREE_TYPE (expr)))
+   return false;
+  if (TYPE_PRECISION (TREE_TYPE (expr)) == 1)
+   return true;
+  if (code != SSA_NAME)
+   break;
+  def_stmt = SSA_NAME_DEF_STMT (expr);
+  if (!def_stmt || !is_gimple_assign (def_stmt))
+   break;
+  code = gimple_assign_rhs_code (def_stmt);
+  if (!CONVERT_EXPR_CODE_P (code))
+   break;
+  expr = gimple_assign_rhs1 (def_stmt);
+}
+  while (CONVERT_EXPR_CODE_P (code));
+
+  if (code == TRUTH_NOT_EXPR || TREE_CODE_CLASS (code) == tcc_comparison)
+return true;
+  return false;
+}

Please don't do arbitrary deep lookups like this.  Instead this
function should be

bool
truth_valued_ssa_name_p (tree name)
{
  tree type = TREE_TYPE (name);
  gimple def_stmt;

  if (!INTEGRAL_TYPE_P (type))
return false;
  if (TREE_CODE (type) == BOOLEAN_TYPE
  || TYPE_PRECISION (type) == 1)
return true;

  def_stmt = SSA_NAME_DEF_STMT (name);
  if (is_gimple_assign (def_stmt))
return truth_value_p (gimple_assign_rhs_code (def_stmt));
  return false;
}

+static tree
+detect_not_expr_operand (tree name, tree *nexpr)

sam

Re: [trans-mem] Beginning of refactoring

[Torvald Riegel]

On Wed, 2011-06-29 at 16:01 -0700, Richard Henderson wrote:
> On 05/25/2011 02:10 PM, Torvald Riegel wrote:
> > Patch 2: _ITM_dropReferences is not sufficiently defined in the ABI. It
> > seems to target some form of open nesting for txnal wrappers, but the
> > prose in the ABI specification is unclear. Thus, disable this for now
> > (aka fatal runtime error), and expect the related tests to fail. Pick it
> > up again once that the ABI has been improved and the use cases are
> > clear.
> 
> Sure, but please actually delete the code rather than just comment it out.

Fixed in updated patch2.

> > Patch 3: The actual change in how ABI calls are dispatched. Also,
> > removed method-readonly (broken, will in a similar form reappear in the
> > family of globallock-based algorithms), and disabled method-wbetl (needs
> > larger refactoring, will be revived/remerged later).
> 
> > +CREATE_DISPATCH_FUNCTIONS_T_MEMCPY(M256, GTM::abi_disp()->_, )
> > +CREATE_DISPATCH_FUNCTIONS_T_MEMCPY(M64, GTM::abi_disp()->_, )
> > +CREATE_DISPATCH_FUNCTIONS_T_MEMCPY(M128, GTM::abi_disp()->_, )
> > +CREATE_DISPATCH_FUNCTIONS(GTM::abi_disp()->_, )
> 
> What's the point of using "GTM::abi_disp()->_" as a mandatory argument?
> 
> Further, that second "M2" argument is universally empty.  What's that?

This prepares us to be later able to instantiate ABI mem access
functions without having to go through the vtable dispatch (thus,
avoiding the overhead of the vtable dispatch / indirection). This will
become useful as soon as GCC can create several code paths with
different instrumentation (ie, calling different sets of _ITM_*
functions) for each transaction. Together with LTO, this will allow us
to have the TM implementation in the library and still be as fast as
direct TM support in the compiler.

How it works is that in a TM-method-specific dispatch class we would add
  CREATE_DISPATCH_METHODS(static, _static)
in addition to the 
  CREATE_DISPATCH_METHODS(virtual, )
that is currently there. In barrier.cc we can then do
  CREATE_DISPATCH_FUNCTIONS(GTM::serial_dispatch::_, _static)
and thus bypass the virtual functions, but still keep one implementation
of the TM method (in the static template functions). This example would
create functions that just use the serial-mode accesses.

Right now, CREATE_DISPATCH_FUNCTIONS will always create the same set of
functions (with names as specified in the ABI), but this is because we
haven't defined yet how those we would separate different
instrumentations (eg, name mangling vs. sth. else).

The trailing underscore at the end of the first param is to make the
preprocessor happen. Is there a better way to let it accept
"GTM::abi_disp()->" as argument?

> 
> > +// Creates memcpy/memmove/memset methods.
> > +#define CREATE_DISPATCH_METHODS_MEM()  \
> > +virtual void _memtransfer(void *dst, const void* src, size_t size, \
> > +bool may_overlap, ls_modifier dst_mod, ls_modifier src_mod)   \
> > +{ \
> > +  memtransfer_static(dst, src, size, may_overlap, dst_mod, src_mod);  \
> > +} \
> > +virtual void _memset(void *dst, int c, size_t size, ls_modifier mod)   \
> > +{ \
> > +  memset_static(dst, c, size, mod);   \
> > +}
> 
> Why are the memtransfer and memset virtuals distinguished from the statics?
> For the patch as written it would seem to be ok to merge them.

For the same reason as above. We seem to need two entry points (virtual
and static) to make that work. In the updated patch3, I add leading
underscores to make the _static version above actually work.

> > +#define ITM_MEMTRANSFER_DEF(TARGET, M2, NAME, READ, WRITE) \
> > +void ITM_REGPARM _ITM_memcpy##NAME(void *dst, const void *src, size_t 
> > size)  \
> > +{  
> >   \
> > +  TARGET##memtransfer##M2 (dst, src, size, 
> >   \
> > + false, GTM::abi_dispatch::WRITE, GTM::abi_dispatch::READ);
> >   \
> > +}  
> >   \
> > +void ITM_REGPARM _ITM_memmove##NAME(void *dst, const void *src, size_t 
> > size) \
> > +{  
> >   \
> > +  if (GTM::abi_dispatch::NONTXNAL == GTM::abi_dispatch::WRITE ||   
> >   \
> > +  GTM::abi_dispatch::NONTXNAL == GTM::abi_dispatch::READ)  
> >   \
> > +{  
> >   \
> > +  if (((uintptr_t)dst <= (uintptr_t)src ?  
> >   \
> > +  (uintptr_t)dst + size > (uintptr_t)src : 
> >   \
> > +  (uintptr_t)src + size > (uintptr_t)dst)) 
> >   \
>

New German PO file for 'gcc' (version 4.6.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-4.6.0.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [Patch] Fix objc/48109

[Richard Guenther]

On Thu, Jun 30, 2011 at 12:50 PM, Iain Sandoe
 wrote:
>
> On 30 Jun 2011, at 11:27, Richard Guenther wrote:
>
>> On Wed, Jun 29, 2011 at 7:47 PM, Iain Sandoe
>>  wrote:
>>>
>>> The bug arises because of the use, by the ObjC FE, of two old target
>>> macros
>>> that emit efficient representations of class definitions and references.
>>>
>>> This 'works fine' (however wrong it might be conceptually), until LTO is
>>> engaged, whereupon the definitions vanish without trace (since no
>>> corresponding real variable is ever created).
>>>
>>> ---
>>>
>>> The patch creates appropriate variables in the FE and tags them as ObjC
>>> meta-data (in the same manner as is done for other objc meta-data).
>>>
>>> We then intercept them in varasm.c with a hook that allows the target to
>>> declare that it has completely handled the output of a variable -
>>> allowing
>>> us to handle them in the required special manner.
>>>
>>> FAOD, It is necessary to preserve this mechanism for emitting the
>>> definitions and references to permit linkage with existing system
>>> libraries.
>>>
>>> 
>>>
>>> If the patch is acceptable, then I would expect to follow up with a patch
>>> to
>>> remove ASM_DECLARE_CLASS_REFERENCE and ASM_DECLARE_UNRESOLVED_REFERENCE
>>> from
>>> the tree - since this is their only use.
>>>
>>> 
>>>
>>> bootstrapped on i686-linux, i686-darwin9, x86_64-darwin10,  (checked to
>>> do
>>> the Right Thing on darwin).
>>>
>>> Mike has already given this a 'seems reasonable' in the PR thread,
>>> however,
>>> I need an approver for the varasm.c and target hook changes.
>>>
>>> OK for trunk & 4.6?
>>
>> Where does the target handle output of the variable?  If it is in the hook
>> then that hook is misnamed - it should then probably be called
>> assemble_variable.
>
> It is in the hook,
> hence named "handled_assemble_variable_p"
> .. allowing us to test if the target has completed the work and finish
> assemble_variable () early.
>
> Does that explain it better? - would an expanded comment help?
>
> (I am happy to use any name generally agreed, but IMO the name should convey
> the idea that the result should be tested to determine if the target did the
> work, or it will be confusing to maintain).

Well, as it certainly isn't a predicate but is supposed to do the actual
work simply calling it assemble_variable is better.

>> Not sure if this is the most reasonable piece of
>> assemble_variable to split out to a hook though.
>
> It is only used by darwin at present - so nothing is split out for any other
> target (the default hook is simply 'false').

Yes, I've seen that.  Still a hook like this should be generally useful,
and you still process through some pieces of assemble_variable
while you choose to skip some other piece - it should probably be
documented which part of assemble_variable is supposed to be handled
by the hook.

I'll defer to Richard for this (and the approval).

> Initially, I thought about simply moving the ASM_DECLARE_CLASS_REFERENCE and
> ASM_DECLARE_UNRESOLVED_REFERENCE to varasm.c
>
> However, there seems to be a general move to use hooks instead of macros,
> and this seemed like a good time to make the change (and pave the way to
> remove those two macros from the tree).
>
> If the consensus is a preference to retain the macros - I could re-work the
> patch to do that.

No, a hook is definitely better.

>> I'm not sure we want to backport this though (there isn't even a bugreport
>> about it?).
>
> PR48109, reported initially against 4.6.0 (before it forked);
> ... I guess it's also wrong code under LTO.

So the ChangeLog should mention this PR.

Richard.

> thanks
> Iain
>
>>
>> Thanks,
>> Richard.
>>
>>> Iain
>>>
>>> ===
>>>
>>> gcc/
>>>
>>>       * target.def (handled_assemble_variable_p): New hook.
>>>       * varasm.c (assemble_variable): Allow target to handle variable
>>> output
>>>       in some special manner.
>>>       * doc/tm.texi: Regenerate.
>>>       * config/darwin.c (darwin_objc1_section): Handle class defs/refs.
>>>       (darwin_handled_assemble_variable_p): New.
>>>       * config/darwin-protos.h (darwin_handled_assemble_variable_p): New.
>>>       * config/darwin.h (TARGET_ASM_HANDLED_ASSEMBLE_VARIABLE_P): New.
>>>
>>> gcc/objc/
>>>
>>>       *objc-next-runtime-abi-01.c (handle_next_class_ref): Don't emit
>>> lazy
>>> refs. for
>>>       cases where the class is local.  Declare a real, meta-data item
>>> tagged as
>>>       a class reference.
>>>       (handle_next_impent): Declare a real, meta-data item tagged as a
>>> class def.
>>>
>>> ===
>>>
>>> Index: gcc/target.def
>>> ===
>>> --- gcc/target.def      (revision 175628)
>>> +++ gcc/target.def      (working copy)
>>> @@ -449,6 +449,13 @@ DEFHOOK
>>>  bool, (FILE *file, rtx x),
>>>  default_asm_output_addr_const_extra)
>>>
>>> +DEFHOOK
>>> +(handled_assemble_variable_p,
>>> + "Returns @code{true} iff the target has handled the assembly of the\
>>> +

Re: [Patch] Fix objc/48109

[Iain Sandoe]

On 30 Jun 2011, at 11:27, Richard Guenther wrote:


On Wed, Jun 29, 2011 at 7:47 PM, Iain Sandoe
 wrote:
The bug arises because of the use, by the ObjC FE, of two old  
target macros
that emit efficient representations of class definitions and  
references.


This 'works fine' (however wrong it might be conceptually), until  
LTO is

engaged, whereupon the definitions vanish without trace (since no
corresponding real variable is ever created).

---

The patch creates appropriate variables in the FE and tags them as  
ObjC

meta-data (in the same manner as is done for other objc meta-data).

We then intercept them in varasm.c with a hook that allows the  
target to
declare that it has completely handled the output of a variable -  
allowing

us to handle them in the required special manner.

FAOD, It is necessary to preserve this mechanism for emitting the
definitions and references to permit linkage with existing system  
libraries.




If the patch is acceptable, then I would expect to follow up with a  
patch to
remove ASM_DECLARE_CLASS_REFERENCE and  
ASM_DECLARE_UNRESOLVED_REFERENCE from

the tree - since this is their only use.



bootstrapped on i686-linux, i686-darwin9, x86_64-darwin10,   
(checked to do

the Right Thing on darwin).

Mike has already given this a 'seems reasonable' in the PR thread,  
however,

I need an approver for the varasm.c and target hook changes.

OK for trunk & 4.6?


Where does the target handle output of the variable?  If it is in  
the hook

then that hook is misnamed - it should then probably be called
assemble_variable.


It is in the hook,
hence named "handled_assemble_variable_p"
.. allowing us to test if the target has completed the work and finish  
assemble_variable () early.


Does that explain it better? - would an expanded comment help?

(I am happy to use any name generally agreed, but IMO the name should  
convey the idea that the result should be tested to determine if the  
target did the work, or it will be confusing to maintain).



Not sure if this is the most reasonable piece of
assemble_variable to split out to a hook though.


It is only used by darwin at present - so nothing is split out for any  
other target (the default hook is simply 'false').


Initially, I thought about simply moving the  
ASM_DECLARE_CLASS_REFERENCE and ASM_DECLARE_UNRESOLVED_REFERENCE to  
varasm.c


However, there seems to be a general move to use hooks instead of  
macros, and this seemed like a good time to make the change (and pave  
the way to remove those two macros from the tree).


If the consensus is a preference to retain the macros - I could re- 
work the patch to do that.


I'm not sure we want to backport this though (there isn't even a  
bugreport

about it?).


PR48109, reported initially against 4.6.0 (before it forked);
... I guess it's also wrong code under LTO.

thanks
Iain



Thanks,
Richard.


Iain

===

gcc/

   * target.def (handled_assemble_variable_p): New hook.
   * varasm.c (assemble_variable): Allow target to handle  
variable

output
   in some special manner.
   * doc/tm.texi: Regenerate.
   * config/darwin.c (darwin_objc1_section): Handle class defs/ 
refs.

   (darwin_handled_assemble_variable_p): New.
   * config/darwin-protos.h  
(darwin_handled_assemble_variable_p): New.
   * config/darwin.h (TARGET_ASM_HANDLED_ASSEMBLE_VARIABLE_P):  
New.


gcc/objc/

   *objc-next-runtime-abi-01.c (handle_next_class_ref): Don't  
emit lazy

refs. for
   cases where the class is local.  Declare a real, meta-data  
item

tagged as
   a class reference.
   (handle_next_impent): Declare a real, meta-data item tagged  
as a

class def.

===

Index: gcc/target.def
===
--- gcc/target.def  (revision 175628)
+++ gcc/target.def  (working copy)
@@ -449,6 +449,13 @@ DEFHOOK
 bool, (FILE *file, rtx x),
 default_asm_output_addr_const_extra)

+DEFHOOK
+(handled_assemble_variable_p,
+ "Returns @code{true} iff the target has handled the assembly of  
the\

+  variable @var{var_decl}",
+ bool, (tree var_decl),
+ hook_bool_tree_false)
+
 /* ??? The TARGET_PRINT_OPERAND* hooks are part of the asm_out  
struct,
   even though that is not reflected in the macro name to override  
their

   initializers.  */
Index: gcc/objc/objc-next-runtime-abi-01.c
===
--- gcc/objc/objc-next-runtime-abi-01.c (revision 175628)
+++ gcc/objc/objc-next-runtime-abi-01.c (working copy)
@@ -2267,27 +2267,51 @@ generate_objc_symtab_decl (void)
  init_objc_symtab (TREE_TYPE (UOBJC_SYMBOLS_decl)));
 }

-
 static void
 handle_next_class_ref (tree chain)
 {
+  tree decl, exp;
+  struct imp_entry *impent;
  const char *name = IDENTIFIER_POINTER (TREE_VALUE (chain));
  char *string = (char *) alloca (strlen (name) + 30);

+  for (impent = imp_list; impent; impent = impent->next)
+if (TREE_CODE (im

[committed] Fix BUILT_IN_ASSUME_ALIGNED handling in find_func_aliases_for_builtin_call

[Jakub Jelinek]

Hi!

__builtin_assume_aligned here needs to be handled just like a lhs = dest
assignment, while for memcpy/etc. resp. memset/etc. it was doing some
further processing, undesirable for this builtin.
Fixed thusly, tested on x86_64-linux, acked by Richi on IRC, committed to
trunk.

2011-06-30  Jakub Jelinek  

* tree-ssa-structalias.c (find_func_aliases_for_builtin_call): Fix
handling of BUILT_IN_ASSUME_ALIGNED.

--- gcc/tree-ssa-structalias.c.jj   2011-06-30 10:05:04.0 +0200
+++ gcc/tree-ssa-structalias.c  2011-06-30 11:02:01.462671158 +0200
@@ -4002,7 +4002,6 @@ find_func_aliases_for_builtin_call (gimp
   case BUILT_IN_STPCPY_CHK:
   case BUILT_IN_STRCAT_CHK:
   case BUILT_IN_STRNCAT_CHK:
-  case BUILT_IN_ASSUME_ALIGNED:
{
  tree res = gimple_call_lhs (t);
  tree dest = gimple_call_arg (t, (DECL_FUNCTION_CODE (fndecl)
@@ -4068,6 +4067,20 @@ find_func_aliases_for_builtin_call (gimp
  VEC_free (ce_s, heap, lhsc);
  return true;
}
+  case BUILT_IN_ASSUME_ALIGNED:
+   {
+ tree res = gimple_call_lhs (t);
+ tree dest = gimple_call_arg (t, 0);
+ if (res != NULL_TREE)
+   {
+ get_constraint_for (res, &lhsc);
+ get_constraint_for (dest, &rhsc);
+ process_all_all_constraints (lhsc, rhsc);
+ VEC_free (ce_s, heap, lhsc);
+ VEC_free (ce_s, heap, rhsc);
+   }
+ return true;
+   }
   /* All the following functions do not return pointers, do not
 modify the points-to sets of memory reachable from their
 arguments and do not add to the ESCAPED solution.  */

Jakub

Re: [PATCH] Add support on powerpc to change CASE_VALUES_THRESHOLD

[Richard Guenther]

On Thu, Jun 30, 2011 at 12:34 AM, Michael Meissner
 wrote:
> On the powerpc, switch statements can be expensive, and we would like to be
> able to tune the threshold of when the compiler generates if statements
> vs. using a table jump operation (and different processors within the powerpc
> have different limits).  This patch adds a powerpc tuning option to control
> this.
>
> I've done bootstraps and make checks with no regressions.  Is this ok to apply
> to the trunk?  At this time, I am not changing the default value (4).  With 
> the
> option, I've seen a few spec 2006 benchmarks run faster, and a few run slower.

Hmm.  This hook looks like it could be turned into a --param.  In fact
it doesn't get whatever context information, so I wonder if any target
does something fancy.

Richard.

> [gcc]
> 2011-06-29  Michael Meissner  
>
>        * config/rs6000/rs6000.opt (-mcase-values-threshold): New switch.
>
>        * config/rs6000/rs6000.c (TARGET_CASE_VALUES_THRESHOLD): New
>        target hook for override choice of when to do jump table vs. if
>        statements based on -mcase-values-threshold=.
>
>        * doc/invoke.texi (RS/6000 and PowerPC Options): Document
>        -mcase-values-threshold.
>
> [gcc/testsuite]
> 2011-06-29  Michael Meissner  
>
>        * gcc.target/powerpc/ppc-switch-1.c: New test for
>        -mcase-values-threshold.
>        * gcc.target/powerpc/ppc-switch-2.c: Ditto.
>
> --
> Michael Meissner, IBM
> 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
> meiss...@linux.vnet.ibm.com     fax +1 (978) 399-6899
>

Re: [Patch] Fix objc/48109

[Richard Guenther]

On Wed, Jun 29, 2011 at 7:47 PM, Iain Sandoe
 wrote:
> The bug arises because of the use, by the ObjC FE, of two old target macros
> that emit efficient representations of class definitions and references.
>
> This 'works fine' (however wrong it might be conceptually), until LTO is
> engaged, whereupon the definitions vanish without trace (since no
> corresponding real variable is ever created).
>
> ---
>
> The patch creates appropriate variables in the FE and tags them as ObjC
> meta-data (in the same manner as is done for other objc meta-data).
>
> We then intercept them in varasm.c with a hook that allows the target to
> declare that it has completely handled the output of a variable - allowing
> us to handle them in the required special manner.
>
> FAOD, It is necessary to preserve this mechanism for emitting the
> definitions and references to permit linkage with existing system libraries.
>
> 
>
> If the patch is acceptable, then I would expect to follow up with a patch to
> remove ASM_DECLARE_CLASS_REFERENCE and ASM_DECLARE_UNRESOLVED_REFERENCE from
> the tree - since this is their only use.
>
> 
>
> bootstrapped on i686-linux, i686-darwin9, x86_64-darwin10,  (checked to do
> the Right Thing on darwin).
>
> Mike has already given this a 'seems reasonable' in the PR thread, however,
> I need an approver for the varasm.c and target hook changes.
>
> OK for trunk & 4.6?

Where does the target handle output of the variable?  If it is in the hook
then that hook is misnamed - it should then probably be called
assemble_variable.  Not sure if this is the most reasonable piece of
assemble_variable to split out to a hook though.

I'm not sure we want to backport this though (there isn't even a bugreport
about it?).

Thanks,
Richard.

> Iain
>
> ===
>
> gcc/
>
>        * target.def (handled_assemble_variable_p): New hook.
>        * varasm.c (assemble_variable): Allow target to handle variable
> output
>        in some special manner.
>        * doc/tm.texi: Regenerate.
>        * config/darwin.c (darwin_objc1_section): Handle class defs/refs.
>        (darwin_handled_assemble_variable_p): New.
>        * config/darwin-protos.h (darwin_handled_assemble_variable_p): New.
>        * config/darwin.h (TARGET_ASM_HANDLED_ASSEMBLE_VARIABLE_P): New.
>
> gcc/objc/
>
>        *objc-next-runtime-abi-01.c (handle_next_class_ref): Don't emit lazy
> refs. for
>        cases where the class is local.  Declare a real, meta-data item
> tagged as
>        a class reference.
>        (handle_next_impent): Declare a real, meta-data item tagged as a
> class def.
>
> ===
>
> Index: gcc/target.def
> ===
> --- gcc/target.def      (revision 175628)
> +++ gcc/target.def      (working copy)
> @@ -449,6 +449,13 @@ DEFHOOK
>  bool, (FILE *file, rtx x),
>  default_asm_output_addr_const_extra)
>
> +DEFHOOK
> +(handled_assemble_variable_p,
> + "Returns @code{true} iff the target has handled the assembly of the\
> +  variable @var{var_decl}",
> + bool, (tree var_decl),
> + hook_bool_tree_false)
> +
>  /* ??? The TARGET_PRINT_OPERAND* hooks are part of the asm_out struct,
>    even though that is not reflected in the macro name to override their
>    initializers.  */
> Index: gcc/objc/objc-next-runtime-abi-01.c
> ===
> --- gcc/objc/objc-next-runtime-abi-01.c (revision 175628)
> +++ gcc/objc/objc-next-runtime-abi-01.c (working copy)
> @@ -2267,27 +2267,51 @@ generate_objc_symtab_decl (void)
>                   init_objc_symtab (TREE_TYPE (UOBJC_SYMBOLS_decl)));
>  }
>
> -
>  static void
>  handle_next_class_ref (tree chain)
>  {
> +  tree decl, exp;
> +  struct imp_entry *impent;
>   const char *name = IDENTIFIER_POINTER (TREE_VALUE (chain));
>   char *string = (char *) alloca (strlen (name) + 30);
>
> +  for (impent = imp_list; impent; impent = impent->next)
> +    if (TREE_CODE (impent->imp_context) == CLASS_IMPLEMENTATION_TYPE
> +        && IDENTIFIER_POINTER (CLASS_NAME (impent->imp_context))
> +           == IDENTIFIER_POINTER (TREE_VALUE (chain)))
> +      return; /* we declare this, no need for a lazy ref.  */
> +
>   sprintf (string, ".objc_class_name_%s", name);
>
> -#ifdef ASM_DECLARE_UNRESOLVED_REFERENCE
> -  ASM_DECLARE_UNRESOLVED_REFERENCE (asm_out_file, string);
> -#else
> -  return ; /* NULL build for targets other than Darwin.  */
> -#endif
> +  decl = build_decl (UNKNOWN_LOCATION,
> +                    VAR_DECL, get_identifier (string), char_type_node);
> +  TREE_PUBLIC (decl) = 1;
> +  DECL_EXTERNAL (decl) = 1;
> +  DECL_CONTEXT (decl) = NULL_TREE;
> +  finish_var_decl (decl, NULL);
> +
> +  /* We build a variable to signal the reference.  This will be intercepted
> +     and output as a lazy reference.  */
> +  sprintf (string, "_OBJC_class_ref_%s", name);
> +  exp = build1 (ADDR_EXPR, string_type_node, decl);
> +  decl = build_decl (input_location,
> +                    VAR_DECL, get_ide

Re: [PATCH] Sign extend before converting constants to GMP values.

[Richard Guenther]

On Wed, 29 Jun 2011, Sebastian Pop wrote:

> Hi,
> 
> This patch fixes PR47653 by sign extending the double int constants
> before converting them to a GMP value.  There still are some places
> where we should not sign extend the values converted: upper bounds of
> unsigned types should for example not be sign extended.
> 
> The patch passed make -k check RUNTESTFLAGS=graphite.exp on c,c++,fortran.
> Regstrap with all languages in progress on amd64-linux.  Ok for trunk?
> 
> Thanks,
> Sebastian
> 
> 
> 2011-06-29  Sebastian Pop  
> 
>   PR tree-optimization/47653
>   * graphite-ppl.h (tree_int_to_gmp): Sign extend before converting
>   constants to GMP values.  Add a sext parameter.
>   (ppl_set_inhomogeneous_tree): Add sext parameter.
>   (ppl_set_coef_tree): Removed.
>   * graphite-sese-to-poly.c (scan_tree_for_params_right_scev): Adjust
>   call to tree_int_to_gmp.
>   (scan_tree_for_params_int): Use tree_int_to_gmp.
>   (scan_tree_for_params): Adjust call to tree_int_to_gmp.
>   (build_loop_iteration_domains): Adjust call to
>   ppl_set_inhomogeneous_tree.
>   (add_param_constraints): Same.
>   (pdr_add_data_dimensions): Same.
> 
>   * gcc.dg/graphite/run-id-pr47653.c: New.
> ---
>  gcc/ChangeLog  |   16 
>  gcc/graphite-ppl.h |   30 +--
>  gcc/graphite-sese-to-poly.c|   27 ++---
>  gcc/testsuite/ChangeLog|5 
>  gcc/testsuite/gcc.dg/graphite/run-id-pr47653.c |   17 +
>  5 files changed, 63 insertions(+), 32 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/graphite/run-id-pr47653.c
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index e37d823..bed0070 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,19 @@
> +2011-06-29  Sebastian Pop  
> +
> + PR tree-optimization/47653
> + * graphite-ppl.h (tree_int_to_gmp): Sign extend before converting
> + constants to GMP values.  Add a sext parameter.
> + (ppl_set_inhomogeneous_tree): Add sext parameter.
> + (ppl_set_coef_tree): Removed.
> + * graphite-sese-to-poly.c (scan_tree_for_params_right_scev): Adjust
> + call to tree_int_to_gmp.
> + (scan_tree_for_params_int): Use tree_int_to_gmp.
> + (scan_tree_for_params): Adjust call to tree_int_to_gmp.
> + (build_loop_iteration_domains): Adjust call to
> + ppl_set_inhomogeneous_tree.
> + (add_param_constraints): Same.
> + (pdr_add_data_dimensions): Same.
> +
>  2011-06-29  Eric Botcazou  
>  
>   PR tree-optimization/49539
> diff --git a/gcc/graphite-ppl.h b/gcc/graphite-ppl.h
> index 695d01f..4ae9f63 100644
> --- a/gcc/graphite-ppl.h
> +++ b/gcc/graphite-ppl.h
> @@ -50,13 +50,18 @@ void debug_gmp_value (mpz_t);
>  bool ppl_powerset_is_empty (ppl_Pointset_Powerset_C_Polyhedron_t);
>  
>  
> -/* Assigns to RES the value of the INTEGER_CST T.  */
> +/* Assigns to RES the value of the INTEGER_CST T.  When SEXT is true,
> +   sign extend the value of T to not get "-1 = 2^n - 1".  */
>  
>  static inline void
> -tree_int_to_gmp (tree t, mpz_t res)
> +tree_int_to_gmp (tree t, mpz_t res, bool sext)
>  {
> +  tree type = TREE_TYPE (t);
>double_int di = tree_to_double_int (t);
> -  mpz_set_double_int (res, di, TYPE_UNSIGNED (TREE_TYPE (t)));
> +
> +  if (sext)
> +di = double_int_sext (di, TYPE_PRECISION (type));
> +  mpz_set_double_int (res, di, false);

That looks odd.  So you given -1U as input you sign-extend that to -1
and then set the mpz to -1ULLL.  In fact it looks like you either
have non-canoncial INTEGER_CSTs from the start or the type of the
integer constants is wrong.

So no, this patch looks completely bogus to me.

Richard.

Re: [Design notes, RFC] Address-lowering prototype design (PR46556)

[Richard Guenther]

On Wed, Jun 29, 2011 at 8:18 PM, William J. Schmidt
 wrote:
> On Tue, 2011-06-14 at 15:39 +0200, Richard Guenther wrote:
>> On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt
>>  wrote:
>> > On Tue, 2011-06-07 at 16:49 +0200, Richard Guenther wrote:
>> >> On Tue, Jun 7, 2011 at 4:14 PM, William J. Schmidt
>> >>  wrote:
>> >
>> > 
>> >
>> >> >> > Loss of aliasing information
>> >> >> > 
>> >> >> > The most serious problem I've run into is degraded performance due 
>> >> >> > to poorer
>> >> >> > instruction scheduling choices. I tracked this down to
>> >> >> > alias.c:nonoverlapping_component_refs_p.
>> >> >> >
>> >> >> > This code proves that two memory accesses don't overlap by 
>> >> >> > attempting to prove
>> >> >> > that they access different fields of the same structure. This is 
>> >> >> > done using
>> >> >> > the MEM_EXPRs of the two rtx's, which record the expression trees 
>> >> >> > that were
>> >> >> > translated into the rtx's during expand. When address lowering is not
>> >> >> > present, a simple COMPONENT_REF will appear in the MEM_EXPR: x.a, for
>> >> >> > example. However, address lowering changes the simple COMPONENT_REF 
>> >> >> > into a
>> >> >> > [TARGET_]MEM_REF that is no longer necessarily identifiable as a 
>> >> >> > field
>> >> >> > reference. Thus the aliasing machinery can no longer prove that two 
>> >> >> > such
>> >> >> > field references are disjoint.
>> >> >> >
>> >> >> > This has severe consequences for performance, and has to be dealt 
>> >> >> > with if
>> >> >> > address lowering is to be successful.
>> >> >> >
>> >> >> > I've worked around this with an admittedly fragile solution; I'll 
>> >> >> > discuss the
>> >> >> > drawbacks below. The idea is to construct a mapping from replacement 
>> >> >> > mem_refs
>> >> >> > to the original expressions that they replaced. When a MEM_EXPR is 
>> >> >> > being set
>> >> >> > during expand, we first look up the mem_ref in the mapping. If 
>> >> >> > present, the
>> >> >> > MEM_EXPR is set to the original expression, rather than to the 
>> >> >> > mem_ref. This
>> >> >> > essentially duplicates the behavior in the absence of address 
>> >> >> > lowering.
>> >> >>
>> >> >> Ick. We had this in the past via TMR_ORIGINAL which caused all sorts
>> >> >> of problems. Removing it didn't cause much degradation because we now
>> >> >> preserve points-to information.
>> >> >>
>> >> >> Originally I played with lowering all memory accesses to MEM_REFs
>> >> >> (see the old mem-ref branch), and the loss of type-based alias
>> >> >> disambiguation was indeed an issue.
>> >> >>
>> >> >> But - I definitely do not like the idea of preserving something similar
>> >> >> to TMR_ORIGINAL. Instead we can try preserving some information
>> >> >> we derive from it. We keep the original access type that we can use
>> >> >> for TBAA but do not retain knowledge on whether the type of the
>> >> >> MEM_REF is valid for TBAA or if it is view-converted.
>> >> >
>> >> > Yes, I really don't like what I have at the moment, either. I put it in
>> >> > place as a stopgap to let me proceed to look for other performance
>> >> > problems.
>> >> >
>> >> > The question is how we can infer useful information for TBAA from the
>> >> > MEM_REFs and TMRs. I poked at trying to identify types and offsets from
>> >> > the MEM_EXPRs, but this ended up being useless; I had to constrain too
>> >> > many cases to maintain correctness, and couldn't prove the type
>> >> > information for the important cases in SPEC I was trying to address.
>> >> >
>> >> > Unfortunately, the whole design goes down the drain if we can't find a
>> >> > way to solve the TBAA issue. The performance degradations are too
>> >> > costly.
>> >>
>> >> If you look at what basic TBAA the alias oracle performs then it boils
>> >> down to the fact that get_alias_set for a.b.c might end up using the
>> >> alias-set of the type of C but for MEM[&a + 4] it will use the alias set
>> >> of the type of a. The tree alias-oracle extracts both alias sets, that
>> >> of the outermost valid type and that of the innermost as both are
>> >> equally useful. But the MEM_REF (or TARGET_MEM_REF) tree
>> >> only have storage for one such alias-set. Thus my idea at some point
>> >> was to store the other one as well in some form. It will not be
>> >> the full information (after all, the complete access path does provide
>> >> some extra information - see aliasing_component_refs_p).
>> >
>> > This is what concerns me. TBAA information for the outer and inner
>> > components doesn't seem sufficient to provide what
>> > nonoverlapping_component_refs_p is currently able to prove. The latter
>> > searches for a common RECORD_TYPE somewhere along the two access paths,
>> > and then disambiguates if the two associated referenced fields differ.
>> > For a simple case like "struct x { int a; int b; };", a and b have the
>> > same type and alias-set, so the alias-set information doesn't add
>> > anything. It

Re: [PATCH] Reintroduce repeat field for ctors (PR fortran/49540)

[Tobias Burnus]

On 06/29/2011 11:35 PM, Jakub Jelinek wrote:

Bootstrapped/regtested on x86_64-linux and i686-linux.  Ok for trunk
and after a while for 4.6 too?


OK - thanks for the quick patch!


@@ -4608,29 +4608,56 @@ gfc_conv_array_initializer (tree type, g
  index = gfc_conv_mpz_to_tree (c->offset, gfc_index_integer_kind);
else
  index = NULL_TREE;
+ if (mpz_cmp_si (c->repeat, 1)>  0)


Minute nit: The indenting of the 4 lines _before_ your added line are 
wrong (space vs. tab), additionally, I find it more readable with an 
empty line before "if".


Tobias

PS: Unrelated to the patch - and  thus not preventing its committal, nor 
do you need to fix them all: The following issues were found when 
looking at the patch and the PR.


- ME: The patch uses RANGE_EXPR, which shows up in the dump as "static 
integer(kind=4) a[40] = {0};" to avoid confusion with "DATA A(1)/0/", it 
should use, e.g., "= {[0...39] = 0}".


- ME: "= { }" (e.g. "integer, save :: A(3) = 0") and RANGE_EXPR "= {0}" 
(e.g. "integer :: A(3); data a/3*0/" - using this patch): The two forms 
are identically and thus could be normalized. (Don't know whether it 
makes a difference to the ME itself, it probably doesn't.)


- FE: For assignments of a scalar to a (static) array, one should use 
RANGE_EXPR. Advantage: It cleans up the tree dump and reduces the memory 
consumption. Currently, only 0 initialization is handled (which is 
arguably most important as .bss and memset exist).


- FE: Several compilers - including gfortran - accept double 
initialization. Expected:
* A warning is always printed (as some other compilers do) - or at least 
with -Wall. Currently, only -std=f2008 produces an error and -pedantic a 
warning
* The order of double initialization should be changed to match gfortran 
4.1, other compilers, and the naive expectation. (The order of 4.6-4.7 
differs from both 4.1 and from 4.3-4.5.) Cf. PR fortran/49586


- FE: DATA initialization to an array vector section does not work (ICE: 
Not yet implemented). Cf. PR fortran/49588

[Patch, AVR, 4.6+trunk]: PR44643 addendum

[Georg-Johann Lay]

avr_insert_attributes uses TREE_READONLY on get readonlyness of node.

That does not work for C++ arrays: it gives false error
"variable must be const in order to be put into read-only section by
means of '__attribute__((progmem))'".

This patch peels arrays and uses TYPE_READONLY.

I did not open separate PR for this, tagged it as addendum to PR44643
instead.

Lightly tested on own code. There is no 'progmem' in testsuite, so
from testsuite's perspective that code is dead, anyway...

Johann

PR target/44643
* config/avr/avr.c (avr_insert_attributes): Use TYPE_READONLY
instead of TREE_READONLY.
Index: config/avr/avr.c
===
--- config/avr/avr.c	(revision 175629)
+++ config/avr/avr.c	(working copy)
@@ -5030,7 +5030,19 @@ avr_insert_attributes (tree node, tree *
   && (TREE_STATIC (node) || DECL_EXTERNAL (node))
   && avr_progmem_p (node, *attributes))
 {
-  if (TREE_READONLY (node)) 
+  tree node0 = node;
+
+  /* For C++, we have to peel arrays in order to get correct
+ determination of readonlyness.  */
+  
+  do
+node0 = TREE_TYPE (node0);
+  while (TREE_CODE (node0) == ARRAY_TYPE);
+
+  if (error_mark_node == node0)
+return;
+  
+  if (TYPE_READONLY (node0))
 {
   static const char dsec[] = ".progmem.data";