Re: [PATCH,AIX] Enable XCOFF in libbacktrace on AIX

[Rainer Orth]

Hi Ian,

> On Mon, May 15, 2017 at 7:24 AM, REIX, Tony  wrote:
>> Description:
>>  * This patch enables libbacktrace to handle XCOFF on AIX.
>>
>> Tests:
>>  * Fedora25/x86_64 + GCC v7.1.0 : Configure/Build: SUCCESS
>>- build made by means of a .spec file based on Fedora gcc-7.0.1-0.12 
>> .spec file
>>  ../configure --enable-bootstrap 
>> --enable-languages=c,c++,objc,obj-c++,fortran,go,lto --prefix=/usr 
>> --mandir=/usr/share/man --infodir=/usr/share/info 
>> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
>> --enable-threads=posix --enable-checking=release --enable-multilib 
>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
>> --enable-gnu-unique-object --enable-linker-build-id 
>> --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin 
>> --enable-initfini-array --with-isl --enable-libmpx 
>> --enable-offload-targets=nvptx-none --without-cuda-driver 
>> --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 
>> --build=x86_64-redhat-linux
>>
>> ChangeLog:
>>   * libbacktrace/Makefile.am : Add xcoff.c
>>   * libbacktrace/Makefile.in : Regenerated
>>   * libbacktrace/configure.ac : Add XCOFF output file type
>>   * libbacktrace/configure : Regenerated
>>   * libbacktrace/fileline.c : Handle AIX procfs tree
>>   * libbacktrace/filetype.awk : Add AIX XCOFF type detection
>>   * libbacktrace/xcoff.c : New file for handling XCOFF format
>
> Thanks.  Committed with some minor changes, as follows.
>
> Ian
>
>
> 2017-07-21  Tony Reix  
>
> * filetype.awk: Add AIX XCOFF type detection.
> * configure.ac: Recognize xcoff format.
> * Makefile.am (FORMAT_FILES): Add xcoff.c.
> * fileline.c: Include .
> (fileline_initialize): Add case for AIX procfs.
> * xcoff.c: New file.
> * configure, Makefile.in: Rebuild.

this patch broke Solaris bootstrap:

/vol/gcc/src/hg/trunk/local/libbacktrace/fileline.c: In function 
'fileline_initialize':
/vol/gcc/src/hg/trunk/local/libbacktrace/fileline.c:105:41: error: format '%d' 
expects argument of type 'int', but argument 4 has type 'pid_t {aka long int}' 
[-Werror=format=]
snprintf (buf, sizeof (buf), "/proc/%d/object/a.out", getpid ());
~^~
%ld

The following patch allowed bootstrap to finish.

Rainer

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


2017-07-23  Rainer Orth  

* fileline.c (fileline_initialize): Print pid_t as long.

diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -102,7 +102,8 @@ fileline_initialize (struct backtrace_st
 	  filename = "/proc/curproc/file";
 	  break;
 	case 4:
-	  snprintf (buf, sizeof (buf), "/proc/%d/object/a.out", getpid ());
+	  snprintf (buf, sizeof (buf), "/proc/%ld/object/a.out",
+		(long) getpid ());
 	  filename = buf;
 	  break;
 	default:

[PATCH, i386]: fix PR80569, "shrx" instruction generated in 16-bit mode

[Uros Bizjak]

Hello!

We have to prevent BMI, BMI2 and TBM instructions in -m16 mode.

2017-07-23  Uros Bizjak  

PR target/80569
* config/i386/i386.c (ix86_option_override_internal): Disable
BMI, BMI2 and TBM instructions for -m16.

testsuite/ChangeLog:

2017-07-23  Uros Bizjak  

PR target/80569
* gcc.target/i386/pr80569.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline, will backport to release branches.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 250457)
+++ config/i386/i386.c  (working copy)
@@ -6284,6 +6284,12 @@ ix86_option_override_internal (bool main_args_p,
 opts->x_ix86_isa_flags
   |= OPTION_MASK_ISA_LZCNT & ~opts->x_ix86_isa_flags_explicit;
 
+  /* Disable BMI, BMI2 and TBM instructions for -m16.  */
+  if (TARGET_16BIT_P(opts->x_ix86_isa_flags))
+opts->x_ix86_isa_flags
+  &= ~((OPTION_MASK_ISA_BMI | OPTION_MASK_ISA_BMI2 | OPTION_MASK_ISA_TBM)
+  & ~opts->x_ix86_isa_flags_explicit);
+
   /* Validate -mpreferred-stack-boundary= value or default it to
  PREFERRED_STACK_BOUNDARY_DEFAULT.  */
   ix86_preferred_stack_boundary = PREFERRED_STACK_BOUNDARY_DEFAULT;
Index: testsuite/gcc.target/i386/pr80569.c
===
--- testsuite/gcc.target/i386/pr80569.c (nonexistent)
+++ testsuite/gcc.target/i386/pr80569.c (working copy)
@@ -0,0 +1,9 @@
+/* PR target/80569 */
+/* { dg-do assemble } */
+/* { dg-options "-O2 -m16 -march=haswell" } */
+
+void load_kernel(void *setup_addr)
+{
+unsigned int seg = (unsigned int)setup_addr >> 4;
+asm("movl %0, %%es" : : "r"(seg));
+}

[patch, fortran] Fix another dependency check for reallocation on assignment

[Thomas Koenig]

Hello world,

in PR 66102, I found a patch by Mikael which has never been applied.
After dusting it off, finding that it looks reasonable and fixes
the test case in question I'd like to apply this.

Regression-tested. OK for trunk?

Regards

Thomas

2017-07-23  Thomas Koenig  
Mikael Morin 

PR fortran/66102
* fortran/trans-array.c (gfc_conv_resolve_dependencies):
Break if dependency has been found.

2017-07-23  Thomas Koenig  
Mikael Morin 

PR fortran/66102
* gfortran.dg/realloc_on_assign_28.f90:  New test.
Index: fortran/trans-array.c
===
--- fortran/trans-array.c	(Revision 249936)
+++ fortran/trans-array.c	(Arbeitskopie)
@@ -4576,8 +4576,11 @@ gfc_conv_resolve_dependencies (gfc_loopinfo * loop
 	  if (ss_info->type == GFC_SS_REFERENCE
 	  && gfc_check_dependency (dest_expr, ss_expr, false))
 	ss_info->data.scalar.needs_temporary = 1;
-
-	  continue;
+	  
+	  if (nDepend)
+	break;
+	  else
+	continue;
 	}
 
   if (dest_expr->symtree->n.sym != ss_expr->symtree->n.sym)
! { dg-do run }
!
! PR fortran/66102
!
! Contributed by Vladimir Fuka  
!
  type t
integer,allocatable :: i
  end type

  type(t) :: e
  type(t), allocatable, dimension(:) :: a, b
  integer :: chksum = 0

  do i=1,3   ! Was 100 in original
e%i = i
chksum = chksum + i
if (.not.allocated(a)) then
  a = [e]
  b = first_arg([e], [e])
else
  call foo
end if
  end do

  if (sum ([(a(i)%i, i=1,size(a))]) .ne. chksum) call abort
  if (any([(a(i)%i, i=1,size(a))] /= [(i, i=1,size(a))])) call abort
  if (size(a) /= size(b)) call abort
  if (any([(b(i)%i, i=1,size(b))] /= [(i, i=1,size(b))])) call abort
contains
  subroutine foo
b = first_arg([b, e], [a, e])
a = [a, e]
  end subroutine
  elemental function first_arg(arg1, arg2)
type(t), intent(in) :: arg1, arg2
type(t) :: first_arg
first_arg = arg1
  end function first_arg
end

Re: [PATCH] allow deferred-shape pointers in OpenACC data clauses

[Thomas Koenig]

Am 17.07.2017 um 00:31 schrieb Cesar Philippidis:

On 07/16/2017 10:28 AM, Thomas Koenig wrote:



It is possible to declare a pointer with the contiguous attribute.
Is there a reason that this cannot be used in general=


That's a good point. But some users don't want to modify their programs
more beyond adding OpenACC directives.



Hm, I can understand that, at least partially, because CONTIGUOUS is
a F2008 feature which my be rejected by compilers which do not
implement it.



I was considering relaxing the error to a warning, but I ended up
deciding this should be a run-time failure, if there is one.


What happens - silent wrong-code or indeed a run-time error which
lets the user know what is wrong?


It would be a run-time error, like a segmentation fault.


What do you think about changing it into a warning enabled with -Wall?
OK if you agree, otherwise we can continue the discussion.

Regards

Thomas

Re: [PATCH 7/6] fortran: fix pair_cmp qsort comparator

[Thomas Koenig]

Am 21.07.2017 um 16:29 schrieb Alexander Monakov:


Bootstrapped and regtested on x86-64, OK for trunk?

* interface.c (pair_cmp): Fix gfc_symbol comparison.  Adjust comment.


OK.

Thanks for the patch!

Regards

Thomas

[PATCH] PR driver/81523: Make -static override -pie

[H.J. Lu]

-static and -pie together behave differently depending on whether GCC is
configured with --enable-default-pie.  On x86, "-static -pie" fails to
create executable when --enable-default-pie isn't used, but creates a
static executable when --enable-default-pie is used.  This patch makes
-static completely override -pie to create a static executable, regardless
if --enable-default-pie is used to configure GCC.

OK for master?

H.J.
--
2017-07-23  Alan Modra  
H.J. Lu  

gcc/

PR driver/81523
* gcc.c (NO_PIE_SPEC): Delete.
(PIE_SPEC): Define as !no-pie/pie.  Move static|shared|r
exclusion..
(LINK_PIE_SPEC): ..to here.
* config/gnu-user.h (GNU_USER_TARGET_STARTFILE_SPEC): Correct
chain of crtbegin*.o selection, update for PIE_SPEC changes and
format.
(GNU_USER_TARGET_ENDFILE_SPEC): Similarly.
* config/sol2.h (STARTFILE_CRTBEGIN_SPEC): Similarly.
(ENDFILE_CRTEND_SPEC): Similarly.

gcc/testsuite/

PR driver/81523
* gcc.dg/pie-static-1.c: New test.
* gcc.dg/pie-static-2.c: Likewise.
---
 gcc/config/gnu-user.h   | 34 --
 gcc/config/sol2.h   | 12 ++--
 gcc/gcc.c   |  6 ++
 gcc/testsuite/gcc.dg/pie-static-1.c |  7 +++
 gcc/testsuite/gcc.dg/pie-static-2.c |  7 +++
 5 files changed, 46 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pie-static-1.c
 create mode 100644 gcc/testsuite/gcc.dg/pie-static-2.c

diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index 2787a3d16be..de605b0c466 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -50,19 +50,28 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 
 #if defined HAVE_LD_PIE
 #define GNU_USER_TARGET_STARTFILE_SPEC \
-  "%{!shared: %{pg|p|profile:gcrt1.o%s;: \
-%{" PIE_SPEC ":Scrt1.o%s} %{" NO_PIE_SPEC ":crt1.o%s}}} \
-   crti.o%s %{static:crtbeginT.o%s;: %{shared:crtbeginS.o%s} \
- %{" PIE_SPEC ":crtbeginS.o%s} \
- %{" NO_PIE_SPEC ":crtbegin.o%s}} \
+  "%{shared:; \
+ pg|p|profile:gcrt1.o%s; \
+ static:crt1.o%s; \
+ " PIE_SPEC ":Scrt1.o%s; \
+ :crt1.o%s} \
+   crti.o%s \
+   %{static:crtbeginT.o%s; \
+ shared|" PIE_SPEC ":crtbeginS.o%s; \
+ :crtbegin.o%s} \
%{fvtable-verify=none:%s; \
  fvtable-verify=preinit:vtv_start_preinit.o%s; \
  fvtable-verify=std:vtv_start.o%s} \
" CRTOFFLOADBEGIN
 #else
 #define GNU_USER_TARGET_STARTFILE_SPEC \
-  "%{!shared: %{pg|p|profile:gcrt1.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s} \
+  "%{shared:; \
+ pg|p|profile:gcrt1.o%s; \
+ :crt1.o%s} \
+   crti.o%s \
+   %{static:crtbeginT.o%s; \
+ shared|pie:crtbeginS.o%s; \
+ :crtbegin.o%s} \
%{fvtable-verify=none:%s; \
  fvtable-verify=preinit:vtv_start_preinit.o%s; \
  fvtable-verify=std:vtv_start.o%s} \
@@ -82,15 +91,20 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
   "%{fvtable-verify=none:%s; \
  fvtable-verify=preinit:vtv_end_preinit.o%s; \
  fvtable-verify=std:vtv_end.o%s} \
-   %{shared:crtendS.o%s;: %{" PIE_SPEC ":crtendS.o%s} \
-   %{" NO_PIE_SPEC ":crtend.o%s}} crtn.o%s \
+   %{static:crtend.o%s; \
+ shared|" PIE_SPEC ":crtendS.o%s; \
+ :crtend.o%s} \
+   crtn.o%s \
" CRTOFFLOADEND
 #else
 #define GNU_USER_TARGET_ENDFILE_SPEC \
   "%{fvtable-verify=none:%s; \
  fvtable-verify=preinit:vtv_end_preinit.o%s; \
  fvtable-verify=std:vtv_end.o%s} \
-   %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s \
+   %{static:crtend.o%s; \
+ shared|pie:crtendS.o%s; \
+ :crtend.o%s} \
+   crtn.o%s \
" CRTOFFLOADEND
 #endif
 #undef  ENDFILE_SPEC
diff --git a/gcc/config/sol2.h b/gcc/config/sol2.h
index b8398d082a9..bf5203b8c16 100644
--- a/gcc/config/sol2.h
+++ b/gcc/config/sol2.h
@@ -174,9 +174,9 @@ along with GCC; see the file COPYING3.  If not see
%{!ansi:values-Xa.o%s}"
 
 #if defined(HAVE_LD_PIE) && defined(HAVE_SOLARIS_CRTS)
-#define STARTFILE_CRTBEGIN_SPEC "%{shared:crtbeginS.o%s} \
-%{" PIE_SPEC ":crtbeginS.o%s} \
-%{" NO_PIE_SPEC ":crtbegin.o%s}"
+#define STARTFILE_CRTBEGIN_SPEC "%{static:crtbegin.o%s; \
+  shared|" PIE_SPEC ":crtbeginS.o%s; \
+  :crtbegin.o%s}"
 #else
 #define STARTFILE_CRTBEGIN_SPEC"crtbegin.o%s"
 #endif
