[patch] Document value of __cplusplus for C++14

[Jonathan Wakely]

Committed to trunk as obvious.

Should it go on gcc-5-branch too?

commit b06d72cb9f0b5fa3f052afaca99393658095624d
Author: Jonathan Wakely 
Date:   Sat Oct 3 01:28:01 2015 +0100

Document value of __cplusplus for C++14

	* doc/cpp.texi (Standard Predefined Macros): Document value of
	__cplusplus for C++14.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 118ba7c..7718d14 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -1925,10 +1925,13 @@ This macro is defined when the C++ compiler is in use.  You can use
 @code{__cplusplus} to test whether a header is compiled by a C compiler
 or a C++ compiler.  This macro is similar to @code{__STDC_VERSION__}, in
 that it expands to a version number.  Depending on the language standard
-selected, the value of the macro is @code{199711L}, as mandated by the
-1998 C++ standard; @code{201103L}, per the 2011 C++ standard; an
-unspecified value strictly larger than @code{201103L} for the experimental 
-languages enabled by @option{-std=c++1y} and @option{-std=gnu++1y}.
+selected, the value of the macro is
+@code{199711L} for the 1998 C++ standard,
+@code{201103L} for the 2011 C++ standard,
+@code{201402L} for the 2014 C++ standard,
+or an unspecified value strictly larger than @code{201402L} for the
+experimental languages enabled by @option{-std=c++1z} and
+@option{-std=gnu++1z}.
 
 @item __OBJC__
 This macro is defined, with value 1, when the Objective-C compiler is in

Re: [PATCH] Clarify __atomic_compare_exchange_n docs

[Jonathan Wakely]

Here's the latest version of the patch, including the typo fix.

commit 96468d6b7e782501459bad306b31d45bc0ba5155
Author: Jonathan Wakely 
Date:   Sat Oct 3 13:59:47 2015 +0100

Clarify __atomic_compare_exchange effects

	* doc/extend.texi (__atomic Builtins): Clarify compare_exchange
	effects.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 8406945..599ad87 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9353,17 +9353,18 @@ This compares the contents of @code{*@var{ptr}} with the contents of
 @code{*@var{expected}}. If equal, the operation is a @emph{read-modify-write}
 operation that writes @var{desired} into @code{*@var{ptr}}.  If they are not
 equal, the operation is a @emph{read} and the current contents of
-@code{*@var{ptr}} is written into @code{*@var{expected}}.  @var{weak} is true
-for weak compare_exchange, and false for the strong variation.  Many targets 
+@code{*@var{ptr}} are written into @code{*@var{expected}}.  @var{weak} is true
+for weak compare_exchange, which may fail spuriously, and false for
+the strong variation, which never fails spuriously.  Many targets 
 only offer the strong variation and ignore the parameter.  When in doubt, use
 the strong variation.
 
-True is returned if @var{desired} is written into
-@code{*@var{ptr}} and the operation is considered to conform to the
+If @var{desired} is written into @code{*@var{ptr}} then true is returned
+and memory is affected according to the
 memory order specified by @var{success_memorder}.  There are no
 restrictions on what memory order can be used here.
 
-False is returned otherwise, and the operation is considered to conform
+Otherwise, false is returned and memory is affected according
 to @var{failure_memorder}. This memory order cannot be
 @code{__ATOMIC_RELEASE} nor @code{__ATOMIC_ACQ_REL}.  It also cannot be a
 stronger order than that specified by @var{success_memorder}.
@@ -9470,7 +9471,7 @@ alignment.  A value of 0 indicates typical alignment should be used.  The
 compiler may also ignore this parameter.
 
 @smallexample
-if (_atomic_always_lock_free (sizeof (long long), 0))
+if (__atomic_always_lock_free (sizeof (long long), 0))
 @end smallexample
 
 @end deftypefn

[patch] Update template instantiation documentation

[Jonathan Wakely]

https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html
currently says that using -frepo "is your best option for application
code written for the Borland model, as it just works."

That was true at one point, but as can be seen from the mentions of
binutils 2.8 and Solaris 2, the information there is pretty old.

Since then -frepo has bitrotted occasionally, and it's much simpler to
rely on implicit instantiations in COMDAT sections, controlling
specific instantiations with explicit instantiations if needed (using
'extern template' which was standardised in C++11).

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910#c2 for an
example of bitrot (now fixed) and people being persuaded by the docs
that -frepo is the best option.

So this revises the docs, to downplay the usefulness of -frepo,
and to endorse the "do nothing" model (with selective explicit
instantations as needed).

It also changes another mention of -frepo to use a different C++-only
option, to further de-emphasize -frepo.

OK for trunk?
commit b115ee74b5aa8cf7e191456b609fa14bb6890e3d
Author: Jonathan Wakely 
Date:   Mon Sep 1 15:50:24 2014 +0100

Update template instantiation documentation

	* doc/extend.texi (Template Instantiation): Stop implying -frepo is
	the best option.
	* doc/invoke.texi (C++ Dialect Options): Use -fstrict-enums in
	example instead of -frepo.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 8406945..6c19682 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -19574,8 +19574,8 @@ If any calls are not inlined, you will get linker errors.
 @section Where's the Template?
 @cindex template instantiation
 
-C++ templates are the first language feature to require more
-intelligence from the environment than one usually finds on a UNIX
+C++ templates were the first language feature to require more
+intelligence from the environment than was traditionally found on a UNIX
 system.  Somehow the compiler and linker have to make sure that each
 template instance occurs exactly once in the executable if it is needed,
 and not at all otherwise.  There are two basic approaches to this
@@ -19588,7 +19588,7 @@ equivalent of common blocks to their linker; the compiler emits template
 instances in each translation unit that uses them, and the linker
 collapses them together.  The advantage of this model is that the linker
 only has to consider the object files themselves; there is no external
-complexity to worry about.  This disadvantage is that compilation time
+complexity to worry about.  The disadvantage is that compilation time
 is increased because the template code is being compiled repeatedly.
 Code written for this model tends to include definitions of all
 templates in the header file, since they must be seen to be
@@ -19633,7 +19633,7 @@ those instantiations and rebuild any affected object files.  The
 link-time overhead is negligible after the first pass, as the compiler
 continues to place the instantiations in the same files.
 
-This is your best option for application code written for the Borland
+This can be a suitable option for application code written for the Borland
 model, as it just works.  Code written for the Cfront model 
 needs to be modified so that the template definitions are available at
 one or more points of instantiation; usually this is as simple as adding
@@ -19701,8 +19701,21 @@ static template class Foo;
 Do nothing.  Pretend G++ does implement automatic instantiation
 management.  Code written for the Borland model works fine, but
 each translation unit contains instances of each of the templates it
-uses.  In a large program, this can lead to an unacceptable amount of code
-duplication.
+uses.  The duplicate instances will be discarded by the linker, but in
+a large program, this can lead to an unacceptable amount of code
+duplication in object files or shared libraries.
+
+Duplicate instances can be avoided by selective use of explicit
+instantiation declarations (using the @code{extern template} syntax
+described above) and explicit instantiation definitions for individual
+instances. Explicit instantiations can be used for the largest or most
+frequently duplicated instances, without having to know exactly which
+other instances are used in the rest of the program.
+
+This is the simplest option, but also offers flexibility and
+fine-grained control when necessary. It is also the most portable
+alternative and programs using this approach will work with most modern
+compilers.
 @end enumerate
 
 @node Bound member functions
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3a9594c..8819c02 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2085,11 +2085,11 @@ regardless of what language your program is in.  For example, you
 might compile a file @file{firstClass.C} like this:
 
 @smallexample
-g++ -g -frepo -O -c firstClass.C
+g++ -g -fstrict-enums -O -c firstClass.C
 @end smallexample
 
 

Re: [PATCH, i386, AVX-512] Update extract_even_odd w/ AVX-512BW insns.

