Re: PATCH [1/n] addr32: Properly use Pmode and word_mode

2012-03-05 Thread Uros Bizjak
On Mon, Mar 5, 2012 at 9:01 AM, Uros Bizjak ubiz...@gmail.com wrote:

 @@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
 ix86_address *out)
   else
     disp = addr;                       /* displacement */

 +  /* Since address override works only on the (reg) part in fs:(reg),
 +     we can't use it as memory operand.  */
 +  if (Pmode != word_mode  seg == SEG_FS  (base || index))
 +    return 0;

 Can you explain the above some more? IMO, if the override works on
 (reg) part, this is just what we want.

 When Pmode == SImode, we have

 fs segment register == 0x1001

 and

 base register (SImode) == -1 (0x).

 We are expecting address to be 0x1001 - 1 == 0x1000.  But, what we get
 is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only applies to
 base register to zero-extend 0x to 64bit.

 I would call this a bug in the specification - I guess that
 0x1001(%eax) works correctly.

 We will treat this issue as a bug.

Nice, we have TARGET_TLS_DIRECT_SEG_REFS option. We can just clear it
somewhere appropriate when Pmode != word_mode.

Uros.


[PATCH] [4.7?] Fix PR 52250

2012-03-05 Thread Andrey Belevantsev

Hello,

The PR is about selective scheduling not trying hard enough to find a 
neighbor block to stick the note list from an empty block being removed. 
Fixed by a) trying harder and b) making sure that if we fail to find the 
right place, we just drop the notes instead of asserting.


Tested on x86-64 and ia64, approved by Alexander offline.  No test as it 
has quite insane number of flags that would likely stop reproducing the 
core issue in a few weeks.


Richard, Jakub, I can commit this to trunk today or to wait until the 
release.  The patch is very safe and so can be committed in case we will 
need an RC2, if you want one bug less in a release, but I would feel 
equally happy to postpone it until 4.7.1 as the problematic situation is 
quite rare (and probably requires pipelining outer loops to trigger which 
is disabled with ia64/-O3).


Yours,
Andrey

2012-03-05  Andrey Belevantsev  a...@ispras.ru

PR rtl-optimization/52250
* sel-sched-ir.c (maybe_tidy_empty_bb): Try harder to find a bb
to put note list into.  Unconditionally call move_bb_info.
(move_bb_info): Do not assert the blocks being in the same region,
just drop the note list if they are not.


diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index a93cd68..c53d2e1 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -3658,7 +3658,7 @@ sel_recompute_toporder (void)
 static bool
 maybe_tidy_empty_bb (basic_block bb)
 {
-  basic_block succ_bb, pred_bb;
+  basic_block succ_bb, pred_bb, note_bb;
   VEC (basic_block, heap) *dom_bbs;
   edge e;
   edge_iterator ei;
@@ -3697,6 +3697,17 @@ maybe_tidy_empty_bb (basic_block bb)
   pred_bb = NULL;
   dom_bbs = NULL;

+  /* Save a pred/succ from the current region to attach the notes to.  */
+  note_bb = NULL;
+  FOR_EACH_EDGE (e, ei, bb-preds)
+if (in_current_region_p (e-src))
+  {
+   note_bb = e-src;
+   break;
+  }
+  if (note_bb == NULL)
+note_bb = succ_bb;
+
   /* Redirect all non-fallthru edges to the next bb.  */
   while (rescan_p)
 {
@@ -3746,10 +3757,8 @@ maybe_tidy_empty_bb (basic_block bb)
   else
 {
   /* This is a block without fallthru predecessor.  Just delete it.  */
-  gcc_assert (pred_bb != NULL);
-
-  if (in_current_region_p (pred_bb))
-   move_bb_info (pred_bb, bb);
+  gcc_assert (note_bb);
+  move_bb_info (note_bb, bb);
   remove_empty_bb (bb, true);
 }

@@ -5231,10 +5240,9 @@ sel_remove_bb (basic_block bb, bool remove_from_cfg_p)
 static void
 move_bb_info (basic_block merge_bb, basic_block empty_bb)
 {
-  gcc_assert (in_current_region_p (merge_bb));
-
-  concat_note_lists (BB_NOTE_LIST (empty_bb),
-BB_NOTE_LIST (merge_bb));
+  if (in_current_region_p (merge_bb))
+concat_note_lists (BB_NOTE_LIST (empty_bb),
+  BB_NOTE_LIST (merge_bb));
   BB_NOTE_LIST (empty_bb) = NULL_RTX;

 }


Re: [PATCH 05/10] addr32: Load TP into register for TLS_MODEL_LOCAL_EXEC modes in x32

2012-03-05 Thread Uros Bizjak
On Fri, Mar 2, 2012 at 9:56 PM, H.J. Lu hongjiu...@intel.com wrote:

 Since the 0x67 address prefix only zeros out the upper 32bits of the
 (reg) part in address fs:(reg), we can't use fs:(reg) as memory operand
 for x32 with Pmode == SImode.  We have to load the address into a
 register first and use it as memory operand.  Tested on Linux/x86-64.
 OK for trunk?

This patch won't be needed when TARGET_TLS_DIRECT_SEG_REFS will be
cleared, as suggested in [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00252.html

Uros.


Re: [PATCH 10/10] addr32: Add *zero_extendsidi2_x32.

2012-03-05 Thread Uros Bizjak
On Fri, Mar 2, 2012 at 10:14 PM, H.J. Lu hongjiu...@intel.com wrote:

 This is the last patch for Pmode == SImod in x32. In x32, the return value
 of the symbol address must be zero-extended to DImode, This patch adds
 *zero_extendsidi2_x32 to load the address of a symbol in SImode and
 zero-extend it to DImode. It works for x32 since the address size is 32bit.
 OK for trunk?

Can you please try attached patch instead? It enhances existing insn
pattern with required functionality.

Uros.
Index: i386.md
===
--- i386.md (revision 184917)
+++ i386.md (working copy)
@@ -3375,10 +3375,10 @@
 
 (define_insn *zero_extendsidi2_rex64
   [(set (match_operand:DI 0 nonimmediate_operand
-   =r,o,?*Ym,?*y,?*Yi,!*x)
+   =r ,o,?*Ym,?*y,?*Yi,!*x)
(zero_extend:DI
-(match_operand:SI 1 nonimmediate_operand
-   rm,0,r   ,m  ,r   ,m*x)))]
+(match_operand:SI 1 x86_64_zext_general_operand
+   rmZ,0,r   ,m  ,r   ,m*x)))]
   TARGET_64BIT
   @
mov{l}\t{%1, %k0|%k0, %1}
Index: predicates.md
===
--- predicates.md   (revision 184917)
+++ predicates.md   (working copy)
@@ -341,6 +341,14 @@
 (match_operand 0 general_operand)))
 
 ;; Return true if OP is general operand representable on x86_64
+;; as zero extended constant.
+(define_predicate x86_64_zext_general_operand
+  (if_then_else (match_test TARGET_64BIT)
+(ior (match_operand 0 nonimmediate_operand)
+(match_operand 0 x86_64_zext_immediate_operand))
+(match_operand 0 general_operand)))
+
+;; Return true if OP is general operand representable on x86_64
 ;; as either sign extended or zero extended constant.
 (define_predicate x86_64_szext_general_operand
   (if_then_else (match_test TARGET_64BIT)


Re: [PATCH] [4.7?] Fix PR 52250

2012-03-05 Thread Richard Guenther
2012/3/5 Andrey Belevantsev a...@ispras.ru:
 Hello,

 The PR is about selective scheduling not trying hard enough to find a
 neighbor block to stick the note list from an empty block being removed.
 Fixed by a) trying harder and b) making sure that if we fail to find the
 right place, we just drop the notes instead of asserting.

 Tested on x86-64 and ia64, approved by Alexander offline.  No test as it has
 quite insane number of flags that would likely stop reproducing the core
 issue in a few weeks.

 Richard, Jakub, I can commit this to trunk today or to wait until the
 release.  The patch is very safe and so can be committed in case we will
 need an RC2, if you want one bug less in a release, but I would feel equally
 happy to postpone it until 4.7.1 as the problematic situation is quite rare
 (and probably requires pipelining outer loops to trigger which is disabled
 with ia64/-O3).

Note that 4.7 has branched, so you can commit to trunk.  As it's a
non-standard option please defer backport until after the release of 4.7.0.

