[PATCH] PR target/85456, Fix __builtin_powil for -mabi=ieeelongdouble on PowerPC

[Michael Meissner]

This patch adds __powikf2 to libgcc, and makes GCC use it for __builtin_powil
when long double is IEEE 128-bit (-mabi=ieeelongdouble).

I tested it on a little endian power8 system with a bootstrap compiler.  There
were no regresion failures.  Can I check this into GCC 8?  This does not need
to be checked into GCC 7, since -mabi=ieeelongdouble was not fully supported in
that release.

[libgcc]
2018-04-18  Michael Meissner  

PR target/85456
* config/rs6000/_powikf2.c: New file.  Entry point for
__builtin_powil when -mabi=ieeelongdouble is in effect.
* config/rs6000/float128-ifunc.c (__powikf2_resolve): Add
__powikf2 support.
(__powikf2): Likewise.
* config/rs6000/quad-float128.h (__powikf2_sw): Likewise.
(__powikf2_hw): Likewise.
(__powikf2): Likewise.
* config/rs6000/t-float128 (fp128_ppc_funcs): Likewise.
* config/rs6000/t-float128-hw (fp128_hw_func): Likewise.
(_powikf2-hw.c): Likewise.

[gcc]
2018-04-18  Michael Meissner  

PR target/85456
* config/rs6000/rs6000.c (init_float128_ieee): Add support to call
__powikf2 when long double is IEEE 128-bit.

[gcc/testsuite]
2018-04-18  Michael Meissner  

PR target/85456
* gcc.target/powerpc/pr85456.c: New test.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: libgcc/config/rs6000/_powikf2.c
===
--- libgcc/config/rs6000/_powikf2.c (revision 0)
+++ libgcc/config/rs6000/_powikf2.c (revision 0)
@@ -0,0 +1,45 @@
+/* Copyright (C) 1989-2018 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+/* This is a temporary specialization of code from libgcc/libgcc2.c.  */
+
+#include "soft-fp.h"
+#include "quad-float128.h"
+
+#if defined(FLOAT128_HW_INSNS) && !defined(__powikf2)
+#define __powikf2 __powikf2_sw
+#endif
+
+TFtype
+__powikf2 (TFtype x, SItype_ppc m)
+{
+  unsigned int n = m < 0 ? -m : m;
+  TFtype y = n % 2 ? x : 1;
+  while (n >>= 1)
+{
+  x = x * x;
+  if (n % 2)
+   y = y * x;
+}
+  return m < 0 ? 1/y : y;
+}
Index: libgcc/config/rs6000/float128-ifunc.c
===
--- libgcc/config/rs6000/float128-ifunc.c   (revision 259476)
+++ libgcc/config/rs6000/float128-ifunc.c   (working copy)
@@ -84,6 +84,12 @@ __negkf2_resolve (void)
   return SW_OR_HW (__negkf2_sw, __negkf2_hw);
 }
 
+static __typeof__ (__powikf2_sw) *
+__powikf2_resolve (void)
+{
+  return SW_OR_HW (__powikf2_sw, __powikf2_hw);
+}
+
 static __typeof__ (__floatsikf_sw) *
 __floatsikf_resolve (void)
 {
@@ -243,6 +249,9 @@ TFtype __divkf3 (TFtype, TFtype)
 TFtype __negkf2 (TFtype)
   __attribute__ ((__ifunc__ ("__negkf2_resolve")));
 
+TFtype __powikf2 (TFtype, SItype_ppc)
+  __attribute__ ((__ifunc__ ("__powikf2_resolve")));
+
 CMPtype __eqkf2 (TFtype, TFtype)
   __attribute__ ((__ifunc__ ("__eqkf2_resolve")));
 
Index: libgcc/config/rs6000/quad-float128.h
===
--- libgcc/config/rs6000/quad-float128.h(revision 259476)
+++ libgcc/config/rs6000/quad-float128.h(working copy)
@@ -72,6 +72,7 @@ extern TFtype __subkf3_sw (TFtype, TFtyp
 extern TFtype __mulkf3_sw (TFtype, TFtype);
 extern TFtype __divkf3_sw (TFtype, TFtype);
 extern TFtype __negkf2_sw (TFtype);
+extern TFtype __powikf2_sw (TFtype, SItype_ppc);
 extern CMPtype __eqkf2_sw (TFtype, TFtype);
 extern CMPtype __gekf2_sw (TFtype, TFtype);
 extern CMPtype __lekf2_sw (TFtype, TFtype);
@@ -114,6 +115,7 @@ extern TFtype __subkf3_hw (TFtype, TFtyp
 extern TFtype __mulkf3_hw (TFtype, TFtype);
 extern TFtype __divkf3_hw (TFtype, TFtype);
 extern TFtype __negkf2_hw (TFtype);
+extern TFtype __powikf2_hw (TFtype, SItype_ppc);
 extern CMPtype __eqkf2_hw (TFtype, TFtype);
 extern CMPtype __gekf2_hw (TFtype, TFtype);
 

Re: [patches] Re: [PATCH] RISC-V: Pass --no-relax to linker if -mno-relax is present.

[Kito Cheng]

Hi Jim:

Turned off both the assembler and the linker sounds good idea to me,
but it's not support on current assembler now, and gcc might release in
next few month, so I afraid we'll have a short time gap that is
-mno-relax is broken due to assembler not support that command
line option in the latest release yet?

On Thu, Apr 19, 2018 at 8:51 AM, Jim Wilson  wrote:
> On Wed, Apr 18, 2018 at 3:10 AM, Kito Cheng  wrote:
>> * config/riscv/elf.h (LINK_SPEC): Pass --no-relax if
>> -mno-relax is present.
>> * config/riscv/linux.h (LINK_SPEC): Ditto.
>
> It is easy enough to use -Wl,--no-relax and there are other linker
> options that require -Wl so I don't think this is very useful.
>
> However, I think it could be useful if it turned off relaxation in
> both the assembler and the linker, since currently there is no easy
> way to do that.  For the assembler, there is no option, but we can
> emit .option norelax at the asm file start.  It needs to be a real
> option in order to make this work.  Also, options should have a doc
> entry, which is more important when it is a real option.
>
> Jim
>
> --
> You received this message because you are subscribed to the Google Groups 
> "RISC-V Patches" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to patches+unsubscr...@groups.riscv.org.
> To post to this group, send email to patc...@groups.riscv.org.
> Visit this group at 
> https://groups.google.com/a/groups.riscv.org/group/patches/.
> To view this discussion on the web visit 
> https://groups.google.com/a/groups.riscv.org/d/msgid/patches/CAFyWVaaz7Wh3GhYEdf%2BbEMfQFb4bHpVJ3hxYM72C-ce0o4ji3w%40mail.gmail.com.
> For more options, visit https://groups.google.com/a/groups.riscv.org/d/optout.

Re: [PATCH] RISC-V: Pass --no-relax to linker if -mno-relax is present.

[Jim Wilson]

On Wed, Apr 18, 2018 at 3:10 AM, Kito Cheng  wrote:
> * config/riscv/elf.h (LINK_SPEC): Pass --no-relax if
> -mno-relax is present.
> * config/riscv/linux.h (LINK_SPEC): Ditto.

It is easy enough to use -Wl,--no-relax and there are other linker
options that require -Wl so I don't think this is very useful.

However, I think it could be useful if it turned off relaxation in
both the assembler and the linker, since currently there is no easy
way to do that.  For the assembler, there is no option, but we can
emit .option norelax at the asm file start.  It needs to be a real
option in order to make this work.  Also, options should have a doc
entry, which is more important when it is a real option.

Jim

Re: [PATCH] RISC-V: Make sure stack is always aligned during adjusting

[Jim Wilson]

On Wed, Apr 18, 2018 at 4:59 AM, Kito Cheng  wrote:
+  HOST_WIDE_INT min_first_step =
+RISCV_STACK_ALIGN (frame->total_size - frame->fp_sp_offset);
+  HOST_WIDE_INT max_first_step =
+ROUND_DOWN (IMM_REACH / 2 - PREFERRED_STACK_BOUNDARY / 8,
+   PREFERRED_STACK_BOUNDARY / 8);
+  HOST_WIDE_INT min_second_step =
+RISCV_STACK_ALIGN (frame->total_size - max_first_step);

IMM_REACH and PREFERRED_STACK_BOUNDARY are aligned values, so I don't
see the point of rounding max_first_step.  Similarly,
frame->total_size and max_first_step are aligned values, so I don't
see the point of rounding min_second_step.  I do see that rounding
min_first_step is useful.  I'd like to add just that one statement
change unless you have a reason for the others.

I tested this with the following

+  if (min_first_step != RISCV_STACK_ALIGN (min_first_step))
+abort ();
+  if (max_first_step != RISCV_STACK_ALIGN (max_first_step))
+abort ();
+  if (min_second_step != RISCV_STACK_ALIGN (min_second_step))
+abort ();

doing 32/64 elf/linux cross builds and testsuite runs.  It failed for
a 32-bit target before I rounded min_first_step.  With that one
change, I saw no further failures.

Jim

Re: [PATCH] Fix (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst match.pd pattern (PR tree-optimization/85446)

[Marc Glisse]

On Thu, 19 Apr 2018, Jakub Jelinek wrote:


As mentioned in the PR, this optimization can't work if @0's precision
is higher than @1's precision, because originally it compares just some set
of lower bits, but in the new comparison compares all bits.
If @0's precision is smaller than @1's precision (in this case @0 can't be
a pointer, as we disallow such direct casts), then in theory it can be
handled, but will not match what the comment says and we'd need to verify
that the @1 constant can be represented in the @0's precision.

This patch just verifies the precision is the same and does small formatting
cleanup.  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?


That certainly seems safe, but I am surprised to see a direct cast from 
64-bit pointer to 32-bit integer. I've always seen gcc represent those 
with an intermediate cast to a 64-bit integer, even if 
verify_gimple_assign_unary allows the direct cast. Does it depend on the 
platform? It might be nice to canonicalize this a bit, either by 
forbidding narrowing pointer-to-integer casts, or by simplifying cast 
chains to direct casts.


--
Marc Glisse

Re: [PATCH] --enable-cet={yes,no,auto} with default no

[H.J. Lu]

On Wed, Apr 18, 2018 at 3:31 PM, Jakub Jelinek  wrote:
> On Wed, Apr 18, 2018 at 12:24:15PM -0700, H.J. Lu wrote:
>> >> So untested patch would be something like:
>> >
>> > Yes, this is what I think should be the most appropriate approach.
>
> Here is the patch with slightly tweaked install.texi and the all the
> regenerated bits too.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux (without any of
> --enable-cet*/--disable-cet, with no -fct-protection -mcet in libraries,
> change compared to previous bootstrap), additionally tested
> (non-bootstrap build) with --enable-cet=auto, --disable-cet and --enable-cet .
> Ok for trunk?
>
> 2018-04-18  Jakub Jelinek  
>
> * config/cet.m4 (GCC_CET_FLAGS): Default to --disable-cet, replace
> --enable-cet=default with --enable-cet=auto.
>
> * doc/install.texi: Document --disable-cet being the default and
> --enable-cet=auto.
>
> * configure: Regenerated.
>

LGTM.

Thanks.

-- 
H.J.

[PATCH] --enable-cet={yes,no,auto} with default no

[Jakub Jelinek]

On Wed, Apr 18, 2018 at 12:24:15PM -0700, H.J. Lu wrote:
> >> So untested patch would be something like:
> >
> > Yes, this is what I think should be the most appropriate approach.

Here is the patch with slightly tweaked install.texi and the all the
regenerated bits too.

Bootstrapped/regtested on x86_64-linux and i686-linux (without any of
--enable-cet*/--disable-cet, with no -fct-protection -mcet in libraries,
change compared to previous bootstrap), additionally tested
(non-bootstrap build) with --enable-cet=auto, --disable-cet and --enable-cet .
Ok for trunk?

2018-04-18  Jakub Jelinek  

* config/cet.m4 (GCC_CET_FLAGS): Default to --disable-cet, replace
--enable-cet=default with --enable-cet=auto.

* doc/install.texi: Document --disable-cet being the default and
--enable-cet=auto.

* configure: Regenerated.

--- config/cet.m4.jj2018-02-19 19:57:05.221280084 +0100
+++ config/cet.m4   2018-04-18 14:05:31.514859185 +0200
@@ -3,14 +3,14 @@ dnl GCC_CET_FLAGS
 dnl(SHELL-CODE_HANDLER)
 dnl
 AC_DEFUN([GCC_CET_FLAGS],[dnl
-GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
-  permit yes|no|default)
+GCC_ENABLE(cet, no, ,[enable Intel CET in target libraries],
+  permit yes|no|auto)
 AC_MSG_CHECKING([for CET support])
 
 case "$host" in
   i[[34567]]86-*-linux* | x86_64-*-linux*)
 case "$enable_cet" in
-  default)
+  auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
AC_COMPILE_IFELSE(
--- gcc/doc/install.texi.jj 2018-02-08 12:21:20.791749480 +0100
+++ gcc/doc/install.texi2018-04-18 14:07:19.637901528 +0200
@@ -2103,10 +2103,11 @@ instrumentation, see @option{-fcf-protec
 to add @option{-fcf-protection} and, if needed, other target
 specific options to a set of building options.
 
-The option is enabled by default on Linux/x86 if target binutils
-supports @code{Intel CET} instructions.  In this case the target
-libraries are configured to get additional @option{-fcf-protection}
-and @option{-mcet} options.
+The option is disabled by default.  When @code{--enable-cet=auto}
+is used, it is enabled on Linux/x86 if target binutils
+supports @code{Intel CET} instructions and disabled otherwise.
+In this case the target libraries are configured to get additional
+@option{-fcf-protection} and @option{-mcet} options.
 @end table
 
 @subheading Cross-Compiler-Specific Options

--- libatomic/configure (revision 259476)
+++ libatomic/configure (working copy)
@@ -1414,8 +1414,7 @@ Optional Features:
  (and sometimes confusing) to the casual installer
   --enable-symvers=STYLE  enables symbol versioning of the shared library
   [default=yes]
-  --enable-cetenable Intel CET in target libraries
-  [default=default]
+  --enable-cetenable Intel CET in target libraries [default=no]
 
 Optional Packages:
   --with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -11121,7 +11120,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11124 "configure"
+#line 11123 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11227,7 +11226,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11230 "configure"
+#line 11229 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -15305,12 +15304,12 @@ fi
 if test "${enable_cet+set}" = set; then :
   enableval=$enable_cet;
   case "$enableval" in
-   yes|no|default) ;;
+   yes|no|auto) ;;
*) as_fn_error "Unknown argument to enable/disable cet" "$LINENO" 5 ;;
   esac
 
 else
-  enable_cet=default
+  enable_cet=no
 fi
 
 
@@ -15320,7 +15319,7 @@ $as_echo_n "checking for CET support...
 case "$host" in
   i[34567]86-*-linux* | x86_64-*-linux*)
 case "$enable_cet" in
-  default)
+  auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
--- libbacktrace/configure  (revision 259476)
+++ libbacktrace/configure  (working copy)
@@ -1386,8 +1386,7 @@ Optional Features:
   optimize for fast installation [default=yes]
   --disable-libtool-lock  avoid locking (might break parallel builds)
   --disable-largefile omit support for large files
-  --enable-cetenable Intel CET in target libraries
-  [default=default]
+  --enable-cetenable Intel CET in target libraries [default=no]
   --enable-host-sharedbuild host code as shared libraries
 
 Optional Packages:
@@ -11149,7 +11148,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11152 "configure"

