RFA (layout): PATCH for c++/48029 (ICE-on-valid with templates and arrays)

[Jason Merrill]

In this testcase, when we first declare the myvectypes and mytype3, 
vector has not been instantiated, so we mark the array, and the 
pointer to the array, for structural equality comparison.  When we 
actually go to instantiate mytype3, we complete vector and 
rebuild the array and pointer types, and use those to look up the 
template specialization.  Which fails to find the one we already had 
because the new pointer type has TYPE_CANONICAL and therefore hashes

differently from the one that didn't.

We deal with ARRAY_TYPE specially in iterative_hash_template_arg, but 
that doesn't cover a compound type which uses an ARRAY_TYPE, such as the 
pointer in this case.


The business of having an array with the same element type and domain 
have different TYPE_CANONICAL dependending on whether or not the element 
type is complete has always seemed strange and fragile to me, so I tried 
removing the relevant code from layout_type; this produced only a single 
test failure, which was fixed by changing type_hash_eq to not trust 
TYPE_ALIGN if the type isn't complete yet.  I imagine that's what Doug 
was talking about in his comment about alignment.


Tested (c,c++,fortran,java,lto,objc) x86_64-pc-linux-gnu.  OK for 4.5 
and 4.6?
commit 45deb1cd5953c5730e14e00c5a8f800dadea66bd
Author: Jason Merrill 
Date:   Wed Mar 9 16:47:10 2011 -0500

PR c++/48029
* stor-layout.c (layout_type): Don't set structural equality
on arrays of incomplete type.
* tree.c (type_hash_eq): Handle comparing them properly.
* cp/pt.c (iterative_hash_template_arg): Remove special case for
ARRAY_TYPE.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ac91698..ab2aea3 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1569,13 +1569,6 @@ iterative_hash_template_arg (tree arg, hashval_t val)
   val = iterative_hash_object (code, val);
   return iterative_hash_template_arg (TREE_OPERAND (arg, 2), val);
 
-case ARRAY_TYPE:
-  /* layout_type sets structural equality for arrays of
-incomplete type, so we can't rely on the canonical type
-for hashing.  */
-  val = iterative_hash_template_arg (TREE_TYPE (arg), val);
-  return iterative_hash_template_arg (TYPE_DOMAIN (arg), val);
-
 case LAMBDA_EXPR:
   /* A lambda can't appear in a template arg, but don't crash on
 erroneous input.  */
diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 9056d7e..ed36c5b 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -2028,11 +2028,6 @@ layout_type (tree type)
 #else
TYPE_ALIGN (type) = MAX (TYPE_ALIGN (element), BITS_PER_UNIT);
 #endif
-   if (!TYPE_SIZE (element))
- /* We don't know the size of the underlying element type, so
-our alignment calculations will be wrong, forcing us to
-fall back on structural equality. */
- SET_TYPE_STRUCTURAL_EQUALITY (type);
TYPE_USER_ALIGN (type) = TYPE_USER_ALIGN (element);
SET_TYPE_MODE (type, BLKmode);
if (TYPE_SIZE (type) != 0
diff --git a/gcc/tree.c b/gcc/tree.c
index c947072..61532db 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -5981,12 +5981,18 @@ type_hash_eq (const void *va, const void *vb)
   || TREE_TYPE (a->type) != TREE_TYPE (b->type)
   || !attribute_list_equal (TYPE_ATTRIBUTES (a->type),
 TYPE_ATTRIBUTES (b->type))
-  || TYPE_ALIGN (a->type) != TYPE_ALIGN (b->type)
-  || TYPE_MODE (a->type) != TYPE_MODE (b->type)
   || (TREE_CODE (a->type) != COMPLEX_TYPE
   && TYPE_NAME (a->type) != TYPE_NAME (b->type)))
 return 0;
 