@@ -224,9 +224,9 @@ along with GCC; see the file COPYING3.  If not see
 #endif
 
 #if defined(HAVE_LD_PIE) && defined(HAVE_SOLARIS_CRTS)
-#define ENDFILE_CRTEND_SPEC "%{shared:crtendS.o%s;: \
-  %{" PIE_SPEC ":crtendS.o%s} \
-  %{" NO_PIE_SPEC ":crtend.o%s}}"
+#define ENDFILE_CRTEND_SPEC "%{static:crtend.o%s; \
+  shared|" PIE_SPEC ":

[PATCH, rs6000, 5/6] Backport patch to align .toc section

[Bill Schmidt]

Hi,

Alan added code to have GCC align the .toc section in GCC 7, aligning to
four bytes for 32-bit mode, and 8 bytes for 64-bit mode.  This is normally
unnecessary since alignment of the .toc has historically been handled by
the standard linker script.  However, people using non-standard toolchains
can still run into problems, so as a courtesy this is now done by the
compiler as well.

We've recently seen this encountered using an out-of-service compiler, and
would like to prevent any more occurrences by people finding interesting
ways to avoid the standard toolchain.  Thus I'd like to backport Alan's
patch to GCC 5 and 6.  Alan, please review as well to be sure I didn't
miss any release-specific differences.

Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Are these backports ok?

Thanks,
Bill


2017-07-23  Bill Schmidt  

Backport from mainline r235874
2016-05-04  Alan Modra  

