[C++ Patch] PR 54485

[Paolo Carlini]

Hi,

this bug, filed by Diego, is about 8.3.6/6, where member functions of 
class templates, at variance with plain classes, do not admit default 
arguments on the out-of-class redeclaration.


Tested x86_64-linux.

Thanks,
Paolo.

//
/cp
2013-08-25  Paolo Carlini  

PR c++/54485
* decl.c (duplicate_decls): Enforce 8.3.6/6 about default arguments
for member functions of class templates.

/testsuite
2013-08-25  Paolo Carlini  

PR c++/54485
* g++.dg/other/default8.C: New.
* g++.dg/tc1/dr217.C: Remove xfail.
* g++.dg/other/default5.C: Adjust.
* g++.old-deja/g++.mike/p1989.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 201977)
+++ cp/decl.c   (working copy)
@@ -1686,25 +1686,47 @@ duplicate_decls (tree newdecl, tree olddecl, bool
  if (TREE_CODE (TREE_TYPE (newdecl)) == METHOD_TYPE)
t1 = TREE_CHAIN (t1), t2 = TREE_CHAIN (t2);
 
- for (; t1 && t1 != void_list_node;
-  t1 = TREE_CHAIN (t1), t2 = TREE_CHAIN (t2), i++)
-   if (TREE_PURPOSE (t1) && TREE_PURPOSE (t2))
- {
-   if (1 == simple_cst_equal (TREE_PURPOSE (t1),
-  TREE_PURPOSE (t2)))
+ if (TREE_CODE (TREE_TYPE (newdecl)) == METHOD_TYPE
+ && CLASSTYPE_TEMPLATE_INFO (CP_DECL_CONTEXT (newdecl)))
+   {
+ /* C++11 8.3.6/6.
+Default arguments for a member function of a class template
+shall be specified on the initial declaration of the member
+function within the class template.  */
+ for (; t2 && t2 != void_list_node; t2 = TREE_CHAIN (t2))
+   if (TREE_PURPOSE (t2))
  {
-   permerror (input_location, "default argument given for 
parameter %d of %q#D",
-  i, newdecl);
-   permerror (input_location, "after previous specification in 
%q+#D", olddecl);
+   permerror (input_location,
+  "redeclaration of %q#D may not have default "
+  "arguments", newdecl);
+   break;
  }
-   else
+   }
+ else
+   {
+ for (; t1 && t1 != void_list_node;
+  t1 = TREE_CHAIN (t1), t2 = TREE_CHAIN (t2), i++)
+   if (TREE_PURPOSE (t1) && TREE_PURPOSE (t2))
  {
-   error ("default argument given for parameter %d of %q#D",
-  i, newdecl);
-   error ("after previous specification in %q+#D",
-olddecl);
+   if (1 == simple_cst_equal (TREE_PURPOSE (t1),
+  TREE_PURPOSE (t2)))
+ {
+   permerror (input_location,
+  "default argument given for parameter %d "
+  "of %q#D", i, newdecl);
+   permerror (input_location,
+  "after previous specification in %q+#D",
+  olddecl);
+ }
+   else
+ {
+   error ("default argument given for parameter %d "
+  "of %q#D", i, newdecl);
+   error ("after previous specification in %q+#D",
+  olddecl);
+ }
  }
- }
+   }
}
 }
 
Index: testsuite/g++.dg/other/default5.C
===
--- testsuite/g++.dg/other/default5.C   (revision 201977)
+++ testsuite/g++.dg/other/default5.C   (working copy)
@@ -43,5 +43,5 @@ template struct B
   void F2(int, int, int = 0);
 };
 
-template void B::F1(int, int = 0, int) {}
-template void B::F2(int = 0, int, int) {}  // { dg-error "default" }
+template void B::F1(int, int = 0, int) {}  // { dg-error "default 
arguments" }
+template void B::F2(int = 0, int, int) {}  // { dg-error "default 
arguments|parameter 2" }
Index: testsuite/g++.dg/other/default8.C
===
--- testsuite/g++.dg/other/default8.C   (revision 0)
+++ testsuite/g++.dg/other/default8.C   (working copy)
@@ -0,0 +1,43 @@
+// PR c++54485
+
+template
+class K1
+{
+  int fn(int, int);
+  int gn(int, int);
+};
+
+template
+int K1::fn (int a, int b = 3)  // { dg-error "default arguments" }
+{
+  return a - b;
+}
+
+template
+int K1::gn (int a = 1, int b = 3)  // { dg-error "default arguments" }
+{
+  return a - b;
+}
+
+template
+class K2
+{
+  template
+  int fn(int, int);
+  template
+  int gn(int, int);
+};
+
+template
+template
+int K2::fn (int a, int b = 3)  // {

Re: wide-int branch now up for public comment and review

[Kenneth Zadeck]

On 08/25/2013 02:42 AM, Richard Sandiford wrote:

Kenneth Zadeck  writes:

On 08/24/2013 08:05 AM, Richard Sandiford wrote:

Richard Sandiford  writes:

I wonder how easy it would be to restrict this use of "zero precision"
(i.e. flexible precision) to those where primitive types like "int" are
used as template arguments to operators, and require a precision when
constructing a wide_int.  I wouldn't have expected "real" precision 0
(from zero-width bitfields or whatever) to need any special handling
compared to precision 1 or 2.

I tried the last bit -- requiring a precision when constructing a
wide_int -- and it seemed surprising easy.  What do you think of
the attached?  Most of the forced knock-on changes seem like improvements,
but the java part is a bit ugly.  I also went with "wide_int (0, prec).cmp"
for now, although I'd like to add static cmp, cmps and cmpu alongside
leu_p, etc., if that's OK.  It would then be possible to write
"wide_int::cmp (0, ...)" and avoid the wide_int construction altogether.

I wondered whether you might also want to get rid of the build_int_cst*
functions, but that still looks a long way off, so I hope using them in
these two places doesn't seem too bad.

This is just an incremental step.  I've also only run it through a
subset of the testsuite so far, but full tests are in progress...

So i am going to make two high level comments here and then i am going
to leave the ultimate decision to the community.   (1) I am mildly in
favor of leaving prec 0 stuff the way that it is (2) my guess is that
richi also will favor this.   My justification for (2) is because he had
a lot of comments about this before he went on leave and this is
substantially the way that it was when he left. Also, remember that one
of his biggest dislikes was having to specify precisions.

Hmm, but you seem to be talking about zero precision in general.
(I'm going to call it "flexible precision" to avoid confusion with
the zero-width bitfield stuff.)
I have tried to purge the zero width bitfield case from my mind. it was 
an ugly incident in the conversion.




Whereas this patch is specifically
about constructing flexible-precision _wide_int_ objects.  I think
wide_int objects should always have a known, fixed precision.
This is where we differ.  I do not.   The top level idea is really 
motivated by richi, but i have come to appreciate his criticism. Many of 
the times, the specification of the precision is simply redundant and it 
glops up the code.



Note that fixed_wide_ints can still use primitive types in the
same way as before, since there the precision is inherent to the
fixed_wide_int.  The templated operators also work in the same
way as before.  Only the construction of wide_int proper is affected.

As it stands you have various wide_int operators that cannot handle two
flexible-precision inputs.  This means that innocent-looking code like:

   extern wide_int foo (wide_int);
   wide_int bar () { return foo (0); }

ICEs when combined with equally innocent-looking code like:

   wide_int foo (wide_int x) { return x + 1; }

So in practice you have to know when calling a function whether any
paths in that function will try applying an operator with a primitive type.
If so, you need to specify a precison when constructing the wide_int
argument.  If not you can leave it out.  That seems really unclean.
my wife, who is a lawyer, likes to quote an old Brittish chancellor: 
"hard cases make bad law".
The fact that you occasionally  have to specify one should not be 
justification for throwing out the entire thing.




The point of this template stuff is to avoid constructing wide_int objects
from primitive integers whereever possible.  And I think the fairly
small size of the patch shows that you've succeeded in doing that.
But I think we really should specify a precision in the handful of cases
where a wide_int does still need to be constructed directly from
a primitive type.

Thanks,
Richard

As i said earlier.Lets see what others in the community feel about this.

Re: Clean up pretty printers [15/n]

[Joseph S. Myers]

On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:

> Instead of defining the same macro several times in different
> translation units, we can just make it a function and use it where
> needed.

Have you made sure that po/exgettext still extracts the relevant messages 
for translation (I'm not sure how good it is at identifying C++ functions 
with arguments called gmsgid, or how good xgettext then is at identifying 
relevant C++ function calls)?  In particular, even if other cases get 
identified properly, conditional expressions such as

