[PATCH] PR fortran/69101 -- IEEE_SELECTED_REAL_KIND part I

[Steve Kargl]

2019-01-04  Steven G. Kargl  

PR fortran/69101
* expr.c (gfc_check_init_expr): If errors were emitted during
simplification of ieee_selected_real_kind(), clear any additional
errors anre return false.
* simplify.c (simplify_ieee_selected_real_kind): make
ieee_selected_real_kind() generic in an initialization expression, and
check for conformance of actual arguments.

 2019-01-04  Steven G. Kargl  

PR fortran/69101
* gfortran.dg/ieee/ieee_7.f90: Remove invalid code.
* gfortran.dg/ieee/pr69101_1.f90: Check for errors in actual
arguments of ieee_selected_real_kind().
* gfortran.dg/ieee/pr69101_2.f90: Test -std=f2003.  RADIX was added
in F2008.

TL;DR version

The attached patch fixes ieee_selected_real_kind (ISRK) when
used in an initialization expression, where either keywords are
mixed up compared to their position or the actual arguments are
not default integer kind.  It does not fix the use of ISRK in
an ordinary expression.

Test on i586-*-freebsd and x86_64-*-freebsd.  OK to commit?


Long version

ISRK is a function with a generic interface.  It is available from
the ieee_arithmetic intrinsic module.  The problem is that the
Fortran standard has specified a generic interface that is not
expressable in Fortran; and hence, gfortran cannot express it in the
file ieee_arithmetic.F90.  If one thinks about the situation, ISRK
is then neither a module procedure nor an intrinsic subprogram.

This patch expands upon the original simplification process when
an ISRK is seen.  It inspects the actual arguments for keywords
and provides a proper ordering.  It checks that each argument, if
present, is a scalar integer entity, and whether -std=F2008 or
later is in effect.  Because gfortran is performing simplification
in an initialization expression, queuing error messages with gfc_error()
is disabled.  Thus, errors are emitted with gfc_error_now().  If one
or more error is emitted, the portion of the patch in expr.c short
circuits simplification to prevent run-on errors.

It is now possible to do 

   program foo
  use ieee_arithmetic, only : isrk => ieee_selected_real_kind
  integer, parameter :: rknd = isrk(radix=2_1, p=6_8, r=200_2)
  print *, rknd
   end program foo

Note, ISRK must be available from the module to allow the renaming
that occurs above, but ideally gfortran should use its machinery
for intrinsic function.

The patch only fixes the use in initialization expression.  If ISRK
appears in a non-initialization expression, gfortran keels over.
Fixes that is Part II of addressing shortcoming with ISRK.

Finally, things are going to even more interesting when F2018's
ieee_real() and ieee_int() are added to gfortran.

-- 
Steve
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(revision 267591)
+++ gcc/fortran/expr.c	(working copy)
@@ -2768,11 +2768,20 @@ gfc_check_init_expr (gfc_expr *e)
 	  mod = sym->generic->sym->from_intmod;
 	if (mod == INTMOD_IEEE_ARITHMETIC || mod == INTMOD_IEEE_EXCEPTIONS)
 	  {
+	int ecnt;
+
 	gfc_expr *new_expr = gfc_simplify_ieee_functions (e);
 	if (new_expr)
 	  {
 		gfc_replace_expr (e, new_expr);
 		t = true;
+		break;
+	  }
+	gfc_get_errors (NULL, &ecnt);
+	if (ecnt > 0)
+ 	  {
+		t = false;
+		gfc_clear_error ();
 		break;
 	  }
 	  }
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 267591)
+++ gcc/fortran/simplify.c	(working copy)
@@ -8521,25 +8521,129 @@ gfc_simplify_compiler_version (void)
 
 /* Simplification routines for intrinsics of IEEE modules.  */
 
+/* IEEE_SELECTED_REAL_KIND is generic, but cannot be specified in the
+   intrinsic module ieee_arithmetic.mod due to ambiguous interfaces.  When
+   it appears in an initialization expression, the checking must be done
+   here.  */
+
 gfc_expr *
 simplify_ieee_selected_real_kind (gfc_expr *expr)
 {
-  gfc_actual_arglist *arg;
-  gfc_expr *p = NULL, *q = NULL, *rdx = NULL;
+  gfc_actual_arglist *arg0, *arg1, *arg2;
+  gfc_expr *p, *r, *rdx;
 
-  arg = expr->value.function.actual;
-  p = arg->expr;
-  if (arg->next)
+  arg1 = arg2 = NULL;
+  p = r = rdx = NULL;
+
+  arg0 = expr->value.function.actual;
+  if (arg0->next)
+{ 
+  arg1 = arg0->next;
+  if (arg1->next) arg2 = arg1->next;
+}
+
+  if (!arg0->expr && arg1 && !arg1->expr && arg2 && !arg2->expr)
+   {
+  gfc_error_now ("At least one of P, R, or RADIX must be present in "
+		 "IEEE_SELECTED_REAL_KIND at %C");
+  gfc_clear_error ();
+  return NULL;
+   }
+
+  /* Look at first argument.  */
+  if (!arg0->name || strcmp(arg0->name, "p") == 0)
+p = arg0->expr;
+  else if (strcmp(arg0->name, "r") == 0)
+r = arg0->expr;
+  else if (strcmp(arg0->name, "radix") == 0)
+rdx = arg0->expr;
+  else
+goto invalid;
+
+  /* Look 

Re: [PATCH] Fix ICU miscompilation due to tree-ssa-strlen.c bug (PR tree-optimization/88693)

[Jeff Law]

On 1/4/19 3:54 PM, Jakub Jelinek wrote:
> Hi!
> 
> The following patch fixes ICU miscompilation, where an initial part of a
> buffer is initializer from non-zero terminated string literal (in ICU
> actually from an array of non-zero chars that the FE newly turns into
> non-zero terminated string literal), but the code recently added to
> tree-ssa-strlen.c doesn't consider the possibility of string literals that
> aren't zero terminated.
> 
> STRING_CSTs actually are always zero terminated, but if TREE_STRING_LENGTH
> doesn't include the terminating character, it is just bytes.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
> 
> I was considering using strnlen, but if all STRING_CSTs are actually zero
> terminated, it will mean it reads are most one further byte and on many
> targets strlen is more optimized than strnlen.
> 
> 2019-01-04  Jakub Jelinek  
> 
>   PR tree-optimization/88693
>   * tree-ssa-strlen.c (get_min_string_length): Don't set *full_string_p
>   for STRING_CSTs that don't contain any NUL characters in the first
>   TREE_STRING_LENGTH bytes.
> 
>   * gcc.c-torture/execute/pr88693.c: New test.
Don't have time to review tonight.  But FYI, my tester flagged ICU due
to a testsuite failure.

Jeff

Re: [REVISED PATCH 1/9]: C++ P0482R5 char8_t: Documentation updates

[Martin Sebor]

On 12/23/18 7:27 PM, Tom Honermann wrote:
Attached is a revised patch that addresses feedback provided by Jason 
and Sandra.  Changes from the prior patch include:

- Updates to the -fchar8_t option documentation as requested by Jason.
- Corrections for indentation, spacing, hyphenation, and wrapping as
   requested by Sandra.



Just a minor nit that backticks in code examples should be avoided
(per the TexInfo manual, they can cause trouble when copying code
from PDF readers):

+@smallexample
+char ca[] = u8"xx"; // error: char-array initialized from wide
+//string
+const char *cp = u8"xx";// error: invalid conversion from
+//`const char8_t*' to `const char*'

Martin

libgo patch committed: Avoid deadlock if SIGPROF arrives during traceback

[Ian Lance Taylor]

This libgo patch by Cherry Zhang prevent deadlock when a profiling
signal arrives during traceback.  Traceback routines, e.g. callers and
funcentry, may call __go_get_backtrace_state.  If a profiling signal
arrives while we are in the critical section of
__go_get_backtrace_state, it tries to do a traceback, which also calls
__go_get_backtrace_state, which tries to enter the same critical
section and will deadlock.  Prevent this deadlock by setting up
runtime_in_callers before calling __go_get_backtrace_state.  This was
found while investigating https://golang.org/29448.  Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 267580)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-0e482bef69d73b9381dbc543e200a1fe57275e81
+2ce291eaee427799bfcde256929dab89e0ab61eb
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/runtime/go-caller.c
===
--- libgo/runtime/go-caller.c   (revision 267580)
+++ libgo/runtime/go-caller.c   (working copy)
@@ -137,7 +137,9 @@ __go_file_line (uintptr pc, int index, S
 
   runtime_memclr (&c, sizeof c);
   c.index = index;
+  runtime_xadd (&__go_runtime_in_callers, 1);
   state = __go_get_backtrace_state ();
+  runtime_xadd (&__go_runtime_in_callers, -1);
   backtrace_pcinfo (state, pc, callback, error_callback, &c);
   *fn = c.fn;
   *file = c.file;
@@ -169,8 +171,13 @@ syminfo_callback (void *data, uintptr_t
 static _Bool
 __go_symbol_value (uintptr pc, uintptr *val)
 {
+  struct backtrace_state *state;
+
   *val = 0;
-  backtrace_syminfo (__go_get_backtrace_state (), pc, syminfo_callback,
+  runtime_xadd (&__go_runtime_in_callers, 1);
+  state = __go_get_backtrace_state ();
+  runtime_xadd (&__go_runtime_in_callers, -1);
+  backtrace_syminfo (state, pc, syminfo_callback,
 error_callback, val);
   return *val != 0;
 }
Index: libgo/runtime/go-callers.c
===
--- libgo/runtime/go-callers.c  (revision 267580)
+++ libgo/runtime/go-callers.c  (working copy)
@@ -202,8 +202,8 @@ runtime_callers (int32 skip, Location *l
   data.index = 0;
   data.max = m;
   data.keep_thunks = keep_thunks;
-  state = __go_get_backtrace_state ();
   runtime_xadd (&__go_runtime_in_callers, 1);
+  state = __go_get_backtrace_state ();
   backtrace_full (state, 0, callback, error_callback, &data);
   runtime_xadd (&__go_runtime_in_callers, -1);
 

Re: PATCH: Updated error messages for ill-formed cases of array initialization by string literal

[Martin Sebor]

On 12/27/18 1:49 PM, Tom Honermann wrote:
As requested by Jason in the review of the P0482 (char8_t) core language 
changes, this patch includes updates to the error messages emitted for 
ill-formed cases of array initialization with a string literal.  With 
these changes, error messages that previously looked something like these:


- "char-array initialized from wide string"
- "wide character array initialized from non-wide string"
- "wide character array initialized from incompatible wide string"

now look like:

- "cannot initialize array of type 'char' from a string literal with 
type array of 'short unsigned int'"


The first word "type" doesn't quite work here.  The type of every
array is "array of T" where T is the type of the element, so for
instance, "array of char."  Saying "array of type X" makes it sound
like X is the type of the whole array, which is of course not
the case when X is char.  I think you want to use the same wording
as for the second type:

  "cannot initialize array of 'char' from a string literal with
  type array of 'short unsigned int'"

or perhaps even better

  "cannot initialize array of 'char' from a string literal with
  type 'char16_t[N]'"

(i.e., show the actual type of the string, including its bound).

Martin

Re: [Patch 4/4][Aarch64] v2: Implement Aarch64 SIMD ABI

[Steve Ellcey]

On Thu, 2018-12-06 at 12:25 +, Richard Sandiford wrote:
> 
> Since we're looking at the call insns anyway, we could have a hook that
> "jousts" two calls and picks the one that preserves *fewer* registers.
> This would mean that loop produces a single instruction that conservatively
> describes the call-preserved registers.  We could then stash that
> instruction in lra_reg instead of the current check_part_clobbered
> boolean.
> 
> The hook should by default be a null pointer, so that we can avoid
> the instruction walk on targets that don't need it.
> 
> That would mean that LRA would always have a call instruction to hand
> when asking about call-preserved information.  So I think we should
> add an insn parameter to targetm.hard_regno_call_part_clobbered,
> with a null insn selecting the defaul behaviour.   I know it's
> going to be a pain to update all callers and targets, sorry.

Richard,  here is an updated version of this patch.  It is not
completly tested yet but I wanted to send this out and make
sure it is what you had in mind and see if you had any comments about
the new target function while I am testing it (including building
some of the other targets).

Steve Ellcey
sell...@cavium.com


2019-01-04  Steve Ellcey  

* config/aarch64/aarch64.c (aarch64_simd_call_p): New function.
(aarch64_hard_regno_call_part_clobbered): Add insn argument.
(aarch64_return_call_with_max_clobbers): New function.
(TARGET_RETURN_CALL_WITH_MAX_CLOBBERS): New macro.
* config/avr/avr.c (avr_hard_regno_call_part_clobbered): Add insn
argument.
* config/i386/i386.c (ix86_hard_regno_call_part_clobbered): Ditto.
* config/mips/mips.c (mips_hard_regno_call_part_clobbered): Ditto.
* config/rs6000/rs6000.c (rs6000_hard_regno_call_part_clobbered): Ditto.
* config/s390/s390.c (s390_hard_regno_call_part_clobbered): Ditto.
* cselib.c (cselib_process_insn): Add argument to
targetm.hard_regno_call_part_clobbered call.
* conflicts.c (ira_build_conflicts): Ditto.
* ira-costs.c (ira_tune_allocno_costs): Ditto.
* lra-constraints.c (inherit_reload_reg): Ditto, plus refactor
return statement.
* lra-int.h (struct lra_reg): Add call_insn field.
* lra-lives.c (check_pseudos_live_through_calls): Add call_insn
argument.  Add argument to targetm.hard_regno_call_part_clobbered
call.
(process_bb_lives): Use new target function
targetm.return_call_with_max_clobbers to set call_insn.
Pass call_insn to check_pseudos_live_through_calls.
Set call_insn in lra_reg_info.
* lra.c (initialize_lra_reg_info_element): Set call_insn to NULL.
* regcprop.c (copyprop_hardreg_forward_1): Add argument to
targetm.hard_regno_call_part_clobbered call.
* reginfo.c (choose_hard_reg_mode): Ditto.
* regrename.c (check_new_reg_p): Ditto.
* reload.c (find_equiv_reg): Ditto.
* reload1.c (emit_reload_insns): Ditto.
* sched-deps.c (deps_analyze_insn): Ditto.
* sel-sched.c (init_regs_for_mode): Ditto.
(mark_unavailable_hard_regs): Ditto.
* targhooks.c (default_dwarf_frame_reg_mode): Ditto.
* target.def (hard_regno_call_part_clobbered): Add insn argument.
(return_call_with_max_clobbers): New target function.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_RETURN_CALL_WITH_MAX_CLOBBERS): New hook.
* hooks.c (hook_bool_uint_mode_false): Change to
hook_bool_insn_uint_mode_false.
* hooks.h (hook_bool_uint_mode_false): Ditto.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c5036c8..87af31b 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1565,16 +1565,55 @@ aarch64_reg_save_mode (tree fndecl, unsigned regno)
 	   : (aarch64_simd_decl_p (fndecl) ? E_TFmode : E_DFmode);
 }
 
+/* Return true if the instruction is a call to a SIMD function, false
+   if it is not a SIMD function or if we do not know anything about
+   the function.  */
+
+static bool
+aarch64_simd_call_p (rtx_insn *insn)
+{
+  rtx symbol;
+  rtx call;
+  tree fndecl;
+
+  gcc_assert (CALL_P (insn));
+  call = get_call_rtx_from (insn);
+  symbol = XEXP (XEXP (call, 0), 0);
+  if (GET_CODE (symbol) != SYMBOL_REF)
+return false;
+  fndecl = SYMBOL_REF_DECL (symbol);
+  if (!fndecl)
+return false;
+
+  return aarch64_simd_decl_p (fndecl);
+}
+
 /* Implement TARGET_HARD_REGNO_CALL_PART_CLOBBERED.  The callee only saves
the lower 64 bits of a 128-bit register.  Tell the compiler the callee
clobbers the top 64 bits when restoring the bottom 64 bits.  */
 
 static bool
-aarch64_hard_regno_call_part_clobbered (unsigned int regno, machine_mode mode)
+aarch64_hard_regno_call_part_clobbered (rtx_insn *insn,
+	unsigned int regno,
+	machine_mode mode)
 {
+  if (insn && CALL_P (insn) && aarch64_simd_call_p (insn)

[PATCH] Export explicit instantiations for C++17 members of std::string

[Jonathan Wakely]

The C++17 standard added some new members to std::basic_string, which
were not previously instantiated in the library. This meant that the
extern template declarations had to be disabled for C++17 mode. With
this patch the new members are instantiated in the library and so the
explicit instantiation declarations can be used for C++17.

The new members added by C++2a are still not exported, and so the
explicit instantiation declarations are still disabled for C++2a.

* config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Make patterns less greedy
for const member functions of std::basic_string.
(GLIBCXX_3.4.26): Export member functions of std::basic_string added
in C++17.
* include/bits/basic_string.h (basic_string(__sv_wrapper, const A&)):
Make non-standard constructor private.
[!_GLIBCXX_USE_CXX11_ABI] (basic_string(__sv_wrapper, const A&)):
Likewise.
* include/bits/basic_string.tcc (std::string, std::wstring): Declare
explicit instantiations for C++17 as well as earlier dialects.
* src/c++17/Makefile.am: Add new source files.
* src/c++17/Makefile.in: Regenerate.
* src/c++17/cow-string-inst.cc: New file defining explicit
instantiations for basic_string member functions added in C++17.
* src/c++17/string-inst.cc: Likewise.

Tested powerpc64le-linux, committed to trunk.

More new C++17 symbols still to follow shortly.

commit 4b6d5774d685f61a73519dca8901fc8f032ba6da
Author: Jonathan Wakely 
Date:   Thu Jan 3 23:05:14 2019 +

Export explicit instantiations for C++17 members of std::string

The C++17 standard added some new members to std::basic_string, which
were not previously instantiated in the library. This meant that the
extern template declarations had to be disabled for C++17 mode. With
this patch the new members are instantiated in the library and so the
explicit instantiation declarations can be used for C++17.

The new members added by C++2a are still not exported, and so the
explicit instantiation declarations are still disabled for C++2a.

* config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Make patterns less greedy
for const member functions of std::basic_string.
(GLIBCXX_3.4.26): Export member functions of std::basic_string added
in C++17.
* include/bits/basic_string.h (basic_string(__sv_wrapper, const 
A&)):
Make non-standard constructor private.
[!_GLIBCXX_USE_CXX11_ABI] (basic_string(__sv_wrapper, const A&)):
Likewise.
* include/bits/basic_string.tcc (std::string, std::wstring): Declare
explicit instantiations for C++17 as well as earlier dialects.
* src/c++17/Makefile.am: Add new source files.
* src/c++17/Makefile.in: Regenerate.
* src/c++17/cow-string-inst.cc: New file defining explicit
instantiations for basic_string member functions added in C++17.
* src/c++17/string-inst.cc: Likewise.

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 1d157288fcf..6c18caa6d8a 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1742,7 +1742,8 @@ GLIBCXX_3.4.21 {
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]I[PN]*;
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE[Daip]*;
-_ZNKSt7__cxx1112basic_string*;
+_ZNKSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE[1-9]*;
+_ZNKSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EEixE[jmy];
 
 # operator+ for ABI-tagged std::basic_string
 
_ZStplI[cw]St11char_traitsI[cw]ESaI[cw]EENSt7__cxx1112basic_stringIT_T0_T1_EE*;
@@ -2077,6 +2078,27 @@ GLIBCXX_3.4.26 {
 _ZNSbIwSt11char_traitsIwESaIwEEC[12]ERKS2_RKS1_;
 _ZNSbIwSt11char_traitsIwESaIwEEC[12]EOS2_RKS1_;
 
+# basic_string::operator basic_string_view() const
+_ZNKSscvSt17basic_string_viewIcSt11char_traitsIcEEEv;
+_ZNKSbIwSt11char_traitsIwESaIwEEcvSt17basic_string_viewIwS0_EEv;
+
_ZNKSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EEcvSt17basic_string_viewI[cw]S2_EEv;
+# basic_string::data()
+_ZNSs4dataEv;
+_ZNSbIwSt11char_traitsIwESaIwEE4dataEv;
+_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE4dataEv;
+# basic_string::_S_to_string_view(basic_string_view)
+_ZNSs17_S_to_string_viewESt17basic_string_viewIcSt11char_traitsIcEE;
+
_ZNSbIwSt11char_traitsIwESaIwEE17_S_to_string_viewESt17basic_string_viewIwS0_E;
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE17_S_to_string_viewESt17basic_string_viewI[cw]S2_E;
+# basic_string::__sv_wrapper::__sv_wrapper(basic_string_view)
+_ZNSs12__sv_wrapperC[12]ESt17basic_string_viewIcSt11char_traitsIcEE;
+
_ZNSbIwSt11char

[PATCH] Add allocator-extended copy/move ctors to COW string

[Jonathan Wakely]

Add these constructors from C++11 which were missing from the COW
basic_string. Additionally simplify the definitions of the
basic_string::reference and basic_string::const_reference types as
required by C++11.

This allows filesystem::path::string() to be simplified, so
that the same code is used for both basic_string implementations.

* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Export allocator-extended
copy/move constructors for old std::basic_string.
* include/bits/basic_string.h [!_GLIBCXX_USE_CXX11_ABI]
(basic_string::reference, basic_string::const_reference): Define
as plain references for C++11 and later.
(basic_string::basic_string()): Put constructor body outside
preprocessor conditional groups.
(basic_string::basic_string(basic_string&&)): Move _Alloc_hider
instead of copying it.
(basic_string::basic_string(const basic_string&, const _Alloc&)):
Define.
(basic_string::basic_string(basic_string&&, const _Alloc&)):
Define.
* include/bits/fs_path.h [!_GLIBCXX_USE_CXX11_ABI]: Remove special
cases for old basic_string.
* testsuite/21_strings/basic_string/cons/char/8.cc: Test
allocator-extended constructors unconditionally. Add extra members to
allocator type when using old string ABI.
* testsuite/21_strings/basic_string/allocator/71964.cc: Enable test
for old string ABI.
* testsuite/21_strings/basic_string/cons/wchar_t/8.cc: Likewise.

Tested powerpc64-linux, committed to trunk.

There are still more new symbols that I plan to add to the library, so
don't regenerate baseline_symbols.txt files yet.


commit d8b09a24301736d69db0d041b4fb313b185c635d
Author: Jonathan Wakely 
Date:   Thu Oct 25 22:39:53 2018 +0100

Add allocator-extended copy/move ctors to COW string

Add these constructors from C++11 which were missing from the COW
basic_string. Additionally simplify the definitions of the
basic_string::reference and basic_string::const_reference types as
required by C++11.

This allows filesystem::path::string() to be simplified, so
that the same code is used for both basic_string implementations.

* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Export allocator-extended
copy/move constructors for old std::basic_string.
* include/bits/basic_string.h [!_GLIBCXX_USE_CXX11_ABI]
(basic_string::reference, basic_string::const_reference): Define
as plain references for C++11 and later.
(basic_string::basic_string()): Put constructor body outside
preprocessor conditional groups.
(basic_string::basic_string(basic_string&&)): Move _Alloc_hider
instead of copying it.
(basic_string::basic_string(const basic_string&, const _Alloc&)):
Define.
(basic_string::basic_string(basic_string&&, const _Alloc&)):
Define.
* include/bits/fs_path.h [!_GLIBCXX_USE_CXX11_ABI]: Remove special
cases for old basic_string.
* testsuite/21_strings/basic_string/cons/char/8.cc: Test
allocator-extended constructors unconditionally. Add extra members 
to
allocator type when using old string ABI.
* testsuite/21_strings/basic_string/allocator/71964.cc: Enable test
for old string ABI.
* testsuite/21_strings/basic_string/cons/wchar_t/8.cc: Likewise.

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index de3c87abf15..1d157288fcf 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2072,6 +2072,11 @@ GLIBCXX_3.4.26 {
 _ZNSt14collate_bynameI[cw]EC[12]ERKSs[jmy];
 
_ZNKSt8time_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEE3getES3_S3_RSt8ios_baseRSt12_Ios_IostateP2tmcc;
 
+_ZNSsC[12]ERKSsRKSaIcE;
+_ZNSsC[12]EOSsRKSaIcE;
+_ZNSbIwSt11char_traitsIwESaIwEEC[12]ERKS2_RKS1_;
+_ZNSbIwSt11char_traitsIwESaIwEEC[12]EOS2_RKS1_;
+
 } GLIBCXX_3.4.25;
 
 # Symbols in the support library (libsupc++) have their own tag.
diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index e96d93fca34..43460df5d1f 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -3145,8 +3145,13 @@ _GLIBCXX_END_NAMESPACE_CXX11
   typedef _Alloc   allocator_type;
   typedef typename _CharT_alloc_type::size_typesize_type;
   typedef typename _CharT_alloc_type::difference_type   difference_type;
+#if __cplusplus < 201103L
   typedef typename _CharT_alloc_type::referencereference;
   typedef typename _CharT_alloc_type::const_reference   const_reference;
+#else
+  typedef value_type&  reference;
+  typedef const value_type&   

[C++ PATCH] Avoid ICE trying to add a bogus fixit hint (PR c++/88554)

[Jakub Jelinek]

Hi!

As found by Jonathan, we shouldn't be trying to emit return *this; fixit
hint in non-methods where this is not available (and ICEing because
current_class_ref is NULL there).
I've just added a testcase for Jon's patch from the PR and merged two nested
ifs into one.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2019-01-04  Jonathan Wakely  
Jakub Jelinek  

PR c++/88554
* decl.c (finish_function): For -Wreturn-type don't add a return *this;
fixit hint if current_class_ref is NULL.  Use a single if instead of
two nested ones.

* g++.dg/warn/Wreturn-type-11.C: New test.

--- gcc/cp/decl.c.jj2019-01-03 11:11:11.568612960 +0100
+++ gcc/cp/decl.c   2019-01-04 20:33:39.258819779 +0100
@@ -16094,11 +16094,12 @@ finish_function (bool inline_p)
{
  tree valtype = TREE_TYPE (DECL_RESULT (fndecl));
  if (TREE_CODE (valtype) == REFERENCE_TYPE
+ && current_class_ref
  && same_type_ignoring_top_level_qualifiers_p
- (TREE_TYPE (valtype), TREE_TYPE (current_class_ref)))
-   if (global_dc->option_enabled (OPT_Wreturn_type,
-  global_dc->option_state))
- add_return_star_this_fixit (&richloc, fndecl);
+ (TREE_TYPE (valtype), TREE_TYPE (current_class_ref))
+ && global_dc->option_enabled (OPT_Wreturn_type,
+   global_dc->option_state))
+   add_return_star_this_fixit (&richloc, fndecl);
}
   warning_at (&richloc, OPT_Wreturn_type,
  "no return statement in function returning non-void");
--- gcc/testsuite/g++.dg/warn/Wreturn-type-11.C.jj  2019-01-04 
20:34:18.062185207 +0100
+++ gcc/testsuite/g++.dg/warn/Wreturn-type-11.C 2019-01-04 20:35:36.048909843 
+0100
@@ -0,0 +1,11 @@
+// PR c++/88554
+// { dg-do compile }
+// { dg-options "-Wreturn-type" }
+
+struct X {
+  friend X & operator+= (X &, int) { } // { dg-warning "no return statement in 
function returning non-void" }
+   // { dg-bogus "return \\*this;" "" { 
target *-*-* } .-1 }
+};
+struct Y {};
+Y & operator += (Y &, Y &) { } // { dg-warning "no return statement in 
function returning non-void" }
+   // { dg-bogus "return \\*this;" "" { 
target *-*-* } .-1 }

