Re: [PATCH, committed] Fix PR 57422

[Andrey Belevantsev]

On 23.12.2013 16:24, H.J. Lu wrote:

On Sun, Dec 22, 2013 at 10:52 PM, Andrey Belevantsev  wrote:

Hello,

As described in the PR, the ICE reason was the typo made when introducing
calls to add_hard_reg_set.  Fixed by the first attached patch, bootstrapped
and tested on both ia64 and x86_64, committed as obvious.

The test case is very sensitive to the scheduler decisions (e.g. it didn't
fail on trunk but only on the revision reported for me), so instead of
adding the test I have put in the code two asserts checking that we can
always schedule the fence instruction as is.  This hunk was tested together
with the first but committed separately.



Testcase is very small. Why not add it?


Frankly, I think that the chances of this test uncovering similar issues in 
the future are very small.  It needs lots of options to make it trigger and 
even with this a specific revision.  The chance of triggering the asserts I 
added on another code is much higher.  In the past, I have also avoided to 
add tests that require 5+ options to trigger the issue, adding only those 
that have some hope on more ore less reliably reproducing the required 
issue.  The best solution of course is having an infrastructure to test the 
specific scheduler decisions, which we don't have.


You are welcome to add the test if you feel so strongly about us needing it.

Andrey

Re: [PATCH, committed] Fix PR 57422

[Jakub Jelinek]

On Fri, Dec 27, 2013 at 02:11:13PM +0400, Andrey Belevantsev wrote:
> >Testcase is very small. Why not add it?
> 
> Frankly, I think that the chances of this test uncovering similar
> issues in the future are very small.  It needs lots of options to
> make it trigger and even with this a specific revision.  The chance
> of triggering the asserts I added on another code is much higher.
> In the past, I have also avoided to add tests that require 5+
> options to trigger the issue, adding only those that have some hope
> on more ore less reliably reproducing the required issue.  The best
> solution of course is having an infrastructure to test the specific
> scheduler decisions, which we don't have.
> 
> You are welcome to add the test if you feel so strongly about us needing it.

I guess it depends, if you e.g. have a small runtime testcase, it might be
useful to add it, while it is unlikely it will trigger the same issue, it
could trigger a different issue in another part of the compiler, especially
if the testcase is a combination of e.g. several more rarely used features.
But for a ICE testcase with many weird options to trigger it I agree it
sometimes doesn't make sense to add the testcase, especially if it already
doesn't trigger on the trunk as in this case.

Jakub

Re: RFC Asan instrumentation control

[Jakub Jelinek]

On Tue, Dec 24, 2013 at 02:10:57PM +0400, Maxim Ostapenko wrote:
> >As for the tests, I'm afraid I don't like them at all.
> >If anything, it ought to be dg-do compile tests where you say
> >scan assembly or some dump, but having runtime testcases that
> >trigger undefined behavior that isn't detected by the instrumentation
> >library at all and expect them to "pass" is simply wrong.
> >
> Got it, converted all tests except no-asan-stack.c, because i failed
> to discover how to grep for stack
> instrumentation. Perhaps memcmp of random data is fine?

It is still undefined behavior, IMNSHO it is far better to just change those
tests into compile time tests and verify assembly using dg-final
scan-assembler.  Say verify that __asan_option_detect_stack_use_after_return
isn't present for the no-use-after-return test, or __asan_report_store
resp. __asan_report_load isn't present, or __asan_register_globals
etc.

Jakub

Re: [PATCH] Fix for PR59585

[Jakub Jelinek]

On Tue, Dec 24, 2013 at 10:05:37AM +0400, Yury Gribov wrote:
> Yury wrote:
> >> Still sounds like a bug elsewhere to me.
> >
> > Let me investigate this deeper tomorrow (rebuilding fresh Dg, etc.).
> 
> So I've double-checked that this is a problem with trunk DejaGNU
> rsh.exp script removing trailing newline from test output:
> 
> # Delete one trailing \n because that is what `exec' will do and
> we want
> # to behave identical to it.
> regsub "\n$" $output "" output
> 
> I can report this to DejaGNU mailing list but even if they agree to
> fix we'll still have to do something about legacy Dg installations.
> I suggest to work around by removing trailing newline as suggested
> by original patch (or maybe replacing it with $ ?).
> 
> What's your opinion?

