Re: [PATCH] Add fields to struct gomp_thread for debugging purposes

[Jakub Jelinek]

On Mon, Oct 30, 2017 at 04:06:15PM -0700, Kevin Buettner wrote:
> This patch adds a new member named "pthread_id" to the gomp_thread
> struct.  It is initialized in team.c.

That part is reasonable, though it is unclear how the debugger will
query it (through OMPD, or through hardcoded name lookup of the struct and
field in libgomp's debug info, something else).  But the field certainly
has to be guarded by #ifdef LIBGOMP_USE_PTHREADS, otherwise it will break
NVPTX offloading or any other pthread-less libgomp ports.
Another question is exact placement of the field, struct gomp_thread
vs. struct gomp_team_state etc.  Maybe it is ok, as the pthread_id is
the same once the thread is created, doesn't change when we create more
levels.

> It also adds a field named "parent" which is initialized to the thread
> which created the thread in question.  For non-nested parallel
> regions, this is always the master thread.

What do you need it for and why isn't the current way of querying
parent (see e.g. omp_get_ancestor_thread_num or omp_get_team_size)
sufficient for the debugger?  Even if gomp_team_state doesn't contain
pthread_id, perhaps it would be more space and performance efficient
to store some pointer into struct gomp_team, gomp_team_state/gomp_thread
structs are in TLS which should be kept as small as possible.
Why do you care about which thread called pthread_create, rather than
what actually owns it right now (is the master thread)?

Jakub

Re: [PATCH 1/2] [i386] PR82002 Part 1: Correct ICE caused by wrong calculation.

[Uros Bizjak]

On Tue, Oct 31, 2017 at 3:09 AM, Daniel Santos  wrote:
> This is a residual problem caused by the off-by-one error in sp_valid_at
> and fp_valid_at originally corrected in r252099.  However, adding tests
> that include an ms_abi to sysv_abi call reveals an additional, more
> complex problem with an invalid INSN due to overflowing the s32 offset.
> Therefore I'm including all new tests, but marking ones that are broken
> by this additional problem as xfail and addressing that in the next
> patch.
>
> gcc:
> config/i386/i386.c (ix86_expand_epilogue): Correct stack
> calculation.
>
> gcc/testsuite:
> gcc.target/i386/pr82002-1.c: New test.
> gcc.target/i386/pr82002-2a.c: New xfail test.
> gcc.target/i386/pr82002-2b.c: New xfail test.

I'd rather see these two xfailed tests committed in the second part,
but  your approach is also OK.

OK for mainline.

Thanks,
Uros.

> Signed-off-by: Daniel Santos 
> ---
>  gcc/config/i386/i386.c |  2 +-
>  gcc/testsuite/gcc.target/i386/pr82002-1.c  | 12 
>  gcc/testsuite/gcc.target/i386/pr82002-2a.c | 14 ++
>  gcc/testsuite/gcc.target/i386/pr82002-2b.c | 14 ++
>  4 files changed, 41 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr82002-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr82002-2a.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr82002-2b.c
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 2de0dd0c283..83a07afb3e1 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -13812,7 +13812,7 @@ ix86_expand_epilogue (int style)
>  the stack pointer, if we will restore SSE regs via sp.  */
>if (TARGET_64BIT
>   && m->fs.sp_offset > 0x7fff
> - && sp_valid_at (frame.stack_realign_offset)
> + && sp_valid_at (frame.stack_realign_offset + 1)
>   && (frame.nsseregs + frame.nregs) != 0)
> {
>   pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
> diff --git a/gcc/testsuite/gcc.target/i386/pr82002-1.c 
> b/gcc/testsuite/gcc.target/i386/pr82002-1.c
> new file mode 100644
> index 000..86678a01992
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr82002-1.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target lp64 } } */
> +/* { dg-options "-Ofast -mstackrealign -mabi=ms" } */
> +
> +void a (char *);
> +void
> +b ()
> +{
> +  char c[100];
> +  c[1099511627776] = 'b';
> +  a (c);
> +  a (c);
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr82002-2a.c 
> b/gcc/testsuite/gcc.target/i386/pr82002-2a.c
> new file mode 100644
> index 000..bc85080ba8e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr82002-2a.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile { target lp64 } } */
> +/* { dg-options "-Ofast -mstackrealign -mabi=ms" } */
> +/* { dg-xfail-if "" { *-*-* }  } */
> +/* { dg-xfail-run-if "" { *-*-* }  } */
> +
> +void __attribute__((sysv_abi)) a (char *);
> +void
> +b ()
> +{
> +  char c[100];
> +  c[1099511627776] = 'b';
> +  a (c);
> +  a (c);
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr82002-2b.c 
> b/gcc/testsuite/gcc.target/i386/pr82002-2b.c
> new file mode 100644
> index 000..10e44cd7b1d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr82002-2b.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile { target lp64 } } */
> +/* { dg-options "-Ofast -mstackrealign -mabi=ms -mcall-ms2sysv-xlogues" } */
> +/* { dg-xfail-if "" { *-*-* }  } */
> +/* { dg-xfail-run-if "" { *-*-* }  } */
> +
> +void __attribute__((sysv_abi)) a (char *);
> +void
> +b ()
> +{
> +  char c[100];
> +  c[1099511627776] = 'b';
> +  a (c);
> +  a (c);
> +}
> --
> 2.14.3
>

Re: [PATCH 2/2] [i386] PR82002 Part 2: Correct non-immediate offset/invalid INSN

[Uros Bizjak]

On Tue, Oct 31, 2017 at 4:23 AM, Daniel Santos  wrote:
> On 10/30/2017 09:09 PM, Daniel Santos wrote:
>> 3. Modify choose_baseaddr to take an optional scratch_regno argument
>>and never return rtx that cannot be used as an immediate.
>
> I should amend this, it actually does a gcc_assert, so that won't happen
> if --enable-checking=no, but it would still fail later in expand.

This is the intention of --enable-checking, so no worries here.

Uros.

[PATCH v2] Fix Incorrect ASan global variables alignment on arm (PR sanitizer/81697)

[Maxim Ostapenko]

Hi,

this is the second attempt to fix PR sanitizer/81697.

For architectures that use section anchors there is a problem with 
asan_protect_global because it's involved in a circular dependency:
1) categorize_decl_for_section calls asan_protect_global that returns 
false because DECL_RTL is not set at this point and assigns decl to 
SECCAT_RODATA_MERGE_CONST section.

2) make_decl_rtl sets up SET_DECL_RTL (decl, x).
3) Following asan_protect_global calls (e.g. from asan_finish_file) will 
return true and we end up with mismatch between section and alignment 
requirements.


Previous patch 
(https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00569.html) just disabled 
section anchors if ASan is enabled, but it was rejected.
This patch just introduces an additional ignore_decl_rtl_set_p parameter 
for asan_protect_global to break dependence mentioned above.


Tested on arm-linux-gnueabi, ppc64-unknown-linux-gnu and x86{, 
_64}-linux-gnu, bootstrapped on x86_64-unknown-linux-gnu.


-Maxim
gcc/ChangeLog:

2017-10-31  Maxim Ostapenko  

	PR sanitizer/81697
	* asan.c (asan_protect_global): Add new ignore_decl_rtl_set_p
	parameter. Return true if ignore_decl_rtl_set_p is true and other
	conditions are satisfied.
	* asan.h (asan_protect_global): Add new parameter.
	* varasm.c (categorize_decl_for_section): Pass true as second parameter
	to asan_protect_global calls.

gcc/testsuite/ChangeLog:

2017-10-31  Maxim Ostapenko  

	PR sanitizer/81697
	* g++.dg/asan/global-alignment.C: New test.

diff --git a/gcc/asan.c b/gcc/asan.c
index d5128aa..78c3b60 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1605,7 +1605,7 @@ is_odr_indicator (tree decl)
ASAN_RED_ZONE_SIZE bytes.  */
 
 bool
-asan_protect_global (tree decl)
+asan_protect_global (tree decl, bool ignore_decl_rtl_set_p)
 {
   if (!ASAN_GLOBALS)
 return false;
@@ -1627,7 +1627,13 @@ asan_protect_global (tree decl)
   || DECL_THREAD_LOCAL_P (decl)
   /* Externs will be protected elsewhere.  */
   || DECL_EXTERNAL (decl)
-  || !DECL_RTL_SET_P (decl)
+  /* PR sanitizer/81697: For architectures that use section anchors first
+	 call to asan_protect_global may occur before DECL_RTL (decl) is set.
+	 We should ignore DECL_RTL_SET_P then, because otherwise the first call
+	 to asan_protect_global will return FALSE and the following calls on the
+	 same decl after setting DECL_RTL (decl) will return TRUE and we'll end
+	 up with inconsistency at runtime.  */
+  || (!DECL_RTL_SET_P (decl) && !ignore_decl_rtl_set_p)
   /* Comdat vars pose an ABI problem, we can't know if
 	 the var that is selected by the linker will have
 	 padding or not.  */
@@ -1651,6 +1657,9 @@ asan_protect_global (tree decl)
   || is_odr_indicator (decl))
 return false;
 
+  if (ignore_decl_rtl_set_p)
+return true;
+
   rtl = DECL_RTL (decl);
   if (!MEM_P (rtl) || GET_CODE (XEXP (rtl, 0)) != SYMBOL_REF)
 return false;
diff --git a/gcc/asan.h b/gcc/asan.h
index c82d4d9..885b47e 100644
--- a/gcc/asan.h
+++ b/gcc/asan.h
@@ -26,7 +26,7 @@ extern void asan_finish_file (void);
 extern rtx_insn *asan_emit_stack_protection (rtx, rtx, unsigned int,
 	 HOST_WIDE_INT *, tree *, int);
 extern rtx_insn *asan_emit_allocas_unpoison (rtx, rtx, rtx_insn *);
-extern bool asan_protect_global (tree);
+extern bool asan_protect_global (tree, bool ignore_decl_rtl_set_p = false);
 extern void initialize_sanitizer_builtins (void);
 extern tree asan_dynamic_init_call (bool);
 extern bool asan_expand_check_ifn (gimple_stmt_iterator *, bool);
diff --git a/gcc/testsuite/g++.dg/asan/global-alignment.C b/gcc/testsuite/g++.dg/asan/global-alignment.C
new file mode 100644
index 000..84dac37
--- /dev/null
+++ b/gcc/testsuite/g++.dg/asan/global-alignment.C
@@ -0,0 +1,18 @@
+/* { dg-options "-fmerge-all-constants" } */
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
+
+#include 
+#include 
+
+const char kRecoveryInstallString[] = "NEW";
+const char kRecoveryUpdateString[] = "UPDATE";
+const char kRecoveryUninstallationString[] = "UNINSTALL";
+
+const std::map kStringToRequestMap = {
+  {kRecoveryInstallString, 0},
+  {kRecoveryUpdateString, 0},
+  {kRecoveryUninstallationString, 0},
+};
+
+/* { dg-final { scan-assembler-times {\.section\s+\.rodata\n(?:(?!\.section).)*\.\w+\s+"NEW} 1 } } */
diff --git a/gcc/varasm.c b/gcc/varasm.c
index a139151..849eae0 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -6508,7 +6508,7 @@ categorize_decl_for_section (const_tree decl, int reloc)
   else if (TREE_CODE (decl) == STRING_CST)
 {
   if ((flag_sanitize & SANITIZE_ADDRESS)
-	  && asan_protect_global (CONST_CAST_TREE (decl)))
+	  && asan_protect_global (CONST_CAST_TREE (decl), true))
   /* or !flag_merge_constants */
 return SECCAT_RODATA;
   else
@@ -6536,7 +6536,7 @@ categorize_decl_for_section (const_tree decl, int reloc)
 	ret = reloc == 1 ? SECCAT_DATA_REL_RO_LOCAL : SECCAT_DATA_REL_RO;
   else if (reloc || flag_merge_constants < 2
 

Re: [PATCH, Makefile] improve libsubdir variable transmission to sub-makes on Windows

[Olivier Hainque]

> On Oct 31, 2017, at 00:07 , Jeff Law  wrote:

>>  * Makefile.in (FLAGS_TO_PASS): Add libsubdir.
> OK.

:-) Thanks Jeff!

Re: [PATCH][compare-elim] Fix PR rtl-optimization/82597

[Jakub Jelinek]

On Fri, Oct 20, 2017 at 04:10:15AM +, Michael Collison wrote:
> This patch fixes an ICE on x86 because we were not constraining the operands
> of a recognized insn. Bootstrapped and tested on aarch64-none-linux-gnu and 
> x86_64.
> 
> Also successfully compiled the failing test cases in 82597 and duplicate 
> 82592.
> 
> Ok for trunk?
> 
> 2017-10-18  Michael Collison  
> 
>   PR rtl-optimization/82597
>   * compare-elim.c: (try_validate_parallel): Constrain operands
>   of recognized insn.

That just duplicates more of insn_invalid_p.
I wonder if we don't want to do something like the following instead
(untested so far).  The insn_uid decrement and ggc_free can be left out if
deemed unnecessary, I don't have an idea how many try_validate_parallel
calls fail in real-world.

More importantly, I still don't really like the
  df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN);
part of the earlier changes, that is very expensive and I doubt it is really
necessary.  You only use the UD/DU chains to find from the comparison insn
the previous setter of the in_a in the same basic block (if any), but you
walk before that the basic block from HEAD to END in
find_comparison_dom_walker::before_dom_children.  So, wouldn't it be cheaper
to track during that walk the last setter insn of each hard register e.g. in an
array indexed by REGNO (or perhaps track only selected simple single_set
arith instructions) and remember for comparisons of a hard reg with
const0_rtx in struct comparison next to prev_clobber field also the
reg_setter?  After all, that is the way prev_clobber is computed, except
in that case it is just a single register (CC) we track it for.
For many targets that is all we need (if all the arith instructions clobber
flags), on say x86_64/i686 there are only very few exceptions (e.g. lea, but
that is typically used in a way that makes it impossible to merge).
On others such as aarch64 (or arm or both?) not, so we need to track more.

The pass has other weirdnesses, e.g. for each insn:
  /* Compute the set of registers modified by this instruction.  */
  bitmap_clear (killed);
  df_simulate_find_defs (insn, killed);
...
  /* Notice if this instruction kills the flags register.  */
  if (bitmap_bit_p (killed, targetm.flags_regnum))
{
Given df_simulate_find_defs is:
  df_ref def;
 
  FOR_EACH_INSN_DEF (def, insn)
bitmap_set_bit (defs, DF_REF_REGNO (def));
this is quite expensive way of doing this with a completely useless bitmap.
If we throw away the first two stmts and replace bitmap_bit_p with:
  df_ref def;
  FOR_EACH_INSN_DEF (def, insn)
if (DF_REF_REGNO (def) == targetm.flags_regnum)
  {
...
break;
we'll save all the bitmap handling.

2017-10-31  Jakub Jelinek  

PR rtl-optimization/82778
* compare-elim.c (try_validate_parallel): Use insn_invalid_p instead of
recog_memoized.  Return insn rather than just the pattern.

* g++.dg/opt/pr82778.C: New test.

--- gcc/compare-elim.c.jj   2017-10-19 09:08:17.0 +0200
+++ gcc/compare-elim.c  2017-10-31 09:39:26.936696234 +0100
@@ -625,13 +625,18 @@ can_merge_compare_into_arith (rtx_insn *
 static rtx
 try_validate_parallel (rtx set_a, rtx set_b)
 {
-  rtx par
-= gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, set_a, set_b));
+  rtx par = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, set_a, set_b));
+  rtx_insn *insn = make_insn_raw (par);
 
-  rtx_insn *insn;
-  insn = gen_rtx_INSN (VOIDmode, 0, 0, 0, par, 0, -1, 0);
+  if (insn_invalid_p (insn, false))
+{
+  crtl->emit.x_cur_insn_uid--;
+  ggc_free (insn);
+  ggc_free (par);
+  return NULL_RTX;
+}
 
-  return recog_memoized (insn) > 0 ? par : NULL_RTX;
+  return insn;
 }
 
 /* For a comparison instruction described by CMP check if it compares a
@@ -711,7 +716,7 @@ try_merge_compare (struct comparison *cm
 }
   if (!apply_change_group ())
 return false;
-  emit_insn_after (par, def_insn);
+  emit_insn_after_setloc (par, def_insn, INSN_LOCATION (def_insn));
   delete_insn (def_insn);
   delete_insn (cmp->insn);
   return true;
--- gcc/testsuite/g++.dg/opt/pr82778.C.jj   2017-10-31 09:01:25.025934660 
+0100
+++ gcc/testsuite/g++.dg/opt/pr82778.C  2017-10-31 09:00:08.0 +0100
@@ -0,0 +1,37 @@
+// PR rtl-optimization/82778
+// { dg-do compile }
+// { dg-options "-O2" }
+
+template  struct c {
+  typedef a d[b];
+  static a e(d f, int g) { return f[g]; }
+};
+template  struct B {
+  typedef c h;
+  typename h::d i;
+  long j;
+  a at() { return h::e(i, j); }
+};
+int k, m, r, s, t;
+char l, n, q;
+short o, p, w;
+struct C {
+  int u;
+};
+B v;
+void x() {
+  if (((p > (q ? v.at().u : k)) >> l - 226) + !(n ^ r * m))
+s = ((-(((p > (q ? v.at().u : k)) >> l - 226) + !(n ^ r * m)) < 0) /
+ (-(((p > (q ? v.at().u : k)) >> l - 226) + !(n ^ r * m)) ^
+  -25 & o) &&
+ p) >>
+(0 <= 0
+ ? 0 ||
+  

Re: [PATCH 2/2] [i386] PR82002 Part 2: Correct non-immediate offset/invalid INSN

[Uros Bizjak]

On Tue, Oct 31, 2017 at 3:09 AM, Daniel Santos  wrote:
> When we are realigning the stack pointer, making an ms_abi to sysv_abi
> call and alllocating 2GiB or more on the stack we end up with an invalid
> INSN due to a non-immediate offset.  This occurs both with and without
> -mcall-ms2sysv-xlogues.  Additionally, I've discovered that the stack
> allocation with -mcall-ms2sysv-xlogues is incorrect as it ignores stack
> checking, stack clash checking and probing.
>
> This patch fixes these problems by
>
> 1. No longer allocate stack space in ix86_emit_outlined_ms2sysv_save.
> 2. Rearrange where we emit SSE saves or stub call:
>a. Before frame allocation when offset from frame to save area is >= 2GiB.
>b. After frame allocation when frame is < 2GiB.  (Stack allocations
>   prior to the stub call can't be combined with those afterwards, so
>   this is better when possible.)
> 3. Modify choose_baseaddr to take an optional scratch_regno argument
>and never return rtx that cannot be used as an immediate.
>
> gcc:
> config/i386/i386.c (choose_basereg): Use optional scratch
> register and add assertion.
> (x86_emit_outlined_ms2sysv_save): use scratch register when
> needed, and don't allocate stack.
> (ix86_expand_prologue): Rearrange where SSE saves/stub call is
> emitted, correct wrong allocation with -mcall-ms2sysv-xlogues.
> (ix86_emit_outlined_ms2sysv_restore): Fix non-immediate offsets.
>
> gcc/testsuite:
> gcc.target/i386/pr82002-2a.c: Change from xfail to fail.
> gcc.target/i386/pr82002-2b.c: Likewise.
>
> Signed-off-by: Daniel Santos 
> ---
>  gcc/config/i386/i386.c | 76 
> --
>  gcc/testsuite/gcc.target/i386/pr82002-2a.c |  2 -
>  gcc/testsuite/gcc.target/i386/pr82002-2b.c |  2 -
>  3 files changed, 62 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 83a07afb3e1..abd8e937e0d 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -11520,7 +11520,8 @@ choose_basereg (HOST_WIDE_INT cfa_offset, rtx 
> &base_reg,
> The valid base registers are taken from CFUN->MACHINE->FS.  */
>
>  static rtx
> -choose_baseaddr (HOST_WIDE_INT cfa_offset, unsigned int *align)
> +choose_baseaddr (HOST_WIDE_INT cfa_offset, unsigned int *align,
> +int scratch_regno = -1)
>  {
>rtx base_reg = NULL;
>HOST_WIDE_INT base_offset = 0;
> @@ -11534,6 +11535,28 @@ choose_baseaddr (HOST_WIDE_INT cfa_offset, unsigned 
> int *align)
>  choose_basereg (cfa_offset, base_reg, base_offset, 0, align);
>
>gcc_assert (base_reg != NULL);
> +
> +  if (TARGET_64BIT)
> +{
> +  rtx base_offset_rtx = GEN_INT (base_offset);
> +
> +  if (scratch_regno >= 0)
> +   {
> + if (!x86_64_immediate_operand (base_offset_rtx, DImode))
> +   {
> + rtx tmp;
> + rtx scratch_reg = gen_rtx_REG (DImode, scratch_regno);
> +
> + emit_insn (gen_rtx_SET (scratch_reg, base_offset_rtx));
> + tmp = gen_rtx_PLUS (DImode, scratch_reg, base_reg);
> + emit_insn (gen_rtx_SET (scratch_reg, tmp));
> + return scratch_reg;
> +   }
> +   }
> +  else
> +   gcc_assert (x86_64_immediate_operand (base_offset_rtx, DImode));
> +}
> +
>return plus_constant (Pmode, base_reg, base_offset);
>  }

This function doesn't need to return a register, it can return plus
RTX. I'd suggest the following implementation:

--cut here--
Index: i386.c
===
--- i386.c  (revision 254243)
+++ i386.c  (working copy)
@@ -11520,7 +11520,8 @@
The valid base registers are taken from CFUN->MACHINE->FS.  */

 static rtx
-choose_baseaddr (HOST_WIDE_INT cfa_offset, unsigned int *align)
+choose_baseaddr (HOST_WIDE_INT cfa_offset, unsigned int *align,
+unsigned int scratch_regno = INVALID_REGNUM)
 {
   rtx base_reg = NULL;
   HOST_WIDE_INT base_offset = 0;
@@ -11534,6 +11535,19 @@
 choose_basereg (cfa_offset, base_reg, base_offset, 0, align);

   gcc_assert (base_reg != NULL);
+
+  rtx base_offset_rtx = GEN_INT (base_offset);
+
+  if (!x86_64_immediate_operand (base_offset_rtx, Pmode))
+{
+  gcc_assert (scratch_regno != INVALID_REGNUM);
+
+  rtx scratch_reg = gen_rtx_REG (Pmode, scratch_regno);
+  emit_move_insn (scratch_reg, base_offset_rtx);
+
+  return gen_rtx_PLUS (Pmode, base_reg, scratch_reg);
+}
+
   return plus_constant (Pmode, base_reg, base_offset);
 }

--cut here--

You have to always return Pmode, otherwise x32 will complain (you may
try with -maddress-mode=short). Also, the above will immediately ICE
when too large base_offset is used without the scratch, so one can
backtrace to offending function.

> @@ -12793,23 +12816,22 @@ ix86_emit_outlined_ms2sysv_save (const struct 
> ix86_frame &frame)
>rtx sym, addr;
>rtx

[PATCH] rs6000: Fix crash with big stack clash interval (PR82674)

[Segher Boessenkool]

If the user asks for a stack clash probe interval of 64kB, we currently
generate a "stdu rX,-65536(r1)" instruction.  That instruction does not
exist (the offset is a 16-bit signed number).  If the offset is too big
we should force it into a register and generate a "stdux rX,rY,r1"
instruction, instead.

Bootstrapped and regression checked on powerpc64-linux {-m32,-m64};
committing to trunk.


Segher


2017-10-31  Segher Boessenkool  

PR target/82674
* config/rs6000/rs6000.md (allocate_stack): Force update interval
into a register if it does not fit into an immediate offset field.

---
 gcc/config/rs6000/rs6000.md | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 62bd19b..18ebe8f 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -10333,6 +10333,9 @@ (define_expand "allocate_stack"
{
  rtx loop_lab, end_loop;
  bool rotated = CONST_INT_P (rounded_size);
+ rtx update = GEN_INT (-probe_interval);
+ if (probe_interval > 32768)
+   update = force_reg (Pmode, update);
 
  emit_stack_clash_protection_probe_loop_start (&loop_lab, &end_loop,
last_addr, rotated);
@@ -10340,13 +10343,11 @@ (define_expand "allocate_stack"
  if (Pmode == SImode)
emit_insn (gen_movsi_update_stack (stack_pointer_rtx,
   stack_pointer_rtx,
-  GEN_INT (-probe_interval),
-  chain));
+  update, chain));
  else
emit_insn (gen_movdi_di_update_stack (stack_pointer_rtx,
  stack_pointer_rtx,
- GEN_INT (-probe_interval),
- chain));
+ update, chain));
  emit_stack_clash_protection_probe_loop_end (loop_lab, end_loop,
  last_addr, rotated);
}
-- 
1.8.3.1

[C++ Patch] PR 81957 ("ICE decltype")

[Paolo Carlini]

Hi,

this ICE on valid seems rather easy to fix, one of those bugs where we 
aren't propagating the tsubst_flags_t argument. In this case, we aren't 
propagating from tsubst_pack_expansion to make_pack_expansion. Doing it, 
fixes the ICE and we actually accept the code as we should. In general, 
make_pack_expansion is also called from many other places, eg, the 
parser, thus I'm using a default tf_warning_or_error for it. Similarly 
to other past fixes, I ended up adding tsubst_flags_t parameters to a 
few other functions in pt.c, eg template_parms_to_args, which eventually 
use make_pack_expansion without propagating.


There are a couple of places where I'm proposing passing a /tf_none/ to 
template_parms_to_args: is_compatible_template_arg, which is currently 
calling template_parms_to_args and passing the result together with a 
tf_none to tsubst_constraint_info; convert_generic_types_to_packs, which 
is currently calling template_parms_to_args and passing the result (via 
add_to_template_args) together with tf_none to tsubst. Of course the 
"conservative" choice would be instead passing tf_warning_or_error.


Tested x86_64-linux.

Thanks, Paolo.

//

/cp
2017-10-31  Paolo Carlini  

PR c++/81957
* pt.c (make_pack_expansion): Add tsubst_flags_t parameter.
(template_parm_to_arg): Likewise.
(template_parms_level_to_args): Likewise.
(template_parms_to_args): Likewise.
(current_template_args): Likewise.
(get_underlying_template): Likewise.
(expand_integer_pack, template_parm_to_arg,
template_parms_level_to_args, template_parms_to_args,
current_template_args, add_inherited_template_parms,
get_underlying_template, coerce_template_args_for_ttp,
coerce_template_template_parms, is_compatible_template_arg,
convert_template_argument, coerce_template_parms,
lookup_template_class_1, tsubst_pack_expansion, tsubst_template_decl,
unify, rewrite_template_parm, build_deduction_guide,
do_auto_deduction, convert_generic_types_to_packs): Adjust calls.
* tree.c (cp_build_qualified_type_real): Likewise.
* constraint.cc (finish_shorthand_constraint,
finish_template_introduction): Likewise.
* cp-tree.h (make_pack_expansion, template_parm_to_arg): Adjust
declarations.

/testsuite
2017-10-31  Paolo Carlini  

