Re: [PR debug/59992 #1/2] avoid quadratic behavior for the removal of useless values

[Alexandre Oliva]

On Feb 27, 2014, Alexandre Oliva  wrote:

> I wasn't entirely sure this wouldn't invalidate assumptions made in
> callers of cselib_preserve_only_values (the function called at the end
> of each extended basic block), but some analysis, plus comparing before
> and after assembly output ;-), made sure it didn't ;-)

For some values of didn't ;-) PR60381 proved otherwise.  On PA, FP args
may be passed by reference with incoming-rtl (mem (plus (reg)
(const_int))), and we don't preserve the VALUE for the REG in this case.
There may be other such cases, so I decided to not try to fix just this
one.

Fortunately, the second patch of this series, that moves permanent
entries to an alternate table, brings about by itself nearly all of the
benefit of the two together.

I'm checking this in.

Revert r208220.

From: Alexandre Oliva 

for gcc/ChangeLog

	PR debug/60381
	Revert:
	2014-02-28  Alexandre Oliva 
	PR debug/59992
	* cselib.c (remove_useless_values): Skip to avoid quadratic
	behavior if the condition moved from...
	(cselib_process_insn): ... here holds.
---
 gcc/cselib.c |   16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/gcc/cselib.c b/gcc/cselib.c
