Re: [PATCH][4/n] referenced-vars TLC

[Richard Guenther]

On Wed, 23 May 2012, H.J. Lu wrote:

> On Wed, May 23, 2012 at 5:00 AM, Richard Guenther  wrote:
> >
> > This finally switches us to not record global vars in referenced-vars.
> > For this to work I had to re-engineer how we handle global var removal
> > from local-decls in remove_unused_locals.  Incidentially that code
> > already had some sort of a bitmap (for some weird reason even), thus
> > I borrowed that and simplified the handling.  You may notice that
> > it would be easy to handle all vars that way ...
> >
> > So eventually 5/n will make referenced-vars go away completely
> > (the only serious user seems to be the SSA renamer for its
> > SYMS_TO_RENAME bitmap).
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> >
> > Richard.
> >
> > 2012-05-23  Richard Guenther  
> >
> >        * tree-dfa.c (add_referenced_var_1): Do not add global vars.
> >        * tree-ssa-live.c (mark_all_vars_used_1): Handle global vars
> >        via the global_unused_vars bitmap.
> >        (remove_unused_locals): Handle global vars in local-decls via
> >        a global_unused_vars bitmap instead of the used flag in the
> >        var annotation.  Simplify global variable handling and removal.
> >
> 
> This breaks bootstrap on Linux/x86-64:
> 
> http://gcc.gnu.org/ml/gcc-regression/2012-05/msg00468.html
> 
> Comparing stages 2 and 3
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap comparison failure!
> gcc/trans-mem.o differs
> gcc/gimple-low.o differs
> gcc/sese.o differs
> make[5]: *** [compare] Error 1
> 
> Please make sure that your compiler used for bootstrap
> doesn't add anything to .comment section, which will
> disable debug compare.