* config/rs6000/rs6000.c (rs6000_elf_output_toc_section_asm_op):
Align .toc.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 250426)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -32699,8 +32699,8 @@ rs6000_elf_output_toc_section_asm_op (const void *
 {
   if (!toc_initialized)
{
- toc_initialized = 1;
  fprintf (asm_out_file, "%s\n", TOC_SECTION_ASM_OP);
+ ASM_OUTPUT_ALIGN (asm_out_file, TARGET_64BIT ? 3 : 2);
  (*targetm.asm_out.internal_label) (asm_out_file, "LCTOC", 0);
  fprintf (asm_out_file, "\t.tc ");
  ASM_OUTPUT_INTERNAL_LABEL_PREFIX (asm_out_file, "LCTOC1[TC],");
@@ -32708,8 +32708,10 @@ rs6000_elf_output_toc_section_asm_op (const void *
  fprintf (asm_out_file, "\n");
 
  fprintf (asm_out_file, "%s\n", MINIMAL_TOC_SECTION_ASM_OP);
+ ASM_OUTPUT_ALIGN (asm_out_file, TARGET_64BIT ? 3 : 2);
  ASM_OUTPUT_INTERNAL_LABEL_PREFIX (asm_out_file, "LCTOC1");
  fprintf (asm_out_file, " = .+32768\n");
+ toc_initialized = 1;
}
   else
fprintf (asm_out_file, "%s\n", MINIMAL_TOC_SECTION_ASM_OP);
@@ -32716,12 +32718,20 @@ rs6000_elf_output_toc_section_asm_op (const void *
 }
   else if ((DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)
   && !TARGET_RELOCATABLE)
-fprintf (asm_out_file, "%s\n", TOC_SECTION_ASM_OP);
+{
+  fprintf (asm_out_file, "%s\n", TOC_SECTION_ASM_OP);
+  if (!toc_initialized)
+   {
+ ASM_OUTPUT_ALIGN (asm_out_file, TARGET_64BIT ? 3 : 2);
+ toc_initialized = 1;
+   }
+}
   else
 {
   fprintf (asm_out_file, "%s\n", MINIMAL_TOC_SECTION_ASM_OP);
   if (!toc_initialized)
{
+ ASM_OUTPUT_ALIGN (asm_out_file, TARGET_64BIT ? 3 : 2);
  ASM_OUTPUT_INTERNAL_LABEL_PREFIX (asm_out_file, "LCTOC1");
  fprintf (asm_out_file, " = .+32768\n");
  toc_initialized = 1;

std::vector default default and move constructors

[François Dumont]

Hi

Is it time now to consider this patch ?

* include/bits/stl_vector.h
(_Vector_impl_data): New.
(_Vector_impl): Inherit from latter.
(_Vertor_impl(_Vector_impl&&, _Tp_alloc_type&&)): New.
(_Vector_base(_Vector_base&&, const allocator_type&)): Use latter.
(_Vector_base()): Default.
(_Vector_base(size_t)): Delete.
(_Vector_base(_Tp_alloc_type&&)): Delete.
(_Vector_base(_Vector_base&&)): Default.
(vector()): Default.
(vector(vector&&, const allocator_type&, true_type)): New.
(vector(vector&&, const allocator_type&, false_type)): New.
(vector(vector&&, const allocator_type&)): Use latters.

Tested under linux x86_64.

François


diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h
index 69cb803..d1abaf4 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -85,29 +85,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   typedef typename __gnu_cxx::__alloc_traits<_Tp_alloc_type>::pointer
	pointer;
 
-  struct _Vector_impl
-  : public _Tp_alloc_type
+  struct _Vector_impl_data
   {
 	pointer _M_start;
 	pointer _M_finish;
 	pointer _M_end_of_storage;
 
-	_Vector_impl()
-	: _Tp_alloc_type(), _M_start(), _M_finish(), _M_end_of_storage()
-	{ }
-
-	_Vector_impl(_Tp_alloc_type const& __a) _GLIBCXX_NOEXCEPT
-	: _Tp_alloc_type(__a), _M_start(), _M_finish(), _M_end_of_storage()
+	_Vector_impl_data() _GLIBCXX_NOEXCEPT
+	: _M_start(), _M_finish(), _M_end_of_storage()
 	{ }
 
 #if __cplusplus >= 201103L
-	_Vector_impl(_Tp_alloc_type&& __a) noexcept
-	: _Tp_alloc_type(std::move(__a)),
-	  _M_start(), _M_finish(), _M_end_of_storage()
-	{ }
+	_Vector_impl_data(_Vector_impl_data&& __x) noexcept
+	: _M_start(__x._M_start), _M_finish(__x._M_finish),
+	  _M_end_of_storage(__x._M_end_of_storage)
+	{ __x._M_start = __x._M_finish = __x._M_end_of_storage = pointer(); }
 #endif
 
-	void _M_swap_data(_Vector_impl& __x) _GLIBCXX_NOEXCEPT
+	void
+	_M_swap_data(_Vector_impl_data& __x) _GLIBCXX_NOEXCEPT
 	{
 	  std::swap(_M_start, __x._M_start);
 	  std::swap(_M_finish, __x._M_finish);
@@ -230,54 +226,64 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 #endif // _GLIBCXX_SANITIZE_STD_ALLOCATOR && _GLIBCXX_SANITIZE_VECTOR
   };
 
+  struct _Vector_impl
+	: public _Tp_alloc_type, public _Vector_impl_data
+  {
+	_Vector_impl() _GLIBCXX_NOEXCEPT_IF( noexcept(_Tp_alloc_type()) )
+	: _Tp_alloc_type()
+	{ }
+
+	_Vector_impl(_Tp_alloc_type const& __a) _GLIBCXX_NOEXCEPT
+	: _Tp_alloc_type(__a)
+	{ }
+
+#if __cplusplus >= 201103L
+	_Vector_impl(_Vector_impl&&) = default;
+
+	_Vector_impl(_Tp_alloc_type&& __a) noexcept
+	  : _Tp_alloc_type(std::move(__a))
+	{ }
+
+	_Vector_impl(_Vector_impl&& __rv, _Tp_alloc_type&& __a) noexcept
+	: _Tp_alloc_type(std::move(__a)), _Vector_impl_data(std::move(__rv))
+	{ }
+#endif
+  };
+
 public:
   typedef _Alloc allocator_type;
 
   _Tp_alloc_type&
   _M_get_Tp_allocator() _GLIBCXX_NOEXCEPT
-  { return *static_cast<_Tp_alloc_type*>(&this->_M_impl); }
+  { return this->_M_impl; }
 
   const _Tp_alloc_type&
   _M_get_Tp_allocator() const _GLIBCXX_NOEXCEPT
-  { return *static_cast(&this->_M_impl); }
+  { return this->_M_impl; }
 
   allocator_type
   get_allocator() const _GLIBCXX_NOEXCEPT
   { return allocator_type(_M_get_Tp_allocator()); }
 
-  _Vector_base()
-  : _M_impl() { }
+#if __cplusplus >= 201103L
+  _Vector_base() = default;
+#else
+  _Vector_base() { }
+#endif
 
   _Vector_base(const allocator_type& __a) _GLIBCXX_NOEXCEPT
   : _M_impl(__a) { }
 
-  _Vector_base(size_t __n)
-  : _M_impl()
-  { _M_create_storage(__n); }
-
   _Vector_base(size_t __n, const allocator_type& __a)
   : _M_impl(__a)
   { _M_create_storage(__n); }
 
 #if __cplusplus >= 201103L
-  _Vector_base(_Tp_alloc_type&& __a) noexcept
-  : _M_impl(std::move(__a)) { }
-
-  _Vector_base(_Vector_base&& __x) noexcept
-  : _M_impl(std::move(__x._M_get_Tp_allocator()))
-  { this->_M_impl._M_swap_data(__x._M_impl); }
+  _Vector_base(_Vector_base&&) = default;
 
   _Vector_base(_Vector_base&& __x, const allocator_type& __a)
-  : _M_impl(__a)
-  {
-	if (__x.get_allocator() == __a)
-	  this->_M_impl._M_swap_data(__x._M_impl);
-	else
-	  {
-	size_t __n = __x._M_impl._M_finish - __x._M_impl._M_start;
-	_M_create_storage(__n);
-	  }
-  }
+  : _M_impl(std::move(__x._M_impl), _Tp_alloc_type(__a))
+  { }
 #endif
 
   ~_Vector_base() _GLIBCXX_NOEXCEPT
@@ -379,11 +385,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /**
*  @brief  Creates a %vector with no elements.
*/
-  vector()
 #if __cplusplus >= 201103L
-  noexcept(is_nothrow_default_constructible<_Alloc>::value)
+  vector() = default;
+#else
+  vector() { }
 #endif
-  : _Base() { }
 
   /**
*  @brief  Creates a %vector with no elements.

[PING][PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

[Denis Khalikov]

Hello,
this is a ping for that patch
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00022.html

Thanks.

[patch, libfortran] Fix PR 80365, undefined memcpy

[Thomas Koenig]

Hello world,

the attached test cases fixes a problematic invocation of
memcpy where src=NULL and n=0 by simply doing nothing
in the surrounding function if there is nothing to be done.

No test case, because this only shows up with a sanitized
libgfortran or under a debugger.

OK for trunk?

Regards

Thomas

2017-07-23  Thomas Koenig  

* io/unix.c (buf_write):  Return early if there is
nothing to write.
Index: io/unix.c
===
--- io/unix.c	(Revision 249936)
+++ io/unix.c	(Arbeitskopie)
@@ -582,6 +582,9 @@
 static ssize_t
 buf_write (unix_stream *s, const void *buf, ssize_t nbyte)
 {
+  if (nbyte == 0)
+return 0;
+
   if (s->ndirty == 0)
 s->buffer_offset = s->logical_offset;
 

Re: [patch, fortran] Fix another dependency check for reallocation on assignment

[Jerry DeLisle]

On 07/23/2017 04:27 AM, Thomas Koenig wrote:
> Hello world,
> 
> in PR 66102, I found a patch by Mikael which has never been applied.
> After dusting it off, finding that it looks reasonable and fixes
> the test case in question I'd like to apply this.
> 
> Regression-tested. OK for trunk?
> 

OK, thanks.

Jerry

Re: [PATCH] New C++ warning option '-Wduplicated-access-specifiers'

[Volker Reichelt]

On 21 Jul, Martin Sebor wrote:
> On 07/20/2017 10:35 AM, Volker Reichelt wrote:
>> Hi,
>>
>> the following patch introduces a new C++ warning option
>> -Wduplicated-access-specifiers that warns about redundant
>> access-specifiers in classes, e.g.
>>
>>   class B
>>   {
>> public:
>>   B();
>>
>> private:
>>   void foo();
>> private:
>>   int i;
>>   };
> 
> I'm very fond of warnings that help find real bugs, or even that
> provide an opportunity to review code for potential problems or
> inefficiencies and suggest a possibility to improve it in some
> way (make it clearer, or easier for humans or compilers to find
> real bugs in, or faster, etc.), even if the code isn't strictly
> incorrect.
> 
> In this case I'm having trouble coming up with an example where
> the warning would have this effect.  What do you have in mind?
> (Duplicate access specifiers tend to crop up in large classes
> and/or as a result of preprocessor conditionals.)

This warning fights the "tend to crop up" effect that clutters the
code. After some time these redundant access specifiers creep in
and make your code harder to read. If I see something like

  ...
void foo() const;

  private:
void bar();
  ...

on the screen I tend to think that 'foo' has a different access
level than bar. If that's not the case because the access-specifier
is redundant, then that's just confusing and distracting.
The warning helps to maintain readability of your code.

The benefit might not be big, but the warning comes at relatively
low cost. It passes a location around through the class stack and
checks less than a handful of tokens.

My personal motivation to implement this warning was the fact that
I changed a big Qt application suite from Qt's legacy SIGNAL-SLOT
mechanism to the new function pointer syntax of Qt5. In the old
version you had to mark slots in the following fashion:

  public slots:
void foo();
void bar();

But now you can use any function making the 'slots' macro obsolete.
Therefore I ended up with hundreds of redundant access-specifiers
which this warning helped to clean up. Doing this sort of thing in the
compiler with a proper parser is way safer than to write some script
to achieve this.

Btw, the SonarAnalyzer also provides this warning to clean up code:

https://sonarcloud.io/organizations/default/rules#rule_key=cpp%3AS3539

> Btw., there are examples of poor coding practices where I can
> imagine a warning focused on access specifiers being helpful.
> For instance, a class whose member functions maintain non-trivial
> invariants among its data members should declare the data private
> to prevent clients from inadvertently breaking those invariants.
> A specific example might be a container class (like string or
> vector) that owns the block of memory it allocates.  A warning
> that detected when such members are publicly accessible could
> help improve encapsulation.  I suspect this would be challenging
> to implement and would likely require some non-trivial analysis
> in the middle end.

That's way beyond the scope of what my warning is trying to achieve.

> Another example is a class that defines an inaccessible member
> that isn't used (e.g., class A { int i; }; that Clang detects
> with -Wunused-private-field; or class A { void f () { } };).
> I would expect this to be doable in the front end.

That's indeed a nice warning, too.

> Martin

Regards,
Volker

Re: [PATCH] New C++ warning option '-Wduplicated-access-specifiers'

[Volker Reichelt]

On 21 Jul, David Malcolm wrote:
> On Fri, 2017-07-21 at 19:58 +0200, Volker Reichelt wrote:
>> On 21 Jul, David Malcolm wrote:
>> > On Thu, 2017-07-20 at 18:35 +0200, Volker Reichelt wrote:
>> >> Hi,
>> >> 
>> >> the following patch introduces a new C++ warning option
>> >> -Wduplicated-access-specifiers that warns about redundant
>> >> access-specifiers in classes, e.g.
>> >> 
>> >>   class B
>> >>   {
>> >> public:
>> >>   B();
>> >> 
>> >> private:
>> >>   void foo();
>> >> private:
>> >>   int i;
>> >>   };
>> >> 
>> >> test.cc:8:5: warning: duplicate 'private' access-specifier [
>> >> -Wduplicated-access-specifiers]
>> >>  private:
>> >>  ^~~
>> >>  ---
>> >> test.cc:6:5: note: access-specifier was previously given here
>> >>  private:
>> >>  ^~~

{...snip...]

>> > If you're going to implement a fix-it hint for this, there should
>> be a
>> > test case that tests it (probably as a separate file, e.g.
>> Wduplicated
>> > -access-specifiers-2.C, to allow for the extra option -
>> -fdiagnostics
>> > -show-caret, covering just one instance of the diagnostic firing,
>> for
>> > simplicity).
>> 
>> I actually did try that, but dejagnu somehow gets confused.
>> To me it looks like the reason for this is that both multi-line
>> messages
>> are so similar. I'll give it a second try, though.
> 
> I'm not sure what you mean by "both" multi-line messages; shouldn't
> there be just one multi-line message for the fix-it hint.
> 
> Isn't this like e.g. g++.dg/cpp0x/auto1.C ?  (an example of a testcase
> that verifies a deletion fix-it hint)
> 
> Dave

There are two multi-line messages. One for the warning and one for the
note, see the example above the "[...snip...]". The message after the
note consists of the first two lines of the message after the warning.
This seems to confuse dejagnu. However, I managed to work around this
problem. I'll post an updated patch soon.

Regards,
Volker

[PATCH v2] New C++ warning option '-Waccess-specifiers'

[Volker Reichelt]

Hi again,

here is an updated patch for a new warning about redundant
access-specifiers. It takes Dave's various comments into account.

The main changes w.r.t. to the previous versions are:

* The warning is now a two-level warning with a slightly shorter name:
  -Waccess-specifiers=1, -Waccess-specifiers=2
  with -Waccess-specifiers defaulting to -Waccess-specifiers=1.
* The warning now checks for 3 different scenarios, see testcase
  Waccess-specifiers-2.C below:
  A) Two consecutive access-specifiers, so that the first one
 has no effect. (This is new.)
  B) Two (non-consecutive) equal access-specifiers.
 (That's what the original patch checked.)
  C) An access-specifier that does not change the class-type's default.
 (That's what I only suggested in the original patch.)
  The first two tests are enabled in level 1, the last in level 2.
* The warning is now in a separate function.
* The fix-it hints now include the colon after the access-specifier.
* There's a testcase for the fix-it hints.

What's missing from Dave's comments are some examples for invoke.texi.
I'll work on that once the warning made it into the trunk.

The switch statement in cp_parser_maybe_warn_access_specifier is a little
bit ugly. It would be nicer to emit the warnings directly next to the
checks. But then I'd have to write the code for the fix-it hint 3 times.
With C++11 I'd use a lambda for this, but with C++03 I hope the switch
is OK.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK for trunk?

Regards,
Volker


2017-07-22  Volker Reichelt  

* doc/invoke.texi (-Waccess-specifiers, -Waccess-specifiers=):
Document new warning options.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 250356)
+++ gcc/doc/invoke.texi (working copy)
@@ -259,7 +259,8 @@
 @xref{Warning Options,,Options to Request or Suppress Warnings}.
 @gccoptlist{-fsyntax-only  -fmax-errors=@var{n}  -Wpedantic @gol
 -pedantic-errors @gol
--w  -Wextra  -Wall  -Waddress  -Waggregate-return  @gol
+-w  -Wextra  -Wall  -Waccess-specifiers  -Waccess-specifiers=@var{n} @gol
+-Waddress  -Waggregate-return  @gol
 -Walloc-zero  -Walloc-size-larger-than=@var{n}
 -Walloca  -Walloca-larger-than=@var{n} @gol
 -Wno-aggressive-loop-optimizations  -Warray-bounds  -Warray-bounds=@var{n} @gol
@@ -5254,6 +5255,13 @@
 Warn about overriding virtual functions that are not marked with the override
 keyword.
 
+@item -Waccess-specifiers @r{(C++ and Objective-C++ only)}
+@itemx -Waccess-specifiers=@var{n}
+@opindex Wno-access-specifiers
+@opindex Waccess-specifiers
+Warn when an access-specifier is redundant because it was already given
+before.
+
 @item -Walloc-zero
 @opindex Wno-alloc-zero
 @opindex Walloc-zero
===


2017-07-22  Volker Reichelt  

* c.opt (Waccess-specifiers=): New C++ warning flag.
(Waccess-specifiers): New alias.

Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt  (revision 250443)
+++ gcc/c-family/c.opt  (working copy)
@@ -476,6 +476,14 @@
 C ObjC C++ ObjC++ Var(warn_div_by_zero) Init(1) Warning
 Warn about compile-time integer division by zero.
 
+Waccess-specifiers
+C++ ObjC++ Warning Alias(Waccess-specifiers=, 1, 0)
+Warn about redundant access-specifiers.
+
+Waccess-specifiers=
+C++ ObjC++ Var(warn_access_specifiers) Warning Joined RejectNegative UInteger
+Warn about redundant access-specifiers.
+
 Wduplicated-branches
 C ObjC C++ ObjC++ Var(warn_duplicated_branches) Init(0) Warning
 Warn about duplicated branches in if-else statements.
===


2017-07-22  Volker Reichelt  

* cp-tree.h (struct saved_scope): New access_specifier_loc variable.
(current_access_specifier_loc): New macro.
* class.c (struct class_stack_node): New access_loc variable.
(pushclass): Push current_access_specifier_loc.  Set new
initial value.
(popclass): Pop current_access_specifier_loc.
* parser.c (cp_parser_maybe_warn_access_specifier): New function
to warn about duplicated access-specifiers.
(cp_parser_member_specification_opt): Call it.  Set
current_access_specifier_loc.

Index: gcc/cp/class.c
===
--- gcc/cp/class.c  (revision 250443)
+++ gcc/cp/class.c  (working copy)
@@ -60,6 +60,7 @@
   /* The access specifier pending for new declarations in the scope of
  this class.  */
   tree access;
+  location_t access_loc;
 
   /* If were defining TYPE, the names used in this class.  */
   splay_tree names_used;
@@ -7724,6 +7725,7 @@
   csn->name = current_class_name;
   csn->type = current_class_type;
   csn->access = current_access_specifier;
+  csn->access_loc = current_access_specifier_loc;
   csn->names_used = 0;
   csn

Re: [PATCH v2] New C++ warning option '-Waccess-specifiers'

[Eric Gallager]

On 7/23/17, Volker Reichelt  wrote:
> Hi again,
>
> here is an updated patch for a new warning about redundant
> access-specifiers. It takes Dave's various comments into account.
>
> The main changes w.r.t. to the previous versions are:
>
> * The warning is now a two-level warning with a slightly shorter name:
>   -Waccess-specifiers=1, -Waccess-specifiers=2
>   with -Waccess-specifiers defaulting to -Waccess-specifiers=1.

Just a more generalized comment as a user, but I don't really like
this trend that new warning options are so often given numeric levels
these days. A warning option with different levels requires special
handling in configure scripts or Makefiles, which is harder than just
toggling different names (i.e. how things work without numeric
levels).

> * The warning now checks for 3 different scenarios, see testcase
>   Waccess-specifiers-2.C below:
>   A) Two consecutive access-specifiers, so that the first one
>  has no effect. (This is new.)
>   B) Two (non-consecutive) equal access-specifiers.
>  (That's what the original patch checked.)
>   C) An access-specifier that does not change the class-type's default.
>  (That's what I only suggested in the original patch.)
>   The first two tests are enabled in level 1, the last in level 2.

Instead of levels, I'd prefer A and B to be in an option like the
original -Wduplicate-access-specifiers, while putting C under a
separate name like -Wdefault-access-specifiers. This way they can be
toggled individually, so for example I can get just warning C without
also getting warnings A and B. Using numeric levels makes that
impossible. But that's just my personal preference for how to separate
them, so feel free to disregard me.

> * The warning is now in a separate function.
> * The fix-it hints now include the colon after the access-specifier.
> * There's a testcase for the fix-it hints.
>
> What's missing from Dave's comments are some examples for invoke.texi.
> I'll work on that once the warning made it into the trunk.
>
> The switch statement in cp_parser_maybe_warn_access_specifier is a little
> bit ugly. It would be nicer to emit the warnings directly next to the
> checks. But then I'd have to write the code for the fix-it hint 3 times.
> With C++11 I'd use a lambda for this, but with C++03 I hope the switch
> is OK.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu.
> OK for trunk?
>
> Regards,
> Volker
>
>
> 2017-07-22  Volker Reichelt  
>
>   * doc/invoke.texi (-Waccess-specifiers, -Waccess-specifiers=):
>   Document new warning options.
>
> Index: gcc/doc/invoke.texi
> ===
> --- gcc/doc/invoke.texi   (revision 250356)
> +++ gcc/doc/invoke.texi   (working copy)
> @@ -259,7 +259,8 @@
>  @xref{Warning Options,,Options to Request or Suppress Warnings}.
>  @gccoptlist{-fsyntax-only  -fmax-errors=@var{n}  -Wpedantic @gol
>  -pedantic-errors @gol
> --w  -Wextra  -Wall  -Waddress  -Waggregate-return  @gol
> +-w  -Wextra  -Wall  -Waccess-specifiers  -Waccess-specifiers=@var{n} @gol
> +-Waddress  -Waggregate-return  @gol
>  -Walloc-zero  -Walloc-size-larger-than=@var{n}
>  -Walloca  -Walloca-larger-than=@var{n} @gol
>  -Wno-aggressive-loop-optimizations  -Warray-bounds  -Warray-bounds=@var{n}
> @gol
> @@ -5254,6 +5255,13 @@
>  Warn about overriding virtual functions that are not marked with the
> override
>  keyword.
>
> +@item -Waccess-specifiers @r{(C++ and Objective-C++ only)}
> +@itemx -Waccess-specifiers=@var{n}
> +@opindex Wno-access-specifiers
> +@opindex Waccess-specifiers
> +Warn when an access-specifier is redundant because it was already given
> +before.
> +
>  @item -Walloc-zero
>  @opindex Wno-alloc-zero
>  @opindex Walloc-zero
> ===
>
>
> 2017-07-22  Volker Reichelt  
>
>   * c.opt (Waccess-specifiers=): New C++ warning flag.
>   (Waccess-specifiers): New alias.
>
> Index: gcc/c-family/c.opt
> ===
> --- gcc/c-family/c.opt(revision 250443)
> +++ gcc/c-family/c.opt(working copy)
> @@ -476,6 +476,14 @@
>  C ObjC C++ ObjC++ Var(warn_div_by_zero) Init(1) Warning
>  Warn about compile-time integer division by zero.
>
> +Waccess-specifiers
> +C++ ObjC++ Warning Alias(Waccess-specifiers=, 1, 0)
> +Warn about redundant access-specifiers.
> +
> +Waccess-specifiers=
> +C++ ObjC++ Var(warn_access_specifiers) Warning Joined RejectNegative
> UInteger
> +Warn about redundant access-specifiers.
> +
>  Wduplicated-branches
>  C ObjC C++ ObjC++ Var(warn_duplicated_branches) Init(0) Warning
>  Warn about duplicated branches in if-else statements.
> ===
>
>
> 2017-07-22  Volker Reichelt  
>
>   * cp-tree.h (struct saved_scope): New access_specifier_loc variable.
>   (current_access_specifier_loc): New macro.
>   * class.c (struct class_st

Re: [PATCH v2] New C++ warning option '-Waccess-specifiers'

[Volker Reichelt]

On 23 Jul, Eric Gallager wrote:
> On 7/23/17, Volker Reichelt  wrote:
>> Hi again,
>>
>> here is an updated patch for a new warning about redundant
>> access-specifiers. It takes Dave's various comments into account.
>>
>> The main changes w.r.t. to the previous versions are:
>>
>> * The warning is now a two-level warning with a slightly shorter name:
>>   -Waccess-specifiers=1, -Waccess-specifiers=2
>>   with -Waccess-specifiers defaulting to -Waccess-specifiers=1.
> 
> Just a more generalized comment as a user, but I don't really like
> this trend that new warning options are so often given numeric levels
> these days. A warning option with different levels requires special
> handling in configure scripts or Makefiles, which is harder than just
> toggling different names (i.e. how things work without numeric
> levels).

Fair point.

>> * The warning now checks for 3 different scenarios, see testcase
>>   Waccess-specifiers-2.C below:
>>   A) Two consecutive access-specifiers, so that the first one
>>  has no effect. (This is new.)
>>   B) Two (non-consecutive) equal access-specifiers.
>>  (That's what the original patch checked.)
>>   C) An access-specifier that does not change the class-type's default.
>>  (That's what I only suggested in the original patch.)
>>   The first two tests are enabled in level 1, the last in level 2.
> 
> Instead of levels, I'd prefer A and B to be in an option like the
> original -Wduplicate-access-specifiers, while putting C under a
> separate name like -Wdefault-access-specifiers. This way they can be
> toggled individually, so for example I can get just warning C without
> also getting warnings A and B. Using numeric levels makes that
> impossible. But that's just my personal preference for how to separate
> them, so feel free to disregard me.

What I like about the numeric levels is that they are easier to
remember. You don't have to look up different names.
OTOH, toggling on C without A+B might really make sense here.

But I'd like to get some more opinions before I change that.

Regards,
Volker

Re: [PATCH] New C++ warning option '-Wduplicated-access-specifiers'

[Martin Sebor]

On 07/23/2017 02:42 PM, Volker Reichelt wrote:

On 21 Jul, Martin Sebor wrote:

On 07/20/2017 10:35 AM, Volker Reichelt wrote:

Hi,

the following patch introduces a new C++ warning option
-Wduplicated-access-specifiers that warns about redundant
access-specifiers in classes, e.g.

  class B
  {
public:
  B();

private:
  void foo();
private:
  int i;
  };


I'm very fond of warnings that help find real bugs, or even that
provide an opportunity to review code for potential problems or
inefficiencies and suggest a possibility to improve it in some
way (make it clearer, or easier for humans or compilers to find
real bugs in, or faster, etc.), even if the code isn't strictly
incorrect.

In this case I'm having trouble coming up with an example where
the warning would have this effect.  What do you have in mind?
(Duplicate access specifiers tend to crop up in large classes
and/or as a result of preprocessor conditionals.)


This warning fights the "tend to crop up" effect that clutters the
code. After some time these redundant access specifiers creep in
and make your code harder to read. If I see something like

  ...
void foo() const;

  private:
void bar();
  ...

on the screen I tend to think that 'foo' has a different access
level than bar. If that's not the case because the access-specifier
is redundant, then that's just confusing and distracting.
The warning helps to maintain readability of your code.

The benefit might not be big, but the warning comes at relatively
low cost. It passes a location around through the class stack and
checks less than a handful of tokens.

My personal motivation to implement this warning was the fact that
I changed a big Qt application suite from Qt's legacy SIGNAL-SLOT
mechanism to the new function pointer syntax of Qt5. In the old
version you had to mark slots in the following fashion:

  public slots:
void foo();
void bar();

But now you can use any function making the 'slots' macro obsolete.
Therefore I ended up with hundreds of redundant access-specifiers
which this warning helped to clean up. Doing this sort of thing in the
compiler with a proper parser is way safer than to write some script
to achieve this.


Okay, thanks for clarifying that.  I think what's distracting to
one could be helpful to another.  For example, it's not uncommon
for classes with many members to use redundant access specifiers
to group blocks of related declarations.  Or, in a class with many
lines of comments (e.g., Doxygen), repeating the access specifier
every so often could be seen as helpful because otherwise there
would be no way to tell what its access is without scrolling up
or down.  It's debatable what approach to dealing with this is
best.  Java, for instance, requires every non-public member to
be declared with its own access specifier.  Some other languages
(I think D) do as well.  An argument could be made that that's
a far clearer style than using the specifier only when changing
access.  It seems to me that the most suitable approach will be
different from one project to another, if not from one person to
another.  A diagnostic that recommends a particular style (or that
helps with a specific kind of a project like the one you did for
Qt) might be a good candidate for a plugin, but enshrining any
one style (or a solution to a project-specific problem) in GCC
as a general-purpose warning doesn't seem appropriate or in line
with the definition of warnings in GCC:

  constructions that are not inherently erroneous but that are
  risky or suggest there may have been an error

Martin

PS There are other redundancies that some might say unnecessarily
clutter code.  For instance, declaring a symbol static in
an unnamed namespace, or explicitly declaring a member function
inline that's also defined within the body of a class, or
explicitly declaring a function virtual that overrides one
declared in a base class.  None of these is diagnosed, and I'd
say for good reason: they are all benign and do not suggest any
sort of a coding mistake or present an opportunity for improvement.
In fact, warning for some of them (especially the virtual function)
might even be detrimental


Btw, the SonarAnalyzer also provides this warning to clean up code:

https://sonarcloud.io/organizations/default/rules#rule_key=cpp%3AS3539


Thanks, that's an interesting data point.

Martin




Btw., there are examples of poor coding practices where I can
imagine a warning focused on access specifiers being helpful.
For instance, a class whose member functions maintain non-trivial
invariants among its data members should declare the data private
to prevent clients from inadvertently breaking those invariants.
A specific example might be a container class (like string or
vector) that owns the block of memory it allocates.  A warning
that detected when such members are publicly accessible could
help improve encapsulation.  I suspect this would be challenging
to implement and wo

[committed] Always assume NetBSD provides __cxa_atexit

[Krister Walfridsson]

I have committed the attached patch to remove checks for obsolete NetBSD 
releases from the 1990s that do not provide __cxa_atexit.


Bootstrapped and tested on i386-unknown-netbsdelf6.1 and
x86_64-unknown-netbsd6.1.

   /Krister


2017-07-23  Krister Walfridsson  

* config.gcc (*-*-netbsd*): Remove check for NetBSD versions not
having __cxa_atexit.Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 250465)
+++ gcc/config.gcc  (revision 250466)
@@ -798,14 +798,7 @@
   case ${enable_threads} in
 "" | yes | posix) thread_file='posix' ;;
   esac
-
-  # NetBSD 2.0 and later provide __cxa_atexit(), which we use by
-  # default (unless overridden by --disable-__cxa_atexit).
-  case ${target} in
-*-*-netbsd[2-9]* | *-*-netbsdelf[2-9]*)
-  default_use_cxa_atexit=yes
-  ;;
-  esac
+  default_use_cxa_atexit=yes
   ;;
 *-*-openbsd*)
   tmake_file="t-openbsd"

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 08/08 V2

[Jeff Law]

On 07/21/2017 07:23 AM, Andreas Krebbel wrote:
> Hi,
> 
> I've used your patch as the base and applied my changes on top.  The
> attached patch is the result, so it is supposed to replace your
> version.  It now also supports emitting a runtime loop.
> 
> It bootstraps fine but unfortunately I see an Ada regression which I
> haven't tracked down yet.
> 
>> FAIL: cb1010a
>> FAIL: gnat.dg/stack_check1.adb execution test
>> FAIL: gnat.dg/stack_check1.adb execution test
Ugh.  The s390 I'm using doesn't have Ada installed, nor is there a
usable version I can reasonably install.

I'm still reasonably  confident this regression is a result of my
defining STACK_CHECK_STATIC_BUILTIN which was needed in earlier versions
of the kit but shouldn't be needed anymore.

Your patches are definitely a step forward.   Thanks again!

jeff

[PATCH] RTEMS: Add GCC Runtime Library Exception

[Sebastian Huber]

gcc/

PR libgcc/61152
* aarch64/rtems.h: Add GCC Runtime Library Exception.  Format
changes.
* arm/rtems.h: Likewise.
* bfin/rtems.h: Likewise.
* i386/rtemself.h: Likewise.
* lm32/rtems.h: Likewise.
* m32c/rtems.h: Likewise.
* m68k/rtemself.h: Likewise.
* microblaze/rtems.h: Likewise.
* mips/rtems.h: Likewise.
* moxie/rtems.h: Likewise.
* nios2/rtems.h: Likewise.
* powerpcspe/rtems.h: Likewise.
* rs6000/rtems.h: Likewise.
* rtems.h: Likewise.
* sh/rtems.h: Likewise.
* sh/rtemself.h: Likewise.
* sparc/rtemself.h: Likewise.
---
 gcc/config/aarch64/rtems.h| 17 +++--
 gcc/config/arm/rtems.h| 17 +++--
 gcc/config/bfin/rtems.h   | 29 +
 gcc/config/i386/rtemself.h| 29 +
 gcc/config/lm32/rtems.h   | 29 +
 gcc/config/m32c/rtems.h   | 29 +
 gcc/config/m68k/rtemself.h| 29 +
 gcc/config/microblaze/rtems.h | 29 +
 gcc/config/mips/rtems.h   | 29 +
 gcc/config/moxie/rtems.h  | 29 +
 gcc/config/nios2/rtems.h  | 35 ---
 gcc/config/powerpcspe/rtems.h |  9 +++--
 gcc/config/rs6000/rtems.h |  9 +++--
 gcc/config/rtems.h| 40 
 gcc/config/sh/rtems.h | 29 +
 gcc/config/sh/rtemself.h  | 29 +
 gcc/config/sparc/rtemself.h   | 29 +
 17 files changed, 263 insertions(+), 183 deletions(-)

diff --git a/gcc/config/aarch64/rtems.h b/gcc/config/aarch64/rtems.h
index b48e28afda0..07c5679d5c1 100644
--- a/gcc/config/aarch64/rtems.h
+++ b/gcc/config/aarch64/rtems.h
@@ -1,20 +1,25 @@
 /* Definitions for RTEMS based AARCH64 system.
Copyright (C) 2016-2017 Free Software Foundation, Inc.
- 
+
This file is part of GCC.
- 
+
GCC is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published
by the Free Software Foundation; either version 3, or (at your
option) any later version.
- 
+
GCC is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
License for more details.
- 
-   You should have received a copy of the GNU General Public License
-   along with GCC; see the file COPYING3.  If not see
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
 #define HAS_INIT_SECTION
diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
index b34bbe8a063..77eb32c1d20 100644
--- a/gcc/config/arm/rtems.h
+++ b/gcc/config/arm/rtems.h
@@ -1,20 +1,25 @@
 /* Definitions for RTEMS based ARM systems using EABI.
Copyright (C) 2011-2017 Free Software Foundation, Inc.
- 
+
This file is part of GCC.
- 
+
GCC is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published
by the Free Software Foundation; either version 3, or (at your
option) any later version.
- 
+
GCC is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
License for more details.
- 
-   You should have received a copy of the GNU General Public License
-   along with GCC; see the file COPYING3.  If not see
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
 #define HAS_INIT_SECTION
diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
index 440e886..f70573507dd 100644
--- a/gcc/config/bfin/rtems.h
+++ b/gcc/config/bfin/rtems.h
@@ -2,21 +2,26 @@
Copyright (C) 2006-2017 Free Software Foundation, Inc.
Contributed by Ralf Corsépius (ralf.corsep...@rtems.org).
 
-This file is part of GCC.
+   T