PR c++/81957
* g++.dg/cpp0x/variadic-crash5.C: New.
Index: cp/constraint.cc
===
--- cp/constraint.cc(revision 254249)
+++ cp/constraint.cc(working copy)
@@ -1272,7 +1272,8 @@ finish_shorthand_constraint (tree decl, tree const
 
   /* Get the argument and overload used for the requirement
  and adjust it if we're going to expand later.  */
-  tree arg = template_parm_to_arg (build_tree_list (NULL_TREE, decl));
+  tree arg = template_parm_to_arg (build_tree_list (NULL_TREE, decl),
+  tf_warning_or_error);
   if (apply_to_all_p)
 arg = PACK_EXPANSION_PATTERN (TREE_VEC_ELT (ARGUMENT_PACK_ARGS (arg), 0));
 
@@ -1420,7 +1421,8 @@ finish_template_introduction (tree tmpl_decl, tree
   for (; n < TREE_VEC_LENGTH (parm_list); ++n)
 {
   tree parm = TREE_VEC_ELT (parm_list, n);
-  TREE_VEC_ELT (check_args, n) = template_parm_to_arg (parm);
+  TREE_VEC_ELT (check_args, n)
+   = template_parm_to_arg (parm, tf_warning_or_error);
 }
   SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (check_args, n);
 
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 254249)
+++ cp/cp-tree.h(working copy)
@@ -6435,7 +6435,7 @@ extern bool uses_parameter_packs(t
 extern bool template_parameter_pack_p   (const_tree);
 extern bool function_parameter_pack_p  (const_tree);
 extern bool function_parameter_expanded_from_pack_p (tree, tree);
-extern tree make_pack_expansion (tree);
+extern tree make_pack_expansion (tree, tsubst_flags_t = 
tf_warning_or_error);
 extern bool check_for_bare_parameter_packs  (tree);
 extern tree build_template_info(tree, tree);
 extern tree get_template_info  (const_tree);
@@ -6517,7 +6517,7 @@ extern tree coerce_template_parms   (t
 extern void register_local_specialization   (tree, tree);
 extern tree retrieve_local_specialization   (tree);
 extern tree extract_fnparm_pack (tree, tree *);
-extern tree template_parm_to_arg(tree);
+extern tree template_parm_to_arg(tree, tsubst_flags_t);
 extern tree dguide_name(tree);
 extern bool dguide_name_p  (tree);
 extern bool deduction_guide_p  (const_tree);
Index: cp/pt.c
===
--- cp/pt

Re: [PATCH PR79868 ][aarch64] Fix error calls in aarch64 code so they can be translated (version 2)

[Richard Earnshaw (lists)]

On 30/10/17 20:50, Steve Ellcey wrote:
> On Thu, 2017-10-26 at 13:56 +0100, Richard Earnshaw (lists) wrote:
>>  
>> I can't help feeling that all this logic is somewhat excessive and
>> changing the wording of each message to include "pragma or attribute"
>> would solve it equally well.  With the new context highlighting it's
>> trivial to tell which subcase of usage is being referred to.
>>
>> R.
> 
> I have no problem with that.  Here is a version that uses "pragma or
> attribute".
> 
> Tested on ToT with no regressions.  Ok to checkin?
> 
> Steve Ellcey
> sell...@cavium.com
> 
> 
> 
> ChangeLog:
> 
> 2017-10-30  Steve Ellcey  
> 
>   PR target/79868
>   * config/aarch64/aarch64-c.c (aarch64_pragma_target_parse):
>   Remove second argument from aarch64_process_target_attr call.
>   * config/aarch64/aarch64-protos.h (aarch64_process_target_attr):
>   Ditto.
>   * config/aarch64/aarch64.c (aarch64_attribute_info): Change
>   field type.
>   (aarch64_handle_attr_arch): Remove second argument.
>   (aarch64_handle_attr_cpu): Ditto.
>   (aarch64_handle_attr_tune): Ditto.
>   (aarch64_handle_attr_isa_flags): Ditto.
>   (aarch64_process_one_target_attr): Ditto.
>   (aarch64_process_target_attr): Ditto.
>   (aarch64_option_valid_attribute_p): Remove second argument.
>   on aarch64_process_target_attr call.
> 
> 
> Testsuite ChangeLog:
> 
> 2017-10-30  Steve Ellcey  
> 
>   PR target/79868
>   * gcc.target/aarch64/spellcheck_1.c: Update dg-error string to match
>   new format.
>   * gcc.target/aarch64/spellcheck_2.c: Ditto.
>   * gcc.target/aarch64/spellcheck_3.c: Ditto.
>   * gcc.target/aarch64/target_attr_11.c: Ditto.
>   * gcc.target/aarch64/target_attr_12.c: Ditto.
>   * gcc.target/aarch64/target_attr_17.c: Ditto.
> 

This is looking better...

I may have missed some discussion on this topic, but what's the
reasoning behind changing the quoting around the 'str' parameter value in

-   error ("unknown value %qs for 'cpu' target %s", str, pragma_or_attr);
+   error ("invalid name (\"%s\") in % pragma or
attribute", str);

And also with the new generic message does the %
still make sense?  My feeling is that the original text here is perhaps
more appropriate.  Similarly for other messages.

R.

Re: [09/nn] Add a fixed_size_mode_pod class

[Trevor Saunders]

On Mon, Oct 30, 2017 at 11:11:12AM +0100, Eric Botcazou wrote:
> > It sounds like people are mostly concerned about sun studio and xlc? It
> > doesn't seem that hard to provide precompiled binaries for those two
> > platforms, and maybe 4.8 binaries for people who want to compile theire
> > own gcc from source.
> 
> I'm not sure that we want to enter the business of precompiled binaries.

I don't see a reason not to other than a pretty small amount of work
each time we make a release.

> Moreover, if we want people to contribute to GCC's development, especially 
> occasionally to fix a couple of bugs, we need to make it easier to build the 
> compiler, not the other way around.

Well first this would only matter to the 0.01% of people who want to do
that on AIX or Solaris machines, not the vast majority of possible
contributors who already use clang or gcc as there system compiler.
Secondly downloading a tarball isn't very difficult and arguably
providing them makes it easier for people to test gcc on those systems
without having to build it themselves.
Thirdly making it easier to work on the compiler and understand it makes
things easier for those possible contributors, so if being able to use
C++11 advances that goalthings could be better over all for possible
contributors with different system compilers.

Trev

> 
> -- 
> Eric Botcazou

[PATCH, alpha]: Fix PR 82772, could not split atomic_andsi insn

[Uros Bizjak]

The constraint for atomic_andsi didn't fit predicate.

2017-10-31  Uros Bizjak  

PR target/82772
* config/alpha/sync.md (fetchop_constr) : Change to "rINM".

Bootstrapped on alphaev68-linux-gnu, committed to mainline SVN and
release branches under obvious rule.

Uros.
Index: config/alpha/sync.md
===
--- config/alpha/sync.md(revision 254243)
+++ config/alpha/sync.md(working copy)
@@ -24,7 +24,7 @@
   [(plus "add_operand") (minus "reg_or_8bit_operand")
(ior "or_operand") (xor "or_operand") (and "and_operand")])
 (define_code_attr fetchop_constr
-  [(plus "rKL") (minus "rI") (ior "rIN") (xor "rIN") (and "riNM")])
+  [(plus "rKL") (minus "rI") (ior "rIN") (xor "rIN") (and "rINM")])
 
 
 (define_expand "memory_barrier"

Re: [PATCH][compare-elim] Fix PR rtl-optimization/82597

[Jakub Jelinek]

On Tue, Oct 31, 2017 at 10:35:59AM +0100, Jakub Jelinek wrote:
> > 2017-10-18  Michael Collison  
> > 
> > PR rtl-optimization/82597
> > * compare-elim.c: (try_validate_parallel): Constrain operands
> > of recognized insn.
> 
> That just duplicates more of insn_invalid_p.
> I wonder if we don't want to do something like the following instead
> (untested so far).  The insn_uid decrement and ggc_free can be left out if
> deemed unnecessary, I don't have an idea how many try_validate_parallel
> calls fail in real-world.
> 
> More importantly, I still don't really like the
>   df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN);
> part of the earlier changes, that is very expensive and I doubt it is really
> necessary.  You only use the UD/DU chains to find from the comparison insn
> the previous setter of the in_a in the same basic block (if any), but you
> walk before that the basic block from HEAD to END in
> find_comparison_dom_walker::before_dom_children.  So, wouldn't it be cheaper
> to track during that walk the last setter insn of each hard register e.g. in 
> an
> array indexed by REGNO (or perhaps track only selected simple single_set
> arith instructions) and remember for comparisons of a hard reg with
> const0_rtx in struct comparison next to prev_clobber field also the
> reg_setter?  After all, that is the way prev_clobber is computed, except
> in that case it is just a single register (CC) we track it for.
> For many targets that is all we need (if all the arith instructions clobber
> flags), on say x86_64/i686 there are only very few exceptions (e.g. lea, but
> that is typically used in a way that makes it impossible to merge).
> On others such as aarch64 (or arm or both?) not, so we need to track more.

Here is an untested patch (only tried the cmpelim_mult_uses_1.c testcase in
aarch64 cross) that does that.  I don't have aarch64 boxes around for easy
trunk testing, can bootstrap/regtest it on x86_64-linux/i686-linux and
maybe powerpc64le-linux though.

If the memset (last_setter, 0, sizeof (last_setter)); for each bb is a problem
(maybe for ia64/mmix/mips which have huge numbers of hard registers),
one possibility would be to put the array into find_comparison_dom_walker
class, clear it only in the constructor and have next to it an auto_vec
into which we'd push the REGNOs we've set last_setter to non-NULL where
previously they were NULL, then instead of clearing the whole vector we'd
just pop all the REGNOs from the vector and clear just those.
One extra advantage would be that we could also cheaply clear the
last_setter entries when seeing some following flags setter, user,
call/jump/asm_input (stuff that can_merge_compare_into_arith verifies).

2017-10-31  Jakub Jelinek  

PR rtl-optimization/82778
PR rtl-optimization/82597
* compare-elim.c (struct comparison): Add in_a_setter field.
(find_comparison_dom_walker::before_dom_children): Remove killed
bitmap and df_simulate_find_defs call, instead walk the defs.
Compute last_setter and initialize in_a_setter.  Merge definitions
with first initialization for a few variables.
(try_validate_parallel): Use insn_invalid_p instead of
recog_memoized.  Return insn rather than just the pattern.
(try_merge_compare): Fix up comment.  Don't uselessly test if
in_a is a REG_P.  Use cmp->in_a_setter instead of walking UD
chains.

* g++.dg/opt/pr82778.C: New test.

2017-10-31  Michael Collison  

PR rtl-optimization/82597
* gcc.dg/pr82597.c: New test.

--- gcc/compare-elim.c.jj   2017-10-19 09:08:17.0 +0200
+++ gcc/compare-elim.c  2017-10-31 11:37:29.430797609 +0100
@@ -97,6 +97,9 @@ struct comparison
   /* The insn prior to the comparison insn that clobbers the flags.  */
   rtx_insn *prev_clobber;
 
+  /* The insn prior to the comparison insn that sets in_a REG.  */
+  rtx_insn *in_a_setter;
+
   /* The two values being compared.  These will be either REGs or
  constants.  */
   rtx in_a, in_b;
@@ -309,26 +312,22 @@ can_eliminate_compare (rtx compare, rtx
 edge
 find_comparison_dom_walker::before_dom_children (basic_block bb)
 {
-  struct comparison *last_cmp;
-  rtx_insn *insn, *next, *last_clobber;
-  bool last_cmp_valid;
+  rtx_insn *insn, *next;
   bool need_purge = false;
-  bitmap killed;
-
-  killed = BITMAP_ALLOC (NULL);
+  rtx_insn *last_setter[FIRST_PSEUDO_REGISTER];
 
   /* The last comparison that was made.  Will be reset to NULL
  once the flags are clobbered.  */
-  last_cmp = NULL;
+  struct comparison *last_cmp = NULL;
 
   /* True iff the last comparison has not been clobbered, nor
  have its inputs.  Used to eliminate duplicate compares.  */
-  last_cmp_valid = false;
+  bool last_cmp_valid = false;
 
   /* The last insn that clobbered the flags, if that insn is of
  a form that may be valid for eliminating a following compare.
  To be reset to NULL once the flags are set otherwise.

Re: [PATCH 1/7] GCOV: document behavior of -fkeep-{static,inline}-functions (PR gcov-profile/82633).

[Martin Liška]

On 10/30/2017 01:15 PM, Nathan Sidwell wrote:

On 10/26/2017 04:11 AM, marxin wrote:

gcc/ChangeLog:



+++ b/gcc/doc/gcov.texi
@@ -327,6 +327,11 @@ non-exceptional paths or only exceptional paths such as 
C++ exception
  handlers, respectively. Given @samp{-a} option, unexecuted blocks are
  marked @samp{$} or @samp{%}, depending on whether a basic block
  is reachable via non-exceptional or exceptional paths.
+Note that GCC can perform function removal for functions obviously not
+used in a compilation unit.  Such functions are marked with @samp{-}
+even though they contain a code.  Use @option{-fkeep-inline-functions} and
+@option{-fkeep-static-functions} in order to properly
+record @var{execution_count} of such functions.


This reads a little oddly.  How about:

Note that GCC can completely remove the bodies of functions that are not needed 
-- for instance if they are inlined everywhere.  Such functions are marked with 
@samp{-}, which can be confusing.  Use the @option{-fkeep-inline-functions} and 
@option{-fkeep-static-functions} options to retain these functions and allow 
gcov to properly show their @var{execution_count}.


Hi.

Thanks for rewriting that. Native speakers always produce more readable 
documentation.
I'll install your version as it is.

Martin



Ok with that (or something approximating it).

nathan

Re: [PATCH 2/7] GCOV: introduce usage of terminal colors.

[Martin Liška]

On 10/30/2017 03:49 PM, David Malcolm wrote:

On Mon, 2017-10-30 at 08:17 -0400, Nathan Sidwell wrote:

On 10/26/2017 04:11 AM, marxin wrote:

I consider using colors in context of gcov as very useful. There's
example for tramp3d:
https://pste.eu/p/Tl2D.html


nice!


gcc/ChangeLog:

2017-10-23  Martin Liska  

* color-macros.h: New file.
* diagnostic-color.c: Factor out color related to macros to
color-macros.h.
* doc/gcov.texi: Document -k option.
* gcov.c (INCLUDE_STRING): Include string.h.
(print_usage): Add -k option.
(process_args): Parse it.
(pad_count_string): New function.
(output_line_beginning): Likewise.
(DEFAULT_LINE_START): New macro.
(output_lines): Support color output.


The gcov changes are ok.  I guess David has the review ball for the
diagnostic refactoring?

nathan


The comments beginning:
+/* Select Graphic Rendition (SGR, "\33[...m") strings.  */

and ending:
   It would be impractical for GCC to become a full-fledged
   terminal program linked against ncurses or the like, so it will
   not detect terminfo(5) capabilities.  */

are still in diagnostic-color.c after your patch, but they are
describing the macros, and in particular, if I'm reading them right,
are a rationale for why SGR_END contains a "\33[K".

Hence I think that those comments should also be moved to color-
macros.h.


Hi.

Will do that.



Other than that the diagnostic changes mostly look good to me, but the
color-macros.h has:
+   Copyright (C) 2017 Free Software Foundation, Inc.

Shouldn't that copyright line express the full range of years for the
existing content that's being moved from diagnostic-color.c?

The macros there were introduced by the creation of diagnostic-color.c
in r197842 in April 2013 (aka dc604d41825b3cbd09045baeef09b1b88fc5a02),
which had the copyright line:

+   Copyright 2011-2013 Free Software Foundation, Inc.


FWIW, the macros seem to come from this patch by Manu:
"RFC: color diagnostics markers"
   https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01365.html

where the code in question has:

/* Based on code from: */
+/* grep.c - main driver file for grep.
+   Copyright (C) 1992, 1997-2002, 2004-2013 Free Software Foundation,
Inc.

though as far as I can tell the only material taken directly from
"grep" are the comments I mentioned above beginning i.e. it appears to
me that the actual macros in the new file were written by Manu in 2013.

The comments mentioned above come from GNU grep; looking at the history
in grep's git repo shows it comes from commit
56623b5129d487cb6673fa5a582d094edc1fe983:

2005-06-20  Charles Levert  

* src/grep.c: Extensively document the SGR/EL-to-Right issue.

Hence I believe the color-macros.h copyright line should range from
2005-2017 if you move the comments (please do), or from 2013-2017 as-
is.


Thanks for clarification, 2005-2017 will be in final version of patch
I'm planning to install.

Martin



Diagnostic refactoring is OK otherwise.

Dave

Re: [PATCH 3/7] GCOV: add support for lines with an unexecuted lines.

[Martin Liška]

On 10/30/2017 01:21 PM, Nathan Sidwell wrote:


Looks good otherwise, WDYT?


Hi.

Works for me, it's more precise!

Thanks,
Martin



nathan

RE: [PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling, also needed asm files are updated.

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Friday, October 13, 2017 1:02 AM
> To: Joseph Myers 
> Cc: gcc-patches@gcc.gnu.org; Jeff Law ; i...@airs.com;
> Tsimbalist, Igor V 
> Subject: RE: [PATCH 07/22] Enable building libgcc with CET options.
> 
> > -Original Message-
> > From: Joseph Myers [mailto:jos...@codesourcery.com]
> > Sent: Thursday, October 12, 2017 10:36 PM
> > To: Tsimbalist, Igor V 
> > Cc: gcc-patches@gcc.gnu.org; Jeff Law ; i...@airs.com
> > Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
> >
> > On Thu, 12 Oct 2017, Tsimbalist, Igor V wrote:
> >
> > > Enable building libgcc with CET options by default on Linux/x86 if
> > > binutils supports CET v2.0.
> > > It can be disabled with --disable-cet.  It is an error to configure
> > > GCC with --enable-cet if bintuiils doesn't support CET v2.0.
> > >
> > > config/
> > >   * cet.m4: New file
> >
> > This file is checking $target.  That's only ever appropriate in directories
> > building compilers and similar tools; target library directories should 
> > check
> > $host, as the host for target libraries is the target for the compiler.
> 
> Fixed.
> 
> > This file has a comment
> >
> > > +dnl GCC_CET_LIBRARY
> > > +dnl(SHELL-CODE_HANDLER)
> >
> > which doesn't seem to match the subsequent definition of
> GCC_CET_FLAGS.
> 
> Fixed.
> 
> > I don't see any documentation of the new configure option.  I'd expect the
> > first patch adding such an option to document it in install.texi, and then
> > subsequent patches to update that documentation if those patches extend
> > the option to cover more things.
> 
> Added the description of this configure option to install.texi.
> 
> The updated patch is attached.
> 
> Igor
> 
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com


0007-Enable-building-libgcc-with-CET-options.patch
Description: 0007-Enable-building-libgcc-with-CET-options.patch

RE: [PATCH 09/22] Enable building libbacktrace with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling. -iclude option is dropped, each 
needed asm file is processed separately.

Igor


> -Original Message-
> From: Ian Lance Taylor [mailto:i...@airs.com]
> Sent: Friday, October 13, 2017 6:45 PM
> To: Tsimbalist, Igor V 
> Cc: gcc-patches@gcc.gnu.org; Jeff Law 
> Subject: Re: [PATCH 09/22] Enable building libbacktrace with Intel CET
> 
> "Tsimbalist, Igor V"  writes:
> 
> >
> > This file is included to simplify building a library that might have
> > assembler files.
> > This is an auxiliary file to automate creation of a special section in
> > an output object
> > file. Without it every assembler file has to be modified by hand to
> > include a special
> > section. This "-include cet.h " option is specified at a high level to
> > not bother if a
> > library has or does not have assembler files. The option either has no 
> > effect
> if
> > all source files are C/C++ or used only for assembler file
> > processing. The file itself
> > has an assembler code. The same code is generated by the compiler for
> each
> > input C/C++/etc. files.
> >
> > In real life a user who is going to write an assemble code and have it
> > CET compatible
> > has to add a special section to mark the object file as CET compatible.
> 
> I guess I don't understand how you can assume that general assembly code
> is CET compatible.  And if you know it is CET compatible then adding the
> section seems simple enough; people already do it routinely for
> .note.GNU-stack.
> 
> In any case a -include file such as you describe does not belong in a
> general FLAGS variable, it belongs in CPPFLAGS or, ideally, ASPPFLAGS if
> there were such a Make variable.
> 
> Ian


0009-Enable-building-libbacktrace-with-Intel-CET.PATCH
Description: 0009-Enable-building-libbacktrace-with-Intel-CET.PATCH

Re: [PATCH 4/7] GCOV: add -j argument (human readable format).

[Martin Liška]

On 10/30/2017 01:35 PM, Nathan Sidwell wrote:

On 10/26/2017 04:11 AM, marxin wrote:

Human readable format is quite useful in my opinion. There's example:

 -:    1:unsigned
    14.00K:    2:loop (unsigned n, int value)


My first thought is 'why 2 decimal places'?  That seems excessive.  Zero surely 
suffices?


Hi.

Agree.




Question is do we want to do it by default, or a new option is fine?
Note that all external tools using gcov should use intermediate format
which is obviously unchanged.


I don't think other tools do it by default.


Works for me/





+ [@option{-j}|@option{--human-numbers}]


man ls:
   -h, --human-readable
   with -l and/or -s, print human readable sizes (e.g., 1K 234M 2G)

Sadly '-h' is help (IIRC).  but we could at least copy the long form.


Yep, copied.





+  const char *units[] = {"", "K", "M", "G", "Y", "P", "E", "Z"};


Those aren't right  KMGTPEZY
http://www.npl.co.uk/reference/measurement-units/si-prefixes/


Ha, SI units. Last time I heart about it was at grammar school during Physics 
classes ;)
Following that.





+  for (unsigned i = 0; i < sizeof (units); i++)
+    {
+  if (v < 1000.0f)
+    {
+  sprintf (buffer, "%3.2f%s", v, units[i]);
+  return buffer;
+    }
+
+  v /= 1000.0f;
+    }


that's going to fail on certain roundings.  You're doing multiple divisions by 
1000, which itself will have roundings.  But more importantly, numbers after 
scaling like 999.999 will round to 1000, and you probably don't want that.  
This kind of formatting is tricky.  My inclination is to keep it in the integer 
domain.  Determine a scaling factor.  Divide once by that and then explicitly 
round to nearest even[*] with a check for the 999.9 case.  Then print as an 
unsigned.


Done that.

Is the patch fine to be installed?

Martin



nathan

[*] I presume you're familiar with RNE?  That's probably overkill and plain RN 
would be adequate.



>From b14bed2b376dc60eb35c07c5521007d16b137c78 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 26 Oct 2017 10:11:16 +0200
Subject: [PATCH 4/8] GCOV: add -j argument (human readable format).

Human readable format is quite useful in my opinion. There's example:

-:4:unsigned
  14k:5:loop (unsigned n, int value)		  /* count(14k) */
-:6:{
  21M:7:  for (unsigned i = 0; i < n - 1; i++)
-:8:  {
  21M:9:value += i;  /* count(21M) */
-:   10:  }
-:   11:
  14k:   12:  return value;
-:   13:}
-:   14:
1:   15:int main(int argc, char **argv)
-:   16:{
1:   17:  unsigned sum = 0;
   7k:   18:  for (unsigned i = 0; i < 7 * 1000; i++)
-:   19:  {
   7k:   20:sum += loop (1000, sum);
   7k:   21:sum += loop (2000, sum);		  /* count(7k) */
-:   22:  }
-:   23:
1:   24:  return 0;  /* count(1) */
-:   25:}
-:   26:

gcc/ChangeLog:

2017-10-23  Martin Liska  

	* doc/gcov.texi: Document new option.
	* gcov.c (print_usage): Likewise print it.
	(process_args): Support the argument.
	(format_count): New function.
	(format_gcov): Use the function.

gcc/testsuite/ChangeLog:

2017-10-23  Martin Liska  

	* g++.dg/gcov/loop.C: New test.
	* lib/gcov.exp: Support human readable format for counts.
---
 gcc/doc/gcov.texi|  5 +
 gcc/gcov.c   | 45 ++--
 gcc/testsuite/g++.dg/gcov/loop.C | 27 
 gcc/testsuite/lib/gcov.exp   |  2 +-
 4 files changed, 76 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/gcov/loop.C

diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index e186ac6e1ea..5c4ba8a51a7 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -125,6 +125,7 @@ gcov [@option{-v}|@option{--version}] [@option{-h}|@option{--help}]
  [@option{-d}|@option{--display-progress}]
  [@option{-f}|@option{--function-summaries}]
  [@option{-i}|@option{--intermediate-format}]
+ [@option{-j}|@option{--human-readable}]
  [@option{-k}|@option{--use-colors}]
  [@option{-l}|@option{--long-file-names}]
  [@option{-m}|@option{--demangled-names}]
@@ -186,6 +187,10 @@ be used by @command{lcov} or other tools. The output is a single
 The format of the intermediate @file{.gcov} file is plain text with
 one entry per line
 
+@item -j
+@itemx --human-readable
+Write counts in human readable format (like 24k).
+
 @smallexample
 file:@var{source_file_name}
 function:@var{line_number},@var{execution_count},@var{function_name}
diff --git a/gcc/gcov.c b/gcc/gcov.c
index f9334f96eb3..ff246c104e4 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -44,6 +44,7 @@ along with Gcov; see the file COPYING3.  If not see
 #include "color-macros.h"
 
 #include 
+#include 
 
 #include "md5.h"
 
@@ -393,6 +394,10 @@ static int flag_use_colors = 0;
 
 static int flag_all_blocks = 0;
 
+/* Output human readable numbers.  

RE: [PATCH 10/22] Enable building libcilkrts with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.

Ok for trunk?

Igor


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Wednesday, October 18, 2017 1:34 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 10/22] Enable building libcilkrts with Intel CET
> 
> On 10/12/2017 02:13 PM, Tsimbalist, Igor V wrote:
> > Enable building libcilkrts with CET options.
> >
> > libcilkrts/
> > * Makefile.am: Add AM_CXXFLAGS and XCXXFLAGS.
> > * configure.ac: Set CET_FLAGS, update XCFLAGS, XCXXFLAGS.
> > * Makefile.in: Regenerate.
> > * aclocal.m4: Likewise.
> > * configure: Likewise.
> >
> So like the other patches in this space, the inclusion of cet.h seems
> wrong.  I don't see why this should be needed here.
> 
> It's OK with that bit removed and once any prereqs are OK'd.
> 
> jeff


0010-Enable-building-libcilkrts-with-Intel-CET.PATCH
Description: 0010-Enable-building-libcilkrts-with-Intel-CET.PATCH

RE: [PATCH 11/22] Enable building libatomic with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:35 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 11/22] Enable building libatomic with Intel CET
> 
> On 10/12/2017 02:18 PM, Tsimbalist, Igor V wrote:
> > Enable building libatomic with CET options.
> >
> > libatomic/
> > * configure.ac: Set CET_FLAGS, update XCFLAGS.
> > * acinclude.m4: Add cet.m4 and enable.m4.
> > * configure: Regenerate.
> > * Makefile.in: Likewise.
> > * testsuite/Makefile.in: Likewise.
> >
> Same comments as with libcilkrts.
> Jeff


0011-Enable-building-libatomic-with-Intel-CET.PATCH
Description: 0011-Enable-building-libatomic-with-Intel-CET.PATCH

RE: [PATCH 12/22] Enable building libgomp with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:36 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: ja...@redhat.com
> Subject: Re: [PATCH 12/22] Enable building libgomp with Intel CET
> 
> On 10/12/2017 02:20 PM, Tsimbalist, Igor V wrote:
> > Enable building libgomp with CET options.
> >
> > libgomp/
> > * configure.ac: Set CET_FLAGS, update XCFLAGS and FCFLAGS.
> > * acinclude.m4: Add cet.m4.
> > * configure: Regenerate.
> > * Makefile.in: Likewise.
> > * testsuite/Makefile.in: Likewise
> >
> 
> Same comments as with libcilkrts.
> Jeff


0012-Enable-building-libgomp-with-Intel-CET.PATCH
Description: 0012-Enable-building-libgomp-with-Intel-CET.PATCH

RE: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Friday, October 13, 2017 2:09 PM
> To: gcc-patches@gcc.gnu.org; libstd...@gcc.gnu.org
> Cc: Jeff Law ; Tsimbalist, Igor V
> 
> Subject: RE: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET
> 
> Added libstd...@gcc.gnu.org
> 
> 
> > -Original Message-
> > From: Tsimbalist, Igor V
> > Sent: Thursday, October 12, 2017 10:24 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Jeff Law ; jwak...@redhat.com; Tsimbalist, Igor V
> > 
> > Subject: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET
> >
> > Enable building libstdc++v3 with CET options.
> >
> > libstdc++-v3/
> > * acinclude.m4: Add cet.m4.
> > * configure.ac: Set CET_FLAGS. Update EXTRA_CFLAGS.
> > * libsupc++/Makefile.am: Add EXTRA_CFLAGS.
> > * Makefile.in: Regenerate.
> > * configure: Likewise.
> > * doc/Makefile.in: Likewise.
> > * include/Makefile.in: Likewise.
> > * libsupc++/Makefile.in: Likewise.
> > * po/Makefile.in: Likewise.
> > * python/Makefile.in: Likewise.
> > * src/Makefile.in: Likewise.
> > * src/c++11/Makefile.in: Likewise.
> > * src/c++98/Makefile.in: Likewise.
> > * src/filesystem/Makefile.in: Likewise.
> > * testsuite/Makefile.in: Likewise.



0013-Enable-building-libstdc-v3-with-Intel-CET.PATCH
Description: 0013-Enable-building-libstdc-v3-with-Intel-CET.PATCH

Re: [PATCH 4/7] GCOV: add -j argument (human readable format).

[Nathan Sidwell]

On 10/31/2017 07:49 AM, Martin Liška wrote:

On 10/30/2017 01:35 PM, Nathan Sidwell wrote:



Is the patch fine to be installed?

not quite ...


+  gcov_type divisor = 1;
+  for (unsigned i = 0; i < strlen (units); i++)
+{
+  if (v < (1000 * divisor))
+   {
+ gcov_type r = (gcov_type)roundf (v / divisor);
+ sprintf (buffer, "%" PRId64 "%c", r, units[i]);
+ return buffer;
+   }
+  divisor *= 1000;
+}

This doesn't deal with rounding to 1000, which will look a bit odd. 
It'll also overflow if we ever get 10^24 counts (yeah, like that'll ever 
happen in this universe).  We may as well not use floats either.


Excuse the poor formatting

  unsigned i;
  for (i = 0; units[i+1]; i++, divisor *= 1000) {
if (count + divisor / 2 < 1000 * divisor)
   break;
  }
  gcov_type r  = (count + divisor / 2) / divisor;
  sprintf (buffer, "%" PRId64 "%c", r, units[i]);
  return buffer;

--
Nathan Sidwell

RE: [PATCH 15/22] Enable building libvtv with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:38 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: cmt...@google.com
> Subject: Re: [PATCH 15/22] Enable building libvtv with Intel CET
> 
> On 10/12/2017 02:29 PM, Tsimbalist, Igor V wrote:
> > Enable building libvtv with Intel CET options.
> >
> > libvtv/
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * libvtv/configure: Regenerate.
> > * libvtv/configure.ac: Set CET_FLAGS. Update XCFLAGS.
> Same comments as with libcilkrts.
> Jeff
> 



0015-Enable-building-libvtv-with-Intel-CET.PATCH
Description: 0015-Enable-building-libvtv-with-Intel-CET.PATCH

RE: [PATCH 16/22] Enable building libssp with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:38 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 16/22] Enable building libssp with Intel CET
> 
> On 10/12/2017 02:31 PM, Tsimbalist, Igor V wrote:
> > Enable building libssp with Intel CET options.
> >
> > libssp/
> > * Makefile.am: Update AM_CFLAGS.
> > * Makefile.in: Regenerate.
> > * configure: Likewise.
> > * aclocal.m4: Likewise.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS.
> >
> 
> Same comments as with libcilkrts.
> Jeff


0016-Enable-building-libssp-with-Intel-CET.PATCH
Description: 0016-Enable-building-libssp-with-Intel-CET.PATCH

RE: [PATCH 17/22] Enable building libquadmath with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:41 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: ja...@redhat.com
> Subject: Re: [PATCH 17/22] Enable building libquadmath with Intel CET
> 
> On 10/12/2017 02:34 PM, Tsimbalist, Igor V wrote:
> > Enable building libquadmath with Intel CET options.
> >
> > libquadmath/
> > * Makefile.am: Update AM_CFLAGS.
> > * Makefile.in: Regenerate:
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * configure: Regenerate.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS.
> >
> 
> Same comments as the libcilkrts changes.
> 
> Jeff


0017-Enable-building-libquadmath-with-Intel-CET.PATCH
Description: 0017-Enable-building-libquadmath-with-Intel-CET.PATCH

RE: [PATCH 18/22] Enable building libmpx with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Wednesday, October 18, 2017 1:42 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: enkovich@gmail.com
> Subject: Re: [PATCH 18/22] Enable building libmpx with Intel CET
> 
> On 10/12/2017 02:36 PM, Tsimbalist, Igor V wrote:
> > Enable building libmpx with Intel CET options.
> >
> > libmpx/
> > * Makefile.in: Regenerate.
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * configure: Regenerate.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS.
> > * mpxrt/Makefile.am: Update libmpx_la_CFLAGS.
> > * mpxrt/Makefile.in: Regenerate.
> > * mpxwrap/Makefile.am: Add AM_CFLAGS. Update
> > * libmpxwrappers_la_CFLAGS.
> > * mpxwrap/Makefile.in: Regenerate.
> >
> 
> 
> Same comments as the libcilkrts changes.
> 
> Jeff


0018-Enable-building-libmpx-with-Intel-CET.PATCH
Description: 0018-Enable-building-libmpx-with-Intel-CET.PATCH

RE: [PATCH 19/22] Enable building libgfortran with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:43 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 19/22] Enable building libgfortran with Intel CET
> 
> On 10/12/2017 03:17 PM, Tsimbalist, Igor V wrote:
> > Enable building libgfortran with Intel CET options.
> >
> > libgfortran/
> > * acinclude.m4: Add enable.m4, cet.m4.
> > * configure: Regenerate.
> > * configure.ac: Set CET_FLAGS. Update AM_FCFLAGS, AM_CFLAGS,
> > CFLAGS.
> >
> 
> Same comments as the libcilkrts changes.
> 
> Jeff


0019-Enable-building-libgfortran-with-Intel-CET.PATCH
Description: 0019-Enable-building-libgfortran-with-Intel-CET.PATCH

RE: [PATCH 20/22] Enable building libobjc with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:43 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 20/22] Enable building libobjc with Intel CET
> 
> On 10/12/2017 03:19 PM, Tsimbalist, Igor V wrote:
> > Enable building libobjc with Intel CET options.
> >
> > libobjc/
> > * Makefile.in: Regenerate.
> > * aclocal.m4: Likeiwse.
> > * configure: Likewise.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS.
> >
> 
> 
> Same comments as the libcilkrts changes.
> 
> Jeff


0020-Enable-building-libobjc-with-Intel-CET.PATCH
Description: 0020-Enable-building-libobjc-with-Intel-CET.PATCH

[C++ PATCH] overloaded operator fns [1/N]

[Nathan Sidwell]

This patch breaks DECL_OVERLOADED_OPERATOR_P apart into a predicate (as 
its name suggests) and DECL_OVERLOADED_OPERATOR_CODE, an accessor. I 
also add DECL_OVERLOADED_OPERATOR_IS, whose current implementation is a 
stepping stone to more a compressed operator enumeration.  Also add 
assign_op_identifier and call_op_identifier, which we use reasonably 
commonly.


I also notice that we're marking a lambda's conversion operator as an 
overloaded TYPE_EXPR.  That's weird and unnecessary, so this marks it 
simply as a conversion operator.


We're a little inconsistent in whether we check those two overloads by 
looking for identifier equivalence or examining the operator code 
enumeration.  I've not addressed that.


Applying to trunk.

nathan
--
Nathan Sidwell
2017-10-31  Nathan Sidwell  

	* cp-tree.h (assign_op_identifier, call_op_identifier): Define.
	(LAMBDA_FUNCTION_P): Use DECL_OVERLOADED_OPERATOR_IS.
	(DECL_OVERLOADED_OPERATOR_P): Just retuurn true/false.
	(DECL_OVERLOADED_OPERATOR_CODE, DECL_OVERLOADED_OPERATOR_IS): Define.
	* call.c (add_function_candidate): Use
	DECL_OVERLOADED_OPERATOR_IS.
	(build_op_call_1): Use call_op_identifier &
	DECL_OVERLOADED_OPERATOR_IS.
	(build_over_call): Likewise.
	(has_trivial_copy_assign_p): Use assign_op_identifier.
	(build_special_member_call): Likewise.
	* class.c (dfs_declare_virt_assop_and_dtor): Likewise.
	(vbase_has_user_provided_move_assign,
	classtype_has_move_assign_or_move_ctor_p): Likewise.
	* decl.c (duplicate_decls): Use DECL_OVERLOADED_OPERATOR_CODE.
	(grok_special_member_properties): Use assign_op_identifier.
	(start_preparsed_function): Use DECL_OVERLOADED_OPERATOR_IS.
	* decl2.c (mark_used): Use DECL_CONV_FN_P.
	* dump.c (dump_access): Delete prototype.
	(dump_op): Delete.
	(cp_dump_tree): Don't call it.
	* lambda.c (lambda_function): Use call_op_identifier.
	(maybe_add_lambda_conv_op): Not an overloaded operator.  Remove
	unneeded braces.
	* mangle.c (write_unqualified_name): Use DECL_OVERLOADED_OPERTOR_CODE.
	* method.c (do_build_copy_assign): Use assign_op_identifier.
	(synthesize_method): Use DECL_OVERLOADED_OPERATOR_IS.
	(get_copy_assign): Use assign_op_identifier.
	(synthesized_method_walk): Likewise.
	(defaultable_fn_check): Use DECL_OVERLOADED_OPERATOR_IS.
	* parser.c (cp_parser_lambda_declarator_opt): Use
	call_op_identifier.
	* semanitics.c (classtype_has_nothrow_assign_or_copy_p): Use
	assign_op_identifier.
	* tree.c (special_function_p):  Use DECL_OVERLOADED_OPERATOR_IS.
	* typeck.c (check_return_expr): Use DECL_OVERLOADED_OPERATOR_CODE.
	(check_return_expr): Use assign_op_identifier.

Index: call.c
===
--- call.c	(revision 254243)
+++ call.c	(working copy)
@@ -2082,7 +2082,7 @@ add_function_candidate (struct z_candida
   if (DECL_CONSTRUCTOR_P (fn))
 	i = 1;
   else if (DECL_ASSIGNMENT_OPERATOR_P (fn)
-	   && DECL_OVERLOADED_OPERATOR_P (fn) == NOP_EXPR)
+	   && DECL_OVERLOADED_OPERATOR_IS (fn, NOP_EXPR))
 	i = 2;
   else
 	i = 0;
@@ -4474,7 +4474,7 @@ build_op_call_1 (tree obj, vecfn will be a type, not a function, for a conversion
-	 function, we must be careful not to unconditionally look at
-	 DECL_NAME here.  */
   else if (TREE_CODE (cand->fn) == FUNCTION_DECL
-	   && DECL_OVERLOADED_OPERATOR_P (cand->fn) == CALL_EXPR)
+	   && DECL_OVERLOADED_OPERATOR_P (cand->fn)
+	   && DECL_OVERLOADED_OPERATOR_IS (cand->fn, CALL_EXPR))
 	result = build_over_call (cand, LOOKUP_NORMAL, complain);
   else
 	{
@@ -8116,7 +8114,8 @@ build_over_call (struct z_candidate *can
 	  return val;
 	}
 }
-  else if (DECL_OVERLOADED_OPERATOR_P (fn) == NOP_EXPR
+  else if (DECL_ASSIGNMENT_OPERATOR_P (fn)
+	   && DECL_OVERLOADED_OPERATOR_IS (fn, NOP_EXPR)
 	   && trivial_fn_p (fn)
 	   && !DECL_DELETED_FN (fn))
 {
@@ -8284,7 +8283,7 @@ first_non_public_field (tree type)
 static bool
 has_trivial_copy_assign_p (tree type, bool access, bool *hasassign)
 {
-  tree fns = get_class_binding (type, cp_assignment_operator_id (NOP_EXPR));
+  tree fns = get_class_binding (type, assign_op_identifier);
   bool all_trivial = true;
 
   /* Iterate over overloads of the assignment operator, checking
@@ -8784,8 +8783,7 @@ build_special_member_call (tree instance
   vec *allocated = NULL;
   tree ret;
 
-  gcc_assert (IDENTIFIER_CDTOR_P (name)
-	  || name == cp_assignment_operator_id (NOP_EXPR));
+  gcc_assert (IDENTIFIER_CDTOR_P (name) || name == assign_op_identifier);
   if (TYPE_P (binfo))
 {
   /* Resolve the name.  */
@@ -8811,7 +8809,7 @@ build_special_member_call (tree instance
   if (!same_type_ignoring_top_level_qualifiers_p
 	  (TREE_TYPE (instance), BINFO_TYPE (binfo)))
 	{
-	  if (name != cp_assignment_operator_id (NOP_EXPR))
+	  if (IDENTIFIER_CDTOR_P (name))
 	/* For constructors and destructors, either the base is
 	   non-virtual, or it is virtual but we are doing the
 	   conversion from a constructor or destructor for the
@

[libgomp, hsa,committed] Remove semicolon after do {} while (false) in HSA_LOG

[Tom de Vries]

Hi,

this patch removes a semicolon after "do {} while (false)" in HSA_LOG, 
making sure we can use it in if-then-elses without curly braces.


Build hsa plugin.

Committed as trivial.

Thanks,
- Tom
Remove semicolon after do {} while (false) in HSA_LOG

2017-10-31  Tom de Vries  

	* plugin/plugin-hsa.c (HSA_LOG): Remove semicolon after
	"do {} while (false)".
	(init_single_kernel, GOMP_OFFLOAD_async_run): Add missing semicolon
	after HSA_DEBUG call.

---
 libgomp/plugin/plugin-hsa.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgomp/plugin/plugin-hsa.c b/libgomp/plugin/plugin-hsa.c
index fc08f5d..cf3a4d51 100644
--- a/libgomp/plugin/plugin-hsa.c
+++ b/libgomp/plugin/plugin-hsa.c
@@ -261,7 +261,7 @@ init_enviroment_variables (void)
 	fprintf (stderr, __VA_ARGS__); \
   } \
   } \
-  while (false);
+  while (false)
 
 /* Print a debugging message to stderr.  */
 
@@ -1241,7 +1241,7 @@ init_single_kernel (struct kernel_info *kernel, unsigned *max_omp_data_size)
   if (dependency->dependencies_count > 0)
 	{
 	  HSA_DEBUG ("HSA does not allow kernel dispatching code with "
-		 "a depth bigger than one\n")
+		 "a depth bigger than one\n");
 	  goto failure;
 	}
 
@@ -1664,7 +1664,7 @@ GOMP_OFFLOAD_async_run (int device, void *tgt_fn, void *tgt_vars,
 {
   pthread_t pt;
   struct async_run_info *info;
-  HSA_DEBUG ("GOMP_OFFLOAD_async_run invoked\n")
+  HSA_DEBUG ("GOMP_OFFLOAD_async_run invoked\n");
   info = GOMP_PLUGIN_malloc (sizeof (struct async_run_info));
 
   info->device = device;

Re: [PATCH v3] Add asan and ubsan support on NetBSD/amd64

[Jakub Jelinek]

On Mon, Oct 30, 2017 at 09:01:25PM +0100, Kamil Rytarowski wrote:
> On 30.10.2017 08:24, Jakub Jelinek wrote:
> > On Thu, Oct 26, 2017 at 09:50:43PM +0200, Kamil Rytarowski wrote:
> >> $ make check-asan
> >> $ make check-asan-dynamic
> >> $ make check-ubsan
> > 
> > That is testing of the upstream code, not of GCC and the libsanitizer
> > copy in GCC.  What I'm more interested to hear is whether
> > you've bootstrapped/regtested the gcc tree with this patch on
> > x86_64-*-netbsd*, as per https://gcc.gnu.org/contribute.html
> > I.e. /configure ...; make -jN bootstrap; make -jN -k check; 
> > /contrib/test_summary
> > and from there if there are any */asan/* or */ubsan/* FAILs.
> > 
> 
> I've been executing GCC tests.
> 
> Some/many tests were hanging and I was killing them after a longer
> period of time. There were certainly environment issues, like attempts
> to execute non-existent 'python' (in pkgsrc/NetBSD we version python to
> python2.7, python3.6 etc).
> 
> http://netbsd.org/~kamil/gcc/test_summary.log.8-20171022.txt

That seems that asan pretty much doesn't work at all in GCC for netbsd.
A few FAILs might be acceptable, but so many FAILs certainly aren't.
The testsuite doesn't use python, at least not for *san testing nor
test_summary, so that shouldn't be the problem.  If it is asan/ubsan tests
that are hanging, that is something that needs to be debugged and understood
why it hangs.

You should look into ...objdir/gcc/testsuite/{gcc,g++}/{gcc,g++}.log
for details on some short/simple tests and see what the problem is.

Jakub

[patch, fortran] Index interchange for FORALL and DO CONCURRENT

[Thomas Koenig]

Hello world,

here is a version of the patch for index interchange for FORALL
and DO CONCURRENT that I would like to commit.

It introduces a new option for selecting (or deselecting)
the option, -ffrontend-loop-interchange.  The reason for
this is simple: It is always possible that the heurisics in the
patch might make a bad choice, and the user should be able to
deselect this optimization when he has already optimized loop
ordering in his code.  The new option is selected when
optimizing, the same way that -ffrontend-optimize is.

No test case because I could not think of anything
that could test the nesting of loops.

Regression-tested. OK for trunk?

Regards

Thomas

2017-10-31  Thomas Koenig  

* lang.opt (ffrontend-loop-interchange): New option.
* options.c (gfc_post_options): Handle it.
* frontend-passes.c (gfc_run_passes): Run
optimize_namespace if flag_frontend_optimize or
flag_frontend_loop_interchange are set.
(optimize_namespace): Run functions according to flags set;
also call index_interchange.
(ind_type): New function.
(has_var): New function.
(index_cost): New function.
(loop_comp): New function.
Index: lang.opt
===
--- lang.opt	(Revision 254232)
+++ lang.opt	(Arbeitskopie)
@@ -548,6 +548,10 @@ ffree-line-length-
 Fortran RejectNegative Joined UInteger Var(flag_free_line_length) Init(132)
 -ffree-line-length-	Use n as character line width in free mode.
 
+ffrontend-loop-interchange
+Fortran Var(flag_frontend_loop_interchange) Init(-1)
+Try to interchange loops if profitable.
+
 ffrontend-optimize
 Fortran Var(flag_frontend_optimize) Init(-1)
 Enable front end optimization.
Index: options.c
===
--- options.c	(Revision 254232)
+++ options.c	(Arbeitskopie)
@@ -417,6 +417,11 @@ gfc_post_options (const char **pfilename)
   if (flag_frontend_optimize == -1)
 flag_frontend_optimize = optimize;
 
+  /* Same for front end loop interchange.  */
+
+  if (flag_frontend_loop_interchange == -1)
+flag_frontend_loop_interchange = optimize;
+
   if (flag_max_array_constructor < 65535)
 flag_max_array_constructor = 65535;
 
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 254232)
+++ frontend-passes.c	(Arbeitskopie)
@@ -55,6 +55,7 @@ static gfc_expr* check_conjg_transpose_variable (g
 		 bool *);
 static bool has_dimen_vector_ref (gfc_expr *);
 static int matmul_temp_args (gfc_code **, int *,void *data);
+static int index_interchange (gfc_code **, int*, void *);
 
 #ifdef CHECKING_P
 static void check_locus (gfc_namespace *);
@@ -155,9 +156,11 @@ gfc_run_passes (gfc_namespace *ns)
   check_locus (ns);
 #endif
 
+  if (flag_frontend_optimize || flag_frontend_loop_interchange)
+optimize_namespace (ns);
+
   if (flag_frontend_optimize)
 {
-  optimize_namespace (ns);
   optimize_reduction (ns);
   if (flag_dump_fortran_optimized)
 	gfc_dump_parse_tree (ns, stdout);
@@ -1350,7 +1353,8 @@ simplify_io_impl_do (gfc_code **code, int *walk_su
   return 0;
 }
 
-/* Optimize a namespace, including all contained namespaces.  */
+/* Optimize a namespace, including all contained namespaces. flag_frontend_optimize and
+ flag_fronend_loop_interchange are handled separately.  */
 
 static void
 optimize_namespace (gfc_namespace *ns)
@@ -1363,28 +1367,35 @@ optimize_namespace (gfc_namespace *ns)
   in_assoc_list = false;
   in_omp_workshare = false;
 
-  gfc_code_walker (&ns->code, simplify_io_impl_do, dummy_expr_callback, NULL);
-  gfc_code_walker (&ns->code, convert_do_while, dummy_expr_callback, NULL);
-  gfc_code_walker (&ns->code, convert_elseif, dummy_expr_callback, NULL);
-  gfc_code_walker (&ns->code, cfe_code, cfe_expr_0, NULL);
-  gfc_code_walker (&ns->code, optimize_code, optimize_expr, NULL);
-  if (flag_inline_matmul_limit != 0)
+  if (flag_frontend_optimize)
 {
-  bool found;
-  do
+  gfc_code_walker (&ns->code, simplify_io_impl_do, dummy_expr_callback, NULL);
+  gfc_code_walker (&ns->code, convert_do_while, dummy_expr_callback, NULL);
+  gfc_code_walker (&ns->code, convert_elseif, dummy_expr_callback, NULL);
+  gfc_code_walker (&ns->code, cfe_code, cfe_expr_0, NULL);
+  gfc_code_walker (&ns->code, optimize_code, optimize_expr, NULL);
+  if (flag_inline_matmul_limit != 0)
 	{
-	  found = false;
-	  gfc_code_walker (&ns->code, matmul_to_var_code, matmul_to_var_expr,
-			   (void *) &found);
+	  bool found;
+	  do
+	{
+	  found = false;
+	  gfc_code_walker (&ns->code, matmul_to_var_code, matmul_to_var_expr,
+			   (void *) &found);
+	}
+	  while (found);
+
+	  gfc_code_walker (&ns->code, matmul_temp_args, dummy_expr_callback,
+			   NULL);
+	  gfc_code_walker (&ns->code, inline_matmul_assign, dummy_expr_callback,
+			   NULL);
 	

Re: [PATCH 07/22] Enable building libgcc with CET options.

[Andreas Schwab]

On Okt 31 2017, "Tsimbalist, Igor V"  wrote:

> diff --git a/config/cet.m4 b/config/cet.m4
> new file mode 100644
> index 000..c903791
> --- /dev/null
> +++ b/config/cet.m4
> @@ -0,0 +1,40 @@
> +dnl
> +dnl GCC_CET_FLAGS
> +dnl(SHELL-CODE_HANDLER)
> +dnl
> +AC_DEFUN([GCC_CET_FLAGS],[dnl
> +GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
> +permit yes|no|default)
> +case "$host" in
> +  i[34567]86-*-linux* | x86_64-*-linux*)

Missing quoting around [...].

Andreas.

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

[PATCH][AArch64] Restrict POST_INC operand in aarch64_simd_mem_operand_p to register

[Dominik Inführ]

Hi,

I have a custom optimization pass, that moves an expression into an 
POST_INC-expression. GCC then ICE’s in df-scan.c since it expects REG_P to be 
true for POST_INC’s operand. aarch64_simd_mem_operand_p doesn’t seem to check 
POST_INC’s operand. Here is a patch that fixes this for me, although I am not 
sure if this is the right way to address this. GCC bootstraps and it causes no 
test regressions.

Dominik

ChangeLog:
2017-10-31  Dominik Infuehr  

* config/aarch64/aarch64.c (aarch64_simd_mem_operand_p): Check
if register given as operand for POST_INC.

-

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index ed30b8c..bb61506 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11850,8 +11850,15 @@ aarch64_simd_lane_bounds (rtx operand, HOST_WIDE_INT 
low, HOST_WIDE_INT high,
 bool
 aarch64_simd_mem_operand_p (rtx op)
 {
-  return MEM_P (op) && (GET_CODE (XEXP (op, 0)) == POST_INC
-   || REG_P (XEXP (op, 0)));
+  if (!MEM_P (op))
+return false;
+
+  rtx opnd = XEXP (op, 0);
+
+  if (GET_CODE (opnd) == POST_INC)
+opnd = XEXP(opnd, 0);
+
+  return REG_P (opnd);
 }

 /* Emit a register copy from operand to operand, taking care not to


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH v3] Add asan and ubsan support on NetBSD/amd64

[Kamil Rytarowski]

On 31.10.2017 14:22, Jakub Jelinek wrote:
> On Mon, Oct 30, 2017 at 09:01:25PM +0100, Kamil Rytarowski wrote:
>> On 30.10.2017 08:24, Jakub Jelinek wrote:
>>> On Thu, Oct 26, 2017 at 09:50:43PM +0200, Kamil Rytarowski wrote:
 $ make check-asan
 $ make check-asan-dynamic
 $ make check-ubsan
>>>
>>> That is testing of the upstream code, not of GCC and the libsanitizer
>>> copy in GCC.  What I'm more interested to hear is whether
>>> you've bootstrapped/regtested the gcc tree with this patch on
>>> x86_64-*-netbsd*, as per https://gcc.gnu.org/contribute.html
>>> I.e. /configure ...; make -jN bootstrap; make -jN -k check; 
>>> /contrib/test_summary
>>> and from there if there are any */asan/* or */ubsan/* FAILs.
>>>
>>
>> I've been executing GCC tests.
>>
>> Some/many tests were hanging and I was killing them after a longer
>> period of time. There were certainly environment issues, like attempts
>> to execute non-existent 'python' (in pkgsrc/NetBSD we version python to
>> python2.7, python3.6 etc).
>>
>> http://netbsd.org/~kamil/gcc/test_summary.log.8-20171022.txt
> 
> That seems that asan pretty much doesn't work at all in GCC for netbsd.
> A few FAILs might be acceptable, but so many FAILs certainly aren't.
> The testsuite doesn't use python, at least not for *san testing nor
> test_summary, so that shouldn't be the problem.  If it is asan/ubsan tests
> that are hanging, that is something that needs to be debugged and understood
> why it hangs.
> 

It is similar in LLVM, where it works against statically linked .a files
with sanitizers. For .so, I can observe similar information about
DEADLYSIGNAL without detailed information.

I will try to fix it in LLVM first.

I noted that FreeBSD people has similar issues, caused e.g. by the link
order of libraries (libthr vs libc).. not sure what's the reason in NetBSD.

> You should look into ...objdir/gcc/testsuite/{gcc,g++}/{gcc,g++}.log
> for details on some short/simple tests and see what the problem is.
> 
>   Jakub
> 


T



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 4/7] GCOV: add -j argument (human readable format).

[Martin Liška]

On 10/31/2017 01:05 PM, Nathan Sidwell wrote:

On 10/31/2017 07:49 AM, Martin Liška wrote:

On 10/30/2017 01:35 PM, Nathan Sidwell wrote:



Is the patch fine to be installed?

not quite ...


+  gcov_type divisor = 1;
+  for (unsigned i = 0; i < strlen (units); i++)
+    {
+  if (v < (1000 * divisor))
+    {
+  gcov_type r = (gcov_type)roundf (v / divisor);
+  sprintf (buffer, "%" PRId64 "%c", r, units[i]);
+  return buffer;
+    }
+  divisor *= 1000;
+    }

This doesn't deal with rounding to 1000, which will look a bit odd. It'll also 
overflow if we ever get 10^24 counts (yeah, like that'll ever happen in this 
universe).  We may as well not use floats either.


Hi.

Do you mean numbers a bit smaller than 1000 or bit bigger? Do you have an 
example that will
be handled in a different way?



Excuse the poor formatting

   unsigned i;
   for (i = 0; units[i+1]; i++, divisor *= 1000) {
     if (count + divisor / 2 < 1000 * divisor)
    break;
   }
   gcov_type r  = (count + divisor / 2) / divisor;
   sprintf (buffer, "%" PRId64 "%c", r, units[i]);
   return buffer;



I've adapted your code snippet.

Martin
>From 902208a24eafaf1a6a4b334a2c8ea32afaec63df Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 26 Oct 2017 10:11:16 +0200
Subject: [PATCH 4/8] GCOV: add -j argument (human readable format).

Human readable format is quite useful in my opinion. There's example:

-:4:unsigned
  14k:5:loop (unsigned n, int value)		  /* count(14k) */
-:6:{
  21M:7:  for (unsigned i = 0; i < n - 1; i++)
-:8:  {
  21M:9:value += i;  /* count(21M) */
-:   10:  }
-:   11:
  14k:   12:  return value;
-:   13:}
-:   14:
1:   15:int main(int argc, char **argv)
-:   16:{
1:   17:  unsigned sum = 0;
   7k:   18:  for (unsigned i = 0; i < 7 * 1000; i++)
-:   19:  {
   7k:   20:sum += loop (1000, sum);
   7k:   21:sum += loop (2000, sum);		  /* count(7k) */
-:   22:  }
-:   23:
1:   24:  return 0;  /* count(1) */
-:   25:}
-:   26:

gcc/ChangeLog:

2017-10-23  Martin Liska  

	* doc/gcov.texi: Document new option.
	* gcov.c (print_usage): Likewise print it.
	(process_args): Support the argument.
	(format_count): New function.
	(format_gcov): Use the function.

gcc/testsuite/ChangeLog:

2017-10-23  Martin Liska  

	* g++.dg/gcov/loop.C: New test.
	* lib/gcov.exp: Support human readable format for counts.
---
 gcc/doc/gcov.texi|  5 +
 gcc/gcov.c   | 41 ++--
 gcc/testsuite/g++.dg/gcov/loop.C | 27 ++
 gcc/testsuite/lib/gcov.exp   |  2 +-
 4 files changed, 72 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/gcov/loop.C

diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index e186ac6e1ea..5c4ba8a51a7 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -125,6 +125,7 @@ gcov [@option{-v}|@option{--version}] [@option{-h}|@option{--help}]
  [@option{-d}|@option{--display-progress}]
  [@option{-f}|@option{--function-summaries}]
  [@option{-i}|@option{--intermediate-format}]
+ [@option{-j}|@option{--human-readable}]
  [@option{-k}|@option{--use-colors}]
  [@option{-l}|@option{--long-file-names}]
  [@option{-m}|@option{--demangled-names}]
@@ -186,6 +187,10 @@ be used by @command{lcov} or other tools. The output is a single
 The format of the intermediate @file{.gcov} file is plain text with
 one entry per line
 
+@item -j
+@itemx --human-readable
+Write counts in human readable format (like 24k).
+
 @smallexample
 file:@var{source_file_name}
 function:@var{line_number},@var{execution_count},@var{function_name}
diff --git a/gcc/gcov.c b/gcc/gcov.c
index f9334f96eb3..972e567160e 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -44,6 +44,7 @@ along with Gcov; see the file COPYING3.  If not see
 #include "color-macros.h"
 
 #include 
+#include 
 
 #include "md5.h"
 
@@ -393,6 +394,10 @@ static int flag_use_colors = 0;
 
 static int flag_all_blocks = 0;
 
+/* Output human readable numbers.  */
+
+static int flag_human_readable_numbers = 0;
+
 /* Output summary info for each function.  */
 
 static int flag_function_summary = 0;
@@ -710,6 +715,7 @@ print_usage (int error_p)
   fnotice (file, "  -f, --function-summariesOutput summaries for each function\n");
   fnotice (file, "  -h, --help  Print this help, then exit\n");
   fnotice (file, "  -i, --intermediate-format   Output .gcov file in intermediate text format\n");
+  fnotice (file, "  -j, --human-readableOutput human readable numbers\n");
   fnotice (file, "  -k, --use-colorsEmit colored output\n");
   fnotice (file, "  -l, --long-file-names   Use long output file names for included\n\
 source files\n");
@@ -752,6 +758

Re: [PATCH v3] Add asan and ubsan support on NetBSD/amd64

[Jakub Jelinek]

On Tue, Oct 31, 2017 at 02:53:26PM +0100, Kamil Rytarowski wrote:
> >> http://netbsd.org/~kamil/gcc/test_summary.log.8-20171022.txt
> > 
> > That seems that asan pretty much doesn't work at all in GCC for netbsd.
> > A few FAILs might be acceptable, but so many FAILs certainly aren't.
> > The testsuite doesn't use python, at least not for *san testing nor
> > test_summary, so that shouldn't be the problem.  If it is asan/ubsan tests
> > that are hanging, that is something that needs to be debugged and understood
> > why it hangs.
> > 
> 
> It is similar in LLVM, where it works against statically linked .a files
> with sanitizers. For .so, I can observe similar information about
> DEADLYSIGNAL without detailed information.

But dynamic linking of libasan or libubsan is the default in gcc, so
it needs to work out of the box.
Note gcc/config/gnu-user.h has:
/* Link -lasan early on the command line.  For -static-libasan, don't link
   it for -shared link, the executable should be compiled with -static-libasan
   in that case, and for executable link with --{,no-}whole-archive around
   it to force everything into the executable.  And similarly for -ltsan
   and -llsan.  */
#if defined(HAVE_LD_STATIC_DYNAMIC)
#undef LIBASAN_EARLY_SPEC
#define LIBASAN_EARLY_SPEC "%{!shared:libasan_preinit%O%s} " \
  "%{static-libasan:%{!shared:" \
  LD_STATIC_OPTION " --whole-archive -lasan --no-whole-archive " \
  LD_DYNAMIC_OPTION "}}%{!static-libasan:-lasan}"
#undef LIBTSAN_EARLY_SPEC
#define LIBTSAN_EARLY_SPEC "%{!shared:libtsan_preinit%O%s} " \
  "%{static-libtsan:%{!shared:" \
  LD_STATIC_OPTION " --whole-archive -ltsan --no-whole-archive " \
  LD_DYNAMIC_OPTION "}}%{!static-libtsan:-ltsan}"
#undef LIBLSAN_EARLY_SPEC
#define LIBLSAN_EARLY_SPEC "%{!shared:liblsan_preinit%O%s} " \
  "%{static-liblsan:%{!shared:" \
  LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \
  LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}"
#endif

which might need to be duplicated into gcc/config/netbsd-elf.h.

Jakub

Re: [PATCH][AArch64] Restrict POST_INC operand in aarch64_simd_mem_operand_p to register

[Kyrill Tkachov]

[cc'ing aarch64 maintainers]

Hi Dominik,

On 31/10/17 13:47, Dominik Inführ wrote:

Hi,

I have a custom optimization pass, that moves an expression into an 
POST_INC-expression. GCC then ICE’s in df-scan.c since it expects REG_P to be 
true for POST_INC’s operand. aarch64_simd_mem_operand_p doesn’t seem to check 
POST_INC’s operand. Here is a patch that fixes this for me, although I am not 
sure if this is the right way to address this. GCC bootstraps and it causes no 
test regressions.


The documentation for POST_INC says that its operand has to be a MEM or 
a REG.

Anything else is invalid RTL.
AArch64 only supports REGs as an operand to POST_INC.
The existing implementation of aarch64_simd_lane_bounds indeed doesn't 
properly reject non-REG operands to
POST_INC, so I think your patch is correct, in that we should be tighter 
to make sure we don't accept any MEMs.

But you'll need an approval from an aarch64 maintainer before committing.

However, I suggest you check your pass to make sure it doesn't try to 
put any arbitrary RTL into a POST_INC, because

otherwise some other parts of the compiler might blow up.

Thanks,
Kyrill


Dominik

ChangeLog:
2017-10-31  Dominik Infuehr  

* config/aarch64/aarch64.c (aarch64_simd_mem_operand_p): Check
if register given as operand for POST_INC.

-

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index ed30b8c..bb61506 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11850,8 +11850,15 @@ aarch64_simd_lane_bounds (rtx operand, HOST_WIDE_INT 
low, HOST_WIDE_INT high,
  bool
  aarch64_simd_mem_operand_p (rtx op)
  {
-  return MEM_P (op) && (GET_CODE (XEXP (op, 0)) == POST_INC
-   || REG_P (XEXP (op, 0)));
+  if (!MEM_P (op))
+return false;
+
+  rtx opnd = XEXP (op, 0);
+
+  if (GET_CODE (opnd) == POST_INC)
+opnd = XEXP(opnd, 0);
+
+  return REG_P (opnd);
  }

  /* Emit a register copy from operand to operand, taking care not to

Re: [PATCH 4/7] GCOV: add -j argument (human readable format).

[Nathan Sidwell]

On 10/31/2017 10:04 AM, Martin Liška wrote:

Do you mean numbers a bit smaller than 1000 or bit bigger? Do you have 
an example that will

be handled in a different way?


A count like 999500 would have been scaled to 999.5 and then rounded to 
1000.  We'd print 1000k rather than 1M.



I've adapted your code snippet.


thanks, this is ok.

nathan

--
Nathan Sidwell

[C++ PATCH] overloaded operator fns [2/N]

[Nathan Sidwell]

This patch removes cp_operator_id(C) and cp_assignment_operator_id(C), 
replacing them with a singlle ovl_op_identifier(A,C) macro.  There's 
also OVL_OP_INFO(A,C) to get at the other information.  The 
implementation of that macro will change later in this patch series, so 
don't freak on the (A ? assop_ary : op_ary) idiom.


nathan

--
Nathan Sidwell
2017-10-31  Nathan Sidwell  

	gcc/cp/
	* cp-tree.h (ovl_op_identifier): New.
	(assign_op_identifier, call_op_identifier): Adjust.
	(cp_operator_id, cp_assignment_operator_ide): Delete.
	(SET_OVERLOADED_OPERATOR_CODE): Delete.
	(OVL_OP_INFO): New.
	* call.c (op_error): Use OVL_OP_INFO.
	(build_conditional_expr_1): Use ovl_op_identifier.
	(build_new_op_1): Use OVL_OP_INFO & ovl_op_identifier.
	(build_op_delete_call): Likewise.
	* class.c (type_requires_array_cookie): Use ovl_op_identifier.
	* decl.c (duplicate_decls): Directly copy operator code.
	(builtin_function_1): Do not set operator code.
	(build_library_fn): Directly set operator code.
	(push_cp_library_fn): Use ovl_op_identifier.
	(grok_op_properties): Directly set operator code.
	* decl2.c (maybe_warn_sized_delete): Use ovl_op_identifier.
	* error.c (dump_expr): Use OVL_OP_INFO.
	(op_to_string): Add assop arg. Use OVL_OP_INFO.
	(assop_to_string): Delete.
	(args_to_string): Adjust.
	* init.c (build_new_1): Use ovl_op_identifier.
	* mangle.c (write_unqualified_name): Use OVL_OP_INFO.
	(write_expression): Likewise.
	* method.c (synthesized_method_walk): Use ovl_op_identifier.
	(implicitly_declare_fn): Use assign_op_identifier. Directly set
	operator code.
	* name-lookup.c (get_class_binding): Use assign_op_identifier.
	* parser.c (cp_parser_operator): Use ovl_op_identifier.
	(cp_parser_omp_clause_reduction): Likewise.
	* semantics.c (omp_reduction_id): Likewise.
	* typeck.c (cxx_sizeof_or_alignof_type): Use OVL_OP_INFO.

	libcc1/
	* libcp1plugin.cc (plugin_build_decl): Use ovl_op_identifier.
	Directly set operator code.
	(plugin_build_dependent_expr): Use ovl_op_identifier.

Index: gcc/cp/call.c
===
--- gcc/cp/call.c	(revision 254263)
+++ gcc/cp/call.c	(working copy)
@@ -4620,12 +4620,8 @@ static void
 op_error (location_t loc, enum tree_code code, enum tree_code code2,
 	  tree arg1, tree arg2, tree arg3, bool match)
 {
-  const char *opname;
-
-  if (code == MODIFY_EXPR)
-opname = assignment_operator_name_info[code2].name;
-  else
-opname = operator_name_info[code].name;
+  bool assop = code == MODIFY_EXPR;
+  const char *opname = OVL_OP_INFO (assop, assop ? code2 : code)->name;
 
   switch (code)
 {
@@ -5184,7 +5180,7 @@ build_conditional_expr_1 (location_t loc
   add_builtin_candidates (&candidates,
 			  COND_EXPR,
 			  NOP_EXPR,
-			  cp_operator_id (COND_EXPR),
+			  ovl_op_identifier (false, COND_EXPR),
 			  args,
 			  LOOKUP_NORMAL, complain);
 
@@ -5574,7 +5570,6 @@ build_new_op_1 (location_t loc, enum tre
 {
   struct z_candidate *candidates = 0, *cand;
   vec *arglist;
-  tree fnname;
   tree args[3];
   tree result = NULL_TREE;
   bool result_valid_p = false;
@@ -5591,14 +5586,13 @@ build_new_op_1 (location_t loc, enum tre
   || error_operand_p (arg3))
 return error_mark_node;
 
-  if (code == MODIFY_EXPR)
+  bool ismodop = code == MODIFY_EXPR;
+  if (ismodop)
 {
   code2 = TREE_CODE (arg3);
   arg3 = NULL_TREE;
-  fnname = cp_assignment_operator_id (code2);
 }
-  else
-fnname = cp_operator_id (code);
+  tree fnname = ovl_op_identifier (ismodop, ismodop ? code2 : code);
 
   arg1 = prep_operand (arg1);
 
@@ -5793,7 +5787,7 @@ build_new_op_1 (location_t loc, enum tre
 		? G_("no %<%D(int)%> declared for postfix %qs,"
 		 " trying prefix operator instead")
 		: G_("no %<%D(int)%> declared for postfix %qs");
-	  permerror (loc, msg, fnname, operator_name_info[code].name);
+	  permerror (loc, msg, fnname, OVL_OP_INFO (false, code)->name);
 	}
 
 	  if (!flag_permissive)
@@ -6205,7 +6199,7 @@ build_op_delete_call (enum tree_code cod
 
   type = strip_array_types (TREE_TYPE (TREE_TYPE (addr)));
 
-  fnname = cp_operator_id (code);
+  fnname = ovl_op_identifier (false, code);
 
   if (CLASS_TYPE_P (type)
   && COMPLETE_TYPE_P (complete_type (type))
@@ -6434,7 +6428,7 @@ build_op_delete_call (enum tree_code cod
 
   if (complain & tf_error)
 error ("no suitable % for %qT",
-	   operator_name_info[(int)code].name, type);
+	   OVL_OP_INFO (false, code)->name, type);
   return error_mark_node;
 }
 
Index: gcc/cp/class.c
===
--- gcc/cp/class.c	(revision 254263)
+++ gcc/cp/class.c	(working copy)
@@ -5304,7 +5304,7 @@ type_requires_array_cookie (tree type)
  the array to the deallocation function, so we will need to store
  a cookie.  */
   fns = lookup_fnfields (TYPE_BINFO (type),
-			 cp_operator_id (VEC_DELETE_EXPR),
+			 ovl_op_identifier (false, VEC_DELETE_EXPR),
 			 

Re: [PATCH][AArch64] Restrict POST_INC operand in aarch64_simd_mem_operand_p to register

[Dominik Inführ]

> On 31 Oct 2017, at 15:10, Kyrill Tkachov  wrote:
> 
> [cc'ing aarch64 maintainers]
> 
> Hi Dominik,
> 
> On 31/10/17 13:47, Dominik Inführ wrote:
>> Hi,
>> 
>> I have a custom optimization pass, that moves an expression into an 
>> POST_INC-expression. GCC then ICE’s in df-scan.c since it expects REG_P to 
>> be true for POST_INC’s operand. aarch64_simd_mem_operand_p doesn’t seem to 
>> check POST_INC’s operand. Here is a patch that fixes this for me, although I 
>> am not sure if this is the right way to address this. GCC bootstraps and it 
>> causes no test regressions.
> 
> The documentation for POST_INC says that its operand has to be a MEM or a REG.
> Anything else is invalid RTL.
> AArch64 only supports REGs as an operand to POST_INC.
> The existing implementation of aarch64_simd_lane_bounds indeed doesn't 
> properly reject non-REG operands to
> POST_INC, so I think your patch is correct, in that we should be tighter to 
> make sure we don't accept any MEMs.
> But you'll need an approval from an aarch64 maintainer before committing.

Thanks!

> 
> However, I suggest you check your pass to make sure it doesn't try to put any 
> arbitrary RTL into a POST_INC, because
> otherwise some other parts of the compiler might blow up.

Even if the pass then uses recog() to determine if this is still some valid 
instruction? Right now recog() succeeds with some arbitrary expression for 
POST_INC.

> 
> Thanks,
> Kyrill
> 
>> Dominik
>> 
>> ChangeLog:
>> 2017-10-31  Dominik Infuehr  
>> 
>>  * config/aarch64/aarch64.c (aarch64_simd_mem_operand_p): Check
>>  if register given as operand for POST_INC.
>> 
>> -
>> 
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index ed30b8c..bb61506 100644
>> --- a/gcc/config/aarch64/aarch64.c
>> +++ b/gcc/config/aarch64/aarch64.c
>> @@ -11850,8 +11850,15 @@ aarch64_simd_lane_bounds (rtx operand, 
>> HOST_WIDE_INT low, HOST_WIDE_INT high,
>>  bool
>>  aarch64_simd_mem_operand_p (rtx op)
>>  {
>> -  return MEM_P (op) && (GET_CODE (XEXP (op, 0)) == POST_INC
>> -   || REG_P (XEXP (op, 0)));
>> +  if (!MEM_P (op))
>> +return false;
>> +
>> +  rtx opnd = XEXP (op, 0);
>> +
>> +  if (GET_CODE (opnd) == POST_INC)
>> +opnd = XEXP(opnd, 0);
>> +
>> +  return REG_P (opnd);
>>  }
>> 
>>  /* Emit a register copy from operand to operand, taking care not to
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH][AArch64] Restrict POST_INC operand in aarch64_simd_mem_operand_p to register

[Kyrill Tkachov]

On 31/10/17 14:44, Dominik Inführ wrote:

On 31 Oct 2017, at 15:10, Kyrill Tkachov  wrote:

[cc'ing aarch64 maintainers]

Hi Dominik,

On 31/10/17 13:47, Dominik Inführ wrote:

Hi,

I have a custom optimization pass, that moves an expression into an 
POST_INC-expression. GCC then ICE’s in df-scan.c since it expects REG_P to be 
true for POST_INC’s operand. aarch64_simd_mem_operand_p doesn’t seem to check 
POST_INC’s operand. Here is a patch that fixes this for me, although I am not 
sure if this is the right way to address this. GCC bootstraps and it causes no 
test regressions.

The documentation for POST_INC says that its operand has to be a MEM or a REG.
Anything else is invalid RTL.
AArch64 only supports REGs as an operand to POST_INC.
The existing implementation of aarch64_simd_lane_bounds indeed doesn't properly 
reject non-REG operands to
POST_INC, so I think your patch is correct, in that we should be tighter to 
make sure we don't accept any MEMs.
But you'll need an approval from an aarch64 maintainer before committing.

Thanks!


However, I suggest you check your pass to make sure it doesn't try to put any 
arbitrary RTL into a POST_INC, because
otherwise some other parts of the compiler might blow up.

Even if the pass then uses recog() to determine if this is still some valid 
instruction? Right now recog() succeeds with some arbitrary expression for 
POST_INC.


I think that's still dangerous. AFAIK RTL functions, including recog (),
are not obliged to handle invalid RTL gracefully (they can assume it 
doesn't get passed),
so there is at least a theoretical risk of something blowing up in the 
future.


Kyrill




Thanks,
Kyrill


Dominik

ChangeLog:
2017-10-31  Dominik Infuehr  

* config/aarch64/aarch64.c (aarch64_simd_mem_operand_p): Check
if register given as operand for POST_INC.

-

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index ed30b8c..bb61506 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11850,8 +11850,15 @@ aarch64_simd_lane_bounds (rtx operand, HOST_WIDE_INT 
low, HOST_WIDE_INT high,
  bool
  aarch64_simd_mem_operand_p (rtx op)
  {
-  return MEM_P (op) && (GET_CODE (XEXP (op, 0)) == POST_INC
-   || REG_P (XEXP (op, 0)));
+  if (!MEM_P (op))
+return false;
+
+  rtx opnd = XEXP (op, 0);
+
+  if (GET_CODE (opnd) == POST_INC)
+opnd = XEXP(opnd, 0);
+
+  return REG_P (opnd);
  }

  /* Emit a register copy from operand to operand, taking care not to

RE: [PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

Fixed.

-  i[34567]86-*-linux* | x86_64-*-linux*)
+  i[[34567]]86-*-linux* | x86_64-*-linux*)

Igor


> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: Tuesday, October 31, 2017 2:30 PM
> To: Tsimbalist, Igor V 
> Cc: Joseph Myers ; gcc-patches@gcc.gnu.org;
> Jeff Law ; i...@airs.com
> Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
> 
> On Okt 31 2017, "Tsimbalist, Igor V"  wrote:
> 
> > diff --git a/config/cet.m4 b/config/cet.m4
> > new file mode 100644
> > index 000..c903791
> > --- /dev/null
> > +++ b/config/cet.m4
> > @@ -0,0 +1,40 @@
> > +dnl
> > +dnl GCC_CET_FLAGS
> > +dnl(SHELL-CODE_HANDLER)
> > +dnl
> > +AC_DEFUN([GCC_CET_FLAGS],[dnl
> > +GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
> > +  permit yes|no|default)
> > +case "$host" in
> > +  i[34567]86-*-linux* | x86_64-*-linux*)
> 
> Missing quoting around [...].
> 
> Andreas.
> 
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

Re: [PATCH][AArch64] Restrict POST_INC operand in aarch64_simd_mem_operand_p to register

[Dominik Inführ]

> On 31 Oct 2017, at 15:47, Kyrill Tkachov  wrote:
> 
> 
> On 31/10/17 14:44, Dominik Inführ wrote:
>>> On 31 Oct 2017, at 15:10, Kyrill Tkachov  
>>> wrote:
>>> 
>>> [cc'ing aarch64 maintainers]
>>> 
>>> Hi Dominik,
>>> 
>>> On 31/10/17 13:47, Dominik Inführ wrote:
 Hi,
 
 I have a custom optimization pass, that moves an expression into an 
 POST_INC-expression. GCC then ICE’s in df-scan.c since it expects REG_P to 
 be true for POST_INC’s operand. aarch64_simd_mem_operand_p doesn’t seem to 
 check POST_INC’s operand. Here is a patch that fixes this for me, although 
 I am not sure if this is the right way to address this. GCC bootstraps and 
 it causes no test regressions.
>>> The documentation for POST_INC says that its operand has to be a MEM or a 
>>> REG.
>>> Anything else is invalid RTL.
>>> AArch64 only supports REGs as an operand to POST_INC.
>>> The existing implementation of aarch64_simd_lane_bounds indeed doesn't 
>>> properly reject non-REG operands to
>>> POST_INC, so I think your patch is correct, in that we should be tighter to 
>>> make sure we don't accept any MEMs.
>>> But you'll need an approval from an aarch64 maintainer before committing.
>> Thanks!
>> 
>>> However, I suggest you check your pass to make sure it doesn't try to put 
>>> any arbitrary RTL into a POST_INC, because
>>> otherwise some other parts of the compiler might blow up.
>> Even if the pass then uses recog() to determine if this is still some valid 
>> instruction? Right now recog() succeeds with some arbitrary expression for 
>> POST_INC.
> 
> I think that's still dangerous. AFAIK RTL functions, including recog (),
> are not obliged to handle invalid RTL gracefully (they can assume it doesn't 
> get passed),
> so there is at least a theoretical risk of something blowing up in the future.

Oh, thanks that’s good to know!

Dominik

> 
> Kyrill
> 
>> 
>>> Thanks,
>>> Kyrill
>>> 
 Dominik
 
 ChangeLog:
 2017-10-31  Dominik Infuehr  
 
* config/aarch64/aarch64.c (aarch64_simd_mem_operand_p): Check
if register given as operand for POST_INC.
 
 -
 
 diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
 index ed30b8c..bb61506 100644
 --- a/gcc/config/aarch64/aarch64.c
 +++ b/gcc/config/aarch64/aarch64.c
 @@ -11850,8 +11850,15 @@ aarch64_simd_lane_bounds (rtx operand, 
 HOST_WIDE_INT low, HOST_WIDE_INT high,
  bool
  aarch64_simd_mem_operand_p (rtx op)
  {
 -  return MEM_P (op) && (GET_CODE (XEXP (op, 0)) == POST_INC
 -   || REG_P (XEXP (op, 0)));
 +  if (!MEM_P (op))
 +return false;
 +
 +  rtx opnd = XEXP (op, 0);
 +
 +  if (GET_CODE (opnd) == POST_INC)
 +opnd = XEXP(opnd, 0);
 +
 +  return REG_P (opnd);
  }
 
  /* Emit a register copy from operand to operand, taking care not to



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH 07/22] Enable building libgcc with CET options.

[Andreas Schwab]

On Okt 31 2017, "Tsimbalist, Igor V"  wrote:

> Fixed.
>
> -  i[34567]86-*-linux* | x86_64-*-linux*)
> +  i[[34567]]86-*-linux* | x86_64-*-linux*)

Don't forget to regenerate all configure scripts.

Andreas.

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

Re: [PATCH] rs6000: Fix crash with big stack clash interval (PR82674)

[Jeff Law]

On 10/31/2017 03:41 AM, Segher Boessenkool wrote:
> If the user asks for a stack clash probe interval of 64kB, we currently
> generate a "stdu rX,-65536(r1)" instruction.  That instruction does not
> exist (the offset is a 16-bit signed number).  If the offset is too big
> we should force it into a register and generate a "stdux rX,rY,r1"
> instruction, instead.
> 
> Bootstrapped and regression checked on powerpc64-linux {-m32,-m64};
> committing to trunk.
> 
> 
> Segher
> 
> 
> 2017-10-31  Segher Boessenkool  
> 
>   PR target/82674
>   * config/rs6000/rs6000.md (allocate_stack): Force update interval
>   into a register if it does not fit into an immediate offset field.
:-)  That's one I had a fix for.  But the issues with large probing
intervals are much more serious.  In particular dealing with large
probing intervals for allocations in the prologue is a significantly
tougher problem due to the lack of a free hard reg.

jeff

RE: [PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

Ok, just did it :)

Igor


> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: Tuesday, October 31, 2017 4:00 PM
> To: Tsimbalist, Igor V 
> Cc: Joseph Myers ; gcc-patches@gcc.gnu.org;
> Jeff Law ; i...@airs.com
> Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
> 
> On Okt 31 2017, "Tsimbalist, Igor V"  wrote:
> 
> > Fixed.
> >
> > -  i[34567]86-*-linux* | x86_64-*-linux*)
> > +  i[[34567]]86-*-linux* | x86_64-*-linux*)
> 
> Don't forget to regenerate all configure scripts.
> 
> Andreas.
> 
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

Re: [PATCH 4/7] GCOV: add -j argument (human readable format).

[Martin Liška]

On 10/31/2017 03:35 PM, Nathan Sidwell wrote:

On 10/31/2017 10:04 AM, Martin Liška wrote:


Do you mean numbers a bit smaller than 1000 or bit bigger? Do you have an 
example that will
be handled in a different way?


A count like 999500 would have been scaled to 999.5 and then rounded to 1000.  
We'd print 1000k rather than 1M.


I see! Thank you for clarification.




I've adapted your code snippet.


thanks, this is ok.


Has been just installed.

Martin



nathan

Re: [PATCH] rs6000: Fix crash with big stack clash interval (PR82674)

[Segher Boessenkool]

On Tue, Oct 31, 2017 at 09:12:25AM -0600, Jeff Law wrote:
> On 10/31/2017 03:41 AM, Segher Boessenkool wrote:
> > If the user asks for a stack clash probe interval of 64kB, we currently
> > generate a "stdu rX,-65536(r1)" instruction.  That instruction does not
> > exist (the offset is a 16-bit signed number).  If the offset is too big
> > we should force it into a register and generate a "stdux rX,rY,r1"
> > instruction, instead.
> > 
> > Bootstrapped and regression checked on powerpc64-linux {-m32,-m64};
> > committing to trunk.
> > 
> > 
> > Segher
> > 
> > 
> > 2017-10-31  Segher Boessenkool  
> > 
> > PR target/82674
> > * config/rs6000/rs6000.md (allocate_stack): Force update interval
> > into a register if it does not fit into an immediate offset field.
> :-)  That's one I had a fix for.  But the issues with large probing
> intervals are much more serious.  In particular dealing with large
> probing intervals for allocations in the prologue is a significantly
> tougher problem due to the lack of a free hard reg.

Yes, but I haven't seen testcases for that?  The PR was just this.

We do have more than one register we can use here, FWIW.  It gets a
bit nasty because it depends on which ABI you're on exactly, which.


Segher

Re: [PATCH, rs6000] Add Power 9 support for vec_first builtins

[Carl Love]

GCC maintainers:

The patch has been updated to fix the typo and retested.  Unfortunately
the names of the builtins are rather long and unwieldy to begin with.  


Please let me know if the following patch is acceptable.  Thanks.

   Carl Love

-

gcc/ChangeLog:

2017-10-31  Carl Love  

* config/rs6000/rs6000-c.c: Add support for builtins:
unsigned int vec_first_match_index (vector signed char,
vector signed char);
unsigned int vec_first_match_index (vector unsigned char,
vector unsigned char);
unsigned int vec_first_match_index (vector signed int,
vector signed int);
unsigned int vec_first_match_index (vector unsigned int,
vector unsigned int);
unsigned int vec_first_match_index (vector signed short,
vector signed short);
unsigned int vec_first_match_index (vector unsigned short,
vector unsigned short);
unsigned int vec_first_match_or_eos_index (vector signed char,
   vector signed char);
unsigned int vec_first_match_or_eos_index (vector unsigned char,
   vector unsigned char);
unsigned int vec_first_match_or_eos_index (vector signed int,
   vector signed int);
unsigned int vec_first_match_or_eos_index (vector unsigned int,
   vector unsigned int);
unsigned int vec_first_match_or_eos_index (vector signed short,
   vector signed short);
unsigned int vec_first_match_or_eos_index (vector unsigned short,
   vector unsigned short);
unsigned int vec_first_mismatch_index (vector signed char,
   vector signed char);
unsigned int vec_first_mismatch_index (vector unsigned char,
   vector unsigned char);
unsigned int vec_first_mismatch_index (vector signed int,
   vector signed int);
unsigned int vec_first_mismatch_index (vector unsigned int,
   vector unsigned int);
unsigned int vec_first_mismatch_index (vector signed short,
   vector signed short);
unsigned int vec_first_mismatch_index (vector unsigned short,
   vector unsigned short);
unsigned int vec_first_mismatch_or_eos_index (vector signed char,
  vector signed char);
unsigned int vec_first_mismatch_or_eos_index (vector unsigned char,
  vector unsigned char);
unsigned int vec_first_mismatch_or_eos_index (vector signed int,
  vector signed int);
unsigned int vec_first_mismatch_or_eos_index (vector unsigned int,
  vector unsigned int);
unsigned int vec_first_mismatch_or_eos_index (vector signed short,
  vector signed short);
unsigned int vec_first_mismatch_or_eos_index (vector unsigned short,
  vector unsigned short);
* config/rs6000/rs6000-builtin.def (VFIRSTMATCHINDEX,
VFIRSTMATCHOREOSINDEX, VFIRSTMISMATCHINDEX, VFIRSTMISMATCHOREOSINDEX):
Add BU_P9V_AV_2 expansions for the builtins.
* config/rs6000/altivec.h (vec_first_match_index,
vec_first_mismatch_index, vec_first_match_or_eos_index,
vec_first_mismatch_or_eos_index): Add #defines for the builtins.
* config/rs6000/rs6000-protos.h (bytes_in_mode): Add extern
declaration.
* config/rs6000/rs6000.c (bytes_in_mode): Add function to return mode
size in bytes.
* config/rs6000/vsx.md: (first_match_index_,
first_match_or_eos_index_, first_mismatch_index_,
first_mismatch_or_eos_index_):  Add define expand to implement
the builtins.
(vctzlsbb_): Add mode field to define_insn for vctzlsbb.
* doc/extend.texi: Update the built-in documenation file for the new
built-in functions.

gcc/testsuite/ChangeLog:

2017-10-31  Carl Love  

* gcc.target/powerpc/builtins-6-p9-runnable.c: Add runnable test for
the new builtins.
---
 gcc/config/rs6000/altivec.h|4 +

[PATCH] GCOV: create one intermediate file per a gcno file (PR gcov-profile/82702).

[Martin Liška]

Hi.

This is partial revert of r246804 where I accidentally changed behavior so that 
each
intermediate file is written to a source file. That's not intended for example 
for header files.
As mentioned in documentation: "The output is a single ‘.gcov’ file per ‘.gcda’ 
file".
Outer loop in main function must be changed and intermediate files should be 
processed one by one
(process_file + generate_results). On the contrary, for normal mode, we first 
process all files
and then print gcov file for all seen source files.

Patch survives gcov.exp test suite.

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2017-10-31  Martin Liska  

PR gcov-profile/82702
* gcov.c (main): Handle intermediate files in a different
way.
(get_gcov_intermediate_filename): New function.
(output_gcov_file): Remove support of intermediate files.
(generate_results): Allocate intermediate file.
(release_structures): Clean-up properly fn_end.
---
 gcc/gcov.c | 114 -
 1 file changed, 91 insertions(+), 23 deletions(-)


diff --git a/gcc/gcov.c b/gcc/gcov.c
index f1ecf94..979ca183d7e 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -708,17 +708,31 @@ main (int argc, char **argv)
 
   first_arg = argno;
 
-  for (; argno != argc; argno++)
+  if (flag_intermediate_format)
 {
-  if (flag_display_progress)
-	printf ("Processing file %d out of %d\n", argno - first_arg + 1,
-		argc - first_arg);
-  process_file (argv[argno]);
+  for (; argno != argc; argno++)
+	{
+	  if (flag_display_progress)
+	printf ("Processing file %d out of %d\n", argno - first_arg + 1,
+		argc - first_arg);
+	  process_file (argv[argno]);
+	  generate_results (argv[argno]);
+	  release_structures ();
+	}
 }
+  else
+{
+  for (; argno != argc; argno++)
+	{
+	  if (flag_display_progress)
+	printf ("Processing file %d out of %d\n", argno - first_arg + 1,
+		argc - first_arg);
+	  process_file (argv[argno]);
+	}
 
-  generate_results (multiple_files ? NULL : argv[argc - 1]);
-
-  release_structures ();
+  generate_results (multiple_files ? NULL : argv[argc - 1]);
+  release_structures ();
+}
 
   return 0;
 }
@@ -880,6 +894,31 @@ process_args (int argc, char **argv)
   return optind;
 }
 
+/* Get the name of the gcov file.  The return value must be free'd.
+
+   It appends the '.gcov' extension to the *basename* of the file.
+   The resulting file name will be in PWD.
+
+   e.g.,
+   input: foo.da,   output: foo.da.gcov
+   input: a/b/foo.cc,   output: foo.cc.gcov  */
+
+static char *
+get_gcov_intermediate_filename (const char *file_name)
+{
+  const char *gcov = ".gcov";
+  char *result;
+  const char *cptr;
+
+  /* Find the 'basename'.  */
+  cptr = lbasename (file_name);
+
+  result = XNEWVEC (char, strlen (cptr) + strlen (gcov) + 1);
+  sprintf (result, "%s%s", cptr, gcov);
+
+  return result;
+}
+
 /* Output the result in intermediate format used by 'lcov'.
 
 The intermediate format contains a single file named 'foo.cc.gcov',
@@ -1018,19 +1057,16 @@ output_gcov_file (const char *file_name, source_info *src)
 {
   FILE *gcov_file = fopen (gcov_file_name, "w");
   if (gcov_file)
-{
-  fnotice (stdout, "Creating '%s'\n", gcov_file_name);
-
-	  if (flag_intermediate_format)
-	output_intermediate_file (gcov_file, src);
-	  else
-	output_lines (gcov_file, src);
-  if (ferror (gcov_file))
-fnotice (stderr, "Error writing output file '%s'\n", gcov_file_name);
-  fclose (gcov_file);
-}
+	{
+	  fnotice (stdout, "Creating '%s'\n", gcov_file_name);
+	  output_lines (gcov_file, src);
+	  if (ferror (gcov_file))
+	fnotice (stderr, "Error writing output file '%s'\n",
+		 gcov_file_name);
+	  fclose (gcov_file);
+	}
   else
-fnotice (stderr, "Could not open output file '%s'\n", gcov_file_name);
+	fnotice (stderr, "Could not open output file '%s'\n", gcov_file_name);
 }
   else
 {
@@ -1044,6 +1080,8 @@ static void
 generate_results (const char *file_name)
 {
   function_t *fn;
+  FILE *gcov_intermediate_file = NULL;
+  char *gcov_intermediate_filename = NULL;
 
   for (fn = functions; fn; fn = fn->next)
 {
@@ -1072,6 +1110,19 @@ generate_results (const char *file_name)
 	file_name = canonicalize_name (file_name);
 }
 
+  if (flag_gcov_file && flag_intermediate_format)
+{
+  /* Open the intermediate file.  */
+  gcov_intermediate_filename = get_gcov_intermediate_filename (file_name);
+  gcov_intermediate_file = fopen (gcov_intermediate_filename, "w");
+  if (!gcov_intermediate_file)
+	{
+	  fnotice (stderr, "Cannot open intermediate output file %s\n",
+		   gcov_intermediate_filename);
+	  return;
+	}
+}
+
   for (vector::iterator it = sources.begin ();
it != sources.end (); it++)
 {
@@ -1096,9 +1147,21 @@ generate_results (const char *file_name)
   total_executed += 

Re: [PATCH] rs6000: Fix crash with big stack clash interval (PR82674)

[Jeff Law]

On 10/31/2017 09:32 AM, Segher Boessenkool wrote:
> On Tue, Oct 31, 2017 at 09:12:25AM -0600, Jeff Law wrote:
>> On 10/31/2017 03:41 AM, Segher Boessenkool wrote:
>>> If the user asks for a stack clash probe interval of 64kB, we currently
>>> generate a "stdu rX,-65536(r1)" instruction.  That instruction does not
>>> exist (the offset is a 16-bit signed number).  If the offset is too big
>>> we should force it into a register and generate a "stdux rX,rY,r1"
>>> instruction, instead.
>>>
>>> Bootstrapped and regression checked on powerpc64-linux {-m32,-m64};
>>> committing to trunk.
>>>
>>>
>>> Segher
>>>
>>>
>>> 2017-10-31  Segher Boessenkool  
>>>
>>> PR target/82674
>>> * config/rs6000/rs6000.md (allocate_stack): Force update interval
>>> into a register if it does not fit into an immediate offset field.
>> :-)  That's one I had a fix for.  But the issues with large probing
>> intervals are much more serious.  In particular dealing with large
>> probing intervals for allocations in the prologue is a significantly
>> tougher problem due to the lack of a free hard reg.
> 
> Yes, but I haven't seen testcases for that?  The PR was just this.
 :-)  I just turned stack clash on by default, cranked up the probing
interval and ran the testsuite and started looking at the root cause of
the failures.


> 
> We do have more than one register we can use here, FWIW.  It gets a
> bit nasty because it depends on which ABI you're on exactly, which.
BIg sigh...  There are times I wonder if I'd be happier as an app
developer or database junkie.  Instead I chose to do low level stuff :(



jeff

Re: [PATCH, rs6000] Add Power 9 support for vec_first builtins

[Jakub Jelinek]

On Tue, Oct 31, 2017 at 08:46:09AM -0700, Carl Love wrote:
> 2017-10-31  Carl Love  
> 
>   * config/rs6000/rs6000-c.c: Add support for builtins:
>   unsigned int vec_first_match_index (vector signed char,
>   vector signed char);

...  The ChangeLog IMHO is not.  It should be something like:
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add support
for vec_first_{,mis}match_{,or_eos_}index builtins with
vector {,un}signed {char,short,int} arguments.

Note (altivec_overloaded_builtins) to say what you've changed and
then just a sentence (in which IMHO wildcards are fine, but function
arguments in a way you wrote are not, because it is confusing with
what ()s mean in ChangeLog entry.

>   * config/rs6000/rs6000-builtin.def (VFIRSTMATCHINDEX,
>   VFIRSTMATCHOREOSINDEX, VFIRSTMISMATCHINDEX, VFIRSTMISMATCHOREOSINDEX):
>   Add BU_P9V_AV_2 expansions for the builtins.
>   * config/rs6000/altivec.h (vec_first_match_index,
>   vec_first_mismatch_index, vec_first_match_or_eos_index,
>   vec_first_mismatch_or_eos_index): Add #defines for the builtins.
>   * config/rs6000/rs6000-protos.h (bytes_in_mode): Add extern
>   declaration.

New declaration. ?

>   * config/rs6000/rs6000.c (bytes_in_mode): Add function to return mode
>   size in bytes.

New function. ? You don't need to explain what the function is for in
ChangeLog.

>   * config/rs6000/vsx.md: (first_match_index_,

No : between filename and (what changed), please.

>   first_match_or_eos_index_, first_mismatch_index_,
>   first_mismatch_or_eos_index_):  Add define expand to implement
>   the builtins.
>   (vctzlsbb_): Add mode field to define_insn for vctzlsbb.
>   * doc/extend.texi: Update the built-in documenation file for the new
>   built-in functions.
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-10-31  Carl Love  
> 
>   * gcc.target/powerpc/builtins-6-p9-runnable.c: Add runnable test for
>   the new builtins.

New test.
Again, don't explain what the test is for.

For the rest I'll defer to PowerPC maintainers.

Jakub

Re: [006/nnn] poly_int: tree constants

[Martin Sebor]

On 10/30/2017 04:19 AM, Pedro Alves wrote:

On 10/27/2017 12:29 AM, Martin Sebor wrote:



IMO, a good rule of thumb to follow in class design is to have
every class with any user-defined ctor either define a default
ctor that puts the object into a determinate state, or make
the default ctor inaccessible (or deleted in new C++ versions).
If there is a use case for leaving newly constructed objects
of a class in an uninitialized state that's an exception to
the rule that can be accommodated by providing a special API
(or in C++ 11, a defaulted ctor).


Yet another rule of thumb is to make classes that model
built-in types behave as close to the built-in types as
possible, making it easier to migrate between the custom
types and the built-in types (and vice versa), to follow
expectations, and to avoid pessimization around e.g., otherwise
useless forcing initialization of such types in containers/arrays
when you're going to immediately fill in the container/array with
real values.

BTW, there's a proposal for adding a wide_int class to C++20:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0539r1.html

and I noticed:

~~~
  26.??.2.?? wide_integer constructors [numeric.wide_integer.cons]

  constexpr wide_integer() noexcept = default;

  Effects: A Constructs an object with undefined value.
~~~


Thanks for the reference.  As I said in an earlier reply, this
would make sense to me if we could use C++ 11 or later.  Unlike
a no-op default ctor, the = default constructor provides syntax
to initialize the object, so both the safe use case and the
efficient one are supported.  I.e., the proposed wide_int is
zero-initialized by using the 'wide_int()' syntax.  The GCC
wide int and poly_int classes, on the other hand, are left in
an indeterminate state.  That's a bug waiting to happen (as I
already experienced with offset_int.)

Martin

Re: [PATCH, AArch64] Disable reg offset in quad-word store for Falkor.

[Jim Wilson]

On Tue, 2017-10-31 at 14:35 +1100, Kugan Vivekanandarajah wrote:
> Ping ?
> 
> I see that Jim has clarified the comments from Andrew.

Andrew also suggested that we add a testcase to the testsuite.  I
didn't do that.  I did put a testcase to reproduce in the bug report.
 See
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82533
It should be a relatively simple matter of taking that testcase,
compiling to assembly with -mcpu=falkor, then doing a pattern search
for a str q [r+r] instruction, and fail if it is present.

Jim

Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals)

[Mukesh Kapoor]

On 10/25/2017 6:44 PM, Mukesh Kapoor wrote:

On 10/25/2017 4:20 AM, Nathan Sidwell wrote:

On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:

Thanks for pointing this out. Checking in the front end will be 
difficult because the front end gets tokens after macro expansion. I 
think the difficulty of fixing this bug comes because of the 
requirement to maintain backward compatibility with the option 
-Wliteral-suffix for -std=c++11.


IIUC the warning's intent is to catch cases of:
printf ("some format"PRIx64 ..., ...);
where there's no space between the string literals and the PRIx64 
macro.  I suspect it's very common for there to be a following 
string-literal, so perhaps the preprocessor could detect:


NON-FN-MACRO

and warn on that sequence?


Yes, this can be done easily and this is also the usage mentioned in 
the man page. I made this change in the compiler, bootstrapped it and 
ran the tests. The following two tests fail after the fix:


g++.dg/cpp0x/Wliteral-suffix.C
g++.dg/cpp0x/warn_cxx0x4.C

Both tests have code similar to the following (from Wliteral-suffix.C):

#define BAR "bar"
#define PLUS_ONE + 1

  char c = '3'PLUS_ONE;   // { dg-warning "invalid suffix on literal" }
  char s[] = "foo"BAR;    // { dg-warning "invalid suffix on literal" }

Other compilers don't accept this code. Maybe I should just modify 
these tests to have error messages instead of warnings and submit my 
revised fix?


Actually, according to the man page for -Wliteral-suffix, only macro 
names that don't start with an underscore should be considered when 
issuing a warning:


   -Wliteral-suffix (C++ and Objective-C++ only)
   Warn when a string or character literal is followed by a 
ud-suffix

   which does not begin with an underscore...

So the fix is simply to check if the macro name in is_macro() starts 
with an underscore. The function is_macro() is called only at three 
places. At two places it's used to check for the warning related to 
-Wliteral-suffix and the check for underscore should be made for these 
two cases; at one place it is used to check for the warning related to 
-Wc++11-compat and there is no need to check for underscore for this case.


The fix is simply to pass a bool flag as an additional argument to 
is_macro() to decide whether the macro name starts with an underscore or 
not. I have tested the attached patch on x86_64-linux. Thanks.


Mukesh
/libcpp
2017-10-31  Mukesh Kapoor   

PR c++/80955
* lex.c (lex_string): Add an argument, 'bool no_underscore', to
is_macro(). If no_underscore is true, check if the macro name
starts with an underscore and return false if it does.
If no_underscore is false, don't check for underscore. 
is_macro() is called at three places. At two places it's used to
check for the warning related to -Wliteral-suffix and the check for
underscore is made for these two cases. At one place it's used to
check for the warning related to -Wc++11-compat and the check for
underscore is not made for this case.

/testsuite
2017-10-31  Mukesh Kapoor   

PR c++/80955
* g++.dg/cpp0x/udlit-macros.C: New.

Index: gcc/testsuite/g++.dg/cpp0x/udlit-macros.C
===
--- gcc/testsuite/g++.dg/cpp0x/udlit-macros.C   (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/udlit-macros.C   (working copy)
@@ -0,0 +1,31 @@
+// PR c++/80955
+// { dg-do compile { target c++11 } }
+
+#define __STDC_FORMAT_MACROS
+#include 
+#include 
+#include 
+
+using size_t = decltype(sizeof(0));
+#define _zero
+#define _ID _xx
+int operator""_zero(const char*, size_t) { return 0; }
+int operator""_ID(const char*, size_t) { return 0; }
+
+int main()
+{
+  int64_t i64 = 123;
+  char buf[100];
+  sprintf(buf, "%"PRId64"abc", i64);  // { dg-warning "invalid suffix on 
literal" }
+  return strcmp(buf, "123abc")
++ ""_zero
++ "bob"_zero
++ R"#(raw
+  string)#"_zero
++ "xx"_ID
++ ""_ID
++ R"AA(another
+   raw
+   string)AA"_ID;
+}
+
Index: libcpp/lex.c
===
--- libcpp/lex.c(revision 254048)
+++ libcpp/lex.c(working copy)
@@ -1576,14 +1576,17 @@
 
 
 /* Returns true if a macro has been defined.
+   If no_underscore is true, check that the macro
+   name does not start with underscore.
This might not work if compile with -save-temps,
or preprocess separately from compilation.  */
 
 static bool
-is_macro(cpp_reader *pfile, const uchar *base)
+is_macro(cpp_reader *pfile, const uchar *base, bool no_underscore)
 {
   const uchar *cur = base;
-  if (! ISIDST (*cur))
+  bool invalid_ident = (no_underscore ? ! ISALPHA (*cur) : ! ISIDST (*cur));
+  if (invalid_ident)
 return false;
   unsigned int hash = HT_HASHSTEP (0, *cur);
   ++cur;
@@ -1872,7 +1875,7 @@
 a string literal it could be p

[C++ PATCH] overloaded operator fns [3/N]

[Nathan Sidwell]

This patch replaces the operator info 'arity' field with a 'flags' field 
that encodes more information.  Adjusted the few places that look at 
this.  More use will be made in future patches.


nathan

--
Nathan Sidwell
2017-10-31  Nathan Sidwell  

	* cp-tree.h (enum ovl_op_flags): New.
	(struct operator_name_info_t): Rename arity to flags.
	* lex.c (set_operator_ident): New.
	(init_operators): Use it.  Adjust for flags.
	* mangle.c (write_unqualified_id): Adjust for flags.
	* operators.def: Replace arity with flags.

Index: cp-tree.h
===
--- cp-tree.h	(revision 254267)
+++ cp-tree.h	(working copy)
@@ -5474,16 +5474,27 @@ enum auto_deduction_context
 
 extern void init_reswords (void);
 
-typedef struct GTY(()) operator_name_info_t {
+/* Various flags for the overloaded operator information.  */
+enum ovl_op_flags
+  {
+OVL_OP_FLAG_NONE = 0,
+OVL_OP_FLAG_UNARY = 1,
+OVL_OP_FLAG_BINARY = 2,
+OVL_OP_FLAG_ALLOC = 4,  	/* operator new or delete  */
+OVL_OP_FLAG_DELETE = 1,	/* operator delete  */
+OVL_OP_FLAG_VEC = 2		/* vector new or delete  */
+  };
+
+struct GTY(()) operator_name_info_t {
   /* The IDENTIFIER_NODE for the operator.  */
   tree identifier;
   /* The name of the operator.  */
   const char *name;
   /* The mangled name of the operator.  */
   const char *mangled_name;
-  /* The arity of the operator.  */
-  int arity;
-} operator_name_info_t;
+  /* The ovl_op_flags of the operator */
+  unsigned flags : 8;
+};
 
 /* A mapping from tree codes to operator name information.  */
 extern GTY(()) operator_name_info_t operator_name_info
Index: lex.c
===
--- lex.c	(revision 254263)
+++ lex.c	(working copy)
@@ -82,13 +82,6 @@ operator_name_info_t operator_name_info[
 /* Similar, but for assignment operators.  */
 operator_name_info_t assignment_operator_name_info[(int) MAX_TREE_CODES];
 
-/* Initialize data structures that keep track of operator names.  */
-
-#define DEF_OPERATOR(NAME, C, M, AR, AP) \
- CONSTRAINT (C, sizeof "operator " + sizeof NAME <= 256);
-#include "operators.def"
-#undef DEF_OPERATOR
-
 /* Get the name of the kind of identifier T.  */
 
 const char *
@@ -120,28 +113,40 @@ set_identifier_kind (tree id, cp_identif
   IDENTIFIER_KIND_BIT_0 (id) |= (kind >> 0) & 1;
 }
 
+/* Create and tag the internal operator name for the overloaded
+   operator PTR describes.  */
+
+static tree
+set_operator_ident (operator_name_info_t *ptr)
+{
+  char buffer[32];
+  size_t len = snprintf (buffer, sizeof (buffer), "operator%s%s",
+			 &" "[ptr->name[0] && ptr->name[0] != '_'
+			  && !ISALPHA (ptr->name[0])],
+			 ptr->name);
+  gcc_checking_assert (len < sizeof (buffer));
+
+  tree ident = get_identifier_with_length (buffer, len);
+  ptr->identifier = ident;
+
+  return ident;
+}
+
 static void
 init_operators (void)
 {
   tree identifier;
-  char buffer[256];
-  struct operator_name_info_t *oni;
+  operator_name_info_t *oni;
 
-#define DEF_OPERATOR(NAME, CODE, MANGLING, ARITY, KIND)			\
-  sprintf (buffer, "operator%s%s", !NAME[0]\
-	   || NAME[0] == '_' || ISALPHA (NAME[0]) ? " " : "", NAME);	\
-  identifier = get_identifier (buffer);	\
-	\
-  if (KIND != cik_simple_op || !IDENTIFIER_ANY_OP_P (identifier))	\
-set_identifier_kind (identifier, KIND);\
-  	\
-  oni = (KIND == cik_assign_op		\
-	 ? &assignment_operator_name_info[(int) CODE]			\
-	 : &operator_name_info[(int) CODE]);\
-  oni->identifier = identifier;		\
+#define DEF_OPERATOR(NAME, CODE, MANGLING, FLAGS, KIND)			\
+  oni = OVL_OP_INFO (KIND == cik_assign_op, CODE);			\
   oni->name = NAME;			\
   oni->mangled_name = MANGLING;		\
-  oni->arity = ARITY;
+  oni->flags = FLAGS;			\
+  identifier = set_operator_ident (oni);\
+	\
+  if (KIND != cik_simple_op || !IDENTIFIER_ANY_OP_P (identifier))	\
+set_identifier_kind (identifier, KIND);
 
 #include "operators.def"
 #undef DEF_OPERATOR
Index: mangle.c
===
--- mangle.c	(revision 254267)
+++ mangle.c	(working copy)
@@ -1276,7 +1276,7 @@ write_unqualified_id (tree identifier)
 	  {
 	/* The ABI says that we prefer binary operator
 	   names to unary operator names.  */
-	if (operator_name_info[i].arity == 2)
+	if (operator_name_info[i].flags == OVL_OP_FLAG_BINARY)
 	  {
 		mangled_name = operator_name_info[i].mangled_name;
 		break;
Index: operators.def
===
--- operators.def	(revision 254263)
+++ operators.def	(working copy)
@@ -45,11 +45,10 @@ along with GCC; see the file COPYING3.
  mangled under the new ABI.  For `operator +', for example, this
  would be "pl".
 
-   ARITY
+   FLAGS
 
- The arity of the operator, or -1 if any arity is allowed.  (As
- for `operator ()'.)  Postincrement and postdecrement ope

RE: [PATCH 21/22] Enable building libitm with Intel CET

[Tsimbalist, Igor V]

Actually I did changes to add the new field for linux under ifdef __linux__.

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, October 31, 2017 12:21 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: trie...@redhat.com
> Subject: Re: [PATCH 21/22] Enable building libitm with Intel CET
> 
> On 10/12/2017 03:21 PM, Tsimbalist, Igor V wrote:
> > Enable building libitm with Intel CET options.
> >
> > libitm/
> > * Makefile.in: Regenerate.
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * config/x86/sjlj.S
> > (_ITM_beginTransaction): Save Shadow Stack pointer.
> > (GTM_longjmp): Restore Shadow Stack pointer.
> > * config/x86/target.h (struct gtm_jmpbuf):
> > Add Shadow Stack pointer.
> > * configure: Regenerate.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS, libtool_VERSION.
> > * testsuite/Makefile.in: Regenerate.
> >
> > * config/cet.m4: Define ENABLE_CET_COMPATIBILITY. Set
> > enable_cet_compatibility.
> >
> Would it make sense to avoid having different sizes of gtm_jmpbuf by
> simply having the ssp slot always defined, even if we're not using it?

Yes, it make sense. We can do it for x86 configuration. In that case the
conditional code will be limited to Shadow Stack pointer read/write.

> Along the same lines, would it make sense to have that field at the end
> of the structure so that the amount of conditional code in in sjlj.S is
> minimized (ie, all the offests are the same, so in the CET case you just
> have a single extra store).

The comments says the buffer is specially located in such a way that eip/rip
field overlap with  a return address on the stack. That means the field can be
added anywhere before eip/rip and in turn the offsets will change.

I will re-implement the fixes with adding the new field for x86 only.

Igor

> 
> Jeff

Re: [patch, fortran] Index interchange for FORALL and DO CONCURRENT

[Bernhard Reutner-Fischer]

On Tue, Oct 31, 2017 at 02:24:39PM +0100, Thomas Koenig wrote:
> Hello world,
> 
> here is a version of the patch for index interchange for FORALL
> and DO CONCURRENT that I would like to commit.
> 
> It introduces a new option for selecting (or deselecting)
> the option, -ffrontend-loop-interchange.  The reason for
> this is simple: It is always possible that the heurisics in the
> patch might make a bad choice, and the user should be able to
> deselect this optimization when he has already optimized loop
> ordering in his code.  The new option is selected when
> optimizing, the same way that -ffrontend-optimize is.
> 
> No test case because I could not think of anything
> that could test the nesting of loops.
> 
> Regression-tested. OK for trunk?

s/shoud/should/; s/acessed/accessed/; s/indces/indices/;
why are struct ind_type "n" and "num" int and not unsigned int?

Can't you scan the original dump for something characteristic?
Or maybe emit diagnostics into the frontend optimize dump file and scan
that?

thanks,

Re: [PATCH PR79868 ][aarch64] Fix error calls in aarch64 code so they can be translated (version 2)

[Steve Ellcey]

On Tue, 2017-10-31 at 09:57 +, Richard Earnshaw (lists) wrote:
> 
> This is looking better...
> 
> I may have missed some discussion on this topic, but what's the
> reasoning behind changing the quoting around the 'str' parameter
> value in
> 
> - error ("unknown value %qs for 'cpu' target %s", str,
> pragma_or_attr);
> + error ("invalid name (\"%s\") in % pragma
> or
> attribute", str);
> 
> And also with the new generic message does the %
> still make sense?  My feeling is that the original text here is perhaps
> more appropriate.  Similarly for other messages.
> 
> R.


%qs uses single quotes vs. double quotes, changing that was suggested
by Martin Sebor in this comment:

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01569.html

using '%' was also suggested by Martin in that
same thread at:

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01277.html
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01469.html

as being more consistent with other usage (mainly config/i386/i386.c).

Steve Ellcey
sell...@cavium.com

[PATCH][AArch64] Define MALLOC_ABI_ALIGNMENT

[Wilco Dijkstra]

The AArch64 backend currently doesn't set MALLOC_ABI_ALIGNMENT, so
add this to enable alignment optimizations on malloc pointers.

OK for commit?

2017-10-31  Wilco Dijkstra  

* config/aarch64/aarch64.h (MALLOC_ABI_ALIGNMENT): New define.
--
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 
8e7093f0476fa7fed3ba6d6cb008743106d1ff58..159dde7c7134d4d0e5378951d1d8a1d6dab48ba2
 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -111,6 +111,9 @@
 
 #define STRUCTURE_SIZE_BOUNDARY8
 
+/* Heap alignment.  */
+#define MALLOC_ABI_ALIGNMENT  BIGGEST_ALIGNMENT
+
 /* Defined by the ABI */
 #define WCHAR_TYPE "unsigned int"
 #define WCHAR_TYPE_SIZE32

Re: RFA: PATCH to tell gdb to skip over is-a.h inlines

[Jason Merrill]

On Thu, Apr 28, 2016 at 3:04 PM, Jason Merrill  wrote:
> On 04/25/2016 01:28 PM, Jason Merrill wrote:
>>
>> There doesn't seem to be any need to step through the is-a inline
>> functions.  OK for trunk?
>
> Likewise line-map.h.

And timevar.h.

Jason
commit b2476880463deb5da5547dfb50eafe4d1a38cf64
Author: Jason Merrill 
Date:   Fri Oct 20 16:11:39 2017 -0400

* gdbinit.in: Skip over inlines from timevar.h.

diff --git a/gcc/gdbinit.in b/gcc/gdbinit.in
index be56b0ee25b..3e1279e5b2a 100644
--- a/gcc/gdbinit.in
+++ b/gcc/gdbinit.in
@@ -252,6 +252,9 @@ skip file is-a.h
 # And line-map.h.
 skip file line-map.h
 
+# And timevar.h.
+skip file timevar.h
+
 # Likewise, skip various inline functions in rtl.h.
 skip rtx_expr_list::next
 skip rtx_expr_list::element

Re: [09/nn] Add a fixed_size_mode_pod class

[Eric Botcazou]

> I don't see a reason not to other than a pretty small amount of work
> each time we make a release.

I'm not sure it would be so small an amount of work, especially on non-Linux 
platforms, so this would IMO divert our resources for little benefit.

> Well first this would only matter to the 0.01% of people who want to do
> that on AIX or Solaris machines, not the vast majority of possible
> contributors who already use clang or gcc as there system compiler.

Yes, but we're GCC, not Clang, and we support more than Linux and Darwin.

> Thirdly making it easier to work on the compiler and understand it makes
> things easier for those possible contributors, so if being able to use
> C++11 advances that goalthings could be better over all for possible
> contributors with different system compilers.

I don't buy this at all.  You don't need bleeding edge C++ features to build a 
compiler and people don't work on compilers to use bleeding edge C++.  Using a 
narrow and sensible set of C++ features was one of the conditions under which 
the switch to C++ as implementation language was accepted at the time.

-- 
Eric Botcazou

Re: [PATCH][GCC][testsuite][mid-end][ARM][AARCH64] Fix failing vec align tests.

[James Greenhalgh]

On Mon, Oct 23, 2017 at 10:37:39AM +0100, Tamar Christina wrote:
> Ping

OK for backport, but I'm not sure why you want to backport a patch which
you know is going to break something.

When you commit, just roll everything up in to one patch, rather than three
patches, two of which cause breaks.

Reviewed-by: James Greenhalgh 

Thanks,
James

> 
> From: Tamar Christina
> Sent: Monday, October 16, 2017 11:17 AM
> To: Christophe Lyon
> Cc: Rainer Orth; gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard 
> Earnshaw; Marcus Shawcroft
> Subject: Re: [PATCH][GCC][testsuite][mid-end][ARM][AARCH64] Fix failing vec 
> align tests.
> 
> Hi All,
> 
> I've submitted a patch to fix this 
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00971.html
> 
> Permission (just as the new patch) to backport these test changes to
> GCC 7 to fix the regressions there?
> 
> Thanks,
> Tamar.
> 
> From: Christophe Lyon 
> Sent: Friday, October 6, 2017 5:07:44 PM
> To: Tamar Christina
> Cc: Rainer Orth; gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard 
> Earnshaw; Marcus Shawcroft
> Subject: Re: [PATCH][GCC][testsuite][mid-end][ARM][AARCH64] Fix failing vec 
> align tests.
> 
> On 6 October 2017 at 09:45, Tamar Christina  wrote:
> >
> >
> >> -Original Message-
> >> From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
> >> Sent: 05 October 2017 20:16
> >> To: Tamar Christina
> >> Cc: gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard Earnshaw;
> >> Marcus Shawcroft
> >> Subject: Re: [PATCH][GCC][testsuite][mid-end][ARM][AARCH64] Fix failing
> >> vec align tests.
> >>
> >> Hi Tamar,
> >>
> >> > Previously I had corrected the vect_hw_misalign check which prompted
> >> > these three test to start failing because the condition needs to be
> >> > inverted in the testcases.
> >> >
> >> > Regtested on aarch64-none-elf, arm-none-linux-gnueabihf and x86_64-pc-
> >> linux-gnu.
> >> >
> >> > Ok for trunk?
> >> >
> >> > Thanks,
> >> > Tamar.
> >> >
> >> > gcc/testsuite/
> >> > 2017-10-02  Tamar Christina  
> >> >
> >> > * gcc.dg/vect/vect-align-1.c: Fix vect_hw_misalign condition.
> >> > * gcc.dg/vect/vect-align-2.c: Likewise.
> >> > * gcc.dg/vect/vect-multitypes-1.c: Likewise.
> >>
> >> unfortunately, your patch caused gcc.dg/vect/vect-multitypes-1.c to FAIL on
> >> sparc-sun-solaris2.11 (32 and 64-bit):
> >>
> >> FAIL: gcc.dg/vect/vect-multitypes-1.c -flto -ffat-lto-objects  
> >> scan-tree-dump-
> >> times vect "Vectorizing an unaligned access" 4
> >> FAIL: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect
> >> "Vectorizing an unaligned access" 4
> >
> > Thanks! I'll take a look.
> >
> 
> If that's easier for you, I've noticed the same thing on
> armeb-none-linux-gnueabihf
> --with-mode arm
> --with-cpu cortex-a9
> --with-fpu neon-fp16
> 
> Christophe
> 
> 
> > Tamar
> >
> >>
> >> It had XFAILed before.
> >>
> >>   Rainer
> >>
> >> --
> >> -
> >> Rainer Orth, Center for Biotechnology, Bielefeld University

[Ada] Fix PR ada/82785

[Eric Botcazou]

Small typo libgnarl->libgnat.  Applied on the mainline.


2017-10-31  Eric Botcazou  

PR ada/82785
* gcc-interface/Makefile.in (m68k/Linux): Fix typo.

-- 
Eric BotcazouIndex: gcc-interface/Makefile.in
===
--- gcc-interface/Makefile.in	(revision 254252)
+++ gcc-interface/Makefile.in	(working copy)
@@ -1629,7 +1629,7 @@ ifeq ($(strip $(filter-out m68k% linux%,
   a-intnam.ads

Re: [09/nn] Add a fixed_size_mode_pod class

[Jeff Law]

On 10/31/2017 11:22 AM, Eric Botcazou wrote:
>> I don't see a reason not to other than a pretty small amount of work
>> each time we make a release.
> 
> I'm not sure it would be so small an amount of work, especially on non-Linux 
> platforms, so this would IMO divert our resources for little benefit.
Having done this for years on HPUX, yes, it takes more time than one
could imagine.  THen I went to work for a company that did this for
hpux, solaris, aix, irix and others and well, it was very painful.

> 
>> Well first this would only matter to the 0.01% of people who want to do
>> that on AIX or Solaris machines, not the vast majority of possible
>> contributors who already use clang or gcc as there system compiler.
> 
> Yes, but we're GCC, not Clang, and we support more than Linux and Darwin.
Very true.

> 
>> Thirdly making it easier to work on the compiler and understand it makes
>> things easier for those possible contributors, so if being able to use
>> C++11 advances that goalthings could be better over all for possible
>> contributors with different system compilers.
> 
> I don't buy this at all.  You don't need bleeding edge C++ features to build 
> a 
> compiler and people don't work on compilers to use bleeding edge C++.  Using 
> a 
> narrow and sensible set of C++ features was one of the conditions under which 
> the switch to C++ as implementation language was accepted at the time.
Agreed that we need to stick with a sensible set of features.  But the
sensible set isn't necessarily fixed forever.

Jeff

Re: [PATCH] PR debug/81570: dwarf2cfi.c: Update cfa.offset in create_pseudo_cfg

[H.J. Lu]

On Tue, Oct 24, 2017 at 8:26 PM, Jason Merrill  wrote:
> On Thu, Jul 27, 2017 at 3:50 PM, H.J. Lu  wrote:
>> execute_dwarf2_frame is called for each funtion.  But create_cie_data
>> is called only once to initialize cie_cfi_row for all functions.  Since
>> INCOMING_FRAME_SP_OFFSET may be different for each function, we can't
>> use the same INCOMING_FRAME_SP_OFFSET in cie_cfi_row for all functions.
>> This patch sets cie_cfi_row->cfa.offset to INCOMING_FRAME_SP_OFFSET in
>> create_pseudo_cfg which is called for each function.
>>
>> Tested on x86-64.  OK for trunk?
>
> This looks wrong.  cie_cfi_row is the state produced by the
> instructions in the CIE, which don't vary between functions.  If

/* The state of the first row of the FDE table, which includes the
   state provided by the CIE.  */
static GTY(()) dw_cfi_row *cie_cfi_row;

cie_cfi_row is created by

  cie_cfi_row = cur_row = new_cfi_row ();

  /* On entry, the Canonical Frame Address is at SP.  */
  memset (&loc, 0, sizeof (loc));
  loc.reg = dw_stack_pointer_regnum;
  loc.offset = INCOMING_FRAME_SP_OFFSET;
  def_cfa_1 (&loc);

and used by create_pseudo_cfg

  ti.beg_row = cie_cfi_row;
  ti.cfa_store = cie_cfi_row->cfa;

The problem is that the offset field in cie_cfi_row->cfa may not be the same for
all functions.  cie_cfi_row does change in this case.  My patch simply corrects
the offset in CFA of the first row of the FDE table.

> INCOMING_FRAME_SP_OFFSET varies, we need to add actual FDE
> instructions to reflect that, not just clobber our current model of
> what the CIE means.
>
> Jason



-- 
H.J.

Re: [01/nn] [AArch64] Generate permute patterns using rtx builders

[James Greenhalgh]

On Fri, Oct 27, 2017 at 02:22:39PM +0100, Richard Sandiford wrote:
> This patch replaces switch statements that call specific generator
> functions with code that constructs the rtl pattern directly.
> This seemed to scale better to SVE and also seems less error-prone.
> 
> As a side-effect, the patch fixes the REV handling for diff==1,
> vmode==E_V4HFmode and adds missing support for diff==3,
> vmode==E_V4HFmode.
> 
> To compensate for the lack of switches that check for specific modes,
> the patch makes aarch64_expand_vec_perm_const_1 reject permutes on
> single-element vectors (specifically V1DImode).

OK.

Would you mind placing a comment somewhere near both the unspecs, and the
patterns using these unspecs to warn that the calls constructing the
RTX here *MUST* be kept in sync?

Some of these patterns are probably used rarely enough that we could easily
miss an unreconizable insn.

Reviewed-by: James Greenhalgh 

Thanks,
James

> 
> 
> 2017-10-27  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * config/aarch64/aarch64.c (aarch64_evpc_trn, aarch64_evpc_uzp)
>   (aarch64_evpc_zip, aarch64_evpc_ext, aarch64_evpc_rev)
>   (aarch64_evpc_dup): Generate rtl direcly, rather than using
>   named expanders.
>   (aarch64_expand_vec_perm_const_1): Explicitly check for permutes
>   of a single element.
> 

Re: [02/nn] [AArch64] Move code around

[James Greenhalgh]

On Fri, Oct 27, 2017 at 02:23:30PM +0100, Richard Sandiford wrote:
> This patch simply moves code around, in order to make the later
> patches easier to read, and to avoid forward declarations.
> It doesn't add the missing function comments because the interfaces
> will change in a later patch.

OK.

Reviewed-by: James Greenhalgh 

Thanks,
James

> 
> 
> 2017-10-26  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * config/aarch64/aarch64.c (aarch64_add_constant_internal)
>   (aarch64_add_constant, aarch64_add_sp, aarch64_sub_sp): Move
>   earlier in file.
> 

Re: [04/nn] [AArch64] Rename the internal "Upl" constraint

[James Greenhalgh]

On Fri, Oct 27, 2017 at 02:25:56PM +0100, Richard Sandiford wrote:
> The SVE port uses the public constraints "Upl" and "Upa" to mean
> "low predicate register" and "any predicate register" respectively.
> "Upl" was already used as an internal-only constraint by the
> addition patterns, so this patch renames it to "Uaa" ("two adds
> needed").

OK.

Reviewed-By: James Greenhalgh  

Thanks,
James

> 
> 
> 2017-10-27  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * config/aarch64/constraints.md (Upl): Rename to...
>   (Uaa): ...this.
>   * config/aarch64/aarch64.md
>   (*zero_extend2_aarch64, *addsi3_aarch64_uxtw):
>   Update accordingly.
> 
> Index: gcc/config/aarch64/constraints.md
> ===
> --- gcc/config/aarch64/constraints.md 2017-10-27 14:06:16.159815485 +0100
> +++ gcc/config/aarch64/constraints.md 2017-10-27 14:11:54.071011147 +0100
> @@ -35,7 +35,7 @@ (define_constraint "I"
>   (and (match_code "const_int")
>(match_test "aarch64_uimm12_shift (ival)")))
>  
> -(define_constraint "Upl"
> +(define_constraint "Uaa"
>"@internal A constant that matches two uses of add instructions."
>(and (match_code "const_int")
> (match_test "aarch64_pluslong_strict_immedate (op, VOIDmode)")))
> Index: gcc/config/aarch64/aarch64.md
> ===
> --- gcc/config/aarch64/aarch64.md 2017-10-27 14:07:01.875769946 +0100
> +++ gcc/config/aarch64/aarch64.md 2017-10-27 14:11:54.071011147 +0100
> @@ -1562,7 +1562,7 @@ (define_insn "*add3_aarch64"
>  (match_operand:GPI 0 "register_operand" "=rk,rk,w,rk,r")
>  (plus:GPI
>   (match_operand:GPI 1 "register_operand" "%rk,rk,w,rk,rk")
> - (match_operand:GPI 2 "aarch64_pluslong_operand" "I,r,w,J,Upl")))]
> + (match_operand:GPI 2 "aarch64_pluslong_operand" "I,r,w,J,Uaa")))]
>""
>"@
>add\\t%0, %1, %2
> @@ -1580,7 +1580,7 @@ (define_insn "*addsi3_aarch64_uxtw"
>  (match_operand:DI 0 "register_operand" "=rk,rk,rk,r")
>  (zero_extend:DI
>   (plus:SI (match_operand:SI 1 "register_operand" "%rk,rk,rk,rk")
> -  (match_operand:SI 2 "aarch64_pluslong_operand" "I,r,J,Upl"]
> +   (match_operand:SI 2 "aarch64_pluslong_operand" "I,r,J,Uaa"]
>""
>"@
>add\\t%w0, %w1, %2

Re: [PATCH, version 5a], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Michael Meissner]

On Mon, Oct 30, 2017 at 11:30:12PM +, Joseph Myers wrote:
> On Mon, 30 Oct 2017, Michael Meissner wrote:
> 
> > This patch fixes exporting the non __builtin_ names to be done by default 
> > only
> > for the C language.  I added a target hook in case a port needs to enable
> > built-ins for C++ (either wholesale, or for particular built-in functions).
> 
> Testing lang_GNU_C () can't possibly be correct here; ObjC should always 
> be handled like C unless there is a strong reason not to do so, explicitly 
> commented.
> 
> Also, I'd expect the FALLBACK_P argument to DEF_BUILTIN to be true, not a 
> call to the hook; __builtin_sqrtf128 should always end up generating a 
> call to the out-of-line sqrtf128 function if not inlined, regardless of 
> source language.

This patch fixes both issues.  I have done bootstrap builds on both a little
endian power8 and an x86-64 system with no regressions.  Can I check this into
the trunk?

Assuming the following patch is ok, I have another patch that is awaiting
review:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02124.html

2017-10-31  Michael Meissner  

* builtins.def (DEF_FLOATN_BUILTIN): Change most _Float and
_FloatX built-in functions so that the variant without the
"__builtin_" prefix is only enabled for the GNU C and Objective C
languages when they are in non-strict ANSI/ISO mode.
(DEF_EXT_LIB_FLOATN_NX_BUILTINS): Likewise.
* target.def (floatn_builtin_p): Add a target hook to control
whether _Float and _FloatX built-in functions without the
"__builtin_" prefix are enabled, and return true for C and
Objective C in the default hook.  Include langhooks.h in
targhooks.c.
* targhooks.h (default_floatn_builtin_p): Likewise.
* targhooks.c (default_floatn_builtin_p): Likewise.
* doc/tm.texi.in (TARGET_FLOATN_BUILTIN_P): Document the
floatn_builtin_p target hook.
* doc/tm.texi (TARGET_FLOATN_BUILTIN_P): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/builtins.def
===
--- gcc/builtins.def(revision 254243)
+++ gcc/builtins.def(working copy)
@@ -130,18 +130,26 @@ along with GCC; see the file COPYING3.
 
 /* A set of GCC builtins for _FloatN and _FloatNx types.  TYPE_MACRO is called
with an argument such as FLOAT32 to produce the enum value for the type.  If
-   we are being fully conformant we ignore the version of these builtins that
-   does not being with __builtin_.  */
+   we are compiling for the C language with GNU extensions, we enable the name
+   without the __builtin_ prefix as well as the name with the __builtin_
+   prefix.  C++ does not enable these names by default because they don't have
+   the _Float and _FloatX keywords, and a class based library should use
+   the __builtin_ names.  */
+#undef DEF_FLOATN_BUILTIN
+#define DEF_FLOATN_BUILTIN(ENUM, NAME, TYPE, ATTRS)\
+  DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_NORMAL, TYPE, TYPE,   \
+  targetm.floatn_builtin_p ((int) ENUM), true, true, ATTRS, \
+  false, true)
 #undef DEF_EXT_LIB_FLOATN_NX_BUILTINS
-#define DEF_EXT_LIB_FLOATN_NX_BUILTINS(ENUM, NAME, TYPE_MACRO, ATTRS)  
\
-  DEF_EXT_LIB_BUILTIN (ENUM ## F16, NAME "f16", TYPE_MACRO (FLOAT16), ATTRS) \
-  DEF_EXT_LIB_BUILTIN (ENUM ## F32, NAME "f32", TYPE_MACRO (FLOAT32), ATTRS) \
-  DEF_EXT_LIB_BUILTIN (ENUM ## F64, NAME "f64", TYPE_MACRO (FLOAT64), ATTRS) \
-  DEF_EXT_LIB_BUILTIN (ENUM ## F128, NAME "f128", TYPE_MACRO (FLOAT128), 
ATTRS)\
-  DEF_EXT_LIB_BUILTIN (ENUM ## F32X, NAME "f32x", TYPE_MACRO (FLOAT32X), 
ATTRS)\
-  DEF_EXT_LIB_BUILTIN (ENUM ## F64X, NAME "f64x", TYPE_MACRO (FLOAT64X), 
ATTRS)\
-  DEF_EXT_LIB_BUILTIN (ENUM ## F128X, NAME "f128x", TYPE_MACRO (FLOAT128X), \
-   ATTRS)
+#define DEF_EXT_LIB_FLOATN_NX_BUILTINS(ENUM, NAME, TYPE_MACRO, ATTRS)  \
+  DEF_FLOATN_BUILTIN (ENUM ## F16, NAME "f16", TYPE_MACRO (FLOAT16), ATTRS) \
+  DEF_FLOATN_BUILTIN (ENUM ## F32, NAME "f32", TYPE_MACRO (FLOAT32), ATTRS) \
+  DEF_FLOATN_BUILTIN (ENUM ## F64, NAME "f64", TYPE_MACRO (FLOAT64), ATTRS) \
+  DEF_FLOATN_BUILTIN (ENUM ## F128, NAME "f128", TYPE_MACRO (FLOAT128), ATTRS) 
\
+  DEF_FLOATN_BUILTIN (ENUM ## F32X, NAME "f32x", TYPE_MACRO (FLOAT32X), ATTRS) 
\
+  DEF_FLOATN_BUILTIN (ENUM ## F64X, NAME "f64x", TYPE_MACRO (FLOAT64X), ATTRS) 
\
+  DEF_FLOATN_BUILTIN (ENUM ## F128X, NAME "f128x", TYPE_MACRO (FLOAT128X), \
+ ATTRS)
 
 /* Like DEF_LIB_BUILTIN, except that the function is only a part of
the standard in C94 or above.  */
Index: gcc/target.def
===
--- gcc/target.def  (revision 254243)
+++ gcc/target.def  (working copy)
@@ -3458,6 +3458,19 @@ if @var{extended} is false, 16 

Re: [10/nn] [AArch64] Minor rtx costs tweak

[James Greenhalgh]

On Fri, Oct 27, 2017 at 02:30:18PM +0100, Richard Sandiford wrote:
> aarch64_rtx_costs uses the number of registers in a mode as the basis
> of SET costs.  This patch makes it get the number of registers from
> aarch64_hard_regno_nregs rather than repeating the calcalation inline.
> Handling SVE modes in aarch64_hard_regno_nregs is then enough to get
> the correct SET cost as well.

OK.

Reviewed-By: James Greenhalgh  

Thanks,
James

> 
> 
> 2017-10-27  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * config/aarch64/aarch64.c (aarch64_rtx_costs): Use
>   aarch64_hard_regno_nregs to get the number of registers
>   in a mode.
> 

Re: [PATCH, version 5a], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Joseph Myers]

On Tue, 31 Oct 2017, Michael Meissner wrote:

> On Mon, Oct 30, 2017 at 11:30:12PM +, Joseph Myers wrote:
> > On Mon, 30 Oct 2017, Michael Meissner wrote:
> > 
> > > This patch fixes exporting the non __builtin_ names to be done by default 
> > > only
> > > for the C language.  I added a target hook in case a port needs to enable
> > > built-ins for C++ (either wholesale, or for particular built-in 
> > > functions).
> > 
> > Testing lang_GNU_C () can't possibly be correct here; ObjC should always 
> > be handled like C unless there is a strong reason not to do so, explicitly 
> > commented.
> > 
> > Also, I'd expect the FALLBACK_P argument to DEF_BUILTIN to be true, not a 
> > call to the hook; __builtin_sqrtf128 should always end up generating a 
> > call to the out-of-line sqrtf128 function if not inlined, regardless of 
> > source language.
> 
> This patch fixes both issues.  I have done bootstrap builds on both a little
> endian power8 and an x86-64 system with no regressions.  Can I check this into
> the trunk?

All the references to "enum builtin_in_function", in comments and 
documentation, should be "enum built_in_function".  OK with that change.

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

Re: [PATCH v3] Add asan and ubsan support on NetBSD/amd64

[Kamil Rytarowski]

On 31.10.2017 15:04, Jakub Jelinek wrote:
> On Tue, Oct 31, 2017 at 02:53:26PM +0100, Kamil Rytarowski wrote:
 http://netbsd.org/~kamil/gcc/test_summary.log.8-20171022.txt
>>>
>>> That seems that asan pretty much doesn't work at all in GCC for netbsd.
>>> A few FAILs might be acceptable, but so many FAILs certainly aren't.
>>> The testsuite doesn't use python, at least not for *san testing nor
>>> test_summary, so that shouldn't be the problem.  If it is asan/ubsan tests
>>> that are hanging, that is something that needs to be debugged and understood
>>> why it hangs.
>>>
>>
>> It is similar in LLVM, where it works against statically linked .a files
>> with sanitizers. For .so, I can observe similar information about
>> DEADLYSIGNAL without detailed information.
> 
> But dynamic linking of libasan or libubsan is the default in gcc, so
> it needs to work out of the box.
> Note gcc/config/gnu-user.h has:
> /* Link -lasan early on the command line.  For -static-libasan, don't link
>it for -shared link, the executable should be compiled with -static-libasan
>in that case, and for executable link with --{,no-}whole-archive around
>it to force everything into the executable.  And similarly for -ltsan
>and -llsan.  */
> #if defined(HAVE_LD_STATIC_DYNAMIC)
> #undef LIBASAN_EARLY_SPEC
> #define LIBASAN_EARLY_SPEC "%{!shared:libasan_preinit%O%s} " \
>   "%{static-libasan:%{!shared:" \
>   LD_STATIC_OPTION " --whole-archive -lasan --no-whole-archive " \
>   LD_DYNAMIC_OPTION "}}%{!static-libasan:-lasan}"
> #undef LIBTSAN_EARLY_SPEC
> #define LIBTSAN_EARLY_SPEC "%{!shared:libtsan_preinit%O%s} " \
>   "%{static-libtsan:%{!shared:" \
>   LD_STATIC_OPTION " --whole-archive -ltsan --no-whole-archive " \
>   LD_DYNAMIC_OPTION "}}%{!static-libtsan:-ltsan}"
> #undef LIBLSAN_EARLY_SPEC
> #define LIBLSAN_EARLY_SPEC "%{!shared:liblsan_preinit%O%s} " \
>   "%{static-liblsan:%{!shared:" \
>   LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \
>   LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}"
> #endif
> 
> which might need to be duplicated into gcc/config/netbsd-elf.h.
> 
>   Jakub
> 


I'm giving it a try. I took the asan part and skipped
"%{!shared:libasan_preinit%O%s} ". If I understand this correctly, it
attempts to use the ELF section with preinit property in order to
bootstrap asan quickly. The preinit sections are not enabled on
NetBSD/amd64. From my understanding, there is a design choice in NetBSD
to not include extensional sections unless they are requested by ABI.


$NetBSD$

--- ./gcc/config/netbsd-elf.h.orig  2017-01-01 12:07:43.0 +
+++ ./gcc/config/netbsd-elf.h
@@ -85,3 +85,16 @@ along with GCC; see the file COPYING3.
 #ifdef HAVE_LD_AS_NEEDED
 #define USE_LD_AS_NEEDED 1
 #endif
+
+/* Link -lasan early on the command line.  For -static-libasan, don't link
+   it for -shared link, the executable should be compiled with
-static-libasan
+   in that case, and for executable link with --{,no-}whole-archive around
+   it to force everything into the executable.  And similarly for -ltsan
+   and -llsan.  */
+#if defined(HAVE_LD_STATIC_DYNAMIC)
+#undef LIBASAN_EARLY_SPEC
+#define LIBASAN_EARLY_SPEC \
+  "%{static-libasan:%{!shared:" \
+  LD_STATIC_OPTION " --whole-archive -lasan --no-whole-archive " \
+  LD_DYNAMIC_OPTION "}}%{!static-libasan:-lasan}"
+#endif





signature.asc
Description: OpenPGP digital signature

Fix PR rtl-optimization/81803

[Eric Botcazou]

This is a regression present on the mainline and 7 branch for little-endian 
64-bit MIPS platforms under the form of incorrect spill/reload pairs generated 
by the LRA pass, i.e. for which the spill instruction is a narrower access 
than the reload instruction.  That's incorrect for accesses no wider than a 
word on WORD_REGISTER_OPERATIONS target because all the bits up to the word 
size need to be preserved.

The attached patch fixes the problem by mimicing in curr_insn_transform what 
push_reload does for SUBREGs no wider than a word for WORD_REGISTER_OPERATIONS 
targets, i.e. reloading the whole register and not just the subreg.

Tested on SPARC64/Linux and ARM/EABI (both WORD_REGISTER_OPERATIONS targets).
Unfortunately I don't have access to MIPS hardware anymore and the PR doesn't 
contain any executable testcase.

Applied on the mainline only for now.


2017-10-31  Matthew Fortune  
Eric Botcazou  

PR rtl-optimization/81803
* lra-constraints.c (curr_insn_transform): Also reload the whole
register for a strict subreg no wider than a word if this is for
a WORD_REGISTER_OPERATIONS target.

-- 
Eric BotcazouIndex: lra-constraints.c
===
--- lra-constraints.c	(revision 254193)
+++ lra-constraints.c	(working copy)
@@ -4207,8 +4207,9 @@ curr_insn_transform (bool check_only_p)
 	  reg = SUBREG_REG (*loc);
 	  byte = SUBREG_BYTE (*loc);
 	  if (REG_P (reg)
-		  /* Strict_low_part requires reload the register not
-		 the sub-register.	*/
+		  /* Strict_low_part requires reloading the register and not
+		 just the subreg.  Likewise for a strict subreg no wider
+		 than a word for WORD_REGISTER_OPERATIONS targets.  */
 		  && (curr_static_id->operand[i].strict_low
 		  || (!paradoxical_subreg_p (mode, GET_MODE (reg))
 			  && (hard_regno
@@ -4219,7 +4220,11 @@ curr_insn_transform (bool check_only_p)
 			  && (goal_alt[i] == NO_REGS
 			  || (simplify_subreg_regno
   (ira_class_hard_regs[goal_alt[i]][0],
-   GET_MODE (reg), byte, mode) >= 0)
+   GET_MODE (reg), byte, mode) >= 0)))
+		  || (GET_MODE_PRECISION (mode)
+			  < GET_MODE_PRECISION (GET_MODE (reg))
+			  && GET_MODE_SIZE (GET_MODE (reg)) <= UNITS_PER_WORD
+			  && WORD_REGISTER_OPERATIONS)))
 		{
 		  /* An OP_INOUT is required when reloading a subreg of a
 		 mode wider than a word to ensure that data beyond the

[C++ PATCH] overloaded operator fns [4/N]

[Nathan Sidwell]

The overloaded operator table conflates a couple of things -- both 
mangling and special names.  Entries just for mangling do not need a 
special name.  This sets them to NULL and no associated identifier is 
created.  init_operators created a bunch of pseudo entries, ostensibly 
'because errors', with a comment that we shouldn't be generating them. 
Turns out we don't appear to be using them, so also nuked.


nathan

--
Nathan Sidwell
2017-10-31  Nathan Sidwell  

	* lex.c (init_operators): Allow NULL operator name.  Don't add
	special cases.
	* operators.def: Use NULL for mangling only operators.  Move to
	after regular operators but move assignment operators last.

Index: lex.c
===
--- lex.c	(revision 254271)
+++ lex.c	(working copy)
@@ -143,48 +143,14 @@ init_operators (void)
   oni->name = NAME;			\
   oni->mangled_name = MANGLING;		\
   oni->flags = FLAGS;			\
-  identifier = set_operator_ident (oni);\
-	\
-  if (KIND != cik_simple_op || !IDENTIFIER_ANY_OP_P (identifier))	\
-set_identifier_kind (identifier, KIND);
+  if (NAME) {\
+identifier = set_operator_ident (oni);\
+if (KIND != cik_simple_op || !IDENTIFIER_ANY_OP_P (identifier))	\
+  set_identifier_kind (identifier, KIND);\
+  }
 
 #include "operators.def"
 #undef DEF_OPERATOR
-
-  operator_name_info[(int) TYPE_EXPR] = operator_name_info[(int) CAST_EXPR];
-  operator_name_info[(int) ERROR_MARK].identifier
-= get_identifier ("");
-
-  /* Handle some special cases.  These operators are not defined in
- the language, but can be produced internally.  We may need them
- for error-reporting.  (Eventually, we should ensure that this
- does not happen.  Error messages involving these operators will
- be confusing to users.)  */
-
-  operator_name_info [(int) INIT_EXPR].name
-= operator_name_info [(int) MODIFY_EXPR].name;
-
-  operator_name_info [(int) EXACT_DIV_EXPR].name = "(ceiling /)";
-  operator_name_info [(int) CEIL_DIV_EXPR].name = "(ceiling /)";
-  operator_name_info [(int) FLOOR_DIV_EXPR].name = "(floor /)";
-  operator_name_info [(int) ROUND_DIV_EXPR].name = "(round /)";
-  operator_name_info [(int) CEIL_MOD_EXPR].name = "(ceiling %)";
-  operator_name_info [(int) FLOOR_MOD_EXPR].name = "(floor %)";
-  operator_name_info [(int) ROUND_MOD_EXPR].name = "(round %)";
-
-  operator_name_info [(int) ABS_EXPR].name = "abs";
-  operator_name_info [(int) TRUTH_AND_EXPR].name = "strict &&";
-  operator_name_info [(int) TRUTH_OR_EXPR].name = "strict ||";
-  operator_name_info [(int) RANGE_EXPR].name = "...";
-  operator_name_info [(int) UNARY_PLUS_EXPR].name = "+";
-
-  assignment_operator_name_info [(int) EXACT_DIV_EXPR].name = "(exact /=)";
-  assignment_operator_name_info [(int) CEIL_DIV_EXPR].name = "(ceiling /=)";
-  assignment_operator_name_info [(int) FLOOR_DIV_EXPR].name = "(floor /=)";
-  assignment_operator_name_info [(int) ROUND_DIV_EXPR].name = "(round /=)";
-  assignment_operator_name_info [(int) CEIL_MOD_EXPR].name = "(ceiling %=)";
-  assignment_operator_name_info [(int) FLOOR_MOD_EXPR].name = "(floor %=)";
-  assignment_operator_name_info [(int) ROUND_MOD_EXPR].name = "(round %=)";
 }
 
 /* Initialize the reserved words.  */
Index: operators.def
===
--- operators.def	(revision 254271)
+++ operators.def	(working copy)
@@ -100,13 +100,6 @@ DEF_SIMPLE_OPERATOR ("alignof", ALIGNOF_
 DEF_SIMPLE_OPERATOR ("__imag__", IMAGPART_EXPR, "v18__imag__", OVL_OP_FLAG_UNARY)
 DEF_SIMPLE_OPERATOR ("__real__", REALPART_EXPR, "v18__real__", OVL_OP_FLAG_UNARY)
 
-/* The cast operators.  */
-DEF_SIMPLE_OPERATOR ("", CAST_EXPR, "cv", OVL_OP_FLAG_UNARY)
-DEF_SIMPLE_OPERATOR ("dynamic_cast", DYNAMIC_CAST_EXPR, "dc", OVL_OP_FLAG_UNARY)
-DEF_SIMPLE_OPERATOR ("reinterpret_cast", REINTERPRET_CAST_EXPR, "rc", OVL_OP_FLAG_UNARY)
-DEF_SIMPLE_OPERATOR ("const_cast", CONST_CAST_EXPR, "cc", OVL_OP_FLAG_UNARY)
-DEF_SIMPLE_OPERATOR ("static_cast", STATIC_CAST_EXPR, "sc", OVL_OP_FLAG_UNARY)
-
 /* Binary operators.  */
 DEF_SIMPLE_OPERATOR ("+", PLUS_EXPR, "pl", OVL_OP_FLAG_BINARY)
 DEF_SIMPLE_OPERATOR ("-", MINUS_EXPR, "mi", OVL_OP_FLAG_BINARY)
@@ -133,8 +126,23 @@ DEF_SIMPLE_OPERATOR ("->", COMPONENT_REF
 DEF_SIMPLE_OPERATOR ("[]", ARRAY_REF, "ix", OVL_OP_FLAG_BINARY)
 DEF_SIMPLE_OPERATOR ("++", POSTINCREMENT_EXPR, "pp", OVL_OP_FLAG_BINARY)
 DEF_SIMPLE_OPERATOR ("--", POSTDECREMENT_EXPR, "mm", OVL_OP_FLAG_BINARY)
-/* This one is needed for mangling.  */
-DEF_SIMPLE_OPERATOR ("::", SCOPE_REF, "sr", OVL_OP_FLAG_BINARY)
+
+/* Miscellaneous.  */
+DEF_SIMPLE_OPERATOR ("?:", COND_EXPR, "qu", OVL_OP_FLAG_NONE)
+DEF_SIMPLE_OPERATOR ("()", CALL_EXPR, "cl", OVL_OP_FLAG_NONE)
+
+/* Operators needed for mangling.  */
+DEF_SIMPLE_OPERATOR (NULL, CAST_EXPR, "cv", OVL_OP_FLAG_NONE)
+DEF_SIMPLE_OPERATOR (NULL, DYNAMIC_CAST_EXPR, "dc", OVL_OP_FLAG_NONE)
+DEF_SIMPLE_OPERATOR (NULL, REINT

Re: [PATCH v3] Add asan and ubsan support on NetBSD/amd64

[Jakub Jelinek]

On Tue, Oct 31, 2017 at 07:28:23PM +0100, Kamil Rytarowski wrote:
> I'm giving it a try. I took the asan part and skipped
> "%{!shared:libasan_preinit%O%s} ". If I understand this correctly, it
> attempts to use the ELF section with preinit property in order to
> bootstrap asan quickly. The preinit sections are not enabled on
> NetBSD/amd64. From my understanding, there is a design choice in NetBSD
> to not include extensional sections unless they are requested by ABI.

??  SHT_PREINIT_ARRAY/DT_PREINIT_ARRAY/DT_PREINIT_ARRAYSZ is not any
kind of extension, it is an integral part of the ELF gABI:
http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#dynamic_section
And that is quite essential for proper asan behavior, because the library
interposes a lot of functions and if they are invoked before the library
is initialized, they crash (of course better would be to fix the library
not to rely on that and initialize the minimal stuff needed for
interposition if they are called before the initialization, but that is
unlikely to happen upstream).

Jakub

Re: [PATCH][AArch64] Improve aarch64_legitimate_constant_p

[Wilco Dijkstra]

James Greenhalgh wrote:

> This is mostly OK, but I think you lose one case we previosuly permitted,
> buried in aarch64_classify_address (the CONST case).
> 
> OK with that case handled too (assuming that passes a bootstrap and test).

That case is already handled. The CONST case handles the constant addresses,
and the remaining ones are LABEL_REFs, which is also handled. So I don't see
what case could be missing...

I've tweaked the code to use split_const like elsewhere:

2017-10-31  Wilco Dijkstra  

* config/aarch64/aarch64.c (aarch64_legitimate_constant_p):
Return true for more constants, symbols and label references.
(aarch64_valid_floating_const): Remove unused function.

--
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 
6ab6092e1e518460e69d4c59ce5c1717f996f3db..1d7a5102d4f9f4dc9d4658df466231c47e3ca165
 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -10396,51 +10396,49 @@ aarch64_legitimate_pic_operand_p (rtx x)
   return true;
 }
 
-/* Return true if X holds either a quarter-precision or
- floating-point +0.0 constant.  */
-static bool
-aarch64_valid_floating_const (rtx x)
-{
-  if (!CONST_DOUBLE_P (x))
-return false;
-
-  /* This call determines which constants can be used in mov
- as integer moves instead of constant loads.  */
-  if (aarch64_float_const_rtx_p (x))
-return true;
-
-  return aarch64_float_const_representable_p (x);
-}
+/* Implement TARGET_LEGITIMATE_CONSTANT_P hook.  Return true for constants
+   that should be rematerialized rather than spilled.  */
 
 static bool
 aarch64_legitimate_constant_p (machine_mode mode, rtx x)
 {
+  /* Support CSE and rematerialization of common constants.  */
+  if (CONST_INT_P (x) || CONST_DOUBLE_P (x) || GET_CODE (x) == CONST_VECTOR)
+return true;
+
   /* Do not allow vector struct mode constants.  We could support
  0 and -1 easily, but they need support in aarch64-simd.md.  */
-  if (TARGET_SIMD && aarch64_vect_struct_mode_p (mode))
+  if (aarch64_vect_struct_mode_p (mode))
 return false;
 
-  /* For these cases we never want to use a literal load.
- As such we have to prevent the compiler from forcing these
- to memory.  */
-  if ((GET_CODE (x) == CONST_VECTOR
-   && aarch64_simd_valid_immediate (x, mode, false, NULL))
-  || CONST_INT_P (x)
-  || aarch64_valid_floating_const (x)
-  || aarch64_can_const_movi_rtx_p (x, mode)
-  || aarch64_float_const_rtx_p (x))
-   return !targetm.cannot_force_const_mem (mode, x);
+  /* Do not allow wide int constants - this requires support in movti.  */
+  if (CONST_WIDE_INT_P (x))
+return false;
 
-  if (GET_CODE (x) == HIGH
-  && aarch64_valid_symref (XEXP (x, 0), GET_MODE (XEXP (x, 0
-return true;
+  /* Do not allow const (plus (anchor_symbol, const_int)).  */
+  if (GET_CODE (x) == CONST)
+{
+  rtx offset;
+
+  split_const (x, &x, &offset);
+
+  if (SYMBOL_REF_P (x) && SYMBOL_REF_ANCHOR_P (x))
+   return false;
+}
+
+  if (GET_CODE (x) == HIGH)
+x = XEXP (x, 0);
 
   /* Treat symbols as constants.  Avoid TLS symbols as they are complex,
  so spilling them is better than rematerialization.  */
   if (SYMBOL_REF_P (x) && !SYMBOL_REF_TLS_MODEL (x))
 return true;
 
-  return aarch64_constant_address_p (x);
+  /* Label references are always constant.  */
+  if (GET_CODE (x) == LABEL_REF)
+return true;
+
+  return false;
 }
 
 rtx

Re: [PATCH v3] Add asan and ubsan support on NetBSD/amd64

[Kamil Rytarowski]

On 31.10.2017 19:45, Jakub Jelinek wrote:
> On Tue, Oct 31, 2017 at 07:28:23PM +0100, Kamil Rytarowski wrote:
>> I'm giving it a try. I took the asan part and skipped
>> "%{!shared:libasan_preinit%O%s} ". If I understand this correctly, it
>> attempts to use the ELF section with preinit property in order to
>> bootstrap asan quickly. The preinit sections are not enabled on
>> NetBSD/amd64. From my understanding, there is a design choice in NetBSD
>> to not include extensional sections unless they are requested by ABI.
> 
> ??  SHT_PREINIT_ARRAY/DT_PREINIT_ARRAY/DT_PREINIT_ARRAYSZ is not any
> kind of extension, it is an integral part of the ELF gABI:
> http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#dynamic_section
> And that is quite essential for proper asan behavior, because the library
> interposes a lot of functions and if they are invoked before the library
> is initialized, they crash (of course better would be to fix the library
> not to rely on that and initialize the minimal stuff needed for
> interposition if they are called before the initialization, but that is
> unlikely to happen upstream).
> 
>   Jakub
> 

Right now this is only Linux-specific at least in asan/LLVM.

// We can use .preinit_array section on Linux to call sanitizer
initialization
// functions very early in the process startup (unless PIC macro is
defined).
// FIXME: do we have anything like this on Mac?
#if SANITIZER_LINUX && !SANITIZER_ANDROID && !defined(PIC)
# define SANITIZER_CAN_USE_PREINIT_ARRAY 1
#else
# define SANITIZER_CAN_USE_PREINIT_ARRAY 0
#endif

-- lib/sanitizer_common/sanitizer_internal_defs.h

NetBSD needs to use different ways to initialize, like through
interception of a call and during this stage bootstrap initialization
bits. The tricky part is that we cannot initialize a sanitizer before
sufficient libc+libpthread bootstrap and this is my current obstacle
with tsan.

Specifying new LIBASAN_EARLY_SPEC does not fix the "AddressSanitizer can
not provide additional info." problem.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH,RFC] collect2 LTO for AIX

[David Edelsohn]

On Mon, Oct 30, 2017 at 3:13 PM, Jeff Law  wrote:
> On 10/13/2017 12:04 PM, David Edelsohn wrote:
>> The attached patch is an incremental step toward GCC LTO on AIX.  The
>> recent Libiberty Simple Object improvements for XCOFF provide more
>> capabilities for operations on XCOFF object files, which are a
>> prerequisite for GCC LTO functionality.
>>
>> This patch adds the basic LTO scanning pass to the COFF support in
>> collect2.  I don't believe that this change should affect other COFF
>> targets adversely (do they even use collect2?), but I wanted to give
>> people an opportunity to comment.
> I honestly can't remember what the COFF targets do anymore :-)  Didn't
> we delete them all a while back?  I see that the generic COFF targets
> died back in gcc-4.4.

Jim,

With your recent removal of SDB and -gcoff support, I would appreciate
your advice about my patch to incrementally add some preliminary LTO
support for AIX to collect2.c:

https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00893.html

There don't seem to be any other COFF targets around that still use
the collect2 code to manually scan object and archive files. And I
don't think that they would be hurt by the additional search for the
LTO symbol.  I want to check if anyone is aware of a potential problem
before I commit the code.

Thanks, David

Re: [patch][x86] GFNI enabling [2/4]

[Jakub Jelinek]

On Mon, Oct 30, 2017 at 07:02:23PM +, Koval, Julia wrote:
> gcc/testsuite/
>   * gcc.target/i386/avx-1.c: Handle new intrinsics.
>   * gcc.target/i386/avx512-check.h: Check GFNI bit.
>   * gcc.target/i386/avx512f-gf2p8affineinvqb-2.c: Runtime test.
>   * gcc.target/i386/avx512vl-gf2p8affineinvqb-2.c: Runtime test.
>   * gcc.target/i386/gfni-1.c: New.
>   * gcc.target/i386/gfni-2.c: New.
>   * gcc.target/i386/gfni-3.c: New.
>   * gcc.target/i386/gfni-4.c: New.

The gfni-4.c testcase ICEs on i686-linux (e.g. try
make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-m32/-msse,-m32/-mno-sse,-m64\} 
i386.exp=gfni*'
to see it).

I must say I'm confused by the CPUIDs, the 
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
lists GFNI; 2x AVX+GFNI; 2x AVX512VL+GFNI; AVX512F+GFNI CPUIDs for the
instructions, but i386-builtins.def has:
BDESC (OPTION_MASK_ISA_GFNI, CODE_FOR_vgf2p8affineinvqb_v64qi, 
"__builtin_ia32_vgf2p8affineinvqb_v64qi", IX86_BUILTIN_VGF2P8AFFINEINVQB512, 
UNKNOWN
BDESC (OPTION_MASK_ISA_GFNI | OPTION_MASK_ISA_AVX512BW, 
CODE_FOR_vgf2p8affineinvqb_v64qi_mask, 
"__builtin_ia32_vgf2p8affineinvqb_v64qi_mask", IX86_
BDESC (OPTION_MASK_ISA_GFNI, CODE_FOR_vgf2p8affineinvqb_v32qi, 
"__builtin_ia32_vgf2p8affineinvqb_v32qi", IX86_BUILTIN_VGF2P8AFFINEINVQB256, 
UNKNOWN
BDESC (OPTION_MASK_ISA_GFNI | OPTION_MASK_ISA_AVX512BW, 
CODE_FOR_vgf2p8affineinvqb_v32qi_mask, 
"__builtin_ia32_vgf2p8affineinvqb_v32qi_mask", IX86_
BDESC (OPTION_MASK_ISA_GFNI, CODE_FOR_vgf2p8affineinvqb_v16qi, 
"__builtin_ia32_vgf2p8affineinvqb_v16qi", IX86_BUILTIN_VGF2P8AFFINEINVQB128, 
UNKNOWN
BDESC (OPTION_MASK_ISA_GFNI | OPTION_MASK_ISA_AVX512BW, 
CODE_FOR_vgf2p8affineinvqb_v16qi_mask, 
"__builtin_ia32_vgf2p8affineinvqb_v16qi_mask", IX86_
and the gfniintrin.h requires just gfni for the first insn,
and then some combinations of gfni,avx, or gfni,avx512vl, or
gfni,avx512vl,avx512bw, or gfni,avx512f,avx512bw.

So, what is right, the paper, i386-builtins.def or gfniintrin.h?

Obviously even if the GF2P8AFFINEINVQB instruction doesn't list SSE as
required CPUID, we can't really emit it without at least SSE because
then the operands can't be emitted.  So, at least in GCC we should
require both GFNI and SSE for the first instruction.

Which leads to another issue, as ix86_expand_builtin documents,
we treat the BDESC ISAs OPTION_MASK_ISA_ISA1 | OPTION_MASK_ISA_ISA2
as either ISA1 or ISA2, not ISA1 and ISA2.  The exceptions are
MMX, AVX512VL and 64BIT is also special.
So, shall GFNI be added to that set?  Do we have other ISAs that
should be handled the same?  I guess maybe OPTION_MASK_ISA_AES, but
that is handled weirdly.

Jakub

[C++ PATCH] overloaded operator fns [5/N]

[Nathan Sidwell]

This patch replaces the separate operator_name_info & 
assignment_operator_name_info arrays with a single 2D ovl_op_info array. 
 I also add a tree_code field to the renamed ovl_op_info_t, which 
although in this instance is simply a 1:1 mapping to the array index, 
will morph soon as the indices will not be by tree_code.


Although this tweaks the array scanning, the ultimate aim is that that 
scanning goes away, and a simple indirection gets us to what we want.


nathan

--
Nathan Sidwell
2017-10-31  Nathan Sidwell  

	* cp-tree.h (struct operator_name_info_t): Rename to ...
	(struct ovl_op_info_t): ... here.  Add tree_code field.
	(operator_name_info, assignment_operator_name_info): Delete.
	(ovl_op_info): Declare.
	(OVL_OP_INFO): Adjust.
	* decl.c (grok_op_properties): Use ovl_op_flags.
	* lex.c (operator_name_info, assignment_operator_name_info):
	Delete.
	(ovl_op_info): Define.
	(set_operator_ident): Adjust.
	(init_operators): Set tree_code.
	* mangle.c (write_unqualified_id): Adjust operator array scan.

Index: cp-tree.h
===
--- cp-tree.h	(revision 254271)
+++ cp-tree.h	(working copy)
@@ -5485,29 +5485,26 @@ enum ovl_op_flags
 OVL_OP_FLAG_VEC = 2		/* vector new or delete  */
   };
 
-struct GTY(()) operator_name_info_t {
+struct GTY(()) ovl_op_info_t {
   /* The IDENTIFIER_NODE for the operator.  */
   tree identifier;
   /* The name of the operator.  */
   const char *name;
   /* The mangled name of the operator.  */
   const char *mangled_name;
+  /* The tree code.  */
+  enum tree_code tree_code : 16;
   /* The ovl_op_flags of the operator */
   unsigned flags : 8;
 };
 
-/* A mapping from tree codes to operator name information.  */
-extern GTY(()) operator_name_info_t operator_name_info
-  [(int) MAX_TREE_CODES];
-/* Similar, but for assignment operators.  */
-extern GTY(()) operator_name_info_t assignment_operator_name_info
-  [(int) MAX_TREE_CODES];
+/* Overloaded operator info indexed by ass_op_p & tree_code.  */
+extern GTY(()) ovl_op_info_t ovl_op_info[2][MAX_TREE_CODES];
 
 /* Given an ass_op_p boolean and a tree code, return a pointer to its
overloaded operator info.  */
 #define OVL_OP_INFO(IS_ASS_P, TREE_CODE)			\
-  (((IS_ASS_P) ? assignment_operator_name_info : operator_name_info)	\
-   + (TREE_CODE))
+  (&ovl_op_info[(IS_ASS_P) != 0][(TREE_CODE)])
 
 /* A type-qualifier, or bitmask therefore, using the TYPE_QUAL
constants.  */
Index: decl.c
===
--- decl.c	(revision 254267)
+++ decl.c	(working copy)
@@ -12898,8 +12898,8 @@ unary_op_p (enum tree_code code)
 	  || code == TYPE_EXPR);
 }
 
-/* DECL is a declaration for an overloaded operator.  If COMPLAIN is true,
-   errors are issued for invalid declarations.  */
+/* DECL is a declaration for an overloaded or conversion operator.  If
+   COMPLAIN is true, errors are issued for invalid declarations.  */
 
 bool
 grok_op_properties (tree decl, bool complain)
@@ -12912,52 +12912,54 @@ grok_op_properties (tree decl, bool comp
   if (class_type && !CLASS_TYPE_P (class_type))
 class_type = NULL_TREE;
 
-  enum tree_code operator_code = ERROR_MARK;
+  tree_code operator_code = ERROR_MARK;
+  unsigned op_flags = OVL_OP_FLAG_NONE;
   if (IDENTIFIER_CONV_OP_P (name))
-operator_code = TYPE_EXPR;
+{
+  /* Conversion operators are TYPE_EXPR for the purposes of this
+	 function.  */
+  operator_code = TYPE_EXPR;
+  op_flags = OVL_OP_FLAG_UNARY;
+}
   else
 {
   /* It'd be nice to hang something else of the identifier to
 	 find CODE more directly.  */
   bool assign_op = IDENTIFIER_ASSIGN_OP_P (name);
-  const operator_name_info_t *oni
-	= (assign_op ? assignment_operator_name_info : operator_name_info);
-
+  const ovl_op_info_t *ovl_op = OVL_OP_INFO (assign_op, 0);
   if (false)
 	;
-#define DEF_OPERATOR(NAME, CODE, MANGLING, ARITY, KIND)		\
-  else if (assign_op == (KIND == cik_assign_op)		\
-	   && oni[int (CODE)].identifier == name)		\
+#define DEF_OPERATOR(NAME, CODE, MANGLING, FLAGS, KIND)		\
+  else if (ovl_op[CODE].identifier == name)			\
 	operator_code = (CODE);
 #include "operators.def"
 #undef DEF_OPERATOR
   else
 	gcc_unreachable ();
-  }
-while (0);
-  gcc_assert (operator_code != MAX_TREE_CODES);
-  DECL_OVERLOADED_OPERATOR_CODE (decl) = operator_code;
+  gcc_assert (operator_code != ERROR_MARK);
+  op_flags = ovl_op[operator_code].flags;
+  DECL_OVERLOADED_OPERATOR_CODE (decl) = operator_code;
+}
 
-  if (operator_code == NEW_EXPR || operator_code == VEC_NEW_EXPR
-  || operator_code == DELETE_EXPR || operator_code == VEC_DELETE_EXPR)
+  if (op_flags & OVL_OP_FLAG_ALLOC)
 {
   /* operator new and operator delete are quite special.  */
   if (class_type)
-	switch (operator_code)
+	switch (op_flags)
 	  {
-	  case NEW_EXPR:
+	  case OVL_OP_FLAG_ALLOC:
 	TYPE_HAS_NEW_OPERATOR (class_type)

Re: [006/nnn] poly_int: tree constants

[Martin Sebor]

On 10/29/2017 09:14 PM, Trevor Saunders wrote:

On Sun, Oct 29, 2017 at 10:25:38AM -0600, Martin Sebor wrote:

On 10/27/2017 02:08 AM, Richard Sandiford wrote:

Martin Sebor  writes:

On 10/26/2017 11:52 AM, Richard Sandiford wrote:

Martin Sebor  writes:

For offset_int the default precision is 128-bits.  Making that
the default also for wide_int should be unsurprising.


I think it'd be surprising.  offset_int should always be used in
preference to wide_int if the precision is known to be 128 bits
in advance, and there doesn't seem any reason to prefer the
precision of offset_int over widest_int, HOST_WIDE_INT or int.

We would end up with:

   wide_int
   f (const wide_int &y)
   {
 wide_int x;
 x += y;
 return x;
   }

being valid if y happens to have 128 bits as well, and a runtime error
otherwise.


Surely that would be far better than the undefined behavior we
have today.


I disagree.  People shouldn't rely on the above behaviour because
it's never useful.


Well, yes, but the main point of my feedback on the poly_int default
ctor (and the ctor of the extended_tree class, and the existing wide
int classes) is that it makes them easy to misuse.  That they're not
meant to be [mis]used like that isn't an answer.


I think Richard's point is different from saying don't misuse it.  I
think its that 0 initializing is also always a bug, and the user needs
to choosesome initialization to follow the default ctor in either case.


Initializing offset_int to zero isn't a bug and there are examples
of it in GCC sources.  Some of those are now being replaced with
those of poly_int xxx = 0.  Here's one example from [015/nnn]
poly_int: ao_ref and vn_reference_op_t:

@@ -1365,8 +1369,8 @@ indirect_refs_may_alias_p (tree ref1 ATT
 refs_may_alias_p_1 (ao_ref *ref1, ao_ref *ref2, bool tbaa_p)
 {
   tree base1, base2;
-  HOST_WIDE_INT offset1 = 0, offset2 = 0;
-  HOST_WIDE_INT max_size1 = -1, max_size2 = -1;
+  poly_int64 offset1 = 0, offset2 = 0;
+  poly_int64 max_size1 = -1, max_size2 = -1;

I'm not suggesting these be changed to avoid the explicit
initialization.  But I show this to disprove the claim above.
Clearly, zero initialization is valid and useful.

Martin

[committed] diagnostics: get rid of *_at_rich_loc in favor of overloading

[David Malcolm]

Adding a fix-it hint currently involves changing e.g.:

  error_at (token->location,
"unknown type name %qE; did you mean %qs?",
token->value, hint);
to:

  gcc_rich_location richloc (token->location);
  richloc.add_fixit_replace (hint);
  error_at_rich_loc (&richloc,
 "unknown type name %qE; did you mean %qs?",
 token->value, hint);

to make the change from taking a location_t to a rich_location *.

This patch renames the "*_at_rich_loc" diagnostic entrypoints to use
the same function names for rich_location * as for location_t,
via overloading, to simplify the above change to just changing from:

  error_at (token->location,
"unknown type name %qE; did you mean %qs?",
token->value, hint);
to:

  gcc_rich_location richloc (token->location);
  richloc.add_fixit_replace (hint);
  error_at (&richloc,
"unknown type name %qE; did you mean %qs?",
token->value, hint);

thus saving space (and typing) and usually avoiding the need to reindent
the "error_at" invocation.

With this change, 0 is no longer acceptable as a location_t to these
entrypoints, as e.g.:

../../src/gcc/auto-profile.c:855:37: error: call of overloaded
'inform(int, const char [18])' is ambiguous
   inform (0, "Not expected TAG.");
 ^
In file included from ../../src/gcc/auto-profile.c:35:0:
../../src/gcc/diagnostic-core.h:88:13: note: candidate:
'void inform(location_t, const char*, ...)'
 extern void inform (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
 ^~
../../src/gcc/diagnostic-core.h:89:13: note: candidate:
'void inform(rich_location*, const char*, ...)'
 extern void inform (rich_location *, const char *, ...) 
ATTRIBUTE_GCC_DIAG(2,3);
 ^~

Such locations now need to be spelled out as UNKNOWN_LOCATION,
rather than 0.

I considered making the API take a rich_location & rather than a
rich_location *, but doing so would mean replacing
  diagnostic_set_info
and
  diagnostic_set_info_translated
with a constructor for diagnostic_info, which was a more invasive
change.  Maybe in the future.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
successfully built everything in contrib/config-list.mk, with
the exception of:

  i686-cygwinOPT-enable-threads=yes
  i686-mingw32crt
  x86_64-mingw32OPT-enable-sjlj-exceptions=yes
  x86_64-w64-mingw32

which all appear to have the same pre-existing failure in gimplify.c
here:

src/gcc/config/i386/i386.h:611:46: error: 'ix86_cfun_abi' was not declared in 
this scope
 #define TARGET_64BIT_MS_ABI (TARGET_64BIT && ix86_cfun_abi () == MS_ABI)
  ^

Committed to trunk as r254280.

gcc/ChangeLog:
* auto-profile.c (autofdo_source_profile::read): Use
UNKNOWN_LOCATION rather than 0.
* diagnostic-core.h (warning_at_rich_loc): Rename to...
(warning_at): ...this overload.
(warning_at_rich_loc_n): Rename to...
(warning_n): ...this overload.
(error_at_rich_loc): Rename to...
(error_at): ...this overload.
(pedwarn_at_rich_loc): Rename to...
(pedwarn): ...this overload.
(permerror_at_rich_loc): Rename to...
(permerror): ...this overload.
(inform_at_rich_loc): Rename to...
(inform): ...this overload.
* diagnostic.c: (diagnostic_n_impl): Delete location_t-based decl.
(diagnostic_n_impl_richloc): Rename to...
(diagnostic_n_impl): ...this rich_location *-based decl.
(inform_at_rich_loc): Rename to...
(inform): ...this, and add an assertion.
(inform_n): Update for removal of location_t-based diagnostic_n_impl.
(warning_at_rich_loc): Rename to...
(warning_at): ...this, and add an assertion.
(warning_at_rich_loc_n): Rename to...
(warning_n): ...this, and add an assertion.
(warning_n): Update location_t-based implementation for removal of
location_t-based diagnostic_n_impl.
(pedwarn_at_rich_loc): Rename to...
(pedwarn): ...this, and add an assertion.
(permerror_at_rich_loc): Rename to...
(permerror): ...this, and add an assertion.
(error_n): Update for removal of location_t-based diagnostic_n_impl.
(error_at_rich_loc): Rename to...
(error_at): ...this, and add an assertion.
* gcc.c (do_spec_1): Use UNKNOWN_LOCATION rather than 0.
(driver::do_spec_on_infiles): Likewise.
* substring-locations.c (format_warning_va): Update for renaming
of inform_at_rich_loc.

gcc/c-family/ChangeLog:
* c-common.c (binary_op_error): Update for renaming of
error_at_rich_loc.
(c_parse_error): Likewise.
* c-warn.c (warn_logical_not_parentheses): Likewise for
renaming of inform_at_rich_loc.
(warn_for_restrict): Likewise for renaming of
warning_at_rich_loc_

Re: [patch, fortran] Index interchange for FORALL and DO CONCURRENT

[Thomas Koenig]

Hi Bernhard,


Regression-tested. OK for trunk?


s/shoud/should/; s/acessed/accessed/; s/indces/indices/;


Fixed.


why are struct ind_type "n" and "num" int and not unsigned int?


I tend not to use signed variables unless the special overflow
semantics are required.  I like Fortran, which doesn't have
unsigned ints.


Can't you scan the original dump for something characteristic?


I'd need a dejagnu multiline regexp, to reject


   i.7 = 1;
count.10 = 512;
while (1)
  {
if (ANNOTATE_EXPR ) goto L.4;
j.6 = 1;
count.9 = 512;
while (1)
  {
if (ANNOTATE_EXPR ) goto L.3;

while accepting

   k.7 = 1;
count.10 = 512;
while (1)
  {
if (ANNOTATE_EXPR ) goto L.4;
j.6 = 1;
count.9 = 512;
while (1)
  {
if (ANNOTATE_EXPR ) goto L.3;
i.5 = 1;
count.8 = 512;

and not being confused by

if (ANNOTATE_EXPR ) goto L.2;
(*(real(kind=4)[0:] * restrict) c.data)[((c.offset 
+ (integer(kind=8)) k.5 * c.dim[2].stride) + (integer(kind=8)) j.6 * 
c.dim[1].stride) + (integer(kind=8)) i.7] = (*(real(kind=4)[0:] * 
restrict) a.data)[((a.offset + (integer(kind=8)) k.5 * a.dim[2].stride) 
+ (integer(kind=8)) j.6 * a.dim[1].stride) + (integer(kind=8)) i.7] + 
(*(real(kind=4)[0:] * restrict) b.data)[((b.offset + (integer(kind=8)) 
k.5 * b.dim[2].stride) + (integer(kind=8)) j.6 * b.dim[1].stride) + 
(integer(kind=8)) i.7];

L.1:;
k.5 = k.5 + 1;
count.8 = count.8 + -1;
  }
L.2:;
j.6 = j.6 + 1;
count.9 = count.9 + -1;
  }
L.3:;
i.7 = i.7 + 1;
count.10 = count.10 + -1;
  }
L.4:;
  }

... but keep that easy enough to understand so people can
change it later if somebody changes something in trans-*.
I gave up.


Or maybe emit diagnostics into the frontend optimize dump file and scan
that?


If we could check the Fortran tree dumps with dejagnu, that would be
doable. Unfortunately, we don't have that in place.

This would be the difference between

DO CONCURRENT test_do_speed:k 1:512:1,test_do_speed:j 
1:512:1,test_do_speed:i 1:512:1()


and

DO CONCURRENT test_do_speed:i 1:512:1,test_do_speed:j 
1:512:1,test_do_speed:k 1:512:1()


Just about the only way I can think of is to add a warning
option if something is actually interchanged. Might be worth
doing anyway, but I would like not to add too many -W options.

-fopt-info would be nice to have here (PR 66576). I had a
preliminary look at what it does for gcc, but after a look
at the source, I decided that this was not really self-explanatory
and that I'd rather do other things :-)

Regards

Thomas

[committed] pt.c: add missing %< and %>

[David Malcolm]

This patch fixes some missing quoting of a source code element within
a diagnostic: a reference to "#include ".

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;

Commited to trunk as r254281.

gcc/cp/ChangeLog:
* pt.c (listify): Use %< and %> for description of #include.

gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/auto21.C: Update dg-error to reflect addition of
quotes.
* g++.dg/cpp0x/missing-initializer_list-include.C: Likewise.
---
 gcc/cp/pt.c   | 2 +-
 gcc/testsuite/g++.dg/cpp0x/auto21.C   | 2 +-
 gcc/testsuite/g++.dg/cpp0x/missing-initializer_list-include.C | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2642e57..55a11a7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25133,7 +25133,7 @@ listify (tree arg)
   maybe_add_include_fixit (&richloc, "");
   error_at (&richloc,
"deducing from brace-enclosed initializer list"
-   " requires #include ");
+   " requires %<#include %>");
 
   return error_mark_node;
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto21.C 
b/gcc/testsuite/g++.dg/cpp0x/auto21.C
index a827b3d..346e98c 100644
--- a/gcc/testsuite/g++.dg/cpp0x/auto21.C
+++ b/gcc/testsuite/g++.dg/cpp0x/auto21.C
@@ -1,5 +1,5 @@
 // Origin PR c++/47208
 // { dg-do compile { target c++11 } }
 
-constexpr auto list = { }; // { dg-error "deducing from brace-enclosed 
initializer list requires #include " }
+constexpr auto list = { }; // { dg-error "deducing from brace-enclosed 
initializer list requires '#include '" }
 static const int l = list.size();
diff --git a/gcc/testsuite/g++.dg/cpp0x/missing-initializer_list-include.C 
b/gcc/testsuite/g++.dg/cpp0x/missing-initializer_list-include.C
index 8e803c8..7d72ec4 100644
--- a/gcc/testsuite/g++.dg/cpp0x/missing-initializer_list-include.C
+++ b/gcc/testsuite/g++.dg/cpp0x/missing-initializer_list-include.C
@@ -7,7 +7,7 @@
 
 void test (int i)
 {
-  auto a = { &i }; // { dg-error "deducing from brace-enclosed initializer 
list requires #include " }
+  auto a = { &i }; // { dg-error "deducing from brace-enclosed initializer 
list requires '#include '" }
 }
 
 /* Verify the output from -fdiagnostics-generate-patch.
-- 
1.8.5.3

[committed] jit: add a way to preserve testsuite executables

[David Malcolm]

The jit documentation has instructions on running testsuite executables
under the debugger, but I realize now that the executables were always
being deleted after being run, and I've always been hacking up my jit.exp
to prevent this, to allow for debugging them.

This patch adds a PRESERVE_EXECUTABLES environment variable to jit.exp
to provide a simple, documented way to do this.

Committed to trunk as r254282.

gcc/jit/ChangeLog:
* docs/internals/index.rst (Running the test suite): Document
PRESERVE_EXECUTABLES.
(Running under valgrind): Add markup to RUN_UNDER_VALGRIND.
* docs/_build/texinfo/libgccjit.texi: Regenerate.

gcc/testsuite/ChangeLog:
* jit.dg/jit.exp (jit-dg-test): If PRESERVE_EXECUTABLES is set in
the environment, don't delete the generated executable.
---
 gcc/jit/docs/internals/index.rst | 10 +++---
 gcc/testsuite/jit.dg/jit.exp |  9 +
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/gcc/jit/docs/internals/index.rst b/gcc/jit/docs/internals/index.rst
index cadf362..4ad7f61 100644
--- a/gcc/jit/docs/internals/index.rst
+++ b/gcc/jit/docs/internals/index.rst
@@ -103,7 +103,9 @@ and detailed logs in:
 
   jit/build/gcc/testsuite/jit/jit.log
 
-The test executables can be seen as:
+The test executables are normally deleted after each test is run.  For
+debugging, they can be preserved by setting :envvar:`PRESERVE_EXECUTABLES`
+in the environment.  If so, they can then be seen as:
 
 .. code-block:: console
 
@@ -115,7 +117,9 @@ You can compile and run individual tests by passing 
"jit.exp=TESTNAME" to RUNTES
 
 .. code-block:: console
 
-   [gcc] $ make check-jit RUNTESTFLAGS="-v -v -v jit.exp=test-factorial.c"
+   [gcc] $ PRESERVE_EXECUTABLES= \
+ make check-jit \
+   RUNTESTFLAGS="-v -v -v jit.exp=test-factorial.c"
 
 and once a test has been compiled, you can debug it directly:
 
@@ -130,7 +134,7 @@ and once a test has been compiled, you can debug it 
directly:
 Running under valgrind
 **
 
-The jit testsuite detects if RUN_UNDER_VALGRIND is present in the
+The jit testsuite detects if :envvar:`RUN_UNDER_VALGRIND` is present in the
 environment (with any value).  If it is present, it runs the test client
 code under `valgrind `_,
 specifcally, the default
diff --git a/gcc/testsuite/jit.dg/jit.exp b/gcc/testsuite/jit.dg/jit.exp
index 39e37c2..869d9f6 100644
--- a/gcc/testsuite/jit.dg/jit.exp
+++ b/gcc/testsuite/jit.dg/jit.exp
@@ -580,6 +580,15 @@ proc jit-dg-test { prog do_what extra_tool_flags } {
verbose "$name is not meant to generate a reproducer"
 }
 
+# Normally we would return $comp_output and $output_file to the
+# caller, which would delete $output_file, the generated executable.
+# If we need to debug, it's handy to be able to suppress this behavior,
+# keeping the executable around.
+set preserve_executables [info exists env(PRESERVE_EXECUTABLES)]
+if $preserve_executables {
+   set output_file ""
+}
+
 return [list $comp_output $output_file]
 }
 
-- 
1.8.5.3

Re: [patch, fortran] Index interchange for FORALL and DO CONCURRENT

[Bernhard Reutner-Fischer]

On Tue, Oct 31, 2017 at 09:30:27PM +0100, Thomas Koenig wrote:

> > Or maybe emit diagnostics into the frontend optimize dump file and scan
> > that?
> 
> If we could check the Fortran tree dumps with dejagnu, that would be
> doable. Unfortunately, we don't have that in place.

Well that should be rather easy.
Don't we have a basic scan-dump where we can pass the file as well as a
regexp? I might look into this later.
> 
> This would be the difference between
> 
> DO CONCURRENT test_do_speed:k 1:512:1,test_do_speed:j
> 1:512:1,test_do_speed:i 1:512:1()
> 
> and
> 
> DO CONCURRENT test_do_speed:i 1:512:1,test_do_speed:j
> 1:512:1,test_do_speed:k 1:512:1()
> 
> Just about the only way I can think of is to add a warning
> option if something is actually interchanged. Might be worth
> doing anyway, but I would like not to add too many -W options.
> 
> -fopt-info would be nice to have here (PR 66576). I had a
> preliminary look at what it does for gcc, but after a look
> at the source, I decided that this was not really self-explanatory
> and that I'd rather do other things :-)

ah right that would be a good idea, too.

Thanks for the explanation!

cheers,

Re: [patch, fortran] Index interchange for FORALL and DO CONCURRENT

[Bernhard Reutner-Fischer]

On Tue, Oct 31, 2017 at 09:50:37PM +0100, Bernhard Reutner-Fischer wrote:
> On Tue, Oct 31, 2017 at 09:30:27PM +0100, Thomas Koenig wrote:
> 
> > > Or maybe emit diagnostics into the frontend optimize dump file and scan
> > > that?
> > 
> > If we could check the Fortran tree dumps with dejagnu, that would be
> > doable. Unfortunately, we don't have that in place.
> 
> Well that should be rather easy.
> Don't we have a basic scan-dump where we can pass the file as well as a
> regexp? I might look into this later.

and there is a scan-lang-dump which may be exactly for this case.

Re: [PATCH] RFC: Preserving locations for variable-uses and constants (PR 43486)

[David Malcolm]

On Tue, 2017-10-24 at 09:53 -0400, Jason Merrill wrote:
> On Fri, Oct 20, 2017 at 5:53 PM, David Malcolm 
> wrote:
> > Design questions:
> > 
> > * The patch introduces a new kind of tree node, currently called
> >   DECL_WRAPPER_EXPR (although it's used for wrapping constants as
> > well
> >   as decls).  Should wrappers be a new kind of tree node, or should
> > they
> >   reuse an existing TREE_CODE? (e.g. NOP_EXPR, CONVERT_EXPR, etc).
> > * NOP_EXPR: seems to be for use as an rvalue
> > * CONVERT_EXPR: for type conversions
> > * NON_LVALUE_EXPR: "Value is same as argument, but guaranteed
> > not an
> >   lvalue"
> >   * but we *do* want to support lvalues here
> 
> I think using NON_LVALUE_EXPR for constants would be appropriate.
> 
> > * VIEW_CONVERT_EXPR: viewing one thing as of a different type
> >   * can it support lvalues?
> 
> Yes, the purpose of VIEW_CONVERT_EXPR is to support lvalues, it seems
> like the right choice.
> 
> Jason

Thanks.  I've been working on a new version of the patch using those
tree codes, but have run into an issue.

In g++.dg/conversion/reinterpret1.C:

  // PR c++/15076

  struct Y { Y(int &); };

  int v;
  Y y1(reinterpret_cast(v));  // { dg-error "" }

With trunk, this successfully generates an error:

  reinterpret1.C:6:6: error: cannot bind non-const lvalue reference of type 
‘int&’ to an rvalue of type ‘int’
   Y y1(reinterpret_cast(v));  // { dg-error "" }
^~~~
  reinterpret1.C:3:12: note:   initializing argument 1 of ‘Y::Y(int&)’
   struct Y { Y(int &); };
  ^

where internally there's a NON_LVALUE_EXPR around a VAR_DECL, where
both have the same type:

(gdb) call debug_tree (expr)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 
0x7132e5e8 precision:32 min  max 

pointer_to_this  reference_to_this 
>
   
arg:0 
used public static tree_1 read SI 
/home/david/coding-3/gcc-git-expr-vs-decl/src/gcc/testsuite/g++.dg/conversion/reinterpret1.C:5:5
 size  unit-size 
align:32 warn_if_not_align:0 context 
chain 
public decl_2 VOID 
/home/david/coding-3/gcc-git-expr-vs-decl/src/gcc/testsuite/g++.dg/conversion/reinterpret1.C:3:8
align:8 warn_if_not_align:0 context 
 chain >>

/home/david/coding-3/gcc-git-expr-vs-decl/src/gcc/testsuite/g++.dg/conversion/reinterpret1.C:6:6
 start: 
/home/david/coding-3/gcc-git-expr-vs-decl/src/gcc/testsuite/g++.dg/conversion/reinterpret1.C:6:6
 finish: 
/home/david/coding-3/gcc-git-expr-vs-decl/src/gcc/testsuite/g++.dg/conversion/reinterpret1.C:6:29>

The problem is that this reinterpret cast "looks" just like one of my
location wrappers.

I see a similar issue with constants, where with:

  struct Y { Y(int &); };
  Y y1(reinterpret_cast(42));

trunk generates an error like the above, but my code handles the
  NON_LVALUE_EXPR(INTEGER_CST(42))
as if it were a location wrapper around the INTEGER_CST, and thus
doesn't emit the error.

I can envisage a few hackish solutions, like assuming that there will
be a location wrapper around such a constant, and thus to expect:
  NON_LVALUE_EXPR(NON_LVALUE_EXPR(INTEGER_CST(42)))
but this seems clunky and fragile; maybe we do need a new tree code for
this (e.g. LOCATION_WRAPPER or somesuch?)

Thoughts?

Thanks
Dave

[PR 81702] Remove devirtualization assert

[Martin Jambor]

Hi,

in PR 81702, both me and Honza came to the conclusion that the assert
that is being hit can be removed if it is indeed OK that a particular
variable is constructed without a DECL_INITIAL.  Yesterday Nathan
confirmed that in this case it is fine.  So the patch below removes
the assert.

Bootstrapped and tested on x86_64-linux, I will commit it to teunk as
pre-approved in Bugzilla in a few moments.  I will commit it tomorrow
to the gcc-7-branch after testing it there too.

Thanks,

Martin


2017-10-31  Martin Jambor  

PR c++/81702
* gimple-fold.c (gimple_get_virt_method_for_vtable): Remove assert.

testsuite/
* g++.dg/tree-ssa/pr81702.C: New test.
---
 gcc/gimple-fold.c   |   1 -
 gcc/testsuite/g++.dg/tree-ssa/pr81702.C | 110 
 2 files changed, 110 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr81702.C

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index cb33c1e09fe..85fd3971946 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -6586,7 +6586,6 @@ gimple_get_virt_method_for_vtable (HOST_WIDE_INT token,
   gcc_assert (init);
   if (init == error_mark_node)
 {
-  gcc_assert (in_lto_p);
   /* Pass down that we lost track of the target.  */
   if (can_refer)
*can_refer = false;
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr81702.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr81702.C
new file mode 100644
index 000..85acd857e67
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr81702.C
@@ -0,0 +1,110 @@
+// { dg-do compile }
+// { dg-options "-O2" }
+
+namespace std {
+  struct type_info
+  {
+virtual bool __do_catch(const type_info *__thr_type, void **__thr_obj,
+   unsigned __outer) const;
+  };
+}
+
+template< typename VALUE_T, typename TYPE >
+struct List_policy
+{
+  typedef VALUE_T *Value_type;
+  typedef TYPE **Type;
+  typedef TYPE *Head_type;
+  typedef TYPE Item_type;
+};
+
+template< typename POLICY >
+class List
+{
+public:
+  typedef typename POLICY::Value_type Value_type;
+  class Iterator
+  {
+typedef typename POLICY::Type Internal_type;
+  public:
+typedef typename POLICY::Value_type value_type;
+typedef typename POLICY::Value_type Value_type;
+Value_type operator -> () const { return static_cast(*_c); }
+Internal_type _c;
+  };
+  Iterator begin() { return Iterator(); }
+  Iterator end() { return Iterator(); }
+  typename POLICY::Head_type _f;
+};
+
+template class H_list_item_t { };
+
+template< typename T, typename POLICY >
+class H_list : public List
+{
+public:
+  typedef typename POLICY::Item_type Item;
+  typedef List Base;
+  typedef typename Base::Iterator Iterator;
+  Iterator insert(T *e, Iterator const &pred)
+  {
+Item **x = &this->_f;
+*x = static_cast(e);
+return Iterator();
+  }
+};
+
+template< typename T >
+struct H_list_t : H_list > >
+{
+  H_list_t(bool b) : H_list > >(b) {}
+};
+
+template< typename BASE, typename MATCH_RESULT >
+struct Type_matcher : H_list_item_t
+{
+  explicit Type_matcher(std::type_info const *type);
+  typedef MATCH_RESULT Match_result;
+
+private:
+  std::type_info *_type;
+  typedef H_list_t List;
+  typedef typename List::Iterator Iterator;
+  static List _for_type;
+};
+
+template< typename BASE, typename MR >
+Type_matcher::Type_matcher(std::type_info const *t)
+{
+  Iterator c = _for_type.begin();
+  t->__do_catch(c->_type, 0, 0);
+  _for_type.insert(static_cast(this), _for_type.begin());
+}
+
+template< typename VI, typename HW >
+class Fa : public Type_matcher, VI*>
+{
+public:
+  typedef Fa Self;
+  virtual VI *do_match(HW *f) = 0;
+  explicit Fa(std::type_info const *type) : Type_matcher(type) {}
+};
+
+class Res {};
+typedef Fa R_fac;
+
+template< typename VI, typename HW_BASE, typename HW, typename BASE >
+class Fa_t : public BASE
+{
+public:
+  Fa_t() : BASE(&typeid(HW)) {}
+  VI *do_match(HW_BASE *) { return 0; }
+};
+
+template< typename VI, typename HW >
+class Resource_factory_t : public Fa_t {};
+
+class Foo {};
+class Foo2;
+class Foo3 : public Res {};
+Resource_factory_t _x;
-- 
2.14.2

Re: [PATCH][compare-elim] Fix PR rtl-optimization/82597

[Jakub Jelinek]

On Tue, Oct 31, 2017 at 12:02:26PM +0100, Jakub Jelinek wrote:
> 2017-10-31  Jakub Jelinek  
> 
>   PR rtl-optimization/82778
>   PR rtl-optimization/82597
>   * compare-elim.c (struct comparison): Add in_a_setter field.
>   (find_comparison_dom_walker::before_dom_children): Remove killed
>   bitmap and df_simulate_find_defs call, instead walk the defs.
>   Compute last_setter and initialize in_a_setter.  Merge definitions
>   with first initialization for a few variables.
>   (try_validate_parallel): Use insn_invalid_p instead of
>   recog_memoized.  Return insn rather than just the pattern.
>   (try_merge_compare): Fix up comment.  Don't uselessly test if
>   in_a is a REG_P.  Use cmp->in_a_setter instead of walking UD
>   chains.
> 
>   * g++.dg/opt/pr82778.C: New test.
> 
> 2017-10-31  Michael Collison  
> 
>   PR rtl-optimization/82597
>   * gcc.dg/pr82597.c: New test.

Successfully bootstrapped/regtested on {x86_64,i686,powerpc64{,le}}-linux.
Ok for trunk?

Jakub

Re: [committed] diagnostics: get rid of *_at_rich_loc in favor of overloading

[Joseph Myers]

To confirm: can you make sure that exgettext (via "make gcc.pot") still 
works to extract messages from these overloaded functions for translation?

It *should* work, because the msgid argument is at the same position for 
all overloads (what definitely doesn't work is overloads of diagnostic 
functions where the same function name can have the msgid argument in 
different positions for different overloads), but it's still a good idea 
to test to make sure.

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

Re: [PATCH, AArch64] Disable reg offset in quad-word store for Falkor.

[Kugan Vivekanandarajah]

Hi Jim,

On 1 November 2017 at 03:12, Jim Wilson  wrote:
> On Tue, 2017-10-31 at 14:35 +1100, Kugan Vivekanandarajah wrote:
>> Ping ?
>>
>> I see that Jim has clarified the comments from Andrew.
>
> Andrew also suggested that we add a testcase to the testsuite.  I
> didn't do that.  I did put a testcase to reproduce in the bug report.
>  See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82533
> It should be a relatively simple matter of taking that testcase,
> compiling to assembly with -mcpu=falkor, then doing a pattern search
> for a str q [r+r] instruction, and fail if it is present.

Sorry, I missed that part. I will create the test case as you have
suggested and post it.

Thanks,
Kugan

> Jim
>

Re: [committed] diagnostics: get rid of *_at_rich_loc in favor of overloading

[David Malcolm]

On Tue, 2017-10-31 at 23:20 +, Joseph Myers wrote:
> To confirm: can you make sure that exgettext (via "make gcc.pot")
> still 
> works to extract messages from these overloaded functions for
> translation?
> It *should* work, because the msgid argument is at the same position
> for 
> all overloads (what definitely doesn't work is overloads of
> diagnostic 
> functions where the same function name can have the msgid argument
> in 
> different positions for different overloads), but it's still a good
> idea 
> to test to make sure.
> 

Good catch.

Yes: "make gcc.pot" seems to work; I re-ran it, and it generated a
po/gcc.pot; I verified some of the rich_location * callsites by hand,
e.g.:

#: c/c-decl.c:3475
#, gcc-internal-format
msgid "%qE undeclared here (not in a function); did you mean %qs?"
msgstr ""

and it appears to be working as before.


Thanks
Dave

[PATCH] RISC-V: Document the medlow and medany code models

[Palmer Dabbelt]

This documentation is patterned off the aarch64 -mcmodel documentation.

gcc/ChangeLog:

2017-10-31  Palmer Dabbelt  

* doc/invoke.texi (RISC-V Options): Explicitly name the medlow
and medany code models, and describe what they do.
---
 gcc/doc/invoke.texi | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 43acbcbbcd77..8903afaeeffc 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -989,7 +989,7 @@ See RS/6000 and PowerPC Options.
 -msmall-data-limit=@var{N-bytes} @gol
 -msave-restore  -mno-save-restore @gol
 -mstrict-align -mno-strict-align @gol
--mcmodel=@var{code-model} @gol
+-mcmodel=medlow -mcmodel=medany @gol
 -mexplicit-relocs  -mno-explicit-relocs @gol}
 
 @emph{RL78 Options}
@@ -21765,9 +21765,18 @@ Use smaller but slower prologue and epilogue code.
 @opindex mstrict-align
 Do not generate unaligned memory accesses.
 
-@item -mcmodel=@var{code-model}
-@opindex mcmodel
-Specify the code model.
+@item -mcmodel=medlow
+@opindex mcmodel=medlow
+Generate code for the medium-low code model. The program and its statically
+defined symbols must lie within a single 2 GiB address range and must lie
+between absolute addresses -2 GiB and +2 GiB. Programs can be statically or
+dynamically linked. This is the default code model.
+
+@item -mcmodel=medany
+@opindex mcmodel=medany
+Generate code for the medium-any code model. The program and its statically
+defined symbols must be within any single 2 GiB address range. Programs can be
+statically or dynamically linked.
 
 @end table
 
-- 
2.13.6

Re: [09/nn] Add a fixed_size_mode_pod class

[Trevor Saunders]

On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote:
> On 10/31/2017 11:22 AM, Eric Botcazou wrote:
> >> I don't see a reason not to other than a pretty small amount of work
> >> each time we make a release.
> > 
> > I'm not sure it would be so small an amount of work, especially on 
> > non-Linux 
> > platforms, so this would IMO divert our resources for little benefit.
> Having done this for years on HPUX, yes, it takes more time than one
> could imagine.  THen I went to work for a company that did this for
> hpux, solaris, aix, irix and others and well, it was very painful.

I'm sure its a project one can spend arbitrary amounts of time on if one
wishes or is payed to do so.  That said I'm considering the scope here
limitted to running configure / make  / make install with the defaults
and taring up the result.  I'll admitt I've only done that on linux
where it was easy, but people do keep AIX and Solaris building and they
really are supposed to be buildable in a release.  However at some point
it can be less work to do this than to beat C++98 into doing what is
desired.

> >> Well first this would only matter to the 0.01% of people who want to do
> >> that on AIX or Solaris machines, not the vast majority of possible
> >> contributors who already use clang or gcc as there system compiler.
> > 
> > Yes, but we're GCC, not Clang, and we support more than Linux and Darwin.
> Very true.

certainly, but I think it makes sense to understand how many people
might be negatively effected by a change, and to what degree before
making that decision.

> >> Thirdly making it easier to work on the compiler and understand it makes
> >> things easier for those possible contributors, so if being able to use
> >> C++11 advances that goalthings could be better over all for possible
> >> contributors with different system compilers.
> > 
> > I don't buy this at all.  You don't need bleeding edge C++ features to 
> > build a 
> > compiler and people don't work on compilers to use bleeding edge C++.  
> > Using a 
> > narrow and sensible set of C++ features was one of the conditions under 
> > which 
> > the switch to C++ as implementation language was accepted at the time.
> Agreed that we need to stick with a sensible set of features.  But the
> sensible set isn't necessarily fixed forever.

Also as a counter example what brought this thread up is Richard wanting
to use something from C++11.  So in that particular case it probably
would make something better.

thanks

Trev

> 
> Jeff

Re: [PATCH] RISC-V: Document the medlow and medany code models

[Sandra Loosemore]

On 10/31/2017 06:54 PM, Palmer Dabbelt wrote:

This documentation is patterned off the aarch64 -mcmodel documentation.

gcc/ChangeLog:

2017-10-31  Palmer Dabbelt  

 * doc/invoke.texi (RISC-V Options): Explicitly name the medlow
 and medany code models, and describe what they do.
---
  gcc/doc/invoke.texi | 17 +
  1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 43acbcbbcd77..8903afaeeffc 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -989,7 +989,7 @@ See RS/6000 and PowerPC Options.
  -msmall-data-limit=@var{N-bytes} @gol
  -msave-restore  -mno-save-restore @gol
  -mstrict-align -mno-strict-align @gol
--mcmodel=@var{code-model} @gol
+-mcmodel=medlow -mcmodel=medany @gol
  -mexplicit-relocs  -mno-explicit-relocs @gol}

  @emph{RL78 Options}


Hmmm.  I have a mild preference for keeping the metasyntactic variable 
in the option documentation and using a nested table to list the 
possible values, but I see that the documentation for other backends 
that support this option are not consistent, so I guess it is OK to 
expand it like that as long as you don't anticipate adding additional 
keywords in the future.



@@ -21765,9 +21765,18 @@ Use smaller but slower prologue and epilogue code.
  @opindex mstrict-align
  Do not generate unaligned memory accesses.

-@item -mcmodel=@var{code-model}
-@opindex mcmodel
-Specify the code model.
+@item -mcmodel=medlow
+@opindex mcmodel=medlow
+Generate code for the medium-low code model. The program and its statically
+defined symbols must lie within a single 2 GiB address range and must lie
+between absolute addresses -2 GiB and +2 GiB. Programs can be statically or
+dynamically linked. This is the default code model.
+
+@item -mcmodel=medany
+@opindex mcmodel=medany
+Generate code for the medium-any code model. The program and its statically
+defined symbols must be within any single 2 GiB address range. Programs can be
+statically or dynamically linked.

  @end table


s/statically defined symbols/statically-defined symbols/g

Bonus points if you make that fix in the aarch64 documentation you 
copied this from, too.  :-)


-Sandra