Well, I can't.  Why is debug compare so fragile?  Now trying to find
a way to reproduce (I can't see why it should cause this ...)

Richard.

Re: [PATCH][4/n] referenced-vars TLC

[Richard Guenther]

On Wed, 23 May 2012, H.J. Lu wrote:

> On Wed, May 23, 2012 at 7:25 AM, H.J. Lu  wrote:
> > On Wed, May 23, 2012 at 5:00 AM, Richard Guenther  wrote:
> >>
> >> This finally switches us to not record global vars in referenced-vars.
> >> For this to work I had to re-engineer how we handle global var removal
> >> from local-decls in remove_unused_locals.  Incidentially that code
> >> already had some sort of a bitmap (for some weird reason even), thus
> >> I borrowed that and simplified the handling.  You may notice that
> >> it would be easy to handle all vars that way ...
> >>
> >> So eventually 5/n will make referenced-vars go away completely
> >> (the only serious user seems to be the SSA renamer for its
> >> SYMS_TO_RENAME bitmap).
> >>
> >> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> >>
> >> Richard.
> >>
> >> 2012-05-23  Richard Guenther  
> >>
> >>        * tree-dfa.c (add_referenced_var_1): Do not add global vars.
> >>        * tree-ssa-live.c (mark_all_vars_used_1): Handle global vars
> >>        via the global_unused_vars bitmap.
> >>        (remove_unused_locals): Handle global vars in local-decls via
> >>        a global_unused_vars bitmap instead of the used flag in the
> >>        var annotation.  Simplify global variable handling and removal.
> >>
> >
> > This breaks bootstrap on Linux/x86-64:
> >
> > http://gcc.gnu.org/ml/gcc-regression/2012-05/msg00468.html
> >
> > Comparing stages 2 and 3
> > warning: gcc/cc1plus-checksum.o differs
> > warning: gcc/cc1obj-checksum.o differs
> > warning: gcc/cc1-checksum.o differs
> > Bootstrap comparison failure!
> > gcc/trans-mem.o differs
> > gcc/gimple-low.o differs
> > gcc/sese.o differs
> > make[5]: *** [compare] Error 1
> >
> > Please make sure that your compiler used for bootstrap
> > doesn't add anything to .comment section, which will
> > disable debug compare.
> 
> I opened:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53466

I am testing the following (or it will reproduce hopefully, with
--with-build-config=bootstrap-debug).  Why can't compare-debug ignore
comment sections?

Thanks,
Richard.

2012-05-24  Richard Guenther  

PR bootstrap/53466
* tree-ssa-live.c (remove_unused_scope_block_p): Properly
handle globals.
(remove_unused_locals): Pass global_unused_vars to
remove_unused_scope_block_p.

Index: gcc/tree-ssa-live.c
===
--- gcc/tree-ssa-live.c (revision 187800)
+++ gcc/tree-ssa-live.c (working copy)
@@ -429,7 +429,7 @@ mark_scope_block_unused (tree scope)
done by the inliner.  */
 
 static bool
-remove_unused_scope_block_p (tree scope)
+remove_unused_scope_block_p (tree scope, bitmap global_unused_vars)
 {
   tree *t, *next;
   bool unused = !TREE_USED (scope);
@@ -472,7 +472,9 @@ remove_unused_scope_block_p (tree scope)
 info about optimized-out variables in the scope blocks.
 Exception are the scope blocks not containing any instructions
 at all so user can't get into the scopes at first place.  */
-  else if (var_ann (*t) != NULL && is_used_p (*t))
+  else if ((is_global_var (*t)
+   && !bitmap_bit_p (global_unused_vars, DECL_UID (*t)))
+  || (var_ann (*t) != NULL && is_used_p (*t)))
unused = false;
   else if (TREE_CODE (*t) == LABEL_DECL && TREE_USED (*t))
/* For labels that are still used in the IL, the decision to
@@ -517,7 +519,7 @@ remove_unused_scope_block_p (tree scope)
 }
 
   for (t = &BLOCK_SUBBLOCKS (scope); *t ;)
-if (remove_unused_scope_block_p (*t))
+if (remove_unused_scope_block_p (*t, global_unused_vars))
   {
if (BLOCK_SUBBLOCKS (*t))
  {
@@ -847,9 +849,12 @@ remove_unused_locals (void)
 }
   if (dstidx != num)
 VEC_truncate (tree, cfun->local_decls, dstidx);
+
+  remove_unused_scope_block_p (DECL_INITIAL (current_function_decl),
+  global_unused_vars);
+
   BITMAP_FREE (global_unused_vars);
 
-  remove_unused_scope_block_p (DECL_INITIAL (current_function_decl));
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   fprintf (dump_file, "Scope blocks after cleanups:\n");

Re: fix cross build

[Richard Guenther]

On Wed, May 23, 2012 at 7:58 PM, Nathan Sidwell  wrote:
> On 05/22/12 15:12, Richard Guenther wrote:
>
>> But I wonder why CONSTRUCTORs do not inherit TREE_SIDE_EFFECTS
>> properly ...
>
>
> the attached patch fixes the ICE and causes no regressions on
> i686-pc-linux-gnu.
>
> ok?

Looks ok to me.  Though I wonder how we got away with that for so long time ...

What do others prefer?  Keep CONSTRUCTORs "broken" and paper over in
gimplify.c instead?

If you don't hear from somebody else in 24h the patch is ok as-is
(can you do some grepping whether there are callers of build_constructor
that set TREE_SIDE_EFFECTS on it afterwards?)

Thanks,
Richard.

> nathan

Re: [cxx-conversion] Convert vec.[ch] to C++ [2/3] (issue6236043)

[Richard Guenther]

On Wed, May 23, 2012 at 9:49 PM, Diego Novillo  wrote:
>
> Part 2 of the VEC C++ conversion.  This patch implements the gengtype
> changes.
>
> I extended gengtype to understand templated types.  These changes are
> not as ugly as I thought they would be.  Gengtype has some hardwired
> knowledge of VEC_*, which I renamed to vec_t.  I'm not even sure why
> gengtype needs to care about vec_t in this way, but I was looking for
> minimal changes, so I just did it.
>
> The other change is more generic.  It allows gengtype to deal with
> templated types.  There is a new function (filter_type_name) that
> recognizes C++ special characters '<', '>' and ':'.  It turns them
> into '_'.  This way, gengtype can generate a valid identifier for the
> pre-processor.  It only does this in contexts where it needs a
> pre-processor identifier.  For everything else, it emits the type
> directly.  So, the functions emitted in gt-*.h files have proper
> template type references.

This is, of course, just a replacement of special-case handling for vec.h
with another special-case handling.  It does not show us how templated
structs should work with gengtype in general.  And no, I don't think
gengtype should keep the special-case for vec.h.

The point was to make all the gt_ggc_* functions function template
specializations so the code gengtype emits for walking a structs fields
would be just

   mark (field1);
   mark (field2);
 ...

and we could manually provide specializations for selected types
(well, the templates).  Add a GTY((template)) marker to make gengtype
not emit the specializations itself (or simply make it recognize template
types and do nothing for them).

Richard.

> 2012-05-23   Diego Novillo  
>
>        * gengtype-lex.l (DEF_VEC_ALLOC_[IOP]/{EOID}): Remove.
>        * gengtype-parse.c (token_names): Remove DEF_VEC_ALLOC_[IOP].
>        (typedef_name): Emit vec_t instead of VEC_C1_C2.
>        (def_vec_alloc): Remove.  Update all callers.
>        * gengtype.c (filter_type_name): New.
>        (output_mangled_typename): Call it.
>        (write_func_for_structure): Likewise.
>        (write_types): Likewise.
>        (write_root): Likewise.
>        (write_typed_alloc_def): Likewise.
>        (note_def_vec): Emit vec_t instead of VEC_TYPE_NAME_base.
>        (note_def_vec_alloc): Remove.
>        * gengtype.h (note_def_vec_alloc): Remove.
>        (DEFVEC_ALLOC): Remove token code.
>
> diff --git a/gcc/gengtype-lex.l b/gcc/gengtype-lex.l
> index a71cce0..edfd4a1 100644
> --- a/gcc/gengtype-lex.l
> +++ b/gcc/gengtype-lex.l
> @@ -100,10 +100,6 @@ EOID       [^[:alnum:]_]
>   BEGIN(in_struct);
>   return DEFVEC_I;
>  }
> -^{HWS}DEF_VEC_ALLOC_[IOP]/{EOID} {
> -  BEGIN(in_struct);
> -  return DEFVEC_ALLOC;
> -}
>  }
>
>  {
> diff --git a/gcc/gengtype-parse.c b/gcc/gengtype-parse.c
> index 89f14e8..4fc2b07 100644
> --- a/gcc/gengtype-parse.c
> +++ b/gcc/gengtype-parse.c
> @@ -79,7 +79,6 @@ static const char *const token_names[] = {
>   "VEC",
>   "DEF_VEC_[OP]",
>   "DEF_VEC_I",
> -  "DEF_VEC_ALLOC_[IOP]",
>   "...",
>   "ptr_alias",
>   "nested_ptr",
> @@ -227,7 +226,7 @@ typedef_name (void)
>       require (',');
>       c2 = require (ID);
>       require (')');
> -      r = concat ("VEC_", c1, "_", c2, (char *) 0);
> +      r = concat ("vec_t<", c1, ">", (char *) 0);
>       free (CONST_CAST (char *, c1));
>       free (CONST_CAST (char *, c2));
>       return r;
> @@ -916,31 +915,6 @@ def_vec (void)
>     return;
>
>   note_def_vec (type, is_scalar, &lexer_line);
> -  note_def_vec_alloc (type, "none", &lexer_line);
> -}
> -
> -/* Definition of an allocation strategy for a VEC structure:
> -
> -   'DEF_VEC_ALLOC_[IPO]' '(' id ',' id ')' ';'
> -
> -   For purposes of gengtype, this just declares a wrapper structure.  */
> -static void
> -def_vec_alloc (void)
> -{
> -  const char *type, *astrat;
> -
> -  require (DEFVEC_ALLOC);
> -  require ('(');
> -  type = require2 (ID, SCALAR);
> -  require (',');
> -  astrat = require (ID);
> -  require (')');
> -  require (';');
> -
> -  if (!type || !astrat)
> -    return;
> -
> -  note_def_vec_alloc (type, astrat, &lexer_line);
>  }
>
>  /* Parse the file FNAME for GC-relevant declarations and definitions.
> @@ -972,10 +946,6 @@ parse_file (const char *fname)
>          def_vec ();
>          break;
>
> -       case DEFVEC_ALLOC:
> -         def_vec_alloc ();
> -         break;
> -
>        case EOF_TOKEN:
>          goto eof;
>
> diff --git a/gcc/gengtype.c b/gcc/gengtype.c
> index 814d9e0..82dca36 100644
> --- a/gcc/gengtype.c
> +++ b/gcc/gengtype.c
> @@ -2295,6 +2295,34 @@ struct walk_type_data
>   int loopcounter;
>  };
>
> +
> +/* Given a string TYPE_NAME, representing a C++ typename, return a valid
> +   pre-processor identifier to use in a #define directive.  This replaces
> +   special characters used in C++ identifiers like '>', '<' and ':' with
> +   '_'.
> +
> +   If no C++ special characters are found in TYPE_NAME, return
> +   TYPE_NAME.  Otherwise, return a copy

Re: [PATCH][4/n] referenced-vars TLC

[Richard Guenther]

On Thu, 24 May 2012, Richard Guenther wrote:

> On Wed, 23 May 2012, H.J. Lu wrote:
> 
> > On Wed, May 23, 2012 at 7:25 AM, H.J. Lu  wrote:
> > > On Wed, May 23, 2012 at 5:00 AM, Richard Guenther  
> > > wrote:
> > >>
> > >> This finally switches us to not record global vars in referenced-vars.
> > >> For this to work I had to re-engineer how we handle global var removal
> > >> from local-decls in remove_unused_locals.  Incidentially that code
> > >> already had some sort of a bitmap (for some weird reason even), thus
> > >> I borrowed that and simplified the handling.  You may notice that
> > >> it would be easy to handle all vars that way ...
> > >>
> > >> So eventually 5/n will make referenced-vars go away completely
> > >> (the only serious user seems to be the SSA renamer for its
> > >> SYMS_TO_RENAME bitmap).
> > >>
> > >> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > >>
> > >> Richard.
> > >>
> > >> 2012-05-23  Richard Guenther  
> > >>
> > >>        * tree-dfa.c (add_referenced_var_1): Do not add global vars.
> > >>        * tree-ssa-live.c (mark_all_vars_used_1): Handle global vars
> > >>        via the global_unused_vars bitmap.
> > >>        (remove_unused_locals): Handle global vars in local-decls via
> > >>        a global_unused_vars bitmap instead of the used flag in the
> > >>        var annotation.  Simplify global variable handling and removal.
> > >>
> > >
> > > This breaks bootstrap on Linux/x86-64:
> > >
> > > http://gcc.gnu.org/ml/gcc-regression/2012-05/msg00468.html
> > >
> > > Comparing stages 2 and 3
> > > warning: gcc/cc1plus-checksum.o differs
> > > warning: gcc/cc1obj-checksum.o differs
> > > warning: gcc/cc1-checksum.o differs
> > > Bootstrap comparison failure!
> > > gcc/trans-mem.o differs
> > > gcc/gimple-low.o differs
> > > gcc/sese.o differs
> > > make[5]: *** [compare] Error 1
> > >
> > > Please make sure that your compiler used for bootstrap
> > > doesn't add anything to .comment section, which will
> > > disable debug compare.
> > 
> > I opened:
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53466
> 
> I am testing the following (or it will reproduce hopefully, with
> --with-build-config=bootstrap-debug).  Why can't compare-debug ignore
> comment sections?

This one passes bootstrap for C/C++.  I have applied it to unbreak
bootstrap.

Thanks,
Richard.

2012-05-24  Richard Guenther  

PR bootstrap/53466
* tree-ssa-live.c (remove_unused_scope_block_p): Properly
handle globals.
(remove_unused_locals): Pass global_unused_vars to
remove_unused_scope_block_p.  Restore code walking all
referenced vars and pruning them.

Index: gcc/tree-ssa-live.c
===
--- gcc/tree-ssa-live.c (revision 187800)
+++ gcc/tree-ssa-live.c (working copy)
@@ -429,7 +429,7 @@ mark_scope_block_unused (tree scope)
done by the inliner.  */
 
 static bool
-remove_unused_scope_block_p (tree scope)
+remove_unused_scope_block_p (tree scope, bitmap global_unused_vars)
 {
   tree *t, *next;
   bool unused = !TREE_USED (scope);
@@ -472,7 +472,9 @@ remove_unused_scope_block_p (tree scope)
 info about optimized-out variables in the scope blocks.
 Exception are the scope blocks not containing any instructions
 at all so user can't get into the scopes at first place.  */
-  else if (var_ann (*t) != NULL && is_used_p (*t))
+  else if ((is_global_var (*t)
+   && !bitmap_bit_p (global_unused_vars, DECL_UID (*t)))
+  || (var_ann (*t) != NULL && is_used_p (*t)))
unused = false;
   else if (TREE_CODE (*t) == LABEL_DECL && TREE_USED (*t))
/* For labels that are still used in the IL, the decision to
@@ -517,7 +519,7 @@ remove_unused_scope_block_p (tree scope)
 }
 
   for (t = &BLOCK_SUBBLOCKS (scope); *t ;)
-if (remove_unused_scope_block_p (*t))
+if (remove_unused_scope_block_p (*t, global_unused_vars))
   {
if (BLOCK_SUBBLOCKS (*t))
  {
@@ -847,9 +849,20 @@ remove_unused_locals (void)
 }
   if (dstidx != num)
 VEC_truncate (tree, cfun->local_decls, dstidx);
+
+  /* ???  We end up with decls in referenced-vars that are not in
+ local-decls.  */
+  FOR_EACH_REFERENCED_VAR (cfun, t, rvi)
+if (TREE_CODE (t) == VAR_DECL
+   && !VAR_DECL_IS_VIRTUAL_OPERAND (t)
+   && !is_used_p (t))
+  remove_referenced_var (t);
+
+  remove_unused_scope_block_p (DECL_INITIAL (current_function_decl),
+  global_unused_vars);
+
   BITMAP_FREE (global_unused_vars);
 
-  remove_unused_scope_block_p (DECL_INITIAL (current_function_decl));
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   fprintf (dump_file, "Scope blocks after cleanups:\n");

Symbol table 24/many: Remove old alias handling code

[Jan Hubicka]

Hi,
this patch removes code handling alias pairs after they was taken over by 
symbol table.
It also streamlines how things are output - do_assemble_alias is called when 
alias should
be output now, while assemble_alias is the function registering new alias into 
symbol
table.

I think I will rename these incrementaly.

Bootstrapped/regtested x86_64-linux

* tree.h (alias_diag_flags): Remove.
(alias_pair): Remove emitted_diags.
(finish_aliases_1, finish_aliases_2, remove_unreachable_alias_pairs,
symbol_alias_set_t, symbol_alias_set_destroy,
symbol_alias_set_contains, propagate_aliases_backward): Remove.
* toplev.c (compile_file): Do not call finish_aliases_2
* cgraphunit.c (cgraph_process_new_functions): Do not call 
finish_aliases_1.
(handle_alias_pairs): Output diagnostics about aliases to externals.
(assemble_thunks_and_aliases): Use do_assemble_alias.
(output_weakrefs): Likewise.
(finalize_compilation_unit): Do not call finish_aliases_1.
* ipa.c (symtab_remove_unreachable_nodes): De not call 
remove_unreachable_alias_pairs.
* varasm.c (do_assemble_alias): Export.
(symbol_alias_set_create, symbol_alias_set_destroy, 
symbol_alias_set_contains,
symbol_alias_set_insert, propagate_aliases_forward, 
propagate_aliases_backward,
propagate_aliases_backward, trivially_visible_alias, 
trivially_defined_alias,
remove_unreachable_alias_pairs, finish_aliases_1, finish_aliases_2, 
assemble_alias): Remove.
* output.h (do_assemble_alias): Declare.
* varpool.c (varpool_remove_unreferenced_decls): Do not call 
finish_aliases_1.
Index: tree.h
===
*** tree.h  (revision 187695)
--- tree.h  (working copy)
*** extern const unsigned char tree_code_len
*** 239,263 
  
  extern const char *const tree_code_name[];
  
! /* We have to be able to tell cgraph about the needed-ness of the target
!of an alias.  This requires that the decl have been defined.  Aliases
!that precede their definition have to be queued for later processing.  */
! 
! /* The deferred processing proceeds in several passes.  We memorize the
!diagnostics emitted for a pair to prevent repeating messages when the
!queue gets re-scanned after possible updates.  */
! 
! typedef enum {
!   ALIAS_DIAG_NONE  = 0x0,
!   ALIAS_DIAG_TO_UNDEF  = 0x1,
!   ALIAS_DIAG_TO_EXTERN = 0x2
! } alias_diag_flags;
!   
  typedef struct GTY(()) alias_pair
  {
tree decl;
tree target;  
-   int  emitted_diags;  /* alias_diags already emitted for this pair.  */
  } alias_pair;
  
  /* Define gc'd vector type.  */
--- 239,252 
  
  extern const char *const tree_code_name[];
  
! /* When procesing aliases on symtab level, we need the declaration of target.
!For this reason we need to queue aliases and process them after all 
declarations
!has been produced.  */
! 
  typedef struct GTY(()) alias_pair
  {
tree decl;
tree target;  
  } alias_pair;
  
  /* Define gc'd vector type.  */
*** extern void mark_decl_referenced (tree);
*** 5686,5709 
  extern void notice_global_symbol (tree);
  extern void set_user_assembler_name (tree, const char *);
  extern void process_pending_assemble_externals (void);
- extern void finish_aliases_1 (void);
- extern void finish_aliases_2 (void);
- extern void remove_unreachable_alias_pairs (void);
  extern bool decl_replaceable_p (tree);
  extern bool decl_binds_to_current_def_p (tree);
- 
- /* Derived type for use by compute_visible_aliases and callers.  A symbol
-alias set is a pointer set into which we enter IDENTIFIER_NODES bearing
-the canonicalised assembler-level symbol names corresponding to decls
-and their aliases.  */
- typedef struct pointer_set_t symbol_alias_set_t;
- 
- extern void symbol_alias_set_destroy (symbol_alias_set_t *);
- extern int symbol_alias_set_contains (const symbol_alias_set_t *, tree);
- extern symbol_alias_set_t * propagate_aliases_backward (bool (*)
-(tree, tree, void *),
-   void *);
- 
  /* In stmt.c */
  extern void expand_computed_goto (tree);
  extern bool parse_output_constraint (const char **, int, int, int,
--- 5675,5682 
Index: toplev.c
===
*** toplev.c(revision 187695)
--- toplev.c(working copy)
*** compile_file (void)
*** 577,584 
   basically finished.  */
if (in_lto_p || !flag_lto || flag_fat_lto_objects)
  {
-   finish_aliases_2 ();
- 
/* Likewise for mudflap static object registrations.  */
if (flag_mudflap)
mudflap_finish_file ();
--- 577,582 
Index: cgraphunit.c
===
*** cgraphunit.c(re

[PATCH][5/n] referenced-vars TLC

[Richard Guenther]

This removes redundant calls to create_var_ann.  A future patch
will make this function private.

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

Richard.

2012-05-24  Richard Guenther  

* varpool.c (add_new_static_var): Remove call to create_var_ann.
* tree-ssa-operands.c (create_vop_var): Likewise.

Index: gcc/varpool.c
===
*** gcc/varpool.c   (revision 187823)
--- gcc/varpool.c   (working copy)
*** add_new_static_var (tree type)
*** 457,463 
DECL_CONTEXT (new_decl) = NULL_TREE;
DECL_ABSTRACT (new_decl) = 0;
lang_hooks.dup_lang_specific_decl (new_decl);
-   create_var_ann (new_decl);
new_node = varpool_node (new_decl);
add_referenced_var (new_decl);
varpool_finalize_decl (new_decl);
--- 457,462 
Index: gcc/tree-ssa-operands.c
===
*** gcc/tree-ssa-operands.c (revision 187823)
--- gcc/tree-ssa-operands.c (working copy)
*** create_vop_var (struct function *fn)
*** 177,183 
TREE_ADDRESSABLE (global_var) = 0;
VAR_DECL_IS_VIRTUAL_OPERAND (global_var) = 1;
  
-   create_var_ann (global_var);
add_referenced_var_1 (global_var, fn);
fn->gimple_df->vop = global_var;
  }
--- 177,182 

[C++ Patch] PR 32080

[Paolo Carlini]

Hi,

the issue here is that we don't diagnose jumps into the try of a 
function-try-block. The reason is quite simple: from 
cp_parser_function_try_block we call 
cp_parser_ctor_initializer_opt_and_function_body which calls 
cp_parser_function_body, which always passes false to 
cp_parser_compound_statement as third argument.


Thus it seems to me that the straightforward way to fix this is making 
sure a true reaches the latter when parsing a function-try-block, then 
it must work because try-blocks do exactly that and are already fine.


Bootstrapped and tested x86_64-linux.

Thanks,
Paolo.

///
/cp
2012-05-24  Paolo Carlini  

PR c++/32080
* parser.c (cp_parser_ctor_initializer_opt_and_function_body,
cp_parser_function_body): Add a bool parameter, true when parsing
a function-try-block.
(cp_parser_function_try_block): Pass true to the above.
(cp_parser_function_definition_after_declarator,
cp_parser_function_transaction): Adjust.

/testsuite
2012-05-24  Paolo Carlini  

PR c++/32080
* g++.dg/eh/goto2.C: New.

Index: testsuite/g++.dg/eh/goto2.C
===
--- testsuite/g++.dg/eh/goto2.C (revision 0)
+++ testsuite/g++.dg/eh/goto2.C (revision 0)
@@ -0,0 +1,12 @@
+// PR c++/32080
+
+void f()
+try
+  {
+goto l2;   // { dg-error "from here" }
+  l1: ;// { dg-error "jump to label 'l1'" }
+  } catch (...)
+  {
+  l2: ;// { dg-error "jump to label 'l2'|enters catch block" }
+goto l1;   // { dg-error "from here|enters try block" }
+  }
Index: cp/parser.c
===
--- cp/parser.c (revision 187822)
+++ cp/parser.c (working copy)
@@ -1989,7 +1989,7 @@ static cp_parameter_declarator *cp_parser_paramete
 static tree cp_parser_default_argument 
   (cp_parser *, bool);
 static void cp_parser_function_body
-  (cp_parser *);
+  (cp_parser *, bool);
 static tree cp_parser_initializer
   (cp_parser *, bool *, bool *);
 static tree cp_parser_initializer_clause
@@ -2000,7 +2000,7 @@ static VEC(constructor_elt,gc) *cp_parser_initiali
   (cp_parser *, bool *);
 
 static bool cp_parser_ctor_initializer_opt_and_function_body
-  (cp_parser *);
+  (cp_parser *, bool);
 
 /* Classes [gram.class] */
 
@@ -17395,16 +17395,18 @@ cp_parser_default_argument (cp_parser *parser, boo
  compound_statement  */
 
 static void
-cp_parser_function_body (cp_parser *parser)
+cp_parser_function_body (cp_parser *parser, bool in_function_try_block)
 {
-  cp_parser_compound_statement (parser, NULL, false, true);
+  cp_parser_compound_statement (parser, NULL, in_function_try_block, true);
 }
 
 /* Parse a ctor-initializer-opt followed by a function-body.  Return
-   true if a ctor-initializer was present.  */
+   true if a ctor-initializer was present.  When IN_FUNCTION_TRY_BLOCK
+   is true we are parsing a function-try-block.  */
 
 static bool
-cp_parser_ctor_initializer_opt_and_function_body (cp_parser *parser)
+cp_parser_ctor_initializer_opt_and_function_body (cp_parser *parser,
+ bool in_function_try_block)
 {
   tree body, list;
   bool ctor_initializer_p;
@@ -17431,7 +17433,7 @@ static bool
last = STATEMENT_LIST_TAIL (list)->stmt;
 }
   /* Parse the function-body.  */
-  cp_parser_function_body (parser);
+  cp_parser_function_body (parser, in_function_try_block);
   if (check_body_p)
 check_constexpr_ctor_body (last, list);
   /* Finish the function body.  */
@@ -19707,8 +19709,8 @@ cp_parser_function_try_block (cp_parser* parser)
   /* Let the rest of the front end know where we are.  */
   try_block = begin_function_try_block (&compound_stmt);
   /* Parse the function-body.  */
-  ctor_initializer_p
-= cp_parser_ctor_initializer_opt_and_function_body (parser);
+  ctor_initializer_p = cp_parser_ctor_initializer_opt_and_function_body
+(parser, /*in_function_try_block=*/true);
   /* We're done with the `try' part.  */
   finish_function_try_block (try_block);
   /* Parse the handlers.  */
@@ -21048,8 +21050,8 @@ cp_parser_function_definition_after_declarator (cp
   else if (cp_lexer_next_token_is_keyword (parser->lexer, RID_TRY))
 ctor_initializer_p = cp_parser_function_try_block (parser);
   else
-ctor_initializer_p
-  = cp_parser_ctor_initializer_opt_and_function_body (parser);
+ctor_initializer_p = cp_parser_ctor_initializer_opt_and_function_body
+  (parser, /*in_function_try_block=*/false);
 
   finish_lambda_scope ();
 
@@ -27224,8 +27226,8 @@ cp_parser_function_transaction (cp_parser *parser,
   if (cp_lexer_next_token_is_keyword (parser->lexer, RID_TRY))
 ctor_initializer_p = cp_parser_function_try_block (parser);
   else
-ctor_initializer_p
-  = cp_parser_ctor_initializer_opt_and_function_body (parser);
+ctor_initializer_p = cp_parser_ctor_initializer_opt_and_function_body
+  (pa

[PATCH][6/n] referenced-vars TLC

[Richard Guenther]

I'm bootstrapping and testing the following patch that inlines
create_var_ann into its single caller and removes calls to
add_referenced_vars when the var is global (which would be a no-op
and in a future patch will assert).

Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.

Richard.

2012-05-24  Richard Guenther  

* tree-flow.h (create_var_ann): Remove.
* tree-dfa.c (create_var_ann): Remove and inline into its
single caller ...
(add_referenced_var_1): ... here.
* varpool.c (add_new_static_var): Do not call add_referenced_var
for global vars.
* gimple-fold.c (canonicalize_constructor_val): Likewise.
* tree-switch-conversion.c (build_one_array): Likewise.
* tree-profile.c (gimple_gen_ic_profiler): Likewise.
* tree-inline.c (remap_gimple_op_r): Likewise.  Check
gimple_referenced_vars instead of gimple_in_ssa_p.
(copy_tree_body_r): Likewise.
(setup_one_parameter): Likewise.
(declare_return_variable): Likewise.
(tree_function_versioning): Likewise.

Index: gcc/tree-flow.h
===
--- gcc/tree-flow.h (revision 187825)
+++ gcc/tree-flow.h (working copy)
@@ -482,7 +482,6 @@ extern int op_prio (const_tree);
 extern const char *op_symbol_code (enum tree_code);
 
 /* In tree-dfa.c  */
-extern var_ann_t create_var_ann (tree);
 extern void renumber_gimple_stmt_uids (void);
 extern void renumber_gimple_stmt_uids_in_blocks (basic_block *, int);
 extern void dump_dfa_stats (FILE *);
Index: gcc/varpool.c
===
--- gcc/varpool.c   (revision 187825)
+++ gcc/varpool.c   (working copy)
@@ -458,7 +458,6 @@ add_new_static_var (tree type)
   DECL_ABSTRACT (new_decl) = 0;
   lang_hooks.dup_lang_specific_decl (new_decl);
   new_node = varpool_node (new_decl);
-  add_referenced_var (new_decl);
   varpool_finalize_decl (new_decl);
 
   return new_node->symbol.decl;
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 187825)
+++ gcc/tree-inline.c   (working copy)
@@ -876,8 +876,8 @@ remap_gimple_op_r (tree *tp, int *walk_s
 
   /* Global variables we haven't seen yet need to go into referenced
 vars.  If not referenced from types only.  */
-  if (gimple_in_ssa_p (cfun)
- && TREE_CODE (*tp) == VAR_DECL
+  if (gimple_referenced_vars (cfun)
+ && TREE_CODE (*tp) == VAR_DECL && !is_global_var (*tp)
  && id->remapping_type_depth == 0
  && !processing_debug_stmt)
add_referenced_var (*tp);
@@ -1119,8 +1119,8 @@ copy_tree_body_r (tree *tp, int *walk_su
 
   /* Global variables we haven't seen yet needs to go into referenced
 vars.  If not referenced from types or debug stmts only.  */
-  if (gimple_in_ssa_p (cfun)
- && TREE_CODE (*tp) == VAR_DECL
+  if (gimple_referenced_vars (cfun)
+ && TREE_CODE (*tp) == VAR_DECL && !is_global_var (*tp)
  && id->remapping_type_depth == 0
  && !processing_debug_stmt)
add_referenced_var (*tp);
@@ -2604,11 +2604,11 @@ setup_one_parameter (copy_body_data *id,
   /* We are eventually using the value - make sure all variables
  referenced therein are properly recorded.  */
   if (value
-  && gimple_in_ssa_p (cfun)
+  && gimple_referenced_vars (cfun)
   && TREE_CODE (value) == ADDR_EXPR)
 {
   tree base = get_base_address (TREE_OPERAND (value, 0));
-  if (base && TREE_CODE (base) == VAR_DECL)
+  if (base && TREE_CODE (base) == VAR_DECL && !is_global_var (base))
add_referenced_var (base);
 }
 
@@ -2917,7 +2917,7 @@ declare_return_variable (copy_body_data
   gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (callee_type)) == INTEGER_CST);
 
   var = copy_result_decl_to_var (result, id);
-  if (gimple_in_ssa_p (cfun))
+  if (gimple_referenced_vars (cfun))
 add_referenced_var (var);
 
   DECL_SEEN_IN_BIND_EXPR_P (var) = 1;
@@ -2978,7 +2978,7 @@ declare_return_variable (copy_body_data
   && !is_gimple_val (var))
 {
   tree temp = create_tmp_var (TREE_TYPE (result), "retvalptr");
-  if (gimple_in_ssa_p (id->src_cfun))
+  if (gimple_referenced_vars (cfun))
add_referenced_var (temp);
   insert_decl_map (id, result, temp);
   /* When RESULT_DECL is in SSA form, we need to remap and initialize
@@ -5194,10 +5194,8 @@ tree_function_versioning (tree old_decl,
 
if (TREE_CODE (op) == ADDR_EXPR)
  {
-   op = TREE_OPERAND (op, 0);
-   while (handled_component_p (op))
- op = TREE_OPERAND (op, 0);
-   if (TREE_CODE (op) == VAR_DECL)
+   op = get_base_address (TREE_OPERAND (op, 0));
+   if (op && TREE_CODE (op) == VAR_DECL && !is_global_var (op))
  add_referenced_var (op);
  }
   

Re: [patch] More thorough checking in reg_fits_class_p

[Marcus Shawcroft]

On 21/05/12 15:47, Richard Earnshaw wrote:

On 17/05/12 14:23, Jim MacArthur wrote:


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.



OK.

R.




Jim, I've committed your patch.

/Marcus

[PATCH] Fix VRP VR_UNDEFINED handling (PR tree-optimization/53465))

[Jakub Jelinek]

Hi!

As discussed in the PR and on IRC, when UNDEFINED meets some vr with
equivalences in it, we need to drop the equivalences, at least when
the equivalenced SSA_NAME definition doesn't dominate the PHI stmt.
The change in vrp_visit_phi_node is needed because otherwise vrp_meet
would drop the equivalences even when it should not.
The extract_range_from_cond_expr change is because when vrp_meet is
called first, we might remove some equivalences even from the original
SSA_NAME's vr.

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

2012-05-24  Jakub Jelinek  

PR tree-optimization/53465
* tree-vrp.c (extract_range_from_cond_expr): First copy_value_range
vr0 into *vr, then vrp_meet that.
(vrp_meet): If one vr type is VR_UNDEFINED, ensure the result doesn't
have any equivalences.
(vrp_visit_phi_node): Call copy_value_range instead of vrp_meet the
first time.

* gcc.c-torture/execute/pr53465.c: New test.

--- gcc/tree-vrp.c.jj   2012-05-17 08:40:45.0 +0200
+++ gcc/tree-vrp.c  2012-05-24 10:36:50.433325234 +0200
@@ -3282,8 +3282,8 @@ extract_range_from_cond_expr (value_rang
 set_value_range_to_varying (&vr1);
 
   /* The resulting value range is the union of the operand ranges */
-  vrp_meet (&vr0, &vr1);
   copy_value_range (vr, &vr0);
+  vrp_meet (vr, &vr1);
 }
 
 
@@ -6888,13 +6888,17 @@ vrp_meet (value_range_t *vr0, value_rang
 {
   if (vr0->type == VR_UNDEFINED)
 {
-  copy_value_range (vr0, vr1);
+  /* Drop equivalences.  See PR53465.  */
+  set_value_range (vr0, vr1->type, vr1->min, vr1->max, NULL);
   return;
 }
 
   if (vr1->type == VR_UNDEFINED)
 {
-  /* Nothing to do.  VR0 already has the resulting range.  */
+  /* VR0 already has the resulting range, just drop equivalences.
+See PR53465.  */
+  if (vr0->equiv)
+   bitmap_clear (vr0->equiv);
   return;
 }
 
@@ -7036,6 +7040,7 @@ vrp_visit_phi_node (gimple phi)
   tree lhs = PHI_RESULT (phi);
   value_range_t *lhs_vr = get_value_range (lhs);
   value_range_t vr_result = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
+  bool first = true;
   int edges, old_edges;
   struct loop *l;
 
@@ -7092,7 +7097,11 @@ vrp_visit_phi_node (gimple phi)
  fprintf (dump_file, "\n");
}
 
- vrp_meet (&vr_result, &vr_arg);
+ if (first)
+   copy_value_range (&vr_result, &vr_arg);
+ else
+   vrp_meet (&vr_result, &vr_arg);
+ first = false;
 
  if (vr_result.type == VR_VARYING)
break;
--- gcc/testsuite/gcc.c-torture/execute/pr53465.c.jj2012-05-24 
10:34:16.867240005 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr53465.c   2012-05-24 
10:33:28.0 +0200
@@ -0,0 +1,30 @@
+/* PR tree-optimization/53465 */
+
+extern void abort ();
+
+static const int a[] = { 1, 2 };
+
+void
+foo (const int *x, int y)
+{
+  int i;
+  int b = 0;
+  int c;
+  for (i = 0; i < y; i++)
+{
+  int d = x[i];
+  if (d == 0)
+   break;
+  if (b && d <= c)
+   abort ();
+  c = d;
+  b = 1;
+}
+}
+
+int
+main ()
+{
+  foo (a, 2);
+  return 0;
+}

Jakub

Re: [PATCH] Fix VRP VR_UNDEFINED handling (PR tree-optimization/53465))

[Richard Guenther]

On Thu, May 24, 2012 at 1:41 PM, Jakub Jelinek  wrote:
> Hi!
>
> As discussed in the PR and on IRC, when UNDEFINED meets some vr with
> equivalences in it, we need to drop the equivalences, at least when
> the equivalenced SSA_NAME definition doesn't dominate the PHI stmt.
> The change in vrp_visit_phi_node is needed because otherwise vrp_meet
> would drop the equivalences even when it should not.
> The extract_range_from_cond_expr change is because when vrp_meet is
> called first, we might remove some equivalences even from the original
> SSA_NAME's vr.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.7?

Ok.

Thanks,
Richard.

> 2012-05-24  Jakub Jelinek  
>
>        PR tree-optimization/53465
>        * tree-vrp.c (extract_range_from_cond_expr): First copy_value_range
>        vr0 into *vr, then vrp_meet that.
>        (vrp_meet): If one vr type is VR_UNDEFINED, ensure the result doesn't
>        have any equivalences.
>        (vrp_visit_phi_node): Call copy_value_range instead of vrp_meet the
>        first time.
>
>        * gcc.c-torture/execute/pr53465.c: New test.
>
> --- gcc/tree-vrp.c.jj   2012-05-17 08:40:45.0 +0200
> +++ gcc/tree-vrp.c      2012-05-24 10:36:50.433325234 +0200
> @@ -3282,8 +3282,8 @@ extract_range_from_cond_expr (value_rang
>     set_value_range_to_varying (&vr1);
>
>   /* The resulting value range is the union of the operand ranges */
> -  vrp_meet (&vr0, &vr1);
>   copy_value_range (vr, &vr0);
> +  vrp_meet (vr, &vr1);
>  }
>
>
> @@ -6888,13 +6888,17 @@ vrp_meet (value_range_t *vr0, value_rang
>  {
>   if (vr0->type == VR_UNDEFINED)
>     {
> -      copy_value_range (vr0, vr1);
> +      /* Drop equivalences.  See PR53465.  */
> +      set_value_range (vr0, vr1->type, vr1->min, vr1->max, NULL);
>       return;
>     }
>
>   if (vr1->type == VR_UNDEFINED)
>     {
> -      /* Nothing to do.  VR0 already has the resulting range.  */
> +      /* VR0 already has the resulting range, just drop equivalences.
> +        See PR53465.  */
> +      if (vr0->equiv)
> +       bitmap_clear (vr0->equiv);
>       return;
>     }
>
> @@ -7036,6 +7040,7 @@ vrp_visit_phi_node (gimple phi)
>   tree lhs = PHI_RESULT (phi);
>   value_range_t *lhs_vr = get_value_range (lhs);
>   value_range_t vr_result = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
> +  bool first = true;
>   int edges, old_edges;
>   struct loop *l;
>
> @@ -7092,7 +7097,11 @@ vrp_visit_phi_node (gimple phi)
>              fprintf (dump_file, "\n");
>            }
>
> -         vrp_meet (&vr_result, &vr_arg);
> +         if (first)
> +           copy_value_range (&vr_result, &vr_arg);
> +         else
> +           vrp_meet (&vr_result, &vr_arg);
> +         first = false;
>
>          if (vr_result.type == VR_VARYING)
>            break;
> --- gcc/testsuite/gcc.c-torture/execute/pr53465.c.jj    2012-05-24 
> 10:34:16.867240005 +0200
> +++ gcc/testsuite/gcc.c-torture/execute/pr53465.c       2012-05-24 
> 10:33:28.0 +0200
> @@ -0,0 +1,30 @@
> +/* PR tree-optimization/53465 */
> +
> +extern void abort ();
> +
> +static const int a[] = { 1, 2 };
> +
> +void
> +foo (const int *x, int y)
> +{
> +  int i;
> +  int b = 0;
> +  int c;
> +  for (i = 0; i < y; i++)
> +    {
> +      int d = x[i];
> +      if (d == 0)
> +       break;
> +      if (b && d <= c)
> +       abort ();
> +      c = d;
> +      b = 1;
> +    }
> +}
> +
> +int
> +main ()
> +{
> +  foo (a, 2);
> +  return 0;
> +}
>
>        Jakub

[PATCH] Fix PR53406

[Richard Guenther]

This fixes PR53406, calling execute_fixup_cfg may need a subsequent
cfg-cleanup run.

Profiledbootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2012-05-24  Richard Guenther  

PR middle-end/53460
* tree-profile.c (tree_profiling): Cleanup the CFG if
execute_fixup_cfg requests it.

* g++.dg/tree-prof/pr53460.C: New testcase.

Index: gcc/tree-profile.c
===
--- gcc/tree-profile.c  (revision 187769)
+++ gcc/tree-profile.c  (working copy)
@@ -497,7 +497,8 @@ tree_profiling (void)
   gcov_type_tmp_var = NULL_TREE;
 
   /* Local pure-const may imply need to fixup the cfg.  */
-  execute_fixup_cfg ();
+  if (execute_fixup_cfg () & TODO_cleanup_cfg)
+   cleanup_tree_cfg ();
   branch_prob ();
 
   if (! flag_branch_probabilities
Index: gcc/testsuite/g++.dg/tree-prof/pr53460.C
===
--- gcc/testsuite/g++.dg/tree-prof/pr53460.C(revision 0)
+++ gcc/testsuite/g++.dg/tree-prof/pr53460.C(revision 0)
@@ -0,0 +1,25 @@
+// { dg-options "-O" }
+
+template class OwnPtr {
+public:
+~OwnPtr();
+};
+template class GlyphMetricsMap {
+public:
+GlyphMetricsMap() { }
+OwnPtr m_pages;
+};
+class SimpleFontData {
+public:
+void boundsForGlyph() const;
+};
+inline __attribute__((__always_inline__))
+void SimpleFontData::boundsForGlyph() const
+{
+  new GlyphMetricsMap;
+}
+void offsetToMiddleOfGlyph(const SimpleFontData* fontData)
+{
+  fontData->boundsForGlyph();
+}
+int main() {}

Re: fix install-no-fixedincludes mishaps

[Olivier Hainque]

On May 24, 2012, at 06:18 , Ian Lance Taylor wrote:
>>(install-unwind_h): Reinstate, copy to user install destination
>>for include files, not to the internal gcc object directory one.
>>(install-leaf): Depend on it.
> 
> The effect is that every time libgcc is built, unwind.h
> changes.  And the effect of that is that every library file that depends on
> unwind.h gets rebuilt every time.  This affects libgo and libitm.

> Please fix this one way or another so that the copy of unwind.h installed
> in the gcc object directory does not have its timestamp change if the
> file contents are unchanged, as it used to be.

 Sure, sorry for the inconvenience. The intent was to

 * not touch what used to be done for "all", with

   -install-unwind_h:
   +install-unwind_h-forbuild:

   -all: install-unwind_h
   +all: install-unwind_h-forbuild

 * add something to have unwind.h copied as well for "install".

   I added that via an extra rule+dep to install-leaf, thinking that
   it was only used as helper for "install". I missed that install-leaf
   is also invoked for "all", via a command and not a dep.

 The attached patch should fix it. Testing in progress ...

 Olivier

 2012-05-24  Olivier Hainque  

libgcc/
* Makefile.in: move dependency on install-unwind_h from
"install-leaf" to "install".



unwh.diff
Description: Binary data

Re: Continue strict-volatile-bitfields fixes

[Thomas Schwinge]

Hi!

Ping.

On Wed, 16 May 2012 19:14:45 +0200, I wrote:
> Ping.
> 
> On Wed, 09 May 2012 10:01:55 +0800, I wrote:
> > On Fri, 27 Apr 2012 10:29:06 +0200, Jakub Jelinek  wrote:
> > > On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote:
> > > > > > GET_MODE_BITSIZE (lmode)« (8 bits).  (With the current sources, 
> > > > > > lmode is
> > > > > > VOIDmode.)
> > > > > >
> > > > > > Is emmitting »BIT_FIELD_REF <*common, 32, 0> & 255« wrong in this 
> > > > > > case,
> > > > > > or should a later optimization pass be able to figure out that
> > > > > > »BIT_FIELD_REF <*common, 32, 0> & 255« is in fact the same as
> > > > > > common->code, and then be able to conflate these?  Any suggestions
> > > > > > where/how to tackle this?
> > > > > 
> > > > > The BIT_FIELD_REF is somewhat of a red-herring.  It is created by 
> > > > > fold-const.c
> > > > > in optimize_bit_field_compare, code that I think should be removed 
> > > > > completely.
> > > > > Or it needs to be made aware of strict-volatile bitfield and C++ 
> > > > > memory model
> > > > > details.
> > > 
> > > I'd actually very much prefer the latter, just disable
> > > optimize_bit_field_compare for strict-volatile bitfield mode and when
> > > avoiding load data races in C++ memory model (that isn't going to be
> > > default, right?).  This optimization is useful, and it is solely about
> > > loads, so even C++ memory model usually shouldn't care.
> > 
> > I can't comment on the C++ memory model bits, but I have now tested the
> > following patch (fixes the issue for SH, no regressions for ARM, x86):
> > 
> > gcc/
> > * fold-const.c (optimize_bit_field_compare): Abort early in the strict
> > volatile bitfields case.
> > 
> > Index: fold-const.c
> > ===
> > --- fold-const.c(revision 186856)
> > +++ fold-const.c(working copy)
> > @@ -3342,6 +3342,11 @@ optimize_bit_field_compare (location_t loc, enum t
> >tree mask;
> >tree offset;
> >  
> > +  /* In the strict volatile bitfields case, doing code changes here may 
> > prevent
> > + other optimizations, in particular in a SLOW_BYTE_ACCESS setting.  */
> > +  if (flag_strict_volatile_bitfields > 0)
> > +return 0;
> > +
> >/* Get all the information about the extractions being done.  If the bit 
> > size
> >   if the same as the size of the underlying object, we aren't doing an
> >   extraction at all and so can do nothing.  We also don't want to


Grüße,
 Thomas


pgppDuQupdsW3.pgp
Description: PGP signature

[PATCH] Add testcase for PR53466

[Richard Guenther]

Committed.

Richard.

2012-05-24  Richard Guenther  

PR bootstrap/53466
* g++.dg/debug/pr53466.C: New testcase.

Index: gcc/testsuite/g++.dg/debug/pr53466.C
===
--- gcc/testsuite/g++.dg/debug/pr53466.C(revision 0)
+++ gcc/testsuite/g++.dg/debug/pr53466.C(revision 0)
@@ -0,0 +1,39 @@
+// { dg-do compile }
+// { dg-options "-foptimize-sibling-calls -fcompare-debug" }
+
+typedef union gimple_statement_d *gimple;
+typedef gimple gimple_seq_node;
+typedef struct {
+gimple_seq_node ptr;
+void *seq;
+void *bb;
+} gimple_stmt_iterator;
+struct gimple_statement_base {
+gimple next;
+};
+union gimple_statement_d {
+struct gimple_statement_base gsbase;
+};
+static inline gimple_stmt_iterator gsi_start_1 (gimple stmt)
+{
+  gimple_stmt_iterator i;
+  i.ptr = stmt;
+  return i;
+}
+bool gimple_may_fallthru (gimple);
+static bool gimple_try_catch_may_fallthru (gimple stmt)
+{
+  gimple_stmt_iterator i = gsi_start_1 (stmt);
+  for (; i.ptr; i.ptr = i.ptr->gsbase.next)
+{
+  if (gimple_may_fallthru (i.ptr))
+   return true;
+}
+}
+bool gimple_stmt_may_fallthru (gimple stmt, bool x)
+{
+  if (x)
+return gimple_may_fallthru (stmt);
+  else
+return gimple_try_catch_may_fallthru (stmt);
+}

Re: Continue strict-volatile-bitfields fixes

[Jakub Jelinek]

On Thu, May 24, 2012 at 02:29:18PM +0200, Thomas Schwinge wrote:
> Hi!
> 
> Ping.

Ok.

> > >   * fold-const.c (optimize_bit_field_compare): Abort early in the strict
> > >   volatile bitfields case.
> > > 
> > > Index: fold-const.c
> > > ===
> > > --- fold-const.c  (revision 186856)
> > > +++ fold-const.c  (working copy)
> > > @@ -3342,6 +3342,11 @@ optimize_bit_field_compare (location_t loc, enum t
> > >tree mask;
> > >tree offset;
> > >  
> > > +  /* In the strict volatile bitfields case, doing code changes here may 
> > > prevent
> > > + other optimizations, in particular in a SLOW_BYTE_ACCESS setting.  
> > > */
> > > +  if (flag_strict_volatile_bitfields > 0)
> > > +return 0;
> > > +
> > >/* Get all the information about the extractions being done.  If the 
> > > bit size
> > >   if the same as the size of the underlying object, we aren't doing an
> > >   extraction at all and so can do nothing.  We also don't want to

Jakub

Re: [C++ Patch] PR 32080

[Jason Merrill]

OK.

Jason

Re: [C++ Patch] for c++/51214

[Jason Merrill]

OK, thanks.

Jason

Re: [cxx-conversion] Convert vec.[ch] to C++ [1/3] (issue6233044)

[Gabriel Dos Reis]

On Wed, May 23, 2012 at 2:48 PM, Diego Novillo  wrote:
>
> This series of 3 patches re-implement vec.[ch] in C++.
>

this is fantastic! The changes look good to me.

-- Gaby

Re: fix install-no-fixedincludes mishaps

[Olivier Hainque]

Hello Ian,

On May 24, 2012, at 14:22 , Olivier Hainque wrote:
>   libgcc/
>   * Makefile.in: move dependency on install-unwind_h from
>   "install-leaf" to "install".

 Testing went fine for me. Here is what I checked:

 For a pristine tree:

   configure --enable-languages=c --disable-libada --disable-multilib 
--disable-bootstrap 
   make
   find . -name unwind.h -ls > ls0
   make maintainer-clean-target-libgcc
   make (*)
   find . -name unwind.h -ls > ls1

   diff ls0 ls1 indeed shows

   < 4883963   12 -rw-r--r--   1 hainque  users   10246 May 24 14:42 
./gcc/include/unwind.h
   > 4883963   12 -rw-r--r--   1 hainque  users   10246 May 24 15:00 
./gcc/include/unwind.h

 (*) For this sequence to work, I had to change libgcc_tm.h into libgcc_tm.stamp
 in the list of files removed by "clean:" in libgcc/Makefile.in. Otherwise 
the
 second make fails to rebuild libgcc, complaining about libgcc_tm.h missing
 (removed by clean and not rebuilt because .stamp remained there).

 On a tree with the patch applied, the difference on gcc/include/unwind.h 
before and after the
 rebuild disappears.
 
 I also checked that unwind.h remains copied by install-no-fixedincludes.

 OK to apply ?

libgcc/
* Makefile.in: move dependency on install-unwind_h from
"install-leaf" to "install".

Re: [cxx-conversion] Convert vec.[ch] to C++ [1/3] (issue6233044)

[Gabriel Dos Reis]

On Thu, May 24, 2012 at 3:16 AM, Richard Guenther
 wrote:

>> Some client code changes were needed:
>>
>> 1- The allocation names 'heap', 'stack' and 'gc' are not embedded in
>>   the type name anymore.  They are enum values used as a template
>>   argument for functions like VEC_alloc() and VEC_free().  Since they
>>   are now separate identifiers, some existing code that declared
>>   variables with the names 'heap' and 'stack' had to change.
>>
>>   I did not change these enum values to better names because that
>>   would have meant changing a lot more client code.  I will change
>>   this in a future patch.
>
> Yeah.  Can we have
>
> template <...>
> struct vec {
>   enum { gc, heap, stack };
> ...
> }
>
> and use vec instead?  Not sure if this or something similar
> is valid C++.

It isn't valid.  But, you probably want someting like

namespace store {
enum kind {
 gc, heap, stack
}
}

template
struct vec_t {
   // 
}

vec_t

or variations of this.

-- Gaby

Re: [cxx-conversion] Convert vec.[ch] to C++ [2/3] (issue6236043)

[Gabriel Dos Reis]

On Thu, May 24, 2012 at 3:24 AM, Richard Guenther
 wrote:
> On Wed, May 23, 2012 at 9:49 PM, Diego Novillo  wrote:
>>
>> Part 2 of the VEC C++ conversion.  This patch implements the gengtype
>> changes.
>>
>> I extended gengtype to understand templated types.  These changes are
>> not as ugly as I thought they would be.  Gengtype has some hardwired
>> knowledge of VEC_*, which I renamed to vec_t.  I'm not even sure why
>> gengtype needs to care about vec_t in this way, but I was looking for
>> minimal changes, so I just did it.
>>
>> The other change is more generic.  It allows gengtype to deal with
>> templated types.  There is a new function (filter_type_name) that
>> recognizes C++ special characters '<', '>' and ':'.  It turns them
>> into '_'.  This way, gengtype can generate a valid identifier for the
>> pre-processor.  It only does this in contexts where it needs a
>> pre-processor identifier.  For everything else, it emits the type
>> directly.  So, the functions emitted in gt-*.h files have proper
>> template type references.
>
> This is, of course, just a replacement of special-case handling for vec.h
> with another special-case handling.  It does not show us how templated
> structs should work with gengtype in general.  And no, I don't think
> gengtype should keep the special-case for vec.h.
>
> The point was to make all the gt_ggc_* functions function template
> specializations so the code gengtype emits for walking a structs fields
> would be just
>
>   mark (field1);
>   mark (field2);
>  ...
>
> and we could manually provide specializations for selected types
> (well, the templates).  Add a GTY((template)) marker to make gengtype
> not emit the specializations itself (or simply make it recognize template
> types and do nothing for them).

True, but as a preliminary step (and a member of a series of patches), it does
make sense and is good to have.

-- Gaby

Re: [PATCH][4/n] referenced-vars TLC

[H.J. Lu]

On Thu, May 24, 2012 at 12:12 AM, Richard Guenther  wrote:
> On Wed, 23 May 2012, H.J. Lu wrote:
>
>> On Wed, May 23, 2012 at 5:00 AM, Richard Guenther  wrote:
>> >
>> > This finally switches us to not record global vars in referenced-vars.
>> > For this to work I had to re-engineer how we handle global var removal
>> > from local-decls in remove_unused_locals.  Incidentially that code
>> > already had some sort of a bitmap (for some weird reason even), thus
>> > I borrowed that and simplified the handling.  You may notice that
>> > it would be easy to handle all vars that way ...
>> >
>> > So eventually 5/n will make referenced-vars go away completely
>> > (the only serious user seems to be the SSA renamer for its
>> > SYMS_TO_RENAME bitmap).
>> >
>> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>> >
>> > Richard.
>> >
>> > 2012-05-23  Richard Guenther  
>> >
>> >        * tree-dfa.c (add_referenced_var_1): Do not add global vars.
>> >        * tree-ssa-live.c (mark_all_vars_used_1): Handle global vars
>> >        via the global_unused_vars bitmap.
>> >        (remove_unused_locals): Handle global vars in local-decls via
>> >        a global_unused_vars bitmap instead of the used flag in the
>> >        var annotation.  Simplify global variable handling and removal.
>> >
>>
>> This breaks bootstrap on Linux/x86-64:
>>
>> http://gcc.gnu.org/ml/gcc-regression/2012-05/msg00468.html
>>
>> Comparing stages 2 and 3
>> warning: gcc/cc1plus-checksum.o differs
>> warning: gcc/cc1obj-checksum.o differs
>> warning: gcc/cc1-checksum.o differs
>> Bootstrap comparison failure!
>> gcc/trans-mem.o differs
>> gcc/gimple-low.o differs
>> gcc/sese.o differs
>> make[5]: *** [compare] Error 1
>>
>> Please make sure that your compiler used for bootstrap
>> doesn't add anything to .comment section, which will
>> disable debug compare.
>
> Well, I can't.  Why is debug compare so fragile?  Now trying to find
> a way to reproduce (I can't see why it should cause this ...)
>

I opened:

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


-- 
H.J.

PATCH: PR bootstrap/53472: contrib/compare-debug should strip out .comment section

[H.J. Lu]

Hi,

configure checks if contrib/compare-debug actually works for comparing a
debug and non-debug .o file before enabling bootstrap-debug.  But some
compilers encode some command line options (among them -g) into a special
.comment section.  This patch removes .comment section before comparing
debug and non-debug files.  OK for trunk?

Thanks.

H.J.

2012-05-24  H.J. Lu  

PR bootstrap/53472
* contrib/compare-debug: Also remove .comment section.

diff --git a/contrib/compare-debug b/contrib/compare-debug
index 010d17f..c3eb659 100755
--- a/contrib/compare-debug
+++ b/contrib/compare-debug
@@ -73,6 +73,12 @@ Darwin)
   ;;
 esac
 
+# Also remove .comment section.
+if (objcopy -v) 2>&1 | grep ' --remove-section' > /dev/null; then
+  objcopy --remove-section .comment "$1.$suf1"
+  objcopy --remove-section .comment "$2.$suf2"
+fi
+
 if cmp "$1.$suf1" "$2.$suf2"; then
   status=0
 else

Re: fix install-no-fixedincludes mishaps

[Paolo Bonzini]

Il 24/05/2012 15:32, Olivier Hainque ha scritto:
> Hello Ian,
> 
> On May 24, 2012, at 14:22 , Olivier Hainque wrote:
>>  libgcc/
>>  * Makefile.in: move dependency on install-unwind_h from
>>  "install-leaf" to "install".
> 
>  Testing went fine for me. Here is what I checked:
> 
>  For a pristine tree:
> 
>configure --enable-languages=c --disable-libada --disable-multilib 
> --disable-bootstrap 
>make
>find . -name unwind.h -ls > ls0
>make maintainer-clean-target-libgcc
>make (*)
>find . -name unwind.h -ls > ls1
> 
>diff ls0 ls1 indeed shows
> 
>< 4883963   12 -rw-r--r--   1 hainque  users   10246 May 24 14:42 
> ./gcc/include/unwind.h
>> 4883963   12 -rw-r--r--   1 hainque  users   10246 May 24 15:00 
> ./gcc/include/unwind.h
> 
>  (*) For this sequence to work, I had to change libgcc_tm.h into 
> libgcc_tm.stamp
>  in the list of files removed by "clean:" in libgcc/Makefile.in. 
> Otherwise the
>  second make fails to rebuild libgcc, complaining about libgcc_tm.h 
> missing
>  (removed by clean and not rebuilt because .stamp remained there).

I think you need to remove both files?  Can you send a patch for that?

>  On a tree with the patch applied, the difference on gcc/include/unwind.h 
> before and after the
>  rebuild disappears.
>  
>  I also checked that unwind.h remains copied by install-no-fixedincludes.
> 
>  OK to apply ?

Ok.

Paolo

Re: [cxx-conversion] Convert vec.[ch] to C++ [1/3] (issue6233044)

[Diego Novillo]

On 12-05-24 04:20 , Andrew Pinski wrote:

On Thu, May 24, 2012 at 1:16 AM, Richard Guenther
  wrote:


I believe this was because of aliasing - you may dig in the svn history
to find out what we miscompiled when not doing this and whether it is
still necessary or not.


Yes it was done for aliasing reasons (I did this change).  In fact it
is still necessary and it was only reproduciable with LTO and -O3.


No tests fail with all languages enabled (including Ada and Go), 
profiled+LTO bootstrap works.  If you added a test for this, it is now 
working.  If not, could you please add one?


In any case, it is very likely that I will refactor this data structure 
again so I can make vectors one word structures, so that I can implement 
operator[].



Diego.

Re: [cxx-conversion] Convert vec.[ch] to C++ [2/3] (issue6236043)

[Diego Novillo]

On 12-05-24 04:24 , Richard Guenther wrote:


and we could manually provide specializations for selected types
(well, the templates).  Add a GTY((template)) marker to make gengtype
not emit the specializations itself (or simply make it recognize template
types and do nothing for them).


Patience.  One patch at a time.


Diego.

Re: [cxx-conversion] Convert vec.[ch] to C++ [1/3] (issue6233044)

[Diego Novillo]

On 12-05-24 04:16 , Richard Guenther wrote:

On Wed, May 23, 2012 at 9:48 PM, Diego Novillo  wrote:


This series of 3 patches re-implement vec.[ch] in C++.

The main goal of this first step is to minimize changes to client
code.  I tried very hard to maintain the existing API.  This means
that vectors are still simple structures accessed via the existing
VEC_* functions.

The major change introduced here is the removal of all the macro-based
type creation in vec.h:

1- Given a type T and an allocation strategy A, VEC(T,A) used to
   expand into the C type 'struct VEC_T_A'.  The family of accessor
   functions for VEC_T_A were created via macro expansion and token
   pasting.

   After this patch, VEC(T,A) expands to 'vec_t':

template
struct GTY(()) vec_t
{
  vec_prefix prefix;
  T GTY((length ("%h.prefix.num"))) vec[1];
};

   The family of accessor functions for vec_t  are free functions
   templated on  or  depending on whether the function needs
   to perform allocation operations.

2- All the DEF_VEC_[IOP] and DEF_VEC_ALLOC_[IOP] macros expand to the
   nil expansion 'struct vec_swallow_trailing_semi'.  This represents
   the bulk of the removal in vec.h.

3- I removed one indirection from the existing VEC structures.  Before
   this patch, the visible structure created by VEC_T_A had a single
   element 'base', which, in turn, was the structure holding 'prefix'
   and 'vec'.  The new vec_t  has 'prefix' and 'vec' in it.  This
   may change in the second iteration of this patch.


I believe this was because of aliasing - you may dig in the svn history
to find out what we miscompiled when not doing this and whether it is
still necessary or not.


Some client code changes were needed:

1- The allocation names 'heap', 'stack' and 'gc' are not embedded in
   the type name anymore.  They are enum values used as a template
   argument for functions like VEC_alloc() and VEC_free().  Since they
   are now separate identifiers, some existing code that declared
   variables with the names 'heap' and 'stack' had to change.

   I did not change these enum values to better names because that
   would have meant changing a lot more client code.  I will change
   this in a future patch.


Yeah.  Can we have

template<...>
struct vec {
enum { gc, heap, stack };
...
}

and use vec  instead?  Not sure if this or something similar
is valid C++.


Sure.  Something involving a new namespace, like Gaby suggested down-thread.




2- VEC_index and VEC_last now return a reference to the element.  The
   existing APIs implemented two versions of these functions.  One
   returning the element itself (used for vec_t).  Another returning
   a pointer to the element (used for vec_t).

   This is impossible to represent in C++ directly, as functions
   cannot be overloaded by their return value.  Instead, I made them
   return a reference to the element.  This means that vectors storing
   pointers (T *) do not need to change, but vectors of objects (T) do
   need to change.

   We have fewer vec_t  than vec_t, so this was the smaller change
   (which still meant changing a few hundred call sites).


We still can have const overloads when taking a const vec though?


I'm going to say 'sure' because I don't really think I understand this 
question :)



3- The family of VEC_*push and VEC_*replace functions have overloads
   for handling 'T' and 'const T *' objects.  The former is used for
   vec_t, the latter for vec_t.  This means, however, than when
   pushing the special value 0 on a vec_t, the compiler will not
   know which overload we meant, as 0 matches both.  In these cases
   (not very many), a static cast is all we need to help it.

   I'm not terribly content with this one.  I'll try to have a better
   approach in the second iteration (which will liberally change all
   client code).


I wonder whether explicitely specifying the template type is better?  Thus,
VEC_safe_push(0) instead of automatically deducing the template
argument?


Not sure.  I didn't like the casts, Lawrence had another suggestion 
involving something like C++11's nullptr.  Lawrence, what was that 
nullptr thing you were telling me earlier?





4- I extended gengtype to understand templated types.  These changes
   are not as ugly as I thought they would be.  Gengtype has some
   hardwired knowledge of VEC_*, which I renamed to vec_t.  I'm not
   even sure why gengtype needs to care about vec_t in this way, but I
   was looking for minimal changes, so I just did it.

   The other change is more generic.  It allows gengtype to deal with
   templated types.  There is a new function (filter_type_name) that
   recognizes C++ special characters '<','>' and ':'.  It turns them
   into '_'.  This way, gengtype can generate a valid identifier for
   the pre-processor.  It only does this in contexts where it needs a
   pre-processor identifier.  For everything else, it emits the ty

Re: [PATCH, rs6000] Fix insertion of nop[s] to force dependent load into new dispatch group.

[David Edelsohn]

On Wed, May 23, 2012 at 11:48 AM, Pat Haugen
 wrote:
> The following patch fixes existing code that tried to prevent load-hit-store
> (LHS) from being in the same dispatch group. The main problem was use of the
> wrong dependency list in is_costly_group(), but I also added code to verify
> the memory refs overlap and to emit group ending nops for those ISAs that
> have them.
>
> Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk?
>
> -Pat
>
>
> 2012-05-23  Pat Haugen 
>
>        * config/rs6000/rs6000.c (rs6000_option_override_internal): Change
>        rs6000_sched_costly_dep default to true_store_to_load_dep_costly.
>        (adjacent_mem_locations): Move some code to and call...
>        (get_memref_parts): ...new function.
>        (mem_locations_overlap): New function.
>        (rs6000_adjust_priority): Adjust calls to is_load_insn/is_store_insn.
>        (is_mem_ref): Rename to...
>        (find_mem_ref): ...this. Return MEM rtx.
>        (get_store_dest): Remove function.
>        (is_load_insn1, is_load_insn, is_store_insn1, is_store_insn): Add
>        new parameter and adjust calls.
>        (rs6000_is_costly_dependence): Update calls for extra arg. Make sure
>        mem refs overlap for true_store_to_load_dep_costly.
>        (rs6000_sched_reorder2): Update calls for extra arg. Adjust args
>        passed to adjacent_mem_locations.
>        (is_costly_group): Walk resolved dependency list.
>        (force_new_group): Emit group ending nop for Power6/Power7.
>        * config/rs6000/rs6000.md (UNSPEC_GRP_END_NOP): New enum value.
>        (group_ending_nop): New define_insn.
>
> gcc/testsuite:
>        * gcc.target/powerpc/lhs-1.c: New.
>        * gcc.target/powerpc/lhs-2.c: New.
>        * gcc.target/powerpc/lhs-3.c: New.

I thought there was common infrastructure for recursively walking an
insn for use in the memref comparison code, but, as you mentioned
privately, other parts of GCC implement it manually.


+/* Determine is PAT refers to memory. If so, set MEM_REF to the MEM rtx
+   and return true.  */

I assume you mean "... if PAT" not "is PAT".

Okay with that typo fix.

Thanks, David

Re: [cxx-conversion] Convert vec.[ch] to C++ [1/3] (issue6233044)

[Diego Novillo]

I have committed these three patches as a single revision r187836 on 
cxx-conversion.


I will address further comments to the patch in subsequent changes.

Andrew, if you have some time, could you see if you can recreate that 
LTO aliasing failure you were describing earlier?


I may change the data structure again, but it would still be interesting 
to have a test for it.



Thanks.  Diego.

Re: fix install-no-fixedincludes mishaps

[Olivier Hainque]

On May 24, 2012, at 16:01 , Paolo Bonzini wrote:
>> (*) For this sequence to work, I had to change libgcc_tm.h into 
>> libgcc_tm.stamp
>> in the list of files removed by "clean:" in libgcc/Makefile.in.

> I think you need to remove both files?

 Agreed. The .h is generated and needs to be removed by "make clean".
 
>  Can you send a patch for that?

 Sure. Attached. The use of a separate command for stamp removals
 is only to avoid an overlong line.

2012-05-24  Olivier Hainque  

libgcc/
* Makefile.in (clean): Remove libgcc_tm.stamp as well.
Use a separate command for stamp removals.


libgcc_tm.diff
Description: Binary data

Re: fix install-no-fixedincludes mishaps

[Paolo Bonzini]

Il 24/05/2012 16:31, Olivier Hainque ha scritto:
> 
> On May 24, 2012, at 16:01 , Paolo Bonzini wrote:
>>> (*) For this sequence to work, I had to change libgcc_tm.h into 
>>> libgcc_tm.stamp
>>> in the list of files removed by "clean:" in libgcc/Makefile.in.
> 
>> I think you need to remove both files?
> 
>  Agreed. The .h is generated and needs to be removed by "make clean".
>  
>>  Can you send a patch for that?
> 
>  Sure. Attached. The use of a separate command for stamp removals
>  is only to avoid an overlong line.
> 
> 2012-05-24  Olivier Hainque  
> 
>   libgcc/
>   * Makefile.in (clean): Remove libgcc_tm.stamp as well.
>   Use a separate command for stamp removals.

Ok, thanks.

Paolo

[Patch, Fortran] PR45170 - Fix deferred-length issue

[Tobias Burnus]

This patch fixes an ordering problem with deferred string lengths. For

  str = str2(:nn)

where "nn" is a something a tad more complicated than a local variable 
(e.g. a non-VALUE dummy argument), the result was wrong: the temporary 
variable with the string length was used before it was set.


The attached patch fixes the issue. However, I wonder whether the block 
should/could always be added.


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

 * * *

Remaining deferred-length issues:

- PR 47674: a = a(:n); reallocation messed up; "realloc" should be 
enough as the length has to be always <= previous length [memory content 
is then guaranteed to remain untouched]. Alternatively, a temporary is 
required
- PR 49954: String length is wrong for "array(:)(1:1)": It's wrongly the 
one of "array" instead of 1; there might be some extra issues.

- PR 50221: Some odd array assignment issues.
- PR 51976: Deferred-string components. Needs a hidden component for the 
string length. Tricky: expr->ts.u.cl->backend_decl is wrong as that 
points to the component - missing the component ref ("var->comp"). 
Similar to the issue of PR49954.


Tobias
2012-05-24  Tobias Burnus  

	PR fortran/45170
	* trans-expr.c (gfc_trans_assignment_1): Fix handling of RHS
	string lengths for deferred-length LHS.
	(gfc_trans_scalar_assign): Remove superfluous gcc_assert.

2012-05-24  Tobias Burnus  

	PR fortran/45170
	* gfortran.dg/deferred_type_param_7.f90: New.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 9d48a09..ce915b6 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6106,7 +6110,6 @@ gfc_trans_scalar_assign (gfc_se * lse, gfc_se * rse, gfc_typespec ts,
 
   if (rse->string_length != NULL_TREE)
 	{
-	  gcc_assert (rse->string_length != NULL_TREE);
 	  gfc_conv_string_parameter (rse);
 	  gfc_add_block_to_block (&block, &rse->pre);
 	  rlen = rse->string_length;
@@ -6891,7 +6897,6 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
   stmtblock_t body;
   bool l_is_temp;
   bool scalar_to_array;
-  bool def_clen_func;
   tree string_length;
   int n;
 
@@ -7010,13 +7015,8 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
  otherwise the character length of the result is not known.
  NOTE: This relies on having the exact dependence of the length type
  parameter available to the caller; gfortran saves it in the .mod files. */
-  def_clen_func = (expr2->expr_type == EXPR_FUNCTION
-		   || expr2->expr_type == EXPR_COMPCALL
-		   || expr2->expr_type == EXPR_PPC);
-  if (gfc_option.flag_realloc_lhs
-	&& expr2->ts.type == BT_CHARACTER
-	&& (def_clen_func || expr2->expr_type == EXPR_OP)
-	&& expr1->ts.deferred)
+  if (gfc_option.flag_realloc_lhs && expr2->ts.type == BT_CHARACTER
+  && expr1->ts.deferred)
 gfc_add_block_to_block (&block, &rse.pre);
 
   tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
--- /dev/null	2012-05-24 07:57:26.555773053 +0200
+++ gcc/gcc/testsuite/gfortran.dg/deferred_type_param_7.f90	2012-05-24 15:18:26.0 +0200
@@ -0,0 +1,64 @@
+! { dg-do run }
+!
+! PR fortran/45170
+!
+! Contribued by Steve Kargl
+!
+
+PROGRAM helloworld
+  implicit none
+  character(:),allocatable::string
+  character(11), parameter :: cmpstring = "hello world"
+  real::rnd
+  integer :: i, cnt
+  do i = 1, 100
+ call random_number(rnd)
+ cnt = floor(12*rnd)
+
+ if (allocated (string) .and. mod(i, 3) == 0) deallocate (string)
+ call hello1 (cnt, string)
+ if (len(string) /= cnt .or. string /= cmpstring(1:cnt)) call abort ()
+
+ if (allocated (string) .and. mod(i, 5) == 0) deallocate (string)
+ call hello2 (cnt, string)
+ if (len(string) /= cnt .or. string /= cmpstring(1:cnt)) call abort ()
+
+ if (allocated (string) .and. mod(i, 7) == 0) deallocate (string)
+ call hello3 (cnt, string)
+ if (len(string) /= cnt .or. string /= cmpstring(1:cnt)) call abort ()
+
+ if (allocated (string) .and. mod(i, 9) == 0) deallocate (string)
+ call hello4 (cnt, string)
+ if (len(string) /= cnt .or. string /= cmpstring(1:cnt)) call abort ()
+
+! print '(A,1X,I0)', '>' // string // '<', len(string)
+  end do
+contains
+  subroutine hello1 (n,string)
+character(:),allocatable,intent(out)::string
+integer,intent(in)::n
+character(11)::helloworld="hello world"
+string=helloworld(:n)  ! Does not work.
+  end subroutine hello1
+
+  subroutine hello2 (n,string)
+character(:),allocatable,intent(out)::string
+integer,intent(in)::n
+character(11)::helloworld="hello world"
+string=(helloworld(:n))
+  end subroutine hello2
+
+  subroutine hello3 (n,string)
+character(:),allocatable,intent(out)::string
+integer,intent(in)::n
+character(11)::helloworld="hello world"
+allocate(string, source=helloworld(:n))
+  end subroutine hello3
+
+  subroutine hello4 (n,string)
+character(:),allocatable,intent(ou

Re: PATCH: PR bootstrap/53472: contrib/compare-debug should strip out .comment section

[Paolo Bonzini]

Il 24/05/2012 16:01, H.J. Lu ha scritto:
> configure checks if contrib/compare-debug actually works for comparing a
> debug and non-debug .o file before enabling bootstrap-debug.  But some
> compilers encode some command line options (among them -g) into a special
> .comment section.  This patch removes .comment section before comparing
> debug and non-debug files.  OK for trunk?

Ok.

Paolo

Re: [Patch, fortran] PR 53456 More CPU timing fallbacks

[Tobias Burnus]

On 05/23/2012 10:43 PM, Janne Blomqvist wrote:

the attached patch allows the use of clock_gettime() with
CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID if the target
doesn't have getrusage() or times().


It's not completely clear to me whether CLOCK_PROCESS_CPUTIME_ID or even 
CLOCK_THREAD_CPUTIME_ID are always better than "clock()". In case of 
VxWorks the answer is probably yes as its clock() returns -1 (no 
per-process clock exists), though unless there is a thread, the patch 
won't change the result of -1.


I was wondering whether "call cpu_time()" alias clock_gettime with 
CLOCK_MONOTONIC would be better. (Returns time since startup in case of 
VxWorks, but could be also something else like time since the epoch.)


As you patch does not break something, might improve the result in some 
corner cases, and as CLOCK_MONOTONIC is available via cpu_time:


OK for the trunk.

Tobias


Such a target is apparently
VxWorks 6.something, see
http://www-ad.fnal.gov/controls/micro_p/manuals/vxworks_application_programmers_guide_6.7.pdf

Ok for trunk?

2012-05-23  Janne Blomqvist

PR fortran/53456
* intrinsics/time_1.h (gf_cputime): Fallback for clock_gettime.

Re: PATCH: PR bootstrap/53472: contrib/compare-debug should strip out .comment section

[H.J. Lu]

On Thu, May 24, 2012 at 7:35 AM, Paolo Bonzini  wrote:
> Il 24/05/2012 16:01, H.J. Lu ha scritto:
>> configure checks if contrib/compare-debug actually works for comparing a
>> debug and non-debug .o file before enabling bootstrap-debug.  But some
>> compilers encode some command line options (among them -g) into a special
>> .comment section.  This patch removes .comment section before comparing
>> debug and non-debug files.  OK for trunk?
>
> Ok.

Hi Richard,

Before I check it in,  can you verify it enables bootstrap-debug on SuSE?

Thanks.


-- 
H.J.

Re: fix install-no-fixedincludes mishaps

[Olivier Hainque]

On May 24, 2012, at 16:32 , Paolo Bonzini wrote:

>>  libgcc/
>>  * Makefile.in (clean): Remove libgcc_tm.stamp as well.
>>  Use a separate command for stamp removals.
> 
> Ok, thanks.

 Committed. The other one also, on the 4.7 branch as well.

 Thanks for for prompt feedback. And thanks Ian for the heads-up.

 With Kind Regards,

 Olivier
 

Re: Symbol table 24/many: Remove old alias handling code

[H.J. Lu]

On Thu, May 24, 2012 at 2:46 AM, Jan Hubicka  wrote:
> Hi,
> this patch removes code handling alias pairs after they was taken over by 
> symbol table.
> It also streamlines how things are output - do_assemble_alias is called when 
> alias should
> be output now, while assemble_alias is the function registering new alias 
> into symbol
> table.
>
> I think I will rename these incrementaly.
>
> Bootstrapped/regtested x86_64-linux
>
>        * tree.h (alias_diag_flags): Remove.
>        (alias_pair): Remove emitted_diags.
>        (finish_aliases_1, finish_aliases_2, remove_unreachable_alias_pairs,
>        symbol_alias_set_t, symbol_alias_set_destroy,
>        symbol_alias_set_contains, propagate_aliases_backward): Remove.
>        * toplev.c (compile_file): Do not call finish_aliases_2
>        * cgraphunit.c (cgraph_process_new_functions): Do not call 
> finish_aliases_1.
>        (handle_alias_pairs): Output diagnostics about aliases to externals.
>        (assemble_thunks_and_aliases): Use do_assemble_alias.
>        (output_weakrefs): Likewise.
>        (finalize_compilation_unit): Do not call finish_aliases_1.
>        * ipa.c (symtab_remove_unreachable_nodes): De not call 
> remove_unreachable_alias_pairs.
>        * varasm.c (do_assemble_alias): Export.
>        (symbol_alias_set_create, symbol_alias_set_destroy, 
> symbol_alias_set_contains,
>        symbol_alias_set_insert, propagate_aliases_forward, 
> propagate_aliases_backward,
>        propagate_aliases_backward, trivially_visible_alias, 
> trivially_defined_alias,
>        remove_unreachable_alias_pairs, finish_aliases_1, finish_aliases_2,
>        assemble_alias): Remove.
>        * output.h (do_assemble_alias): Declare.
>        * varpool.c (varpool_remove_unreferenced_decls): Do not call 
> finish_aliases_1.

This caused:

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


-- 
H.J.

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Dodji Seketeli]

Jason Merrill  writes:

> On 05/22/2012 05:04 AM, Dodji Seketeli wrote:
>> The problem is that cpp_get_token_1 can be called when we are at the
>> beginning of a macro expansion (inside enter_macro_expansion, called
>> from cpp_get_token_1), *before* context->c.macro is set.  This happens
>> e.g, when we call funlike_invocation_p to know if the current macro is
>> function-like or not.
>
> OK, sounds like we need some additional code to handle that.  I guess
> we could do something in funlike_invocation_p to prevent
> cpp_get_token_1 from setting invocation_location, or change the check
> we use to decide whether or not we already have an invocation
> location, perhaps by looking at invocation_location itself (and
> clearing it when we finish a macro).

So.  After thinking about this a bit more, here is how I phrase the
issue.

There is a small interval of time between when we decide to start the
expansion of a macro (when we get into enter_macro_context), and when we
really start that expansion (when push the context of macro the macro)
where we can recursively call cpp_get_token_1.  In that time interval,
cpp_get_token_1 might wrongly think that no macro expansion is in
progress.

And I think that's the issue root issue over which the
cpp_reader::set_invocation_location flag was papering.

It seems to me that a small and maintainable option to tackle this is to
introduce a flag cpp_reader::about_to_expand_macro_p, that is 'on'
during that time interval.  A new predicate function
in_macro_expansion_p then can now accurately tell cpp_get_token_1 if we
are in the process of expanding a macro or not, doing away with the need
for casual users of cpp_get_token_1 to set a flag to deal with macro
expansion point handling.

Tested and bootstrapped and tested on x86_64-unknown-linux-gnu against
trunk.


libcpp/

PR preprocessor/53229
* internal.h (cpp_reader::set_invocation_location): Remove.
(cpp_reader::about_to_expand_macro_p): New member flag.
* directives.c (do_pragma):  Remove Kludge as
pfile->set_invocation_location is no more.
* macro.c (cpp_get_token_1): Do away with the use of
cpp_reader::set_invocation_location.  Just collect the macro
expansion point when we are about to expand the top-most macro.
Do not override cpp_reader::about_to_expand_macro_p.
This fixes gcc.dg/cpp/paste12.c by making get_token_no_padding
properly handle locations of expansion points.
(cpp_get_token_with_location): Adjust, as
cpp_reader::set_invocation_location is no more.
(paste_tokens): Take a virtual location parameter for
the LHS of the pasting operator.  Use it in diagnostics.  Update
comments.
(paste_all_tokens): Tighten the assert.  Propagate the location of
the expansion point when no virtual locations are available.
Pass the virtual location to paste_tokens.
(in_macro_expansion_p): New static function.
(enter_macro_context): Set the cpp_reader::about_to_expand_macro_p
flag until we really start expanding the macro.
(_cpp_push_token_context, push_ptoken_context)
(push_extended_tokens_context): Unset the
cpp_reader::about_to_expand_macro_p flag when we push the macro
context.

gcc/testsuite/

PR preprocessor/53229
* gcc.dg/cpp/paste6.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste8.c: Likewise.
* gcc.dg/cpp/paste8-2.c: New test, like paste8.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12-2.c: New test, like paste12.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste13.c: Likewise.
* gcc.dg/cpp/paste14.c: Likewise.
* gcc.dg/cpp/paste14-2.c: New test, like paste14.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste18.c: New test.
---
 gcc/testsuite/gcc.dg/cpp/paste12-2.c |   11 +
 gcc/testsuite/gcc.dg/cpp/paste12.c   |5 ++-
 gcc/testsuite/gcc.dg/cpp/paste13.c   |5 ++-
 gcc/testsuite/gcc.dg/cpp/paste14-2.c |   11 +
 gcc/testsuite/gcc.dg/cpp/paste14.c   |5 ++-
 gcc/testsuite/gcc.dg/cpp/paste18.c   |   16 +++
 gcc/testsuite/gcc.dg/cpp/paste6.c|5 ++-
 gcc/testsuite/gcc.dg/cpp/paste8-2.c  |   15 ++
 gcc/testsuite/gcc.dg/cpp/paste8.c|2 +-
 libcpp/directives.c  |   30 +
 libcpp/internal.h|   10 +++-
 libcpp/macro.c   |   82 ++---
 12 files changed, 142 insertions(+), 55 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/cpp/paste12-2.c
 create mode 100644 gcc/testsuite/gcc.dg/cpp/paste14-2.c
 create mode 100644 gcc/testsuite/gcc.dg/cpp/paste18.c
 create mode 100644 gcc/testsuite/gcc.dg/cpp/paste8-2.c

diff --git a/gcc/testsuite/gcc.dg/cpp/paste12-2.c 
b/g

PING: [PATCH diagnostics] Make unwound macro expansion trace less redundant

[Dodji Seketeli]

PING: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01003.html

Dodji Seketeli  writes:

> Hello,
>
> As discussed previously, the unwinder for macro expansion is quite
> verbose [1].  This patch proposes to address that shortcoming.
>
> Consider this test case:
>
> $ cat -n test.c
>1  #define MYMAX(A,B) __extension__ ({ __typeof__(A) __a = (A); \
>2   __typeof__(B) __b = (B); __a < __b ? __b : __a; })
>3
>4  struct mystruct {};
>5  void
>6  foo()
>7  {
>8struct mystruct p;
>9float f = 0.0;
>   10MYMAX (p, f);
>   11  }
> $
>
> The output of the compiler from trunk yields:
>
> $ cc1 -quiet ./test.c
> ./test.c: In function ‘foo’:
> ./test.c:2:31: error: invalid operands to binary < (have ‘struct 
> mystruct’ and ‘float’)
>   __typeof__(B) __b = (B); __a < __b ? __b : __a; })
>  ^
> ./test.c:2:31: note: in expansion of macro 'MYMAX'
>   __typeof__(B) __b = (B); __a < __b ? __b : __a; })
>  ^
> ./test.c:10:3: note: expanded from here
>MYMAX (p, f);
>^
> $
>
> After this patch, the compiler yields:
>
> $ ./cc1 -quiet ./test.c
> ./test.c: In function ‘foo’:
> ./test.c:2:31: error: invalid operands to binary < (have ‘struct 
> mystruct’ and ‘float’)
>   __typeof__(B) __b = (B); __a < __b ? __b : __a; })
>  ^
> ./test.c:10:3: note: in expansion of macro 'MYMAX'
>MYMAX (p, f);
>^
> $
>
> The gotcha is, in the general case, we cannot simply eliminate the
> context of the macro definition.  That is, the line from the first
> output that is redundant with the first diagnostic line that has
> line/column number:
>
> ./test.c:2:31: note: in expansion of macro 'MYMAX'
>   __typeof__(B) __b = (B); __a < __b ? __b : __a; })
>^
>
> We cannot simply eliminate that context of macro definition because
> there are cases where the first diagnostic that has a line/column
> number doesn't point to a location inside the definition of the macro
> where the relevant token is used.  For instance:
>
> $ cat -n test2.c
>1  #define OPERATE(OPRD1, OPRT, OPRD2) \
>2OPRD1 OPRT OPRD2;
>3
>4  #define SHIFTL(A,B) \
>5OPERATE (A,<<,B)
>6
>7  #define MULT(A) \
>8SHIFTL (A,1)
>9
>   10  void
>   11  g ()
>   12  {
>   13MULT (1.0);// 1.0 << 1; <-- so this is an error.
>   14  }
> $
>
> Which yields without the patch:
>
> $ cc1 -quiet ./test2.c
> ./test2.c: In function ‘g’:
> ./test2.c:5:14: error: invalid operands to binary << (have ‘double’ and 
> ‘int’)
>OPERATE (A,<<,B)
> ^
> ./test2.c:2:9: note: in expansion of macro 'OPERATE'
>OPRD1 OPRT OPRD2;
>^
> ./test2.c:5:3: note: expanded from here
>OPERATE (A,<<,B)
>^
> ./test2.c:5:14: note: in expansion of macro 'SHIFTL'
>OPERATE (A,<<,B)
> ^
> ./test2.c:8:3: note: expanded from here
>SHIFTL (A,1)
>^
> ./test2.c:8:3: note: in expansion of macro 'MULT'
>SHIFTL (A,1)
>^
> ./test2.c:13:3: note: expanded from here
>MULT (1.0);// 1.0 << 1; <-- so this is an error.
>^
> $
>
> Here, the line that has the context of macro definition:
>
> ./test2.c:2:9: note: in expansion of macro 'OPERATE'
>OPRD1 OPRT OPRD2;
>^
> is useful, because the first diagnostic that has line/column number
> wasn't pointing into the definition of the macro OPERATE, where the
> token '<<' is used.
>
> ./test2.c:5:14: error: invalid operands to binary << (have ‘double’ and 
> ‘int’)
>OPERATE (A,<<,B)
> ^
> So in this this case, displaying the macro definition context is not
> redundant.  I think it is even desirable.
>
> The patch changes the output in that case to be:
>
> ./test2.c: In function ‘g’:
> ./test2.c:5:14: erreur: invalid operands to binary << (have ‘double’ and 
> ‘int’)
>OPERATE (A,<<,B)
> ^
> ./test2.c:2:9: note: in definition of macro 'OPERATE'
>OPRD1 OPRT OPRD2;
>^
> ./test2.c:8:3: note: in expansion of macro 'SHIFTL'
>SHIFTL (A,1)
>^
> ./test2.c:13:3: note: in expansion of macro 'MULT'
>MULT (1.0);// 1.0 << 1; <-- so this is an error.
>^
> $
>
> It's shorter, but I believe it has all the information that was
> present before the patch.
>
> [1]: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00321.html
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
>
> gcc/
>
>   Make unwound macro expansion trace less redundant
>   * tree-diagnostic.c (maybe_unwind_expa

Re: PING: [PATCH diagnostics] Make unwound macro expansion trace less redundant

[Gabriel Dos Reis]

On Thu, May 24, 2012 at 11:07 AM, Dodji Seketeli  wrote:
> PING: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01003.html

Sorry, this slipped under my radar.
Patch is OK.

-- Gaby

Re: fix install-no-fixedincludes mishaps

[Ian Lance Taylor]

Olivier Hainque  writes:

>  OK to apply ?
>
>   libgcc/
>   * Makefile.in: move dependency on install-unwind_h from
>   "install-leaf" to "install".

I don't see the final patch, but it sounds promising.  Thanks for
looking at it so quickly.

Ian

[RFA PATCH, i386]: Fix gcc.target/i386/pr53249.c on Sun targets

[Uros Bizjak]

Hello!

Currently gcc fails to compile following test from the testsuite [1]:

FAIL: gcc.target/i386/pr53249.c (test for excess errors)

We are trying to compile X32 specific test, but the special pattern
that was introduced to handle certain sun assembler limitation, is not
prepared to handle X32.

The patch avoids this special pattern for X32 target. X32 is currently
supported only with gnu tools, and if/when sun tools will support X32
target, they will certainly fix the limitation which allows TP loads
to AX register only.

2012-05-24  Uros Bizjak  

* config/i386/i386.c (legitimize_tls_address) :
Generate tls_initial_exec_64_sun insn only when !TARGET_X32.

Patch was tested by looking at the assembler of the failing test:

gomp_end_task:
.LFB0:
movl%fs:0, %edx
movqgomp_tls_data@gottpoff(%rip), %rax
movl4(%rdx,%rax), %ecx
movl(%ecx), %ecx
movl%ecx, 4(%edx,%eax)
ret

OK for mainline?

[1] http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg02028.html

Uros.
Index: i386.c
===
--- i386.c  (revision 187841)
+++ i386.c  (working copy)
@@ -12811,13 +12811,13 @@ legitimize_tls_address (rtx x, enum tls_model mode
 case TLS_MODEL_INITIAL_EXEC:
   if (TARGET_64BIT)
{
- if (TARGET_SUN_TLS)
+ if (TARGET_SUN_TLS && !TARGET_X32)
{
  /* The Sun linker took the AMD64 TLS spec literally
 and can only handle %rax as destination of the
 initial executable code sequence.  */
 
- dest = gen_reg_rtx (Pmode);
+ dest = gen_reg_rtx (DImode);
  emit_insn (gen_tls_initial_exec_64_sun (dest, x));
  return dest;
}

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Jason Merrill]

On 05/24/2012 12:03 PM, Dodji Seketeli wrote:

+  if (macro != NULL)
+pfile->about_to_expand_macro_p = false;


The approach sounds good, but why do this in the push_token_context 
functions rather than in enter_macro_context?


Jason

Re: [PATCH][ARM] 64-bit shifts in NEON.

[Andrew Stubbs]

On 23/02/12 20:36, Andrew Stubbs wrote:

On 21/02/12 15:23, Andrew Stubbs wrote:

On 06/02/12 13:13, Andrew Stubbs wrote:

This patch adds DImode shift support in NEON registers/instructions.

The patch causes delays any lowering until the split2 pass, after the
register allocator has chosen whether to do the shift in NEON (VFP)
registers, or in core-registers.

The core-registers case depends on the patch I previously posted here:
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01472.html

The NEON right-shifts make life more interesting by using a left-shift
instruction with a negative offset. This means that the amount has to be
negated. Ideally you'd want to do this at expand time, but the delayed
NEON/core decision makes this impossible, so I've chosen to expand this
in the post-reload split pass. Unfortunately, NEON does not provide a
suitable instruction for negating the shift amount, so that ends up
happening in core-registers.

Another complication is that the NEON shift instructions use a 64-bit
register for the shift amount, but they only pay attention to the bottom
8 bits. I did experiment with using a DImode shift amount, but that
didn't work out well; there were unnecessary extends and the
core-registers fall back was less efficient.

Therefore, I've chosen to create a new register class, VFP_LO_REGS_EVEN,
which includes only the 32-bit low-part of the DImode NEON registers so
the shift amount can be loaded into VFP regs without extending them.
This required a new print format 'E' that converts the low-part name to
the full register name the instructions need. Unfortunately, this does
artificially limit the shift amount to the bottom half of the register
set, but hopefully that's not going to be a big problem.

The register allocator is causing me trouble though. The problem is that
the compiler just refused to use the NEON variant in all of my toy
examples. It turns out to be simply that the IRA & reload passes do not
change hard-registers already present in the RTL (function parameters,
return values, etc.) unless there is absolutely no alternative that
works with that register. I'm not sure if there's anything that can be
done about this, or not. I'm not even sure if it isn't the right choice
much of the time, cost wise.


I've now updated the patch to take into account size optimization.

Currently, if optimizing for size the compiler prefers to call the
libgcc function, rather that do the shift inline.

With my old patch, when NEON is enabled it always used the inline code
(either in NEON or core-registers) no matter which optimization flags
were set. This is more-or-less correct if the register allocator chooses
to do the operation in NEON, but much less space efficient otherwise.

The update simply disables the core-registers fall-back option when
optimizing for size. Transferring the values to NEON registers and back
should be roughly the same size as calling a function, so there
shouldn't be a big loss.

I'm in two minds about the shift-by-constant cases though, since they
expand to fewer instructions. Any thoughts?


And yet another update.

This time I noticed that I didn't discard the "clobber"s after the split
has determined they're not necessary any more. Presumably the
unallocated "match_scratch"es were harmless, but the unnecessary CC
clobbers could affect if-conversion and scheduling.

This patch is the same as the previous, except that I've broken out the
alternatives that don't need any clobbers.

Ok for 4.8?


Ping!

The pre-requisite patch is now committed so this one is ready for review.

Here's a rebased version of the same patch. The only real difference is 
that one of my constraint names is no longer available, so now their all 
renamed.


OK?

Andrew
2012-05-18  Andrew Stubbs  

	gcc/
	* config/arm/arm.c (arm_print_operand): Add new 'E' format code.
	* config/arm/arm.h (enum reg_class): Add VFP_LO_REGS_EVEN.
	(REG_CLASS_NAMES, REG_CLASS_CONTENTS, IS_VFP_CLASS): Likewise.
	* config/arm/arm.md (opt, opt_enabled): New attributes.
	(enabled): Use opt_enabled.
	(ashldi3, ashrdi3, lshrdi3): Add TARGET_NEON case.
	* config/arm/constraints.md (T): New register constraint.
	(Pf, PF, P1, Pg, Ph): New constraints.
	* config/arm/neon.md (signed_shift_di3_neon, unsigned_shift_di3_neon,
	ashldi3_neon, ashldi3_neon_noclobber, ashrdi3_neon_imm,
	ashrdi3_neon_reg, ashrdi3_neon, ashrdi3_neon_imm_noclobber,
	lshrdi3_neon_imm, ashrdi3_neon, lshrdi3_neon_imm_noclobber,
	lshrdi3_neon_imm, lshrdi3_neon_reg, lshrdi3_neon): New patterns.
	* config/arm/predicates.md (int_1_to_64): New predicate.

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 3ad4c75..f581d15 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -17973,6 +17973,24 @@ arm_print_operand (FILE *stream, rtx x, int code)
   }
   return;
 
+/* Print the VFP/Neon double precision register name that overlaps the
+   given single-precision register.  */
+case 'E':
+  {
+	int mode = GET_

Re: PATCH: PR bootstrap/53472: contrib/compare-debug should strip out .comment section

[H.J. Lu]

On Thu, May 24, 2012 at 7:43 AM, H.J. Lu  wrote:
> On Thu, May 24, 2012 at 7:35 AM, Paolo Bonzini  wrote:
>> Il 24/05/2012 16:01, H.J. Lu ha scritto:
>>> configure checks if contrib/compare-debug actually works for comparing a
>>> debug and non-debug .o file before enabling bootstrap-debug.  But some
>>> compilers encode some command line options (among them -g) into a special
>>> .comment section.  This patch removes .comment section before comparing
>>> debug and non-debug files.  OK for trunk?
>>
>> Ok.
>
> Hi Richard,
>
> Before I check it in,  can you verify it enables bootstrap-debug on SuSE?
>

It doesn't work since the comment section name may be
.comment.SUSE.OPTs


-- 
H.J.

Re: [cxx-conversion] New Hash Table (issue6244048)

[Gabriel Dos Reis]

On Thu, May 24, 2012 at 11:43 AM, Lawrence Crowl  wrote:
> Add a type-safe hash table, typed_htab.  Uses of this table replace
> uses of libiberty's htab_t.  The benefits include less boiler-plate
> code, full type safety, and improved performance.

Lawrence, is there any chance you could just call it hash_table<>?
After the conversion, we will be living most of the time in a typed
world, so the "typed_" prefix will be redundant if not confusing :-)

[...]
> The type-safe hash table is a template, taking the element type
> and the operational functions as template parameters.  Passing the
> operational functions as template parameters, rather than function
> pointers, exposes the calls to inlining at -O2.  A side effect is that
> declarations of hash tables move to after the declarations of those
> functions.  A further side effect is that the control block shrinks
> from 108 bytes to 44 bytes.  There is otherwise no effect on data
> size.

Nice.

Do you anticipate that at some point we could just pass function object
classes as template arguments as opposed to functions?  That of
course would retain the nice property of inlining, but it would remove
the need to make the function have an external linkage.  The downside
is that change would touch more places than your current patch does.

-- Gaby

Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek]

On Wed, May 23, 2012 at 10:17:51AM +0200, Richard Guenther wrote:
> On Wed, 23 May 2012, Andreas Jaeger wrote:
> 
> > On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
> > > [...]
> > > This is a behaviour change.  It would need RM approval for a release
> > > branch.
> > > 
> > > R.
> > 
> > There was agreement by all pushing for the change to use it. So, let's ask 
> > the release managers about their opinion,
> 
> I'm ok with the change - but of course only to carry one less patch
> in our local tree.  What do others think?  It would definitely (anyway)
> need documenting in changes.html (for both 4.7.1 and 4.8).

I'm ok with that change as well (again, would apply that too), but note that
it isn't effortless on the side of gcc users, with the patch in they either
need recent enough glibc, or at least make a compatiblity symlink.

Jakub

Re: [PATCH] Fix PR51572

[H.J. Lu]

On Mon, Dec 19, 2011 at 3:50 AM, Richard Guenther  wrote:
>
> This fixes another case of PR51572 - we need to properly stream
> TYPE_DECLs in TYPE_FIELDS.
>
> LTO Boostrap and regtest running on x86_64-unknown-linux-gnu,
> SPEC 2k6 build scheduled.
>
> Richard.
>
> 2011-12-19  Richard Guenther  
>
>        PR lto/51572
>        * tree.c (free_lang_data_in_type): Do not unlink TYPE_DECL
>        from TYPE_FIELDS.
>        (find_decls_types_r): Walk TYPE_DECLs in TYPE_FIELDS.
>        * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Do
>        not stream TREE_CHAIN.
>        (write_ts_type_non_common_tree_pointers): Stream TYPE_FIELDS
>        using streamer_write_chain.
>        * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers):
>        Do not stream TREE_CHAIN.
>        (lto_input_ts_type_non_common_tree_pointers): Stream TYPE_FIELDS
>        using streamer_read_chain.
>        * gimple-streamer-in.c (input_gimple_stmt): Skip non-FIELD_DECLs.
>        * gimple.c (gimple_canonical_types_compatible_p): Properly
>        handle trailing non-FIELD_DECLs in TYPE_FIELDS.
>

This caused:

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

-- 
H.J.

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Dodji Seketeli]

Jason Merrill  writes:

> On 05/24/2012 12:03 PM, Dodji Seketeli wrote:
>> +  if (macro != NULL)
>> +pfile->about_to_expand_macro_p = false;
>
> The approach sounds good, but why do this in the push_token_context
> functions rather than in enter_macro_context?

Because, it's not only in enter_macro_context that I'd have to put it,
but also in replace_args, called from enter_macro_context, for instance.

Another way of seeing it is to say that, from the beginning of
enter_macro_context, we are in a state of "about to expand a macro"
until we actually push the macro context.  So it seems to make sense to
flip the flag where the the macro context push happens, IMHO.

-- 
Dodji

Re: [PATCH] Add powerpc64-linux configuration options

[Michael Meissner]

On Wed, May 23, 2012 at 10:59:10PM +, Joseph S. Myers wrote:
> On Wed, 23 May 2012, Michael Meissner wrote:
> 
> > An alternative would be for the powerpc64-linux case, should we just delete 
> > the
> > software floating emulation multilib and stop using the -mstrict-align, 
> > since
> > Linux only runs in big endian mode.  The software emulation multilib would 
> > be
> > built for other powerpc varients and -mstrict-align would be used there as
> > well.
> 
> I support deleting the soft-float multilib; it can't be used as-is because 
> it requires its own libc, in its own sysroot, and the configuration 
> doesn't use a separate sysroot for it.  As for -mstrict-align, again if 
> someone wants -mstrict-align libraries I think they should set up a 
> multilib using that option (or a CPU option that implies it) rather than 
> trying to make the libraries from a compiler configured for some CPU 
> compatible with another CPU they wouldn't normally be compatible with.

This alternative patch just disables building the 32-bit softfloat multlib, and
removes the -mstrict-align in the powerpc64-linux case.

I have bootstrapped it and had no regressions.

David, which patch do you prefer?

2012-05-24  Michael Meissner  

* config/rs6000/t-linux64: Delete the 32-bit multilib that uses
software floating point emulation.  No longer build the multilibs
with -mstrict-align.

Index: gcc/config/rs6000/t-linux64
===
--- gcc/config/rs6000/t-linux64 (revision 187805)
+++ gcc/config/rs6000/t-linux64 (working copy)
@@ -26,10 +26,7 @@
 # it doesn't tell anything about the 32bit libraries on those systems.  Set
 # MULTILIB_OSDIRNAMES according to what is found on the target.
 
-MULTILIB_OPTIONS= m64/m32 msoft-float
-MULTILIB_DIRNAMES   = 64 32 nof
-MULTILIB_EXTRA_OPTS = fPIC mstrict-align
-MULTILIB_EXCEPTIONS = m64/msoft-float
-MULTILIB_EXCLUSIONS = m64/!m32/msoft-float
-MULTILIB_OSDIRNAMES= ../lib64 $(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib) nof
-MULTILIB_MATCHES= $(MULTILIB_MATCHES_FLOAT)
+MULTILIB_OPTIONS= m64/m32
+MULTILIB_DIRNAMES   = 64 32
+MULTILIB_EXTRA_OPTS = fPIC
+MULTILIB_OSDIRNAMES= ../lib64 $(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

[google] make the temp names in FDO/LIPO demanglable (issue6251048)

[Rong Xu]

Hi,

This is for google branches only.

It changes the format of the temp function name so that they
can be demangled.

Tested with regression tests.

Google ref b/5733865.

Thanks,

2012-05-24   Rong Xu  

* l-ipo.c (create_unique_name): Make temp names demanglable.

Index: l-ipo.c
===
--- l-ipo.c (revision 187817)
+++ l-ipo.c (working copy)
@@ -1726,15 +1726,15 @@ create_unique_name (tree decl, unsigned module_id)
   char *n;
   unsigned fno =  FUNC_DECL_FUNC_ID (context);
   n = (char *)alloca (strlen (name) + 15);
-  sprintf (n, "%s_%u", name, fno);
+  sprintf (n, "%s.%u", name, fno);
   name = n;
 }
 
   assembler_name = (char*) alloca (strlen (name) + 30);
-  sprintf (assembler_name, "%s_cmo_%u", name, module_id);
+  sprintf (assembler_name, "%s.cmo.%u", name, module_id);
   seq = get_name_seq_num (assembler_name);
   if (seq)
-sprintf (assembler_name, "%s_%d", assembler_name, seq);
+sprintf (assembler_name, "%s.%d", assembler_name, seq);
 
   assemb_id = get_identifier (assembler_name);
 

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

Re: [google] make the temp names in FDO/LIPO demanglable (issue6251048)

[Xinliang David Li]

Ok.

David

On Thu, May 24, 2012 at 11:38 AM, Rong Xu  wrote:
> Hi,
>
> This is for google branches only.
>
> It changes the format of the temp function name so that they
> can be demangled.
>
> Tested with regression tests.
>
> Google ref b/5733865.
>
> Thanks,
>
> 2012-05-24   Rong Xu  
>
>        * l-ipo.c (create_unique_name): Make temp names demanglable.
>
> Index: l-ipo.c
> ===
> --- l-ipo.c     (revision 187817)
> +++ l-ipo.c     (working copy)
> @@ -1726,15 +1726,15 @@ create_unique_name (tree decl, unsigned module_id)
>       char *n;
>       unsigned fno =  FUNC_DECL_FUNC_ID (context);
>       n = (char *)alloca (strlen (name) + 15);
> -      sprintf (n, "%s_%u", name, fno);
> +      sprintf (n, "%s.%u", name, fno);
>       name = n;
>     }
>
>   assembler_name = (char*) alloca (strlen (name) + 30);
> -  sprintf (assembler_name, "%s_cmo_%u", name, module_id);
> +  sprintf (assembler_name, "%s.cmo.%u", name, module_id);
>   seq = get_name_seq_num (assembler_name);
>   if (seq)
> -    sprintf (assembler_name, "%s_%d", assembler_name, seq);
> +    sprintf (assembler_name, "%s.%d", assembler_name, seq);
>
>   assemb_id = get_identifier (assembler_name);
>
>
> --
> This patch is available for review at http://codereview.appspot.com/6251048

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Jason Merrill]

On 05/24/2012 01:41 PM, Dodji Seketeli wrote:

Jason Merrill  writes:


The approach sounds good, but why do this in the push_token_context
functions rather than in enter_macro_context?


Because, it's not only in enter_macro_context that I'd have to put it,
but also in replace_args, called from enter_macro_context, for instance.


Why?


Another way of seeing it is to say that, from the beginning of
enter_macro_context, we are in a state of "about to expand a macro"
until we actually push the macro context.  So it seems to make sense to
flip the flag where the the macro context push happens, IMHO.


Sure, that makes sense.  It just seems better to me to have the flag set 
a little longer than necessary in order to keep the setting and 
unsetting closer together for maintainability.


Jason

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Dodji Seketeli]

Jason Merrill  writes:

> On 05/24/2012 01:41 PM, Dodji Seketeli wrote:

[...]

>> Another way of seeing it is to say that, from the beginning of
>> enter_macro_context, we are in a state of "about to expand a macro"
>> until we actually push the macro context.  So it seems to make sense to
>> flip the flag where the the macro context push happens, IMHO.
>
> Sure, that makes sense.  It just seems better to me to have the flag
> set a little longer than necessary in order to keep the setting and
> unsetting closer together for maintainability.

Like the below?  Bootstrap is under way.

libcpp/

PR preprocessor/53229
* internal.h (cpp_reader::set_invocation_location): Remove.
(cpp_reader::about_to_expand_macro_p): New member flag.
* directives.c (do_pragma):  Remove Kludge as
pfile->set_invocation_location is no more.
* macro.c (cpp_get_token_1): Do away with the use of
cpp_reader::set_invocation_location.  Just collect the macro
expansion point when we are about to expand the top-most macro.
Do not override cpp_reader::about_to_expand_macro_p.
This fixes gcc.dg/cpp/paste12.c by making get_token_no_padding
properly handle locations of expansion points.
(cpp_get_token_with_location): Adjust, as
cpp_reader::set_invocation_location is no more.
(paste_tokens): Take a virtual location parameter for
the LHS of the pasting operator.  Use it in diagnostics.  Update
comments.
(paste_all_tokens): Tighten the assert.  Propagate the location of
the expansion point when no virtual locations are available.
Pass the virtual location to paste_tokens.
(in_macro_expansion_p): New static function.
(enter_macro_context): Set the cpp_reader::about_to_expand_macro_p
flag until we really start expanding the macro.

gcc/testsuite/

PR preprocessor/53229
* gcc.dg/cpp/paste6.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste8.c: Likewise.
* gcc.dg/cpp/paste8-2.c: New test, like paste8.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12-2.c: New test, like paste12.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste13.c: Likewise.
* gcc.dg/cpp/paste14.c: Likewise.
* gcc.dg/cpp/paste14-2.c: New test, like paste14.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste18.c: New test.

diff --git a/gcc/testsuite/gcc.dg/cpp/paste12-2.c 
b/gcc/testsuite/gcc.dg/cpp/paste12-2.c
new file mode 100644
index 000..6e2e4f1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/paste12-2.c
@@ -0,0 +1,11 @@
+/* 
+   { dg-options "-ftrack-macro-expansion=2" }
+   { dg-do preprocess }
+ */
+
+/* Test correct diagnostics when pasting in #include.
+   Source: PR preprocessor/6780.  */
+
+#define inc2(a,b) <##a.b>  /* { dg-error "pasting \"<\" and \"stdio\" does 
not" } */
+#define INC(X) inc2(X,h)
+#include INC(stdio)
diff --git a/gcc/testsuite/gcc.dg/cpp/paste12.c 
b/gcc/testsuite/gcc.dg/cpp/paste12.c
index e61ec51..3e0f7b9 100644
--- a/gcc/testsuite/gcc.dg/cpp/paste12.c
+++ b/gcc/testsuite/gcc.dg/cpp/paste12.c
@@ -1,4 +1,7 @@
-/* { dg-do preprocess } */
+/*
+  { dg-options "-ftrack-macro-expansion=0" }
+  { dg-do preprocess }
+*/
 
 /* Test correct diagnostics when pasting in #include.
Source: PR preprocessor/6780.  */
diff --git a/gcc/testsuite/gcc.dg/cpp/paste13.c 
b/gcc/testsuite/gcc.dg/cpp/paste13.c
index 62c72d4..f0f4fd8 100644
--- a/gcc/testsuite/gcc.dg/cpp/paste13.c
+++ b/gcc/testsuite/gcc.dg/cpp/paste13.c
@@ -1,6 +1,9 @@
 /* Copyright (C) 2000 Free Software Foundation, Inc.  */
 
-/* { dg-do preprocess } */
+/*
+  { dg-options "-ftrack-macro-expansion=0" }
+  { dg-do preprocess }
+*/
 
 /* This used to be recognized as a comment when lexing after pasting
spellings.  Neil Booth, 9 Oct 2002.  */
diff --git a/gcc/testsuite/gcc.dg/cpp/paste14-2.c 
b/gcc/testsuite/gcc.dg/cpp/paste14-2.c
new file mode 100644
index 000..3b23ada
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/paste14-2.c
@@ -0,0 +1,11 @@
+/* PR preprocessor/28709 */
+/* 
+   { dg-options "-ftrack-macro-expansion=2" }
+   { dg-do preprocess }
+*/
+
+#define foo - ## >> /* { dg-error "pasting \"-\" and \">>\"" } */
+foo
+#define bar = ## == /* { dg-error "pasting \"=\" and \"==\"" } */
+bar
+
diff --git a/gcc/testsuite/gcc.dg/cpp/paste14.c 
b/gcc/testsuite/gcc.dg/cpp/paste14.c
index ec243c2..043d5e5 100644
--- a/gcc/testsuite/gcc.dg/cpp/paste14.c
+++ b/gcc/testsuite/gcc.dg/cpp/paste14.c
@@ -1,5 +1,8 @@
 /* PR preprocessor/28709 */
-/* { dg-do preprocess } */
+/* 
+   { dg-options "-ftrack-macro-expansion=0" }
+   { dg-do preprocess }
+*/
 
 #define foo - ## >>
 foo/* { dg-error "pasting \"-\" and \">>\"" } */
diff --git a/gcc/testsuite/gcc.dg/cpp/paste18.

Re: PING: [PATCH diagnostics] Make unwound macro expansion trace less redundant

[Dodji Seketeli]

Gabriel Dos Reis  writes:

> On Thu, May 24, 2012 at 11:07 AM, Dodji Seketeli  wrote:
>> PING: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01003.html
>
> Sorry, this slipped under my radar.

No problem.

> Patch is OK.

Thank you.  Applied to trunk, revision r187845.

-- 
Dodji

Re: [google/gcc-4_6] More Fission updates (revised) (issue6219049)

[Diego Novillo]

On 12-05-22 21:56 , Cary Coutant wrote:

[Revised to address review comments and to fix a bug we found late:
We've changed want_pubnames to a static inline function, and changed
the pubnames output to include (ironically enough) inline functions.]

This patch is for the google/gcc-4_6 branch.

Fission improvements and bug fixes.  Adds new DW_OP_GNU_const_index to
handle TLS offsets in debug info.  Adds -gpubnames/-gno-pubnames options
to explicitly request .debug_pubnames/pubtypes sections.  Adds style
parameter to C/C++ pretty-printer so that we can get canonical pubnames
without affecting diagnostic output.

Bootstrapped and tested on x86_64.


2012-05-21  Sterling Augustine
Cary Coutant

include/
* dwarf2.h: Add DW_OP_GNU_const_index.

gcc/
* opts.c (finish_options): -gfission implies -gpubnames.
(common_handle_option): Pass empty arg string to set_debug_level.
* common.opt (gno-fission): New option.
(gfission): Remove JoinedOrMissing, add RejectNegative.
(gno-pubnames, gpubnames): New options.
* target.def (want_debug_pub_sections): Change default to false.
* gcc.c (check_live_switch): Check -g options for -gno- options.

* c-family/c-pretty-print.c (pp_c_specifier_qualifier_list): Add
support for gnu_v3 style.
* c-family/c-pretty-print.h (pp_c_flag_gnu_v3): New enum constant.
* cp/error.c (dump_decl): Add support for gnu_v3 style.
(decl_as_string): Likewise.
(lang_decl_name): Likewise.
* cp/cp-lang.c (cxx_dwarf_name): Likewise.
* cp/cp-tree.h (enum overload_flags): Add TFF_MATCH_GNU_V3_DEMANGLER.

* dwarf2out.c (dwarf_stack_op_name): Add DW_OP_GNU_const_index.
(size_of_loc_descr): Likewise.
(output_loc_operands): Likewise.
(output_loc_operands_raw): Likewise.
(dw_addr_op): New function.
(new_addr_loc_descr): Call dw_addr_op.
(want_pubnames): New function.
(add_AT_pubnames): Add DW_AT_GNU_pubnames/pubtypes only if
generating .debug_pubnames/pubtypes sections.
(add_pubname_string): Check for -gpubnames option.
(add_pubname): Likewise.
(add_pubtype): Likewise.
(output_pubnames): Likewise.
(mem_loc_descriptor): Call new_addr_loc_desc for TLS vars.
(loc_list_from_tree): Likewise.
(gen_subprogram_die): Output pubnames for all inlined functions.
(output_addr_table): Handle DW_OP_GNU_const_index.  Add missing
newline.
(hash_loc_operands): Add DW_OP_GNU_const_index.
(compare_loc_operands): Likewise.

* testsuite/g++.old-deja/g++.pt/memtemp77.C: Revert earlier change
to expected results.
* testsuite/g++.dg/ext/pretty3.C: Likewise.
* testsuite/g++.dg/warn/Wuninitializable-member.C: Likewise.
* testsuite/g++.dg/warn/pr35711.C: Likewise.
* testsuite/g++.dg/pr44486.C: Likewise.


OK with a couple of nits I found on the second read.


@@ -445,6 +445,9 @@ pp_c_specifier_qualifier_list (c_pretty_
  {
const enum tree_code code = TREE_CODE (t);

+  if (!(pp->flags&  pp_c_flag_gnu_v3)&&  TREE_CODE (t) != POINTER_TYPE)
+pp_c_type_qualifier_list (pp, t);


You can use 'code' here instead of TREE_CODE(t).  Either that, or remove 
the declaration of 'code' above.



+
switch (code)
  {
  case REFERENCE_TYPE:
@@ -489,7 +492,7 @@ pp_c_specifier_qualifier_list (c_pretty_
pp_simple_type_specifier (pp, t);
break;
  }
-  if (TREE_CODE (t) != POINTER_TYPE)
+  if ((pp->flags&  pp_c_flag_gnu_v3)&&  TREE_CODE (t) != POINTER_TYPE)


Likewise here.


@@ -6589,17 +6595,30 @@ static bool generic_type_p (tree);
  static void schedule_generic_params_dies_gen (tree t);
  static void gen_scheduled_generic_parms_dies (void);

+/* DW_OP_addr is relocated by the debug info consumer, while
+   tls relative operands should not be.  */
+
+static inline enum dwarf_location_atom dw_addr_op (bool dtprel)


Can you describe what DTPREL is used for here?



Diego.

Re: fix install-no-fixedincludes mishaps

[Olivier Hainque]

On May 24, 2012, at 6:18 PM, Ian Lance Taylor wrote:
>>  * Makefile.in: move dependency on install-unwind_h from
>>  "install-leaf" to "install".
> 
> I don't see the final patch, but it sounds promising.

 :) Testing was good on my side and Paolo approved
 so this was checked in, rev 187839.

> Thanks for looking at it so quickly.

 My pleasure. Thanks for the heads up and clear
 description of the issue you were observing.

 With Kind Regards,

 Olivier

Re: [Patch, fortran] PR 53456 More CPU timing fallbacks

[Janne Blomqvist]

On Thu, May 24, 2012 at 5:37 PM, Tobias Burnus  wrote:
> On 05/23/2012 10:43 PM, Janne Blomqvist wrote:
>>
>> the attached patch allows the use of clock_gettime() with
>> CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID if the target
>> doesn't have getrusage() or times().
>
>
> It's not completely clear to me whether CLOCK_PROCESS_CPUTIME_ID or even
> CLOCK_THREAD_CPUTIME_ID are always better than "clock()".

AFAICS, CLOCK_PROCESS_CPUTIME_ID should roughly measure the same thing
as clock(), except with higher resolution and no wraparound issues. So
yes, I think it's always better.

Better than CLOCK_THREAD_CPUTIME_ID, maybe not, since that measures a
slightly different thing. But, I'm counting on vxworks being the only
target without getrusage(), times(), or CLOCK_PROCESS_CPUTIME_ID, and
a clock() which always returns error. Hence I put the clock_gettime
block ahead of the clock() block. If a target turns up where this
logic breaks down we can revisit it then IMHO, rather than worrying
prematurely about it.

> In case of VxWorks
> the answer is probably yes as its clock() returns -1 (no per-process clock
> exists), though unless there is a thread, the patch won't change the result
> of -1.

My understanding of the docs was that it would return the CPU usage of
the calling thread; with a process always having >= 1 thread(s). So it
"should" work, although for a multithreaded program the result would
be different compared to the other methods in gf_cputime which all
measure per-process CPU usage.

> I was wondering whether "call cpu_time()" alias clock_gettime with
> CLOCK_MONOTONIC would be better. (Returns time since startup in case of
> VxWorks, but could be also something else like time since the epoch.)

Hmm, for system_clock our first choice is clock_gettime with
CLOCK_MONOTONIC (see gf_gettime_mono in system_clock.c) yes, but I
don't see how that would be appropriate for cpu_time.

> OK for the trunk.

Thanks, committed as r187846.


-- 
Janne Blomqvist

libgo patch committed: Copy runtime_printf from other library

[Ian Lance Taylor]

This patch to libgo copies the implementation of runtime_printf from the
other Go library, and use that instead of calling the C library printf
function.  This removes some unnecessary differences in shared files,
and removes some unnecessary stack splits.  However, the main reason I'm
doing it is to pick up the support for sending the printf output into a
goroutine-specific buffer, used to implement runtime.Stack, coming up
next.  Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.

Ian

diff -r d99f020243e7 libgo/runtime/go-callers.c
--- a/libgo/runtime/go-callers.c	Tue May 22 09:54:14 2012 -0700
+++ b/libgo/runtime/go-callers.c	Tue May 22 14:50:06 2012 -0700
@@ -72,5 +72,8 @@
 int
 Callers (int skip, struct __go_open_array pc)
 {
-  return runtime_callers (skip, (uintptr *) pc.__values, pc.__count);
+  /* In the Go 1 release runtime.Callers has an off-by-one error,
+ which we can not correct because it would break backward
+ compatibility.  Adjust SKIP here to be compatible.  */
+  return runtime_callers (skip - 1, (uintptr *) pc.__values, pc.__count);
 }

Re: [libgo] Fix IRIX bootstrap failure

[Ian Lance Taylor]

Rainer Orth  writes:

> The current 4.7 branch fails to build on IRIX 6.5:
>
> /vol/gcc/src/hg/gcc-4.7-branch/local/libgo/runtime/go-caller.c:51:1: error: 
> conflicting types for '__go_file_line'
> In file included from 
> /vol/gcc/src/hg/gcc-4.7-branch/local/libgo/runtime/go-caller.c:11:0:
> /vol/gcc/src/hg/gcc-4.7-branch/local/libgo/runtime/runtime.h:481:14: note: 
> previous declaration of '__go_file_line' was here 
>
> The following patch fixes the inconsistency between runtime.h and
> go-caller.c and lets the bootstrap finish.

Thanks.  I committed the patch to mainline and 4.7 branch.


> Testsuite results are still
> terrible since many tests timeout (with timeout doubled to 600s to
> account for the slow 250 MHz MIPS R10k CPUs on my test machine), and
> others not even hitting the timeout at all:
>
>  PID USERNAME  PRI NICE  SIZE   RES STATE   TIME   WCPUCPU COMMAND
> 35782082 ro 200  784M 3696K ready 357:50 29.59% 59.18% goprint.ex
> 33666480 ro 200  784M 5568K ready 437:14 29.56% 59.11% select5.ex
> 35957493 ro 200  784M 5264K run/2 206:40 29.43% 58.86% 64bit.exe
> 35654428 ro 200  784M 5072K ready 432:59 29.41% 58.82% index.exe
>
> They all seem to loop in a SIGSEGV handling loop.

I don't know what is happening here.

Ian

Re: [google/gcc-4_6] More Fission updates (revised) (issue6219049)

[Cary Coutant]

> OK with a couple of nits I found on the second read.
>
>> +  if (!(pp->flags&  pp_c_flag_gnu_v3)&&  TREE_CODE (t) != POINTER_TYPE)
>> +    pp_c_type_qualifier_list (pp, t);
>
> You can use 'code' here instead of TREE_CODE(t).  Either that, or remove the
> declaration of 'code' above.
>
>> -  if (TREE_CODE (t) != POINTER_TYPE)
>> +  if ((pp->flags&  pp_c_flag_gnu_v3)&&  TREE_CODE (t) != POINTER_TYPE)
>
> Likewise here.

Fixed. Note that the original code was guilty as well. :-)

>> +/* DW_OP_addr is relocated by the debug info consumer, while
>> +   tls relative operands should not be.  */
>> +
>> +static inline enum dwarf_location_atom dw_addr_op (bool dtprel)
>
> Can you describe what DTPREL is used for here?

I've rewritten the comment as follows:

/* Return the operator to use for an address of a variable.
   DTPREL is true for thread-local variables whose address
   is really an offset relative to the TLS pointer, which
   will need link-time relocation, but will not need relocation
   by the DWARF consumer.  For those, we use DW_OP_const*.
   For regular variables, which need both link-time relocation
   and consumer-level relocation (e.g., to account for
   shared objects loaded at a random address), we use
   DW_OP_addr*.  */

Thanks!

-cary

libgo patch committed: Make runtime.Stack work

[Ian Lance Taylor]

This patch makes the function runtime.Stack actually work, rather than
simply hang the program.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline and 4.7 branch.

Ian

Index: libgo/runtime/mprof.goc
===
--- libgo/runtime/mprof.goc	(revision 187623)
+++ libgo/runtime/mprof.goc	(working copy)
@@ -343,6 +343,7 @@ func ThreadCreateProfile(p Slice) (n int
 
 func Stack(b Slice, all bool) (n int32) {
 	byte *pc, *sp;
+	bool enablegc;
 	
 	sp = runtime_getcallersp(&b);
 	pc = runtime_getcallerpc(&b);
@@ -351,6 +352,8 @@ func Stack(b Slice, all bool) (n int32) 
 		runtime_semacquire(&runtime_worldsema);
 		runtime_m()->gcing = 1;
 		runtime_stoptheworld();
+		enablegc = mstats.enablegc;
+		mstats.enablegc = false;
 	}
 
 	if(b.__count == 0)
@@ -373,33 +376,31 @@ func Stack(b Slice, all bool) (n int32) 
 	
 	if(all) {
 		runtime_m()->gcing = 0;
+		mstats.enablegc = enablegc;
 		runtime_semrelease(&runtime_worldsema);
 		runtime_starttheworld(false);
 	}
 }
 
 static void
-saveg(byte *pc, byte *sp, G *g, TRecord *r)
+saveg(G *g, TRecord *r)
 {
 	int32 n;
 
-	USED(pc);
-	USED(sp);
-	USED(g);
-	// n = runtime_gentraceback(pc, sp, 0, g, 0, r->stk, nelem(r->stk));
-	n = 0;
+	if(g == runtime_g())
+		n = runtime_callers(0, r->stk, nelem(r->stk));
+	else {
+		// FIXME: Not implemented.
+		n = 0;
+	}
 	if((size_t)n < nelem(r->stk))
 		r->stk[n] = 0;
 }
 
 func GoroutineProfile(b Slice) (n int32, ok bool) {
-	byte *pc, *sp;
 	TRecord *r;
 	G *gp;
 	
-	sp = runtime_getcallersp(&b);
-	pc = runtime_getcallerpc(&b);
-	
 	ok = false;
 	n = runtime_gcount();
 	if(n <= b.__count) {
@@ -412,12 +413,11 @@ func GoroutineProfile(b Slice) (n int32,
 			G* g = runtime_g();
 			ok = true;
 			r = (TRecord*)b.__values;
-			saveg(pc, sp, g, r++);
+			saveg(g, r++);
 			for(gp = runtime_allg; gp != nil; gp = gp->alllink) {
 if(gp == g || gp->status == Gdead)
 	continue;
-//saveg(gp->sched.pc, gp->sched.sp, gp, r++);
-r++;
+saveg(gp, r++);
 			}
 		}
 	
Index: libgo/runtime/runtime.h
===
--- libgo/runtime/runtime.h	(revision 187848)
+++ libgo/runtime/runtime.h	(working copy)
@@ -71,6 +71,8 @@ typedef	struct	__go_panic_stack	Panic;
 typedef struct	__go_func_type		FuncType;
 typedef struct	__go_map_type		MapType;
 
+typedef struct  Traceback	Traceback;
+
 /*
  * per-cpu declaration.
  */
@@ -151,7 +153,7 @@ struct	G
 	// uintptr	sigpc;
 	uintptr	gopc;	// pc of go statement that created this goroutine
 
-	G*	dotraceback;
+	Traceback* traceback;
 
 	ucontext_t	context;
 	void*		stack_context[10];
@@ -299,6 +301,7 @@ void	runtime_goroutineheader(G*);
 void	runtime_goroutinetrailer(G*);
 void	runtime_traceback();
 void	runtime_tracebackothers(G*);
+void	runtime_printtrace(uintptr*, int32);
 String	runtime_gostringnocopy(const byte*);
 void*	runtime_mstart(void*);
 G*	runtime_malg(int32, byte**, size_t*);
Index: libgo/runtime/proc.c
===
--- libgo/runtime/proc.c	(revision 18)
+++ libgo/runtime/proc.c	(working copy)
@@ -348,7 +348,7 @@ runtime_mcall(void (*pfn)(G*))
 		mp = runtime_m();
 		gp = runtime_g();
 
-		if(gp->dotraceback != nil)
+		if(gp->traceback != nil)
 			gtraceback(gp);
 	}
 	if (gp == nil || !gp->fromgogo) {
@@ -542,11 +542,20 @@ runtime_goroutinetrailer(G *g)
 	}
 }
 
+struct Traceback
+{
+	G* gp;
+	uintptr pcbuf[100];
+	int32 c;
+};
+
 void
 runtime_tracebackothers(G * volatile me)
 {
 	G * volatile g;
+	Traceback traceback;
 
+	traceback.gp = me;
 	for(g = runtime_allg; g != nil; g = g->alllink) {
 		if(g == me || g->status == Gdead)
 			continue;
@@ -567,16 +576,19 @@ runtime_tracebackothers(G * volatile me)
 			continue;
 		}
 
-		g->dotraceback = me;
+		g->traceback = &traceback;
 
 #ifdef USING_SPLIT_STACK
 		__splitstack_getcontext(&me->stack_context[0]);
 #endif
 		getcontext(&me->context);
 
-		if(g->dotraceback) {
+		if(g->traceback != nil) {
 			runtime_gogo(g);
 		}
+
+		runtime_printtrace(traceback.pcbuf, traceback.c);
+		runtime_goroutinetrailer(g);
 	}
 }
 
@@ -586,13 +598,13 @@ runtime_tracebackothers(G * volatile me)
 static void
 gtraceback(G* gp)
 {
-	G* ret;
+	Traceback* traceback;
 
-	runtime_traceback(nil);
-	runtime_goroutinetrailer(gp);
-	ret = gp->dotraceback;
-	gp->dotraceback = nil;
-	runtime_gogo(ret);
+	traceback = gp->traceback;
+	gp->traceback = nil;
+	traceback->c = runtime_callers(1, traceback->pcbuf,
+		sizeof traceback->pcbuf / sizeof traceback->pcbuf[0]);
+	runtime_gogo(traceback->gp);
 }
 
 // Mark this g as m's idle goroutine.
Index: libgo/runtime/go-traceback.c
===
--- libgo/runtime/go-traceback.c	(revision 187623)
+++ libgo/runtime/go-traceback.c	(working copy)
@@ -6,57 +6,37 @@
 
 #include "config.h"
 
-#include "unwind.h"
-
 #include "runtime.h"
 #include "go-string.h"
 
-static _U

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Dodji Seketeli]

Dodji Seketeli  writes:

> Jason Merrill  writes:
>
>> On 05/24/2012 01:41 PM, Dodji Seketeli wrote:
>
> [...]
>
>>> Another way of seeing it is to say that, from the beginning of
>>> enter_macro_context, we are in a state of "about to expand a macro"
>>> until we actually push the macro context.  So it seems to make sense to
>>> flip the flag where the the macro context push happens, IMHO.
>>
>> Sure, that makes sense.  It just seems better to me to have the flag
>> set a little longer than necessary in order to keep the setting and
>> unsetting closer together for maintainability.
>
> Like the below?  Bootstrap is under way.

FWIW, the patch passed bootstrap and testing on x86_64-unknown-linux-gnu
against trunk.

> 
> libcpp/
> 
>   PR preprocessor/53229
>   * internal.h (cpp_reader::set_invocation_location): Remove.
>   (cpp_reader::about_to_expand_macro_p): New member flag.
>   * directives.c (do_pragma):  Remove Kludge as
>   pfile->set_invocation_location is no more.
>   * macro.c (cpp_get_token_1): Do away with the use of
>   cpp_reader::set_invocation_location.  Just collect the macro
>   expansion point when we are about to expand the top-most macro.
>   Do not override cpp_reader::about_to_expand_macro_p.
>   This fixes gcc.dg/cpp/paste12.c by making get_token_no_padding
>   properly handle locations of expansion points.
>   (cpp_get_token_with_location): Adjust, as
>   cpp_reader::set_invocation_location is no more.
>   (paste_tokens): Take a virtual location parameter for
>   the LHS of the pasting operator.  Use it in diagnostics.  Update
>   comments.
>   (paste_all_tokens): Tighten the assert.  Propagate the location of
>   the expansion point when no virtual locations are available.
>   Pass the virtual location to paste_tokens.
>   (in_macro_expansion_p): New static function.
>   (enter_macro_context): Set the cpp_reader::about_to_expand_macro_p
>   flag until we really start expanding the macro.
> 
> gcc/testsuite/
> 
>   PR preprocessor/53229
>   * gcc.dg/cpp/paste6.c: Force to run without
>   -ftrack-macro-expansion.
>   * gcc.dg/cpp/paste8.c: Likewise.
>   * gcc.dg/cpp/paste8-2.c: New test, like paste8.c but run with
>   -ftrack-macro-expansion.
>   * gcc.dg/cpp/paste12.c: Force to run without
>   -ftrack-macro-expansion.
>   * gcc.dg/cpp/paste12-2.c: New test, like paste12.c but run with
>   -ftrack-macro-expansion.
>   * gcc.dg/cpp/paste13.c: Likewise.
>   * gcc.dg/cpp/paste14.c: Likewise.
>   * gcc.dg/cpp/paste14-2.c: New test, like paste14.c but run with
>   -ftrack-macro-expansion.
>   * gcc.dg/cpp/paste18.c: New test.

Thanks.

-- 
Dodji

Re: PATCH: PR bootstrap/53472: contrib/compare-debug should strip out .comment section

[H.J. Lu]

On Thu, May 24, 2012 at 9:53 AM, H.J. Lu  wrote:
> On Thu, May 24, 2012 at 7:43 AM, H.J. Lu  wrote:
>> On Thu, May 24, 2012 at 7:35 AM, Paolo Bonzini  wrote:
>>> Il 24/05/2012 16:01, H.J. Lu ha scritto:
 configure checks if contrib/compare-debug actually works for comparing a
 debug and non-debug .o file before enabling bootstrap-debug.  But some
 compilers encode some command line options (among them -g) into a special
 .comment section.  This patch removes .comment section before comparing
 debug and non-debug files.  OK for trunk?
>>>
>>> Ok.
>>
>> Hi Richard,
>>
>> Before I check it in,  can you verify it enables bootstrap-debug on SuSE?
>>
>
> It doesn't work since the comment section name may be
> .comment.SUSE.OPTs
>

This patch works on openSUSE 12.1.  OK to install?

Thanks.


-- 
H.J.
--
2012-05-24  H.J. Lu  

PR bootstrap/53472
* contrib/compare-debug (remove_comment): New function.
Also remove any .comment sections.

diff --git a/contrib/compare-debug b/contrib/compare-debug
index 010d17f..2468899 100755
--- a/contrib/compare-debug
+++ b/contrib/compare-debug
@@ -73,6 +73,27 @@ Darwin)
   ;;
 esac

+remove_comment ()
+{
+  file=$1
+  opts=
+  for s in `objdump --section-headers "$file" | awk '{ print $2 }'`; do
+case "$s" in
+.comment*)
+  opts="$opts --remove-section $s"
+  ;;
+esac
+  done
+  [ -n "$opts" ] && objcopy $opts $file
+}
+
+# Also remove any .comment sections.
+if (objcopy -v) 2>&1 | grep ' --remove-section' > /dev/null \
+   && (objdump --help) 2>&1 | grep ' --\[*section-\]*headers' > /dev/null; then
+  remove_comment "$1.$suf1"
+  remove_comment "$2.$suf2"
+fi
+
 if cmp "$1.$suf1" "$2.$suf2"; then
   status=0
 else

