PR middle-end/52584

[David Miller]

Richard, I was looking into a testsuite failure on the 4.7 branch
on sparc and I think your fix for 52584 would fix it too.

The problem eminates in gcc.c-torture/execute/vector-shift2.c with -O0

The 4 integer vector shifts get lowered to 2 integer vector shifts,
since that is what the VIS3 shifts are capable of.

However, type_for_widest_vector_mode does not take the signedness into
consideration.  So:

signed_vector >> unsigned_vector

gets lowered into:

unsigned_vector >> unsigned_vector

since type_for_widest_vector_mode unconditionally always passes
'1' for "unsignedp", and thus the testcase aborts since we use
a logical shift instead of an arithmetic one.

I came up with the crude fix below, but then I noticed in mainline
the change you made in order to resolve 52584.

I'd like to see this fixed on the 4.7 branch since the problem
generates incorrect code, rather than merely miss an optimization
opportunity.

diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
index be54710..aa7b774 100644
--- a/gcc/tree-vect-generic.c
+++ b/gcc/tree-vect-generic.c
@@ -476,7 +476,8 @@ expand_vector_operation (gimple_stmt_iterator *gsi, tree 
type, tree compute_type
SATP is true for saturating fixed-point types.  */
 
 static tree
-type_for_widest_vector_mode (enum machine_mode inner_mode, optab op, int satp)
+type_for_widest_vector_mode (enum machine_mode inner_mode, optab op, int satp,
+int unsignedp)
 {
   enum machine_mode best_mode = VOIDmode, mode;
   int best_nunits = 0;
@@ -508,7 +509,7 @@ type_for_widest_vector_mode (enum machine_mode inner_mode, 
optab op, int satp)
   if (ALL_FIXED_POINT_MODE_P (best_mode))
return lang_hooks.types.type_for_mode (best_mode, satp);
 
-  return lang_hooks.types.type_for_mode (best_mode, 1);
+  return lang_hooks.types.type_for_mode (best_mode, unsignedp);
 }
 }
 
