[wwwdocs] Rotate news

2017-01-28 Thread Gerald Pfeifer
Trim to focus on things that happened in the last year, 15 months.

I will note that in the last period we mostly had release announcements, 
so DO NOT BE SHY, we surely have quite a bit more to talk about. :-)

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1038
diff -u -r1.1038 index.html
--- index.html  20 Jan 2017 13:55:31 -  1.1038
+++ index.html  28 Jan 2017 22:49:09 -
@@ -81,36 +81,6 @@
 [2015-12-04]
 
 
-GCC 5.2 released
-[2015-07-16]
-
-
-GCC 4.9.3 released
-[2015-06-26]
-
-
-GCC 4.8.5 released
-[2015-06-23]
-
-
-GCC 5.1 released
-[2015-04-22]
-
-
-MIPS Release 6 architecture support
- [2015-01-20]
- Support for MIPS Release 6 (r6) has been contributed by Imagination
- Technologies.
-
-OpenMP 4.0 offloading support in GCC
- [2015-01-14]
- http://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf";>
- OpenMP 4.0 https://gcc.gnu.org/gcc-5/changes.html#offload";>
- offloading support was added to GCC.
- Contributed by Jakub Jelinek (Red Hat), Bernd Schmidt and
- Thomas Schwinge (CodeSourcery), Andrey Turetskiy,
- Ilya Verbin and Kirill Yukhin (Intel).
-
 
 
 
Index: news.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v
retrieving revision 1.154
diff -u -r1.154 news.html
--- news.html   29 Dec 2016 23:21:54 -  1.154
+++ news.html   28 Jan 2017 22:49:09 -
@@ -14,6 +14,36 @@
 
 
 
+GCC 5.2 released
+[2015-07-16]
+
+
+GCC 4.9.3 released
+[2015-06-26]
+
+
+GCC 4.8.5 released
+[2015-06-23]
+
+
+GCC 5.1 released
+[2015-04-22]
+
+
+MIPS Release 6 architecture support
+ [2015-01-20]
+ Support for MIPS Release 6 (r6) has been contributed by Imagination
+ Technologies.
+
+OpenMP 4.0 offloading support in GCC
+ [2015-01-14]
+ http://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf";>
+ OpenMP 4.0 https://gcc.gnu.org/gcc-5/changes.html#offload";>
+ offloading support was added to GCC.
+ Contributed by Jakub Jelinek (Red Hat), Bernd Schmidt and
+ Thomas Schwinge (CodeSourcery), Andrey Turetskiy,
+ Ilya Verbin and Kirill Yukhin (Intel).
+
 Intel Skylake Server AVX-512 extensions support
  [2015-01-14]
  New ISA extensions support



Contents of PO file 'cpplib-7.1-b20170101.eo.po'

2017-01-28 Thread Translation Project Robot


cpplib-7.1-b20170101.eo.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.



New Esperanto PO file for 'cpplib' (version 7.1-b20170101)

2017-01-28 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Esperanto team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/eo.po