Re: PATCH: PR bootstrap/53472: contrib/compare-debug should strip out .comment section

[Jakub Jelinek]

On Thu, May 24, 2012 at 02:32:59PM -0700, H.J. Lu wrote:
> This patch works on openSUSE 12.1.  OK to install?

Can't you do that only if the first cmp failed?
In that case strip and cmp again...

> 2012-05-24  H.J. Lu  
> 
>   PR bootstrap/53472
>   * contrib/compare-debug (remove_comment): New function.
>   Also remove any .comment sections.
> 
> diff --git a/contrib/compare-debug b/contrib/compare-debug
> index 010d17f..2468899 100755
> --- a/contrib/compare-debug
> +++ b/contrib/compare-debug
> @@ -73,6 +73,27 @@ Darwin)
>;;
>  esac
> 
> +remove_comment ()
> +{
> +  file=$1
> +  opts=
> +  for s in `objdump --section-headers "$file" | awk '{ print $2 }'`; do
> +case "$s" in
> +.comment*)
> +  opts="$opts --remove-section $s"
> +  ;;
> +esac
> +  done
> +  [ -n "$opts" ] && objcopy $opts $file
> +}
> +
> +# Also remove any .comment sections.
> +if (objcopy -v) 2>&1 | grep ' --remove-section' > /dev/null \
> +   && (objdump --help) 2>&1 | grep ' --\[*section-\]*headers' > /dev/null; 
> then
> +  remove_comment "$1.$suf1"
> +  remove_comment "$2.$suf2"
> +fi
> +
>  if cmp "$1.$suf1" "$2.$suf2"; then
>status=0
>  else