+  /* Be careful about comparing arrays before and after the element type
+ has been completed; don't compare TYPE_ALIGN unless both types are
+ complete.  */
+  if (TYPE_SIZE (a->type) && TYPE_SIZE (b->type)
+  && (TYPE_ALIGN (a->type) != TYPE_ALIGN (b->type)
+ || TYPE_MODE (a->type) != TYPE_MODE (b->type)))
+return 0;
+
   switch (TREE_CODE (a->type))
 {
 case VOID_TYPE:

Re: [4.7] Avoid global state in score_handle_option

[Liqin Chen]

Hi Joseph,

Joseph Myers  写于 2011-03-10 08:59:52:

> Tested building cc1 and xgcc for cross to score-elf.  Will commit to
> trunk for 4.7 in the absence of target maintainer objections.

Thanks Joseph, please commit.
We will merge it in our new update.

Cheers
--liqin

[pph] Buffer overrun in preprocessor symbol replay

[Lawrence Crowl]

In my last PPH change, I eliminated the redundancy in the preprocessor
identifier lookaside table by removing the name of the identifier from
the head of the macro value.  This later led to a buffer overrun in
libcpp/symtab.c cpp_lt_replay.  The buffer was allocated based on the
value string size, which is was no longer large enough to hold the
definition string.

Split cpp_idents_used::max_length and cpp_lookaside::max_length into
max_ident_len and max_value_len.  In cpp_lt_replay, allocate the
buffer based on the sum of max_ident_len and max_value_len.

-- 
Lawrence Crowl


src.change
Description: Binary data
Index: gcc/cp/pph.c
===
*** gcc/cp/pph.c	(revision 170837)
--- gcc/cp/pph.c	(working copy)
*** pth_dump_identifiers (FILE *stream, cpp_
*** 502,509 
  {
unsigned int idx, col = 1;
  
!   fprintf (stream, "%u identifiers up to %u chars\n",
!identifiers->num_entries, identifiers->max_length);
for (idx = 0; idx < identifiers->num_entries; ++idx)
  {
cpp_ident_use *ident = identifiers->entries + idx;
--- 502,510 
  {
unsigned int idx, col = 1;
  
!   fprintf (stream, "%u identifiers up to %u chars, vals to %u chars\n",
!identifiers->num_entries, identifiers->max_ident_len,
!identifiers->max_value_len);
for (idx = 0; idx < identifiers->num_entries; ++idx)
  {
cpp_ident_use *ident = identifiers->entries + idx;
*** pth_save_identifiers (cpp_idents_used *i
*** 793,814 
unsigned int num_entries, id;
  
num_entries = identifiers->num_entries;
!   pph_output_uint (stream, identifiers->max_length);
pph_output_uint (stream, num_entries);
  
for ( id = 0; id < num_entries; ++id )
  {
cpp_ident_use *entry = identifiers->entries + id;
  
!   gcc_assert (entry->ident_len <= identifiers->max_length);
pph_output_string_with_length (stream, entry->ident_str,
   entry->ident_len);
  
!   gcc_assert (entry->before_len <= identifiers->max_length);
pph_output_string_with_length (stream, entry->before_str,
   entry->before_len);
  
!   gcc_assert (entry->after_len <= identifiers->max_length);
pph_output_string_with_length (stream, entry->after_str,
   entry->after_len);
  }
--- 794,816 
unsigned int num_entries, id;
  
num_entries = identifiers->num_entries;
!   pph_output_uint (stream, identifiers->max_ident_len);
!   pph_output_uint (stream, identifiers->max_value_len);
pph_output_uint (stream, num_entries);
  
for ( id = 0; id < num_entries; ++id )
  {
cpp_ident_use *entry = identifiers->entries + id;
  
!   gcc_assert (entry->ident_len <= identifiers->max_ident_len);
pph_output_string_with_length (stream, entry->ident_str,
   entry->ident_len);
  
!   gcc_assert (entry->before_len <= identifiers->max_value_len);
pph_output_string_with_length (stream, entry->before_str,
   entry->before_len);
  
!   gcc_assert (entry->after_len <= identifiers->max_value_len);
pph_output_string_with_length (stream, entry->after_str,
   entry->after_len);
  }
*** static void
*** 1025,1035 
  pth_load_identifiers (cpp_idents_used *identifiers, pph_stream *stream)
  {
unsigned int j;
!   unsigned int max_length, num_entries;
unsigned int ident_len, before_len, after_len;
  
!   max_length = pph_input_uint (stream);
!   identifiers->max_length = max_length;
num_entries = pph_input_uint (stream);
identifiers->num_entries = num_entries;
identifiers->entries = XCNEWVEC (cpp_ident_use, num_entries);
--- 1027,1039 
  pth_load_identifiers (cpp_idents_used *identifiers, pph_stream *stream)
  {
unsigned int j;
!   unsigned int max_ident_len, max_value_len, num_entries;
unsigned int ident_len, before_len, after_len;
  
!   max_ident_len = pph_input_uint (stream);
!   identifiers->max_ident_len = max_ident_len;
!   max_value_len = pph_input_uint (stream);
!   identifiers->max_value_len = max_value_len;
num_entries = pph_input_uint (stream);
identifiers->num_entries = num_entries;
identifiers->entries = XCNEWVEC (cpp_ident_use, num_entries);
Index: libcpp/symtab.c
===
*** libcpp/symtab.c	(revision 170837)
--- libcpp/symtab.c	(working copy)
*** cpp_lt_create (unsigned int order, unsig
*** 411,417 
table->sticky_order = order;
table->active = 0;
  
!   table->max_length = 0;
table->strings = XCNEW (struct obstack);
/* Strings need no alignment.  */
_obstack_begin (table->strings, 0, 0,
--- 411,418 
table->sticky_order = order;
table->active = 0;
  
!   table->max_ident_len = 0;
!   table->max_value_len = 0;
table->strings = XCNEW (struct obstack);
/* Strings need no alignment.  */
_obstack_begin (table->strings, 0, 0,

Re: [4.7] Avoid global state in mep_handle_option

[DJ Delorie]

> Tested building cc1 and xgcc for cross to mep-elf.  Will commit to
> trunk for 4.7 in the absence of target maintainer objections.

No objections from me.

Re: [4.7] Make SPARC use PROCESSOR_NIAGARA2 for "niagara2"

[David Miller]

From: "Joseph S. Myers" 
Date: Thu, 10 Mar 2011 01:01:12 + (UTC)

> In the course of preparing target changes to avoid global state in
> option handlers (and use more .opt facilities to simplify those
> handlers) I found that SPARC has a PROCESSOR_NIAGARA2 enumeration
> value but maps "niagara2" in command-line options to PROCESSOR_NIAGARA
> for no apparent reason (at least, there's no comment to explain this
> oddity).
> 
> Supposing this mapping to be a mistake, this patch changes it to use
> PROCESSOR_NIAGARA2.  Tested building cc1 and xgcc for cross to
> sparc-elf.  OK to commit for 4.7?  (If the mapping is deliberate,
> changes to make SPARC use the .opt Enum facility will need to add a
> separate enumeration corresponding to -march values, in order to
> distinguish the two entries.)
> 
> 2011-03-09  Joseph Myers  
> 
>   * config/sparc/sparc.c (sparc_option_override): Use
>   PROCESSOR_NIAGARA2 not PROCESSOR_NIAGARA for "niagara2".

Thanks for finding this bug Joseph, please commit this fix and I think
it's appropriate for existing stable release branches as well.

[4.7] Make SPARC use PROCESSOR_NIAGARA2 for "niagara2"

[Joseph S. Myers]

In the course of preparing target changes to avoid global state in
option handlers (and use more .opt facilities to simplify those
handlers) I found that SPARC has a PROCESSOR_NIAGARA2 enumeration
value but maps "niagara2" in command-line options to PROCESSOR_NIAGARA
for no apparent reason (at least, there's no comment to explain this
oddity).

Supposing this mapping to be a mistake, this patch changes it to use
PROCESSOR_NIAGARA2.  Tested building cc1 and xgcc for cross to
sparc-elf.  OK to commit for 4.7?  (If the mapping is deliberate,
changes to make SPARC use the .opt Enum facility will need to add a
separate enumeration corresponding to -march values, in order to
distinguish the two entries.)

2011-03-09  Joseph Myers  

* config/sparc/sparc.c (sparc_option_override): Use
PROCESSOR_NIAGARA2 not PROCESSOR_NIAGARA for "niagara2".

diff -rupN --exclude=.svn gcc-mainline-1/gcc/config/sparc/sparc.c 
gcc-mainline/gcc/config/sparc/sparc.c
--- gcc-mainline-1/gcc/config/sparc/sparc.c 2011-02-24 13:36:04.0 
-0800
+++ gcc-mainline/gcc/config/sparc/sparc.c   2011-03-09 15:16:41.0 
-0800
@@ -787,7 +787,7 @@ sparc_option_override (void)
 { "niagara", PROCESSOR_NIAGARA, MASK_ISA,
   MASK_V9|MASK_DEPRECATED_V8_INSNS},
 /* UltraSPARC T2 */
-{ "niagara2", PROCESSOR_NIAGARA, MASK_ISA, MASK_V9},
+{ "niagara2", PROCESSOR_NIAGARA2, MASK_ISA, MASK_V9},
 { 0, (enum processor_type) 0, 0, 0 }
   };
   const struct cpu_table *cpu;

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

[4.7] Avoid global state in score_handle_option

[Joseph S. Myers]

This patch, for 4.7 and relative to a tree with
 applied,
stops the SCORE handle_option hook from using global state.

The -march= option is converted to use enumerated arguments.  The
existing handling of this option maps arguments to bits in
target_flags, and this is still done after this patch; it would
probably be better to map architectures to values of an actual enum
type (with flags bits used to describe actual subsets of processors
that support some particular instruction if needed), and to make the
options -mscore into aliases for -march= options (documenting
-march= accordingly), but I don't plan to do this cleanup.

Tested building cc1 and xgcc for cross to score-elf.  Will commit to
trunk for 4.7 in the absence of target maintainer objections.

2011-03-09  Joseph Myers  

* config/score/score.c (score_handle_option): Don't assert that
global structures are in use.  Access target_flags via opts
pointer.  Use value of -march= option to determine target_flags
settings.
* config/score/score.opt (march=): Use Enum.
(score_arch): New Enum and EnumValue entries.

diff -rupN --exclude=.svn gcc-mainline-1/gcc/config/score/score.c 
gcc-mainline/gcc/config/score/score.c
--- gcc-mainline-1/gcc/config/score/score.c 2011-02-24 12:56:51.0 
-0800
+++ gcc-mainline/gcc/config/score/score.c   2011-03-09 13:46:47.0 
-0800
@@ -309,67 +309,30 @@ score_asm_file_end (void)
 
 /* Implement TARGET_HANDLE_OPTION.  */
 static bool
-score_handle_option (struct gcc_options *opts, struct gcc_options *opts_set,
+score_handle_option (struct gcc_options *opts,
+struct gcc_options *opts_set ATTRIBUTE_UNUSED,
 const struct cl_decoded_option *decoded,
 location_t loc ATTRIBUTE_UNUSED)
 {
   size_t code = decoded->opt_index;
-  const char *arg = decoded->arg;
-
-  gcc_assert (opts == &global_options);
-  gcc_assert (opts_set == &global_options_set);
+  int value = decoded->value;
 
   switch (code)
 {
 case OPT_mscore7d:
-  target_flags &= ~(MASK_ALL_CPU_BITS);
-  target_flags |= MASK_SCORE7 | MASK_SCORE7D;
+  opts->x_target_flags &= ~(MASK_ALL_CPU_BITS);
+  opts->x_target_flags |= MASK_SCORE7 | MASK_SCORE7D;
   return true;
 
 case OPT_mscore3d:
-  target_flags &= ~(MASK_ALL_CPU_BITS);
-  target_flags |= MASK_SCORE3 | MASK_SCORE3D;
+  opts->x_target_flags &= ~(MASK_ALL_CPU_BITS);
+  opts->x_target_flags |= MASK_SCORE3 | MASK_SCORE3D;
   return true;
 
 case OPT_march_:
-  if (strcmp (arg, "score5") == 0)
-{
-  target_flags &= ~(MASK_ALL_CPU_BITS);
-  target_flags |= MASK_SCORE5;
-  return true;
-}
-  else if (strcmp (arg, "score5u") == 0)
-{
-  target_flags &= ~(MASK_ALL_CPU_BITS);
-  target_flags |= MASK_SCORE5U;
-  return true;
-}
-  else if (strcmp (arg, "score7") == 0)
-{
-  target_flags &= ~(MASK_ALL_CPU_BITS);
-  target_flags |= MASK_SCORE7;
-  return true;
-}
-  else if (strcmp (arg, "score7d") == 0)
-{
-  target_flags &= ~(MASK_ALL_CPU_BITS);
-  target_flags |= MASK_SCORE7 | MASK_SCORE7D;
-  return true;
-}
-  else if (strcmp (arg, "score3") == 0)
-{
-  target_flags &= ~(MASK_ALL_CPU_BITS);
-  target_flags |= MASK_SCORE3;
-  return true;
-}
-  else if (strcmp (arg, "score3d") == 0)
-{
-  target_flags &= ~(MASK_ALL_CPU_BITS);
-  target_flags |= MASK_SCORE3 | MASK_SCORE3D;
-  return true;
-}
-  else
-return false;
+  opts->x_target_flags &= ~(MASK_ALL_CPU_BITS);
+  opts->x_target_flags |= value;
+  return true;
 
 default:
   return true;
diff -rupN --exclude=.svn gcc-mainline-1/gcc/config/score/score.opt 
gcc-mainline/gcc/config/score/score.opt
--- gcc-mainline-1/gcc/config/score/score.opt   2009-03-28 00:38:42.0 
-0700
+++ gcc-mainline/gcc/config/score/score.opt 2011-03-09 14:26:06.0 
-0800
@@ -1,6 +1,6 @@
 ; Options for the Sunnorth port of the compiler.
 
-; Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+; Copyright (C) 2005, 2007, 2011 Free Software Foundation, Inc.
 ;
 ; This file is part of GCC.
 ;
@@ -59,5 +59,27 @@ Target RejectNegative Report Mask(SCORE3
 Support SCORE 3d ISA
 
 march=
-Target RejectNegative Joined
+Target RejectNegative Joined Enum(score_arch)
 Specify the name of the target architecture
+
+Enum
+Name(score_arch) Type(int)
+Known SCORE architectures (for use with the -march= option):
+
+EnumValue
+Enum(score_arch) String(score5) Value(MASK_SCORE5)
+
+EnumValue
+Enum(score_arch) String(score5u) Value(MASK_SCORE5U)
+
+EnumValue
+Enum(score_arch) String(score7) Value(MASK_SCORE7)
+
+EnumValue
+Enum(score_arch) String(score7d) Value(MASK_SCO

[4.7] Avoid global state in mep_handle_option

[Joseph S. Myers]

This patch, for 4.7 and relative to a tree with
 applied,
stops the MEP handle_option hook from using global state.  The
variable option_mtiny_specified is replaced by the automatic setting
of x_mep_tiny_cutoff in the opts_set structure.  Setting of register
properties and names for -mivc2 is deferred to mep_option_override.
The other part of the effect of that option is setting various bits in
target_flags (now opts->x_target_flags); as the part of the semantics
described in the .opt file is now the deferral rather than setting a
bit (both can't be described for the same option), the relevant mask
is now defined by a Mask entry in mep.opt rather than by the Mask flag
on the option entry for -mivc2.  (The code to set this mask when the
option is passed was already present in mep_handle_option, although
before this patch it was redundant with the automatic setting.)

Tested building cc1 and xgcc for cross to mep-elf.  Will commit to
trunk for 4.7 in the absence of target maintainer objections.

2011-03-09  Joseph Myers  

* config/mep/mep.c (option_mtiny_specified): Remove.
(mep_option_override): Move register handling for -mivc2 from
mep_handle_option.  Use global_options_set.x_mep_tiny_cutoff
instead of option_mtiny_specified.
(mep_handle_option): Access target_flags via opts pointer.  Don't
assert that global structures are in use.  Defer part of -mivc2
handling and move it to mep_option_override.
* config/mep/mep.opt (IVC2): New Mask entry.
(mivc2): Use Var and Defer instead of Mask.

diff -rupN --exclude=.svn gcc-mainline-1/gcc/config/mep/mep.c 
gcc-mainline/gcc/config/mep/mep.c
--- gcc-mainline-1/gcc/config/mep/mep.c 2011-02-24 13:59:57.0 -0800
+++ gcc-mainline/gcc/config/mep/mep.c   2011-03-09 12:54:33.0 -0800
@@ -268,8 +268,6 @@ static const int mep_cmov_insns[] = {
   mep_cor3
 };
 
-static int option_mtiny_specified = 0;
-
 
 static void
 mep_set_leaf_registers (int enable)
@@ -316,6 +314,58 @@ static const struct default_options mep_
 static void
 mep_option_override (void)
 {
+  unsigned int i;
+  int j;
+  cl_deferred_option *opt;
+  VEC(cl_deferred_option,heap) *vec
+= (VEC(cl_deferred_option,heap) *) mep_deferred_options;
+
+  FOR_EACH_VEC_ELT (cl_deferred_option, vec, i, opt)
+{
+  switch (opt->opt_index)
+   {
+   case OPT_mivc2:
+ for (j = 0; j < 32; j++)
+   fixed_regs[j + 48] = 0;
+ for (j = 0; j < 32; j++)
+   call_used_regs[j + 48] = 1;
+ for (j = 6; j < 8; j++)
+   call_used_regs[j + 48] = 0;
+
+#define RN(n,s) reg_names[FIRST_CCR_REGNO + n] = s
+ RN (0, "$csar0");
+ RN (1, "$cc");
+ RN (4, "$cofr0");
+ RN (5, "$cofr1");
+ RN (6, "$cofa0");
+ RN (7, "$cofa1");
+ RN (15, "$csar1");
+
+ RN (16, "$acc0_0");
+ RN (17, "$acc0_1");
+ RN (18, "$acc0_2");
+ RN (19, "$acc0_3");
+ RN (20, "$acc0_4");
+ RN (21, "$acc0_5");
+ RN (22, "$acc0_6");
+ RN (23, "$acc0_7");
+
+ RN (24, "$acc1_0");
+ RN (25, "$acc1_1");
+ RN (26, "$acc1_2");
+ RN (27, "$acc1_3");
+ RN (28, "$acc1_4");
+ RN (29, "$acc1_5");
+ RN (30, "$acc1_6");
+ RN (31, "$acc1_7");
+#undef RN
+ break;
+
+   default:
+ gcc_unreachable ();
+   }
+}
+
   if (flag_pic == 1)
 warning (OPT_fpic, "-fpic is not supported");
   if (flag_pic == 2)
@@ -326,9 +376,9 @@ mep_option_override (void)
 error ("only one of -ms and -ml may be given");
   if (TARGET_M && TARGET_L)
 error ("only one of -mm and -ml may be given");
-  if (TARGET_S && option_mtiny_specified)
+  if (TARGET_S && global_options_set.x_mep_tiny_cutoff)
 error ("only one of -ms and -mtiny= may be given");
-  if (TARGET_M && option_mtiny_specified)
+  if (TARGET_M && global_options_set.x_mep_tiny_cutoff)
 error ("only one of -mm and -mtiny= may be given");
   if (TARGET_OPT_CLIP && ! TARGET_OPT_MINMAX)
 warning (0, "-mclip currently has no effect without -mminmax");
@@ -345,7 +395,7 @@ mep_option_override (void)
 mep_tiny_cutoff = 65536;
   if (TARGET_M)
 mep_tiny_cutoff = 0;
-  if (TARGET_L && ! option_mtiny_specified)
+  if (TARGET_L && ! global_options_set.x_mep_tiny_cutoff)
 mep_tiny_cutoff = 0;
 
   if (TARGET_64BIT_CR_REGS)
@@ -7258,76 +7308,36 @@ mep_address_cost (rtx addr ATTRIBUTE_UNU
 }
 
 static bool
-mep_handle_option (struct gcc_options *opts, struct gcc_options *opts_set,
+mep_handle_option (struct gcc_options *opts,
+  struct gcc_options *opts_set ATTRIBUTE_UNUSED,
   const struct cl_decoded_option *decoded,
   location_t loc ATTRIBUTE_UNUSED)
 {
-  int i;
   size_t code = decoded->opt_index;
 
-  gcc_assert (opts == &global_options);
-  gcc_assert (opts_set == &global_

libgo patch committed: Pass -v to nm in gotest

[Ian Lance Taylor]

This libgo patch passes -v to nm in the gotest script.  That has no
effect on GNU nm (it's overridden by the -p option), and will tell
Solaris nm to sort by value.  With luck that will make the functions
apear in the order in which they appear in the source file, which is
what some of the tests expect.  It would be better if the tests were not
order dependent, but they are what they are.  This is for PR go/48020.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian

diff -r a7ab61d1e5a1 libgo/testsuite/gotest
--- a/libgo/testsuite/gotest	Wed Mar 09 14:10:38 2011 -0800
+++ b/libgo/testsuite/gotest	Wed Mar 09 16:45:16 2011 -0800
@@ -274,7 +274,9 @@
 	# the grep -v eliminates methods and other special names
 	# that have multiple dots.
 	pattern='Test([^a-z].*)?'
-	tests=$($NM -p _gotest_.o $xofile | egrep ' T .*\.'$pattern'$' | grep -v '\..*\..*\.' | sed 's/.* //' | sed 's/.*\.\(.*\.\)/\1/')
+	# The -p option tells GNU nm not to sort.
+	# The -v option tells Solaris nm to sort by value.
+	tests=$($NM -p -v _gotest_.o $xofile | egrep ' T .*\.'$pattern'$' | grep -v '\..*\..*\.' | sed 's/.* //' | sed 's/.*\.\(.*\.\)/\1/')
 	if [ "x$tests" = x ]; then
 		echo 'gotest: warning: no tests matching '$pattern in _gotest_.o $xofile 1>&2
 		exit 2

libgo patch committed: Solaris specific syslog support

[Ian Lance Taylor]

This libgo patch implements Solaris specific syslog support.  On Solaris
we call the libc function rather than worrying about STREAMS.  This
should fix PR go/48018.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r 08dcb2e2c1d2 libgo/Makefile.am
--- a/libgo/Makefile.am	Wed Mar 09 11:16:48 2011 -0800
+++ b/libgo/Makefile.am	Wed Mar 09 13:58:30 2011 -0800
@@ -787,8 +787,15 @@
 go_sync_c_files = \
 	go/sync/cas.c
 
+if LIBGO_IS_SOLARIS
+go_syslog_file = go/syslog/syslog_solaris.go
+else
+go_syslog_file = go/syslog/syslog_unix.go
+endif
+
 go_syslog_files = \
-	go/syslog/syslog.go
+	go/syslog/syslog.go \
+	$(go_syslog_file)
 
 go_tabwriter_files = \
 	go/tabwriter/tabwriter.go
@@ -1785,10 +1792,14 @@
 	$(CHECK)
 .PHONY: sync/check
 
-syslog/libsyslog.$(OBJEXT): $(go_syslog_files) fmt.gox log.gox net.gox os.gox
-	$(BUILDPACKAGE)
-syslog/libsyslog.lo: syslog/libsyslog.$(OBJEXT)
-syslog/libsyslog.la: syslog/libsyslog.lo
+syslog/syslog.$(OBJEXT): $(go_syslog_files) fmt.gox log.gox net.gox os.gox \
+		syscall.gox
+	test -d syslog || $(MKDIR_P) syslog
+	$(LTGOCOMPILE) -I . -c -o $@ -fgo-prefix=libgo_syslog $(srcdir)/go/syslog/syslog.go $(srcdir)/$(go_syslog_file)
+syslog/syslog_c.$(OBJEXT): $(srcdir)/go/syslog/syslog_c.c syslog/syslog.$(OBJEXT)
+	$(LTCOMPILE) -c -o $@ $(srcdir)/go/syslog/syslog_c.c
+syslog/libsyslog.la: syslog/syslog.$(OBJEXT) syslog/syslog_c.$(OBJEXT)
+	$(LINK) syslog/syslog.lo syslog/syslog_c.lo
 syslog/check: $(CHECK_DEPS)
 	$(CHECK)
 .PHONY: syslog/check
@@ -2733,7 +2744,7 @@
 	$(BUILDGOX)
 sync.gox: sync/mutex.$(OBJEXT)
 	$(BUILDGOX)
-syslog.gox: syslog/libsyslog.$(OBJEXT)
+syslog.gox: syslog/syslog.$(OBJEXT)
 	$(BUILDGOX)
 syscall.gox: syscalls/syscall.$(OBJEXT)
 	$(BUILDGOX)
diff -r 08dcb2e2c1d2 libgo/go/syslog/syslog.go
--- a/libgo/go/syslog/syslog.go	Wed Mar 09 11:16:48 2011 -0800
+++ b/libgo/go/syslog/syslog.go	Wed Mar 09 13:58:30 2011 -0800
@@ -34,7 +34,17 @@
 type Writer struct {
 	priority Priority
 	prefix   string
-	conn net.Conn
+	conn serverConn
+}
+
+type serverConn interface {
+	writeBytes(p Priority, prefix string, b []byte) (int, os.Error)
+	writeString(p Priority, prefix string, s string) (int, os.Error)
+	close() os.Error
+}
+
+type netConn struct {
+	conn net.Conn
 }
 
 // New establishes a new connection to the system log daemon.
@@ -52,46 +62,30 @@
 	if prefix == "" {
 		prefix = os.Args[0]
 	}
-	var conn net.Conn
+	var conn serverConn
 	if network == "" {
 		conn, err = unixSyslog()
 	} else {
-		conn, err = net.Dial(network, "", raddr)
+		var c net.Conn
+		c, err = net.Dial(network, "", raddr)
+		conn = netConn{c}
 	}
 	return &Writer{priority, prefix, conn}, err
 }
 
-func unixSyslog() (conn net.Conn, err os.Error) {
-	logTypes := []string{"unixgram", "unix"}
-	logPaths := []string{"/dev/log", "/var/run/syslog"}
-	var raddr string
-	for _, network := range logTypes {
-		for _, path := range logPaths {
-			raddr = path
-			conn, err := net.Dial(network, "", raddr)
-			if err != nil {
-continue
-			} else {
-return conn, nil
-			}
-		}
-	}
-	return nil, os.ErrorString("Unix syslog delivery error")
-}
-
 // Write sends a log message to the syslog daemon.
 func (w *Writer) Write(b []byte) (int, os.Error) {
 	if w.priority > LOG_DEBUG || w.priority < LOG_EMERG {
 		return 0, os.EINVAL
 	}
-	return fmt.Fprintf(w.conn, "<%d>%s: %s\n", w.priority, w.prefix, b)
+	return w.conn.writeBytes(w.priority, w.prefix, b)
 }
 
 func (w *Writer) writeString(p Priority, s string) (int, os.Error) {
-	return fmt.Fprintf(w.conn, "<%d>%s: %s\n", p, w.prefix, s)
+	return w.conn.writeString(p, w.prefix, s)
 }
 
-func (w *Writer) Close() os.Error { return w.conn.Close() }
+func (w *Writer) Close() os.Error { return w.conn.close() }
 
 // Emerg logs a message using the LOG_EMERG priority.
 func (w *Writer) Emerg(m string) (err os.Error) {
@@ -131,6 +125,18 @@
 	return err
 }
 
+func (n netConn) writeBytes(p Priority, prefix string, b []byte) (int, os.Error) {
+	return fmt.Fprintf(n.conn, "<%d>%s: %s\n", p, prefix, b)
+}
+
+func (n netConn) writeString(p Priority, prefix string, s string) (int, os.Error) {
+	return fmt.Fprintf(n.conn, "<%d>%s: %s\n", p, prefix, s)
+}
+
+func (n netConn) close() os.Error {
+	return n.conn.Close()
+}
+
 // NewLogger provides an object that implements the full log.Logger interface,
 // but sends messages to Syslog instead; flag is passed as is to Logger;
 // priority will be used for all messages sent using this interface.
diff -r 08dcb2e2c1d2 libgo/go/syslog/syslog_c.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +
+++ b/libgo/go/syslog/syslog_c.c	Wed Mar 09 13:58:30 2011 -0800
@@ -0,0 +1,19 @@
+/* syslog_c.c -- call syslog for Go.
+
+   Copyright 2011 The Go Authors. All rights reserved.
+   Use of this source code is governed by a BSD-style
+   license that can be found in the LICENSE file.  */
+
+#include 
+
+/* We need to use a C function to call the syslog function, because we
+   can't represent a 

4.5 backport request...

[DJ Delorie]

May I backport this change to 4.5 ?  rx-elf can use this for a
performance boost (a separate 4.5 target patch would be needed for
that)

2010-10-19  DJ Delorie  

* doc/tm.texi.in (TARGET_ASM_JUMP_ALIGN_MAX_SKIP): New.
(TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP): Change to hook.
(TARGET_ASM_LOOP_ALIGN_MAX_SKIP): Likewise.
(TARGET_ASM_LABEL_ALIGN_MAX_SKIP): Likewise.
* doc/tm.texi: Regenerate.
* targhooks.h (default_label_align_after_barrier_max_skip,
default_loop_align_max_skip, default_label_align_max_skip,
default_jump_align_max_skip): Declare.
* target.def (label_align_after_barrier_max_skip): New.
(loop_align_max_skip): New.
(label_align_max_skip): New.
(jump_align_max_skip): New.
* system.h (poison): Add those macros to the list.
* final.c (LABEL_ALIGN_MAX_SKIP): Remove.
(LOOP_ALIGN_MAX_SKIP): Remove.
(LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP): Remove.
(JUMP_ALIGN_MAX_SKIP): Remove.
(default_label_align_after_barrier_max_skip): New.
(default_loop_align_max_skip): New.
(default_label_align_max_skip): New.
(default_jump_align_max_skip): New.
(compute_alignments): Use the new hooks.
(shorten_branches): Likewise.

Re: [c++ demangle, trans-mem, pr47952] Demangle cdtor group names

[Jason Merrill]

OK.

Jason

[c++ demangle, trans-mem, pr47952] Demangle cdtor group names

[Richard Henderson]

The ELF group name for cdtors is mangled differently from the actual
constructors, so that both the complete object ctor and the base
object ctor are both taken from the same object file when duplicate
link-once sections are discarded.

Bizzarely, one can't actually dump full group names, so one can't
actually feed the output of anything into c++filt and be surprised
that some of them don't get demangled.  It would seem like readelf -S
with extra -w (wide) options would do it, but the names are always
truncated.

That said, this came up in the context of trans-mem, in which we
re-mangle names to their transactional-clone equivalent.  It was 
surprising to look at the assembly output and see these names not
being re-mangled "properly".

This adds support for demangling these names, even if we never
distinguish between them when actually outputting them.

Ok for 4.7 and trans-mem branches?  I see no need for this in 4.6...


r~
include/
* demangle.h (enum gnu_v3_ctor_kinds): Add gnu_v3_object_ctor_group.
(enum gnu_v3_dtor_kinds): Add gnu_v3_object_dtor_group.

libiberty/
* cp-demangle.c (cplus_demangle_fill_ctor): Accept
gnu_v3_object_ctor_group.
(cplus_demangle_fill_dtor): Accept gnu_v3_object_dtor_group.
(d_ctor_dtor_name): Recognize gnu_v3_object_ctor_group
and gnu_v3_object_dtor_group.


diff --git a/include/demangle.h b/include/demangle.h
index c062455..872a6a0 100644
--- a/include/demangle.h
+++ b/include/demangle.h
@@ -166,7 +166,8 @@ ada_demangle (const char *mangled, int options);
 enum gnu_v3_ctor_kinds {
   gnu_v3_complete_object_ctor = 1,
   gnu_v3_base_object_ctor,
-  gnu_v3_complete_object_allocating_ctor
+  gnu_v3_complete_object_allocating_ctor,
+  gnu_v3_object_ctor_group
 };
 
 /* Return non-zero iff NAME is the mangled form of a constructor name
@@ -180,7 +181,8 @@ extern enum gnu_v3_ctor_kinds
 enum gnu_v3_dtor_kinds {
   gnu_v3_deleting_dtor = 1,
   gnu_v3_complete_object_dtor,
-  gnu_v3_base_object_dtor
+  gnu_v3_base_object_dtor,
+  gnu_v3_object_dtor_group
 };
 
 /* Return non-zero iff NAME is the mangled form of a destructor name
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 7e951cc..b6280bc 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -731,7 +731,7 @@ cplus_demangle_fill_ctor (struct demangle_component *p,
   if (p == NULL
   || name == NULL
   || (int) kind < gnu_v3_complete_object_ctor
-  || (int) kind > gnu_v3_complete_object_allocating_ctor)
+  || (int) kind > gnu_v3_object_ctor_group)
 return 0;
   p->type = DEMANGLE_COMPONENT_CTOR;
   p->u.s_ctor.kind = kind;
@@ -750,7 +750,7 @@ cplus_demangle_fill_dtor (struct demangle_component *p,
   if (p == NULL
   || name == NULL
   || (int) kind < gnu_v3_deleting_dtor
-  || (int) kind > gnu_v3_base_object_dtor)
+  || (int) kind > gnu_v3_object_dtor_group)
 return 0;
   p->type = DEMANGLE_COMPONENT_DTOR;
   p->u.s_dtor.kind = kind;
@@ -1911,6 +1911,9 @@ d_ctor_dtor_name (struct d_info *di)
  case '3':
kind = gnu_v3_complete_object_allocating_ctor;
break;
+ case '5':
+   kind = gnu_v3_object_ctor_group;
+   break;
  default:
return NULL;
  }
@@ -1933,6 +1936,9 @@ d_ctor_dtor_name (struct d_info *di)
  case '2':
kind = gnu_v3_base_object_dtor;
break;
+ case '5':
+   kind = gnu_v3_object_dtor_group;
+   break;
  default:
return NULL;
  }

Re: Fix pr48032, powerpc64 -mcmodel=medium invalid ld offset

[David Edelsohn]

On Wed, Mar 9, 2011 at 1:07 AM, Alan Modra  wrote:
> This patch
> a) Moves the offsettable_ok_by_alignment call from rs6000_emit_move to
>   legitimate_constant_pool_address_p, and
> b) teaches offsettable_ok_by_alignment how to handle -fsection-anchors
>   addresses, and
> c) teaches offsettable_ok_by_alignment about other SYMBOL_REF_DECL
>   trees I see there, various constant trees and CONSTRUCTOR.
>
> About (a), well, that's just the way I should have written the
> cmodel=medium optimization in the first place.  There is no alignment
> reason to not create a cmodel=medium address (ie. addis,addi relative
> to toc pointer), it's just that they do need to be sufficiently
> aligned to use in a MEM.  We want reg=cmodel_medium_losum; mem[reg]
> whenever we can do so, rather than creating a toc entry, but must not
> allow the sequence to be combined into mem[cmodel_medium_losum] if
> cmodel_medium_losum is not offsettable to access all the bytes of mem.
> Perhaps legitimate_constant_pool_address_p should be renamed.  I
> didn't do that because it already allows the non-constant-pool
> cmodel=medium addresses, and the name is long enough now.  I commented
> the function instead.
>
> (b) is necessary because -fsection-anchors unfortunately loses the
> real SYMBOL_REF_DECL when substituting anchor+offset into MEMs.  The
> way I imlemented this is why legitimate_constant_pool_address_p needs
> the MEM mode.  I suppose it would be possible to keep the original
> SYMBOL_REF_DECL around in the rtl by some means or find the decl in
> the struct object_block info, but both of these options seem like
> overkill to me.  Note that I pass QImode to l_c_p_a_p from
> rs6000_mode_dependent_address, print_operand_address, and the 'R'
> constraint to indicate that any cmodel=medium address is permissable.
>
> (c) was developed specifically to fix problems found on
> ibm/gcc-4_5-branch.  I'd still like to commit this on mainline even
> though it seems that mainline creates VAR_DECLs for constants.
>
> Bootstrapped and regression tested powerpc64-linux.  OK to apply?

Alan,

I agree that this is a better approach.  You might want to ask Richard
Sandiford to look at the section anchors issue.

Thanks, David

libgo patch committed: Mention GCCGO_RUN_ALL_TESTS in README.gcc

[Ian Lance Taylor]

Rainer pointed out that the GCCGO_RUN_ALL_TESTS environment variable
should really be documented.  This patch adds a note to
libgo/README.gcc.  Committed to mainline.

Ian

diff -r 5d83cac5a1c5 libgo/README.gcc
--- a/libgo/README.gcc	Tue Mar 08 22:54:43 2011 -0800
+++ b/libgo/README.gcc	Wed Mar 09 11:16:12 2011 -0800
@@ -1,3 +1,7 @@
 The files in this directory are mirrored from the gofrontend project
 hosted at http://code.google.com/p/gofrontend.  These files are the
 ones in the libgo subdirectory of that project.
+
+By default, the networking tests are not run.  In order to run all the
+libgo tests, you need to define the environment variable
+GCCGO_RUN_ALL_TESTS to a non-empty string.

[v3] libstdc++/48038

[Paolo Carlini]

Hi,

tested x86_64-linux multilib + debug-mode, committed to mainline (see
Audit trail for details)

Thanks,
Paolo.


2011-03-09  Paolo Carlini  

* testsuite/util/testsuite_rvalref.h: Minor tweaks.

2011-03-09  Jonathan Wakely  
Chris Jefferson  
Paolo Carlini  

* testsuite/util/testsuite_rvalref.h (rvalstruct_compare_by_value):
New.
* testsuite/25_algorithms/sort_heap/check_compare_by_value.cc:
Likewise.
* testsuite/25_algorithms/partial_sort/check_compare_by_value:
Likewise.
* testsuite/25_algorithms/stable_sort/check_compare_by_value.cc:
Likewise.
* testsuite/25_algorithms/sort/check_compare_by_value: Likewise.

2011-03-09  Chris Jefferson  

PR libstdc++/48038
* include/bits/stl_algo.h (__merge_backward): Rename to
__move_merge_backward and change to always move rather than copy.
(__move_merge): New function similar to std::merge except values
are moved instead of copied.
(__merge_adaptive, __merge_sort_loop): Change from using std::merge
and __merge_backward to __move_merge and __move_merge_backward.
Index: include/bits/stl_algo.h
===
--- include/bits/stl_algo.h (revision 170820)
+++ include/bits/stl_algo.h (working copy)
@@ -2720,32 +2720,32 @@
   template
 _BidirectionalIterator3
-__merge_backward(_BidirectionalIterator1 __first1,
-_BidirectionalIterator1 __last1,
-_BidirectionalIterator2 __first2,
-_BidirectionalIterator2 __last2,
-_BidirectionalIterator3 __result)
+__move_merge_backward(_BidirectionalIterator1 __first1,
+ _BidirectionalIterator1 __last1,
+ _BidirectionalIterator2 __first2,
+ _BidirectionalIterator2 __last2,
+ _BidirectionalIterator3 __result)
 {
   if (__first1 == __last1)
-   return std::copy_backward(__first2, __last2, __result);
+   return _GLIBCXX_MOVE_BACKWARD3(__first2, __last2, __result);
   if (__first2 == __last2)
-   return std::copy_backward(__first1, __last1, __result);
+   return _GLIBCXX_MOVE_BACKWARD3(__first1, __last1, __result);
   --__last1;
   --__last2;
   while (true)
{
  if (*__last2 < *__last1)
{
- *--__result = *__last1;
+ *--__result = _GLIBCXX_MOVE(*__last1);
  if (__first1 == __last1)
-   return std::copy_backward(__first2, ++__last2, __result);
+   return _GLIBCXX_MOVE_BACKWARD3(__first2, ++__last2, __result);
  --__last1;
}
  else
{
- *--__result = *__last2;
+ *--__result = _GLIBCXX_MOVE(*__last2);
  if (__first2 == __last2)
-   return std::copy_backward(__first1, ++__last1, __result);
+   return _GLIBCXX_MOVE_BACKWARD3(__first1, ++__last1, __result);
  --__last2;
}
}
@@ -2755,39 +2755,94 @@
   template
 _BidirectionalIterator3
-__merge_backward(_BidirectionalIterator1 __first1,
-_BidirectionalIterator1 __last1,
-_BidirectionalIterator2 __first2,
-_BidirectionalIterator2 __last2,
-_BidirectionalIterator3 __result,
-_Compare __comp)
+__move_merge_backward(_BidirectionalIterator1 __first1,
+ _BidirectionalIterator1 __last1,
+ _BidirectionalIterator2 __first2,
+ _BidirectionalIterator2 __last2,
+ _BidirectionalIterator3 __result,
+ _Compare __comp)
 {
   if (__first1 == __last1)
-   return std::copy_backward(__first2, __last2, __result);
+   return _GLIBCXX_MOVE_BACKWARD3(__first2, __last2, __result);
   if (__first2 == __last2)
-   return std::copy_backward(__first1, __last1, __result);
+   return _GLIBCXX_MOVE_BACKWARD3(__first1, __last1, __result);
   --__last1;
   --__last2;
   while (true)
{
  if (__comp(*__last2, *__last1))
{
- *--__result = *__last1;
+ *--__result = _GLIBCXX_MOVE(*__last1);
  if (__first1 == __last1)
-   return std::copy_backward(__first2, ++__last2, __result);
+   return _GLIBCXX_MOVE_BACKWARD3(__first2, ++__last2, __result);
  --__last1;
}
  else
{
- *--__result = *__last2;
+ *--__result = _GLIBCXX_MOVE(*__last2);
  if (__first2 == __last2)
-   return std::copy_backward(__first1, ++__last1, __result);
+   return _GLIBCXX_MOVE_BACKWARD3(__first1, ++__last1, __result);
   

Re: fix for pr47837

[Xinliang David Li]

Ok.

Regarding this particular patch, I hope it can be checked in to make
the test clean. It is a simple enhancement to a wheel that is already
there. It also serves as a case that can be referenced in the future
when the more general mechanism is available.

Thanks,

David

On Wed, Mar 9, 2011 at 9:54 AM, Richard Guenther
 wrote:
> On Wed, Mar 9, 2011 at 6:34 PM, Xinliang David Li  wrote:
>> On Wed, Mar 9, 2011 at 8:29 AM, Richard Guenther
>>  wrote:
>>> On Wed, Mar 9, 2011 at 5:24 PM, Xinliang David Li  
>>> wrote:
 On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/09/11 02:45, Richard Guenther wrote:
>> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>
>> True.  I've been repeatedly thinking of building some on-the-side CFG
>> with value-numbered predicates to also catch the CFG vs. scalar-code
>> predicate combinations we have.  On such on-the-side data structure
>> we could do very aggressive jump-threading just for analysis purposes
>> (experiments when working on separating conditions shows that
>> a PRE-like algorithm could drive this).
> I'm pondering the same kind of thing.  PRE on the predicates with a more
> structured approach to block copying to isolate the paths seems to be
> the way to go.


 Any simple examples to show how your idea would work?
>>>
>>> You basically would copy all paths with redundant predicate computations,
>>> removing them and leaving no redundant checks around.  Of course you
>>> wouldn't really do this code-transformation but just do it to help analyses.
>>
>> You will also need to compute SSA on the alternate CFG as well, right?
>
> It depends on what task you want to perform on the alternate CFG.  For
> uninitialized vars, yes, likely.
>
>> How will partially redundant predicates handled? Split the predicates?
>
> Yes.
>
>> if (p1 OR p2)
>>  foo();
>> bar();
>> if (p1)
>>   baz();
>>
>> ==>
>>
>> if (p1)
>> {
>>    foo(); bar(); baz();
>> }
>> else if (p2)
>> {
>>   foo(); bar();
>> }
>> else
>>   bar();
>>
>> Things can be complicated when dealing with slightly complex
>> predicates. For instance
>>
>> p1 = x | y;   // bitwise OR
>>
>> p2_1 = (x!=0);
>> p2_2 = (y!=0);
>> p2 = (p2_1 & p2_2);
>>
>> p1 can be split into (x AND !y), p2 , and (!x AND y).
>>
>> How about short circuite &&, || expressions lowered into if-then-else?
>>  Will the side CFG collapse the expanded branches and expose the
>> 'original' predicates that are easier to analyze?
>
> That all remains to be seen.  Just the current restriction of working on
> the present IL for analysis purposes should be lifted (and made easier
> w/o the need to re-invent the wheel everywhere).
>
> Richard.
>
>> Thanks,
>>
>> David
>>
>>
>>>
>>> Like in
>>>
>>>  if (p)
>>>   foo();
>>>  bar();
>>>  if (p)
>>>   baz();
>>>
>>> you'd generate
>>>
>>>  if(p)
>>>   {
>>>     foo();
>>>     bar();
>>>     baz();
>>>   }
>>> else
>>>  bar();
>>>
>>> for all, even partially redundant predicates.  See the patch I linked to, it
>>> causes PRE to identify them (but do nothing too useful yet)
>>>
>>> Richard.
>>>
 Thanks,

 David
>
> jeff
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNd4irAAoJEBRtltQi2kC73SAH/jIC30j/CkWSV9rQGYn+gtfD
> WiBXnbYxv7rc6PUqkT8U5I3upk/subJKlAhAQ1D1Eg6355QqpcMh7yZJGz20ovGc
> CXQOK1ZbtCXvk6uZ8QamdfowojhkkxQo900c9mJtuaaevjywwt+MX3VwShNIrfbA
> bKSIjHVeeZ2qwymNYHV8C82Zss5WA72FQqIpmlTlPKEwWFO49jLld/iXszyjC1cF
> OWQdH37ZNgXARibaWI28KZCz5B39yz5F4mljVCyMS9XvNKzfwabT5FHj8btYzdAK
> HYoAsBtONN/0/FJPn3I9VwyYC0q8M6tm9BgMyhhVmCU2PWMCt0jZJZA9aW/4X+o=
> =R64B
> -END PGP SIGNATURE-
>

>>>
>>
>

C++ PATCH for c++/44629 (ICE with function template as non-type template argument)

[Jason Merrill]

In this testcase, we have a function template used as an argument for a 
function pointer template parameter.  This causes unify to abort because 
an OVERLOAD doesn't satisfy EXPR_P.  14.8.2.5 lists an overloaded 
function given as a function argument as a non-deduced context, so it 
seems reasonable to treat one given as a template argument as 
non-deduced as well.


The ABI is silent on how to mangle this, and EDG currently does 
something strange, so I'm not going to add mangling in 4.6; as a result, 
the testcase will get a sorry from the mangler, but that's better than 
an ICE.


Tested x86_64-pc-linux-gnu, applied to trunk, 4.4, 4.5.

commit 5faa2c811748d00cbee57ad0e5c991549099b95a
Author: Jason Merrill 
Date:   Tue Mar 8 21:44:29 2011 -0500

PR c++/44629
* pt.c (unify): An unresolved overload is a nondeduced context.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2ca2cd0..ac91698 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -15688,6 +15688,9 @@ unify (tree tparms, tree targs, tree parm, tree arg, 
int strict)
   return 1;
 
 default:
+  /* An unresolved overload is a nondeduced context.  */
+  if (type_unknown_p (parm))
+   return 0;
   gcc_assert (EXPR_P (parm));
 
   /* We must be looking at an expression.  This can happen with
diff --git a/gcc/testsuite/g++.dg/template/nontype22.C 
b/gcc/testsuite/g++.dg/template/nontype22.C
new file mode 100644
index 000..f2c8c46
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/nontype22.C
@@ -0,0 +1,11 @@
+// PR c++/44629
+// The proper mangling is unclear.
+
+template int cmp1(T a, T b);
+template struct A { };
+template  void f (A &); // { dg-bogus "" "" { xfail *-*-* } }
+void g()
+{
+  A a;
+  f(a);
+}

Re: fix for pr47837

[Richard Guenther]

On Wed, Mar 9, 2011 at 6:34 PM, Xinliang David Li  wrote:
> On Wed, Mar 9, 2011 at 8:29 AM, Richard Guenther
>  wrote:
>> On Wed, Mar 9, 2011 at 5:24 PM, Xinliang David Li  wrote:
>>> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 03/09/11 02:45, Richard Guenther wrote:
> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:

> True.  I've been repeatedly thinking of building some on-the-side CFG
> with value-numbered predicates to also catch the CFG vs. scalar-code
> predicate combinations we have.  On such on-the-side data structure
> we could do very aggressive jump-threading just for analysis purposes
> (experiments when working on separating conditions shows that
> a PRE-like algorithm could drive this).
 I'm pondering the same kind of thing.  PRE on the predicates with a more
 structured approach to block copying to isolate the paths seems to be
 the way to go.
>>>
>>>
>>> Any simple examples to show how your idea would work?
>>
>> You basically would copy all paths with redundant predicate computations,
>> removing them and leaving no redundant checks around.  Of course you
>> wouldn't really do this code-transformation but just do it to help analyses.
>
> You will also need to compute SSA on the alternate CFG as well, right?

It depends on what task you want to perform on the alternate CFG.  For
uninitialized vars, yes, likely.

> How will partially redundant predicates handled? Split the predicates?

Yes.

> if (p1 OR p2)
>  foo();
> bar();
> if (p1)
>   baz();
>
> ==>
>
> if (p1)
> {
>    foo(); bar(); baz();
> }
> else if (p2)
> {
>   foo(); bar();
> }
> else
>   bar();
>
> Things can be complicated when dealing with slightly complex
> predicates. For instance
>
> p1 = x | y;   // bitwise OR
>
> p2_1 = (x!=0);
> p2_2 = (y!=0);
> p2 = (p2_1 & p2_2);
>
> p1 can be split into (x AND !y), p2 , and (!x AND y).
>
> How about short circuite &&, || expressions lowered into if-then-else?
>  Will the side CFG collapse the expanded branches and expose the
> 'original' predicates that are easier to analyze?

That all remains to be seen.  Just the current restriction of working on
the present IL for analysis purposes should be lifted (and made easier
w/o the need to re-invent the wheel everywhere).

Richard.

> Thanks,
>
> David
>
>
>>
>> Like in
>>
>>  if (p)
>>   foo();
>>  bar();
>>  if (p)
>>   baz();
>>
>> you'd generate
>>
>>  if(p)
>>   {
>>     foo();
>>     bar();
>>     baz();
>>   }
>> else
>>  bar();
>>
>> for all, even partially redundant predicates.  See the patch I linked to, it
>> causes PRE to identify them (but do nothing too useful yet)
>>
>> Richard.
>>
>>> Thanks,
>>>
>>> David

 jeff


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

 iQEcBAEBAgAGBQJNd4irAAoJEBRtltQi2kC73SAH/jIC30j/CkWSV9rQGYn+gtfD
 WiBXnbYxv7rc6PUqkT8U5I3upk/subJKlAhAQ1D1Eg6355QqpcMh7yZJGz20ovGc
 CXQOK1ZbtCXvk6uZ8QamdfowojhkkxQo900c9mJtuaaevjywwt+MX3VwShNIrfbA
 bKSIjHVeeZ2qwymNYHV8C82Zss5WA72FQqIpmlTlPKEwWFO49jLld/iXszyjC1cF
 OWQdH37ZNgXARibaWI28KZCz5B39yz5F4mljVCyMS9XvNKzfwabT5FHj8btYzdAK
 HYoAsBtONN/0/FJPn3I9VwyYC0q8M6tm9BgMyhhVmCU2PWMCt0jZJZA9aW/4X+o=
 =R64B
 -END PGP SIGNATURE-

>>>
>>
>

Re: fix for pr47837

[Xinliang David Li]

On Wed, Mar 9, 2011 at 8:29 AM, Richard Guenther
 wrote:
> On Wed, Mar 9, 2011 at 5:24 PM, Xinliang David Li  wrote:
>> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 03/09/11 02:45, Richard Guenther wrote:
 On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>>>
 True.  I've been repeatedly thinking of building some on-the-side CFG
 with value-numbered predicates to also catch the CFG vs. scalar-code
 predicate combinations we have.  On such on-the-side data structure
 we could do very aggressive jump-threading just for analysis purposes
 (experiments when working on separating conditions shows that
 a PRE-like algorithm could drive this).
>>> I'm pondering the same kind of thing.  PRE on the predicates with a more
>>> structured approach to block copying to isolate the paths seems to be
>>> the way to go.
>>
>>
>> Any simple examples to show how your idea would work?
>
> You basically would copy all paths with redundant predicate computations,
> removing them and leaving no redundant checks around.  Of course you
> wouldn't really do this code-transformation but just do it to help analyses.

You will also need to compute SSA on the alternate CFG as well, right?
How will partially redundant predicates handled? Split the predicates?

if (p1 OR p2)
  foo();
bar();
if (p1)
   baz();

==>

if (p1)
{
foo(); bar(); baz();
}
else if (p2)
{
   foo(); bar();
}
else
   bar();

Things can be complicated when dealing with slightly complex
predicates. For instance

p1 = x | y;   // bitwise OR

p2_1 = (x!=0);
p2_2 = (y!=0);
p2 = (p2_1 & p2_2);

p1 can be split into (x AND !y), p2 , and (!x AND y).

How about short circuite &&, || expressions lowered into if-then-else?
 Will the side CFG collapse the expanded branches and expose the
'original' predicates that are easier to analyze?

Thanks,

David


>
> Like in
>
>  if (p)
>   foo();
>  bar();
>  if (p)
>   baz();
>
> you'd generate
>
>  if(p)
>   {
>     foo();
>     bar();
>     baz();
>   }
> else
>  bar();
>
> for all, even partially redundant predicates.  See the patch I linked to, it
> causes PRE to identify them (but do nothing too useful yet)
>
> Richard.
>
>> Thanks,
>>
>> David
>>>
>>> jeff
>>>
>>>
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>>>
>>> iQEcBAEBAgAGBQJNd4irAAoJEBRtltQi2kC73SAH/jIC30j/CkWSV9rQGYn+gtfD
>>> WiBXnbYxv7rc6PUqkT8U5I3upk/subJKlAhAQ1D1Eg6355QqpcMh7yZJGz20ovGc
>>> CXQOK1ZbtCXvk6uZ8QamdfowojhkkxQo900c9mJtuaaevjywwt+MX3VwShNIrfbA
>>> bKSIjHVeeZ2qwymNYHV8C82Zss5WA72FQqIpmlTlPKEwWFO49jLld/iXszyjC1cF
>>> OWQdH37ZNgXARibaWI28KZCz5B39yz5F4mljVCyMS9XvNKzfwabT5FHj8btYzdAK
>>> HYoAsBtONN/0/FJPn3I9VwyYC0q8M6tm9BgMyhhVmCU2PWMCt0jZJZA9aW/4X+o=
>>> =R64B
>>> -END PGP SIGNATURE-
>>>
>>
>

Re: fix for pr47837

[Xinliang David Li]

On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/09/11 02:45, Richard Guenther wrote:
>> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>
>> True.  I've been repeatedly thinking of building some on-the-side CFG
>> with value-numbered predicates to also catch the CFG vs. scalar-code
>> predicate combinations we have.  On such on-the-side data structure
>> we could do very aggressive jump-threading just for analysis purposes
>> (experiments when working on separating conditions shows that
>> a PRE-like algorithm could drive this).
> I'm pondering the same kind of thing.  PRE on the predicates with a more
> structured approach to block copying to isolate the paths seems to be
> the way to go.


Any simple examples to show how your idea would work?

Thanks,

David
>
> jeff
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNd4irAAoJEBRtltQi2kC73SAH/jIC30j/CkWSV9rQGYn+gtfD
> WiBXnbYxv7rc6PUqkT8U5I3upk/subJKlAhAQ1D1Eg6355QqpcMh7yZJGz20ovGc
> CXQOK1ZbtCXvk6uZ8QamdfowojhkkxQo900c9mJtuaaevjywwt+MX3VwShNIrfbA
> bKSIjHVeeZ2qwymNYHV8C82Zss5WA72FQqIpmlTlPKEwWFO49jLld/iXszyjC1cF
> OWQdH37ZNgXARibaWI28KZCz5B39yz5F4mljVCyMS9XvNKzfwabT5FHj8btYzdAK
> HYoAsBtONN/0/FJPn3I9VwyYC0q8M6tm9BgMyhhVmCU2PWMCt0jZJZA9aW/4X+o=
> =R64B
> -END PGP SIGNATURE-
>

Re: fix for pr47837

[Richard Guenther]

On Wed, Mar 9, 2011 at 5:24 PM, Xinliang David Li  wrote:
> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 03/09/11 02:45, Richard Guenther wrote:
>>> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>>
>>> True.  I've been repeatedly thinking of building some on-the-side CFG
>>> with value-numbered predicates to also catch the CFG vs. scalar-code
>>> predicate combinations we have.  On such on-the-side data structure
>>> we could do very aggressive jump-threading just for analysis purposes
>>> (experiments when working on separating conditions shows that
>>> a PRE-like algorithm could drive this).
>> I'm pondering the same kind of thing.  PRE on the predicates with a more
>> structured approach to block copying to isolate the paths seems to be
>> the way to go.
>
>
> Any simple examples to show how your idea would work?

You basically would copy all paths with redundant predicate computations,
removing them and leaving no redundant checks around.  Of course you
wouldn't really do this code-transformation but just do it to help analyses.

Like in

 if (p)
   foo();
 bar();
 if (p)
   baz();

you'd generate

  if(p)
   {
 foo();
 bar();
 baz();
   }
else
  bar();

for all, even partially redundant predicates.  See the patch I linked to, it
causes PRE to identify them (but do nothing too useful yet)

Richard.

> Thanks,
>
> David
>>
>> jeff
>>
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJNd4irAAoJEBRtltQi2kC73SAH/jIC30j/CkWSV9rQGYn+gtfD
>> WiBXnbYxv7rc6PUqkT8U5I3upk/subJKlAhAQ1D1Eg6355QqpcMh7yZJGz20ovGc
>> CXQOK1ZbtCXvk6uZ8QamdfowojhkkxQo900c9mJtuaaevjywwt+MX3VwShNIrfbA
>> bKSIjHVeeZ2qwymNYHV8C82Zss5WA72FQqIpmlTlPKEwWFO49jLld/iXszyjC1cF
>> OWQdH37ZNgXARibaWI28KZCz5B39yz5F4mljVCyMS9XvNKzfwabT5FHj8btYzdAK
>> HYoAsBtONN/0/FJPn3I9VwyYC0q8M6tm9BgMyhhVmCU2PWMCt0jZJZA9aW/4X+o=
>> =R64B
>> -END PGP SIGNATURE-
>>
>

Re: fix for pr47837

[Xinliang David Li]

Sounds interesting. Do you have examples to illustrate your idea?

Thanks,

David

On Wed, Mar 9, 2011 at 1:45 AM, Richard Guenther
 wrote:
> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 03/08/11 11:55, Diego Novillo wrote:
>>> On 03/08/2011 12:54 PM, Xinliang David Li wrote:
 Please review the attached patch, it does some simplification of the
 complicated logical or expressions (x1 or x2 or x3 ...) constructed
 from control flow analysis into simpler form.

 Bootstraps and works on s390x for both testcases.

 Bootstraps on x86-64. Regression testing is on going (it takes forever
 (whole night already) to finish possibly because the lto test in
 c-torture ..).

 Ok for trunk?
>>>
>>> As a general comment, do you think we will start adding more and more of
>>> these special pattern matchers into uninit analysis?  I'm wondering how
>>> much effort should we make into creating something more generic.
>>>
>>> Right now it's this pattern, but there may be others.  It could grow
>>> pretty big and ugly.
>> We have a real problem in that our underlying analysis to eliminate
>> unexecutable edges is the CFG needs help, particularly for path
>> sensitive cases.
>>
>> Given that I'm seeing a real interest in other analysis that ultimately
>> have problems similar to those for uninitialized variable analysis,
>> building too much goo into tree-ssa-uninit doesn't seem like a long term
>> solution.
>
> True.  I've been repeatedly thinking of building some on-the-side CFG
> with value-numbered predicates to also catch the CFG vs. scalar-code
> predicate combinations we have.  On such on-the-side data structure
> we could do very aggressive jump-threading just for analysis purposes
> (experiments when working on separating conditions shows that
> a PRE-like algorithm could drive this).
>
> Thanks,
> Richard.
>

[Committed] S/390: Fix literal pool with -falign-labels

[Andreas Krebbel]

Hi,

on s390 (31 bit code with -mesa) the literal pool does not work when
using -falign-labels=

We rely on the literal pool base label being exact after the
instruction setting up the literal pool base pointer. Using
-falign-labels an ".align" command is emitted between the instruction
and the label which breaks all literal pool references.

The solution is similiar to what the sh target does.  The attached
patch defines the LABEL_ALIGN target macro and checks if right before
label there is a literal pool base insn.  If this is the case
alignment is suppressed.

Bootstrapped on s390. No regression.

This fixes the following testcase:
< FAIL: gcc.dg/falign-labels-1.c execution test

Committed to mainline

Bye,

-Andreas-


2011-03-09  Andreas Krebbel  

* config/s390/s390-protos.h (s390_label_align): New prototype.
* config/s390/s390.c (s390_label_align): New function.
* config/s390/s390.h (LABEL_ALIGN): New target macro definition.


Index: gcc/config/s390/s390-protos.h
===
*** gcc/config/s390/s390-protos.h.orig
--- gcc/config/s390/s390-protos.h
*** extern void s390_split_access_reg (rtx, 
*** 101,106 
--- 101,107 
  extern void print_operand_address (FILE *, rtx);
  extern void print_operand (FILE *, rtx, int);
  extern void s390_output_pool_entry (rtx, enum machine_mode, unsigned int);
+ extern int s390_label_align (rtx);
  extern int s390_agen_dep_p (rtx, rtx);
  extern rtx s390_load_got (void);
  extern rtx s390_get_thread_pointer (void);
Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** struct GTY(()) machine_function
*** 384,389 
--- 384,415 
 bytes on a z10 (or higher) CPU.  */
  #define PREDICT_DISTANCE (TARGET_Z10 ? 384 : 2048)
  
+ /* Return the alignment for LABEL.  We default to the -falign-labels
+value except for the literal pool base label.  */
+ int
+ s390_label_align (rtx label)
+ {
+   rtx prev_insn = prev_active_insn (label);
+ 
+   if (prev_insn == NULL_RTX)
+ goto old;
+ 
+   prev_insn = single_set (prev_insn);
+ 
+   if (prev_insn == NULL_RTX)
+ goto old;
+ 
+   prev_insn = SET_SRC (prev_insn);
+ 
+   /* Don't align literal pool base labels.  */
+   if (GET_CODE (prev_insn) == UNSPEC
+   && XINT (prev_insn, 1) == UNSPEC_MAIN_BASE)
+ return 0;
+ 
+  old:
+   return align_labels_log;
+ }
+ 
  static enum machine_mode
  s390_libgcc_cmp_return_mode (void)
  {
Index: gcc/config/s390/s390.h
===
*** gcc/config/s390/s390.h.orig
--- gcc/config/s390/s390.h
*** do {
\
*** 870,875 
--- 870,878 
  /* The LOCAL_LABEL_PREFIX variable is used by dbxelf.h.  */
  #define LOCAL_LABEL_PREFIX "."
  
+ #define LABEL_ALIGN(LABEL) \
+   s390_label_align (LABEL)
+ 
  /* How to refer to registers in assembler output.  This sequence is
 indexed by compiler's hard-register-number (see above).  */
  #define REGISTER_NAMES
\

Re: [PATCH][ARM] Fix RVCT interoperation issue

[Ramana Radhakrishnan]

On Fri, 2011-03-04 at 11:23 +, Andrew Stubbs wrote:
> The attached patch, submitted on behalf of Dan Jacobowitz, fixes an 
> unwind bug when using RealView and libgcc.
> 
> It's an old patch that has been in CodeSourcery and Linaro toolchains 
> for sometime, but somehow escaped being posted here.

I would like to see some context around this patch before accepting or
rejecting this, maybe a testcase (agreed that this is harder) or a
description of the problem this patch is attempting to fix. 

cheers
Ramana
-- 

Re: libgo patch committed: Only run net tests if GCCGO_RUN_ALL_TESTS

[Rainer Orth]

Ian Lance Taylor  writes:

> This patch to libgo only runs the networking dependent tests if
> GCCGO_RUN_ALL_TESTS is set in the environment.  This is PR 48017.  In
> that PR Rainer suggests having the tests drop back to UNSUPPORTED or
> UNRESOLVED if they fail to open a network connection.  That is tempting

My suggestion would have been to only change the test outcome for a `No
route to host' error (which would happen already for the DNS lookup).

> but I don't agree with it, because it means that the tests will never
> fail.  It might be better to have some way to test whether the network

Only if you change the test outcome for all errors, which obviously
isn't appropriate.

> is available and usable before running the tests.  However, that is in
> itself problematic, as people running all the gcc tests don't
> necessarily want their machine to start opening network connections.  So
> I think the compromise of requiring an environment variable works well.

Sort of works for me, but I fear that the tests will be only rarely be
run.  Perhaps the variable should be documented in the libgo/README*
files so at least libgo porters are aware of it.

Rainer

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

[PATCH][4.7] Fix the issue in PR13954

[Richard Guenther]

This fixes PR13954, not by doing SRA as requested but instead by
looking through memcpy during value-numbering (similar to what
we do for aggregate copies).  On its own it isn't that useful
as we still do not optimize the memcpy away itself (PR16427),
but that issue can be fixed in DCE with the returns-have-VOPs
prerequesite.

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

Richard.

2011-03-09  Richard Guenther  

PR tree-optimization/13954
* tree-ssa-sccvn.c (vn_reference_lookup_3): Look through memcpy
and friends.

* g++.dg/tree-ssa/pr13954.C: New testcase.

Index: gcc/tree-ssa-sccvn.c
===
*** gcc/tree-ssa-sccvn.c.orig   2011-03-08 16:50:33.0 +0100
--- gcc/tree-ssa-sccvn.c2011-03-09 15:45:44.0 +0100
*** vn_reference_lookup_3 (ao_ref *ref, tree
*** 1288,1294 
  {
vn_reference_t vr = (vn_reference_t)vr_;
gimple def_stmt = SSA_NAME_DEF_STMT (vuse);
-   tree fndecl;
tree base;
HOST_WIDE_INT offset, maxsize;
static VEC (vn_reference_op_s, heap) *lhs_ops = NULL;
--- 1288,1293 
*** vn_reference_lookup_3 (ao_ref *ref, tree
*** 1326,1335 
   from that defintion.
   1) Memset.  */
if (is_gimple_reg_type (vr->type)
!   && is_gimple_call (def_stmt)
!   && (fndecl = gimple_call_fndecl (def_stmt))
!   && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
!   && DECL_FUNCTION_CODE (fndecl) == BUILT_IN_MEMSET
&& integer_zerop (gimple_call_arg (def_stmt, 1))
&& host_integerp (gimple_call_arg (def_stmt, 2), 1)
&& TREE_CODE (gimple_call_arg (def_stmt, 0)) == ADDR_EXPR)
--- 1325,1331 
   from that defintion.
   1) Memset.  */
if (is_gimple_reg_type (vr->type)
!   && gimple_call_builtin_p (def_stmt, BUILT_IN_MEMSET)
&& integer_zerop (gimple_call_arg (def_stmt, 1))
&& host_integerp (gimple_call_arg (def_stmt, 2), 1)
&& TREE_CODE (gimple_call_arg (def_stmt, 0)) == ADDR_EXPR)
*** vn_reference_lookup_3 (ao_ref *ref, tree
*** 1379,1385 
}
  }
  
!   /* For aggregate copies translate the reference through them if
   the copy kills ref.  */
else if (vn_walk_kind == VN_WALKREWRITE
   && gimple_assign_single_p (def_stmt)
--- 1375,1381 
}
  }
  
!   /* 3) For aggregate copies translate the reference through them if
   the copy kills ref.  */
else if (vn_walk_kind == VN_WALKREWRITE
   && gimple_assign_single_p (def_stmt)
*** vn_reference_lookup_3 (ao_ref *ref, tree
*** 1450,1455 
--- 1446,1592 
vr->hashcode = vn_reference_compute_hash (vr);
  
/* Adjust *ref from the new operands.  */
+   if (!ao_ref_init_from_vn_reference (&r, vr->set, vr->type, 
vr->operands))
+   return (void *)-1;
+   /* This can happen with bitfields.  */
+   if (ref->size != r.size)
+   return (void *)-1;
+   *ref = r;
+ 
+   /* Do not update last seen VUSE after translating.  */
+   last_vuse_ptr = NULL;
+ 
+   /* Keep looking for the adjusted *REF / VR pair.  */
+   return NULL;
+ }
+ 
+   /* 4) For memcpy copies translate the reference through them if
+  the copy kills ref.  */
+   else if (vn_walk_kind == VN_WALKREWRITE
+  && is_gimple_reg_type (vr->type)
+  /* ???  Handle BCOPY as well.  */
+  && (gimple_call_builtin_p (def_stmt, BUILT_IN_MEMCPY)
+  || gimple_call_builtin_p (def_stmt, BUILT_IN_MEMPCPY)
+  || gimple_call_builtin_p (def_stmt, BUILT_IN_MEMMOVE))
+  && (TREE_CODE (gimple_call_arg (def_stmt, 0)) == ADDR_EXPR
+  || TREE_CODE (gimple_call_arg (def_stmt, 0)) == SSA_NAME)
+  && (TREE_CODE (gimple_call_arg (def_stmt, 1)) == ADDR_EXPR
+  || TREE_CODE (gimple_call_arg (def_stmt, 1)) == SSA_NAME)
+  && host_integerp (gimple_call_arg (def_stmt, 2), 1))
+ {
+   tree lhs, rhs;
+   ao_ref r;
+   HOST_WIDE_INT rhs_offset, copy_size, lhs_offset;
+   vn_reference_op_s op;
+   HOST_WIDE_INT at;
+ 
+ 
+   /* Only handle non-variable, addressable refs.  */
+   if (ref->size != maxsize
+ || offset % BITS_PER_UNIT != 0
+ || ref->size % BITS_PER_UNIT != 0)
+   return (void *)-1;
+ 
+   /* Extract a pointer base and an offset for the destination.  */
+   lhs = gimple_call_arg (def_stmt, 0);
+   lhs_offset = 0;
+   if (TREE_CODE (lhs) == SSA_NAME)
+   lhs = SSA_VAL (lhs);
+   if (TREE_CODE (lhs) == ADDR_EXPR)
+   {
+ tree tem = get_addr_base_and_unit_offset (TREE_OPERAND (lhs, 0),
+   &lhs_offset);
+ if (!tem)
+   return (void *)-1;
+ if (TREE_CODE (tem) == MEM_REF
+ && host_integerp (TREE_OPERAND (tem, 1), 1))
+   {
+ lhs = TREE_OPERAND (tem, 0);
+ 

Re: [PATCH][4.7][RFC] Fix store-sinking, make returns have a VUSE

[Diego Novillo]

On Wed, Mar 9, 2011 at 10:26, Richard Guenther  wrote:

> I have just forward ported this patch to trunk and don't remember
> whether it caused any problems back when I originally worked on this
> (IIRC it was during stage3 of 4.5).  So, this is just a heads-up
> in case you have any issues with having more virtual operands.

Not at all.  This looks useful.


Diego.

[PATCH][4.7][RFC] Fix store-sinking, make returns have a VUSE

[Richard Guenther]

This old patch of mine makes the return statement of a function
have a VUSE even if it does not return a value (or does not reference
memory).  This is to have a virtual operand chain for values that
escape the function via returns.

This allows to fix store-sinking to do its job again by simply using
the fact that we always will have a PHI node merging the virtual
operands (which does not happen right now if there is no load or
store following the location we want to sink to).

I have just forward ported this patch to trunk and don't remember
whether it caused any problems back when I originally worked on this
(IIRC it was during stage3 of 4.5).  So, this is just a heads-up
in case you have any issues with having more virtual operands.

If the patch happens to bootstrap and test ok I plan to commit this
somewhen during stage1.

Richard.

2011-03-09  Richard Guenther  

PR tree-optimization/41490
* tree-ssa-dce.c (propagate_necessity): Handle returns without
value but with VUSE.
* tree-ssa-operands.c (parse_ssa_operands): Add a VUSE on all
return statements.
* tree-ssa-sink.c (statement_sink_location): Fix store sinking.

* gcc.dg/tree-ssa/ssa-sink-6.c: New testcase.
* gcc.dg/tree-ssa/ssa-sink-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-sink-8.c: Likewise.
* gcc.dg/tree-ssa/ssa-sink-9.c: Likewise.

Index: gcc/tree-ssa-dce.c
===
*** gcc/tree-ssa-dce.c.orig 2011-02-23 16:18:20.0 +0100
--- gcc/tree-ssa-dce.c  2011-03-09 15:58:34.0 +0100
*** propagate_necessity (struct edge_list *e
*** 869,875 
{
  tree rhs = gimple_return_retval (stmt);
  /* A return statement may perform a load.  */
! if (TREE_CODE (rhs) != SSA_NAME
  && !is_gimple_min_invariant (rhs))
{
  if (!ref_may_be_aliased (rhs))
--- 869,876 
{
  tree rhs = gimple_return_retval (stmt);
  /* A return statement may perform a load.  */
! if (rhs
! && TREE_CODE (rhs) != SSA_NAME
  && !is_gimple_min_invariant (rhs))
{
  if (!ref_may_be_aliased (rhs))
Index: gcc/tree-ssa-operands.c
===
*** gcc/tree-ssa-operands.c.orig2010-11-30 15:31:11.0 +0100
--- gcc/tree-ssa-operands.c 2011-03-09 15:58:34.0 +0100
*** parse_ssa_operands (gimple stmt)
*** 1065,1070 
--- 1065,1073 
/* Add call-clobbered operands, if needed.  */
if (code == GIMPLE_CALL)
maybe_add_call_vops (stmt);
+ 
+   if (code == GIMPLE_RETURN)
+   append_vuse (gimple_vop (cfun));
  }
  }
  
Index: gcc/tree-ssa-sink.c
===
*** gcc/tree-ssa-sink.c.orig2011-02-15 15:08:49.0 +0100
--- gcc/tree-ssa-sink.c 2011-03-09 16:08:46.0 +0100
*** statement_sink_location (gimple stmt, ba
*** 276,299 
ssa_op_iter iter;
imm_use_iterator imm_iter;
  
!   FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_ALL_DEFS)
! {
!   FOR_EACH_IMM_USE_FAST (one_use, imm_iter, def)
!   {
! if (is_gimple_debug (USE_STMT (one_use)))
!   continue;
! 
! break;
!   }
!   if (one_use != NULL_USE_OPERAND_P)
! break;
! }
  
!   /* Return if there are no immediate uses of this stmt.  */
!   if (one_use == NULL_USE_OPERAND_P)
  return false;
  
!   if (gimple_code (stmt) != GIMPLE_ASSIGN)
  return false;
  
/* There are a few classes of things we can't or don't move, some because we
--- 276,292 
ssa_op_iter iter;
imm_use_iterator imm_iter;
  
!   /* We only can sink assignments.  */
!   if (!is_gimple_assign (stmt))
! return false;
  
!   /* We only can sink stmts with a single definition.  */
!   def_p = single_ssa_def_operand (stmt, SSA_OP_ALL_DEFS);
!   if (def_p == NULL_DEF_OPERAND_P)
  return false;
  
!   /* Return if there are no immediate uses of this stmt.  */
!   if (has_zero_uses (DEF_FROM_PTR (def_p)))
  return false;
  
/* There are a few classes of things we can't or don't move, some because we
*** statement_sink_location (gimple stmt, ba
*** 323,342 
*/
if (stmt_ends_bb_p (stmt)
|| gimple_has_side_effects (stmt)
-   || is_hidden_global_store (stmt)
|| gimple_has_volatile_ops (stmt)
!   || gimple_vuse (stmt)
|| (cfun->has_local_explicit_reg_vars
  && TYPE_MODE (TREE_TYPE (gimple_assign_lhs (stmt))) == BLKmode))
  return false;
  
!   FOR_EACH_SSA_DEF_OPERAND (def_p, stmt, iter, SSA_OP_ALL_DEFS)
! {
!   tree def = DEF_FROM_PTR (def_p);
!   if (is_global_var (SSA_NAME_VAR (def))
! || SSA_NAME_OCCURS_IN_ABNORMAL_PHI (def))
!  

Re: Build regression [Re: [patch libiberty include]: Add additional helper functions for directory-separator searching]

[Jan Kratochvil]

On Wed, 09 Mar 2011 16:02:36 +0100, Pedro Alves wrote:
> Thanks, had forgotten --enable-targets=all.  Sorry about that.

It builds now OK.


Thanks,
Jan

Re: Build regression [Re: [patch libiberty include]: Add additional helper functions for directory-separator searching]

[Pedro Alves]

On Wednesday 09 March 2011 14:37:15, Jan Kratochvil wrote:
> On Wed, 09 Mar 2011 13:58:38 +0100, Pedro Alves wrote:
> > Thanks.  I've applied it.
> 
> nto-tdep.c:130:8: error: assignment discards ‘const’ qualifier from pointer 
> target type [-Werror]

Thanks, had forgotten --enable-targets=all.  Sorry about that.

Applied.

-- 
Pedro Alves

2011-03-09  Pedro Alves  

gdb/
* nto-tdep.c (nto_find_and_open_solib): Constify local `base'.

---
 gdb/nto-tdep.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: src/gdb/nto-tdep.c
===
--- src.orig/gdb/nto-tdep.c 2011-03-09 12:47:34.0 +
+++ src/gdb/nto-tdep.c  2011-03-09 14:56:44.18280 +
@@ -89,7 +89,8 @@ nto_map_arch_to_cputype (const char *arc
 int
 nto_find_and_open_solib (char *solib, unsigned o_flags, char **temp_pathname)
 {
-  char *buf, *arch_path, *nto_root, *endian, *base;
+  char *buf, *arch_path, *nto_root, *endian;
+  const char *base;
   const char *arch;
   int ret;
 #define PATH_FMT \

Build regression [Re: [patch libiberty include]: Add additional helper functions for directory-separator searching]

[Jan Kratochvil]

On Wed, 09 Mar 2011 13:58:38 +0100, Pedro Alves wrote:
> Thanks.  I've applied it.

nto-tdep.c:130:8: error: assignment discards ‘const’ qualifier from pointer 
target type [-Werror]

gcc-4.6.0-0.12.fc15.x86_64
--with-system-zlib --enable-64-bit-bfd --enable-targets=all --enable-static 
--disable-shared --enable-debug --disable-sim --enable-gold 
--with-separate-debug-dir=/usr/lib/debug CC=gcc CFLAGS=-m64 -ggdb2 -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 LDFLAGS= -lmcheck

commit 7403e6b3f0f7d4c4f80703486f602ee5e2c9a3dd
Author: Pedro Alves 
Date:   Wed Mar 9 12:48:53 2011 +

* cli/cli-cmds.c (shell_escape): Use lbasename.
* coffread.c (coff_start_symtab): Constify parameter.
(complete_symtab): Constify `name' parameter.
(coff_symtab_read): Constify `filestring' local.
(coff_getfilename): Constify return and `result' local.
Use lbasename.
* fbsd-nat.c (fbsd_make_corefile_notes): Use lbasename.
* linux-fork.c (info_checkpoints_command): Use lbasename.
* linux-nat.c (linux_nat_make_corefile_notes): Use lbasename.
* minsyms.c (lookup_minimal_symbol): Use lbasename.
* nto-tdep.c (nto_find_and_open_solib): Use lbasename.
* procfs.c (procfs_make_note_section): Use lbasename.
* tui/tui-io.c (printable_part): Constity return and parameter.
Use lbasename.
(print_filename): Constify parameters, and local `s'.
(tui_rl_display_match_list): Constify local `temp'.


Thanks,
Jan

Re: fix for pr47837

[Richard Guenther]

On Wed, Mar 9, 2011 at 3:03 PM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/09/11 02:45, Richard Guenther wrote:
>> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>
>> True.  I've been repeatedly thinking of building some on-the-side CFG
>> with value-numbered predicates to also catch the CFG vs. scalar-code
>> predicate combinations we have.  On such on-the-side data structure
>> we could do very aggressive jump-threading just for analysis purposes
>> (experiments when working on separating conditions shows that
>> a PRE-like algorithm could drive this).
> I'm pondering the same kind of thing.  PRE on the predicates with a more
> structured approach to block copying to isolate the paths seems to be
> the way to go.

FYI I was talking about
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg02098.html, a start to
force preidcate computations to separate
statements.  First post for the idea was at
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01001.html

Richard.

> jeff
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNd4irAAoJEBRtltQi2kC73SAH/jIC30j/CkWSV9rQGYn+gtfD
> WiBXnbYxv7rc6PUqkT8U5I3upk/subJKlAhAQ1D1Eg6355QqpcMh7yZJGz20ovGc
> CXQOK1ZbtCXvk6uZ8QamdfowojhkkxQo900c9mJtuaaevjywwt+MX3VwShNIrfbA
> bKSIjHVeeZ2qwymNYHV8C82Zss5WA72FQqIpmlTlPKEwWFO49jLld/iXszyjC1cF
> OWQdH37ZNgXARibaWI28KZCz5B39yz5F4mljVCyMS9XvNKzfwabT5FHj8btYzdAK
> HYoAsBtONN/0/FJPn3I9VwyYC0q8M6tm9BgMyhhVmCU2PWMCt0jZJZA9aW/4X+o=
> =R64B
> -END PGP SIGNATURE-
>

Re: fix for pr47837

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/09/11 02:45, Richard Guenther wrote:
> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:

> True.  I've been repeatedly thinking of building some on-the-side CFG
> with value-numbered predicates to also catch the CFG vs. scalar-code
> predicate combinations we have.  On such on-the-side data structure
> we could do very aggressive jump-threading just for analysis purposes
> (experiments when working on separating conditions shows that
> a PRE-like algorithm could drive this).
I'm pondering the same kind of thing.  PRE on the predicates with a more
structured approach to block copying to isolate the paths seems to be
the way to go.

jeff


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNd4irAAoJEBRtltQi2kC73SAH/jIC30j/CkWSV9rQGYn+gtfD
WiBXnbYxv7rc6PUqkT8U5I3upk/subJKlAhAQ1D1Eg6355QqpcMh7yZJGz20ovGc
CXQOK1ZbtCXvk6uZ8QamdfowojhkkxQo900c9mJtuaaevjywwt+MX3VwShNIrfbA
bKSIjHVeeZ2qwymNYHV8C82Zss5WA72FQqIpmlTlPKEwWFO49jLld/iXszyjC1cF
OWQdH37ZNgXARibaWI28KZCz5B39yz5F4mljVCyMS9XvNKzfwabT5FHj8btYzdAK
HYoAsBtONN/0/FJPn3I9VwyYC0q8M6tm9BgMyhhVmCU2PWMCt0jZJZA9aW/4X+o=
=R64B
-END PGP SIGNATURE-

Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

[Eli Zaretskii]

> From: Pedro Alves 
> Date: Wed, 9 Mar 2011 12:58:38 +
> Cc: gdb-patc...@sourceware.org,
>  d...@redhat.com,
>  ktiet...@googlemail.com,
>  binut...@sourceware.org,
>  gcc-patches@gcc.gnu.org
> 
> > > The one's left are: 1 in a linux-native only file (never cares
> > > for other filesystem semantics), and a couple in the coff and
> > > mdebug readers.  The latter could be rewritten in terms of
> > > lbasename, but I'm not sure whether gcc outputs a literal '/' in
> > > that case even when building on mingw.  If so, and we changed them,
> > > we'd be breaking reading these files on Windows
> > 
> > Sorry, I don't understand how would that break on Windows.  Could you
> > elaborate?  And what "couple of coff and mdebug readers" did you have
> > in mind?
> 
> Sorry, in the hurry, I had a (another) brain cramp.  Wouldn't break.
> Still it'd be useless to change this _if_ gcc hardcodes '/'.  Dunno
> whether it does.

At least on MinGW, GCC simply uses whatever was passed on the command
line.  I tested that by compiling the same source file, passing it to
GCC with different flavors of slashes, including mixed ones.  Then in
GDB I typed "info sources" and saw the source file with exactly the
same flavor of slashes as what I typed on the GCC command line.

Funnily enough, when the file name given to GCC includes at least one
backslash, "info sources" shows the same file twice, like this:

  (gdb) info sources
  Source files for which symbols have been read in:



  Source files for which symbols will be read in on demand:

  d:/usr/eli/data/dbw.c, d:\usr\eli/data\dbw.c

This is with GDB 7.2 and GCC 3.4.2.  That means we compare files with
strcmp/strcasecmp somewhere, and don't know that / and \ are
equivalent here.  Or maybe it's a bug in the ancient version of GCC I
use.

Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

[Pedro Alves]

On Wednesday 09 March 2011 12:35:00, Eli Zaretskii wrote:
> > I meant a valid use case in the code bases.
> 
> Sorry for my misunderstanding.

NP.

> 
> > Might as well cook up a (gdb) patch.  Find it pasted below.  Does it
> > look good to you?
> 
> Yes, looks fine.  Thanks.

Thanks.  I've applied it.

> > The one's left are: 1 in a linux-native only file (never cares
> > for other filesystem semantics), and a couple in the coff and
> > mdebug readers.  The latter could be rewritten in terms of
> > lbasename, but I'm not sure whether gcc outputs a literal '/' in
> > that case even when building on mingw.  If so, and we changed them,
> > we'd be breaking reading these files on Windows
> 
> Sorry, I don't understand how would that break on Windows.  Could you
> elaborate?  And what "couple of coff and mdebug readers" did you have
> in mind?

Sorry, in the hurry, I had a (another) brain cramp.  Wouldn't break.
Still it'd be useless to change this _if_ gcc hardcodes '/'.  Dunno
whether it does.

>find . -name "*.c" | xargs grep strrchr | grep "'/'"
./linux-thread-db.c:cp = strrchr (path, '/');
./mdebugread.c:   p = strrchr (namestring, '/');
./dbxread.c:p = strrchr (namestring, '/');

Both look like this:

/* Some compilers (including gcc) emit a pair of initial N_SOs.
   The first one is a directory name; the second the file name.
   If pst exists, is empty, and has a filename ending in '/',
   we assume the previous N_SO was a directory name.  */

p = strrchr (namestring, '/');
if (p && *(p + 1) == '\000')
  {
/* Save the directory name SOs locally, then save it into
   the psymtab when it's created below.  */
dirname_nso = namestring;
continue;   
  }

-- 
Pedro Alves

Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

[Eli Zaretskii]

> From: Pedro Alves 
> Date: Wed, 9 Mar 2011 11:46:36 +
> Cc: gdb-patc...@sourceware.org,
>  d...@redhat.com,
>  ktiet...@googlemail.com,
>  binut...@sourceware.org,
>  gcc-patches@gcc.gnu.org
> 
> On Wednesday 09 March 2011 05:29:09, Eli Zaretskii wrote:
> > > Actually, is there any case where lbasename wouldn't
> > > work instead of filename_dirrchr?
> > 
> > Almost: lbasename returns a pointer one character after the last
> > slash.  It also skips the drive letter on DOS/Windows (which might be
> > TRT, actually).
> 
> I meant a valid use case in the code bases.

Sorry for my misunderstanding.

> Might as well cook up a (gdb) patch.  Find it pasted below.  Does it
> look good to you?

Yes, looks fine.  Thanks.

> The one's left are: 1 in a linux-native only file (never cares
> for other filesystem semantics), and a couple in the coff and
> mdebug readers.  The latter could be rewritten in terms of
> lbasename, but I'm not sure whether gcc outputs a literal '/' in
> that case even when building on mingw.  If so, and we changed them,
> we'd be breaking reading these files on Windows

Sorry, I don't understand how would that break on Windows.  Could you
elaborate?  And what "couple of coff and mdebug readers" did you have
in mind?

Re: [c++, PR 47714] Reset the addressable flag of thunk PARM_DECLs

[Eric Botcazou]

> 2011-03-08  Martin Jambor  
>
>   PR tree-optimization/47714
>   * cp/method.c (use_thunk): Clear addressable flag of thunk arguments.

This should go in cp/ChangeLog without the cp/ prefix.

-- 
Eric Botcazou

[c++, PR 47714] Reset the addressable flag of thunk PARM_DECLs

[Martin Jambor]

Hi,

the patch below fixes PR 47714.  The problem is that as thunk function
declarations are built, their PARM_DECLs are copied from the thunked
function together with their TREE_ADDRESSABLE flags.  This then means
the parameters are not considered gimple registers when they are
supposed to be converted to SSA which makes the SSA verifier very
unhappy later.  The solution is to clear the addressable flag for the
PARM_DECLs which reflects the reality as their addresses are not taken
in thunks.

The fix seems to be rather obvious (and Jakub wrote that in bugzilla
too) and the bug is a P1 which can potentially postpone the release so
my plan is to take the liberty and commit it if no-one stops me in the
next few hours.  Needless to say, the patch has been successfully
bootstrapped and tested on x86_64-linux.

Thanks,

Martin


2011-03-08  Martin Jambor  

PR tree-optimization/47714
* cp/method.c (use_thunk): Clear addressable flag of thunk arguments.

* testsuite/g++.dg/torture/pr47714.C: New test.

Index: src/gcc/cp/method.c
===
--- src.orig/gcc/cp/method.c
+++ src/gcc/cp/method.c
@@ -372,6 +372,7 @@ use_thunk (tree thunk_fndecl, bool emit_
   DECL_CONTEXT (x) = thunk_fndecl;
   SET_DECL_RTL (x, NULL);
   DECL_HAS_VALUE_EXPR_P (x) = 0;
+  TREE_ADDRESSABLE (x) = 0;
   t = x;
 }
   a = nreverse (t);
Index: src/gcc/testsuite/g++.dg/torture/pr47714.C
===
--- /dev/null
+++ src/gcc/testsuite/g++.dg/torture/pr47714.C
@@ -0,0 +1,16 @@
+struct A { virtual ~A () {} };
+struct B { virtual ~B () {} };
+struct C { virtual const A *foo (int) const = 0; };
+struct E : public B, public A { };
+struct F : public C
+{
+  virtual const E *foo (int) const;
+};
+void bar (int &);
+
+const E *
+F::foo (int x) const
+{
+  bar (x);
+  return __null;
+}

Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

[Pedro Alves]

On Wednesday 09 March 2011 05:29:09, Eli Zaretskii wrote:
> > Actually, is there any case where lbasename wouldn't
> > work instead of filename_dirrchr?
> 
> Almost: lbasename returns a pointer one character after the last
> slash.  It also skips the drive letter on DOS/Windows (which might be
> TRT, actually).

I meant a valid use case in the code bases.  Might as
well cook up a (gdb) patch.  Find it pasted below.  Does it look good to you?

The one's left are: 1 in a linux-native only file (never cares
for other filesystem semantics), and a couple in the coff and
mdebug readers.  The latter could be rewritten in terms of
lbasename, but I'm not sure whether gcc outputs a literal '/' in
that case even when building on mingw.  If so, and we changed them,
we'd be breaking reading these files on Windows, so I'd rather
change them only if proven necessary.  (remember the source vs host
path distinction we're missing)

> It would be reasonable to rewrite filename_dirrchr in terms of
> lbasename, though, by backing up the pointer returned by lbasename if
> it points to a slash, and otherwise returning NULL.  The case of
> "d:foo" should also be resolved (probably, return a pointer to the
> colon).

The means it's just an adapter, and callers could be rewritten
a little to think in terms of lbasename.  The only case where
I imagine filename_dirrchr would be a little bit more efficient,
is when breaking up path directories components from right
to left, for step-wise comparison with another path, say.
IMO, the less code to maintain and the fewer the APIs
readers have to understand, the better.

I did a:

 grep strrchr * | grep "'/'"

under gcc and all the cases I saw could/should
be using lbasename.  I suggest gcc folks fix that first
before anything else.

-- 
Pedro Alves

2011-03-09  Pedro Alves  

gdb/
* cli/cli-cmds.c (shell_escape): Use lbasename.
* coffread.c (coff_start_symtab): Constify parameter.
(complete_symtab): Constify `name' parameter.
(coff_symtab_read): Constify `filestring' local.
(coff_getfilename): Constify return and `result' local.
Use lbasename.
* fbsd-nat.c (fbsd_make_corefile_notes): Use lbasename.
* linux-fork.c (info_checkpoints_command): Use lbasename.
* linux-nat.c (linux_nat_make_corefile_notes): Use lbasename.
* minsyms.c (lookup_minimal_symbol): Use lbasename.
* nto-tdep.c (nto_find_and_open_solib): Use lbasename.
* procfs.c (procfs_make_note_section): Use lbasename.
* tui/tui-io.c (printable_part): Constity return and parameter.
Use lbasename.
(print_filename): Constify parameters, and local `s'.
(tui_rl_display_match_list): Constify local `temp'.

---
 gdb/cli/cli-cmds.c |7 ++-
 gdb/coffread.c |   15 +++
 gdb/fbsd-nat.c |2 +-
 gdb/linux-fork.c   |9 +
 gdb/linux-nat.c|2 +-
 gdb/minsyms.c  |7 +--
 gdb/nto-tdep.c |8 +---
 gdb/procfs.c   |2 +-
 gdb/tui/tui-io.c   |   22 ++
 9 files changed, 21 insertions(+), 53 deletions(-)

Index: src/gdb/cli/cli-cmds.c
===
--- src.orig/gdb/cli/cli-cmds.c 2011-03-09 10:53:22.06283 +
+++ src/gdb/cli/cli-cmds.c  2011-03-09 11:14:37.67287 +
@@ -730,16 +730,13 @@ shell_escape (char *arg, int from_tty)
 
   if ((pid = vfork ()) == 0)
 {
-  char *p, *user_shell;
+  const char *p, *user_shell;
 
   if ((user_shell = (char *) getenv ("SHELL")) == NULL)
user_shell = "/bin/sh";
 
   /* Get the name of the shell for arg0.  */
-  if ((p = strrchr (user_shell, '/')) == NULL)
-   p = user_shell;
-  else
-   p++;/* Get past '/' */
+  p = lbasename (user_shell);
 
   if (!arg)
execl (user_shell, p, (char *) 0);
Index: src/gdb/coffread.c
===
--- src.orig/gdb/coffread.c 2011-03-09 10:53:22.06283 +
+++ src/gdb/coffread.c  2011-03-09 11:14:37.67287 +
@@ -178,7 +178,7 @@ static int init_lineno (bfd *, long, int
 
 static char *getsymname (struct internal_syment *);
 
-static char *coff_getfilename (union internal_auxent *);
+static const char *coff_getfilename (union internal_auxent *);
 
 static void free_stringtab (void);
 
@@ -366,7 +366,7 @@ coff_alloc_type (int index)
it indicates the start of data for one original source file.  */
 
 static void
-coff_start_symtab (char *name)
+coff_start_symtab (const char *name)
 {
   start_symtab (
   /* We fill in the filename later.  start_symtab puts this pointer
@@ -388,7 +388,7 @@ coff_start_symtab (char *name)
text.  */
 
 static void
-complete_symtab (char *name, CORE_ADDR start_addr, unsigned int size)
+complete_symtab (const char *name, CORE_ADDR start_addr, unsigned int size)
 {
   if (last_source_file != NULL)
 xfree (last_sour

Re: [PATCH] Fix MEM_IN_STRUCT_P/MEM_SCALAR_P during expansion (PR rtl-optimization/47866)

[Richard Guenther]

On Wed, Mar 9, 2011 at 10:58 AM, Jakub Jelinek  wrote:
> On Wed, Mar 09, 2011 at 10:55:39AM +0100, Richard Guenther wrote:
>> On Wed, Mar 9, 2011 at 9:40 AM, Eric Botcazou  wrote:
>> >> and as t isn't AGGREGATE_TYPE nor COMPLEX_TYPE and is a decl,
>> >> it is marked MEM_SCALAR_P and e.g. set_mem_attributes_minus_bitpos
>> >> once MEM_SCALAR_P is set doesn't change it to MEM_IN_STRUCT_P
>> >> because of BIT_FIELD_REF etc.  The BIT_FIELD_REF  = 1
>> >> stores are done through store_field though, and for some reason
>> >> the code sets MEM_IN_STRUCT_P in that codepath unconditionally.
>> >
>> > The irony of marking something scalar when its type is VECTOR_TYPE...
>> >
>> >> Changing this fixes the testcase, bootstrapped/regtested on x86_64-linux
>> >> and i686-linux.  I'll try to test this on ia64-linux tomorrow.
>> >>
>> >> 2011-03-08  Jakub Jelinek  
>> >>
>> >>       PR rtl-optimization/47866
>> >>       * expr.c (store_field): If MEM_SCALAR_P (target), don't use
>> >>       MEM_SET_IN_STRUCT_P (to_rtx, 1), just set MEM_IN_STRUCT_P (to_rtx)
>> >>       if target wasn't scalar.
>> >
>> > I cannot formally approve, but I think it's the way to go.
>>
>> Yes, this is ok.
>
> In the posted form or in the proposed.  ia64-linux base regtest is still
> pending, once it finishes will bootstrap/regtest whatever patch you prefer.

The patch below is ok.

Thanks,
Richard.

> 2011-03-09  Jakub Jelinek  
>
>        PR rtl-optimization/47866
>        * expr.c (store_field): If MEM_SCALAR_P (target), don't use
>        MEM_SET_IN_STRUCT_P (to_rtx, 1), just set MEM_IN_STRUCT_P (to_rtx)
>        if target wasn't scalar.
>        * function.c (assign_stack_temp_for_type): Assert that neither
>        MEM_SCALAR_P nor MEM_IN_STRUCT_P is set previously, set either
>        MEM_IN_STRUCT_P or MEM_SCALAR_P instead of using MEM_SET_IN_STRUCT_P
>        macro.
>        * rtl.h (MEM_SET_IN_STRUCT_P): Removed.
>
> --- gcc/expr.c.jj       2011-02-04 16:45:02.0 +0100
> +++ gcc/expr.c  2011-03-08 20:49:19.531545778 +0100
> @@ -5924,7 +5924,8 @@ store_field (rtx target, HOST_WIDE_INT b
>       if (to_rtx == target)
>        to_rtx = copy_rtx (to_rtx);
>
> -      MEM_SET_IN_STRUCT_P (to_rtx, 1);
> +      if (!MEM_SCALAR_P (to_rtx))
> +       MEM_IN_STRUCT_P (to_rtx) = 1;
>       if (!MEM_KEEP_ALIAS_SET_P (to_rtx) && MEM_ALIAS_SET (to_rtx) != 0)
>        set_mem_alias_set (to_rtx, alias_set);
>
> --- gcc/function.c.jj   2011-03-04 19:39:17.0 +0100
> +++ gcc/function.c      2011-03-09 09:52:47.428670935 +0100
> @@ -942,8 +942,11 @@ assign_stack_temp_for_type (enum machine
>   if (type != 0)
>     {
>       MEM_VOLATILE_P (slot) = TYPE_VOLATILE (type);
> -      MEM_SET_IN_STRUCT_P (slot, (AGGREGATE_TYPE_P (type)
> -                                 || TREE_CODE (type) == COMPLEX_TYPE));
> +      gcc_checking_assert (!MEM_SCALAR_P (slot) && !MEM_IN_STRUCT_P (slot));
> +      if (AGGREGATE_TYPE_P (type) || TREE_CODE (type) == COMPLEX_TYPE)
> +       MEM_IN_STRUCT_P (slot) = 1;
> +      else
> +       MEM_SCALAR_P (slot) = 1;
>     }
>   MEM_NOTRAP_P (slot) = 1;
>
> --- gcc/rtl.h.jj        2011-02-28 18:02:20.0 +0100
> +++ gcc/rtl.h   2011-03-09 09:48:58.858400436 +0100
> @@ -1279,24 +1279,6 @@ do {                                                   
>                   \
>  #define MEM_NOTRAP_P(RTX) \
>   (RTL_FLAG_CHECK1("MEM_NOTRAP_P", (RTX), MEM)->call)
>
> -/* If VAL is nonzero, set MEM_IN_STRUCT_P and clear MEM_SCALAR_P in
> -   RTX.  Otherwise, vice versa.  Use this macro only when you are
> -   *sure* that you know that the MEM is in a structure, or is a
> -   scalar.  VAL is evaluated only once.  */
> -#define MEM_SET_IN_STRUCT_P(RTX, VAL)          \
> -do {                                           \
> -  if (VAL)                                     \
> -    {                                          \
> -      MEM_IN_STRUCT_P (RTX) = 1;               \
> -      MEM_SCALAR_P (RTX) = 0;                  \
> -    }                                          \
> -  else                                         \
> -    {                                          \
> -      MEM_IN_STRUCT_P (RTX) = 0;               \
> -      MEM_SCALAR_P (RTX) = 1;                  \
> -    }                                          \
> -} while (0)
> -
>  /* The memory attribute block.  We provide access macros for each value
>    in the block and provide defaults if none specified.  */
>  #define MEM_ATTRS(RTX) X0MEMATTR (RTX, 1)
>
>
>        Jakub
>

Re: [PATCH] Fix MEM_IN_STRUCT_P/MEM_SCALAR_P during expansion (PR rtl-optimization/47866)

[Jakub Jelinek]

On Wed, Mar 09, 2011 at 10:55:39AM +0100, Richard Guenther wrote:
> On Wed, Mar 9, 2011 at 9:40 AM, Eric Botcazou  wrote:
> >> and as t isn't AGGREGATE_TYPE nor COMPLEX_TYPE and is a decl,
> >> it is marked MEM_SCALAR_P and e.g. set_mem_attributes_minus_bitpos
> >> once MEM_SCALAR_P is set doesn't change it to MEM_IN_STRUCT_P
> >> because of BIT_FIELD_REF etc.  The BIT_FIELD_REF  = 1
> >> stores are done through store_field though, and for some reason
> >> the code sets MEM_IN_STRUCT_P in that codepath unconditionally.
> >
> > The irony of marking something scalar when its type is VECTOR_TYPE...
> >
> >> Changing this fixes the testcase, bootstrapped/regtested on x86_64-linux
> >> and i686-linux.  I'll try to test this on ia64-linux tomorrow.
> >>
> >> 2011-03-08  Jakub Jelinek  
> >>
> >>       PR rtl-optimization/47866
> >>       * expr.c (store_field): If MEM_SCALAR_P (target), don't use
> >>       MEM_SET_IN_STRUCT_P (to_rtx, 1), just set MEM_IN_STRUCT_P (to_rtx)
> >>       if target wasn't scalar.
> >
> > I cannot formally approve, but I think it's the way to go.
> 
> Yes, this is ok.

In the posted form or in the proposed.  ia64-linux base regtest is still
pending, once it finishes will bootstrap/regtest whatever patch you prefer.

2011-03-09  Jakub Jelinek  

PR rtl-optimization/47866
* expr.c (store_field): If MEM_SCALAR_P (target), don't use
MEM_SET_IN_STRUCT_P (to_rtx, 1), just set MEM_IN_STRUCT_P (to_rtx)
if target wasn't scalar.
* function.c (assign_stack_temp_for_type): Assert that neither
MEM_SCALAR_P nor MEM_IN_STRUCT_P is set previously, set either
MEM_IN_STRUCT_P or MEM_SCALAR_P instead of using MEM_SET_IN_STRUCT_P
macro.
* rtl.h (MEM_SET_IN_STRUCT_P): Removed.

--- gcc/expr.c.jj   2011-02-04 16:45:02.0 +0100
+++ gcc/expr.c  2011-03-08 20:49:19.531545778 +0100
@@ -5924,7 +5924,8 @@ store_field (rtx target, HOST_WIDE_INT b
   if (to_rtx == target)
to_rtx = copy_rtx (to_rtx);
 
-  MEM_SET_IN_STRUCT_P (to_rtx, 1);
+  if (!MEM_SCALAR_P (to_rtx))
+   MEM_IN_STRUCT_P (to_rtx) = 1;
   if (!MEM_KEEP_ALIAS_SET_P (to_rtx) && MEM_ALIAS_SET (to_rtx) != 0)
set_mem_alias_set (to_rtx, alias_set);
 
--- gcc/function.c.jj   2011-03-04 19:39:17.0 +0100
+++ gcc/function.c  2011-03-09 09:52:47.428670935 +0100
@@ -942,8 +942,11 @@ assign_stack_temp_for_type (enum machine
   if (type != 0)
 {
   MEM_VOLATILE_P (slot) = TYPE_VOLATILE (type);
-  MEM_SET_IN_STRUCT_P (slot, (AGGREGATE_TYPE_P (type)
- || TREE_CODE (type) == COMPLEX_TYPE));
+  gcc_checking_assert (!MEM_SCALAR_P (slot) && !MEM_IN_STRUCT_P (slot));
+  if (AGGREGATE_TYPE_P (type) || TREE_CODE (type) == COMPLEX_TYPE)
+   MEM_IN_STRUCT_P (slot) = 1;
+  else
+   MEM_SCALAR_P (slot) = 1;
 }
   MEM_NOTRAP_P (slot) = 1;
 
--- gcc/rtl.h.jj2011-02-28 18:02:20.0 +0100
+++ gcc/rtl.h   2011-03-09 09:48:58.858400436 +0100
@@ -1279,24 +1279,6 @@ do { 
\
 #define MEM_NOTRAP_P(RTX) \
   (RTL_FLAG_CHECK1("MEM_NOTRAP_P", (RTX), MEM)->call)
 
-/* If VAL is nonzero, set MEM_IN_STRUCT_P and clear MEM_SCALAR_P in
-   RTX.  Otherwise, vice versa.  Use this macro only when you are
-   *sure* that you know that the MEM is in a structure, or is a
-   scalar.  VAL is evaluated only once.  */
-#define MEM_SET_IN_STRUCT_P(RTX, VAL)  \
-do {   \
-  if (VAL) \
-{  \
-  MEM_IN_STRUCT_P (RTX) = 1;   \
-  MEM_SCALAR_P (RTX) = 0;  \
-}  \
-  else \
-{  \
-  MEM_IN_STRUCT_P (RTX) = 0;   \
-  MEM_SCALAR_P (RTX) = 1;  \
-}  \
-} while (0)
-
 /* The memory attribute block.  We provide access macros for each value
in the block and provide defaults if none specified.  */
 #define MEM_ATTRS(RTX) X0MEMATTR (RTX, 1)


Jakub

Re: [PATCH] Fix MEM_IN_STRUCT_P/MEM_SCALAR_P during expansion (PR rtl-optimization/47866)

[Richard Guenther]

On Wed, Mar 9, 2011 at 9:40 AM, Eric Botcazou  wrote:
>> and as t isn't AGGREGATE_TYPE nor COMPLEX_TYPE and is a decl,
>> it is marked MEM_SCALAR_P and e.g. set_mem_attributes_minus_bitpos
>> once MEM_SCALAR_P is set doesn't change it to MEM_IN_STRUCT_P
>> because of BIT_FIELD_REF etc.  The BIT_FIELD_REF  = 1
>> stores are done through store_field though, and for some reason
>> the code sets MEM_IN_STRUCT_P in that codepath unconditionally.
>
> The irony of marking something scalar when its type is VECTOR_TYPE...
>
>> Changing this fixes the testcase, bootstrapped/regtested on x86_64-linux
>> and i686-linux.  I'll try to test this on ia64-linux tomorrow.
>>
>> 2011-03-08  Jakub Jelinek  
>>
>>       PR rtl-optimization/47866
>>       * expr.c (store_field): If MEM_SCALAR_P (target), don't use
>>       MEM_SET_IN_STRUCT_P (to_rtx, 1), just set MEM_IN_STRUCT_P (to_rtx)
>>       if target wasn't scalar.
>
> I cannot formally approve, but I think it's the way to go.

Yes, this is ok.

I thought about deleting these two flags completely at some point.

Richard.

>  I'd also delete
> the confusing macro MEM_SET_IN_STRUCT_P altogether and replace its only other
> use (in assign_stack_temp_for_type) with the manual equivalent, as is already
> done in set_mem_attributes_minus_bitpos.
>
> --
> Eric Botcazou
>

Re: [tree-ssa] conversion between dissimilar-sized pointers is not useless

[Richard Guenther]

On Wed, Mar 9, 2011 at 10:51 AM, Richard Guenther
 wrote:
> On Wed, Mar 9, 2011 at 4:44 AM, DJ Delorie  wrote:
>>
>> Affects tpf, mips64, and m32c.  Hand-checked tpf by inspection, m32c
>> tests running now.  Look OK so far?
>>
>>        * tree-ssa.c (useless_type_conversion_p): Conversions between
>>        pointers of different modes are not useless.
>>
>> Index: tree-ssa.c
>> ===
>> --- tree-ssa.c  (revision 170807)
>> +++ tree-ssa.c  (working copy)
>> @@ -1227,6 +1227,14 @@
>>          != TYPE_ADDR_SPACE (TREE_TYPE (inner_type)))
>>        return false;
>>
>> +      /* Some targets support multiple pointer sizes, others support
>> +        partial-int modes for some pointer types.  Do not lose casts
>> +        between these.  */
>> +      if (TYPE_SIZE (inner_type) != TYPE_SIZE (outer_type)
>> +         || (GET_MODE_CLASS (TYPE_MODE (inner_type))
>> +             != GET_MODE_CLASS (TYPE_MODE (outer_type
>> +       return false;
>
> Why not simply
>
>  if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type))
>    return false;
>
> ?  This only breaks because of the VOID_TYPE_P check below,
> right?

Oh, btw - I expect that a lot more code will be confused about different
size pointer types, notably IVOPTs and the POINTER_PLUS_EXPR
restriction of only accepting sizetype offsets.

Richard.

Re: [tree-ssa] conversion between dissimilar-sized pointers is not useless

[Richard Guenther]

On Wed, Mar 9, 2011 at 4:44 AM, DJ Delorie  wrote:
>
> Affects tpf, mips64, and m32c.  Hand-checked tpf by inspection, m32c
> tests running now.  Look OK so far?
>
>        * tree-ssa.c (useless_type_conversion_p): Conversions between
>        pointers of different modes are not useless.
>
> Index: tree-ssa.c
> ===
> --- tree-ssa.c  (revision 170807)
> +++ tree-ssa.c  (working copy)
> @@ -1227,6 +1227,14 @@
>          != TYPE_ADDR_SPACE (TREE_TYPE (inner_type)))
>        return false;
>
> +      /* Some targets support multiple pointer sizes, others support
> +        partial-int modes for some pointer types.  Do not lose casts
> +        between these.  */
> +      if (TYPE_SIZE (inner_type) != TYPE_SIZE (outer_type)
> +         || (GET_MODE_CLASS (TYPE_MODE (inner_type))
> +             != GET_MODE_CLASS (TYPE_MODE (outer_type
> +       return false;

Why not simply

  if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type))
return false;

?  This only breaks because of the VOID_TYPE_P check below,
right?

Richard.

>       /* Do not lose casts to restrict qualified pointers.  */
>       if ((TYPE_RESTRICT (outer_type)
>           != TYPE_RESTRICT (inner_type))
>

Re: fix for pr47837

[Richard Guenther]

On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/08/11 11:55, Diego Novillo wrote:
>> On 03/08/2011 12:54 PM, Xinliang David Li wrote:
>>> Please review the attached patch, it does some simplification of the
>>> complicated logical or expressions (x1 or x2 or x3 ...) constructed
>>> from control flow analysis into simpler form.
>>>
>>> Bootstraps and works on s390x for both testcases.
>>>
>>> Bootstraps on x86-64. Regression testing is on going (it takes forever
>>> (whole night already) to finish possibly because the lto test in
>>> c-torture ..).
>>>
>>> Ok for trunk?
>>
>> As a general comment, do you think we will start adding more and more of
>> these special pattern matchers into uninit analysis?  I'm wondering how
>> much effort should we make into creating something more generic.
>>
>> Right now it's this pattern, but there may be others.  It could grow
>> pretty big and ugly.
> We have a real problem in that our underlying analysis to eliminate
> unexecutable edges is the CFG needs help, particularly for path
> sensitive cases.
>
> Given that I'm seeing a real interest in other analysis that ultimately
> have problems similar to those for uninitialized variable analysis,
> building too much goo into tree-ssa-uninit doesn't seem like a long term
> solution.

True.  I've been repeatedly thinking of building some on-the-side CFG
with value-numbered predicates to also catch the CFG vs. scalar-code
predicate combinations we have.  On such on-the-side data structure
we could do very aggressive jump-threading just for analysis purposes
(experiments when working on separating conditions shows that
a PRE-like algorithm could drive this).

Thanks,
Richard.

Re: avoid useless if-before-free tests

[Richard Guenther]

On Tue, Mar 8, 2011 at 5:34 PM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/05/11 07:05, Jim Meyering wrote:
>> Hello,
>>
>> Someone asked me about this yesterday, and since I've been carrying
>> this patch series for over a year -- it's not high priority --
>> this seems like a good time finally to post it.
>>
>> I've been removing if-before-free tests for a few years now.
>> Here are some of the projects that have endured this janitorial work:
> You know, it probably wouldn't be that hard to have GCC perform this
> analysis for you using its dataflow framework.  Checking for a free call
> which is dominated by a test if the argument is null would be a pretty
> simple check.

Yeah, I did this for the malloc hoisting patches first but then settled
on changing the Fortran frontend to not emit a NULL test (which it still
does, the patches were not merged).

Richard.

> Jeff
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNdlqeAAoJEBRtltQi2kC746gIAImSP5BZAQ/d9wF94EQcBsWQ
> Qo4hn+LK6G2h5R2yVwB9dMf4CTZygxnowlFTxtG9QXMlzMCQp61jHJNLJLpgY4Qz
> HLMjPGS8uMUa28pJkeRU0ZIMy5hDGID24F0FChnrpNalBnlCvP0xXsnZEcXi8Ei2
> 3VkOMx87MAnVT0k7omZSnMy2HeKqmnP9xQMGM+ISEAFJuiGYeb5Os3T7IRprJjia
> DSOjSF20O8TTV6543pUrMvdzrEYtTTmsv1UKejiyGMDpHrs2qNHsyqiFBO/FLGLA
> bdNplowv5xTTrlPy/4zYXewvl3XLr8okrk8/c0Y4dIKq/g5jIB6pYVXilGSOVa0=
> =WHAM
> -END PGP SIGNATURE-
>

Re: [PATCH] Fix MEM_IN_STRUCT_P/MEM_SCALAR_P during expansion (PR rtl-optimization/47866)

[Eric Botcazou]

> and as t isn't AGGREGATE_TYPE nor COMPLEX_TYPE and is a decl,
> it is marked MEM_SCALAR_P and e.g. set_mem_attributes_minus_bitpos
> once MEM_SCALAR_P is set doesn't change it to MEM_IN_STRUCT_P
> because of BIT_FIELD_REF etc.  The BIT_FIELD_REF  = 1
> stores are done through store_field though, and for some reason
> the code sets MEM_IN_STRUCT_P in that codepath unconditionally.

The irony of marking something scalar when its type is VECTOR_TYPE...

> Changing this fixes the testcase, bootstrapped/regtested on x86_64-linux
> and i686-linux.  I'll try to test this on ia64-linux tomorrow.
>
> 2011-03-08  Jakub Jelinek  
>
>   PR rtl-optimization/47866
>   * expr.c (store_field): If MEM_SCALAR_P (target), don't use
>   MEM_SET_IN_STRUCT_P (to_rtx, 1), just set MEM_IN_STRUCT_P (to_rtx)
>   if target wasn't scalar.

I cannot formally approve, but I think it's the way to go.  I'd also delete 
the confusing macro MEM_SET_IN_STRUCT_P altogether and replace its only other 
use (in assign_stack_temp_for_type) with the manual equivalent, as is already 
done in set_mem_attributes_minus_bitpos.

-- 
Eric Botcazou