[Dominique d'Humières]

Kirill,

The new tests fail on x86_64-apple-darwin14:

FAIL: gcc.target/i386/vect-pack-trunc-1.c (test for excess errors)
UNRESOLVED: gcc.target/i386/vect-pack-trunc-1.c compilation failed to produce 
executable
FAIL: gcc.target/i386/vect-pack-trunc-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/vect-pack-trunc-2.c compilation failed to produce 
executable
FAIL: gcc.target/i386/vect-perm-even-1.c (test for excess errors)
UNRESOLVED: gcc.target/i386/vect-perm-even-1.c compilation failed to produce 
executable
FAIL: gcc.target/i386/vect-perm-odd-1.c (test for excess errors)
UNRESOLVED: gcc.target/i386/vect-perm-odd-1.c compilation failed to produce 
executable
FAIL: gcc.target/i386/vect-unpack-1.c (test for excess errors)
UNRESOLVED: gcc.target/i386/vect-unpack-1.c compilation failed to produce 
executable
FAIL: gcc.target/i386/vect-unpack-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/vect-unpack-2.c compilation failed to produce 
executable

I think the tests should be protected with

/* { dg-require-effective-target avx512bw } */

Note also that the options '-fno-diagnostics-show-caret 
-fdiagnostics-color=never -O2’ are not obeyed:

^[[1mvect-pack-trunc-1.s:67:2: ^[[0;1;31merror: ^[[0m^[[1minstruction requires: 
AVX-512 ISA
^[[0mvmovdqa64   LC0-L1$pb(%ebx), %zmm0
^[[0;1;32m^
^[[0m^[[1mvect-pack-trunc-1.s:68:2: ^[[0;1;31merror: ^[[0m^[[1minstruction 
requires: AVX-512 ISA
^[[0mvmovdqa64   LC1-L1$pb(%ebx), %zmm4
^[[0;1;32m^
…

Dominique

[PATCH] 2015-10-02 Benedikt Huber <benedikt.hu...@theobroma-systems.com> Philipp Tomsich <philipp.toms...@theobroma-systems.com>

[Benedikt Huber]

* config/aarch64/aarch64-builtins.c: Builtins for rsqrt and
rsqrtf.
* config/aarch64/aarch64-protos.h: Declare.
* config/aarch64/aarch64-simd.md: Matching expressions for
frsqrte and frsqrts.
* config/aarch64/aarch64-tuning-flags.def: Added
MRECIP_DEFAULT_ENABLED.
* config/aarch64/aarch64.c: New functions. Emit rsqrt
estimation code in fast math mode.
* config/aarch64/aarch64.md: Added enum entries.
* config/aarch64/aarch64.opt: Added options -mrecip and
-mlow-precision-recip-sqrt.
* testsuite/gcc.target/aarch64/rsqrt-asm-check.c: Assembly scans
for frsqrte and frsqrts
* testsuite/gcc.target/aarch64/rsqrt.c: Functional tests for rsqrt.

Signed-off-by: Philipp Tomsich 
---
 gcc/ChangeLog  |  19 
 gcc/config/aarch64/aarch64-builtins.c  | 112 
 gcc/config/aarch64/aarch64-protos.h|   3 +
 gcc/config/aarch64/aarch64-simd.md |  27 +
 gcc/config/aarch64/aarch64-tuning-flags.def|   1 +
 gcc/config/aarch64/aarch64.c   | 115 -
 gcc/config/aarch64/aarch64.md  |   3 +
 gcc/config/aarch64/aarch64.opt |   4 +
 gcc/doc/invoke.texi|  12 +++
 .../gcc.target/aarch64/rsqrt-asm-check_1.c |  65 
 gcc/testsuite/gcc.target/aarch64/rsqrt_1.c | 111 
 11 files changed, 467 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/rsqrt-asm-check_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/rsqrt_1.c

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c8200db..7226f29 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,22 @@
+2015-10-02  Benedikt Huber  
+   Philipp Tomsich  
+
+   * config/aarch64/aarch64-builtins.c: Builtins for rsqrt and
+   rsqrtf.
+   * config/aarch64/aarch64-protos.h: Declare.
+   * config/aarch64/aarch64-simd.md: Matching expressions for
+   frsqrte and frsqrts.
+   * config/aarch64/aarch64-tuning-flags.def: Added
+   RECIP_SQRT.
+   * config/aarch64/aarch64.c: New functions.  Emit rsqrt
+   estimation code in fast math mode.
+   * config/aarch64/aarch64.md: Added enum entries.
+   * config/aarch64/aarch64.opt: Added options -mrecip and
+   -mlow-precision-recip-sqrt.
+   * testsuite/gcc.target/aarch64/rsqrt-asm-check.c: Assembly scans
+   for frsqrte and frsqrts
+   * testsuite/gcc.target/aarch64/rsqrt.c: Functional tests for rsqrt.
+
 2015-10-01  Lynn Boger  
 
PR target/66870
diff --git a/gcc/config/aarch64/aarch64-builtins.c 
b/gcc/config/aarch64/aarch64-builtins.c
index 80916a9..29cfbf5 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -344,6 +344,11 @@ enum aarch64_builtins
   AARCH64_BUILTIN_GET_FPSR,
   AARCH64_BUILTIN_SET_FPSR,
 
+  AARCH64_BUILTIN_RSQRT_DF,
+  AARCH64_BUILTIN_RSQRT_SF,
+  AARCH64_BUILTIN_RSQRT_V2DF,
+  AARCH64_BUILTIN_RSQRT_V2SF,
+  AARCH64_BUILTIN_RSQRT_V4SF,
   AARCH64_SIMD_BUILTIN_BASE,
   AARCH64_SIMD_BUILTIN_LANE_CHECK,
 #include "aarch64-simd-builtins.def"
@@ -842,6 +847,46 @@ aarch64_init_crc32_builtins ()
 }
 }
 
+/* Add builtins for reciprocal square root.  */
+
+void
+aarch64_add_builtin_rsqrt (void)
+{
+  tree fndecl = NULL;
+  tree ftype = NULL;
+
+  tree V2SF_type_node = build_vector_type (float_type_node, 2);
+  tree V2DF_type_node = build_vector_type (double_type_node, 2);
+  tree V4SF_type_node = build_vector_type (float_type_node, 4);
+
+  ftype = build_function_type_list (double_type_node, double_type_node,
+   NULL_TREE);
+  fndecl = add_builtin_function ("__builtin_aarch64_rsqrt_df",
+ftype, AARCH64_BUILTIN_RSQRT_DF, BUILT_IN_MD, NULL, NULL_TREE);
+  aarch64_builtin_decls[AARCH64_BUILTIN_RSQRT_DF] = fndecl;
+
+  ftype = build_function_type_list (float_type_node, float_type_node,
+   NULL_TREE);
+  fndecl = add_builtin_function ("__builtin_aarch64_rsqrt_sf",
+ftype, AARCH64_BUILTIN_RSQRT_SF, BUILT_IN_MD, NULL, NULL_TREE);
+  aarch64_builtin_decls[AARCH64_BUILTIN_RSQRT_SF] = fndecl;
+
+  ftype = build_function_type_list (V2DF_type_node, V2DF_type_node, NULL_TREE);
+  fndecl = add_builtin_function ("__builtin_aarch64_rsqrt_v2df",
+ftype, AARCH64_BUILTIN_RSQRT_V2DF, BUILT_IN_MD, NULL, NULL_TREE);
+  aarch64_builtin_decls[AARCH64_BUILTIN_RSQRT_V2DF] = fndecl;
+
+  ftype = build_function_type_list (V2SF_type_node, V2SF_type_node, NULL_TREE);
+  fndecl = add_builtin_function ("__builtin_aarch64_rsqrt_v2sf",
+ftype, AARCH64_BUILTIN_RSQRT_V2SF, BUILT_IN_MD, NULL, NULL_TREE);
+  

[PATCH v6][aarch64] Implemented reciprocal square root (rsqrt) estimation in -ffast-math

[Benedikt Huber]

This sixth revision of the patch:
 * Cleans up style issues.
 * Makes test conform to standards.

Ok for check in.

Benedikt Huber (1):
  2015-10-02  Benedikt Huber  
Philipp Tomsich  

 gcc/ChangeLog  |  19 
 gcc/config/aarch64/aarch64-builtins.c  | 112 
 gcc/config/aarch64/aarch64-protos.h|   3 +
 gcc/config/aarch64/aarch64-simd.md |  27 +
 gcc/config/aarch64/aarch64-tuning-flags.def|   1 +
 gcc/config/aarch64/aarch64.c   | 115 -
 gcc/config/aarch64/aarch64.md  |   3 +
 gcc/config/aarch64/aarch64.opt |   4 +
 gcc/doc/invoke.texi|  12 +++
 .../gcc.target/aarch64/rsqrt-asm-check_1.c |  65 
 gcc/testsuite/gcc.target/aarch64/rsqrt_1.c | 111 
 11 files changed, 467 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/rsqrt-asm-check_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/rsqrt_1.c

-- 
1.9.1

Re: [PATCH] xtensa: add uclinux support

[augustine.sterl...@gmail.com]

On Wed, Sep 30, 2015 at 8:23 AM, Max Filippov  wrote:
> 2015-09-30  Max Filippov  
> gcc/
> * config.gcc (xtensa*-*-uclinux*): New configuration.
> * config/xtensa/uclinux.h: New file.
> * config/xtensa/uclinux.opt: New file.
>
> libgcc/
> * config.host (xtensa*-*-uclinux*): New configuration.

Approved, please apply.

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

[Mikael Morin]

Le 02/10/2015 18:44, Steve Kargl a écrit :

On Fri, Oct 02, 2015 at 11:28:06AM +0200, Mikael Morin wrote:

Le 01/10/2015 18:30, Steve Kargl a écrit :

The call-stmt in the code is the start of an execution-construct
A common-stmt is not allowed in an execution-construct.  At
least, that's how I intepret the BNF in 2.1 of F2008.


The error message appears too soon, before we finish parsing the common
statement.  If it's delayed, as with the following additional patch, the
common statements is properly rejected:

common_24.f:10:72:

 COMMON /FMCOM / XX(80 000 000) ! { dg-error "conflicts with
COMMON" }
  1
Error: Unexpected COMMON statement at (1)
common_24.f:8:72:

Error: PROCEDURE attribute conflicts with COMMON attribute in ???xx??? at (1)

This needs a little more polishing (location missing in the second error
message), then let's see how the testsuite likes it.



While I prefer the first error message above, if it requires
too much polish, then at least commit your first patch to cure
the ICE.  We can worry about polish later.

I have finally managed to find a patch that doesn't regress in the 
testsuite.


The gfc_add_in_common call in gfc_match_common is delayed after the 
array spec handling and without return value check, so that errors are 
ignored.  Another gfc_add_in_common call is necessary to report errors 
again during resolution.  This is patch number 2.
The error location for the second call is grabbed from the common block 
struct, which is made accessible in the function by patch number 1.


No regression on x86-unknown-linux-gnu, OK for trunk?

Mikael

2015-10-02  Mikael Morin  

	* resolve.c (resolve_common_vars): Move access to the common
	block's head symbol inside the function.
	(resolve_common_blocks, resolve_types): Update callers.
	  
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 7363e06..582c3f9 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -912,9 +912,9 @@ resolve_entries (gfc_namespace *ns)
 
 /* Resolve common variables.  */
 static void
-resolve_common_vars (gfc_symbol *sym, bool named_common)
+resolve_common_vars (gfc_common_head *common_block, bool named_common)
 {
-  gfc_symbol *csym = sym;
+  gfc_symbol *csym = common_block->head;
 
   for (; csym; csym = csym->common_next)
 {
@@ -972,7 +972,7 @@ resolve_common_blocks (gfc_symtree *common_root)
   if (common_root->right)
 resolve_common_blocks (common_root->right);
 
-  resolve_common_vars (common_root->n.common->head, true);
+  resolve_common_vars (common_root->n.common, true);
 
   /* The common name is a global name - in Fortran 2003 also if it has a
  C binding name, since Fortran 2008 only the C binding name is a global
@@ -15202,7 +15202,7 @@ resolve_types (gfc_namespace *ns)
 
   resolve_entries (ns);
 
-  resolve_common_vars (ns->blank_common.head, false);
+  resolve_common_vars (>blank_common, false);
   resolve_common_blocks (ns->common_root);
 
   resolve_contained_functions (ns);


2015-10-02  Mikael Morin  

	PR fortran/67758
	* match.c (gfc_match_common): Delay the common_block pointer
	assignment after error checking.
	Delay the call to gfc_add_in_common attribute after the handling
	of array specs.
	* resolve.c (resolve_common_vars): Call gfc_add_in_common again.

2015-10-02  Mikael Morin  

	PR fortran/67758
	* gfortran.dg/common_24.f: New.

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 523e9b2..a63c731 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -4330,10 +4330,6 @@ gfc_match_common (void)
 	  if (m == MATCH_NO)
 	goto syntax;
 
-  /* Store a ref to the common block for error checking.  */
-  sym->common_block = t;
-  sym->common_block->refs++;
-
   /* See if we know the current common block is bind(c), and if
  so, then see if we can check if the symbol is (which it'll
  need to be).  This can happen if the bind(c) attr stmt was
@@ -4376,8 +4372,8 @@ gfc_match_common (void)
 		goto cleanup;
 	}
 
-	  if (!gfc_add_in_common (>attr, sym->name, NULL))
-	goto cleanup;
+	  sym->common_block = t;
+	  sym->common_block->refs++;
 
 	  if (tail != NULL)
 	tail->common_next = sym;
@@ -4416,6 +4412,10 @@ gfc_match_common (void)
 
 	}
 
+	  /* Add the in_common attribute, but ignore the reported errors
+	 if any, and continue matching.  */
+	  gfc_add_in_common (>attr, sym->name, NULL);
+
 	  sym->common_head = t;
 
 	  /* Check to see if the symbol is already in an equivalence group.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 582c3f9..6e61250 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -918,6 +918,12 @@ resolve_common_vars (gfc_common_head *common_block, bool named_common)
 
   for (; csym; csym = csym->common_next)
 {
+  /* gfc_add_in_common may have been 

[patch] fix warnings in gcc.target/arm/pr67756.c

[Bernd Edlinger]

Hi,

this fixes a test suite fall out for pr67756.

committed as r22844.


Index: gcc/testsuite/gcc.target/arm/pr67756.c
===
--- gcc/testsuite/gcc.target/arm/pr67756.c    (Revision 228444)
+++ gcc/testsuite/gcc.target/arm/pr67756.c    (Arbeitskopie)
@@ -2,6 +2,8 @@
 /* { dg-require-effective-target arm_hard_vfp_ok } */
 /* { dg-options "-O2 -mapcs -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" } 
*/
 
+int inode_permission (), try_break_deleg ();
+int mutex_lock (), mutex_unlock ();
 struct mutex
 {
 };
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog    (Revision 228444)
+++ gcc/testsuite/ChangeLog    (Arbeitskopie)
@@ -1,3 +1,7 @@
+2015-10-03  Bernd Edlinger  
+
+    * gcc.target/arm/pr67756.c: Fixed warnings.
+
 2015-10-02  Marek Polacek  
 
     PR c/67730

  

[patch] Two tiny libstdc++ cleanups

[Jonathan Wakely]

This fixes some misleading comments (getenv isn't used in those files)
and removes pretty-printer support for experimental::any objects that
use allocators, as the allocator feature was removed from the TS and
dropped in r218709 before it was included in a GCC release.

Tested powerpc64le-linux, committed to trunk.


commit f1c83d9bbd77d4c22b22051b409efbe12968d653
Author: Jonathan Wakely 
Date:   Sat Oct 3 00:56:55 2015 +0100

Remove pretty printing for 'any' with allocators

	* python/libstdcxx/v6/printers.py (StdExpAnyPrinter): Remove support
	for _Manager_alloc.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 2d16786..12e732e 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -945,10 +945,6 @@ class StdExpAnyPrinter(SingleObjContainerPrinter):
 valptr = self.val['_M_storage']['_M_buffer'].address
 elif '::_Manager_external' in mgrname:
 valptr = self.val['_M_storage']['_M_ptr']
-elif '::_Manager_alloc' in mgrname:
-datatype = gdb.lookup_type(mgrname + '::_Data')
-valptr = self.val['_M_storage']['_M_ptr'].cast(datatype.pointer())
-valptr = valptr.dereference()['_M_data'].address
 else:
 raise ValueError("Unknown manager function in std::experimental::any")
 contained_value = valptr.cast(self.contained_type.pointer()).dereference()

commit 934867ab0ab9b2648ce89daa43012bd3c8190e01
Author: Jonathan Wakely 
Date:   Sat Oct 3 00:49:29 2015 +0100

Fix comments saying why headers are included

	* src/c++98/locale.cc: Fix comment.
	* src/c++98/locale_init.cc: Likewise.

diff --git a/libstdc++-v3/src/c++98/locale.cc b/libstdc++-v3/src/c++98/locale.cc
index 1c29a56..3395c93 100644
--- a/libstdc++-v3/src/c++98/locale.cc
+++ b/libstdc++-v3/src/c++98/locale.cc
@@ -23,7 +23,6 @@
 #define _GLIBCXX_USE_CXX11_ABI 1
 #include 
 #include 
-#include  // For getenv
 #include 
 #include  // For towupper, etc.
 #include 
diff --git a/libstdc++-v3/src/c++98/locale_init.cc b/libstdc++-v3/src/c++98/locale_init.cc
index 0a95b9f..be7fd90 100644
--- a/libstdc++-v3/src/c++98/locale_init.cc
+++ b/libstdc++-v3/src/c++98/locale_init.cc
@@ -23,7 +23,7 @@
 #define _GLIBCXX_USE_CXX11_ABI 1
 #include 
 #include 
-#include  // For getenv, free.
+#include  // For free.
 #include 
 #include  // For towupper, etc.
 #include 

Re: Possible patch for fortran/65766

[Dominique d'Humières]

AFAICT this patch has been approved by FX at 
https://gcc.gnu.org/ml/fortran/2015-07/msg00168.html. Any reason to not commit 
it?

Dominique

Re: [patch committed SH] Fix PR target/67716

[Oleg Endo]

On Tue, 2015-09-29 at 14:39 +0900, Kaz Kojima wrote:
> I've committed the attached patch to fix PR target/67716.  It
> implements targetm.override_options_after_change for SH.  Tested
> on sh4-unknown-linux-gnu.

I've committed this to GCC 5 branch as r228449.
Tested briefly on sh-elf with "make all".

Cheers,
Oleg


> 
> Regards,
>   kaz
> --
> 2015-09-29  Kaz Kojima  
> 
>   PR target/67716
>   * config/sh/sh.c (sh_override_options_after_change): New.
>   (TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): Define.
>   (sh_option_override): Move align_loops, align_jumps and
> align_functions handling into sh_override_options_after_change.
> 
> diff --git a/config/sh/sh.c b/config/sh/sh.c
> index b203258..16fb575 100644
> --- a/config/sh/sh.c
> +++ b/config/sh/sh.c
> @@ -202,6 +202,7 @@ static bool noncall_uses_reg (rtx, rtx_insn *, rtx *);
>  static rtx_insn *gen_block_redirect (rtx_insn *, int, int);
>  static void sh_reorg (void);
>  static void sh_option_override (void);
> +static void sh_override_options_after_change (void);
>  static void output_stack_adjust (int, rtx, int, HARD_REG_SET *, bool);
>  static rtx_insn *frame_insn (rtx);
>  static rtx push (int);
> @@ -392,6 +393,10 @@ static const struct attribute_spec sh_attribute_table[] =
>  #undef TARGET_OPTION_OVERRIDE
>  #define TARGET_OPTION_OVERRIDE sh_option_override
>  
> +#undef TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
> +#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE \
> +  sh_override_options_after_change
> +
>  #undef TARGET_PRINT_OPERAND
>  #define TARGET_PRINT_OPERAND sh_print_operand
>  #undef TARGET_PRINT_OPERAND_ADDRESS
> @@ -1044,6 +1049,50 @@ sh_option_override (void)
>TARGET_ACCUMULATE_OUTGOING_ARGS = 1;
>  }
>  
> +  if (flag_unsafe_math_optimizations)
> +{
> +  /* Enable fsca insn for SH4A if not otherwise specified by the user.  
> */
> +  if (global_options_set.x_TARGET_FSCA == 0 && TARGET_SH4A_FP)
> + TARGET_FSCA = 1;
> +
> +  /* Enable fsrra insn for SH4A if not otherwise specified by the user.  
> */
> +  if (global_options_set.x_TARGET_FSRRA == 0 && TARGET_SH4A_FP)
> + TARGET_FSRRA = 1;
> +}
> +
> +  /*  Allow fsrra insn only if -funsafe-math-optimizations and
> +  -ffinite-math-only is enabled.  */
> +  TARGET_FSRRA = TARGET_FSRRA
> +  && flag_unsafe_math_optimizations
> +  && flag_finite_math_only;
> +
> +  /* If the -mieee option was not explicitly set by the user, turn it on
> + unless -ffinite-math-only was specified.  See also PR 33135.  */
> +  if (! global_options_set.x_TARGET_IEEE)
> +TARGET_IEEE = ! flag_finite_math_only;
> +
> +  if (sh_fixed_range_str)
> +sh_fix_range (sh_fixed_range_str);
> +
> +  /* This target defaults to strict volatile bitfields.  */
> +  if (flag_strict_volatile_bitfields < 0 && abi_version_at_least(2))
> +flag_strict_volatile_bitfields = 1;
> +
> +  sh_override_options_after_change ();
> +
> +  /* Parse atomic model option and make sure it is valid for the current
> + target CPU.  */
> +  selected_atomic_model_
> += parse_validate_atomic_model_option (sh_atomic_model_str);
> +
> +  register_sh_passes ();
> +}
> +
> +/* Implement targetm.override_options_after_change.  */
> +
> +static void
> +sh_override_options_after_change (void)
> +{
>/*  Adjust loop, jump and function alignment values (in bytes), if those
>were not specified by the user using -falign-loops, -falign-jumps
>and -falign-functions options.
> @@ -1093,42 +1142,6 @@ sh_option_override (void)
>if (align_functions < min_align)
>   align_functions = min_align;
>  }
> -
> -  if (flag_unsafe_math_optimizations)
> -{
> -  /* Enable fsca insn for SH4A if not otherwise specified by the user.  
> */
> -  if (global_options_set.x_TARGET_FSCA == 0 && TARGET_SH4A_FP)
> - TARGET_FSCA = 1;
> -
> -  /* Enable fsrra insn for SH4A if not otherwise specified by the user.  
> */
> -  if (global_options_set.x_TARGET_FSRRA == 0 && TARGET_SH4A_FP)
> - TARGET_FSRRA = 1;
> -}
> -
> -  /*  Allow fsrra insn only if -funsafe-math-optimizations and
> -  -ffinite-math-only is enabled.  */
> -  TARGET_FSRRA = TARGET_FSRRA
> -  && flag_unsafe_math_optimizations
> -  && flag_finite_math_only;
> -
> -  /* If the -mieee option was not explicitly set by the user, turn it on
> - unless -ffinite-math-only was specified.  See also PR 33135.  */
> -  if (! global_options_set.x_TARGET_IEEE)
> -TARGET_IEEE = ! flag_finite_math_only;
> -
> -  if (sh_fixed_range_str)
> -sh_fix_range (sh_fixed_range_str);
> -
> -  /* This target defaults to strict volatile bitfields.  */
> -  if (flag_strict_volatile_bitfields < 0 && abi_version_at_least(2))
> -flag_strict_volatile_bitfields = 1;
> -
> -  /* Parse atomic model option and make sure it is valid for the current
> - target CPU.  */
> -  selected_atomic_model_
> -= 

Re: [patch] Update template instantiation documentation

[Andrew Pinski]

On Sat, Oct 3, 2015 at 9:44 AM, Sandra Loosemore
 wrote:
> On 10/03/2015 06:47 AM, Jonathan Wakely wrote:
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html
>> currently says that using -frepo "is your best option for application
>> code written for the Borland model, as it just works."
>>
>> That was true at one point, but as can be seen from the mentions of
>> binutils 2.8 and Solaris 2, the information there is pretty old.
>>
>> Since then -frepo has bitrotted occasionally, and it's much simpler to
>> rely on implicit instantiations in COMDAT sections, controlling
>> specific instantiations with explicit instantiations if needed (using
>> 'extern template' which was standardised in C++11).
>>
>> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910#c2 for an
>> example of bitrot (now fixed) and people being persuaded by the docs
>> that -frepo is the best option.
>>
>> So this revises the docs, to downplay the usefulness of -frepo,
>> and to endorse the "do nothing" model (with selective explicit
>> instantations as needed).
>>
>> It also changes another mention of -frepo to use a different C++-only
>> option, to further de-emphasize -frepo.
>>
>> OK for trunk?
>
>
> Thanks for tackling this.  I remember thinking that this section looked
> bit-rotted when I was reviewing the manual earlier this year.  Your patch
> looks like a step in the right direction, but can I get you to fix a couple
> other things while you're at it?
>
> First, I think the reference to ancient ld versions is confusing, and it
> would be better to rewrite that to emphasize that this is the default
> behavior on most targets.  (I'd guess that anybody trying to use a recent
> GCC release with an ld version from 1996 is going to run into more critical
> blocking issues than this one.)  Maybe something like:
>
> "G++ implements the Borland model on targets where the linker supports it,
> including both ELF targets (such as GNU/Linux) and Microsoft Windows.
> Otherwise G++ implements neither automatic model."


Add "And Mac OS X" to that too.  So people don't use that against us
for the reason why Apple went to clang/LLVM.

Thanks,
Andrew

>
> Second, if "Do nothing" is now the recommended way to handle this, let's
> move that option to the front of the itemized list instead of the end. Also,
> I'm confused by the "pretend" here; can we just delete that sentence?
>
> -Sandra
>

Re: [patch] Update template instantiation documentation

[Jonathan Wakely]

On 03/10/15 10:44 -0600, Sandra Loosemore wrote:
Thanks for tackling this.  I remember thinking that this section 
looked bit-rotted when I was reviewing the manual earlier this year.  
Your patch looks like a step in the right direction, but can I get you 
to fix a couple other things while you're at it?


First, I think the reference to ancient ld versions is confusing, and 
it would be better to rewrite that to emphasize that this is the 
default behavior on most targets.  (I'd guess that anybody trying to 
use a recent GCC release with an ld version from 1996 is going to run 
into more critical blocking issues than this one.)  Maybe something 
like:


"G++ implements the Borland model on targets where the linker supports 
it, including both ELF targets (such as GNU/Linux) and Microsoft 
Windows.  Otherwise G++ implements neither automatic model."


Second, if "Do nothing" is now the recommended way to handle this, 
let's move that option to the front of the itemized list instead of 
the end. Also, I'm confused by the "pretend" here; can we just delete 
that sentence?


Yes, all good ideas, I'll incorporate these asap.

Re: [patch] Update template instantiation documentation

[Jonathan Wakely]

On 03/10/15 09:49 -0700, Andrew Pinski wrote:

Add "And Mac OS X" to that too.  So people don't use that against us
for the reason why Apple went to clang/LLVM.


Will do.

Re: [PATCH] libgcc: quote ARM macro parameters

[Andreas Schwab]

Saleem Abdulrasool  writes:

> For ARM EHABI _Unwind_{G,S}setIP are macros rather than proper functions as 
> they
> are extensions to the EHABI specification (though they are part of the Level 1
> interface).  Quote the macro parameters, as otherwise, a complex parameter may
> be ambiguously mis-expanded.
> ---
>  libgcc/config/arm/unwind-arm.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libgcc/config/arm/unwind-arm.h b/libgcc/config/arm/unwind-arm.h
> index f1f789c..3821c08 100644
> --- a/libgcc/config/arm/unwind-arm.h
> +++ b/libgcc/config/arm/unwind-arm.h
> @@ -74,10 +74,10 @@ extern "C" {
>  }
>/* Return the address of the instruction, not the actual IP value.  */
>  #define _Unwind_GetIP(context) \
> -  (_Unwind_GetGR (context, 15) & ~(_Unwind_Word)1)
> +  (_Unwind_GetGR ((context), 15) & ~(_Unwind_Word)1)

How can that get mis-expanded (other than cheating with a macro that
expands to a comma)?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Possible patch for fortran/65766

[Louis Krupp]

I'm ready to check it in.

Louis

 On Sat, 03 Oct 2015 07:00:56 -0700 Dominique 
dHumières wrote  
 > AFAICT this patch has been approved by FX at 
 > https://gcc.gnu.org/ml/fortran/2015-07/msg00168.html. Any reason to not 
 > commit it? 
 >  
 > Dominique 
 >  
 > 

Re: [C/C++ PATCH] RFC: Implement -Wduplicated-cond (PR c/64249) (take

[Marek Polacek]

On Sat, Oct 03, 2015 at 09:07:29AM +0200, Andreas Schwab wrote:
> Marek Polacek  writes:
> 
> > diff --git gcc/Makefile.in gcc/Makefile.in
> > index c2df21d..d7caa76 100644
> > --- gcc/Makefile.in
> > +++ gcc/Makefile.in
> > @@ -217,6 +217,8 @@ libgcov-merge-tool.o-warn = -Wno-error
> >  gimple-match.o-warn = -Wno-unused
> >  generic-match.o-warn = -Wno-unused
> >  dfp.o-warn = -Wno-strict-aliasing
> > +insn-latencytab.o-warn = -Wno-duplicated-cond
> > +insn-dfatab.o-warn = -Wno-duplicated-cond
> 
> cc1plus: error: unrecognized command line option "-Wno-duplicated-cond"
> make[3]: *** [insn-dfatab.o] Error 1

Sorry, fixed with:

Bootstrapped/regtested on x86_64-linux, applying to trunk.

2015-10-03  Marek Polacek  

* Makefile.in (insn-latencytab.o): Remove -Wno-duplicated-cond.
(insn-dfatab.o): Likewise.

diff --git gcc/Makefile.in gcc/Makefile.in
index b22b5ab..009c745 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -217,8 +217,6 @@ libgcov-merge-tool.o-warn = -Wno-error
 gimple-match.o-warn = -Wno-unused
 generic-match.o-warn = -Wno-unused
 dfp.o-warn = -Wno-strict-aliasing
-insn-latencytab.o-warn = -Wno-duplicated-cond
-insn-dfatab.o-warn = -Wno-duplicated-cond
 
 # All warnings have to be shut off in stage1 if the compiler used then
 # isn't gcc; configure determines that.  WARN_CFLAGS will be either

Marek

RE: Do not use TYPE_CANONICAL in useless_type_conversion

[Bernd Edlinger]

Hi,

On Fri, 2 Oct 2015 23:31:09, Eric Botcazou wrote:
>
> It's related to a known difficulty with alignment and inheritance, and other
> languages are affected by variant of it, see e.g. PR c++/37798.
>

I doubt that this is still an issue with the current trunk.

I tried the test case from the pr37798 on x86_64, and now the object is 
8-aligned,
but the object was only 4-byte aligned according to the comments in the bugzilla
at that time.

If the middle-end would not know the alignment by means of get_object_alignment
that would break the tsan instrumentation immediately, because the tsan library 
only
works for correctly aligned data accesses.

BTW: It is easy to list all gcc-6 regressions, but is there also a way to query 
the bugzilla
for old and believed-to-be unfixable bugs?

I mean something like that one is technically not a regression, but it would be 
good to
locate forgotten trackers, and revive them from time to time...


>> You remember, when I removed the TYPE_ALIGN_OK handing (initially it wasn't
>> clear to me that it's entire use is only to make Ada happy), all Ada tests
>> continued to pass, even on ARM. BTW: You promised me last year to give me
>> an example where that makes a difference.
>
> I know, but that's low priority, sorry. You can probably browse the 2004
> archives and find one (or a sketch of one); that being said, gigi was a bit
> changed since then so this could as well be obsolete.
>



I digged a bit, but did not find any hint for Ada test cases though.

This change introduced TYPE_ALIGN_OK to get_inner_reference for the first time.
I did not find the discussion for that in the archives:


r66465 | kenner | 2003-05-05 00:09:48 +0200 (Mo, 05. Mai 2003) | 6 Zeilen

    * expr.c (store_field): Don't clobber TEMP in shift: it might be
    a variable.
    (get_inner_reference): Don't go through a VIEW_CONVERT_EXPR
    whose purpose is to step up the alignment.
    (expand_expr, case ADDR_EXPR): Force LO_SUM into memory, just like REG.


And this change rewrote the code to the form that caused a regression,
that was fixed later by you:


r91511 | rth | 2004-11-30 04:52:37 +0100 (Di, 30. Nov 2004) | 14 Zeilen

    * expr.c (get_inner_reference): Handle REAL/IMAGPART_EXPR.
    (handled_component_p): Likewise.
    * alias.c (can_address_p): Reformat and simplify.  Handle
    REAL/IMAGPART_EXPR.  Do not disable addressability based on
    alias set zero.
    * fold-const.c (build_fold_addr_expr_with_type): Remove duplicate
    check for REAL/IMAGPART_EXPR.
    * gimplify.c (gimplify_compound_lval): Likewise.
    * tree-cfg.c (verify_expr): Likewise.
    * tree-gimple.c (is_gimple_addressable, get_base_address): Likewise.
    * tree-nested.c (build_addr, convert_nonlocal_reference): Likewise.
    (convert_local_reference): Likewise.
    * tree-ssa-loop-ivopts.c (prepare_decl_rtl): Likewise.


That one was discussed here: 
https://gcc.gnu.org/ml/gcc-patches/2004-11/msg02652.html
aka pr15289, the corresponding test case was added to the test suite later.
But there was no Ada problem reported at that time.


Bernd.
  

Re: [patch] Update template instantiation documentation

[Sandra Loosemore]

On 10/03/2015 06:47 AM, Jonathan Wakely wrote:

https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html
currently says that using -frepo "is your best option for application
code written for the Borland model, as it just works."

That was true at one point, but as can be seen from the mentions of
binutils 2.8 and Solaris 2, the information there is pretty old.

Since then -frepo has bitrotted occasionally, and it's much simpler to
rely on implicit instantiations in COMDAT sections, controlling
specific instantiations with explicit instantiations if needed (using
'extern template' which was standardised in C++11).

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910#c2 for an
example of bitrot (now fixed) and people being persuaded by the docs
that -frepo is the best option.

So this revises the docs, to downplay the usefulness of -frepo,
and to endorse the "do nothing" model (with selective explicit
instantations as needed).

It also changes another mention of -frepo to use a different C++-only
option, to further de-emphasize -frepo.

OK for trunk?


Thanks for tackling this.  I remember thinking that this section looked 
bit-rotted when I was reviewing the manual earlier this year.  Your 
patch looks like a step in the right direction, but can I get you to fix 
a couple other things while you're at it?


First, I think the reference to ancient ld versions is confusing, and it 
would be better to rewrite that to emphasize that this is the default 
behavior on most targets.  (I'd guess that anybody trying to use a 
recent GCC release with an ld version from 1996 is going to run into 
more critical blocking issues than this one.)  Maybe something like:


"G++ implements the Borland model on targets where the linker supports 
it, including both ELF targets (such as GNU/Linux) and Microsoft 
Windows.  Otherwise G++ implements neither automatic model."


Second, if "Do nothing" is now the recommended way to handle this, let's 
move that option to the front of the itemized list instead of the end. 
Also, I'm confused by the "pretend" here; can we just delete that sentence?


-Sandra

Re: [PATCH] SH FDPIC backend support

[Rich Felker]

On Sat, Oct 03, 2015 at 05:17:53PM +0900, Oleg Endo wrote:
> On Sat, 2015-10-03 at 00:50 -0400, Rich Felker wrote:
> 
> > I have -mfdpic in the self-specs when FDPIC_DEFAULT is defined, so I
> > think only the positive form is needed. 
> 
> Having positive and negative forms for options makes sense.  It usually
> costs nothing because anyway the compiler internally supports both and
> it allows special-casing if one of them is the default, which can be
> useful for testing.

What I'm saying is that the self-specs approach to FDPIC_DEFAULT has
the compiler driver adding -mfdpic to its own command line (via
%{!mno-fdpic:-mfdpic}) when FDPIC_DEFAULT is defined. This allows
other specs simply to test %{mfdpic:...} rather than having complex
separate forms depending on whether FDPIC_DEFAULT is defined. The
negative form is of course supported too (and suppresses the self-spec
addition of -mfdpic).

I'm not sure if this approach is acceptable upstream in gcc. I like it
a lot better because it isolates this kind of logic as described above
rather than having it spread out all over the place in error-prone
ways. I had a several-line patch for default-pie support that worked
via self-specs too; the one that was actually committed to gcc was
hugely invasive across many files including most targets...

Rich

Re: [PATCH] SH FDPIC backend support

[Rich Felker]

On Thu, Oct 01, 2015 at 09:30:17PM -0400, Rich Felker wrote:
> But trying the patch on vanilla GCC trunk without my usual J2 target
> setup revealed some additional issues I need to address. I'm getting
> ICE in the code that generates the libgcc bitshift calls, which
> weren't used on J2. This is my fault for failing to extend the changes
> made to other parts of sh.md to the patterns for the new shifts (the
> same ones that broke the kernel) and perhaps also some other things.
> I'm going to go back and review that code and get it done right before
> resubmitting the patch against trunk.

I found and fixed the problem, but I have a new concern: calls to the
new shift instructions are using the following address forms:

-mno-fdpic -fPIC:
.long   __ashlsi3_r0@GOTOFF

-mfdpic:
.long   __ashlsi3_r0-(.LPCS1+2)

Neither of these seems valid. Both assume __ashlsi3_r0 will be defined
in the same DSO, which is not true in general; shared libgcc_s.so
might be in use. In this case the call would need to go through the
PLT, which (for PIC or FDPIC) requires r12 to be loaded with the GOT
address. In the non-FDPIC case, r12 _happens_ to contain the GOT
address just because it was used as an addend to get the function
address from the @GOTOFF address, but this does not seem
safe/reliable. In the FDPIC case there's nothing to cause r12 to
contain the GOT address, and in fact if the function has already made
another function call (which uses and clobbers r12), no code is
generated to save and restore r12 for the libgcc call.

Calls to other functions lib libgcc (e.g. division) seem to work fine
and either go through the PLT or bypass it and load from the GOT
directly. It's only these new special-calling-convention ones that are
broken, and I can't figure out why...

Rich

Re: Do not use TYPE_CANONICAL in useless_type_conversion

[Eric Botcazou]

> I doubt that this is still an issue with the current trunk.
> 
> I tried the test case from the pr37798 on x86_64, and now the object is
> 8-aligned, but the object was only 4-byte aligned according to the comments
> in the bugzilla at that time.

Yes, it's already fixed with the 4.9.x compiler apparently.

> I digged a bit, but did not find any hint for Ada test cases though.
> 
> This change introduced TYPE_ALIGN_OK to get_inner_reference for the first
> time. I did not find the discussion for that in the archives:
> 
> 
> r66465 | kenner | 2003-05-05 00:09:48 +0200 (Mo, 05. Mai 2003) | 6 Zeilen
> 
> * expr.c (store_field): Don't clobber TEMP in shift: it might be
> a variable.
> (get_inner_reference): Don't go through a VIEW_CONVERT_EXPR
> whose purpose is to step up the alignment.
> (expand_expr, case ADDR_EXPR): Force LO_SUM into memory, just like REG.

OK, thanks for digging.  I'm going to disable the circuitry and see what 
happens on SPARC and SPARC64.

-- 
Eric Botcazou

Re: [PATCH] xtensa: add uclinux support

[Max Filippov]

On Sat, Oct 3, 2015 at 6:19 PM, augustine.sterl...@gmail.com
 wrote:
> On Wed, Sep 30, 2015 at 8:23 AM, Max Filippov  wrote:
>> 2015-09-30  Max Filippov  
>> gcc/
>> * config.gcc (xtensa*-*-uclinux*): New configuration.
>> * config/xtensa/uclinux.h: New file.
>> * config/xtensa/uclinux.opt: New file.
>>
>> libgcc/
>> * config.host (xtensa*-*-uclinux*): New configuration.
>
> Approved, please apply.

Applied to trunk. Thanks!

-- Max

[PATCH] libgcc: quote ARM macro parameters

[Saleem Abdulrasool]

For ARM EHABI _Unwind_{G,S}setIP are macros rather than proper functions as they
are extensions to the EHABI specification (though they are part of the Level 1
interface).  Quote the macro parameters, as otherwise, a complex parameter may
be ambiguously mis-expanded.
---
 libgcc/config/arm/unwind-arm.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libgcc/config/arm/unwind-arm.h b/libgcc/config/arm/unwind-arm.h
index f1f789c..3821c08 100644
--- a/libgcc/config/arm/unwind-arm.h
+++ b/libgcc/config/arm/unwind-arm.h
@@ -74,10 +74,10 @@ extern "C" {
 }
   /* Return the address of the instruction, not the actual IP value.  */
 #define _Unwind_GetIP(context) \
-  (_Unwind_GetGR (context, 15) & ~(_Unwind_Word)1)
+  (_Unwind_GetGR ((context), 15) & ~(_Unwind_Word)1)
 
 #define _Unwind_SetIP(context, val) \
-  _Unwind_SetGR (context, 15, val | (_Unwind_GetGR (context, 15) & 1))
+  _Unwind_SetGR ((context), 15, (val) | (_Unwind_GetGR ((context), 15) & 1))
 
 #ifdef __cplusplus
 }   /* extern "C" */
-- 
2.5.3

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

[Steve Kargl]

On Sat, Oct 03, 2015 at 12:13:12PM +0200, Mikael Morin wrote:
>
> I have finally managed to find a patch that doesn't regress in the 
> testsuite.
> 
> The gfc_add_in_common call in gfc_match_common is delayed after the 
> array spec handling and without return value check, so that errors are 
> ignored.  Another gfc_add_in_common call is necessary to report errors 
> again during resolution.  This is patch number 2.
> The error location for the second call is grabbed from the common block 
> struct, which is made accessible in the function by patch number 1.
> 
> No regression on x86-unknown-linux-gnu, OK for trunk?
> 

The patch is OK.  Thanks for taking over PR.

-- 
Steve

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

[Matthias Klose]

On 01.10.2015 01:07, Ian Lance Taylor wrote:

On Thu, Sep 17, 2015 at 12:13 PM, Lynn A. Boger
<labo...@linux.vnet.ibm.com> wrote:

Here is my updated patch, with the changes suggested by
Ian for gcc/gospec.c and David for gcc/configure.ac.

Bootstrap built and tested on ppc64le, ppc64 multilib.

2015-09-17Lynn Boger <labo...@linux.vnet.ibm.com>
gcc/
 PR target/66870
 config/rs6000/sysv4.h:  Define TARGET_CAN_SPLIT_STACK_64BIT
 config.in:  Set up HAVE_GOLD_ALTERNATE_SPLIT_STACK
 configure.ac:  Define HAVE_GOLD_ALTERNATE_SPLIT_STACK
 on Power based on gold linker version
 configure:  Regenerate
 gcc.c:  Add -fuse-ld=gold to STACK_SPLIT_SPEC if
 HAVE_GOLD_ALTERNATE_SPLIT_STACK defined
 go/gospec.c:  (lang_specific_driver):  Set appropriate split
stack
 options for 64 bit compiles based on
TARGET_CAN_SPLIT_STACK_64BIT


Thanks.  I had to add ATTRIBUTE_UNUSED to the new variable in
go/gospec.c.  Committed with these ChangeLog entries:

2015-10-01  Lynn Boger  <labo...@linux.vnet.ibm.com>

PR target/66870
* config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Define.
* configure.ac: Define HAVE_GOLD_ALTERNATE_SPLIT_STACK on Power
based on gold linker version.
* gcc.c: Add -fuse-ld=gold to STACK_SPLIT_SPEC if
HAVE_GOLD_ALTERNATE_SPLIT_STACK defined.
* configure, config.in: Regenerate.

2015-10-01  Lynn Boger  <labo...@linux.vnet.ibm.com>

PR target/66870
* gospec.c (lang_specific_driver): Set appropriate split stack
options for 64 bit compiles based on TARGET_CAN_SPLIT_STACK_64BIT.

Ian



this causes the build to fail on powerpc-linux-gnu:

make[4]: Entering directory '/home/doko/gcc/gcc-snapshot-20151003/build/gotools'
/home/doko/gcc/gcc-snapshot-20151003/build/./gcc/gccgo 
-B/home/doko/gcc/gcc-snapshot-20151003/build/./gcc/ -g -O2  -static-libstdc++ 
-static-libgcc -Wl,-z,relro -L ../powerpc-linux-gnu/libgo -L 
../powerpc-linux-gnu/libgo/.libs -o go 
../../src/gotools/../libgo/go/cmd/go/build.go 
../../src/gotools/../libgo/go/cmd/go/clean.go 
../../src/gotools/../libgo/go/cmd/go/context.go 
../../src/gotools/../libgo/go/cmd/go/discovery.go 
../../src/gotools/../libgo/go/cmd/go/env.go 
../../src/gotools/../libgo/go/cmd/go/fix.go 
../../src/gotools/../libgo/go/cmd/go/fmt.go 
../../src/gotools/../libgo/go/cmd/go/generate.go 
../../src/gotools/../libgo/go/cmd/go/get.go 
../../src/gotools/../libgo/go/cmd/go/go11.go 
../../src/gotools/../libgo/go/cmd/go/help.go 
../../src/gotools/../libgo/go/cmd/go/http.go 
../../src/gotools/../libgo/go/cmd/go/list.go 
../../src/gotools/../libgo/go/cmd/go/main.go 
../../src/gotools/../libgo/go/cmd/go/pkg.go 
../../src/gotools/../libgo/go/cmd/go/run.go 
../../src/gotools/../libgo/go/cmd/go/signal.go 
../../src/gotools/../libgo/go/cmd/go/signal_unix.go 
../../src/gotools/../libgo/go/cmd/go/test.go 
../../src/gotools/../libgo/go/cmd/go/testflag.go 
../../src/gotools/../libgo/go/cmd/go/tool.go 
../../src/gotools/../libgo/go/cmd/go/vcs.go 
../../src/gotools/../libgo/go/cmd/go/version.go 
../../src/gotools/../libgo/go/cmd/go/vet.go 
../powerpc-linux-gnu/libgo/zstdpkglist.go zdefaultcc.go
go1: error: '-fsplit-stack' currently only supported on PowerPC64 GNU/Linux with 
glibc-2.18 or later

go1: error: '-fsplit-stack' is not supported by this compiler configuration
Makefile:667: recipe for target 'go' failed
make[4]: *** [go] Error 1
make[4]: Leaving directory '/home/doko/gcc/gcc-snapshot-20151003/build/gotools'
Makefile:12908: recipe for target 'all-gotools' failed
make[3]: *** [all-gotools] Error 2

Re: [PATCH] libgcc: quote ARM macro parameters

[Andreas Schwab]

Saleem Abdulrasool  writes:

> On Saturday, October 3, 2015, Andreas Schwab  wrote:
>
>> Saleem Abdulrasool > writes:
>>
>> > For ARM EHABI _Unwind_{G,S}setIP are macros rather than proper functions
>> as they
>> > are extensions to the EHABI specification (though they are part of the
>> Level 1
>> > interface).  Quote the macro parameters, as otherwise, a complex
>> parameter may
>> > be ambiguously mis-expanded.
>> > ---
>> >  libgcc/config/arm/unwind-arm.h | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libgcc/config/arm/unwind-arm.h
>> b/libgcc/config/arm/unwind-arm.h
>> > index f1f789c..3821c08 100644
>> > --- a/libgcc/config/arm/unwind-arm.h
>> > +++ b/libgcc/config/arm/unwind-arm.h
>> > @@ -74,10 +74,10 @@ extern "C" {
>> >  }
>> >/* Return the address of the instruction, not the actual IP value.  */
>> >  #define _Unwind_GetIP(context) \
>> > -  (_Unwind_GetGR (context, 15) & ~(_Unwind_Word)1)
>> > +  (_Unwind_GetGR ((context), 15) & ~(_Unwind_Word)1)
>>
>> How can that get mis-expanded (other than cheating with a macro that
>> expands to a comma)?
>>
>
> Poor choice of words on my part.  It won't mis-expand, it may expand into
> an "ambiguous" statement (which will be diagnosed with a warning) if the
> argument is an expression in the sense of:
>
> a + b | 1

That cannot happen here, unless the caller already passes such an
expression.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] x86 interrupt attribute

[Yulia Koval]

Hi,

Here is the last version of the patch. Regtested/bootstraped for
Linux/i686 and Linux/x86_64.

Date: Fri, 4 Sep 2015 08:53:23 -0700
Subject: [PATCH] Implement x86 interrupt attribute

The interrupt and exception handlers are called by x86 processors.  X86
hardware pushes information onto stack and calls the handler.  The
requirements are

1. Both interrupt and exception handlers must use the 'IRET' instruction,
instead of the 'RET' instruction, to return from the handlers.
2. All registers are callee-saved in interrupt and exception handlers.
3. The difference between interrupt and exception handlers is the
exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
instruction.

The design goals of interrupt and exception handlers for x86 processors
are:

1. Support both 32-bit and 64-bit modes.
2. Flexible for compilers to optimize.
3. Easy to use by programmers.

To implement interrupt and exception handlers for x86 processors, a
compiler should support:

'interrupt' attribute

Use this attribute to indicate that the specified function with
mandatory arguments is an interrupt or exception handler.  The compiler
generates function entry and exit sequences suitable for use in an
interrupt handler when this attribute is present.  The 'IRET' instruction,
instead of the 'RET' instruction, is used to return from interrupt or
exception handlers.  All registers, except for the EFLAGS register which
is restored by the 'IRET' instruction, are preserved by the compiler.

Any interruptible-without-stack-switch code must be compiled with
-mno-red-zone since interrupt handlers can and will, because of the
hardware design, touch the red zone.

1. interrupt handler must be declared with a mandatory pointer argument:

struct interrupt_frame;

__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame)
{
...
}

and user must properly define the structure the pointer pointing to.

2. exception handler:

The exception handler is very similar to the interrupt handler with
a different mandatory function signature:

typedef unsigned long long int uword_t;
typedef unsigned int uword_t;

struct interrupt_frame;

__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame, uword_t error_code)
{
...
}

and compiler pops the error code off stack before the 'IRET' instruction.

The exception handler should only be used for exceptions which push an
error code and all other exceptions must use the interrupt handler.
The system will crash if the wrong handler is used.

To be feature complete, compiler may implement the optional
'no_caller_saved_registers' attribute:

Use this attribute to indicate that the specified function has no
caller-saved registers.  That is, all registers are callee-saved.
The compiler generates proper function entry and exit sequences to
save and restore any modified registers.

The user can call functions specified with 'no_caller_saved_registers'
attribute from an interrupt handler without saving and restoring all
call clobbered registers.

PR target/66960
PR target/67630
PR target/67634
* config/i386/i386-protos.h (ix86_epilogue_uses): New prototype.
* config/i386/i386.c (ix86_frame): Add nbndregs and nmaskregs.
(ix86_conditional_register_usage): Preserve all registers if
there are no caller-saved registers.
(ix86_set_current_function): Set no_caller_saved_registers and
func_type.  Mark arguments in interrupt handler as used.
(ix86_function_ok_for_sibcall): Return false if there are no
caller-saved registers.
(ix86_maybe_switch_abi): Call reinit_regs if AX register usage
isn't consistent.
(type_natural_mode): Don't warn ABI change for MMX in interrupt
handler.
(ix86_function_arg_advance): Skip for callee in interrupt
handler.
(ix86_function_arg): Handle arguments for callee in interrupt
handler.
(ix86_can_use_return_insn_p): Don't use `ret' instruction in
interrupt handler.
(ix86_hard_regno_scratch_ok): New function.
(ix86_epilogue_uses): Likewise.
(ix86_reg_ever_defined_p): Likewise.
(ix86_nsaved_bndregs): Likewise.
(ix86_nsaved_maskregs): Likewise.
(ix86_reg_save_area_size): Likewise.
(ix86_handle_no_caller_saved_registers_attribute): Likewise.
(ix86_handle_interrupt_attribute): Likewise.
(ix86_save_reg): Preserve all registers if there are no
caller-saved registers after reload.
(ix86_nsaved_sseregs): Don't return 0 if there are no
caller-saved registers.
(ix86_compute_frame_layout): Set nbndregs and nmaskregs.  Set
save_regs_using_mov to true to save bound and mask registers.
Call ix86_reg_save_area_size to get register save area size.
Allocate space to save full vector registers if there are
no caller-saved registers.
(ix86_emit_save_reg_using_mov): Set alignment to word_mode
alignment when saving full vector registers if there are no
caller-saved registers.
(ix86_emit_save_regs_using_mov): Use regno_reg_rtx to get
register size.
(ix86_emit_restore_regs_using_mov): Likewise.
(ix86_emit_save_sse_regs_using_mov): Save full vector registers
if there are no caller-saved 

Re: [PATCH] SH FDPIC backend support

[Rich Felker]

On Sat, Oct 03, 2015 at 03:12:16PM -0400, Rich Felker wrote:
> On Thu, Oct 01, 2015 at 09:30:17PM -0400, Rich Felker wrote:
> > But trying the patch on vanilla GCC trunk without my usual J2 target
> > setup revealed some additional issues I need to address. I'm getting
> > ICE in the code that generates the libgcc bitshift calls, which
> > weren't used on J2. This is my fault for failing to extend the changes
> > made to other parts of sh.md to the patterns for the new shifts (the
> > same ones that broke the kernel) and perhaps also some other things.
> > I'm going to go back and review that code and get it done right before
> > resubmitting the patch against trunk.
> 
> I found and fixed the problem, but I have a new concern: calls to the
> new shift instructions are using the following address forms:
> 
> -mno-fdpic -fPIC:
>   .long   __ashlsi3_r0@GOTOFF
> 
> -mfdpic:
>   .long   __ashlsi3_r0-(.LPCS1+2)
> 
> Neither of these seems valid. Both assume __ashlsi3_r0 will be defined
> in the same DSO, which is not true in general; shared libgcc_s.so
> might be in use. In this case the call would need to go through the
> PLT, which (for PIC or FDPIC) requires r12 to be loaded with the GOT
> address. In the non-FDPIC case, r12 _happens_ to contain the GOT
> address just because it was used as an addend to get the function
> address from the @GOTOFF address, but this does not seem
> safe/reliable. In the FDPIC case there's nothing to cause r12 to
> contain the GOT address, and in fact if the function has already made
> another function call (which uses and clobbers r12), no code is
> generated to save and restore r12 for the libgcc call.
> 
> Calls to other functions lib libgcc (e.g. division) seem to work fine
> and either go through the PLT or bypass it and load from the GOT
> directly. It's only these new special-calling-convention ones that are
> broken, and I can't figure out why...

Hmm, according to sh-protos.h:

  /* A special function that should be linked statically.  These are typically
 smaller or not much larger than a PLT entry.
 Some also have a non-standard ABI which precludes dynamic linking.  */
  SFUNC_STATIC

So apparently the strange behavior I observed is intended. Presumably
there is some mechanism to ensure that these functions are always
static-linked? But I don't see it. The libgcc spec I see is:

*libgcc:
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed
-lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc

This explicitly omits -lgcc when -shared-libgcc is used with -shared.
Thankfully __ashlsi3_r0 is not exported from libgcc.so.1 (as far as I
can tell), so this will just be a link error rather than horribly
wrong behavior, but it still seems like there's a bug here unless I'm
misunderstanding something. I think the final %{!shared: -lgcc} in the
spec is an error and should be replaced by simply -lgcc if there are
targets where libgcc.a contains necessary symbols that are not/cannot
be defined in libgcc_s.so.1.

Rich

Re: [PATCH] SH FDPIC backend support

[Rich Felker]

On Fri, Oct 02, 2015 at 11:18:32AM -0400, Rich Felker wrote:
> > > +#ifdef __FDPIC__
> > > +#define udiv_qrnnd(q, r, n1, n0, d) \
> > > +  do {   
> > > \
> > > +extern UWtype __udiv_qrnnd_16 (UWtype, UWtype)   
> > > \
> > 
> > It's really difficult to spot the subtle difference of the FDPIC version
> > and the non-FDPIC version.  At least there should be a comment.
> 
> OK, I can add a comment; this is appropriate anyway since the way it's
> making the FDPIC call is unconventional.

Before I add comments, can we discuss whether the approach I took is
appropriate? The udiv_qrnnd asm block takes as an operand a function
pointer for __udiv_qrnnd_16 which it calls from asm. The
__udiv_qrnnd_16 function is itself written in asm has a special
contract for register clobbers, and it doesn't need a GOT register.
The non-FDPIC asm calls it via jsr @%5 (%5 is the function pointer)
but on FDPIC the function pointer points to a function descriptor, not
code, so an extra level of indirection is needed. This is actually
inefficient to do in asm because we have to repeat it twice. Normally
an FDPIC call would also require loading the GOT pointer from the
function descriptor, but since this call is local, that can be
skipped.

Another option would be to pass (essentially) *(void**)__udiv_qrnnd_16
instead of __udiv_qrnnd_16 to the asm block; then the existing inline
asm can be used as-is. This could be done via passing
SH_CODE_ADDRESS(__udiv_qrnnd_16) instead of __udiv_qrnnd_16, where
SH_CODE_ADDRESS would be a macro defined to pass through its argument
for non-FDPIC and to extract the code address from the function
descriptor for FDPIC. However I'm not convinced it's clean/safe to do
the above punning. At the very least a may_alias attribute probably
belongs in there somewhere. But an approach like this would reduce
code duplication and slightly improve the size/performance of the
resulting code.

Opinions?

Rich

Re: C PATCH for c/65345 (file-scope _Atomic expansion with floats)

[David Edelsohn]

On Fri, Oct 2, 2015 at 1:08 PM, Ramana Radhakrishnan
 wrote:

>> It's very improbable that I could fix and properly test all of them;
>> I simply don't have the cycles and resources to fix e.g. sh/sparc/alpha/mips.
>
> I don't think anyone expects you to be testing the patch on every single port 
> .
>
> Even though these changes sit in the target hooks into various backends, you 
> may be best
> placed to advise how target maintainers adjust their backends. If at that 
> point this appears to be
> mechanical, it's been good practice in the community for folks to send patches
> that the maintainers can fully test even if the testing has been light for the
> proposed patch.
>
> However, I am not aware of a "policy" for these things other than that these
> sort of changes are selectively enforced in the community. Maybe we should 
> think
> about it 

The bug was not x86-specific.  The fix happens to be in
target-specific code, but that's the luck of the draw.  Numerous other
GCC developers have fixed bugs or added features that required tweaks
to all ports.  Not all targets are easily accessible and you certainly
can ask port maintainers to test a patch.  But writing that you don't
have the cycles to fix all of the targets is not a collegial answer.
Why do you believe that target maintainers have more cycles than you?
I didn't see you tell Uros to fix the bug on x86.  The approach may
work for your one specific bug, but it does not scale if every GCC
developer pursues the same process.

It's poor form to fix a bug only on x86 that is common to all targets
and leave the problem "as an exercise for the reader" for all other
targets -- essentially banishing the other targets to second-class
status with respect to conformance -- especially when the change is
mostly mechanical.  I don't expect developers to specifically enable
and exploit every new feature on every architecture, but had expected
bug fixes to be distributed to all targets.  "It's just not cricket."

GCC has thrived for over 25 years -- supporting a huge number of
targets and languages -- through a general sense of cooperation and
collaboration to ensure the success of the entire project.  If this is
going to degrade into a more parochial attitude, then maybe GCC will
need an explicit policy to counteract that mindset.

I am testing the attached patch for PPC.

- David


ZZ
Description: Binary data

Re: [PATCH] SH FDPIC backend support

[Oleg Endo]

On Sat, 2015-10-03 at 18:34 -0400, Rich Felker wrote:
> > 
> > I found and fixed the problem, but I have a new concern: calls to the
> > new shift instructions are using the following address forms:
> > 
> > -mno-fdpic -fPIC:
> > .long   __ashlsi3_r0@GOTOFF
> > 
> > -mfdpic:
> > .long   __ashlsi3_r0-(.LPCS1+2)
> > 
> > Neither of these seems valid. Both assume __ashlsi3_r0 will be defined
> > in the same DSO, which is not true in general; shared libgcc_s.so
> > might be in use. In this case the call would need to go through the
> > PLT, which (for PIC or FDPIC) requires r12 to be loaded with the GOT
> > address. In the non-FDPIC case, r12 _happens_ to contain the GOT
> > address just because it was used as an addend to get the function
> > address from the @GOTOFF address, but this does not seem
> > safe/reliable. In the FDPIC case there's nothing to cause r12 to
> > contain the GOT address, and in fact if the function has already made
> > another function call (which uses and clobbers r12), no code is
> > generated to save and restore r12 for the libgcc call.

I might be missing something, but usually R12 is preserved across
function calls.  The special functions in libgcc tell the compiler
exactly which things they clobber and which not.  R12 is not clobbered
by the shift functions.

> > Calls to other functions lib libgcc (e.g. division) seem to work fine
> > and either go through the PLT or bypass it and load from the GOT
> > directly. It's only these new special-calling-convention ones that are
> > broken, and I can't figure out why...

Sorry, I wasn't paying attention to dynamic linking or *PIC when
changing the shift patterns back then, so maybe I've screwed up
something there.
To me it looks like they do the same thing as expanders for division or
the SH1 multiplication ("mulsi3" pattern).  Each of the libgcc support
functions have a different "ABI", so "__ashlsi3_r0" or "__lshrsi3_r0"
doesn't introduce a new special ABI, it already is as per definition.
These function calls are not expanded like regular function calls, via
e.g. (define_expand "call" ... ).  The function call is hidden from the
regular function call machinery and everything thinks it's a regular
instruction that just has some special register constraints and
clobbers.

I've just tried compiling the following with -m2 -ml -fPIC

unsigned int test_2 (unsigned int x, unsigned int y)
{
  return x << y;
}

unsigned int test_3 (unsigned int x, unsigned int y)
{
  return x / y;
}

And the compiled code is basically identically for both.  For the labels
I get:

.L4:.long   _GLOBAL_OFFSET_TABLE_
.L5:.long   ___ashlsi3_r0@GOTOFF

and

.L10:   .long   _GLOBAL_OFFSET_TABLE_
.L11:   .long   ___udivsi3@GOTOFF

So the shifts do not work, but the divisions do work that way?


> Hmm, according to sh-protos.h:
> 
>   /* A special function that should be linked statically.  These are typically
>  smaller or not much larger than a PLT entry.
>  Some also have a non-standard ABI which precludes dynamic linking.  */
>   SFUNC_STATIC
> 
> So apparently the strange behavior I observed is intended. Presumably
> there is some mechanism to ensure that these functions are always
> static-linked? But I don't see it. The libgcc spec I see is:
> 
> *libgcc:
> %{static|static-libgcc:-lgcc
> -lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed
> -lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc
> 
> This explicitly omits -lgcc when -shared-libgcc is used with -shared.
> Thankfully __ashlsi3_r0 is not exported from libgcc.so.1 (as far as I
> can tell), so this will just be a link error rather than horribly
> wrong behavior, but it still seems like there's a bug here unless I'm
> misunderstanding something. I think the final %{!shared: -lgcc} in the
> spec is an error and should be replaced by simply -lgcc if there are
> targets where libgcc.a contains necessary symbols that are not/cannot
> be defined in libgcc_s.so.1.

Hm, maybe, but I don't know enough about this, sorry.  Kaz, maybe you
have a comment on that?

Cheers,
Oleg

Re: [C/C++ PATCH] RFC: Implement -Wduplicated-cond (PR c/64249) (take

[Andreas Schwab]

Marek Polacek  writes:

> diff --git gcc/Makefile.in gcc/Makefile.in
> index c2df21d..d7caa76 100644
> --- gcc/Makefile.in
> +++ gcc/Makefile.in
> @@ -217,6 +217,8 @@ libgcov-merge-tool.o-warn = -Wno-error
>  gimple-match.o-warn = -Wno-unused
>  generic-match.o-warn = -Wno-unused
>  dfp.o-warn = -Wno-strict-aliasing
> +insn-latencytab.o-warn = -Wno-duplicated-cond
> +insn-dfatab.o-warn = -Wno-duplicated-cond

cc1plus: error: unrecognized command line option "-Wno-duplicated-cond"
make[3]: *** [insn-dfatab.o] Error 1

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH, i386] Introduce switch for Skylake Server CPU.

[Uros Bizjak]

On Fri, Oct 2, 2015 at 6:12 PM, Kirill Yukhin  wrote:
> Hello,
>
> Patch in the bottom introduces cpuid detection
> for Skylake CPU supporting AVX-512.
>
> Bootstrapped. Changed test pass. Is it ok for trunk?
>
> libgcc/
> * libgcc/config/i386/cpuinfo.c (get_intel_cpu): Detect 
> "skylake-avx512".
>
> gcc/testsuite/
> * gcc.target/i386/builtin_target.c: Add check for "skylake-avx512".

OK.

Thanks,
Uros.

> --
> Thanks, K
>
> commit 230beb0d31a9463c8339975580142298138442f6
> Author: Kirill Yukhin 
> Date:   Fri Oct 2 19:03:21 2015 +0300
>
> AVX-512. Add family/model to cpuinfo.c.
>
> diff --git a/gcc/testsuite/gcc.target/i386/builtin_target.c 
> b/gcc/testsuite/gcc.target/i386/builtin_target.c
> index a9a8753..82357a7 100644
> --- a/gcc/testsuite/gcc.target/i386/builtin_target.c
> +++ b/gcc/testsuite/gcc.target/i386/builtin_target.c
> @@ -91,6 +91,11 @@ check_intel_cpu_model (unsigned int family, unsigned int 
> model,
>   assert (__builtin_cpu_is ("corei7"));
>   assert (__builtin_cpu_is ("skylake"));
>   break;
> +   case 0x55:
> + /* Skylake with AVX-512 support.  */
> + assert (__builtin_cpu_is ("corei7"));
> + assert (__builtin_cpu_is ("skylake-avx512"));
> + break;
> case 0x17:
> case 0x1d:
>   /* Penryn.  */
> diff --git a/libgcc/config/i386/cpuinfo.c b/libgcc/config/i386/cpuinfo.c
> index 40ed84c..0cbbc85 100644
> --- a/libgcc/config/i386/cpuinfo.c
> +++ b/libgcc/config/i386/cpuinfo.c
> @@ -78,6 +78,7 @@ enum processor_subtypes
>INTEL_COREI7_HASWELL,
>INTEL_COREI7_BROADWELL,
>INTEL_COREI7_SKYLAKE,
> +  INTEL_COREI7_SKYLAKE_AVX512,
>CPU_SUBTYPE_MAX
>  };
>
> @@ -260,6 +261,11 @@ get_intel_cpu (unsigned int family, unsigned int model, 
> unsigned int brand_id)
>   __cpu_model.__cpu_type = INTEL_COREI7;
>   __cpu_model.__cpu_subtype = INTEL_COREI7_SKYLAKE;
>   break;
> +   case 0x55:
> + /* Skylake with AVX-512 support.  */
> + __cpu_model.__cpu_type = INTEL_COREI7;
> + __cpu_model.__cpu_subtype = INTEL_COREI7_SKYLAKE_AVX512;
> + break;
> case 0x17:
> case 0x1d:
>   /* Penryn.  */

Re: [PATCH] SH FDPIC backend support

[Oleg Endo]

On Sat, 2015-10-03 at 00:50 -0400, Rich Felker wrote:

> I have -mfdpic in the self-specs when FDPIC_DEFAULT is defined, so I
> think only the positive form is needed. 

Having positive and negative forms for options makes sense.  It usually
costs nothing because anyway the compiler internally supports both and
it allows special-casing if one of them is the default, which can be
useful for testing.

Cheers,
Oleg