Jakub

Re: [cxx-conversion] New Hash Table (issue6244048)

[Lawrence Crowl]

On 5/24/12, Gabriel Dos Reis  wrote:
> On May 24, 2012 Lawrence Crowl  wrote:
> > Add a type-safe hash table, typed_htab.  Uses of this table
> > replace uses of libiberty's htab_t.  The benefits include less
> > boiler-plate code, full type safety, and improved performance.
>
> Lawrence, is there any chance you could just call it hash_table<>?
> After the conversion, we will be living most of the time in a
> typed world, so the "typed_" prefix will be redundant if not
> confusing :-)

I agree that the name is not great, and have no love of it.
I'd like to get all the name suggestions on the table before I to
a renaming pass.

> > [...]
> >
> > The type-safe hash table is a template, taking the element
> > type and the operational functions as template parameters.
> > Passing the operational functions as template parameters, rather
> > than function pointers, exposes the calls to inlining at -O2.
> > A side effect is that declarations of hash tables move to after
> > the declarations of those functions.  A further side effect
> > is that the control block shrinks from 108 bytes to 44 bytes.
> > There is otherwise no effect on data size.
>
> Nice.
>
> Do you anticipate that at some point we could just pass function
> object classes as template arguments as opposed to functions?
> That of course would retain the nice property of inlining, but
> it would remove the need to make the function have an external
> linkage.  The downside is that change would touch more places
> than your current patch does.