(This file, 'cpplib-7.1-b20170101.eo.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.




[wwwdocs] rsync.html - rsync.samba.org now uses https

2017-01-28 Thread Gerald Pfeifer
For an earlier test, http even failed (instead of redirecting),
but in any case, https appears to be the new standard for that
site.

Applied.

Gerald

Index: rsync.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/rsync.html,v
retrieving revision 1.20
diff -u -r1.20 rsync.html
--- rsync.html  2 Jan 2011 20:10:48 -   1.20
+++ rsync.html  28 Jan 2017 22:31:03 -
@@ -10,7 +10,7 @@
 GCC: Anonymous read-only rsync access
 
 We are offering our SVN repository and various other data like our FTP
-site through anonymous http://rsync.samba.org";>rsync.
+site through anonymous https://rsync.samba.org";>rsync.
 
 That way you can make local copies of the GCC SVN repository to ease
 the burden on the GCC main site, and browse the source locally.


[wwwdocs] remove gcc-uk.internet.bs from mirrors.html

2017-01-28 Thread Gerald Pfeifer
>From all I can tell gcc-uk.internet.bs has not been reachable for
quite a while, and while in theory it may be limited to UK Internet
clients, a mirror that is not reachable from Austrian nor German
nor US IP addresses (including the system it mirrors) likely is
dead, so I applied the patch below

i...@internet.bs, can you confirm?

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.237
diff -u -r1.237 mirrors.html
--- mirrors.html14 Aug 2016 16:06:14 -  1.237
+++ mirrors.html28 Jan 2017 22:25:09 -
@@ -46,7 +46,6 @@
 The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan 
Cristiaan van Winkel (jc at ATComputing.nl)
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (admin at 2600.sk)
 UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/,
 thanks to mirror at mirrorservice.org
-UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to 
Internet.bs (info at internet.bs)
 US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to admin 
at netgull.com
 US:
   http://mirrors-usa.go-parts.com/gcc/";>http://mirrors-usa.go-parts.com/gcc


[wwwdocs] projects/cxx-status.html -- fix link to N3928

2017-01-28 Thread Gerald Pfeifer
Usually individual issues of WG21 are stored as HTML files, but
N3928 is a PDF file (and may have been for a longer time).

Jason, just FYI, since I believe you originally added this.

I went ahead and applied the obvious fix.

Gerald

Index: projects/cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.38
diff -u -r1.38 cxx-status.html
--- projects/cxx-status.html9 Jan 2017 21:51:54 -   1.38
+++ projects/cxx-status.html28 Jan 2017 22:19:50 -
@@ -97,7 +97,7 @@
 
 
Extending static_assert 
-  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.html";>N3928
 
+  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf";>N3928
 
   6
__cpp_static_assert >= 201411 
 


RE: [wwwdocs] benchmarks/ -- cp2k.berlios.de/gfortran/ seems gone?

2017-01-28 Thread Gerald Pfeifer
On Mon, 23 Jan 2017, VandeVondele  Joost wrote:
> cp2k moved to https://www.cp2k.org/ , but isn't running a nightly gcc 
> trunk tester anymore. So, yes, patch is OK, unfortunately.

Thanks, Joost.  I applied this patch now.

Gerald


Re: [PATCH, wwwdocs, committed] Update gcc-7/changes.html for LRA

2017-01-28 Thread Gerald Pfeifer
On Mon, 19 Sep 2016, Segher Boessenkool wrote:
> I'm committing the following for changes-7.html

Thanks!

> Index: htdocs/gcc-7/changes.html
> ===
> +  GCC now uses LRA by default for new targets.

> +  The PowerPC port now uses LRA by default.

All of us (on this list) know what LRA is, why this is a good
change, etc.

Since our release notes in changes.html are also consumed by
users and media, would it make sense to provide a little more
color?

I applied the patch below, but there may be more we could do?

Gerald

Index: gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.46
diff -u -r1.46 changes.html
--- gcc-7/changes.html  28 Jan 2017 01:15:53 -  1.46
+++ gcc-7/changes.html  28 Jan 2017 21:50:24 -
@@ -25,8 +25,8 @@
 
 Caveats
 
-  GCC now uses https://gcc.gnu.org/wiki/LRAIsDefault";>LRA by
-  default for new targets.
+  GCC now uses https://gcc.gnu.org/wiki/LRAIsDefault";>LRA (a
+  new local register allocator) by default for new targets.
 
   The non-standard C++0x type traits
   has_trivial_default_constructor,


[committed] Skip gnat.dg/trampoline4.adb on hppa

2017-01-28 Thread John David Anglin
We have function descriptors.

Dave
--
John David Anglin   dave.ang...@bell.net


2017-01-28  John David Anglin  

* gnat.dg/trampoline4.adb: Skip on hppa*-*-*.

Index: gnat.dg/trampoline4.adb
===
--- gnat.dg/trampoline4.adb (revision 245009)
+++ gnat.dg/trampoline4.adb (working copy)
@@ -1,6 +1,6 @@
 -- { dg-do compile { target *-*-linux* } }
 -- { dg-options "-ftrampolines -gnatws" }
--- { dg-skip-if "standard descriptors" { ia64-*-* powerpc64-*-* } }
+-- { dg-skip-if "standard descriptors" { hppa*-*-* ia64-*-* powerpc64-*-* } }
 
 procedure Trampoline4 is
 


[PATCH/VECT/AARCH64] Improve cost model for ThunderX2 CN99xx

2017-01-28 Thread Andrew Pinski
Hi,
  On some (most) AARCH64 cores, it is not always profitable to
vectorize some integer loops.  This patch does two things (I can split
it into different patches if needed).
1) It splits the aarch64 back-end's vector cost model's vector and
scalar costs into int and fp fields
1a) For thunderx2t99, models correctly the integer vector/scalar costs.
2) Fixes/Improves a few calls to record_stmt_cost in tree-vect-loop.c
where stmt_info was not being passed.

OK?  Bootstrapped and tested on aarch64-linux-gnu and provides 20% on
libquantum and ~1% overall on SPEC CPU 2006 int.