@@ -858,7 +859,8 @@ expand_vector_operations_1 (gimple_stmt_iterator *gsi)
 {
   tree vector_compute_type
 = type_for_widest_vector_mode (TYPE_MODE (TREE_TYPE (type)), op,
-  TYPE_SATURATING (TREE_TYPE (type)));
+  TYPE_SATURATING (TREE_TYPE (type)),
+  TYPE_UNSIGNED (TREE_TYPE (type)));
   if (vector_compute_type != NULL_TREE
  && (TYPE_VECTOR_SUBPARTS (vector_compute_type)
  < TYPE_VECTOR_SUBPARTS (compute_type))

Re: [C++ Patch] PR 44516

[Paolo Carlini]

On 05/17/2012 05:32 AM, Jason Merrill wrote:

On 05/16/2012 08:34 PM, Paolo Carlini wrote:

Ok. Something like p2 below?


Yes.  Since the earlier patch without LOC_OR_HERE passed testing, 
let's apply that plus this p2.

Ok, great.


Does Manuel's suggestion of aborting if we get UNKNOWN_LOCATION for a 
diagnostic pass the testsuite?
Right, yesterday forgot to try that, when I came back to this task was a 
bit tired.


Now, the exercise turned out to be funny, because if I add a gcc_assert 
(location != UNKNOWN_LOCATION); at the beginning of 
diagnostic_report_diagnostic the bootstrap fails very early when 
configuring libgcc because the C compiler is not usable at all. The 
problem is that the following warning reaches the diagnostic machinery:


(gdb) p *diagnostic
$2 = {message = {format_spec = 0x38138b0 "-Wformat-y2k ignored without 
-Wformat", args_ptr = 0x7fffdaf8, err_no = 2, locus = 0x4fa94a3f, 
x_data = 0x0}, location = 0, override_column = 0, x_data = 0x0, kind = 
DK_WARNING, option_index = 226}


now, besides the specific warning - which right now I can't say to fully 
understand - it looks like we may sometimes try to output stuff which 
doesn't have to do with a specific line of the user code, thus doesn't 
come with a location. Can we concisely characterize those messages and 
exclude them from the gcc_assert?


Thanks,
Paolo.

Re: [C++ Patch] PR 44516

[Paolo Carlini]

On 05/17/2012 09:48 AM, Paolo Carlini wrote:
Can we concisely characterize those messages and exclude them from the 
gcc_assert?
Well, if don't quickly figure out something better, I guess we can 
always add the assert at the beginning of warning_at, error_at, etc.


Paolo.

Re: [C++ Patch] PR 44516

[Gabriel Dos Reis]

On Thu, May 17, 2012 at 2:52 AM, Paolo Carlini  wrote:
> On 05/17/2012 09:48 AM, Paolo Carlini wrote:
>>
>> Can we concisely characterize those messages and exclude them from the
>> gcc_assert?
>
> Well, if don't quickly figure out something better, I guess we can always
> add the assert at the beginning of warning_at, error_at, etc.

I am still puzzled by why we need to assert, as opposed to just ignore, unless
we have a plan to make a wholesale move -- but even there I am bit nervous.

-- Gaby

Re: [libjava] --enable-symvers tweak for 52700

[Andrew Haley]

On 05/17/2012 12:14 AM, Benjamin De Kosnik wrote:
> Allows use of --enable-symvers=gnu-versioned-namespace while
> configuring in libjava. The rest of the target libs that use
> --enable-symvers already handle this. As per libstdc++/52700.
> 
> Pretty simple, but will wait for OK for trunk/branch
> 
> tested x86/linux

OK, thanks.

Andrew.

Re: [C++ Patch] PR 44516

[Paolo Carlini]

On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:

On Thu, May 17, 2012 at 2:52 AM, Paolo Carlini  wrote:

On 05/17/2012 09:48 AM, Paolo Carlini wrote:

Can we concisely characterize those messages and exclude them from the
gcc_assert?

Well, if don't quickly figure out something better, I guess we can always
add the assert at the beginning of warning_at, error_at, etc.

I am still puzzled by why we need to assert, as opposed to just ignore, unless
we have a plan to make a wholesale move -- but even there I am bit nervous.
Eh, don't ask me ;) Anyway, in terms of testing that we aren't screwing 
up anything in the C++ front-end, the testsuite just passed with the 
below p3 attached. That's good.


If we wanted to apply it we would have to tweak a bit objc, because it 
wants to use warning_at (0, 0, ..). Also, as you can see, I didn't test 
asserts in permerror, inform, because explicitly passing 0 has uses in 
the C++ front-end, and also pedwarn, because the comment before it 
explains that pedwarn (0, ...) can be useful in some cases.


Thus, I guess, basing on this further positive test and the previous 
feedback from Jason, I 'm going ahead with the last complete patch I 
posted for 44516 + the tweak named p2. I'm going to boot and test again 
and commit the whole thing.


If we want to add something in terms of asserts, that seems anyway quite 
an independent issue, just let me know.


Thanks!
Paolo.

/
Index: diagnostic.c
===
--- diagnostic.c(revision 187624)
+++ diagnostic.c(working copy)
@@ -798,6 +798,8 @@ warning_at (location_t location, int opt, const ch
   diagnostic_info diagnostic;
   va_list ap;
   bool ret;
+  
+  gcc_assert (location != UNKNOWN_LOCATION);
 
   va_start (ap, gmsgid);
   diagnostic_set_info (&diagnostic, gmsgid, &ap, location, DK_WARNING);
@@ -881,6 +883,8 @@ error_n (location_t location, int n, const char *s
   diagnostic_info diagnostic;
   va_list ap;
 
+  gcc_assert (location != UNKNOWN_LOCATION);
+
   va_start (ap, plural_gmsgid);
   diagnostic_set_info_translated (&diagnostic,
   ngettext (singular_gmsgid, plural_gmsgid, n),
@@ -891,13 +895,15 @@ error_n (location_t location, int n, const char *s
 
 /* Same as ebove, but use location LOC instead of input_location.  */
 void
-error_at (location_t loc, const char *gmsgid, ...)
+error_at (location_t location, const char *gmsgid, ...)
 {
   diagnostic_info diagnostic;
   va_list ap;
 
+  gcc_assert (location != UNKNOWN_LOCATION);
+
   va_start (ap, gmsgid);
-  diagnostic_set_info (&diagnostic, gmsgid, &ap, loc, DK_ERROR);
+  diagnostic_set_info (&diagnostic, gmsgid, &ap, location, DK_ERROR);
   report_diagnostic (&diagnostic);
   va_end (ap);
 }

Coldfire Cores

[Nathan Sidwell]

I've committed this patch of Kwok's, which adds some additional Coldfire 
51-series cores.  I committed the binutils part yesterday.


nathan
2012-05-17  Kwok Cheung Yeung  

	* config/m68k/m68k-devices.def: Add 51ag, 51je, 51jf, 51jg, 51mm,
	51qm.
	* config/m68k/m68k-tables.opt: Regenerated.
	* doc/invoke.texi (M680x0 Options): Document.

Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 187586)
+++ doc/invoke.texi	(working copy)
@@ -14556,7 +14556,7 @@ below, which also classifies the CPUs in
 
 @multitable @columnfractions 0.20 0.80
 @item @strong{Family} @tab @strong{@samp{-mcpu} arguments}
-@item @samp{51} @tab @samp{51} @samp{51ac} @samp{51cn} @samp{51em} @samp{51qe}
+@item @samp{51} @tab @samp{51} @samp{51ac} @samp{51ag} @samp{51cn} @samp{51em} @samp{51je} @samp{51jf} @samp{51jg} @samp{51jm} @samp{51mm} @samp{51qe} @samp{51qm}
 @item @samp{5206} @tab @samp{5202} @samp{5204} @samp{5206}
 @item @samp{5206e} @tab @samp{5206e}
 @item @samp{5208} @tab @samp{5207} @samp{5208}
Index: config/m68k/m68k-devices.def
===
--- config/m68k/m68k-devices.def	(revision 187586)
+++ config/m68k/m68k-devices.def	(working copy)
@@ -84,10 +84,16 @@ M68K_DEVICE ("cpu32", cpu32,"cpu32",
 /* For historical reasons, the 51 multilib is named 51qe.  */
 M68K_DEVICE ("51",mcf51,"51","51qe",  cfv1, isa_c, FL_CF_USP)
 M68K_DEVICE ("51ac",  mcf51ac,  "51","51qe",  cfv1, isa_c, FL_CF_USP)
+M68K_DEVICE ("51ag",  mcf51ag,  "51","51qe",  cfv1, isa_c, FL_CF_USP)
 M68K_DEVICE ("51cn",  mcf51cn,  "51","51qe",  cfv1, isa_c, FL_CF_USP)
 M68K_DEVICE ("51em",  mcf51em,  "51","51qe",  cfv1, isa_c, FL_CF_USP | FL_CF_MAC)
+M68K_DEVICE ("51je",  mcf51je,  "51","51qe",  cfv1, isa_c, FL_CF_USP | FL_CF_MAC)
+M68K_DEVICE ("51jf",  mcf51jf,  "51","51qe",  cfv1, isa_c, FL_CF_USP | FL_CF_EMAC)
+M68K_DEVICE ("51jg",  mcf51jg,  "51","51qe",  cfv1, isa_c, FL_CF_USP | FL_CF_EMAC)
 M68K_DEVICE ("51jm",  mcf51jm,  "51","51qe",  cfv1, isa_c, FL_CF_USP)
+M68K_DEVICE ("51mm",  mcf51mm,  "51","51qe",  cfv1, isa_c, FL_CF_USP | FL_CF_MAC)
 M68K_DEVICE ("51qe",  mcf51qe,  "51","51qe",  cfv1, isa_c, FL_CF_USP)
+M68K_DEVICE ("51qm",  mcf51qm,  "51","51qe",  cfv1, isa_c, FL_CF_USP | FL_CF_EMAC)
 
 /* ColdFire CFV2 processors.  */
 M68K_DEVICE ("5202",  mcf5202,  "5206",  "5206",  cfv2, isa_a, 0)
Index: config/m68k/m68k-tables.opt
===
--- config/m68k/m68k-tables.opt	(revision 187586)
+++ config/m68k/m68k-tables.opt	(working copy)
@@ -58,18 +58,36 @@ EnumValue
 Enum(target_device) String(51ac) Value(mcf51ac)
 
 EnumValue
+Enum(target_device) String(51ag) Value(mcf51ag)
+
+EnumValue
 Enum(target_device) String(51cn) Value(mcf51cn)
 
 EnumValue
 Enum(target_device) String(51em) Value(mcf51em)
 
 EnumValue
+Enum(target_device) String(51je) Value(mcf51je)
+
+EnumValue
+Enum(target_device) String(51jf) Value(mcf51jf)
+
+EnumValue
+Enum(target_device) String(51jg) Value(mcf51jg)
+
+EnumValue
 Enum(target_device) String(51jm) Value(mcf51jm)
 
 EnumValue
+Enum(target_device) String(51mm) Value(mcf51mm)
+
+EnumValue
 Enum(target_device) String(51qe) Value(mcf51qe)
 
 EnumValue
+Enum(target_device) String(51qm) Value(mcf51qm)
+
+EnumValue
 Enum(target_device) String(5202) Value(mcf5202)
 
 EnumValue

Make ipa-reference to work on non-static at LTO time

[Jan Hubicka]

Hi,
when I was upding ipa-reference.c to LTO I took the easiest possible approach
keeping it to work only on statics without address taken at compile time and
propagate at linktime. The idea was that soonish we will replace it by something
more sane.

Well, this did not happen yet and this hack needed update with my symtab work
so I decided to go ahead and make ipa-reference to analyze all variables
and at execution time prune out non-statics and vars with address taken.
This makes it stronger especially with LTO, but also without WRT cases where
we optimize out the ADDR_EXPR operaitons.
Not that this would be too important optimizaiton, but it is easy to do.

Bootstrapped/regtested x86_64 and tested with Mozilla, comitted.

Honza

* ipa-reference.c (is_proper_for_analysis): Do not check flags
that might change as result of global optimization.
(analyze_function): Do not check analyzed and externally_visible
flags; be happy about address dereferences.
(propagate): Prune all_module_statics so it really contains just
statics; prune all the local summaries.
(ipa_reference_write_optimization_summary): Simplify.
Index: ipa-reference.c
===
--- ipa-reference.c (revision 187412)
+++ ipa-reference.c (working copy)
@@ -247,10 +247,6 @@ add_static_var (tree var)
 static inline bool
 is_proper_for_analysis (tree t)
 {
-  /* We handle only variables whose address is never taken.  */
-  if (TREE_ADDRESSABLE (t))
-return false;
-
   /* If the variable has the "used" attribute, treat it as if it had a
  been touched by the devil.  */
   if (DECL_PRESERVE_P (t))
@@ -266,10 +262,6 @@ is_proper_for_analysis (tree t)
   if (TREE_READONLY (t))
 return false;
 
-  /* We cannot touch decls where the type needs constructing.  */
-  if (TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (t)))
-return false;
-
   /* This is a variable we care about.  Check if we have seen it
  before, and if not add it the set of variables we care about.  */
   if (all_module_statics
@@ -438,9 +430,7 @@ analyze_function (struct cgraph_node *fn
   if (!symtab_variable_p (ref->referred))
continue;
   var = ipa_ref_varpool_node (ref)->symbol.decl;
-  if (ipa_ref_varpool_node (ref)->symbol.externally_visible
- || !ipa_ref_varpool_node (ref)->analyzed
- || !is_proper_for_analysis (var))
+  if (!is_proper_for_analysis (var))
continue;
   switch (ref->use)
{
@@ -453,7 +443,6 @@ analyze_function (struct cgraph_node *fn
   bitmap_set_bit (local->statics_written, DECL_UID (var));
  break;
case IPA_REF_ADDR:
- gcc_unreachable ();
  break;
}
 }
@@ -613,6 +602,7 @@ static unsigned int
 propagate (void)
 {
   struct cgraph_node *node;
+  struct varpool_node *vnode;
   struct cgraph_node *w;
   struct cgraph_node **order =
 XCNEWVEC (struct cgraph_node *, cgraph_n_nodes);
@@ -625,6 +615,28 @@ propagate (void)
   ipa_discover_readonly_nonaddressable_vars ();
   generate_summary ();
 
+  /* Now we know what vars are realy statics; prune out those that aren't.  */
+  FOR_EACH_VARIABLE (vnode)
+if (vnode->symbol.externally_visible
+   || TREE_ADDRESSABLE (vnode->symbol.decl)
+   || TREE_READONLY (vnode->symbol.decl)
+   || !is_proper_for_analysis (vnode->symbol.decl)
+   || !vnode->analyzed)
+  bitmap_clear_bit (all_module_statics, DECL_UID (vnode->symbol.decl));
+
+  /* Forget info we collected "just for fun" on variables that turned out to be
+ non-local.  */
+  FOR_EACH_DEFINED_FUNCTION (node)
+{
+  ipa_reference_local_vars_info_t node_l;
+
+  node_l = &get_reference_vars_info (node)->local;
+  if (node_l->statics_read != all_module_statics)
+bitmap_and_into (node_l->statics_read, all_module_statics);
+  if (node_l->statics_written != all_module_statics)
+bitmap_and_into (node_l->statics_written, all_module_statics);
+}
+
   /* Propagate the local information thru the call graph to produce
  the global information.  All the nodes within a cycle will have
  the same info so we collapse cycles first.  Then we can do the
@@ -1034,9 +1046,7 @@ ipa_reference_write_optimization_summary
   for (i = 0; i < lto_varpool_encoder_size (varpool_encoder); i++)
 {
   struct varpool_node *vnode = lto_varpool_encoder_deref (varpool_encoder, 
i);
-  if (!vnode->symbol.externally_visible
- && vnode->analyzed
- && bitmap_bit_p (all_module_statics, DECL_UID (vnode->symbol.decl))
+  if (bitmap_bit_p (all_module_statics, DECL_UID (vnode->symbol.decl))
  && referenced_from_this_partition_p (&vnode->symbol.ref_list, set, 
vset))
{
  tree decl = vnode->symbol.decl;

Re: PING PATCH: break lines in announce_function

[Manuel López-Ibáñez]

On 16 May 2012 20:41, Tom Tromey  wrote:
>
> Manuel> * Hitting auto-completion in GDB means staring at the window for 5-10
> Manuel> minutes until it decides to stop listing stuff.
>
> Report completion bugs to gdb.  There's only so much gdb can do here.
> But maybe we could have some mode to be more selective about what to
> complete.

Well, it could do like bash. Give a message if there are more than N
options and ask y/n, no?

Cheers,

Manuel.

[C++ Patch] PR 53371

[Paolo Carlini]

Hi,

this is a rather simple PR about us not rejecting rvalue reference catch 
parameters. When I looked into it I noticed that we also aren't 
explicitly handling abstract types (which now in C++11 are explicitly 
mentioned in [except.handle]): eventually we rejected those but with a 
quite poor diagnostic. In fact handling the latter too allows to share 
most of the checking code with that on throw expressions, like in the 
below  is_admissible_throw_operand_or_catch_parameter.


Booted and tested x86_64-linux. Ok?

Thanks,
Paolo.

///
/cp
2012-05-17  Paolo Carlini  

PR c++/53371
* except.c (is_admissible_throw_operand): Rename to
is_admissible_throw_operand_or_catch_parameter and handle
catch parameter too.
(expand_start_catch_block): Use it.
(build_throw): Adjust.

/testsuite
2012-05-17  Paolo Carlini  

PR c++/53371
* g++.dg/cpp0x/catch1.C: New.
Index: testsuite/g++.dg/cpp0x/catch1.C
===
--- testsuite/g++.dg/cpp0x/catch1.C (revision 0)
+++ testsuite/g++.dg/cpp0x/catch1.C (revision 0)
@@ -0,0 +1,16 @@
+// PR c++/53371
+// { dg-do compile { target c++11 } }
+
+struct Abs
+{
+  virtual void a() = 0;
+};
+
+void foo()
+{
+  try {
+  } catch (Abs) { }   // { dg-error "abstract class type" }
+
+  try {
+  } catch (int&&) { } // { dg-error "rvalue reference type" }
+}
Index: cp/except.c
===
--- cp/except.c (revision 187624)
+++ cp/except.c (working copy)
@@ -46,7 +46,7 @@ static void initialize_handler_parm (tree, tree);
 static tree do_allocate_exception (tree);
 static tree wrap_cleanups_r (tree *, int *, void *);
 static int complete_ptr_ref_or_void_ptr_p (tree, tree);
-static bool is_admissible_throw_operand (tree);
+static bool is_admissible_throw_operand_or_catch_parameter (tree, bool);
 static int can_convert_eh (tree, tree);
 
 /* Sets up all the global eh stuff that needs to be initialized at the
@@ -485,12 +485,13 @@ expand_start_catch_block (tree decl)
   if (! doing_eh ())
 return NULL_TREE;
 
-  /* Make sure this declaration is reasonable.  */
-  if (decl && !complete_ptr_ref_or_void_ptr_p (TREE_TYPE (decl), NULL_TREE))
-decl = error_mark_node;
+  if (decl)
+{
+  if (!is_admissible_throw_operand_or_catch_parameter (decl, false))
+   decl = error_mark_node;
 
-  if (decl)
-type = prepare_eh_type (TREE_TYPE (decl));
+  type = prepare_eh_type (TREE_TYPE (decl));
+}
   else
 type = NULL_TREE;
 
@@ -720,7 +721,7 @@ build_throw (tree exp)
 
   if (exp != NULL_TREE)
 {
-  if (!is_admissible_throw_operand (exp))
+  if (!is_admissible_throw_operand_or_catch_parameter (exp, true))
return error_mark_node;
 }
 
@@ -944,15 +945,22 @@ complete_ptr_ref_or_void_ptr_p (tree type, tree fr
   return 1;
 }
 
-/* Return truth-value if EXPRESSION is admissible in throw-expression,
-   i.e. if it is not of incomplete type or a pointer/reference to such
-   a type or of an abstract class type.  */
+/* If IS_THROW is true return truth-value if T is an expression admissible
+   in throw-expression, i.e. if it is not of incomplete type or a pointer/
+   reference to such a type or of an abstract class type.
+   If IS_THROW is false, likewise for a catch parameter, same requirements
+   for its type plus rvalue reference type is also not admissible.  */
 
 static bool
-is_admissible_throw_operand (tree expr)
+is_admissible_throw_operand_or_catch_parameter (tree t, bool is_throw)
 {
-  tree type = TREE_TYPE (expr);
+  tree expr = is_throw ? t : NULL_TREE;
+  tree type = TREE_TYPE (t);
 
+  /* C++11 [except.handle] The exception-declaration shall not denote
+ an incomplete type, an abstract class type, or an rvalue reference 
+ type.  */
+
   /* 15.1/4 [...] The type of the throw-expression shall not be an
incomplete type, or a pointer or a reference to an incomplete
type, other than void*, const void*, volatile void*, or
@@ -968,10 +976,22 @@ static bool
conversion.  */
   else if (CLASS_TYPE_P (type) && CLASSTYPE_PURE_VIRTUALS (type))
 {
-  error ("expression %qE of abstract class type %qT cannot "
-"be used in throw-expression", expr, type);
+  if (is_throw)
+   error ("expression %qE of abstract class type %qT cannot "
+  "be used in throw-expression", expr, type);
+  else
+   error ("cannot declare catch parameter to be of abstract "
+  "class type %qT", type);
   return false;
 }
+  else if (!is_throw
+  && TREE_CODE (type) == REFERENCE_TYPE
+  && TYPE_REF_IS_RVALUE (type))
+{
+  error ("cannot declare catch parameter to be of rvalue "
+"reference type %qT", type);
+  return false;
+}
 
   return true;
 }

Re: [patch] More thorough checking in reg_fits_class_p

[Jim MacArthur]

On 02/05/12 14:55, Richard Sandiford wrote:

Richard Earnshaw  writes:

On 02/05/12 14:00, Richard Sandiford wrote:

Jim MacArthur  writes:

New Changelog text:

2012-05-02 Jim MacArthur
* recog.c (reg_fits_class_p): Check both regno and regno + offset are
hard registers.

Thanks.  I still think the final:


+   &&  HARD_REGISTER_NUM_P (end_hard_regno (regno + offset, mode))

check belongs in in_hard_reg_set_p, since most callers don't (and IMO
shouldn't need to) check this.  The idea behind adding these functions
was to commonise various bits of code that were doing the same checks
in slightly different ways.  Requiring each caller to check the end
register would go against that to some extent.


If you're going to do that (which is fine, BTW), I think
in_hard_reg_set_p should gcc_assert() that regno is a valid hard reg.

Sounds good.

Richard



Sorry for the delay in responding to this, I had a few problems with 
end_hard_regno. Here's a new version of the patch, which adds to 
in_hard_reg_set_p the assert and a check for the hardness of end_regno.  
end_hard_regno is the exclusive upper bound of the range, so not 
actually a meaningful reg no. HARD_REGNO_NREGS is required to return a 
positive value, so (end_regno - 1) is always safe, as I understand it.


I've tested this with an x86 bootstrap which shows no errors, and with 
our own AArch64 back end.


Jim

New ChangeLog text:

2012-05-17  Jim MacArthur
  * recog.c (reg_fits_class_p): Check both regno and regno + offset are  
hard registers.

  * regs.h (in_hard_reg_set_p): Assert that regno is a hard register and
check end_regno - 1 is a hard register.

diff --git a/gcc/recog.c b/gcc/recog.c
index c5725d2..d664594 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -2792,14 +2792,16 @@ bool
 reg_fits_class_p (const_rtx operand, reg_class_t cl, int offset,
  enum machine_mode mode)
 {
-  int regno = REGNO (operand);
+  unsigned int regno = REGNO (operand);
 
   if (cl == NO_REGS)
 return false;
 
+  /* Regno must not be a pseudo register.  Offset may be negative.  */
   return (HARD_REGISTER_NUM_P (regno)
- && in_hard_reg_set_p (reg_class_contents[(int) cl],
-   mode, regno + offset));
+ && HARD_REGISTER_NUM_P (regno + offset)
+ && in_hard_reg_set_p (reg_class_contents[(int) cl], mode, 
+   regno + offset));
 }
 
 /* Split single instruction.  Helper function for split_all_insns and
diff --git a/gcc/regs.h b/gcc/regs.h
index 328b839..d18bf0a 100644
--- a/gcc/regs.h
+++ b/gcc/regs.h
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #include "machmode.h"
 #include "hard-reg-set.h"
+#include "rtl.h"
 
 #define REG_BYTES(R) mode_size[(int) GET_MODE (R)]
 
@@ -367,10 +368,16 @@ in_hard_reg_set_p (const HARD_REG_SET regs, enum 
machine_mode mode,
 {
   unsigned int end_regno;
 
+  gcc_assert (HARD_REGISTER_NUM_P (regno));
+  
   if (!TEST_HARD_REG_BIT (regs, regno))
 return false;
 
   end_regno = end_hard_regno (mode, regno);
+
+  if (!HARD_REGISTER_NUM_P (end_regno - 1))
+return false;
+
   while (++regno < end_regno)
 if (!TEST_HARD_REG_BIT (regs, regno))
   return false;

Ping (Was: Speed up insn-attrtab.c compilation)

[Michael Matz]

Ping.

On Tue, 8 May 2012, Michael Matz wrote:

> Hi,
> 
> On Mon, 7 May 2012, Mike Stump wrote:
> 
> > On May 7, 2012, at 6:11 AM, Michael Matz wrote:
> > > I'd like to retain the #if 0 code therein,
> > 
> > Can you structure this code as
> > 
> > #define DEBUG 0
> > 
> >   if (DEBUG) ...
> > 
> > ?
> > 
> > If so, that would be a preferable way to structure the code.
> 
> Sure, consider the patch so amended.
> 
> 
> Ciao,
> Michael.
> 

Re: Turn check macros into functions. (issue6188088)

[Michael Matz]

Hi,

On Wed, 16 May 2012, Lawrence Crowl wrote:

> > Because it accepts any type as tree argument?  It's of course not less 
> > type safety than using macros, but less type safety compared to not 
> > using templates.
> 
> The overload works if the only types are tree and const_tree. In the 
> future, we may wish to refine the types so that, for example, we can 
> have a pointer to a decl and ask if it is a var decl.

Cross the bridge when you reach it, not before.  Not everybody agrees that 
the splitting of tree would be a good idea.  Right now templates aren't 
necessary, so you shouldn't use them.  (well, and an investigation why 
they come up with smaller .text would be in order anyway).


Ciao,
Michael.

Re: [C++ Patch] PR 53371

[Jason Merrill]

OK.

Jason

[Patch, committed as obvious] obj++/53388

[Paolo Carlini]

Hi,

sorry about that, will commit momentarily at the end of a bootstrap.

Thanks,
Paolo.

///
2012-05-17  Paolo Carlini  

PR objc++/53388
* objc-act.c (objc_get_class_reference, objc_build_message_expr):
Use build_min_nt_loc.

Index: objc-act.c
===
--- objc-act.c  (revision 187624)
+++ objc-act.c  (working copy)
@@ -3293,7 +3293,7 @@ objc_get_class_reference (tree ident)
 #ifdef OBJCPLUS
   if (processing_template_decl)
 /* Must wait until template instantiation time.  */
-return build_min_nt (CLASS_REFERENCE_EXPR, ident);
+return build_min_nt_loc (UNKNOWN_LOCATION, CLASS_REFERENCE_EXPR, ident);
 #endif
 
   if (TREE_CODE (ident) == TYPE_DECL)
@@ -5272,8 +5272,8 @@ objc_build_message_expr (tree receiver, tree messa
 #ifdef OBJCPLUS
   if (processing_template_decl)
 /* Must wait until template instantiation time.  */
-return build_min_nt (MESSAGE_SEND_EXPR, receiver, sel_name,
-method_params);
+return build_min_nt_loc (UNKNOWN_LOCATON, MESSAGE_SEND_EXPR, receiver,
+sel_name, method_params);
 #endif
 
   return objc_finish_message_expr (receiver, sel_name, method_params, NULL);

Re: PING PATCH: break lines in announce_function

[Mike Stump]

On May 16, 2012, at 6:56 AM, Manuel López-Ibáñez  wrote:
> On 16 May 2012 15:40, Richard Guenther  wrote:
>>> 
>>> Without that patch displaying happen too late (and eats a lot of Emacs 
>>> CPU)!!
>> 
>> 1) Fix emacs (do not buffer stderr)
>> 2) do not omit -quiet when running from inside emacs
> 
> Actually, I wonder how you (Richard) and other GCC hackers work with
> and debug GCC, because it is a real pain in the ass.
> 
> * All the TREE_ macros don't work.
> * __extension__ prevents GDB from evaluating many things.

I posted a solution to this just this week.  If you like it, make someone check 
it in.  The concept of using inline functions in C has already been proposed 
and agreed on in spirit.

> * announce_function dumps slow down Emacs (and the shell when working
> via SSH) when debugging anything related to libstdc++ (or any large
> testcase).

Let's make -quiet the default.  People that want the spew, can ask for it.  I, 
99 times out of 100 don't want it.

Re: PING PATCH: break lines in announce_function

[Gabriel Dos Reis]

On Thu, May 17, 2012 at 10:24 AM, Mike Stump  wrote:

>> * announce_function dumps slow down Emacs (and the shell when working
>> via SSH) when debugging anything related to libstdc++ (or any large
>> testcase).
>
> Let's make -quiet the default.

Agreed.

(I had always reflexively used -quiet so that it wasn't a proble, ofr me.)

-- Gaby

Re: PING PATCH: break lines in announce_function

[Mike Stump]

On May 16, 2012, at 8:57 AM, Manuel López-Ibáñez  wrote:
> I see now that any change in the underlying implementation becomes a
> serious annoyance for you.

No, it is easy, we just need a low cost solution by which people can use the 
normal accessors.  Once that is provided, then I think it is easy to change the 
underlying bits.  Though, it is kinda sad that 20 years later, things are still 
as they were, with no improvement.  I wish the steering committe would find a 
way to allow improvements to be made more easily in this area.  I would have 
checked in my changes to support -g3 debugging if it were easier.  I'll note, 
I'm not the first person to do the work, just the last.

Re: PING PATCH: break lines in announce_function

[Mike Stump]

On May 16, 2012, at 11:44 AM, Tom Tromey  wrote:

>> "Manuel" == Manuel López-Ibáñez  writes:
> 
> Manuel> It seems it will never work for statement expressions:
> Manuel> http://article.gmane.org/gmane.comp.gcc.devel/107339
> 
> It could be done, but it is non-trivial for sure.
> 
> Manuel> I see how these small functions can quickly become annoying. Is it
> Manuel> really that hard to make GDB ignore some functions?
> 
> There's a new "skip" feature in gdb specifically for this.
> It is in gdb 7.4.

Or, you can mark them with an attribute, if you use Darwin, we've had the 
feature for almost a decade.

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue6197069)

[Sterling Augustine]

On Thu, May 10, 2012 at 9:08 AM, Sterling Augustine
 wrote:
> The enclosed patch fixes many issues with pubnames and pubtypes. It generates
> them for many more variables and with mostly correct and canonical dwarf 
> names.
>
> This patch should not affect any target that does not use pubnames.
>
> The exceptions to the canonical names are addressed in a separate patch in
> to the front end under review at 
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00512.html.
>
> Tested with bootstrap and running the test_pubnames_and_indices.py script
> recently contributed to the GDB project.
>
> OK for mainline?
>
> Sterling
>
> 2012-05-10   Sterling Augustine  
>
>        * dwarf2out.c (DEBUG_PUBNAMES_SECTION_LABEL,
>        DEBUG_PUBTYPES_SECTION_LABEL): New macros.
>        (debug_pubnames_section_label, debug_pubtypes_section_label): New
>        globals.
>        (is_cu_die, is_namespace_die, is_class_die, add_AT_pubnames,
>        add_enumerator_pubname): New functions.
>        (add_pubname): Rework logic.  Call is_class_die, is_cu_die and
>        is_namespace_die.  Fix minor style violation.
>        (add_pubtype): Rework logic for calculating type name.  Call
>        is_namespace_die.
>        (output_pubnames): Move conditional logic deciding when to produce the
>        section from dwarf2out_finish.  Output debug_pubnames_section_label
>        and debug_pubtypes_section_label.
>        (base_type_die): Call add_pubtype.
>        (gen_enumeration_type_die): Unconditionally call add_pubtype.
>        (gen_namespace_die): Call add_pubname_string.
>        (dwarf2out_init): Generate debug_pubnames_section_label and
>        debug_pubtypes_section_label from DEBUG_PUBNAMES_SECTION_LABEL and
>        DEBUG_PUBTYPES_SECTION_LABEL respectively.
>        (dwarf2out_finish): Call add_AT_pubnames; Move logic on when to
>        produce pubnames and pubtypes sections to output_pubnames.
>
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c     (revision 187271)
> +++ gcc/dwarf2out.c     (working copy)
> @@ -3007,6 +3007,7 @@ static void output_comp_unit (dw_die_ref, int);
>  static void output_comdat_type_unit (comdat_type_node *);
>  static const char *dwarf2_name (tree, int);
>  static void add_pubname (tree, dw_die_ref);
> +static void add_enumerator_pubname (const char *, dw_die_ref);
>  static void add_pubname_string (const char *, dw_die_ref);
>  static void add_pubtype (tree, dw_die_ref);
>  static void output_pubnames (VEC (pubname_entry,gc) *);
> @@ -3210,6 +3211,12 @@ static void gen_scheduled_generic_parms_dies (void
>  #ifndef COLD_TEXT_SECTION_LABEL
>  #define COLD_TEXT_SECTION_LABEL         "Ltext_cold"
>  #endif
> +#ifndef DEBUG_PUBNAMES_SECTION_LABEL
> +#define DEBUG_PUBNAMES_SECTION_LABEL       "Ldebug_pubnames"
> +#endif
> +#ifndef DEBUG_PUBTYPES_SECTION_LABEL
> +#define DEBUG_PUBTYPES_SECTION_LABEL       "Ldebug_pubtypes"
> +#endif
>  #ifndef DEBUG_LINE_SECTION_LABEL
>  #define DEBUG_LINE_SECTION_LABEL       "Ldebug_line"
>  #endif
> @@ -3246,6 +3253,8 @@ static char cold_end_label[MAX_ARTIFICIAL_LABEL_BY
>  static char abbrev_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
>  static char debug_info_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
>  static char debug_line_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
> +static char debug_pubnames_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
> +static char debug_pubtypes_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
>  static char macinfo_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
>  static char loc_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
>  static char ranges_section_label[2 * MAX_ARTIFICIAL_LABEL_BYTES];
> @@ -5966,6 +5975,22 @@ is_cu_die (dw_die_ref c)
>   return c && c->die_tag == DW_TAG_compile_unit;
>  }
>
> +/* Returns true iff C is a namespace DIE.  */
> +
> +static inline bool
> +is_namespace_die (dw_die_ref c)
> +{
> +  return c && c->die_tag == DW_TAG_namespace;
> +}
> +
> +/* Returns true iff C is a class DIE.  */
> +
> +static inline bool
> +is_class_die (dw_die_ref c)
> +{
> +  return c && c->die_tag == DW_TAG_class_type;
> +}
> +
>  static char *
>  gen_internal_sym (const char *prefix)
>  {
> @@ -8033,6 +8058,20 @@ output_comp_unit (dw_die_ref die, int output_if_em
>     }
>  }
>
> +/* Add the DW_AT_GNU_pubnames and DW_AT_GNU_pubtypes attributes.  */
> +
> +static void
> +add_AT_pubnames (dw_die_ref die)
> +{
> +  if (targetm.want_debug_pub_sections)
> +    {
> +      /* FIXME: Should use add_AT_pubnamesptr.  This works because most 
> targets
> +         don't care what the base section is.  */
> +      add_AT_lineptr (die, DW_AT_GNU_pubnames, debug_pubnames_section_label);
> +      add_AT_lineptr (die, DW_AT_GNU_pubtypes, debug_pubtypes_section_label);
> +    }
> +}
> +
>  /* Output a comdat type unit DIE and its children.  */
>
>  static void
> @@ -8116,14 +8155,32 @@ add_pubname_string (const char *str, dw_die_ref di
>  static void
>  add_pubname (tree decl, dw_die_ref die)

Re: [google/gcc-4_6_3-mobile] Port r187569 from google/gcc-4_6 branch (issue 6210060)

[沈涵]

Hi, ok for approval?

Thanks,
-Han

On Wed, May 16, 2012 at 4:49 PM,   wrote:
> On 2012/05/16 23:30:28, Diego Novillo wrote:
>
>> On 12-05-16 19:22 , mailto:jin...@google.com wrote:
>> > In my opinion, gcc/ChangeLog is for upstream commits only.
>> > It is fine that you want to port upstream gcc/ChangeLog as well.
>
> Just
>>
>> > remove your identities
>> > +2012-05-11 Han Shen 
>>
>> > +
>> > + Backported r187569 from branches/google/gcc-4_6.
>
>
>> The convention for branches is that all the commits to them should get
>
>
>> ChangeLog entries in the file ChangeLog.
>
>
>> where  is generally the basename of the branch URL, though
>
>
>> it is sometimes changed slightly.  In the google branches we use the
>> convention 'google-' for all the branches under google/*
>
>
>
>> Diego.
>
>
> Thanks, Jing and Diego.
>
> Reverted gcc/ChangeLog.
>
> Regards,
> -Han
>
> http://codereview.appspot.com/6210060/



-- 
Han Shen |  Software Engineer |  shen...@google.com |  +1-650-440-3330

Re: [google/gcc-4_6_3-mobile] Port r187569 from google/gcc-4_6 branch (issue 6210060)

[Diego Novillo]

On 12-05-17 12:27 , Han Shen(沈涵) wrote:

Hi, ok for approval?


OK.


Diego.

Symbol table 21/many: analyze initializers of external vars

[Jan Hubicka]

Hi,
C++ virtual tables keyed to other compilation units are represented as 
DECL_EXTERNAL
variables with constructor known. Knowhing the constructor helps constant 
folding to do
devirtualization.

At the moment these costructors are not seen by varpool and thus they are not
represented by ipa-ref and thus WHOPR partitioning is not seeing them and we
later in can_refer_decl_in_current_unit_p try to work out if the partitioning
was done in lucky or unlucky way.

This patch makes external variables to be handled similarly to external 
functions.
That is the variables gets finalized and analyzed by varpool. They go in similar
way to partitioning as comdat functions.

Code removing unreachable nodes treats them as normal variables until after
inlining when vars/funcions referred only by those are considred unreachable.
This also allows us to remove the constructors from memory when we know they
are no longer needed saving couple hundred KB on compiling Mozilla with LTO.

The patch also enables aboud 3000 extra foldings on Mozilla LTO build.
Mostly those are devirtualized calls to libstdc++.

Bootstrapped/regtested x86_64-linux, comitted.
Index: ChangeLog
===
*** ChangeLog   (revision 187630)
--- ChangeLog   (working copy)
***
*** 1,3 
--- 1,26 
+ 2012-05-17  Jan Hubicka  
+ 
+   * lto-symtab.c (lto_symtab_resolve_symbols): Preffer decl with 
constructor
+   over decl without.
+   * cgraph.c (cgraph_remove_node): Clear also body of unanalyzed nodes.
+   * cgraph.h (varpool_can_remove_if_no_refs): Handle external correctly.
+   * cgraphunit.c (process_function_and_variable_attributes): Finalize 
+   extrnal decls.
+   (mark_functions_to_output): Also accept bodies for functions with 
clones.
+   (output_in_order): Skip external vars.
+   * lto-cgraph.c (lto_output_node): External functions are never in other
+   partition.
+   (lto_output_varpool_node): Likewise.
+   * lto-streamer-out.c (lto_write_tree): Always use error_mark_nodes for
+   forgotten initializers.
+   * ipa.c (process_references): Handle external vars.
+   (symtab_remove_unreachable_nodes): Update to handle external vars.
+   (varpool_externally_visible_p): External vars are externally visible.
+   * gimple-fold.c (can_refer_decl_in_current_unit_p): Update.
+   * varpool.c (varpool_remove_node): Remove constructor.
+   (decide_is_variable_needed): Handle externals.
+   (varpool_remove_unreferenced_decls): Likewise.
+ 
  2012-05-17  Manuel López-Ibáñez  
  
* opts.c (common_handle_option): -pedantic-errors enables -Wpedantic.
Index: lto/ChangeLog
===
*** lto/ChangeLog   (revision 187630)
--- lto/ChangeLog   (working copy)
***
*** 1,3 
--- 1,9 
+ 2012-05-17  Jan Hubicka  
+ 
+   * lto-partition.c (add_references_to_partition): Handle external vars.
+   (partition_varpool_node_p): Likewise.
+   (lto_promote_cross_file_statics): Do not promote externals.
+ 
  2012-05-14  Bernd Schmidt  
  
* lto-lang.c (handle_fnspec_attribute): New static function.
Index: lto-symtab.c
===
*** lto-symtab.c(revision 187630)
--- lto-symtab.c(working copy)
*** lto_symtab_resolve_symbols (void **slot)
*** 489,495 
/* From variables that can prevail choose the largest one.  */
if (!prevailing
  || tree_int_cst_lt (DECL_SIZE (prevailing->decl),
! DECL_SIZE (e->decl)))
prevailing = e;
  }
  
--- 489,509 
/* From variables that can prevail choose the largest one.  */
if (!prevailing
  || tree_int_cst_lt (DECL_SIZE (prevailing->decl),
! DECL_SIZE (e->decl))
! /* When variables are equivalent try to chose one that has useful
!DECL_INITIAL.  This makes sense for keyed vtables that are
!DECL_EXTERNAL but initialized.  In units that do not need them
!we replace the initializer by error_mark_node to conserve
!memory.
! 
!We know that the vtable is keyed outside the LTO unit - otherwise
!the keyed instance would prevail.  We still can preserve useful
!info in the initializer.  */
! || (DECL_SIZE (prevailing->decl) == DECL_SIZE (e->decl)
! && (DECL_INITIAL (e->decl)
! && DECL_INITIAL (e->decl) != error_mark_node)
! && (!DECL_INITIAL (prevailing->decl)
! || DECL_INITIAL (prevailing->decl) == error_mark_node)))
prevailing = e;
  }
  
Index: cgraph.c
===
*** cgraph.c(revision 187630)
--- cgraph.c(working copy)
*** cgraph_remove_node (struct cgraph

Re: [google][4.7]Port function reordering via linker plugin from google/gcc-4_6 branch (issue6195099)

[Sriraman Tallam]

Patch committed. I am preparing to send to trunk by splitting this
into multiple patches.

Thanks,
-Sri.

On Wed, May 16, 2012 at 9:23 PM, Xinliang David Li  wrote:
> ok for google-4_7 branch. This should also be pushed to trunk.
>
> Thanks,
>
> David
>
> On Wed, May 16, 2012 at 6:56 PM, Sriraman Tallam  wrote:
>> Patch too large to be attached, rejected by gcc-patches. Please see:
>>
>> http://codereview.appspot.com/download/issue6195099_1.diff
>>
>> Thanks,
>> -Sri.
>>
>> On Wed, May 16, 2012 at 6:52 PM, Sriraman Tallam  wrote:
>>> Hi,
>>>
>>>  This patch ports function reordering support into google/gcc-4_7 branch
>>>  from google/gcc-4_6 branch.  There are 3 parts which are combined:
>>>
>>>  * Adding option -freoder-functions=callgraph.
>>>  * Dumping callgraph profiles in separate sections.
>>>  * The linker plugin itself.
>>>
>>>  Port revisions from google/gcc-4_6
>>>  r177289, r177308, r179104, r179289, r179303, r179404, r182447
>>>
>>>  into google/gcc-4_7
>>>
>>>  adding function reordering support via linker plugin invoked with option
>>>  -freorder-functions=callgraph.
>>>
>>> Patch also can be reviewed here: http://codereview.appspot.com/6195099
>>>
>>> function_reordering_plugin:
>>>
>>>       * config.h.in: Generate.
>>>       * configure: Generate.
>>>       * Makefile.in: New file.
>>>       * configure.ac: New file.
>>>       * callgraph.h: New file.
>>>       * callgraph.c: New file.
>>>       * function_reordering_plugin.c: New file.
>>>       * Makefile.am: Generate.
>>>       * aclocal.m4: Generate.
>>>
>>> gcc:
>>>       * doc/invoke.texi: Document -freorder-functions=*
>>>       * cgraphbuild.c (remove_cgraph_callee_edges): Preserve
>>>       callgraph till pass_final.
>>>       * configure: Regenerate.
>>>       * final.c (dump_cgraph_profiles): New function.
>>>       (rest_of_handle_final): Call dumping of cgraph profiles in
>>>       .gnu.text.callgraph sections.
>>>       * gcc.c (LINK_COMMAND_SPEC): Process -freorder-functions=
>>>       (set_func_reorder_linker_plugin_spec): New function.
>>>       (main): Call function reorder plugin.
>>>       * testsuite/lib/target-supports-dg.exp
>>>       (dg-require-section-exclude): New proc.
>>>       (dg-require-linker-function-reordering-plugin): New proc.
>>>       * testsuite/lib/target-supports.exp
>>>       (check_section_exclude_available): New proc.
>>>       (check_linker_function_reordering_plugin_supported): New proc.
>>>       * testsuite/g++.dg/tree-prof/callgraph-profiles.C: New test.
>>>       * config.in: undef FRPLUGINSONAME
>>>       * opts.c
>>>       * configure.ac (FRPLUGINSONAME): Define
>>>       * common.opt (fcallgraph-profiles-sections): Remove.
>>>       (freorder-functions=): New option.
>>>       * tree-optimize.c (gate_all_optimizations): Mark last cleanup of
>>>       callgraph.
>>>       * config.host: Set function reordering plugin.
>>>       * params.def (PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOLD): Remove.
>>>       (PARAM_GNU_CGRAPH_SECTION_EDGE_THRESHOLD): Add.
>>>
>>> toplevel:
>>>       * Makefile.in: Regenerate.
>>>       * Makefile.def: Build function reordering plugin.
>>>       * configure.ac: Build function reordering plugin.
>>>       * configure: Regenerate.
>>>
>>> Patch attached.
>>>
>>> Thanks,
>>> -Sri.

Re: [RFC] PR 53063 encode group options in .opt files

[Chung-Lin Tang]

On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
>> I'm guessing these changes are the cause of a full C bootstrap
>> > (--disable-build-poststage1-with-cxx) failure I'm seeing on trunk. The
>> > *_handle_option_auto function prototypes are not seen in options.c, and
>> > -Werror -Wmissing-prototypes are in effect (oddly, such strict checking
>> > is not enforced in the default post-stage1 C++ bootstrap)
> Yep, We should add -Wmissing-declarations to the post-stage1 flags,
> which also exists in C. Could you also add that to your patch?
> 

I'm a little unsure of how -Wmissing-declarations vs
-Wmissing-prototypes behave for C? Anyways here's a patch to add
-Wmissing-declarations for C++, keeping C as is.

Joseph, how does this look? It makes the default post-stage1 C++
bootstrap fail similarly without the other options.c Makefile change, so
I guess it works as intended.

I'll commit both changes together once approved.

Thanks,
Chung-Lin

2012-05-18  Chung-Lin Tang  

* configure.ac: Check for -Wmissing-declarations for C++.
* configure: Regenerate.
* Makefile.in (CXX_LOOSE_WARN): Set to @cxx_loose_warn@.
(GCC_WARN_CXXFLAGS): Add $(CXX_LOOSE_WARN).
Index: configure.ac
===
--- configure.ac(revision 187624)
+++ configure.ac(working copy)
@@ -347,6 +347,8 @@ ACX_PROG_CC_WARNING_OPTS(
m4_quote(m4_do([-Wstrict-prototypes -Wmissing-prototypes])),
[c_loose_warn])
 ACX_PROG_CC_WARNING_OPTS(
+   m4_quote(m4_do([-Wmissing-declarations])), [cxx_loose_warn])
+ACX_PROG_CC_WARNING_OPTS(
m4_quote(m4_do([-Wmissing-format-attribute])), [strict_warn])
 ACX_PROG_CC_WARNING_OPTS(
m4_quote(m4_do([-Wold-style-definition -Wc++-compat])), [c_strict_warn])
Index: Makefile.in
===
--- Makefile.in (revision 187624)
+++ Makefile.in (working copy)
@@ -157,6 +157,7 @@ coverageexts = .{gcda,gcno}
 # C_STRICT_WARN is similar, with C-only warnings.
 LOOSE_WARN = @loose_warn@
 C_LOOSE_WARN = @c_loose_warn@
+CXX_LOOSE_WARN = @cxx_loose_warn@
 STRICT_WARN = @strict_warn@
 C_STRICT_WARN = @c_strict_warn@
 
@@ -188,7 +189,7 @@ VALGRIND_DRIVER_DEFINES = @valgrind_path_defines@
 .-warn = $(STRICT_WARN)
 build-warn = $(STRICT_WARN)
 GCC_WARN_CFLAGS = $(LOOSE_WARN) $(C_LOOSE_WARN) $($(@D)-warn) $(if 
$(filter-out $(STRICT_WARN),$($(@D)-warn)),,$(C_STRICT_WARN)) $(NOCOMMON_FLAG) 
$($@-warn)
-GCC_WARN_CXXFLAGS = $(LOOSE_WARN) $($(@D)-warn) $(NOCOMMON_FLAG) $($@-warn)
+GCC_WARN_CXXFLAGS = $(LOOSE_WARN) $(CXX_LOOSE_WARN) $($(@D)-warn) 
$(NOCOMMON_FLAG) $($@-warn)
 
 # These files are to have specific diagnostics suppressed, or are not to
 # be subject to -Werror:

Re: [RFC] PR 53063 encode group options in .opt files

[Gabriel Dos Reis]

On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
 wrote:
> On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
>>> I'm guessing these changes are the cause of a full C bootstrap
>>> > (--disable-build-poststage1-with-cxx) failure I'm seeing on trunk. The
>>> > *_handle_option_auto function prototypes are not seen in options.c, and
>>> > -Werror -Wmissing-prototypes are in effect (oddly, such strict checking
>>> > is not enforced in the default post-stage1 C++ bootstrap)
>> Yep, We should add -Wmissing-declarations to the post-stage1 flags,
>> which also exists in C. Could you also add that to your patch?
>>
>
> I'm a little unsure of how -Wmissing-declarations vs
> -Wmissing-prototypes behave for C? Anyways here's a patch to add
> -Wmissing-declarations for C++, keeping C as is.

What is the purpose of  -Wmissing-declarations for C++?

>
> Joseph, how does this look? It makes the default post-stage1 C++
> bootstrap fail similarly without the other options.c Makefile change, so
> I guess it works as intended.
>
> I'll commit both changes together once approved.
>
> Thanks,
> Chung-Lin
>
> 2012-05-18  Chung-Lin Tang  
>
> * configure.ac: Check for -Wmissing-declarations for C++.
> * configure: Regenerate.
> * Makefile.in (CXX_LOOSE_WARN): Set to @cxx_loose_warn@.
> (GCC_WARN_CXXFLAGS): Add $(CXX_LOOSE_WARN).

Re: [RFC] PR 53063 encode group options in .opt files

[Manuel López-Ibáñez]

On 17 May 2012 19:25, Gabriel Dos Reis  wrote:
> On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
>  wrote:
>> On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
 I'm guessing these changes are the cause of a full C bootstrap
 > (--disable-build-poststage1-with-cxx) failure I'm seeing on trunk. The
 > *_handle_option_auto function prototypes are not seen in options.c, and
 > -Werror -Wmissing-prototypes are in effect (oddly, such strict checking
 > is not enforced in the default post-stage1 C++ bootstrap)
>>> Yep, We should add -Wmissing-declarations to the post-stage1 flags,
>>> which also exists in C. Could you also add that to your patch?
>>>
>>
>> I'm a little unsure of how -Wmissing-declarations vs
>> -Wmissing-prototypes behave for C? Anyways here's a patch to add
>> -Wmissing-declarations for C++, keeping C as is.
>
> What is the purpose of  -Wmissing-declarations for C++?

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

Cheers,

Manuel.

Re: [RFC] PR 53063 encode group options in .opt files

[Gabriel Dos Reis]

On Thu, May 17, 2012 at 12:28 PM, Manuel López-Ibáñez
 wrote:
> On 17 May 2012 19:25, Gabriel Dos Reis  wrote:
>> On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
>>  wrote:
>>> On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
> I'm guessing these changes are the cause of a full C bootstrap
> > (--disable-build-poststage1-with-cxx) failure I'm seeing on trunk. The
> > *_handle_option_auto function prototypes are not seen in options.c, and
> > -Werror -Wmissing-prototypes are in effect (oddly, such strict checking
> > is not enforced in the default post-stage1 C++ bootstrap)
 Yep, We should add -Wmissing-declarations to the post-stage1 flags,
 which also exists in C. Could you also add that to your patch?

>>>
>>> I'm a little unsure of how -Wmissing-declarations vs
>>> -Wmissing-prototypes behave for C? Anyways here's a patch to add
>>> -Wmissing-declarations for C++, keeping C as is.
>>
>> What is the purpose of  -Wmissing-declarations for C++?
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134

The point is: it is mostly useless for C++.  The rationale for its
existence in C are largely irrelevant in the context of C++.

-- Gaby

Re: [RFC] PR 53063 encode group options in .opt files

[Gabriel Dos Reis]

On Thu, May 17, 2012 at 12:41 PM, Gabriel Dos Reis
 wrote:
> On Thu, May 17, 2012 at 12:28 PM, Manuel López-Ibáñez
>  wrote:
>> On 17 May 2012 19:25, Gabriel Dos Reis  wrote:
>>> On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
>>>  wrote:
 On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
>> I'm guessing these changes are the cause of a full C bootstrap
>> > (--disable-build-poststage1-with-cxx) failure I'm seeing on trunk. The
>> > *_handle_option_auto function prototypes are not seen in options.c, and
>> > -Werror -Wmissing-prototypes are in effect (oddly, such strict checking
>> > is not enforced in the default post-stage1 C++ bootstrap)
> Yep, We should add -Wmissing-declarations to the post-stage1 flags,
> which also exists in C. Could you also add that to your patch?
>

 I'm a little unsure of how -Wmissing-declarations vs
 -Wmissing-prototypes behave for C? Anyways here's a patch to add
 -Wmissing-declarations for C++, keeping C as is.
>>>
>>> What is the purpose of  -Wmissing-declarations for C++?
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
>
> The point is: it is mostly useless for C++.  The rationale for its
> existence in C are largely irrelevant in the context of C++.

Let me add that the notion of "global function defined in header" is
largely meaningless in C++.  I fear this is one of those cases where
we are trying too hard to push a C style to C++.  We should not.

The notion of "global function in C++" can only be interpreted as
meaning a function with external linkage -- because C++ has namespace
and C does not, and a there is no reason to treat the global scope differently.
 Furthermore, C++98 and C++03 requires that functions
used in certain contexts have external linkage.  For GCC's own source code,
we would refrain from anonymous namespaces because they might interfer with
bootstrap compare and reproducibility.  That means we are left with
having to declare
those functions right before their definitions, not but in headers;
that is just plain silly.

-- Gaby

Re: [RFC, 4.8] Magic matching for flags clobbering and setting

[Steven Bosscher]

On Sat, Feb 11, 2012 at 1:12 AM, Richard Henderson  wrote:
> Seeing as how Uros is starting to go down the path of cleaning up the
> flags handling for x86, I thought I'd go ahead and knock up the idea
> that I've been tossing around to help automate the process of building
> patterns that match both clobbering the flags and setting the flags to
> a comparison.
>
> This is far from complete, but it at least shows the direction.
>
> What I know is missing off the top of my head are:
>
>  (0) Documentation in some .texi file; atm there's only what's in rtl.def.
>
>  (1) Generate (clobber (reg flags)) from genemit, should this construct
>     be used in a named insn pattern.
>
>  (2) Can't be usefully used with define_insn_and_split, and no way to tell.
>     This problem should simply be documented in the .texi file as user error.
>
>  (3) Can't be used for x86 add patterns, as the "clobber" version wants the
>     freedom to use "lea" and the "set flags" version cannot.  And there are
>     different sets of constraints if lea may be used or not.
>
>     What would be nice, however, is exposing the targetm.cc_modes_compatible
>     thing in such a way that the x86 add patterns could use that, for the
>     separate insn that does do the set flags.
>
>     Exposing the targetm.cc_modes_compatible thing separately might also
>     clean up some of the evil magic in genrecog.c too.
>
> Comments?


Hello Richard,

Are you still working on this for GCC 4.8?

Ciao!
Steven

Re: [RFC, 4.8] Magic matching for flags clobbering and setting

[Richard Henderson]

On 05/17/12 10:59, Steven Bosscher wrote:
> Are you still working on this for GCC 4.8?

Not actively.


r~

Re: [RFA] leb128.h: New file.

[Doug Evans]

Hi.

This is a slightly modified version of my previous patch.

ref: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00962.html

The only change is to make the result of the functions an int
instead of a const pointer.
This lets them be used in places where the code is using
non-const pointers without having to apply ugly casts.

Ok to check in?

2012-05-17  Doug Evans  

* leb128.h: New file.

Index: leb128.h
===
RCS file: leb128.h
diff -N leb128.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ leb128.h17 May 2012 18:23:29 -
@@ -0,0 +1,130 @@
+/* Utilities for reading leb128 values.
+   Copyright (C) 2012 Free Software Foundation, Inc.
+
+This file is part of the libiberty library.
+Libiberty is free software; you can redistribute it and/or
+modify it under the terms of the GNU Library General Public
+License as published by the Free Software Foundation; either
+version 2 of the License, or (at your option) any later version.
+
+Libiberty is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Library General Public License for more details.
+
+You should have received a copy of the GNU Library General Public
+License along with libiberty; see the file COPYING.LIB.  If not, write
+to the Free Software Foundation, Inc., 51 Franklin Street - Fifth Floor,
+Boston, MA 02110-1301, USA.  */
+
+/* The functions defined here can be speed critical.
+   Since they are all pretty small we keep things simple and just define
+   them all as "static inline".  */
+
+#ifndef LEB128_H
+#define LEB128_H
+
+#include "ansidecl.h"
+
+/* Get a definition for NULL.  */
+#include 
+
+#ifdef HAVE_STDINT_H
+#include 
+#endif
+#ifdef HAVE_INTTYPES_H
+#include 
+#endif
+
+/* Decode the unsigned LEB128 constant at BUF into the variable pointed to
+   by R, and return the number of bytes read.
+   If we read off the end of the buffer, zero is returned,
+   and nothing is stored in R.
+
+   Note: The result is an int instead of a pointer to the next byte to be
+   read to avoid const-vs-non-const problems.  */
+
+static inline int
+read_uleb128 (const unsigned char *buf, const unsigned char *buf_end,
+ uint64_t *r)
+{
+  const unsigned char *p = buf;
+  unsigned int shift = 0;
+  uint64_t result = 0;
+  unsigned char byte;
+
+  while (1)
+{
+  if (p >= buf_end)
+   return 0;
+
+  byte = *p++;
+  result |= ((uint64_t) (byte & 0x7f)) << shift;
+  if ((byte & 0x80) == 0)
+   break;
+  shift += 7;
+}
+
+  *r = result;
+  return p - buf;
+}
+
+/* Decode the signed LEB128 constant at BUF into the variable pointed to
+   by R, and return the number of bytes read.
+   If we read off the end of the buffer, zero is returned,
+   and nothing is stored in R.
+
+   Note: The result is an int instead of a pointer to the next byte to be
+   read to avoid const-vs-non-const problems.  */
+
+static inline int
+read_sleb128 (const unsigned char *buf, const unsigned char *buf_end,
+ int64_t *r)
+{
+  const unsigned char *p = buf;
+  unsigned int shift = 0;
+  int64_t result = 0;
+  unsigned char byte;
+
+  while (1)
+{
+  if (p >= buf_end)
+   return 0;
+
+  byte = *p++;
+  result |= ((uint64_t) (byte & 0x7f)) << shift;
+  shift += 7;
+  if ((byte & 0x80) == 0)
+   break;
+}
+  if (shift < (sizeof (*r) * 8) && (byte & 0x40) != 0)
+result |= -(((uint64_t) 1) << shift);
+
+  *r = result;
+  return p - buf;
+}
+
+/* Return the number of bytes to read to skip past an LEB128 number in BUF.
+   If the end isn't found before reaching BUF_END, return zero.
+
+   Note: The result is an int instead of a pointer to the next byte to be
+   read to avoid const-vs-non-const problems.  */
+
+static inline int
+skip_leb128 (const unsigned char *buf, const unsigned char *buf_end)
+{
+  const unsigned char *p = buf;
+  unsigned char byte;
+
+  while (1)
+{
+  if (p == buf_end)
+   return 0;
+
+  byte = *p++;
+  if ((byte & 128) == 0)
+   return p - buf;
+}
+}
+
+#endif /* LEB128_H */

Re: [PATCH] Fix bessel_7.f90 failures on sparc-*-linux-gnu

[Steven Bosscher]

On Thu, May 17, 2012 at 1:56 AM, David Miller  wrote:
>
> I've noticed this failure for some time but never got around to
> inspecting things.  The X=34.53 case seem to need a precision
> allowance bump.
>
> Ok for mainline and 4.7 branch?

OK.

Ciao!
Steven

Re: Turn check macros into functions. (issue6188088)

[Diego Novillo]

On 12-05-17 10:52 , Michael Matz wrote:


Cross the bridge when you reach it, not before.  Not everybody agrees that
the splitting of tree would be a good idea.  Right now templates aren't
necessary, so you shouldn't use them.  (well, and an investigation why
they come up with smaller .text would be in order anyway).


I've been playing around with this patch a little bit.  The main 
motivation for using templates here is to preserve the existing 
semantics.  Note that the return type from the function mimics the type 
of the argument passed in.  So, if the user passes a const_tree, the 
function returns a const_tree.


The way to do this in C++ is to: (a) use templates (as in Lawrence's 
patch), or (b) produce overloaded variants for tree and const_tree.


For trunk, we have a third option: (c) make these functions out-of-line 
functions that take const_tree and return tree.  This slightly weakens 
the semantics of the checks, but it does not rely on C++ features.


Options (a) or (b) are the same to me.  Option (b) has the slight 
advantage that the code can be taken out of tree.h and buried in tree.c.


The attached patch implements option (c).  Should we consider this for 
trunk now and then just replace the CONST_CAST_TREE into C++ overloads?



Thanks.  Diego.


2012-05-17  Lawrence Crowl  

* tree.h (tree_check): Declare.
(TREE_CHECK): Use function above instead of __extension__.
(tree_not_check): Declare.
(TREE_NOT_CHECK): Use function above instead of __extension__.
(tree_check2): Declare.
(TREE_CHECK2): Use function above instead of __extension__.
(tree_not_check2): Declare.
(TREE_NOT_CHECK2): Use function above instead of __extension__.
(tree_check3): Declare.
(TREE_CHECK3): Use function above instead of __extension__.
(tree_not_check3): Declare.
(TREE_NOT_CHECK3): Use function above instead of __extension__.
(tree_check4): Declare.
(TREE_CHECK4): Use function above instead of __extension__.
(tree_not_check4): Declare.
(TREE_NOT_CHECK4): Use function above instead of __extension__.
(tree_check5): Declare.
(TREE_CHECK5): Use function above instead of __extension__.
(tree_not_check5): Declare.
(TREE_NOT_CHECK5): Use function above instead of __extension__.
(contains_struct_check): Declare.
(CONTAINS_STRUCT_CHECK): Use function above instead of
__extension__.
(tree_class_check): Declare.
(TREE_CLASS_CHECK): Use function above instead of __extension__.
(tree_range_check): Declare.
(TREE_RANGE_CHECK): Use function above instead of __extension__.
(omp_clause_subcode_check): Declare.
(OMP_CLAUSE_SUBCODE_CHECK): Use function above instead of
__extension__.
(omp_clause_range_check): Declare.
(OMP_CLAUSE_RANGE_CHECK): Use function above instead of
__extension__.
(expr_check): Declare.
(EXPR_CHECK): Use function above instead of __extension__.
(non_type_check): Declare.
(NON_TYPE_CHECK): Use function above instead of __extension__.
(tree_vec_elt_check): Declare.
(TREE_VEC_ELT_CHECK): Use function above instead of
__extension__.
(omp_clause_elt_check): Declare.
(OMP_CLAUSE_ELT_CHECK): Use function above instead of
__extension__.
(tree_operand_check): Declare.
(TREE_OPERAND_CHECK): Use function above instead of
__extension__.
(tree_operand_check_code): Declare.
(TREE_OPERAND_CHECK_CODE): Use function above instead of
__extension__.
(TREE_CHAIN): Simplify implementation.
(TREE_TYPE): Simplify implementation.
(tree_operand_length): Move for compilation dependences.
* tree.c (tree_check): New.
(tree_not_check): New.
(tree_check2): New.
(tree_not_check2): New.
(tree_check3): New.
(tree_not_check3): New.
(tree_check4): New.
(tree_not_check4): New.
(tree_check5): New.
(tree_not_check5): New.
(contains_struct_check): New.
(tree_range_check): New.
(omp_clause_subcode_check): New.
(omp_clause_range_check): New.
(expr_check): New.
(non_type_check): New.
(tree_vec_elt_check): New.
(omp_clause_elt_check): New.
(tree_operand_check): New.
(tree_operand_check_code): New.
* gdbinit.in: (macro define __FILE__): New.
(macro define __LINE__): New.
(skip "tree.h"): New.
2012-05-17  Lawrence Crowl  

* tree.h (tree_check): Declare.
(TREE_CHECK): Use function above instead of __extension__.
(tree_not_check): Declare.
(TREE_NOT_CHECK): Use function above instead of __extension__.
(tree_check2): Declare.
(TREE_CHECK2): Use function above instead of __extension__.
(tree_not_check2): Decla

Re: [RFC] PR 53063 encode group options in .opt files

[Joseph S. Myers]

On Fri, 18 May 2012, Chung-Lin Tang wrote:

> Joseph, how does this look? It makes the default post-stage1 C++
> bootstrap fail similarly without the other options.c Makefile change, so
> I guess it works as intended.

For build system patches you ought to be asking the build system 
maintainers for their views, rather than me.

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

Re: [C++ Patch] PR 44516

[Jason Merrill]

On 05/17/2012 05:06 AM, Paolo Carlini wrote:

On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:

I am still puzzled by why we need to assert, as opposed to just
ignore, unless we have a plan to make a wholesale move -- but even there I am 
bit
nervous.

Eh, don't ask me ;) Anyway, in terms of testing that we aren't screwing
up anything in the C++ front-end, the testsuite just passed with the
below p3 attached. That's good.


Yep, that's what the assert is for: testing that we aren't screwing up 
anything in the C++ front end.  If it fires, it lets us know there's 
something still to fix.  Sounds like it looks good so far.


Jason

Re: [C++ Patch] PR 44516

[Paolo Carlini]

On 05/17/2012 09:47 PM, Jason Merrill wrote:

On 05/17/2012 05:06 AM, Paolo Carlini wrote:

On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:

I am still puzzled by why we need to assert, as opposed to just
ignore, unless we have a plan to make a wholesale move -- but even 
there I am bit

nervous.

Eh, don't ask me ;) Anyway, in terms of testing that we aren't screwing
up anything in the C++ front-end, the testsuite just passed with the
below p3 attached. That's good.


Yep, that's what the assert is for: testing that we aren't screwing up 
anything in the C++ front end.  If it fires, it lets us know there's 
something still to fix.  Sounds like it looks good so far.
If you like, I can install p3 now, but I think it would be a pity if we 
can't have the warning_at bit because of that lone use in the ocbj 
front-end of an explicit 'warning_at (0' (in objc-gnu-runtime-abi-01.c). 
Maybe Mike has something to suggest?


Paolo.

Re: [PATCH] PR rtl-optimization/53352

[Richard Sandiford]

Steven Bosscher  writes:
> On Thu, May 17, 2012, Meador Inge  wrote:
>>> ;; This is *not* equal to zero because the upper
>>> ;; two bytes are undefined.
>>> (insn 14 13 15 2 (set (reg:SI 142)
>>>         (subreg:SI (reg:QI 141) 0))
>>>      (expr_list:REG_EQUAL (const_int 0 [0])
>>>         (nil)))
>
> Hmm, this is what doc/rtl.texi has to say about paradoxical subregs as 
> rvalues:
>
> The high-order bits of rvalues are in the following circumstances:
>
> * subreg regs
> The upper bits are defined when SUBREG_PROMOTED_VAR_P is true.
> SUBREG_PROMOTED_UNSIGNED_P describes what the upper bits hold.
>
> The way I read this, suggests your patch allow simplify_subreg on
> paradoxical subregs if SUBREG_PROMOTED_VAR_P is true. But I'm not
> exactly an RTL expert, and I'm not 100% sure if this part of doc
> applies here. ;-)

Yeah, I think that's just for non-paradoxical lowpart subregs.
I.e. for (subreg:M (reg:N ...)), it's making a guarantee about
the bits that are in N but not in M.

After agonising over this for a couple of days, I think it's probably
the correct fix.  What we're doing now would be valid if the only use of
equiv_constant(x) were to substitute for x.  The name and current use
of the function obviously require equality though.

Patch is OK, thanks.  It might be worth extending fold_rtx and
equiv_constant to set a flag that says whether the returned value
is equivalent or simply one of many valid replacement values.
We'd then be able to replace uses of registers like 142 with 0,
while not replacing uses of 0 with 142.  I don't know how much it
would buy us though.  That kind of thing is probably more of a job
for fwprop.

Please add UL to the hex constants in the testcase.  Not sure whether
it matters for 16-bit int targets or not, but better safe than sorry :-)

Also, rather than:

> +  /* Otherwise see if we already have a constant for the inner REG.
> +  Don't bother with paradoxical subregs because we have no way
> +  of knowing what the upper bytes are.  */

how about:

  /* Otherwise see if we already have a constant for the inner REG,
 and if that is enough to calculate an equivalent constant for
 the subreg.  Note that the upper bits of paradoxical subregs
 are undefined, so they cannot be said to equal anything.  */

Richard

Re: [C++ Patch] PR 44516

[Mike Stump]

On May 17, 2012, at 12:53 PM, Paolo Carlini wrote:
> On 05/17/2012 09:47 PM, Jason Merrill wrote:
>> On 05/17/2012 05:06 AM, Paolo Carlini wrote:
>>> On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
 I am still puzzled by why we need to assert, as opposed to just
 ignore, unless we have a plan to make a wholesale move -- but even there I 
 am bit
 nervous.
>>> Eh, don't ask me ;) Anyway, in terms of testing that we aren't screwing
>>> up anything in the C++ front-end, the testsuite just passed with the
>>> below p3 attached. That's good.
>> 
>> Yep, that's what the assert is for: testing that we aren't screwing up 
>> anything in the C++ front end.  If it fires, it lets us know there's 
>> something still to fix.  Sounds like it looks good so far.
> If you like, I can install p3 now, but I think it would be a pity if we can't 
> have the warning_at bit because of that lone use in the ocbj front-end of an 
> explicit 'warning_at (0' (in objc-gnu-runtime-abi-01.c). Maybe Mike has 
> something to suggest?

Gosh, I'm not wedded to even having that warning.  :-)  The compiler knows what 
it has to do for codegen, it can eat and ignore the flag silently for all I 
care.  I'd ask Nicola or Iain if they have any thoughts.

One could also reasonably use:

  inform (UNKNOWN_LOCATION, "");

for it, if that helps.

Re: [C++ Patch] PR 44516

[Iain Sandoe]

On 17 May 2012, at 21:16, Mike Stump wrote:


On May 17, 2012, at 12:53 PM, Paolo Carlini wrote:

On 05/17/2012 09:47 PM, Jason Merrill wrote:

On 05/17/2012 05:06 AM, Paolo Carlini wrote:

On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:

I am still puzzled by why we need to assert, as opposed to just
ignore, unless we have a plan to make a wholesale move -- but  
even there I am bit

nervous.
Eh, don't ask me ;) Anyway, in terms of testing that we aren't  
screwing
up anything in the C++ front-end, the testsuite just passed with  
the

below p3 attached. That's good.


Yep, that's what the assert is for: testing that we aren't  
screwing up anything in the C++ front end.  If it fires, it lets  
us know there's something still to fix.  Sounds like it looks good  
so far.
If you like, I can install p3 now, but I think it would be a pity  
if we can't have the warning_at bit because of that lone use in the  
ocbj front-end of an explicit 'warning_at (0' (in objc-gnu-runtime- 
abi-01.c). Maybe Mike has something to suggest?


Gosh, I'm not wedded to even having that warning.  :-)  The compiler  
knows what it has to do for codegen, it can eat and ignore the flag  
silently for all I care.  I'd ask Nicola or Iain if they have any  
thoughts.


One could also reasonably use:

 inform (UNKNOWN_LOCATION, "");

for it, if that helps.


For my part, I'd prefer inform (UNKNOWN_LOCATION  as is used below ..  
and, hopefully everywhere else, where new stuff has been introduced.


it's probable that the warning_at (0,0  was a remnant of the pre-split  
code (but I don't 100% remember w/out checking logs).


I doubt it would be a huge burden to change any test-cases that depend  
on it.

Re: [PATCH] PR rtl-optimization/53352

[Meador Inge]

On 05/17/2012 03:02 PM, Richard Sandiford wrote:

> After agonising over this for a couple of days, I think it's probably
> the correct fix.  What we're doing now would be valid if the only use of
> equiv_constant(x) were to substitute for x.  The name and current use
> of the function obviously require equality though.
> 
> Patch is OK, thanks.  It might be worth extending fold_rtx and
> equiv_constant to set a flag that says whether the returned value
> is equivalent or simply one of many valid replacement values.
> We'd then be able to replace uses of registers like 142 with 0,
> while not replacing uses of 0 with 142.  I don't know how much it
> would buy us though.  That kind of thing is probably more of a job
> for fwprop.

Thanks for the review.

> Please add UL to the hex constants in the testcase.  Not sure whether
> it matters for 16-bit int targets or not, but better safe than sorry :-)

Fixed.

> Also, rather than:
> 
>> +  /* Otherwise see if we already have a constant for the inner REG.
>> + Don't bother with paradoxical subregs because we have no way
>> + of knowing what the upper bytes are.  */
> 
> how about:
> 
>   /* Otherwise see if we already have a constant for the inner REG,
>and if that is enough to calculate an equivalent constant for
>the subreg.  Note that the upper bits of paradoxical subregs
>are undefined, so they cannot be said to equal anything.  */

Sounds good to me.

v2 OK?  If so, would you mind committing for me?  I don't have write access.


-- 
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
Index: testsuite/gcc.dg/pr53352.c
===
--- testsuite/gcc.dg/pr53352.c	(revision 0)
+++ testsuite/gcc.dg/pr53352.c	(revision 0)
@@ -0,0 +1,41 @@
+/* { dg-do run } */
+/* { dg-options "-O1" } */
+
+#include 
+
+typedef union
+{
+  struct
+  {
+unsigned char a;
+unsigned char b;
+unsigned char c;
+unsigned char d;
+  } parts;
+  unsigned long whole;
+} T;
+
+T *g_t;
+
+void bar (unsigned long x)
+{
+  if (x != 0)
+abort ();
+}
+
+int main ()
+{
+  T one;
+  T two;
+  T tmp1, tmp2;
+
+  one.whole = 0xFFE0E0E0UL;
+  two.whole = 0xFF00UL;
+  tmp1.parts = two.parts;
+  tmp2.parts = one.parts;
+  tmp2.parts.c = tmp1.parts.c;
+  one.parts = tmp2.parts;
+
+  g_t = &one;
+  bar (0);
+}
Index: cse.c
===
--- cse.c	(revision 187470)
+++ cse.c	(working copy)
@@ -3786,8 +3786,12 @@ equiv_constant (rtx x)
 	}
 	}
 
-  /* Otherwise see if we already have a constant for the inner REG.  */
+  /* Otherwise see if we already have a constant for the inner REG,
+	 and if that is enough to calculate an equivalent constant for
+	 the subreg.  Note that the upper bits of paradoxical subregs
+	 are undefined, so they cannot be said to equal anything.  */
   if (REG_P (SUBREG_REG (x))
+	  && (GET_MODE_SIZE (mode) <= GET_MODE_SIZE (imode))
 	  && (new_rtx = equiv_constant (SUBREG_REG (x))) != 0)
 return simplify_subreg (mode, new_rtx, imode, SUBREG_BYTE (x));
 

Re: Turn check macros into functions. (issue6188088)

[Tom Tromey]

> "Lawrence" == Lawrence Crowl  writes:

Tom> Doesn't this mean that if you have checking enabled, and you use the
Tom> wrong macro on some tree, cc1 will crash?  That seems like a distinct
Tom> minus to me.

Lawrence> Yes, it does mean that, but it is a net overall improvement.

It is a net debugging improvement compared to trunk, but not compared to
using 'macro define's.

It would be nice if there were a way to make cc1 not crash due to user
error in the debugger.  I think this kind of crash will be especially
crazy-making.

Lawrence> These extensions are not on gdb's list of things to implement.

As a digression - I guess they could be.

Reusing the compiler for this seems like the only way to go.  But, we
did look at using g++ to parse C++ expressions from gdb, and it was too
slow :-(.  We're going to look again, at least to generate some bug
reports if we can.

Tom

Re: rfa: vectorize strided loads [2/2] [PR 18437]

[H.J. Lu]

On Sat, Apr 21, 2012 at 11:19 AM, H.J. Lu  wrote:
> On Sat, Apr 21, 2012 at 11:11 AM, H.J. Lu  wrote:
>> On Tue, Apr 10, 2012 at 6:46 AM, Michael Matz  wrote:
>>> Hi,
>>>
>>
>>> Michael.
>>>
>>>        PR tree-optimization/18437
>>>
>>>        * tree-vectorizer.h (_stmt_vec_info.stride_load_p): New member.
>>>        (STMT_VINFO_STRIDE_LOAD_P): New accessor.
>>>        (vect_check_strided_load): Declare.
>>>        * tree-vect-data-refs.c (vect_check_strided_load): New function.
>>>        (vect_analyze_data_refs): Use it to accept strided loads.
>>>        * tree-vect-stmts.c (vectorizable_load): Ditto and handle them.
>>>
>>
>> This caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062
>>
>
> It also caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53048
>

It also caused:

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

-- 
H.J.

Re: Turn check macros into functions. (issue6188088)

[Andrew Pinski]

On Thu, May 17, 2012 at 1:53 PM, Tom Tromey  wrote:
>> "Lawrence" == Lawrence Crowl  writes:
>
> Tom> Doesn't this mean that if you have checking enabled, and you use the
> Tom> wrong macro on some tree, cc1 will crash?  That seems like a distinct
> Tom> minus to me.
>
> Lawrence> Yes, it does mean that, but it is a net overall improvement.
>
> It is a net debugging improvement compared to trunk, but not compared to
> using 'macro define's.
>
> It would be nice if there were a way to make cc1 not crash due to user
> error in the debugger.  I think this kind of crash will be especially
> crazy-making.

Then maybe someone should write some python scripts to do the
extractions so that the debugger will not crash.
Note I don't have enough experience with python or python scripting in
gdb to do that.

Thanks,
Andrew

>
> Lawrence> These extensions are not on gdb's list of things to implement.
>
> As a digression - I guess they could be.
>
> Reusing the compiler for this seems like the only way to go.  But, we
> did look at using g++ to parse C++ expressions from gdb, and it was too
> slow :-(.  We're going to look again, at least to generate some bug
> reports if we can.
>
> Tom

Re: Turn check macros into functions. (issue6188088)

[Lawrence Crowl]

On 5/17/12, Tom Tromey  wrote:
> > "Lawrence" == Lawrence Crowl  writes:
>
> Tom> Doesn't this mean that if you have checking enabled, and you use
> Tom> the wrong macro on some tree, cc1 will crash?  That seems like
> Tom> a distinct minus to me.
>
> Lawrence> Yes, it does mean that, but it is a net overall improvement.
>
> It is a net debugging improvement compared to trunk, but not
> compared to using 'macro define's.

If you know about them and your debuggers supports them.  It was
two years before I learned about those macros.  By moving the
source closer to standard code, we reduce the frustration for
new developers.  I was particularly frustrated by this problem.

> It would be nice if there were a way to make cc1 not crash due
> to user error in the debugger.  I think this kind of crash will
> be especially crazy-making.

Agreed.  Intercept abort in gdb?

> Lawrence> These extensions are not on gdb's list of things to
> Lawrence> implement.
>
> As a digression - I guess they could be.

That would certainly help in several when using gdb.  It would not
help if someone needs or wants to use a different debugger.

> Reusing the compiler for this seems like the only way to go.
> But, we did look at using g++ to parse C++ expressions from gdb,
> and it was too slow :-(.  We're going to look again, at least to
> generate some bug reports if we can.

It's a tough problem, particularly as C/C++ and their compilers
were not designed for a read-eval-print-loop environment.

-- 
Lawrence Crowl

[PATCH] Simplify attempt_builtin_powi logic

[William J. Schmidt]

This patch gives up on using the reassociation rank algorithm to
correctly place __builtin_powi calls and their feeding multiplies.  In
the end this proved to introduce more complexity than it saved, due in
part to the poor fit of introducing DAG expressions into the
reassociated operand tree.  This patch returns to generating explicit
multiplies to bind the builtin calls together and to the results of the
expression tree rewrite.  I feel this version is smaller, easier to
understand, and less fragile than the existing code.

Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
regressions.  Ok for trunk?

Thanks,
Bill


2012-05-17  Bill Schmidt  

* tree-ssa-reassoc.c (bip_map): Remove decl.
(completely_remove_stmt): Remove function.
(remove_def_if_absorbed_call): Remove function.
(remove_visited_stmt_chain): Remove __builtin_powi handling.
(possibly_move_powi): Remove function.
(rewrite_expr_tree): Remove calls to possibly_move_powi.
(rewrite_expr_tree_parallel): Likewise.
(attempt_builtin_powi): Build multiplies explicitly rather than
relying on the ops vector and rank system.
(transform_stmt_to_copy): New function.
(transform_stmt_to_multiply): Likewise.
(reassociate_bb): Handle leftover operations after __builtin_powi
optimization; build a final multiply if necessary.


Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c  (revision 187626)
+++ gcc/tree-ssa-reassoc.c  (working copy)
@@ -200,10 +200,6 @@ static long *bb_rank;
 /* Operand->rank hashtable.  */
 static struct pointer_map_t *operand_rank;
 
-/* Map from inserted __builtin_powi calls to multiply chains that
-   feed them.  */
-static struct pointer_map_t *bip_map;
-
 /* Forward decls.  */
 static long get_rank (tree);
 
@@ -2184,32 +2180,6 @@ is_phi_for_stmt (gimple stmt, tree operand)
   return false;
 }
 
-/* Remove STMT, unlink its virtual defs, and release its SSA defs.  */
-
-static inline void
-completely_remove_stmt (gimple stmt)
-{
-  gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
-  gsi_remove (&gsi, true);
-  unlink_stmt_vdef (stmt);
-  release_defs (stmt);
-}
-
-/* If OP is defined by a builtin call that has been absorbed by
-   reassociation, remove its defining statement completely.  */
-
-static inline void
-remove_def_if_absorbed_call (tree op)
-{
-  gimple stmt;
-
-  if (TREE_CODE (op) == SSA_NAME
-  && has_zero_uses (op)
-  && is_gimple_call ((stmt = SSA_NAME_DEF_STMT (op)))
-  && gimple_visited_p (stmt))
-completely_remove_stmt (stmt);
-}
-
 /* Remove def stmt of VAR if VAR has zero uses and recurse
on rhs1 operand if so.  */
 
@@ -2218,7 +2188,6 @@ remove_visited_stmt_chain (tree var)
 {
   gimple stmt;
   gimple_stmt_iterator gsi;
-  tree var2;
 
   while (1)
 {
@@ -2228,95 +2197,15 @@ remove_visited_stmt_chain (tree var)
   if (is_gimple_assign (stmt) && gimple_visited_p (stmt))
{
  var = gimple_assign_rhs1 (stmt);
- var2 = gimple_assign_rhs2 (stmt);
  gsi = gsi_for_stmt (stmt);
  gsi_remove (&gsi, true);
  release_defs (stmt);
- /* A multiply whose operands are both fed by builtin pow/powi
-calls must check whether to remove rhs2 as well.  */
- remove_def_if_absorbed_call (var2);
}
-  else if (is_gimple_call (stmt) && gimple_visited_p (stmt))
-   {
- completely_remove_stmt (stmt);
- return;
-   }
   else
return;
 }
 }
 
-/* If OP is an SSA name, find its definition and determine whether it
-   is a call to __builtin_powi.  If so, move the definition prior to
-   STMT.  Only do this during early reassociation.  */
-
-static void
-possibly_move_powi (gimple stmt, tree op)
-{
-  gimple stmt2, *mpy;
-  tree fndecl;
-  gimple_stmt_iterator gsi1, gsi2;
-
-  if (!first_pass_instance
-  || !flag_unsafe_math_optimizations
-  || TREE_CODE (op) != SSA_NAME)
-return;
-  
-  stmt2 = SSA_NAME_DEF_STMT (op);
-
-  if (!is_gimple_call (stmt2)
-  || !has_single_use (gimple_call_lhs (stmt2)))
-return;
-
-  fndecl = gimple_call_fndecl (stmt2);
-
-  if (!fndecl
-  || DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_NORMAL)
-return;
-
-  switch (DECL_FUNCTION_CODE (fndecl))
-{
-CASE_FLT_FN (BUILT_IN_POWI):
-  break;
-default:
-  return;
-}
-
-  /* Move the __builtin_powi.  */
-  gsi1 = gsi_for_stmt (stmt);
-  gsi2 = gsi_for_stmt (stmt2);
-  gsi_move_before (&gsi2, &gsi1);
-
-  /* See if there are multiplies feeding the __builtin_powi base
- argument that must also be moved.  */
-  while ((mpy = (gimple *) pointer_map_contains (bip_map, stmt2)) != NULL)
-{
-  /* If we've already moved this statement, we're done.  This is
- identified by a NULL entry for the statement in bip_map.  */
-  gimple *next = (gimple *) pointer_map_con

Re: [RFA] PowerPC e5500 and e6500 cores support

[Michael Meissner]

On Tue, Mar 06, 2012 at 11:44:08AM -0500, Edmar wrote:
> Freescale would like to contribute these patches to gcc.
> 
> It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
> description,  and set proper default flags for the e5500 and e6500 cores.
> 
> Both are 64 bit cores capable to execute popcntb/w/d, bperm, cmpb,
> and prtyw/d instructions.
> 
> The e6500 core has Altivec and also the new Altivec instructions that
> will be part of Power ISA-2.07.
> Several tests cases for the new altivec builtins are included.
> 
> The patch was generated from subversion revision 184757.
> 
> The patch was regression tested for power7 target under these conditions:
> --enable-checking --disable-decimal-float --enable-languages=c,c++,fortran
> 
> During the development process, an ICE for cell target was found.
> The e6500 patch also fixes that problem.
> 
> Since the cell ICE is an regression, I have a separate patch and
> ChangeLog that can be applied against gcc-4.7/4.6/4.5 to fix this ICE only.
> (The branches were also regression tested using the same conditions above)
> 
> Regarding the implementation of popcntb, popcntd, and cmpb. Gcc has
> dedicated masks on target_flags for them, but due to shortage of bits,
> those masks controls more than the name implies.
> 
> TARGET_POPCNTB also controls FP reciprocal estimate that the
> Frescale cores does not have
>
> TARGET_POPCNTD also controls FP double word conversion, lfiwzx that
> the Freescale cores does not have.
>
> TARGET_CMPB also controls copy sign, lfiwax that the Freescale cores
> does not have.

As currently used in the compiler:

  * TARGET_POPCNTB is for all insns in ISA 2.04,
  * TARGET_CMPB is for all insns in ISA 2.05 other than Altivec, Decimal
  * TARGET_POPCNTD is for all insns in ISA 2.06 other than Altivec, Decimal,
and VSX

> In the patch I minimized the number of changes, while not adding
> any new mask to target_flags.

While we may get some bits back when the original Power flags are removed, it
may be time to bite the bullet and have two separate target flags like x86 did,
because we keep running out of bits.

> A new attribute type "popcnt" is created. This is used in our scheduler,
> since it takes 2 cycles on Freescale cores. The scheduler of current
> architectures are not affected, because the default value of popcnt type
> is the same as not having a type definition on a define_insn.

It is 2 cycles on power6/power7 so this is reasonable.

> We thanks in advance for your time to review and commit these patches

Some comments from looking at the patches:

A meta-issue is the name of the Freescale extensions.  The problem of calling
it Altivec2 is we get into a situation like AMD and Intel have had over what
the next SSE revision is.  Perhaps using a different name than Altivec2.  David
probably needs to weigh in on this.

What is the rationale for changing modes for stv* from V4SI to V16QI, and is it
safe?  I'm just worried about existing code, that suddenly stops working.

In rs6000.c, I think gpopt/mfocrf should only be cleared if the user did not
explicitly set those options.  If you want to issue an error if the user
explicitly set the options for the new cpus, that is fine, but I don't like the
backend to silently change options that were explicitly set on the command
line.

In terms of the comments about the insns being in ISA 2.07, that may be
premature until the ISA is actually published.  Also, some of the Altivec2
insns are not in the ISA 2.07 versions I've reviewed (the trouble is finding
which insns are in which RFCs).

I really don't like the explict CPU checks in TARGET_LFIWAX, TARGET_LFIWZX,
because it is easy to miss when the next new cpu comes out.  Perhaps it would
be better to have one more target flag that says to ignore the instructions
Freescale doesn't support.  I dunno, or as I said, maybe it is time to have two
target_flags.  The x86 has also gone to using HOST_WIDE_INT for their two sets
of target flags.

As I mentioned earlier, I like the new popcnt type attribute, but whenever you
add a new type attribute, you should to go through all of the *.md files add
add support for the new attribute.  Now, insns that aren't supported on older
machines are one thing, but since popcnt has been part of the architecture
since the Power/PowerPC came out, I would think you need to edit power4.md,
7xx.md, etc. to add popcnt in the same place as integer.

I think you need to refine the tests, and change powerpc_altivec_ok lines to
something like:
/* { dg-require-effective-target powerpc_altivec2_ok } */

And then add in support in testsuite/lib/target-supports.exp to detect whether
the assembler supports all of the Altivec2 (or whatever we call it)
instructions.  In the same vein, you probably need to add support in
configure.ac to detect whether the assembler knows about the insns similar to
like I did in gcc_cv_as_powerpc_vsx to detect if the assembler knows about
VSX.

-- 
Michael Meissner, IBM
5 Te

Re: Turn check macros into functions. (issue6188088)

[Mike Stump]

On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
>> Reusing the compiler for this seems like the only way to go.
>> But, we did look at using g++ to parse C++ expressions from gdb,
>> and it was too slow :-(.  We're going to look again, at least to
>> generate some bug reports if we can.
> 
> It's a tough problem, particularly as C/C++ and their compilers
> were not designed for a read-eval-print-loop environment.

This of course is trivial to do, and reasonably fast as well.  We have an 
existence proof that they can generate a call on the target system, all one 
needs to do would be to locate the target compiler, compile up a strapping 
routine, push a dlopen of that routine onto the target system and then call 
dlsym to grab a handle to it.  The strapping routine can set up an environment 
and communication channels as needed.  If could even allocate a thread and have 
it always be live (non-stop), if one wanted.

Oh, and the benefit, the language supported by the code closely matches the 
compiler.  Speed, 1/40 of a second, fast enough for command like use.  Want to 
evaluate it 100 times, sure, just be sure to cache the dlopen/dlsym, and 
notice that you can do a million invocations, well, I'd guess a million times 
faster than gdb currently.

If gdb won't solve these problem, dump it, move to lldb, I can assure you, they 
will not fail to solve the problem, just because gdb can't or won't.  The name 
of the game is compete or die.

If you use the clang libraries, you can read eval, print... and the performance 
would likely be even better.  After all, it can be used to do OpenCL style 
programming, and that certainly was built for speed.  So, I reject the idea 
this all isn't trivial.


$ cat eval.c
#include 
#include 
#include 
#include 

int main() {
  char buf[4096];
  while (fgets (buf, sizeof (buf), stdin) != NULL) {
struct timeval tv1, tv2;
gettimeofday(&tv1, 0);
FILE *fp = popen ("gcc -w -xc - -shared -o test.so", "w");
if (fputs (buf, fp) < 0) {
  printf ("write fails\n");
  exit (1);
}
if (pclose (fp) != 0) {
  printf ("compile fails\n");
  exit (1);
}  
void *vp = dlopen("test.so", RTLD_NOW|RTLD_LOCAL|RTLD_FIRST);
void *fcn = dlsym (vp, "eval");
if (fcn) {
  void (*func)();
  func = fcn;
  printf("about to run\n");
  func();
  gettimeofday(&tv2, 0);
  printf("done running, took %ld usecs\n", tv2.tv_sec*100 + tv2.tv_usec 
- tv1.tv_sec*100 - tv1.tv_usec);
} else {
  printf ("eval not found\n");
}
if (dlclose (vp) < 0) {
  printf ("dlclose fails\n");
  exit (1);
}  
  
  }
}
$ gcc eval.c -o eval -O3
$ ./eval
int eval () { printf ("hi\n"); }
about to run
hi
done running, took 28419 usecs
int eval () { printf ("hi\n"); }
about to run
hi
done running, took 29300 usecs
int eval () { printf ("hi\n"); }
about to run
hi
done running, took 25755 usecs
int eval () { printf ("hi\n"); }
about to run
hi
done running, took 28295 usecs


Maybe your thinking of lisp, certainly that language makes it hard.  ;-P

Re: [RFC] PR 53063 encode group options in .opt files

[Chung-Lin Tang]

On 2012/5/18 01:51 AM, Gabriel Dos Reis wrote:
> On Thu, May 17, 2012 at 12:41 PM, Gabriel Dos Reis
>  wrote:
>> On Thu, May 17, 2012 at 12:28 PM, Manuel López-Ibáñez
>>  wrote:
>>> On 17 May 2012 19:25, Gabriel Dos Reis  
>>> wrote:
 On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
  wrote:
> On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
>>> I'm guessing these changes are the cause of a full C bootstrap
 (--disable-build-poststage1-with-cxx) failure I'm seeing on trunk. The
 *_handle_option_auto function prototypes are not seen in options.c, and
 -Werror -Wmissing-prototypes are in effect (oddly, such strict checking
 is not enforced in the default post-stage1 C++ bootstrap)
>> Yep, We should add -Wmissing-declarations to the post-stage1 flags,
>> which also exists in C. Could you also add that to your patch?
>>
>
> I'm a little unsure of how -Wmissing-declarations vs
> -Wmissing-prototypes behave for C? Anyways here's a patch to add
> -Wmissing-declarations for C++, keeping C as is.

 What is the purpose of  -Wmissing-declarations for C++?
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
>>
>> The point is: it is mostly useless for C++.  The rationale for its
>> existence in C are largely irrelevant in the context of C++.
> 
> Let me add that the notion of "global function defined in header" is
> largely meaningless in C++.  I fear this is one of those cases where
> we are trying too hard to push a C style to C++.  We should not.
> 
> The notion of "global function in C++" can only be interpreted as
> meaning a function with external linkage -- because C++ has namespace
> and C does not, and a there is no reason to treat the global scope 
> differently.
>  Furthermore, C++98 and C++03 requires that functions
> used in certain contexts have external linkage.  For GCC's own source code,
> we would refrain from anonymous namespaces because they might interfer with
> bootstrap compare and reproducibility.  That means we are left with
> having to declare
> those functions right before their definitions, not but in headers;
> that is just plain silly.

The point here is that, a group of changes that broke C bootstrap went
in undetected for several days, because of the partially C++ default. To
prevent that in the future, we should enforce similar checking in both C
and C++.

Chung-Lin

Re: [RFC] PR 53063 encode group options in .opt files

[Chung-Lin Tang]

On 2012/5/18 03:20 AM, Joseph S. Myers wrote:
> On Fri, 18 May 2012, Chung-Lin Tang wrote:
> 
>> Joseph, how does this look? It makes the default post-stage1 C++
>> bootstrap fail similarly without the other options.c Makefile change, so
>> I guess it works as intended.
> 
> For build system patches you ought to be asking the build system 
> maintainers for their views, rather than me.
> 

Ok, CCing build system maintainers.

Thanks,
Chung-Lin