Thanks,
Richard.

 Yours,
 Andrey

 2012-03-05  Andrey Belevantsev  a...@ispras.ru

        PR rtl-optimization/52250
        * sel-sched-ir.c (maybe_tidy_empty_bb): Try harder to find a bb
        to put note list into.  Unconditionally call move_bb_info.
        (move_bb_info): Do not assert the blocks being in the same region,
        just drop the note list if they are not.


 diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
 index a93cd68..c53d2e1 100644
 --- a/gcc/sel-sched-ir.c
 +++ b/gcc/sel-sched-ir.c
 @@ -3658,7 +3658,7 @@ sel_recompute_toporder (void)
  static bool
  maybe_tidy_empty_bb (basic_block bb)
  {
 -  basic_block succ_bb, pred_bb;
 +  basic_block succ_bb, pred_bb, note_bb;
   VEC (basic_block, heap) *dom_bbs;
   edge e;
   edge_iterator ei;
 @@ -3697,6 +3697,17 @@ maybe_tidy_empty_bb (basic_block bb)
   pred_bb = NULL;
   dom_bbs = NULL;

 +  /* Save a pred/succ from the current region to attach the notes to.  */
 +  note_bb = NULL;
 +  FOR_EACH_EDGE (e, ei, bb-preds)
 +    if (in_current_region_p (e-src))
 +      {
 +       note_bb = e-src;
 +       break;
 +      }
 +  if (note_bb == NULL)
 +    note_bb = succ_bb;
 +
   /* Redirect all non-fallthru edges to the next bb.  */
   while (rescan_p)
     {
 @@ -3746,10 +3757,8 @@ maybe_tidy_empty_bb (basic_block bb)
   else
     {
       /* This is a block without fallthru predecessor.  Just delete it.  */
 -      gcc_assert (pred_bb != NULL);
 -
 -      if (in_current_region_p (pred_bb))
 -       move_bb_info (pred_bb, bb);
 +      gcc_assert (note_bb);
 +      move_bb_info (note_bb, bb);
       remove_empty_bb (bb, true);
     }

 @@ -5231,10 +5240,9 @@ sel_remove_bb (basic_block bb, bool
 remove_from_cfg_p)
  static void
  move_bb_info (basic_block merge_bb, basic_block empty_bb)
  {
 -  gcc_assert (in_current_region_p (merge_bb));
 -
 -  concat_note_lists (BB_NOTE_LIST (empty_bb),
 -                    BB_NOTE_LIST (merge_bb));
 +  if (in_current_region_p (merge_bb))
 +    concat_note_lists (BB_NOTE_LIST (empty_bb),
 +                      BB_NOTE_LIST (merge_bb));
   BB_NOTE_LIST (empty_bb) = NULL_RTX;

  }


Re: Fix 64-bit *intmax_t definitions on IRIX

2012-03-05 Thread Rainer Orth
Richard Sandiford rdsandif...@googlemail.com writes:

 Rainer Orth r...@cebitec.uni-bielefeld.de writes:
 2012-02-22  Rainer Orth  r...@cebitec.uni-bielefeld.de

  * config/mips/iris6.h [!USED_FOR_TARGET] (long_intmax): Declare.
  (INTMAX_TYPE): Use it.
  (UINTMAX_TYPE): Likewise.
  (SUBTARGET_OVERRIDE_OPTIONS): Define.
  (irix6_c_common_override_options): Declare.
  (C_COMMON_OVERRIDE_OPTIONS): Define.
  * config/mips/mips.c [TARGET_IRIX6] (long_intmax): Define.
  * config/mips/irix6-c.c: New file.
  * config/mips/t-irix6 (irix6-c.o): New target.
  * config.gcc (mips-sgi-irix6.5): Set c_target_objs,
  cxx_target_objs.

 OK for mips.c bit, thanks.  Everything else is yours.

Testing has completed successfully.  I'd like to apply this patch to the
4.7 branch only, since I'm about to remove the obsolete IRIX port in
4.8.

Ok?
Rainer

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


Re: Fix 64-bit *intmax_t definitions on IRIX

2012-03-05 Thread Richard Guenther
On Mon, 5 Mar 2012, Rainer Orth wrote:

 Richard Sandiford rdsandif...@googlemail.com writes:
 
  Rainer Orth r...@cebitec.uni-bielefeld.de writes:
  2012-02-22  Rainer Orth  r...@cebitec.uni-bielefeld.de
 
 * config/mips/iris6.h [!USED_FOR_TARGET] (long_intmax): Declare.
 (INTMAX_TYPE): Use it.
 (UINTMAX_TYPE): Likewise.
 (SUBTARGET_OVERRIDE_OPTIONS): Define.
 (irix6_c_common_override_options): Declare.
 (C_COMMON_OVERRIDE_OPTIONS): Define.
 * config/mips/mips.c [TARGET_IRIX6] (long_intmax): Define.
 * config/mips/irix6-c.c: New file.
 * config/mips/t-irix6 (irix6-c.o): New target.
 * config.gcc (mips-sgi-irix6.5): Set c_target_objs,
 cxx_target_objs.
 
  OK for mips.c bit, thanks.  Everything else is yours.
 
 Testing has completed successfully.  I'd like to apply this patch to the
 4.7 branch only, since I'm about to remove the obsolete IRIX port in
 4.8.
 
 Ok?

Ok.

Thanks,
Richard.


Patch ping

2012-03-05 Thread Jakub Jelinek
Hi!

I'd like to ping two patches deferred to 4.8.  I've bootstrapped/regtested
them on x86_64-linux and i686-linux:

- PR51721 VRP register_edge_assert_for_2 improvements
  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00046.html

- PR51902 dwarf2out .debug_ranges ~ 22% reduction
  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01171.html

Jakub


[PATCH] cfg_layout_merge_blocks cleanup

2012-03-05 Thread Jakub Jelinek
Hi!

Here is a tiny cleanup, written as part of PR52139 fix.
Bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

2012-03-05  Jakub Jelinek  ja...@redhat.com

* cfgrtl.c (cfg_layout_merge_blocks): Cleanup.

--- gcc/cfgrtl.c.jj 2012-02-07 16:05:47.977533716 +0100
+++ gcc/cfgrtl.c2012-02-07 17:03:52.925956927 +0100
@@ -2818,6 +2818,7 @@ static void
 cfg_layout_merge_blocks (basic_block a, basic_block b)
 {
   bool forwarder_p = (b-flags  BB_FORWARDER_BLOCK) != 0;
+  rtx insn;
 
   gcc_checking_assert (cfg_layout_can_merge_blocks_p (a, b));
 
@@ -2883,40 +2884,28 @@ cfg_layout_merge_blocks (basic_block a,
   /* In the case basic blocks are not adjacent, move them around.  */
   if (NEXT_INSN (BB_END (a)) != BB_HEAD (b))
 {
-  rtx first = unlink_insn_chain (BB_HEAD (b), BB_END (b));
+  insn = unlink_insn_chain (BB_HEAD (b), BB_END (b));
 
-  emit_insn_after_noloc (first, BB_END (a), a);
-  /* Skip possible DELETED_LABEL insn.  */
-  if (!NOTE_INSN_BASIC_BLOCK_P (first))
-   first = NEXT_INSN (first);
-  gcc_assert (NOTE_INSN_BASIC_BLOCK_P (first));
-  BB_HEAD (b) = NULL;
-
-  /* emit_insn_after_noloc doesn't call df_insn_change_bb.
- We need to explicitly call. */
-  update_bb_for_insn_chain (NEXT_INSN (first),
-   BB_END (b),
-   a);
-
-  delete_insn (first);
+  emit_insn_after_noloc (insn, BB_END (a), a);
 }
   /* Otherwise just re-associate the instructions.  */
   else
 {
-  rtx insn;
-
-  update_bb_for_insn_chain (BB_HEAD (b), BB_END (b), a);
-
   insn = BB_HEAD (b);
-  /* Skip possible DELETED_LABEL insn.  */
-  if (!NOTE_INSN_BASIC_BLOCK_P (insn))
-   insn = NEXT_INSN (insn);
-  gcc_assert (NOTE_INSN_BASIC_BLOCK_P (insn));
-  BB_HEAD (b) = NULL;
   BB_END (a) = BB_END (b);
-  delete_insn (insn);
 }
 
+  /* emit_insn_after_noloc doesn't call df_insn_change_bb.
+ We need to explicitly call. */
+  update_bb_for_insn_chain (insn, BB_END (b), a);
+
+  /* Skip possible DELETED_LABEL insn.  */
+  if (!NOTE_INSN_BASIC_BLOCK_P (insn))
+insn = NEXT_INSN (insn);
+  gcc_assert (NOTE_INSN_BASIC_BLOCK_P (insn));
+  BB_HEAD (b) = NULL;
+  delete_insn (insn);
+
   df_bb_delete (b-index);
 
   /* Possible tablejumps and barriers should appear after the block.  */

Jakub


Re: [PATCH] cfg_layout_merge_blocks cleanup

2012-03-05 Thread Richard Guenther
On Mon, 5 Mar 2012, Jakub Jelinek wrote:

 Hi!
 
 Here is a tiny cleanup, written as part of PR52139 fix.
 Bootstrapped/regtested on x86_64-linux and i686-linux,
 ok for trunk?

Ok.

Thanks,
Richard.

 2012-03-05  Jakub Jelinek  ja...@redhat.com
 
   * cfgrtl.c (cfg_layout_merge_blocks): Cleanup.
 
 --- gcc/cfgrtl.c.jj   2012-02-07 16:05:47.977533716 +0100
 +++ gcc/cfgrtl.c  2012-02-07 17:03:52.925956927 +0100
 @@ -2818,6 +2818,7 @@ static void
  cfg_layout_merge_blocks (basic_block a, basic_block b)
  {
bool forwarder_p = (b-flags  BB_FORWARDER_BLOCK) != 0;
 +  rtx insn;
  
gcc_checking_assert (cfg_layout_can_merge_blocks_p (a, b));
  
 @@ -2883,40 +2884,28 @@ cfg_layout_merge_blocks (basic_block a,
/* In the case basic blocks are not adjacent, move them around.  */
if (NEXT_INSN (BB_END (a)) != BB_HEAD (b))
  {
 -  rtx first = unlink_insn_chain (BB_HEAD (b), BB_END (b));
 +  insn = unlink_insn_chain (BB_HEAD (b), BB_END (b));
  
 -  emit_insn_after_noloc (first, BB_END (a), a);
 -  /* Skip possible DELETED_LABEL insn.  */
 -  if (!NOTE_INSN_BASIC_BLOCK_P (first))
 - first = NEXT_INSN (first);
 -  gcc_assert (NOTE_INSN_BASIC_BLOCK_P (first));
 -  BB_HEAD (b) = NULL;
 -
 -  /* emit_insn_after_noloc doesn't call df_insn_change_bb.
 - We need to explicitly call. */
 -  update_bb_for_insn_chain (NEXT_INSN (first),
 - BB_END (b),
 - a);
 -
 -  delete_insn (first);
 +  emit_insn_after_noloc (insn, BB_END (a), a);
  }
/* Otherwise just re-associate the instructions.  */
else
  {
 -  rtx insn;
 -
 -  update_bb_for_insn_chain (BB_HEAD (b), BB_END (b), a);
 -
insn = BB_HEAD (b);
 -  /* Skip possible DELETED_LABEL insn.  */
 -  if (!NOTE_INSN_BASIC_BLOCK_P (insn))
 - insn = NEXT_INSN (insn);
 -  gcc_assert (NOTE_INSN_BASIC_BLOCK_P (insn));
 -  BB_HEAD (b) = NULL;
BB_END (a) = BB_END (b);
 -  delete_insn (insn);
  }
  
 +  /* emit_insn_after_noloc doesn't call df_insn_change_bb.
 + We need to explicitly call. */
 +  update_bb_for_insn_chain (insn, BB_END (b), a);
 +
 +  /* Skip possible DELETED_LABEL insn.  */
 +  if (!NOTE_INSN_BASIC_BLOCK_P (insn))
 +insn = NEXT_INSN (insn);
 +  gcc_assert (NOTE_INSN_BASIC_BLOCK_P (insn));
 +  BB_HEAD (b) = NULL;
 +  delete_insn (insn);
 +
df_bb_delete (b-index);
  
/* Possible tablejumps and barriers should appear after the block.  */
 
   Jakub
 
 

-- 
Richard Guenther rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

[C++ PATCH] Change local_specializations from htab_t to pointer map

2012-03-05 Thread Jakub Jelinek
Hi!

This patch changes local_specializations into a pointer map. 
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2012-03-05  Jakub Jelinek  ja...@redhat.com

* pt.c (local_specializations): Change from htab_t into
struct pointer_map_t *.
(retrieve_local_specializations, register_local_specialization,
tsubst_pack_expansion, instantiate_decl): Adjust users.
(eq_local_specializations, hash_local_specialization): Remove.

--- gcc/cp/pt.c.jj  2012-02-15 07:35:05.013340385 +0100
+++ gcc/cp/pt.c 2012-03-05 08:20:55.422649037 +0100
@@ -79,7 +79,7 @@ static tree cur_stmt_expr;
 /* A map from local variable declarations in the body of the template
presently being instantiated to the corresponding instantiated
local variables.  */
-static htab_t local_specializations;
+static struct pointer_map_t *local_specializations;
 
 typedef struct GTY(()) spec_entry
 {
@@ -189,7 +189,6 @@ static tree for_each_template_parm_r (tr
 static tree copy_default_args_to_explicit_spec_1 (tree, tree);
 static void copy_default_args_to_explicit_spec (tree);
 static int invalid_nontype_parm_type_p (tree, tsubst_flags_t);
-static int eq_local_specializations (const void *, const void *);
 static bool dependent_template_arg_p (tree);
 static bool any_template_arguments_need_structural_equality_p (tree);
 static bool dependent_type_p_r (tree);
@@ -1078,14 +1077,13 @@ retrieve_specialization (tree tmpl, tree
 static tree
 retrieve_local_specialization (tree tmpl)
 {
-  tree spec;
+  void **slot;
 
   if (local_specializations == NULL)
 return NULL_TREE;
 
-  spec = (tree) htab_find_with_hash (local_specializations, tmpl,
-htab_hash_pointer (tmpl));
-  return spec ? TREE_PURPOSE (spec) : NULL_TREE;
+  slot = pointer_map_contains (local_specializations, tmpl);
+  return slot ? (tree) *slot : NULL_TREE;
 }
 
 /* Returns nonzero iff DECL is a specialization of TMPL.  */
@@ -1677,24 +1675,6 @@ reregister_specialization (tree spec, tr
   return 0;
 }
 
-/* Compare an entry in the local specializations hash table P1 (which
-   is really a pointer to a TREE_LIST) with P2 (which is really a
-   DECL).  */
-
-static int
-eq_local_specializations (const void *p1, const void *p2)
-{
-  return TREE_VALUE ((const_tree) p1) == (const_tree) p2;
-}
-
-/* Hash P1, an entry in the local specializations table.  */
-
-static hashval_t
-hash_local_specialization (const void* p1)
-{
-  return htab_hash_pointer (TREE_VALUE ((const_tree) p1));
-}
-
 /* Like register_specialization, but for local declarations.  We are
registering SPEC, an instantiation of TMPL.  */
 
@@ -1703,9 +1683,8 @@ register_local_specialization (tree spec
 {
   void **slot;
 
-  slot = htab_find_slot_with_hash (local_specializations, tmpl,
-  htab_hash_pointer (tmpl), INSERT);
-  *slot = build_tree_list (spec, tmpl);
+  slot = pointer_map_insert (local_specializations, tmpl);
+  *slot = spec;
 }
 
 /* TYPE is a class type.  Returns true if TYPE is an explicitly
@@ -9307,7 +9286,7 @@ tsubst_pack_expansion (tree t, tree args
   int missing_level = 0;
   int i, len = -1;
   tree result;
-  htab_t saved_local_specializations = NULL;
+  struct pointer_map_t *saved_local_specializations = NULL;
   bool need_local_specializations = false;
   int levels;
 
@@ -9492,14 +9471,11 @@ tsubst_pack_expansion (tree t, tree args
   if (need_local_specializations)
 {
   /* We're in a late-specified return type, so create our own local
-specializations table; the current table is either NULL or (in the
+specializations map; the current map is either NULL or (in the
 case of recursive unification) might have bindings that we don't
 want to use or alter.  */
   saved_local_specializations = local_specializations;
-  local_specializations = htab_create (37,
-  hash_local_specialization,
-  eq_local_specializations,
-  NULL);
+  local_specializations = pointer_map_create ();
 }
 
   /* For each argument in each argument pack, substitute into the
@@ -9586,7 +9562,7 @@ tsubst_pack_expansion (tree t, tree args
 
   if (need_local_specializations)
 {
-  htab_delete (local_specializations);
+  pointer_map_destroy (local_specializations);
   local_specializations = saved_local_specializations;
 }
   
@@ -18704,7 +18680,7 @@ instantiate_decl (tree d, int defer_ok,
 synthesize_method (d);
   else if (TREE_CODE (d) == FUNCTION_DECL)
 {
-  htab_t saved_local_specializations;
+  struct pointer_map_t *saved_local_specializations;
   tree subst_decl;
   tree tmpl_parm;
   tree spec_parm;
@@ -18714,10 +18690,7 @@ instantiate_decl (tree d, int defer_ok,
   saved_local_specializations = local_specializations;
 
   /* Set up the list of local 

[PATCH] Improve trivial foldings with VECTOR_CSTs

2012-03-05 Thread Richard Guenther

This handles VECTOR_CSTs in integer_zerop, integer_onep and 
integer_all_onesp to allow trivial foldings to work on them.

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

Richard.

2012-03-05  Richard Guenther  rguent...@suse.de

* tree.c (integer_zerop): Handle VECTOR_CSTs.
(integer_onep): Likewise.
(integer_all_onesp): Likewise.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 184390)
+++ gcc/tree.c  (working copy)
@@ -1714,12 +1714,25 @@ integer_zerop (const_tree expr)
 {
   STRIP_NOPS (expr);
 
-  return ((TREE_CODE (expr) == INTEGER_CST
-   TREE_INT_CST_LOW (expr) == 0
-   TREE_INT_CST_HIGH (expr) == 0)
- || (TREE_CODE (expr) == COMPLEX_CST
-  integer_zerop (TREE_REALPART (expr))
-  integer_zerop (TREE_IMAGPART (expr;
+  switch (TREE_CODE (expr))
+{
+case INTEGER_CST:
+  return (TREE_INT_CST_LOW (expr) == 0
+  TREE_INT_CST_HIGH (expr) == 0);
+case COMPLEX_CST:
+  return (integer_zerop (TREE_REALPART (expr))
+  integer_zerop (TREE_IMAGPART (expr)));
+case VECTOR_CST:
+  {
+   tree elt;
+   for (elt = TREE_VECTOR_CST_ELTS (expr); elt; elt = TREE_CHAIN (elt))
+ if (!integer_zerop (TREE_VALUE (elt)))
+   return false;
+   return true;
+  }
+default:
+  return false;
+}
 }
 
 /* Return 1 if EXPR is the integer constant one or the corresponding
@@ -1730,12 +1743,25 @@ integer_onep (const_tree expr)
 {
   STRIP_NOPS (expr);
 
-  return ((TREE_CODE (expr) == INTEGER_CST
-   TREE_INT_CST_LOW (expr) == 1
-   TREE_INT_CST_HIGH (expr) == 0)
- || (TREE_CODE (expr) == COMPLEX_CST
-  integer_onep (TREE_REALPART (expr))
-  integer_zerop (TREE_IMAGPART (expr;
+  switch (TREE_CODE (expr))
+{
+case INTEGER_CST:
+  return (TREE_INT_CST_LOW (expr) == 1
+  TREE_INT_CST_HIGH (expr) == 0);
+case COMPLEX_CST:
+  return (integer_onep (TREE_REALPART (expr))
+  integer_zerop (TREE_IMAGPART (expr)));
+case VECTOR_CST:
+  {
+   tree elt;
+   for (elt = TREE_VECTOR_CST_ELTS (expr); elt; elt = TREE_CHAIN (elt))
+ if (!integer_onep (TREE_VALUE (elt)))
+   return false;
+   return true;
+  }
+default:
+  return false;
+}
 }
 
 /* Return 1 if EXPR is an integer containing all 1's in as much precision as
@@ -1754,6 +1780,15 @@ integer_all_onesp (const_tree expr)
integer_zerop (TREE_IMAGPART (expr)))
 return 1;
 
+  else if (TREE_CODE (expr) == VECTOR_CST)
+{
+  tree elt;
+  for (elt = TREE_VECTOR_CST_ELTS (expr); elt; elt = TREE_CHAIN (elt))
+   if (!integer_all_onesp (TREE_VALUE (elt)))
+ return 0;
+  return 1;
+}
+
   else if (TREE_CODE (expr) != INTEGER_CST)
 return 0;
 


Re: [PATCH, i386] RTM support

2012-03-05 Thread Kirill Yukhin
Hello Uros,

 As the first remark, you don't have to add BLKmode memory clobbers.
 unspec_volatile RTX is considered to use and clobber all memory:


Thanks, fixed!


 But, I think that we want to use code label from the top of the false
 branch instead of .+6. The question is, how to get it ...

Agreed, this seems not as nice, but still it works :)
I still do not understand, why not to put something like this?
xbegin\t1f\n1:
This is local label, which is not intercept others...


 Please use ix86_expand_setcc instead of opencoding sete insn.


Fixed!

Anything else?

Thanks, K


Re: [PATCH, i386] RTM support

2012-03-05 Thread Kirill Yukhin
Adding patch

On Mon, Mar 5, 2012 at 3:30 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
 Hello Uros,

 As the first remark, you don't have to add BLKmode memory clobbers.
 unspec_volatile RTX is considered to use and clobber all memory:


 Thanks, fixed!


 But, I think that we want to use code label from the top of the false
 branch instead of .+6. The question is, how to get it ...

 Agreed, this seems not as nice, but still it works :)
 I still do not understand, why not to put something like this?
 xbegin\t1f\n1:
 This is local label, which is not intercept others...


 Please use ix86_expand_setcc instead of opencoding sete insn.


 Fixed!

 Anything else?

 Thanks, K


rtm-2.gcc.patch
Description: Binary data


Re: [PATCH, i386] RTM support

2012-03-05 Thread Jakub Jelinek
On Mon, Mar 05, 2012 at 03:30:53PM +0400, Kirill Yukhin wrote:
 Agreed, this seems not as nice, but still it works :)
 I still do not understand, why not to put something like this?
 xbegin\t1f\n1:
 This is local label, which is not intercept others...

Because they should be reserved for inline-asm use, the compiler
can always create its own .Lwhatever125 labels.

Jakub


[PATCH][1/N] Preserve loop structures from tree loop to RTL loop optimizers

2012-03-05 Thread Richard Guenther

This patch fixes PR52353 towards a point we no longer ICE.  We fail
to properly treat -ftrapv operations (or rather their libcall block)
as trapping after RTL expansion because we simply check may_trap_p
on the REG_EQUAL note.  The following patch re-arranges
emit_libcall_block to take an additional argument overriding that
result properly.

The testcase is still miscompiled later by RTL DCE, I'll open a
bug for that once this patch is in.  Thus, no testcase, but it
avoids an existing one from ICEing after preserving loops over RTL
expansion.

The new predicates will help fixing PR52478 as well (trying a fix now).

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

Richard.

2012-03-05  Richard Guenther  rguent...@suse.de

PR middle-end/52353
* optabs.h (trapv_unoptab_p): New function.
(trapv_binoptab_p): Likewise.
* optabs.c (expand_binop): Use emit_libcall_block_1 with
a proper equiv_may_trap argument.
(expand_unop): Likewise.
(emit_libcall_block_1): Take extra argument whether the
instruction may trap.  Renamed from ...
(emit_libcall_block): ... this.  New wrapper.

Index: gcc/optabs.h
===
--- gcc/optabs.h(revision 184918)
+++ gcc/optabs.h(working copy)
@@ -1103,6 +1103,25 @@ set_direct_optab_handler (direct_optab o
   op-handlers[(int) mode].insn_code = (int) code - (int) CODE_FOR_nothing;
 }
 
+/* Return true if UNOPTAB is for a trapping-on-overflow operation.  */
+
+static inline bool
+trapv_unoptab_p (optab unoptab)
+{
+  return (unoptab == negv_optab
+ || unoptab == absv_optab); 
+}
+
+/* Return true if BINOPTAB is for a trapping-on-overflow operation.  */
+
+static inline bool
+trapv_binoptab_p (optab binoptab)
+{
+  return (binoptab == addv_optab
+ || binoptab == subv_optab
+ || binoptab == smulv_optab);
+}
+
 extern rtx optab_libfunc (optab optab, enum machine_mode mode);
 extern rtx convert_optab_libfunc (convert_optab optab, enum machine_mode mode1,
  enum machine_mode mode2);
Index: gcc/optabs.c
===
--- gcc/optabs.c(revision 184918)
+++ gcc/optabs.c(working copy)
@@ -60,6 +60,7 @@ optab code_to_optab[NUM_RTX_CODE + 1];
 static void prepare_float_lib_cmp (rtx, rtx, enum rtx_code, rtx *,
   enum machine_mode *);
 static rtx expand_unop_direct (enum machine_mode, optab, rtx, rtx, int);
+static void emit_libcall_block_1 (rtx, rtx, rtx, rtx, bool);
 
 /* Debug facility for use in GDB.  */
 void debug_optab_libfuncs (void);
@@ -2115,8 +2116,9 @@ expand_binop (enum machine_mode mode, op
   end_sequence ();
 
   target = gen_reg_rtx (mode);
-  emit_libcall_block (insns, target, value,
- gen_rtx_fmt_ee (binoptab-code, mode, op0, op1));
+  emit_libcall_block_1 (insns, target, value,
+   gen_rtx_fmt_ee (binoptab-code, mode, op0, op1),
+   trapv_binoptab_p (binoptab));
 
   return target;
 }
@@ -3197,7 +3199,8 @@ expand_unop (enum machine_mode mode, opt
eq_value = simplify_gen_unary (TRUNCATE, outmode, eq_value, mode);
   else if (GET_MODE_SIZE (outmode)  GET_MODE_SIZE (mode))
eq_value = simplify_gen_unary (ZERO_EXTEND, outmode, eq_value, mode);
-  emit_libcall_block (insns, target, value, eq_value);
+  emit_libcall_block_1 (insns, target, value, eq_value,
+   trapv_unoptab_p (unoptab));
 
   return target;
 }
@@ -3775,8 +3778,9 @@ no_conflict_move_test (rtx dest, const_r
an insn to move RESULT to TARGET.  This last insn will have a REQ_EQUAL
note with an operand of EQUIV.  */
 
-void
-emit_libcall_block (rtx insns, rtx target, rtx result, rtx equiv)
+static void
+emit_libcall_block_1 (rtx insns, rtx target, rtx result, rtx equiv,
+ bool equiv_may_trap)
 {
   rtx final_dest = target;
   rtx next, last, insn;
@@ -3789,7 +3793,8 @@ emit_libcall_block (rtx insns, rtx targe
   /* If we're using non-call exceptions, a libcall corresponding to an
  operation that may trap may also trap.  */
   /* ??? See the comment in front of make_reg_eh_region_note.  */
-  if (cfun-can_throw_non_call_exceptions  may_trap_p (equiv))
+  if (cfun-can_throw_non_call_exceptions
+   (equiv_may_trap || may_trap_p (equiv)))
 {
   for (insn = insns; insn; insn = NEXT_INSN (insn))
if (CALL_P (insn))
@@ -3870,6 +3875,12 @@ emit_libcall_block (rtx insns, rtx targe
   if (final_dest != target)
 emit_move_insn (final_dest, target);
 }
+
+void
+emit_libcall_block (rtx insns, rtx target, rtx result, rtx equiv)
+{
+  emit_libcall_block_1 (insns, target, result, equiv, false);
+}
 
 /* Nonzero if we can perform a comparison of mode MODE straightforwardly.
PURPOSE describes how this comparison will be 

Re: [fortran, patch] Fix handling of backtrace options in the library

2012-03-05 Thread Janne Blomqvist
On Sat, Mar 3, 2012 at 00:35, FX fxcoud...@gmail.com wrote:
 Hi all,

 I'll offer my first patch to the new 4.8 trunk. I noticed that the 
 -fbacktrace option and the GFORTRAN_ERROR_BACKTRACE environment variable are 
 somewhat inconsistently handled. Currently, the environment variabled doesn't 
 actually override the compilation option, as it should. So, I set to change 
 that (checking both options.backtrace and compile_options.backtrace instead 
 of only the latter) when I realized that we could improve this further by 
 moving the checking code: it is currently located in the set_options() 
 function, which is called from the main Fortran routine (call generated by 
 the front-end). This means that it's not triggered if the main program is C.

Good catch!

 Full disclosure: I removed the function maybe_find_addr2line() because it's 
 not needed anymore now the code was regrouped. However, I'll note that I 
 don't understand why it was useful before, and that I think the comment on 
 top of it was wrong (variable options could be seen in the function, it was 
 just shadowed by the local function argument!). Thus, while I was at it, I 
 renamed the options argument to set_options(), just to make sure we didn't 
 have a problem of this sort in the future.

I added it because, as you say, the argument options in
set_options() prevented access to the global variable options, and I
was lazy and considered a new function faster than renaming the
argument. :)

 The change was bootstrapped and regtested on x86_64-apple-darwin11, but is an 
 area not covered by the testsuite. I have manually checked that running 
 various types of abort, both in a pure Fortran code and a mixed C/Fortran 
 (with C main), with all combinations -fno-backtrace/GFORTRAN_ERROR_BACKTRACE, 
 behaved as expected.

I don't think it will work if you have a C main program which then
calls _gfortran_set_options() to enable backtracing per the
mixed-language programming chapter in the manual. You probably need to
move the setup code to a separate function which is called both from
init and set_options.

Also, in the patch as it stands now, you could make find_addr2line
static and remove the prototype from libgfortran.h.  That being said,
I'd recommend moving both find_addr2line and the signal handler setup
code to backtrace.c, and then do a bit of janitorial work checking
which functions and variables can be made static.

-- 
Janne Blomqvist


Re: [PATCH, i386] RTM support

2012-03-05 Thread Kirill Yukhin
On Mon, Mar 5, 2012 at 3:34 PM, Jakub Jelinek ja...@redhat.com wrote:
 On Mon, Mar 05, 2012 at 03:30:53PM +0400, Kirill Yukhin wrote:
 Agreed, this seems not as nice, but still it works :)
 I still do not understand, why not to put something like this?
 xbegin\t1f\n1:
 This is local label, which is not intercept others...

 Because they should be reserved for inline-asm use, the compiler
 can always create its own .Lwhatever125 labels.

As far as I understand .L* labels are not local, and created in this
way, it may intercept other compiler genererated ones.
The beauty of local labels is that they're almost invisible

K


Re: [PATCH, i386] RTM support

2012-03-05 Thread Uros Bizjak
On Mon, Mar 5, 2012 at 1:02 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:

 Agreed, this seems not as nice, but still it works :)
 I still do not understand, why not to put something like this?
 xbegin\t1f\n1:
 This is local label, which is not intercept others...

 Because they should be reserved for inline-asm use, the compiler
 can always create its own .Lwhatever125 labels.

 As far as I understand .L* labels are not local, and created in this
 way, it may intercept other compiler genererated ones.
 The beauty of local labels is that they're almost invisible

I'd suggest you generate local label in the expander and pass it to
insn RTX. This way, we can also reuse insn pattern later with eventual
different code label.

Uros.


Re: [PATCH] Fix PR49484, gthr requirements update (target maintainers have a looksee)

2012-03-05 Thread Richard Guenther
On Wed, Jan 18, 2012 at 3:21 PM, Richard Guenther rguent...@suse.de wrote:

 This fixes PR49484 by protecting __gcov_flush against concurrent
 execution.  To be able to use the gthread facility I have to
 introduce the requirement that __GTHREAD_MUTEX_INIT_FUNCTION
 is always available, even if __GTHREAD_MUTEX_INIT is available as
 otherwise no dynamic initialization of a mutex is possible.
 I have adjusted gthr-posix.h and gthr-single.h only - target
 maintainers, please update your ports accordingly in advance.

 Boostrap and regtest on x86_64-unknown-linux-gnu is ongoing,
 but this looks like something for stage1 anyway.

Bootstrap and regtest finished ok.  I am going to commit this without fixing
eventually broken targets that I know nothing of.  See above.

Unless I hear objections until tomorrow.

Thanks,
Richard.

 Richard.

 2012-01-18  Richard Guenther  rguent...@suse.de

        * gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification.
        * gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
        (__gthread_mutex_init_function): New function.
        * gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.

        PR gcov/49484
        * libgcov.c: Include gthr.h.
        (__gcov_flush_mx): New global variable.
        (init_mx, init_mx_once): New functions.
        (__gcov_flush): Protect self with a mutex.
        (__gcov_fork): Re-initialize mutex after forking.
        * unwind-dw2-fde.c: Change condition under which to use
        __GTHREAD_MUTEX_INIT_FUNCTION.

 Index: libgcc/libgcov.c
 ===
 *** libgcc/libgcov.c    (revision 183270)
 --- libgcc/libgcov.c    (working copy)
 *** see the files COPYING3 and COPYING.RUNTI
 *** 30,35 
 --- 30,36 
  #include coretypes.h
  #include tm.h
  #include libgcc_tm.h
 + #include gthr.h

  #if defined(inhibit_libc)
  #define IN_LIBGCOV (-1)
 *** __gcov_init (struct gcov_info *info)
 *** 705,710 
 --- 706,730 
    info-version = 0;
  }

 + #ifdef __GTHREAD_MUTEX_INIT
 + ATTRIBUTE_HIDDEN __gthread_mutex_t __gcov_flush_mx = __GTHREAD_MUTEX_INIT;
 + #define init_mx_once()
 + #else
 + __gthread_mutex_t __gcov_flush_mx ATTRIBUTE_HIDDEN;
 +
 + static void
 + init_mx (void)
 + {
 +   __GTHREAD_MUTEX_INIT_FUNCTION (mx);
 + }
 + static void
 + init_mx_once (void)
 + {
 +   static __gthread_once_t once = __GTHREAD_ONCE_INIT;
 +   __gthread_once (once, init_mx);
 + }
 + #endif
 +
  /* Called before fork or exec - write out profile information gathered so
     far and reset it to zero.  This avoids duplication or loss of the
     profile information gathered so far.  */
 *** __gcov_flush (void)
 *** 714,719 
 --- 734,742 
  {
    const struct gcov_info *gi_ptr;

 +   init_mx_once ();
 +   __gthread_mutex_lock (__gcov_flush_mx);
 +
    gcov_exit ();
    for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
      {
 *** __gcov_flush (void)
 *** 737,742 
 --- 760,767 
            }
        }
      }
 +
 +   __gthread_mutex_unlock (__gcov_flush_mx);
  }

  #endif /* L_gcov */
 *** __gcov_ior_profiler (gcov_type *counters
 *** 975,982 
  pid_t
  __gcov_fork (void)
  {
    __gcov_flush ();
 !   return fork ();
  }
  #endif

 --- 1000,1012 
  pid_t
  __gcov_fork (void)
  {
 +   pid_t pid;
 +   extern __gthread_mutex_t __gcov_flush_mx;
    __gcov_flush ();
 !   pid = fork ();
 !   if (pid == 0)
 !     __GTHREAD_MUTEX_INIT_FUNCTION (__gcov_flush_mx);
 !   return pid;
  }
  #endif

 Index: libgcc/unwind-dw2-fde.c
 ===
 *** libgcc/unwind-dw2-fde.c     (revision 183270)
 --- libgcc/unwind-dw2-fde.c     (working copy)
 *** static struct object *seen_objects;
 *** 47,57 

  #ifdef __GTHREAD_MUTEX_INIT
  static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
  #else
  static __gthread_mutex_t object_mutex;
 - #endif

 - #ifdef __GTHREAD_MUTEX_INIT_FUNCTION
  static void
  init_object_mutex (void)
  {
 --- 47,56 

  #ifdef __GTHREAD_MUTEX_INIT
  static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
 + #define init_object_mutex_once()
  #else
  static __gthread_mutex_t object_mutex;

  static void
  init_object_mutex (void)
  {
 *** init_object_mutex_once (void)
 *** 64,71 
    static __gthread_once_t once = __GTHREAD_ONCE_INIT;
    __gthread_once (once, init_object_mutex);
  }
 - #else
 - #define init_object_mutex_once()
  #endif

  /* Called from crtbegin.o to register the unwind info for an object.  */
 --- 63,68 
 Index: libgcc/gthr-posix.h
 ===
 *** libgcc/gthr-posix.h (revision 183270)
 --- libgcc/gthr-posix.h (working copy)
 *** typedef struct timespec __gthread_time_t
 *** 63,68 
 --- 63,69 
  #define __GTHREAD_HAS_COND    1

  #define __GTHREAD_MUTEX_INIT PTHREAD_MUTEX_INITIALIZER
 + #define 

Re: Patch ping

2012-03-05 Thread Richard Guenther
On Mon, 5 Mar 2012, Jakub Jelinek wrote:

 Hi!
 
 I'd like to ping two patches deferred to 4.8.  I've bootstrapped/regtested
 them on x86_64-linux and i686-linux:
 
 - PR51721 VRP register_edge_assert_for_2 improvements
   http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00046.html

Ok.

Thanks,
Richard.


[PATCH][2/N] Preserve loop structures from tree loop to RTL loop optimizers

2012-03-05 Thread Richard Guenther

The following patch adds checking to calculate_dominance_info that
if we re-use existing dominance info it is correct (unsurprisingly
this wasn't always the case, noticed when using verify_loop_structure
in random places ...).

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

Do people think the extra checking is worth its time?  We might
want to drop other explicit calls to verify_dominators (we currently
do not assert we drop post-dom info and nowhere verify post-dom
info for example).

I've been unconditionally checking loop structure and dominator info
if they are available after each pass, from the pass manager
(I think the TODO_verify_* bits are odd, I mean, that passes can
opt-out from being verified ... OTOH between IRA and reload we
have loop info but it breaks (sometimes at least))

Thanks,
Richard.

2012-03-05  Richard Guenther  rguent...@suse.de

* cfgexpand.c (gimple_expand_cfg): Free dominator info.
* cfgloop.c (verify_loop_structure): Compute dominator info.
* dominance.c (calculate_dominance_info): If we re-use existing
computed dominance info, verify if it is correct.
* tree-if-conv.c (combine_blocks): Free post-dominator info
after breaking it.
* tree-parloops.c (create_parallel_loop): Free and re-compute
dominator info after breaking it.

Index: gcc/cfgexpand.c
===
*** gcc/cfgexpand.c.orig2012-02-23 13:24:54.0 +0100
--- gcc/cfgexpand.c 2012-02-23 14:16:43.0 +0100
*** gimple_expand_cfg (void)
*** 4362,4367 
--- 4369,4376 
  
/* Some backends want to know that we are expanding to RTL.  */
currently_expanding_to_rtl = 1;
+   /* Dominators are not kept up-to-date as we may create new basic-blocks.  */
+   free_dominance_info (CDI_DOMINATORS);
  
rtl_profile_for_bb (ENTRY_BLOCK_PTR);
  
Index: gcc/cfgloop.c
===
*** gcc/cfgloop.c.orig  2012-02-23 13:24:54.0 +0100
--- gcc/cfgloop.c   2012-02-23 14:06:15.0 +0100
*** verify_loop_structure (void)
*** 1317,1322 
--- 1317,1326 
unsigned num = number_of_loops ();
loop_iterator li;
struct loop_exit *exit, *mexit;
+   bool dom_available = dom_info_available_p (CDI_DOMINATORS);
+ 
+   /* Ensure that the dominators are computed.  */
+   calculate_dominance_info (CDI_DOMINATORS);
  
/* Check sizes.  */
sizes = XCNEWVEC (unsigned, num);
*** verify_loop_structure (void)
*** 1560,1565 
--- 1572,1579 
gcc_assert (!err);
  
free (sizes);
+   if (!dom_available)
+ free_dominance_info (CDI_DOMINATORS);
  }
  
  /* Returns latch edge of LOOP.  */
Index: gcc/dominance.c
===
*** gcc/dominance.c.orig2012-02-23 13:24:54.0 +0100
--- gcc/dominance.c 2012-02-23 14:06:15.0 +0100
*** calculate_dominance_info (enum cdi_direc
*** 639,645 
bool reverse = (dir == CDI_POST_DOMINATORS) ? true : false;
  
if (dom_computed[dir_index] == DOM_OK)
! return;
  
timevar_push (TV_DOMINANCE);
if (!dom_info_available_p (dir))
--- 639,650 
bool reverse = (dir == CDI_POST_DOMINATORS) ? true : false;
  
if (dom_computed[dir_index] == DOM_OK)
! {
! #ifdef ENABLE_CHECKING
!   verify_dominators (dir);
! #endif
!   return;
! }
  
timevar_push (TV_DOMINANCE);
if (!dom_info_available_p (dir))
*** calculate_dominance_info (enum cdi_direc
*** 667,672 
--- 672,681 
free_dom_info (di);
dom_computed[dir_index] = DOM_NO_FAST_QUERY;
  }
+ #ifdef ENABLE_CHECKING
+   else
+ verify_dominators (dir);
+ #endif
  
compute_dom_fast_query (dir);
  
Index: gcc/tree-if-conv.c
===
*** gcc/tree-if-conv.c.orig 2012-02-23 13:24:54.0 +0100
--- gcc/tree-if-conv.c  2012-02-23 14:06:15.0 +0100
*** combine_blocks (struct loop *loop)
*** 1712,1717 
--- 1712,1720 
  
free (ifc_bbs);
ifc_bbs = NULL;
+ 
+   /* Post-dominators are corrupt now.  */
+   free_dominance_info (CDI_POST_DOMINATORS);
  }
  
  /* If-convert LOOP when it is legal.  For the moment this pass has no
Index: gcc/tree-parloops.c
===
*** gcc/tree-parloops.c.orig2012-02-23 13:24:54.0 +0100
--- gcc/tree-parloops.c 2012-02-23 14:06:15.0 +0100
*** create_parallel_loop (struct loop *loop,
*** 1740,1745 
--- 1740,1749 
gimple_set_location (stmt, loc);
gsi_insert_after (gsi, stmt, GSI_NEW_STMT);
  
+   /* After the above dom info is hosed.  Re-compute it.  */
+   free_dominance_info (CDI_DOMINATORS);
+   calculate_dominance_info (CDI_DOMINATORS);
+ 
return paral_bb;
  }
  



[PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

2012-03-05 Thread Richard Guenther

This fixes PRs 52080 (unexpected access to adjacent fields for bitfield
access), 52097 (ICE with the C++ memory model enabled) and 48124
(wrong code accessing adjacent objects).  It's an unchanged re-post
of the RFCs I sent out during stage4 (it now re-uses the pointer
for DECL_QUALIFIER instead of enlarging each FIELD_DECL).

The core of the patch is computation of an underlying FIELD_DECL that
should be used for the access of bitfield FIELD_DECLs (or at least
constrain such access).  This computation is done when laying out
a RECORD_TYPE, for simplicity after it has been layed out.  This
FIELD_DECL is currently only used to constrain bitfield accesses,
so it employs a 1:1 mapping.  I plan to change this to a 1:n
(1 bitfield group, multiple possibly overlapping representatives)
when resuming work on lowering bitfield accesses on the gimple level
(to address PR48696).

This patch also completely replaces get_bit_range (which is where
PR52097 ICEs) by a trivial implementation.

There is PR52134 which will make this patch cause 1 gnat regression.

Bootstrapped and tested on 
{x86_64,i586,s390,s390x,ia64,ppc,ppc64}-suse-linux-gnu.

If there are no serious objections (or reasonable requests) I plan
to go forward with this version early next week.

If you have a weird target it might be good to double-check codegen
quality for bitfield stores (which is what you should have done
with the C++ memory model enabled already).

Thanks,
Richard.

2012-03-05  Richard Guenther  rguent...@suse.de

* tree.h (DECL_BIT_FIELD_REPRESENTATIVE): New define.
* stor-layout.c (start_bitfield_representative): New function.
(finish_bitfield_representative): Likewise.
(finish_bitfield_layout): Likewise.
(finish_record_layout): Call finish_bitfield_layout.
* tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers):
Stream DECL_BIT_FIELD_REPRESENTATIVE.
* tree-streamer-out.c (write_ts_field_decl_tree_pointers): Likewise.

PR middle-end/52080
PR middle-end/52097
PR middle-end/48124
* expr.c (get_bit_range): Unconditionally extract bitrange
from DECL_BIT_FIELD_REPRESENTATIVE.
(expand_assignment): Adjust call to get_bit_range.

* gimplify.c (gimplify_expr): Translate bitfield accesses
to BIT_FIELD_REFs of the representative.

* tree-sra.c (create_access_replacement): Only rename the
replacement if we can rewrite it into SSA form.  Properly
mark register typed replacements that we cannot rewrite
with TREE_ADDRESSABLE.

* gcc.dg/torture/pr48124-1.c: New testcase.
* gcc.dg/torture/pr48124-2.c: Likewise.
* gcc.dg/torture/pr48124-3.c: Likewise.
* gcc.dg/torture/pr48124-4.c: Likewise.

Index: gcc/stor-layout.c
===
*** gcc/stor-layout.c.orig  2012-02-21 12:59:35.0 +0100
--- gcc/stor-layout.c   2012-02-24 12:53:11.0 +0100
*** finalize_type_size (tree type)
*** 1722,1727 
--- 1722,1908 
  }
  }
  
+ /* Return a new underlying object for a bitfield started with FIELD.  */
+ 
+ static tree
+ start_bitfield_representative (tree field)
+ {
+   tree repr = make_node (FIELD_DECL);
+   DECL_FIELD_OFFSET (repr) = DECL_FIELD_OFFSET (field);
+   /* Force the representative to begin at an BITS_PER_UNIT aligned
+  boundary - C++ may use tail-padding of a base object to
+  continue packing bits so the bitfield region does not start
+  at bit zero (see g++.dg/abi/bitfield5.C for example).
+  Unallocated bits may happen for other reasons as well,
+  for example Ada which allows explicit bit-granular structure layout.  */
+   DECL_FIELD_BIT_OFFSET (repr)
+ = size_binop (BIT_AND_EXPR,
+ DECL_FIELD_BIT_OFFSET (field),
+ bitsize_int (~(BITS_PER_UNIT - 1)));
+   SET_DECL_OFFSET_ALIGN (repr, DECL_OFFSET_ALIGN (field));
+   DECL_SIZE (repr) = DECL_SIZE (field);
+   DECL_PACKED (repr) = DECL_PACKED (field);
+   DECL_CONTEXT (repr) = DECL_CONTEXT (field);
+   return repr;
+ }
+ 
+ /* Finish up a bitfield group that was started by creating the underlying
+object REPR with the last fied in the bitfield group FIELD.  */
+ 
+ static void
+ finish_bitfield_representative (tree repr, tree field)
+ {
+   unsigned HOST_WIDE_INT bitsize, maxbitsize, modesize;
+   enum machine_mode mode = BLKmode;
+   tree nextf, size;
+ 
+   size = size_diffop (DECL_FIELD_OFFSET (field),
+ DECL_FIELD_OFFSET (repr));
+   gcc_assert (host_integerp (size, 1));
+   bitsize = (tree_low_cst (size, 1) * BITS_PER_UNIT
++ tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1)
+- tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1)
++ tree_low_cst (DECL_SIZE (field), 1));
+ 
+   /* Now nothing tells us how to pad out bitsize ...  */
+   nextf = DECL_CHAIN (field);
+   while (nextf  TREE_CODE (nextf) != 

[patch] libitm: Don't execute memtransfer/memset if size isn't larger than zero.

2012-03-05 Thread Torvald Riegel
This patch skips execution of memtransfer/memset if there actually isn't
anything to do.  Calls to memcpy/memmove/memset with size==0 should be
rare I'd suppose but prior code would still treat this no-op like some
store (ml_wt was particularly bad: it would to acquire _all_ locks in
such a case due to calculating a correct exclusive upper bound anymore).

OK for trunk?
4.7 too?
commit e0cd0b0a1cac087020d63e63e2d8ff67eab915d1
Author: Torvald Riegel trie...@redhat.com
Date:   Mon Mar 5 14:27:01 2012 +0100

libitm: Don't execute memtransfer/memset if size isn't larger than zero.

libitm/
* dispatch.h (CREATE_DISPATCH_METHODS_MEM): Don't execute
memtransfer/memset if size isn't larger than zero.

diff --git a/libitm/dispatch.h b/libitm/dispatch.h
index d059c49..6a9e62e 100644
--- a/libitm/dispatch.h
+++ b/libitm/dispatch.h
@@ -102,11 +102,13 @@
 virtual void memtransfer(void *dst, const void* src, size_t size,\
 bool may_overlap, ls_modifier dst_mod, ls_modifier src_mod)   \
 { \
-  memtransfer_static(dst, src, size, may_overlap, dst_mod, src_mod); \
+  if (size  0)   \
+memtransfer_static(dst, src, size, may_overlap, dst_mod, src_mod); \
 } \
 virtual void memset(void *dst, int c, size_t size, ls_modifier mod)  \
 { \
-  memset_static(dst, c, size, mod);  \
+  if (size  0)   \
+memset_static(dst, c, size, mod); \
 }
 
 #define CREATE_DISPATCH_METHODS_MEM_PV()  \


Re: [patch] libitm: Don't execute memtransfer/memset if size isn't larger than zero.

2012-03-05 Thread Richard Guenther
On Mon, Mar 5, 2012 at 2:34 PM, Torvald Riegel trie...@redhat.com wrote:
 This patch skips execution of memtransfer/memset if there actually isn't
 anything to do.  Calls to memcpy/memmove/memset with size==0 should be
 rare I'd suppose but prior code would still treat this no-op like some
 store (ml_wt was particularly bad: it would to acquire _all_ locks in
 such a case due to calculating a correct exclusive upper bound anymore).

 OK for trunk?
 4.7 too?

Not before 4.7.0 please.

Richard.


[PATCH] Cleanup dominator verifying when verifying loops

2012-03-05 Thread Richard Guenther

Currently verify_loop_structure assumes dominators are up-to-date.
Most of the callers of verify_loop_structure verify dominators before
calling it, some do it afterwards, some don't do it at all.  This
cleans things up by moving the verification into verify_loop_structure.
It also notices some unconditional verifier calls and wraps them
in ENABLE_CHECKING properly.

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

Richard.

2012-03-05  Richard Guenther  rguent...@suse.de

* cfgloop.c (verify_loop_structure): Verify dominators before
using them.
* graphite-clast-to-gimple.c (graphite_verify): Do not verify
dominators from here.
* graphite-scop-detection.c (create_sese_edges): Likewise.
* loop-doloop.c (doloop_optimize_loops): Likewise.
* loop-init.c (loop_optimizer_init): Likewise.
* loop-unroll.c (unroll_and_peel_loops): Likewise.
* loop-unswitch.c (unswitch_loops): Likewise.
* tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Likewise.
* tree-parloops.c (parallelize_loops): Likewise.  Verify
only when checking is enabled.
* tree-loop-distribution.c (tree_loop_distribution): Likewise.

Index: graphite-clast-to-gimple.c
===
--- graphite-clast-to-gimple.c  (revision 184932)
+++ graphite-clast-to-gimple.c  (working copy)
@@ -55,7 +55,6 @@ graphite_verify (void)
 {
 #ifdef ENABLE_CHECKING
   verify_loop_structure ();
-  verify_dominators (CDI_DOMINATORS);
   verify_loop_closed_ssa (true);
 #endif
 }
Index: graphite-scop-detection.c
===
--- graphite-scop-detection.c   (revision 184932)
+++ graphite-scop-detection.c   (working copy)
@@ -1026,7 +1026,6 @@ create_sese_edges (VEC (sd_region, heap)
 
 #ifdef ENABLE_CHECKING
   verify_loop_structure ();
-  verify_dominators (CDI_DOMINATORS);
   verify_ssa (false);
 #endif
 }
Index: loop-doloop.c
===
--- loop-doloop.c   (revision 184932)
+++ loop-doloop.c   (working copy)
@@ -747,7 +747,6 @@ doloop_optimize_loops (void)
   iv_analysis_done ();
 
 #ifdef ENABLE_CHECKING
-  verify_dominators (CDI_DOMINATORS);
   verify_loop_structure ();
 #endif
 }
Index: loop-init.c
===
--- loop-init.c (revision 184932)
+++ loop-init.c (working copy)
@@ -91,7 +91,6 @@ loop_optimizer_init (unsigned flags)
   flow_loops_dump (dump_file, NULL, 1);
 
 #ifdef ENABLE_CHECKING
-  verify_dominators (CDI_DOMINATORS);
   verify_loop_structure ();
 #endif
 }
Index: loop-unroll.c
===
--- loop-unroll.c   (revision 184932)
+++ loop-unroll.c   (working copy)
@@ -198,7 +198,6 @@ unroll_and_peel_loops (int flags)
   if (check)
{
 #ifdef ENABLE_CHECKING
- verify_dominators (CDI_DOMINATORS);
  verify_loop_structure ();
 #endif
}
@@ -255,7 +254,6 @@ peel_loops_completely (int flags)
{
  peel_loop_completely (loop);
 #ifdef ENABLE_CHECKING
- verify_dominators (CDI_DOMINATORS);
  verify_loop_structure ();
 #endif
}
Index: loop-unswitch.c
===
--- loop-unswitch.c (revision 184932)
+++ loop-unswitch.c (working copy)
@@ -149,7 +149,6 @@ unswitch_loops (void)
 {
   unswitch_single_loop (loop, NULL_RTX, 0);
 #ifdef ENABLE_CHECKING
-  verify_dominators (CDI_DOMINATORS);
   verify_loop_structure ();
 #endif
 }
Index: tree-loop-distribution.c
===
--- tree-loop-distribution.c(revision 184932)
+++ tree-loop-distribution.c(working copy)
@@ -1293,7 +1293,9 @@ tree_loop_distribution (void)
fprintf (dump_file, Loop %d is the same.\n, num);
}
 
+#ifdef ENABLE_CHECKING
   verify_loop_structure ();
+#endif
 
   VEC_free (gimple, heap, work_list);
 }
Index: tree-parloops.c
===
--- tree-parloops.c (revision 184932)
+++ tree-parloops.c (working copy)
@@ -,10 +,11 @@ parallelize_loops (void)
   }
   gen_parallel_loop (loop, reduction_list,
 n_threads, niter_desc);
+#ifdef ENABLE_CHECKING
   verify_flow_info ();
-  verify_dominators (CDI_DOMINATORS);
   verify_loop_structure ();
   verify_loop_closed_ssa (true);
+#endif
 }
 
   free_stmt_vec_info_vec ();
Index: tree-ssa-loop-manip.c
===
--- tree-ssa-loop-manip.c   (revision 184932)
+++ tree-ssa-loop-manip.c   (working copy)
@@ -1096,7 +1096,6 @@ tree_transform_and_unroll_loop (struct l
 
 #ifdef ENABLE_CHECKING
   verify_flow_info ();
-  verify_dominators 

Re: [Patch,AVR] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Georg-Johann Lay
Georg-Johann Lay wrote:
 This patch fixes several issues with RAMP registers:
 
 * On Devices with more than 64 KiB RAM, RAMPZ is used as high-byte of
   RAM address. If RAMPZ is used to read flash, it must be reset to 0
   after the read so that RAM-read will operate correctly in the remainder.
   There is no support for RAM  64 Ki so RAMPZ = 0 is in order.
 
 * The ISR epilogue restored RAMP* registers in the wrong order.
 
 * As RAMPZ is used both in ELPM and LD/LDD on some xmega core, the right
   condition to set RAMPZ prior to ELPM is have ELPM, not have RAMPZ.
 
 * Never read unintentionally from RAM because a flash address interpreted
   as a RAM address might point to the I/O area.
 
 Ok for trunk and 4.7?

The following change in expand_prologue is wrong:

-  if (AVR_HAVE_RAMPZ
+  if (AVR_HAVE_RAMPD /* sic! */

similar in expand_epilogue.

Ok without that change?

 
 Johann
 
 libgcc/
   PR target/52461
   * config/avr/lib1funcs.S (__do_copy_data): Clear RAMPZ after usage
   if RAMPZ affects reading from RAM.
   (__tablejump_elpm__): Ditto.
   (.xload): Ditto.
   (__movmemx_hi): Ditto.
   (__do_global_ctors): Right condition for RAMPZ usage is have ELPM.
   (__do_global_dtors): Ditto.
   (__xload_1, __xload_2, __xload_3, __xload_4): Ditto.  And make weak.
   (__movmemx_hi): Ditto.  And fix RAM-loop label.
   (__xload_1): Never read unintentionally from RAM.
 
 gcc/
   PR target/52461
   * gcc/config/avr/avr.c (expand_prologue): Depend save/restore of
   RAMPZ on HAVE_RAMPD, not HAVE_RAMPZ.
   (expand_epilogue): Ditto.  And fix order of restoration to:
   RAMPZ, RAMPY, RAMPX, RAMPD.
   (avr_xload_libgcc_p): Always load __memx by lilbgcc call on
   big-RAM devices.
   (avr_out_lpm): Clear RAMPZ after usage if RAMPZ affects reading
   from RAM.
   (avr_out_xload): Never read unintentionally from RAM.
   * config/avr/avr.md (xload_8): Adjust insn length.


Re: [Patch,AVR] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Richard Guenther
On Mon, Mar 5, 2012 at 3:11 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Georg-Johann Lay wrote:
 This patch fixes several issues with RAMP registers:

 * On Devices with more than 64 KiB RAM, RAMPZ is used as high-byte of
   RAM address. If RAMPZ is used to read flash, it must be reset to 0
   after the read so that RAM-read will operate correctly in the remainder.
   There is no support for RAM  64 Ki so RAMPZ = 0 is in order.

 * The ISR epilogue restored RAMP* registers in the wrong order.

 * As RAMPZ is used both in ELPM and LD/LDD on some xmega core, the right
   condition to set RAMPZ prior to ELPM is have ELPM, not have RAMPZ.

 * Never read unintentionally from RAM because a flash address interpreted
   as a RAM address might point to the I/O area.

 Ok for trunk and 4.7?

All commits to the 4.7 branch need explicit release manager approval.  AVR
isn't primary/secondary so please do not change anything before is
released 4.7.0 for it.

Thanks,
Richard.

 The following change in expand_prologue is wrong:

 -      if (AVR_HAVE_RAMPZ
 +      if (AVR_HAVE_RAMPD /* sic! */

 similar in expand_epilogue.

 Ok without that change?


 Johann

 libgcc/
       PR target/52461
       * config/avr/lib1funcs.S (__do_copy_data): Clear RAMPZ after usage
       if RAMPZ affects reading from RAM.
       (__tablejump_elpm__): Ditto.
       (.xload): Ditto.
       (__movmemx_hi): Ditto.
       (__do_global_ctors): Right condition for RAMPZ usage is have ELPM.
       (__do_global_dtors): Ditto.
       (__xload_1, __xload_2, __xload_3, __xload_4): Ditto.  And make weak.
       (__movmemx_hi): Ditto.  And fix RAM-loop label.
       (__xload_1): Never read unintentionally from RAM.

 gcc/
       PR target/52461
       * gcc/config/avr/avr.c (expand_prologue): Depend save/restore of
       RAMPZ on HAVE_RAMPD, not HAVE_RAMPZ.
       (expand_epilogue): Ditto.  And fix order of restoration to:
       RAMPZ, RAMPY, RAMPX, RAMPD.
       (avr_xload_libgcc_p): Always load __memx by lilbgcc call on
       big-RAM devices.
       (avr_out_lpm): Clear RAMPZ after usage if RAMPZ affects reading
       from RAM.
       (avr_out_xload): Never read unintentionally from RAM.
       * config/avr/avr.md (xload_8): Adjust insn length.


Remove obsolete OpenBSD/MIPS support

2012-03-05 Thread Rainer Orth
I'm currently working on removing the obsolete Tru64 UNIX and IRIX
ports.  When IRIX is gone, the obsoleted OpenBSD/MIPS is the only
remaining port that uses MIPS_DEBUGGING_INFO (which I plan to remove as
a followup once IRIX is gone).

The following patch has been included in a i386-pc-solaris2.10 bootstrap
to make sure that no obvious syntactic errors have crept in.

Ok for mainline?

Rainer


2012-02-24  Rainer Orth  r...@cebitec.uni-bielefeld.de

libgcc:
* config.host (mips*-*-openbsd*): Remove.

gcc:
* config.gcc (mips*-*-openbsd*): Remove.
* config/mips/openbsd.h: Remove.
* config/mips/sdb.h: Remove.

contrib:
* config-list.mk (LIST): Remove mips-openbsd.

# HG changeset patch
# Parent a45494fba4427f160e6f6b624c53e28274d2744c
Remove obsolete OpenBSD/MIPS support

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -40,7 +40,7 @@ LIST = alpha-linux-gnu alpha-freebsd6 al
   mips-sgi-irix6.5OPT-with-stabsOPT-enable-threads=posixOPT-enable-obsolete \
   mips-netbsd \
   mips64el-st-linux-gnu mips64octeon-linux mipsisa64r2-linux \
-  mipsisa32r2-linux-gnu mips-openbsd mipsisa64r2-sde-elf mipsisa32-elfoabi \
+  mipsisa32r2-linux-gnu mipsisa64r2-sde-elf mipsisa32-elfoabi \
   mipsisa64-elfoabi mipsisa64r2el-elf mipsisa64sr71k-elf mipsisa64sb1-elf \
   mipsel-elf mips64-elf mips64vr-elf mips64orion-elf mips-rtems \
   mips-wrs-vxworks mipstx39-elf mmix-knuth-mmixware mn10300-elf moxie-elf \
diff --git a/gcc/config.gcc b/gcc/config.gcc
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -244,7 +244,6 @@ md_file=
 case ${target} in
alpha*-dec-osf5.1*			\
  | mips-sgi-irix6.5			\
- | mips*-*-openbsd*			\
  | score-*\
  | *-*-solaris2.8*			\
  )
@@ -1765,17 +1764,6 @@ mips*-*-linux*)# Linux MIPS, either 
 esac
 	test x$with_llsc != x || with_llsc=yes
 	;;
-mips*-*-openbsd*)
-	tm_defines=${tm_defines} OBSD_HAS_DECLARE_FUNCTION_NAME OBSD_HAS_DECLARE_OBJECT OBSD_HAS_CORRECT_SPECS
-	target_cpu_default=MASK_ABICALLS
-	tm_file=mips/mips.h openbsd.h openbsd-stdint.h openbsd-libpthread.h mips/openbsd.h mips/sdb.h
-	extra_options=${extra_options} openbsd.opt
-	case ${target} in
-	mips*el-*-openbsd*)
-	tm_defines=${tm_defines} TARGET_ENDIAN_DEFAULT=0;;
-	*)  tm_defines=${tm_defines} TARGET_ENDIAN_DEFAULT=MASK_BIG_ENDIAN;;
-esac
-	;;
 mips*-sde-elf*)
 	tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/sde.h
 	tmake_file=mips/t-sde
diff --git a/gcc/config/mips/openbsd.h b/gcc/config/mips/openbsd.h
deleted file mode 100644
--- a/gcc/config/mips/openbsd.h
+++ /dev/null
@@ -1,101 +0,0 @@
-/* Configuration for  a MIPS ABI32 OpenBSD target.
-   Copyright (C) 1999, 2003, 2004, 2007, 2008, 2009, 2010, 2011
-   Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC 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, or (at your option)
-any later version.
-
-GCC 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
-http://www.gnu.org/licenses/.  */
-
-/* Definitions needed for OpenBSD, to avoid picking mips 'defaults'.  */
-
-/* GAS must know this.  */
-#undef SUBTARGET_ASM_SPEC
-#define SUBTARGET_ASM_SPEC %{fPIC|fPIE:-KPIC}
-
-/* CPP specific OpenBSD specs.  */
-#undef SUBTARGET_CPP_SPEC
-#define SUBTARGET_CPP_SPEC OBSD_CPP_SPEC
-
-/* Needed for ELF (inspired by netbsd-elf).  */
-#undef LOCAL_LABEL_PREFIX
-#define LOCAL_LABEL_PREFIX	.
-
-/* The profiling lib spec here is not really correct but we leave
-   it as it is until we have some kind of profiling working.  */
-#define LIB_SPEC OBSD_LIB_SPEC
-
-/* mips assembler uses .set for arcane purposes.  __attribute__((alias))
-   and friends won't work until we get recent binutils with .weakext
-	support.  */
-#undef SET_ASM_OP
-
-#define TARGET_OS_CPP_BUILTINS()			\
-do {		\
-	builtin_define (__unix__);			\
-	builtin_define (__SYSTYPE_BSD__);		\
-	builtin_define (__NO_LEADING_UNDERSCORES__);	\
-	builtin_define (__GP_SUPPORT__);		\
-	builtin_define (__OpenBSD__);			\
-	builtin_assert (system=unix);			\
-	builtin_assert (system=OpenBSD);		\
-} while (0)
-
-/* Layout of source language data types.  */
-
-/* This must agree with machine/ansi.h.  */
-#undef SIZE_TYPE
-#define SIZE_TYPE long unsigned int
-
-#undef PTRDIFF_TYPE
-#define PTRDIFF_TYPE long int
-
-#undef WCHAR_TYPE
-#define WCHAR_TYPE int
-
-#undef WCHAR_TYPE_SIZE
-#define WCHAR_TYPE_SIZE 32
-
-#undef WINT_TYPE
-#define WINT_TYPE int
-
-/* Controlling the compilation driver.  */
-
-/* LINK_SPEC appropriate for OpenBSD:  

[Patch,AVR]: Document -mmcu=avrxmega...

2012-03-05 Thread Georg-Johann Lay
This patch adds the documentation for -mmcu= for xmega cores that is still 
missing.

Moreover, there is some explanation of RAMP SFR usage.

Ok for the trunk and 4.7?

Johann

* doc/invoke.texi (AVR Options): -mmcu=: Document the XMEGA cores.
Explain RAMPD, RAMPX, RAMPDY, RAMPZ usage by avr-gcc.
Some more notes on EIND usage and reorder EIND subsection.

Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 184926)
+++ doc/invoke.texi	(working copy)
@@ -10992,6 +10992,32 @@ memory and with the @code{MOVW} instruct
 of program memory.
 @*@var{mcu}@tie{}= @code{atmega2560}, @code{atmega2561}.
 
+@item avrxmega2
+``XMEGA'' devices with more than 8@tie{}KiB and up to 64@tie{}KiB
+of program memory.
+@*@var{mcu}@tie{}= @code{atxmega16a4}, @code{atxmega16d4},
+@dots{}
+
+@item avrxmega4
+``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB
+of program memory.
+@*@var{mcu}@tie{}= @code{atxmega64a3}, @code{atxmega64d3}.
+
+@item avrxmega5
+``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB
+of program memory and more than 64@tie{}KiB of RAM.
+@*@var{mcu}@tie{}= @code{atxmega64a1}, @code{atxmega64a1u}.
+
+@item avrxmega6
+``XMEGA'' devices with more than 128@tie{}KiB of program memory.
+@*@var{mcu}@tie{}= @code{atxmega128a3}, @code{atxmega192d3},
+@dots{}
+
+@item avrxmega7
+``XMEGA'' devices with more than 128@tie{}KiB of program memory and
+more than 64@tie{}KiB of RAM.
+@*@var{mcu}@tie{}= @code{atxmega128a1}, @code{atxmega128a1u}.
+
 @end table
 
 
@@ -11080,7 +11106,7 @@ byte of SP is always zero.
 @end table
 
 @subsubsection @code{EIND} and Devices with more than 128 Ki Bytes of Flash
-
+@cindex @code{EIND}
 Pointers in the implementation are 16@tie{}bits wide.
 The address of a function or label is represented as word address so
 that indirect jumps and calls can target any code address in the
@@ -11100,12 +11126,6 @@ the compiler and are subject to some lim
 The compiler never sets @code{EIND}.
 
 @item
-The startup code from libgcc never sets @code{EIND}.
-Notice that startup code is a blend of code from libgcc and avr-libc.
-For the impact of avr-libc on @code{EIND}, see the
-@w{@uref{http://nongnu.org/avr-libc/user-manual,avr-libc user manual}}.
-
-@item
 The compiler uses @code{EIND} implicitely in @code{EICALL}/@code{EIJMP}
 instructions or might read @code{EIND} directly in order to emulate an
 indirect call/jump by means of a @code{RET} instruction.
@@ -7,18 +11137,47 @@ saved/restored in function or interrupt
 prologue/epilogue.
 
 @item
-It is legitimate for user-specific startup code to set up @code{EIND}
-early, for example by means of initialization code located in
-section @code{.init3}. Such code runs prior to general startup code
-that initializes RAM and calls constructors.
-
-@item
 For indirect calls to functions and computed goto, the linker will
 generate @emph{stubs}. Stubs are jump pads sometimes also called
 @emph{trampolines}. Thus, the indirect call/jump will jump to such a stub.
 The stub contains a direct jump to the desired address.
 
 @item
+The default linker script is arranged for code with @code{EIND = 0}.
+If code is supposed to work for a setup with @code{EIND != 0}, a custom
+linker script has to be used in order to place the sections whose
+name start with @code{.trampolines} into the segment where @code{EIND}
+points to.
+
+@item
+The startup code from libgcc never sets @code{EIND}.
+Notice that startup code is a blend of code from libgcc and AVR-Libc.
+For the impact of AVR-Libc on @code{EIND}, see the
+@w{@uref{http://nongnu.org/avr-libc/user-manual,AVR-Libc user manual}}.
+
+@item
+It is legitimate for user-specific startup code to set up @code{EIND}
+early, for example by means of initialization code located in
+section @code{.init3}. Such code runs prior to general startup code
+that initializes RAM and calls constructors, but after the bit
+of startup code from AVR-Libc that sets @code{EIND} to the segment
+where the vector table is located.
+@example
+#include avr/io.h
+
+static void
+__attribute__ ((section (.init3), naked, used, no_instrument_function))
+init3_set_eind (void)
+@{
+__asm volatile (ldi r24, pm_hh8(__trampolines_start) \n\t
+out %i0, r24 :: n (EIND) : r24, memory);
+@}
+@end example
+
+@noindent
+The @code{__trampolines_start} symbol is defined in the linker script.
+
+@item
 Stubs will be generated automatically by the linker if
 the following two conditions are met:
 @itemize @minus
@@ -11158,13 +11207,6 @@ tables you can specify the @option{-fno-
 @end itemize
 
 @item
-The default linker script is arranged for code with @code{EIND = 0}.
-If code is supposed to work for a setup with @code{EIND != 0}, a custom
-linker script has to be used in order to place the sections whose
-name start with @code{.trampolines} into the segment where @code{EIND}
-points to.
-
-@item
 Jumping to non-symbolic 

Re: [Patch,AVR] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Georg-Johann Lay
Richard Guenther wrote:

 All commits to the 4.7 branch need explicit release manager approval.  AVR
 isn't primary/secondary so please do not change anything before is
 released 4.7.0 for it.
 
 Thanks,
 Richard.

What is the exact procedure in that case?
Wait until approve from release manager in that case?
Who is the release manager, and should I CC for such changes?
Or just hope the patch is not overseen.

Johann



Re: [Patch,AVR] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Richard Guenther
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:

 All commits to the 4.7 branch need explicit release manager approval.  AVR
 isn't primary/secondary so please do not change anything before is
 released 4.7.0 for it.

 Thanks,
 Richard.

 What is the exact procedure in that case?
 Wait until approve from release manager in that case?
 Who is the release manager, and should I CC for such changes?
 Or just hope the patch is not overseen.

The exact procedure is to do bugfixing during stage3/4, for release blockers
that pop up after a release candidate is created (like now), CC a release
manager (Jakub, me, Joseph) for patches that you like to get in even
though the branch is frozen.  Usually only bugs that prevent basic functionality
(like building a target) can be fixed at this point, for everything
else you have
to wait until after 4.7.0 is released and the branch opens again for regression
fixes.

Richard.

 Johann



Re: [PATCH 02/10] addr32: Output REX prefix for UNSPEC_GOTNTPOFF

2012-03-05 Thread Uros Bizjak
On Fri, Mar 2, 2012 at 9:36 PM, H.J. Lu hongjiu...@intel.com wrote:

 X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
 by checking

        movq foo@gottpoff(%rip), %reg

 and

        addq foo@gottpoff(%rip), %reg

 It uses the REX prefix to avoid the last byte of the previous
 instruction.  With 32bit Pmode, we may not have the REX prefix and
 the last byte of the previous instruction may be an offset, which
 may look like a REX prefix.  IE-LE optimization will generate corrupted
 binary.  This patch makes sure we always output an REX pfrefix for
 UNSPEC_GOTNTPOFF.  OK for trunk?

Actually, linker has:

case R_X86_64_GOTTPOFF:
  /* Check transition from IE access model:
mov foo@gottpoff(%rip), %reg
add foo@gottpoff(%rip), %reg
   */

  /* Check REX prefix first.  */
  if (offset = 3  (offset + 4) = sec-size)
{
  val = bfd_get_8 (abfd, contents + offset - 3);
  if (val != 0x48  val != 0x4c)
{
  /* X32 may have 0x44 REX prefix or no REX prefix.  */
  if (ABI_64_P (abfd))
return FALSE;
}
}
  else
{
  /* X32 may not have any REX prefix.  */
  if (ABI_64_P (abfd))
return FALSE;
  if (offset  2 || (offset + 3)  sec-size)
return FALSE;
}

So, it should handle the case without REX just OK. If it doesn't, then
this is a bug in binutils.

Uros.


Re: [patch, libffi] Sync merge libffi

2012-03-05 Thread John David Anglin

On 3/4/2012 11:18 PM, Anthony Green wrote:

On 3/4/2012 10:22 PM, John David Anglin wrote:
I'm just wondering why Anthony Green and Redhat are listed as 
copyright holders. I can understand the Free Software Foundation 
addition since the file was contributed to it.


Simply because of changes that were made to that source file over the 
years.  For instance, in 2011 I made a small change to that file (ABI 
check change), and the copyright notice update was largely a 
mechanical byproduct (emacs mostly automates this).


I have no objection to removing this if you feel strongly about it.
My personal opinion is that it is better if open source software is not 
encumbered by multiple copyright
holders.  A copyright holder probably has the right to change the work's 
permission notice.


Dave

--
John David Anglindave.ang...@bell.net



Re: [Patch,AVR,trunk,4.7] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Georg-Johann Lay
Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:

 All commits to the 4.7 branch need explicit release manager approval.  AVR
 isn't primary/secondary so please do not change anything before is
 released 4.7.0 for it.

 Thanks,
 Richard.
 What is the exact procedure in that case?
 Wait until approve from release manager in that case?
 Who is the release manager, and should I CC for such changes?
 Or just hope the patch is not overseen.
 
 The exact procedure is to do bugfixing during stage3/4, for release blockers
 that pop up after a release candidate is created (like now), CC a release
 manager (Jakub, me, Joseph) for patches that you like to get in even
 though the branch is frozen.  Usually only bugs that prevent basic 
 functionality
 (like building a target) can be fixed at this point, for everything
 else you have
 to wait until after 4.7.0 is released and the branch opens again for 
 regression
 fixes.
 
 Richard.

I was not aware that the 4.7.0 branch is completely frozen for the next 3
weeks; I thought the usual rules for backporting patches do apply...

The patch changes only in libgcc/config/avr and gcc/config/avr

The patch does not fix a blocker in the sense that without it avr cannot be
built, but the changes are essential.

Johann

libgcc/
PR target/52461
* config/avr/lib1funcs.S (__do_copy_data): Clear RAMPZ after usage
if RAMPZ affects reading from RAM.
(__tablejump_elpm__): Ditto.
(.xload): Ditto.
(__movmemx_hi): Ditto.
(__do_global_ctors): Right condition for RAMPZ usage is have ELPM.
(__do_global_dtors): Ditto.
(__xload_1, __xload_2, __xload_3, __xload_4): Ditto.  And make weak.
(__movmemx_hi): Ditto.  And fix RAM-loop label.
(__xload_1): Never read unintentionally from RAM.

gcc/
PR target/52461
* gcc/config/avr/avr.c (expand_prologue): Depend save/restore of
RAMPZ on HAVE_RAMPD, not HAVE_RAMPZ.
(expand_epilogue): Ditto.  And fix order of restoration to:
RAMPZ, RAMPY, RAMPX, RAMPD.
(avr_xload_libgcc_p): Always load __memx by lilbgcc call on
big-RAM devices.
(avr_out_lpm): Clear RAMPZ after usage if RAMPZ affects reading
from RAM.
(avr_out_xload): Never read unintentionally from RAM.
* config/avr/avr.md (xload_8): Adjust insn length.
Index: libgcc/config/avr/lib1funcs.S
===
--- libgcc/config/avr/lib1funcs.S	(revision 184887)
+++ libgcc/config/avr/lib1funcs.S	(working copy)
@@ -1853,7 +1853,7 @@ DEFUN __do_copy_data
 	cpi	r26, lo8(__data_end)
 	cpc	r27, r17
 	brne	.L__do_copy_data_loop
-#elif  !defined(__AVR_HAVE_ELPMX__)  defined(__AVR_HAVE_ELPM__)
+#elif defined(__AVR_HAVE_ELPM__)
 	ldi	r17, hi8(__data_end)
 	ldi	r26, lo8(__data_start)
 	ldi	r27, hi8(__data_start)
@@ -1873,7 +1873,7 @@ DEFUN __do_copy_data
 	cpi	r26, lo8(__data_end)
 	cpc	r27, r17
 	brne	.L__do_copy_data_loop
-#elif !defined(__AVR_HAVE_ELPMX__)  !defined(__AVR_HAVE_ELPM__)
+#else /* !ELPM */
 	ldi	r17, hi8(__data_end)
 	ldi	r26, lo8(__data_start)
 	ldi	r27, hi8(__data_start)
@@ -1892,7 +1892,11 @@ DEFUN __do_copy_data
 	cpi	r26, lo8(__data_end)
 	cpc	r27, r17
 	brne	.L__do_copy_data_loop
-#endif /* !defined(__AVR_HAVE_ELPMX__)  !defined(__AVR_HAVE_ELPM__) */
+#endif /* ELPMX / ELPM / LPM */
+#if defined (__AVR_HAVE_ELPM__)  defined (__AVR_HAVE_RAMPD__)
+	;; Reset RAMPZ to 0 so that EBI devices don't read garbage from RAM
+	out	__RAMPZ__, __zero_reg__
+#endif /* ELPM  RAMPD */
 ENDF __do_copy_data
 #endif /* L_copy_data */
 
@@ -1920,7 +1924,7 @@ ENDF __do_clear_bss
 #ifdef L_ctors
 	.section .init6,ax,@progbits
 DEFUN __do_global_ctors
-#if defined(__AVR_HAVE_RAMPZ__)
+#if defined(__AVR_HAVE_ELPM__)
 	ldi	r17, hi8(__ctors_start)
 	ldi	r28, lo8(__ctors_end)
 	ldi	r29, hi8(__ctors_end)
@@ -1939,7 +1943,7 @@ DEFUN __do_global_ctors
 	ldi	r24, hh8(__ctors_start)
 	cpc	r16, r24
 	brne	.L__do_global_ctors_loop
-#else
+#else /* !ELPM */
 	ldi	r17, hi8(__ctors_start)
 	ldi	r28, lo8(__ctors_end)
 	ldi	r29, hi8(__ctors_end)
@@ -1953,14 +1957,14 @@ DEFUN __do_global_ctors
 	cpi	r28, lo8(__ctors_start)
 	cpc	r29, r17
 	brne	.L__do_global_ctors_loop
-#endif /* defined(__AVR_HAVE_RAMPZ__) */
+#endif /* defined(__AVR_HAVE_ELPM__) */
 ENDF __do_global_ctors
 #endif /* L_ctors */
 
 #ifdef L_dtors
 	.section .fini6,ax,@progbits
 DEFUN __do_global_dtors
-#if defined(__AVR_HAVE_RAMPZ__)
+#if defined(__AVR_HAVE_ELPM__)
 	ldi	r17, hi8(__dtors_end)
 	ldi	r28, lo8(__dtors_start)
 	ldi	r29, hi8(__dtors_start)
@@ -1979,7 +1983,7 @@ DEFUN __do_global_dtors
 	ldi	r24, hh8(__dtors_end)
 	cpc	r16, r24
 	brne	.L__do_global_dtors_loop
-#else
+#else /* !ELPM */
 	ldi	r17, hi8(__dtors_end)
 	ldi	r28, lo8(__dtors_start)
 	ldi	r29, hi8(__dtors_start)
@@ -1993,7 +1997,7 @@ DEFUN __do_global_dtors
 	cpi	r28, lo8(__dtors_end)
 	cpc	r29, r17
 	brne	

Re: [Fwd: [patch] libitm: Don't execute memtransfer/memset if size isn't larger than zero.]

2012-03-05 Thread Richard Henderson
On 03/05/2012 05:35 AM, Torvald Riegel wrote:
   libitm/
   * dispatch.h (CREATE_DISPATCH_METHODS_MEM): Don't execute
   memtransfer/memset if size isn't larger than zero.

Ok everywhere.


r~


Re: [gimplefe][patch] The symbol table for declarations

2012-03-05 Thread Diego Novillo

On 01/03/12 13:06 , Sandeep Soni wrote:


2012-03-01  Sandeep Sonisoni.sande...@gmail.com

* parser.c : Include hashtab.h.
(gimple_symtab): New. The symbol table.
(gimple_symtab_entry_hash): New.
(gimple_symtab_eq_hash): New.
(gimple_symtab_entry_marked_p):New.
(gimple_symtab_maybe_init_hash_table):New.
(gimple_symtab_register_decl):New.
(gimple_register_var_decl_in_symtab):New.
(gp_parse_var_decl): Put declaration in the symbol table.
(gimple_main): Creates the symbol table
* parser.h : (struct gimple_symtab_entry_def): New.

2011-10-11  Sandeep Sonisoni.sande...@gmail.com

* parser.c (gp_parse_var_decl): Fixed a bug for the
missing symbol 'CPP_LESS' in the 'INTEGER_TYPE' declaration.


OK.  Thanks.


Diego.


[patch] fix memory corruption bug in tm_region_init

2012-03-05 Thread Aldy Hernandez

Hi folks.

Torvald has a testcase from the STAMP benchmark that is showing a memory 
corruption error after my fix to publication safety problems.


The problem is we're allocating a chunk of worklist memory of size 
n_basic_blocks which changes with tail merge optimization and such.  We 
end up with a smaller n_basic_blocks than some of the BB's left in the 
region.  I believe what we want is last_basic_block.


This fixes the memory corruption bug.  I couldn't minimize a sensible 
testcase.


OK?
* trans-mem.c (tm_region_init): Use last_basic_block.

Index: trans-mem.c
===
--- trans-mem.c (revision 184935)
+++ trans-mem.c (working copy)
@@ -1868,7 +1868,7 @@ tm_region_init (struct tm_region *region
  using bb-aux.  */
   region_worklist =
 (struct tm_region **) xcalloc (sizeof (struct tm_region *),
- n_basic_blocks + NUM_FIXED_BLOCKS + 2);
+ last_basic_block + NUM_FIXED_BLOCKS);
 
   VEC_safe_push (basic_block, heap, queue, bb);
   region_worklist[bb-index] = region;


Re: [Patch,AVR,trunk,4.7] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Richard Guenther
On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:

 All commits to the 4.7 branch need explicit release manager approval.  AVR
 isn't primary/secondary so please do not change anything before is
 released 4.7.0 for it.

 Thanks,
 Richard.
 What is the exact procedure in that case?
 Wait until approve from release manager in that case?
 Who is the release manager, and should I CC for such changes?
 Or just hope the patch is not overseen.

 The exact procedure is to do bugfixing during stage3/4, for release blockers
 that pop up after a release candidate is created (like now), CC a release
 manager (Jakub, me, Joseph) for patches that you like to get in even
 though the branch is frozen.  Usually only bugs that prevent basic 
 functionality
 (like building a target) can be fixed at this point, for everything
 else you have
 to wait until after 4.7.0 is released and the branch opens again for 
 regression
 fixes.

 Richard.

 I was not aware that the 4.7.0 branch is completely frozen for the next 3
 weeks; I thought the usual rules for backporting patches do apply...

No they don't.  How would you expect that testing a release candidate would
work if we put in any not strictly necessary changes?  That would make a
release candidate quite pointless.

 The patch changes only in libgcc/config/avr and gcc/config/avr

 The patch does not fix a blocker in the sense that without it avr cannot be
 built, but the changes are essential.

Surely not so essential as that they cannot be put in place to make the 4.7.1
release then.

Richard.

 Johann

 libgcc/
        PR target/52461
        * config/avr/lib1funcs.S (__do_copy_data): Clear RAMPZ after usage
        if RAMPZ affects reading from RAM.
        (__tablejump_elpm__): Ditto.
        (.xload): Ditto.
        (__movmemx_hi): Ditto.
        (__do_global_ctors): Right condition for RAMPZ usage is have ELPM.
        (__do_global_dtors): Ditto.
        (__xload_1, __xload_2, __xload_3, __xload_4): Ditto.  And make weak.
        (__movmemx_hi): Ditto.  And fix RAM-loop label.
        (__xload_1): Never read unintentionally from RAM.

 gcc/
        PR target/52461
        * gcc/config/avr/avr.c (expand_prologue): Depend save/restore of
        RAMPZ on HAVE_RAMPD, not HAVE_RAMPZ.
        (expand_epilogue): Ditto.  And fix order of restoration to:
        RAMPZ, RAMPY, RAMPX, RAMPD.
        (avr_xload_libgcc_p): Always load __memx by lilbgcc call on
        big-RAM devices.
        (avr_out_lpm): Clear RAMPZ after usage if RAMPZ affects reading
        from RAM.
        (avr_out_xload): Never read unintentionally from RAM.
        * config/avr/avr.md (xload_8): Adjust insn length.


Re: [PATCH 02/10] addr32: Output REX prefix for UNSPEC_GOTNTPOFF

2012-03-05 Thread H.J. Lu
On Mon, Mar 5, 2012 at 7:31 AM, Uros Bizjak ubiz...@gmail.com wrote:
 On Fri, Mar 2, 2012 at 9:36 PM, H.J. Lu hongjiu...@intel.com wrote:

 X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
 by checking

        movq foo@gottpoff(%rip), %reg

 and

        addq foo@gottpoff(%rip), %reg

 It uses the REX prefix to avoid the last byte of the previous
 instruction.  With 32bit Pmode, we may not have the REX prefix and
 the last byte of the previous instruction may be an offset, which
 may look like a REX prefix.  IE-LE optimization will generate corrupted
 binary.  This patch makes sure we always output an REX pfrefix for
 UNSPEC_GOTNTPOFF.  OK for trunk?

 Actually, linker has:

    case R_X86_64_GOTTPOFF:
      /* Check transition from IE access model:
                mov foo@gottpoff(%rip), %reg
                add foo@gottpoff(%rip), %reg
       */

      /* Check REX prefix first.  */
      if (offset = 3  (offset + 4) = sec-size)
        {
          val = bfd_get_8 (abfd, contents + offset - 3);
          if (val != 0x48  val != 0x4c)
            {
              /* X32 may have 0x44 REX prefix or no REX prefix.  */
              if (ABI_64_P (abfd))
                return FALSE;
            }
        }
      else
        {
          /* X32 may not have any REX prefix.  */
          if (ABI_64_P (abfd))
            return FALSE;
          if (offset  2 || (offset + 3)  sec-size)
            return FALSE;
        }

 So, it should handle the case without REX just OK. If it doesn't, then
 this is a bug in binutils.


The last byte of the displacement in the previous instruction
may happen to look like a REX byte. In that case, linker
will overwrite the last byte of the previous instruction and
generate the wrong instruction sequence.

I need to update linker to enforce the REX byte check.

-- 
H.J.


Re: libgo patch committed: Update to weekly.2012-02-22 release

2012-03-05 Thread Ian Lance Taylor
Uros Bizjak ubiz...@gmail.com writes:

 It looks that this patch introduced:

 /home/uros/gcc-build-go/x86_64-unknown-linux-gnu/32/libgo/.libs/libgo.so:
 undefined reference to `libgo_runtime.runtime.Callers'
 collect2: error: ld returned 1 exit status

 All libgo tests fail due to this undefined reference.

I guess I'm not seeing it because your system is defaulting to
-Wl,-z,now.

Fixed with this patch.  Sorry about that.

Bootstrapped on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r 2f1b1ab1b4d9 libgo/runtime/go-callers.c
--- a/libgo/runtime/go-callers.c	Sun Mar 04 22:37:34 2012 -0800
+++ b/libgo/runtime/go-callers.c	Mon Mar 05 09:06:45 2012 -0800
@@ -55,3 +55,12 @@
   _Unwind_Backtrace (backtrace, arg);
   return arg.index;
 }
+
+int Callers (int, struct __go_open_array)
+  __asm__ (libgo_runtime.runtime.Callers);
+
+int
+Callers (int skip, struct __go_open_array pc)
+{
+  return runtime_callers (skip, (uintptr *) pc.__values, pc.__count);
+}


Re: [patch] fix memory corruption bug in tm_region_init

2012-03-05 Thread Rainer Orth
Aldy Hernandez al...@redhat.com writes:

 Torvald has a testcase from the STAMP benchmark that is showing a memory
 corruption error after my fix to publication safety problems.

 The problem is we're allocating a chunk of worklist memory of size
 n_basic_blocks which changes with tail merge optimization and such.  We end
 up with a smaller n_basic_blocks than some of the BB's left in the region.
 I believe what we want is last_basic_block.

 This fixes the memory corruption bug.  I couldn't minimize a sensible
 testcase.

Could this be PR middle-end/52463 libitm.c/memcpy-1.c FAILs?

Rainer

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


Re: PATCH [1/n] addr32: Properly use Pmode and word_mode

2012-03-05 Thread H.J. Lu
On Sun, Mar 4, 2012 at 11:47 PM, Uros Bizjak ubiz...@gmail.com wrote:
 On Mon, Mar 5, 2012 at 4:53 AM, H.J. Lu hjl.to...@gmail.com wrote:

 and compiler does generate the same output. i386.c also has

        xasm = jmp\t%A0;
    xasm = call\t%A0;

 for calls.  There are no separate indirect call patterns.  For x32,
 only indirect register calls have to be in DImode.  The direct call
 should be in Pmode (SImode).

 Direct call just expects label to some abolute address that is assumed
 to fit in 32 bits (see constant_call_address_operand_p).

 call and jmp insn expect word_mode operands, so please change
 ix86_expand_call and call patterns in the same way as jump
 instructions above.

 Since x86-64 hardware always zero-extends upper 32bits of 64bit
 registers when loading its lower 32bits, it is safe and easier to just
 to output 64bit registers for %A than zero-extend it by hand for all
 jump/call patterns.

 No, the instruction expects word_mode operands, so we have to extend
 values to expected mode. I don't think that patching at insn output
 time is acceptable.

You are right. I found a testcase to show problem:

struct foo
{
  void (*f) (void);
  int i;
};

void
__attribute__ ((noinline))
bar (struct foo x)
{
  x.f ();
}

x is passed in RDI and the uppper 32bits of RDI is int i.

 BTW: I propose to split the patch into smaller pieces, dealing with
 various independent parts separately. Handling jump/call insn is
 definitely one of them, the other is stringops handling, another
 prologue/epilogue expansion.


I will do that.

Thanks.

-- 
H.J.


Re: [PATCH, i386] RTM support

2012-03-05 Thread Andi Kleen
On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
 Adding patch

I would still remove the -mrtm option. I never understood what options
for intrinsics are good for. They are just a pain to add to Makefiles,
but don't give any benefit.

-Andi


Re: PATCH [1/n] addr32: Properly use Pmode and word_mode

2012-03-05 Thread H.J. Lu
On Mon, Mar 5, 2012 at 12:01 AM, Uros Bizjak ubiz...@gmail.com wrote:
 On Sun, Mar 4, 2012 at 11:01 PM, H.J. Lu hjl.to...@gmail.com wrote:

 @@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
 ix86_address *out)
   else
     disp = addr;                       /* displacement */

 +  /* Since address override works only on the (reg) part in fs:(reg),
 +     we can't use it as memory operand.  */
 +  if (Pmode != word_mode  seg == SEG_FS  (base || index))
 +    return 0;

 Can you explain the above some more? IMO, if the override works on
 (reg) part, this is just what we want.

 When Pmode == SImode, we have

 fs segment register == 0x1001

 and

 base register (SImode) == -1 (0x).

 We are expecting address to be 0x1001 - 1 == 0x1000.  But, what we get
 is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only applies to
 base register to zero-extend 0x to 64bit.

 I would call this a bug in the specification - I guess that
 0x1001(%eax) works correctly.

This is how hardware works.

 We will treat this issue as a bug.


I also was surprised by this behavior.

-- 
H.J.


Re: [Patch,AVR,trunk,4.7] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Georg-Johann Lay
Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:

 All commits to the 4.7 branch need explicit release manager approval.  AVR
 isn't primary/secondary so please do not change anything before is
 released 4.7.0 for it.

 Thanks,
 Richard.
 What is the exact procedure in that case?
 Wait until approve from release manager in that case?
 Who is the release manager, and should I CC for such changes?
 Or just hope the patch is not overseen.
 The exact procedure is to do bugfixing during stage3/4, for release blockers
 that pop up after a release candidate is created (like now), CC a release
 manager (Jakub, me, Joseph) for patches that you like to get in even
 though the branch is frozen.  Usually only bugs that prevent basic 
 functionality
 (like building a target) can be fixed at this point, for everything
 else you have
 to wait until after 4.7.0 is released and the branch opens again for 
 regression
 fixes.

 Richard.
 I was not aware that the 4.7.0 branch is completely frozen for the next 3
 weeks; I thought the usual rules for backporting patches do apply...
 
 No they don't.  How would you expect that testing a release candidate would
 work if we put in any not strictly necessary changes?  That would make a
 release candidate quite pointless.
 
 The patch changes only in libgcc/config/avr and gcc/config/avr

 The patch does not fix a blocker in the sense that without it avr cannot be
 built, but the changes are essential.
 
 Surely not so essential as that they cannot be put in place to make the 4.7.1
 release then.

Okay.

In that case I'd like to add a note to the caveats section in wwwdocs

./gcc-4.7/changes.html

that the avr-gcc 4.7.0 is not intended for public consumption and because of
developer shortage at least 4.7.1 should be used.



Re: [patch] fix memory corruption bug in tm_region_init

2012-03-05 Thread Richard Henderson
On 03/05/2012 08:54 AM, Aldy Hernandez wrote:
region_worklist =
  (struct tm_region **) xcalloc (sizeof (struct tm_region *),
 -   n_basic_blocks + NUM_FIXED_BLOCKS + 2);
 +   last_basic_block + NUM_FIXED_BLOCKS);

This is ok.

I was confused for a moment by the worklist variable name, which
suggests a queue.  I'd also suggest that you change to use a vec,
rather than callocing yourself, and would have caught the memory
error earlier.


r~


Re: PATCH [1/n] addr32: Properly use Pmode and word_mode

2012-03-05 Thread H.J. Lu
On Mon, Mar 5, 2012 at 12:24 AM, Uros Bizjak ubiz...@gmail.com wrote:
 On Mon, Mar 5, 2012 at 9:01 AM, Uros Bizjak ubiz...@gmail.com wrote:

 @@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
 ix86_address *out)
   else
     disp = addr;                       /* displacement */

 +  /* Since address override works only on the (reg) part in fs:(reg),
 +     we can't use it as memory operand.  */
 +  if (Pmode != word_mode  seg == SEG_FS  (base || index))
 +    return 0;

 Can you explain the above some more? IMO, if the override works on
 (reg) part, this is just what we want.

 When Pmode == SImode, we have

 fs segment register == 0x1001

 and

 base register (SImode) == -1 (0x).

 We are expecting address to be 0x1001 - 1 == 0x1000.  But, what we get
 is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only applies to
 base register to zero-extend 0x to 64bit.

 I would call this a bug in the specification - I guess that
 0x1001(%eax) works correctly.

 We will treat this issue as a bug.

 Nice, we have TARGET_TLS_DIRECT_SEG_REFS option. We can just clear it
 somewhere appropriate when Pmode != word_mode.


This only applies to fs:(reg) address.  fs:offset is OK.

-- 
H.J.


Re: Remove obsolete Tru64 UNIX V5.1B support

2012-03-05 Thread Andrew Haley
On 03/05/2012 05:01 PM, Rainer Orth wrote:
 * In libjava, there were several workarounds for OSF bugs/quirks.  I've
   ripped them out as explained above.
 
   There's one particular issue: the change to java/io/File.java required
   my to regenerate the .class file in classpath.  I've used Sun javac
   -target 1.5 for that and hope I got it right.

OK.

Andrew.



Re: PATCH [1/n] addr32: Properly use Pmode and word_mode

2012-03-05 Thread Jakub Jelinek
On Mon, Mar 05, 2012 at 09:13:49AM -0800, H.J. Lu wrote:
  We are expecting address to be 0x1001 - 1 == 0x1000.  But, what we get
  is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only applies 
  to
  base register to zero-extend 0x to 64bit.
 
  I would call this a bug in the specification - I guess that
  0x1001(%eax) works correctly.
 
 This is how hardware works.

Do you really need to use addr32 prefixes for the direct TLS seg refs?
Without that the addresses will be sign-extended from the 32-bit immediate
(which is used in LP64 x86_64 code too) and everything will work fine, won't
it?

Jakub


Remove MIPS_DEBUGGING_INFO support

2012-03-05 Thread Rainer Orth
The only two users of MIPS_DEBUGGING_INFO are on their way out: I've
just submitted a patch to remove the OpenBSD/MIPS configuration, and
IRIX removal will follow soon.  There seems to be no point in retaining
what seems to be primarily workarounds for quirks in SGI dbx, so the
following patch removes all other remnants of MIPS_DEBUGGING_INFO.

Bootstrapped without regressions on i386-pc-solaris2.10 to ensure
syntactic correctness.  I'll wait with committing until after
OpenBSD/MIPS and IRIX are actually gone.

Ok for mainline?

Rainer


2012-02-24  Rainer Orth  r...@cebitec.uni-bielefeld.de

* config/alpha/alpha.h (MIPS_DEBUGGING_INFO): Remove.
* config/alpha/elf.h (MIPS_DEBUGGING_INFO): Don't undef.
* config/alpha/vms.h (MIPS_DEBUGGING_INFO): Don't undef.

* dwarf2cfi.c (def_cfa_0): Remove MIPS_DEBUGGING_INFO handling.
(dwarf2out_do_cfi_asm): Likewise.
* dwarf2out.c (output_call_frame_info): Remove MIPS_DEBUGGING_INFO
handling.
(add_data_member_location_attribute): Likewise.
(gen_array_type_die): Likewise.
(gen_subprogram_die): Likewise.
(gen_producer_string): Likewise.
* sdbout.c (sdbout_begin_prologue): Declare unconditionally.
Remove MIPS_DEBUGGING_INFO handling.
(sdb_debug_hooks): Likewise.
(sdbout_begin_block): Likewise.
(sdbout_end_block): Likewise.
(sdbout_begin_prologue): Likewise.
(sdbout_start_source_file): Likewise.
(sdbout_end_source_file): Likewise.
(sdbout_init): Likewise.

# HG changeset patch
# Parent 7065cf1a3c9457e7ea48e3e7feee9b4e0726c3a7
Remove MIPS_DEBUGGING_INFO support

diff --git a/gcc/config/alpha/alpha.h b/gcc/config/alpha/alpha.h
--- a/gcc/config/alpha/alpha.h
+++ b/gcc/config/alpha/alpha.h
@@ -1165,7 +1165,6 @@ do {		\
 
 #define SDB_DEBUGGING_INFO 1		/* generate info for mips-tfile */
 #define DBX_DEBUGGING_INFO 1		/* generate embedded stabs */
-#define MIPS_DEBUGGING_INFO 1		/* MIPS specific debugging info */
 
 #ifndef PREFERRED_DEBUGGING_TYPE	/* assume SDB_DEBUGGING_INFO */
 #define PREFERRED_DEBUGGING_TYPE  SDB_DEBUG
diff --git a/gcc/config/alpha/elf.h b/gcc/config/alpha/elf.h
--- a/gcc/config/alpha/elf.h
+++ b/gcc/config/alpha/elf.h
@@ -1,6 +1,6 @@
 /* Definitions of target machine for GNU compiler, for DEC Alpha w/ELF.
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2007, 2008,
-   2009, 2010 Free Software Foundation, Inc.
+   2009, 2010, 2012 Free Software Foundation, Inc.
Contributed by Richard Henderson (r...@tamu.edu).
 
 This file is part of GCC.
@@ -25,7 +25,6 @@ along with GCC; see the file COPYING3.  
 
 /* ??? Move all SDB stuff from alpha.h to osf.h.  */
 #undef SDB_DEBUGGING_INFO
-#undef MIPS_DEBUGGING_INFO
 #undef DBX_DEBUGGING_INFO
 
 #define DWARF2_DEBUGGING_INFO 1
diff --git a/gcc/config/alpha/vms.h b/gcc/config/alpha/vms.h
--- a/gcc/config/alpha/vms.h
+++ b/gcc/config/alpha/vms.h
@@ -1,6 +1,6 @@
 /* Output variables, constants and external declarations, for GNU compiler.
Copyright (C) 1996, 1997, 1998, 2000, 2001, 2002, 2004, 2005, 2007, 2008,
-   2009, 2010, 2011
+   2009, 2010, 2011, 2012
Free Software Foundation, Inc.
 
 This file is part of GCC.
@@ -206,7 +206,6 @@ typedef struct {int num_args; enum avms_
 #define TARGET_ASM_DESTRUCTOR   vms_asm_out_destructor
 
 #undef SDB_DEBUGGING_INFO
-#undef MIPS_DEBUGGING_INFO
 #undef DBX_DEBUGGING_INFO
 
 #define DWARF2_DEBUGGING_INFO 1
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -1,6 +1,6 @@
 /* Dwarf2 Call Frame Information helper routines.
Copyright (C) 1992, 1993, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-   2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+   2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
 
 This file is part of GCC.
@@ -724,8 +724,6 @@ def_cfa_0 (dw_cfa_location *old_cfa, dw_
 	cfi-dw_cfi_opc = DW_CFA_def_cfa_offset;
   cfi-dw_cfi_oprnd1.dw_cfi_offset = new_cfa-offset;
 }
-
-#ifndef MIPS_DEBUGGING_INFO  /* SGI dbx thinks this means no offset.  */
   else if (new_cfa-offset == old_cfa-offset
 	old_cfa-reg != INVALID_REGNUM
 	!new_cfa-indirect
@@ -737,8 +735,6 @@ def_cfa_0 (dw_cfa_location *old_cfa, dw_
   cfi-dw_cfi_opc = DW_CFA_def_cfa_register;
   cfi-dw_cfi_oprnd1.dw_cfi_reg_num = new_cfa-reg;
 }
-#endif
-
   else if (new_cfa-indirect == 0)
 {
   /* Construct a DW_CFA_def_cfa register offset instruction,
@@ -3388,10 +3384,6 @@ dwarf2out_do_cfi_asm (void)
 {
   int enc;
 
-#ifdef MIPS_DEBUGGING_INFO
-  return false;
-#endif
-
   if (saved_do_cfi_asm != 0)
 return saved_do_cfi_asm  0;
 
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -879,11 +879,6 @@ output_call_frame_info (int for_eh)
 
   if (for_eh  targetm.terminate_dw2_eh_frame_info)
 dw2_asm_output_data (4, 0, End of Table);
-#ifdef 

Re: Remove MIPS_DEBUGGING_INFO support

2012-03-05 Thread Richard Henderson
On 03/05/2012 09:20 AM, Rainer Orth wrote:
 2012-02-24  Rainer Orth  r...@cebitec.uni-bielefeld.de
 
   * config/alpha/alpha.h (MIPS_DEBUGGING_INFO): Remove.
   * config/alpha/elf.h (MIPS_DEBUGGING_INFO): Don't undef.
   * config/alpha/vms.h (MIPS_DEBUGGING_INFO): Don't undef.
 
   * dwarf2cfi.c (def_cfa_0): Remove MIPS_DEBUGGING_INFO handling.
   (dwarf2out_do_cfi_asm): Likewise.
   * dwarf2out.c (output_call_frame_info): Remove MIPS_DEBUGGING_INFO
   handling.
   (add_data_member_location_attribute): Likewise.
   (gen_array_type_die): Likewise.
   (gen_subprogram_die): Likewise.
   (gen_producer_string): Likewise.
   * sdbout.c (sdbout_begin_prologue): Declare unconditionally.
   Remove MIPS_DEBUGGING_INFO handling.
   (sdb_debug_hooks): Likewise.
   (sdbout_begin_block): Likewise.
   (sdbout_end_block): Likewise.
   (sdbout_begin_prologue): Likewise.
   (sdbout_start_source_file): Likewise.
   (sdbout_end_source_file): Likewise.
   (sdbout_init): Likewise.

Ok.


r~


[PATCH] reload: Try alternative with swapped operands before going to the next

2012-03-05 Thread Andreas Krebbel
Hi,

I've re-tested the patch from:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01819.html
on s390x and x86_64.

Ok for mainline?

Bye,

-Andreas-



Re: [PATCH 02/10] addr32: Output REX prefix for UNSPEC_GOTNTPOFF

2012-03-05 Thread Uros Bizjak
On Mon, Mar 5, 2012 at 6:03 PM, H.J. Lu hjl.to...@gmail.com wrote:

 X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
 by checking

        movq foo@gottpoff(%rip), %reg

 and

        addq foo@gottpoff(%rip), %reg

 It uses the REX prefix to avoid the last byte of the previous
 instruction.  With 32bit Pmode, we may not have the REX prefix and
 the last byte of the previous instruction may be an offset, which
 may look like a REX prefix.  IE-LE optimization will generate corrupted
 binary.  This patch makes sure we always output an REX pfrefix for
 UNSPEC_GOTNTPOFF.  OK for trunk?

 Actually, linker has:

    case R_X86_64_GOTTPOFF:
      /* Check transition from IE access model:
                mov foo@gottpoff(%rip), %reg
                add foo@gottpoff(%rip), %reg
       */

      /* Check REX prefix first.  */
      if (offset = 3  (offset + 4) = sec-size)
        {
          val = bfd_get_8 (abfd, contents + offset - 3);
          if (val != 0x48  val != 0x4c)
            {
              /* X32 may have 0x44 REX prefix or no REX prefix.  */
              if (ABI_64_P (abfd))
                return FALSE;
            }
        }
      else
        {
          /* X32 may not have any REX prefix.  */
          if (ABI_64_P (abfd))
            return FALSE;
          if (offset  2 || (offset + 3)  sec-size)
            return FALSE;
        }

 So, it should handle the case without REX just OK. If it doesn't, then
 this is a bug in binutils.


 The last byte of the displacement in the previous instruction
 may happen to look like a REX byte. In that case, linker
 will overwrite the last byte of the previous instruction and
 generate the wrong instruction sequence.

 I need to update linker to enforce the REX byte check.

One important observation: if we want to follow the x86_64 TLS spec
strictly, we have to use existing DImode patterns only. This also
means that we should NOT convert other TLS patterns to Pmode, since
they explicitly state movq and addq. If this is not the case, then we
need new TLS specification for X32.

Uros.

 --
 H.J.


Re: PATCH [1/n] addr32: Properly use Pmode and word_mode

2012-03-05 Thread H.J. Lu
On Mon, Mar 5, 2012 at 9:20 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Mon, Mar 05, 2012 at 09:13:49AM -0800, H.J. Lu wrote:
  We are expecting address to be 0x1001 - 1 == 0x1000.  But, what we get
  is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only applies 
  to
  base register to zero-extend 0x to 64bit.
 
  I would call this a bug in the specification - I guess that
  0x1001(%eax) works correctly.

 This is how hardware works.

 Do you really need to use addr32 prefixes for the direct TLS seg refs?
 Without that the addresses will be sign-extended from the 32-bit immediate
 (which is used in LP64 x86_64 code too) and everything will work fine, won't
 it?


32bit immediate is OK.  The problem is fs:(32bit register).


-- 
H.J.


Re: [Patch,AVR,trunk,4.7] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Richard Guenther
On Mon, Mar 5, 2012 at 6:15 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:

 All commits to the 4.7 branch need explicit release manager approval.  
 AVR
 isn't primary/secondary so please do not change anything before is
 released 4.7.0 for it.

 Thanks,
 Richard.
 What is the exact procedure in that case?
 Wait until approve from release manager in that case?
 Who is the release manager, and should I CC for such changes?
 Or just hope the patch is not overseen.
 The exact procedure is to do bugfixing during stage3/4, for release 
 blockers
 that pop up after a release candidate is created (like now), CC a release
 manager (Jakub, me, Joseph) for patches that you like to get in even
 though the branch is frozen.  Usually only bugs that prevent basic 
 functionality
 (like building a target) can be fixed at this point, for everything
 else you have
 to wait until after 4.7.0 is released and the branch opens again for 
 regression
 fixes.

 Richard.
 I was not aware that the 4.7.0 branch is completely frozen for the next 3
 weeks; I thought the usual rules for backporting patches do apply...

 No they don't.  How would you expect that testing a release candidate would
 work if we put in any not strictly necessary changes?  That would make a
 release candidate quite pointless.

 The patch changes only in libgcc/config/avr and gcc/config/avr

 The patch does not fix a blocker in the sense that without it avr cannot be
 built, but the changes are essential.

 Surely not so essential as that they cannot be put in place to make the 4.7.1
 release then.

 Okay.

 In that case I'd like to add a note to the caveats section in wwwdocs

 ./gcc-4.7/changes.html

 that the avr-gcc 4.7.0 is not intended for public consumption and because of
 developer shortage at least 4.7.1 should be used.

Completely unusable?  It looks like it only affects a subset of all devices:
To read from flash on devices with more than 64KiB of flash

It sounds like a random wrong-code bug, which do happen.

There is just a timeframe where random fixes are not good.

Was 4.6.3 intended for public consumption?

Be reasonable.
Richard.


Re: Remove obsolete Tru64 UNIX V5.1B support

2012-03-05 Thread Richard Henderson
On 03/05/2012 09:14 AM, Rainer Orth wrote:
 * In the alpha backend, there are a couple of cases that might be
   osf-specific, but I cannot tell for certain:
 
   macro osf5.halpha.h
 
   TARGET_AS_CAN_SUBTRACT_LABELS 1 TARGET_GAS
 
   I cannot tell if !TARGET_GAS configurations exist, especially Alpha VMS.
   Also, in alpha.h there are some references to mips-tfile, which is
   gone with osf.  If there are no non-gas configrations remaining, that
   stuff can go, too.

Given that GAS supports VMS, I suspect that all targets are now GAS.
I'll let the adacore folks answer that for certain howeverl.

   TARGET_HAS_XFLOATING_LIBS 1 TARGET_LONG_DOUBLE_128
 
   Same here: any configurations with !TARGET_LONG_DOUBLE_128?

I wouldn't think so; glibc before version 2.4, circa 1998?

   HAVE_STAMP_H1
 
   In my understanding, this is purely a OSF thing and can go, but maybe
   other OSes on alpha mimiced OSF here?

I've no idea what that actually is.

I'll have a look at the patch in detail later

r~


Re: Remove obsolete Tru64 UNIX V5.1B fixinclude support

2012-03-05 Thread Bruce Korb

On 03/05/12 09:01, Rainer Orth wrote:

This is where I need explicit approval and/or guidance:

* There are some fixincludes hacks that from their names seem to be
   osf-specific, but are not restricted to alpha*-dec-osf*.  Bruce,
   what's the best way to handle those?  Disable them e.g. with a mach
   clause like unused-alpha*-dec-osf* and see if anything else breaks?


I think the right way is to require that all ports have a maintenance
person build the thing at least once a year for all supported platforms.

For such maintenance builds, I can trivially emit a list of hacks that
got triggered during the build.  Any hacks that don't show up in the
list for a couple of years get marked as obsolete and trigger a build
warning.  If nobody complains about the warning, then its gone.
Shouldn't take more than 3 or 4 years of disuse to get rid of the cruft. :)

How's that for an approach?

Cheers - Bruce


Re: PATCH [1/n] addr32: Properly use Pmode and word_mode

2012-03-05 Thread Jakub Jelinek
On Mon, Mar 05, 2012 at 09:26:20AM -0800, H.J. Lu wrote:
 On Mon, Mar 5, 2012 at 9:20 AM, Jakub Jelinek ja...@redhat.com wrote:
  On Mon, Mar 05, 2012 at 09:13:49AM -0800, H.J. Lu wrote:
   We are expecting address to be 0x1001 - 1 == 0x1000.  But, what we get
   is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only 
   applies to
   base register to zero-extend 0x to 64bit.
  
   I would call this a bug in the specification - I guess that
   0x1001(%eax) works correctly.
 
  This is how hardware works.
 
  Do you really need to use addr32 prefixes for the direct TLS seg refs?
  Without that the addresses will be sign-extended from the 32-bit immediate
  (which is used in LP64 x86_64 code too) and everything will work fine, won't
  it?
 
 
 32bit immediate is OK.  The problem is fs:(32bit register).
 

Just require that the MEM uses DImode address in those patterns, even for -mx32?

Jakub


Re: Remove obsolete Tru64 UNIX V5.1B support

2012-03-05 Thread Bruce Korb
CF:
fixincludes:
   * inclhack.def (alpha___extern_prefix): Remove.
   (alpha___extern_prefix_standards): Remove.
   (alpha___extern_prefix_sys_stat): Remove.
   (alpha_bad_lval): Remove.
   (alpha_pthread): Remove.
   (alpha_pthread_gcc): Remove.
   (alpha_pthread_init): Remove.
   * fixincl.x: Regenerate.
   * tests/base/pthread.h [ALPHA_PTHREAD_CHECK]: Remove.
   [ALPHA_PTHREAD_GCC_CHECK]: Remove.
   [ALPHA_PTHREAD_INIT_CHECK]: Remove.
   * tests/base/standards.h: Remove.
   * tests/base/sys/stat.h [ALPHA___EXTERN_PREFIX_SYS_STAT_CHECK]:
   Remove.
   * tests/base/testing.h [ALPHA___EXTERN_PREFIX_CHECK]: Remove.
   [ALPHA_BAD_LVAL_CHECK]: Remove.

Seems reasonable to me...


Re: Remove obsolete Tru64 UNIX V5.1B support

2012-03-05 Thread Jakub Jelinek
On Mon, Mar 05, 2012 at 09:28:18AM -0800, Richard Henderson wrote:
TARGET_HAS_XFLOATING_LIBS   1 TARGET_LONG_DOUBLE_128
  
Same here: any configurations with !TARGET_LONG_DOUBLE_128?
 
 I wouldn't think so; glibc before version 2.4, circa 1998?

No idea about MIPS, but for ppc/ppc64/s390/s390x/sparc32 the selectable
size long double support is from 2006.

Jakub


Re: Remove obsolete Tru64 UNIX V5.1B support

2012-03-05 Thread Douglas Rupp

On 3/5/2012 9:28 AM, Richard Henderson wrote:

On 03/05/2012 09:14 AM, Rainer Orth wrote:

* In the alpha backend, there are a couple of cases that might be
   osf-specific, but I cannot tell for certain:

   macro  osf5.halpha.h

   TARGET_AS_CAN_SUBTRACT_LABELS  1 TARGET_GAS

   I cannot tell if !TARGET_GAS configurations exist, especially Alpha VMS.
   Also, in alpha.h there are some references to mips-tfile, which is
   gone with osf.  If there are no non-gas configrations remaining, that
   stuff can go, too.

Given that GAS supports VMS, I suspect that all targets are now GAS.
I'll let the adacore folks answer that for certain howeverl.


All Alpha/VMS targets use GAS.
--Doug


Re: [PATCH, i386] RTM support

2012-03-05 Thread Kirill Yukhin
On Mon, Mar 5, 2012 at 9:12 PM, Andi Kleen a...@firstfloor.org wrote:
 On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
 Adding patch

 I would still remove the -mrtm option. I never understood what options
 for intrinsics are good for. They are just a pain to add to Makefiles,
 but don't give any benefit.

 -Andi

Hi Andi,
I agree with youm but, think such things are up to mainteiners..

Guys, what do you think?
I see no problem enabling RTM by default. We may still provide -mno-rtm option.

Thanks, K


Re: Remove obsolete Tru64 UNIX V5.1B support

2012-03-05 Thread Rainer Orth
Jakub Jelinek ja...@redhat.com writes:

 On Mon, Mar 05, 2012 at 09:28:18AM -0800, Richard Henderson wrote:
TARGET_HAS_XFLOATING_LIBS  1 TARGET_LONG_DOUBLE_128
  
Same here: any configurations with !TARGET_LONG_DOUBLE_128?
 
 I wouldn't think so; glibc before version 2.4, circa 1998?

 No idea about MIPS, but for ppc/ppc64/s390/s390x/sparc32 the selectable
 size long double support is from 2006.

... which leaves us with the BSDs.  No idea about those.

Rainer

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


Re: [Patch,AVR,trunk,4.7] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

2012-03-05 Thread Georg-Johann Lay
Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 6:15 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:
 On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
 Richard Guenther wrote:

 All commits to the 4.7 branch need explicit release manager approval.  
 AVR
 isn't primary/secondary so please do not change anything before is
 released 4.7.0 for it.

 Thanks,
 Richard.
 What is the exact procedure in that case?
 Wait until approve from release manager in that case?
 Who is the release manager, and should I CC for such changes?
 Or just hope the patch is not overseen.
 The exact procedure is to do bugfixing during stage3/4, for release 
 blockers
 that pop up after a release candidate is created (like now), CC a release
 manager (Jakub, me, Joseph) for patches that you like to get in even
 though the branch is frozen.  Usually only bugs that prevent basic 
 functionality
 (like building a target) can be fixed at this point, for everything
 else you have
 to wait until after 4.7.0 is released and the branch opens again for 
 regression
 fixes.

 Richard.
 I was not aware that the 4.7.0 branch is completely frozen for the next 3
 weeks; I thought the usual rules for backporting patches do apply...
 No they don't.  How would you expect that testing a release candidate would
 work if we put in any not strictly necessary changes?  That would make a
 release candidate quite pointless.

 The patch changes only in libgcc/config/avr and gcc/config/avr

 The patch does not fix a blocker in the sense that without it avr cannot be
 built, but the changes are essential.
 Surely not so essential as that they cannot be put in place to make the 
 4.7.1
 release then.
 Okay.

 In that case I'd like to add a note to the caveats section in wwwdocs

 ./gcc-4.7/changes.html

 that the avr-gcc 4.7.0 is not intended for public consumption and because of
 developer shortage at least 4.7.1 should be used.
 
 Completely unusable?  It looks like it only affects a subset of all devices:
 To read from flash on devices with more than 64KiB of flash

The patch fixes more problems than indicated by log message's PR.

 It sounds like a random wrong-code bug, which do happen.

Yes they happen. But if the defect is so severe that the code is effectively
useless, the compiler is useless.

That is not a problem if it is clearly stated and people don't waste days to
set up and distribute avr toolchains that are useless. It would simply be not
fair to let them waste their time and to hold back that knowledge.

 There is just a timeframe where random fixes are not good.

This is not a problem. Just inform the potential users about the defect.

 Was 4.6.3 intended for public consumption?

Yes.

Johann



Re: Remove obsolete Tru64 UNIX V5.1B support

2012-03-05 Thread Jonathan Wakely
On 5 March 2012 17:01, Rainer Orth wrote:

 * The libstdc++ testsuite is messy since every thing pthread test
  includes the complete list of targets where it should be run, and the
  options required.  I've long meant to clean this up, but this will
  have to wait until after osf and irix are gone from the tree.

That would be fantastic if you do clean it up some time.

The libstdc++ parts of this patch are OK.


Re: [C++ PATCH] Change local_specializations from htab_t to pointer map

2012-03-05 Thread Jason Merrill

OK.

Jason


[SH] PR 51244 - Improve conditional branches

2012-03-05 Thread Oleg Endo
Hello,

The attached patch is the same as the last one proposed in the PR.
Tested against rev 184877 with

make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a-single/-mb,
-m4-single/-ml,-m4-single/-mb,
-m4a-single/-ml,-m4a-single/-mb}

and no new failures.
OK?

Cheers,
Oleg

ChangeLog:

PR target/51244
* config/sh/sh.c (sh_expand_t_scc): Remove SH2A special case
and use unified expansion logic.
* config/sh/sh.md (xorsi3_movrt): Rename to movrt.  Move
closer to the existing movt insn.
(negc): Rename insn to *negc.  Add new expander.
(movnegt): Use xor pattern for T bit negation.  Reserve helper
constant for negc pattern.
(*movnegt): New insn and splitter.

testsuite/ChangeLog:

PR target/51244
* gcc.target/sh/pr51244-1.c: New.
* gcc.target/sh/pr51244-2.c: New.
* gcc.target/sh/pr51244-3.c: New.

Index: gcc/testsuite/gcc.target/sh/pr51244-1.c
===
--- gcc/testsuite/gcc.target/sh/pr51244-1.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/pr51244-1.c	(revision 0)
@@ -0,0 +1,32 @@
+/* Check that inverted conditional branch logic does not generate
+   unnecessary explicit T bit extractions, inversions and 
+   test instructions.  */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 -mbranch-cost=2 } */
+/* { dg-skip-if  { sh*-*-* } { -m5*} {  } } */
+/* { dg-final { scan-assembler-not tst|negc|extu } } */
+
+int
+testfunc_00 (int a, int b, int c, int d)
+{
+  return (a != b || a != d) ? b : c;
+}
+
+int
+testfunc_01 (int a, char* p, int b, int c)
+{
+  return (a == b  a == c) ? b : c;
+}
+
+int
+testfunc_02 (int a, char* p, int b, int c)
+{
+  return (a == b  a == c) ? b : c;
+}
+
+int
+testfunc_03 (int a, char* p, int b, int c)
+{
+  return (a != b  a != c) ? b : c;
+}
+
Index: gcc/testsuite/gcc.target/sh/pr51244-2.c
===
--- gcc/testsuite/gcc.target/sh/pr51244-2.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/pr51244-2.c	(revision 0)
@@ -0,0 +1,18 @@
+/* Check that when taking the complement of the T bit using the negc
+   instruction pattern, the constant -1 is loaded only once.
+   On SH2A this test is skipped because the movrt instruction is used
+   to get the complement of the T bit.  */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 -mbranch-cost=2 } */
+/* { dg-skip-if  { sh*-*-* } { -m5* -m2a* } {  } } */
+/* { dg-final { scan-assembler-times mov\t#-1 1 } } */
+
+void
+testfunc_00 (int* a, int* b, int c, int d)
+{
+  b[0] = a[0] != c;
+  b[1] = a[1] != d;
+  b[2] = a[2] != c;
+  b[3] = a[3] != d;
+}
+
Index: gcc/testsuite/gcc.target/sh/pr51244-3.c
===
--- gcc/testsuite/gcc.target/sh/pr51244-3.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/pr51244-3.c	(revision 0)
@@ -0,0 +1,16 @@
+/* Check that when taking the complement of the T bit on SH2A, 
+   the movrt instruction is being generated.  */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 -mbranch-cost=2 } */
+/* { dg-skip-if  { sh*-*-* } { * } { -m2a* } } */
+/* { dg-final { scan-assembler-times movrt 4 } } */
+
+void
+testfunc_00 (int* a, int* b, int c, int d)
+{
+  b[0] = a[0] != c;
+  b[1] = a[1] != d;
+  b[2] = a[2] != c;
+  b[3] = a[3] != d;
+}
+
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 184877)
+++ gcc/config/sh/sh.c	(working copy)
@@ -11883,15 +11883,8 @@
   val = INTVAL (op1);
   if ((code == EQ  val == 1) || (code == NE  val == 0))
 emit_insn (gen_movt (result));
-  else if (TARGET_SH2A  ((code == EQ  val == 0)
-			|| (code == NE  val == 1)))
-emit_insn (gen_xorsi3_movrt (result));
   else if ((code == EQ  val == 0) || (code == NE  val == 1))
-{
-  emit_clobber (result);
-  emit_insn (gen_subc (result, result, result));
-  emit_insn (gen_addsi3 (result, result, const1_rtx));
-}
+   emit_insn (gen_movnegt (result));
   else if (code == EQ || code == NE)
 emit_insn (gen_move_insn (result, GEN_INT (code == NE)));
   else
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 184877)
+++ gcc/config/sh/sh.md	(working copy)
@@ -3354,15 +3354,6 @@
 	xori	%1, %2, %0
   [(set_attr type arith_media)])
 
-;; Store the complements of the T bit in a register.
-(define_insn xorsi3_movrt
-  [(set (match_operand:SI 0 arith_reg_dest =r)
-	(xor:SI (reg:SI T_REG)
-		(const_int 1)))]
-  TARGET_SH2A
-  movrt\\t%0
-  [(set_attr type arith)])
-
 (define_insn xordi3
   [(set (match_operand:DI 0 arith_reg_dest =r,r)
 	(xor:DI (match_operand:DI 1 arith_reg_operand %r,r)
@@ -4387,7 +4378,17 @@
 ;; Unary arithmetic
 ;; -
 
-(define_insn negc

Re: Remove obsolete Tru64 UNIX V5.1B support

2012-03-05 Thread Rainer Orth
Richard Henderson r...@redhat.com writes:

   HAVE_STAMP_H1
 
   In my understanding, this is purely a OSF thing and can go, but maybe
   other OSes on alpha mimiced OSF here?

 I've no idea what that actually is.

It's used to emit .verstamp directives for ECOFF objects.  I've just
checked again: all of Linux, *BSD, and VMS use ELF, so HAVE_STAMP_H
support (and any code for !OBJECT_FORMAT_ELF) can go.

Rainer

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


Re: Remove obsolete Tru64 UNIX V5.1B fixinclude support

2012-03-05 Thread Rainer Orth
Bruce Korb bk...@gnu.org writes:

 On 03/05/12 09:01, Rainer Orth wrote:
 This is where I need explicit approval and/or guidance:

 * There are some fixincludes hacks that from their names seem to be
osf-specific, but are not restricted to alpha*-dec-osf*.  Bruce,
what's the best way to handle those?  Disable them e.g. with a mach
clause like unused-alpha*-dec-osf* and see if anything else breaks?

 I think the right way is to require that all ports have a maintenance
 person build the thing at least once a year for all supported platforms.

 For such maintenance builds, I can trivially emit a list of hacks that
 got triggered during the build.  Any hacks that don't show up in the
 list for a couple of years get marked as obsolete and trigger a build
 warning.  If nobody complains about the warning, then its gone.
 Shouldn't take more than 3 or 4 years of disuse to get rid of the cruft. :)

 How's that for an approach?

Sounds like a good approach, since it helps even for hacks with mach
clauses that are matched on supported target version, e.g. a
*-*-solaris2* hack that only applies to Solaris 2.5 and is thus
irrelevant nowadays.

Rainer

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


Re: [PATCH, i386] RTM support

2012-03-05 Thread Uros Bizjak
On Mon, Mar 5, 2012 at 6:12 PM, Andi Kleen a...@firstfloor.org wrote:
 On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
 Adding patch

 I would still remove the -mrtm option. I never understood what options
 for intrinsics are good for. They are just a pain to add to Makefiles,
 but don't give any benefit.

Without -mrtm, the test will just emit a call to
__builtin_ia32_xbegin, for instance. You would ge linking error from
your app.

And the reason to have -mXXX flags is quite obvious. You don't want
combiner to optimize the sequence of two supported instructions (SSE
level X, for example) to an unsupported one (SSE level X+N) that
implements the same functionality. The same goes for integer
instructions, but less obvious ;)

So, I'm afraid that -mXXX options stay. But you can sprinkle target
option pragmas around the code now.

Uros.


Re: C++ PATCH for c++/51930 (instantiation hidden despite visibility attribute)

2012-03-05 Thread Jason Merrill
While looking at the class variant of this issue, I noticed that some of 
the code in determine_visibility was wrong; template_class_depth only 
considers unbound template parameters, and the number we want is the 
total number of levels.  I've also adjusted the diagnostic for misplaced 
class attributes as manu requested.


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


Re: C++ PATCH for c++/51930 (instantiation hidden despite visibility attribute)

2012-03-05 Thread Jason Merrill

On 03/05/2012 01:05 PM, Jason Merrill wrote:

While looking at the class variant of this issue, I noticed that some of
the code in determine_visibility was wrong; template_class_depth only
considers unbound template parameters, and the number we want is the
total number of levels. I've also adjusted the diagnostic for misplaced
class attributes as manu requested.

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


...and here's the patch.
commit b3b1728e0f4f9d565b33f7d8c07f64b60d3503fe
Author: Jason Merrill ja...@redhat.com
Date:   Tue Feb 14 17:36:48 2012 -0800

	PR c++/51930
	* decl2.c (determine_visibility): Correct calculation of class
	args depth.
	* decl.c (check_tag_decl): Adjust warning.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index c47f87c..a18b312 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4216,17 +4216,20 @@ check_tag_decl (cp_decl_specifier_seq *declspecs)
 error (%constexpr% cannot be used for type declarations);
 }
 
-  if (declspecs-attributes)
+  if (declspecs-attributes  warn_attributes)
 {
-  location_t loc = input_location;
+  location_t loc;
   if (!CLASSTYPE_TEMPLATE_INSTANTIATION (declared_type))
-	/* For a non-template class, use the name location; for a template
-	   class (an explicit instantiation), use the current location.  */
-	input_location = location_of (declared_type);
-  warning (0, attribute ignored in declaration of %q#T, declared_type);
-  warning (0, attribute for %q#T must follow the %qs keyword,
-	   declared_type, class_key_or_enum_as_string (declared_type));
-  input_location = loc;
+	/* For a non-template class, use the name location.  */
+	loc = location_of (declared_type);
+  else
+	/* For a template class (an explicit instantiation), use the
+	   current location.  */
+	loc = input_location;
+  warning_at (loc, OPT_Wattributes, attribute ignored in declaration 
+		  of %q#T, declared_type);
+  inform (loc, attribute for %q#T must follow the %qs keyword,
+	  declared_type, class_key_or_enum_as_string (declared_type));
 }
 
   return declared_type;
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index bdc962a..7eccf67 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -2181,12 +2181,8 @@ determine_visibility (tree decl)
 		  ? TYPE_ATTRIBUTES (TREE_TYPE (decl))
 		  : DECL_ATTRIBUTES (decl));
   
-  if (args != error_mark_node
-	  /* Template argument visibility outweighs #pragma or namespace
-	 visibility, but not an explicit attribute.  */
-	   !lookup_attribute (visibility, attribs))
+  if (args != error_mark_node)
 	{
-	  int depth = TMPL_ARGS_DEPTH (args);
 	  tree pattern = DECL_TEMPLATE_RESULT (TI_TEMPLATE (tinfo));
 
 	  if (!DECL_VISIBILITY_SPECIFIED (decl))
@@ -2202,10 +2198,31 @@ determine_visibility (tree decl)
 		}
 	}
 
-	  /* FIXME should TMPL_ARGS_DEPTH really return 1 for null input? */
-	  if (args  depth  template_class_depth (class_type))
-	/* Limit visibility based on its template arguments.  */
-	constrain_visibility_for_template (decl, args);
+	  if (args
+	  /* Template argument visibility outweighs #pragma or namespace
+		 visibility, but not an explicit attribute.  */
+	   !lookup_attribute (visibility, attribs))
+	{
+	  int depth = TMPL_ARGS_DEPTH (args);
+	  int class_depth = 0;
+	  if (class_type  CLASSTYPE_TEMPLATE_INFO (class_type))
+		class_depth = TMPL_ARGS_DEPTH (CLASSTYPE_TI_ARGS (class_type));
+	  if (DECL_VISIBILITY_SPECIFIED (decl))
+		{
+		  /* A class template member with explicit visibility
+		 overrides the class visibility, so we need to apply
+		 all the levels of template args directly.  */
+		  int i;
+		  for (i = 1; i = depth; ++i)
+		{
+		  tree lev = TMPL_ARGS_LEVEL (args, i);
+		  constrain_visibility_for_template (decl, lev);
+		}
+		}
+	  else if (depth  class_depth)
+		/* Limit visibility based on its template arguments.  */
+		constrain_visibility_for_template (decl, args);
+	}
 	}
 }
 
diff --git a/gcc/testsuite/g++.dg/ext/visibility/template11.C b/gcc/testsuite/g++.dg/ext/visibility/template11.C
new file mode 100644
index 000..fb47fe2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/visibility/template11.C
@@ -0,0 +1,20 @@
+// PR c++/51930
+// { dg-require-visibility  }
+// { dg-options -fvisibility=hidden }
+// { dg-final { scan-not-hidden _ZN13template_testI4testE8functionEv } }
+
+struct test { };
+
+templatetypename T
+struct template_test
+{
+  __attribute__((visibility(default)))
+  void function();
+};
+
+templatetypename T
+void template_testT::function() { }
+
+template
+struct __attribute__((visibility(default)))
+template_testtest;


C++ PATCH to exception-specification of implicitly declared constructors

2012-03-05 Thread Jason Merrill
In a defaulted constructor, the destructors used for subobject cleanups 
affect whether or not the constructor is deleted.  But discussion in 
Kona pointed out that they should not affect the 
exception-specification, since if one of those cleanups throws an 
exception then it's a double-fault, and we call terminate.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit e5c23605aabc4b96d32facb9d13d469ac3997542
Author: Jason Merrill ja...@redhat.com
Date:   Thu Feb 9 10:34:26 2012 -1000

	* method.c (synthesized_method_walk): Cleanups don't affect the EH
	spec either.

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index cf2a713..0718916 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1272,8 +1272,11 @@ synthesized_method_walk (tree ctype, special_function_kind sfk, bool const_p,
 	  rval = locate_fn_flags (base_binfo, complete_dtor_identifier,
   NULL_TREE, flags, complain);
 	  /* Note that we don't pass down trivial_p; the subobject
-	 destructors don't affect triviality of the constructor.  */
-	  process_subob_fn (rval, false, spec_p, NULL,
+	 destructors don't affect triviality of the constructor.  Nor
+	 do they affect constexpr-ness (a constant expression doesn't
+	 throw) or exception-specification (a throw from one of the
+	 dtors would be a double-fault).  */
+	  process_subob_fn (rval, false, NULL, NULL,
 			deleted_p, NULL, NULL,
 			basetype);
 	}
diff --git a/gcc/testsuite/g++.dg/cpp0x/implicit13.C b/gcc/testsuite/g++.dg/cpp0x/implicit13.C
new file mode 100644
index 000..96bc770
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/implicit13.C
@@ -0,0 +1,24 @@
+// Make sure that A's destructor doesn't affect constexpr
+// or exception-spec on D's default constructor.
+// { dg-do compile { target c++11 } }
+
+struct A {
+  constexpr A() noexcept: i(0) { }
+  int i;
+  ~A() noexcept(false);
+};
+
+struct B: A { };
+
+// Should get static initialization, so no constructor call.
+// { dg-final { scan-assembler-not _ZN1BC1Ev } }
+B b;
+
+struct C { C() noexcept; ~C(); };
+struct D: C { };
+extern D d;
+
+void *operator new(__SIZE_TYPE__, void*) noexcept;
+
+#define SA(X) static_assert((X),#X)
+SA(noexcept(new (d) D));


Re: [patch] fix memory corruption bug in tm_region_init

2012-03-05 Thread Aldy Hernandez

On 03/05/12 11:16, Richard Henderson wrote:

On 03/05/2012 08:54 AM, Aldy Hernandez wrote:

region_worklist =
  (struct tm_region **) xcalloc (sizeof (struct tm_region *),
- n_basic_blocks + NUM_FIXED_BLOCKS + 2);
+ last_basic_block + NUM_FIXED_BLOCKS);


This is ok.

I was confused for a moment by the worklist variable name, which
suggests a queue.  I'd also suggest that you change to use a vec,
rather than callocing yourself, and would have caught the memory
error earlier.


r~


I thought there'd be a lot less overhead by callocing the value myself. 
 Is the overhead negligible?


I can certainly make it a VEC in a follow up patch if you want, though 
I'll commit this now so I can at get Rainer and Torvald happy while I do so.


Aldy


Re: [patch] fix memory corruption bug in tm_region_init

2012-03-05 Thread Aldy Hernandez

On 03/05/12 11:08, Rainer Orth wrote:

Aldy Hernandezal...@redhat.com  writes:


Torvald has a testcase from the STAMP benchmark that is showing a memory
corruption error after my fix to publication safety problems.

The problem is we're allocating a chunk of worklist memory of size
n_basic_blocks which changes with tail merge optimization and such.  We end
up with a smaller n_basic_blocks than some of the BB's left in the region.
I believe what we want is last_basic_block.

This fixes the memory corruption bug.  I couldn't minimize a sensible
testcase.


Could this be PR middle-end/52463 libitm.c/memcpy-1.c FAILs?

Rainer



Yes, fixed and closed.


[lra] a patch to fix a live-range splitting problem in EBB

2012-03-05 Thread Vladimir Makarov
On some targets in rare cases, LRA can put a live-range splitting insn 
right after a jump insn setting up the split pseudo.  The following 
patch fixes the problem by putting such insn at the beginning of next BB.


The patch was successfully bootstrapped on x86/x86-64.

Committed as rev. 184942.

2012-03-05  Vladimir Makarov vmaka...@redhat.com

* lra-constraints.c (simplify_operand_subreg): Treat out subreg
operand which is a part of the pseudo as in/out one.
(get_live_on_other_edges): Move lower and add non-input operands
of jump to the bitmap.

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 184749)
+++ lra-constraints.c   (working copy)
@@ -1371,7 +1371,8 @@ simplify_operand_subreg (int nop, enum m
= (enum reg_class) targetm.preferred_reload_class (reg, ALL_REGS);
 
   if (get_reload_reg (type, reg_mode, reg, rclass, subreg reg, new_reg)
-  type != OP_OUT)
+  (type != OP_OUT
+ || GET_MODE_SIZE (GET_MODE (reg))  GET_MODE_SIZE (mode)))
{
  push_to_sequence (before);
  lra_emit_move (new_reg, reg);
@@ -4214,21 +4215,6 @@ add_to_inherit (int regno, rtx insns)
   to_inherit[to_inherit_num++].insns = insns;
 }
 
-/* Set up RES by registers living on edges FROM except edege (FROM,
-   TO).  */
-static void
-get_live_on_other_edges (basic_block from, basic_block to, bitmap res)
-{
-  edge e;
-  edge_iterator ei;
-
-  gcc_assert (to != NULL);
-  bitmap_clear (res);
-  FOR_EACH_EDGE (e, ei, from-succs)
-if (e-dest != to)
-  bitmap_ior_into (res, DF_LR_IN (e-dest));
-}
-   
 /* Return first (if FIRST_P) or last non-debug insn in basic block BB.
Return null if there are no non-debug insns in the block.  */
 static rtx
@@ -4245,6 +4231,31 @@ get_non_debug_insn (bool first_p, basic_
   return insn;
 }
 
+/* Set up RES by registers living on edges FROM except edge (FROM, TO)
+   or by registers set up in a jump insn in BB FROM.  */
+static void
+get_live_on_other_edges (basic_block from, basic_block to, bitmap res)
+{
+  int regno;
+  rtx last;
+  struct lra_insn_reg *reg;
+  edge e;
+  edge_iterator ei;
+
+  gcc_assert (to != NULL);
+  bitmap_clear (res);
+  FOR_EACH_EDGE (e, ei, from-succs)
+if (e-dest != to)
+  bitmap_ior_into (res, DF_LR_IN (e-dest));
+  if ((last = get_non_debug_insn (false, from)) == NULL_RTX || ! JUMP_P (last))
+return;
+  curr_id = lra_get_insn_recog_data (last);
+  for (reg = curr_id-regs; reg != NULL; reg = reg-next)
+if (reg-type != OP_IN
+(regno = reg-regno) = FIRST_PSEUDO_REGISTER)
+  bitmap_set_bit (res, regno);
+}
+   
 /* Used as a temporary results of some bitmap calculations.  */
 static bitmap_head temp_bitmap;
 


[PATCH][target/52481] m68k-*: internal compiler error: in extract_insn, at recog.c:2123

2012-03-05 Thread Richard Henderson
 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-03-04 
 21:01:28 UTC ---
 Created attachment 26827
   -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26827
 reduced test case in C
 
 Depends on target CPU selection.  -mcpu=680[012346]0 and -mcpu=cpu32 all work,
 but -mcpu=5206 (or apparently any other coldfire) ICEs.

Indeed.  Fixed by not trying to use negqi2 directly, but going
through the normal expanders which will DTRT for coldfire.

Tested via cross-compile, committed to mainline and 4.7.


r~
PR target/52481
* config/m68k/sync.md (atomic_test_and_set): Use expand_simple_unop
instead of calling negqi2 directly.



diff --git a/gcc/config/m68k/sync.md b/gcc/config/m68k/sync.md
index 5d5002a..6c840f5 100644
--- a/gcc/config/m68k/sync.md
+++ b/gcc/config/m68k/sync.md
@@ -62,8 +62,11 @@
(match_operand:SI 2 const_int_operand )];; model
   
 {
-  emit_insn (gen_atomic_test_and_set_1 (operands[0], operands[1]));
-  emit_insn (gen_negqi2 (operands[0], operands[0]));
+  rtx t = gen_reg_rtx (QImode);
+  emit_insn (gen_atomic_test_and_set_1 (t, operands[1]));
+  t = expand_simple_unop (QImode, NEG, t, operands[0], 0);
+  if (t != operands[0])
+emit_move_insn (operands[0], t);
   DONE;
 })
 


Re: [PATCH, i386] RTM support

2012-03-05 Thread Andi Kleen
On Mon, Mar 05, 2012 at 07:04:47PM +0100, Uros Bizjak wrote:
 On Mon, Mar 5, 2012 at 6:12 PM, Andi Kleen a...@firstfloor.org wrote:
  On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
  Adding patch
 
  I would still remove the -mrtm option. I never understood what options
  for intrinsics are good for. They are just a pain to add to Makefiles,
  but don't give any benefit.
 
 Without -mrtm, the test will just emit a call to
 __builtin_ia32_xbegin, for instance. You would ge linking error from
 your app.

Disabling it for the __builtin_* too of course.
 
 And the reason to have -mXXX flags is quite obvious. You don't want
 combiner to optimize the sequence of two supported instructions (SSE
 level X, for example) to an unsupported one (SSE level X+N) that
 implements the same functionality. The same goes for integer
 instructions, but less obvious ;)

I don't think the compiler ever changes intrinsics into something else?
Especially not for RTM of course, but I also didn't think it applied
to any others?

The problem I have with the flag is that the typical use model is to 
have multiple code paths, like:

if (cpuid_has_rtm())
... do rtm ...
else
... do something else ...

So you have a basic block which needs RTM and another one which doesn't
want it.  If the flag would affect the code generation of the else block 
that would be bad.  So essentially the flag has to be a nop anyways 
except for the intrinsic itself.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.


Re: [patch] fix memory corruption bug in tm_region_init

2012-03-05 Thread Richard Henderson
On 03/05/2012 10:37 AM, Aldy Hernandez wrote:
 I thought there'd be a lot less overhead by callocing the value myself.  Is 
 the overhead negligible?

Yes, it's negligible.

 I can certainly make it a VEC in a follow up patch if you want, though I'll 
 commit this now so I can at get Rainer and Torvald happy while I do so.

Certainly.


r~


Re: [PATCH, i386] RTM support

2012-03-05 Thread Uros Bizjak
On Mon, Mar 5, 2012 at 7:47 PM, Andi Kleen a...@firstfloor.org wrote:

 The problem I have with the flag is that the typical use model is to
 have multiple code paths, like:

 if (cpuid_has_rtm())
    ... do rtm ...
 else
    ... do something else ...

 So you have a basic block which needs RTM and another one which doesn't
 want it.  If the flag would affect the code generation of the else block
 that would be bad.  So essentially the flag has to be a nop anyways
 except for the intrinsic itself.

As I said, you have target pragmas exactly for this problem:

if (cpuid_has_rtm())
#pragma GCC push_options
#pragma GCC target (rtm)
... do rtm ...
#pragma GCC pop_options
 else
... do something else ...

Removing -mrtm option would remove one point of control.

Uros.


Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1

2012-03-05 Thread Richard Henderson
On 03/04/2012 11:09 AM, Oleg Endo wrote:
 Richard, could you also please take the
 TARGET_ATOMIC_TEST_AND_SET_TRUEVAL hunk from this patch for the 4.7
 branch?

Done.  I've also moved the TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 
definition from sh.h to sh.c where it belongs.


r~


Re: [Patch,AVR]: Document -mmcu=avrxmega...

2012-03-05 Thread Georg-Johann Lay

Georg-Johann Lay schrieb:

This patch adds the documentation for -mmcu= for xmega cores that is still 
missing.

Moreover, there is some explanation of RAMP SFR usage.

Ok for the trunk and 4.7?


This patch is just for trunk, not for 4.7


Johann

* doc/invoke.texi (AVR Options): -mmcu=: Document the XMEGA cores.
Explain RAMPD, RAMPX, RAMPDY, RAMPZ usage by avr-gcc.
Some more notes on EIND usage and reorder EIND subsection.


Re: [PATCH, i386] RTM support

2012-03-05 Thread Andi Kleen
 Removing -mrtm option would remove one point of control.

If I use the intrinsics I can never remove it because it would just make the 
code not compile.

If I don't use the intrinsics I never need it in the first place.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.


Re: [PATCH, i386] RTM support

2012-03-05 Thread Uros Bizjak
On Mon, Mar 5, 2012 at 8:12 PM, Andi Kleen a...@firstfloor.org wrote:
 Removing -mrtm option would remove one point of control.

 If I use the intrinsics I can never remove it because it would just make the
 code not compile.

 If I don't use the intrinsics I never need it in the first place.

Aha, I see your point now.

IIUC, you are annoyed by:

+#ifndef __RTM__
+# error RTM instruction set not enabled
+#endif /* __RTM__ */

in the headers. Indeed, this prevents #pragma GCC target to be effective.

But OTOH, intrinsics are internally implemented using code sequences
that call various __builtin_* functions, so they require correct
target flags to be set when #included...

I doubt this can be fixed in any sensible way. Maybe by adding correct
#pragmas around header #include ?

Uros.


RE: [Patch,AVR]: Document -mmcu=avrxmega...

2012-03-05 Thread Weddington, Eric


 -Original Message-
 From: Georg-Johann Lay
 Sent: Monday, March 05, 2012 12:00 PM
 To: Georg-Johann Lay
 Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Weddington, Eric
 Subject: Re: [Patch,AVR]: Document -mmcu=avrxmega...
 
 Georg-Johann Lay schrieb:
  This patch adds the documentation for -mmcu= for xmega cores that is
still
 missing.
 
  Moreover, there is some explanation of RAMP SFR usage.
 
  Ok for the trunk and 4.7?
 
 This patch is just for trunk, not for 4.7
 
  Johann
 
  * doc/invoke.texi (AVR Options): -mmcu=: Document the XMEGA
cores.
  Explain RAMPD, RAMPX, RAMPDY, RAMPZ usage by avr-gcc.
  Some more notes on EIND usage and reorder EIND subsection.

Please commit.

Eric


[PR 52242] Re: atomic-2 failure on s390x

2012-03-05 Thread Richard Henderson
On 02/07/2012 12:12 AM, Andreas Krebbel wrote:
 Hi,
 
 I would like to get rid of the atomic-2 failure on s390x. What do you think 
 about my
 comments on the BIGGEST_ALIGNMENT check in omp-low.c?
 
 http://gcc.gnu.org/ml/gcc-patches/2012-02/msg9.html

I've reverted the patch in question, on 4.7 and mainline.

This solves the incorrect code generation problem for s390x
and re-introduces a testsuite failure on m68k.  The later is
not afaik a wrong-code problem, since in the m68k case we do
wrap the atomic operation in a lock.  The testsuite is not
expecting that, however.  One possible fix for the testsuite
is to add -malign-int to the options for those tests.

It is, arguably, an ABI problem for m68k to switch from using
a lock in gcc 4.6 to a CAS insn in gcc 4.7.  I had briefly
looked into using another target hook before I stumbled across
this issue.  The better part of valour says leave it alone...



r~
PR tree-opt/52242
Revert: 2011-11-26  Richard Henderson  r...@redhat.com
* omp-low.c (expand_omp_atomic): Assume anything aligned to
BIGGEST_ALIGNMENT is aligned.

 
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index db71594..82ca4fd 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -5504,9 +5504,7 @@ expand_omp_atomic (struct omp_region *region)
   unsigned int align = TYPE_ALIGN_UNIT (type);
 
   /* __sync builtins require strict data alignment.  */
-  /* ??? Assume BIGGEST_ALIGNMENT *is* aligned.  */
-  if (exact_log2 (align) = index
- || align * BITS_PER_UNIT = BIGGEST_ALIGNMENT)
+  if (exact_log2 (align) = index)
{
  /* Atomic load.  */
  if (loaded_val == stored_val


Re: Patch ping

2012-03-05 Thread Richard Henderson
On 03/05/2012 03:08 AM, Jakub Jelinek wrote:
 - PR51902 dwarf2out .debug_ranges ~ 22% reduction
   http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01171.html

Ok.


r~



[patch] PR 51417

2012-03-05 Thread Ralf Corsépius

Hi,

The patch below addresses an issue with gcc-4.7.0 the issue I had 
reported in

http://gcc.gnu.org/ml/gcc/2012-03/msg00035.html

and somebody else had bz'ed as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417

Tested by cross-building gcc-4_7-branch for several *rtems targets on 
Fedora 16. Further test-builds are in progress.


No native build-testing, yet.

OK to apply?

Ralf

2012-03-05  Ralf Corsépius  ralf.corsep...@rtems.org

	PR target/51417
	* Makefile.in: Let install-gcc-ar depend on installdirs, gcc-ar$(exeext),
	gcc-nm$(exeext), gcc-ranlib$(exeext).
	Don't double canonicalize if cross-compiling.


diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index f6cf8ff..2319cab 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -4811,20 +4811,18 @@ install-collect2: collect2 installdirs
 install-lto-wrapper: lto-wrapper$(exeext)
 	$(INSTALL_PROGRAM) lto-wrapper$(exeext) $(DESTDIR)$(libexecsubdir)/lto-wrapper$(exeext)
 
-install-gcc-ar:
-	set -e ; \
-	for i in ar nm ranlib ; do \
-	  install_name=`echo gcc-$$i|sed '$(program_transform_name)'`$(exeext) ;\
-	  target_install_name=$(target_noncanonical)-`echo gcc-$$i|sed '$(program_transform_name)'`$(exeext) ; \
-	  binname=gcc-$$i$(exeext) ; \
-	  rm -f $(DESTDIR)$(bindir)/$$install_name ; \
-	  rm -f $(DESTDIR)$(bindir)/$$target_install_name ; \
-	  $(INSTALL_PROGRAM) $$binname $(DESTDIR)$(bindir)/$$install_name ;\
-	  if test -f $(DESTDIR)$(bindir)$$target_install_name ; then \
+install-gcc-ar: installdirs gcc-ar$(exeext) gcc-nm$(exeext) gcc-ranlib$(exeext)
+	for i in gcc-ar gcc-nm gcc-ranlib; do \
+	  install_name=`echo $$i|sed '$(program_transform_name)'` ;\
+	  target_install_name=$(target_noncanonical)-`echo $$i|sed '$(program_transform_name)'` ; \
+	  rm -f $(DESTDIR)$(bindir)/$$install_name$(exeext) ; \
+	  $(INSTALL_PROGRAM) $$i$(exeext) $(DESTDIR)$(bindir)/$$install_name$(exeext) ;\
+	  if test -f gcc-cross$(exeext); then \
 	:; \
 	  else \
+	rm -f $(DESTDIR)$(bindir)/$$target_install_name$(exeext); \
 	( cd $(DESTDIR)$(bindir)  \
-	  $(LN) $$install_name $$target_install_name ) ; \
+	  $(LN) $$install_name$(exeext) $$target_install_name$(exeext) ) ; \
 	  fi ; \
 	done
 


Re: [PATCH, i386] RTM support

2012-03-05 Thread Andi Kleen
 IIUC, you are annoyed by:
 
 +#ifndef __RTM__
 +# error RTM instruction set not enabled
 +#endif /* __RTM__ */

That, yes, but also

(and see PR44987)

 
 in the headers. Indeed, this prevents #pragma GCC target to be effective.
 
 But OTOH, intrinsics are internally implemented using code sequences
 that call various __builtin_* functions, so they require correct
 target flags to be set when #included...

... also I'm arguing to remove the target flags for the intrinsics, 
because they are not useful for things that the compiler doesn't 
auto generate on its own.

 
 I doubt this can be fixed in any sensible way. Maybe by adding correct
 #pragmas around header #include ?

That doesn't set the defines. I did it before, but it's extremly ugly.
In the end I just gave up and used inline assembler.

-Andi


C++ PATCH to objc-map.c to fix build with --enable-gather-detailed-mem-stats

2012-03-05 Thread Jason Merrill
objc-map.c has been calling _stat allocation functions without using 
MEM_STAT_INFO for passing the file location information to the 
allocator, which breaks bootstrap with 
--enable-gather-detailed-mem-stats.  Fixed by calling the non-_stat 
variant instead.


Applying as obvious.
commit c70308c0c323642d823af0c4e7a6ed5e320b499f
Author: Jason Merrill ja...@redhat.com
Date:   Mon Mar 5 16:12:13 2012 -0500

	* objc-map.c (objc_map_private_resize, objc_map_alloc_ggc): Don't
	call _stat functions without MEM_STAT_INFO.

diff --git a/gcc/objc/objc-map.c b/gcc/objc/objc-map.c
index 77a98c1..a4a1eec 100644
--- a/gcc/objc/objc-map.c
+++ b/gcc/objc/objc-map.c
@@ -56,7 +56,7 @@ next_power_of_two (size_t x)
 objc_map_t
 objc_map_alloc_ggc (size_t initial_capacity)
 {
-  objc_map_t map = (objc_map_t) ggc_internal_cleared_vec_alloc_stat (1, sizeof (struct objc_map_private));
+  objc_map_t map = (objc_map_t) ggc_internal_cleared_vec_alloc (1, sizeof (struct objc_map_private));
   if (map == NULL)
 OUT_OF_MEMORY;
   
@@ -67,8 +67,8 @@ objc_map_alloc_ggc (size_t initial_capacity)
   map-maximum_load_factor = 70;
   map-max_number_of_non_empty_slots = (initial_capacity * map-maximum_load_factor) / 100;
 
-  map-slots = (tree *)ggc_internal_cleared_vec_alloc_stat (initial_capacity, sizeof (tree));
-  map-values = (tree *)ggc_internal_cleared_vec_alloc_stat (initial_capacity, sizeof (tree));
+  map-slots = (tree *)ggc_internal_cleared_vec_alloc (initial_capacity, sizeof (tree));
+  map-values = (tree *)ggc_internal_cleared_vec_alloc (initial_capacity, sizeof (tree));
 
   if (map-slots == NULL)
 OUT_OF_MEMORY;
@@ -112,8 +112,8 @@ objc_map_private_resize (objc_map_t map, size_t new_number_of_slots)
   map-max_number_of_non_empty_slots = (map-number_of_slots * map-maximum_load_factor) / 100;
 
 
-  map-slots = (tree *)ggc_internal_cleared_vec_alloc_stat (map-number_of_slots, sizeof (tree));
-  map-values = (tree *)ggc_internal_cleared_vec_alloc_stat (map-number_of_slots, sizeof (tree));
+  map-slots = (tree *)ggc_internal_cleared_vec_alloc (map-number_of_slots, sizeof (tree));
+  map-values = (tree *)ggc_internal_cleared_vec_alloc (map-number_of_slots, sizeof (tree));
 
   if (map-slots == NULL)
 OUT_OF_MEMORY;


Re: C++ PATCH to objc-map.c to fix build with --enable-gather-detailed-mem-stats

2012-03-05 Thread Jason Merrill

Er, not actually a C++ patch.  Fingers on autopilot...


PATCH to ada/gcc-interface/Make-lang.in to fix build issues

2012-03-05 Thread Jason Merrill
Rebuilding gcc was failing for me because the rule for gnat_ugn.texi was 
trying to use xgnatugn before it had been built.  Fixed by making it 
directly, like the rule for projects.texi.


OK for trunk?
commit 2ad07fd7f293027ed3f779fc0d7e79b58a4b7e2a
Author: Jason Merrill ja...@redhat.com
Date:   Mon Mar 5 16:05:23 2012 -0500

	* gcc-interface/Make-lang.in (doc/gnat_ugn.texi): Build xgnatugn
	before using it.

diff --git a/gcc/ada/gcc-interface/Make-lang.in b/gcc/ada/gcc-interface/Make-lang.in
index 06a8803..8a2f346 100644
--- a/gcc/ada/gcc-interface/Make-lang.in
+++ b/gcc/ada/gcc-interface/Make-lang.in
@@ -667,6 +667,7 @@ ada/doctools/xgnatugn$(build_exeext): ada/xgnatugn.adb
 
 doc/gnat_ugn.texi: $(srcdir)/ada/gnat_ugn.texi $(srcdir)/ada/ug_words \
doc/projects.texi $(gcc_docdir)/include/gcc-common.texi gcc-vers.texi
+	$(MAKE) ada/doctools/xgnatugn$(build_exeext)
 	ada/doctools/xgnatugn unw $(srcdir)/ada/gnat_ugn.texi \
 	   $(srcdir)/ada/ug_words doc/gnat_ugn.texi
 


[RFC PATCH]: Handle Pmode == SImode in stringop patterns

2012-03-05 Thread Uros Bizjak
Hello!

Attached RFC patch enhances stringop patterns to emit addr32 prefix
when Pmode == SImode. I have introduced %^ operand modifier that
conditionally emits addr32 to all stringop insn templates.

H.J., can you please test the patch if it works OK on SImode X32
target? I have tested it on x86_64-pc-linux-gnu {,-m32}, but I can't
test anything else than that it doesn't break compilation and
regression tests.

Thanks,
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 184959)
+++ config/i386/i386.c  (working copy)
@@ -13742,6 +13748,7 @@ get_some_local_dynamic_name (void)
; -- print a semicolon (after prefixes due to bug in older gas).
~ -- print i if TARGET_AVX2, f otherwise.
@ -- print a segment register of thread base pointer load
+   ^ -- print addr32 address prefix if TARGET_64BIT and Pmode == SImode
  */
 
 void
@@ -14247,6 +14254,19 @@ ix86_print_operand (FILE *file, rtx x, int code)
  putc (TARGET_AVX2 ? 'i' : 'f', file);
  return;
 
+   case '^':
+ if (TARGET_64BIT  Pmode == SImode)
+   {
+ fputs (addr32, file);
+#ifndef HAVE_AS_IX86_REP_LOCK_PREFIX
+ if (ASSEMBLER_DIALECT == ASM_ATT)
+   fputs (addr32; , file);
+ else
+#endif
+   fputs (addr32 , file);
+   }
+ return;
+
default:
output_operand_lossage (invalid operand code '%c', code);
}
@@ -14386,8 +14406,8 @@ ix86_print_operand (FILE *file, rtx x, int code)
 static bool
 ix86_print_operand_punct_valid_p (unsigned char code)
 {
-  return (code == '@' || code == '*' || code == '+'
- || code == '' || code == ';' || code == '~');
+  return (code == '@' || code == '*' || code == '+' || code == ''
+ || code == ';' || code == '~' || code == '^');
 }
 
 /* Print a memory operand whose address is ADDR.  */
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 184959)
+++ config/i386/i386.md (working copy)
@@ -60,7 +60,9 @@
 ;; Y -- print condition for XOP pcom* instruction.
 ;; + -- print a branch hint as 'cs' or 'ds' prefix
 ;; ; -- print a semicolon (after prefixes due to bug in older gas).
+;; ~ -- print i if TARGET_AVX2, f otherwise.
 ;; @ -- print a segment register of thread base pointer load
+;; ^ -- print addr32 address prefix if TARGET_64BIT and Pmode == SImode
 
 (define_c_enum unspec [
   ;; Relocation specifiers
@@ -15678,17 +15687,17 @@
   ix86_current_function_needs_cld = 1;)
 
 (define_insn *strmovdi_rex_1
-  [(set (mem:DI (match_operand:DI 2 register_operand 0))
-   (mem:DI (match_operand:DI 3 register_operand 1)))
-   (set (match_operand:DI 0 register_operand =D)
-   (plus:DI (match_dup 2)
-(const_int 8)))
-   (set (match_operand:DI 1 register_operand =S)
-   (plus:DI (match_dup 3)
-(const_int 8)))]
+  [(set (mem:DI (match_operand:P 2 register_operand 0))
+   (mem:DI (match_operand:P 3 register_operand 1)))
+   (set (match_operand:P 0 register_operand =D)
+   (plus:P (match_dup 2)
+   (const_int 8)))
+   (set (match_operand:P 1 register_operand =S)
+   (plus:P (match_dup 3)
+   (const_int 8)))]
   TARGET_64BIT
 !(fixed_regs[SI_REG] || fixed_regs[DI_REG])
-  movsq
+  %^movsq
   [(set_attr type str)
(set_attr memory both)
(set_attr mode DI)])
@@ -15703,7 +15712,7 @@
(plus:P (match_dup 3)
(const_int 4)))]
   !(fixed_regs[SI_REG] || fixed_regs[DI_REG])
-  movs{l|d}
+  %^movs{l|d}
   [(set_attr type str)
(set_attr memory both)
(set_attr mode SI)])
@@ -15718,7 +15727,7 @@
(plus:P (match_dup 3)
(const_int 2)))]
   !(fixed_regs[SI_REG] || fixed_regs[DI_REG])
-  movsw
+  %^movsw
   [(set_attr type str)
(set_attr memory both)
(set_attr mode HI)])
@@ -15733,7 +15742,7 @@
(plus:P (match_dup 3)
(const_int 1)))]
   !(fixed_regs[SI_REG] || fixed_regs[DI_REG])
-  movsb
+  %^movsb
   [(set_attr type str)
(set_attr memory both)
(set (attr prefix_rex)
@@ -15756,20 +15765,20 @@
   ix86_current_function_needs_cld = 1;)
 
 (define_insn *rep_movdi_rex64
-  [(set (match_operand:DI 2 register_operand =c) (const_int 0))
-   (set (match_operand:DI 0 register_operand =D)
-(plus:DI (ashift:DI (match_operand:DI 5 register_operand 2)
-   (const_int 3))
-(match_operand:DI 3 register_operand 0)))
-   (set (match_operand:DI 1 register_operand =S)
-(plus:DI (ashift:DI (match_dup 5) (const_int 3))
-(match_operand:DI 4 register_operand 1)))
+  [(set (match_operand:P 2 register_operand =c) (const_int 0))
+   (set (match_operand:P 0 register_operand =D)
+(plus:P (ashift:P (match_operand:P 5 register_operand 2)
+ (const_int 3))
+   (match_operand:P 3 

Re: [RFC PATCH]: Handle Pmode == SImode in stringop patterns

2012-03-05 Thread Jakub Jelinek
On Mon, Mar 05, 2012 at 10:33:19PM +0100, Uros Bizjak wrote:
 + case '^':
 +   if (TARGET_64BIT  Pmode == SImode)
 + {
 +   fputs (addr32, file);
 +#ifndef HAVE_AS_IX86_REP_LOCK_PREFIX
 +   if (ASSEMBLER_DIALECT == ASM_ATT)
 + fputs (addr32; , file);
 +   else
 +#endif
 + fputs (addr32 , file);
 + }

Why do you print addr32 twice? addr32addr32;  or addr32addr32 .

Jakub


[patch] Clean up some lang_hooks pushdecl uses in the back ends

2012-03-05 Thread Steven Bosscher
Hello,

This is a simple cleanup that introduces a new function
add_builtin_type and uses it in the mep and rs6000 back ends.

Bootstrapped and tested on powerpc64-unknown-linux-gnu (gcc110) and
verified that a cross to mep builds.
OK for trunk?

Ciao!
Steven

* langhooks.c (add_builtin_type): New function.
* langhooks.h (add_builtin_type): Export it.
* config/mep/mep.c (mep_init_builtins): Use it.
* config/rs6000/rs6000.c (rs6000_init_builtins): Use it.
* langhooks.c (add_builtin_type): New function.
* langhooks.h (add_builtin_type): Export it.
* config/mep/mep.c (mep_init_builtins): Use it.
* config/rs6000/rs6000.c (rs6000_init_builtins): Use it.

Index: langhooks.c
===
*** langhooks.c (revision 184954)
--- langhooks.c (working copy)
*** lhd_builtin_function (tree decl)
*** 605,610 
--- 605,620 
return decl;
  }
  
+ /* Create a builtin type.  */
+ 
+ tree
+ add_builtin_type (const char *name, tree type)
+ {
+   tree   id = get_identifier (name);
+   tree decl = build_decl (BUILTINS_LOCATION, TYPE_DECL, id, type);
+   return lang_hooks.decls.pushdecl (decl);
+ }
+ 
  /* LTO hooks.  */
  
  /* Used to save and restore any previously active section.  */
Index: langhooks.h
===
*** langhooks.h (revision 184954)
--- langhooks.h (working copy)
*** struct lang_hooks
*** 479,484 
--- 479,485 
  
  /* Each front end provides its own.  */
  extern struct lang_hooks lang_hooks;
+ 
  extern tree add_builtin_function (const char *name, tree type,
  int function_code, enum built_in_class cl,
  const char *library_name,
*** extern tree add_builtin_function_ext_sco
*** 489,493 
enum built_in_class cl,
const char *library_name,
tree attrs);
! 
  #endif /* GCC_LANG_HOOKS_H */
--- 490,495 
enum built_in_class cl,
const char *library_name,
tree attrs);
! extern tree add_builtin_type (const char *name, tree type);
!  
  #endif /* GCC_LANG_HOOKS_H */
Index: config/mep/mep.c
===
*** config/mep/mep.c(revision 184954)
--- config/mep/mep.c(working copy)
*** mep_init_builtins (void)
*** 6059,6091 
v4uhi_type_node = build_vector_type (unsigned_intHI_type_node, 4);
v2usi_type_node = build_vector_type (unsigned_intSI_type_node, 2);
  
!   (*lang_hooks.decls.pushdecl)
! (build_decl (BUILTINS_LOCATION, TYPE_DECL, get_identifier 
(cp_data_bus_int),
!cp_data_bus_int_type_node));
! 
!   (*lang_hooks.decls.pushdecl)
! (build_decl (BUILTINS_LOCATION, TYPE_DECL, get_identifier (cp_vector),
!opaque_vector_type_node));
! 
!   (*lang_hooks.decls.pushdecl)
! (build_decl (BUILTINS_LOCATION, TYPE_DECL, get_identifier (cp_v8qi),
!v8qi_type_node));
!   (*lang_hooks.decls.pushdecl)
! (build_decl (BUILTINS_LOCATION, TYPE_DECL, get_identifier (cp_v4hi),
!v4hi_type_node));
!   (*lang_hooks.decls.pushdecl)
! (build_decl (BUILTINS_LOCATION, TYPE_DECL, get_identifier (cp_v2si),
!v2si_type_node));
! 
!   (*lang_hooks.decls.pushdecl)
! (build_decl (BUILTINS_LOCATION, TYPE_DECL, get_identifier (cp_v8uqi),
!v8uqi_type_node));
!   (*lang_hooks.decls.pushdecl)
! (build_decl (BUILTINS_LOCATION, TYPE_DECL, get_identifier (cp_v4uhi),
!v4uhi_type_node));
!   (*lang_hooks.decls.pushdecl)
! (build_decl (BUILTINS_LOCATION, TYPE_DECL, get_identifier (cp_v2usi),
!v2usi_type_node));
  
/* Intrinsics like mep_cadd3 are implemented with two groups of
   instructions, one which uses UNSPECs and one which uses a specific
--- 6059,6075 
v4uhi_type_node = build_vector_type (unsigned_intHI_type_node, 4);
v2usi_type_node = build_vector_type (unsigned_intSI_type_node, 2);
  
!   add_builtin_type (cp_data_bus_int, cp_data_bus_int_type_node);
! 
!   add_builtin_type (cp_vector, opaque_vector_type_node);
! 
!   add_builtin_type (cp_v8qi, v8qi_type_node);
!   add_builtin_type (cp_v4hi, v4hi_type_node);
!   add_builtin_type (cp_v2si, v2si_type_node);
! 
!   add_builtin_type (cp_v8uqi, v8uqi_type_node);
!   add_builtin_type (cp_v4uhi, v4uhi_type_node);
!   add_builtin_type (cp_v2usi, v2usi_type_node);
  
/* Intrinsics like mep_cadd3 are implemented with two groups of
   instructions, one which uses UNSPECs and one which uses a specific
Index: config/rs6000/rs6000.c
===

Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1

2012-03-05 Thread Oleg Endo
On Mon, 2012-03-05 at 11:00 -0800, Richard Henderson wrote:
 On 03/04/2012 11:09 AM, Oleg Endo wrote:
  Richard, could you also please take the
  TARGET_ATOMIC_TEST_AND_SET_TRUEVAL hunk from this patch for the 4.7
  branch?
 
 Done.  

Thanks!

 I've also moved the TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 
 definition from sh.h to sh.c where it belongs.

Yeah, however, I'm also using the value behind
TARGET_ATOMIC_TEST_AND_SET_TRUEVAL in sync.md.  If it's in sh.c it
doesn't work.  That's why I left it in sh.h.

Cheers,
Oleg



Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1

2012-03-05 Thread Richard Henderson
On 03/05/2012 01:44 PM, Oleg Endo wrote:
 Yeah, however, I'm also using the value behind
 TARGET_ATOMIC_TEST_AND_SET_TRUEVAL in sync.md.  If it's in sh.c it
 doesn't work.  That's why I left it in sh.h.

That value should be available via targetm.atomic_test_and_set_trueval.


r~


Re: [patch] Clean up some lang_hooks pushdecl uses in the back ends

2012-03-05 Thread Richard Henderson
On 03/05/2012 01:43 PM, Steven Bosscher wrote:
 * langhooks.c (add_builtin_type): New function.
 * langhooks.h (add_builtin_type): Export it.
 * config/mep/mep.c (mep_init_builtins): Use it.
 * config/rs6000/rs6000.c (rs6000_init_builtins): Use it.

Ok.


r~


Re: [RFC PATCH]: Handle Pmode == SImode in stringop patterns

2012-03-05 Thread Uros Bizjak
On Mon, Mar 5, 2012 at 10:42 PM, Jakub Jelinek ja...@redhat.com wrote:

 On Mon, Mar 05, 2012 at 10:33:19PM +0100, Uros Bizjak wrote:
 +     case '^':
 +       if (TARGET_64BIT  Pmode == SImode)
 +         {
 +           fputs (addr32, file);
 +#ifndef HAVE_AS_IX86_REP_LOCK_PREFIX
 +           if (ASSEMBLER_DIALECT == ASM_ATT)
 +             fputs (addr32; , file);
 +           else
 +#endif
 +             fputs (addr32 , file);
 +         }

 Why do you print addr32 twice? addr32addr32;  or addr32addr32 .

Oops, please remove the first one.

Thanks,
Uros.


  1   2   >