Ok, I guess I can live with the original patch then.

Jakub

Re: RFC Asan instrumentation control

[Yury Gribov]

Jakub wrote:

IMNSHO it is far better to just change those
tests into compile time tests and verify assembly using dg-final
scan-assembler.


We did exactly this for majority of tests except for
* c-c++-common/asan/use-after-return-1.c (back-ported from Clang, no UB)
* c-c++-common/asan/no-asan-stack.c (this triggers read overflow because 
we haven't found a cross-platform way to grep for stack redzones 
instrumentation)


We can simply remove no-asan-stack.c from the patch, then it won't 
contain any UB (but we won't have any test for --param no-asan-stack).


-Y

Re: RFC Asan instrumentation control

[Jakub Jelinek]

Hi!

On Fri, Dec 27, 2013 at 03:06:06PM +0400, Yury Gribov wrote:
> We did exactly this for majority of tests except for

Ah, sorry, I saw one test and didn't check carefully the rest of them.

> * c-c++-common/asan/use-after-return-1.c (back-ported from Clang, no UB)

Well, it is still UB, but one that should be detected by the sanitizer and
stopped before it happens, so it is ok.

> * c-c++-common/asan/no-asan-stack.c (this triggers read overflow
> because we haven't found a cross-platform way to grep for stack
> redzones instrumentation)

I'd prefer no test in that case, or just some semi-platform specific test
(scan that the 0x41b58ab3 constant doesn't appear in say some late RTL dump,
or perhaps just assembly (just scan it with lower and upper case and decimal
too)).

Jakub

Update GCC 4.9 changes.html

[H.J. Lu]

Hi,

This patch adds Intel microarchitecture changes to GCC 4.9 changes.html.
OK to install?

Thanks.

-- 
H.J.
--
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.49
diff -u -p -r1.49 changes.html
--- changes.html18 Dec 2013 02:20:47 -1.49
+++ changes.html27 Dec 2013 11:26:42 -
@@ -393,7 +393,15 @@ auto incr = [](auto x) { return x++; };
   >Function Multiversioning.
 
 GCC now supports the new Intel microarchitecture named Silvermont
-  through -march=slm.
+  through -march=silvermont.
+
+GCC now supports the new Intel microarchitecture named Broadwell
+  through -march=broadwell.
+
+Optimizing for other Intel microarchitectures have been renamed
+  to -march=nahelam, westmere,
+  sandybridge, ivybridge,
+  haswell, bonnell.
 
 -march=generic has been retuned for better support of
   Intel core and AMD Bulldozer architectures.  Performance of AMD K7, K8,

Re: RFA: fix libstdc++ regression, simulator timeout from r205810

[Yufeng Zhang]

Many thanks for your effort in fixing the issue.  I can confirm that the 
new tests pass on arm-eabi using qemu as the simulator.


Thanks,
Yufeng

P.s. Wish you have nice holiday break and happy new year!

On 12/20/13 01:12, Hans-Peter Nilsson wrote:

Here's a patch that splits up 20_util/hash/chi2_quality.cc *and*
increases some of the iteration numbers for simulator targets to
something that passes for all working targets mentioned below.
I am a bit worried about the stability of these tests and the
implementation, seeing this amount of target-specific
differences in results.  Maybe a person interested in the
quality of the implementation and knowing statistics should have
a look.

I originally naively thought just splitting up the test would
help; allowing to remove the simulator target-test-constraints
completely, but that only produced timeouts for cris-elf.

The effect of this patch is therefore to split it up and
increase some of the SAMPLES values compared to the the current
commit, assuming there's a useful linear dependence.  Don't be
fooled by test_document_words now being excluded at the
test-top: it already was (for all SAMPLES<  10), except for
compiling and running an empty function; see the original.

I've tested this on two different x86_64-linux-gnu hosts, Fedora
17 and Debian 7 aka. "wheezy" (to eliminate my suspicion of
distro differences) and three simulator targets: cris-elf,
powerpc-eabi and mipsisa32r2el-elf.  I also tried running these
tests for arm-eabi / arm-sim.exp but they all failed apparently
because of memory resource constraints within the simulator
setup: in libstdc++.log I see "terminate called after throwing
an instance of 'std::bad_alloc'".

I felt I honestly had to increase some of the SAMPLES numbers
from the current number of 3; the final number I came up
with, passes for all the mentioned working targets.  I didn't
want to *decrease* any of the numbers (e.g. for simulator only)
to exploit some local minima of the "k" values (for example
there's one such for 1 for all targets above except
x86_64/32 and the ones the ARM people mentioned).  So, I
increased the respective number to be higher than where at least
one target showed a test-suite failure.  When checking the
SAMPLES numbers for the hosts, I of course just hacked the
default SAMPLES temporarily; they were not tested as simulator
targets. The SAMPLES number for all but test_bit_flip_set change
to 35000; a number somewhat arbitrarily chosen as higher than
3.

Curiously, I never saw test_bit_flip_set fail as mentioned in
.  Maybe
that was a mistaken observation and what was observed was
test_bit_string_set failing.  (That's a good reason to always
copy-paste instead of *typing* from memory or from reading.)
That test certainly failed for most targets, but also for
SAMPLES=3, not mentioned in the referenced message, which
made me suspect a distribution- or glibc-version-related
difference.

A higher SAMPLES number definitely has a noticeable cost in
terms of test-time, challenging the statement "it doesn't take
that much time either".  For both cris-elf-sim and
powerpc-eabi-sim running on a x86_64 host of yesteryear, the
time for the affected tests went from about 30 seconds to 4 min
28 seconds and 6 min 20 seconds respectively, going from 1
to these numbers.  For the original r205810 change compared to
r205803, test-time for cris-elf for a *complete "make
check"-run* (C, C++, ObjC, Fortran including libraries) went
from 3h56min to 4h5min (when the test timed out).

Ok to commit?

libstdc++-v3:
 * testsuite/20_util/hash/chi2_quality.h: Break out from
 chi2_quality.cc.
 * testsuite/20_util/hash/chi2_q_bit_flip_set.cc: Ditto.
 * testsuite/20_util/hash/chi2_q_document_words.cc: Ditto.
 * testsuite/20_util/hash/chi2_q_bit_string_set.cc: Ditto.  Increase
 SAMPLES to 35000 for simulator targets.
 * testsuite/20_util/hash/chi2_q_numeric_pattern_set.cc: Ditto.
 * testsuite/20_util/hash/chi2_q_uniform_random.cc: Ditto.
 * testsuite/20_util/hash/chi2_quality.cc: Remove.

--- libstdc++-v3/testsuite/20_util/hash/chi2_quality.cc Sun Dec 15 15:01:43 2013
+++ /dev/null   Thu Jan 01 00:00:00 1970 +
@@ -1,218 +0,0 @@
-// { dg-options "-std=gnu++0x" }
-
-// Use smaller statistics when running on simulators, so it takes less time.
-// { dg-options "-std=gnu++0x -DSAMPLES=3" { target simulator } }
-
-// Copyright (C) 2010-2013 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 warr

Re: [C++ Patch] Fix __is_base_of vs incomplete types

[Paolo Carlini]

Hi,

On 12/12/2013 03:19 PM, Jason Merrill wrote:

I wouldn't expect it to cause problems.
Ok. Then I looked a bit into this and something is making me nervous: 
lookup_base wants to return a binfo, not a type. Thus what do we do when 
the type is incomplete and there is no binfo? Something like the below 
"works" but it doesn't seem right vs multiple call of the function with 
the same arguments. Conservatively but still more neatly than my first 
try, we could maybe use same_type_ignoring_top_level_qualifiers_p in the 
definition of the DERIVED_FROM_P macro?


Thanks,
Paolo.


Index: search.c
===
--- search.c(revision 206218)
+++ search.c(working copy)
@@ -242,6 +242,12 @@ lookup_base (tree t, tree base, base_access access
   else
bk = bk_proper_base;
 }
+  else if (CLASS_TYPE_P (base) && same_type_p (TYPE_MAIN_VARIANT (t), base))
+{
+  binfo = make_tree_binfo (0);
+  BINFO_TYPE (binfo) = base;
+  bk = bk_same_type;
+}
   else
 {
   binfo = NULL_TREE;

Re: [PATCH] Fix for PR59585

[Yury Gribov]

Jakub wrote:
> Ok, I guess I can live with the original patch then.

r206219.

-Y

Re: [PATCH i386 6/8] [AVX-512] Add builtins/intrinsics.

[Kirill Yukhin]

Hello,

On 18 Dec 18:16, Uros Bizjak wrote:
> the patch is OK (with above mentioned changes) for mainline.
Thanks,

One more nit. It seems that currently vectorizer expects mask_type to
be equal to operand_type, which doesn't hold for AVX-512F.

So, I'll comment out like this:

@@ -34677,6 +36423,31 @@ ix86_vectorize_builtin_gather (const_tree mem_vectype,
 case V8SImode:
   code = si ? IX86_BUILTIN_GATHERSIV8SI : IX86_BUILTIN_GATHERALTDIV8SI;
   break;
+/*  FIXME: Commented until vectorizer can work with (mask_type != src_type)
+case V8DFmode:
+  if (TARGET_AVX512F)
+   code = si ? IX86_BUILTIN_GATHER3ALTSIV8DF : IX86_BUILTIN_GATHER3DIV8DF;
+  else
+   return NULL_TREE;
+  break;
+case V8DImode:
+  if (TARGET_AVX512F)
+   code = si ? IX86_BUILTIN_GATHER3ALTSIV8DI : IX86_BUILTIN_GATHER3DIV8DI;
+  else
+   return NULL_TREE;
+  break;
+case V16SFmode:
+  if (TARGET_AVX512F)
+   code = si ? IX86_BUILTIN_GATHER3SIV16SF :
IX86_BUILTIN_GATHER3ALTDIV16SF;
+  else
+   return NULL_TREE;
+  break;
+case V16SImode:
+  if (TARGET_AVX512F)
+   code = si ? IX86_BUILTIN_GATHER3SIV16SI :
IX86_BUILTIN_GATHER3ALTDIV16SI;
+  else
+   return NULL_TREE;
+  break;  */

Mark avx512f-gather-*.c tests with XFAIL, submit PR and move whole hunk to 5/8.

Objections?

--
Thanks, K

Re: [PATCH i386 6/8] [AVX-512] Add builtins/intrinsics.

[Uros Bizjak]

On Fri, Dec 27, 2013 at 4:04 PM, Kirill Yukhin  wrote:

> On 18 Dec 18:16, Uros Bizjak wrote:
>> the patch is OK (with above mentioned changes) for mainline.
> Thanks,
>
> One more nit. It seems that currently vectorizer expects mask_type to
> be equal to operand_type, which doesn't hold for AVX-512F.
>
> So, I'll comment out like this:
>
> @@ -34677,6 +36423,31 @@ ix86_vectorize_builtin_gather (const_tree 
> mem_vectype,
>  case V8SImode:
>code = si ? IX86_BUILTIN_GATHERSIV8SI : IX86_BUILTIN_GATHERALTDIV8SI;
>break;
> +/*  FIXME: Commented until vectorizer can work with (mask_type != 
> src_type)
> +case V8DFmode:
> +  if (TARGET_AVX512F)
> +   code = si ? IX86_BUILTIN_GATHER3ALTSIV8DF : 
> IX86_BUILTIN_GATHER3DIV8DF;
> +  else
> +   return NULL_TREE;
> +  break;
> +case V8DImode:
> +  if (TARGET_AVX512F)
> +   code = si ? IX86_BUILTIN_GATHER3ALTSIV8DI : 
> IX86_BUILTIN_GATHER3DIV8DI;
> +  else
> +   return NULL_TREE;
> +  break;
> +case V16SFmode:
> +  if (TARGET_AVX512F)
> +   code = si ? IX86_BUILTIN_GATHER3SIV16SF :
> IX86_BUILTIN_GATHER3ALTDIV16SF;
> +  else
> +   return NULL_TREE;
> +  break;
> +case V16SImode:
> +  if (TARGET_AVX512F)
> +   code = si ? IX86_BUILTIN_GATHER3SIV16SI :
> IX86_BUILTIN_GATHER3ALTDIV16SI;
> +  else
> +   return NULL_TREE;
> +  break;  */
>
> Mark avx512f-gather-*.c tests with XFAIL, submit PR and move whole hunk to 
> 5/8.

Please put this part into #if 0/#endif, with the reference to the PR.
Also add PR reference to xfailed tests.

Thanks,
Uros.

std::vector move assign patch

[François Dumont]

Hi

Here is a patch to fix an issue in normal mode during the move 
assignment. The destination vector allocator instance is moved too 
during the assignment which is wrong.


As I discover this problem while working on issues with management 
of safe iterators during move operations this patch also fix those 
issues in the debug mode for the vector container. Fixes for other 
containers in debug mode will come later.


2013-12-27  François Dumont 

* include/bits/stl_vector.h (std::vector<>::_M_move_assign): Pass
*this allocator instance when building temporary vector instance
so that *this allocator do not get moved.
* include/debug/safe_base.h
(_Safe_sequence_base(_Safe_sequence_base&&)): New.
* include/debug/vector (__gnu_debug::vector<>(vector&&)): Use
latter.
(__gnu_debug::vector<>(vector&&, const allocator_type&)): Swap
safe iterators if the instance is moved.
(__gnu_debug::vector<>::operator=(vector&&)): Likewise.
* testsuite/23_containers/vector/allocator/move.cc (test01): Add
check on a vector iterator.
* testsuite/23_containers/vector/allocator/move_assign.cc
(test02): Likewise.
(test03): New, test with a non-propagating allocator.
* testsuite/23_containers/vector/debug/move_assign_neg.cc: New.

Tested under Linux x86_64 normal and debug modes.

I will be in vacation for a week starting today so if you want to apply 
it quickly do not hesitate to do it yourself.


François

Index: include/bits/stl_vector.h
===
--- include/bits/stl_vector.h	(revision 206214)
+++ include/bits/stl_vector.h	(working copy)
@@ -1433,7 +1433,7 @@
   void
   _M_move_assign(vector&& __x, std::true_type) noexcept
   {
-	const vector __tmp(std::move(*this));
+	const vector __tmp(std::move(*this), get_allocator());
 	this->_M_impl._M_swap_data(__x._M_impl);
 	if (_Alloc_traits::_S_propagate_on_move_assign())
 	  std::__alloc_on_move(_M_get_Tp_allocator(),
Index: include/debug/safe_base.h
===
--- include/debug/safe_base.h	(revision 206214)
+++ include/debug/safe_base.h	(working copy)
@@ -192,6 +192,12 @@
 : _M_iterators(0), _M_const_iterators(0), _M_version(1)
 { }
 
+#if __cplusplus >= 201103L
+_Safe_sequence_base(_Safe_sequence_base&& __x) noexcept
+  : _Safe_sequence_base()
+{ _M_swap(__x); }
+#endif
+
 /** Notify all iterators that reference this sequence that the
 	sequence is being destroyed. */
 ~_Safe_sequence_base()
Index: include/debug/vector
===
--- include/debug/vector	(revision 206214)
+++ include/debug/vector	(working copy)
@@ -52,6 +52,7 @@
   typedef __gnu_debug::_Equal_to<_Base_const_iterator> _Equal;
 
 #if __cplusplus >= 201103L
+  typedef __gnu_debug::_Safe_sequence > _Safe_base;
   typedef __gnu_cxx::__alloc_traits<_Allocator>  _Alloc_traits;
 #endif
 
@@ -111,18 +112,16 @@
   vector(const vector& __x)
   : _Base(__x), _M_guaranteed_capacity(__x.size()) { }
 
-  /// Construction from a release-mode vector
+  /// Construction from a normal-mode vector
   vector(const _Base& __x)
   : _Base(__x), _M_guaranteed_capacity(__x.size()) { }
 
 #if __cplusplus >= 201103L
   vector(vector&& __x) noexcept
   : _Base(std::move(__x)),
+	_Safe_base(std::move(__x)),
 	_M_guaranteed_capacity(this->size())
-  {
-	this->_M_swap(__x);
-	__x._M_guaranteed_capacity = 0;
-  }
+  { __x._M_guaranteed_capacity = 0; }
 
   vector(const vector& __x, const allocator_type& __a)
   : _Base(__x, __a), _M_guaranteed_capacity(__x.size()) { }
@@ -131,7 +130,10 @@
   : _Base(std::move(__x), __a),
 _M_guaranteed_capacity(this->size())
   {
-	__x._M_invalidate_all();
+	if (__x.get_allocator() == __a)
+	  this->_M_swap(__x);
+	else
+	  __x._M_invalidate_all();
 	__x._M_guaranteed_capacity = 0;
   }
 
@@ -146,7 +148,7 @@
   vector&
   operator=(const vector& __x)
   {
-	static_cast<_Base&>(*this) = __x;
+	_M_base() = __x;
 	this->_M_invalidate_all();
 	_M_update_guaranteed_capacity();
 	return *this;
@@ -157,8 +159,13 @@
   operator=(vector&& __x) noexcept(_Alloc_traits::_S_nothrow_move())
   {
 	__glibcxx_check_self_move_assign(__x);
-	_Base::operator=(std::move(__x));
-	this->_M_invalidate_all();
+	bool xfer_memory = _Alloc_traits::_S_propagate_on_move_assign()
+	|| __x.get_allocator() == this->get_allocator();
+	_M_base() = std::move(__x._M_base());
+	if (xfer_memory)
+	  this->_M_swap(__x);
+	else
+	  this->_M_invalidate_all();
 	_M_update_guaranteed_capacity();
 	__x._M_invalidate_all();
 	__x._M_guaranteed_capacity = 0;
@@ -168,7 +175,7 @@
   vector&
   operator=(initializer_list __l)
   {
-	static_cast<_Base&>(*this) = __l;
+	_M_base() = __l;
 	this->_M_invalidate_all();
 	_M_update_guaranteed_capacity();
 	return *thi

Rb tree node recycling patch

[François Dumont]

Hi

Here is a patch to add recycling of Rb tree nodes when possible.

I replaced the _Rb_tree::_M_move_assign with a move assignment 
operator to benefit from:

- move of elements when the whole data structure cannot be moved
- faster data structure cloning rather than full regeneration of the 
tree when _M_move_assign was failing


Note that this patch contains also a cleanup of a useless template 
parameter _Is_pod_comparator on _Rb_tree_impl. If you want to apply it 
quickly for 4.9 do not hesitate.


I haven't done any specific test for this feature, existing ones 
looks good enough to me. If you want me to add some I will when back 
from vacation. I am mostly submitting this patch to show you that I 
worked on it and you do not need to do it yourself.


2013-12-27  François Dumont 

* include/bits/stl_tree.h (_Rb_tree_reuse_or_alloc_node<>): New.
(_Rb_tree_alloc_node<>): Likewise.
(_Rb_tree<>::_M_clone_node): Made template to take a node
generator.
(_Rb_tree_impl<>): Remove unused _Is_pod_comparator template
value.
(_Rb_tree<>::_M_move_assign): Replace by...
(_Rb_tree<>::operator(_Rb_tree&&)): ...this.
(_Rb_tree_impl<>::_M_reset): New.
(_Rb_tree<>::_M_insert_): Add node generator parameter.
(_Rb_tree<>::_M_copy): Add overload taking a node generator.
(_Rb_tree<>::_M_insert_unique_): Add node generator parameter.
(_Rb_tree<>::_M_insert_equal_): Add node generator parameter.
(_Rb_tree<>::_M_assign_unique): New.
(_Rb_tree<>::_M_assign_equal): New.
(_Rb_tree<>): Adapt to use _Rb_tree_impl<>::_M_reset and reuse
nodes as much as possible.
* include/bits/stl_set.h (set<>::operator=(set<>&&): Adapt to use
_Rb_tree move assignment operator.
(set<>::operator=(initializer_list<>)): Adapt to use
_Rb_tree<>::_M_assign_unique.
* include/bits/stl_multiset.h
(multiset<>::operator=(multiset<>&&)): Adapt to use
_Rb_tree move assignment operator.
(multiset<>::operator=(initializer_list<>)): Adapt to use
_Rb_tree<>::_M_assign_equal.
* include/bits/stl_map.h (map<>::operator=(map<>&&): Adapt to use
_Rb_tree move assignment operator.
(map<>::operator=(initializer_list<>)): Adapt to use
_Rb_tree<>::_M_assign_unique.
* include/bits/stl_multimap.h
(multimap<>::operator=(multimap<>&&)): Adapt to use
_Rb_tree move assignment operator.
(multimap<>::operator=(initializer_list<>)): Adapt to use
_Rb_tree<>::_M_assign_equal.

Tested under Linux x86_64.

Happy new year.

François

Index: include/bits/stl_set.h
===
--- include/bits/stl_set.h	(revision 206214)
+++ include/bits/stl_set.h	(working copy)
@@ -277,15 +277,7 @@
   set&
   operator=(set&& __x) noexcept(_Alloc_traits::_S_nothrow_move())
   {
-	if (!_M_t._M_move_assign(__x._M_t))
-	  {
-	// The rvalue's allocator cannot be moved and is not equal,
-	// so we need to individually move each element.
-	clear();
-	insert(std::__make_move_if_noexcept_iterator(__x._M_t.begin()),
-		   std::__make_move_if_noexcept_iterator(__x._M_t.end()));
-	__x.clear();
-	  }
+	_M_t = std::move(__x._M_t);
   	return *this;
   }
 
@@ -303,8 +295,7 @@
   set&
   operator=(initializer_list __l)
   {
-	this->clear();
-	this->insert(__l.begin(), __l.end());
+	_M_t._M_assign_unique(__l.begin(), __l.end());
 	return *this;
   }
 #endif
Index: include/bits/stl_multiset.h
===
--- include/bits/stl_multiset.h	(revision 206214)
+++ include/bits/stl_multiset.h	(working copy)
@@ -274,15 +274,7 @@
   multiset&
   operator=(multiset&& __x) noexcept(_Alloc_traits::_S_nothrow_move())
   {
-	if (!_M_t._M_move_assign(__x._M_t))
-	  {
-	// The rvalue's allocator cannot be moved and is not equal,
-	// so we need to individually move each element.
-	clear();
-	insert(std::__make_move_if_noexcept_iterator(__x._M_t.begin()),
-		   std::__make_move_if_noexcept_iterator(__x._M_t.end()));
-	__x.clear();
-	  }
+	_M_t = std::move(__x._M_t);
 	return *this;
   }
 
@@ -300,8 +292,7 @@
   multiset&
   operator=(initializer_list __l)
   {
-	this->clear();
-	this->insert(__l.begin(), __l.end());
+	_M_t._M_assign_equal(__l.begin(), __l.end());
 	return *this;
   }
 #endif
Index: include/bits/stl_map.h
===
--- include/bits/stl_map.h	(revision 206214)
+++ include/bits/stl_map.h	(working copy)
@@ -307,15 +307,7 @@
   map&
   operator=(map&& __x) noexcept(_Alloc_traits::_S_nothrow_move())
   {
-	if (!_M_t._M_move_assign(__x._M_t))
-	  {
-	// The rvalue's allocator cannot be moved and is not equal,
-	// so we need to individually move each element.
-	clear();
-	insert(std::__make_move_if_noexcept_iterator(__x.begin()),
-		   std::__make_move_if_noexcept_iterator(__

libgo patch committed: Use DialTimeout in self-connect test

[Ian Lance Taylor]

This patch from Uros Bizjak changes TestSelfConnect to use DialTimeout,
to avoid a problem where some operating systems take a long time to fail
a connection to localhost.  This patch adds a timeout to make the
connection fail quickly.  This is PR 59506.  Ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r 9f703c696641 libgo/go/net/dial_test.go
--- a/libgo/go/net/dial_test.go	Tue Dec 17 12:26:20 2013 -0800
+++ b/libgo/go/net/dial_test.go	Fri Dec 27 13:37:23 2013 -0800
@@ -147,7 +147,7 @@
 		n = 100
 	}
 	for i := 0; i < n; i++ {
-		c, err := Dial("tcp", addr)
+		c, err := DialTimeout("tcp", addr, time.Millisecond)
 		if err == nil {
 			c.Close()
 			t.Errorf("#%d: Dial %q succeeded", i, addr)

[Patch, trivial] PR 56653: Fix warning when verifying checksums from MD5SUMS file in tarballs

[Dmitry Gorbachev]

This patch is to fix `md5sum: WARNING: 1 line is improperly formatted' thing.


2013-12-28  Dmitry Gorbachev  

PR 56653
* gcc_release: Add an extra `#' character to the comment header of
MD5SUMS.


*** maintainer-scripts/gcc_release
--- maintainer-scripts/gcc_release
***
*** 214,218 
  # Suggested usage:
  # md5sum -c MD5SUMS | grep -v \"OK$\"
! " > MD5SUMS

find . -type f |
--- 214,218 
  # Suggested usage:
  # md5sum -c MD5SUMS | grep -v \"OK$\"
! #" > MD5SUMS

find . -type f |

[Patch, trivial] Fix a potential bug of cost_classes_eq in ira-costs.c

[Yangfei (Felix)]

Hi Vladimir,

  I am trying to fix a potential bug of cost_classes_eq in ira-costs.c. This 
patch is for gcc-4.8 branch and should work for gcc-4.9.
  Library function memcmp return 0 if no difference for the two compared data. 
Please take a look.
  
  
/* Compares cost classes info V1 and V2.  */
static int
cost_classes_eq (const void *v1, const void *v2)
{
  const_cost_classes_t hv1 = (const_cost_classes_t) v1;
  const_cost_classes_t hv2 = (const_cost_classes_t) v2;

  return hv1->num == hv2->num && memcmp (hv1->classes, hv2->classes,
-sizeof (enum reg_class) * hv1->num);
+sizeof (enum reg_class) * hv1->num) == 
0;
}

Cheers,
Fei

Re: [PATCH][1/3] Re-submission of Altera Nios II port, gcc parts

[Chung-Lin Tang]

On 13/12/23 12:54 AM, Chung-Lin Tang wrote:
>> Other than these two, I think this can go in.
>> > Bernd
> Attached is the updated patch for the compiler.
> 
> Since Bernd is a Global Reviewer, am I clear for committing the port
> now? (including the testsuite and libgcc parts)

I will be taking Bernd's prior mail as an approval. For avoidance of
doubt, unless there are more comments raised, I will be committing the
port to trunk next week.

Thanks,
Chung-Lin