Yes, we could do that.  I'm a little reluctant to make too many
steps in any one patch.

As an example, we could move the control block into the variable for
most uses of the table, but not all.  Doing so would complicate this
patch, and so I thought it best to make that change a separate issue.

That said, I'll let y'all decide how much to put in any one piece.

-- 
Lawrence Crowl

ping x2 : latch mem to reg before multi-access in convert_move

[Olivier Hainque]

Hello,

Ping # 2 for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00298.html

Thanks in advance,

Olivier

(sorry for a possible empty version of that message
sent by mistake a few minutes ago)

On Apr 5, 2012, at 17:30 , Olivier Hainque wrote:
...
> With a previous version of the compiler, we happened to get there
> pretty easily with MEM_P(from) and the multi-insn sequence producing
> multiple memory references to the source.
> 
> The original problem we had with this was the introduction of an
> artificial race condition in addition to the potential performance
> impact.

> While our original testcases don't expose the problem with current
> versions of the compiler, the issue appears to remain latent and the
> change still looks sensible in any case.
...
>* expr.c (convert_move): Latch mem integer inputs into a
>register before expanding a multi-instructions sequence.
> 
> 
> 

Re: [cxx-conversion] New Hash Table (issue6244048)

[Diego Novillo]

On 12-05-24 17:52 , Lawrence Crowl wrote:


That said, I'll let y'all decide how much to put in any one piece.


I favour the approach we are taking now.  Each patch to cxx-conversion 
is a small incremental step.


When we merge into trunk we'll merge the final product of each change, 
of course.  But with the minimalistic approach, we can discuss and 
understand each change better.



Diego.

ping x2: recognize .persistent.bss sections as bss

[Olivier Hainque]

Hello,

Ping # 2 for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00833.html

Thanks in advance,

Olivier

(sorry for a possible duplicate or empty
 version of that message a few minutes ago)

On Apr 13, 2012, at 15:06 , Olivier Hainque wrote:

> For several years now, Ada has support for a "Persistent_BSS" pragma
> that let users place data in a ".persistent.bss" section. This section: 
> 
> - needs to be treated as a bss section by the compiler (in particular,
>  to set flags that will prevent use of space in executable files)
> 
> - can be treated specially by run-time loaders, not resetting to all
>  zeroes on application warm-restarts. 
> 
> This patch simply adds ".persistent.bss" to the list of section names
> that GCC identifies a bss sections.
...
>* varasm.c (default_section_type_flags): Flag .persistent.bss
>sections as SECTION_BSS.
> 
> 

ping x2: use longcall to abort from !pic trampoline setup on ppc-vxworks

[Olivier Hainque]