Thanks,
Andrew Pinski

ChangeLog:
* tree-vect-loop.c (vect_compute_single_scalar_iteration_cost): Pass
stmt_info to record_stmt_cost.
(vect_get_known_peeling_cost): Pass stmt_info if known to record_stmt_cost.

* config/aarch64/aarch64-protos.h (cpu_vector_cost): Split
cpu_vector_cost field into
scalar_int_stmt_cost and scalar_fp_stmt_cost.  Split vec_stmt_cost
field into vec_int_stmt_cost and vec_fp_stmt_cost.
* config/aarch64/aarch64.c (generic_vector_cost): Update for the
splitting of scalar_stmt_cost and vec_stmt_cost.
(thunderx_vector_cost): Likewise.
(cortexa57_vector_cost): LIkewise.
(exynosm1_vector_cost): Likewise.
(xgene1_vector_cost): Likewise.
(thunderx2t99_vector_cost): Improve after the splitting of the two fields.
(aarch64_builtin_vectorization_cost): Update for the splitting of
scalar_stmt_cost and vec_stmt_cost.
Index: config/aarch64/aarch64-protos.h
===
--- config/aarch64/aarch64-protos.h (revision 245002)
+++ config/aarch64/aarch64-protos.h (working copy)
@@ -151,11 +151,17 @@ struct cpu_regmove_cost
 /* Cost for vector insn classes.  */
 struct cpu_vector_cost
 {
-  const int scalar_stmt_cost;   /* Cost of any scalar operation,
+  const int scalar_int_stmt_cost;   /* Cost of any int scalar operation,
+   excluding load and store.  */
+  const int scalar_fp_stmt_cost;/* Cost of any fp scalar operation,
excluding load and store.  */
   const int scalar_load_cost;   /* Cost of scalar load.  */
   const int scalar_store_cost;  /* Cost of scalar store.  */
-  const int vec_stmt_cost;  /* Cost of any vector operation,
+  const int vec_int_stmt_cost;  /* Cost of any int vector operation,
+   excluding load, store, permute,
+   vector-to-scalar and
+   scalar-to-vector operation.  */
+  const int vec_fp_stmt_cost;   /* Cost of any fp vector operation,
excluding load, store, permute,
vector-to-scalar and
scalar-to-vector operation.  */
Index: config/aarch64/aarch64.c
===
--- config/aarch64/aarch64.c(revision 245002)
+++ config/aarch64/aarch64.c(working copy)
@@ -365,10 +365,12 @@ static const struct cpu_regmove_cost thu
 /* Generic costs for vector insn classes.  */
 static const struct cpu_vector_cost generic_vector_cost =
 {
-  1, /* scalar_stmt_cost  */
+  1, /* scalar_int_stmt_cost  */
+  1, /* scalar_fp_stmt_cost  */
   1, /* scalar_load_cost  */
   1, /* scalar_store_cost  */
-  1, /* vec_stmt_cost  */
+  1, /* vec_int_stmt_cost  */
+  1, /* vec_fp_stmt_cost  */
   2, /* vec_permute_cost  */
   1, /* vec_to_scalar_cost  */
   1, /* scalar_to_vec_cost  */
@@ -383,10 +385,12 @@ static const struct cpu_vector_cost gene
 /* ThunderX costs for vector insn classes.  */
 static const struct cpu_vector_cost thunderx_vector_cost =
 {
-  1, /* scalar_stmt_cost  */
+  1, /* scalar_int_stmt_cost  */
+  1, /* scalar_fp_stmt_cost  */
   3, /* scalar_load_cost  */
   1, /* scalar_store_cost  */
-  4, /* vec_stmt_cost  */
+  4, /* vec_int_stmt_cost  */
+  4, /* vec_fp_stmt_cost  */
   4, /* vec_permute_cost  */
   2, /* vec_to_scalar_cost  */
   2, /* scalar_to_vec_cost  */
@@ -401,10 +405,12 @@ static const struct cpu_vector_cost thun
 /* Generic costs for vector insn classes.  */
 static const struct cpu_vector_cost cortexa57_vector_cost =
 {
-  1, /* scalar_stmt_cost  */
+  1, /* scalar_int_stmt_cost  */
+  1, /* scalar_fp_stmt_cost  */
   4, /* scalar_load_cost  */
   1, /* scalar_store_cost  */
-  2, /* vec_stmt_cost  */
+  2, /* vec_int_stmt_cost  */
+  2, /* vec_fp_stmt_cost  */
   3, /* vec_permute_cost  */
   8, /* vec_to_scalar_cost  */
   8, /* scalar_to_vec_cost  */
@@ -418,10 +424,12 @@ static const struct cpu_vector_cost cort
 
 static const struct cpu_vector_cost exynosm1_vector_cost =
 {
-  1, /* scalar_stmt_cost  */
+  1, /* scalar_int_stmt_cost  */
+  1, /* scalar_fp_stmt_cost  */
   5, /* scalar_load_cost  */
   1, /* scalar_store_cost  */
-  3, /* vec_stmt_cost  */
+  3, /* vec_int_s

[PATCH, i386]: Use REGNO instead of true_regnum in print_reg

2017-01-28 Thread Uros Bizjak
Using true_regnum to determine register number at insn output time is
just giant waste of cycles. For sure, we have only hard regs here.

2017-01-27  Uros Bizjak  

* config/i386/i386.c (print_reg): Use REGNO instead of true_regnum.

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

Committed to mainline SVN as obvious one-liner.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 245003)
+++ config/i386/i386.c  (working copy)
@@ -17592,7 +17592,7 @@ print_reg (rtx x, int code, FILE *file)
   else
 msize = GET_MODE_SIZE (GET_MODE (x));
 
-  regno = true_regnum (x);
+  regno = REGNO (x);
 
   gcc_assert (regno != ARG_POINTER_REGNUM
  && regno != FRAME_POINTER_REGNUM


New French PO file for 'gcc' (version 7.1-b20170101)

2017-01-28 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators.  The file is available at:

http://translationproject.org/latest/gcc/fr.po

(This file, 'gcc-7.1-b20170101.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.




[committed] Fix g++.old-deja/g++.abi/vtable2.C on hppa

2017-01-28 Thread John David Anglin
On hppa, the function pointers used in vtables point to function descriptors.  
In order for  CMP_VPTR
to work, we need to extract the actual function address from the function 
descriptor.  On linux, we further
need to canonicalize the function pointer due to the lazy binding of function 
descriptors.

Tested on hppa-unknown-linux-gnu, hhpa2.0w-hp-hpux11.11 and 
hppa64-hp-hpux11.11.  Committed
to trunk and gcc-6 branch.

Dave
--
John David Anglin   dave.ang...@bell.net


2017-01-28  John David Anglin  

PR testsuite/70583
* g++.old-deja/g++.abi/vtable2.C: Adjust CMP_VPTR define on hppa.

Index: g++.old-deja/g++.abi/vtable2.C
===
--- g++.old-deja/g++.abi/vtable2.C  (revision 244960)
+++ g++.old-deja/g++.abi/vtable2.C  (working copy)
@@ -142,10 +142,24 @@
 #define INC_VDATA(A,N) ((A) += 2*(N))
 #endif
 #else
+// HPPA uses function pointers but they point to function descriptors.
+#if defined __hppa__
+#ifdef __hpux__
+#ifdef _LP64
+#define CMP_VPTR(A, B) (*(unsigned long *)(*(A)+16) == *(unsigned long 
*)((unsigned long)(B)+16))
+#else
 #define CMP_VPTR(A, B) (*(A) == (ptrdiff_t)(B))
+#endif /* _LP64 */
+#else
+extern "C" { unsigned int __canonicalize_funcptr_for_compare (void*); }
+#define CMP_VPTR(A, B) (__canonicalize_funcptr_for_compare(*(void **)A) == 
__canonicalize_funcptr_for_compare((void *)B))
+#endif /* __hpux__ */
+#else
+#define CMP_VPTR(A, B) (*(A) == (ptrdiff_t)(B))
+#endif /* __hppa__ */
 #define INC_VPTR(A)((A) += 1)
 #define INC_VDATA(A,N) ((A) += (N))
-#endif
+#endif /* __ia64__ */
 
 int main ()
 {


[committed] Skip gnat.dg/debug7.adb and gnat.dg/debug9.adb on hppa*-*-hpux*

2017-01-28 Thread John David Anglin
The 32-bit hppa*-*-hpux* does not support dwarf debugging.  Gnat is not 
supported on 64-bit hpux.

Dave
--
John David Anglin   dave.ang...@bell.net


2017-01-28  John David Anglin  

* gnat.dg/debug7.adb: Skip on hppa*-*-hpux*.
* gnat.dg/debug9.adb: Likewise.

Index: gnat.dg/debug7.adb
===
--- gnat.dg/debug7.adb  (revision 244960)
+++ gnat.dg/debug7.adb  (working copy)
@@ -1,4 +1,5 @@
 -- { dg-do compile }
+-- { dg-skip-if "No dwarf-2 support" { hppa*-*-hpux* } "*" "" }
 -- { dg-options "-cargs -gdwarf-2 -gstrict-dwarf -dA -margs" }
 -- { dg-final { scan-assembler "DW_TAG_imported_decl" } }
 
Index: gnat.dg/debug9.adb
===
--- gnat.dg/debug9.adb  (revision 244960)
+++ gnat.dg/debug9.adb  (working copy)
@@ -7,6 +7,7 @@
 --  some hackish way to check that types are output in the proper context (i.e.
 --  at global or local scope).
 --
+--  { dg-skip-if "No dwarf-4 support" { hppa*-*-hpux* } "*" "" }
 --  { dg-options "-cargs -gdwarf-4 -fdebug-types-section -dA -margs" }
 --  { dg-final { scan-assembler-times "\\(DIE \\(0x\[a-f0-9\]*\\) 
DW_TAG_type_unit\\)" 0 } }
 


[committed] Add -fno-common option to gcc.dg/torture/pr78515.c on hppa*-*-hpux*

2017-01-28 Thread John David Anglin
Another test where we need to avoid the limited alignment of common on 
hppa*-*-hpux*.
Committed to trunk.

Dave
--
John David Anglin   dave.ang...@bell.net


2017-01-28  John David Anglin  

* gcc.dg/torture/pr78515.c: Add -fno-common option on hppa*-*-hpux*.

Index: gcc.dg/torture/pr78515.c
===
--- gcc.dg/torture/pr78515.c(revision 244960)
+++ gcc.dg/torture/pr78515.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-additional-options "-Wno-psabi" } */
 /* { dg-additional-options "-mavx512bw" { target x86_64-*-* i?86-*-* } } */
+/* { dg-additional-options "-fno-common" { target hppa*-*-hpux* } } */
 
 typedef unsigned V __attribute__ ((vector_size (64)));
 


[committed] Link various gfortran tests against libatomic when available

2017-01-28 Thread John David Anglin
The attached change fixes these fortran tests on hppa-hpux.  We need to 
explicitly link against libatomic.
Committed to trunk.

Dave
--
John David Anglin   dave.ang...@bell.net


2017-01-28  John David Anglin  

* gfortran.dg/coarray_41.f90: Add "-latomic" option if
libatomic_available.
* gfortran.dg/coarray_42.f90: Likewise.
* gfortran.dg/coarray_alloc_comp_3.f08: Likewise.
* gfortran.dg/coarray_alloc_comp_4.f08: Likewise.
* gfortran.dg/coarray_lib_alloc_4.f90: Likewise.

Index: gfortran.dg/coarray_41.f90
===
--- gfortran.dg/coarray_41.f90  (revision 244960)
+++ gfortran.dg/coarray_41.f90  (working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
 
 program coarray_41
 
Index: gfortran.dg/coarray_42.f90
===
--- gfortran.dg/coarray_42.f90  (revision 244960)
+++ gfortran.dg/coarray_42.f90  (working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fdump-tree-original -fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
 
 program Jac
   type Domain
Index: gfortran.dg/coarray_alloc_comp_3.f08
===
--- gfortran.dg/coarray_alloc_comp_3.f08(revision 244960)
+++ gfortran.dg/coarray_alloc_comp_3.f08(working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
 !
 ! Contributed by Andre Vehreschild
 ! Check that manually freeing components does not lead to a runtime crash,
Index: gfortran.dg/coarray_alloc_comp_4.f08
===
--- gfortran.dg/coarray_alloc_comp_4.f08(revision 244960)
+++ gfortran.dg/coarray_alloc_comp_4.f08(working copy)
@@ -1,5 +1,6 @@
 ! { dg-do compile }
 ! { dg-options "-fcoarray=lib -fdump-tree-original" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
 !
 ! Contributed by Andre Vehreschild
 ! Check that sub-components are caf_deregistered and not freed.
Index: gfortran.dg/coarray_lib_alloc_4.f90
===
--- gfortran.dg/coarray_lib_alloc_4.f90 (revision 244960)
+++ gfortran.dg/coarray_lib_alloc_4.f90 (working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fcoarray=lib -lcaf_single -fdump-tree-original" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
 !
 ! Allocate/deallocate with libcaf.
 !


New Spanish PO file for 'gcc' (version 7.1-b20170101)

2017-01-28 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/es.po

(This file, 'gcc-7.1-b20170101.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.