Re: [PATCH, i386, Android] -mandroid support for i386 target

[Ilya Enkovich]

Hello Maxim,

Thanks a lot for review. My comments are below.

 On 28/02/2012, at 3:41 AM, Ilya Enkovich wrote:

 You should keep those *_SPEC and define them with new
 GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
 by other non-linux targets.  In linux.h, you undef *_SPEC
 before defining them.


 --
 H.J.

 Thanks for the note. Here is fixed version. Is it OK now?

 This version looks mostly OK, but still needs a bit of work and testing.

 How did you test this patch?  You should have built before- and after-patch 
 compilers for both Linux and Android and run regression testsuites at least 
 for Linux, and make sure there are no new failures.

 As is, it appears this patch did not see much testing, I'm pretty sure it 
 breaks building shared libraries and PIE executable for Linux.

I do not expect any changes in compiler behavior for non Android
targets. I bootstrapped and checked patched compiler on linux-x86_64.
I also built ptched compiler for Android target using NDK scripts.




 Thanks,
 Ilya
 --
 2012-02-27  Enkovich Ilya  ilya.enkov...@intel.com

       * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New.
       (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC.
       (GNU_USER_TARGET_LINK_SPEC): New.
       (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
       (GNU_USER_TARGET_MATHFILE_SPEC): New.
       (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC.

       * gcc/config/i386/linux.h (CC1_SPEC): New.
       (LINK_SPEC): New.
       (LIB_SPEC): New.
       (STARTFILE_SPEC): New.
       (ENDFILE_SPEC): New.


 diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
 index 98d0a25..33ceab7 100644
 --- a/gcc/config/i386/gnu-user.h
 +++ b/gcc/config/i386/gnu-user.h
 @@ -77,8 +77,11 @@ along with GCC; see the file COPYING3.  If not see
 #undef CPP_SPEC
 #define CPP_SPEC %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}

 +#undef GNU_USER_TARGET_CC1_SPEC
 +#define GNU_USER_TARGET_CC1_SPEC %(cc1_cpu) %{profile:-p}

 Here and in other instances below you use GNU_USER_TARGET_ prefix.  I would 
 prefer using a shorter GNU_USER_ instead unless there is a good reason to 
 add TARGET too.

The reason is that some macroses are defined in other files and I just
redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also
used for other targets (i.e. in linux-eabi.h). So I do not see a good
reason to change it everywhere or mix it with other prefix
GNU_USER_.


 +
 #undef CC1_SPEC
 -#define CC1_SPEC %(cc1_cpu) %{profile:-p}
 +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC

 /* Provide a LINK_SPEC appropriate for GNU userspace.  Here we provide 
 support
    for the special GCC options -static and -shared, which allow us to
 @@ -97,22 +100,28 @@ along with GCC; see the file COPYING3.  If not see
   { link_emulation, GNU_USER_LINK_EMULATION },\
   { dynamic_linker, GNU_USER_DYNAMIC_LINKER }

 -#undef       LINK_SPEC
 -#define LINK_SPEC -m %(link_emulation) %{shared:-shared} \
 +#define GNU_USER_TARGET_LINK_SPEC \
 +  -m %(link_emulation) %{shared:-shared} \
   %{!shared: \
     %{!static: \
       %{rdynamic:-export-dynamic} \
       -dynamic-linker %(dynamic_linker)} \
       %{static:-static}}

 +#undef       LINK_SPEC
 +#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC
 +
 /* Similar to standard GNU userspace, but adding -ffast-math support.  */
 -#undef  ENDFILE_SPEC
 -#define ENDFILE_SPEC \
 +#define GNU_USER_TARGET_MATHFILE_SPEC \
   %{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
    %{mpc32:crtprec32.o%s} \
    %{mpc64:crtprec64.o%s} \
 -   %{mpc80:crtprec80.o%s} \
 -   %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s
 +   %{mpc80:crtprec80.o%s}
 +
 +#undef  ENDFILE_SPEC
 +#define ENDFILE_SPEC \
 +  GNU_USER_TARGET_MATHFILE_SPEC   \
 +  GNU_USER_TARGET_ENDFILE_SPEC

 Here you remove %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s.  
 Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you 
 never define it.

You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined
in gcc/config/gnu-user.h.



 /* A C statement (sans semicolon) to output to the stdio stream
    FILE the assembler definition of uninitialized global DECL named
 diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
 index 73681fe..a832ddc 100644
 --- a/gcc/config/i386/linux.h
 +++ b/gcc/config/i386/linux.h

 i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is 
 used for multilib-enabled x86 toolchains.  Placing below definitions in 
 i386/linux.h will not allow adding an Android as an additional multilib to 
 -m32/-m64 x86 builds.  I improve on this situation I suggest:
 - rename i386/linux.h to i386/linux32.h (with corresponding change to 
 config.gcc),
 - put below definitions to new i386/linux.h (remember to add license notice 
 header to the new file),
 - include i386/linux.h from both i386/linux32.h and i386/linux64.h.

Android does not support x86_64 target and therefore I do not want
-mandroid support for this target. When Android supports 

Re: [PATCH, i386, Android] -mandroid support for i386 target

[Ilya Enkovich]

Hello Honza,

 2012-02-27  Enkovich Ilya  ilya.enkov...@intel.com

       * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New.
       (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC.
       (GNU_USER_TARGET_LINK_SPEC): New.
       (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
       (GNU_USER_TARGET_MATHFILE_SPEC): New.
       (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC.

       * gcc/config/i386/linux.h (CC1_SPEC): New.
       (LINK_SPEC): New.
       (LIB_SPEC): New.
       (STARTFILE_SPEC): New.
       (ENDFILE_SPEC): New.
 OK.
 I guess the patch now follows quite closely the arm implementation, right?
 I am not quite sure if it makes sense to go around hassle and breaking up
 the following into generic linux-or-android.h?

Right, impementations are quite close but do not same. For example
ENDFILE_SPEC and CC1PLUS_SPEC are defined differently. Therefore we
will have target specific parts anyway.

Ilya

 Honza

 diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
 index 73681fe..a832ddc 100644
 --- a/gcc/config/i386/linux.h
 +++ b/gcc/config/i386/linux.h
 @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3.  If not see

  #define GNU_USER_LINK_EMULATION elf_i386
  #define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2
 +
 +#undef CC1_SPEC
 +#define CC1_SPEC \
 +  LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \
 +                    GNU_USER_TARGET_CC1_SPEC   ANDROID_CC1_SPEC)
 +
 +#undef       LINK_SPEC
 +#define LINK_SPEC \
 +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \
 +                    GNU_USER_TARGET_LINK_SPEC   ANDROID_LINK_SPEC)
 +
 +#undef  LIB_SPEC
 +#define LIB_SPEC \
 +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \
 +                    GNU_USER_TARGET_LIB_SPEC   ANDROID_LIB_SPEC)
 +
 +#undef  STARTFILE_SPEC
 +#define STARTFILE_SPEC \
 +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \
 +                    ANDROID_STARTFILE_SPEC)
 +
 +#undef  ENDFILE_SPEC
 +#define ENDFILE_SPEC \
 +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC   \
 +                    GNU_USER_TARGET_ENDFILE_SPEC,     \
 +                    GNU_USER_TARGET_MATHFILE_SPEC   \
 +                    ANDROID_ENDFILE_SPEC)

Re: [PATCH, i386, Android] -mandroid support for i386 target

[H.J. Lu]

On Sun, Apr 1, 2012 at 8:23 AM, Ilya Enkovich enkovich@gmail.com wrote:

 i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is 
 used for multilib-enabled x86 toolchains.  Placing below definitions in 
 i386/linux.h will not allow adding an Android as an additional multilib to 
 -m32/-m64 x86 builds.  I improve on this situation I suggest:
 - rename i386/linux.h to i386/linux32.h (with corresponding change to 
 config.gcc),
 - put below definitions to new i386/linux.h (remember to add license notice 
 header to the new file),
 - include i386/linux.h from both i386/linux32.h and i386/linux64.h.

 Android does not support x86_64 target and therefore I do not want
 -mandroid support for this target. When Android supports x86_64 target
 this change would be appropriate.


Please add x86-64 Android support as suggested by Maxim.  It can also
be used for x32 Android.


-- 
H.J.

Re: [google] Work around PR52796 by replacing empty packs with explicit overloads. (issue5971053)

[Diego Novillo]

On 3/30/12 9:55 PM, Jeffrey Yasskin wrote:

Work around http://gcc.gnu.org/PR52796 in gcc-4.6 by adding an
overload of each function that passes a parameter pack directly as the
only arguments of an object's constructor, which explicitly takes no
arguments in place of the pack.

Tested with check-c++ and by trying to provoke the bug in valgrind for
each changed location.  Some of the insert_aux locations appear
inaccessible because of missing emplace() functions.

I plan to only apply this to the google/gcc-4_6 branch, since gcc-4.7
already makes these cases work properly.

2012-03-30   Jeffrey Yasskinjyass...@google.com

* libstdc++-v3/include/ext/pool_allocator.h: Add 1-argument construct() 
method.
* libstdc++-v3/include/ext/bitmap_allocator.h: Likewise.
* libstdc++-v3/include/ext/new_allocator.h: Likewise.
* libstdc++-v3/include/ext/malloc_allocator.h: Likewise.
* libstdc++-v3/include/ext/array_allocator.h: Likewise.
* libstdc++-v3/include/ext/mt_allocator.h: Likewise.
* libstdc++-v3/include/ext/extptr_allocator.h: Likewise.
* libstdc++-v3/include/bits/stl_construct.h:Add 1-argument _Construct 
function.
* libstdc++-v3/include/bits/stl_list.h: Add default _List_node 
constructor.
* libstdc++-v3/include/bits/hashtable_policy.h: Add default _Hash_node 
constructor.
* libstdc++-v3/include/bits/forward_list.h:Add default _Fwd_list_node 
constructor.
* libstdc++-v3/include/bits/stl_tree.h:Add default _Rb_tree_node 
constructor.
* 
libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/assign_neg.cc:
 Update line numbers.
* 
libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/insert_neg.cc:
 Likewise.
* 
libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/constructor_1_neg.cc:
 Likewise.
* 
libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/constructor_2_neg.cc:
 Likewise.
* 
libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc: 
Likewise.
* 
libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc: 
Likewise.
* 
libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc:
 Likewise.
* 
libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc:
 Likewise.


This is OK for google/gcc-4_6.

I'm not sure it makes sense to propose it for gcc-4_6-branch. 
Jason/Ben, any opinions on PR 52796 and what should we do for 
gcc-4_6-branch?



Thanks.  Diego.

[v3] Fix std::function to cope with volatile-qualified pointers to members

[Jonathan Wakely]

(N.B. not pointers to volatile member functions!)

* include/std/functional (__callable_functor): Overload for
volatile-qualified pointers.
* testsuite/20_util/function/10.cc: New.

Tested x86_64-linux, committed to trunk.  I think the problem is
obscure enough that the fix doesn't need to go on older branches.
commit fb1df22f59d2ac8f60b9ec1b90f5ce062dbfdaab
Author: Jonathan Wakely jwakely@gmail.com
Date:   Tue Mar 27 22:18:00 2012 +0100

* include/std/functional (__callable_functor): Overload for
volatile-qualified pointers.
* testsuite/20_util/function/10.cc: New.

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index 14785dd..980c6ab 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1716,6 +1716,16 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
 __callable_functor(_Member _Class::* const __p)
 { return std::mem_fn(__p); }
 
+  templatetypename _Member, typename _Class
+inline _Mem_fn_Member _Class::*
+__callable_functor(_Member _Class::* volatile __p)
+{ return std::mem_fn(__p); }
+
+  templatetypename _Member, typename _Class
+inline _Mem_fn_Member _Class::*
+__callable_functor(_Member _Class::* const volatile __p)
+{ return std::mem_fn(__p); }
+
   templatetypename _Signature
 class function;
 
diff --git a/libstdc++-v3/testsuite/20_util/function/10.cc 
b/libstdc++-v3/testsuite/20_util/function/10.cc
new file mode 100644
index 000..3776f39
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/function/10.cc
@@ -0,0 +1,37 @@
+// { dg-options -std=gnu++0x }
+// { dg-do compile }
+//
+// Copyright (C) 2012 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
+// http://www.gnu.org/licenses/.
+
+// 20.8.11 polymorphic function object wrapper
+
+#include functional
+
+struct X { void f() { } };
+
+void (X::*p)() = X::f;
+void (X::* volatile vp)() = p;
+
+typedef std::functionvoid(X) function_type;
+
+void test01()
+{
+  function_type f( vp );
+  function_type f2( std::ref(vp) );
+  function_type f3( std::cref(vp) );
+}

PATCH: Update x32 rt_sigreturn syscall number to 0x40000201

[H.J. Lu]

On Tue, Aug 2, 2011 at 9:38 PM, Ian Lance Taylor i...@airs.com wrote:
 H.J. Lu hongjiu...@intel.com writes:

 2011-08-02  H.J. Lu  hongjiu...@intel.com

       * config/i386/linux-unwind.h (RT_SIGRETURN_SYSCALL): New.
       (x86_64_fallback_frame_state): Use RT_SIGRETURN_SYSCALL and
       long long to check rt_sigreturn syscall.

 This is OK.


Hi,

The final rt_sigreturn syscall number is changed to 0x4201 in
Linux kernel v3.4-rc1.  This patch updates x32 rt_sigreturn syscall
number.  OK for trunk and 4.7 branch?

Thanks.


-- 
H.J.


gcc-x32-sigreturn.patch
Description: Binary data

Re: [C++ RFC / Patch] Implementing Deducing noexcept for destructors

[Jason Merrill]

On 03/30/2012 09:34 PM, Paolo Carlini wrote:

Thus I'm adding a
!TYPE_BEING_DEFINED (DECL_CONTEXT (decl)) check


Sounds good.


we reject, with a different exception specifier error, both:

templatetypename T
struct A
{
  ~A() noexcept;
};

templatetypename T
AT::~A() { }

and:

templatetypename T
struct A
{
  ~A();
};

templatetypename T
AT::~A() noexcept { }

Over the last days I wasted a lot of time trying painfully to not reject 
either, but actually now I'm pretty sure that we are right to reject the former 
(there are exception specifiers on the declaration thus automatic deduction 
should not trigger at all) and probably also the latter.


I'm OK with that, as long as we correctly allow

struct B
{
  ~B() noexcept;
};

B::~B() { }

and

struct B
{
  ~B();
};
B::~B() noexcept { }

The patch is OK.

Jason

Re: [PATCH, i386, Android] -mandroid support for i386 target

[Maxim Kuvyrkov]

On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote:

 As is, it appears this patch did not see much testing, I'm pretty sure it 
 breaks building shared libraries and PIE executable for Linux.
 
 I do not expect any changes in compiler behavior for non Android
 targets. I bootstrapped and checked patched compiler on linux-x86_64.
 I also built ptched compiler for Android target using NDK scripts.

OK.

 
 Here and in other instances below you use GNU_USER_TARGET_ prefix.  I 
 would prefer using a shorter GNU_USER_ instead unless there is a good 
 reason to add TARGET too.
 
 The reason is that some macroses are defined in other files and I just
 redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also
 used for other targets (i.e. in linux-eabi.h). So I do not see a good
 reason to change it everywhere or mix it with other prefix
 GNU_USER_.

OK.

 Here you remove %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s.  
 Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you 
 never define it.
 
 You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined
 in gcc/config/gnu-user.h.

OK.  I missed that GNU_USER_TARGET_ENDFILE_SPEC was already defined.

 
 
 
 /* A C statement (sans semicolon) to output to the stdio stream
FILE the assembler definition of uninitialized global DECL named
 diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
 index 73681fe..a832ddc 100644
 --- a/gcc/config/i386/linux.h
 +++ b/gcc/config/i386/linux.h
 
 i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is 
 used for multilib-enabled x86 toolchains.  Placing below definitions in 
 i386/linux.h will not allow adding an Android as an additional multilib to 
 -m32/-m64 x86 builds.  I improve on this situation I suggest:
 - rename i386/linux.h to i386/linux32.h (with corresponding change to 
 config.gcc),
 - put below definitions to new i386/linux.h (remember to add license notice 
 header to the new file),
 - include i386/linux.h from both i386/linux32.h and i386/linux64.h.
 
 Android does not support x86_64 target and therefore I do not want
 -mandroid support for this target. When Android supports x86_64 target
 this change would be appropriate.

The point is that one can build a toolchain for i686-linux-gnu that will 
support both 32-bit and 64-bit multilibs.  The 32-bit multilib will be used by 
default, and compilation for 64-bit user-space can be requested with -m64 
option.  Even though Android is not supported for -m64, such a toolchain can 
support Android as a additional -m32 -mandroid multilib.  I.e., the toolchain 
will have three multilibs in total: -m32 (default), -m64 and -m32 
-mandroid.  I386/linux64.h will be picked up for such a toolchain, even though 
by default it would compile for 32-bit target.  Does this clear up things?

Thank you,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

Re: [PATCH, i386, Android] -mandroid support for i386 target

[Maxim Kuvyrkov]

On 30/03/2012, at 6:48 AM, Jan Hubicka wrote:

 2012-02-27  Enkovich Ilya  ilya.enkov...@intel.com
 
  * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New.
  (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC.
  (GNU_USER_TARGET_LINK_SPEC): New.
  (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
  (GNU_USER_TARGET_MATHFILE_SPEC): New.
  (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC.
 
  * gcc/config/i386/linux.h (CC1_SPEC): New.
  (LINK_SPEC): New.
  (LIB_SPEC): New.
  (STARTFILE_SPEC): New.
  (ENDFILE_SPEC): New.
 OK.
 I guess the patch now follows quite closely the arm implementation, right?
 I am not quite sure if it makes sense to go around hassle and breaking up
 the following into generic linux-or-android.h?

I think this is clear as one can reasonably get.  It would be possible to 
include linux-or-android.h at the end of linux*.h that would #undef/#define 
*_SPEC macros like below, but it seems clearer to give the final choice of what 
is going into the *_SPEC macros to individual targets.

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

 diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
 index 73681fe..a832ddc 100644
 --- a/gcc/config/i386/linux.h
 +++ b/gcc/config/i386/linux.h
 @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3.  If not see
 
 #define GNU_USER_LINK_EMULATION elf_i386
 #define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2
 +
 +#undef CC1_SPEC
 +#define CC1_SPEC \
 +  LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \
 +   GNU_USER_TARGET_CC1_SPEC   ANDROID_CC1_SPEC)
 +
 +#undef  LINK_SPEC
 +#define LINK_SPEC \
 +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \
 +   GNU_USER_TARGET_LINK_SPEC   ANDROID_LINK_SPEC)
 +
 +#undef  LIB_SPEC
 +#define LIB_SPEC \
 +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \
 +   GNU_USER_TARGET_LIB_SPEC   ANDROID_LIB_SPEC)
 +
 +#undef  STARTFILE_SPEC
 +#define STARTFILE_SPEC \
 +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \
 +   ANDROID_STARTFILE_SPEC)
 +
 +#undef  ENDFILE_SPEC
 +#define ENDFILE_SPEC \
 +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC   \
 +   GNU_USER_TARGET_ENDFILE_SPEC, \
 +   GNU_USER_TARGET_MATHFILE_SPEC   \
 +   ANDROID_ENDFILE_SPEC)

[v3] fix libstdc++/52591

[Jonathan Wakely]

This allows move-assignment for std::vectorT when T is not
MoveAssignable but the allocator is moved or equal, as a QoI
extension.  It also makes the code a bit cleaner and simpler, so I
plan to use the same pattern as I make the rest of the library meet
the allocator-aware container requirements.

PR libstdc++/52591
* include/bits/stl_vector.h (vector::operator=(vector)): Dispatch
to _M_move_assign depending on whether allocator is moved.
(vector::_M_move_assign): Add overloaded functions.
* testsuite/23_containers/vector/52591.cc: New.
* testsuite/23_containers/vector/requirements/dr438/assign_neg.cc:
Adjust dg-error line number.
* 
testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc:
Likewise.
* 
testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc:
Likewise.
* testsuite/23_containers/vector/requirements/dr438/insert_neg.cc:
Likewise.

Tested x86_64-linux, committed to trunk.  After this has been on the
trunk for a while I plan to apply it to the 4.7 branch too.
commit e08d4fbd65667448fd93505acefc4828baff7a69
Author: Jonathan Wakely jwakely@gmail.com
Date:   Fri Mar 16 22:22:31 2012 +

PR libstdc++/52591
* include/bits/stl_vector.h (vector::operator=(vector)): Dispatch
to _M_move_assign depending on whether allocator is moved.
(vector::_M_move_assign): Add overloaded functions.
* testsuite/23_containers/vector/52591.cc: New.
* testsuite/23_containers/vector/requirements/dr438/assign_neg.cc:
Adjust dg-error line number.
* 
testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc:
Likewise.
* 
testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc:
Likewise.
* testsuite/23_containers/vector/requirements/dr438/insert_neg.cc:
Likewise.

diff --git a/libstdc++-v3/include/bits/stl_vector.h 
b/libstdc++-v3/include/bits/stl_vector.h
index 239f8b9..31660d3 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -428,36 +428,18 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*  @brief  %Vector move assignment operator.
*  @param  __x  A %vector of identical element and allocator types.
*
-   *  The contents of @a __x are moved into this %vector (without copying).
+   *  The contents of @a __x are moved into this %vector (without copying,
+   *  if the allocators permit it).
*  @a __x is a valid, but unspecified %vector.
*/
   vector
   operator=(vector __x) noexcept(_Alloc_traits::_S_nothrow_move())
   {
-   if (_Alloc_traits::_S_propagate_on_move_assign())
- {
-   // We're moving the rvalue's allocator so can move the data too.
-   const vector __tmp(std::move(*this)); // discard existing data
-   this-_M_impl._M_swap_data(__x._M_impl);
-   std::__alloc_on_move(_M_get_Tp_allocator(),
-__x._M_get_Tp_allocator());
- }
-   else if (_Alloc_traits::_S_always_equal()
-|| __x._M_get_Tp_allocator() == this-_M_get_Tp_allocator())
- {
-   // The rvalue's allocator can free our storage and vice versa,
-   // so can swap the data storage after destroying our contents.
-   this-clear();
-   this-_M_impl._M_swap_data(__x._M_impl);
- }
-   else
- {
-   // The rvalue's allocator cannot be moved, or is not equal,
-   // so we need to individually move each element.
-   this-assign(std::__make_move_if_noexcept_iterator(__x.begin()),
-std::__make_move_if_noexcept_iterator(__x.end()));
-   __x.clear();
- }
+constexpr bool __move_storage =
+  _Alloc_traits::_S_propagate_on_move_assign()
+  || _Alloc_traits::_S_always_equal();
+_M_move_assign(std::move(__x),
+   integral_constantbool, __move_storage());
return *this;
   }
 
@@ -1363,6 +1345,39 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
std::_Destroy(__pos, this-_M_impl._M_finish, _M_get_Tp_allocator());
this-_M_impl._M_finish = __pos;
   }
+
+#ifdef __GXX_EXPERIMENTAL_CXX0X__
+private:
+  // Constant-time move assignment when source object's memory can be
+  // moved, either because the source's allocator will move too
+  // or because the allocators are equal.
+  void
+  _M_move_assign(vector __x, std::true_type) noexcept
+  {
+   const vector __tmp(std::move(*this));
+   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(),
+  __x._M_get_Tp_allocator());
+  }
+
+  // Do move assignment when it might not be possible to move source
+ 

Re: [v3] fix libstdc++/52476

[Paolo Carlini]

Hi,

Attached patch applied.

2012-03-16  François Dumont fdum...@gcc.gnu.org

PR libstdc++/52476
* include/bits/hashtable.h (_Hashtable::_M_rehash_aux): Add.
(_Hashtable::_M_rehash): Use the latter.
* testsuite/23_containers/unordered_multimap/insert/52476.cc: 
New.
* testsuite/23_containers/unordered_multiset/insert/52476.cc: 
New.
Francois, at your ease, I think it's time to apply the fix to 4_7-branch 
too and resolve the PR. By the way, Daniel confirmed in private email 
that mainline works just fine now.


Thanks,
Paolo.

Re: [PATCH] Preserve loops from tree to RTL loop optimizers

[David Edelsohn]

 If there are no further comments I am inclined to commit this
 patch early next week (possibly causing quite some fallout ...).

I am glad there was not more fallout.  Unfortunately powerpc-aix was
not so lucky:

/farm/dje/src/src/libstdc++-v3/src/c++98/streambuf.cc: In function
'std::streamsize
std::__copy_streambufs_eof(std::basic_streambuf_CharT, _Traits*,
std::basic_streambuf_CharT, _Traits*, bool) [with _CharT = wchar_t;
_Traits = std::char_traitswchar_t; std::streamsize = long int]':
/farm/dje/src/src/libstdc++-v3/src/c++98/streambuf.cc:113:5: internal
compiler error: in get_loop_body, at cfgloop.c:831

Line 831 is:

  gcc_assert (tv == loop-num_nodes);

Reverting the patch fixes the ICE.

- David

Re: [C++ RFC / Patch] Implementing Deducing noexcept for destructors

[Paolo Carlini]

Hi,

we reject, with a different exception specifier error, both:

templatetypename T
struct A
{
  ~A() noexcept;
};

templatetypename T
AT::~A() { }

and:

templatetypename T
struct A
{
  ~A();
};

templatetypename T
AT::~A() noexcept { }

Over the last days I wasted a lot of time trying painfully to not 
reject either, but actually now I'm pretty sure that we are right to 
reject the former (there are exception specifiers on the declaration 
thus automatic deduction should not trigger at all) and probably also 
the latter.


I'm OK with that, as long as we correctly allow

struct B
{
  ~B() noexcept;
};

B::~B() { }

and

struct B
{
  ~B();
};
B::~B() noexcept { }

Agreed. Thanks for asking on the reflector.


The patch is OK.

Thanks again, the patch is in with the attached ChangeLog.

Paolo.


/cp
2012-04-01  Paolo Carlini  paolo.carl...@oracle.com

PR c++/50043
* class.c (deduce_noexcept_on_destructor,
deduce_noexcept_on_destructors): New.
(check_bases_and_members): Call the latter.
* decl.c (grokfndecl): Call the former.
* method.c (implicitly_declare_fn): Not static.
* cp-tree.h (deduce_noexcept_on_destructor, implicitly_declare_fn):
Declare

/testsuite
2012-04-01  Paolo Carlini  paolo.carl...@oracle.com

PR c++/50043
* g++.dg/cpp0x/noexcept17.C: New.
* g++.old-deja/g++.eh/cleanup1.C: Adjust.
* g++.dg/tree-ssa/ehcleanup-1.C: Likewise.
* g++.dg/cpp0x/noexcept01.C: Likewise.
* g++.dg/eh/init-temp1.C: Likewise.
* g++.dg/eh/ctor1.C: Likwise.

Re: [PATCH] PR c++/40942 - Failure of template specialization partial ordering

[Jason Merrill]

OK.

Jason