Hello,

Ping #2 for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00808.html

Thanks in advance,

Olivier

(sorry for a duplicate or empty version of this
 message a few minutes ago)

On Apr 13, 2012, at 10:08 , Olivier Hainque wrote:

> Relocation troubles (24bit reloc overflows) might show up when module
> instructions contain short references to kernel symbols and the module
> happens to be loaded very far away from the kernel in memory.
> 
> As of today, the powerpc "__trampoline_setup" function embeds such a
> potentially problematic reference, in the short call the "abort" at the
> end.
...
>   libgcc/
>   * config/rs6000/vxworks/tramp.S (trampoline_setup): Use a longcall
>   sequence in the non pic case on VxWorks.
> 
> 

Re: PATCH: PR bootstrap/53472: contrib/compare-debug should strip out .comment section

[H.J. Lu]

On Thu, May 24, 2012 at 2:43 PM, Jakub Jelinek  wrote:
> On Thu, May 24, 2012 at 02:32:59PM -0700, H.J. Lu wrote:
>> This patch works on openSUSE 12.1.  OK to install?
>
> Can't you do that only if the first cmp failed?
> In that case strip and cmp again...
>

Like this?  OK to install?

Thanks.

-- 
H.J.
---
2012-05-24  H.J. Lu  

PR bootstrap/53472
* contrib/compare-debug (remove_comment): New function.
Remove any .comment sections if the first cmp failed.