index 0fcfe28..4dfc557 100644
--- a/gcc/cselib.c
+++ b/gcc/cselib.c
@@ -681,14 +681,6 @@ remove_useless_values (void)
 {
   cselib_val **p, *v;
 
-  if (n_useless_values <= MAX_USELESS_VALUES
-  /* remove_useless_values is linear in the hash table size.  Avoid
- quadratic behavior for very large hashtables with very few
-	 useless elements.  */
-  || ((unsigned int)n_useless_values
-	  <= (cselib_hash_table.elements () - n_debug_values) / 4))
-return;
-
   /* First pass: eliminate locations that reference the value.  That in
  turn can make more values useless.  */
   do
@@ -2720,7 +2712,13 @@ cselib_process_insn (rtx insn)
 
   cselib_current_insn = NULL_RTX;
 
-  remove_useless_values ();
+  if (n_useless_values > MAX_USELESS_VALUES
+  /* remove_useless_values is linear in the hash table size.  Avoid
+ quadratic behavior for very large hashtables with very few
+	 useless elements.  */
+  && ((unsigned int)n_useless_values
+	  > (cselib_hash_table.elements () - n_debug_values) / 4))
+remove_useless_values ();
 }
 
 /* Initialize cselib for one pass.  The caller must also call


-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist Red Hat Brazil Toolchain Engineer

RE: [patch,avr] Device specific instructions support for avr

[S, Pitchumani]

Hi Denis,

> -Original Message-
> From: Denis Chertykov [mailto:cherty...@gmail.com]
> Sent: Monday, March 03, 2014 10:45 PM
> 2014-03-03 13:34 GMT+04:00 S, Pitchumani :
> > Hi,
> >
> > Few AVR Xmega devices have specific instruction support than the
> architecture
> > it belongs to. For example atxmega128b1 device has RMW instructions
> (XCH,LAC,
> > LAS and LAT) support, but not all avrxmega6 devices have.
> >
> > Now, avr-gcc passes architecture name to assembler instead of device
> name. So,
> > RMW instructions are not recognized (illegal opcode error) by assembler.
> >
> > To address this issue, we could add device specific ISA to device
> details
> > in GCC. Driver can pass additional option based on specific ISA that a
> device
> > has. Assembler can add device specific ISA to architecture ISA based on
> the
> > option it receives.
> >
> > I have attached patches for avr-gcc.
> >
> > device-specific-isa-avr-gcc.patch:
> > * Device specific ISA information is added to device details.
> > * avr-gcc passes -mrmw option to assembler if the selected device
> > has RMW instruction support.
> 
> I don't like additional option '-mrmw' because we already have a way
> for passing device specific ISA.
> IMHO better to add new avr_arch (ie atxmega128b1 is ARCH_AVRXMEGA6U)
> GAS already have AVR_ISA_XMEGAU for RMW instructions.

New avr_arch can be added. But there are devices in avrxmega2, 4, 5, 6 and 7
architectures which has rmw instructions. In this case, new architecture 
required 
for above variants as well. Also there is DES instruction which is available 
only 
for few avr devices. So, I thought adding an option will avoid creating many 
new 
architectures.

Related binutils PR: http://sourceware.org/PR15043
Related discussion: 
http://lists.nongnu.org/archive/html/avr-gcc-list/2014-03/msg0.html

Please suggest.

Regards,
Pitchumani

Re: [PATCH] Fix ARM TLS handling (PR target/58595)

[Ramana Radhakrishnan]

On Wed, Mar 5, 2014 at 9:12 AM, Jakub Jelinek  wrote:
> Hi!
>
> arm_legitimize_address may be called with a TLS symbol referenced, even when
> x is not itself a SYMBOL_REF.  Most often it is something like:
> (const:SI (plus:SI (symbol_ref:SI "tlsvar") (const_int NNN)))
> but generally it can be something else (e.g. from expansion of
> TARGET_MEM_REF).  Unfortunately this function legitimizes only the
> SYMBOL_REF TLS case as TLS load, but the more complex forms with e.g. -fpic
> can e.g. fall thru into legitimize_pic_address -> gen_calculate_pic_address,
> which means either wrong-code or ICE later on.
> Fixed by legitimizing both the SYMBOL_REF and
> CONST+PLUS+SYMBOL_REF+CONST_INT case, and for more complex TLS containing
> expressions just returning x (in that case the caller will split the PLUS
> on its own).
>
> Kyrill has kindly bootstrapped/regtested this on Chromebook, ok for
> trunk/4.8?
>
> 2014-03-05  Jakub Jelinek  
> Meador Inge  
>
> PR target/58595
> * config/arm/arm.c (arm_tls_symbol_p): Remove.
> (arm_legitimize_address): Call legitimize_tls_address for any
> arm_tls_referenced_p expression, handle constant addend.  Call it
> before testing for !TARGET_ARM.
> (thumb_legitimize_address): Don't handle arm_tls_symbol_p here.
>
> * gcc.dg/tls/pr58595.c: New test.


OK if no regressions. Please let any auto testers catch any issues and
back port to 4.8 in about 48 hours.

Regards,
Ramana
>
> --- gcc/config/arm/arm.c.jj 2014-03-04 08:51:39.620081210 +0100
> +++ gcc/config/arm/arm.c2014-03-04 14:06:26.776277688 +0100
> @@ -235,7 +235,6 @@ static tree arm_gimplify_va_arg_expr (tr
>  static void arm_option_override (void);
>  static unsigned HOST_WIDE_INT arm_shift_truncation_mask (enum machine_mode);
>  static bool arm_cannot_copy_insn_p (rtx);
> -static bool arm_tls_symbol_p (rtx x);
>  static int arm_issue_rate (void);
>  static void arm_output_dwarf_dtprel (FILE *, int, rtx) ATTRIBUTE_UNUSED;
>  static bool arm_output_addr_const_extra (FILE *, rtx);
> @@ -7336,6 +7335,32 @@ legitimize_tls_address (rtx x, rtx reg)
>  rtx
>  arm_legitimize_address (rtx x, rtx orig_x, enum machine_mode mode)
>  {
> +  if (arm_tls_referenced_p (x))
> +{
> +  rtx addend = NULL;
> +
> +  if (GET_CODE (x) == CONST && GET_CODE (XEXP (x, 0)) == PLUS)
> +   {
> + addend = XEXP (XEXP (x, 0), 1);
> + x = XEXP (XEXP (x, 0), 0);
> +   }
> +
> +  if (GET_CODE (x) != SYMBOL_REF)
> +   return x;
> +
> +  gcc_assert (SYMBOL_REF_TLS_MODEL (x) != 0);
> +
> +  x = legitimize_tls_address (x, NULL_RTX);
> +
> +  if (addend)
> +   {
> + x = gen_rtx_PLUS (SImode, x, addend);
> + orig_x = x;
> +   }
> +  else
> +   return x;
> +}
> +
>if (!TARGET_ARM)
>  {
>/* TODO: legitimize_address for Thumb2.  */
> @@ -7344,9 +7369,6 @@ arm_legitimize_address (rtx x, rtx orig_
>return thumb_legitimize_address (x, orig_x, mode);
>  }
>
> -  if (arm_tls_symbol_p (x))
> -return legitimize_tls_address (x, NULL_RTX);
> -
>if (GET_CODE (x) == PLUS)
>  {
>rtx xop0 = XEXP (x, 0);
> @@ -7459,9 +7481,6 @@ arm_legitimize_address (rtx x, rtx orig_
>  rtx
>  thumb_legitimize_address (rtx x, rtx orig_x, enum machine_mode mode)
>  {
> -  if (arm_tls_symbol_p (x))
> -return legitimize_tls_address (x, NULL_RTX);
> -
>if (GET_CODE (x) == PLUS
>&& CONST_INT_P (XEXP (x, 1))
>&& (INTVAL (XEXP (x, 1)) >= 32 * GET_MODE_SIZE (mode)
> @@ -7756,20 +7775,6 @@ thumb_legitimize_reload_address (rtx *x_
>
>  /* Test for various thread-local symbols.  */
>
> -/* Return TRUE if X is a thread-local symbol.  */
> -
> -static bool
> -arm_tls_symbol_p (rtx x)
> -{
> -  if (! TARGET_HAVE_TLS)
> -return false;
> -
> -  if (GET_CODE (x) != SYMBOL_REF)
> -return false;
> -
> -  return SYMBOL_REF_TLS_MODEL (x) != 0;
> -}
> -
>  /* Helper for arm_tls_referenced_p.  */
>
>  static int
> --- gcc/testsuite/gcc.dg/tls/pr58595.c.jj   2014-03-04 12:56:48.337915114 
> +0100
> +++ gcc/testsuite/gcc.dg/tls/pr58595.c  2014-03-04 12:56:48.337915114 +0100
> @@ -0,0 +1,28 @@
> +/* PR target/58595 */
> +/* { dg-do run } */
> +/* { dg-options "-O2" } */
> +/* { dg-additional-options "-fpic" { target fpic } } */
> +/* { dg-require-effective-target tls } */
> +/* { dg-require-effective-target sync_int_long } */
> +
> +struct S { unsigned long a, b; };
> +__thread struct S s;
> +void bar (unsigned long *);
> +
> +__attribute__((noinline)) void
> +foo (void)
> +{
> +  int i;
> +  for (i = 0; i < 10; i++)
> +__sync_fetch_and_add (&s.b, 1L);
> +}
> +
> +int
> +main ()
> +{
> +  s.b = 12;
> +  foo ();
> +  if (s.b != 22)
> +__builtin_abort ();
> +  return 0;
> +}
>
> Jakub

Re: [PATCH] Use the LTO linker plugin by default

[Jan Hubicka]

> On Tue, 4 Mar 2014, Jan Hubicka wrote:
> 
> > > 
> > > The following patch addresses the common (?) issue of people
> > > omitting -flto from the linker command-line which gets more
> > > severe with GCC 4.9 where slim LTO objects are emitted by
> > > default.  The patch simply _always_ arranges for the linker
> > > plugin to be used, so if there are any (slim) LTO objects
> > > on the link LTO will be done on them.  Similarly the
> > > non-linker-plugin path in collect2 is adjusted.
> > > 
> > > You can still disable this by specifying -fno-lto on the 
> > > linker command-line.
> > > 
> > > One side-effect of enabling the linker-plugin by default
> > > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then
> > > use the configured plugin ld rather than the default ld.
> > > Not sure if that is desired.
> > > 
> > > Comments?
> > 
> > I like it; it was on my TODO list, but I was only worried about
> > --with-plugin-ld and did not find time, yet, to look into the consequences.
> > These days, I do not think we need to worry much aboud --with-plugin-ld.
> 
> Yeah, I think we should eventually remove that capability.
> 
> Now as of the two patches (compute a default link-time optimization
> level and this patch, make considering LTO at link-time the default),
> they only make sense together (at least the default opt level at
> link-time doesn't improve real-world situations without also considering
> all links to be possibly -flto).
> 
> So the question remains if we want to have both patches at this
> stage or if we want to wait with them for 4.10 (we do have the
> user-visible change of slim-lto objects by default with 4.9
> already).

I think it makes things easier, so I would like to see this in 4.9

Honza

[libstdc++,docs] libstdc++ status doc updates for filesystem and fundamentals TSen.

[Ed Smith-Rowland]

On 03/05/2014 01:52 PM, Jonathan Wakely wrote:

On 5 March 2014 18:16, Ed Smith-Rowland wrote:

After the latest batch of papers came out I updated the status docs.

OK?

OK (CCing gcc-patches with the attachments again).

Thanks.

After the latest batch of papers came out I updated the status docs.
As applied.
Ed

2014-03-05  Ed Smith-Rowland  <3dw...@verizon.net>

* doc/xml/manual/status_cxx2014.xml: Add new items and latest papers
for filesystem and fundamentals TS work items.

Index: doc/xml/manual/status_cxx2014.xml
===
--- doc/xml/manual/status_cxx2014.xml   (revision 208278)
+++ doc/xml/manual/status_cxx2014.xml   (working copy)
@@ -283,32 +283,164 @@
 
 
 
+  
   
-   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3793.html";>
- N3672
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3783.pdf";>
+ N3783

   
+  Network byte order conversion
+  N
+  Library Fundamentals TS
+
+
+
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3793.html";>
+ N3793
+   
+  
   A proposal to add a utility class to represent optional 
objects
   Y
   Library Fundamentals TS
 
 
 
+  
   
-   http://www.w3.org/1999/xlink"; 
xlink:href="http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html";>
- N3762
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3804.html";>
+ N3804

   
+  Any library proposal
+  N
+  Library Fundamentals TS
+
+
+
+  
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3843.pdf";>
+ N3843
+   
+  
+  A SFINAE-Friendly std::common_type (option 2 was approved)
+  N
+  Library Fundamentals TS
+
+
+
+  
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3866.html";>
+ N3866
+   
+  
+  Invocation type traits, but dropping 
function_call_operator.
+  N
+  Library Fundamentals TS
+
+
+
+  
+  
+   http://www.w3.org/1999/xlink"; xlink:href="">
+ N3905
+   
+  
+  Faster string searching (Boyer-Moore et al.)
+  N
+  Library Fundamentals TS
+
+
+
+  
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3915.pdf";>
+ N3915
+   
+  
+  apply() call a function with arguments from a tuple
+  N
+  Library Fundamentals TS
+
+
+
+  
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3916.pdf";>
+ N3916
+   
+  
+  Polymorphic memory resources
+  N
+  Library Fundamentals TS
+
+
+
+  
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3920.html";>
+ N3920
+   
+  
+  Extending shared_ptr to support arrays
+  N
+  Library Fundamentals TS
+
+
+
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3921.html";>
+ N3921
+   
+  
   string_view: a non-owning reference to a 
string
   Y
   Library Fundamentals TS
 
 
 
+  
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3923.pdf";>
+ N3923
+   
+  
+  A SFINAE-Friendly std::iterator_traits
+  N
+  Library Fundamentals TS
+
+
+
+  
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3925.pdf";>
+ N3925
+   
+  
+  A sample proposal
+  N
+  Library Fundamentals TS
+
+
+
+  
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3932.htm";>
+ N3932
+   
+  
+  Variable Templates For Type Traits
+  N
+  Library Fundamentals TS
+
+
+
   
   
-   http://www.w3.org/1999/xlink"; 
xlink:href="http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3790.html";>
- N3790
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3932.htm";>
+ N3940

   
   File System

[jit] New API entrypoint: gcc_jit_function_dump_to_dot

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/
* libgccjit.h (gcc_jit_function_dump_to_dot): New.
* libgccjit.map (gcc_jit_function_dump_to_dot): New.
* libgccjit++.h (gccjit::function::dump_to_dot): New.
* libgccjit.c (gcc_jit_function_dump_to_dot): New.
* internal-api.h (gcc::jit::recording::function::dump_to_dot): New.
(gcc::jit::recording::block::block): Add m_index member.
(gcc::jit::recording::block::dump_to_dot): New.
(gcc::jit::recording::block::dump_edges_to_dot): New.
* internal-api.c (gcc::jit::recording::function::new_block): Give
each block an index.
(gcc::jit::recording::function::dump_to_dot): New.
(gcc::jit::recording::block::dump_to_dot): New.
(gcc::jit::recording::block::dump_edges_to_dot): New.
---
 gcc/jit/ChangeLog.jit  | 16 ++
 gcc/jit/internal-api.c | 79 +-
 gcc/jit/internal-api.h |  9 +-
 gcc/jit/libgccjit++.h  |  9 ++
 gcc/jit/libgccjit.c| 11 +++
 gcc/jit/libgccjit.h|  5 
 gcc/jit/libgccjit.map  |  1 +
 7 files changed, 128 insertions(+), 2 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index b9172a1..3e2799f 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,19 @@
+2014-03-05  David Malcolm  
+
+   * libgccjit.h (gcc_jit_function_dump_to_dot): New.
+   * libgccjit.map (gcc_jit_function_dump_to_dot): New.
+   * libgccjit++.h (gccjit::function::dump_to_dot): New.
+   * libgccjit.c (gcc_jit_function_dump_to_dot): New.
+   * internal-api.h (gcc::jit::recording::function::dump_to_dot): New.
+   (gcc::jit::recording::block::block): Add m_index member.
+   (gcc::jit::recording::block::dump_to_dot): New.
+   (gcc::jit::recording::block::dump_edges_to_dot): New.
+   * internal-api.c (gcc::jit::recording::function::new_block): Give
+   each block an index.
+   (gcc::jit::recording::function::dump_to_dot): New.
+   (gcc::jit::recording::block::dump_to_dot): New.
+   (gcc::jit::recording::block::dump_edges_to_dot): New.
+
 2014-03-04  David Malcolm  
 
* internal-api.c (gcc::jit::recording::memento_of_get_pointer::
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 835aa7f..62301b2 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -1294,7 +1294,7 @@ recording::function::new_block (const char *name)
   gcc_assert (m_kind != GCC_JIT_FUNCTION_IMPORTED);
 
   recording::block *result =
-new recording::block (this, new_string (name));
+new recording::block (this, m_blocks.length (), new_string (name));
   m_ctxt->record (result);
   m_blocks.safe_push (result);
   return result;
@@ -1430,6 +1430,42 @@ recording::function::validate ()
 }
 }
 
+void
+recording::function::dump_to_dot (const char *path)
+{
+  FILE *fp  = fopen (path, "w");
+  if (!fp)
+return;
+
+  pretty_printer the_pp;
+  the_pp.buffer->stream = fp;
+
+  pretty_printer *pp = &the_pp;
+
+  pp_printf (pp,
+"digraph %s {\n", get_debug_string ());
+
+  /* Blocks: */
+  {
+int i;
+block *b;
+FOR_EACH_VEC_ELT (m_blocks, i, b)
+  b->dump_to_dot (pp);
+  }
+
+  /* Edges: */
+  {
+int i;
+block *b;
+FOR_EACH_VEC_ELT (m_blocks, i, b)
+  b->dump_edges_to_dot (pp);
+  }
+
+  pp_printf (pp, "}\n");
+  pp_flush (pp);
+  fclose (fp);
+}
+
 recording::string *
 recording::function::make_debug_string ()
 {
@@ -1573,6 +1609,47 @@ recording::block::make_debug_string ()
(void *)this);
 }
 
+void
+recording::block::dump_to_dot (pretty_printer *pp)
+{
+  pp_printf (pp,
+("\tblock_%d "
+ "[shape=record,style=filled,fillcolor=white,label=\"{"),
+m_index);
+  pp_write_text_to_stream (pp);
+  if (m_name)
+{
+  pp_string (pp, m_name->c_str ());
+  pp_string (pp, ":");
+  pp_newline (pp);
+  pp_write_text_as_dot_label_to_stream (pp, true /*for_record*/);
+}
+
+  int i;
+  statement *s;
+  FOR_EACH_VEC_ELT (m_statements, i, s)
+{
+  pp_string (pp, s->get_debug_string ());
+  pp_newline (pp);
+  pp_write_text_as_dot_label_to_stream (pp, true /*for_record*/);
+}
+
+  pp_printf (pp,
+"}\"];\n\n");
+  pp_flush (pp);
+}
+
+void
+recording::block::dump_edges_to_dot (pretty_printer *pp)
+{
+  block *next[2];
+  int num_succs = get_successor_blocks (&next[0], &next[1]);
+  for (int i = 0; i < num_succs; i++)
+pp_printf (pp,
+  "\tblock_%d:s -> block_%d:n;\n",
+  m_index, next[i]->m_index);
+}
+
 /* gcc::jit::recording::global:: */
 void
 recording::global::replay_into (replayer *r)
diff --git a/gcc/jit/internal-api.h b/gcc/jit/internal-api.h
index 5c11085..23352fc 100644
--- a/gcc/jit/internal-api.h
+++ b/gcc/jit/internal-api.h
@@ -889,6 +889,8 @@ public:
 
   void validate ();
 
+  void dump_to_dot (const char *path);
+
 private:
   string * 

Re: [v3] LWG 2106: move_iterator::reference

[Jonathan Wakely]

On 5 March 2014 21:35, Marc Glisse wrote:
> On Wed, 5 Mar 2014, Jonathan Wakely wrote:
>
>> Please put _GLIBCXX_RESOLVE_DEFECTS (or whatever
>> it is we use elsewhere) in the comment, rather than just "DR 2106". I
>> think the point of that is to be able to grep for all DR fixes
>> (especially ones that aren't actually accepted as defects yet :-)
>
>
> Believe it or not, I did look at other occurences in the code, and didn't
> hit any that used such a keyword. Now that I know to look for it, there is
> indeed _GLIBCXX_RESOLVE_LIB_DEFECTS (I'll add it), but it is missing in a
> lot of places.

That's the one. I know I've not always been consistent about adding
it, but I try to when I remember.

Re: [v3] LWG 2106: move_iterator::reference

[Marc Glisse]

On Wed, 5 Mar 2014, Jonathan Wakely wrote:


Please put _GLIBCXX_RESOLVE_DEFECTS (or whatever
it is we use elsewhere) in the comment, rather than just "DR 2106". I
think the point of that is to be able to grep for all DR fixes
(especially ones that aren't actually accepted as defects yet :-)


Believe it or not, I did look at other occurences in the code, and didn't 
hit any that used such a keyword. Now that I know to look for it, there is 
indeed _GLIBCXX_RESOLVE_LIB_DEFECTS (I'll add it), but it is missing in a 
lot of places.


--
Marc Glisse

Re: [PATCH, x86] X86 Silvermont vector cost model tune

[Evgeny Stupachenko]

slm_cost/intel_cost and TARGET_SLOW_PSHUFB are just preparation to a
next vectorization patch.
Changes in ix86_add_stmt_cost gives real performance to Silvermont.
Let's move all to stage1.

On Wed, Mar 5, 2014 at 9:29 PM, Uros Bizjak  wrote:
> On Wed, Mar 5, 2014 at 5:46 PM, H.J. Lu  wrote:
>> On Wed, Mar 5, 2014 at 7:58 AM, Evgeny Stupachenko  
>> wrote:
>>> Hi,
>>>
>>> The patch is for x86 Silvermont.
>>> It improves x86 Silvermont vector cost model.
>>> It gives +20% on facerec spec on Silvermont.
>>> It passes make check and bootstrap on x86.
>>>
>>> Is this patch ok for stage1?
>>>
>>> ChangeLog:
>>>
>>> 2014-03-05  Evgeny Stupachenko  
>>>
>>> * config/i386/x86-tune.def (TARGET_SLOW_PSHUFB): Target for slow byte
>>> shuffle on some x86 architectures.
>>> * config/i386/i386.h (TARGET_SLOW_PSHUFB): Ditto.
>>> * config/i386/i386.c (processor_costs): Fixing vec_to_scalar_cost for
>>> Silvermont according latency table.
>>> (expand_vec_perm_even_odd_1): Avoid byte shuffles in architectures
>>> where they are slow (TARGET_SLOW_PSHUFB).
>>> (x86_add_stmt_cost): Fixing vector cost model for Silvermont.
>>>
>>> Thanks,
>>> Evgeny
>>
>> There are 3 separate changes in this patch:
>>
>> 1. Update slm_cost, which doesn't have a ChangeLog entry.
>> 2. Add TARGET_SLOW_PSHUFB.
>> 3. Update ix86_add_stmt_cost.
>>
>> I suggest you break it into 3 independent patches.
>
> I think that slm_cost/intel_cost and TARGET_SLOW_PSHUFB changes can
> still go into mainline at this stage since they are trivial tuning
> changes that should not destabilize the compiler.
>
> The  ix86_add_stmt_cost should wait for stage 1.
>
> Uros.

[PATCH] Add support for powerpc ISA 2.07 128-bit add/subtract builtins

[Michael Meissner]

This patch adds support for the PowerPC ISA 2.07 (power8) 128-bit add/subtract
instructions that use the Altivec (VMX) register set (vaddumq, etc.).

Unfortunately at the moment, TImode (__int128_t) is not allowed to use the
VSX/VMX register set, unless you use the undocumented switch -mvsx-timode.
This was disabled because there were several bugs that showed up during the
original ISA 2.07 patches.  I spent some time trying to work out all of the
problems with -mvsx-timode, but I was not able to do so at present.

These patches add support for the builtins when the code is running in 64-bit
mode.  If TImode is not allowed to go into the VMX registers, the code uses
V2DImode to do the operation.  Simple minded tests show that the compiler can
do loads directly into the VMX registers, but after the operation, it does a
permute, 2 direct move instructions, and a store quad from the GPR register
set.  Ideally, a future patch will fix -mvsx-timode so it can be default.

In these patches, I updated test timode_off.c.  This test would fail if
-mvsx-timode is enabled because in that mode, TImode addresses can only be a
single register, so that the address can be used either to load GPRs or VSX
registers without reloading.  This causes the test code to be slightly bigger,
and the test then fails when the code size gets to be larger than 616 bytes.

I have tested these patches on power7 and power8 machines with no regressions.
I have tested the executable test on both big endian and little endian power8
systems, and it produces the correct values in both cases.  Are the patches ok
to install?

[gcc]
2014-03-05  Michael Meissner  

* doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions):
Document vec_vaddcuq, vec_vadduqm, vec_vaddecuq, vec_vaddeuqm,
vec_subecuq, vec_subeuqm, vec_vsubcuq, vec_vsubeqm builtins adding
128-bit integer add/subtract to ISA 2.07.

* config/rs6000/rs6000-protos.h (rs6000_move_128bit_ok_p): Add new
declaration.
(rs6000_split_128bit_ok_p): Likewise.
(rs6000_int128_builtin_fixup): Likewise.

* gcc/config/rs6000/rs6000-builtin.def (BU_P8V_AV_3): Add new
macros to support adding ISA 2.07 3 argument builtins.
(BU_P8V_OVERLOAD_3): Likewise.
(VADDCUQ): Add ISA 2.07 builtins to support 128-bit integer
add/subtract instructions, both as a normal builtin, and as an
overloaded builtin.
(VADDUQM): Likewise.
(VSUBCUQ): Likewise.
(VSUBUQM): Likewise.
(VADDECUQ): Likewise.
(VADDECUQ): Likewise.
(VSUBECUQ): Likewise.
(VSUBEUQM): Likewise.

* gcc/config/rs6000-c.c (altivec_overloaded_builtins): Add support
for ISA 2.07 overloaded builtins to do 128-bit add and subtract.

* gcc/config/rs6000.c (rs6000_init_builtins): Initialize state
variables for using __int128_t and __uint128_t as arguments to
builtins.
(rs6000_move_128bit_ok_p): New function to validate TImode/PTImode
moves.
(rs6000_split_128bit_ok_p): New function to say when it is ok to
split TImode/PTImove moves.
(rs6000_int128_builtin_fixup): New function to convert int 128-bit
add/subtract from using TImode to using V2DImode to allow use of
the ISA 2.07 builtins when TImode is not allowed in VSX
registers.

* gcc/config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add
support to allow __int128_t and __uint128_t types as builtin
arguments.
(intTI_type_internal_node): Likewise.
(uintTI_type_internal_node): Likewise.

* gcc/config/rs6000/altivec.md (UNSPEC_VADDUQM): New unspec
literals to allow addition of the ISA 2.07 128-bit add/subtract
builtin functions.
(UNSPEC_VADDCUQ): Likewise.
(UNSPEC_VADDEUQM): Likewise.
(UNSPEC_VADDECUQ): Likewise.
(UNSPEC_VSUBUQM): Likewise.
(UNSPEC_VSUBCUQ): Likewise.
(UNSPEC_VSUBEUQM): Likewise.
(UNSPEC_VSUBECUQ): Likewise.
(VINT128): New iterator for 128-bit add/subtract builtins.
(altivec_vadduqm): New ISA 2.07 128-bit add/subtract builtins.
(altivec_vadduqm_): Likewise.
(altivec_vaddcuq): Likewise.
(altivec_vaddcuq_): Likewise.
(altivec_vaddeuqm): Likewise.
(altivec_vaddeuqm_): Likewise.
(altivec_vaddecuq): Likewise.
(altivec_vaddecuq_): Likewise.
(altivec_vsubuqm): Likewise.
(altivec_vsubuqm_): Likewise.
(altivec_vsubcuq): Likewise.
(altivec_vsubcuq_): Likewise.
(altivec_vsubeuqm): Likewise.
(altivec_vsubeuqm_): Likewise.
(altivec_vsubecuq): Likewise.
(altivec_vsubecuq_): Likewise.

* gcc/config/rs6000/altivec.h (vec_vadduqm): If ISA 2.07, add
support for 128-bit add/subtract builtins.
(vec_vaddcuq): Likewise.
(vec_vaddeuqm): Likewise.
(vec_vaddecuq): Lik

Re: [v3] LWG 2106: move_iterator::reference

[Jonathan Wakely]

On 5 March 2014 19:36, Marc Glisse wrote:
> Hello,
>
> this issue got delayed in LWG, apparently because of a failed "improvement"
> to the wording along the way (happens, that's ok), but there seems to be a
> consensus on the resolution and I don't really see the point of waiting (it
> changes code that currently returns a reference to a temporary).
>
> Tested on x86_64-linux-gnu. Stage 1?

Yes, OK for Stage 1.  Please put _GLIBCXX_RESOLVE_DEFECTS (or whatever
it is we use elsewhere) in the comment, rather than just "DR 2106". I
think the point of that is to be able to grep for all DR fixes
(especially ones that aren't actually accepted as defects yet :-)

Thanks.

Re: Patch RFC: Use internal qsort function in libbacktrace

[Ian Lance Taylor]

On Wed, Mar 5, 2014 at 9:17 AM, Ondřej Bílka  wrote:
> On Wed, Mar 05, 2014 at 08:05:25AM -0800, Ian Lance Taylor wrote:
>> On Wed, Mar 5, 2014 at 1:25 AM, Richard Biener
>>  wrote:
>> > On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor  wrote:
>> >> The GNU glibc qsort function will call malloc in some cases.  That makes
>> >> it unsuitable for libbacktrace, which is intended to work when called
>> >> from a signal handler.  This patch changes libbacktrace to use an
>> >> internal qsort function.
>> >>
> Another solution is use a malloc wrapper that makes to make malloc signal
> safe. Problem with this solution is that its on application layer, not
> library one. I am trying to add a signal safety to glibc.

I don't see any reasonable way to change libbacktrace to work that
way.  The libbacktrace library may be being invoked by a signal
handler that was run because of a signal that was sent while malloc
was executing.  At that point it is too late for libbacktrace to avoid
calling malloc recursively, which won't work.  It would not be
reasonable for libbacktrace, a small library, to override malloc for
the entire application.

Ian

Re: [testsuite] Further logical_op_short_circuit changes (PR testsuite/59308)

[Mike Stump]

On Mar 4, 2014, at 8:39 AM, Jakub Jelinek  wrote:
> With some -march=/-mtune= flags even i?86/x86_64 has BRANCH_COST 1 and
> various tests fail, furthermore ssa-ifcombine-ccmp* apparently fail on e.g.
> s390* or some arm variants.
> 
> This patch tries to fix that up.
> 
> ok for trunk?

Ok.

Re: [PATCH] Change HONOR_REG_ALLOC_ORDER to a marco for C expression

[Vladimir Makarov]

On 3/4/2014, 9:59 AM, Kito Cheng wrote:

Ping.



Although this patch is safe.  I guess it could wait for stage 1 as right 
now we don't need this functionality.


The patch is ok for the stage1 which is probably about a month away.

Thanks for the patch.



On Thu, Feb 27, 2014 at 12:32 PM, Kito Cheng  wrote:

Hi all:

Sorry for repeat patch content in last mail, here is the clean version
for this patch.

diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 7ca47a7..1638332 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1152,7 +1152,7 @@ extern int arm_regs_in_sequence[];

  /* Tell IRA to use the order we define rather than messing it up with its
 own cost calculations.  */
-#define HONOR_REG_ALLOC_ORDER
+#define HONOR_REG_ALLOC_ORDER 1

  /* Interrupt functions can only use registers that have already been
 saved by the prologue, even if they would normally be
diff --git a/gcc/config/nds32/nds32.h b/gcc/config/nds32/nds32.h
index 38847e5..8f966ec 100644
--- a/gcc/config/nds32/nds32.h
+++ b/gcc/config/nds32/nds32.h
@@ -553,7 +553,7 @@ enum nds32_builtins

  /* Tell IRA to use the order we define rather than messing it up with its
 own cost calculations.  */
-#define HONOR_REG_ALLOC_ORDER
+#define HONOR_REG_ALLOC_ORDER 1

  /* The number of consecutive hard regs needed starting at
 reg "regno" for holding a value of mode "mode".  */
diff --git a/gcc/defaults.h b/gcc/defaults.h
index f94ae17..1c48759 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -1085,6 +1085,10 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see
  #define LOCAL_REGNO(REGNO)  0
  #endif

+#ifndef HONOR_REG_ALLOC_ORDER
+#define HONOR_REG_ALLOC_ORDER 0
+#endif
+
  /* EXIT_IGNORE_STACK should be nonzero if, when returning from a function,
 the stack pointer does not matter.  The value is tested only in
 functions that have frame pointers.  */
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index f204936..c0de478 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -2044,8 +2044,8 @@ Normally, IRA tries to estimate the costs for
saving a register in the
  prologue and restoring it in the epilogue.  This discourages it from
  using call-saved registers.  If a machine wants to ensure that IRA
  allocates registers in the order given by REG_ALLOC_ORDER even if some
-call-saved registers appear earlier than call-used ones, this macro
-should be defined.
+call-saved registers appear earlier than call-used ones, then define this
+ macro as a C expression to nonzero. Default is 0.
  @end defmac

  @defmac IRA_HARD_REGNO_ADD_COST_MULTIPLIER (@var{regno})
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 50f412c..d7ae6a7 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -1849,8 +1849,8 @@ Normally, IRA tries to estimate the costs for
saving a register in the
  prologue and restoring it in the epilogue.  This discourages it from
  using call-saved registers.  If a machine wants to ensure that IRA
  allocates registers in the order given by REG_ALLOC_ORDER even if some
-call-saved registers appear earlier than call-used ones, this macro
-should be defined.
+call-saved registers appear earlier than call-used ones, then define this
+ macro as a C expression to nonzero. Default is 0.
  @end defmac

  @defmac IRA_HARD_REGNO_ADD_COST_MULTIPLIER (@var{regno})
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index c20aaf7..773c86e 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -1599,7 +1599,6 @@ check_hard_reg_p (ira_allocno_t a, int hard_regno,
  }
return j == nregs;
  }
-#ifndef HONOR_REG_ALLOC_ORDER

  /* Return number of registers needed to be saved and restored at
 function prologue/epilogue if we allocate HARD_REGNO to hold value
@@ -1618,7 +1617,6 @@ calculate_saved_nregs (int hard_regno, enum
machine_mode mode)
nregs++;
return nregs;
  }
-#endif

  /* Choose a hard register for allocno A.  If RETRY_P is TRUE, it means
 that the function called from function
@@ -1653,11 +1651,9 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
enum reg_class aclass;
enum machine_mode mode;
static int costs[FIRST_PSEUDO_REGISTER], full_costs[FIRST_PSEUDO_REGISTER];
-#ifndef HONOR_REG_ALLOC_ORDER
int saved_nregs;
enum reg_class rclass;
int add_cost;
-#endif
  #ifdef STACK_REGS
bool no_stack_reg_p;
  #endif
@@ -1823,19 +1819,21 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
   continue;
cost = costs[i];
full_cost = full_costs[i];
-#ifndef HONOR_REG_ALLOC_ORDER
-  if ((saved_nregs = calculate_saved_nregs (hard_regno, mode)) != 0)
- /* We need to save/restore the hard register in
-   epilogue/prologue.  Therefore we increase the cost.  */
- {
-  rclass = REGNO_REG_CLASS (hard_regno);
-  add_cost = ((ira_memory_move_cost[mode][rclass][0]
-   + ira_memory_move_cost[mode][rclass][1])
-  * saved_nregs / hard_regno_nregs[hard_regno][mode] - 1);
-  cost += add_cost;
-  full_cost += add_cost;

Re: RFA: New ipa-devirt PATCH for c++/58678 (devirt vs. KDE)

[Jason Merrill]

On 03/05/2014 01:40 PM, Jan Hubicka wrote:

I think the abstract classes probably should never be considered in the type
inheritance graph walk as possible instances. That is we probably want to test
them in record_targets_from_bases, possible_polymorphic_call_targets and
record_target_from_binfo and simply never call maybe_record_node when the type
considered is abstract without concluding that list is incomplete as we do when
method can not be referred.  If the type has derivations that do not override
something, we will record the methods when walking derived type, so i do not
think we need to make difference in between destructor and other type.


Hmm, if we see

struct A
{
  virtual void f() = 0;
  virtual void g() { };
};

void f(A* a)
{
  a->g();
}

and ignore A because it's abstract, then we don't speculatively 
devirtualize the call to g, which we might want to do; it might be the 
case that most derived classes don't override g.  The destructor is 
special because all derived classes must override it.



I can prepare patch tomorrow if you prefer, thanks for looking into this!


Sounds good, thanks.

Jason

[v3] LWG 2106: move_iterator::reference

[Marc Glisse]

Hello,

this issue got delayed in LWG, apparently because of a failed 
"improvement" to the wording along the way (happens, that's ok), but there 
seems to be a consensus on the resolution and I don't really see the point 
of waiting (it changes code that currently returns a reference to a 
temporary).


Tested on x86_64-linux-gnu. Stage 1?

2014-04-01  Marc Glisse  

PR libstdc++/59434
* include/bits/stl_iterator.h (move_iterator::reference,
move_iterator::operator*): Implement LWG 2106.
* testsuite/24_iterators/move_iterator/dr2106.cc: New file.

--
Marc GlisseIndex: libstdc++-v3/include/bits/stl_iterator.h
===
--- libstdc++-v3/include/bits/stl_iterator.h(revision 208349)
+++ libstdc++-v3/include/bits/stl_iterator.h(working copy)
@@ -958,48 +958,52 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  generic algorithms can be called with move iterators to replace
*  copying with moving.
*/
   template
 class move_iterator
 {
 protected:
   _Iterator _M_current;
 
   typedef iterator_traits<_Iterator>   __traits_type;
+  typedef typename __traits_type::reference__base_ref;
 
 public:
   typedef _Iteratoriterator_type;
   typedef typename __traits_type::iterator_category iterator_category;
   typedef typename __traits_type::value_type   value_type;
   typedef typename __traits_type::difference_type  difference_type;
   // NB: DR 680.
   typedef _Iteratorpointer;
-  typedef value_type&& reference;
+  // DR 2106.
+  typedef typename conditional::value,
+typename remove_reference<__base_ref>::type&&,
+__base_ref>::type  reference;
 
   move_iterator()
   : _M_current() { }
 
   explicit
   move_iterator(iterator_type __i)
   : _M_current(__i) { }
 
   template
move_iterator(const move_iterator<_Iter>& __i)
: _M_current(__i.base()) { }
 
   iterator_type
   base() const
   { return _M_current; }
 
   reference
   operator*() const
-  { return std::move(*_M_current); }
+  { return static_cast(*_M_current); }
 
   pointer
   operator->() const
   { return _M_current; }
 
   move_iterator&
   operator++()
   {
++_M_current;
return *this;
Index: libstdc++-v3/testsuite/24_iterators/move_iterator/dr2106.cc
===
--- libstdc++-v3/testsuite/24_iterators/move_iterator/dr2106.cc (revision 0)
+++ libstdc++-v3/testsuite/24_iterators/move_iterator/dr2106.cc (working copy)
@@ -0,0 +1,33 @@
+// { dg-options "-std=gnu++11" }
+// { dg-do compile }
+
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+#include 
+
+typedef std::vector  Vec;
+typedef Vec::reference Ref;
+typedef Vec::const_reference   CRef;
+typedef Vec::iterator  It;
+typedef Vec::const_iteratorCIt;
+typedef std::move_iterator MIt;
+typedef std::move_iteratorMCIt;
+static_assert(std::is_same::value,"");
+static_assert(std::is_same::value,"");

Property changes on: libstdc++-v3/testsuite/24_iterators/move_iterator/dr2106.cc
___
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property

Re: C++ PATCH for c++/60361 (decl/expr ambiguity)

[Jason Merrill]

OK.

Jason

C++ PATCH for c++/60409 (ICE with non-dependent call in c++1y mode)

[Jason Merrill]

Various code was being confused by the PAREN_EXPR.  Let's only add them 
when the expression is dependent.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 96995b9f04091798416d64c572950df31d3add8a
Author: Jason Merrill 
Date:   Wed Mar 5 13:19:16 2014 -0500

	PR c++/60409
	* semantics.c (force_paren_expr): Only add a PAREN_EXPR to a
	dependent expression.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 4081e0e..d2c453f 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -1609,7 +1609,7 @@ force_paren_expr (tree expr)
   && TREE_CODE (expr) != SCOPE_REF)
 return expr;
 
-  if (processing_template_decl)
+  if (type_dependent_expression_p (expr))
 expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
   else
 {
diff --git a/gcc/testsuite/g++.dg/cpp1y/regress1.C b/gcc/testsuite/g++.dg/cpp1y/regress1.C
new file mode 100644
index 000..94b00eb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/regress1.C
@@ -0,0 +1,12 @@
+// PR c++/60409
+// { dg-options -std=c++1y }
+
+struct A
+{
+  void foo();
+};
+
+template void bar(T)
+{
+  (A().foo)();
+}

Re: [PATCH] Properly check for _Cilk_spawn in return stmt (PR c/60197)

[Jeff Law]

On 02/26/14 08:21, Marek Polacek wrote:

Ping.

Based on Balaji's comments, OK.

jeff

Re: RFA: New ipa-devirt PATCH for c++/58678 (devirt vs. KDE)

[Jakub Jelinek]

On Wed, Mar 05, 2014 at 07:40:06PM +0100, Jan Hubicka wrote:
> > gcc/cp/
> > * search.c (get_pure_virtuals): Set BINFO_ABSTRACT_P.
> > * tree.c (copy_binfo): Copy it.
> 
> You need to also save and restre the flag in LTO streaming.
> I can prepare patch tomorrow if you preffer, thanks for looking into this!

It is TREE_ADDRESSABLE, isn't it streamed already?

> > --- a/gcc/tree.h
> > +++ b/gcc/tree.h
> > @@ -1804,6 +1804,9 @@ extern void protected_set_expr_location (tree, 
> > location_t);
> >  /* Nonzero means that the derivation chain is via a `virtual' declaration. 
> >  */
> >  #define BINFO_VIRTUAL_P(NODE) (TREE_BINFO_CHECK (NODE)->base.static_flag)
> >  
> > +/* Nonzero means that the base is an abstract class.  */
> > +#define BINFO_ABSTRACT_P(NODE) (TREE_BINFO_CHECK 
> > (NODE)->base.addressable_flag)
> > +
> >  /* Flags for language dependent use.  */
> >  #define BINFO_MARKED(NODE) TREE_LANG_FLAG_0 (TREE_BINFO_CHECK (NODE))
> >  #define BINFO_FLAG_1(NODE) TREE_LANG_FLAG_1 (TREE_BINFO_CHECK (NODE))

Jakub

Re: RFA: New ipa-devirt PATCH for c++/58678 (devirt vs. KDE)

[Jan Hubicka]

> > This patch fixes the latest 58678 testcase by avoiding speculative
> > devirtualization to the destructor of an abstract class, which can
> > never succeed: you can't create an object of an abstract class, so
> > the pointer must point to an object of a derived class, and the
> > derived class necessarily has its own destructor.  Other virtual
> > member functions of an abstract class are OK for devirtualization:
> > the destructor is the only virtual function that is always
> > overridden in every class.]
> > 
> > We could also detect an abstract class by searching through the
> > vtable for __cxa_pure_virtual, but I figured it was easy enough for
> > the front end to set a flag on the BINFO.
> > 
> > Tested x86_64-pc-linux-gnu.  OK for trunk?
> 
> > commit b64f52066f3f4cdc9d5a30e2d48aaf6dd5efd3d4
> > Author: Jason Merrill 
> > Date:   Wed Mar 5 11:35:07 2014 -0500
> > 
> > PR c++/58678
> > gcc/
> > * tree.h (BINFO_ABSTRACT_P): New.
> > * ipa-devirt.c (abstract_class_dtor_p): New.
> > (likely_target_p): Check it.
> 
> I think the abstract classes probably shuld never be considered in the type
> inheritance graph walk as possible instances. That is we probably want to test
> them in record_targets_from_bases, possible_polymorphic_call_targets and
> record_target_from_binfo and simply never call maybe_record_node when the type
> considered is abstract without concluding that list is incomplete as we do 
> when
> method can not be referred.  If the type has derivations that do not override
> something, we will record the methods when walking derrived type, so i do not
> think we need to make difference in between destructor and other type.
> 
> We also want to sanity check that after get_class_context the outer_type
> is not abstract or maybe_derived_type is set. 
> > gcc/cp/
> > * search.c (get_pure_virtuals): Set BINFO_ABSTRACT_P.
> > * tree.c (copy_binfo): Copy it.
> 
> You need to also save and restre the flag in LTO streaming.
> 
> I can prepare patch tomorrow if you preffer, thanks for looking into this!

BTW it would conserve little bit of memory & streaming if we also stripped 
DECL_INITIAL
of those vtables. They should never be needed. (We still need DECL_VTABLE to be 
able to
work out ODR equivalence, since the types must be in type inheritance tree)

Honza

Re: C++ PATCH for c++/60361 (decl/expr ambiguity)

[Paolo Carlini]

... finishing testing the below.

Thanks,
Paolo.

///
2014-03-05  Paolo Carlini  

* parser.c (cp_lexer_set_source_position): New.
(cp_parser_mem_initializer): Use it.
(cp_parser_postfix_open_square_expression): Likewise.
(cp_parser_parenthesized_expression_list): Likewise.
(cp_parser_new_initializer): Likewise.
(cp_parser_jump_statement): Likewise.
(cp_parser_initializer): Likewise.
(cp_parser_functional_cast): Likewise.
Index: parser.c
===
--- parser.c(revision 208351)
+++ parser.c(working copy)
@@ -844,6 +844,14 @@ cp_lexer_set_source_position_from_token (cp_token
 }
 }
 
+/* Update the globals input_location and the input file stack from LEXER.  */
+static inline void
+cp_lexer_set_source_position (cp_lexer *lexer)
+{
+  cp_token *token = cp_lexer_peek_token (lexer);
+  cp_lexer_set_source_position_from_token (token);
+}
+
 /* Return a pointer to the next token in the token stream, but do not
consume it.  */
 
@@ -6359,8 +6367,7 @@ cp_parser_postfix_open_square_expression (cp_parse
   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
{
  bool expr_nonconst_p;
- cp_token *token = cp_lexer_peek_token (parser->lexer);
- cp_lexer_set_source_position_from_token (token);
+ cp_lexer_set_source_position (parser->lexer);
  maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
  index = cp_parser_braced_list (parser, &expr_nonconst_p);
  if (flag_cilkplus
@@ -6673,8 +6680,7 @@ cp_parser_parenthesized_expression_list (cp_parser
if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
  {
/* A braced-init-list.  */
-   cp_token *token = cp_lexer_peek_token (parser->lexer);
-   cp_lexer_set_source_position_from_token (token);
+   cp_lexer_set_source_position (parser->lexer);
maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
expr = cp_parser_braced_list (parser, &expr_non_constant_p);
if (non_constant_p && expr_non_constant_p)
@@ -7523,8 +7529,7 @@ cp_parser_new_initializer (cp_parser* parser)
 {
   tree t;
   bool expr_non_constant_p;
-  cp_token *token = cp_lexer_peek_token (parser->lexer);
-  cp_lexer_set_source_position_from_token (token);
+  cp_lexer_set_source_position (parser->lexer);
   maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
   t = cp_parser_braced_list (parser, &expr_non_constant_p);
   CONSTRUCTOR_IS_DIRECT_INIT (t) = 1;
@@ -10681,8 +10686,7 @@ cp_parser_jump_statement (cp_parser* parser)
 
if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
  {
-   cp_token *token = cp_lexer_peek_token (parser->lexer);
-   cp_lexer_set_source_position_from_token (token);
+   cp_lexer_set_source_position (parser->lexer);
maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
expr = cp_parser_braced_list (parser, &expr_non_constant_p);
  }
@@ -12361,8 +12365,7 @@ cp_parser_mem_initializer (cp_parser* parser)
   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
 {
   bool expr_non_constant_p;
-  cp_token *token = cp_lexer_peek_token (parser->lexer);
-  cp_lexer_set_source_position_from_token (token);
+  cp_lexer_set_source_position (parser->lexer);
   maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
   expression_list = cp_parser_braced_list (parser, &expr_non_constant_p);
   CONSTRUCTOR_IS_DIRECT_INIT (expression_list) = 1;
@@ -18816,8 +18819,7 @@ cp_parser_initializer (cp_parser* parser, bool* is
 }
   else if (token->type == CPP_OPEN_BRACE)
 {
-  cp_token *token = cp_lexer_peek_token (parser->lexer);
-  cp_lexer_set_source_position_from_token (token);
+  cp_lexer_set_source_position (parser->lexer);
   maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
   init = cp_parser_braced_list (parser, non_constant_p);
   CONSTRUCTOR_IS_DIRECT_INIT (init) = 1;
@@ -23253,8 +23255,7 @@ cp_parser_functional_cast (cp_parser* parser, tree
 
   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
 {
-  cp_token *token = cp_lexer_peek_token (parser->lexer);
-  cp_lexer_set_source_position_from_token (token);
+  cp_lexer_set_source_position (parser->lexer);
   maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
   expression_list = cp_parser_braced_list (parser, &nonconst_p);
   CONSTRUCTOR_IS_DIRECT_INIT (expression_list) = 1;

Re: RFA: New ipa-devirt PATCH for c++/58678 (devirt vs. KDE)

[Jan Hubicka]

> This patch fixes the latest 58678 testcase by avoiding speculative
> devirtualization to the destructor of an abstract class, which can
> never succeed: you can't create an object of an abstract class, so
> the pointer must point to an object of a derived class, and the
> derived class necessarily has its own destructor.  Other virtual
> member functions of an abstract class are OK for devirtualization:
> the destructor is the only virtual function that is always
> overridden in every class.]
> 
> We could also detect an abstract class by searching through the
> vtable for __cxa_pure_virtual, but I figured it was easy enough for
> the front end to set a flag on the BINFO.
> 
> Tested x86_64-pc-linux-gnu.  OK for trunk?

> commit b64f52066f3f4cdc9d5a30e2d48aaf6dd5efd3d4
> Author: Jason Merrill 
> Date:   Wed Mar 5 11:35:07 2014 -0500
> 
>   PR c++/58678
> gcc/
>   * tree.h (BINFO_ABSTRACT_P): New.
>   * ipa-devirt.c (abstract_class_dtor_p): New.
>   (likely_target_p): Check it.

I think the abstract classes probably shuld never be considered in the type
inheritance graph walk as possible instances. That is we probably want to test
them in record_targets_from_bases, possible_polymorphic_call_targets and
record_target_from_binfo and simply never call maybe_record_node when the type
considered is abstract without concluding that list is incomplete as we do when
method can not be referred.  If the type has derivations that do not override
something, we will record the methods when walking derrived type, so i do not
think we need to make difference in between destructor and other type.

We also want to sanity check that after get_class_context the outer_type
is not abstract or maybe_derived_type is set. 
> gcc/cp/
>   * search.c (get_pure_virtuals): Set BINFO_ABSTRACT_P.
>   * tree.c (copy_binfo): Copy it.

You need to also save and restre the flag in LTO streaming.

I can prepare patch tomorrow if you preffer, thanks for looking into this!
Honza
> 
> diff --git a/gcc/cp/search.c b/gcc/cp/search.c
> index c3eed90..7a3ea4b 100644
> --- a/gcc/cp/search.c
> +++ b/gcc/cp/search.c
> @@ -2115,6 +2115,8 @@ get_pure_virtuals (tree type)
>   which it is a primary base will contain vtable entries for the
>   pure virtuals in the base class.  */
>dfs_walk_once (TYPE_BINFO (type), NULL, dfs_get_pure_virtuals, type);
> +  if (CLASSTYPE_PURE_VIRTUALS (type))
> +BINFO_ABSTRACT_P (TYPE_BINFO (type)) = true;
>  }
>  
>  /* Debug info for C++ classes can get very large; try to avoid
> diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
> index 5567253..3836e16 100644
> --- a/gcc/cp/tree.c
> +++ b/gcc/cp/tree.c
> @@ -1554,6 +1554,7 @@ copy_binfo (tree binfo, tree type, tree t, tree 
> *igo_prev, int virt)
>  
>BINFO_OFFSET (new_binfo) = BINFO_OFFSET (binfo);
>BINFO_VIRTUALS (new_binfo) = BINFO_VIRTUALS (binfo);
> +  BINFO_ABSTRACT_P (new_binfo) = BINFO_ABSTRACT_P (binfo);
>  
>/* We do not need to copy the accesses, as they are read only.  */
>BINFO_BASE_ACCESSES (new_binfo) = BINFO_BASE_ACCESSES (binfo);
> diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
> index 2f84f17..3f4a1d5 100644
> --- a/gcc/ipa-devirt.c
> +++ b/gcc/ipa-devirt.c
> @@ -1674,6 +1674,19 @@ update_type_inheritance_graph (void)
>timevar_pop (TV_IPA_INHERITANCE);
>  }
>  
> +/* A destructor for an abstract class is not likely because it can never be
> +   called through the vtable; any actual object will have a derived type,
> +   which will have its own destructor.  */
> +
> +static bool
> +abstract_class_dtor_p (tree fn)
> +{
> +  if (!DECL_CXX_DESTRUCTOR_P (fn))
> +return false;
> +  tree type = DECL_CONTEXT (fn);
> +  tree binfo = TYPE_BINFO (type);
> +  return BINFO_ABSTRACT_P (binfo);
> +}
>  
>  /* Return true if N looks like likely target of a polymorphic call.
> Rule out cxa_pure_virtual, noreturns, function declared cold and
> @@ -1694,6 +1707,8 @@ likely_target_p (struct cgraph_node *n)
>  return false;
>if (n->frequency < NODE_FREQUENCY_NORMAL)
>  return false;
> +  if (abstract_class_dtor_p (n->decl))
> +return false;
>return true;
>  }
>  
> diff --git a/gcc/testsuite/g++.dg/ipa/devirt-30.C 
> b/gcc/testsuite/g++.dg/ipa/devirt-30.C
> new file mode 100644
> index 000..c4ac694
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ipa/devirt-30.C
> @@ -0,0 +1,25 @@
> +// PR c++/58678
> +// { dg-options "-O3 -fdump-ipa-devirt" }
> +
> +// We shouldn't speculatively devirtualize to ~B because B is an abstract
> +// class; any actual object passed to f will be of some derived class which
> +// has its own destructor.
> +
> +struct A
> +{
> +  virtual void f() = 0;
> +  virtual ~A();
> +};
> +
> +struct B : A
> +{
> +  virtual ~B() {}
> +};
> +
> +void f(B* b)
> +{
> +  delete b;
> +}
> +
> +// { dg-final { scan-ipa-dump-not "Speculatively devirtualizing" "devirt" } }
> +// { dg-final { cleanup-ipa-dump "devirt" } }
> diff --git a/gcc/tree-core.h b/gcc/

Re: C++ PATCH for c++/60361 (decl/expr ambiguity)

[Paolo Carlini]

Hi,

On 03/05/2014 06:35 PM, Jason Merrill wrote:

+ cp_token *token = cp_lexer_peek_token (parser->lexer);
+ cp_lexer_set_source_position_from_token (token);
Shall we add a static inline void cp_lexer_set_source_position (cp_lexer 
*lexer)? We do have a couple of existing instances too...


Paolo.

C++ PATCH for c++/60361 (decl/expr ambiguity)

[Jason Merrill]

The problem in this testcase was that we were initially tentatively 
parsing int(A) as a parameter declaration, then complaining about using 
that parameter as a template-argument.  We should treat it as a parse 
error rather than a semantic error until we know how we really want to 
parse  things.


The second patch fixes the diagnostic location of the pedwarn about 
using list-initialization in C++98 mode.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4c3bf0de12cf730edf673cddedf43f8bdc8ef7ff
Author: Jason Merrill 
Date:   Mon Mar 3 15:41:03 2014 -0500

	PR c++/60361
	* parser.c (cp_parser_template_id): Don't set up a CPP_TEMPLATE_ID
	if re-parsing might succeed.
	* semantics.c (finish_id_expression): Use of a parameter outside
	the function body is a parse error.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 5b3e489..b56870d 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13466,7 +13466,12 @@ cp_parser_template_id (cp_parser *parser,
  the effort required to do the parse, nor will we issue duplicate
  error messages about problems during instantiation of the
  template.  */
-  if (start_of_id)
+  if (start_of_id
+  /* Don't do this if we had a parse error in a declarator; re-parsing
+	 might succeed if a name changes meaning (60361).  */
+  && !(cp_parser_error_occurred (parser)
+	   && cp_parser_parsing_tentatively (parser)
+	   && parser->in_declarator_p))
 {
   cp_token *token = cp_lexer_token_at (parser->lexer, start_of_id);
 
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 787eab8..4081e0e 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3246,7 +3246,7 @@ finish_id_expression (tree id_expression,
 	  && DECL_CONTEXT (decl) == NULL_TREE
 	  && !cp_unevaluated_operand)
 	{
-	  error ("use of parameter %qD outside function body", decl);
+	  *error_msg = "use of parameter outside function body";
 	  return error_mark_node;
 	}
 }
diff --git a/gcc/testsuite/g++.dg/parse/ambig7.C b/gcc/testsuite/g++.dg/parse/ambig7.C
new file mode 100644
index 000..9a5b879
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/ambig7.C
@@ -0,0 +1,16 @@
+// PR c++/60361
+
+struct Helper
+{
+  Helper(int a, void (*pfunc)());
+};
+
+template  void function();
+
+const int A = 1;
+const int B = 2;
+
+Helper testOk(A, function);
+Helper testOk2(int(A), function);
+Helper testOk3((int(A)), function);
+Helper testFail(int(A), function);
diff --git a/gcc/testsuite/g++.dg/parse/parameter-declaration-2.C b/gcc/testsuite/g++.dg/parse/parameter-declaration-2.C
index 6116630..3c983cc 100644
--- a/gcc/testsuite/g++.dg/parse/parameter-declaration-2.C
+++ b/gcc/testsuite/g++.dg/parse/parameter-declaration-2.C
@@ -1,2 +1,2 @@
-void f (int i, int p[i]); // { dg-error "use of parameter .i. outside function body" }
+void f (int i, int p[i]); // { dg-error "use of parameter.*outside function body" }
 // { dg-prune-output "array bound" }
diff --git a/gcc/testsuite/g++.dg/parse/typename7.C b/gcc/testsuite/g++.dg/parse/typename7.C
index 6ec7696..e49a1ec 100644
--- a/gcc/testsuite/g++.dg/parse/typename7.C
+++ b/gcc/testsuite/g++.dg/parse/typename7.C
@@ -7,10 +7,9 @@
 
 struct A
 {
-  template   void foo(int); // { dg-message "note" }
-  template void bar(T t) { // { dg-message "note" }
+  template   void foo(int);
+  template void bar(T t) {
 this->foo(t); } // { dg-error "expected|parse error|no matching" }
-  // { dg-message "candidate" "candidate note" { target *-*-* } 12 }
   template void bad(T t) {
 foo(t); } // { dg-error "expected|parse error|no matching" }
 };
@@ -20,7 +19,6 @@ struct B
 {
   void bar(T t) {
 A().bar(t); } // { dg-error "expected|parse error|no matching" }
-  // { dg-message "candidate" "candidate note" { target *-*-* } 22 }
   void bad(T t) {
 B::bar(t); } // { dg-error "invalid|qualified-id|not a template" }
 };
commit 575a4d70513faec5d8a66fe818a48a6abcf91500
Author: Jason Merrill 
Date:   Mon Mar 3 16:39:46 2014 -0500

	* parser.c (cp_parser_mem_initializer): Set input_location
	properly for init-list warning.
	(cp_parser_postfix_open_square_expression): Likewise.
	(cp_parser_parenthesized_expression_list): Likewise.
	(cp_parser_new_initializer): Likewise.
	(cp_parser_jump_statement): Likewise.
	(cp_parser_initializer): Likewise.
	(cp_parser_functional_cast): Likewise.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index bb7d268..5b3e489 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6359,6 +6359,8 @@ cp_parser_postfix_open_square_expression (cp_parser *parser,
   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
 	{
 	  bool expr_nonconst_p;
+	  cp_token *token = cp_lexer_peek_token (parser->lexer);
+	  cp_lexer_set_source_position_from_token (token);
 	  maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
 	  index = cp_parser_braced_list (parser, &expr_nonconst_p);
 	  if (flag_cilkplus
@@ -6671,6 +6673,8 @@ cp_parser_parenthesized_expression_list (cp_parser*

Re: [PATCH, x86] X86 Silvermont vector cost model tune

[Uros Bizjak]

On Wed, Mar 5, 2014 at 5:46 PM, H.J. Lu  wrote:
> On Wed, Mar 5, 2014 at 7:58 AM, Evgeny Stupachenko  wrote:
>> Hi,
>>
>> The patch is for x86 Silvermont.
>> It improves x86 Silvermont vector cost model.
>> It gives +20% on facerec spec on Silvermont.
>> It passes make check and bootstrap on x86.
>>
>> Is this patch ok for stage1?
>>
>> ChangeLog:
>>
>> 2014-03-05  Evgeny Stupachenko  
>>
>> * config/i386/x86-tune.def (TARGET_SLOW_PSHUFB): Target for slow byte
>> shuffle on some x86 architectures.
>> * config/i386/i386.h (TARGET_SLOW_PSHUFB): Ditto.
>> * config/i386/i386.c (processor_costs): Fixing vec_to_scalar_cost for
>> Silvermont according latency table.
>> (expand_vec_perm_even_odd_1): Avoid byte shuffles in architectures
>> where they are slow (TARGET_SLOW_PSHUFB).
>> (x86_add_stmt_cost): Fixing vector cost model for Silvermont.
>>
>> Thanks,
>> Evgeny
>
> There are 3 separate changes in this patch:
>
> 1. Update slm_cost, which doesn't have a ChangeLog entry.
> 2. Add TARGET_SLOW_PSHUFB.
> 3. Update ix86_add_stmt_cost.
>
> I suggest you break it into 3 independent patches.

I think that slm_cost/intel_cost and TARGET_SLOW_PSHUFB changes can
still go into mainline at this stage since they are trivial tuning
changes that should not destabilize the compiler.

The  ix86_add_stmt_cost should wait for stage 1.

Uros.

Re: Patch RFC: Use internal qsort function in libbacktrace

[Ondřej Bílka]

On Wed, Mar 05, 2014 at 08:05:25AM -0800, Ian Lance Taylor wrote:
> On Wed, Mar 5, 2014 at 1:25 AM, Richard Biener
>  wrote:
> > On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor  wrote:
> >> The GNU glibc qsort function will call malloc in some cases.  That makes
> >> it unsuitable for libbacktrace, which is intended to work when called
> >> from a signal handler.  This patch changes libbacktrace to use an
> >> internal qsort function.
> >>
Another solution is use a malloc wrapper that makes to make malloc signal
safe. Problem with this solution is that its on application layer, not
library one. I am trying to add a signal safety to glibc.

Re: [build, i386] Disable local dynamic TLS model on Solaris/x86 if as/ld cannot handle it

[Uros Bizjak]

On Wed, Mar 5, 2014 at 4:53 PM, Rainer Orth  
wrote:
> When using GNU as with Solaris ld, the TLS local dynamic tests
> (gcc.dg/torture/tls/run-ld.c etc.) FAIL to execute before Solaris 11:
> the programs crash with an illegal instruction: e.g. in the
> gcc.dg/lto/20090210 test, we have
>
> 0x8050ce0 : mov%gs:0x0,%eax
> 0x8050ce6 : call   0x8050ce7 
> 0x8050ce7 : cld
> 0x8050ce8 : (bad)
>
> The reason is that Solaris ld before Solaris 11 requires the use of the
> @tlsldmplt relocation documented in the Solaris 10 Linker and Libraries
> Guide:
>
> http://docs.oracle.com/cd/E26505_01/html/E26506/chapter8-20.html#gentextid-23600
>
> Unfortunately, gas doesn't support that relocation.  While adding the
> gas side was easy, I completely failed for gld and didn't propose the
> incomplete patch to binutils since it would (rightly) have been
> rejected.
>
> Old versions of ld mishandle the TLS LD code sequence emitted by gcc
> when @tlsldmplt isn't available, causing the crashes observed.  So ld
> cannot handle what gas emits and gas cannot emit what ld requires.  The
> only solution seems to fall back to the GD model in that case, which is
> ugly but certainly better than having perfectly valid programs crash.
>
> The following patch does just that.  It carefully restricts its actions
> to Solaris.  I'm falling back to using dis when objdump isn't available
> to avoid enabling this fallback unnecessarily.
>
> Bootstraps on i386-pc-solaris2.{9,10,11} (as/ld, gas/ld, gas/gld,
> as/gld), amd64-pc-solaris2.{10,11} (as/ld, gas/ld),
> x86_64-unknown-linux-gnu, and i686-unknown-linux-gnu either completed
> successfully or still running.
>
> Ok for mainline if those pass?
>
> Thanks.
> Rainer
>
>
> 2014-03-04  Rainer Orth  
>
> * configure.ac (TLS_SECTION_ASM_FLAG): Save as tls_section_flag.
> (LIB_TLS_SPEC): Save as ld_tls_libs.
> (HAVE_AS_IX86_TLSLDMPLT): Define as 1/0.
> (HAVE_AS_IX86_TLSLDM): New test.
> * configure, config.in: Regenerate.
> * config/i386/i386.c (legitimize_tls_address): Fall back to
> TLS_MODEL_GLOBAL_DYNAMIC on 32-bit Solaris/x86 if tool chain
> cannot support TLS_MODEL_LOCAL_DYNAMIC.
> * config/i386/i386.md (*tls_local_dynamic_base_32_gnu): Use if
> instead of #ifdef in HAVE_AS_IX86_TLSLDMPLT test.

OK for mainline on x86 part (and the configure check approach). The
patch still needs build maintainer approval as the added code in
config.in does not look that trivial to me.

Thanks,
Uros.

RFA: New ipa-devirt PATCH for c++/58678 (devirt vs. KDE)

[Jason Merrill]

This patch fixes the latest 58678 testcase by avoiding speculative 
devirtualization to the destructor of an abstract class, which can never 
succeed: you can't create an object of an abstract class, so the pointer 
must point to an object of a derived class, and the derived class 
necessarily has its own destructor.  Other virtual member functions of 
an abstract class are OK for devirtualization: the destructor is the 
only virtual function that is always overridden in every class.


We could also detect an abstract class by searching through the vtable 
for __cxa_pure_virtual, but I figured it was easy enough for the front 
end to set a flag on the BINFO.


Tested x86_64-pc-linux-gnu.  OK for trunk?
commit b64f52066f3f4cdc9d5a30e2d48aaf6dd5efd3d4
Author: Jason Merrill 
Date:   Wed Mar 5 11:35:07 2014 -0500

	PR c++/58678
gcc/
	* tree.h (BINFO_ABSTRACT_P): New.
	* ipa-devirt.c (abstract_class_dtor_p): New.
	(likely_target_p): Check it.
gcc/cp/
	* search.c (get_pure_virtuals): Set BINFO_ABSTRACT_P.
	* tree.c (copy_binfo): Copy it.

diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index c3eed90..7a3ea4b 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -2115,6 +2115,8 @@ get_pure_virtuals (tree type)
  which it is a primary base will contain vtable entries for the
  pure virtuals in the base class.  */
   dfs_walk_once (TYPE_BINFO (type), NULL, dfs_get_pure_virtuals, type);
+  if (CLASSTYPE_PURE_VIRTUALS (type))
+BINFO_ABSTRACT_P (TYPE_BINFO (type)) = true;
 }
 
 /* Debug info for C++ classes can get very large; try to avoid
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 5567253..3836e16 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1554,6 +1554,7 @@ copy_binfo (tree binfo, tree type, tree t, tree *igo_prev, int virt)
 
   BINFO_OFFSET (new_binfo) = BINFO_OFFSET (binfo);
   BINFO_VIRTUALS (new_binfo) = BINFO_VIRTUALS (binfo);
+  BINFO_ABSTRACT_P (new_binfo) = BINFO_ABSTRACT_P (binfo);
 
   /* We do not need to copy the accesses, as they are read only.  */
   BINFO_BASE_ACCESSES (new_binfo) = BINFO_BASE_ACCESSES (binfo);
diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 2f84f17..3f4a1d5 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1674,6 +1674,19 @@ update_type_inheritance_graph (void)
   timevar_pop (TV_IPA_INHERITANCE);
 }
 
+/* A destructor for an abstract class is not likely because it can never be
+   called through the vtable; any actual object will have a derived type,
+   which will have its own destructor.  */
+
+static bool
+abstract_class_dtor_p (tree fn)
+{
+  if (!DECL_CXX_DESTRUCTOR_P (fn))
+return false;
+  tree type = DECL_CONTEXT (fn);
+  tree binfo = TYPE_BINFO (type);
+  return BINFO_ABSTRACT_P (binfo);
+}
 
 /* Return true if N looks like likely target of a polymorphic call.
Rule out cxa_pure_virtual, noreturns, function declared cold and
@@ -1694,6 +1707,8 @@ likely_target_p (struct cgraph_node *n)
 return false;
   if (n->frequency < NODE_FREQUENCY_NORMAL)
 return false;
+  if (abstract_class_dtor_p (n->decl))
+return false;
   return true;
 }
 
diff --git a/gcc/testsuite/g++.dg/ipa/devirt-30.C b/gcc/testsuite/g++.dg/ipa/devirt-30.C
new file mode 100644
index 000..c4ac694
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/devirt-30.C
@@ -0,0 +1,25 @@
+// PR c++/58678
+// { dg-options "-O3 -fdump-ipa-devirt" }
+
+// We shouldn't speculatively devirtualize to ~B because B is an abstract
+// class; any actual object passed to f will be of some derived class which
+// has its own destructor.
+
+struct A
+{
+  virtual void f() = 0;
+  virtual ~A();
+};
+
+struct B : A
+{
+  virtual ~B() {}
+};
+
+void f(B* b)
+{
+  delete b;
+}
+
+// { dg-final { scan-ipa-dump-not "Speculatively devirtualizing" "devirt" } }
+// { dg-final { cleanup-ipa-dump "devirt" } }
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index e548a0d..708a8ab 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -786,6 +786,9 @@ struct GTY(()) tree_base {
PREDICT_EXPR_OUTCOME in
 	   PREDICT_EXPR
 
+   BINFO_ABSTRACT_P in
+   TREE_BINFO
+
static_flag:
 
TREE_STATIC in
diff --git a/gcc/tree.h b/gcc/tree.h
index 0dc8d0d..01e23ec 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -1804,6 +1804,9 @@ extern void protected_set_expr_location (tree, location_t);
 /* Nonzero means that the derivation chain is via a `virtual' declaration.  */
 #define BINFO_VIRTUAL_P(NODE) (TREE_BINFO_CHECK (NODE)->base.static_flag)
 
+/* Nonzero means that the base is an abstract class.  */
+#define BINFO_ABSTRACT_P(NODE) (TREE_BINFO_CHECK (NODE)->base.addressable_flag)
+
 /* Flags for language dependent use.  */
 #define BINFO_MARKED(NODE) TREE_LANG_FLAG_0 (TREE_BINFO_CHECK (NODE))
 #define BINFO_FLAG_1(NODE) TREE_LANG_FLAG_1 (TREE_BINFO_CHECK (NODE))

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

[Ilya Verbin]

On 28 Feb 17:21, Bernd Schmidt wrote:
> I think it won't help that much - I still think this entire scheme
> is likely to fail on nvptx. I'll try to construct an example at some
> point.
> 
> One other thing about the split tables is that we don't have to
> write a useless size of 1 for functions.
> 
> 
> The concept of "image" is likely to vary somewhat between
> accelerators. For ptx, it's just a string and it can't really be
> generated the same way as for your target where you can manipulate
> ELF images. So I think it is better to have a call to a gomp
> registration function for every offload target. That should also
> give you the ordering you said you wanted between shared libraries.
> 
> 
> Probably. I think the constructor call to the gomp registration
> function would contain an opaque pointer to whatever data the target
> wants, so it can arrange its image/table data in whatever way it
> likes.

Assuming that we're using the scheme with tables.
Every DSO with offloading must contain a constructor call to 
GOMP_offload_register (const void *openmp_target);
The openmp_target descriptor in every DSO will have target-independent entries 
(addresses of host tables) and target-dependent entries for each target. Its 
format may be like this:

void *__OPENMP_TARGET__[] =
{
  _omp_host_func_table;
  _omp_host_funcs_end;
  _omp_host_var_table;
  _omp_host_vars_end;
  _omp_num_targets;
  _omp_target_descs[]; /* array of tgt_desc */
}

struct tgt_desc
{
  int _omp_tgt_id;
  void *_omp_tgt_%s_image_start;
  void *_omp_tgt_%s_image_end;
  void *_omp_tgt_%s_func_mappings;
  void *_omp_tgt_%s_var_mappings;
  /* some other data if needed */
}

The mkoffload tool will fill those symbols, that are required by the 
corresponding target.
E.g. for the MIC and PTX targets the openmp_target descriptor will look like:

{
  &_omp_host_func_table,
  &_omp_host_funcs_end,
  &_omp_host_var_table,
  &_omp_host_vars_end,
  2,

  MIC_ID,
  &_omp_tgt_mic_image_start,
  &_omp_tgt_mic_image_end,
  &_omp_tgt_mic_func_mappings, /* 0 */
  &_omp_tgt_mic_var_mappings, /* 0 */

  PTX_ID,
  &_omp_tgt_ptx_image_start,
  &_omp_tgt_ptx_image_end, /* 0 */
  &_omp_tgt_ptx_func_mappings,
  &_omp_tgt_ptx_var_mappings
}

During the devices initialization libgomp will pass the openmp_target pointer 
to all plugins. Each plugin will scan over tgt_descs and find the required 
entries using the _omp_tgt_id.
Then the plugin loads the image to the target, does whatever it wants, and 
returns func_mappings and var_mappings to libgomp, because libgomp has to add 
host-target mapping into the splay tree.
How does this look?

BTW, do you have any estimate when you will commit your patches to the branch, 
so that we could merge them with ours, and get something working for everybody?

  -- Ilya

ICE in gcc/c/c-typeck.c:c_finish_omp_clauses -- The error_mark_node is not an OpenMP mappable type

[Thomas Schwinge]

Hi!

../../map.c: In function 'main':
../../map.c:4:21: error: array type has incomplete element type
   extern struct foo s2[1];
 ^
../../map.c:8:11: internal compiler error: tree check: expected class 
'type', have 'exceptional' (error_mark) in c_finish_omp_clauses, at 
c/c-typeck.c:12126
   #pragma omp target map(s2) /* { dg-error "array type has incomplete 
element type" } */
   ^
0xe5cf3a tree_class_check_failed(tree_node const*, tree_code_class, char 
const*, int, char const*)
../../source/gcc/tree.c:9271
0x580866 tree_class_check
../../source/gcc/tree.h:2894
0x580866 c_finish_omp_clauses(tree_node*)
../../source/gcc/c/c-typeck.c:12126
0x59f99b c_parser_omp_all_clauses
../../source/gcc/c/c-parser.c:11367
0x5ad404 c_parser_omp_target
../../source/gcc/c/c-parser.c:13081
[...]

This does not happen for C++, because gcc/cp/decl2.c:cp_omp_mappable_type
catches the »type == error_mark_node« case -- so I suggest to do the same
generically/for C.  OK to commit the following to trunk, once tested?

commit 63aa927ea54304f6bfd119ad7f72a0322e059637
Author: Thomas Schwinge 
Date:   Wed Mar 5 17:06:50 2014 +0100

The error_mark_node is not an OpenMP mappable type.

gcc/
* langhooks.c (lhd_omp_mappable_type): The error_mark_node is not
an OpenMP mappable type.
gcc/c/
* c-decl.c (c_decl_attributes): Use
lang_hooks.types.omp_mappable_type.
* c-typeck.c (c_finish_omp_clauses): Likewise.
gcc/testsuite/
* c-c++-common/gomp/map-1.c: Extend.

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 7a7d68e..2c41bf2 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -4024,7 +4024,7 @@ c_decl_attributes (tree *node, tree attributes, int flags)
error ("%q+D in block scope inside of declare target directive",
   *node);
   else if (TREE_CODE (*node) == VAR_DECL
-  && !COMPLETE_TYPE_P (TREE_TYPE (*node)))
+  && !lang_hooks.types.omp_mappable_type (TREE_TYPE (*node)))
error ("%q+D in declare target directive does not have mappable type",
   *node);
   else
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 191adfb..65ef1f3 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -12082,7 +12082,7 @@ c_finish_omp_clauses (tree clauses)
  else
{
  t = OMP_CLAUSE_DECL (c);
- if (!COMPLETE_TYPE_P (TREE_TYPE (t)))
+ if (!lang_hooks.types.omp_mappable_type (TREE_TYPE (t)))
{
  error_at (OMP_CLAUSE_LOCATION (c),
"array section does not have mappable type "
@@ -12111,9 +12111,9 @@ c_finish_omp_clauses (tree clauses)
}
  else if (!c_mark_addressable (t))
remove = true;
- else if (!COMPLETE_TYPE_P (TREE_TYPE (t))
-  && !(OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
-   && OMP_CLAUSE_MAP_KIND (c) == OMP_CLAUSE_MAP_POINTER))
+ else if (!(OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
+&& OMP_CLAUSE_MAP_KIND (c) == OMP_CLAUSE_MAP_POINTER)
+  && !lang_hooks.types.omp_mappable_type (TREE_TYPE (t)))
{
  error_at (OMP_CLAUSE_LOCATION (c),
"%qD does not have a mappable type in %qs clause", t,
diff --git gcc/langhooks.c gcc/langhooks.c
index eca0299..d00ebd8 100644
--- gcc/langhooks.c
+++ gcc/langhooks.c
@@ -524,13 +524,15 @@ lhd_omp_firstprivatize_type_sizes (struct 
gimplify_omp_ctx *c ATTRIBUTE_UNUSED,
 {
 }
 
-/* Return true if TYPE is an OpenMP mappable type.  By default return true
-   if type is complete.  */
+/* Return true if TYPE is an OpenMP mappable type.  */
 
 bool
 lhd_omp_mappable_type (tree type)
 {
-  return COMPLETE_TYPE_P (type);
+  /* Mappable type has to be complete.  */
+  if (type == error_mark_node || !COMPLETE_TYPE_P (type))
+return false;
+  return true;
 }
 
 /* Common function for add_builtin_function and
diff --git gcc/testsuite/c-c++-common/gomp/map-1.c 
gcc/testsuite/c-c++-common/gomp/map-1.c
index 694d88c..5dad7d6 100644
--- gcc/testsuite/c-c++-common/gomp/map-1.c
+++ gcc/testsuite/c-c++-common/gomp/map-1.c
@@ -8,6 +8,8 @@ int k[10], l[10], m[10], n[10], o;
 int *p;
 int **q;
 int r[4][4][4][4][4];
+extern struct s s1;
+extern struct s s2[1]; /* { dg-error "array type has incomplete element type" 
"" { target c } } */
 int t[10];
 #pragma omp threadprivate (t)
 #pragma omp declare target
@@ -32,6 +34,10 @@ foo (int g[3][10], int h[4][8], int i[2][10], int j[][9],
 ;
   #pragma omp target map(to: o[2:5]) /* { dg-error "does not have pointer or 
array type" } */
 ;
+  #pragma omp target map(alloc: s1) /* { dg-error "'s1' does not have a 
mappable type in 'map' clause" } */
+;
+  #pragma omp target map(alloc: s2) /* { dg-error "'s2' does 

Re: [PATCH, x86] X86 Silvermont vector cost model tune

[H.J. Lu]

On Wed, Mar 5, 2014 at 7:58 AM, Evgeny Stupachenko  wrote:
> Hi,
>
> The patch is for x86 Silvermont.
> It improves x86 Silvermont vector cost model.
> It gives +20% on facerec spec on Silvermont.
> It passes make check and bootstrap on x86.
>
> Is this patch ok for stage1?
>
> ChangeLog:
>
> 2014-03-05  Evgeny Stupachenko  
>
> * config/i386/x86-tune.def (TARGET_SLOW_PSHUFB): Target for slow byte
> shuffle on some x86 architectures.
> * config/i386/i386.h (TARGET_SLOW_PSHUFB): Ditto.
> * config/i386/i386.c (processor_costs): Fixing vec_to_scalar_cost for
> Silvermont according latency table.
> (expand_vec_perm_even_odd_1): Avoid byte shuffles in architectures
> where they are slow (TARGET_SLOW_PSHUFB).
> (x86_add_stmt_cost): Fixing vector cost model for Silvermont.
>
> Thanks,
> Evgeny

There are 3 separate changes in this patch:

1. Update slm_cost, which doesn't have a ChangeLog entry.
2. Add TARGET_SLOW_PSHUFB.
3. Update ix86_add_stmt_cost.

I suggest you break it into 3 independent patches.

Thanks.

-- 
H.J.

Re: How my codes comply with gcc code formatting?

[Marc Glisse]

On Wed, 5 Mar 2014, David Malcolm wrote:


On Wed, 2014-03-05 at 15:46 +0800, lin zuojian wrote:

On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote:

That is not true.  The indentation style is:
http://www.gnu.org/prep/standards/standards.html#Formatting
...
The above also mentions particular options
for GNU indent which set various rules.


Ah, good to know. So, are contributors expected to run indent on
their changes before sending patches? Or maybe add some checks to
check_GNU_style.sh?

-Y

Yeah.Very good if there is such a script.


FWIW for emacs, there was a config file .dir-locals.el added last
October in r203715 which makes emacs automatically follow the GNU
indentation conventions when within the gcc sources.

It sounds like something similar, for vim, would be useful for you.  I
don't know if such a thing already exists.


Since I don't see a link in this thread yet:
http://gcc.gnu.org/wiki/FormattingCodeForGCC

(you can wrap that in a function and use an autocmd to enable it only for 
some directories for instance)


--
Marc Glisse

Re: How my codes comply with gcc code formatting?

[Markus Trippelsdorf]

On 2014.03.05 at 11:18 -0500, David Malcolm wrote:
> On Wed, 2014-03-05 at 15:46 +0800, lin zuojian wrote:
> > On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote:
> > > >That is not true.  The indentation style is:
> > > >http://www.gnu.org/prep/standards/standards.html#Formatting
> > > >...
> > > >The above also mentions particular options
> > > >for GNU indent which set various rules.
> > > 
> > > Ah, good to know. So, are contributors expected to run indent on
> > > their changes before sending patches? Or maybe add some checks to
> > > check_GNU_style.sh?
> > > 
> > > -Y
> > Yeah.Very good if there is such a script.
> 
> FWIW for emacs, there was a config file .dir-locals.el added last
> October in r203715 which makes emacs automatically follow the GNU
> indentation conventions when within the gcc sources.
> 
> It sounds like something similar, for vim, would be useful for you.  I
> don't know if such a thing already exists.

 clang-format --style="{BasedOnStyle: gnu, UseTab: Always}" file.c
also gives good results...

-- 
Markus

Re: How my codes comply with gcc code formatting?

[David Malcolm]

On Wed, 2014-03-05 at 15:46 +0800, lin zuojian wrote:
> On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote:
> > >That is not true.  The indentation style is:
> > >http://www.gnu.org/prep/standards/standards.html#Formatting
> > >...
> > >The above also mentions particular options
> > >for GNU indent which set various rules.
> > 
> > Ah, good to know. So, are contributors expected to run indent on
> > their changes before sending patches? Or maybe add some checks to
> > check_GNU_style.sh?
> > 
> > -Y
> Yeah.Very good if there is such a script.

FWIW for emacs, there was a config file .dir-locals.el added last
October in r203715 which makes emacs automatically follow the GNU
indentation conventions when within the gcc sources.

It sounds like something similar, for vim, would be useful for you.  I
don't know if such a thing already exists.

Hope this is helpful
Dave

Re: Patch RFC: Use internal qsort function in libbacktrace

[Ian Lance Taylor]

On Wed, Mar 5, 2014 at 1:25 AM, Richard Biener
 wrote:
> On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor  wrote:
>> The GNU glibc qsort function will call malloc in some cases.  That makes
>> it unsuitable for libbacktrace, which is intended to work when called
>> from a signal handler.  This patch changes libbacktrace to use an
>> internal qsort function.
>>
>> I'm posting this for comments in case anybody sees anything wrong with
>> the implementation.  I'll commit it in a day or two if I don't hear
>> anything.
>>
>> Bootstrapped and ran libbacktrace and Go tests on
>> x86_64-unknown-linux-gnu.
>
> Doesn't it make sense to put this into libiberty and call it
> sigsafe_qsort or qsort_sigsafe? (not sure if there is a standard
> suffix/prefix for signal-safe variants of functions like _r is
> for thread-safe variants)

My main hesitation is that libbacktrace and libgo do not currently use
libiberty.  In general our target libraries do not use libiberty, and
using libiberty exposes them to licensing issues since libiberty
contains straight GPL code without the runtime exception.

Ian

[PATCH, x86] X86 Silvermont vector cost model tune

[Evgeny Stupachenko]

Hi,

The patch is for x86 Silvermont.
It improves x86 Silvermont vector cost model.
It gives +20% on facerec spec on Silvermont.
It passes make check and bootstrap on x86.

Is this patch ok for stage1?

ChangeLog:

2014-03-05  Evgeny Stupachenko  

* config/i386/x86-tune.def (TARGET_SLOW_PSHUFB): Target for slow byte
shuffle on some x86 architectures.
* config/i386/i386.h (TARGET_SLOW_PSHUFB): Ditto.
* config/i386/i386.c (processor_costs): Fixing vec_to_scalar_cost for
Silvermont according latency table.
(expand_vec_perm_even_odd_1): Avoid byte shuffles in architectures
where they are slow (TARGET_SLOW_PSHUFB).
(x86_add_stmt_cost): Fixing vector cost model for Silvermont.

Thanks,
Evgeny


vect_slm_tune.patch
Description: Binary data

[build, i386] Disable local dynamic TLS model on Solaris/x86 if as/ld cannot handle it

[Rainer Orth]

When using GNU as with Solaris ld, the TLS local dynamic tests
(gcc.dg/torture/tls/run-ld.c etc.) FAIL to execute before Solaris 11:
the programs crash with an illegal instruction: e.g. in the
gcc.dg/lto/20090210 test, we have

0x8050ce0 : mov%gs:0x0,%eax
0x8050ce6 : call   0x8050ce7 
0x8050ce7 : cld
0x8050ce8 : (bad)  

The reason is that Solaris ld before Solaris 11 requires the use of the
@tlsldmplt relocation documented in the Solaris 10 Linker and Libraries
Guide:

http://docs.oracle.com/cd/E26505_01/html/E26506/chapter8-20.html#gentextid-23600

Unfortunately, gas doesn't support that relocation.  While adding the
gas side was easy, I completely failed for gld and didn't propose the
incomplete patch to binutils since it would (rightly) have been
rejected.

Old versions of ld mishandle the TLS LD code sequence emitted by gcc
when @tlsldmplt isn't available, causing the crashes observed.  So ld
cannot handle what gas emits and gas cannot emit what ld requires.  The
only solution seems to fall back to the GD model in that case, which is
ugly but certainly better than having perfectly valid programs crash.

The following patch does just that.  It carefully restricts its actions
to Solaris.  I'm falling back to using dis when objdump isn't available
to avoid enabling this fallback unnecessarily.

Bootstraps on i386-pc-solaris2.{9,10,11} (as/ld, gas/ld, gas/gld,
as/gld), amd64-pc-solaris2.{10,11} (as/ld, gas/ld),
x86_64-unknown-linux-gnu, and i686-unknown-linux-gnu either completed
successfully or still running.

Ok for mainline if those pass?

Thanks.
Rainer


2014-03-04  Rainer Orth  

* configure.ac (TLS_SECTION_ASM_FLAG): Save as tls_section_flag.
(LIB_TLS_SPEC): Save as ld_tls_libs.
(HAVE_AS_IX86_TLSLDMPLT): Define as 1/0.
(HAVE_AS_IX86_TLSLDM): New test.
* configure, config.in: Regenerate.
* config/i386/i386.c (legitimize_tls_address): Fall back to
TLS_MODEL_GLOBAL_DYNAMIC on 32-bit Solaris/x86 if tool chain
cannot support TLS_MODEL_LOCAL_DYNAMIC.
* config/i386/i386.md (*tls_local_dynamic_base_32_gnu): Use if
instead of #ifdef in HAVE_AS_IX86_TLSLDMPLT test.

# HG changeset patch
# Parent 7e1c533059af7a5120250c5c055ae22288bd828a
Disable local dynamic TLS model on Solaris/x86 if as/ld cannot handle it

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13396,6 +13396,13 @@ legitimize_tls_address (rtx x, enum tls_
   enum machine_mode tp_mode = Pmode;
   int type;
 
+  /* Fall back to global dynamic model if tool chain cannot support local
+ dynamic.  */
+  if (TARGET_SUN_TLS && !TARGET_64BIT
+  && !HAVE_AS_IX86_TLSLDMPLT && !HAVE_AS_IX86_TLSLDM
+  && model == TLS_MODEL_LOCAL_DYNAMIC)
+model = TLS_MODEL_GLOBAL_DYNAMIC;
+
   switch (model)
 {
 case TLS_MODEL_GLOBAL_DYNAMIC:
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -12962,11 +12962,12 @@
   output_asm_insn
 ("lea{l}\t{%&@tlsldm(%1), %0|%0, %&@tlsldm[%1]}", operands);
   if (TARGET_SUN_TLS)
-#ifdef HAVE_AS_IX86_TLSLDMPLT
-return "call\t%&@tlsldmplt";
-#else
-return "call\t%p2@plt";
-#endif
+{
+  if (HAVE_AS_IX86_TLSLDMPLT)
+	return "call\t%&@tlsldmplt";
+  else
+	return "call\t%p2@plt";
+}
   return "call\t%P2";
 }
   [(set_attr "type" "multi")
diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2973,6 +2973,7 @@ foo:	.long	25
 	.section .tdata,"awt",@progbits'
   tls_first_major=0
   tls_first_minor=0
+  tls_section_flag=t
 changequote([,])dnl
   AC_DEFINE(TLS_SECTION_ASM_FLAG, 't',
 [Define to the flag used to mark TLS sections if the default (`T') doesn't work.])
@@ -2982,6 +2983,7 @@ changequote(,)dnl
 	.section ".tdata","awT",@progbits'
   tls_first_major=2
   tls_first_minor=14
+  tls_section_flag=T
   tls_as_opt="--fatal-warnings"
 fi
 conftest_s="$conftest_s
@@ -3012,6 +3014,7 @@ foo:	.long	25
 	movq	$foo@TPOFF, %rax'
 	tls_first_major=2
 	tls_first_minor=14
+	tls_section_flag=T
 	tls_as_opt=--fatal-warnings
 	;;
   ia64-*-*)
@@ -3368,6 +3371,7 @@ case "$target" in
 # (32-bit x86) only lived in libthread, so check for that.  Keep
 # set_have_as_tls if found, disable if not.
 AC_SEARCH_LIBS([$tga_func], [thread],, [set_have_as_tls=no])
+ld_tls_libs="$LIBS"
 # Clear LIBS if we cannot support TLS.
 if test $set_have_as_tls = no; then
   LIBS=
@@ -3924,9 +3928,48 @@ foo:	nop
 	 && $gcc_cv_ld -o conftest conftest.o -G > /dev/null 2>&1; then
 	   gcc_cv_as_ix86_tlsldmplt=yes
 	 fi
-	 rm -f conftest],
-  [AC_DEFINE(HAVE_AS_IX86_TLSLDMPLT, 1,
-[Define if your assembler and linker support @tlsldmplt.])])
+	 rm -f conftest])
+AC_DEFINE_UNQUOTED(HAVE_AS_IX86_TLSLDMPLT,
+  [`if test $gcc_cv_as_ix86_tlsldmplt = yes; then echo 1; 

Re: [PATCH] Add some more headers to PLUGIN_HEADERS (PR plugins/59335)

[Basile Starynkevitch]

On Wed, 2014-03-05 at 15:00 +0100, Jakub Jelinek wrote:
> Hi!
> 
> The PR requests beyond the already commited ones some further headers.
> 
> Tested with make install, ok for trunk?

I am not authorized to approve that, but I hope it will be committed.

Cheers.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [PATCH] Add some more headers to PLUGIN_HEADERS (PR plugins/59335)

[Richard Biener]

On Wed, 5 Mar 2014, Jakub Jelinek wrote:

> Hi!
> 
> The PR requests beyond the already commited ones some further headers.
> 
> Tested with make install, ok for trunk?

Ok.

Thanks,
Richard.

> 2014-03-05  Jakub Jelinek  
> 
>   PR plugins/59335
>   * Makefile.in (PLUGIN_HEADERS): Add tree-phinodes.h, stor-layout.h,
>   ssa-iterators.h, $(RESOURCE_H) and tree-cfgcleanup.h.
> 
> --- gcc/Makefile.in.jj2014-02-06 11:54:55.0 +0100
> +++ gcc/Makefile.in   2014-03-05 11:05:27.033215552 +0100
> @@ -3124,7 +3124,8 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
>$(IPA_PROP_H) $(TARGET_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) \
>version.h stringpool.h gimplify.h gimple-iterator.h gimple-ssa.h \
>fold-const.h tree-cfg.h tree-into-ssa.h tree-ssanames.h print-tree.h \
> -  varasm.h context.h
> +  varasm.h context.h tree-phinodes.h stor-layout.h ssa-iterators.h \
> +  $(RESOURCE_H) tree-cfgcleanup.h
>  
>  # generate the 'build fragment' b-header-vars
>  s-header-vars: Makefile
> 
>   Jakub

[PATCH] Add some more headers to PLUGIN_HEADERS (PR plugins/59335)

[Jakub Jelinek]

Hi!

The PR requests beyond the already commited ones some further headers.

Tested with make install, ok for trunk?

2014-03-05  Jakub Jelinek  

PR plugins/59335
* Makefile.in (PLUGIN_HEADERS): Add tree-phinodes.h, stor-layout.h,
ssa-iterators.h, $(RESOURCE_H) and tree-cfgcleanup.h.

--- gcc/Makefile.in.jj  2014-02-06 11:54:55.0 +0100
+++ gcc/Makefile.in 2014-03-05 11:05:27.033215552 +0100
@@ -3124,7 +3124,8 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
   $(IPA_PROP_H) $(TARGET_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) \
   version.h stringpool.h gimplify.h gimple-iterator.h gimple-ssa.h \
   fold-const.h tree-cfg.h tree-into-ssa.h tree-ssanames.h print-tree.h \
-  varasm.h context.h
+  varasm.h context.h tree-phinodes.h stor-layout.h ssa-iterators.h \
+  $(RESOURCE_H) tree-cfgcleanup.h
 
 # generate the 'build fragment' b-header-vars
 s-header-vars: Makefile

Jakub

Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

[Janus Weil]

Hi Mikael,

>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
> I'm asking for one more minor change, namely:
>
>> @@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
>> return false;
>>   }
>>
>> +  /* Add the hidden deferred length field.  */
>> +  if (c->ts.type == BT_CHARACTER && c->ts.deferred && !c->attr.function
>> +   && !sym->attr.is_class)
>> + {
>> +   char name[GFC_MAX_SYMBOL_LEN+1];
>> +   gfc_component *strlen;
>> +   sprintf (name, "_%s", c->name);
>
> It's not more costly to have a more explicit name like "_%s_length" or
> something, and I prefer having the latter in complicated dumps or in the
> debugger.

I agree.


> OK with that change, with the associated buffer size update.  Also Steve
> noted that the buffer size should take the terminating null character
> into account.

Steve's comment somehow got lost in the noise. I have updated both the
name and the buffer size now in resolve_fl_derived0 as well as
gfc_deferred_strlen. Updated patch attached.

A few people expressed mixed feelings, therefore I'll wait a couple of
days to allow the naysayers to chime in. In the absence of further
feedback, I'll commit the patch on the weekend.

Cheers,
Janus
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h  (revision 208344)
+++ gcc/fortran/gfortran.h  (working copy)
@@ -811,6 +811,9 @@ typedef struct
   /* Attributes set by compiler extensions (!GCC$ ATTRIBUTES).  */
   unsigned ext_attr:EXT_ATTR_NUM;
 
+  /* Is a parameter associated with a deferred type component.  */
+  unsigned deferred_parameter:1;
+
   /* The namespace where the attribute has been set.  */
   struct gfc_namespace *volatile_ns, *asynchronous_ns;
 }
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 208344)
+++ gcc/fortran/primary.c   (working copy)
@@ -2355,7 +2355,7 @@ build_actual_constructor (gfc_structure_ctor_compo
}
 
   /* If it was not found, try the default initializer if there's any;
-otherwise, it's an error.  */
+otherwise, it's an error unless this is a deferred parameter.  */
   if (!comp_iter)
{
  if (comp->initializer)
@@ -2365,7 +2365,7 @@ build_actual_constructor (gfc_structure_ctor_compo
return false;
  value = gfc_copy_expr (comp->initializer);
}
- else
+ else if (!comp->attr.deferred_parameter)
{
  gfc_error ("No initializer for component '%s' given in the"
 " structure constructor at %C!", comp->name);
@@ -2447,7 +2447,7 @@ gfc_convert_to_structure_constructor (gfc_expr *e,
{
  /* Components without name are not allowed after the first named
 component initializer!  */
- if (!comp)
+ if (!comp || comp->attr.deferred_parameter)
{
  if (last_name)
gfc_error ("Component initializer without name after component"
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 208344)
+++ gcc/fortran/resolve.c   (working copy)
@@ -12105,14 +12105,6 @@ resolve_fl_derived0 (gfc_symbol *sym)
   if (c->attr.artificial)
continue;
 
-  /* See PRs 51550, 47545, 48654, 49050, 51075 - and 45170.  */
-  if (c->ts.type == BT_CHARACTER && c->ts.deferred && !c->attr.function)
-   {
- gfc_error ("Deferred-length character component '%s' at %L is not "
-"yet supported", c->name, &c->loc);
- return false;
-   }
-
   /* F2008, C442.  */
   if ((!sym->attr.is_class || c != sym->components)
  && c->attr.codimension
@@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
  return false;
}
 
+  /* Add the hidden deferred length field.  */
+  if (c->ts.type == BT_CHARACTER && c->ts.deferred && !c->attr.function
+ && !sym->attr.is_class)
+   {
+ char name[GFC_MAX_SYMBOL_LEN+9];
+ gfc_component *strlen;
+ sprintf (name, "_%s_length", c->name);
+ strlen = gfc_find_component (sym, name, true, true);
+ if (strlen == NULL)
+   {
+ if (!gfc_add_component (sym, name, &strlen))
+   return false;
+ strlen->ts.type = BT_INTEGER;
+ strlen->ts.kind = gfc_charlen_int_kind;
+ strlen->attr.access = ACCESS_PRIVATE;
+ strlen->attr.deferred_parameter = 1;
+   }
+   }
+
   if (c->ts.type == BT_DERIVED
  && sym->component_access != ACCESS_PRIVATE
  && gfc_check_symbol_access (sym)
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c   (revision 20834

Re: copyright dates in binutils (and includes/)

[Alan Modra]

On Mon, Mar 03, 2014 at 01:33:18PM +, Richard Sandiford wrote:
> Alan Modra  writes:
> > On Mon, Mar 03, 2014 at 02:14:51PM +1030, Alan Modra wrote:
> >> I'll post update-copyright.py separately.
> 
> Thanks for doing this, looks good to me FWIW.  I don't know whether
> we want to keep a single script for both GCC and binutils+gdb or fork,
> but probably separate copies makes sense.

I guess we have 8 months to decide what to do with my hacks. :-)  If
you choose to merge my changes that's fine by me too.

> As far as including include/ goes: the only reason that didn't happen
> for gcc/ was because I didn't want to sort out which files were GCC-
> specific and whether binutils, GCC or GDB was the master for each file.
> So if we do your option (b) I think we should do (c) as well.  I suppose
> that means syncing GCC's include/ with binutils+gdb and then adding
> GCC's include/ to the list of "approved" directories.  I'm happy to try
> that if it sounds OK.  (Maybe after the 4.9 release, not sure.)

I'm happy with (c, but for now have committed just the other changes.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc

[Paulo Matos]

On 05/03/2014 11:51, Richard Biener wrote:
On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres 
 wrote:


Revision 208312 causes

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


Uhm.  pointer comparison against double_type_node ...

I'd say we want to revert the patch.  Paulo, please do that.  Let's
do the alternate approach of marking -fshort-double eligible for LTO
as well and handle it there properly.



Sure, I will prepare a new patch and post it for approval by the end of 
the day.


Apologies for the regression.
--
Paulo Matos

Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc

[Richard Biener]

On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres  wrote:
>
> Revision 208312 causes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427

Uhm.  pointer comparison against double_type_node ...

I'd say we want to revert the patch.  Paulo, please do that.  Let's
do the alternate approach of marking -fshort-double eligible for LTO
as well and handle it there properly.

Thanks,
Richard.

> Also compiling the test gcc.dg/lto/pr55113 with -m32 gives an ICE
>
> FAIL: gcc.dg/lto/pr55113 c_lto_pr55113_0.o assemble,  -flto -fshort-double 
> -O0  (internal compiler error)
>
> internal compiler error: in layout_type, at stor-layout.c:2116
>
> TIA
>
> Dominique

Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc

[Dominique Dhumieres]

Revision 208312 causes

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

Also compiling the test gcc.dg/lto/pr55113 with -m32 gives an ICE

FAIL: gcc.dg/lto/pr55113 c_lto_pr55113_0.o assemble,  -flto -fshort-double -O0  
(internal compiler error)

internal compiler error: in layout_type, at stor-layout.c:2116

TIA

Dominique

Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

[Mikael Morin]

Le 01/03/2014 16:58, Janus Weil a écrit :
>>> Index: gcc/fortran/trans-stmt.c
>>> ===
>>> --- gcc/fortran/trans-stmt.c  (revision 207896)
>>> +++ gcc/fortran/trans-stmt.c  (working copy)
>>> @@ -5028,6 +5028,11 @@ gfc_trans_allocate (gfc_code * code)
>>> if (tmp && TREE_CODE (tmp) == VAR_DECL)
>>>   gfc_add_modify (&se.pre, tmp, fold_convert (TREE_TYPE (tmp),
>>>   memsz));
>>> +   else if (al->expr->ts.type == BT_CHARACTER
>>> +&& al->expr->ts.deferred && se.string_length)
>>> + gfc_add_modify (&se.pre, se.string_length,
>>> + fold_convert (TREE_TYPE (se.string_length),
>>> + memsz));
>>>
>> and here.  There may be other places that I have missed.
> 
> Actually I don't see a problem here. Also no further modifications
> were necessary to get a KIND=4 example to work.
> 
Mmmh, yes indeed.  I assumed memsz was the memory size, which it isn't
until a few lines down.  Thanks for checking.

> 
>>> /* Convert to size in bytes, using the character KIND.  */
>>> if (unlimited_char)
>>
>> As the patch seems to provide a wanted feature, and as the new code
>> seems to be properly guarded, I'm not against it after the above has
>> been checked and fixed if necessary.
> 
> Attached is a new version of the patch which fixes the above-mentioned
> problems and should make the non-default-kind cases work. I have added
> a KIND=4 version of the original test case, which seems to work
> properly.
> 
> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
> 
I'm asking for one more minor change, namely:

> @@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
> return false;
>   }
>  
> +  /* Add the hidden deferred length field.  */
> +  if (c->ts.type == BT_CHARACTER && c->ts.deferred && !c->attr.function
> +   && !sym->attr.is_class)
> + {
> +   char name[GFC_MAX_SYMBOL_LEN+1];
> +   gfc_component *strlen;
> +   sprintf (name, "_%s", c->name);

It's not more costly to have a more explicit name like "_%s_length" or
something, and I prefer having the latter in complicated dumps or in the
debugger.
OK with that change, with the associated buffer size update.  Also Steve
noted that the buffer size should take the terminating null character
into account.

Thanks for the patch.
Mikael

Re: [PATCH][AArch64] Fix default CPU configurations

[Kyrill Tkachov]

Ping?

On 25/02/14 10:08, Kyrill Tkachov wrote:

Hi all,

The problem solved in this patch is that when gcc is configured with
--with-arch=armv8-a gcc will go into  aarch64-arches.def, pick the
representative CPU (Cortex-A53 for ARMv8-A) and use that CPUs ISA flags. Now
that we specified that Cortex-A53 has CRC and crypto though, this means that gcc
will choose by default to enable CRC and Crypto.

What it should be doing though is to use the 4th field in the AARCH64_ARCH macro
that specifies the ISA flags implied by the architecture. This patch does that
by looking in aarch64-arches.def and extracting the 4th field appropriately and
using that as the ext_mask when processing a --with-arch option.

Furthermore, if no --with-arch or --with-cpu directives are specified config.gcc
will set TARGET_DEFAULT_CPU to TARGET_CPU_generic. What it should be doing, is
leaving it undefined so that the backend in aarch64.h can define its own default
with the correct ISA options (currently we have this scheme where the
TARGET_CPU_ is encoded in the first 6 bits of TARGET_DEFAULT_CPU and the
ISA flags are encoded in the upper part of it. We should clean that up in the
next release). Before this patch, the code in aarch64.h that does that
initialisation was never even exercised because TARGET_CPU_DEFAULT was always
defined by config.gcc no matter what! config.gcc defined it as
TARGET_CPU_generic but without encoding the appropriate ISA flags in the upper
bits, leading to a cpu configured without fp or simd.

After a discussion with Richard, this patch sets the default CPU (if no
-mcpu,-march,--with-cpu,--with-arch is given) to be generic+fp+simd. The generic
CPU already schedules like the Cortex-A53, so it should give a decent generic
tuning.

This patch should improve the current situation a bit.
With this patch:
- If --with-arch=armv8-a is specified we will use generic+fp+simd as the CPU
(without the patch it's cortex-a53+fp+simd+crc+crypto)
- If no arch or cpu options specified anywhere, we will use the generic+fp+simd
CPU (without the patch it would be just generic)

Tested aarch64-none-elf on a model and checked the .cpu directive in the
generated assembly for a variety of --with-cpu, --with-arch combinations.

I'm proposing this patch as an alternative to
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01072.html.

Ok for trunk?

Thanks,
Kyrill

2014-02-25  Kyrylo Tkachov  

  * config.gcc (aarch64*-*-*): Use ISA flags from aarch64-arches.def.
  Do not define target_cpu_default2 to generic.
  * config/aarch64/aarch64.h (TARGET_CPU_DEFAULT): Use generic cpu.
  * config/aarch64/aarch64.c (aarch64_override_options): Update comment.
  * config/aarch64/aarch64-arches.def (armv8-a): Use generic cpu.

Re: Patch RFC: Use internal qsort function in libbacktrace

[Steven Bosscher]

On Wed, Mar 5, 2014 at 10:25 AM, Richard Biener wrote:
> On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor wrote:
>> The GNU glibc qsort function will call malloc in some cases.  That makes
>> it unsuitable for libbacktrace, which is intended to work when called
>> from a signal handler.  This patch changes libbacktrace to use an
>> internal qsort function.
>>
>> I'm posting this for comments in case anybody sees anything wrong with
>> the implementation.  I'll commit it in a day or two if I don't hear
>> anything.
>>
>> Bootstrapped and ran libbacktrace and Go tests on
>> x86_64-unknown-linux-gnu.
>
> Doesn't it make sense to put this into libiberty and call it
> sigsafe_qsort or qsort_sigsafe? (not sure if there is a standard
> suffix/prefix for signal-safe variants of functions like _r is
> for thread-safe variants)

Or use mergesort from libunwind.

Ciao!
Steven

RE: Changing the MIPS ISA for the Loongson 3A from MIPS64 to MIPS64r2

[Andrew Bennett]

> Richard Sandiford  writes:
>> Andrew Bennett  writes:
>>> Hi,
>>>
>>> I have noticed that a patch was placed in bugzilla to do this change, but 
>>> it 
>>> does not appear to have been pushed.  I was wondering if anyone could 
>>> comment
>>> why this is the case?
>>>
>>> The bugzilla URL is the following:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754
>>
>> Looks OK if it passes testing.  We'll need a name and email address for
>> the commit though.
>
> Following the discussion on binutils@ I committed the patch as follows.
> I slightly tweaked it so that the MIPS64r2 processors stayed in
> alphabetical order (which also means that mips-tables.opt doesn't
> need to be regenerated).
> 
> Sorry again for the delay.

Thats fine.  Many thanks for sorting this out so promptly.

Regards,


Andrew

Re: [PATCH] Install config/i386/stringop.def as a plugin header

[Uros Bizjak]

On Wed, Mar 5, 2014 at 10:20 AM, Jakub Jelinek  wrote:

>> > Pretty much all plugins fail to compile against installed plugin headers
>> > on i?86, because stringop.def isn't installed.
>> >
>> > This patch should fix that, ok if testing succeeds?
>> >
>> > 2014-03-05  Jakub Jelinek  
>> >
>> > * config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def.
>>
>> This is actually PR59335 [1], and as shown there, a couple of other
>> headers are missing as well.
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
>
> Ah, I see, not sure we have to handle everything at once though, it can be
> fixed incrementally.
> Anyway, as for OPTIONS_H_EXTRA vs. PLUGIN_HEADERS, I think the former is
> more correct, stringop.def is included by i386-opts.h.
> And x86-tune.def, being included directly by i386.h, should be added to
> TM_H.
> So is this ok instead?
>
> Note, only tested with make install and checking that the *.def file is
> installed.
>
> 2014-03-05  Jakub Jelinek  
>
> PR plugins/59335
> * config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def.

OK with updated ChangeLog.

Thanks,
Uros.

Re: Patch RFC: Use internal qsort function in libbacktrace

[Richard Biener]

On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor  wrote:
> The GNU glibc qsort function will call malloc in some cases.  That makes
> it unsuitable for libbacktrace, which is intended to work when called
> from a signal handler.  This patch changes libbacktrace to use an
> internal qsort function.
>
> I'm posting this for comments in case anybody sees anything wrong with
> the implementation.  I'll commit it in a day or two if I don't hear
> anything.
>
> Bootstrapped and ran libbacktrace and Go tests on
> x86_64-unknown-linux-gnu.

Doesn't it make sense to put this into libiberty and call it
sigsafe_qsort or qsort_sigsafe? (not sure if there is a standard
suffix/prefix for signal-safe variants of functions like _r is
for thread-safe variants)

Thanks,
Richard.

> Ian
>
>
> 2014-03-04  Ian Lance Taylor  
>
> * sort.c: New file.
> * stest.c: New file.
> * internal.h (backtrace_qsort): Declare.
> * dwarf.c (read_abbrevs): Call backtrace_qsort instead of qsort.
> (read_line_info, read_function_entry): Likewise.
> (read_function_info, build_dwarf_data): Likewise.
> * elf.c (elf_initialize_syminfo): Likewise.
> * Makefile.am (libbacktrace_la_SOURCES): Add sort.c.
> (stest_SOURCES, stest_LDADD): Define.
> (check_PROGRAMS): Add stest.
>
>

Re: [PATCH] Install config/i386/stringop.def as a plugin header

[Jakub Jelinek]

On Wed, Mar 05, 2014 at 10:10:13AM +0100, Uros Bizjak wrote:
> On Wed, Mar 5, 2014 at 9:48 AM, Jakub Jelinek  wrote:
> > Hi!
> >
> > Pretty much all plugins fail to compile against installed plugin headers
> > on i?86, because stringop.def isn't installed.
> >
> > This patch should fix that, ok if testing succeeds?
> >
> > 2014-03-05  Jakub Jelinek  
> >
> > * config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def.
> 
> This is actually PR59335 [1], and as shown there, a couple of other
> headers are missing as well.
> 
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335

Ah, I see, not sure we have to handle everything at once though, it can be
fixed incrementally.
Anyway, as for OPTIONS_H_EXTRA vs. PLUGIN_HEADERS, I think the former is
more correct, stringop.def is included by i386-opts.h.
And x86-tune.def, being included directly by i386.h, should be added to
TM_H.
So is this ok instead?

Note, only tested with make install and checking that the *.def file is
installed.

2014-03-05  Jakub Jelinek  

PR plugins/59335
* config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def.

--- gcc/config/i386/t-i386.jj   2014-01-03 11:41:06.0 +0100
+++ gcc/config/i386/t-i386  2014-03-05 09:40:22.433466727 +0100
@@ -16,11 +16,13 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
+OPTIONS_H_EXTRA += $(srcdir)/config/i386/stringop.def
+TM_H += $(srcdir)/config/i386/x86-tune.def
+
 i386-c.o: $(srcdir)/config/i386/i386-c.c i386-builtin-types.inc
  $(COMPILE) $<
  $(POSTCOMPILE)
 
-
 i386-builtin-types.inc: s-i386-bt ; @true
 s-i386-bt: $(srcdir)/config/i386/i386-builtin-types.awk \
   $(srcdir)/config/i386/i386-builtin-types.def


Jakub

[PATCH] Fix ARM TLS handling (PR target/58595)

[Jakub Jelinek]

Hi!

arm_legitimize_address may be called with a TLS symbol referenced, even when
x is not itself a SYMBOL_REF.  Most often it is something like:
(const:SI (plus:SI (symbol_ref:SI "tlsvar") (const_int NNN)))
but generally it can be something else (e.g. from expansion of
TARGET_MEM_REF).  Unfortunately this function legitimizes only the
SYMBOL_REF TLS case as TLS load, but the more complex forms with e.g. -fpic
can e.g. fall thru into legitimize_pic_address -> gen_calculate_pic_address,
which means either wrong-code or ICE later on.
Fixed by legitimizing both the SYMBOL_REF and
CONST+PLUS+SYMBOL_REF+CONST_INT case, and for more complex TLS containing
expressions just returning x (in that case the caller will split the PLUS
on its own).

Kyrill has kindly bootstrapped/regtested this on Chromebook, ok for
trunk/4.8?

2014-03-05  Jakub Jelinek  
Meador Inge  

PR target/58595
* config/arm/arm.c (arm_tls_symbol_p): Remove.
(arm_legitimize_address): Call legitimize_tls_address for any
arm_tls_referenced_p expression, handle constant addend.  Call it
before testing for !TARGET_ARM.
(thumb_legitimize_address): Don't handle arm_tls_symbol_p here.

* gcc.dg/tls/pr58595.c: New test.

--- gcc/config/arm/arm.c.jj 2014-03-04 08:51:39.620081210 +0100
+++ gcc/config/arm/arm.c2014-03-04 14:06:26.776277688 +0100
@@ -235,7 +235,6 @@ static tree arm_gimplify_va_arg_expr (tr
 static void arm_option_override (void);
 static unsigned HOST_WIDE_INT arm_shift_truncation_mask (enum machine_mode);
 static bool arm_cannot_copy_insn_p (rtx);
-static bool arm_tls_symbol_p (rtx x);
 static int arm_issue_rate (void);
 static void arm_output_dwarf_dtprel (FILE *, int, rtx) ATTRIBUTE_UNUSED;
 static bool arm_output_addr_const_extra (FILE *, rtx);
@@ -7336,6 +7335,32 @@ legitimize_tls_address (rtx x, rtx reg)
 rtx
 arm_legitimize_address (rtx x, rtx orig_x, enum machine_mode mode)
 {
+  if (arm_tls_referenced_p (x))
+{
+  rtx addend = NULL;
+
+  if (GET_CODE (x) == CONST && GET_CODE (XEXP (x, 0)) == PLUS)
+   {
+ addend = XEXP (XEXP (x, 0), 1);
+ x = XEXP (XEXP (x, 0), 0);
+   }
+
+  if (GET_CODE (x) != SYMBOL_REF)
+   return x;
+
+  gcc_assert (SYMBOL_REF_TLS_MODEL (x) != 0);
+
+  x = legitimize_tls_address (x, NULL_RTX);
+
+  if (addend)
+   {
+ x = gen_rtx_PLUS (SImode, x, addend);
+ orig_x = x;
+   }
+  else
+   return x;
+}
+
   if (!TARGET_ARM)
 {
   /* TODO: legitimize_address for Thumb2.  */
@@ -7344,9 +7369,6 @@ arm_legitimize_address (rtx x, rtx orig_
   return thumb_legitimize_address (x, orig_x, mode);
 }
 
-  if (arm_tls_symbol_p (x))
-return legitimize_tls_address (x, NULL_RTX);
-
   if (GET_CODE (x) == PLUS)
 {
   rtx xop0 = XEXP (x, 0);
@@ -7459,9 +7481,6 @@ arm_legitimize_address (rtx x, rtx orig_
 rtx
 thumb_legitimize_address (rtx x, rtx orig_x, enum machine_mode mode)
 {
-  if (arm_tls_symbol_p (x))
-return legitimize_tls_address (x, NULL_RTX);
-
   if (GET_CODE (x) == PLUS
   && CONST_INT_P (XEXP (x, 1))
   && (INTVAL (XEXP (x, 1)) >= 32 * GET_MODE_SIZE (mode)
@@ -7756,20 +7775,6 @@ thumb_legitimize_reload_address (rtx *x_
 
 /* Test for various thread-local symbols.  */
 
-/* Return TRUE if X is a thread-local symbol.  */
-
-static bool
-arm_tls_symbol_p (rtx x)
-{
-  if (! TARGET_HAVE_TLS)
-return false;
-
-  if (GET_CODE (x) != SYMBOL_REF)
-return false;
-
-  return SYMBOL_REF_TLS_MODEL (x) != 0;
-}
-
 /* Helper for arm_tls_referenced_p.  */
 
 static int
--- gcc/testsuite/gcc.dg/tls/pr58595.c.jj   2014-03-04 12:56:48.337915114 
+0100
+++ gcc/testsuite/gcc.dg/tls/pr58595.c  2014-03-04 12:56:48.337915114 +0100
@@ -0,0 +1,28 @@
+/* PR target/58595 */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+/* { dg-additional-options "-fpic" { target fpic } } */
+/* { dg-require-effective-target tls } */
+/* { dg-require-effective-target sync_int_long } */
+
+struct S { unsigned long a, b; };
+__thread struct S s;
+void bar (unsigned long *);
+
+__attribute__((noinline)) void
+foo (void)
+{
+  int i;
+  for (i = 0; i < 10; i++)
+__sync_fetch_and_add (&s.b, 1L);
+}
+
+int
+main ()
+{
+  s.b = 12;
+  foo ();
+  if (s.b != 22)
+__builtin_abort ();
+  return 0;
+}

Jakub

Re: [PATCH] Install config/i386/stringop.def as a plugin header

[Uros Bizjak]

On Wed, Mar 5, 2014 at 9:48 AM, Jakub Jelinek  wrote:
> Hi!
>
> Pretty much all plugins fail to compile against installed plugin headers
> on i?86, because stringop.def isn't installed.
>
> This patch should fix that, ok if testing succeeds?
>
> 2014-03-05  Jakub Jelinek  
>
> * config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def.

This is actually PR59335 [1], and as shown there, a couple of other
headers are missing as well.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335

Uros.

Re: [PATCH] Use the LTO linker plugin by default

[Richard Biener]

On Tue, 4 Mar 2014, Jan Hubicka wrote:

> > 
> > The following patch addresses the common (?) issue of people
> > omitting -flto from the linker command-line which gets more
> > severe with GCC 4.9 where slim LTO objects are emitted by
> > default.  The patch simply _always_ arranges for the linker
> > plugin to be used, so if there are any (slim) LTO objects
> > on the link LTO will be done on them.  Similarly the
> > non-linker-plugin path in collect2 is adjusted.
> > 
> > You can still disable this by specifying -fno-lto on the 
> > linker command-line.
> > 
> > One side-effect of enabling the linker-plugin by default
> > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then
> > use the configured plugin ld rather than the default ld.
> > Not sure if that is desired.
> > 
> > Comments?
> 
> I like it; it was on my TODO list, but I was only worried about
> --with-plugin-ld and did not find time, yet, to look into the consequences.
> These days, I do not think we need to worry much aboud --with-plugin-ld.

Yeah, I think we should eventually remove that capability.

Now as of the two patches (compute a default link-time optimization
level and this patch, make considering LTO at link-time the default),
they only make sense together (at least the default opt level at
link-time doesn't improve real-world situations without also considering
all links to be possibly -flto).

So the question remains if we want to have both patches at this
stage or if we want to wait with them for 4.10 (we do have the
user-visible change of slim-lto objects by default with 4.9
already).

Thanks,
Richard.

> Honza
> > 
> > Thanks,
> > Richard.
> > 
> > 2014-03-04  Richard Biener  
> > 
> > * gcc.c (PLUGIN_COND): Always enable unless -fno-use-linker-plugin
> > or -fno-lto is specified and the linker has full plugin support.
> > * collect2.c (lto_mode): Default to LTO_MODE_WHOPR if LTO is
> > enabled.
> > (main): Remove -flto processing, adjust lto_mode using
> > use_plugin late.
> > 
> > Index: gcc/gcc.c
> > ===
> > --- gcc/gcc.c   (revision 208310)
> > +++ gcc/gcc.c   (working copy)
> > @@ -695,7 +695,7 @@ proper position among the other output f
> >  #if HAVE_LTO_PLUGIN > 0
> >  /* The linker used has full plugin support, use LTO plugin by default.  */
> >  #if HAVE_LTO_PLUGIN == 2
> > -#define PLUGIN_COND 
> > "!fno-use-linker-plugin:%{flto|flto=*|fuse-linker-plugin"
> > +#define PLUGIN_COND "!fno-use-linker-plugin:%{!fno-lto"
> >  #define PLUGIN_COND_CLOSE "}"
> >  #else
> >  /* The linker used has limited plugin support, use LTO plugin with explicit
> > Index: gcc/collect2.c
> > ===
> > --- gcc/collect2.c  (revision 208310)
> > +++ gcc/collect2.c  (working copy)
> > @@ -192,7 +192,11 @@ enum lto_mode_d {
> >  };
> >  
> >  /* Current LTO mode.  */
> > +#ifdef ENABLE_LTO
> > +static enum lto_mode_d lto_mode = LTO_MODE_WHOPR;
> > +#else
> >  static enum lto_mode_d lto_mode = LTO_MODE_NONE;
> > +#endif
> >  
> >  bool debug;/* true if -debug */
> >  bool helpflag; /* true if --help */
> > @@ -1018,15 +1022,11 @@ main (int argc, char **argv)
> >   debug = true;
> >  else if (! strcmp (argv[i], "-flto-partition=none"))
> >   no_partition = true;
> > -else if ((! strncmp (argv[i], "-flto=", 6)
> > - || ! strcmp (argv[i], "-flto")) && ! use_plugin)
> > - lto_mode = LTO_MODE_WHOPR;
> > else if (!strncmp (argv[i], "-fno-lto", 8))
> >   lto_mode = LTO_MODE_NONE;
> >  else if (! strcmp (argv[i], "-plugin"))
> >   {
> > use_plugin = true;
> > -   lto_mode = LTO_MODE_NONE;
> > if (selected_linker == USE_DEFAULT_LD)
> >   selected_linker = USE_PLUGIN_LD;
> >   }
> > @@ -1056,6 +1056,8 @@ main (int argc, char **argv)
> >}
> >  vflag = debug;
> >  find_file_set_debug (debug);
> > +if (use_plugin)
> > +  lto_mode = LTO_MODE_NONE;
> >  if (no_partition && lto_mode == LTO_MODE_WHOPR)
> >lto_mode = LTO_MODE_LTO;
> >}
> 
> 

-- 
Richard Biener 
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer

[PATCH] Install config/i386/stringop.def as a plugin header

[Jakub Jelinek]

Hi!

Pretty much all plugins fail to compile against installed plugin headers
on i?86, because stringop.def isn't installed.

This patch should fix that, ok if testing succeeds?

2014-03-05  Jakub Jelinek  

* config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def.

--- gcc/config/i386/t-i386.jj   2014-01-03 11:41:06.0 +0100
+++ gcc/config/i386/t-i386  2014-03-05 09:40:22.433466727 +0100
@@ -16,11 +16,12 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
+OPTIONS_H_EXTRA += $(srcdir)/config/i386/stringop.def
+
 i386-c.o: $(srcdir)/config/i386/i386-c.c i386-builtin-types.inc
  $(COMPILE) $<
  $(POSTCOMPILE)
 
-
 i386-builtin-types.inc: s-i386-bt ; @true
 s-i386-bt: $(srcdir)/config/i386/i386-builtin-types.awk \
   $(srcdir)/config/i386/i386-builtin-types.def

Jakub

Re: [PATCH] Fix up -O1 -> -O0 -flto expansion (PR lto/60404)

[Richard Biener]

On Tue, 4 Mar 2014, Jakub Jelinek wrote:

> Hi!
> 
> As discussed in the PR, the assumption that in !optimize functions
> all SSA_NAMEs for a particular PARM_DECL or RESULT_DECL can be coalesced
> together is wrong for -flto, if you compile with optimizations the object
> file and then link with -O0 -flto, because the SSA_NAMEs can already
> overlap.
> 
> As we don't have info right now if a particular function has always been
> compiled with !optimize during the LTO pipeline, this patch fixes the
> wrong-code by always assuming it might be optimized at some point if
> in_lto_p.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard.

> 2014-03-04  Jakub Jelinek  
> 
>   PR lto/60404
>   * cfgexpand.c (expand_used_vars): Do not assume all SSA_NAMEs
>   of PARM/RESULT_DECLs must be coalesced with optimize && in_lto_p.
>   * tree-ssa-coalesce.c (coalesce_ssa_name): Use MUST_COALESCE_COST - 1
>   cost for in_lto_p.
> 
>   * gcc.dg/lto/pr60404_0.c: New test.
>   * gcc.dg/lto/pr60404_1.c: New file.
>   * gcc.dg/lto/pr60404_2.c: New file.
> 
> --- gcc/cfgexpand.c.jj2014-03-04 10:57:18.0 +0100
> +++ gcc/cfgexpand.c   2014-03-04 11:12:12.684524383 +0100
> @@ -1652,10 +1652,12 @@ expand_used_vars (void)
>debug info, there is no need to do so if optimization is disabled
>because all the SSA_NAMEs based on these DECLs have been coalesced
>into a single partition, which is thus assigned the canonical RTL
> -  location of the DECLs.  */
> +  location of the DECLs.  If in_lto_p, we can't rely on optimize,
> +  a function could be compiled with -O1 -flto first and only the
> +  link performed at -O0.  */
>if (TREE_CODE (SSA_NAME_VAR (var)) == VAR_DECL)
>   expand_one_var (var, true, true);
> -  else if (DECL_IGNORED_P (SSA_NAME_VAR (var)) || optimize)
> +  else if (DECL_IGNORED_P (SSA_NAME_VAR (var)) || optimize || in_lto_p)
>   {
> /* This is a PARM_DECL or RESULT_DECL.  For those partitions that
>contain the default def (representing the parm or result itself)
> --- gcc/tree-ssa-coalesce.c.jj2014-01-03 11:40:57.0 +0100
> +++ gcc/tree-ssa-coalesce.c   2014-03-04 11:15:46.955296026 +0100
> @@ -1289,9 +1289,12 @@ coalesce_ssa_name (void)
>_require_ that all the names originating from it be
>coalesced, because there must be a single partition
>containing all the names so that it can be assigned
> -  the canonical RTL location of the DECL safely.  */
> +  the canonical RTL location of the DECL safely.
> +  If in_lto_p, a function could have been compiled
> +  originally with optimizations and only the link
> +  performed at -O0, so we can't actually require it.  */
> const int cost
> - = TREE_CODE (SSA_NAME_VAR (a)) == VAR_DECL
> + = (TREE_CODE (SSA_NAME_VAR (a)) == VAR_DECL || in_lto_p)
> ? MUST_COALESCE_COST - 1 : MUST_COALESCE_COST;
> add_coalesce (cl, SSA_NAME_VERSION (a),
>   SSA_NAME_VERSION (*slot), cost);
> --- gcc/testsuite/gcc.dg/lto/pr60404_0.c.jj   2014-03-04 11:19:48.503909557 
> +0100
> +++ gcc/testsuite/gcc.dg/lto/pr60404_0.c  2014-03-04 11:09:51.590333222 
> +0100
> @@ -0,0 +1,15 @@
> +/* { dg-lto-do run } */
> +/* { dg-lto-options { { -O1 -flto } } } */
> +/* { dg-extra-ld-options { -O0 } } */
> +
> +extern void fn2 (int);
> +int a[1], b;
> +
> +int
> +main ()
> +{
> +  fn2 (0);
> +  if (b != 0 || a[b] != 0)
> +__builtin_abort ();
> +  return 0;
> +}
> --- gcc/testsuite/gcc.dg/lto/pr60404_1.c.jj   2014-03-04 11:19:51.057894910 
> +0100
> +++ gcc/testsuite/gcc.dg/lto/pr60404_1.c  2014-03-04 09:32:35.0 
> +0100
> @@ -0,0 +1,4 @@
> +void
> +fn1 (int p)
> +{
> +}
> --- gcc/testsuite/gcc.dg/lto/pr60404_2.c.jj   2014-03-04 11:19:54.578874717 
> +0100
> +++ gcc/testsuite/gcc.dg/lto/pr60404_2.c  2014-03-04 09:33:18.0 
> +0100
> @@ -0,0 +1,9 @@
> +extern int b;
> +extern void fn1 (int);
> +
> +void
> +fn2 (int p)
> +{
> +  b = p++;
> +  fn1 (p);
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer

Re: [ping] Re: [PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build

[Richard Earnshaw]

On 31/01/14 12:37, Matthias Klose wrote:

ping, adding build maintainers



I was hoping one of the configury maintainers would comment on this.  No 
such luck.


Based on the following in the manual:

"@code{MULTIARCH_DIRNAME} is not used for configurations that support
both multilib and multiarch.  In that case, multiarch names are encoded
in @code{MULTILIB_OSDIRNAMES} instead."

I think this is OK.

Please give the configury maintainers 24 hours to comment before committing.

R.



Am 10.01.2014 12:06, schrieb Matthias Klose:

Am 10.01.2014 10:49, schrieb Zhenqiang Chen:

On 10 January 2014 17:23, Matthias Klose  wrote:

Am 10.01.2014 09:23, schrieb Zhenqiang Chen:

Hi,

MULTIARCH_DIRNAME was removed @r196649 since the dir info had been
combined in MULTILIB_OSDIRNAMES.

But MULTIARCH_DIRNAME was re-added @r201164. With this change, the
final multiarch_dir is combined as
"aarch64-linux-gnu:aarch64-linux-gnu", which is incorrect and leads to
multiarch build fail if the sysroot is in correct multiarch layout.

Any reason to add MULTIARCH_DIRNAME? If it is not necessary, can we
remove it as the patch?


see the thread "[patch] set MULTIARCH_DIRNAME for multilib architectures" from
June 2013.  I think it is necessary to have the default defined.  Yesterday's
build looks ok for me, looking at default and include paths, so maybe I don't
yet understand the issue.


In our build, we configure eglbc with
rtlddir=/lib
libdir=/usr/lib/aarch64-linux-gnu
slibdir=/lib/aarch64-linux-gnu

And we configure gcc with "--disable-multilib --enable-multiarch",
But when building gcc libraries, configure FAIL since it can not find
the C libraries. And I try
./xgcc --print-multiarch
the output is "aarch64-linux-gnu:aarch64-linux-gnu"

Any comments?




Thanks!
-Zhenqiang




I think aarch64 is the only architecture which introduces MULTILIB_* macros
without actually building any multilib, just to set the default library name to
lib64. So maybe this has some side effects.


sorry, I have a local patch applied after the lib64 change, which I forgot to
forward.

* Makefile.in (s-mlib): Only pass MULTIARCH_DIRNAME if
MULTILIB_OSDIRNAMES is not defined.

--- a/src/gcc/Makefile.in
+++ b/src/gcc/Makefile.in
@@ -1837,7 +1837,7 @@
 "$(MULTILIB_EXCLUSIONS)" \
 "$(MULTILIB_OSDIRNAMES)" \
 "$(MULTILIB_REQUIRED)" \
-   "$(MULTIARCH_DIRNAME)" \
+   "$(if $(MULTILIB_OSDIRNAMES),,$(MULTIARCH_DIRNAME))" \
 "$(MULTILIB_REUSE)" \
 "@enable_multilib@" \
 > tmp-mlib.h; \

applied/tested since July 2013 on the Debian/Ubuntu distro builds. It doesn't
affect the non-multiarch case.

Ok for the trunk?

   Matthias