Jakub

[PATCH] Fix ICU miscompilation due to tree-ssa-strlen.c bug (PR tree-optimization/88693)

[Jakub Jelinek]

Hi!

The following patch fixes ICU miscompilation, where an initial part of a
buffer is initializer from non-zero terminated string literal (in ICU
actually from an array of non-zero chars that the FE newly turns into
non-zero terminated string literal), but the code recently added to
tree-ssa-strlen.c doesn't consider the possibility of string literals that
aren't zero terminated.

STRING_CSTs actually are always zero terminated, but if TREE_STRING_LENGTH
doesn't include the terminating character, it is just bytes.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

I was considering using strnlen, but if all STRING_CSTs are actually zero
terminated, it will mean it reads are most one further byte and on many
targets strlen is more optimized than strnlen.

2019-01-04  Jakub Jelinek  

PR tree-optimization/88693
* tree-ssa-strlen.c (get_min_string_length): Don't set *full_string_p
for STRING_CSTs that don't contain any NUL characters in the first
TREE_STRING_LENGTH bytes.

* gcc.c-torture/execute/pr88693.c: New test.

--- gcc/tree-ssa-strlen.c.jj2019-01-03 09:47:28.018069413 +0100
+++ gcc/tree-ssa-strlen.c   2019-01-04 16:28:47.549196405 +0100
@@ -3232,8 +3232,9 @@ get_min_string_length (tree rhs, bool *f
 
   if (rhs && TREE_CODE (rhs) == STRING_CST)
 {
-  *full_string_p = true;
-  return strlen (TREE_STRING_POINTER (rhs));
+  HOST_WIDE_INT len = strlen (TREE_STRING_POINTER (rhs));
+  *full_string_p = len < TREE_STRING_LENGTH (rhs);
+  return len;
 }
 
   return -1;
--- gcc/testsuite/gcc.c-torture/execute/pr88693.c.jj2019-01-04 
16:31:50.892218304 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr88693.c   2019-01-04 
16:31:09.808885630 +0100
@@ -0,0 +1,54 @@
+/* PR tree-optimization/88693 */
+
+__attribute__((noipa)) void
+foo (char *p)
+{
+  if (__builtin_strlen (p) != 9)
+__builtin_abort ();
+}
+
+__attribute__((noipa)) void
+quux (char *p)
+{
+  int i;
+  for (i = 0; i < 100; i++)
+if (p[i] != 'x')
+  __builtin_abort ();
+}
+
+__attribute__((noipa)) void
+qux (void)
+{
+  char b[100];
+  __builtin_memset (b, 'x', sizeof (b));
+  quux (b);
+}
+
+__attribute__((noipa)) void
+bar (void)
+{
+  static unsigned char u[9] = "abcdefghi";
+  char b[100];
+  __builtin_memcpy (b, u, sizeof (u));
+  b[sizeof (u)] = 0;
+  foo (b);
+}
+
+__attribute__((noipa)) void
+baz (void)
+{
+  static unsigned char u[] = { 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r' };
+  char b[100];
+  __builtin_memcpy (b, u, sizeof (u));
+  b[sizeof (u)] = 0;
+  foo (b);
+}
+
+int
+main ()
+{
+  qux ();
+  bar ();
+  baz ();
+  return 0;
+}

Jakub

[PATCH] Add a two value VR comparison to two consecutive PHI args optimization (PR tree-optimization/88676)

[Jakub Jelinek]

Hi!

The following patch adds an optimization, if we know certain SSA_NAME
has two possible values and have GIMPLE_COND EQ_EXPR/NE_EXPR of that
SSA_NAME with one of the two values and PHI which has two adjacent
constants, we can optimize it into addition or subtraction.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

The pr15826.c change is just a small change on what is present in GIMPLE
with this patch, previously (from the bugzilla apparently only on some
targets) we had a (_Bool) cast and now we have & 1, which effectively
results in exactly the same expansion.

2019-01-04  Jakub Jelinek  

PR tree-optimization/88676
* tree-ssa-phiopt.c (two_value_replacement): New function.
(tree_ssa_phiopt_worker): Call it.

* gcc.dg/tree-ssa/pr88676.c: New test.
* gcc.dg/pr88676.c: New test.
* gcc.dg/tree-ssa/pr15826.c: Just verify there is no goto,
allow &.

--- gcc/tree-ssa-phiopt.c.jj2019-01-01 12:37:17.716965779 +0100
+++ gcc/tree-ssa-phiopt.c   2019-01-04 13:55:26.293746657 +0100
@@ -48,6 +48,8 @@ along with GCC; see the file COPYING3.
 #include "case-cfn-macros.h"
 
 static unsigned int tree_ssa_phiopt_worker (bool, bool, bool);
+static bool two_value_replacement (basic_block, basic_block, edge, gphi *,
+  tree, tree);
 static bool conditional_replacement (basic_block, basic_block,
 edge, edge, gphi *, tree, tree);
 static gphi *factor_out_conditional_conversion (edge, edge, gphi *, tree, tree,
@@ -332,8 +334,11 @@ tree_ssa_phiopt_worker (bool do_store_el
}
 
  /* Do the replacement of conditional if it can be done.  */
- if (!early_p
- && conditional_replacement (bb, bb1, e1, e2, phi, arg0, arg1))
+ if (two_value_replacement (bb, bb1, e2, phi, arg0, arg1))
+   cfgchanged = true;
+ else if (!early_p
+  && conditional_replacement (bb, bb1, e1, e2, phi,
+  arg0, arg1))
cfgchanged = true;
  else if (abs_replacement (bb, bb1, e1, e2, phi, arg0, arg1))
cfgchanged = true;
@@ -572,6 +577,118 @@ factor_out_conditional_conversion (edge
   return newphi;
 }
 
+/* Optimize
+   # x_5 in range [cst1, cst2] where cst2 = cst1 + 1
+   if (x_5 op cstN) # where op is == or != and N is 1 or 2
+ goto bb3;
+   else
+ goto bb4;
+   bb3:
+   bb4:
+   # r_6 = PHI # where cst3 == cst4 + 1 or cst4 == cst3 + 1
+
+   to r_6 = x_5 + (min (cst3, cst4) - cst1) or
+   r_6 = (min (cst3, cst4) + cst1) - x_5 depending on op, N and which
+   of cst3 and cst4 is smaller.  */
+
+static bool
+two_value_replacement (basic_block cond_bb, basic_block middle_bb,
+  edge e1, gphi *phi, tree arg0, tree arg1)
+{
+  /* Only look for adjacent integer constants.  */
+  if (!INTEGRAL_TYPE_P (TREE_TYPE (arg0))
+  || !INTEGRAL_TYPE_P (TREE_TYPE (arg1))
+  || TREE_CODE (arg0) != INTEGER_CST
+  || TREE_CODE (arg1) != INTEGER_CST
+  || (tree_int_cst_lt (arg0, arg1)
+ ? wi::to_widest (arg0) + 1 != wi::to_widest (arg1)
+ : wi::to_widest (arg1) + 1 != wi::to_widest (arg1)))
+return false;
+
+  if (!empty_block_p (middle_bb))
+return false;
+
+  gimple *stmt = last_stmt (cond_bb);
+  tree lhs = gimple_cond_lhs (stmt);
+  tree rhs = gimple_cond_rhs (stmt);
+
+  if (TREE_CODE (lhs) != SSA_NAME
+  || !INTEGRAL_TYPE_P (TREE_TYPE (lhs))
+  || TREE_CODE (TREE_TYPE (lhs)) == BOOLEAN_TYPE
+  || TREE_CODE (rhs) != INTEGER_CST)
+return false;
+
+  switch (gimple_cond_code (stmt))
+{
+case EQ_EXPR:
+case NE_EXPR:
+  break;
+default:
+  return false;
+}
+
+  wide_int min, max;
+  if (get_range_info (lhs, &min, &max) != VR_RANGE
+  || min + 1 != max
+  || (wi::to_wide (rhs) != min
+ && wi::to_wide (rhs) != max))
+return false;
+
+  /* We need to know which is the true edge and which is the false
+ edge so that we know when to invert the condition below.  */
+  edge true_edge, false_edge;
+  extract_true_false_edges_from_block (cond_bb, &true_edge, &false_edge);
+  if ((gimple_cond_code (stmt) == EQ_EXPR)
+  ^ (wi::to_wide (rhs) == max)
+  ^ (e1 == false_edge))
+std::swap (arg0, arg1);
+
+  tree type;
+  if (TYPE_PRECISION (TREE_TYPE (lhs)) == TYPE_PRECISION (TREE_TYPE (arg0)))
+{
+  if (TREE_CODE (TREE_TYPE (arg0)) == BOOLEAN_TYPE
+ || !TYPE_OVERFLOW_WRAPS (TREE_TYPE (arg0)))
+   type = TREE_TYPE (lhs);
+  else
+   type = TREE_TYPE (arg0);
+}
+  else if (TYPE_PRECISION (TREE_TYPE (lhs)) > TYPE_PRECISION (TREE_TYPE 
(arg0)))
+type = TREE_TYPE (lhs);
+  else
+type = TREE_TYPE (arg0);
+  if (!TYPE_OVERFLOW_WRAPS (type))
+type = unsigned_type_for (type);
+
+  tree m = fold_convert (type, wide_int_to_tree (TREE_TYPE (lhs), min));
+  enum tree_code code;
+  if (tree_int_cst_lt (arg0, arg1))
+ 

Re: [PATCH] PR60563 - FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*

[Mike Stump]

On Jan 4, 2019, at 2:56 AM, Dominique d'Humières  wrote:
> 
> Is the following patch OK for trunk and the release branches?

Ok.

> 2019-01-04  Dominique d'Humieres  
> 
>   * g++.dg/ext/sync-4.C: Add dg-xfail-run-if for darwin.
> 
> --- ../_clean/gcc/testsuite/g++.dg/ext/sync-4.C   2015-04-30 
> 23:36:40.0 +0200
> +++ gcc/testsuite/g++.dg/ext/sync-4.C 2019-01-03 20:28:29.0 +0100
> @@ -1,4 +1,6 @@
> /* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin* 
> *-*-darwin[912]* } } */
> +/* FIXME The following additional option should be removed after the fix for 
> radr://19802258.
> +/* { dg-xfail-run-if "PR60563 radr://19802258" { *-*-darwin* } } */
> /* { dg-require-effective-target sync_long_long_runtime } */
> /* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
> /* { dg-additional-options "-march=pentium" { target { { i?86-*-* x86_64-*-* 
> } && ia32 } } } */

Re: [PATCH] restore CFString handling in attribute format (PR 88638)

[Mike Stump]

On Jan 4, 2019, at 2:03 PM, Martin Sebor  wrote:
> 
> The improved handling of attribute positional arguments added
> in r266195 introduced a regression on Darwin where attribute
> format with the CFString archetype accepts CFString* parameter
> types in positions where only char* would otherwise be allowed.

You didn't ask Ok?  I'll assume you want a review...  The darwin bits and the 
testsuite bits look fine.

That just leaves the C bits for someone...

Re: [PATCH, C++,rebased] Fix PR c++/88261

[Bernd Edlinger]

On 1/4/19 10:22 PM, Jason Merrill wrote:
> On 1/4/19 10:30 AM, Bernd Edlinger wrote:
>> On 12/22/18 7:53 PM, Bernd Edlinger wrote:
>>> On 12/21/18 2:03 AM, Martin Sebor wrote:
 On 12/20/18 2:07 PM, Bernd Edlinger wrote:
> On 12/20/18 6:50 PM, Martin Sebor wrote:
>> On 12/20/18 10:46 AM, Martin Sebor wrote:
>>> On 12/17/18 7:58 AM, Jason Merrill wrote:
 On 12/15/18 3:36 AM, Bernd Edlinger wrote:
> this patch implements an error message, for non-static initialization 
> of a flexible array member.
> This duplicates the existing error message from the C-FE, to avoid 
> ICE and wrong code generation
> issues, as pointed out in the PR.
>
> It is a bit funny that a non-functional feature like that has already 
> rather much test coverage.
> The most easy adjustment seems to change the existing test cases to 
> use static declarations.

 Martin, thoughts?
>>>
>>> Our high-level goal when tightening up how flexible array members
>>> are handled in C++ was to accept what's accepted in standard C mode
>>> and reject (or, at a minimum, warn for) C++ extensions that could
>>> be relied on in existing code.
>>
>> I meant "reject what couldn't be relied on" and "warn for that could
>> be."
>>
>
> I believe the problem here is effectively that initializing non-static
> flexible array is not supported by the middle-end.  All examples
> where flexible array members are initialized on automatic variable
> work only as long as they are simple enough that they are optimized
> away so that they do not survive until expansion.
>
> Take as example gcc/testsuite/g++.dg/ext/flexary13.C,
> it compiles and runs successfully, but the assertions start to
> fail if Ax is declared volatile, and at the same time, we know
> that the automatic variables are allocated in a way that they
> can overlap and crash at any time.
>
> My impression is that the existing C error made the middle-end kind of 
> rely
> on this behavior.
>
> So I think the right thing to do is duplicate the existing C error in
> the C++ FE.  I do not see any automatic variable with initialized flexible
> data members where it would be safe to only warn about them.

 If there are no reasonable use cases that code out there could
 be relying on because none of them works correctly then rejecting
 the initialization makes sense to me.

>> (Sorry for the delay, by the way.  I've been migrating to a new machine
>> this week and things aren't yet working quite like I'm used to.)
>>
>>>
>>> The flexarray tests I added back then were for features that looked
>>> like intentional extensions and that seemed to work for at least
>>> some use cases as far as I could tell.  What I noticed didn't work
>>> I created bugs for: 69338, 69696, and 69338 look related, but there
>>> are others.
>>>
>>> I think all these bugs should all be reviewed and a decision made
>>> about what's intended to work and what continues to be accepted as
>>> an accident and should be rejected.  After that, we can adjust
>>> the existing tests.
>>>
>
> I would not rule out the possibility that there can be more bugs.
> But I think the existing tests need to avoid the case which evokes
> the new error.  The question is, if changing from automatic to static
> objects prevents those tests to test what they were originally written 
> for.
> I believe this is not the case, but I do probably not know all the
> background here.

 IIRC, most of the tests I added were meant to exercise just
 the front-end, not any later stages (if that's what you meant).
 Otherwise, if you're worried about the changes from auto to
 static no longer exercising downstream front-end code, whether
 that matters depends on the intent of each test.

 flexary13.C was most likely meant to also verify codegen (hence
 the assertions) so I would suggest to make it do that (i.e.,
 verify the assertions are optimized out if in fact they are,
 or make the test run so they must pass).

>>>
>>> Oh well, unfortunately the modified test case with static objects
>>> fails one assertion when executed at -O0, I missed that before,
>>> because I used -O2 or higher.  I filed that as PR 88578, so in the
>>> moment I would like to leave the test case as compile only,
>>> and change that to run once PR 88578 is resolved.
>>>
 The changes to the rest of the flexary*.C tests seem okay,
 though a new test should be added to explicitly exercise this
 change (bug 88261), even if the error happens to be tested by
 one of the changed tests.

>>>
>>> That is the case, because the array-6.c test case was moved
>>> to c-c++-common.  That is the reproducer for the

[PATCH] restore CFString handling in attribute format (PR 88638)

[Martin Sebor]

The improved handling of attribute positional arguments added
in r266195 introduced a regression on Darwin where attribute
format with the CFString archetype accepts CFString* parameter
types in positions where only char* would otherwise be allowed.
This is specific to Darwin so it didn't show up in tests.
The attached patch restores the feature.

r266195 also replaced an error issued for an invalid attribute
format parameter with just a warning.  On reflection I think
that was a mistake and an error is more appropriate.  The patch
also restores the error.

Finally, I've adjusted the Darwin Format Checks documentation
to better match the effects of the archetype (i.e., no checking
at call sites but no undefined behavior).

Besides testing natively on x86_64-linux I have also manually
run the affected tests with an x86_64-apple-darwin18 cross to
verify the changes (they are UNSUPPORTED under the test suite).

Martin
PR target/88638 - FAIL: fsf-nsstring-format-1.s on darwin

gcc/c-family/ChangeLog:

	PR target/88638
	* c-attribs.c (positional_argument): Call valid_format_string_type_p
	and issue errors if it fails.
	* c-common.h (valid_format_string_type_p): Declare.
	* c-format.c (valid_stringptr_type_p): Rename...
	(valid_format_string_type_p): ...to this and make extern.
	(handle_format_arg_attribute): Adjust to new name.
	(check_format_string): Same.

gcc/testsuite/ChangeLog:

	PR target/88638
	* gcc.dg/format/attr-8.c: New test.
	* gcc.dg/darwin-cfstring-format-1.c: Adjust diagnostics.
	* gcc.dg/format/attr-3.c: Same.
	* obj-c++.dg/fsf-nsstring-format-1.mm: Same.
	* objc.dg/fsf-nsstring-format-1.m: Same.

gcc/ChangeLog:

	PR target/88638
	* doc/extend.texi (Darwin Format Checks): Clarify.

Index: gcc/c-family/c-attribs.c
===
--- gcc/c-family/c-attribs.c	(revision 267580)
+++ gcc/c-family/c-attribs.c	(working copy)
@@ -631,21 +631,32 @@ positional_argument (const_tree fntype, const_tree
 	}
 
   /* Where the expected code is STRING_CST accept any pointer
-	 to a narrow character type, qualified or otherwise.  */
+	 expected by attribute format (this includes possibly qualified
+	 char pointers and, for targets like Darwin, also pointers to
+	 struct CFString).  */
   bool type_match;
-  if (code == STRING_CST && POINTER_TYPE_P (argtype))
-	{
-	  tree type = TREE_TYPE (argtype);
-	  type = TYPE_MAIN_VARIANT (type);
-	  type_match = (type == char_type_node
-			|| type == signed_char_type_node
-			|| type == unsigned_char_type_node);
-	}
+  if (code == STRING_CST)
+	type_match = valid_format_string_type_p (argtype);
   else
 	type_match = TREE_CODE (argtype) == code;
 
   if (!type_match)
 	{
+	  if (code == STRING_CST)
+	{
+	  /* Reject invalid format strings with an error.  */
+	  if (argno < 1)
+		error ("%qE attribute argument value %qE refers to "
+		   "parameter type %qT",
+		   atname, pos, argtype);
+	  else
+		error ("%qE attribute argument %i value %qE refers to "
+		   "parameter type %qT",
+		   atname, argno, pos, argtype);
+
+	  return NULL_TREE;
+	}
+
 	  if (argno < 1)
 	warning (OPT_Wattributes,
 		 "%qE attribute argument value %qE refers to "
Index: gcc/c-family/c-common.h
===
--- gcc/c-family/c-common.h	(revision 267580)
+++ gcc/c-family/c-common.h	(working copy)
@@ -1335,6 +1335,9 @@ extern tree tm_mask_to_attr (int);
 extern tree find_tm_attribute (tree);
 extern const struct attribute_spec::exclusions attr_cold_hot_exclusions[];
 
+/* In c-format.c.  */
+extern bool valid_format_string_type_p (tree);
+
 /* A bitmap of flags to positional_argument.  */
 enum posargflags {
   /* Consider positional attribute argument value zero valid.  */
Index: gcc/c-family/c-format.c
===
--- gcc/c-family/c-format.c	(revision 267580)
+++ gcc/c-family/c-format.c	(working copy)
@@ -122,8 +122,8 @@ format_warning_at_char (location_t fmt_string_loc,
The function returns true if strref points to any string type valid for the 
language dialect and target.  */
 
-static bool
-valid_stringptr_type_p (tree strref)
+bool
+valid_format_string_type_p (tree strref)
 {
   return (strref != NULL
 	  && TREE_CODE (strref) == POINTER_TYPE
@@ -160,7 +160,7 @@ handle_format_arg_attribute (tree *node, tree atna
 	return NULL_TREE;
 }
 
-  if (!valid_stringptr_type_p (TREE_TYPE (type)))
+  if (!valid_format_string_type_p (TREE_TYPE (type)))
 {
   if (!(flags & (int) ATTR_FLAG_BUILT_IN))
 	error ("function does not return string type");
@@ -194,7 +194,7 @@ check_format_string (const_tree fntype, unsigned H
 }
 
   if (!ref
-  || !valid_stringptr_type_p (ref))
+  || !valid_format_string_type_p (ref))
 {
   if (!(flags & (int) ATTR_FLAG_BUILT_IN))
 	error ("format string argument is not a string type");
@@ -267,13 +267,21 @@ 

Re: [testsuite] Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)

[Rainer Orth]

Hi Richard,

>> On Thu, 3 Jan 2019, Rainer Orth wrote:
>>
>>> gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as (both
>>> sparc and x86):
>>> 
>>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (DIE
>>> (0x([0-9a-f]*)) DW_TAG_lexical_block)[^#/!]*[#/!]
>>> [^(].*DW_TAG_lexical_block)[^#/!x]*x1[^#/!]*[#/!]
>>> DW_AT_abstract_origin
>>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> DW_TAG_lexical_block)[^#/!]*[#/!] (DIE (0x[0-9a-f]*)
>>> DW_TAG_variable 1
>>> 
>>> The first failure seems to be caused because .* performs multiline
>>> matches by default in Tcl; tightening it to [^\n]* avoids the problem.
>>
>> Hmm, but the matches are supposed to match multiple lines...  how
>> does it fail for you?
>
> it matches all of
>
> (DIE (0x19f) DW_TAG_lexical_block)
> .byte   0xd / uleb128 0xd; (DIE (0x1a0) DW_TAG_variable)
> .ascii "j"  / DW_AT_name
> .byte   0x1 / DW_AT_decl_file 
> (/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c)
> .byte   0x12/ DW_AT_decl_line
> .byte   0x14/ DW_AT_decl_column
> .long   0x17f   / DW_AT_type
> .byte   0   / end of children of DIE 0x19f
> .byte   0   / end of children of DIE 0x184
> .byte   0xe / uleb128 0xe; (DIE (0x1ac) DW_TAG_subprogram)
> .long   0x184   / DW_AT_abstract_origin
> .long   .LFB0   / DW_AT_low_pc
> .long   .LFE0-.LFB0 / DW_AT_high_pc
> .byte   0x1 / uleb128 0x1; DW_AT_frame_base
> .byte   0x9c/ DW_OP_call_frame_cfa
> / DW_AT_GNU_all_call_sites
> .byte   0xf / uleb128 0xf; (DIE (0x1bb) DW_TAG_formal_parameter)
> .long   0x195   / DW_AT_abstract_origin
> .byte   0x2 / uleb128 0x2; DW_AT_location
> .byte   0x91/ DW_OP_fbreg
> .byte   0   / sleb128 0
> .byte   0x6 / uleb128 0x6; (DIE (0x1c3) DW_TAG_lexical_block)
> .long   0x19f   / DW_AT_abstract_origin
>
> while with gas there's instead
>
>   .uleb128 0xc/ (DIE (0xad) DW_TAG_lexical_block)
>   .uleb128 0xd/ (DIE (0xae) DW_TAG_variable)
>   .ascii "j\0"/ DW_AT_name
>   .byte   0x1 / DW_AT_decl_file 
> (/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c)
>
> i.e. the pattern doesn't match with gas due to the [^(] while with as we
> have uleb128 first which does match, producing the failure (which shows
> that that part of my patch is wrong).

I still have a hard time determining what to do here.  I've now reverted
the tree to r264642, i.e. the one before the PR debug/87443 patch.  Then
I build on x86_64-pc-linux-gnu and ran the inline5.c testcase against
the old compiler.  I'd have expected all the scan-assembler* tests to
FAIL here, but instead I get

PASS: gcc.dg/debug/dwarf2/inline5.c (test for excess errors)
PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times DW_TAG_inlined_subrouti
ne 2
FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times DW_TAG_lexical_block\\)
[^#/!]*[#/!] DW_AT_abstract_origin 2
PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times DW_TAG_lexical_block\\)
[^#/!]*[#/!] \\(DIE \\(0x[0-9a-f]*\\) DW_TAG_variable 1
PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not \\(DIE \\(0x([0-9a-f]*)\\
) DW_TAG_lexical_block\\)[^#/!]*[#/!] [^(].*DW_TAG_lexical_block\\)[^#/!x]*x\\1[
^#/!]*[#/!] DW_AT_abstract_origin
FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not DW_TAG_lexical_block\\)[^
#/!x]*x([0-9a-f]*)[^#/!]*[#/!] DW_AT_abstract_origin.*\\(DIE \\(0x\\1\\) DW_TAG_
lexical_block\\)[^#/!]*[#/!] DW_AT

i.e. the problematic scan-assembler-not test PASSes before and after
your patch, making it hard to determine what that test is guarding
against (i.e. what is matched on Linux/x86_64 or Solaris with gas) and
adapting it to the Solaris as syntax.

Rainer

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

Re: [PATCH, C++,rebased] Fix PR c++/88261

[Jason Merrill]

On 1/4/19 10:30 AM, Bernd Edlinger wrote:

On 12/22/18 7:53 PM, Bernd Edlinger wrote:

On 12/21/18 2:03 AM, Martin Sebor wrote:

On 12/20/18 2:07 PM, Bernd Edlinger wrote:

On 12/20/18 6:50 PM, Martin Sebor wrote:

On 12/20/18 10:46 AM, Martin Sebor wrote:

On 12/17/18 7:58 AM, Jason Merrill wrote:

On 12/15/18 3:36 AM, Bernd Edlinger wrote:

this patch implements an error message, for non-static initialization of a 
flexible array member.
This duplicates the existing error message from the C-FE, to avoid ICE and 
wrong code generation
issues, as pointed out in the PR.

It is a bit funny that a non-functional feature like that has already rather 
much test coverage.
The most easy adjustment seems to change the existing test cases to use static 
declarations.


Martin, thoughts?


Our high-level goal when tightening up how flexible array members
are handled in C++ was to accept what's accepted in standard C mode
and reject (or, at a minimum, warn for) C++ extensions that could
be relied on in existing code.


I meant "reject what couldn't be relied on" and "warn for that could
be."



I believe the problem here is effectively that initializing non-static
flexible array is not supported by the middle-end.  All examples
where flexible array members are initialized on automatic variable
work only as long as they are simple enough that they are optimized
away so that they do not survive until expansion.

Take as example gcc/testsuite/g++.dg/ext/flexary13.C,
it compiles and runs successfully, but the assertions start to
fail if Ax is declared volatile, and at the same time, we know
that the automatic variables are allocated in a way that they
can overlap and crash at any time.

My impression is that the existing C error made the middle-end kind of rely
on this behavior.

So I think the right thing to do is duplicate the existing C error in
the C++ FE.  I do not see any automatic variable with initialized flexible
data members where it would be safe to only warn about them.


If there are no reasonable use cases that code out there could
be relying on because none of them works correctly then rejecting
the initialization makes sense to me.


(Sorry for the delay, by the way.  I've been migrating to a new machine
this week and things aren't yet working quite like I'm used to.)



The flexarray tests I added back then were for features that looked
like intentional extensions and that seemed to work for at least
some use cases as far as I could tell.  What I noticed didn't work
I created bugs for: 69338, 69696, and 69338 look related, but there
are others.

I think all these bugs should all be reviewed and a decision made
about what's intended to work and what continues to be accepted as
an accident and should be rejected.  After that, we can adjust
the existing tests.



I would not rule out the possibility that there can be more bugs.
But I think the existing tests need to avoid the case which evokes
the new error.  The question is, if changing from automatic to static
objects prevents those tests to test what they were originally written for.
I believe this is not the case, but I do probably not know all the
background here.


IIRC, most of the tests I added were meant to exercise just
the front-end, not any later stages (if that's what you meant).
Otherwise, if you're worried about the changes from auto to
static no longer exercising downstream front-end code, whether
that matters depends on the intent of each test.

flexary13.C was most likely meant to also verify codegen (hence
the assertions) so I would suggest to make it do that (i.e.,
verify the assertions are optimized out if in fact they are,
or make the test run so they must pass).



Oh well, unfortunately the modified test case with static objects
fails one assertion when executed at -O0, I missed that before,
because I used -O2 or higher.  I filed that as PR 88578, so in the
moment I would like to leave the test case as compile only,
and change that to run once PR 88578 is resolved.


The changes to the rest of the flexary*.C tests seem okay,
though a new test should be added to explicitly exercise this
change (bug 88261), even if the error happens to be tested by
one of the changed tests.



That is the case, because the array-6.c test case was moved
to c-c++-common.  That is the reproducer for the ICE from the PR.


In changes to the Wplacement-new-size*.C tests I would suggest
to follow the same approach of using statics instead of testing
for errors so the code that exercises warnings doesn't depend
on erroneous constructs.

The comment in Wplacement-new-size-2.C just above the code your
patch changes that reads:

    // Initialization of non-static objects with flexible array members
    // isn't allowed in C and should perhaps be disallowed in C++ as
    // well to avoid c++/69696 - incorrect initialization of block-scope
    // flexible array members.
    Ax ax2 = { 1, { 2, 3 } };

should be updated and the referenced bug and any others that t

Re: PING #2 [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Joseph Myers]

This patch is OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Avoid spurious test failures when -fno-inline in test flags

[Jonathan Wakely]

On 04/01/19 11:38 +, Jonathan Wakely wrote:

These tests rely on inlining, so if -fno-inline is added to the compiler
flags the tests fail. Use the predefined __NO_INLINE__ macro to detect
that situation, and don't bother testing the move assignment.

* testsuite/21_strings/basic_string/modifiers/assign/char/
move_assign_optim.cc: Avoid spurious failure when -fno-inline added
to test flags.
* testsuite/21_strings/basic_string/modifiers/assign/wchar_t/
move_assign_optim.cc: Likewise.


And another similar patch.

Tested x86_64-linux, committed to trunk.


commit 13388137fd5b141231daba34b55c176ed5b2c980
Author: Jonathan Wakely 
Date:   Fri Jan 4 18:49:11 2019 +

Fix test failure when -fno-inline is used

This currently checks _GLIBCXX_USE_DUAL_ABI which is incorrect, as that
can be true when _GLIBCXX_USE_CXX11_ABI == 0. The correct check would be
_GLIBCXX_USE_CXX11_ABI == 1, but that's made redundant by the cxx11-abi
effective target that the test requires. However, the test will fail if
-fno-inline is used, so check __NO_INLINE__ instead.

* testsuite/23_containers/list/61347.cc: Avoid spurious failure when
-fno-inline added to test flags.

diff --git a/libstdc++-v3/testsuite/23_containers/list/61347.cc b/libstdc++-v3/testsuite/23_containers/list/61347.cc
index 0ae905848ec..178c306698f 100644
--- a/libstdc++-v3/testsuite/23_containers/list/61347.cc
+++ b/libstdc++-v3/testsuite/23_containers/list/61347.cc
@@ -42,7 +42,7 @@ void testc(const std::list& l)
 
 int main()
 {
-#if _GLIBCXX_USE_DUAL_ABI
+#if ! __NO_INLINE__
   std::list l;
   testm(l);
   testc(l);

Re: [C++ Patch] [PR c++/88146] do not crash synthesizing inherited ctor(...)

[Jason Merrill]

On 12/28/18 9:33 PM, Alexandre Oliva wrote:

On Dec 28, 2018, Alexandre Oliva  wrote:


I guess I still need to
fill in other gaps to in my knowledge to try and make sense of it.


Done.


diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c


Here's a patch based on your suggestion.

[PR88146] do not instantiate constexpr if not manifestly const

This is another approach at fixing the g++.dg/cpp0x/inh-ctor32.C test
failures on targets that have non-void return values for cdtors: only
instantiate constexpr functions for expressions that are potentially
constant evaluated.

Alas, this exposed a latent problem elsewhere: braced initializer
lists underwent check_narrowing when simplified to non-lists, but that
did not signal maybe_constant_value the potentially constant evaluated
constant that all direct members of braced initializer lists have, so
after the change above we'd no longer initialize constexpr functions
that per P0859 we ought to.


Ah, yeah, that's a troublesome complication.  This area of the standard 
is very new, so I think let's defer trying to deal with this issue and 
pursue your other patch for now.



+  if (TREE_OPERAND (expr, 1)
+ && TREE_CODE (TREE_OPERAND (expr, 1)) == ADDR_EXPR
+ && DECL_P (TREE_OPERAND (TREE_OPERAND (expr, 1), 0))
+ && IDENTIFIER_CDTOR_P (DECL_NAME (TREE_OPERAND (TREE_OPERAND (expr, 
1), 0


Maybe

if (tree fn = cp_get_callee_fndecl_nofold (expr))
  if (DECL_CONSTRUCTOR_P (fn) || DECL_DESTRUCTOR_P (fn))

?  The other patch is OK with that change.

Jason

Re: [PATCH] attribute copy, leaf, weakref and -Wmisisng-attributes (PR 88546)

[Joseph Myers]

On Thu, 3 Jan 2019, Martin Sebor wrote:

> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01616.html

This is OK (with the typo fix Jakub noted).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [GCC][middle-end] Add rules to strip away unneeded type casts in expressions (2nd patch)

[Marc Glisse]

+(convert:newtype (op (convert:newtype @1) (convert:newtype @2)))


The outer 'convert' is unnecessary, op already has the same type.


+   (nop:type (op (convert:ty1 @1) (convert:ty2 @2)


Please don't use 'nop' directly, use 'convert' instead. This line is very 
suspicious, both arguments of op should have the same type. Specifying the 
outertype should be unnecessary, it is always 'type'. And if necessary, I 
expect '(convert:ty1 @1)' is the same as '{ arg0; }'.


The explicit list of types is quite ugly, but since it already exists...

--
Marc Glisse

Re: [PATCH] Disable gdb pagination temporarily in gdbinit.in

[Richard Sandiford]

Jakub Jelinek  writes:
> Hi!
>
> After upgrading gdb recently gdb ./cc1 etc. asks me to
> --Type  for more, q to quit, c to continue without paging--
> on start, because the stuff it prints by default + all the
> File tree.h will be skipped when stepping.
> File is-a.h will be skipped when stepping.
> File line-map.h will be skipped when stepping.
> File timevar.h will be skipped when stepping.
> Function rtx_expr_list::next will be skipped when stepping.
> Function rtx_expr_list::element will be skipped when stepping.
> Function rtx_insn_list::next will be skipped when stepping.
> Function rtx_insn_list::insn will be skipped when stepping.
> Function rtx_sequence::len will be skipped when stepping.
> Function rtx_sequence::element will be skipped when stepping.
> Function rtx_sequence::insn will be skipped when stepping.
> Function INSN_UID will be skipped when stepping.
> Function PREV_INSN will be skipped when stepping.
> Function SET_PREV_INSN will be skipped when stepping.
> Function NEXT_INSN will be skipped when stepping.
> Function SET_NEXT_INSN will be skipped when stepping.
> Function BLOCK_FOR_INSN will be skipped when stepping.
> Function PATTERN will be skipped when stepping.
> Function INSN_LOCATION will be skipped when stepping.
> Function INSN_HAS_LOCATION will be skipped when stepping.
> Function JUMP_LABEL_AS_INSN will be skipped when stepping.
>
> lines don't fit into my 41 line terminal anymore.  The following patch
> temporarily switches pagination off when printing all those skipped when
> stepping messages and restores it back afterwards.
>
> It uses python, but it seems we already unconditionally add to .gdbinit
> python import sys; sys.path.append('../../gcc'); import gdbhooks
> so I'd hope we don't regress with this anywhere.
>
> Even better would be to tell gdb not to print the skip messages, but it
> doesn't have such a support right now.
>
> Tested on x86_64-linux, ok for trunk?
>
> 2019-01-03  Jakub Jelinek  
>
>   * gdbinit.in: Turn off pagination for the skip commands, restore
>   it to previous state afterwards.

OK, thanks.

Richard

Re: [PATCH 2/3][GCC][AARCH64] Add new -mbranch-protection option to combine pointer signing and BTI

[Sam Tebbs]

On 12/20/18 4:38 PM, Sam Tebbs wrote:

> On 11/22/18 4:54 PM, Sam Tebbs wrote:
>> On 11/12/18 6:24 PM, Sudakshina Das wrote:
>>> Hi Sam
>>>
>>> On 02/11/18 17:31, Sam Tebbs wrote:
 Hi all,

 The -mbranch-protection option combines the functionality of
 -msign-return-address and the BTI features new in Armv8.5 to better reflect
 their relationship. This new option therefore supersedes and deprecates the
 existing -msign-return-address option.

 -mbranch-protection=[none|standard|] - Turns on different types of 
 branch
 protection available where:

  * "none": Turn of all types of branch protection
  * "standard" : Turns on all the types of protection to their 
 respective
standard levels.
  *  can be "+" separated protection types:

* "bti" : Branch Target Identification Mechanism.
* "pac-ret{+leaf+b-key}": Return Address Signing. The default return
  address signing is enabled by signing functions that save the return
  address to memory (non-leaf functions will practically always do this)
  using the a-key. The optional tuning arguments allow the user to
  extend the scope of return address signing to include leaf functions
  and to change the key to b-key. The tuning arguments must proceed the
  protection type "pac-ret".

 Thus -mbranch-protection=standard -> -mbranch-protection=bti+pac-ret.

 Its mapping to -msign-return-address is as follows:

  * -mbranch-protection=none -> -msign-return-address=none
  * -mbranch-protection=standard -> -msign-return-address=leaf
  * -mbranch-protection=pac-ret -> -msign-return-address=non-leaf
  * -mbranch-protection=pac-ret+leaf -> -msign-return-address=all

 This patch implements the option's skeleton and the "none", "standard" and
 "pac-ret" types (along with its "leaf" subtype).

 The previous patch in this series is here:
 https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00103.html

 Bootstrapped successfully and tested on aarch64-none-elf with no 
 regressions.

 OK for trunk?

>>> Thank for doing this. I am not a maintainer so you will need a
>>> maintainer's approval. Only nit, that I would add is that it would
>>> be good to have more test coverage, specially for the new parsing
>>> functions that have been added and the errors that are added.
>>>
>>> Example checking a few valid and invalid combinations of the options
>>> like:
>>> -mbranch-protection=pac-ret -mbranch-protection=none //disables
>>> everything
>>> -mbranch-protection=leaf  //errors out
>>> -mbranch-protection=none+pac-ret //errors out
>>> ... etc
>>> Also instead of removing all the old deprecated options, you can keep
>>> one (or a copy of one) to check for the deprecated warning.
>> Hi Sudi,
>>
>> Thanks for the feedback, I've incorporated your suggestions into the
>> attached patch and the updated changelog.
>>
>> gcc/ChangeLog:
>>
>> 2018-11-22  Sam Tebbs
>>
>>  * config/aarch64/aarch64.c (BRANCH_PROTEC_STR_MAX,
>>  aarch64_parse_branch_protection,
>>  struct aarch64_branch_protec_type,
>>  aarch64_handle_no_branch_protection,
>>  aarch64_handle_standard_branch_protection,
>>  aarch64_validate_mbranch_protection,
>>  aarch64_handle_pac_ret_protection,
>>  aarch64_handle_attr_branch_protection,
>>  accepted_branch_protection_string,
>>  aarch64_pac_ret_subtypes,
>>  aarch64_branch_protec_types,
>>  aarch64_handle_pac_ret_leaf): Define.
>>  (aarch64_override_options_after_change_1): Add check for
>>  accepted_branch_protection_string.
>>  (aarch64_override_options): Add check for
>>  accepted_branch_protection_string.
>>  (aarch64_option_save): Save accepted_branch_protection_string.
>>  (aarch64_option_restore): Save
>>  accepted_branch_protection_string.
>>  * config/aarch64/aarch64.c (aarch64_attributes): Add branch-protection.
>>  * config/aarch64/aarch64.opt: Add mbranch-protection. Deprecate
>>  msign-return-address.
>>  * doc/invoke.texi: Add mbranch-protection.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-11-22  Sam Tebbs
>>
>>  * (gcc.target/aarch64/return_address_sign_1.c,
>>  gcc.target/aarch64/return_address_sign_2.c,
>>  gcc.target/aarch64/return_address_sign_3.c (__attribute__)): Change
>>  option to -mbranch-protection.
>>  * gcc.target/aarch64/(branch-protection-option.c,
>>  branch-protection-option-2.c, branch-protection-attr.c,
>>  branch-protection-attr-2.c): New file.
> Hi all,
>
> Attached is an updated patch with branch_protec_type renamed to
> branch_protect_type, some unneeded ATTRIBUTE_USED removed and an added
> use of ARRAY_SIZE.
>
> Below is the updated changelog.
>
> OK for trunk? I have committed the preceding patch in the series.
>
> gcc/ChangeLog:
>
> 2018-1

Re: [PATCH 3/3][GCC][AARCH64] Add support for pointer authentication B key

[Sam Tebbs]

On 12/21/18 3:00 PM, Sam Tebbs wrote:
> On 11/9/18 11:04 AM, Sam Tebbs wrote:
>> On 11/02/2018 06:01 PM, Sam Tebbs wrote:
>>
>>> On 11/02/2018 05:35 PM, Sam Tebbs wrote:
>>>
 Hi all,

 This patch adds support for the Armv8.3-A pointer authentication 
 instructions
 that use the B-key (pacib*, autib* and retab). This required adding 
 builtins for
 pacib1716 and autib1716, adding the "b-key" feature to the 
 -mbranch-protection
 option, and required emitting a new CFI directive ".cfi_b_key_frame" which
 causes GAS to add 'B' to the CIE augmentation string. I also had to add a 
 new
 hook called ASM_POST_CFI_STARTPROC which is triggered when the 
 .cfi_startproc
 directive is emitted.

 The libgcc stack unwinder has been amended to authenticate return addresses
 with the B key when the function has been signed with the B key.

 The previous patch in this series is here:
 https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00104.html

 Bootstrapped successfully and regression tested on aarch64-none-elf.

 OK for trunk?

 gcc/
 2018-11-02  Sam Tebbs  

* config/aarch64/aarch64-builtins.c (aarch64_builtins): Add
AARCH64_PAUTH_BUILTIN_AUTIB1716 and AARCH64_PAUTH_BUILTIN_PACIB1716.
* config/aarch64/aarch64-builtins.c (aarch64_init_pauth_hint_builtins):
Add autib1716 and pacib1716 initialisation.
* config/aarch64/aarch64-builtins.c (aarch64_expand_builtin): Add checks
for autib1716 and pacib1716.
* config/aarch64/aarch64-protos.h (aarch64_key_type,
aarch64_post_cfi_startproc): Define.
* config/aarch64/aarch64-protos.h (aarch64_ra_sign_key): Define extern.
* config/aarch64/aarch64.c (aarch64_return_address_signing_enabled): Add
check for b-key, remove frame.laid_out assertion.
* config/aarch64/aarch64.c (aarch64_ra_sign_key,
aarch64_post_cfi_startproc, aarch64_handle_pac_ret_b_key): Define.
* config/aarch64/aarch64.h (TARGET_ASM_POST_CFI_STARTPROC): Define.
* config/aarch64/aarch64.c (aarch64_pac_ret_subtypes): Add "b-key".
* config/aarch64/aarch64.md (unspec): Add UNSPEC_AUTIA1716,
UNSPEC_AUTIB1716, UNSPEC_AUTIASP, UNSPEC_AUTIBSP, UNSPEC_PACIA1716,
UNSPEC_PACIB1716, UNSPEC_PACIASP, UNSPEC_PACIBSP.
* config/aarch64/aarch64.md (do_return): Add check for b-key.
* config/aarch64/aarch64.md (sp): Add check for
signing key and scope selected.
* config/aarch64/aarch64.md (1716): Add check for
signing key and scope selected.
* config/aarch64/aarch64.opt (msign-return-address=): Deprecate.
* config/aarch64/iterators.md (PAUTH_LR_SP): Add UNSPEC_AUTIASP,
UNSPEC_AUTIBSP, UNSPEC_PACIASP, UNSPEC_PACIBSP.
* config/aarch64/iterators.md (PAUTH_17_16): Add UNSPEC_AUTIA1716,
UNSPEC_AUTIB1716, UNSPEC_PACIA1716, UNSPEC_PACIB1716.
* config/aarch64/iterators.md (pauth_mnem_prefix): Add UNSPEC_AUTIA1716,
UNSPEC_AUTIB1716, UNSPEC_PACIA1716, UNSPEC_PACIB1716, UNSPEC_AUTIASP,
UNSPEC_AUTIBSP, UNSPEC_PACIASP, UNSPEC_PACIBSP.
* config/aarch64/iterators.md (pauth_hint_num_a): Replace
UNSPEC_PACI1716 and UNSPEC_AUTI1716 with UNSPEC_PACIA1716 and
UNSPEC_AUTIA1716 respectively.
* config/aarch64/iterators.md (pauth_hint_num_b): New int attribute.

 gcc/testsuite
 2018-11-02  Sam Tebbs  

* gcc.target/aarch64/return_address_sign_1.c (dg-final): Replace
"autiasp" and "paciasp" with "hint\t29 // autisp" and
"hint\t25 // pacisp" respectively.
* gcc.target/aarch64/return_address_sign_2.c (dg-final): Replace
"paciasp" with "hint\t25 // pacisp".
* gcc.target/aarch64/return_address_sign_3.c (dg-final): Replace
"paciasp" and "autiasp" with "pacisp" and "autisp" respectively.
* gcc.target/aarch64/return_address_sign_b_1.c: New file.
* gcc.target/aarch64/return_address_sign_b_2.c: New file.
* gcc.target/aarch64/return_address_sign_b_3.c: New file.
* gcc.target/aarch64/return_address_sign_b_exception.c: New file.
* gcc.target/aarch64/return_address_sign_builtin.c: New file

 libgcc/
 2018-11-02  Sam Tebbs  

* config/aarch64/aarch64-unwind.h (aarch64_cie_signed_with_b_key): New
function.
* config/aarch64/aarch64-unwind.h (aarch64_post_extract_frame_addr,
aarch64_post_frob_eh_handler_addr): Add check for b-key.
* unwind-dw2-fde.c (get_cie_encoding): Add check for 'B' in augmentation
string.
* unwind-dw2.c (extract_cie_info): Add check for 'B' in augmentation
string.
>>> Attached is an updated patch rebased on an improvement to the
>>> -mbranch-protection option documentation.
>> ping
> Attached is an improved patch with "hint" removed from the test scans,
> pauth_hint_num_a and pauth_hint_num

Re: [patch] Fix PR rtl-optimization/87727

[Vladimir Makarov]

On 12/28/2018 11:13 AM, Peter Bergner wrote:

On 12/21/18 9:24 AM, Vladimir Makarov wrote:

Peter, also if you are interesting to do RA work, there is another problem
which is to implement sub-register level conflict calculations in LRA.
Currently, IRA has a simple subregister level conflict calculation (see
allocno objects) and in a case of sub-register presence IRA and LRA decisions
are different and this results in worse code generations (there are some PRs
for this).  It would be also a big RA project to do.

Can you point me to the PRs?  Thanks.


Peter, sorry for the answer delay.  I am still on vacation.

Here is a recent PR I remember:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84757

Re: [PATCH][GCC][Aarch64] Change expected bfxil count in gcc.target/aarch64/combine_bfxil.c to 18 (PR/87763)

[Sam Tebbs]

On 1/4/19 4:19 PM, Wilco Dijkstra wrote:
> Hi Sam,
>
> This is a trivial test fix, so it falls under the obvious rule and can be
> committed without approval - https://www.gnu.org/software/gcc/svnwrite.html
>
> Cheers,
> Wilco

Hi Wilco,

Thanks, committed as r267579.

Re: [PATCH][GCC][Aarch64] Change expected bfxil count in gcc.target/aarch64/combine_bfxil.c to 18 (PR/87763)

[Wilco Dijkstra]

Hi Sam,

This is a trivial test fix, so it falls under the obvious rule and can be
committed without approval - https://www.gnu.org/software/gcc/svnwrite.html

Cheers,
Wilco

Re: [PATCH][GCC][Aarch64] Change expected bfxil count in gcc.target/aarch64/combine_bfxil.c to 18 (PR/87763)

[Sam Tebbs]

On 1/4/19 3:49 PM, Sudakshina Das wrote:

> Hi Sam
>
> On 04/01/19 10:26, Sam Tebbs wrote:
>> On 12/19/18 4:47 PM, Sam Tebbs wrote:
>>
>>> Hi all,
>>>
>>> Since r265398 (combine: Do not combine moves from hard registers), the bfxil
>>> scan in gcc.target/aarch64/combine_bfxil.c has been failing.
>>>
>>> FAIL: gcc.target/aarch64/combine_bfxil.c scan-assembler-times bfxil\\t 13
>>>
>>> This is because bfi was generated for the combine_* functions in the
>>> above test,
>>> but as of r265398, bfxil is preferred over bfi and so the bfxil count has
>>> increased. This patch increases the scan count to 18 to account for this so
>>> that the test passes.
>>>
>>> Before r265398
>>>
>>> combine_zero_extended_int:
>>>     bfxil   x0, x1, 0, 16
>>>     ret
>>>
>>> combine_balanced:
>>>     bfi x0, x1, 0, 32
>>>     ret
>>>
>>> combine_minimal:
>>>     bfi x0, x1, 0, 1
>>>     ret
>>>
>>> combine_unbalanced:
>>>     bfi x0, x1, 0, 24
>>>     ret
>>>
>>> combine_balanced_int:
>>>     bfi w0, w1, 0, 16
>>>     ret
>>>
>>> combine_unbalanced_int:
>>>     bfi w0, w1, 0, 8
>>>     ret
>>>
>>> With r265398
>>>
>>> combine_zero_extended_int:
>>>     bfxil   x0, x1, 0, 16
>>>     ret
>>>
>>> combine_balanced:
>>>     bfxil   x0, x1, 0, 32
>>>     ret
>>>
>>> combine_minimal:
>>>     bfxil   x0, x1, 0, 1
>>>     ret
>>>
>>> combine_unbalanced:
>>>     bfxil   x0, x1, 0, 24
>>>     ret
>>>
>>> combine_balanced_int:
>>>     bfxil   w0, w1, 0, 16
>>>     ret
>>>
>>> combine_unbalanced_int:
>>>     bfxil   w0, w1, 0, 8
>>>     ret
>>>
>>> These bfxil and bfi invocations are equivalent, so this patch won't hide any
>>> incorrect code-gen.
>>>
>>> Bootstrapped on aarch64-none-linux-gnu and regression tested on
>>> aarch64-none-elf with no regressions.
>>>
>>> OK for trunk?
>>>
> I am not a maintainer but this looks ok to me on its own. However I see
> that you commented about this patch on PR87763. Can you please add the
> PR tag in your changelog entry. Also since I did not see anyone else
> comment on the PR after your comment, I am adding some of the people
> from the PR to the cc list.
>
> Thanks
> Sudi

Thanks Sudi, below is the changelog with the PR tag added.

gcc/testsuite/Changelog:

2019-01-04  Sam Tebbs  

PR gcc/87763
* gcc.target/aarch64/combine_bfxil.c: Change
scan-assembler-times bfxil count to 18.

>
>>> gcc/testsuite/Changelog:
>>>
>>> 2018-12-19  Sam Tebbs  
>>>
>>>     * gcc.target/aarch64/combine_bfxil.c: Change
>>> scan-assembler-times bfxil count to 18.
>> ping
>>

[PATCH] Remove XFAIL from test that no longer fails

[Jonathan Wakely]

This test started passing with the old ABI with r263808, so doesn't need
to be marked XFAIL now.

* testsuite/21_strings/basic_string/requirements/
explicit_instantiation/debug.cc: Remove XFAIL for old ABI.

Tested x86_64-linux, committed to trunk.

commit c44a290e8ace25ec3ff2f3adcbd859a7f002d3f8
Author: Jonathan Wakely 
Date:   Fri Jan 4 16:04:49 2019 +

Remove XFAIL from test that no longer fails

This test started passing with the old ABI with r263808, so doesn't need
to be marked XFAIL now.

* testsuite/21_strings/basic_string/requirements/
explicit_instantiation/debug.cc: Remove XFAIL for old ABI.

diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string/requirements/explicit_instantiation/debug.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string/requirements/explicit_instantiation/debug.cc
index a0bfa6759cc..5e5642e847e 100644
--- 
a/libstdc++-v3/testsuite/21_strings/basic_string/requirements/explicit_instantiation/debug.cc
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string/requirements/explicit_instantiation/debug.cc
@@ -20,7 +20,6 @@
 #include 
 
 // { dg-do compile }
-// { dg-xfail-if "COW string missing some required members" { ! cxx11-abi } }
 
 // libstdc++/21770
 namespace debug = __gnu_debug;

Re: [PATCH][GCC][Aarch64] Change expected bfxil count in gcc.target/aarch64/combine_bfxil.c to 18 (PR/87763)

[Sudakshina Das]

Hi Sam

On 04/01/19 10:26, Sam Tebbs wrote:
> 
> On 12/19/18 4:47 PM, Sam Tebbs wrote:
> 
>> Hi all,
>>
>> Since r265398 (combine: Do not combine moves from hard registers), the bfxil
>> scan in gcc.target/aarch64/combine_bfxil.c has been failing.
>>
>> FAIL: gcc.target/aarch64/combine_bfxil.c scan-assembler-times bfxil\\t 13
>>
>> This is because bfi was generated for the combine_* functions in the
>> above test,
>> but as of r265398, bfxil is preferred over bfi and so the bfxil count has
>> increased. This patch increases the scan count to 18 to account for this so
>> that the test passes.
>>
>> Before r265398
>>
>> combine_zero_extended_int:
>>    bfxil   x0, x1, 0, 16
>>    ret
>>
>> combine_balanced:
>>    bfi x0, x1, 0, 32
>>    ret
>>
>> combine_minimal:
>>    bfi x0, x1, 0, 1
>>    ret
>>
>> combine_unbalanced:
>>    bfi x0, x1, 0, 24
>>    ret
>>
>> combine_balanced_int:
>>    bfi w0, w1, 0, 16
>>    ret
>>
>> combine_unbalanced_int:
>>    bfi w0, w1, 0, 8
>>    ret
>>
>> With r265398
>>
>> combine_zero_extended_int:
>>    bfxil   x0, x1, 0, 16
>>    ret
>>
>> combine_balanced:
>>    bfxil   x0, x1, 0, 32
>>    ret
>>
>> combine_minimal:
>>    bfxil   x0, x1, 0, 1
>>    ret
>>
>> combine_unbalanced:
>>    bfxil   x0, x1, 0, 24
>>    ret
>>
>> combine_balanced_int:
>>    bfxil   w0, w1, 0, 16
>>    ret
>>
>> combine_unbalanced_int:
>>    bfxil   w0, w1, 0, 8
>>    ret
>>
>> These bfxil and bfi invocations are equivalent, so this patch won't hide any
>> incorrect code-gen.
>>
>> Bootstrapped on aarch64-none-linux-gnu and regression tested on
>> aarch64-none-elf with no regressions.
>>
>> OK for trunk?
>>

I am not a maintainer but this looks ok to me on its own. However I see 
that you commented about this patch on PR87763. Can you please add the 
PR tag in your changelog entry. Also since I did not see anyone else 
comment on the PR after your comment, I am adding some of the people 
from the PR to the cc list.

Thanks
Sudi

>> gcc/testsuite/Changelog:
>>
>> 2018-12-19  Sam Tebbs  
>>
>>    * gcc.target/aarch64/combine_bfxil.c: Change
>> scan-assembler-times bfxil count to 18.
> ping
> 

[PATCH] Fix test failure with old Copy-On-Write std::string

[Jonathan Wakely]

* testsuite/27_io/filesystem/filesystem_error/copy.cc: Fix static
assertion failures with old std::string ABI.

Tested x86_64-linux, committed to trunk.


commit 043782108101ec994884185e058d79ee4e19b57e
Author: Jonathan Wakely 
Date:   Fri Jan 4 14:14:01 2019 +

Fix test failure with old Copy-On-Write std::string

* testsuite/27_io/filesystem/filesystem_error/copy.cc: Fix static
assertion failures with old std::string ABI.

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/filesystem_error/copy.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/filesystem_error/copy.cc
index 529e1e406e2..71eac38e0d3 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/filesystem_error/copy.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/filesystem_error/copy.cc
@@ -24,9 +24,19 @@
 
 using std::filesystem::filesystem_error;
 
+// The COW std::string does not have noexcept copies, because copying a
+// "leaked" string can throw (and for fully-dynamic strings, copying the
+// empty rep can also throw).
+// That's OK, because we know that the std::string in the std::runtime_error
+// or std::logic_error base class won't be leaked (and usually won't be empty).
+// The is_nothrow_xxx type traits don't know that though, so we can only
+// check them for the cxx11 ABI, which uses __cow_string, which has noexcept
+// copies.
+#if _GLIBCXX_USE_CXX11_ABI
 // PR libstdc++/83306
 static_assert(std::is_nothrow_copy_constructible_v);
 static_assert(std::is_nothrow_copy_assignable_v);
+#endif
 
 void
 test01()

[PATCH, C++,rebased] Fix PR c++/88261

[Bernd Edlinger]

On 12/22/18 7:53 PM, Bernd Edlinger wrote:
> On 12/21/18 2:03 AM, Martin Sebor wrote:
>> On 12/20/18 2:07 PM, Bernd Edlinger wrote:
>>> On 12/20/18 6:50 PM, Martin Sebor wrote:
 On 12/20/18 10:46 AM, Martin Sebor wrote:
> On 12/17/18 7:58 AM, Jason Merrill wrote:
>> On 12/15/18 3:36 AM, Bernd Edlinger wrote:
>>> this patch implements an error message, for non-static initialization 
>>> of a flexible array member.
>>> This duplicates the existing error message from the C-FE, to avoid ICE 
>>> and wrong code generation
>>> issues, as pointed out in the PR.
>>>
>>> It is a bit funny that a non-functional feature like that has already 
>>> rather much test coverage.
>>> The most easy adjustment seems to change the existing test cases to use 
>>> static declarations.
>>
>> Martin, thoughts?
>
> Our high-level goal when tightening up how flexible array members
> are handled in C++ was to accept what's accepted in standard C mode
> and reject (or, at a minimum, warn for) C++ extensions that could
> be relied on in existing code.

 I meant "reject what couldn't be relied on" and "warn for that could
 be."

>>>
>>> I believe the problem here is effectively that initializing non-static
>>> flexible array is not supported by the middle-end.  All examples
>>> where flexible array members are initialized on automatic variable
>>> work only as long as they are simple enough that they are optimized
>>> away so that they do not survive until expansion.
>>>
>>> Take as example gcc/testsuite/g++.dg/ext/flexary13.C,
>>> it compiles and runs successfully, but the assertions start to
>>> fail if Ax is declared volatile, and at the same time, we know
>>> that the automatic variables are allocated in a way that they
>>> can overlap and crash at any time.
>>>
>>> My impression is that the existing C error made the middle-end kind of rely
>>> on this behavior.
>>>
>>> So I think the right thing to do is duplicate the existing C error in
>>> the C++ FE.  I do not see any automatic variable with initialized flexible
>>> data members where it would be safe to only warn about them.
>>
>> If there are no reasonable use cases that code out there could
>> be relying on because none of them works correctly then rejecting
>> the initialization makes sense to me.
>>
 (Sorry for the delay, by the way.  I've been migrating to a new machine
 this week and things aren't yet working quite like I'm used to.)

>
> The flexarray tests I added back then were for features that looked
> like intentional extensions and that seemed to work for at least
> some use cases as far as I could tell.  What I noticed didn't work
> I created bugs for: 69338, 69696, and 69338 look related, but there
> are others.
>
> I think all these bugs should all be reviewed and a decision made
> about what's intended to work and what continues to be accepted as
> an accident and should be rejected.  After that, we can adjust
> the existing tests.
>
>>>
>>> I would not rule out the possibility that there can be more bugs.
>>> But I think the existing tests need to avoid the case which evokes
>>> the new error.  The question is, if changing from automatic to static
>>> objects prevents those tests to test what they were originally written for.
>>> I believe this is not the case, but I do probably not know all the
>>> background here.
>>
>> IIRC, most of the tests I added were meant to exercise just
>> the front-end, not any later stages (if that's what you meant).
>> Otherwise, if you're worried about the changes from auto to
>> static no longer exercising downstream front-end code, whether
>> that matters depends on the intent of each test.
>>
>> flexary13.C was most likely meant to also verify codegen (hence
>> the assertions) so I would suggest to make it do that (i.e.,
>> verify the assertions are optimized out if in fact they are,
>> or make the test run so they must pass).
>>
> 
> Oh well, unfortunately the modified test case with static objects
> fails one assertion when executed at -O0, I missed that before,
> because I used -O2 or higher.  I filed that as PR 88578, so in the
> moment I would like to leave the test case as compile only,
> and change that to run once PR 88578 is resolved.
> 
>> The changes to the rest of the flexary*.C tests seem okay,
>> though a new test should be added to explicitly exercise this
>> change (bug 88261), even if the error happens to be tested by
>> one of the changed tests.
>>
> 
> That is the case, because the array-6.c test case was moved
> to c-c++-common.  That is the reproducer for the ICE from the PR.
> 
>> In changes to the Wplacement-new-size*.C tests I would suggest
>> to follow the same approach of using statics instead of testing
>> for errors so the code that exercises warnings doesn't depend
>> on erroneous constructs.
>>
>> The comment in Wplacement-new-size-2.C just ab

Re: C++ PATCH to implement deferred parsing of noexcept-specifiers (c++/86476, c++/52869)

[Marek Polacek]

Ping.

On Wed, Dec 19, 2018 at 03:27:31PM -0500, Marek Polacek wrote:
> Prompted by Jon's observation in 52869, I noticed that we don't treat
> a noexcept-specifier as a complete-class context of a class ([class.mem]/6).
> As with member function bodies, default arguments, and NSDMIs, names used in
> a noexcept-specifier of a member-function can be declared later in the class
> body, so we need to wait and parse them at the end of the class.
> For that, I've made use of DEFAULT_ARG (now best to be renamed to 
> UNPARSED_ARG).
> 
> This wasn't as easy as I'd anticipated, because I needed to make sure to
> * handle well accessing function parameters in the noexcept-specifier,
>   hence the maybe_{begin,end}_member_function_processing business,
> * not regress diagnostic.  See e.g. noexcept38.C for detecting "looser
>   throw specifier", or noexcept39.C, friend decls and redeclaration.
>   This is handled by functions like noexcept_override_late_checks and
>   check_redeclaration_exception_specification.  I hope that's it.
> 
> Compiling libstdc++ was a fairly good stress test, and I've added a bunch
> of reduced testcases I've collected along the way.
> 
> I also noticed we're not properly detecting using 'this' in static member
> functions; tracked in 88548.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2018-12-19  Marek Polacek  
> 
>   PR c++/86476 - noexcept-specifier is a complete-class context.
>   PR c++/52869
>   * cp-tree.def (DEFAULT_ARG): Update commentary.
>   * cp-tree.h (UNPARSED_NOEXCEPT_SPEC_P): New macro.
>   (check_redeclaration_exception_specification): Declare.
>   (maybe_check_throw_specifier): Declare.
>   * decl.c (check_redeclaration_exception_specification): No longer
>   static.  Handle UNPARSED_NOEXCEPT_SPEC_P.
>   * except.c (nothrow_spec_p): Accept DEFAULT_ARG in assert.
>   * parser.c (cp_parser_noexcept_specification_opt,
>   cp_parser_late_noexcept_specifier, noexcept_override_late_checks):
>   Forward-declare.
>   (unparsed_noexcepts): New macro.
>   (push_unparsed_function_queues): Update initializer.
>   (cp_parser_init_declarator): Maybe save the noexcept-specifier to
>   post process.
>   (maybe_begin_member_function_processing): New.
>   (maybe_end_member_function_processing): New.
>   (cp_parser_class_specifier_1): Implement delayed parsing of
>   noexcept-specifiers.
>   (cp_parser_member_declaration): Maybe save the noexcept-specifier to
>   post process.
>   (cp_parser_save_noexcept): New.
>   (cp_parser_late_noexcept_specifier): New.
>   (noexcept_override_late_checks): New.
>   (cp_parser_noexcept_specification_opt): Call cp_parser_save_noexcept
>   instead of the normal processing if needed.
>   (cp_parser_save_member_function_body): Maybe save the
>   noexcept-specifier to post process.
>   * parser.h (cp_unparsed_functions_entry): Add new field to carry
>   a noexcept-specifier.
>   * pt.c (dependent_type_p_r): Handle unparsed noexcept expression.
>   * search.c (maybe_check_throw_specifier): New function, broken out
>   of...
>   (check_final_overrider): ...here.  Call maybe_check_throw_specifier.
>   * tree.c (canonical_eh_spec): Handle UNPARSED_NOEXCEPT_SPEC_P.
>   (cp_tree_equal): Handle DEFAULT_ARG.
>   * typeck2.c (merge_exception_specifiers): If an unparsed noexcept
>   expression has been passed, return it instead of merging it.
> 
>   * g++.dg/cpp0x/noexcept34.C: New test.
>   * g++.dg/cpp0x/noexcept35.C: New test.
>   * g++.dg/cpp0x/noexcept36.C: New test.
>   * g++.dg/cpp0x/noexcept37.C: New test.
>   * g++.dg/cpp0x/noexcept38.C: New test.
>   * g++.dg/cpp0x/noexcept39.C: New test.
> 
> diff --git gcc/cp/cp-tree.def gcc/cp/cp-tree.def
> index 43d90eb1efb..aa8b752d8f4 100644
> --- gcc/cp/cp-tree.def
> +++ gcc/cp/cp-tree.def
> @@ -209,7 +209,9 @@ DEFTREECODE (USING_STMT, "using_stmt", tcc_statement, 1)
>  
>  /* An un-parsed default argument.  Holds a vector of input tokens and
> a vector of places where the argument was instantiated before
> -   parsing had occurred.  */
> +   parsing had occurred.  This is also used for delayed NSDMIs and
> +   noexcept-specifier parsing.  For a noexcept-specifier, the vector
> +   holds a function declaration used for late checking.  */
>  DEFTREECODE (DEFAULT_ARG, "default_arg", tcc_exceptional, 0)
>  
>  /* An uninstantiated/unevaluated noexcept-specification.  For the
> diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
> index 1d806b782bd..bd3cd200fcb 100644
> --- gcc/cp/cp-tree.h
> +++ gcc/cp/cp-tree.h
> @@ -1193,6 +1193,9 @@ struct GTY (()) tree_default_arg {
>  #define UNEVALUATED_NOEXCEPT_SPEC_P(NODE)\
>(DEFERRED_NOEXCEPT_SPEC_P (NODE)   \
> && DEFERRED_NOEXCEPT_PATTERN (TREE_PURPOSE (NODE)) == NULL_TREE)
> +#define UNPARSED_NOEXCEPT_SPEC_P(NODE) \
>

Re: C++ PATCH for c++/88548, this accepted in static member functions

[Marek Polacek]

Ping.

On Sat, Dec 22, 2018 at 04:38:30PM -0500, Marek Polacek wrote:
> I noticed that we weren't diagnosing using 'this' in noexcept-specifiers
> of static member functions, and Jakub pointed out that this is also true
> for trailing-return-type.  cp_parser has local_variables_forbidden_p to
> detect using local vars and 'this' in certain contexts, so let's use that.
> 
> ...except that I found out that I need to be able to distinguish between
> forbidding just local vars and/or this, so I've changed its type to char.
> For instance, you can't use 'this' in a static member function declaration,
> but you can use a local var because noexcept/decltype is an unevaluated
> context.
> 
> I also noticed that we weren't diagnosing 'this' in a friend declaration,
> which is also forbidden.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2018-12-22  Marek Polacek  
> 
>   PR c++/88548 - this accepted in static member functions.
>   * parser.c (cp_debug_parser): Adjust printing of
>   local_variables_forbidden_p.
>   (cp_parser_new): Set local_variables_forbidden_p to 0 rather than false.
>   (cp_parser_primary_expression): When checking
>   local_variables_forbidden_p, use THIS_FORBIDDEN or
>   LOCAL_VARS_FORBIDDEN.
>   (cp_parser_lambda_body): Update the type of
>   local_variables_forbidden_p.  Set it to 0 rather than false.
>   (cp_parser_condition): Adjust call to cp_parser_declarator.
>   (cp_parser_explicit_instantiation): Likewise.
>   (cp_parser_init_declarator): Likewise.
>   (cp_parser_declarator): New parameter.  Use it.
>   (cp_parser_direct_declarator): New parameter.  Use it to set
>   local_variables_forbidden_p.  Adjust call to cp_parser_declarator.
>   (cp_parser_type_id_1): Adjust call to cp_parser_declarator.
>   (cp_parser_parameter_declaration): Likewise.
>   (cp_parser_default_argument): Update the type of
>   local_variables_forbidden_p.  Set it to LOCAL_VARS_AND_THIS_FORBIDDEN
>   rather than true.
>   (cp_parser_member_declaration): Tell cp_parser_declarator if we saw
>   'static' or 'friend'.
>   (cp_parser_exception_declaration): Adjust call to cp_parser_declarator.
>   (cp_parser_late_parsing_default_args): Update the type of
>   local_variables_forbidden_p.  Set it to LOCAL_VARS_AND_THIS_FORBIDDEN
>   rather than true.
>   (cp_parser_cache_defarg): Adjust call to cp_parser_declarator.
>   (cp_parser_objc_class_ivars): Likewise.
>   (cp_parser_objc_struct_declaration): Likewise.
>   (cp_parser_omp_for_loop_init): Likewise.
>   * parser.h (cp_parser): Change the type of local_variables_forbidden_p
>   to unsigned char.
>   (LOCAL_VARS_FORBIDDEN, LOCAL_VARS_AND_THIS_FORBIDDEN, THIS_FORBIDDEN):
>   Define.
> 
>   * g++.dg/cpp0x/this1.C: New test.
> 
> diff --git gcc/cp/parser.c gcc/cp/parser.c
> index 2cd91a37031..8aab21f3d33 100644
> --- gcc/cp/parser.c
> +++ gcc/cp/parser.c
> @@ -536,9 +536,12 @@ cp_debug_parser (FILE *file, cp_parser *parser)
> parser->allow_non_integral_constant_expression_p);
>cp_debug_print_flag (file, "Seen non-constant expression",
> parser->non_integral_constant_expression_p);
> -  cp_debug_print_flag (file, "Local names and 'this' forbidden in "
> -   "current context",
> -   parser->local_variables_forbidden_p);
> +  cp_debug_print_flag (file, "Local names forbidden in current context",
> +   (parser->local_variables_forbidden_p
> +& LOCAL_VARS_FORBIDDEN));
> +  cp_debug_print_flag (file, "'this' forbidden in current context",
> +   (parser->local_variables_forbidden_p
> +& THIS_FORBIDDEN));
>cp_debug_print_flag (file, "In unbraced linkage specification",
> parser->in_unbraced_linkage_specification_p);
>cp_debug_print_flag (file, "Parsing a declarator",
> @@ -2203,9 +2206,10 @@ static tree cp_parser_init_declarator
> location_t *, tree *);
>  static cp_declarator *cp_parser_declarator
>(cp_parser *, cp_parser_declarator_kind, cp_parser_flags, int *, bool *,
> -   bool, bool);
> +   bool, bool, bool);
>  static cp_declarator *cp_parser_direct_declarator
> -  (cp_parser *, cp_parser_declarator_kind, cp_parser_flags, int *, bool, 
> bool);
> +  (cp_parser *, cp_parser_declarator_kind, cp_parser_flags, int *, bool, 
> bool,
> +   bool);
>  static enum tree_code cp_parser_ptr_operator
>(cp_parser *, tree *, cp_cv_quals *, tree *);
>  static cp_cv_quals cp_parser_cv_qualifier_seq_opt
> @@ -3951,7 +3955,7 @@ cp_parser_new (void)
>parser->non_integral_constant_expression_p = false;
>  
>/* Local variable names are not forbidden.  */
> -  parser->local_variables_forbidden_p = false;
> +  parser->local_variables_forbidden_p = 0;
>  
>/* We are not proc

[PATCH] Fix bugs in filesystem::path::lexically_normal()

[Jonathan Wakely]

Using path::_List::erase(const_iterator) to remove a non-final component
in path::lexically_normal() is a bug, because it leaves the following
component with an incorrect _M_pos value.

Instead of providing erase members that allow removing components from
the middle, replace them with pop_back() and
_M_erase_from(const_iterator) which only allow removing elements at the
end. Most uses of erase are unaffected, because they only remove
elements from the end anyway. The one use of erasure from the middle in
lexically_normal() is replaced by calls to pop_back() and/or clearing
the last component to leave it as an empty final filename.

Also replace the "???" comment in lexically_normal() to document when
that branch is taken.

* include/bits/fs_path.h (path::_List::erase): Replace both overloads
with ...
(path::pop_back(), path::_M_erase_from(const_iterator)): New member
functions that will only erase elements at the end.
* src/filesystem/std-path.cc (path::_List::_Impl::pop_back()): Define.
(path::_List::_Impl::_M_erase_from(const_iterator)): Define.
(path::_List::operator=(const _List&)): Use _M_erase_from(p) instead
of erase(p, end()).
(path::_List::pop_back()): Define.
(path::_List::_M_erase_from(const_iterator)): Define.
(path::operator/=(const path&)): Use pop_back to remove last component
and _M_erase_from to remove multiple components.
(path::_M_append(basic_string_view)): Likewise.
(path::operator+=(const path&)): Likewise.
(path::_M_concat(basic_string_view)): Likewise.
(path::remove_filename()): Likewise.
(path::lexically_normal()): Use _List::_Impl iterators instead of
path::iterator. Use pop_back to remove components from the end. Clear
trailing filename, instead of using erase(const_iterator) to remove
a non-final component.
* testsuite/27_io/filesystem/path/generation/normal.cc: Test
additional cases.
* testsuite/27_io/filesystem/path/generation/normal2.cc: New test.

Tested x86_64-linux, committed to trunk.


commit c2464aba81c02c66a0189c39b5f5aafbf39b3d75
Author: Jonathan Wakely 
Date:   Fri Jan 4 13:50:19 2019 +

Fix bugs in filesystem::path::lexically_normal()

Using path::_List::erase(const_iterator) to remove a non-final component
in path::lexically_normal() is a bug, because it leaves the following
component with an incorrect _M_pos value.

Instead of providing erase members that allow removing components from
the middle, replace them with pop_back() and
_M_erase_from(const_iterator) which only allow removing elements at the
end. Most uses of erase are unaffected, because they only remove
elements from the end anyway. The one use of erasure from the middle in
lexically_normal() is replaced by calls to pop_back() and/or clearing
the last component to leave it as an empty final filename.

Also replace the "???" comment in lexically_normal() to document when
that branch is taken.

* include/bits/fs_path.h (path::_List::erase): Replace both 
overloads
with ...
(path::pop_back(), path::_M_erase_from(const_iterator)): New member
functions that will only erase elements at the end.
* src/filesystem/std-path.cc (path::_List::_Impl::pop_back()): 
Define.
(path::_List::_Impl::_M_erase_from(const_iterator)): Define.
(path::_List::operator=(const _List&)): Use _M_erase_from(p) instead
of erase(p, end()).
(path::_List::pop_back()): Define.
(path::_List::_M_erase_from(const_iterator)): Define.
(path::operator/=(const path&)): Use pop_back to remove last 
component
and _M_erase_from to remove multiple components.
(path::_M_append(basic_string_view)): Likewise.
(path::operator+=(const path&)): Likewise.
(path::_M_concat(basic_string_view)): Likewise.
(path::remove_filename()): Likewise.
(path::lexically_normal()): Use _List::_Impl iterators instead of
path::iterator. Use pop_back to remove components from the end. 
Clear
trailing filename, instead of using erase(const_iterator) to remove
a non-final component.
* testsuite/27_io/filesystem/path/generation/normal.cc: Test
additional cases.
* testsuite/27_io/filesystem/path/generation/normal2.cc: New test.

diff --git a/libstdc++-v3/include/bits/fs_path.h 
b/libstdc++-v3/include/bits/fs_path.h
index 69af50a19f8..34a5d324ce0 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -544,8 +544,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   const value_type& front() const noexcept;
   const value_type& back() const noexcept;
 
-  void erase(const_iterator);
-  void erase(const_iterator, const_

Re: [PATCH] Fix -fsanitize=address with > 32 byte aligned vars (PR sanitizer/88619)

[Martin Liška]

On 1/4/19 11:57 AM, Martin Liška wrote:
> I'm going to trigger asan-bootstrap on one of them.

Works for me on gcc112.fsffrance.org machine (ppc64le).

Martin

Re: [1/2] PR88598: Optimise x * { 0 or 1, 0 or 1, ... }

[Richard Sandiford]

Jakub Jelinek  writes:
> On Fri, Jan 04, 2019 at 12:13:13PM +, Richard Sandiford wrote:
>> > Can we avoid the gratuitous use of template here?  We were told that C++ 
>> > would 
>> > be used only when it makes things more straightforward and it's the 
>> > contrary 
>> > in this case, to wit the need for the ugly RECURSE macro in the middle.
>> 
>> I did it that way so that it would be easy to add things like
>> zero_or_minus_onep without cut-&-pasting the whole structure.
>
> IMHO we can make such a change only when it is needed.

The other predicates in tree.c suggest that we won't though.
E.g. there was never any attempt to unify integer_zerop vs. integer_onep
and real_zerop vs. real_onep.

>> The way to do that in C would be to use a macro for the full
>> function, but that's even uglier due to the extra backslashes.
>
> Or just make the function static inline and pass the function pointers
> to it as arguments?  If it is inlined, it will be the same, it could be
> even always_inline if that is really needed.

For that to work for recursive functions I think we'd need to pass the
caller predicate in too, which means one more function pointer overall.

Anyway, here's the patch without the template.

Thanks,
Richard


2019-01-04  Richard Sandiford  

gcc/
PR tree-optimization/88598
* tree.h (initializer_each_zero_or_onep): Declare.
* tree.c (initializer_each_zero_or_onep): New function.
(signed_or_unsigned_type_for): Handle float types too.
(unsigned_type_for, signed_type_for): Update comments accordingly.
* match.pd: Fold x * { 0 or 1, 0 or 1, ...} to
x & { 0 or -1, 0 or -1, ... }.

gcc/testsuite/
PR tree-optimization/88598
* gcc.dg/pr88598-1.c: New test.
* gcc.dg/pr88598-2.c: Likewise.
* gcc.dg/pr88598-3.c: Likewise.
* gcc.dg/pr88598-4.c: Likewise.
* gcc.dg/pr88598-5.c: Likewise.

Index: gcc/tree.h
===
--- gcc/tree.h  2019-01-04 12:40:51.0 +
+++ gcc/tree.h  2019-01-04 12:40:51.990582844 +
@@ -4506,6 +4506,7 @@ extern tree first_field (const_tree);
combinations indicate definitive answers.  */
 
 extern bool initializer_zerop (const_tree, bool * = NULL);
+extern bool initializer_each_zero_or_onep (const_tree);
 
 extern wide_int vector_cst_int_elt (const_tree, unsigned int);
 extern tree vector_cst_elt (const_tree, unsigned int);
Index: gcc/tree.c
===
--- gcc/tree.c  2019-01-04 12:40:51.0 +
+++ gcc/tree.c  2019-01-04 12:40:51.990582844 +
@@ -11229,6 +11229,45 @@ initializer_zerop (const_tree init, bool
 }
 }
 
+/* Return true if EXPR is an initializer expression in which every element
+   is a constant that is numerically equal to 0 or 1.  The elements do not
+   need to be equal to each other.  */
+
+bool
+initializer_each_zero_or_onep (const_tree expr)
+{
+  STRIP_ANY_LOCATION_WRAPPER (expr);
+
+  switch (TREE_CODE (expr))
+{
+case INTEGER_CST:
+  return integer_zerop (expr) || integer_onep (expr);
+
+case REAL_CST:
+  return real_zerop (expr) || real_onep (expr);
+
+case VECTOR_CST:
+  {
+   unsigned HOST_WIDE_INT nelts = vector_cst_encoded_nelts (expr);
+   if (VECTOR_CST_STEPPED_P (expr)
+   && !TYPE_VECTOR_SUBPARTS (TREE_TYPE (expr)).is_constant (&nelts))
+ return false;
+
+   for (unsigned int i = 0; i < nelts; ++i)
+ {
+   tree elt = VECTOR_CST_ENCODED_ELT (expr, i);
+   if (!initializer_each_zero_or_onep (elt))
+ return false;
+ }
+
+   return true;
+  }
+
+default:
+  return false;
+}
+}
+
 /* Check if vector VEC consists of all the equal elements and
that the number of elements corresponds to the type of VEC.
The function returns first element of the vector
@@ -11672,7 +11711,10 @@ int_cst_value (const_tree x)
 
 /* If TYPE is an integral or pointer type, return an integer type with
the same precision which is unsigned iff UNSIGNEDP is true, or itself
-   if TYPE is already an integer type of signedness UNSIGNEDP.  */
+   if TYPE is already an integer type of signedness UNSIGNEDP.
+   If TYPE is a floating-point type, return an integer type with the same
+   bitsize and with the signedness given by UNSIGNEDP; this is useful
+   when doing bit-level operations on a floating-point value.  */
 
 tree
 signed_or_unsigned_type_for (int unsignedp, tree type)
@@ -11702,17 +11744,23 @@ signed_or_unsigned_type_for (int unsigne
   return build_complex_type (inner2);
 }
 
-  if (!INTEGRAL_TYPE_P (type)
-  && !POINTER_TYPE_P (type)
-  && TREE_CODE (type) != OFFSET_TYPE)
+  unsigned int bits;
+  if (INTEGRAL_TYPE_P (type)
+  || POINTER_TYPE_P (type)
+  || TREE_CODE (type) == OFFSET_TYPE)
+bits = TYPE_PRECISION (type);
+  else if (TREE_CODE (type) == REAL_TYPE)
+bits = GET_

Re: [1/2] PR88598: Optimise x * { 0 or 1, 0 or 1, ... }

[Eric Botcazou]

> I did it that way so that it would be easy to add things like
> zero_or_minus_onep without cut-&-pasting the whole structure.

Yes, I inferred that, but people can still templatize afterward if need be.

Following this line of reasoning, why to limit yourself to this arbitrary 
number of 2 values in the template, I'm sure one can imagine the need in some 
distant future for initializer_each_minus_one_or_zero_or_onep. ;-)

-- 
Eric Botcazou

Re: [1/2] PR88598: Optimise x * { 0 or 1, 0 or 1, ... }

[Jakub Jelinek]

On Fri, Jan 04, 2019 at 12:13:13PM +, Richard Sandiford wrote:
> > Can we avoid the gratuitous use of template here?  We were told that C++ 
> > would 
> > be used only when it makes things more straightforward and it's the 
> > contrary 
> > in this case, to wit the need for the ugly RECURSE macro in the middle.
> 
> I did it that way so that it would be easy to add things like
> zero_or_minus_onep without cut-&-pasting the whole structure.

IMHO we can make such a change only when it is needed.

> The way to do that in C would be to use a macro for the full
> function, but that's even uglier due to the extra backslashes.

Or just make the function static inline and pass the function pointers
to it as arguments?  If it is inlined, it will be the same, it could be
even always_inline if that is really needed.

Jakub

Re: [PATCH] genattrtab bit-rot, and if_then_else in values

[Richard Sandiford]

Alan Modra  writes:
> On Thu, Jan 03, 2019 at 07:03:59PM +, Richard Sandiford wrote:
>> Richard Sandiford  writes:
>> > This still seems risky and isn't what the name and function comment
>
> OK, how about this delta from the previous patch to ameliorate the
> maintenance risk?

attr_value_alignment seems clearer, and means that we can handle
things like:

  (mult (symbol_ref "...") (const_int 4))

How about the patch below?

Thanks,
Richard


2019-01-04  Richard Sandiford  

gcc/
* genattrtab.c (or_attr_value): Replace with...
(attr_value_alignment): ...this new function.  Handle PLUS,
MINUS and MULT.
(write_length_unit_log): Update accordingly.

Index: gcc/genattrtab.c
===
--- gcc/genattrtab.c2019-01-04 12:16:51.0 +
+++ gcc/genattrtab.c2019-01-04 12:16:51.32298 +
@@ -268,7 +268,7 @@ static void insert_insn_ent(stru
 static void walk_attr_value   (rtx);
 static int max_attr_value (rtx, int*);
 static int min_attr_value (rtx, int*);
-static int or_attr_value  (rtx, int*);
+static unsigned int attr_value_alignment (rtx);
 static rtx simplify_test_exp  (rtx, int, int);
 static rtx simplify_test_exp_in_temp (rtx, int, int);
 static rtx copy_rtx_unchanging(rtx);
@@ -1568,24 +1568,21 @@ write_length_unit_log (FILE *outf)
   struct attr_value *av;
   struct insn_ent *ie;
   unsigned int length_unit_log, length_or;
-  int unknown = 0;
 
   if (length_attr)
 {
-  length_or = or_attr_value (length_attr->default_val->value, &unknown);
+  length_or = attr_value_alignment (length_attr->default_val->value);
   for (av = length_attr->first_value; av; av = av->next)
for (ie = av->first_insn; ie; ie = ie->next)
- length_or |= or_attr_value (av->value, &unknown);
-}
+ length_or |= attr_value_alignment (av->value);
 
-  if (length_attr == NULL || unknown)
-length_unit_log = 0;
-  else
-{
   length_or = ~length_or;
   for (length_unit_log = 0; length_or & 1; length_or >>= 1)
length_unit_log++;
 }
+  else
+length_unit_log = 0;
+
   fprintf (outf, "EXPORTED_CONST int length_unit_log = %u;\n", 
length_unit_log);
 }
 
@@ -3835,16 +3832,16 @@ min_attr_value (rtx exp, int *unknownp)
   return current_min;
 }
 
-/* Given an attribute value, return the result of ORing together all
-   CONST_STRING arguments encountered.  Set *UNKNOWNP and return -1
-   if the numeric value is not known.  */
+/* Given an attribute value EXP, return the maximum alignment that all
+   values are known to have.  Return 0 if EXP is known to be zero.  */
 
-static int
-or_attr_value (rtx exp, int *unknownp)
+static unsigned int
+attr_value_alignment (rtx exp)
 {
-  int current_or;
+  unsigned int current_or;
   int i;
 
+  /* When breaking, OR the possible alignment values into CURRENT_OR.  */
   switch (GET_CODE (exp))
 {
 case CONST_STRING:
@@ -3852,23 +3849,31 @@ or_attr_value (rtx exp, int *unknownp)
   break;
 
 case COND:
-  current_or = or_attr_value (XEXP (exp, 1), unknownp);
+  current_or = attr_value_alignment (XEXP (exp, 1));
   for (i = 0; i < XVECLEN (exp, 0); i += 2)
-   current_or |= or_attr_value (XVECEXP (exp, 0, i + 1), unknownp);
+   current_or |= attr_value_alignment (XVECEXP (exp, 0, i + 1));
   break;
 
 case IF_THEN_ELSE:
-  current_or = or_attr_value (XEXP (exp, 1), unknownp);
-  current_or |= or_attr_value (XEXP (exp, 2), unknownp);
+  current_or = attr_value_alignment (XEXP (exp, 1));
+  current_or |= attr_value_alignment (XEXP (exp, 2));
   break;
 
-default:
-  *unknownp = 1;
-  current_or = -1;
+case PLUS:
+case MINUS:
+  current_or = attr_value_alignment (XEXP (exp, 0));
+  current_or |= attr_value_alignment (XEXP (exp, 1));
   break;
+
+case MULT:
+  return (attr_value_alignment (XEXP (exp, 0))
+ * attr_value_alignment (XEXP (exp, 1)));
+
+default:
+  return 1;
 }
 
-  return current_or;
+  return current_or & -current_or;
 }
 
 /* Scan an attribute value, possibly a conditional, and record what actions

Re: [1/2] PR88598: Optimise x * { 0 or 1, 0 or 1, ... }

[Richard Sandiford]

Eric Botcazou  writes:
>> Index: gcc/tree.c
>> ===
>> --- gcc/tree.c   2019-01-04 11:39:24.810266962 +
>> +++ gcc/tree.c   2019-01-04 11:40:33.141683783 +
>> @@ -11229,6 +11229,60 @@ initializer_zerop (const_tree init, bool
>>  }
>>  }
>> 
>> +/* Return true if EXPR is an initializer expression that consists only
>> +   of INTEGER_CSTs for which IP0 or IP1 holds and REAL_CSTs for which
>> +   RP0 or RP1 holds.  The choice between IP0 and IP1, and between
>> +   RP0 and RP1, can vary from one element to the next.  */
>> +
>> +template> + bool (*RP0) (const_tree), bool (*RP1) (const_tree)>
>> +bool
>> +initializer_each_a_or_bp (const_tree expr)
>> +{
>> +#define RECURSE(X) initializer_each_a_or_bp (X)
>> +
>> +  STRIP_ANY_LOCATION_WRAPPER (expr);
>> +
>> +  switch (TREE_CODE (expr))
>> +{
>> +case INTEGER_CST:
>> +  return IP0 (expr) || IP1 (expr);
>> +
>> +case REAL_CST:
>> +  return RP0 (expr) || RP1 (expr);
>> +
>> +case VECTOR_CST:
>> +  {
>> +unsigned HOST_WIDE_INT nelts = vector_cst_encoded_nelts (expr);
>> +if (VECTOR_CST_STEPPED_P (expr)
>> +&& !TYPE_VECTOR_SUBPARTS (TREE_TYPE (expr)).is_constant (&nelts))
>> +  return false;
>> +
>> +for (unsigned int i = 0; i < nelts; ++i)
>> +  if (!RECURSE (VECTOR_CST_ENCODED_ELT (expr, i)))
>> +return false;
>> +
>> +return true;
>> +  }
>> +
>> +default:
>> +  return false;
>> +}
>> +
>> +#undef RECURSE
>
> Can we avoid the gratuitous use of template here?  We were told that C++ 
> would 
> be used only when it makes things more straightforward and it's the contrary 
> in this case, to wit the need for the ugly RECURSE macro in the middle.

I did it that way so that it would be easy to add things like
zero_or_minus_onep without cut-&-pasting the whole structure.
The way to do that in C would be to use a macro for the full
function, but that's even uglier due to the extra backslashes.

I can change it to:

for (unsigned int i = 0; i < nelts; ++i)
  {
tree elt = VECTOR_CST_ENCODED_ELT (expr, i);
if (!initializer_each_a_or_bp (elt))
  return false;
  }

if we want to avoid macros.

I was actually worried that this wouldn't be C++ enough, due to not
using a function template to combine each pair of functions. :-)

Richard

Re: [1/2] PR88598: Optimise x * { 0 or 1, 0 or 1, ... }

[Eric Botcazou]

> Index: gcc/tree.c
> ===
> --- gcc/tree.c2019-01-04 11:39:24.810266962 +
> +++ gcc/tree.c2019-01-04 11:40:33.141683783 +
> @@ -11229,6 +11229,60 @@ initializer_zerop (const_tree init, bool
>  }
>  }
> 
> +/* Return true if EXPR is an initializer expression that consists only
> +   of INTEGER_CSTs for which IP0 or IP1 holds and REAL_CSTs for which
> +   RP0 or RP1 holds.  The choice between IP0 and IP1, and between
> +   RP0 and RP1, can vary from one element to the next.  */
> +
> +template +  bool (*RP0) (const_tree), bool (*RP1) (const_tree)>
> +bool
> +initializer_each_a_or_bp (const_tree expr)
> +{
> +#define RECURSE(X) initializer_each_a_or_bp (X)
> +
> +  STRIP_ANY_LOCATION_WRAPPER (expr);
> +
> +  switch (TREE_CODE (expr))
> +{
> +case INTEGER_CST:
> +  return IP0 (expr) || IP1 (expr);
> +
> +case REAL_CST:
> +  return RP0 (expr) || RP1 (expr);
> +
> +case VECTOR_CST:
> +  {
> + unsigned HOST_WIDE_INT nelts = vector_cst_encoded_nelts (expr);
> + if (VECTOR_CST_STEPPED_P (expr)
> + && !TYPE_VECTOR_SUBPARTS (TREE_TYPE (expr)).is_constant (&nelts))
> +   return false;
> +
> + for (unsigned int i = 0; i < nelts; ++i)
> +   if (!RECURSE (VECTOR_CST_ENCODED_ELT (expr, i)))
> + return false;
> +
> + return true;
> +  }
> +
> +default:
> +  return false;
> +}
> +
> +#undef RECURSE

Can we avoid the gratuitous use of template here?  We were told that C++ would 
be used only when it makes things more straightforward and it's the contrary 
in this case, to wit the need for the ugly RECURSE macro in the middle.

-- 
Eric Botcazou

[2/2] PR88598: Optimise reduc (bit_and)

[Richard Sandiford]

This patch folds certain reductions of X & CST to X[I] & CST[I] if I is
the only nonzero element of CST.  This includes the motivating case in
which CST[I] is -1.

We could do the same for REDUC_MAX on unsigned types, but I wasn't sure
that that special case was worth it.

Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
OK to install?

Obvious follow-ons include handling multiplications of
single_nonzero_element constants, multiplications of uniform constants,
and additions of any constant, but this is enough to fix the PR.

Richard


2019-01-04  Richard Sandiford  

gcc/
PR tree-optimization/88598
* tree.h (single_nonzero_element): Declare.
* tree.c (single_nonzero_element): New function.
* match.pd: Fold certain reductions of X & CST to X[I] & CST[I]
if I is the only nonzero element of CST.

gcc/testsuite/
PR tree-optimization/88598
* gcc.dg/vect/pr88598-1.c: New test.
* gcc.dg/vect/pr88598-2.c: Likewise.
* gcc.dg/vect/pr88598-3.c: Likewise.
* gcc.dg/vect/pr88598-4.c: Likewise.
* gcc.dg/vect/pr88598-5.c: Likewise.
* gcc.dg/vect/pr88598-6.c: Likewise.

Index: gcc/tree.h
===
--- gcc/tree.h  2019-01-04 11:40:33.141683783 +
+++ gcc/tree.h  2019-01-04 11:40:36.581654424 +
@@ -4522,6 +4522,8 @@ extern tree uniform_vector_p (const_tree
 
 extern tree uniform_integer_cst_p (tree);
 
+extern int single_nonzero_element (const_tree);
+
 /* Given a CONSTRUCTOR CTOR, return the element values as a vector.  */
 
 extern vec *ctor_to_vec (tree);
Index: gcc/tree.c
===
--- gcc/tree.c  2019-01-04 11:40:33.141683783 +
+++ gcc/tree.c  2019-01-04 11:40:36.577654458 +
@@ -11355,6 +11355,38 @@ uniform_integer_cst_p (tree t)
   return NULL_TREE;
 }
 
+/* If VECTOR_CST T has a single nonzero element, return the index of that
+   element, otherwise return -1.  */
+
+int
+single_nonzero_element (const_tree t)
+{
+  unsigned HOST_WIDE_INT nelts;
+  unsigned int repeat_nelts;
+  if (VECTOR_CST_NELTS (t).is_constant (&nelts))
+repeat_nelts = nelts;
+  else if (VECTOR_CST_NELTS_PER_PATTERN (t) == 2)
+{
+  nelts = vector_cst_encoded_nelts (t);
+  repeat_nelts = VECTOR_CST_NPATTERNS (t);
+}
+  else
+return -1;
+
+  int res = -1;
+  for (unsigned int i = 0; i < nelts; ++i)
+{
+  tree elt = vector_cst_elt (t, i);
+  if (!integer_zerop (elt) && !real_zerop (elt))
+   {
+ if (res >= 0 || i >= repeat_nelts)
+   return -1;
+ res = i;
+   }
+}
+  return res;
+}
+
 /* Build an empty statement at location LOC.  */
 
 tree
Index: gcc/match.pd
===
--- gcc/match.pd2019-01-04 11:40:33.137683817 +
+++ gcc/match.pd2019-01-04 11:40:36.573654492 +
@@ -5251,3 +5251,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
{ wide_int_to_tree (sizetype, off); })
  { swap_p ? @0 : @2; }))
{ rhs_tree; })
+
+/* Fold REDUC (@0 & @1) -> @0[I] & @1[I] if element I is the only nonzero
+   element of @1.  */
+(for reduc (IFN_REDUC_PLUS IFN_REDUC_IOR IFN_REDUC_XOR)
+ (simplify (reduc (view_convert? (bit_and @0 VECTOR_CST@1)))
+  (with { int i = single_nonzero_element (@1); }
+   (if (i >= 0)
+(with { tree elt = vector_cst_elt (@1, i);
+   tree elt_type = TREE_TYPE (elt);
+   unsigned int elt_bits = tree_to_uhwi (TYPE_SIZE (elt_type));
+   tree size = bitsize_int (elt_bits);
+   tree pos = bitsize_int (elt_bits * i); }
+ (view_convert
+  (bit_and:elt_type
+   (BIT_FIELD_REF:elt_type @0 { size; } { pos; })
+   { elt; })))
Index: gcc/testsuite/gcc.dg/vect/pr88598-1.c
===
--- /dev/null   2018-12-31 11:20:29.178325188 +
+++ gcc/testsuite/gcc.dg/vect/pr88598-1.c   2019-01-04 11:40:36.577654458 
+
@@ -0,0 +1,55 @@
+/* { dg-do run } */
+/* { dg-additional-options "-fdump-tree-optimized" } */
+
+#include "tree-vect.h"
+
+#define N 4
+
+int a[N];
+
+int __attribute__ ((noipa))
+f1 (void)
+{
+  int b[N] = { 15, 0, 0, 0 }, res = 0;
+  for (int i = 0; i < N; ++i)
+res += a[i] & b[i];
+  return res;
+}
+
+int __attribute__ ((noipa))
+f2 (void)
+{
+  int b[N] = { 0, 31, 0, 0 }, res = 0;
+  for (int i = 0; i < N; ++i)
+res += a[i] & b[i];
+  return res;
+}
+
+int __attribute__ ((noipa))
+f3 (void)
+{
+  int b[N] = { 0, 0, 0, -1 }, res = 0;
+  for (int i = 0; i < N; ++i)
+res += a[i] & b[i];
+  return res;
+}
+
+int
+main ()
+{
+  check_vect ();
+
+  for (int i = 0; i < N; ++i)
+a[i] = 0xe0 + i;
+
+  if (f1 () != (a[0] & 15)
+  || f2 () != (a[1] & 31)
+  || f3 () != a[N - 1])
+__builtin_abort ();
+
+  return 0;
+}
+
+/* ??? We need more constant folding for this to work 

[1/2] PR88598: Optimise x * { 0 or 1, 0 or 1, ... }

[Richard Sandiford]

The PR has:

vect__6.24_42 = vect__5.23_41 * { 0.0, 1.0e+0, 0.0, 0.0 };

which for -fno-signed-zeros -fno-signaling-nans can be simplified to:

vect__6.24_42 = vect__5.23_41 & { 0, -1, 0, 0 };

I deliberately didn't handle COMPLEX_CST or CONSTRUCTOR in
initializer_each_zero_or_onep since there are no current use cases.

The patch also makes (un)signed_type_for handle floating-point types.
I tried to audit all callers and the few that handle null returns would
be unaffected.

Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
OK to install?

Richard


2019-01-04  Richard Sandiford  

gcc/
PR tree-optimization/88598
* tree.h (initializer_each_zero_or_onep): Declare.
* tree.c (initializer_each_a_or_bp): New function.
(initializer_each_zero_or_onep): Likewise.
(signed_or_unsigned_type_for): Handle float types too.
(unsigned_type_for, signed_type_for): Update comments accordingly.
* match.pd: Fold x * { 0 or 1, 0 or 1, ...} to
x & { 0 or -1, 0 or -1, ... }.

gcc/testsuite/
PR tree-optimization/88598
* gcc.dg/pr88598-1.c: New test.
* gcc.dg/pr88598-2.c: Likewise.
* gcc.dg/pr88598-3.c: Likewise.
* gcc.dg/pr88598-4.c: Likewise.
* gcc.dg/pr88598-5.c: Likewise.

Index: gcc/tree.h
===
--- gcc/tree.h  2019-01-04 11:39:24.810266962 +
+++ gcc/tree.h  2019-01-04 11:40:33.141683783 +
@@ -4506,6 +4506,7 @@ extern tree first_field (const_tree);
combinations indicate definitive answers.  */
 
 extern bool initializer_zerop (const_tree, bool * = NULL);
+extern bool initializer_each_zero_or_onep (const_tree);
 
 extern wide_int vector_cst_int_elt (const_tree, unsigned int);
 extern tree vector_cst_elt (const_tree, unsigned int);
Index: gcc/tree.c
===
--- gcc/tree.c  2019-01-04 11:39:24.810266962 +
+++ gcc/tree.c  2019-01-04 11:40:33.141683783 +
@@ -11229,6 +11229,60 @@ initializer_zerop (const_tree init, bool
 }
 }
 
+/* Return true if EXPR is an initializer expression that consists only
+   of INTEGER_CSTs for which IP0 or IP1 holds and REAL_CSTs for which
+   RP0 or RP1 holds.  The choice between IP0 and IP1, and between
+   RP0 and RP1, can vary from one element to the next.  */
+
+template
+bool
+initializer_each_a_or_bp (const_tree expr)
+{
+#define RECURSE(X) initializer_each_a_or_bp (X)
+
+  STRIP_ANY_LOCATION_WRAPPER (expr);
+
+  switch (TREE_CODE (expr))
+{
+case INTEGER_CST:
+  return IP0 (expr) || IP1 (expr);
+
+case REAL_CST:
+  return RP0 (expr) || RP1 (expr);
+
+case VECTOR_CST:
+  {
+   unsigned HOST_WIDE_INT nelts = vector_cst_encoded_nelts (expr);
+   if (VECTOR_CST_STEPPED_P (expr)
+   && !TYPE_VECTOR_SUBPARTS (TREE_TYPE (expr)).is_constant (&nelts))
+ return false;
+
+   for (unsigned int i = 0; i < nelts; ++i)
+ if (!RECURSE (VECTOR_CST_ENCODED_ELT (expr, i)))
+   return false;
+
+   return true;
+  }
+
+default:
+  return false;
+}
+
+#undef RECURSE
+}
+
+/* Return true if EXPR is an initializer expression in which every element
+   is a constant that is numerically equal to 0 or 1.  The elements do not
+   need to be equal to each other.  */
+
+bool
+initializer_each_zero_or_onep (const_tree expr)
+{
+  return initializer_each_a_or_bp (expr);
+}
+
 /* Check if vector VEC consists of all the equal elements and
that the number of elements corresponds to the type of VEC.
The function returns first element of the vector
@@ -11672,7 +11726,10 @@ int_cst_value (const_tree x)
 
 /* If TYPE is an integral or pointer type, return an integer type with
the same precision which is unsigned iff UNSIGNEDP is true, or itself
-   if TYPE is already an integer type of signedness UNSIGNEDP.  */
+   if TYPE is already an integer type of signedness UNSIGNEDP.
+   If TYPE is a floating-point type, return an integer type with the same
+   bitsize and with the signedness given by UNSIGNEDP; this is useful
+   when doing bit-level operations on a floating-point value.  */
 
 tree
 signed_or_unsigned_type_for (int unsignedp, tree type)
@@ -11702,17 +11759,23 @@ signed_or_unsigned_type_for (int unsigne
   return build_complex_type (inner2);
 }
 
-  if (!INTEGRAL_TYPE_P (type)
-  && !POINTER_TYPE_P (type)
-  && TREE_CODE (type) != OFFSET_TYPE)
+  unsigned int bits;
+  if (INTEGRAL_TYPE_P (type)
+  || POINTER_TYPE_P (type)
+  || TREE_CODE (type) == OFFSET_TYPE)
+bits = TYPE_PRECISION (type);
+  else if (TREE_CODE (type) == REAL_TYPE)
+bits = GET_MODE_BITSIZE (SCALAR_TYPE_MODE (type));
+  else
 return NULL_TREE;
 
-  return build_nonstandard_integer_type (TYPE_PRECISION (type), unsignedp);
+  return build_nonstandard_integer_type (bits, unsignedp);
 }
 
 /* If TYPE is an integral or pointer type, return an integer 

[PATCH] Fix concatenation bug in filesystem::path

[Jonathan Wakely]

When erasing a trailing empty filename component, the output iterator
was not decremented, causing the next component to be created at the
wrong position.

* src/filesystem/std-path.cc (path::operator+=(const path&)): Fix
incorrect treatment of empty filename after trailing slash.
* testsuite/27_io/filesystem/path/concat/path.cc: Test problem case.

Tested x86_64-linux, committed to trunk.


commit cb0b6ed6f18823971bbd2a555849278653b2aef0
Author: Jonathan Wakely 
Date:   Fri Jan 4 11:35:03 2019 +

Fix concatenation bug in filesystem::path

When erasing a trailing empty filename component, the output iterator
was not decremented, causing the next component to be created at the
wrong position.

* src/filesystem/std-path.cc (path::operator+=(const path&)): Fix
incorrect treatment of empty filename after trailing slash.
* testsuite/27_io/filesystem/path/concat/path.cc: Test problem case.

diff --git a/libstdc++-v3/src/filesystem/std-path.cc 
b/libstdc++-v3/src/filesystem/std-path.cc
index bf6f37711eb..b7315ad1686 100644
--- a/libstdc++-v3/src/filesystem/std-path.cc
+++ b/libstdc++-v3/src/filesystem/std-path.cc
@@ -945,7 +945,7 @@ path::operator+=(const path& p)
   else if (orig_filenamelen == 0 && it != last)
{
  // Remove empty filename at end of original path.
- _M_cmpts.erase(std::prev(output));
+ _M_cmpts.erase(--output);
}
 
   if (it != last && it->_M_type() == _Type::_Root_name)
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/concat/path.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/concat/path.cc
index b653219a7f7..e2a14bd8fcc 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/concat/path.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/concat/path.cc
@@ -59,9 +59,18 @@ test02()
   }
 }
 
+void
+test03()
+{
+  path p = "a/";
+  p += path("/b");
+  compare_paths(p, "a//b");
+}
+
 int
 main()
 {
   test01();
   test02();
+  test03();
 }

[PATCH] Avoid spurious test failures when -fno-inline in test flags

[Jonathan Wakely]

These tests rely on inlining, so if -fno-inline is added to the compiler
flags the tests fail. Use the predefined __NO_INLINE__ macro to detect
that situation, and don't bother testing the move assignment.

* testsuite/21_strings/basic_string/modifiers/assign/char/
move_assign_optim.cc: Avoid spurious failure when -fno-inline added
to test flags.
* testsuite/21_strings/basic_string/modifiers/assign/wchar_t/
move_assign_optim.cc: Likewise.

Tested x86_64-linux, committed to trunk.


commit 6b4a77f22e8d63755453bdae3ce1854fae2d2484
Author: redi 
Date:   Fri Jan 4 11:06:49 2019 +

Avoid spurious test failures when -fno-inline in test flags

These tests rely on inlining, so if -fno-inline is added to the compiler
flags the tests fail. Use the predefined __NO_INLINE__ macro to detect
that situation, and don't bother testing the move assignment.

* testsuite/21_strings/basic_string/modifiers/assign/char/
move_assign_optim.cc: Avoid spurious failure when -fno-inline added
to test flags.
* testsuite/21_strings/basic_string/modifiers/assign/wchar_t/
move_assign_optim.cc: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@267573 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign_optim.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign_optim.cc
index 6ac54b509df..bbe60e578ca 100644
--- 
a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign_optim.cc
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign_optim.cc
@@ -30,6 +30,8 @@ test01(std::string& target, std::string&& source)
   // The move assignment operator should be simple enough that the compiler
   // can see that it never results in a length_error or bad_alloc exception
   // (which would be turned into std::terminate by the noexcept on the
-  // assignment operator).
+  // assignment operator). This is only true when inlining though.
+#ifndef __NO_INLINE__
   target = std::move(source);
+#endif
 }
diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign_optim.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign_optim.cc
index 261c6641043..15f3a4bcbe1 100644
--- 
a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign_optim.cc
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign_optim.cc
@@ -30,6 +30,8 @@ test01(std::wstring& target, std::wstring&& source)
   // The move assignment operator should be simple enough that the compiler
   // can see that it never results in a length_error or bad_alloc exception
   // (which would be turned into std::terminate by the noexcept on the
-  // assignment operator).
+  // assignment operator). This is only true when inlining though.
+#ifndef __NO_INLINE__
   target = std::move(source);
+#endif
 }

Re: [PATCH][AArch64] Use Q-reg loads/stores in movmem expansion

[Kyrill Tkachov]

Ping.
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01560.html

Thanks,
Kyrill

On 21/12/18 12:30, Kyrill Tkachov wrote:

Hi all,

Our movmem expansion currently emits TImode loads and stores when copying 
128-bit chunks.
This generates X-register LDP/STP sequences as these are the most preferred 
registers for that mode.

For the purpose of copying memory, however, we want to prefer Q-registers.
This uses one fewer register, so helping with register pressure.
It also allows merging of 256-bit and larger copies into Q-reg LDP/STP, further 
helping code size.

The implementation of that is easy: we just use a 128-bit vector mode (V4SImode 
in this patch)
rather than a TImode.

With this patch the testcase:
#define N 8
int src[N], dst[N];

void
foo (void)
{
  __builtin_memcpy (dst, src, N * sizeof (int));
}

generates:
foo:
adrpx1, src
add x1, x1, :lo12:src
adrpx0, dst
add x0, x0, :lo12:dst
ldp q1, q0, [x1]
stp q1, q0, [x0]
ret

instead of:
foo:
adrpx1, src
add x1, x1, :lo12:src
adrpx0, dst
add x0, x0, :lo12:dst
ldp x2, x3, [x1]
stp x2, x3, [x0]
ldp x2, x3, [x1, 16]
stp x2, x3, [x0, 16]
ret

Bootstrapped and tested on aarch64-none-linux-gnu.
I hope this is a small enough change for GCC 9.
One could argue that it is finishing up the work done this cycle to support 
Q-register LDP/STPs

I've seen this give about 1.8% on 541.leela_r on Cortex-A57 with other changes 
in SPEC2017 in the noise
but there is reduction in code size everywhere (due to more LDP/STP-Q pairs 
being formed)

Ok for trunk?

Thanks,
Kyrill

2018-12-21  Kyrylo Tkachov  

* config/aarch64/aarch64.c (aarch64_expand_movmem): Use V4SImode for
128-bit moves.

2018-12-21  Kyrylo Tkachov  

* gcc.target/aarch64/movmem-q-reg_1.c: New test.

Re: [PATCH] Fix -fsanitize=address with > 32 byte aligned vars (PR sanitizer/88619)

[Martin Liška]

On 1/3/19 11:44 PM, Jakub Jelinek wrote:
> Hi!
> 
> The prev_offset we push into the vector is supposed to be the end of
> the red zone for the variable, it needs to be ASAN_MIN_RED_ZONE_SIZE
> aligned, but by aligning it more we can end up with red zone with negative
> size.  E.g. on the testcase, we have initial frame_offset -8 (because of
> -fstack-protector guard), we align it to -32 first (required that the
> start and end of the var block is 32 byte aligned (4 byte aligned in shadow
> memory)).  The first variable needs 64 byte alignment, but is just 4 bytes,
> so the next after
>   offset = alloc_stack_frame_space (size, alignment);
> we end up with frame_offset (== offset) -64 and the start of red zone is
> after that 4 byte variable, i.e. at -60.  But the align_base tweak from
> -32 with 64 byte alignment gives -64.

Thank you Jakub for the patch.
I was also considering adding a sanity check that will ensure
the offsets in data->asan_vec are always in increasing order.
What do you think about it?

> 
> Now, the stack vars are sorted first by large vs. small alignment (not
> relevant to x86), then by size and only afterwards by alignment, so similar
> problems could appear if we have some large variable followed by > 32 byte
> aligned very small variable.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

I can add here that asan.exp tests work both on ppc64le-linux-gnu and 
ppc64-linux-gnu.
I'm going to trigger asan-bootstrap on one of them.

Martin

> 
> 2019-01-03  Jakub Jelinek  
> 
>   PR sanitizer/88619
>   * cfgexpand.c (expand_stack_vars): Only align prev_offset to
>   ASAN_MIN_RED_ZONE_SIZE, not to maximum of that and alignb.
> 
>   * c-c++-common/asan/pr88619.c: New test.
> 
> --- gcc/cfgexpand.c.jj2019-01-01 12:37:17.328972145 +0100
> +++ gcc/cfgexpand.c   2019-01-03 14:11:16.209366858 +0100
> @@ -1130,7 +1130,7 @@ expand_stack_vars (bool (*pred) (size_t)
> prev_offset = frame_offset.to_constant ();
>   }
> prev_offset = align_base (prev_offset,
> - MAX (alignb, ASAN_MIN_RED_ZONE_SIZE),
> + ASAN_MIN_RED_ZONE_SIZE,
>   !FRAME_GROWS_DOWNWARD);
> tree repr_decl = NULL_TREE;
> unsigned HOST_WIDE_INT size
> --- gcc/testsuite/c-c++-common/asan/pr88619.c.jj  2019-01-03 
> 14:16:00.779659964 +0100
> +++ gcc/testsuite/c-c++-common/asan/pr88619.c 2019-01-03 14:15:40.568994254 
> +0100
> @@ -0,0 +1,14 @@
> +/* PR sanitizer/88619 */
> +/* { dg-do compile { target fstack_protector } } */
> +/* { dg-options "-fstack-protector-strong -fsanitize=address" } */
> +
> +typedef int A __attribute__((aligned (64)));
> +
> +int
> +main ()
> +{
> +  A b;
> +  int *p = &b;
> +  *(p - 1) = 123;
> +  __builtin_alloca (b);
> +}
> 
>   Jakub
> 

[PATCH] PR60563 - FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*

[Dominique d'Humières]

Is the following patch OK for trunk and the release branches?

2019-01-04  Dominique d'Humieres  

* g++.dg/ext/sync-4.C: Add dg-xfail-run-if for darwin.

--- ../_clean/gcc/testsuite/g++.dg/ext/sync-4.C 2015-04-30 23:36:40.0 
+0200
+++ gcc/testsuite/g++.dg/ext/sync-4.C   2019-01-03 20:28:29.0 +0100
@@ -1,4 +1,6 @@
 /* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin* 
*-*-darwin[912]* } } */
+/* FIXME The following additional option should be removed after the fix for 
radr://19802258.
+/* { dg-xfail-run-if "PR60563 radr://19802258" { *-*-darwin* } } */
 /* { dg-require-effective-target sync_long_long_runtime } */
 /* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
 /* { dg-additional-options "-march=pentium" { target { { i?86-*-* x86_64-*-* } 
&& ia32 } } } */

TIA

Dominique

[GCC][middle-end] Add rules to strip away unneeded type casts in expressions (2nd patch)

[Tamar Christina]

Hi All,

This is an updated version of my first patch which moves part of the type 
conversion code
from convert.c to match.pd because match.pd is able to apply this 
transformation in the
presence of intermediate temporary variables.

The previous patch was only regtested on aarch64-none-linux-gnu and I hadn't 
done a
regression on x86_64-pc-linux-gnu only a bootstrap.  The previous patch was 
approved

here https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00116.html
but before committing I ran a x86_64-pc-linux-gnu regtest to be sure and this
showed an issue with a DFP test. I Have fixed this by removing the offending 
convert.
The convert was just saying "keep the type as is" but match.pd looped here as 
it thinks
the match did something and would try other patterns, causing it to match 
itself again.

Instead when there's nothing to update, I just don't do anything.

The second change was to merge this with the existing pattern for integer 
conversion
in order to silence a warning from match.pd which though that the two patterns 
overlaps
because their match conditions are similar (they have different conditions 
inside the ifs
but match.pd doesn't check those of course.).

Regtested and bootstrapped on aarch64-none-linux-gnu and x86_64-pc-linux-gnu 
and no issues.

Ok for trunk?

Thanks,
Tamar

Concretely it makes both these cases behave the same

  float e = (float)a * (float)b;
  *c = (_Float16)e;

and 

  *c = (_Float16)((float)a * (float)b);

Thanks,
Tamar

gcc/ChangeLog:

2019-01-04  Tamar Christina  

* convert.c (convert_to_real_1): Move part of conversion code...
* match.pd: ...To here.

gcc/testsuite/ChangeLog:

2019-01-04  Tamar Christina  

* gcc.dg/type-convert-var.c: New test.

-- 
diff --git a/gcc/convert.c b/gcc/convert.c
index 1a3353c870768a33fe22480ec97c7d3e0c504075..a16b7af0ec54693eb4f1e3a110aabc1aa18eb8df 100644
--- a/gcc/convert.c
+++ b/gcc/convert.c
@@ -295,92 +295,6 @@ convert_to_real_1 (tree type, tree expr, bool fold_p)
 	  return build1 (TREE_CODE (expr), type, arg);
 	}
 	  break;
-	/* Convert (outertype)((innertype0)a+(innertype1)b)
-	   into ((newtype)a+(newtype)b) where newtype
-	   is the widest mode from all of these.  */
-	case PLUS_EXPR:
-	case MINUS_EXPR:
-	case MULT_EXPR:
-	case RDIV_EXPR:
-	   {
-	 tree arg0 = strip_float_extensions (TREE_OPERAND (expr, 0));
-	 tree arg1 = strip_float_extensions (TREE_OPERAND (expr, 1));
-
-	 if (FLOAT_TYPE_P (TREE_TYPE (arg0))
-		 && FLOAT_TYPE_P (TREE_TYPE (arg1))
-		 && DECIMAL_FLOAT_TYPE_P (itype) == DECIMAL_FLOAT_TYPE_P (type))
-	   {
-		  tree newtype = type;
-
-		  if (TYPE_MODE (TREE_TYPE (arg0)) == SDmode
-		  || TYPE_MODE (TREE_TYPE (arg1)) == SDmode
-		  || TYPE_MODE (type) == SDmode)
-		newtype = dfloat32_type_node;
-		  if (TYPE_MODE (TREE_TYPE (arg0)) == DDmode
-		  || TYPE_MODE (TREE_TYPE (arg1)) == DDmode
-		  || TYPE_MODE (type) == DDmode)
-		newtype = dfloat64_type_node;
-		  if (TYPE_MODE (TREE_TYPE (arg0)) == TDmode
-		  || TYPE_MODE (TREE_TYPE (arg1)) == TDmode
-		  || TYPE_MODE (type) == TDmode)
-newtype = dfloat128_type_node;
-		  if (newtype == dfloat32_type_node
-		  || newtype == dfloat64_type_node
-		  || newtype == dfloat128_type_node)
-		{
-		  expr = build2 (TREE_CODE (expr), newtype,
- convert_to_real_1 (newtype, arg0,
-			fold_p),
- convert_to_real_1 (newtype, arg1,
-			fold_p));
-		  if (newtype == type)
-			return expr;
-		  break;
-		}
-
-		  if (TYPE_PRECISION (TREE_TYPE (arg0)) > TYPE_PRECISION (newtype))
-		newtype = TREE_TYPE (arg0);
-		  if (TYPE_PRECISION (TREE_TYPE (arg1)) > TYPE_PRECISION (newtype))
-		newtype = TREE_TYPE (arg1);
-		  /* Sometimes this transformation is safe (cannot
-		 change results through affecting double rounding
-		 cases) and sometimes it is not.  If NEWTYPE is
-		 wider than TYPE, e.g. (float)((long double)double
-		 + (long double)double) converted to
-		 (float)(double + double), the transformation is
-		 unsafe regardless of the details of the types
-		 involved; double rounding can arise if the result
-		 of NEWTYPE arithmetic is a NEWTYPE value half way
-		 between two representable TYPE values but the
-		 exact value is sufficiently different (in the
-		 right direction) for this difference to be
-		 visible in ITYPE arithmetic.  If NEWTYPE is the
-		 same as TYPE, however, the transformation may be
-		 safe depending on the types involved: it is safe
-		 if the ITYPE has strictly more than twice as many
-		 mantissa bits as TYPE, can represent infinities
-		 and NaNs if the TYPE can, and has sufficient
-		 exponent range for the product or ratio of two
-		 values representable in the TYPE to be within the
-		 range of normal values of ITYPE.  */
-		  if (TYPE_PRECISION (newtype) < TYPE_PRECISION (itype)
-		  && (flag_unsaf

Re: [Fortran, test case, committed] Test case for PR 48543

[Thomas Koenig]

Am 03.01.19 um 23:18 schrieb Jakub Jelinek:

On Thu, Jan 03, 2019 at 01:36:30PM +0100, Thomas Koenig wrote:

Hi Jakub,


In any case, IMHO the test should be removed or XFAILed for now.


thanks for your explanations. I have removed the test case.


You've actually removed a different testcase (which was working fine),
while the ChangeLog says const_character_merge.f90 has been removed,
you've removed merge_char_const.f90.


Ah, censored (to quote Larry Niven).

Fixed.

Thanks for the heads-up!

Regards

Thomas

Re: [PATCH][GCC][Aarch64] Change expected bfxil count in gcc.target/aarch64/combine_bfxil.c to 18 (PR/87763)

[Sam Tebbs]

On 12/19/18 4:47 PM, Sam Tebbs wrote:

> Hi all,
>
> Since r265398 (combine: Do not combine moves from hard registers), the bfxil
> scan in gcc.target/aarch64/combine_bfxil.c has been failing.
>
> FAIL: gcc.target/aarch64/combine_bfxil.c scan-assembler-times bfxil\\t 13
>
> This is because bfi was generated for the combine_* functions in the
> above test,
> but as of r265398, bfxil is preferred over bfi and so the bfxil count has
> increased. This patch increases the scan count to 18 to account for this so
> that the test passes.
>
> Before r265398
>
> combine_zero_extended_int:
>       bfxil   x0, x1, 0, 16
>       ret
>
> combine_balanced:
>       bfi x0, x1, 0, 32
>       ret
>
> combine_minimal:
>       bfi x0, x1, 0, 1
>       ret
>
> combine_unbalanced:
>       bfi x0, x1, 0, 24
>       ret
>
> combine_balanced_int:
>       bfi w0, w1, 0, 16
>       ret
>
> combine_unbalanced_int:
>       bfi w0, w1, 0, 8
>       ret
>
> With r265398
>
> combine_zero_extended_int:
>       bfxil   x0, x1, 0, 16
>       ret
>
> combine_balanced:
>       bfxil   x0, x1, 0, 32
>       ret
>
> combine_minimal:
>       bfxil   x0, x1, 0, 1
>       ret
>
> combine_unbalanced:
>       bfxil   x0, x1, 0, 24
>       ret
>
> combine_balanced_int:
>       bfxil   w0, w1, 0, 16
>       ret
>
> combine_unbalanced_int:
>       bfxil   w0, w1, 0, 8
>       ret
>
> These bfxil and bfi invocations are equivalent, so this patch won't hide any
> incorrect code-gen.
>
> Bootstrapped on aarch64-none-linux-gnu and regression tested on
> aarch64-none-elf with no regressions.
>
> OK for trunk?
>
> gcc/testsuite/Changelog:
>
> 2018-12-19  Sam Tebbs  
>
>       * gcc.target/aarch64/combine_bfxil.c: Change
> scan-assembler-times bfxil count to 18.
ping

Re: [PATCH] x86-64: {,V}CVTSI2Sx are ambiguous without suffix

[Uros Bizjak]

On Fri, Jan 4, 2019 at 9:28 AM Jan Beulich  wrote:
>
> >>> On 21.12.18 at 14:55,  wrote:
> > On Fri, Dec 21, 2018 at 9:08 AM Jan Beulich  wrote:
> >>
> >> For 64-bit these should not be emitted without suffix in AT&T mode (as
> >> being ambiguous that way); the suffixes are benign for 32-bit. For
> >> consistency also omit the suffix in Intel mode for {,V}CVTSI2SxQ.
> >>
> >> The omission has originally (prior to rev 260691) lead to wrong code
> >> being generated for the 64-bit unsigned-to-float/double conversions (as
> >> gas guesses an L suffix instead of the required Q one when the operand
> >> is in memory). In all remaining cases (being changed here) the omission
> >> would "just" lead to warnings with future gas versions.
> >>
> >> Since rex64suffix so far has been used also on {,V}CVTSx2SI (but
> >> not on VCVTSx2USI, as gas doesn't permit suffixes there), testsuite
> >> adjustments are also necessary for their test cases. Rather than
> >> making thinks check for the L suffixes in 32-bit cases, make things
> >> symmetric with VCVTSx2USI and drop the redundant suffixes instead,
> >> dropping the Q suffix expectations at the same time from the 64-bit
> >> cases.
> >
> > This diverges from established practice, where all instructions have
> > suffixes in ATT  dialect. I think that we should to continue to follow
> > established convention (that found a couple of bugs in the past), so I
> > think that "l" should be emitted where appropriate. I wonder if gas
> > should be fixed to accept suffixes for VCVTSx2USI.
>
> I did wonder too (a long while ago), but H.J. is strictly objecting to
> making things consistent there.
>
> > For now, let's leave all suffixes, but skip problematic VCVTSx2USI.
>
> Hmm, I've checked some older gas versions, and it looks like
> they all accept rex64suffix on the 2si conversions, even for 32-bit
> code, so I guess retaining rex64suffix there despite the change to
> its definition ought to be fine.
>
> >> In order for related test cases to actually test what they're supposed
> >> to test, add (seemingly unrelated) a few empty "asm volatile()".
> >> Presumably there are more where constant propagation voids the intended
> >> effect of the tests, but these are ones helping make sure the assembler
> >> actually still assembles correctly the output after the changes here.
> >
> > Please just make relevant variable volatile. There are plenty of
> > examples in the i386 target testsuite.
>
> I've seen that, but considering it bad practice I didn't follow that
> model. I've similarly found examples of asm() use as done here,
> so I thought both would be okay, and I've picked the variant
> being better practice imo. Please clarify if you insist on making
> the change. Use of volatile has - iirc - the undesirable side
> effect of the compiler emitting VMOV* for the memory accesses,
> instead of using the instruction of interest with memory operands
> (which, considering the suffix aspect here, is one of the things to
> test here).

Well, I don't want to bikeshed too much here, my only intention was to
prevent the introduction of yet another approach. If you think that
asm is better here, I'm also OK with your choice, especially since the
proposed approach is also already in widespread use in the testsuite.

Uros.

Re: [PATCH] x86-64: {,V}CVTSI2Sx are ambiguous without suffix

[Jan Beulich]

>>> On 21.12.18 at 14:55,  wrote:
> On Fri, Dec 21, 2018 at 9:08 AM Jan Beulich  wrote:
>>
>> For 64-bit these should not be emitted without suffix in AT&T mode (as
>> being ambiguous that way); the suffixes are benign for 32-bit. For
>> consistency also omit the suffix in Intel mode for {,V}CVTSI2SxQ.
>>
>> The omission has originally (prior to rev 260691) lead to wrong code
>> being generated for the 64-bit unsigned-to-float/double conversions (as
>> gas guesses an L suffix instead of the required Q one when the operand
>> is in memory). In all remaining cases (being changed here) the omission
>> would "just" lead to warnings with future gas versions.
>>
>> Since rex64suffix so far has been used also on {,V}CVTSx2SI (but
>> not on VCVTSx2USI, as gas doesn't permit suffixes there), testsuite
>> adjustments are also necessary for their test cases. Rather than
>> making thinks check for the L suffixes in 32-bit cases, make things
>> symmetric with VCVTSx2USI and drop the redundant suffixes instead,
>> dropping the Q suffix expectations at the same time from the 64-bit
>> cases.
> 
> This diverges from established practice, where all instructions have
> suffixes in ATT  dialect. I think that we should to continue to follow
> established convention (that found a couple of bugs in the past), so I
> think that "l" should be emitted where appropriate. I wonder if gas
> should be fixed to accept suffixes for VCVTSx2USI.

I did wonder too (a long while ago), but H.J. is strictly objecting to
making things consistent there.

> For now, let's leave all suffixes, but skip problematic VCVTSx2USI.

Hmm, I've checked some older gas versions, and it looks like
they all accept rex64suffix on the 2si conversions, even for 32-bit
code, so I guess retaining rex64suffix there despite the change to
its definition ought to be fine.

>> In order for related test cases to actually test what they're supposed
>> to test, add (seemingly unrelated) a few empty "asm volatile()".
>> Presumably there are more where constant propagation voids the intended
>> effect of the tests, but these are ones helping make sure the assembler
>> actually still assembles correctly the output after the changes here.
> 
> Please just make relevant variable volatile. There are plenty of
> examples in the i386 target testsuite.

I've seen that, but considering it bad practice I didn't follow that
model. I've similarly found examples of asm() use as done here,
so I thought both would be okay, and I've picked the variant
being better practice imo. Please clarify if you insist on making
the change. Use of volatile has - iirc - the undesirable side
effect of the compiler emitting VMOV* for the memory accesses,
instead of using the instruction of interest with memory operands
(which, considering the suffix aspect here, is one of the things to
test here).

Jan