[PATCH] Fix (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst match.pd pattern (PR tree-optimization/85446)

[Jakub Jelinek]

Hi!

As mentioned in the PR, this optimization can't work if @0's precision
is higher than @1's precision, because originally it compares just some set
of lower bits, but in the new comparison compares all bits.
If @0's precision is smaller than @1's precision (in this case @0 can't be
a pointer, as we disallow such direct casts), then in theory it can be
handled, but will not match what the comment says and we'd need to verify
that the @1 constant can be represented in the @0's precision.

This patch just verifies the precision is the same and does small formatting
cleanup.  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2018-04-18  Jakub Jelinek  

PR tree-optimization/85446
* match.pd ((intptr_t) x eq/ne CST to x eq/ne (typeof x) cst): Require
the integral and pointer types to have the same precision.

--- gcc/match.pd.jj 2018-04-09 20:15:49.158631652 +0200
+++ gcc/match.pd2018-04-18 09:55:47.176343913 +0200
@@ -3711,10 +3711,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (for cmp (ne eq)
  (simplify
   (cmp (convert @0) INTEGER_CST@1)
-  (if ((POINTER_TYPE_P (TREE_TYPE (@0)) && !FUNC_OR_METHOD_TYPE_P (TREE_TYPE 
(TREE_TYPE (@0)))
-   && INTEGRAL_TYPE_P (TREE_TYPE (@1)))
-  || (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && POINTER_TYPE_P (TREE_TYPE (@1))
- && !FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (@1)
+  (if (((POINTER_TYPE_P (TREE_TYPE (@0))
+&& !FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (@0)))
+&& INTEGRAL_TYPE_P (TREE_TYPE (@1)))
+   || (INTEGRAL_TYPE_P (TREE_TYPE (@0))
+   && POINTER_TYPE_P (TREE_TYPE (@1))
+   && !FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (@1)
+   && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1)))
(cmp @0 (convert @1)
 
 /* Non-equality compare simplifications from fold_binary  */

Jakub

Add myself to MAINTAINERS (write-after-approval)

[Paul Clarke]

2018-04-18  Paul A. Clarke  

* MAINTAINERS (write after approval): Add myself.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 259480)
+++ MAINTAINERS (working copy)
@@ -347,6 +347,7 @@ Bin Cheng   

 Harshit Chopra 
 Tamar Christina

 Eric Christopher   
+Paul Clarke
 William Cohen  
 Michael Collison   
 Josh Conner

--
Regards,
Paul Clarke, IBM

[PATCH] Warn for ignored ASM labels on typdef declarations

[Will Hawkins]

Hello everyone!

First, let me ask for your patience -- this is the first patch I am
submitting to gcc. I tried very hard to follow the proper procedure,
but I am sure that I've missed something.

According to https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html#Asm-Labels
asm labels have no effect on anything other than variable and function
declarations. When an asm label is included on a typedef, the compiler
happily goes along but does not indicate anything to the user.

For instance, when parsing

typedef struct {} x asm ("X");

the compiler silently discards the asm label. This patch will generate
a warning (at -Wpedantic) for such a situation. This is in Bugzilla as
85444.

Again, I hope that I have done all the proper formatting so that it is
inline with all the contribution guidelines. Thank you for your
patience!

Will

2018-04-18  Will Hawkins  

* gcc/c/c-decl.c: Warn about ignored asm label for
typedef declaration
* gcc/cp/decl.c: Warn about ignored asm label for
typedef declaration

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index f0198ec..e9c0a72 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -5166,7 +5166,11 @@ finish_decl (tree decl, location_t init_loc, tree init,
   if (!DECL_FILE_SCOPE_P (decl)
   && variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
 add_stmt (build_stmt (DECL_SOURCE_LOCATION (decl), DECL_EXPR, decl));
-
+  if (asmspec_tree != NULL_TREE)
+{
+  warning (OPT_Wpedantic, "asm-specifier is ignored in "
+   "typedef declaration");
+}
   rest_of_decl_compilation (decl, DECL_FILE_SCOPE_P (decl), 0);
 }

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 44a152b..88b4b94 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7069,6 +7069,11 @@ cp_finish_decl (tree decl, tree init, bool
init_const_expr_p,
   /* Take care of TYPE_DECLs up front.  */
   if (TREE_CODE (decl) == TYPE_DECL)
 {
+  if (asmspec_tree != NULL_TREE)
+{
+  warning (OPT_Wpedantic, "asm-specifier is ignored for "
+   "typedef declarations");
+}
   if (type != error_mark_node
   && MAYBE_CLASS_TYPE_P (type) && DECL_NAME (decl))
 {

Re: [PATCH] Support bitfields in Wodr machinery (PR lto/85405).

[Christophe Lyon]

Hi,


On 17 April 2018 at 10:19, Jan Hubicka  wrote:
>> On 04/17/2018 08:58 AM, Jakub Jelinek wrote:
>> > On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
>> >> +  if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
>> >> +{
>> >> +  warn_odr (t1, t2, f1, f2, warn, warned,
>> >> +G_ ("one field is bitfield while other is not 
>> >> "));
>> >
>> > I think all the G_ uses don't put a space in between G_ and (
>> > Also, please avoid the trailing space in the message.
>>
>> Sure. I see other format violations, should I fix that in follow up patch:
>>
>> gcc/c-family/c-warn.c:   ? G_ ("floating point overflow in 
>> expression %qE "
>> gcc/c-family/c-warn.c:   : G_ ("floating point overflow in 
>> expression of type %qT "
>> gcc/gimple-ssa-sprintf.c: ? G_ ("%<%.*s%> directive 
>> output between %wu and "
>> gcc/gimple-ssa-sprintf.c: : G_ ("%<%.*s%> directive 
>> output between %wu and "
>> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
>> '-fplugin-arg-%s-count-ggc-start=%s'"
>> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
>> '-fplugin-arg-%s-count-ggc-end=%s'"
>> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
>> '-fplugin-arg-%s-count-ggc-mark=%s'"
>> gcc/testsuite/gcc.dg/plugin/ggcplug.c:  warning (0, G_ ("option 
>> '-fplugin-arg-%s-test-extra-root=%s'"
>>
>> ?
>>
>> >
>> > Do you diagnose if both are bit-fields, but with different bitcount, e.g. 
>> > if
>> > in your testcase you replace bool mbDisposed : 1; with int mbDisposed : 3;
>> > and bool mbDisposed; with int mbDisposed : 7; ?
>>
>> Good point, I add a new test-case, done in patch.
>> Is it OK to install the patch?
> OK, thanks! (and sorry for the whitespace errors)
> Honza
>>
>> Martin
>>
>> >
>> >> +  return false;
>> >> +}
>> >> +  else
>> >> +gcc_assert (DECL_NONADDRESSABLE_P (f1)
>> >> +== DECL_NONADDRESSABLE_P (f2));
>> >>  }
>> >>
>> >>/* If one aggregate has more fields than the other, they
>> >> diff --git a/gcc/testsuite/g++.dg/lto/pr85405_0.C 
>> >> b/gcc/testsuite/g++.dg/lto/pr85405_0.C
>> >> new file mode 100644
>> >> index 000..1a41d81099c
>> >> --- /dev/null
>> >> +++ b/gcc/testsuite/g++.dg/lto/pr85405_0.C
>> >> @@ -0,0 +1,18 @@
>> >> +// { dg-lto-do link }
>> >> +// { dg-lto-options {{-fPIC -shared -flto}} }
>> >> +
>> >> +class VclReferenceBase { // { dg-lto-warning "7: type 'struct 
>> >> VclReferenceBase' violates the C\\+\\+ One Definition Rule" }
>> >> +  int mnRefCnt;
>> >> +  bool mbDisposed : 1;
>> >> +  virtual ~VclReferenceBase();
>> >> +};
>> >> +class a;
>> >> +class b {
>> >> +  a 
>> >> +  bool c();
>> >> +};
>> >> +class B {
>> >> +  VclReferenceBase d;
>> >> +};
>> >> +class a : B {};
>> >> +bool b::c() { return false; }
>> >> diff --git a/gcc/testsuite/g++.dg/lto/pr85405_1.C 
>> >> b/gcc/testsuite/g++.dg/lto/pr85405_1.C
>> >> new file mode 100644
>> >> index 000..78606185624
>> >> --- /dev/null
>> >> +++ b/gcc/testsuite/g++.dg/lto/pr85405_1.C
>> >> @@ -0,0 +1,9 @@
>> >> +class VclReferenceBase {
>> >> +  int mnRefCnt;
>> >> +  bool mbDisposed;
>> >> +
>> >> +protected:
>> >> +  virtual ~VclReferenceBase();
>> >> +};
>> >> +class : VclReferenceBase {
>> >> +} a;
>> >>
>> >
>> > Jakub
>> >
>>
>
>> From 87380235f9b81bea4cf910e702192586c072ce93 Mon Sep 17 00:00:00 2001
>> From: marxin 
>> Date: Tue, 17 Apr 2018 10:11:07 +0200
>> Subject: [PATCH] Fix coding style and add a new test-case (PR lto/85405).
>>
>> gcc/ChangeLog:
>>
>> 2018-04-17  Martin Liska  
>>
>>   PR lto/85405
>>   * ipa-devirt.c (odr_types_equivalent_p):
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-04-17  Martin Liska  
>>
>>   PR lto/85405
>>   * g++.dg/lto/pr85405b_0.C: New test.
>>   * g++.dg/lto/pr85405b_1.C: New test.

The new testcases require that -shared and -fpic work, which is not
the case on bare-metal targets
(eg arm-eabi, aarch64-elf).

The attached small patch adds
+// { dg-require-effective-target shared }
+// { dg-require-effective-target fpic }
so the tests are skipped on such targets.

OK for trunk?

Thanks,

Christophe

>> ---
>>  gcc/ipa-devirt.c  |  2 +-
>>  gcc/testsuite/g++.dg/lto/pr85405b_0.C | 18 ++
>>  gcc/testsuite/g++.dg/lto/pr85405b_1.C |  9 +
>>  3 files changed, 28 insertions(+), 1 deletion(-)
>>  create mode 100644 gcc/testsuite/g++.dg/lto/pr85405b_0.C
>>  create mode 100644 gcc/testsuite/g++.dg/lto/pr85405b_1.C
>>
>> diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
>> index 85b8ef175f3..cc9b5e347e6 100644
>> --- a/gcc/ipa-devirt.c
>> +++ b/gcc/ipa-devirt.c
>> @@ -1599,7 +1599,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>> bool *warned,
>>   if (DECL_BIT_FIELD (f1) != 

[PATCH] Make Wodr warnings stable.

[Martin Liška]

Hi.

This is small series that fixes 2 Wodr warnings issue that we have in bugzilla.
It should make in stable across targets, I've tested x86_64, ppc64le and 
aarch64.

Patch can bootstrap on x86_64-linux-gnu and ppc64le-linux-gnu. It's pre-approved
by Honza who worked on that with me. I'm going to install it.

Thanks,
Martin
>From fee106e4bb7d25054ec153571734f36ca9f84609 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 18 Apr 2018 14:32:38 +0200
Subject: [PATCH 4/4] Fix coding style and typos.

gcc/ChangeLog:

2018-04-18  Martin Liska  

	* ipa-devirt.c (odr_subtypes_equivalent_p): Fix GNU coding
	style.

gcc/lto/ChangeLog:

2018-04-18  Martin Liska  

	* lto.c (lto_read_decls): Fix GNU coding style and typos.
---
 gcc/ipa-devirt.c | 2 +-
 gcc/lto/lto.c| 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index a0c095e1d5d..308b6e6cdd5 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -685,7 +685,7 @@ odr_subtypes_equivalent_p (tree t1, tree t2,
   if (!types_same_for_odr (t1, t2, true))
 return false;
   /* Limit recursion: If subtypes are ODR types and we know
- that they are same, be happy.  */
+	 that they are same, be happy.  */
   if (!odr_type_p (t1) || !get_odr_type (t1, true)->odr_violated)
 return true;
 }
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 1a6b18d3e34..1c55f3f691a 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1808,9 +1808,9 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
 		  num_prevailing_types++;
 		  lto_fixup_prevailing_type (t);
 
-	  /* Compute the canonical type of all types.
-		 Because SCC components ar estreame in random (hash) order
-		 we may have enountered the type before while registering
+		  /* Compute the canonical type of all types.
+		 Because SCC components are streamed in random (hash) order
+		 we may have encountered the type before while registering
 		 type canonical of a derived type in the same SCC.  */
 		  if (!TYPE_CANONICAL (t))
 		gimple_register_canonical_type (t);
-- 
2.16.3

>From 78fa22944e8021a4cbb40b3b1b52ecd42672299b Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 16 Apr 2018 14:54:02 +0200
Subject: [PATCH 3/4] Make Wodr warnings stable.

gcc/lto/ChangeLog:

2018-04-18  Martin Liska  

	PR ipa/83983
	PR ipa/85391
	* lto.c (cmp_type_location): New function.
	(lto_read_decls): First collect all types, then
	sort them according by location before register_odr_type
	is called.

gcc/testsuite/ChangeLog:

2018-04-18  Martin Liska  

	PR ipa/83983
	PR ipa/85391
	* g++.dg/lto/pr83121_1.C (struct Environment): Adjust expected
	output.
---
 gcc/lto/lto.c| 46 +++-
 gcc/testsuite/g++.dg/lto/pr83121_1.C |  2 +-
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 0099398ece9..1a6b18d3e34 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1695,6 +1695,40 @@ unify_scc (struct data_in *data_in, unsigned from,
 }
 
 
+/* Compare types based on source file location.  */
+
+static int
+cmp_type_location (const void *p1_, const void *p2_)
+{
+  tree *p1 = (tree*)(const_cast(p1_));
+  tree *p2 = (tree*)(const_cast(p2_));
+  if (*p1 == *p2)
+return 0;
+
+  tree tname1 = TYPE_NAME (*p1);
+  tree tname2 = TYPE_NAME (*p2);
+
+  const char *f1 = DECL_SOURCE_FILE (tname1);
+  const char *f2 = DECL_SOURCE_FILE (tname2);
+
+  int r = strcmp (f1, f2);
+  if (r == 0)
+{
+  int l1 = DECL_SOURCE_LINE (tname1);
+  int l2 = DECL_SOURCE_LINE (tname2);
+  if (l1 == l2)
+   {
+	 int l1 = DECL_SOURCE_COLUMN (tname1);
+	 int l2 = DECL_SOURCE_COLUMN (tname2);
+	 return l1 - l2;
+   }
+  else
+   return l1 - l2;
+}
+  else
+return r;
+}
+
 /* Read all the symbols from buffer DATA, using descriptors in DECL_DATA.
RESOLUTIONS is the set of symbols picked by the linker (read from the
resolution file when the linker plugin is being used).  */
@@ -1711,6 +1745,7 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
   unsigned int i;
   const uint32_t *data_ptr, *data_end;
   uint32_t num_decl_states;
+  auto_vec odr_types;
 
   lto_input_block ib_main ((const char *) data + main_offset,
 			   header->main_size, decl_data->mode_table);
@@ -1780,7 +1815,7 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
 		  if (!TYPE_CANONICAL (t))
 		gimple_register_canonical_type (t);
 		  if (odr_type_p (t))
-		register_odr_type (t);
+		odr_types.safe_push (t);
 		}
 	  /* Link shared INTEGER_CSTs into TYPE_CACHED_VALUEs of its
 		 type which is also member of this SCC.  */
@@ -1842,6 +1877,15 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
   *slot = state;
 }
 
+  /* Sort types for 

Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Jakub Jelinek]

On Wed, Apr 18, 2018 at 03:14:19PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 02:59:34PM +0200, Jakub Jelinek wrote:
> > On Wed, Apr 18, 2018 at 05:07:33AM +, Jason Merrill wrote:
> > > I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.
> 
> As for reinterpret_cast, we e.g. accept
> constexpr int a = reinterpret_cast (1);
> which clang++ rejects, shouldn't we simply in build_reinterpret_cast_1
> when not returning error_mark_node wrap the return value inside some new
> FE tree (or reuse REINTERPRET_CAST_EXPR) and remove it only during
> genericization, so that we can reliably reject those in constexpr handling,
> perhaps only if not !ctx->quiet?

So, I've tried that approach, and while it fixed some issues (e.g. PR49171),
even after changing various testcases (double checked with clang++ if it
indeed is invalid and should be rejected etc.), there are still some extra
FAILs with the patch, see below.  I think the addressof1.C are right,
pr55081.C is unfortunate optimization regression, while reinterpret_cast is
pedantically not a constant expression, if we are just trying to get a
constant value if possible it would be nice to get it.  Wonder if for
ctx->quiet we just could pretend the REINTERPRET_CAST_EXPR isn't in there.

Also, I've added removal of the REINTERPRET_CAST_EXPR trees (replacement
with their operand) into the gimplification langhook, so that we get 3
errors on:
constexpr int a = reinterpret_cast (1);
constexpr int foo (int x) { return reinterpret_cast (x); }
template 
constexpr int bar (int x) { return reinterpret_cast (x); }
constexpr int b = foo (1);
constexpr int c = bar <1> (1);
but nothing then removes it from static initializers.  I've added code
to do that into cp_fold if !current_function_decl, unfortunately
cp_fully_fold/cp_fold doesn't really walk all trees (e.g. it doesn't handle
COMPONENT_REF), so the cp_fully_fold called from store_init_value wasn't
enough; thus the patch does another call with cp_fold_r recursion.

In any case, this reinterpret_cast constexpr pedantic stuff looks too
large/risky at this point to me, I wonder if we accept-invalid even the
simple constexpr int a = reinterpret_cast (1); whether it is not ok for
GCC8 to not error out on reinterpret_cast from PTRMEM_CSTs too, essentially
just use Alex's patch for expr.c and the first hunk from this patch from
constexpr.c, plus the new testcases and deal with the rest for stage1. 
Thoughts on this?

FAIL: g++.dg/cpp0x/addressof1.C  -std=c++11 (test for excess errors)
FAIL: g++.dg/cpp0x/addressof1.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/addressof1.C  -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/addressof1.C  -std=c++2a (test for excess errors)
FAIL: g++.dg/cpp0x/addressof1.C  -std=c++17 -fconcepts (test for excess errors)
FAIL: g++.dg/opt/pr55081.C  -std=c++98  scan-assembler-not _ZGVZ3foovE5array
FAIL: g++.dg/opt/pr55081.C  -std=c++11  scan-assembler-not _ZGVZ3foovE5array
FAIL: g++.dg/opt/pr55081.C  -std=c++14  scan-assembler-not _ZGVZ3foovE5array
FAIL: g++.dg/opt/pr55081.C  -std=c++17  scan-assembler-not _ZGVZ3foovE5array
FAIL: g++.dg/opt/pr55081.C  -std=c++2a  scan-assembler-not _ZGVZ3foovE5array
FAIL: g++.dg/opt/pr55081.C  -std=c++17 -fconcepts  scan-assembler-not 
_ZGVZ3foovE5array
FAIL: g++.dg/warn/Wplacement-new-size.C  -std=gnu++98  (test for warnings, line 
128)
FAIL: g++.dg/warn/Wplacement-new-size.C  -std=gnu++11  (test for warnings, line 
128)
FAIL: g++.dg/warn/Wplacement-new-size.C  -std=gnu++14  (test for warnings, line 
128)
FAIL: g++.dg/warn/Wplacement-new-size.C  -std=gnu++17  (test for warnings, line 
128)
FAIL: g++.dg/warn/Wplacement-new-size.C  -std=gnu++2a  (test for warnings, line 
128)
FAIL: g++.dg/warn/Wplacement-new-size.C  -std=gnu++17 -fconcepts  (test for 
warnings, line 128)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++11  (test for bogus messages, line 
12)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++11 (test for excess errors)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++14  (test for bogus messages, line 
12)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++17  (test for bogus messages, line 
12)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++2a  (test for bogus messages, line 
12)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++2a (test for excess errors)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++17 -fconcepts  (test for bogus 
messages, line 12)
FAIL: c-c++-common/Waddress-1.c  -std=gnu++17 -fconcepts (test for excess 
errors)
FAIL: c-c++-common/Wsizeof-pointer-memaccess2.c  -std=gnu++98 (test for excess 
errors)
FAIL: c-c++-common/Wsizeof-pointer-memaccess2.c  -std=gnu++11 (test for excess 
errors)
FAIL: c-c++-common/Wsizeof-pointer-memaccess2.c  -std=gnu++14 (test for excess 
errors)
FAIL: c-c++-common/Wsizeof-pointer-memaccess2.c  -std=gnu++17 (test for excess 
errors)
FAIL: 

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

On Wed, Apr 18, 2018 at 5:32 AM, Uros Bizjak  wrote:
> On Wed, Apr 18, 2018 at 2:09 PM, Jakub Jelinek  wrote:
>> On Wed, Apr 18, 2018 at 02:04:50PM +0200, Jakub Jelinek wrote:
>>> On Wed, Apr 18, 2018 at 04:57:41AM -0700, H.J. Lu wrote:
>>> > On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak  wrote:
>>> > > On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu  wrote:
>>> > >
>>> >  Here is a patch to add -mnop and use it with -fcf-protection.
>>> > >>>
>>> > >>> +mnop
>>> > >>> +Target Report Var(flag_nop) Init(0)
>>> > >>> +Support multi-byte NOP code generation.
>>> > >>>
>>> > >>> the option name is incredibly bad and the documentation doesn't make 
>>> > >>> it
>>> > >>> better either.  The invoke.texi docs refer to duplicate {-mcet}.
>>> > >>>
>>> > >>> Isn't there a -fcf-protection sub-set that can be used to 
>>> > >>> automatically
>>> > >>> enable this?  Or simply do this mode by default when
>>> > >>> -fcf-protection is used but neither -mcet nor -mibt is enabled?
>>> > >>
>>> > >> Make -fcf-protection default to multi-byte NOPs works.  Uros,
>>> > >> should I prepare a patch?
>>> > >
>>> > > Please make it an opt-in feature, so the compiler won't litter the
>>> > > executable with unnecessary nops without user consent.
>>> > >
>>> >
>>> > -fcf-protection is off by default.  Users need to pass -fcf-protection
>>> > to enable it.  I will work on such a patch.
>>>
>>> That is not true.  When building gcc itself, config/cet.m4 makes
>>> -fcf-protection -mcet the default if assembler supports it.
>>> The request was to change --enable-cet configure option from having
>>> yes,no,default arguments with default autodetection and being a default
>>> if --enable-cet*/--disable-cet is not specified to say
>>> yes,no,auto arguments where no would be the default and auto would be the
>>> current default - enable it if as supports it, disable otherwise.
>>
>> So untested patch would be something like:
>
> Yes, this is what I think should be the most appropriate approach.
>
> Uros.
>
>> 2018-04-18  Jakub Jelinek  
>>
>> * config/cet.m4 (GCC_CET_FLAGS): Default to --disable-cet, replace
>> --enable-cet=default with --enable-cet=auto.
>>
>> * doc/install.texi: Document --disable-cet being the default and
>> --enable-cet=auto.
>>
>> --- gcc/config/cet.m4.jj2018-02-19 19:57:05.221280084 +0100
>> +++ gcc/config/cet.m4   2018-04-18 14:05:31.514859185 +0200
>> @@ -3,14 +3,14 @@ dnl GCC_CET_FLAGS
>>  dnl(SHELL-CODE_HANDLER)
>>  dnl
>>  AC_DEFUN([GCC_CET_FLAGS],[dnl
>> -GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
>> -  permit yes|no|default)
>> +GCC_ENABLE(cet, no, ,[enable Intel CET in target libraries],
>> +  permit yes|no|auto)
>>  AC_MSG_CHECKING([for CET support])
>>
>>  case "$host" in
>>i[[34567]]86-*-linux* | x86_64-*-linux*)
>>  case "$enable_cet" in
>> -  default)
>> +  auto)
>> # Check if target supports multi-byte NOPs
>> # and if assembler supports CET insn.
>> AC_COMPILE_IFELSE(
>> --- gcc/doc/install.texi.jj 2018-02-08 12:21:20.791749480 +0100
>> +++ gcc/doc/install.texi2018-04-18 14:07:19.637901528 +0200
>> @@ -2103,10 +2103,11 @@ instrumentation, see @option{-fcf-protec
>>  to add @option{-fcf-protection} and, if needed, other target
>>  specific options to a set of building options.
>>
>> -The option is enabled by default on Linux/x86 if target binutils
>> -supports @code{Intel CET} instructions.  In this case the target
>> -libraries are configured to get additional @option{-fcf-protection}
>> -and @option{-mcet} options.
>> +The option is disabled by default on Linux/x86.  When
>> +@code{--enable-cet=auto} is used, it is enabled if target binutils
>> +supports @code{Intel CET} instructions and disabled otherwise.
>> +In this case the target libraries are configured to get additional
>> +@option{-fcf-protection} and @option{-mcet} options.
>>  @end table
>>
>>  @subheading Cross-Compiler-Specific Options
>>
>>
>> Jakub

Looks good to me.

Thanks.

-- 
H.J.

Re: PING: [PATCH] i386: Insert ENDBR after __morestack call

[H.J. Lu]

On Wed, Apr 18, 2018 at 8:55 AM, H.J. Lu  wrote:
> On Wed, Apr 18, 2018 at 7:00 AM, Tsimbalist, Igor V
>  wrote:
>>> -Original Message-
>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>>> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
>>> Sent: Wednesday, April 18, 2018 3:25 PM
>>> To: GCC Patches ; Tsimbalist, Igor V
>>> 
>>> Cc: Uros Bizjak 
>>> Subject: PING: [PATCH] i386: Insert ENDBR after __morestack call
>>>
>>> On Fri, Apr 13, 2018 at 5:56 AM, H.J. Lu  wrote:
>>> > Since __morestack will jump back to its callee via indirect call, we
>>> > need to insert ENDBR after calling __morestack.
>>> >
>>> > OK for trunk?
>>> >
>>> > H.J.
>>> > 
>>> > gcc/
>>> >
>>> > PR target/85388
>>> > * config/i386/i386.c (ix86_expand_split_stack_prologue): Insert
>>> > ENDBR after calling __morestack.
>>> >
>>> > gcc/testsuite/
>>> >
>>> > PR target/85388
>>> > * gcc.dg/pr85388-1.c: New test.
>>> > * gcc.dg/pr85388-2.c: Likewise.
>>> > * gcc.dg/pr85388-3.c: Likewise.
>>> > * gcc.dg/pr85388-4.c: Likewise.
>>> > * gcc.dg/pr85388-5.c: Likewise.
>>> > * gcc.dg/pr85388-6.c: Likewise.
>>> > ---
>>> >  gcc/config/i386/i386.c   | 11 ++-
>>> >  gcc/testsuite/gcc.dg/pr85388-1.c | 50
>>> +
>>> >  gcc/testsuite/gcc.dg/pr85388-2.c | 56
>>> 
>>> >  gcc/testsuite/gcc.dg/pr85388-3.c | 65
>>> +
>>> >  gcc/testsuite/gcc.dg/pr85388-4.c | 69
>>> 
>>> >  gcc/testsuite/gcc.dg/pr85388-5.c | 54
>>> +++
>>> >  gcc/testsuite/gcc.dg/pr85388-6.c | 56
>>> 
>>> >  7 files changed, 360 insertions(+), 1 deletion(-)
>>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-1.c
>>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-2.c
>>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-3.c
>>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-4.c
>>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-5.c
>>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-6.c
>>> >
>>> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>>> > index 03e5c433574..8b4fd8ae30b 100644
>>> > --- a/gcc/config/i386/i386.c
>>> > +++ b/gcc/config/i386/i386.c
>>> > @@ -15242,7 +15242,16 @@ ix86_expand_split_stack_prologue (void)
>>> >   instruction--we need control flow to continue at the subsequent
>>> >   label.  Therefore, we use an unspec.  */
>>> >gcc_assert (crtl->args.pops_args < 65536);
>>> > -  emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
>>> > +  rtx_insn *ret_insn
>>> > += emit_insn (gen_split_stack_return (GEN_INT 
>>> > (crtl->args.pops_args)));
>>> > +
>>> > +  if ((flag_cf_protection & CF_BRANCH) && TARGET_IBT)
>>> > +{
>>> > +  /* Insert ENDBR since __morestack will jump back here via indirect
>>> > +call.  */
>>> > +  rtx cet_eb = gen_nop_endbr ();
>>> > +  emit_insn_after (cet_eb, ret_insn);
>>> > +}
>>> >
>>> >/* If we are in 64-bit mode and this function uses a static chain,
>>> >   we saved %r10 in %rax before calling _morestack.  */
>>>
>>> PING:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00669.html
>>>
>>
>> OK.
>
> I am going to check it in.
>

This is what I checked in.


-- 
H.J.
From 5cad7ddc0ee6f862414b411fae19516fe2f17e49 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Fri, 13 Apr 2018 05:27:09 -0700
Subject: [PATCH] i386: Insert ENDBR after __morestack call

Since __morestack will jump back to its callee via indirect call, we
need to insert ENDBR after calling __morestack.

gcc/

	PR target/85388
	* config/i386/i386.c (ix86_expand_split_stack_prologue): Insert
	ENDBR after calling __morestack.

gcc/testsuite/

	PR target/85388
	* gcc.dg/pr85388-1.c: New test.
	* gcc.dg/pr85388-2.c: Likewise.
	* gcc.dg/pr85388-3.c: Likewise.
	* gcc.dg/pr85388-4.c: Likewise.
	* gcc.dg/pr85388-5.c: Likewise.
	* gcc.dg/pr85388-6.c: Likewise.
---
 gcc/config/i386/i386.c   | 11 ++-
 gcc/testsuite/gcc.dg/pr85388-1.c | 50 +
 gcc/testsuite/gcc.dg/pr85388-2.c | 56 
 gcc/testsuite/gcc.dg/pr85388-3.c | 65 +
 gcc/testsuite/gcc.dg/pr85388-4.c | 69 
 gcc/testsuite/gcc.dg/pr85388-5.c | 54 +++
 gcc/testsuite/gcc.dg/pr85388-6.c | 56 
 7 files changed, 360 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr85388-1.c
 create mode 100644 gcc/testsuite/gcc.dg/pr85388-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr85388-3.c
 create mode 100644 gcc/testsuite/gcc.dg/pr85388-4.c
 create mode 100644 

Re: [PATCH][i386] Adding MOVDIRI and MOVDIR64B instructions

[Uros Bizjak]

On Wed, Apr 18, 2018 at 2:56 PM, Peryt, Sebastian
 wrote:
> Hi,
>
> This patch enables new instructions - MOVDIRI and MOVDIR64B.
>
> Is it ok for trunk?

Is there a reason that one flag goes to ix86_isa_flags and the other
to ix86_isa_flags2?

Uros.

> 2018-04-18  Sebastian Peryt  
>
> gcc/
>
> * common/config/i386/i386-common.c
> (OPTION_MASK_ISA_MOVDIRI_SET, OPTION_MASK_ISA_MOVDIR64B_SET,
> OPTION_MASK_ISA_MOVDIRI_UNSET,
> OPTION_MASK_ISA_MOVDIR64B_UNSET): New defines.
> (ix86_handle_option): Handle -mmovdiri and -mmovdir64b.
> * config.gcc (movdirintrin.h): New header.
> * config/i386/cpuid.h (bit_MOVDIRI,
> bit_MOVDIR64B): New bits.
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect -mmovdiri
> and -mmvodir64b.
> * config/i386/i386-builtin-types.def ((VOID, PUNSIGNED, UNSIGNED),
> (VOID, PVOID, PCVOID)): New function types.
> * config/i386/i386-builtin.def (__builtin_ia32_directstoreu_u32,
> __builtin_ia32_directstoreu_u64, __builtin_ia32_movdir64b): New 
> builtins.
> * config/i386/i386-c.c (__MOVDIRI__, __MOVDIR64B__): New.
> * config/i386/i386.c (ix86_target_string): Added -mmovdir64b and 
> -mmovdiri.
> (ix86_valid_target_attribute_inner_p): Ditto.
> (ix86_expand_special_args_builtin):  Added 
> VOID_FTYPE_PUNSIGNED_UNSIGNED
> and VOID_FTYPE_PUNSIGNED_UNSIGNED.
> (ix86_expand_builtin): Expand IX86_BUILTIN_MOVDIR64B.
> * config/i386/i386.h (TARGET_MOVDIRI, TARGET_MOVDIRI_P,
> TARGET_MOVDIR64B, TARGET_MOVDIR64B_P): New.
> * config/i386/i386.md (UNSPECV_MOVDIRI, UNSPECV_MOVDIR64B): New.
> (movdiri, movdir64b_): New.
> * config/i386/i386.opt: Add -mmovdiri and -mmovdir64b.
> * config/i386/immintrin.h: Include movdirintrin.h.
> * config/i386/movdirintrin.h: New file.
> * doc/invoke.texi: Added -mmovdiri and -mmovdir64b.
>
> 2018-04-18  Sebastian Peryt  
>
> gcc/testsuite/
>
> * gcc.target/i386/movdir-1.c: New test.
>
>
> Thanks,
> Sebastian

[GCC-9 PATCH, i386]: Emit inter-unit moves using preferred_for_speed infrastructure

[Uros Bizjak]

Hello!

Attached patch conditionally emits inter-unit moves using
preferred_for_speed_infrastructure. Current approach, where registers
are enabled only for TARGET_INTER_UNIT_MOVES_{FROM,TO}_VEC is not
optimal, since for non-performance critical parts of the binary, we
can still emit inter-unit moves, shaving a couple of bytes here and
there.

2018-04-18  Uros Bizjak  

* config/i386/i386.md ("isa" attribute): Add x64_sse2.
("enabled" attribute): Handle "isa" attribute.
(*movdi_internal): Substitute Yi and Yj constraint with x
and Ym and Yn constraint with y constraint.  Update "isa"
attribute and set "preferred_for_speed" attribute from
TARGET_INTER_UNIT_MOVES_{FROM,TO}_VEC for updated alternatives.
(*movsi_internal): Ditto.
(*movdf_internal): Ditto.
(*movsf_internal): Ditto.
(*zero_extendsidi2): Ditto.
* config/i386/sse.md (vec_set_0): Ditto.
(sse2_loadld): Ditto.
(*vec_extract_0): Ditto.
(*vec_extractv4si_0_zext_sse4): Ditto.
(vec_concatv2di): Ditto.
(*vec_dup): Ditto.
* config/i386/mmx.md (*mov_internal): Ditto.
* config/i386/constraints.md (Yi): Remove.
(Yj): Remove.
(Ym): Remove.
(Yn): Remove.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

I plan to commit the patch to gcc-9 when it opens for general development.

Uros.
diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index f9564d3a385c..e750dc4cec74 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -99,14 +99,10 @@
 
 ;; We use the Y prefix to denote any number of conditional register sets:
 ;;  z  First SSE register.
-;;  i  SSE2 inter-unit moves to SSE register enabled
-;;  j  SSE2 inter-unit moves from SSE register enabled
 ;;  d  any EVEX encodable SSE register for AVX512BW target or any SSE register
 ;; for SSE4_1 target, when inter-unit moves to SSE register are enabled
 ;;  e  any EVEX encodable SSE register for AVX512BW target or any SSE register
 ;; for SSE4_1 target, when inter-unit moves from SSE register are enabled
-;;  m  MMX inter-unit moves to MMX register enabled
-;;  n  MMX inter-unit moves from MMX register enabled
 ;;  p  Integer register when TARGET_PARTIAL_REG_STALL is disabled
 ;;  a  Integer register when zero extensions with AND are disabled
 ;;  b  Any register that can be used as the GOT base when calling
@@ -123,14 +119,6 @@
 (define_register_constraint "Yz" "TARGET_SSE ? SSE_FIRST_REG : NO_REGS"
  "First SSE register (@code{%xmm0}).")
 
-(define_register_constraint "Yi"
- "TARGET_SSE2 && TARGET_INTER_UNIT_MOVES_TO_VEC ? ALL_SSE_REGS : NO_REGS"
- "@internal Any SSE register, when SSE2 and inter-unit moves to vector 
registers are enabled.")
-
-(define_register_constraint "Yj"
- "TARGET_SSE2 && TARGET_INTER_UNIT_MOVES_FROM_VEC ? ALL_SSE_REGS : NO_REGS"
- "@internal Any SSE register, when SSE2 and inter-unit moves from vector 
registers are enabled.")
-
 (define_register_constraint "Yd"
  "TARGET_INTER_UNIT_MOVES_TO_VEC
   ? (TARGET_AVX512DQ
@@ -147,14 +135,6 @@
   : NO_REGS"
  "@internal Any EVEX encodable SSE register (@code{%xmm0-%xmm31}) for AVX512DQ 
target or any SSE register for SSE4_1 target, when inter-unit moves from vector 
registers are enabled.")
 
-(define_register_constraint "Ym"
- "TARGET_MMX && TARGET_INTER_UNIT_MOVES_TO_VEC ? MMX_REGS : NO_REGS"
- "@internal Any MMX register, when inter-unit moves to vector registers are 
enabled.")
-
-(define_register_constraint "Yn"
- "TARGET_MMX && TARGET_INTER_UNIT_MOVES_FROM_VEC ? MMX_REGS : NO_REGS"
- "@internal Any MMX register, when inter-unit moves from vector registers are 
enabled.")
-
 (define_register_constraint "Yp"
  "TARGET_PARTIAL_REG_STALL ? NO_REGS : GENERAL_REGS"
  "@internal Any integer register when TARGET_PARTIAL_REG_STALL is disabled.")
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 95ca2cf9e3d6..285ad3c9d61f 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -810,7 +810,7 @@
 (define_attr "movu" "0,1" (const_string "0"))
 
 ;; Used to control the "enabled" attribute on a per-instruction basis.
-(define_attr "isa" "base,x64,x64_sse4,x64_sse4_noavx,x64_avx,nox64,
+(define_attr "isa" "base,x64,x64_sse2,x64_sse4,x64_sse4_noavx,x64_avx,nox64,
sse2,sse2_noavx,sse3,sse4,sse4_noavx,avx,noavx,
avx2,noavx2,bmi,bmi2,fma4,fma,avx512f,noavx512f,
avx512bw,noavx512bw,avx512dq,noavx512dq,
@@ -819,6 +819,8 @@
 
 (define_attr "enabled" ""
   (cond [(eq_attr "isa" "x64") (symbol_ref "TARGET_64BIT")
+(eq_attr "isa" "x64_sse2")
+  (symbol_ref "TARGET_64BIT && TARGET_SSE2")
 (eq_attr "isa" "x64_sse4")
   (symbol_ref "TARGET_64BIT && TARGET_SSE4_1")
 (eq_attr "isa" "x64_sse4_noavx")
@@ -2221,9 +2223,9 @@
 
 (define_insn "*movdi_internal"
   [(set (match_operand:DI 0 "nonimmediate_operand"
-"=r  ,o  ,r,r  ,r,m ,*y,*y,?*y,?m,?r 

Re: [PATCH 2/5] [ARC] Fix FLS, SETI patterns.

[Andrew Burgess]

* Claudiu Zissulescu  [2018-04-06 11:00:11 
+0200]:

> From: claziss 
> 
> Claudiu Zissulescu  
> 
>   * config/arc/arc.md ("vunspec"): Delete it, unify all the unspec
>   enums into a single definition.
>   (fls): Fix predicates and printing.
>   (seti): Likewise.

Looks good,

Thanks,
Andrew

> ---
>  gcc/config/arc/arc.md | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
> index 2ec2b48..ffd9d5b 100644
> --- a/gcc/config/arc/arc.md
> +++ b/gcc/config/arc/arc.md
> @@ -137,9 +137,7 @@
>UNSPEC_ARC_VMPY2H
>UNSPEC_ARC_VMPY2HU
>UNSPEC_ARC_STKTIE
> -  ])
>  
> -(define_c_enum "vunspec" [
>VUNSPEC_ARC_RTIE
>VUNSPEC_ARC_SYNC
>VUNSPEC_ARC_BRK
> @@ -5818,21 +5816,19 @@ archs4x, archs4xd, archs4xd_slow"
> })
>  
>  (define_insn "fls"
> -  [(set (match_operand:SI  0 "dest_reg_operand" "=w,w")
> - (unspec:SI [(match_operand:SI 1 "general_operand" "cL,Cal")]
> +  [(set (match_operand:SI  0 "register_operand" "=r,r")
> + (unspec:SI [(match_operand:SI 1 "nonmemory_operand" "rL,Cal")]
>   UNSPEC_ARC_FLS))]
>"TARGET_NORM && TARGET_V2"
> -  "@
> -   fls \t%0, %1
> -   fls \t%0, %1"
> +  "fls\\t%0,%1"
>[(set_attr "length" "4,8")
> (set_attr "type" "two_cycle_core,two_cycle_core")])
>  
>  (define_insn "seti"
> -  [(unspec_volatile:SI [(match_operand:SI 0 "general_operand" "rL")]
> +  [(unspec_volatile:SI [(match_operand:SI 0 "nonmemory_operand" "rL")]
>  VUNSPEC_ARC_SETI)]
>"TARGET_V2"
> -  "seti  %0"
> +  "seti\\t%0"
>[(set_attr "length" "4")
> (set_attr "type" "misc")])
>  
> -- 
> 1.9.1
> 

Re: ping [PATCH] Fix trunk failing to build for msp430-elf

[DJ Delorie]

The testsuite parts are OK with me, but the tree.c change needs
separate approval...

Re: [PATCH 1/5] [ARC] Update sleep builtin.

[Andrew Burgess]

* Claudiu Zissulescu  [2018-04-06 11:00:10 
+0200]:

> From: claziss 
> 
> gcc/
> 2017-05-09  Claudiu Zissulescu  
> 
>   * config/arc/arc-protos.h (check_if_valid_sleep_operand): Remove.
>   * config/arc/arc.c (arc_expand_builtin): Sleep accepts registers
>   and short u6 immediate.
>   (check_if_valid_sleep_operand): Remove.
>   * config/arc/arc.md (Sleep): Accepts registers and u6 immediates.
> ---
>  gcc/config/arc/arc-protos.h |  1 -
>  gcc/config/arc/arc.c| 26 --
>  gcc/config/arc/arc.md   |  4 ++--
>  3 files changed, 2 insertions(+), 29 deletions(-)

Looks good.

Thanks,
Andrew

> 
> diff --git a/gcc/config/arc/arc-protos.h b/gcc/config/arc/arc-protos.h
> index 75cfeda..0ba6871 100644
> --- a/gcc/config/arc/arc-protos.h
> +++ b/gcc/config/arc/arc-protos.h
> @@ -59,7 +59,6 @@ void arc_asm_output_aligned_decl_local (FILE *, tree, const 
> char *,
>   unsigned HOST_WIDE_INT);
>  extern rtx arc_return_addr_rtx (int , rtx);
>  extern bool check_if_valid_regno_const (rtx *, int);
> -extern bool check_if_valid_sleep_operand (rtx *, int);
>  extern bool arc_legitimate_constant_p (machine_mode, rtx);
>  extern bool arc_legitimate_pic_addr_p (rtx);
>  extern bool arc_raw_symbolic_reference_mentioned_p (rtx, bool);
> diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> index 3564696..47d3ba4 100644
> --- a/gcc/config/arc/arc.c
> +++ b/gcc/config/arc/arc.c
> @@ -6573,11 +6573,6 @@ arc_expand_builtin (tree exp,
>fold (arg0);
>op0 = expand_expr (arg0, NULL_RTX, VOIDmode, EXPAND_NORMAL);
>  
> -  if  (!CONST_INT_P (op0) || !satisfies_constraint_L (op0))
> - {
> -   error ("builtin operand should be an unsigned 6-bit value");
> -   return NULL_RTX;
> - }
>gcc_assert (icode != 0);
>emit_insn (GEN_FCN (icode) (op0));
>return NULL_RTX;
> @@ -6925,27 +6920,6 @@ check_if_valid_regno_const (rtx *operands, int opno)
>return false;
>  }
>  
> -/* Check that after all the constant folding, whether the operand to
> -   __builtin_arc_sleep is an unsigned int of 6 bits.  If not, flag an error. 
>  */
> -
> -bool
> -check_if_valid_sleep_operand (rtx *operands, int opno)
> -{
> -  switch (GET_CODE (operands[opno]))
> -{
> -case CONST :
> -case CONST_INT :
> - if( UNSIGNED_INT6 (INTVAL (operands[opno])))
> - return true;
> -/* FALLTHRU */
> -default:
> - fatal_error (input_location,
> -  "operand for sleep instruction must be an unsigned 6 bit 
> compile-time constant");
> - break;
> -}
> -  return false;
> -}
> -
>  /* Return true if it is ok to make a tail-call to DECL.  */
>  
>  static bool
> diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
> index fb34329..2ec2b48 100644
> --- a/gcc/config/arc/arc.md
> +++ b/gcc/config/arc/arc.md
> @@ -4794,9 +4794,9 @@ archs4x, archs4xd, archs4xd_slow"
>  
>  
>  (define_insn "sleep"
> -  [(unspec_volatile [(match_operand:SI 0 "immediate_operand" "L")]
> +  [(unspec_volatile [(match_operand:SI 0 "nonmemory_operand" "Lr")]
>  VUNSPEC_ARC_SLEEP)]
> -  "check_if_valid_sleep_operand(operands,0)"
> +  ""
>"sleep %0"
>[(set_attr "length" "4")
>(set_attr "type" "misc")])
> -- 
> 1.9.1
> 

Re: [PATCH] PR 83402 Fix ICE for vec_splat_s8, vec_splat_s16, vec_splat_s32 builtins

[Carl Love]

GCC Maintainers:

I have addressed Segher's concerns regarding the range checking of the
argument.  The following is the updated patch.  

The regression testing for the patch was done on GCC mainline on 

    powerpc64le-unknown-linux-gnu (Power 8 LE)

with no regressions.  Additional hand testing was done on the following
test cases to verify the range checking was working.

vec_splat_u8 (0xfffe);
vec_splat_u8 (0x7e);
vec_splat_u8 (0xfe);
vec_splat_u16 (0xfffe);
vec_splat_u16 (0x7ffe);
vec_splat_u16 (0xfffe);
vec_splat_u16 (-2);
vec_splat_u32 (0xfffe);
vec_splat_u32 (0xeffe);
vec_splat_s32 (16);
vec_splat_s32 (15);
vec_splat_s32 (-16);
vec_splat_s32 (-17);
vec_splat_s8 (16);
vec_splat_s8 (15);
vec_splat_s8 (1);
vec_splat_s8 (-1);
vec_splat_s8 (-16);
vec_splat_s8 (-17);

Please let me know if the patch looks OK for the GCC 7 branch.

 Carl Love
--

gcc/ChangeLog:

2018-04-17  Carl Love  

PR target/83402
* config/rs6000/rs6000-c.c (rs6000_gimple_fold_builtin): Add
size check for arg0.
---
 gcc/config/rs6000/rs6000.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a0c9b5c..6b8039d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -16574,10 +16574,23 @@ rs6000_gimple_fold_builtin
(gimple_stmt_iterator *gsi)
 case ALTIVEC_BUILTIN_VSPLTISH:
 case ALTIVEC_BUILTIN_VSPLTISW:
   {
+    int size;
+
+ if (fn_code == ALTIVEC_BUILTIN_VSPLTISB)
+   size = 8;
+ else if (fn_code == ALTIVEC_BUILTIN_VSPLTISH)
+   size = 16;
+ else
+   size = 32;
+
     arg0 = gimple_call_arg (stmt, 0);
     lhs = gimple_call_lhs (stmt);
-    /* Only fold the vec_splat_*() if arg0 is constant.  */
-    if (TREE_CODE (arg0) != INTEGER_CST)
+
+    /* Only fold the vec_splat_*() if the lower bits of arg 0 is
a
+   5-bit signed constant in range -16 to +15.  */
+    if (TREE_CODE (arg0) != INTEGER_CST
+    || !IN_RANGE (sext_hwi(TREE_INT_CST_LOW (arg0), size),
+      -16, 15))
       return false;
     gimple_seq stmts = NULL;
     location_t loc = gimple_location (stmt);
-- 
2.7.4

Re: [PATCH] Fix UB in dbxout.c (PR debug/84637)

[Jeff Law]

On 04/17/2018 02:54 PM, Jakub Jelinek wrote:
> Hi!
> 
> The first hunk is I think rather obvious, -2147483648 should be printed
> as -2147483648 and doesn't need to introduce UB in the compiler while doing
> so.  The changes to stabstr_D are analogous, but in addition to that I don't
> see why we should just strip away the upper bits, it is again just a string
> containing decimal digits.  What that function implemented is that
> values from -4294967295 to 4294967295 were printed as expected and the rest
> had some bits lost and HOST_WIDE_INT signed minimum invoked UB.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-04-17  Jakub Jelinek  
> 
>   PR debug/84637
>   * dbxout.c (dbxout_int): Perform negation in unsigned int type.
>   (stabstr_D): Change type of unum from unsigned int to
>   unsigned HOST_WIDE_INT.  Perform negation in unsigned HOST_WIDE_INT
>   type.
OK.
jeff

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Michael Eager]

On 04/18/2018 05:44 AM, Andrew Sadek wrote:

Hello Michael,

I have attached the patch as well,
(the same as in :
https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/PATCH_BUNDLE/gcc.patch)

On Thu, Mar 22, 2018 at 8:37 PM, Andrew Sadek  wrote:

Hello Michael,

I have adapted the test cases.

Please find the patch below with Change log, description and test results.

Description:
--

This branch is regarding a new implemented feature in GCC Microblaze
that allows Position Independent Code to run using Data Text Relative
addressing instead of using Global Offset Table.

Its aim was to make 'PIC' more efficient and flexible as elf size
excess/ performance overhead were noticed when using GOT due to the
indirect addressing.
The change was tested with the dhrystone benchmark on a real Hardware
(Xilinx FPGA Spartan 6) and the test report went successfully for all
optimization levels.

Indeed, Microblaze does not support PC-relative addressing in Hardware like ARM.
The idea was to store the start address of current text section in
'r20' instead of GOT, in the function prologue. Correspondingly, data
references will be an offset from the original reference value to the
start of text thus being added to the 'r20' base register will resolve
the actual address.

Henceforth, 2 new relocations have been created:
- 'R_MICROBLAZE_TEXTPCREL_64': resolves offset of current PC to start
of text in order to set r20
- 'R_MICROBLAZE_TEXTREL_64': resolves offset of mentioned data
reference to start of text

Accordingly, both assembler and linker (binutils) have been adapted.

For extra details:
https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md

Change Log:
-

2018-03-22 Andrew Sadek  

 Microblaze Target: PIC data text relative
 * gcc/config/microblaze/microblaze.opt: add new option
-mpic-data-text-rel.
 * gcc/config/microblaze/microblaze-protos.h 
(microblaze_constant_address_p):
 Add microblaze_constant_address_p function instead of the macro in
microblaze.h
 * gcc/config/microblaze/microblaze.c (TARGET_PIC_DATA_TEXT_REL):
New addressing mode
 for data-text relative position indepenedent code.
 (microblaze_classify_unspec): add 'UNSPEC_TEXT' case ->
'ADDRESS_SYMBOLIC_TXT_REL'.
 (microblaze_classify_address): add handling for UNSPEC + CONST_INT.
 (microblaze_legitimate_pic_operand): exclude function calls from
pic operands
 in case of TARGET_PIC_DATA_TEXT_REL option.
 (microblaze_legitimize_address): generate 'UNSPEC_TEXT' for all possible
 addresses cases.
 (microblaze_address_insns): add 'ADDRESS_SYMBOLIC_TXT_REL' case.
 (print_operand): add 'ADDRESS_SYMBOLIC_TXT_REL' case.
 (print_operand_address): add 'ADDRESS_SYMBOLIC_TXT_REL' case + handling for
 'address + offset'.
 (microblaze_expand_prologue): add new function prologue call for
'r20' assignation.
 (microblaze_asm_generate_pic_addr_dif_vec): override new target hook
'TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC' to disable address diff vector
 table in case of TARGET_PIC_DATA_TEXT_REL.
 (expand_pic_symbol_ref): add handling for 'UNSPEC_TEXT'.
 * gcc/config/microblaze/microblaze.md (TARGET_PIC_DATA_TEXT_REL):
Add new macros 'UNSPEC_TEXT',
 'UNSPEC_SET_TEXT' + add rule for setting r20 in function prologue
+ exclude function calls
 from 'UNSPEC_PLT' in case of data text relative mode.
 * gcc/doc/tm.texi.in (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): Add
new target hook for generating
 address diff vector tables in case of flag_pic.
 * gcc/doc/tm.texi : Regenerate.
 * gcc/stmt.c (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): append new condition
 'targetm.asm_out.generate_pic_addr_diff_vec' to flag_pic in case
of addr diff vector generation.
 * gcc/target.def (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): add
target hook definition.
 * gcc/targhooks.h, gcc/targhooks.c (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC):
 add default function for generate_pic_addr_diff_vec -> flag_pic.
 * gcc/doc/invoke.texi (Add new pic option): Add new microblaze pic
option for data text relative.


Hi Andrew --

Check indents in the following files:
(Make sure that your tabs are set at 8 chars.)
--- gcc/config/microblaze/microblaze.c  
--- gcc/config/microblaze/microblaze.md 

Just a couple coding notes:

microblaze.c:

@@ -858,6 +879,16 @@ microblaze_classify_address (struct microblaze_add
+   && strict == 2)

Include comment in function header describing meaning of strict == 2.


@@ -1022,7 +1065,7 @@ microblaze_legitimize_address (rtx x, rtx oldx ATT
  else if (flag_pic == 2 && !TARGET_PIC_DATA_TEXT_REL)
{
  ...
}
  else if (flag_pic == 2 && TARGET_PIC_DATA_TEXT_REL)
{
  ...
}

It's better to factor this into
 else if (flag_pic == 2)
   {
 

ping [PATCH] Fix trunk failing to build for msp430-elf

[Jozef Lawrynowicz]

ping x1

Trunk doesn't build for msp430 due to an ICE whilst building libstdc++.

The following patch proposed a while ago fixes the issue, but hasn't been
applied: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01433.html

I don't have write access, so if the patch is acceptable I would 
appreciate

if someone could commit it for me. Thanks.

Re: PING: [PATCH] i386: Insert ENDBR after __morestack call

[H.J. Lu]

On Wed, Apr 18, 2018 at 7:00 AM, Tsimbalist, Igor V
 wrote:
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
>> Sent: Wednesday, April 18, 2018 3:25 PM
>> To: GCC Patches ; Tsimbalist, Igor V
>> 
>> Cc: Uros Bizjak 
>> Subject: PING: [PATCH] i386: Insert ENDBR after __morestack call
>>
>> On Fri, Apr 13, 2018 at 5:56 AM, H.J. Lu  wrote:
>> > Since __morestack will jump back to its callee via indirect call, we
>> > need to insert ENDBR after calling __morestack.
>> >
>> > OK for trunk?
>> >
>> > H.J.
>> > 
>> > gcc/
>> >
>> > PR target/85388
>> > * config/i386/i386.c (ix86_expand_split_stack_prologue): Insert
>> > ENDBR after calling __morestack.
>> >
>> > gcc/testsuite/
>> >
>> > PR target/85388
>> > * gcc.dg/pr85388-1.c: New test.
>> > * gcc.dg/pr85388-2.c: Likewise.
>> > * gcc.dg/pr85388-3.c: Likewise.
>> > * gcc.dg/pr85388-4.c: Likewise.
>> > * gcc.dg/pr85388-5.c: Likewise.
>> > * gcc.dg/pr85388-6.c: Likewise.
>> > ---
>> >  gcc/config/i386/i386.c   | 11 ++-
>> >  gcc/testsuite/gcc.dg/pr85388-1.c | 50
>> +
>> >  gcc/testsuite/gcc.dg/pr85388-2.c | 56
>> 
>> >  gcc/testsuite/gcc.dg/pr85388-3.c | 65
>> +
>> >  gcc/testsuite/gcc.dg/pr85388-4.c | 69
>> 
>> >  gcc/testsuite/gcc.dg/pr85388-5.c | 54
>> +++
>> >  gcc/testsuite/gcc.dg/pr85388-6.c | 56
>> 
>> >  7 files changed, 360 insertions(+), 1 deletion(-)
>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-1.c
>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-2.c
>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-3.c
>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-4.c
>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-5.c
>> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-6.c
>> >
>> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> > index 03e5c433574..8b4fd8ae30b 100644
>> > --- a/gcc/config/i386/i386.c
>> > +++ b/gcc/config/i386/i386.c
>> > @@ -15242,7 +15242,16 @@ ix86_expand_split_stack_prologue (void)
>> >   instruction--we need control flow to continue at the subsequent
>> >   label.  Therefore, we use an unspec.  */
>> >gcc_assert (crtl->args.pops_args < 65536);
>> > -  emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
>> > +  rtx_insn *ret_insn
>> > += emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
>> > +
>> > +  if ((flag_cf_protection & CF_BRANCH) && TARGET_IBT)
>> > +{
>> > +  /* Insert ENDBR since __morestack will jump back here via indirect
>> > +call.  */
>> > +  rtx cet_eb = gen_nop_endbr ();
>> > +  emit_insn_after (cet_eb, ret_insn);
>> > +}
>> >
>> >/* If we are in 64-bit mode and this function uses a static chain,
>> >   we saved %r10 in %rax before calling _morestack.  */
>>
>> PING:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00669.html
>>
>
> OK.

I am going to check it in.

Thanks.

-- 
H.J.

Re: [RFC PATCHES] Obsolete or remove powerpc*-*-*spe* support (PR target/81084)

[Jeff Law]

On 04/18/2018 01:51 AM, Richard Biener wrote:
> On Tue, 17 Apr 2018, Jakub Jelinek wrote:
> 
>> Hi!
>>
>> In the http://gcc.gnu.org/ml/gcc/2017-02/msg00041.html
>> thread it has been proposed that powerpc*-*-*spe* would be obsoleted in
>> GCC 7, which didn't happen and the rs6000 backend has been split into two,
>> one actively maintained where the SPE support has been removed, and the
>> other one which unfortunately had just a few small commits, didn't get rid
>> of the expected 80% of the new backend which would make it deal with it
>> for global changes in GCC, nor has the bugfixes added to rs6000 backend in
>> the last 11 months since the split (many of them apply to powerpcspe too).
>>
>> So, in order to resolve the P1 PR81084, I think we should at least make the
>> powerpc*-*-*spe* obsolete for GCC 8 and remove in GCC 9 if it doesn't get
>> significantly better soon (the first patch), or remove it altogether now,
>> which would match the deal that either the port is cleaned up, or it is
>> removed (the second patch).  In addition to this some changes.html
>> changes will be needed depending on what is chosen.
>>
>> Preferences on what to do?
> 
> I think I prefer the first for GCC8 and remove it early in stage1 if
> people don't get their asses moved.
Agreed.  Similarly for MPX.
jeff

Re: [PATCH] Fix UB in dse.c (PR rtl-optimization/85431)

[Jeff Law]

On 04/17/2018 02:57 PM, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned, for BLKmode stores with MEM_SIZE of 0 we invoke UB,
> lowpart_bitmask (0) is called and that shifts an UHWI by 64.
> Zero size MEMs should only appear in inline asm and shouldn't be interesting
> to DSE at all, they can't make other stores dead, nor can be removed as dead
> themselves.
> 
> Fixed by just ignoring them.  Bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?
> 
> 2018-04-17  Jakub Jelinek  
> 
>   PR rtl-optimization/85431
>   * dse.c (record_store): Ignore zero width stores.
OK.
jeff

RE: [PATCH 2/2] MIPS/GCC/testsuite: Fix data-sym-pool.c for n64 code

[Matthew Fortune]

Maciej Rozycki  writes:
> (we have no support for hard-float n64 MIPS16 code generation), which
> means that the test case will fail, as the regular expression pattern
> expects `lw' and `.word' rather than `ld' and `.dword' respectively to
> appear in assembly code generation.  Correct the pattern in an obvious
> way then making it accept both intructions and pseudo-ops.
> 
>   gcc/testsuite/
>   * gcc.target/mips/data-sym-pool.c (dg-options): Match `ld' and
>   `.dword' in addition to `lw' and `.word'.
> ---
> Hi,
> 
>  I have regression-tested this with the `mips-mti-linux-gnu' target and
> the o32 ABI.  I don't have an n64 soft-float multilib configured, so the
> manually generated assembly file included with the description serves as
> the proof for what needs to be matched.
> 
>  OK to apply?

Hi Maciej,

Apologies as before on slowness. This looks trivially OK to me but that's
thanks to the description, much appreciated.

OK for commit but adding RMs given the imminent release.

Thanks,
Matthew

RE: [PATCH 1/2] MIPS/GCC/testsuite: Fix data-sym-pool.c for SVR4 model at -O0

[Matthew Fortune]

Maciej Rozycki  writes:
> Given that the SVR4 vs PLT code model consideration is irrelevant for
> this test case rather than rewriting the regular expression to match
> this variant of code just enforce the PLT model by using the `-mplt'
> option.  It is safe to use this option unconditionally as it is silently
> ignored with configurations that do not support this model, e.g. bare
> metal ELF.
> 
>   gcc/testsuite/
>   * gcc.target/mips/data-sym-pool.c (dg-options): Add `-mplt'.
> ---
> Hi,
> 
>  I have regression-tested this with the `mips-mti-linux-gnu' target and
> the o32, n32 and n64 ABIs.  The two latters are demoted to o64 by the
> test framework due to the lack of MIPS16 support for the hard-float
> variants of these ABIs and I don't have soft-float multilibs configured,
> so instead I have verified n32/soft-float and n64/soft-float variants by
> hand.  The latter revealed the need for 2/2.
> 
>  Finally I do not have a bare metal ELF configuration available for
> regression-testing right now, so I only verified that `-mplt' is
> silently ignored.  Code generated is expected to be the same as in the
> PLT mode.
> 
>  OK to apply?

Hi Maciej,

Sorry for skimming past this and being slow to respond. I agree with your
choice of forcing an option to stabilise the generated code it does tend
to future proof better than leaving options floating.

OK to apply but given the release date I've added RMs to approve for
trunk right now.

Thanks,
Matthew

Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Jakub Jelinek]

On Wed, Apr 18, 2018 at 02:59:34PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 05:07:33AM +, Jason Merrill wrote:
> > I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.

As for reinterpret_cast, we e.g. accept
constexpr int a = reinterpret_cast (1);
which clang++ rejects, shouldn't we simply in build_reinterpret_cast_1
when not returning error_mark_node wrap the return value inside some new
FE tree (or reuse REINTERPRET_CAST_EXPR) and remove it only during
genericization, so that we can reliably reject those in constexpr handling,
perhaps only if not !ctx->quiet?

Jakub

RE: PING: [PATCH] i386: Insert ENDBR after __morestack call

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Wednesday, April 18, 2018 3:25 PM
> To: GCC Patches ; Tsimbalist, Igor V
> 
> Cc: Uros Bizjak 
> Subject: PING: [PATCH] i386: Insert ENDBR after __morestack call
> 
> On Fri, Apr 13, 2018 at 5:56 AM, H.J. Lu  wrote:
> > Since __morestack will jump back to its callee via indirect call, we
> > need to insert ENDBR after calling __morestack.
> >
> > OK for trunk?
> >
> > H.J.
> > 
> > gcc/
> >
> > PR target/85388
> > * config/i386/i386.c (ix86_expand_split_stack_prologue): Insert
> > ENDBR after calling __morestack.
> >
> > gcc/testsuite/
> >
> > PR target/85388
> > * gcc.dg/pr85388-1.c: New test.
> > * gcc.dg/pr85388-2.c: Likewise.
> > * gcc.dg/pr85388-3.c: Likewise.
> > * gcc.dg/pr85388-4.c: Likewise.
> > * gcc.dg/pr85388-5.c: Likewise.
> > * gcc.dg/pr85388-6.c: Likewise.
> > ---
> >  gcc/config/i386/i386.c   | 11 ++-
> >  gcc/testsuite/gcc.dg/pr85388-1.c | 50
> +
> >  gcc/testsuite/gcc.dg/pr85388-2.c | 56
> 
> >  gcc/testsuite/gcc.dg/pr85388-3.c | 65
> +
> >  gcc/testsuite/gcc.dg/pr85388-4.c | 69
> 
> >  gcc/testsuite/gcc.dg/pr85388-5.c | 54
> +++
> >  gcc/testsuite/gcc.dg/pr85388-6.c | 56
> 
> >  7 files changed, 360 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-1.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-2.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-3.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-4.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-5.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-6.c
> >
> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > index 03e5c433574..8b4fd8ae30b 100644
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -15242,7 +15242,16 @@ ix86_expand_split_stack_prologue (void)
> >   instruction--we need control flow to continue at the subsequent
> >   label.  Therefore, we use an unspec.  */
> >gcc_assert (crtl->args.pops_args < 65536);
> > -  emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
> > +  rtx_insn *ret_insn
> > += emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
> > +
> > +  if ((flag_cf_protection & CF_BRANCH) && TARGET_IBT)
> > +{
> > +  /* Insert ENDBR since __morestack will jump back here via indirect
> > +call.  */
> > +  rtx cet_eb = gen_nop_endbr ();
> > +  emit_insn_after (cet_eb, ret_insn);
> > +}
> >
> >/* If we are in 64-bit mode and this function uses a static chain,
> >   we saved %r10 in %rax before calling _morestack.  */
> 
> PING:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00669.html
> 

OK.

Igor

> 
> --
> H.J.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Jakub Jelinek]

On Wed, Apr 18, 2018 at 04:57:41AM -0700, H.J. Lu wrote:
> On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak  wrote:
> > On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu  wrote:
> >
>  Here is a patch to add -mnop and use it with -fcf-protection.
> >>>
> >>> +mnop
> >>> +Target Report Var(flag_nop) Init(0)
> >>> +Support multi-byte NOP code generation.
> >>>
> >>> the option name is incredibly bad and the documentation doesn't make it
> >>> better either.  The invoke.texi docs refer to duplicate {-mcet}.
> >>>
> >>> Isn't there a -fcf-protection sub-set that can be used to automatically
> >>> enable this?  Or simply do this mode by default when
> >>> -fcf-protection is used but neither -mcet nor -mibt is enabled?
> >>
> >> Make -fcf-protection default to multi-byte NOPs works.  Uros,
> >> should I prepare a patch?
> >
> > Please make it an opt-in feature, so the compiler won't litter the
> > executable with unnecessary nops without user consent.
> >
> 
> -fcf-protection is off by default.  Users need to pass -fcf-protection
> to enable it.  I will work on such a patch.

That is not true.  When building gcc itself, config/cet.m4 makes
-fcf-protection -mcet the default if assembler supports it.
The request was to change --enable-cet configure option from having
yes,no,default arguments with default autodetection and being a default
if --enable-cet*/--disable-cet is not specified to say
yes,no,auto arguments where no would be the default and auto would be the
current default - enable it if as supports it, disable otherwise.

Jakub

Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Jakub Jelinek]

On Wed, Apr 18, 2018 at 05:07:33AM +, Jason Merrill wrote:
> I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.

I have tried following (still need Alex' expr.c changes, otherwise it ICEs),
on the bright side it fixes the new pr85437-4.C testcase,
but it causes Excess errors:
/usr/src/gcc/gcc/testsuite/g++.dg/Wcast-function-type.C:15:19: error: invalid 
conversion to type 'void (S::*)(int)' from type 'void (S::*)(int*)'
/usr/src/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrmem4.C:23:41:   in 
'constexpr' expansion of 'Bar(::test)'
/usr/src/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrmem4.C:23:41: error: a 
reinterpret_cast is not a constant expression
/usr/src/gcc/gcc/testsuite/g++.dg/cpp0x/pr68116.C:12:1: error: invalid 
conversion to type 'void (C::*)(int)' from type 'void (C::*)()'
/usr/src/gcc/gcc/testsuite/g++.dg/template/ptrmem19.C:19:23: error: invalid 
conversion to type 'void (C::*)(F)' from type 'void (C::*)(B*)'
/usr/src/gcc/gcc/testsuite/g++.dg/template/ptrmem19.C:19:23: error: invalid 
conversion to type 'void (C::*)(B*)' from type 'void (C::*)(F)'
/usr/src/gcc/gcc/testsuite/g++.dg/init/static2.C:20:1: error: invalid 
conversion to type 'void (A::*)()' from type 'void (B::*)()'
/usr/src/gcc/gcc/testsuite/g++.dg/init/static2.C:20:1: error: type 'B' is not a 
base type for type 'A'
/usr/src/gcc/gcc/testsuite/g++.dg/init/static2.C:20:1: error:in pointer to 
member conversion
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem4.C:39:33: error: type 'D' 
is not a base type for type 'B'
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem4.C:39:33: error:in 
pointer to member conversion
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem4.C:43:29: error: type 'D' 
is not a base type for type 'X'
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem4.C:43:29: error:in 
pointer to member conversion
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem5.C:31:41: error: invalid 
conversion to type 'float (B::*)()' from type 'int (D::*)()'
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem5.C:31:41: error: type 'D' 
is not a base type for type 'B'
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem5.C:31:41: error:in 
pointer to member conversion
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem5.C:32:41: error: invalid 
conversion to type 'float (D::*)()' from type 'int (B::*)()'
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem5.C:35:37: error: invalid 
conversion to type 'int (X::*)()' from type 'int (D::*)()'
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem5.C:35:37: error: type 'D' 
is not a base type for type 'X'
/usr/src/gcc/gcc/testsuite/g++.dg/conversion/ptrmem5.C:35:37: error:in 
pointer to member conversion
/usr/src/gcc/gcc/testsuite/g++.dg/init/ptrmem3.C:8:66: error: invalid 
conversion to type 'void (foo::*)()' from type 'int (foo::*)(int)'
/usr/src/gcc/gcc/testsuite/g++.dg/pr69379.C:20:1: error: invalid conversion to 
type 'void (Dict::*)(T)' {aka 'void (Dict::*)(int)'} from type 'void 
(Dict::*)()'
/usr/src/gcc/gcc/testsuite/g++.dg/other/default6.C:13:33: error: invalid 
conversion to type 'void (BaseRobot::*)()' from type 'int (BaseRobot::*)()'
/usr/src/gcc/gcc/testsuite/g++.dg/other/default6.C:17:33: error: invalid 
conversion to type 'void (BaseRobot::*)()' from type 'int (BaseRobot::*)()'
/usr/src/gcc/gcc/testsuite/g++.dg/torture/pr37354.C:13:1: error: invalid 
conversion to type 'void (GenericClass::*)()' from type 'int 
(AlsaDriver::*)(unsigned int)'
/usr/src/gcc/gcc/testsuite/g++.dg/torture/pr37354.C:13:1: error: type 
'AlsaDriver' is not a base type for type 'GenericClass'
/usr/src/gcc/gcc/testsuite/g++.dg/torture/pr37354.C:13:1: error:in pointer 
to member conversion
etc.

--- gcc/cp/constexpr.c.jj   2018-04-13 10:33:03.078658240 +0200
+++ gcc/cp/constexpr.c  2018-04-18 13:42:54.097312535 +0200
@@ -4595,10 +4595,12 @@ cxx_eval_constant_expression (const cons
if (TREE_CODE (op) == PTRMEM_CST
&& !TYPE_PTRMEM_P (type))
  op = cplus_expand_constant (op);
-   if (TREE_CODE (op) == PTRMEM_CST && tcode == NOP_EXPR)
+   if (TREE_CODE (op) == PTRMEM_CST
+   && (tcode == NOP_EXPR || tcode == CONVERT_EXPR))
  {
-   if (same_type_ignoring_top_level_qualifiers_p (type,
-  TREE_TYPE (op))
+   if (tcode == NOP_EXPR
+   || same_type_ignoring_top_level_qualifiers_p (type,
+ TREE_TYPE (op))
|| can_convert_qual (type, op))
  return cp_fold_convert (type, op);
else
--- gcc/cp/typeck.c.jj  2018-04-18 08:57:09.555612419 +0200
+++ gcc/cp/typeck.c 2018-04-18 13:50:14.278498305 +0200
@@ -5758,6 +5758,16 @@ build_nop (tree type, tree expr)
   return build1_loc (EXPR_LOCATION (expr), NOP_EXPR, type, expr);
 }
 
+/* Similarly, but build CONVERT_EXPR instead.  */
+
+static tree
+build_convert_expr (tree type, tree expr)
+{

Re: PING^4: [PATCH] Use dlsym to check if libdl is needed for plugin

[H.J. Lu]

On Mon, Apr 16, 2018 at 3:08 PM, Alexandre Oliva  wrote:
> On Apr  3, 2018, "H.J. Lu"  wrote:
>
>> On Mon, Mar 26, 2018 at 4:10 AM, H.J. Lu  wrote:
>>> On Wed, Mar 14, 2018 at 4:41 AM, H.J. Lu  wrote:
 On Wed, Feb 21, 2018 at 3:02 AM, H.J. Lu  wrote:
> On Wed, Oct 18, 2017 at 5:25 PM, H.J. Lu  wrote:
>> * plugins.m4 (AC_PLUGINS): Use dlsym to check if libdl is needed.
>
> This is ok, thanks

Thanks.

 PING.
>
>>> PING.
>
>> PING.
>
> Sorry about the delay.  Next time, I suggest supplying a link to the
> patch in the archives.  Speaking only for myself, I can say it would

Will do.

> have kept me on track a few times I set out to search for and review
> this one patch, got distracted by something else and ended up not
> reviewing it ;-)
>


-- 
H.J.

PING: [PATCH] i386: Insert ENDBR after __morestack call

[H.J. Lu]

On Fri, Apr 13, 2018 at 5:56 AM, H.J. Lu  wrote:
> Since __morestack will jump back to its callee via indirect call, we
> need to insert ENDBR after calling __morestack.
>
> OK for trunk?
>
> H.J.
> 
> gcc/
>
> PR target/85388
> * config/i386/i386.c (ix86_expand_split_stack_prologue): Insert
> ENDBR after calling __morestack.
>
> gcc/testsuite/
>
> PR target/85388
> * gcc.dg/pr85388-1.c: New test.
> * gcc.dg/pr85388-2.c: Likewise.
> * gcc.dg/pr85388-3.c: Likewise.
> * gcc.dg/pr85388-4.c: Likewise.
> * gcc.dg/pr85388-5.c: Likewise.
> * gcc.dg/pr85388-6.c: Likewise.
> ---
>  gcc/config/i386/i386.c   | 11 ++-
>  gcc/testsuite/gcc.dg/pr85388-1.c | 50 +
>  gcc/testsuite/gcc.dg/pr85388-2.c | 56 
>  gcc/testsuite/gcc.dg/pr85388-3.c | 65 +
>  gcc/testsuite/gcc.dg/pr85388-4.c | 69 
> 
>  gcc/testsuite/gcc.dg/pr85388-5.c | 54 +++
>  gcc/testsuite/gcc.dg/pr85388-6.c | 56 
>  7 files changed, 360 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.dg/pr85388-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr85388-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr85388-3.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr85388-4.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr85388-5.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr85388-6.c
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 03e5c433574..8b4fd8ae30b 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -15242,7 +15242,16 @@ ix86_expand_split_stack_prologue (void)
>   instruction--we need control flow to continue at the subsequent
>   label.  Therefore, we use an unspec.  */
>gcc_assert (crtl->args.pops_args < 65536);
> -  emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
> +  rtx_insn *ret_insn
> += emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
> +
> +  if ((flag_cf_protection & CF_BRANCH) && TARGET_IBT)
> +{
> +  /* Insert ENDBR since __morestack will jump back here via indirect
> +call.  */
> +  rtx cet_eb = gen_nop_endbr ();
> +  emit_insn_after (cet_eb, ret_insn);
> +}
>
>/* If we are in 64-bit mode and this function uses a static chain,
>   we saved %r10 in %rax before calling _morestack.  */

PING:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00669.html


-- 
H.J.

PING: [PATCH] libgcc/CET: Add _CET_ENDBR to __stack_split_initialize

[H.J. Lu]

On Thu, Apr 12, 2018 at 6:21 AM, H.J. Lu  wrote:
> Program received signal SIGSEGV, Segmentation fault.
> __stack_split_initialize ()
> at /export/gnu/import/git/sources/gcc/libgcc/config/i386/morestack.S:751
> 751 leaq-16000(%rsp),%rax   # We should have at least 16K.
> Missing separate debuginfos, use: dnf debuginfo-install 
> libgcc-8.0.1-0.21.0.fc28.x86_64
> (gdb) disass
> Dump of assembler code for function __stack_split_initialize:
> => 0x00402858 <+0>: lea-0x3e80(%rsp),%rax
>0x00402860 <+8>: mov%rax,%fs:0x70
>0x00402869 <+17>:sub$0x8,%rsp
>0x0040286d <+21>:mov%rsp,%rdi
>0x00402870 <+24>:mov$0x3e80,%esi
>0x00402875 <+29>:callq  0x401810 
> <__generic_morestack_set_initial_sp>
>0x0040287a <+34>:add$0x8,%rsp
>0x0040287e <+38>:retq
> End of assembler dump.
> (gdb)
>
> This patch adds the missing ENDBR to __stack_split_initialize.
>
> OK for trunk?
>
> H.J.
> ---
> PR libgcc/85379
> * config/i386/morestack.S (__stack_split_initialize): Add
> _CET_ENDBR.
> ---
>  libgcc/config/i386/morestack.S | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libgcc/config/i386/morestack.S b/libgcc/config/i386/morestack.S
> index eca441a2867..99e65eaaff4 100644
> --- a/libgcc/config/i386/morestack.S
> +++ b/libgcc/config/i386/morestack.S
> @@ -730,6 +730,7 @@ __morestack_large_model:
>  #endif
>
>  __stack_split_initialize:
> +   _CET_ENDBR
>
>  #ifndef __x86_64__
>
> --
> 2.14.3
>

PING.

-- 
H.J.

PING: [PATCH] libgcc/CET: Skip signal frames when unwinding shadow stack

[H.J. Lu]

On Thu, Apr 12, 2018 at 12:43 PM, H.J. Lu  wrote:
> On Wed, Apr 11, 2018 at 3:37 AM, H.J. Lu  wrote:
>> When -fcf-protection -mcet is used, I got
>>
>> FAIL: g++.dg/eh/sighandle.C
>>
>> (gdb) bt
>>  #0  _Unwind_RaiseException (exc=exc@entry=0x416ed0)
>> at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:140
>>  #1  0x77d9936b in __cxxabiv1::__cxa_throw (obj=,
>> tinfo=0x403dd0 , dest=0x0)
>> at 
>> /export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++/eh_throw.cc:90
>>  #2  0x00401255 in sighandler (signo=11, si=0x7fffd6f8,
>> uc=0x7fffd5c0)
>> at 
>> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:9
>>  #3    Signal frame which isn't on shadow stack
>>  #4  dosegv ()
>> at 
>> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:14
>>  #5  0x004012e3 in main ()
>> at 
>> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:30
>> (gdb) p frames
>> $6 = 5
>> (gdb)
>>
>> frame count should be 4, not 5.  This patch skips signal frames when
>> unwinding shadow stack.
>>
>> Tested on i686 and x86-64.  OK for trunk?
>>
>> H.J.
>> 
>> PR libgcc/85334
>> * unwind-generic.h (_Unwind_Frames_Increment): New.
>> * config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
>> Likewise.
>> * unwind.inc (_Unwind_RaiseException_Phase2): Increment frame
>> count with _Unwind_Frames_Increment.
>> (_Unwind_ForcedUnwind_Phase2): Likewise.

>
> I need to increment frame count after uw_advance_context which will set
> the signal frame bit.
>
> OK for trunk?

PING:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00633.html


-- 
H.J.

[PATCH][i386] Adding MOVDIRI and MOVDIR64B instructions

[Peryt, Sebastian]

Hi,

This patch enables new instructions - MOVDIRI and MOVDIR64B.

Is it ok for trunk?


2018-04-18  Sebastian Peryt  

gcc/

* common/config/i386/i386-common.c 
(OPTION_MASK_ISA_MOVDIRI_SET, OPTION_MASK_ISA_MOVDIR64B_SET,
OPTION_MASK_ISA_MOVDIRI_UNSET,
OPTION_MASK_ISA_MOVDIR64B_UNSET): New defines.
(ix86_handle_option): Handle -mmovdiri and -mmovdir64b.
* config.gcc (movdirintrin.h): New header.
* config/i386/cpuid.h (bit_MOVDIRI,
bit_MOVDIR64B): New bits.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect -mmovdiri
and -mmvodir64b.
* config/i386/i386-builtin-types.def ((VOID, PUNSIGNED, UNSIGNED),
(VOID, PVOID, PCVOID)): New function types.
* config/i386/i386-builtin.def (__builtin_ia32_directstoreu_u32,
__builtin_ia32_directstoreu_u64, __builtin_ia32_movdir64b): New 
builtins.
* config/i386/i386-c.c (__MOVDIRI__, __MOVDIR64B__): New.
* config/i386/i386.c (ix86_target_string): Added -mmovdir64b and 
-mmovdiri.
(ix86_valid_target_attribute_inner_p): Ditto.
(ix86_expand_special_args_builtin):  Added VOID_FTYPE_PUNSIGNED_UNSIGNED
and VOID_FTYPE_PUNSIGNED_UNSIGNED.
(ix86_expand_builtin): Expand IX86_BUILTIN_MOVDIR64B.
* config/i386/i386.h (TARGET_MOVDIRI, TARGET_MOVDIRI_P,
TARGET_MOVDIR64B, TARGET_MOVDIR64B_P): New.
* config/i386/i386.md (UNSPECV_MOVDIRI, UNSPECV_MOVDIR64B): New.
(movdiri, movdir64b_): New.
* config/i386/i386.opt: Add -mmovdiri and -mmovdir64b.
* config/i386/immintrin.h: Include movdirintrin.h.
* config/i386/movdirintrin.h: New file.
* doc/invoke.texi: Added -mmovdiri and -mmovdir64b.

2018-04-18  Sebastian Peryt  

gcc/testsuite/

* gcc.target/i386/movdir-1.c: New test.


Thanks,
Sebastian


0001-MOVDIRI.PATCH
Description: 0001-MOVDIRI.PATCH

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Andrew Sadek]

Hello Michael,

I have attached the patch as well,
(the same as in :
https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/PATCH_BUNDLE/gcc.patch)

On Thu, Mar 22, 2018 at 8:37 PM, Andrew Sadek  wrote:
> Hello Michael,
>
> I have adapted the test cases.
>
> Please find the patch below with Change log, description and test results.
>
> Description:
> --
>
> This branch is regarding a new implemented feature in GCC Microblaze
> that allows Position Independent Code to run using Data Text Relative
> addressing instead of using Global Offset Table.
>
> Its aim was to make 'PIC' more efficient and flexible as elf size
> excess/ performance overhead were noticed when using GOT due to the
> indirect addressing.
> The change was tested with the dhrystone benchmark on a real Hardware
> (Xilinx FPGA Spartan 6) and the test report went successfully for all
> optimization levels.
>
> Indeed, Microblaze does not support PC-relative addressing in Hardware like 
> ARM.
> The idea was to store the start address of current text section in
> 'r20' instead of GOT, in the function prologue. Correspondingly, data
> references will be an offset from the original reference value to the
> start of text thus being added to the 'r20' base register will resolve
> the actual address.
>
> Henceforth, 2 new relocations have been created:
> - 'R_MICROBLAZE_TEXTPCREL_64': resolves offset of current PC to start
> of text in order to set r20
> - 'R_MICROBLAZE_TEXTREL_64': resolves offset of mentioned data
> reference to start of text
>
> Accordingly, both assembler and linker (binutils) have been adapted.
>
> For extra details:
> https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md
>
> Change Log:
> -
>
> 2018-03-22 Andrew Sadek  
>
> Microblaze Target: PIC data text relative
> * gcc/config/microblaze/microblaze.opt: add new option
> -mpic-data-text-rel.
> * gcc/config/microblaze/microblaze-protos.h 
> (microblaze_constant_address_p):
> Add microblaze_constant_address_p function instead of the macro in
> microblaze.h
> * gcc/config/microblaze/microblaze.c (TARGET_PIC_DATA_TEXT_REL):
> New addressing mode
> for data-text relative position indepenedent code.
> (microblaze_classify_unspec): add 'UNSPEC_TEXT' case ->
> 'ADDRESS_SYMBOLIC_TXT_REL'.
> (microblaze_classify_address): add handling for UNSPEC + CONST_INT.
> (microblaze_legitimate_pic_operand): exclude function calls from
> pic operands
> in case of TARGET_PIC_DATA_TEXT_REL option.
> (microblaze_legitimize_address): generate 'UNSPEC_TEXT' for all possible
> addresses cases.
> (microblaze_address_insns): add 'ADDRESS_SYMBOLIC_TXT_REL' case.
> (print_operand): add 'ADDRESS_SYMBOLIC_TXT_REL' case.
> (print_operand_address): add 'ADDRESS_SYMBOLIC_TXT_REL' case + handling 
> for
> 'address + offset'.
> (microblaze_expand_prologue): add new function prologue call for
> 'r20' assignation.
> (microblaze_asm_generate_pic_addr_dif_vec): override new target hook
>'TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC' to disable address diff vector
> table in case of TARGET_PIC_DATA_TEXT_REL.
> (expand_pic_symbol_ref): add handling for 'UNSPEC_TEXT'.
> * gcc/config/microblaze/microblaze.md (TARGET_PIC_DATA_TEXT_REL):
> Add new macros 'UNSPEC_TEXT',
> 'UNSPEC_SET_TEXT' + add rule for setting r20 in function prologue
> + exclude function calls
> from 'UNSPEC_PLT' in case of data text relative mode.
> * gcc/doc/tm.texi.in (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): Add
> new target hook for generating
> address diff vector tables in case of flag_pic.
> * gcc/doc/tm.texi : Regenerate.
> * gcc/stmt.c (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): append new condition
> 'targetm.asm_out.generate_pic_addr_diff_vec' to flag_pic in case
> of addr diff vector generation.
> * gcc/target.def (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): add
> target hook definition.
> * gcc/targhooks.h, gcc/targhooks.c 
> (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC):
> add default function for generate_pic_addr_diff_vec -> flag_pic.
> * gcc/doc/invoke.texi (Add new pic option): Add new microblaze pic
> option for data text relative.
>
>
> Test Results (using qemu microblaze little endian):
> 
>
> === gcc Summary ===
>
> # of expected passes90874
> # of unexpected failures1317
> # of unexpected successes3
> # of expected failures207
> # of unresolved testcases115
> # of unsupported tests2828
>
> Full summary:
> https://raw.githubusercontent.com/andrewsadek/microblaze-pic-data-text-rel/pic_data_text_rel/PATCH_BUNDLE/gcc.sum
>
> Patch:
> --
>
> Actually, I found that gmail transforms tabs to spaces even plain text
> mode, also I can not attach the 

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Uros Bizjak]

On Wed, Apr 18, 2018 at 2:09 PM, Jakub Jelinek  wrote:
> On Wed, Apr 18, 2018 at 02:04:50PM +0200, Jakub Jelinek wrote:
>> On Wed, Apr 18, 2018 at 04:57:41AM -0700, H.J. Lu wrote:
>> > On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak  wrote:
>> > > On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu  wrote:
>> > >
>> >  Here is a patch to add -mnop and use it with -fcf-protection.
>> > >>>
>> > >>> +mnop
>> > >>> +Target Report Var(flag_nop) Init(0)
>> > >>> +Support multi-byte NOP code generation.
>> > >>>
>> > >>> the option name is incredibly bad and the documentation doesn't make it
>> > >>> better either.  The invoke.texi docs refer to duplicate {-mcet}.
>> > >>>
>> > >>> Isn't there a -fcf-protection sub-set that can be used to automatically
>> > >>> enable this?  Or simply do this mode by default when
>> > >>> -fcf-protection is used but neither -mcet nor -mibt is enabled?
>> > >>
>> > >> Make -fcf-protection default to multi-byte NOPs works.  Uros,
>> > >> should I prepare a patch?
>> > >
>> > > Please make it an opt-in feature, so the compiler won't litter the
>> > > executable with unnecessary nops without user consent.
>> > >
>> >
>> > -fcf-protection is off by default.  Users need to pass -fcf-protection
>> > to enable it.  I will work on such a patch.
>>
>> That is not true.  When building gcc itself, config/cet.m4 makes
>> -fcf-protection -mcet the default if assembler supports it.
>> The request was to change --enable-cet configure option from having
>> yes,no,default arguments with default autodetection and being a default
>> if --enable-cet*/--disable-cet is not specified to say
>> yes,no,auto arguments where no would be the default and auto would be the
>> current default - enable it if as supports it, disable otherwise.
>
> So untested patch would be something like:

Yes, this is what I think should be the most appropriate approach.

Uros.

> 2018-04-18  Jakub Jelinek  
>
> * config/cet.m4 (GCC_CET_FLAGS): Default to --disable-cet, replace
> --enable-cet=default with --enable-cet=auto.
>
> * doc/install.texi: Document --disable-cet being the default and
> --enable-cet=auto.
>
> --- gcc/config/cet.m4.jj2018-02-19 19:57:05.221280084 +0100
> +++ gcc/config/cet.m4   2018-04-18 14:05:31.514859185 +0200
> @@ -3,14 +3,14 @@ dnl GCC_CET_FLAGS
>  dnl(SHELL-CODE_HANDLER)
>  dnl
>  AC_DEFUN([GCC_CET_FLAGS],[dnl
> -GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
> -  permit yes|no|default)
> +GCC_ENABLE(cet, no, ,[enable Intel CET in target libraries],
> +  permit yes|no|auto)
>  AC_MSG_CHECKING([for CET support])
>
>  case "$host" in
>i[[34567]]86-*-linux* | x86_64-*-linux*)
>  case "$enable_cet" in
> -  default)
> +  auto)
> # Check if target supports multi-byte NOPs
> # and if assembler supports CET insn.
> AC_COMPILE_IFELSE(
> --- gcc/doc/install.texi.jj 2018-02-08 12:21:20.791749480 +0100
> +++ gcc/doc/install.texi2018-04-18 14:07:19.637901528 +0200
> @@ -2103,10 +2103,11 @@ instrumentation, see @option{-fcf-protec
>  to add @option{-fcf-protection} and, if needed, other target
>  specific options to a set of building options.
>
> -The option is enabled by default on Linux/x86 if target binutils
> -supports @code{Intel CET} instructions.  In this case the target
> -libraries are configured to get additional @option{-fcf-protection}
> -and @option{-mcet} options.
> +The option is disabled by default on Linux/x86.  When
> +@code{--enable-cet=auto} is used, it is enabled if target binutils
> +supports @code{Intel CET} instructions and disabled otherwise.
> +In this case the target libraries are configured to get additional
> +@option{-fcf-protection} and @option{-mcet} options.
>  @end table
>
>  @subheading Cross-Compiler-Specific Options
>
>
> Jakub

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Wednesday, April 18, 2018 2:10 PM
> To: H.J. Lu 
> Cc: Uros Bizjak ; Richard Biener
> ; gcc-patches@gcc.gnu.org; Tsimbalist, Igor
> V 
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Wed, Apr 18, 2018 at 02:04:50PM +0200, Jakub Jelinek wrote:
> > On Wed, Apr 18, 2018 at 04:57:41AM -0700, H.J. Lu wrote:
> > > On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak 
> wrote:
> > > > On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu 
> wrote:
> > > >
> > >  Here is a patch to add -mnop and use it with -fcf-protection.
> > > >>>
> > > >>> +mnop
> > > >>> +Target Report Var(flag_nop) Init(0)
> > > >>> +Support multi-byte NOP code generation.
> > > >>>
> > > >>> the option name is incredibly bad and the documentation doesn't
> make it
> > > >>> better either.  The invoke.texi docs refer to duplicate {-mcet}.
> > > >>>
> > > >>> Isn't there a -fcf-protection sub-set that can be used to
> automatically
> > > >>> enable this?  Or simply do this mode by default when
> > > >>> -fcf-protection is used but neither -mcet nor -mibt is enabled?
> > > >>
> > > >> Make -fcf-protection default to multi-byte NOPs works.  Uros,
> > > >> should I prepare a patch?
> > > >
> > > > Please make it an opt-in feature, so the compiler won't litter the
> > > > executable with unnecessary nops without user consent.
> > > >
> > >
> > > -fcf-protection is off by default.  Users need to pass -fcf-protection
> > > to enable it.  I will work on such a patch.
> >
> > That is not true.  When building gcc itself, config/cet.m4 makes
> > -fcf-protection -mcet the default if assembler supports it.
> > The request was to change --enable-cet configure option from having
> > yes,no,default arguments with default autodetection and being a default
> > if --enable-cet*/--disable-cet is not specified to say
> > yes,no,auto arguments where no would be the default and auto would be
> the
> > current default - enable it if as supports it, disable otherwise.
> 
> So untested patch would be something like:
> 
> 2018-04-18  Jakub Jelinek  
> 
>   * config/cet.m4 (GCC_CET_FLAGS): Default to --disable-cet, replace
>   --enable-cet=default with --enable-cet=auto.
> 
>   * doc/install.texi: Document --disable-cet being the default and
>   --enable-cet=auto.
> 
> --- gcc/config/cet.m4.jj  2018-02-19 19:57:05.221280084 +0100
> +++ gcc/config/cet.m4 2018-04-18 14:05:31.514859185 +0200
> @@ -3,14 +3,14 @@ dnl GCC_CET_FLAGS
>  dnl(SHELL-CODE_HANDLER)
>  dnl
>  AC_DEFUN([GCC_CET_FLAGS],[dnl
> -GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
> -permit yes|no|default)
> +GCC_ENABLE(cet, no, ,[enable Intel CET in target libraries],
> +permit yes|no|auto)
>  AC_MSG_CHECKING([for CET support])
> 
>  case "$host" in
>i[[34567]]86-*-linux* | x86_64-*-linux*)
>  case "$enable_cet" in
> -  default)
> +  auto)
>   # Check if target supports multi-byte NOPs
>   # and if assembler supports CET insn.
>   AC_COMPILE_IFELSE(
> --- gcc/doc/install.texi.jj   2018-02-08 12:21:20.791749480 +0100
> +++ gcc/doc/install.texi  2018-04-18 14:07:19.637901528 +0200
> @@ -2103,10 +2103,11 @@ instrumentation, see @option{-fcf-protec
>  to add @option{-fcf-protection} and, if needed, other target
>  specific options to a set of building options.
> 
> -The option is enabled by default on Linux/x86 if target binutils
> -supports @code{Intel CET} instructions.  In this case the target
> -libraries are configured to get additional @option{-fcf-protection}
> -and @option{-mcet} options.
> +The option is disabled by default on Linux/x86.  When
> +@code{--enable-cet=auto} is used, it is enabled if target binutils
> +supports @code{Intel CET} instructions and disabled otherwise.
> +In this case the target libraries are configured to get additional
> +@option{-fcf-protection} and @option{-mcet} options.
>  @end table
> 
>  @subheading Cross-Compiler-Specific Options
> 

Thanks! I will work on this.

>   Jakub

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Wednesday, April 18, 2018 1:39 PM
> To: Richard Biener 
> Cc: Uros Bizjak ; gcc-patches@gcc.gnu.org; Tsimbalist,
> Igor V 
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Wed, Apr 18, 2018 at 4:35 AM, Richard Biener
>  wrote:
> > On Wed, Apr 18, 2018 at 1:24 PM, H.J. Lu  wrote:
> >> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu  wrote:
> >>> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu 
> wrote:
>  On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu 
> wrote:
> > On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak
>  wrote:
> >> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu 
> wrote:
> >>> -fcf-protection -mcet can't be used with IFUNC features, like
> symbol
> >>> multiversioning or target clone, since IBT/SHSTK are applied to
> the whole
> >>> program and they may be disabled in some functions.  But -fcf-
> protection
> >>> is implemented with multi-byte NOPs on all 64-bit processors as
> well as
> >>> 32-bit processors starting with Pentium Pro.  If -fcf-protection
> requires
> >>> -mcet, IFUNC features can't be used on Linux when -fcf-
> protection is
> >>> enabled by default.
> >>>
> >>> This patch changes -fcf-protection to to enable the NOP portion
> of CET
> >>> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of
> CET
> >>> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
> >>>
> >>> OK for trunk?
> >>
> >> As said in the PR, NOP sequences have non-zero cost in the
> executable
> >> (they enlarge the executable), so I don't think this feature should
> be
> >> enabled by default.
> >>
> >> There is always a configure option if someone wants their compiler
> to
> >> always emit relevant multi-byte nops.
> >
> > What we need is an option to enable -fcf-function with multi-byte
> NOPs
> > without -mcet which enables the full CET ISAs.  A configure option
> > without the corresponding the command-line option makes test and
> > debug difficult.   I can add
> >
> > --enable-cf-function-nop or --with-cf-function-nop
> >
> > with
> >
> > -fct-function-nop
> >
> 
>  How about adding -mno-cet, which enables the NOP portion of CET
> >>>
> >>> I meant -mnop-cet, not -mno-cet.
> >>>
> >>
> >> Here is a patch to add -mnop and use it with -fcf-protection.
> >
> > +mnop
> > +Target Report Var(flag_nop) Init(0)
> > +Support multi-byte NOP code generation.
> >
> > the option name is incredibly bad and the documentation doesn't make it
> > better either.  The invoke.texi docs refer to duplicate {-mcet}.
> >
> > Isn't there a -fcf-protection sub-set that can be used to automatically
> > enable this?  Or simply do this mode by default when
> > -fcf-protection is used but neither -mcet nor -mibt is enabled?
> 
> Make -fcf-protection default to multi-byte NOPs works.  Uros,
> should I prepare a patch?

This is going to change the designed approach and has to be communicated 
to/agreed
with other compilers. And I assume there will be no extra option introduced, 
like -mnop.

Igor

> --
> H.J.

[wwwdocs] Add no_sanitize attribute

[Martin Liška]

I would like to mention the attribute in GCC 8 changes.

Martin
Index: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.67
diff -r1.67 changes.html
255a256,266
>   
> New no_sanitize attribute has been added.  The attribute
> on functions is used to inform the compiler that it should
> not do sanitization of all options mentioned in sanitize option.
> A list of values acceptable by -fsanitize option can be
> provided.
> 
> void __attribute__ ((no_sanitize ("alignment", "object-size")))
> f () { /* Do something. */; }
> 
>   

[PATCH] PR libstdc++/85442 fix duplicate debuginfo for cxx11-ios_failure.cc

[Jonathan Wakely]

The fix for PR 85222 ends up generating duplicate debuginfo sections,
because we compile the .cc file and then compile the .s file. This
adds -g0 to the second step so we don't generate debuginfo again.

I've verified that we still have debuginfo for the file and can step
through the code when using the $prefix/lib64/debug/libstdc++.so.6
version of the library.

2018-04-18  Jonathan Wakely  
Jakub Jelinek  

PR libstdc++/85442
* src/c++11/Makefile.am: Don't generate debuginfo again for
cxx11-ios_failure-lt.s and cxx11-ios_failure.s files.
* src/c++11/Makefile.in: Regenerate.

Tested powerpc64le-linux, committed to trunk. Backport to gcc-7-branch
to follow.
commit 55c94164faf1f124b5c88067ead6871f383fb319
Author: Jonathan Wakely 
Date:   Wed Apr 18 12:27:11 2018 +0100

PR libstdc++/85442 fix duplicate debuginfo for cxx11-ios_failure.cc

2018-04-18  Jonathan Wakely  
Jakub Jelinek  

PR libstdc++/85442
* src/c++11/Makefile.am: Don't generate debuginfo again for
cxx11-ios_failure-lt.s and cxx11-ios_failure.s files.
* src/c++11/Makefile.in: Regenerate.

diff --git a/libstdc++-v3/src/c++11/Makefile.am 
b/libstdc++-v3/src/c++11/Makefile.am
index cdc49bb7f9b..91bf6f8d642 100644
--- a/libstdc++-v3/src/c++11/Makefile.am
+++ b/libstdc++-v3/src/c++11/Makefile.am
@@ -141,9 +141,9 @@ cxx11-ios_failure.s: cxx11-ios_failure.cc
-rm -f tmp-$@
 
 cxx11-ios_failure.lo: cxx11-ios_failure-lt.s
-   $(LTCXXCOMPILE) -c $< -o $@
+   $(LTCXXCOMPILE) -g0 -c $< -o $@
 cxx11-ios_failure.o: cxx11-ios_failure.s
-   $(CXXCOMPILE) -c $<
+   $(CXXCOMPILE) -g0 -c $<
 endif
 
 # AM_CXXFLAGS needs to be in each subdirectory so that it can be

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

On Wed, Apr 18, 2018 at 5:08 AM, Uros Bizjak  wrote:
> On Wed, Apr 18, 2018 at 1:57 PM, H.J. Lu  wrote:
>> On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak  wrote:
>>> On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu  wrote:
>>>
>> Here is a patch to add -mnop and use it with -fcf-protection.
>
> +mnop
> +Target Report Var(flag_nop) Init(0)
> +Support multi-byte NOP code generation.
>
> the option name is incredibly bad and the documentation doesn't make it
> better either.  The invoke.texi docs refer to duplicate {-mcet}.
>
> Isn't there a -fcf-protection sub-set that can be used to automatically
> enable this?  Or simply do this mode by default when
> -fcf-protection is used but neither -mcet nor -mibt is enabled?

 Make -fcf-protection default to multi-byte NOPs works.  Uros,
 should I prepare a patch?
>>>
>>> Please make it an opt-in feature, so the compiler won't litter the
>>> executable with unnecessary nops without user consent.
>>>
>>
>> -fcf-protection is off by default.  Users need to pass -fcf-protection
>> to enable it.  I will work on such a patch.
>
> Please note that currently all libraries are compiled with
> "-fcf-protection -mcet" by default, even without using --enable-cet
> during configure. The CET instrumentation of libraries should be put
> under strict user control, so please remove the "default" from
> config/cet.m4.
>

Igor, please prepare such a patch to config/cet.m4.


-- 
H.J.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Jakub Jelinek]

On Wed, Apr 18, 2018 at 02:04:50PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 04:57:41AM -0700, H.J. Lu wrote:
> > On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak  wrote:
> > > On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu  wrote:
> > >
> >  Here is a patch to add -mnop and use it with -fcf-protection.
> > >>>
> > >>> +mnop
> > >>> +Target Report Var(flag_nop) Init(0)
> > >>> +Support multi-byte NOP code generation.
> > >>>
> > >>> the option name is incredibly bad and the documentation doesn't make it
> > >>> better either.  The invoke.texi docs refer to duplicate {-mcet}.
> > >>>
> > >>> Isn't there a -fcf-protection sub-set that can be used to automatically
> > >>> enable this?  Or simply do this mode by default when
> > >>> -fcf-protection is used but neither -mcet nor -mibt is enabled?
> > >>
> > >> Make -fcf-protection default to multi-byte NOPs works.  Uros,
> > >> should I prepare a patch?
> > >
> > > Please make it an opt-in feature, so the compiler won't litter the
> > > executable with unnecessary nops without user consent.
> > >
> > 
> > -fcf-protection is off by default.  Users need to pass -fcf-protection
> > to enable it.  I will work on such a patch.
> 
> That is not true.  When building gcc itself, config/cet.m4 makes
> -fcf-protection -mcet the default if assembler supports it.
> The request was to change --enable-cet configure option from having
> yes,no,default arguments with default autodetection and being a default
> if --enable-cet*/--disable-cet is not specified to say
> yes,no,auto arguments where no would be the default and auto would be the
> current default - enable it if as supports it, disable otherwise.

So untested patch would be something like:

2018-04-18  Jakub Jelinek  

* config/cet.m4 (GCC_CET_FLAGS): Default to --disable-cet, replace
--enable-cet=default with --enable-cet=auto.

* doc/install.texi: Document --disable-cet being the default and
--enable-cet=auto.

--- gcc/config/cet.m4.jj2018-02-19 19:57:05.221280084 +0100
+++ gcc/config/cet.m4   2018-04-18 14:05:31.514859185 +0200
@@ -3,14 +3,14 @@ dnl GCC_CET_FLAGS
 dnl(SHELL-CODE_HANDLER)
 dnl
 AC_DEFUN([GCC_CET_FLAGS],[dnl
-GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
-  permit yes|no|default)
+GCC_ENABLE(cet, no, ,[enable Intel CET in target libraries],
+  permit yes|no|auto)
 AC_MSG_CHECKING([for CET support])
 
 case "$host" in
   i[[34567]]86-*-linux* | x86_64-*-linux*)
 case "$enable_cet" in
-  default)
+  auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
AC_COMPILE_IFELSE(
--- gcc/doc/install.texi.jj 2018-02-08 12:21:20.791749480 +0100
+++ gcc/doc/install.texi2018-04-18 14:07:19.637901528 +0200
@@ -2103,10 +2103,11 @@ instrumentation, see @option{-fcf-protec
 to add @option{-fcf-protection} and, if needed, other target
 specific options to a set of building options.
 
-The option is enabled by default on Linux/x86 if target binutils
-supports @code{Intel CET} instructions.  In this case the target
-libraries are configured to get additional @option{-fcf-protection}
-and @option{-mcet} options.
+The option is disabled by default on Linux/x86.  When
+@code{--enable-cet=auto} is used, it is enabled if target binutils
+supports @code{Intel CET} instructions and disabled otherwise.
+In this case the target libraries are configured to get additional
+@option{-fcf-protection} and @option{-mcet} options.
 @end table
 
 @subheading Cross-Compiler-Specific Options


Jakub

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Uros Bizjak]

On Wed, Apr 18, 2018 at 1:57 PM, H.J. Lu  wrote:
> On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak  wrote:
>> On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu  wrote:
>>
> Here is a patch to add -mnop and use it with -fcf-protection.

 +mnop
 +Target Report Var(flag_nop) Init(0)
 +Support multi-byte NOP code generation.

 the option name is incredibly bad and the documentation doesn't make it
 better either.  The invoke.texi docs refer to duplicate {-mcet}.

 Isn't there a -fcf-protection sub-set that can be used to automatically
 enable this?  Or simply do this mode by default when
 -fcf-protection is used but neither -mcet nor -mibt is enabled?
>>>
>>> Make -fcf-protection default to multi-byte NOPs works.  Uros,
>>> should I prepare a patch?
>>
>> Please make it an opt-in feature, so the compiler won't litter the
>> executable with unnecessary nops without user consent.
>>
>
> -fcf-protection is off by default.  Users need to pass -fcf-protection
> to enable it.  I will work on such a patch.

Please note that currently all libraries are compiled with
"-fcf-protection -mcet" by default, even without using --enable-cet
during configure. The CET instrumentation of libraries should be put
under strict user control, so please remove the "default" from
config/cet.m4.

Uros.

[PATCH] RISC-V: Make sure stack is always aligned during adjusting

[Kito Cheng]

Hi all:

I've hit a bug when running gcc testsuite with gc trunk on our
internal simulator, C extension may generate non-aligned
stack in some program point.

Verified with gcc testsuite on rv32imac/rv32ima elf.

Fail case:
riscv32-elf-gcc -march=rv32imac gcc/testsuite/gcc.dg/graph
ite/interchange-6.c  -O2 -ffast-math -floop-nest-opt
imize -o - -S
...
.type   main, @function
main:
   li  t1,-81920
   addisp,sp,-36 # <-- stack not aligned here!
...


gcc/ChangeLog:

2018-04-18  Kito Cheng  

   * config/riscv/riscv.c (riscv_first_stack_step): Round up min
   step and round down max step to make sure stack always aligned.
From cf75c573ec9c8e5071e54a3cfba377fd0cb5bf3d Mon Sep 17 00:00:00 2001
From: Kito Cheng 
Date: Wed, 18 Apr 2018 17:51:35 +0800
Subject: [PATCH] RISC-V: Make sure stack is always aligned during adjusting
 stack.

gcc/ChangeLog:

2018-04-18  Kito Cheng  

	* config/riscv/riscv.c (riscv_first_stack_step): Round up min
	step and round down max step to make sure stack always aligned.
---
 gcc/config/riscv/riscv.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index 2870177fa97..eca1cacf015 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -3507,9 +3507,13 @@ riscv_first_stack_step (struct riscv_frame_info *frame)
   if (SMALL_OPERAND (frame->total_size))
 return frame->total_size;
 
-  HOST_WIDE_INT min_first_step = frame->total_size - frame->fp_sp_offset;
-  HOST_WIDE_INT max_first_step = IMM_REACH / 2 - PREFERRED_STACK_BOUNDARY / 8;
-  HOST_WIDE_INT min_second_step = frame->total_size - max_first_step;
+  HOST_WIDE_INT min_first_step =
+RISCV_STACK_ALIGN (frame->total_size - frame->fp_sp_offset);
+  HOST_WIDE_INT max_first_step =
+ROUND_DOWN (IMM_REACH / 2 - PREFERRED_STACK_BOUNDARY / 8,
+		PREFERRED_STACK_BOUNDARY / 8);
+  HOST_WIDE_INT min_second_step =
+RISCV_STACK_ALIGN (frame->total_size - max_first_step);
   gcc_assert (min_first_step <= max_first_step);
 
   /* As an optimization, use the least-significant bits of the total frame
-- 
2.11.2

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak  wrote:
> On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu  wrote:
>
 Here is a patch to add -mnop and use it with -fcf-protection.
>>>
>>> +mnop
>>> +Target Report Var(flag_nop) Init(0)
>>> +Support multi-byte NOP code generation.
>>>
>>> the option name is incredibly bad and the documentation doesn't make it
>>> better either.  The invoke.texi docs refer to duplicate {-mcet}.
>>>
>>> Isn't there a -fcf-protection sub-set that can be used to automatically
>>> enable this?  Or simply do this mode by default when
>>> -fcf-protection is used but neither -mcet nor -mibt is enabled?
>>
>> Make -fcf-protection default to multi-byte NOPs works.  Uros,
>> should I prepare a patch?
>
> Please make it an opt-in feature, so the compiler won't litter the
> executable with unnecessary nops without user consent.
>

-fcf-protection is off by default.  Users need to pass -fcf-protection
to enable it.  I will work on such a patch.

Thanks.

-- 
H.J.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Uros Bizjak]

On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu  wrote:

>>> Here is a patch to add -mnop and use it with -fcf-protection.
>>
>> +mnop
>> +Target Report Var(flag_nop) Init(0)
>> +Support multi-byte NOP code generation.
>>
>> the option name is incredibly bad and the documentation doesn't make it
>> better either.  The invoke.texi docs refer to duplicate {-mcet}.
>>
>> Isn't there a -fcf-protection sub-set that can be used to automatically
>> enable this?  Or simply do this mode by default when
>> -fcf-protection is used but neither -mcet nor -mibt is enabled?
>
> Make -fcf-protection default to multi-byte NOPs works.  Uros,
> should I prepare a patch?

Please make it an opt-in feature, so the compiler won't litter the
executable with unnecessary nops without user consent.

Uros.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

On Wed, Apr 18, 2018 at 4:35 AM, Richard Biener
 wrote:
> On Wed, Apr 18, 2018 at 1:24 PM, H.J. Lu  wrote:
>> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu  wrote:
>>> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu  wrote:
 On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu  wrote:
> On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak  wrote:
>> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu  wrote:
>>> -fcf-protection -mcet can't be used with IFUNC features, like symbol
>>> multiversioning or target clone, since IBT/SHSTK are applied to the 
>>> whole
>>> program and they may be disabled in some functions.  But -fcf-protection
>>> is implemented with multi-byte NOPs on all 64-bit processors as well as
>>> 32-bit processors starting with Pentium Pro.  If -fcf-protection 
>>> requires
>>> -mcet, IFUNC features can't be used on Linux when -fcf-protection is
>>> enabled by default.
>>>
>>> This patch changes -fcf-protection to to enable the NOP portion of CET
>>> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of CET
>>> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
>>>
>>> OK for trunk?
>>
>> As said in the PR, NOP sequences have non-zero cost in the executable
>> (they enlarge the executable), so I don't think this feature should be
>> enabled by default.
>>
>> There is always a configure option if someone wants their compiler to
>> always emit relevant multi-byte nops.
>
> What we need is an option to enable -fcf-function with multi-byte NOPs
> without -mcet which enables the full CET ISAs.  A configure option
> without the corresponding the command-line option makes test and
> debug difficult.   I can add
>
> --enable-cf-function-nop or --with-cf-function-nop
>
> with
>
> -fct-function-nop
>

 How about adding -mno-cet, which enables the NOP portion of CET
>>>
>>> I meant -mnop-cet, not -mno-cet.
>>>
>>
>> Here is a patch to add -mnop and use it with -fcf-protection.
>
> +mnop
> +Target Report Var(flag_nop) Init(0)
> +Support multi-byte NOP code generation.
>
> the option name is incredibly bad and the documentation doesn't make it
> better either.  The invoke.texi docs refer to duplicate {-mcet}.
>
> Isn't there a -fcf-protection sub-set that can be used to automatically
> enable this?  Or simply do this mode by default when
> -fcf-protection is used but neither -mcet nor -mibt is enabled?

Make -fcf-protection default to multi-byte NOPs works.  Uros,
should I prepare a patch?

-- 
H.J.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Richard Biener]

On Wed, Apr 18, 2018 at 1:24 PM, H.J. Lu  wrote:
> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu  wrote:
>> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu  wrote:
>>> On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu  wrote:
 On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak  wrote:
> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu  wrote:
>> -fcf-protection -mcet can't be used with IFUNC features, like symbol
>> multiversioning or target clone, since IBT/SHSTK are applied to the whole
>> program and they may be disabled in some functions.  But -fcf-protection
>> is implemented with multi-byte NOPs on all 64-bit processors as well as
>> 32-bit processors starting with Pentium Pro.  If -fcf-protection requires
>> -mcet, IFUNC features can't be used on Linux when -fcf-protection is
>> enabled by default.
>>
>> This patch changes -fcf-protection to to enable the NOP portion of CET
>> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of CET
>> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
>>
>> OK for trunk?
>
> As said in the PR, NOP sequences have non-zero cost in the executable
> (they enlarge the executable), so I don't think this feature should be
> enabled by default.
>
> There is always a configure option if someone wants their compiler to
> always emit relevant multi-byte nops.

 What we need is an option to enable -fcf-function with multi-byte NOPs
 without -mcet which enables the full CET ISAs.  A configure option
 without the corresponding the command-line option makes test and
 debug difficult.   I can add

 --enable-cf-function-nop or --with-cf-function-nop

 with

 -fct-function-nop

>>>
>>> How about adding -mno-cet, which enables the NOP portion of CET
>>
>> I meant -mnop-cet, not -mno-cet.
>>
>
> Here is a patch to add -mnop and use it with -fcf-protection.

+mnop
+Target Report Var(flag_nop) Init(0)
+Support multi-byte NOP code generation.

the option name is incredibly bad and the documentation doesn't make it
better either.  The invoke.texi docs refer to duplicate {-mcet}.

Isn't there a -fcf-protection sub-set that can be used to automatically
enable this?  Or simply do this mode by default when
-fcf-protection is used but neither -mcet nor -mibt is enabled?

>
> --
> H.J.

Re: [PATCH, GCC/ARM] Fix PR85261: ICE with FPSCR setter builtin

[Kyrill Tkachov]

Hi Thomas,

On 18/04/18 12:31, Thomas Preudhomme wrote:

Hi Kyrill,

On 11/04/18 10:02, Kyrill Tkachov wrote:

Hi Thomas,

On 09/04/18 15:29, Thomas Preudhomme wrote:

Hi Ramana,

On 06/04/18 17:17, Thomas Preudhomme wrote:
>
>
> On 06/04/18 17:08, Ramana Radhakrishnan wrote:
>> On 06/04/2018 16:54, Thomas Preudhomme wrote:
>>> Instruction pattern for setting the FPSCR expects the input value to be
>>> in a register. However, __builtin_arm_set_fpscr expander does not ensure
>>> that this is the case and as a result GCC ICEs when the builtin is
>>> called with a constant literal.
>>>
>>> This commit fixes the builtin to force the input value into a register.
>>> It also remove the unneeded volatile in the existing fpscr test and
>>> fixes the function prototype.
>>>
>>> ChangeLog entries are as follows:
>>>
>>> *** gcc/ChangeLog ***
>>>
>>> 2018-04-06  Thomas Preud'homme 
>>>
>>> PR target/85261
>>> * config/arm/arm-builtins.c (arm_expand_builtin): Force input operand
>>> into register.
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>>
>>> 2018-04-06  Thomas Preud'homme 
>>>
>>> PR target/85261
>>> * gcc.target/arm/fpscr.c: Add call to __builtin_arm_set_fpscr with
>>> literal value.  Expect 2 MCR instruction. Fix function prototype.
>>> Remove volatile keyword.
>>>
>>> Testing: Built an arm-none-eabi GCC cross-compiler and testsuite shows
>>> no regression.
>>>
>>> Is this ok for stage4?
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>
>> (sorry about the duplicate for those who get it)
>>
>>
>> LGTM, though in this case I would prefer a bootstrap and regression run
>> as this is automatically exercised most with gcc.dg/atomic_*.c and you
>> really need this tested on linux than just bare-metal as I'm not sure
>> how this gets tested on arm-none-eabi.
>
> Oh it is indeed. Didn't realized it was used anywhere. Will start bootstrap
> right away.

Done with --with-arch=armv8-a --with-mode=thumb --with-fpu=neon-vfpv4
--with-float=hard --enable-languages=c,c++,fortran --with-system-zlib
--enable-plugins --enable-bootstrap. Testsuite for that GCC does not show any
regression either.

Ok to commit?



Thanks for doing this.
This is ok for trunk.


>
>>
>> What about earlier branches, have you looked ? This is a silly target
>> bug and fixes should go back to older branches in this particular case
>> after baking this on trunk for some time.
>
> GCC 6 and 7 are affected as well and a backport will be done once it has baked
> long enough of course.

Will now bootstrap and regtest against GCC 6 and 7. Will let you know once that
is finished.


Backports show no regression on a bootstrapped arm-none-linux-gnueabihf GCC 6 & 
7. Ok to commit those?



Yes, thanks.
Kyrill


Best regards,

Thomas

Re: [PATCH, GCC/ARM] Fix PR85261: ICE with FPSCR setter builtin

[Thomas Preudhomme]

Hi Kyrill,

On 11/04/18 10:02, Kyrill Tkachov wrote:

Hi Thomas,

On 09/04/18 15:29, Thomas Preudhomme wrote:

Hi Ramana,

On 06/04/18 17:17, Thomas Preudhomme wrote:
>
>
> On 06/04/18 17:08, Ramana Radhakrishnan wrote:
>> On 06/04/2018 16:54, Thomas Preudhomme wrote:
>>> Instruction pattern for setting the FPSCR expects the input value to be
>>> in a register. However, __builtin_arm_set_fpscr expander does not ensure
>>> that this is the case and as a result GCC ICEs when the builtin is
>>> called with a constant literal.
>>>
>>> This commit fixes the builtin to force the input value into a register.
>>> It also remove the unneeded volatile in the existing fpscr test and
>>> fixes the function prototype.
>>>
>>> ChangeLog entries are as follows:
>>>
>>> *** gcc/ChangeLog ***
>>>
>>> 2018-04-06  Thomas Preud'homme 
>>>
>>> PR target/85261
>>> * config/arm/arm-builtins.c (arm_expand_builtin): Force input operand
>>> into register.
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>>
>>> 2018-04-06  Thomas Preud'homme 
>>>
>>> PR target/85261
>>> * gcc.target/arm/fpscr.c: Add call to __builtin_arm_set_fpscr with
>>> literal value.  Expect 2 MCR instruction. Fix function prototype.
>>> Remove volatile keyword.
>>>
>>> Testing: Built an arm-none-eabi GCC cross-compiler and testsuite shows
>>> no regression.
>>>
>>> Is this ok for stage4?
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>
>> (sorry about the duplicate for those who get it)
>>
>>
>> LGTM, though in this case I would prefer a bootstrap and regression run
>> as this is automatically exercised most with gcc.dg/atomic_*.c and you
>> really need this tested on linux than just bare-metal as I'm not sure
>> how this gets tested on arm-none-eabi.
>
> Oh it is indeed. Didn't realized it was used anywhere. Will start bootstrap
> right away.

Done with --with-arch=armv8-a --with-mode=thumb --with-fpu=neon-vfpv4
--with-float=hard --enable-languages=c,c++,fortran --with-system-zlib
--enable-plugins --enable-bootstrap. Testsuite for that GCC does not show any
regression either.

Ok to commit?



Thanks for doing this.
This is ok for trunk.


>
>>
>> What about earlier branches, have you looked ? This is a silly target
>> bug and fixes should go back to older branches in this particular case
>> after baking this on trunk for some time.
>
> GCC 6 and 7 are affected as well and a backport will be done once it has baked
> long enough of course.

Will now bootstrap and regtest against GCC 6 and 7. Will let you know once that
is finished.


Backports show no regression on a bootstrapped arm-none-linux-gnueabihf GCC 6 & 
7. Ok to commit those?


Best regards,

Thomas

Do not forget to register ODR types to odr type hash

[Jan Hubicka]

Hi,
this patch fixes misplaced conditional on TYPE_CANONICAL that makes 
odr_type_hash incomplete
and thus we may miss some ODR warnings and/or diverge in devirtualization 
decisions.

Bootstrapped/regtested x86_64-linux, also tested on libreoffice and firefox.

Honza

PR lto/85391
* lto.c (lto_read_decls): Do not test TYPE_CANONICAL before registering 
odr
types.
* g++.dg/lto/pr83121_0.C: Update template.
* g++.dg/lto/pr83121_1.C: Update template.
* g++.dg/lto/pr84805_0.C: Update template.
* g++.dg/lto/pr84805_1.C: Update template.
* g++.dg/lto/pr84805_2.C: Update template.
Index: lto/lto.c
===
--- lto/lto.c   (revision 259434)
+++ lto/lto.c   (working copy)
@@ -1772,12 +1772,13 @@
  seen_type = true;
  num_prevailing_types++;
  lto_fixup_prevailing_type (t);
-   }
- /* Compute the canonical type of all types.
-???  Should be able to assert that !TYPE_CANONICAL.  */
- if (TYPE_P (t) && !TYPE_CANONICAL (t))
-   {
- gimple_register_canonical_type (t);
+
+ /* Compute the canonical type of all types.
+Because SCC components ar estreame in random (hash) order
+we may have enountered the type before while registering
+type canonical of a derived type in the same SCC.  */
+ if (!TYPE_CANONICAL (t))
+   gimple_register_canonical_type (t);
  if (odr_type_p (t))
register_odr_type (t);
}
Index: testsuite/g++.dg/lto/pr83121_0.C
===
--- testsuite/g++.dg/lto/pr83121_0.C(revision 259434)
+++ testsuite/g++.dg/lto/pr83121_0.C(working copy)
@@ -4,8 +4,8 @@
from being optimized away.  */
 
 struct Environment { // { dg-lto-warning "8: type 'struct Environment' 
violates the C\\+\\+ One Definition Rule" }
-  struct AsyncHooks {
-int providers_[2]; // { dg-lto-message "a field of same name but different 
type is defined in another translation unit" }
+  struct AsyncHooks { // { dg-lto-warning "10: type 'struct AsyncHooks' 
violates the C\\+\\+ One Definition Rule" }
+int providers_[2]; // { dg-lto-message "the first difference of 
corresponding definitions is field 'providers_'" }
   };
   AsyncHooks async_hooks_;
 };
Index: testsuite/g++.dg/lto/pr83121_1.C
===
--- testsuite/g++.dg/lto/pr83121_1.C(revision 259434)
+++ testsuite/g++.dg/lto/pr83121_1.C(working copy)
@@ -1,8 +1,8 @@
 struct Environment {
-  struct AsyncHooks { // { dg-lto-warning "10: type 'struct AsyncHooks' 
violates the C\\+\\+ One Definition Rule" }
-int providers_[1]; // { dg-lto-message "the first difference of 
corresponding definitions is field 'providers_'" }
+  struct AsyncHooks {
+int providers_[1];
   };
-  AsyncHooks async_hooks_;
+  AsyncHooks async_hooks_; // { dg-lto-message "a field of same name but 
different type is defined in another translation unit" }
 };
 void fn1() { Environment a; }
 int main ()
Index: testsuite/g++.dg/lto/pr84805_0.C
===
--- testsuite/g++.dg/lto/pr84805_0.C(revision 259434)
+++ testsuite/g++.dg/lto/pr84805_0.C(working copy)
@@ -1,5 +1,5 @@
 // { dg-lto-do link }
-// { dg-lto-options {{-O2 -fPIC -shared -flto}} }
+// { dg-lto-options {{-O0 -fPIC -shared -flto}} }
 
 template < typename _Tp, _Tp __v > struct integral_constant {
   static constexpr _Tp value = __v;
@@ -9,7 +9,7 @@
 struct is_void : __is_void_helper {};
 template < typename > struct is_array : false_type {};
 namespace __gnu_cxx {
-enum _Lock_policy { _S_single, _S_mutex, _S_atomic };
+enum _Lock_policy { _S_single, _S_mutex, _S_atomic }; // { dg-lto-warning "6: 
type '_Lock_policy' violates the C\\+\\+ One Definition Rule" }
 const _Lock_policy __default_lock_policy = _S_atomic;
 } namespace std {
 using __gnu_cxx::_Lock_policy;
@@ -21,7 +21,7 @@
bool = is_void::value >
 class __shared_ptr_access {};
 template < typename _Tp, _Lock_policy _Lp >
-class __shared_ptr : __shared_ptr_access< _Tp, _Lp > {
+class __shared_ptr : __shared_ptr_access< _Tp, _Lp > { // { dg-lto-warning "7: 
type 'struct __shared_ptr' violates the C\\+\\+ One Definition Rule" }
   using element_type = _Tp;
   element_type *_M_ptr;
   __shared_count< _Lp > _M_refcount;
@@ -88,7 +88,7 @@
 class ExtSheetBuffer;
 class ExcelToSc;
 class XclImpColRowSettings;
-struct RootData {
+struct RootData { // { dg-lto-warning "8: type 'struct RootData' violates the 
C\\+\\+ One Definition Rule" }
   BiffTyp eDateiTyp;
   ExtSheetBuffer *pExtSheetBuff;
   SharedFormulaBuffer *pShrfmlaBuff;
Index: testsuite/g++.dg/lto/pr84805_1.C

Re: [PATCH] x86: Compile with -fcf-protection=none -mno-cet

[H.J. Lu]

On Wed, Apr 18, 2018 at 1:59 AM, Tsimbalist, Igor V
 wrote:
>> -Original Message-
>> From: Lu, Hongjiu
>> Sent: Sunday, April 15, 2018 12:59 PM
>> To: gcc-patches@gcc.gnu.org; Uros Bizjak ; Tsimbalist,
>> Igor V 
>> Subject: [PATCH] x86: Compile with -fcf-protection=none -mno-cet
>>
>> These tests must be compiled with -fcf-protection=none -mno-cet.
>
> Why -mno-cet is needed? -fcf-protection=none should not require any extra 
> options.
>
> Igor
>
>> OK for trunk?
>>
>> H.J.
>> 
>>   * c-c++-common/attr-nocf-check-1.c: Compile with
>>   -fcf-protection=none -mno-cet for x86 targets.
>>   * c-c++-common/attr-nocf-check-3.c: Likewise.
>>   * gcc.dg/march-generic.c: Likewise.
>>   * gcc.target/i386/align-limit.c: Likewise.
>>   * gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
>>   * gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
>>   * gcc.target/i386/ret-thunk-26.c: Likewise.

This patch has been superseded by

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00868.html


-- 
H.J.

Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[H.J. Lu]

On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu  wrote:
> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu  wrote:
>> On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu  wrote:
>>> On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak  wrote:
 On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu  wrote:
> -fcf-protection -mcet can't be used with IFUNC features, like symbol
> multiversioning or target clone, since IBT/SHSTK are applied to the whole
> program and they may be disabled in some functions.  But -fcf-protection
> is implemented with multi-byte NOPs on all 64-bit processors as well as
> 32-bit processors starting with Pentium Pro.  If -fcf-protection requires
> -mcet, IFUNC features can't be used on Linux when -fcf-protection is
> enabled by default.
>
> This patch changes -fcf-protection to to enable the NOP portion of CET
> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of CET
> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
>
> OK for trunk?

 As said in the PR, NOP sequences have non-zero cost in the executable
 (they enlarge the executable), so I don't think this feature should be
 enabled by default.

 There is always a configure option if someone wants their compiler to
 always emit relevant multi-byte nops.
>>>
>>> What we need is an option to enable -fcf-function with multi-byte NOPs
>>> without -mcet which enables the full CET ISAs.  A configure option
>>> without the corresponding the command-line option makes test and
>>> debug difficult.   I can add
>>>
>>> --enable-cf-function-nop or --with-cf-function-nop
>>>
>>> with
>>>
>>> -fct-function-nop
>>>
>>
>> How about adding -mno-cet, which enables the NOP portion of CET
>
> I meant -mnop-cet, not -mno-cet.
>

Here is a patch to add -mnop and use it with -fcf-protection.


-- 
H.J.
From cb4446aa122dfb7711240612c013e4cdbd73971f Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 16 Apr 2018 14:13:10 -0700
Subject: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

-fcf-protection -mcet can't be used with IFUNC features, like symbol
multiversioning or target clone, since IBT/SHSTK are applied to the whole
program and they may be disabled in some functions.  But -fcf-protection
is implemented with multi-byte NOPs on all 64-bit processors as well as
32-bit processors starting with Pentium Pro.  If -fcf-protection requires
-mcet, IFUNC features can't be used on Linux when -fcf-protection is
enabled by default.

This patch adds -mnop to enable multi-byte NOP code generation which
can be used with -fcf-protection to implement indirect branch and return
address tracking without -mcet.

gcc/

	PR target/85417
	* config/i386/cet.c (file_end_indicate_exec_stack_and_cet):
	Check flag_cf_protection instead of TARGET_IBT and TARGET_SHSTK.
	* config/i386/i386.c (pass_insert_endbranch::gate): Don't check
	TARGET_IBT.
	(ix86_option_override_internal): Allow  -fcf-protection with
	multi-byte NOPs unless CET is disabled explicitly.
	(ix86_trampoline_init): Don't check TARGET_IBT.
	(x86_output_mi_thunk): Likewise.
	(ix86_notrack_prefixed_insn_p): Likewise.
	* config/i386/i386.md (rdssp): Also enable for flag_nop.
	(incssp): Likewise.
	(nop_endbr): Likewise.
	* config/i386/i386.opt: Add -mnop.
	* doc/invoke.texi: Document -mnop.

gcc/testsuite/

	PR target/85417
	* c-c++-common/attr-nocf-check-1.c: Compile with
	-fcf-protection=none.
	* c-c++-common/attr-nocf-check-3.c: Likewise.
	* gcc.dg/march-generic.c: Likewise.
	* gcc.target/i386/align-limit.c: Likewise.
	* c-c++-common/fcf-protection-1.c: Compile with -mno-nop for
	x86 targets.
	* c-c++-common/fcf-protection-2.c: Likewise.
	* c-c++-common/fcf-protection-3.c: Likewise.
	* c-c++-common/fcf-protection-5.c: Likewise.
	* c-c++-common/fcf-protection-6.c: Likewise.
	* c-c++-common/fcf-protection-7.c: Likewise.
	* gcc.target/i386/cet-notrack-icf-1.c: Compile with
	-fcf-protection=none.
	* gcc.target/i386/cet-notrack-icf-3.c: Likewise.
	* gcc.target/i386/cet-property-2.c: Likewise.
	* gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
	* gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
	* gcc.target/i386/ret-thunk-26.c: Likewise.
	* gcc.target/i386/cet-label-3.c: New test.
	* gcc.target/i386/cet-property-3.c: Likewise.
	* gcc.target/i386/cet-sjlj-7.c: Likewise.
	* gcc.target/i386/pr85417-1.c: Likewise.
	* gcc.target/i386/pr85417-2.c: Likewise.
	* gcc.target/i386/pr85403.c: Compile with -mno-nop.
---
 gcc/config/i386/cet.c  |  4 +-
 gcc/config/i386/i386.c | 23 +++
 gcc/config/i386/i386.md|  6 +--
 gcc/config/i386/i386.opt   |  4 ++
 gcc/doc/invoke.texi| 14 ++-
 gcc/testsuite/c-c++-common/attr-nocf-check-1.c |  1 +
 

[PATCH] PR libstdc++/84442 if _Exit isn't declared then use _exit instead

[Jonathan Wakely]

Tested x86_64-linux, committed to trunk.
commit f02b9c3a2b9ffe78613ba57e61a4f48413144218
Author: Jonathan Wakely 
Date:   Wed Apr 18 12:15:16 2018 +0100

PR libstdc++/84442 if _Exit isn't declared then use _exit instead

PR libstdc++/84442
* testsuite/30_threads/thread/cons/terminate.cc
[!_GLIBCXX_USE_C99_STDLIB] : Use _exit or std::exit instead of 
_Exit.

diff --git a/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc 
b/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc
index 63c3b084c5c..cb6fc3eb120 100644
--- a/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc
+++ b/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc
@@ -25,10 +25,19 @@
 #include 
 #include 
 #include 
+#if !_GLIBCXX_USE_C99_STDLIB && defined _GLIBCXX_HAVE_UNISTD_H
+# include 
+#endif
 
 void handle_terminate()
 {
+#if _GLIBCXX_USE_C99_STDLIB
   std::_Exit(0);
+#elif defined _GLIBCXX_HAVE_UNISTD_H
+  _exit(0);
+#else
+  std::exit(0);
+#endif
 }
 
 void f() { throw 1; }
@@ -38,7 +47,9 @@ test01()
 {
   std::set_terminate(handle_terminate);
   std::thread t(f);
+  // This should call the terminate handler and exit with zero status:
   t.join();
+  // Should not reach here:
   std::abort();
 }
 

[wwwdocs] Mention powerpc*-*-*spe* deprecation in gcc-8/changes.html

[Jakub Jelinek]

Hi!

The following patch mentions the deprecation of powerpc*spe*.
Ok for wwwdocs?

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.66
diff -u -p -r1.66 changes.html
--- changes.html16 Apr 2018 13:39:03 -  1.66
+++ changes.html18 Apr 2018 09:04:14 -
@@ -42,6 +42,14 @@ a work-in-progress.
 The non-standard C++0x std::copy_exception function was
 removed. std::make_exception_ptr should be used instead.
   
+  Support for the powerpc*-*-*spe* target ports which have
+been recently unmaintained and untested in GCC has been declared
+obsolete in GCC 8 as announced
+https://gcc.gnu.org/ml/gcc/2018-04/msg00102.html;>here.
+Unless there is activity to revive them, the
+next release of GCC will have their sources permanently
+removed.
+  
 
 
 
@@ -1162,7 +1170,8 @@ is now easier-to-read.
 
   
 The PowerPC SPE support is split off to a separate powerpcspe
-port.  See the separate entry for that new port.
+port.  The separate port is deprecated and might be removed in a future
+release.
   
   
 The Paired Single support (as used on some PPC750 CPUs,
@@ -1181,8 +1190,6 @@ is now easier-to-read.
   
 
 
-PowerPC SPE
-
 
 
 

Jakub

Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

[Pedro Alves]

On 04/17/2018 11:10 PM, Joshua Watt wrote:
> On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
>> On 04/17/2018 06:24 PM, Joshua Watt wrote:
>>> Ping? I'd really like to get this in binutils, which apparently
>>> requires getting it here first.
>>
>> I think it would help if you mentioned what this is and
>> what is the intended use case.
> 
> Ah, that would probably be helpful! Yes, this was discussed on the
> binutils mailing list, see:
> https://sourceware.org/ml/binutils/2018-02/msg00260.html
> 
> In short summary: the gold linker doesn't currently build for mingw,
> but only because it is attempting to link against libpthread
> incorrectly on that platform. Instead of bringing in more specialized
> logic to account for that, I opted to include the autotools
> ax_pthread.m4 macro (this patch) that automatically handles discovering
> pthreads on a wide variety of platforms and compilers, including mingw.
> 
> binutils slaves its config/ directory to GCC, so the patch is required
> to be committed here first, and then it will be ported over there.

Thanks, that helps indeed.

I agree that the ax_pthread.m4 approach makes sense.  Better to use
a field-tested macro than reinvent the wheel.  We're using other
files from the autoconf-archive archive already, for similar reasons
(e.g., config/ax_check_define.m4, and gdb/ax_cxx_compile_stdcxx.m4).

Since GCC won't be using it (yet at least, but it's conceivable it
could make use of it in future), there should be no harm in
installing it even if GCC is in stage 4, IMO.

I don't have the authority to approve it, though.

Thanks,
Pedro Alves

[PATCH] RISC-V: Pass --no-relax to linker if -mno-relax is present.

[Kito Cheng]

Hi all:

Palmer has been added -mno-relax option before, I propose it should
also pass to linker during link phase.

ChangeLog:
2018-04-18  Kito Cheng  

* config/riscv/elf.h (LINK_SPEC): Pass --no-relax if
-mno-relax is present.
* config/riscv/linux.h (LINK_SPEC): Ditto.
From 1f18c78eb54c9e5aa66b4490af61f8803fa47267 Mon Sep 17 00:00:00 2001
From: Kito Cheng 
Date: Wed, 18 Apr 2018 11:22:45 +0800
Subject: [PATCH] RISC-V: Pass --no-relax to linker if -mno-relax is present.

2018-04-18  Kito Cheng  

	* config/riscv/elf.h (LINK_SPEC): Pass --no-relax if
	-mno-relax is present.
	* config/riscv/linux.h (LINK_SPEC): Ditto.
---
 gcc/config/riscv/elf.h   | 1 +
 gcc/config/riscv/linux.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
index f39e83234d2..a8357bb6e18 100644
--- a/gcc/config/riscv/elf.h
+++ b/gcc/config/riscv/elf.h
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #define LINK_SPEC "\
 -melf" XLEN_SPEC "lriscv \
+%{mno-relax:--no-relax} \
 %{shared}"
 
 /* Link against Newlib libraries, because the ELF backend assumes Newlib.
diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
index ad03654e8d6..aa8a28d5d31 100644
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -51,6 +51,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #define LINK_SPEC "\
 -melf" XLEN_SPEC "lriscv \
+%{mno-relax:--no-relax} \
 %{shared} \
   %{!shared: \
 %{!static: \
-- 
2.11.2

Re: [wwwdocs] Mention powerpc*-*-*spe* deprecation in gcc-8/changes.html

[Richard Biener]

On Wed, 18 Apr 2018, Jakub Jelinek wrote:

> Hi!
> 
> The following patch mentions the deprecation of powerpc*spe*.
> Ok for wwwdocs?

OK.

> Index: changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
> retrieving revision 1.66
> diff -u -p -r1.66 changes.html
> --- changes.html  16 Apr 2018 13:39:03 -  1.66
> +++ changes.html  18 Apr 2018 09:04:14 -
> @@ -42,6 +42,14 @@ a work-in-progress.
>  The non-standard C++0x std::copy_exception function was
>  removed. std::make_exception_ptr should be used instead.
>
> +  Support for the powerpc*-*-*spe* target ports which 
> have
> +been recently unmaintained and untested in GCC has been declared
> +obsolete in GCC 8 as announced
> +https://gcc.gnu.org/ml/gcc/2018-04/msg00102.html;>here.
> +Unless there is activity to revive them, the
> +next release of GCC will have their sources permanently
> +removed.
> +  
>  
>  
>  
> @@ -1162,7 +1170,8 @@ is now easier-to-read.
>  
>
>  The PowerPC SPE support is split off to a separate 
> powerpcspe
> -port.  See the separate entry for that new port.
> +port.  The separate port is deprecated and might be removed in a future
> +release.
>
>
>  The Paired Single support (as used on some PPC750 CPUs,
> @@ -1181,8 +1190,6 @@ is now easier-to-read.
>
>  
>  
> -PowerPC SPE
> -
>  
>  
>  
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[og7, openacc, libgomp, testsuite] Fix asserts in non-scalar-data.C

[Tom de Vries]

[ was: Re: [gomp4] fix c++ reference mappings in openacc ]


On 01/21/2016 04:47 AM, Cesar Philippidis wrote:

diff --git a/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C 
b/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
new file mode 100644
index 000..180e86f
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
@@ -0,0 +1,109 @@
+// Ensure that a non-scalar dummy arguments which are implicitly used inside
+// offloaded regions are properly mapped using present_or_copy.
+
+// { dg-do run }
+
+#include 
+
+const int n = 100;
+
+struct data {
+  int v;
+};
+
+void
+kernels_present (data , int )
+{
+#pragma acc kernels present (d, x) default (none)
+  {
+d.v = x;
+  }
+}
+
+void
+parallel_present (data , int )
+{
+#pragma acc parallel present (d, x) default (none)
+  {
+d.v = x;
+  }
+}
+
+void
+kernels_implicit (data , int )
+{
+#pragma acc kernels
+  {
+d.v = x;
+  }
+}
+
+void
+parallel_implicit (data , int )
+{
+#pragma acc parallel
+  {
+d.v = x;
+  }
+}
+
+void
+reference_data (data , int )
+{
+#pragma acc data copy(d, x)
+  {
+kernels_present (d, x);
+
+#pragma acc update host(d)
+assert (d.v == x);
+
+x = 200;
+#pragma acc update device(x)
+
+parallel_present (d, x);
+  }
+
+  assert (d.v = x);
+
+  x = 300;
+  kernels_implicit (d, x);
+  assert (d.v = x);
+
+  x = 400;
+  parallel_implicit (d, x);
+  assert (d.v = x);
+}
+
+int
+main ()
+{
+  data d;
+  int x = 100;
+
+#pragma acc data copy(d, x)
+  {
+kernels_present (d, x);
+
+#pragma acc update host(d)
+assert (d.v == x);
+
+x = 200;
+#pragma acc update device(x)
+
+parallel_present (d, x);
+  }
+
+  assert (d.v = x);
+
+  x = 300;
+  kernels_implicit (d, x);
+  assert (d.v = x);
+
+  x = 400;
+  parallel_implicit (d, x);
+  assert (d.v = x);
+
+  reference_data (d, x);
+
+  return 0;
+}



Some of these assert have assigns in them.

Fixed in attached patch, committed.

Thanks,
- Tom
[openacc, libgomp, testsuite] Fix asserts in non-scalar-data.C

2018-04-18  Tom de Vries  

	* testsuite/libgomp.oacc-c++/non-scalar-data.C (reference_data, main):
	Fix asserts.

---
 libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C b/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
index f24e31e..8143533 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
+++ b/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
@@ -69,15 +69,15 @@ reference_data (data , int )
 parallel_present (d, x);
   }
 
-  assert (d.v = x);
+  assert (d.v == x);
 
   x = 300;
   kernels_implicit (d, x);
-  assert (d.v = x);
+  assert (d.v == x);
 
   x = 400;
   parallel_implicit (d, x);
-  assert (d.v = x);
+  assert (d.v == x);
 }
 
 int
@@ -99,15 +99,15 @@ main ()
 parallel_present (d, x);
   }
 
-  assert (d.v = x);
+  assert (d.v == x);
 
   x = 300;
   kernels_implicit (d, x);
-  assert (d.v = x);
+  assert (d.v == x);
 
   x = 400;
   parallel_implicit (d, x);
-  assert (d.v = x);
+  assert (d.v == x);
 
   reference_data (d, x);
 

RE: [PATCH] x86: Compile with -fcf-protection=none -mno-cet

[Tsimbalist, Igor V]

> -Original Message-
> From: Lu, Hongjiu
> Sent: Sunday, April 15, 2018 12:59 PM
> To: gcc-patches@gcc.gnu.org; Uros Bizjak ; Tsimbalist,
> Igor V 
> Subject: [PATCH] x86: Compile with -fcf-protection=none -mno-cet
> 
> These tests must be compiled with -fcf-protection=none -mno-cet.

Why -mno-cet is needed? -fcf-protection=none should not require any extra 
options.

Igor

> OK for trunk?
> 
> H.J.
> 
>   * c-c++-common/attr-nocf-check-1.c: Compile with
>   -fcf-protection=none -mno-cet for x86 targets.
>   * c-c++-common/attr-nocf-check-3.c: Likewise.
>   * gcc.dg/march-generic.c: Likewise.
>   * gcc.target/i386/align-limit.c: Likewise.
>   * gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
>   * gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
>   * gcc.target/i386/ret-thunk-26.c: Likewise.
> ---
>  gcc/testsuite/c-c++-common/attr-nocf-check-1.c  | 1 +
>  gcc/testsuite/c-c++-common/attr-nocf-check-3.c  | 1 +
>  gcc/testsuite/gcc.dg/march-generic.c| 2 +-
>  gcc/testsuite/gcc.target/i386/align-limit.c | 2 +-
>  gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c   | 2 +-
>  gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c | 2 +-
>  gcc/testsuite/gcc.target/i386/ret-thunk-26.c| 2 +-
>  7 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> b/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> index 15f69731b91..4d579136b5a 100644
> --- a/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> +++ b/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-additional-options "-fcf-protection=none -mno-cet" { target i?86-*-
> * x86_64-*-* } } */
> 
>  int func (int) __attribute__ ((nocf_check)); /* { dg-warning "'nocf_check'
> attribute ignored" } */
>  int (*fptr) (int) __attribute__ ((nocf_check)); /* { dg-warning "'nocf_check'
> attribute ignored" } */
> diff --git a/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> b/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> index ad1ca7eec9b..da58d560a31 100644
> --- a/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> +++ b/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-additional-options "-fcf-protection=none -mno-cet" { target i?86-*-
> * x86_64-*-* } } */
> 
>  int  foo (void) __attribute__ ((nocf_check)); /* { dg-warning "'nocf_check'
> attribute ignored" } */
>  void (*foo1) (void) __attribute__((nocf_check)); /* { dg-warning 
> "'nocf_check'
> attribute ignored" } */
> diff --git a/gcc/testsuite/gcc.dg/march-generic.c
> b/gcc/testsuite/gcc.dg/march-generic.c
> index fb5b83c7d74..94237fee0ca 100644
> --- a/gcc/testsuite/gcc.dg/march-generic.c
> +++ b/gcc/testsuite/gcc.dg/march-generic.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile { target i?86-*-* x86_64-*-* } } */
>  /* { dg-skip-if "" { *-*-* } { "-march=*" } { "" } } */
> -/* { dg-options "-march=generic" } */
> +/* { dg-options "-march=generic -fcf-protection=none -mno-cet" } */
>  /* { dg-error "'generic' CPU can be used only for '-mtune=' switch" "" {
> target *-*-* } 0 } */
>  /* { dg-bogus "march" "" { target *-*-* } 0 } */
>  int i;
> diff --git a/gcc/testsuite/gcc.target/i386/align-limit.c
> b/gcc/testsuite/gcc.target/i386/align-limit.c
> index d3d8dc5656e..2560e7b242f 100644
> --- a/gcc/testsuite/gcc.target/i386/align-limit.c
> +++ b/gcc/testsuite/gcc.target/i386/align-limit.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -falign-functions=64 -flimit-function-alignment -
> march=amdfam10" } */
> +/* { dg-options "-O2 -falign-functions=64 -flimit-function-alignment -
> march=amdfam10 -fcf-protection=none -mno-cet" } */
>  /* { dg-final { scan-assembler ".p2align 6,,1" } } */
>  /* { dg-final { scan-assembler-not ".p2align 6,,63" } } */
> 
> diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> index d53fc887dcc..64c2ff66692 100644
> --- a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> +++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-
> return=keep -fno-pic" } */
> +/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-
> return=keep -fno-pic -fcf-protection=none -mno-cet" } */
> 
>  void func0 (void);
>  void func1 (void);
> diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
> b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
> index 2b9a33e93dc..ff0138b4878 100644
> --- a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
> +++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-
> return=keep 

[og7, openacc, libgomp, testsuite] Fix asserts in firstprivate-int.{c,C}

[Tom de Vries]

[ was: Re: [gomp4] enable GOMP_MAP_FIRSTPRIVATE_INT in OpenACC ]

On 01/27/2017 04:45 PM, Cesar Philippidis wrote:


diff --git a/libgomp/testsuite/libgomp.oacc-c++/firstprivate-int.C 
b/libgomp/testsuite/libgomp.oacc-c++/firstprivate-int.C



+  assert(i8o = i8i);
+  assert(i16o = i16i);
+  assert(i32o = i32i);
+  assert(i64o = i64i);
+
+  assert(u8o = u8i);
+  assert(u16o = u16i);
+  assert(u32o = u32i);
+  assert(u64o = u64i);
+
+  assert(r32o = r32i);
+  assert(r64o = r64i);
+
+  assert(cio = cii);
+  assert(cfo = cfi);
+  assert(cdo = cdi);



diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-int.c 
b/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-int.c



+  assert(i8o = i8i);
+  assert(i16o = i16i);
+  assert(i32o = i32i);
+  assert(i64o = i64i);
+
+  assert(u8o = u8i);
+  assert(u16o = u16i);
+  assert(u32o = u32i);
+  assert(u64o = u64i);
+
+  assert(r32o = r32i);
+  assert(r64o = r64i);
+
+  assert(cio = cii);
+  assert(cfo = cfi);
+  assert(cdo = cdi);


These assert have assigns in them.

Fixed in attached patch, committed.

Thanks,
- Tom
[openacc, libgomp, testsuite] Fix asserts in firstprivate-int.{c,C}

2018-04-18  Tom de Vries  

	* testsuite/libgomp.oacc-c++/firstprivate-int.C (main): Fix asserts.
	* testsuite/libgomp.oacc-c-c++-common/firstprivate-int.c (main): Same.

---
 .../testsuite/libgomp.oacc-c++/firstprivate-int.C  | 26 +++---
 .../libgomp.oacc-c-c++-common/firstprivate-int.c   | 26 +++---
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/libgomp/testsuite/libgomp.oacc-c++/firstprivate-int.C b/libgomp/testsuite/libgomp.oacc-c++/firstprivate-int.C
index 94667b5..c7d90d9 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/firstprivate-int.C
+++ b/libgomp/testsuite/libgomp.oacc-c++/firstprivate-int.C
@@ -62,22 +62,22 @@ main ()
 	u16o, u32i, u32o, u64i, u64o, r32i, r32o, r64i, r64o, cii, cio,
 	cfi, cfo, cdi, cdo);
 
-  assert(i8o = i8i);
-  assert(i16o = i16i);
-  assert(i32o = i32i);
-  assert(i64o = i64i);
+  assert (i8o == i8i);
+  assert (i16o == i16i);
+  assert (i32o == i32i);
+  assert (i64o == i64i);
 
-  assert(u8o = u8i);
-  assert(u16o = u16i);
-  assert(u32o = u32i);
-  assert(u64o = u64i);
+  assert (u8o == u8i);
+  assert (u16o == u16i);
+  assert (u32o == u32i);
+  assert (u64o == u64i);
 
-  assert(r32o = r32i);
-  assert(r64o = r64i);
+  assert (r32o == r32i);
+  assert (r64o == r64i);
 
-  assert(cio = cii);
-  assert(cfo = cfi);
-  assert(cdo = cdi);
+  assert (cio == cii);
+  assert (cfo == cfi);
+  assert (cdo == cdi);
 
   return 0;
 }
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-int.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-int.c
index d9da9a0..8abb610 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-int.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-int.c
@@ -46,22 +46,22 @@ main ()
 cdo = cdi;
   }
 
-  assert(i8o = i8i);
-  assert(i16o = i16i);
-  assert(i32o = i32i);
-  assert(i64o = i64i);
+  assert (i8o == i8i);
+  assert (i16o == i16i);
+  assert (i32o == i32i);
+  assert (i64o == i64i);
 
-  assert(u8o = u8i);
-  assert(u16o = u16i);
-  assert(u32o = u32i);
-  assert(u64o = u64i);
+  assert (u8o == u8i);
+  assert (u16o == u16i);
+  assert (u32o == u32i);
+  assert (u64o == u64i);
 
-  assert(r32o = r32i);
-  assert(r64o = r64i);
+  assert (r32o == r32i);
+  assert (r64o == r64i);
 
-  assert(cio = cii);
-  assert(cfo = cfi);
-  assert(cdo = cdi);
+  assert (cio == cii);
+  assert (cfo == cfi);
+  assert (cdo == cdi);
 
   return 0;
 }

Re: [PATCH] Fix ICE with single element vector

[Richard Biener]

On Mon, Apr 16, 2018 at 6:16 PM, Andreas Krebbel
 wrote:
> I did run into an ICE with a single element vector triggered by
> dividing the number of elements by 2 with exact_div here:
>
> tree-vect-data-refs.c:5132
>
>   else
> {
>   /* If length is not equal to 3 then only power of 2 is supported.  
> */
>   gcc_assert (pow2p_hwi (count));
>   poly_uint64 nelt = GET_MODE_NUNITS (mode);
>
>   /* The encoding has 2 interleaved stepped patterns.  */
>   vec_perm_builder sel (nelt, 2, 3);
>   sel.quick_grow (6);
>   for (i = 0; i < 3; i++)
> {
>   sel[i * 2] = i;
>   sel[i * 2 + 1] = i + nelt;
> }
>   vec_perm_indices indices (sel, 2, nelt);
>   if (can_vec_perm_const_p (mode, indices))
> {
>   for (i = 0; i < 6; i++)
> sel[i] += exact_div (nelt, 2);<-
>   indices.new_vector (sel, 2, nelt);
>   if (can_vec_perm_const_p (mode, indices))
> return true;
> }
> }
>
> The patch adds a check to prevent this.

Testcase?

What's the group size?

Did it work before the poly-int stuff?  Single-element vectors are
somewhat "special" - where do they appear for you?

Richard.

> Ok?
>
> -Andreas-
>
> gcc/ChangeLog:
>
> 2018-04-16  Andreas Krebbel  
>
> * tree-vect-data-refs.c (vect_grouped_store_supported): Exit for
> single element vectors.
> ---
>  gcc/tree-vect-data-refs.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
> index 161a886..01e28ca 100644
> --- a/gcc/tree-vect-data-refs.c
> +++ b/gcc/tree-vect-data-refs.c
> @@ -5135,6 +5135,9 @@ vect_grouped_store_supported (tree vectype, unsigned 
> HOST_WIDE_INT count)
>   gcc_assert (pow2p_hwi (count));
>   poly_uint64 nelt = GET_MODE_NUNITS (mode);
>
> + if (maybe_eq (nelt, 1U))
> +   return false;
> +
>   /* The encoding has 2 interleaved stepped patterns.  */
>   vec_perm_builder sel (nelt, 2, 3);
>   sel.quick_grow (6);
> --
> 2.9.1
>

Re: [PATCH] x86: Compile with -fcf-protection=none -mno-cet

[Richard Biener]

On Sun, Apr 15, 2018 at 12:59 PM, H.J. Lu  wrote:
> These tests must be compiled with -fcf-protection=none -mno-cet.

Required for correctness or just to make the dump scannings happy?
In that case I'd prefer the more descriptive dg-skip-if

> OK for trunk?
>
> H.J.
> 
> * c-c++-common/attr-nocf-check-1.c: Compile with
> -fcf-protection=none -mno-cet for x86 targets.
> * c-c++-common/attr-nocf-check-3.c: Likewise.
> * gcc.dg/march-generic.c: Likewise.
> * gcc.target/i386/align-limit.c: Likewise.
> * gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
> * gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
> * gcc.target/i386/ret-thunk-26.c: Likewise.
> ---
>  gcc/testsuite/c-c++-common/attr-nocf-check-1.c  | 1 +
>  gcc/testsuite/c-c++-common/attr-nocf-check-3.c  | 1 +
>  gcc/testsuite/gcc.dg/march-generic.c| 2 +-
>  gcc/testsuite/gcc.target/i386/align-limit.c | 2 +-
>  gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c   | 2 +-
>  gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c | 2 +-
>  gcc/testsuite/gcc.target/i386/ret-thunk-26.c| 2 +-
>  7 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/testsuite/c-c++-common/attr-nocf-check-1.c 
> b/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> index 15f69731b91..4d579136b5a 100644
> --- a/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> +++ b/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-additional-options "-fcf-protection=none -mno-cet" { target i?86-*-* 
> x86_64-*-* } } */
>
>  int func (int) __attribute__ ((nocf_check)); /* { dg-warning "'nocf_check' 
> attribute ignored" } */
>  int (*fptr) (int) __attribute__ ((nocf_check)); /* { dg-warning 
> "'nocf_check' attribute ignored" } */
> diff --git a/gcc/testsuite/c-c++-common/attr-nocf-check-3.c 
> b/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> index ad1ca7eec9b..da58d560a31 100644
> --- a/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> +++ b/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-additional-options "-fcf-protection=none -mno-cet" { target i?86-*-* 
> x86_64-*-* } } */
>
>  int  foo (void) __attribute__ ((nocf_check)); /* { dg-warning "'nocf_check' 
> attribute ignored" } */
>  void (*foo1) (void) __attribute__((nocf_check)); /* { dg-warning 
> "'nocf_check' attribute ignored" } */
> diff --git a/gcc/testsuite/gcc.dg/march-generic.c 
> b/gcc/testsuite/gcc.dg/march-generic.c
> index fb5b83c7d74..94237fee0ca 100644
> --- a/gcc/testsuite/gcc.dg/march-generic.c
> +++ b/gcc/testsuite/gcc.dg/march-generic.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile { target i?86-*-* x86_64-*-* } } */
>  /* { dg-skip-if "" { *-*-* } { "-march=*" } { "" } } */
> -/* { dg-options "-march=generic" } */
> +/* { dg-options "-march=generic -fcf-protection=none -mno-cet" } */
>  /* { dg-error "'generic' CPU can be used only for '-mtune=' switch" "" { 
> target *-*-* } 0 } */
>  /* { dg-bogus "march" "" { target *-*-* } 0 } */
>  int i;
> diff --git a/gcc/testsuite/gcc.target/i386/align-limit.c 
> b/gcc/testsuite/gcc.target/i386/align-limit.c
> index d3d8dc5656e..2560e7b242f 100644
> --- a/gcc/testsuite/gcc.target/i386/align-limit.c
> +++ b/gcc/testsuite/gcc.target/i386/align-limit.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -falign-functions=64 -flimit-function-alignment 
> -march=amdfam10" } */
> +/* { dg-options "-O2 -falign-functions=64 -flimit-function-alignment 
> -march=amdfam10 -fcf-protection=none -mno-cet" } */
>  /* { dg-final { scan-assembler ".p2align 6,,1" } } */
>  /* { dg-final { scan-assembler-not ".p2align 6,,63" } } */
>
> diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c 
> b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> index d53fc887dcc..64c2ff66692 100644
> --- a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> +++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep 
> -fno-pic" } */
> +/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep 
> -fno-pic -fcf-protection=none -mno-cet" } */
>
>  void func0 (void);
>  void func1 (void);
> diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c 
> b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
> index 2b9a33e93dc..ff0138b4878 100644
> --- a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
> +++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep 
> -mindirect-branch=thunk-extern -fno-pic" } */
> +/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep 
> -mindirect-branch=thunk-extern -fno-pic 

Re: [PATCH][AArch64/arm] PR testsuite/85326 Avoid C++ tests when C++ compiler not present

[Kyrill Tkachov]

On 17/04/18 21:47, Jakub Jelinek wrote:

On Tue, Apr 17, 2018 at 04:36:54PM +0100, Kyrill Tkachov wrote:

This patch makes the arm and aarch64 testsuite safe for when a C++ compiler is 
not present.
This involves moving .C files into g++.dg/other/ and guarding them with the 
appropriate target check.

For others it just means renaming them from .C to .c.

For gcc.target/aarch64/simd/pr67896.C this means adjusting the error messages 
to look
for the errors that the C frontend gives for conflicting types rather than what 
C++ gives.

This fixes the errors seen when testing a non-bootstrapped C-only GCC and the 
tests
still pass on normal testing setups and the tests that are in g++.dg appear 
UNSUPPORTED
on the targets that they don't pertain to.

Tested this on arm-none-linux-gnueabihf and aarch64-none-linux-gnu.

Sorry for missing it in review.  I've noticed that
+FAIL: g++.dg/other/pr81422.C  -std=gnu++98 (test for excess errors)
on both x86_64-linux and i686-linux, so added the needed c++11 effective
target to the test and then noticed a couple of further things.

Tested on x86_64-linux with -m32/-m64, committed to trunk as obvious:


Thanks Jakub, sorry for missing these.

Kyrill


2018-04-17  Jakub Jelinek  

PR testsuite/85326
* g++.dg/other/pr81422.C: Require effective target tls and c++11.
* g++.dg/other/pr60675.C: Likewise.  Remove -std=c++11 from dg-options.
* g++.dg/other/sve_tls_2.C: Require effective target tls.

--- gcc/testsuite/g++.dg/other/pr81422.C.jj 2018-04-17 19:00:20.635357348 
+0200
+++ gcc/testsuite/g++.dg/other/pr81422.C2018-04-17 22:38:54.391423522 
+0200
@@ -1,4 +1,5 @@
-/* { dg-do compile } */
+/* { dg-do compile { target c++11 } } */
+/* { dg-require-effective-target tls } */
  /* { dg-options "-O0" } */
  
  struct DArray

@@ -12,4 +13,3 @@ void foo35(DArray)
  static __thread int x[5];
  foo35({5, (int*)});
  }
-
--- gcc/testsuite/g++.dg/other/pr60675.C.jj 2018-04-17 19:00:20.610357336 
+0200
+++ gcc/testsuite/g++.dg/other/pr60675.C2018-04-17 22:38:23.853407970 
+0200
@@ -1,5 +1,7 @@
-/* { dg-do compile { target fpic } } */
-/* { dg-options "-std=c++11 -w -O2 -fPIC" } */
+/* { dg-do compile { target c++11 } } */
+/* { dg-require-effective-target tls } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-w -O2 -fPIC" } */
  namespace CLHEP {
static const double meter = 1000.*10;
static const double meter2 = meter*meter;
--- gcc/testsuite/g++.dg/other/sve_tls_2.C.jj   2018-04-17 19:00:20.610357336 
+0200
+++ gcc/testsuite/g++.dg/other/sve_tls_2.C  2018-04-17 22:39:30.931442140 
+0200
@@ -1,4 +1,5 @@
  /* { dg-do compile { target aarch64*-*-* } } */
+/* { dg-require-effective-target tls } */
  /* { dg-options "-O2 -march=armv8.2-a+sve -fPIC -msve-vector-bits=256" } */
  
  #include 



Jakub

Re: [RFC PATCHES] Obsolete or remove powerpc*-*-*spe* support (PR target/81084)

[Richard Biener]

On Tue, 17 Apr 2018, Jakub Jelinek wrote:

> Hi!
> 
> In the http://gcc.gnu.org/ml/gcc/2017-02/msg00041.html
> thread it has been proposed that powerpc*-*-*spe* would be obsoleted in
> GCC 7, which didn't happen and the rs6000 backend has been split into two,
> one actively maintained where the SPE support has been removed, and the
> other one which unfortunately had just a few small commits, didn't get rid
> of the expected 80% of the new backend which would make it deal with it
> for global changes in GCC, nor has the bugfixes added to rs6000 backend in
> the last 11 months since the split (many of them apply to powerpcspe too).
> 
> So, in order to resolve the P1 PR81084, I think we should at least make the
> powerpc*-*-*spe* obsolete for GCC 8 and remove in GCC 9 if it doesn't get
> significantly better soon (the first patch), or remove it altogether now,
> which would match the deal that either the port is cleaned up, or it is
> removed (the second patch).  In addition to this some changes.html
> changes will be needed depending on what is chosen.
> 
> Preferences on what to do?

I think I prefer the first for GCC8 and remove it early in stage1 if
people don't get their asses moved.

Richard.

Re: [PATCH] [PR c++/80290] recycle tinst garbage sooner

[Alexandre Oliva]

On Apr 18, 2018, Jason Merrill  wrote:

> Ok, thanks.

Thanks, here's the consolidated patch I installed.


tinst_level objects are created during template instantiation, and
they're most often quite short-lived, but since there's no intervening
garbage collection, they accumulate throughout the pass while most by
far could be recycled after a short while.  The original testcase in
PR80290, for example, creates almost 55 million tinst_level objects,
all but 10 thousand of them without intervening GC, but we don't need
more than 284 of them live at a time.

Furthermore, in many cases, TREE_LIST objects are created to stand for
the decl in tinst_level.  In most cases, those can be recycled as soon
as the tinst_level object is recycled; in some relatively common
cases, they are modified and reused in up to 3 tinst_level objects.
In the same testcase, TREE_LISTs are used in all but 3 thousand of the
tinst_level objects, and we don't need more than 89 tinst_level
objects with TREE_LISTs live at a time.  Furthermore, all but 2
thousand of those are created without intervening GC.

This patch arranges for tinst_level objects to be refcounted (I've
seen as many as 20 live references to a single tinst_level object in
my testing), and for pending_template, tinst_level and TREE_LIST
objects that can be recycled to be added to freelists; that's much
faster than ggc_free()ing them and reallocating them shortly
thereafter.  In fact, the introduction of such freelists is what makes
this entire patch lighter-weight, when it comes to memory use, and
faster.  With refcounting alone, the total memory footprint was still
about the same, and we spent more time.

In order to further reduce memory use, I've arranged for us to create
TREE_LISTs lazily, only at points that really need them (when printing
error messages).  This grows tinst_level by an additional pointer, but
since a TREE_LIST holds a lot more than an extra pointer, and
tinst_levels with TREE_LISTs used to be allocated tens of thousands of
times more often than plain decl ones, we still save memory overall.

I was still not quite happy about growing memory use in cases that
used template classes but not template overload resolution, so I
changed the type of the errors field to unsigned short, from int.
With that change, in_system_header_p and refcount move into the same
word or half-word that used to hold errors, releasing a full word,
bringing tinst_level back to its original size, now without any
padding.

The errors field is only used to test whether we've had any errors
since the expansion of some template, to skip the expansion of further
templates.  If we get 2^16 errors or more, it is probably reasonable
to refrain from expanding further templates, even if we would expand
them before this change.

With these changes, compile time for the original testcase at -O0,
with default checking enabled, is cut down by some 3.7%, total GCable
memory allocation is cut down by almost 20%, and total memory use (as
reported by GNU time as maxresident) is cut down by slightly over 15%.


for  gcc/cp/ChangeLog

PR c++/80290
* cp-tree.h (struct tinst_level): Split decl into tldcl and
targs.  Add private split_list_p, tree_list_p, and not_list_p
inline const predicates; to_list private member function
declaration; free public member function declaration; list_p,
get_node and maybe_get_node accessors, and refcount data
member.  Narrow errors to unsigned short.
* error.c (print_instantiation_full_context): Use new
accessors.
(print_instantiation_partial_context_line): Likewise.  Drop
const from tinst_level-typed parameter.
* mangle.c (mangle_decl_string): Likewise.
* pt.c (freelist): New template class.
(tree_list_freelist_head): New var.
(tree_list_freelist): New fn, along with specializations.
(tinst_level_freelist_head): New var.
(pending_template_freelist_head): Likewise.
(tinst_level_freelist, pending_template_freelist): New fns.
(tinst_level::to_list, tinst_level::free): Define.
(inc_refcount_use, dec_refcount_use): New fns for tinst_level.
(set_refcount_ptr): New template fn.
(add_pending_template): Adjust for refcounting, freelists and
new accessors.
(neglectable_inst_p): Take a NULL d as a non-DECL.
(limit_bad_template_recursion): Use new accessors.
(push_tinst_level): New overload to create the list.
(push_tinst_level_loc): Make it static, split decl into two
args, adjust tests and initialization to cope with split
lists, use freelist, adjust for refcounting.
(push_tinst_level_loc): New wrapper with the old interface.
(pop_tinst_level): Adjust for refcounting.
(record_last_problematic_instantiation): Likewise.
(reopen_tinst_level): Likewise.  Use new accessors.