diff --git a/contrib/compare-debug b/contrib/compare-debug
index 010d17f..fb8986d 100755
--- a/contrib/compare-debug
+++ b/contrib/compare-debug
@@ -73,11 +73,35 @@ Darwin)
   ;;
 esac

+remove_comment ()
+{
+  file=$1
+  opts=
+  for s in `objdump --section-headers "$file" | awk '{ print $2 }'`; do
+case "$s" in
+.comment*)
+  opts="$opts --remove-section $s"
+  ;;
+esac
+  done
+  [ -n "$opts" ] && objcopy $opts $file
+}
+
 if cmp "$1.$suf1" "$2.$suf2"; then
   status=0
 else
   status=1

+  # Remove any .comment sections.
+  if (objcopy -v) 2>&1 | grep ' --remove-section' > /dev/null \
+ && (objdump --help) 2>&1 | grep ' --\[*section-\]*headers' >
/dev/null; then
+remove_comment "$1.$suf1"
+remove_comment "$2.$suf2"
+if cmp "$1.$suf1" "$2.$suf2"; then
+  status=0
+fi
+  fi
+
   # Assembler-generated CFI will add an .eh_frame section for -g not
   # present in -g0.  Try to cope with it by checking that an .eh_frame
   # section is present in either object file, and then stripping it

[gimplefe] Add dejagnu support for gimple tests (issue6258047)

[Diego Novillo]

Add basic testsuite support for gimple.

Running the gimple testsuite is the same as running any other
testsuite.  From /gcc, run:

$ make check-gimple

I have added a single .gimple test which is currently segfaulting the
parser.  This means that you will get the following output from
the testsuite:

Running 
/usr/local/google/home/dnovillo/gimplefe/gimple-front-end/gcc/testsuite/gimple.dg/dg.exp
 ...
FAIL: gimple.dg/20120523-1.gimple  -O  (internal compiler error)
FAIL: gimple.dg/20120523-1.gimple  -O  (test for excess errors)

=== gimple Summary ===

# of unexpected failures2

I will fix this in a separate patch, shortly.

To add gimple tests, simply add .gimple files to the directory
testsuite/gimple.dg.  You can use all the dejagnu commands described
in http://gcc.gnu.org/onlinedocs/gccint/Directives.html.


2012-05-24   Diego Novillo  

gimple/ChangeLog
* Make-lang.in: Add support for check-gimple.

testsuite/ChangeLog.gimplefe
* gimple.dg/20120523-1.gimple: New.
* gimple.dg/dg.exp: New.
* lib/gimple-dg.exp: New.
* lib/gimple.exp: New.

diff --git a/gcc/gimple/ChangeLog b/gcc/gimple/ChangeLog
index 9bfc69c..fe274ce 100644
--- a/gcc/gimple/ChangeLog
+++ b/gcc/gimple/ChangeLog
@@ -1,3 +1,7 @@
+2012-05-24   Diego Novillo  
+
+   * Make-lang.in: Add support for check-gimple.
+
 2012-03-23   Diego Novillo  
 
* gimple-lang.c (def_builtin_1): Call set_builtin_decl.
diff --git a/gcc/gimple/Make-lang.in b/gcc/gimple/Make-lang.in
index ed22492..5cab504 100644
--- a/gcc/gimple/Make-lang.in
+++ b/gcc/gimple/Make-lang.in
@@ -64,6 +64,11 @@ gimple.stage4:
 gimple.stageprofile:
 gimple.stagefeedback:
 
+# Testsuite support.
+lang_checks += check-gimple
+lang_checks_parallelized += check-gimple
+check_gimple_parallelize = gimple.exp=*
+
 # GIMPLE rules.
 
 # Use strict warnings for this front end.
diff --git a/gcc/testsuite/ChangeLog.gimplefe b/gcc/testsuite/ChangeLog.gimplefe
new file mode 100644
index 000..31b226d
--- /dev/null
+++ b/gcc/testsuite/ChangeLog.gimplefe
@@ -0,0 +1,6 @@
+2012-05-24   Diego Novillo  
+
+   * gimple.dg/20120523-1.gimple: New.
+   * gimple.dg/dg.exp: New.
+   * lib/gimple-dg.exp: New.
+   * lib/gimple.exp: New.
diff --git a/gcc/testsuite/gimple.dg/20120523-1.gimple 
b/gcc/testsuite/gimple.dg/20120523-1.gimple
new file mode 100644
index 000..54c39ac
--- /dev/null
+++ b/gcc/testsuite/gimple.dg/20120523-1.gimple
@@ -0,0 +1,2 @@
+gimple_assign 
+
diff --git a/gcc/testsuite/gimple.dg/dg.exp b/gcc/testsuite/gimple.dg/dg.exp
new file mode 100644
index 000..54c732f
--- /dev/null
+++ b/gcc/testsuite/gimple.dg/dg.exp
@@ -0,0 +1,39 @@
+# Copyright (C) 2012 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program 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 General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# gimple testsuite that uses the `dg.exp' driver.
+
+# Load support procs.
+load_lib gimple-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_GIMPLEFLAGS
+if ![info exists DEFAULT_GIMPLEFLAGS] then {
+set DEFAULT_GIMPLEFLAGS ""
+}
+
+# Initialize `dg'.
+dg-init
+
+# Gather a list of all tests, with the exception of those in directories
+# that are handled specially.
+set tests [lsort [find $srcdir/$subdir *.gimple]]
+
+# Main loop.
+gimple-dg-runtest $tests $DEFAULT_GIMPLEFLAGS
+
+# All done.
+dg-finish
diff --git a/gcc/testsuite/lib/gimple-dg.exp b/gcc/testsuite/lib/gimple-dg.exp
new file mode 100644
index 000..5ee5adb
--- /dev/null
+++ b/gcc/testsuite/lib/gimple-dg.exp
@@ -0,0 +1,51 @@
+#   Copyright (C) 1997, 1999, 2000, 2003, 2007 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program 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 General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# Define gimple callbacks for dg.exp.
+
+load_lib gcc-dg.exp
+
+proc gimple-dg-test { prog do_what e

Re: [cxx-conversion] Convert vec.[ch] to C++ [1/3] (issue6233044)

[Lawrence Crowl]

On 5/24/12, Diego Novillo  wrote:
> On 12-05-24 04:16 , Richard Guenther wrote:
>> On May 23, 2012 Diego Novillo wrote:
>>> Some client code changes were needed:
>>>
>>> 1- The allocation names 'heap', 'stack' and 'gc' are not embedded in
>>>the type name anymore.  They are enum values used as a template
>>>argument for functions like VEC_alloc() and VEC_free().  Since they
>>>are now separate identifiers, some existing code that declared
>>>variables with the names 'heap' and 'stack' had to change.
>>>
>>>I did not change these enum values to better names because that
>>>would have meant changing a lot more client code.  I will change
>>>this in a future patch.
>>
>> Yeah.  Can we have
>>
>> template<...>
>> struct vec {
>> enum { gc, heap, stack };
>> ...
>> }
>>
>> and use vec  instead?  Not sure if this or something
>> similar
>> is valid C++.
>
> Sure.  Something involving a new namespace, like Gaby suggested
> down-thread.

I like namespaces, but "using namespace" does not work the way most
people think it does.  So, I was planning to defer that issue for
a while.

>>> 2- VEC_index and VEC_last now return a reference to the element.  The
>>>existing APIs implemented two versions of these functions.  One
>>>returning the element itself (used for vec_t).  Another
>>>returning a pointer to the element (used for vec_t).
>>>
>>>This is impossible to represent in C++ directly, as functions
>>>cannot be overloaded by their return value.  Instead, I made them
>>>return a reference to the element.  This means that vectors storing
>>>pointers (T *) do not need to change, but vectors of objects (T) do
>>>need to change.
>>>
>>>We have fewer vec_t  than vec_t, so this was the smaller
>>>change (which still meant changing a few hundred call sites).
>>
>> We still can have const overloads when taking a const vec though?
>
> I'm going to say 'sure' because I don't really think I understand this
> question :)

Yes, we can.

>>> 3- The family of VEC_*push and VEC_*replace functions have overloads
>>>for handling 'T' and 'const T *' objects.  The former is used for
>>>vec_t, the latter for vec_t.  This means, however, than when
>>>pushing the special value 0 on a vec_t, the compiler will not
>>>know which overload we meant, as 0 matches both.  In these cases
>>>(not very many), a static cast is all we need to help it.
>>>
>>>I'm not terribly content with this one.  I'll try to have a better
>>>approach in the second iteration (which will liberally change all
>>>client code).
>>
>> I wonder whether explicitely specifying the template type is better?
>> Thus, VEC_safe_push(0) instead of automatically deducing the
>> template argument?
>
> Not sure.  I didn't like the casts, Lawrence had another suggestion
> involving something like C++11's nullptr.  Lawrence, what was that
> nullptr thing you were telling me earlier?

One would write VEC_save_push(v, nullptr), which unambiguously
means the null pointer.  C++11 has nullptr built in to the language,
but we can approximate it with:

struct nullptr_t {
  template 
  operator T*() { return 0; }
} nullptr;

The downside is that using plain 0 would still be ambiguous.
Programmers that mean the integer would need to cast the 0.

>>> 4- I extended gengtype to understand templated types.  These changes
>>>are not as ugly as I thought they would be.  Gengtype has some
>>>hardwired knowledge of VEC_*, which I renamed to vec_t.  I'm not
>>>even sure why gengtype needs to care about vec_t in this way, but I
>>>was looking for minimal changes, so I just did it.
>>>
>>>The other change is more generic.  It allows gengtype to deal with
>>>templated types.  There is a new function (filter_type_name) that
>>>recognizes C++ special characters '<','>' and ':'.  It turns them
>>>into '_'.  This way, gengtype can generate a valid identifier for
>>>the pre-processor.  It only does this in contexts where it needs a
>>>pre-processor identifier.  For everything else, it emits the type
>>>directly.  So, the functions emitted in gt-*.h files have proper
>>>template type references.
>>
>> Well, that part is of course what needs to change.  I don't think we want
>> gengtype to work like this for templates as this does not scale.
>
> Well, certainly, but that was outside the scope of this one patch.  I'm
> trying to make small incremental steps.
>
>>> 2- Change VEC_index into operator[].
>>>
>>> 3- Change VEC_replace(...) to assignments using operator[].
>>
>> I think these should not be done for now - they merely add syntactic
>> sugar, no?
>
> It makes the code more compact, readable and easier to write.
> I can certainly wait until the branch has been merged to make
> all these changes.  It's going to affect a boatload of call sites.

How about picking a one or two files to show the effect, but leave
the bulk of the call site changes to later change

Re: [PATCH] Add powerpc64-linux configuration options

[David Edelsohn]

On Wed, May 23, 2012 at 6:36 PM, Michael Meissner
 wrote:
> On powerpc64-linux systems that run on IBM servers, the 32-bit software
> emulation library is not built with the Red Hat and SUSE distributions, but 
> the
> FSF sources still list it as a multilib.  This patch adds a configuration
> option (--disable-ppc64-swfloat) to disable building this library.
>
> We've also seen some performance issues where building the multilibs with the
> -mstrict-align option causes slow downs.  I vaguelly recall adding this option
> in the 1995 time frame, because the 603, 604 systems of the day did not handle
> unaligned accesses in little endian mode, and maybe some of the other embedded
> chips did not handle unaligned accesses at all.  This patch also adds an 
> option
> (--disable-ppc64-strict-align) to disable building the multilibs with
> -mstrict-align.

I thought the use of -mstrict-align for multilibs was because of some
re-use by embedded distros. That somehow one could build apps for
embedded PowerPC processors without a full embedded cross-toolchain --
just using the regular toolchain with an embedded target command line
option and the base libraries already worked. I am not suggesting that
(ab)use is appropriate, but I don't want to break embedded
environments.

I agree that strict-align does not make sense for PPC64.

I believe that is what you are accomplishing with the second version
of your patch, correct?

Thanks, David

Re: [PATCH] Add powerpc64-linux configuration options

[Alan Modra]

On Thu, May 24, 2012 at 01:45:41PM -0400, Michael Meissner wrote:
> This alternative patch just disables building the 32-bit softfloat multlib, 
> and
> removes the -mstrict-align in the powerpc64-linux case.
> 
> I have bootstrapped it and had no regressions.
> 
> David, which patch do you prefer?
> 
> 2012-05-24  Michael Meissner  
> 
>   * config/rs6000/t-linux64: Delete the 32-bit multilib that uses
>   software floating point emulation.  No longer build the multilibs
>   with -mstrict-align.

I like this patch.  I like it because all uses of MULTILIB_EXTRA_OPTS
are suspect.  Why?  The option is not applied to the default multilib!
That means that prior to this patch you get different libraries
depending on the compiler default.  For example, a powerpc-linux gcc
defaulting to -m32 builds the 32-bit libraries without -mstrict-align,
while a powerpc64-linux gcc defaulting to -m64 builds the 32-bit
libraries with -mstrict-align.  This is confusing to say the least,
and I recall seeing libstdc++ test failures due to the difference.

I've had "MULTILIB_EXTRA_OPTS =" in my t-linux64 for quite some time.

-- 
Alan Modra
Australia Development Lab, IBM

Re: use longcall to abort from !pic trampoline setup on ppc-vxworks

[David Edelsohn]

libgcc/
* config/rs6000/vxworks/tramp.S (trampoline_setup): Use a longcall
sequence in the non pic case on VxWorks.

+ addis 11, 0,JUMP_TARGET(abort)@ha

Why do you use the addis mnemonic instead of lis mnemonic? Yes, lis
X,Y is an alias for addis X,0,Y, but the simplified mnemonic clearer
about the actual operation and intention.

The patch is okay with that change.

Thanks, David

[C++ Patch] PR 32054

[Paolo Carlini]

Hi,

another simple issue, this one remained assigned to me for a while ;) 
Anyway, we are not rejecting storage classes for anonymous unions in 
class scope. Details: I'm handling anonymous structs in the same way, 
for consistency (but in principle being an extension we could do 
nothing); the error message I choose is quite terse (essentially the 
beginning of the Standard wording about this issue); in terms of 
testing, auto is of course special in C++11 (I could also, for example, 
wrap the lines for the auto case in #ifndef __GXX_EXPERIMENTAL_CXX0X__)


Bootstrapped and tested x86_64-linux, as usual.

Thanks,
Paolo.

//
/cp
2012-05-25  Paolo Carlini  

PR c++/32054
* parser.c (cp_parser_member_declaration): A storage class is not
allowed in a declaration of an anonymous union (and struct, as a
GCC extension) in a class scope.

/testsuite
2012-05-25  Paolo Carlini  

PR c++/32054
* g++.dg/other/anon-union3.C: New.

Index: testsuite/g++.dg/other/anon-union3.C
===
--- testsuite/g++.dg/other/anon-union3.C(revision 0)
+++ testsuite/g++.dg/other/anon-union3.C(revision 0)
@@ -0,0 +1,25 @@
+// PR c++/32054
+
+class C
+{
+  auto union  // { dg-error "storage class" "" { target c++98 } }
+{
+  int a;
+};// { dg-error "multiple|specified" "" { target c++11 } }
+  register union  // { dg-error "storage class" }
+{
+  int b;
+};
+  static union// { dg-error "storage class" }
+{
+  int c;
+};
+  extern union// { dg-error "storage class" }
+{
+  int d;
+};
+  mutable union   // { dg-error "storage class" }
+{
+  int e;
+};
+};
Index: cp/parser.c
===
--- cp/parser.c (revision 187868)
+++ cp/parser.c (working copy)
@@ -18910,6 +18910,11 @@ cp_parser_member_declaration (cp_parser* parser)
 particular type), as opposed to a nested class.  */
  else if (ANON_AGGR_TYPE_P (type))
{
+ /* C++11 9.5/6.  */
+ if (decl_specifiers.storage_class != sc_none)
+   error_at (decl_spec_token_start->location,
+ "a storage class is not allowed");
+
  /* Remove constructors and such from TYPE, now that we
 know it is an anonymous aggregate.  */
  fixup_anonymous_aggr (type);

Re: [cxx-conversion] New Hash Table (issue6244048)

[Jakub Jelinek]

On Thu, May 24, 2012 at 09:43:42AM -0700, Lawrence Crowl wrote:
> Add a type-safe hash table, typed_htab.  Uses of this table replace
> uses of libiberty's htab_t.  The benefits include less boiler-plate
> code, full type safety, and improved performance.

You haven't looked at the most important problem of that approach -
code bloat.  hashtab.o .text is currently ~ 4KB on x86_64, in your version
only very small part out of it is shared.  In a cc1plus binary I count
roughly 179 htab_create{,_ggc} calls, ignoring the first parameter (initial
size) that is roughly 139 unique hash/eq/del fn combinations, thus you'll
end up with over hundred copies of most of the hashtab code, in many of the
cases performance critical and thus its I-cache friendliness is quite
important.

> Static functions are also not acceptable as template arguments, so
> this patch externalizes the functions.  To avoid potential name
> conflicts, the function names have been prefixed.

Ugh.  I guess the C++ way around this would be to put the functions into
anonymous namespace.

> +  /* Return the current size of this hash table.  */
> +
> +  size_t size()
> +  {
> +return htab->size;
> +  }

(and various other places) - formatting is wrong, missing space between (.

> +void
> +typed_htab 
> +::dispose ()

Do we want to format methods this way?

Jakub

Re: PATCH: PR bootstrap/53472: contrib/compare-debug should strip out .comment section

[Paolo Bonzini]

> 2012-05-24  H.J. Lu  
>
>        PR bootstrap/53472
>        * contrib/compare-debug (remove_comment): New function.
>        Remove any .comment sections if the first cmp failed.

Ok.

Paolo

> diff --git a/contrib/compare-debug b/contrib/compare-debug
> index 010d17f..fb8986d 100755
> --- a/contrib/compare-debug
> +++ b/contrib/compare-debug
> @@ -73,11 +73,35 @@ Darwin)
>   ;;
>  esac
>
> +remove_comment ()
> +{
> +  file=$1
> +  opts=
> +  for s in `objdump --section-headers "$file" | awk '{ print $2 }'`; do
> +    case "$s" in
> +    .comment*)
> +      opts="$opts --remove-section $s"
> +      ;;
> +    esac
> +  done
> +  [ -n "$opts" ] && objcopy $opts $file
> +}
> +
>  if cmp "$1.$suf1" "$2.$suf2"; then
>   status=0
>  else
>   status=1
>
> +  # Remove any .comment sections.
> +  if (objcopy -v) 2>&1 | grep ' --remove-section' > /dev/null \
> +     && (objdump --help) 2>&1 | grep ' --\[*section-\]*headers' >
> /dev/null; then
> +    remove_comment "$1.$suf1"
> +    remove_comment "$2.$suf2"
> +    if cmp "$1.$suf1" "$2.$suf2"; then
> +      status=0
> +    fi
> +  fi
> +
>   # Assembler-generated CFI will add an .eh_frame section for -g not
>   # present in -g0.  Try to cope with it by checking that an .eh_frame
>   # section is present in either object file, and then stripping it
>