> @@ -379,15 +375,15 @@
> switch (code)
>   {
>   case INTEGER_TYPE:
> -   pp_string (pp, (TYPE_UNSIGNED (t)
> -   ? M_(" -   : M_(" +   pp->translate_string (TYPE_UNSIGNED (t)
> +? " +: "

Handle final types & methods in ipa-devirt

[Jan Hubicka]

Hi,
this patch adds ipa-devirt code for final types and methods.  There is
probably no way to construct a testcase that will be devirtualized,
since all the simple minded devirtualization is already done by FE.
I however checked that dumps seems sane at least.  Once we are able
to track types of THIS pointers, this will become interesting.

Bootstrapped/regtested x86_64-linux, will commit it shortly.

Honza

* ipa-devirt.c (struct odr_type_d): Add final_type field.
(dump_odr_type): Add dumping.
(possible_polymorphic_call_targets): Support final types
and final methods.
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 201974)
+++ ipa-devirt.c(working copy)
@@ -137,6 +137,8 @@ struct GTY(()) odr_type_d
   int id;
   /* Is it in anonymous namespace? */
   bool anonymous_namespace;
+  /* Is it final type?  */
+  bool final_type;
 };
 
 
@@ -270,6 +272,7 @@ get_odr_type (tree type, bool insert)
   val->bases = vNULL;
   val->derived_types = vNULL;
   val->anonymous_namespace = type_in_anonymous_namespace_p (type);
+  val->final_type = TYPE_FINAL_P (type);
   *slot = val;
   for (i = 0; i < BINFO_N_BASE_BINFOS (binfo); i++)
/* For now record only polymorphic types. other are
@@ -300,7 +303,8 @@ dump_odr_type (FILE *f, odr_type t, int
   unsigned int i;
   fprintf (f, "%*s type %i: ", indent * 2, "", t->id);
   print_generic_expr (f, t->type, TDF_SLIM);
-  fprintf (f, "%s\n", t->anonymous_namespace ? " (anonymous namespace)":"");
+  fprintf (f, "%s%s\n", t->anonymous_namespace ? " (anonymous namespace)":"",
+  t->final_type ? " (final)":"");
   if (TYPE_NAME (t->type))
 {
   fprintf (f, "%*s defined at: %s:%i\n", indent * 2, "",
@@ -598,7 +602,7 @@ possible_polymorphic_call_targets (tree
 
   /* For anonymous namespace types we can attempt to build full type.
  All derivations must be in this unit.  */
-  if (type->anonymous_namespace && finalp && !flag_ltrans)
+  if ((type->anonymous_namespace || type->final_type) && finalp && 
!flag_ltrans)
 *finalp = true;
 
   /* Initialize query cache.  */
@@ -637,19 +641,24 @@ possible_polymorphic_call_targets (tree
   target = gimple_get_virt_method_for_binfo (otr_token, binfo);
   if (target)
 maybe_record_node (nodes, target, inserted);
-  pointer_set_insert (matched_vtables, BINFO_VTABLE (binfo));
 
-  /* TODO: If method is final, we can stop here and signaize that
- list is final.  We need C++ FE to pass our info about final
- methods and classes.  */
+  /* If we failed to find the method, we no longer have final list
+ This can happen i.e. when we can not refer to decl from other unit.  */
+  if (!nodes.length())
+*finalp = false;
+  pointer_set_insert (matched_vtables, BINFO_VTABLE (binfo));
 
-  /* Walk recursively all derived types.  Here we need to lookup proper 
basetype
- via their BINFO walk that is done by record_binfo  */
-  for (i = 0; i < type->derived_types.length(); i++)
-possible_polymorphic_call_targets_1 (nodes, inserted,
-matched_vtables,
-otr_type, type->derived_types[i],
-otr_token);
+  /* If method is not final, walk recursively all derived types.
+ Here we need to lookup proper basetype via their BINFO walk that is done
+ by record_binfo  */
+  if (!nodes.length () || !DECL_FINAL_P (nodes[0]->symbol.decl))
+for (i = 0; i < type->derived_types.length(); i++)
+  possible_polymorphic_call_targets_1 (nodes, inserted,
+  matched_vtables,
+  otr_type, type->derived_types[i],
+  otr_token);
+  else if (finalp)
+*finalp = true;
   (*slot)->targets = nodes;
 
   pointer_set_destroy (inserted);

Stream TYPE_FINAL_P and DECL_FINAL_P to LTO

[Jan Hubicka]

Hi,
this patch adds code to stream DECL_FINAL_P/TYPE_FINAL_P into LTO so we can
use it after the ipa-devirt code at LTO time is merged in.
(http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01007.html)

Bootstrapped/regtested x86_64-linux, OK?

Honza

* lto-streamer-out.c (hash_tree): Add streaming of DECL_FINAL_P
and TYPE_FINAL_P
* lto/lto.c (compare_tree_sccs_1): Add TYPE_FINAL_P and DECL_FINAL_P
* tree-streamer-out.c (pack_ts_decl_with_vis_value_fields):
Add DECL_FINAL_P.
(pack_ts_type_common_value_fields): Add TYPE_FINAL_P.
* tree-streamer-in.c (unpack_ts_decl_with_vis_value_fields):
Add DECL_FINAL_P.
(unpack_ts_type_common_value_fields): Add TYPE_FINAL_P.

Index: lto-streamer-out.c
===
--- lto-streamer-out.c  (revision 201974)
+++ lto-streamer-out.c  (working copy)
@@ -798,6 +798,9 @@ hash_tree (struct streamer_tree_cache_d
v);
  v = iterative_hash_host_wide_int (DECL_TLS_MODEL (t), v);
}
+  if (TREE_CODE (t) == FUNCTION_DECL)
+   v = iterative_hash_host_wide_int (DECL_FINAL_P (t),
+ v);
   if (VAR_OR_FUNCTION_DECL_P (t))
v = iterative_hash_host_wide_int (DECL_INIT_PRIORITY (t), v);
 }
@@ -838,7 +841,10 @@ hash_tree (struct streamer_tree_cache_d
| (TYPE_USER_ALIGN (t) << 5)
| (TYPE_READONLY (t) << 6), v);
   if (RECORD_OR_UNION_TYPE_P (t))
-   v = iterative_hash_host_wide_int (TYPE_TRANSPARENT_AGGR (t), v);
+   {
+ v = iterative_hash_host_wide_int (TYPE_TRANSPARENT_AGGR (t), v);
+ v = iterative_hash_host_wide_int (TYPE_FINAL_P (t), v);
+   }
   else if (code == ARRAY_TYPE)
v = iterative_hash_host_wide_int (TYPE_NONALIASED_COMPONENT (t), v);
   v = iterative_hash_host_wide_int (TYPE_PRECISION (t), v);
Index: lto/lto.c
===
--- lto/lto.c   (revision 201974)
+++ lto/lto.c   (working copy)
@@ -1892,6 +1892,7 @@ compare_tree_sccs_1 (tree t1, tree t2, t
   compare_values (DECL_DISREGARD_INLINE_LIMITS);
   compare_values (DECL_PURE_P);
   compare_values (DECL_LOOPING_CONST_OR_PURE_P);
+  compare_values (DECL_FINAL_P);
   if (DECL_BUILT_IN_CLASS (t1) != NOT_BUILT_IN)
compare_values (DECL_FUNCTION_CODE);
   if (DECL_STATIC_DESTRUCTOR (t1))
@@ -1905,7 +1906,10 @@ compare_tree_sccs_1 (tree t1, tree t2, t
   compare_values (TYPE_NO_FORCE_BLK);
   compare_values (TYPE_NEEDS_CONSTRUCTING);
   if (RECORD_OR_UNION_TYPE_P (t1))
-   compare_values (TYPE_TRANSPARENT_AGGR);
+   {
+ compare_values (TYPE_TRANSPARENT_AGGR);
+ compare_values (TYPE_FINAL_P);
+   }
   else if (code == ARRAY_TYPE)
compare_values (TYPE_NONALIASED_COMPONENT);
   compare_values (TYPE_PACKED);
Index: tree-streamer-out.c
===
--- tree-streamer-out.c (revision 201974)
+++ tree-streamer-out.c (working copy)
@@ -242,6 +242,8 @@ pack_ts_decl_with_vis_value_fields (stru
   bp_pack_value (bp, DECL_TLS_MODEL (expr),  3);
 }
 
+  if (TREE_CODE (expr) == FUNCTION_DECL)
+bp_pack_value (bp, DECL_FINAL_P (expr), 1);
   if (VAR_OR_FUNCTION_DECL_P (expr))
 bp_pack_var_len_unsigned (bp, DECL_INIT_PRIORITY (expr));
 }
@@ -293,7 +295,10 @@ pack_ts_type_common_value_fields (struct
   bp_pack_value (bp, TYPE_NO_FORCE_BLK (expr), 1);
   bp_pack_value (bp, TYPE_NEEDS_CONSTRUCTING (expr), 1);
   if (RECORD_OR_UNION_TYPE_P (expr))
-bp_pack_value (bp, TYPE_TRANSPARENT_AGGR (expr), 1);
+{
+  bp_pack_value (bp, TYPE_TRANSPARENT_AGGR (expr), 1);
+  bp_pack_value (bp, TYPE_FINAL_P (expr), 1);
+}
   else if (TREE_CODE (expr) == ARRAY_TYPE)
 bp_pack_value (bp, TYPE_NONALIASED_COMPONENT (expr), 1);
   bp_pack_value (bp, TYPE_PACKED (expr), 1);
Index: tree-streamer-in.c
===
--- tree-streamer-in.c  (revision 201974)
+++ tree-streamer-in.c  (working copy)
@@ -275,6 +275,8 @@ unpack_ts_decl_with_vis_value_fields (st
   DECL_TLS_MODEL (expr) = (enum tls_model) bp_unpack_value (bp,  3);
 }
 
+  if (TREE_CODE (expr) == FUNCTION_DECL)
+DECL_FINAL_P (expr) = (unsigned) bp_unpack_value (bp, 1);
   if (VAR_OR_FUNCTION_DECL_P (expr))
 {
   priority_type p;
@@ -346,7 +348,10 @@ unpack_ts_type_common_value_fields (stru
   TYPE_NO_FORCE_BLK (expr) = (unsigned) bp_unpack_value (bp, 1);
   TYPE_NEEDS_CONSTRUCTING (expr) = (unsigned) bp_unpack_value (bp, 1);
   if (RECORD_OR_UNION_TYPE_P (expr))
-TYPE_TRANSPARENT_AGGR (expr) = (unsigned) bp_unpack_value (bp, 1);
+{
+  TYPE_TRANSPARENT_AGGR (expr) = (unsigned) bp_unpack_value (bp, 1);
+  TYPE_FINAL_P (expr) = (unsigned) bp_un

[PING^2] [PATCH 0/6] Contributing new target port: Andes 'nds32'.

[Chung-Ju Wu]

Hi, GCC global reviewers,

The nds32 port initial patch is still awaiting for
any global reviewer's approval.

Since there is no further comment in these days,
is it OK for trunk?

Thanks in advance. :)


Best regards,
jasonwucj


2013/8/13 Chung-Ju Wu :
> Hi, GCC Global Maintainers,
>
> The Andes nds32 port has been accepted by GCC SC [1]
> and the initial patch is posted on [2] but still needs
> global maintainer's approval.
>
[...]
>
> [1] http://gcc.gnu.org/ml/gcc/2013-07/msg00232.html
> [2] http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01144.html
>

Re: Clean up pretty printers [15/n]

[Gabriel Dos Reis]

"Joseph S. Myers"  writes:

| On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
| 
| > Instead of defining the same macro several times in different
| > translation units, we can just make it a function and use it where
| > needed.
| 
| Have you made sure that po/exgettext still extracts the relevant messages 
| for translation (I'm not sure how good it is at identifying C++ functions 
| with arguments called gmsgid, or how good xgettext then is at identifying 
| relevant C++ function calls)?  In particular, even if other cases get 
| identified properly, conditional expressions such as

I trusted xgettext documentation that says that it handles C++ input
source files. 

Looking at the documentation, I notice this:

   By  default  the  language  is guessed depending on the input
   file name extension.

I don't know whether after the switch C++ xgettext is being invoked
explicitly with -C or --c++, or whether we are still relying on xgettext
to pick the language based on the file extension.  This is probably
another reason why we might want to rename files to use apppropriate
extensions.  In the meantime, we might want to explicitly specify the
language for the input source file.

po/exgettext only looks whether the parameter name ends with 'msgid'.

| 
| > @@ -379,15 +375,15 @@
| >   switch (code)
| > {
| > case INTEGER_TYPE:
| > - pp_string (pp, (TYPE_UNSIGNED (t)
| > - ? M_(" - : M_(" + pp->translate_string (TYPE_UNSIGNED (t)
| > +? " +: "

Re: [C++ patch] Move FINAL flag to middle-end trees.

[Jan Hubicka]

> On 08/24/2013 05:18 AM, Jan Hubicka wrote:
> >In the next step I would like to introduce the 
> >DECL_CPP_CONSTRUCTOR/DESTRUCTOR macro.
> >The catch I run into is that these flags are tested on TEMPLATE_DECL so the 
> >middle-end
> >macro bombs on type checking.  I wonder what is best approach here.
> 
> I think fix the front end to use STRIP_TEMPLATE to make sure we're
> checking/setting the flag on a FUNCTION_DECL.

Thank you!
I did not know the FUNCTION_DECLs are already there.  The following patch seems
to work.  Of course if it seems cleaner, I can update the users of the CPP
macros into the expanded variants.  I want to have CPP in name in middle-end to
signify that we actually understand language specific properties of these
functions (so constructors/destructors in other languages probably don't
want to do that).

Bootstrapped/regtested ppc64-linux, OK?

* tree.h (tree_decl_with_vis): Add cpp_constructor and cpp_destructor.
(DECL_CPP_CONSTRUCTOR_P, DECL_CPP_DESTRUCTOR_P): New macros.

* cp-tree.h (DECL_CONSTRUCTOR_P, DECL_DESTRUCTOR_P): Change to
strip templates and set the middle-end flag.
Index: tree.h
===
--- tree.h  (revision 201977)
+++ tree.h  (working copy)
@@ -3232,8 +3232,12 @@ struct GTY(()) tree_decl_with_vis {
  /* Used by C++ only.  Might become a generic decl flag.  */
  unsigned shadowed_for_var_p : 1;
  /* Belong to FUNCTION_DECL exclusively.  */
+ unsigned cpp_constructor : 1;
+ /* Belong to FUNCTION_DECL exclusively.  */
+ unsigned cpp_destructor : 1;
+ /* Belong to FUNCTION_DECL exclusively.  */
  unsigned final : 1;
- /* 13 unused bits. */
+ /* 11 unused bits. */
 };
 
 extern tree decl_debug_expr_lookup (tree);
@@ -3483,6 +3487,18 @@ extern vec **decl_debug_arg
 #define DECL_FUNCTION_VERSIONED(NODE)\
(FUNCTION_DECL_CHECK (NODE)->function_decl.versioned_function)
 
+/* In FUNCTION_DECL, this is set if this function is a C++ constructor.
+   Devirtualization machinery uses this knowledge for determing type of the
+   object constructed.  Also we assume that constructor address is not
+   important.  */
+#define DECL_CPP_CONSTRUCTOR_P(NODE)\
+   (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.cpp_constructor)
+
+/* In FUNCTION_DECL, this is set if this function is a C++ destructor.
+   Devirtualization machinery uses this to track types in destruction.  */
+#define DECL_CPP_DESTRUCTOR_P(NODE)\
+   (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.cpp_destructor)
+
 /* In FUNCTION_DECL that represent an virtual method this is set when
the method is final.  */
 #define DECL_FINAL_P(NODE)\
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 201977)
+++ cp/cp-tree.h(working copy)
@@ -2121,9 +2121,10 @@ struct GTY((variable_size)) lang_decl {
 #define SET_DECL_LANGUAGE(NODE, LANGUAGE) \
   (DECL_LANG_SPECIFIC (NODE)->u.base.language = (LANGUAGE))
 
-/* For FUNCTION_DECLs: nonzero means that this function is a constructor.  */
+/* For FUNCTION_DECLs and TEMPLATE_DECLs: nonzero means that this function
+   is a constructor.  */
 #define DECL_CONSTRUCTOR_P(NODE) \
-  (LANG_DECL_FN_CHECK (NODE)->constructor_attr)
+  DECL_CPP_CONSTRUCTOR_P (STRIP_TEMPLATE (NODE))
 
 /* Nonzero if NODE (a FUNCTION_DECL) is a constructor for a complete
object.  */
@@ -2152,9 +2153,10 @@ struct GTY((variable_size)) lang_decl {
 #define DECL_MOVE_CONSTRUCTOR_P(NODE) \
   (DECL_CONSTRUCTOR_P (NODE) && move_fn_p (NODE))
 
-/* Nonzero if NODE is a destructor.  */
+/* Nonzero if NODE (a FUNCTION_DECL or TEMPLATE_DECL)
+   is a destructor.  */
 #define DECL_DESTRUCTOR_P(NODE)\
-  (LANG_DECL_FN_CHECK (NODE)->destructor_attr)
+  DECL_CPP_DESTRUCTOR_P (STRIP_TEMPLATE (NODE))
 
 /* Nonzero if NODE (a FUNCTION_DECL) is a destructor, but not the
specialized in-charge constructor, in-charge deleting constructor,

Re: [C++ patch] Move FINAL flag to middle-end trees.

[Gabriel Dos Reis]

On Sun, Aug 25, 2013 at 10:38 AM, Jan Hubicka  wrote:
>> On 08/24/2013 05:18 AM, Jan Hubicka wrote:
>> >In the next step I would like to introduce the 
>> >DECL_CPP_CONSTRUCTOR/DESTRUCTOR macro.
>> >The catch I run into is that these flags are tested on TEMPLATE_DECL so the 
>> >middle-end
>> >macro bombs on type checking.  I wonder what is best approach here.
>>
>> I think fix the front end to use STRIP_TEMPLATE to make sure we're
>> checking/setting the flag on a FUNCTION_DECL.
>
> Thank you!
> I did not know the FUNCTION_DECLs are already there.  The following patch 
> seems
> to work.  Of course if it seems cleaner, I can update the users of the CPP
> macros into the expanded variants.  I want to have CPP in name in middle-end 
> to
> signify that we actually understand language specific properties of these
> functions (so constructors/destructors in other languages probably don't
> want to do that).
>
> Bootstrapped/regtested ppc64-linux, OK?
>
> * tree.h (tree_decl_with_vis): Add cpp_constructor and cpp_destructor.
> (DECL_CPP_CONSTRUCTOR_P, DECL_CPP_DESTRUCTOR_P): New macros.
>
> * cp-tree.h (DECL_CONSTRUCTOR_P, DECL_DESTRUCTOR_P): Change to
> strip templates and set the middle-end flag.
> Index: tree.h
> ===
> --- tree.h  (revision 201977)
> +++ tree.h  (working copy)
> @@ -3232,8 +3232,12 @@ struct GTY(()) tree_decl_with_vis {
>   /* Used by C++ only.  Might become a generic decl flag.  */
>   unsigned shadowed_for_var_p : 1;
>   /* Belong to FUNCTION_DECL exclusively.  */
> + unsigned cpp_constructor : 1;
> + /* Belong to FUNCTION_DECL exclusively.  */
> + unsigned cpp_destructor : 1;
> + /* Belong to FUNCTION_DECL exclusively.  */

Naming suggestion:  we already use cpp_ as prefix for the C preprocessor.
Could we please not use it for C++, given that tree is used by so
many clients for just about anything.   cxx_ is a good alternative.

>   unsigned final : 1;
> - /* 13 unused bits. */
> + /* 11 unused bits. */
>  };
>
>  extern tree decl_debug_expr_lookup (tree);
> @@ -3483,6 +3487,18 @@ extern vec **decl_debug_arg
>  #define DECL_FUNCTION_VERSIONED(NODE)\
> (FUNCTION_DECL_CHECK (NODE)->function_decl.versioned_function)
>
> +/* In FUNCTION_DECL, this is set if this function is a C++ constructor.
> +   Devirtualization machinery uses this knowledge for determing type of the
> +   object constructed.  Also we assume that constructor address is not
> +   important.  */
> +#define DECL_CPP_CONSTRUCTOR_P(NODE)\

Same here.

> +   (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.cpp_constructor)
> +
> +/* In FUNCTION_DECL, this is set if this function is a C++ destructor.
> +   Devirtualization machinery uses this to track types in destruction.  */
> +#define DECL_CPP_DESTRUCTOR_P(NODE)\
> +   (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.cpp_destructor)
> +

Likewise.

>  /* In FUNCTION_DECL that represent an virtual method this is set when
> the method is final.  */
>  #define DECL_FINAL_P(NODE)\
> Index: cp/cp-tree.h
> ===
> --- cp/cp-tree.h(revision 201977)
> +++ cp/cp-tree.h(working copy)
> @@ -2121,9 +2121,10 @@ struct GTY((variable_size)) lang_decl {
>  #define SET_DECL_LANGUAGE(NODE, LANGUAGE) \
>(DECL_LANG_SPECIFIC (NODE)->u.base.language = (LANGUAGE))
>
> -/* For FUNCTION_DECLs: nonzero means that this function is a constructor.  */
> +/* For FUNCTION_DECLs and TEMPLATE_DECLs: nonzero means that this function
> +   is a constructor.  */
>  #define DECL_CONSTRUCTOR_P(NODE) \
> -  (LANG_DECL_FN_CHECK (NODE)->constructor_attr)
> +  DECL_CPP_CONSTRUCTOR_P (STRIP_TEMPLATE (NODE))
>
>  /* Nonzero if NODE (a FUNCTION_DECL) is a constructor for a complete
> object.  */
> @@ -2152,9 +2153,10 @@ struct GTY((variable_size)) lang_decl {
>  #define DECL_MOVE_CONSTRUCTOR_P(NODE) \
>(DECL_CONSTRUCTOR_P (NODE) && move_fn_p (NODE))
>
> -/* Nonzero if NODE is a destructor.  */
> +/* Nonzero if NODE (a FUNCTION_DECL or TEMPLATE_DECL)
> +   is a destructor.  */
>  #define DECL_DESTRUCTOR_P(NODE)\
> -  (LANG_DECL_FN_CHECK (NODE)->destructor_attr)
> +  DECL_CPP_DESTRUCTOR_P (STRIP_TEMPLATE (NODE))
>
>  /* Nonzero if NODE (a FUNCTION_DECL) is a destructor, but not the
> specialized in-charge constructor, in-charge deleting constructor,

Re: [C++ patch] Move FINAL flag to middle-end trees.

[Jan Hubicka]

> Naming suggestion:  we already use cpp_ as prefix for the C preprocessor.
> Could we please not use it for C++, given that tree is used by so
> many clients for just about anything.   cxx_ is a good alternative.

CXX is fine with me.  I updated by local copy.

Honza
> 
> >   unsigned final : 1;
> > - /* 13 unused bits. */
> > + /* 11 unused bits. */
> >  };
> >
> >  extern tree decl_debug_expr_lookup (tree);
> > @@ -3483,6 +3487,18 @@ extern vec **decl_debug_arg
> >  #define DECL_FUNCTION_VERSIONED(NODE)\
> > (FUNCTION_DECL_CHECK (NODE)->function_decl.versioned_function)
> >
> > +/* In FUNCTION_DECL, this is set if this function is a C++ constructor.
> > +   Devirtualization machinery uses this knowledge for determing type of the
> > +   object constructed.  Also we assume that constructor address is not
> > +   important.  */
> > +#define DECL_CPP_CONSTRUCTOR_P(NODE)\
> 
> Same here.
> 
> > +   (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.cpp_constructor)
> > +
> > +/* In FUNCTION_DECL, this is set if this function is a C++ destructor.
> > +   Devirtualization machinery uses this to track types in destruction.  */
> > +#define DECL_CPP_DESTRUCTOR_P(NODE)\
> > +   (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.cpp_destructor)
> > +
> 
> Likewise.
> 
> >  /* In FUNCTION_DECL that represent an virtual method this is set when
> > the method is final.  */
> >  #define DECL_FINAL_P(NODE)\
> > Index: cp/cp-tree.h
> > ===
> > --- cp/cp-tree.h(revision 201977)
> > +++ cp/cp-tree.h(working copy)
> > @@ -2121,9 +2121,10 @@ struct GTY((variable_size)) lang_decl {
> >  #define SET_DECL_LANGUAGE(NODE, LANGUAGE) \
> >(DECL_LANG_SPECIFIC (NODE)->u.base.language = (LANGUAGE))
> >
> > -/* For FUNCTION_DECLs: nonzero means that this function is a constructor.  
> > */
> > +/* For FUNCTION_DECLs and TEMPLATE_DECLs: nonzero means that this function
> > +   is a constructor.  */
> >  #define DECL_CONSTRUCTOR_P(NODE) \
> > -  (LANG_DECL_FN_CHECK (NODE)->constructor_attr)
> > +  DECL_CPP_CONSTRUCTOR_P (STRIP_TEMPLATE (NODE))
> >
> >  /* Nonzero if NODE (a FUNCTION_DECL) is a constructor for a complete
> > object.  */
> > @@ -2152,9 +2153,10 @@ struct GTY((variable_size)) lang_decl {
> >  #define DECL_MOVE_CONSTRUCTOR_P(NODE) \
> >(DECL_CONSTRUCTOR_P (NODE) && move_fn_p (NODE))
> >
> > -/* Nonzero if NODE is a destructor.  */
> > +/* Nonzero if NODE (a FUNCTION_DECL or TEMPLATE_DECL)
> > +   is a destructor.  */
> >  #define DECL_DESTRUCTOR_P(NODE)\
> > -  (LANG_DECL_FN_CHECK (NODE)->destructor_attr)
> > +  DECL_CPP_DESTRUCTOR_P (STRIP_TEMPLATE (NODE))
> >
> >  /* Nonzero if NODE (a FUNCTION_DECL) is a destructor, but not the
> > specialized in-charge constructor, in-charge deleting constructor,

Re: [patch, Fortran] PR 58146, enable array slice compile-time bounds checking

[Mikael Morin]

Le 22/08/2013 23:30, Mikael Morin a écrit :
> Le 14/08/2013 23:46, Thomas Koenig a écrit :
>> Hello world,
>>
>> the attached patch enables more sophisticated bounds-checking on
>> array slices by using gfc_dep_difference to calculate extents.
>> The information may also be useful in other places of the
>> front end, I don't really know.
>>
>> There is one wrinkle (alluded to in the comments) which makes
>> this harder.  When somebody changes the value of a variable
>> used in detemining the size of an array, such as
>>
>> subroutine foo(a,n)
>>   real, dimension(n) :: a
>>
>>   n = n -2
>>
>>   print *,ubound(a(n-1:))
>>
>> we cannot compare n-1 against n and think that their difference is
>> one :-(
>>
>> This is why I restricted myself to expressions where all
>> indices are specified, e.g. in a(n+1:n+4) or none are specified,
>> as in a(:).
>>
>> In order for this to work on 64-bit systems, it was necessary
>> to look through widening integer conversions, so I added that
>> functionality to discard_nops.  Using this function in
>> gfc_dep_compare_expr made this function shorter and cleaner.
>>
>> Regression-tested.  OK for trunk?

OK.
By the way, it seems that arg1 and arg2 declarations should be removed
in gfc_dep_compare_expr.

>>
> This looks mostly good.  The dependency.c cleanup is nice, I have yet to
> understand what the 'end == NULL' condition is for.  I come back to you
> soon.
> 
For what it's worth, 'end' is non-NULL in only one place and there the
gfc_ref_dimen_size result is discarded.  Thus its handling should better
be inlined or have its own function separate from gfc_ref_dimen_size.
It seems to be a lot of trouble for little gain though.

Mikael

Re: Clean up pretty printers [15/n]

[Joseph S. Myers]

On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:

> I don't know whether after the switch C++ xgettext is being invoked
> explicitly with -C or --c++, or whether we are still relying on xgettext
> to pick the language based on the file extension.  This is probably
> another reason why we might want to rename files to use apppropriate
> extensions.  In the meantime, we might want to explicitly specify the
> language for the input source file.
> 
> po/exgettext only looks whether the parameter name ends with 'msgid'.

And uses --language=c, --language=c++ and --language=GCC-source depending 
on the source files and functions in question.  The issue is both whether 
the awk code properly handles C++ function declarations to identify the 
parameter, and whether whatever way it passed the identified function name 
to xgettext (if it does identify the function) results in xgettext (with 
whatever language it uses) handling the call correctly.

> | > @@ -379,15 +375,15 @@
> | > switch (code)
> | >   {
> | >   case INTEGER_TYPE:
> | > -   pp_string (pp, (TYPE_UNSIGNED (t)
> | > -   ? M_(" | > -   : M_(" | > +   pp->translate_string (TYPE_UNSIGNED (t)
> | > +? " | > +: " | 
> | may need each case of the conditional expression to be marked for 
> | extraction for translation, or to be separated into two separate calls 
> | using "if" (we've had that issue before with conditional expressions in 
> | diagnostics).
> 
> Hmm, why would that be needed now, and not before?
> (not that I am found of the conditional, but only by curiosity.)

Previously, each string was inside a separate call to M_() - the strings 
themselves were the msgid parameters.  Now, the msgid parameter is not a 
single string but a more complicated expression and xgettext may not 
handle such expressions properly the way it handles having just a single 
string as parameter.

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

Re: wide-int branch now up for public comment and review

[Mike Stump]

On Aug 23, 2013, at 8:02 AM, Richard Sandiford  
wrote:
> We really need to get rid of the #include "tm.h" in wide-int.h.
> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
> thing in there.  If that comes from tm.h then perhaps we should put it
> into a new header file instead.

BITS_PER_UNIT comes from there as well, and I'd need both.  Grabbing the 
#defines we generate is easy enough, but BITS_PER_UNIT would be more annoying.  
No port in the tree makes use of it yet (other than 8).  So, do we just assume 
BITS_PER_UNIT is 8?

Re: Clean up pretty printers [15/n]

[Gabriel Dos Reis]

"Joseph S. Myers"  writes:

[...]

| > | > @@ -379,15 +375,15 @@
| > | >   switch (code)
| > | > {
| > | > case INTEGER_TYPE:
| > | > - pp_string (pp, (TYPE_UNSIGNED (t)
| > | > - ? M_(" | > - : M_(" | > + pp->translate_string (TYPE_UNSIGNED (t)
| > | > +? " | > +: " | 
| > | may need each case of the conditional expression to be marked for 
| > | extraction for translation, or to be separated into two separate calls 
| > | using "if" (we've had that issue before with conditional expressions in 
| > | diagnostics).
| > 
| > Hmm, why would that be needed now, and not before?
| > (not that I am found of the conditional, but only by curiosity.)
| 
| Previously, each string was inside a separate call to M_() - the strings 
| themselves were the msgid parameters.  Now, the msgid parameter is not a 
| single string but a more complicated expression and xgettext may not 
| handle such expressions properly the way it handles having just a single 
| string as parameter.

OK, thanks the explanation.

Do you think the same issue arise with diagnostic_set_info,
diagnostic_append_note?

-- Gaby

Clean up pretty printers [16/n]

[Gabriel Dos Reis]

Same topic as patch 14/n.  This time for primary_expression.

-- Gaby

2013-08-25  Gabriel Dos Reis  
 
c-family/
* c-pretty-print.h (c_pretty_printer::primary_expression): Now a
virtua member function.
(pp_primary_expression): Adjust.
(pp_c_primary_expression): Remove.
* c-pretty-print.c (c_pretty_printer::primary_expression): Rename
from pp_c_primary_expression.  Adjust.
(pp_c_initializer_list): Use pp_primary_expression.
(c_pretty_printer::c_pretty_printer): Do not assign to
primary_expression.

cp/
* cxx-pretty-print.h (cxx_pretty_printer::primary_expression): Now
an overrider of c_pretty_printer::primary_expression.
* cxx-pretty-print.c (cxx_pretty_printer::primary_expression):
Rename from pp_cxx_primary_expression.  Adjust.
(pp_cxx_postfix_expression): Use pp_primary_expression.
(pp_cxx_ctor_initializer): Likewise.
(cxx_pretty_printer::cxx_pretty_printer): Do not assign to
primary_expression.


Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c   (revision 201977)
+++ c-family/c-pretty-print.c   (working copy)
@@ -1212,7 +1212,7 @@
   ( expression )   */
 
 void
-pp_c_primary_expression (c_pretty_printer *pp, tree e)
+c_pretty_printer::primary_expression (tree e)
 {
   switch (TREE_CODE (e))
 {
@@ -1222,49 +1222,49 @@
 case CONST_DECL:
 case FUNCTION_DECL:
 case LABEL_DECL:
-  pp_c_tree_decl_identifier (pp, e);
+  pp_c_tree_decl_identifier (this, e);
   break;
 
 case IDENTIFIER_NODE:
-  pp_c_tree_identifier (pp, e);
+  pp_c_tree_identifier (this, e);
   break;
 
 case ERROR_MARK:
-  pp->translate_string ("");
+  translate_string ("");
   break;
 
 case RESULT_DECL:
-  pp->translate_string ("");
+  translate_string ("");
   break;
 
 case INTEGER_CST:
 case REAL_CST:
 case FIXED_CST:
 case STRING_CST:
-  pp_constant (pp, e);
+  constant (e);
   break;
 
 case TARGET_EXPR:
-  pp_c_ws_string (pp, "__builtin_memcpy");
-  pp_c_left_paren (pp);
-  pp_ampersand (pp);
-  pp_primary_expression (pp, TREE_OPERAND (e, 0));
-  pp_separate_with (pp, ',');
-  pp_ampersand (pp);
-  pp_initializer (pp, TREE_OPERAND (e, 1));
+  pp_c_ws_string (this, "__builtin_memcpy");
+  pp_c_left_paren (this);
+  pp_ampersand (this);
+  primary_expression (TREE_OPERAND (e, 0));
+  pp_separate_with (this, ',');
+  pp_ampersand (this);
+  pp_initializer (this, TREE_OPERAND (e, 1));
   if (TREE_OPERAND (e, 2))
{
- pp_separate_with (pp, ',');
- pp_c_expression (pp, TREE_OPERAND (e, 2));
+ pp_separate_with (this, ',');
+ pp_c_expression (this, TREE_OPERAND (e, 2));
}
-  pp_c_right_paren (pp);
+  pp_c_right_paren (this);
   break;
 
 default:
   /* FIXME:  Make sure we won't get into an infinite loop.  */
-  pp_c_left_paren (pp);
-  pp_expression (pp, e);
-  pp_c_right_paren (pp);
+  pp_c_left_paren (this);
+  pp_expression (this, e);
+  pp_c_right_paren (this);
   break;
 }
 }
@@ -1356,7 +1356,7 @@
if (code == RECORD_TYPE || code == UNION_TYPE)
  {
pp_c_dot (pp);
-   pp_c_primary_expression (pp, TREE_PURPOSE (init));
+   pp_primary_expression (pp, TREE_PURPOSE (init));
  }
else
  {
@@ -2119,7 +2119,7 @@
   Implementation note:  instead of going through the usual recursion
   chain, I take the liberty of dispatching nodes to the appropriate
   functions.  This makes some redundancy, but it worths it. That also
-  prevents a possible infinite recursion between pp_c_primary_expression ()
+  prevents a possible infinite recursion between pp_primary_expression ()
   and pp_c_expression ().  */
 
 void
@@ -2344,7 +2344,6 @@
 
   statement = pp_c_statement;
 
-  primary_expression= pp_c_primary_expression;
   postfix_expression= pp_c_postfix_expression;
   unary_expression  = pp_c_unary_expression;
   initializer   = pp_c_initializer;
Index: c-family/c-pretty-print.h
===
--- c-family/c-pretty-print.h   (revision 201977)
+++ c-family/c-pretty-print.h   (working copy)
@@ -56,6 +56,7 @@
 
   virtual void constant (tree);
   virtual void id_expression (tree);
+  virtual void primary_expression (tree);
   /* Points to the first element of an array of offset-list.
  Not used yet.  */
   int *offset_list;
@@ -81,7 +82,6 @@
 
   c_pretty_print_fn statement;
 
-  c_pretty_print_fn primary_expression;
   c_pretty_print_fn postfix_expression;
   c_pretty_print_fn unary_expression;
   c_pretty_print_fn multiplicative_expression;
@@ -114,7 +114,7 @@
 
 #define

Re: wide-int branch now up for public comment and review

[Richard Sandiford]

Mike Stump  writes:
> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
>  wrote:
>> We really need to get rid of the #include "tm.h" in wide-int.h.
>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
>> thing in there.  If that comes from tm.h then perhaps we should put it
>> into a new header file instead.
>
> BITS_PER_UNIT comes from there as well, and I'd need both.  Grabbing the
> #defines we generate is easy enough, but BITS_PER_UNIT would be more
> annoying.  No port in the tree makes use of it yet (other than 8).  So,
> do we just assume BITS_PER_UNIT is 8?

Looks like wide-int is just using BITS_PER_UNIT to get the number of
bits in "char".  That's a host thing, so it should be CHAR_BIT instead.

Thanks,
Richard

wide-int branch

[Kenneth Zadeck]

cleaned up code to get around tree-vrp issue.   added some code that 
richard is going to play with to see how hard it would be to clean up 
rtl constants.


kenny
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc	(revision 201968)
+++ gcc/wide-int.cc	(working copy)
@@ -171,6 +171,12 @@ wide_int_ro::from_rtx (const rtx_mode_t
 case CONST_INT:
   result.val[0] = INTVAL (x);
   result.len = 1;
+
+#if 0
+  if (prec != HOST_BITS_PER_WIDE_INT)
+	gcc_assert (result.val[0] == sext_hwi (result.val[0], prec));
+#endif
+
 #ifdef DEBUG_WIDE_INT
   debug_wh ("wide_int:: %s = from_rtx ("HOST_WIDE_INT_PRINT_HEX")\n",
 		result, INTVAL (x));
Index: gcc/wide-int.h
===
--- gcc/wide-int.h	(revision 201968)
+++ gcc/wide-int.h	(working copy)
@@ -1843,7 +1843,6 @@ wide_int_ro::zforce_to_size (unsigned in
 inline HOST_WIDE_INT
 wide_int_ro::sign_mask () const
 {
-  int i = len - 1;
   if (precision < HOST_BITS_PER_WIDE_INT)
 {
   /* We don't allow a int:0 inside a struct to get this far,
@@ -1853,14 +1852,13 @@ wide_int_ro::sign_mask () const
 	  >> (HOST_BITS_PER_WIDE_INT - 1));
 }
 
-  /* VRP appears to be badly broken and this is a very ugly fix.  */
-  if (i >= 0)
-return val[i] >> (HOST_BITS_PER_WIDE_INT - 1);
-
-  gcc_unreachable ();
-#if 0
-  return val[len - 1] >> (HOST_BITS_PER_WIDE_INT - 1);
-#endif
+  /* TREE_VRP is not able to see that it is not possible for len to be
+ 0.  So without this test, it warns about this which causes
+ bootstrap failures.  */
+  if (len < 1)
+gcc_unreachable ();
+  else
+return val[len - 1] >> (HOST_BITS_PER_WIDE_INT - 1);
 }
 
 /* Return THIS & C.  */

Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv

[Gerald Pfeifer]

On Tue, 20 Aug 2013, Florian Weimer wrote:
> As the libvtv reviewer, you don't need permission to commit your 
> changes. :-)

Actually, reviewers do need someone else's approval for their own
changes (unlike maintainers and of course not for trivial changes).

Not a biggie in this case, just wanted to clarify.

Gerald

Re: wide-int branch now up for public comment and review

[Mike Stump]

On Aug 25, 2013, at 11:29 AM, Richard Sandiford  
wrote:
> Mike Stump  writes:
>> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
>>  wrote:
>>> We really need to get rid of the #include "tm.h" in wide-int.h.
>>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
>>> thing in there.  If that comes from tm.h then perhaps we should put it
>>> into a new header file instead.
>> 
>> BITS_PER_UNIT comes from there as well, and I'd need both.  Grabbing the
>> #defines we generate is easy enough, but BITS_PER_UNIT would be more
>> annoying.  No port in the tree makes use of it yet (other than 8).  So,
>> do we just assume BITS_PER_UNIT is 8?
> 
> Looks like wide-int is just using BITS_PER_UNIT to get the number of
> bits in "char".  That's a host thing, so it should be CHAR_BIT instead.

?  What?  No.  BITS_PER_UNIT is a feature of the target machine, so, it is 
absolutely wrong to use a property of the host machine or the build machine.  
We don't use sizeof(int) to set the size of int on the target for the example 
same reason.

Re: Clean up pretty printers [15/n]

[Joseph S. Myers]

On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:

> | Previously, each string was inside a separate call to M_() - the strings 
> | themselves were the msgid parameters.  Now, the msgid parameter is not a 
> | single string but a more complicated expression and xgettext may not 
> | handle such expressions properly the way it handles having just a single 
> | string as parameter.
> 
> OK, thanks the explanation.
> 
> Do you think the same issue arise with diagnostic_set_info,
> diagnostic_append_note?

I don't see any problematic calls to those functions with this sort of 
conditional expression.

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

Re: wide-int branch now up for public comment and review

[Joseph S. Myers]

On Sun, 25 Aug 2013, Mike Stump wrote:

> On Aug 23, 2013, at 8:02 AM, Richard Sandiford  
> wrote:
> > We really need to get rid of the #include "tm.h" in wide-int.h.
> > MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
> > thing in there.  If that comes from tm.h then perhaps we should put it
> > into a new header file instead.
> 
> BITS_PER_UNIT comes from there as well, and I'd need both.  Grabbing the 
> #defines we generate is easy enough, but BITS_PER_UNIT would be more 
> annoying.  No port in the tree makes use of it yet (other than 8).  So, 
> do we just assume BITS_PER_UNIT is 8?

Regarding avoiding tm.h dependence through BITS_PER_UNIT (without actually 
converting it from a target macro to a target hook), see my suggestions at 
.  It would seem 
fairly reasonable, if in future other macros are converted to hooks and 
it's possible to build multiple back ends into a single compiler binary, 
to require that all such back ends share a value of BITS_PER_UNIT.

BITS_PER_UNIT describes the number of bits in QImode - the RTL-level byte.  
I don't think wide-int should care about that at all.  As I've previously 
noted, many front-end uses of BITS_PER_UNIT really care about the C-level 
char and so should be TYPE_PRECISION (char_type_node).  Generally, before 
thinking about how to get BITS_PER_UNIT somewhere, consider whether the 
code is actually correct to be using BITS_PER_UNIT at all - whether it's 
the RTL-level QImode that is really what's relevant to the code.

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

Re: wide-int branch now up for public comment and review

[Mike Stump]

On Aug 25, 2013, at 11:29 AM, Richard Sandiford  
wrote:
> Looks like wide-int is just using BITS_PER_UNIT to get the number of
> bits in "char".  That's a host thing, so it should be CHAR_BIT instead.

Oh, Kenny did point out one sin:

diff --git a/gcc/wide-int.cc b/gcc/wide-int.cc
index 37ce5b3..891c227 100644
--- a/gcc/wide-int.cc
+++ b/gcc/wide-int.cc
@@ -2056,7 +2056,7 @@ wide_int_ro::mul_internal (bool high, bool full,
 
   /* The 2 is for a full mult.  */
   memset (r, 0, half_blocks_needed * 2
- * HOST_BITS_PER_HALF_WIDE_INT / BITS_PER_UNIT);
+ * HOST_BITS_PER_HALF_WIDE_INT / CHAR_BIT);
 
   for (j = 0; j < half_blocks_needed; j++)
 {

which I fixed.

Re: wide-int branch now up for public comment and review

[Mike Stump]

On Aug 25, 2013, at 1:11 PM, "Joseph S. Myers"  wrote:
> On Sun, 25 Aug 2013, Mike Stump wrote:
>> On Aug 23, 2013, at 8:02 AM, Richard Sandiford  
>> wrote:
>>> We really need to get rid of the #include "tm.h" in wide-int.h.
>>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
>>> thing in there.  If that comes from tm.h then perhaps we should put it
>>> into a new header file instead.
>> 
>> BITS_PER_UNIT comes from there as well, and I'd need both.  Grabbing the 
>> #defines we generate is easy enough, but BITS_PER_UNIT would be more 
>> annoying.  No port in the tree makes use of it yet (other than 8).  So, 
>> do we just assume BITS_PER_UNIT is 8?
> 
> Regarding avoiding tm.h dependence through BITS_PER_UNIT (without actually 
> converting it from a target macro to a target hook), see my suggestions at 
> .  It would seem 
> fairly reasonable, if in future other macros are converted to hooks and 
> it's possible to build multiple back ends into a single compiler binary, 
> to require that all such back ends share a value of BITS_PER_UNIT.

Ick.  I don't see the beauty of this direction.  If one wants to move in a, we 
can generate code for any target, fine, let's do that.  If someone wants to 
make a target, just a dynamically loaded shared library, let's do that.  There 
are all sorts of directions to move it, but the intermediate, let's design and 
implement a system, where for some targets it works, and for some targets it 
doesn't work, well, I think that is short sighted and we ought not target that.

Having a separate tm-blabla.h for some of the selections of the target is fine, 
but mandating that as the form for doing a target is, well, bad.

I'd love to see the entire hook and target selection mechanism brought up to 
1990's level of sophistication, the 1970s are over.  Sigh.  Anyway, all this is 
well beyond the scope of the work at hand.

> As I've previously 
> noted, many front-end uses of BITS_PER_UNIT really care about the C-level 
> char and so should be TYPE_PRECISION (char_type_node).  Generally, before 
> thinking about how to get BITS_PER_UNIT somewhere, consider whether the 
> code is actually correct to be using BITS_PER_UNIT at all - whether it's 
> the RTL-level QImode that is really what's relevant to the code.

I think we got all the uses correct.  Let us know if any are wrong.

[wwwdocs] lists.html -- misc tweaks

[Gerald Pfeifer]

Shorten some wording.  Avoid direct references to Bugzilla and CVS.
Move a comment to where it belongs (the subscription form).

Installed.

Gerald

Index: lists.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving revision 1.104
diff -u -3 -p -r1.104 lists.html
--- lists.html  13 Sep 2009 22:46:55 -  1.104
+++ lists.html  25 Aug 2013 21:37:58 -
@@ -45,9 +45,8 @@ before subscribing<
   covered by other mailing lists is suitable for discussion here.
 
   Recruiting postings, including recruiting for GCC or other
-  free software jobs, are not permitted on this list, or on any of the
-  other GCC mailing lists.  If you are interested in hiring a GCC
-  developer, please visit the
+  free software jobs, are not permitted on any of our mailing lists.
+  If you are interested in hiring a GCC developer, please visit the
   http://www.fsf.org/resources/jobs/";>FSF jobs page.
 
   All major decisions and changes, like abandoning ports or front ends,
@@ -56,7 +55,7 @@ before subscribing<
   development process.
 
   http://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs
-  is a relatively high volume list with mails from our Bugzilla
+  is a relatively high volume list with mails from our
   bug-tracking system.
 
   http://gcc.gnu.org/ml/gcc-patches/";>gcc-patches
@@ -112,7 +111,7 @@ before subscribing<
 
   http://gcc.gnu.org/ml/gcc-cvs-wwwdocs/";>gcc-cvs-wwwdocs
   is a read-only, relatively low volume list which tracks checkins to
-  the GCC webpages CVS repository.
+  the GCC webpages repository.
 
   http://gcc.gnu.org/ml/gccadmin/";>gccadmin
   is a read-only moderate volume list where output from
@@ -183,6 +182,10 @@ it's assumed that no-one on these lists 
 You will be able to subscribe or unsubscribe from any of the GCC mailing
 lists via this form:
 
+
+
 
 http://gcc.gnu.org/cgi-bin/ml-request";>
   Mailing list: 
@@ -293,18 +296,11 @@ give yourself posting privileges just fo
 
 To complicate the harvesting of e-mail addresses from the web archives
 of the GCC mailing lists, some simple transformations are done on the
-e-mail addresses.  It isn't perfect, but short of destructively modifying
-addresses or omitting addresses altogether, there isn't a whole lot we
-can do right now.
+e-mail addresses.
 
 See also information about dealing with spam on
 the lists.
 
-
-
 
 
 This search will allow you to search the contents gcc.gnu.org.

Ada PATCH: Fix ada/58239 by linking with xg++, not xgcc

[Gabriel Dos Reis]

Hi,

My earlier patch that formally desclared pretty_printer as polymorphic
uncovered a latent bug in the existing build machinery of the Ada
component.  It had been using xgcc to link against C++ source files.  It
should use xg++ instead.

This patch fixes that by introducing GXX_LINK which is GCC_LINK except
that CXX (e.g. xg++) instead of CC (e.g. xgcc) is invoked.

Eric, are there other executables that need to be linked with GXX_LINK
too but aren't triggered yet? 

Thanks,

-- Gaby

ada/
2013-08-25  Gabriel Dos Reis  

* gcc-interface/Makefile.in (GXX_LINK): New.  Same as GCC_LINK but
with xgcc replaced with xgcc.
(common-tools): Use it.
(../../gnatmake$(exeext)): Likewise.
(../../gnatlink$(exeext)): Likewise.

Index: ada/gcc-interface/Makefile.in
===
--- ada/gcc-interface/Makefile.in   (revision 201977)
+++ ada/gcc-interface/Makefile.in   (working copy)
@@ -2398,6 +2398,7 @@
"GNATBIND=$(GNATBIND)"
 
 GCC_LINK=$(CC) $(GCC_LINK_FLAGS) $(ADA_INCLUDES)
+GXX_LINK=$(CXX) $(GCC_LINK_FLAGS) $(ADA_INCLUDES)
 
 # Build directory for the tools. Let's copy the target-dependent
 # sources using the same mechanism as for gnatlib. The other sources are
@@ -2462,23 +2463,23 @@
  gnatchop gnatcmd gnatkr gnatls gnatprep gnatxref gnatfind gnatname \
  gnatclean -bargs $(ADA_INCLUDES) $(GNATBIND_FLAGS)
$(GNATLINK) -v gnatcmd -o ../../gnat$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
$(GNATLINK) -v gnatchop -o ../../gnatchop$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
$(GNATLINK) -v gnatkr -o ../../gnatkr$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
$(GNATLINK) -v gnatls -o ../../gnatls$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
$(GNATLINK) -v gnatprep -o ../../gnatprep$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
$(GNATLINK) -v gnatxref -o ../../gnatxref$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
$(GNATLINK) -v gnatfind -o ../../gnatfind$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
$(GNATLINK) -v gnatname -o ../../gnatname$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
$(GNATLINK) -v gnatclean -o ../../gnatclean$(exeext) \
-   --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
+   --GCC="$(GXX_LINK)" $(TOOLS_LIBS)
 
 ../../gnatsym$(exeext): ../stamp-tools
$(GNATMAKE) -c $(ADA_INCLUDES) gnatsym --GCC="$(CC) $(ALL_ADAFLAGS)"
@@ -2519,11 +2520,11 @@
 
 # Likewise for the tools
 ../../gnatmake$(exeext): $(P) b_gnatm.o $(GNATMAKE_OBJS)
-   +$(GCC_LINK) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatm.o $(GNATMAKE_OBJS) \
+   +$(GXX_LINK) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatm.o $(GNATMAKE_OBJS) \
$(TOOLS_LIBS)
 
 ../../gnatlink$(exeext): $(P) b_gnatl.o $(GNATLINK_OBJS)
-   +$(GCC_LINK) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatl.o $(GNATLINK_OBJS) \
+   +$(GXX_LINK) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatl.o $(GNATLINK_OBJS) \
$(TOOLS_LIBS)
 
 ../stamp-gnatlib-$(RTSDIR):

Re: wide-int branch now up for public comment and review

[Mike Stump]

On Aug 25, 2013, at 12:26 AM, Richard Sandiford  
wrote:
> (2) Adding a new namespace, wi, for the operators.  So far this
>just contains the previously-static comparison functions
>and whatever else was needed to avoid cross-dependencies
>between wi and wide_int_ro (except for the debug routines).

It seems reasonable; I don't see anything I object to.  Seems like most of the 
time, the code is shorter (though, you use wi, which is fairly short).  It 
doesn't seem any more complex, though, knowing how to spell the operation 
wide_int:: v wi:: is confusing on the client side.  I'm torn between this and 
the nice things that come with the patch.

> (3) Removing the comparison member functions and using the static
>ones everywhere.

I've love to have richi weigh in (or someone else that wants to play the role 
of C++ coding expert)…  I'd defer to them…

> The idea behind using a namespace rather than static functions
> is that it makes it easier to separate the core, tree and rtx bits.

Being able to separate core, tree and rtx bits gets a +1 in my book.  I do 
understand the beauty of this.

> IMO wide-int.h shouldn't know about trees and rtxes, and all routines
> related to them should be in tree.h and rtl.h instead.  But using
> static functions means that you have to declare everything in one place.
> Also, it feels odd for wide_int to be both an object and a home
> of static functions that don't always operate on wide_ints, e.g. when
> comparing a CONST_INT against 16.

Yes, though, does wi feel odd being a home for comparing a CONST_INT and 16?  
:-)

> I realise I'm probably not being helpful here.

Iterating on how we want to code to look like is reasonable.  Prettying it up 
where it needs it, is good.

Indeed, if the code is as you like, and as richi likes, we'll then our mission 
is just about complete.  :-)  For this patch, I'd love to defer to richi (or 
someone that has a stronger opinion than I do) to say, better, worse…

Re: [C++ patch] Move FINAL flag to middle-end trees.

[Jason Merrill]

OK.

Jason

Clean up pretty printers [17/n]

[Gabriel Dos Reis]

Same topic as patch 15/n, but postfix_expression.
Tested on an x86_64-suse-linux.  Applied to mainline.

-- Gaby

2013-08-25  Gabriel Dos Reis  
 
c-family/
* c-pretty-print.h (c_pretty_printer::postfix_expression): Now a
virtual member function.
(pp_postfix_expression): Adjust.
(pp_c_postfix_expression): Remove.
* c-pretty-print.c (c_pretty_printer::postfix_expression): Rename
from pp_c_postfix_expression.  Adjust.
(c_pretty_printer::c_pretty_printer): Do not assign to
postfix_expression.

cp/
* cxx-pretty-print.h (cxx_pretty_printer::postfix_expression):
Declare as overrider.
* cxx-pretty-print.c (cxx_pretty_printer::postfix_expression):
Rename from pp_cxx_postfix_expression.  Adjust.
(pp_cxx_expression): Use pp_postfix_expression.
(cxx_pretty_printer::cxx_pretty_printer): Do not assign to
postfix_expression.

Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c   (revision 201984)
+++ c-family/c-pretty-print.c   (working copy)
@@ -1463,112 +1463,112 @@
   ( type-name ) { initializer-list , }  */
 
 void
-pp_c_postfix_expression (c_pretty_printer *pp, tree e)
+c_pretty_printer::postfix_expression (tree e)
 {
   enum tree_code code = TREE_CODE (e);
   switch (code)
 {
 case POSTINCREMENT_EXPR:
 case POSTDECREMENT_EXPR:
-  pp_postfix_expression (pp, TREE_OPERAND (e, 0));
-  pp_string (pp, code == POSTINCREMENT_EXPR ? "++" : "--");
+  postfix_expression (TREE_OPERAND (e, 0));
+  pp_string (this, code == POSTINCREMENT_EXPR ? "++" : "--");
   break;
 
 case ARRAY_REF:
-  pp_postfix_expression (pp, TREE_OPERAND (e, 0));
-  pp_c_left_bracket (pp);
-  pp_expression (pp, TREE_OPERAND (e, 1));
-  pp_c_right_bracket (pp);
+  postfix_expression (TREE_OPERAND (e, 0));
+  pp_c_left_bracket (this);
+  pp_expression (this, TREE_OPERAND (e, 1));
+  pp_c_right_bracket (this);
   break;
 
 case ARRAY_NOTATION_REF:
-  pp_postfix_expression (pp, ARRAY_NOTATION_ARRAY (e));
-  pp_c_left_bracket (pp);
-  pp_expression (pp, ARRAY_NOTATION_START (e));
-  pp_colon (pp);
-  pp_expression (pp, ARRAY_NOTATION_LENGTH (e));
-  pp_colon (pp);
-  pp_expression (pp, ARRAY_NOTATION_STRIDE (e));
-  pp_c_right_bracket (pp);
+  postfix_expression (ARRAY_NOTATION_ARRAY (e));
+  pp_c_left_bracket (this);
+  pp_expression (this, ARRAY_NOTATION_START (e));
+  pp_colon (this);
+  pp_expression (this, ARRAY_NOTATION_LENGTH (e));
+  pp_colon (this);
+  pp_expression (this, ARRAY_NOTATION_STRIDE (e));
+  pp_c_right_bracket (this);
   break;
   
 case CALL_EXPR:
   {
call_expr_arg_iterator iter;
tree arg;
-   pp_postfix_expression (pp, CALL_EXPR_FN (e));
-   pp_c_left_paren (pp);
+   postfix_expression (CALL_EXPR_FN (e));
+   pp_c_left_paren (this);
FOR_EACH_CALL_EXPR_ARG (arg, iter, e)
  {
-   pp_expression (pp, arg);
+   pp_expression (this, arg);
if (more_call_expr_args_p (&iter))
- pp_separate_with (pp, ',');
+ pp_separate_with (this, ',');
  }
-   pp_c_right_paren (pp);
+   pp_c_right_paren (this);
break;
   }
 
 case UNORDERED_EXPR:
-  pp_c_ws_string (pp, flag_isoc99
+  pp_c_ws_string (this, flag_isoc99
   ? "isunordered"
   : "__builtin_isunordered");
   goto two_args_fun;
 
 case ORDERED_EXPR:
-  pp_c_ws_string (pp, flag_isoc99
+  pp_c_ws_string (this, flag_isoc99
   ? "!isunordered"
   : "!__builtin_isunordered");
   goto two_args_fun;
 
 case UNLT_EXPR:
-  pp_c_ws_string (pp, flag_isoc99
+  pp_c_ws_string (this, flag_isoc99
   ? "!isgreaterequal"
   : "!__builtin_isgreaterequal");
   goto two_args_fun;
 
 case UNLE_EXPR:
-  pp_c_ws_string (pp, flag_isoc99
+  pp_c_ws_string (this, flag_isoc99
   ? "!isgreater"
   : "!__builtin_isgreater");
   goto two_args_fun;
 
 case UNGT_EXPR:
-  pp_c_ws_string (pp, flag_isoc99
+  pp_c_ws_string (this, flag_isoc99
   ? "!islessequal"
   : "!__builtin_islessequal");
   goto two_args_fun;
 
 case UNGE_EXPR:
-  pp_c_ws_string (pp, flag_isoc99
+  pp_c_ws_string (this, flag_isoc99
   ? "!isless"
   : "!__builtin_isless");
   goto two_args_fun;
 
 case UNEQ_EXPR:
-  pp_c_ws_string (pp, flag_isoc99
+  pp_c_ws_string (this, flag_isoc99
   ? "!islessgreater"
   : "!__builtin_islessgreater");
   got

Re: powerpc64le multilibs and multiarch dir

[Alan Modra]

On Fri, Aug 23, 2013 at 09:41:28PM +, Joseph S. Myers wrote:
> On Thu, 22 Aug 2013, Alan Modra wrote:
> 
> > For multiarch, powerpc64le-linux now will use powerpc64le-linux-gnu.
> > Given a typical big-endian native toolchain with os dirs /lib and
> > /lib64, we'll use /lible and /lib64le if supporting little-endian as
> > well.  If you happen to use /lib and /lib32, then the little-endian
> > variants are /lible and /lib32le.  For completeness I also support
> > building big-endian multilibs on a little-endian host.
> 
> Given those directory names, what are the defined dynamic linker paths for 
> 32-bit and 64-bit little-endian (which can't depend on which of the 
> various directory arrangements may be in use)?

We haven't defined the little-endian ld.so variants yet.

> Does the Power Architecture support, in principle, a single system running 
> both big-endian and little-endian processes at the same time

It does.  

>, or is it a 
> matter of hardware configuration or boot-time setup?  Unless both can run 
> at once, it doesn't seem particularly useful to define separate 
> directories for big and little endian since a particular system would be 
> just one or the other.

We (IBM) don't intend to support running both big and little-endian
processes on the same system in the near future.  Perhaps I'm jumping
the gun in defining the multi-os dirs like /lible and /lib64le.  I did
that to make it easier for people ideologically opposed to multiarch
to set up a native powerpc64 compiler that supports both big and
little-endian compilation.  I know the multi-os dirs aren't strictly
needed to do that..  Should I not be defining them yet?

-- 
Alan Modra
Australia Development Lab, IBM

Re: libtool update for powerpc64le-linux

[Alan Modra]

On Fri, Aug 23, 2013 at 10:08:29PM +, Joseph S. Myers wrote:
> On Fri, 23 Aug 2013, Alan Modra wrote:
> 
> > I'd like to import upstream libtool into gcc to support powerpc64le,
> 
> Has the sysroot semantics issue been resolved in upstream libtool, or do 
> you mean "import with 3334f7ed5851ef1e96b052f2984c4acdbf39e20c reverted"?

As far as I can tell, upstream libtool hasn't changed its sysroot
support since that patch went in.  I wasn't even aware of the issue..

How did the gcc project get to the place where we aren't following our
own rules http://gcc.gnu.org/codingconventions.html regarding libtool?
We're supposed to get a patch reviewed upstream, applied, then import
the whole lot.  From the top-level ChangeLog, that hasn't happened
since 2009-12-05!  It must be a little disheartening to be a libtool
maintainer, when a major GNU project like gcc treats your work like
this.

-- 
Alan Modra
Australia Development Lab, IBM

Re: wide-int branch now up for public comment and review

[Kenneth Zadeck]

On 08/25/2013 06:55 PM, Mike Stump wrote:

On Aug 25, 2013, at 12:26 AM, Richard Sandiford  
wrote:

(2) Adding a new namespace, wi, for the operators.  So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid cross-dependencies
between wi and wide_int_ro (except for the debug routines).

It seems reasonable; I don't see anything I object to.  Seems like most of the 
time, the code is shorter (though, you use wi, which is fairly short).  It 
doesn't seem any more complex, though, knowing how to spell the operation 
wide_int:: v wi:: is confusing on the client side.  I'm torn between this and 
the nice things that come with the patch.


(3) Removing the comparison member functions and using the static
ones everywhere.

I've love to have richi weigh in (or someone else that wants to play the role 
of C++ coding expert)…  I'd defer to them…


The idea behind using a namespace rather than static functions
is that it makes it easier to separate the core, tree and rtx bits.

Being able to separate core, tree and rtx bits gets a +1 in my book.  I do 
understand the beauty of this.


IMO wide-int.h shouldn't know about trees and rtxes, and all routines
related to them should be in tree.h and rtl.h instead.  But using
static functions means that you have to declare everything in one place.
Also, it feels odd for wide_int to be both an object and a home
of static functions that don't always operate on wide_ints, e.g. when
comparing a CONST_INT against 16.

Yes, though, does wi feel odd being a home for comparing a CONST_INT and 16?  
:-)
on the other hand, how else are you going to do this.i have not seen 
anyone sign up to make an oo version of rtl and even if they did that, 
the consts are just a small part of it.


i agree that it is odd, but then again, it is actually nice to have a 
largely similar interface for trees and rtl.





I realise I'm probably not being helpful here.

Iterating on how we want to code to look like is reasonable.  Prettying it up 
where it needs it, is good.

Indeed, if the code is as you like, and as richi likes, we'll then our mission 
is just about complete.  :-)  For this patch, I'd love to defer to richi (or 
someone that has a stronger opinion than I do) to say, better, worse…

Re: powerpc64le multilibs and multiarch dir

[Mike Stump]

On Aug 25, 2013, at 8:32 PM, Alan Modra  wrote:
> We (IBM) don't intend to support running both big and little-endian
> processes on the same system in the near future.  Perhaps I'm jumping
> the gun in defining the multi-os dirs like /lible and /lib64le.

I'd recommend against multilibs, unless you have a need for them…  Life is much 
simpler (and faster).  The usual people to add them are, say the linux people 
that do a distribution that want to support both, at that point, they'll add it.

Sometimes one might add multilib to enable easier, faster testing.  On targets 
where there are small numbers of users and the developers want to do a multilib 
to make testing easier (build once, test twice).  One can have all the beef in 
the tree, with the multilib in comments.  Easy to turn on, if one wants, but 
you don't pay the price otherwise.