Re: Relax std::move_if_noexcept for std::pair

[Ville Voutilainen]

On Thu, 20 Dec 2018 at 08:29, François Dumont  wrote:
>
> Hi
>
>  I eventually find out what was the problem with the
> std::move_if_noexcept within associative containers.
>
>  The std::pair move default constructor might not move both first
> and second member. If any is not moveable it will just copy it. And then

..as it should..

> the noexcept qualification of the copy constructor will participate in
> the noexcept qualification of the std::pair move constructor. So
> std::move_if_noexcept can eventually decide to not use move because a
> _copy_ constructor not noexcept qualified.

..and again, as it should.

>  This is why I am partially specializing __move_if_noexcept_cond. As
> there doesn't seem to exist any Standard meta function to find out if
> move will take place I resort using std::is_const as in this case for
> sure the compiler won't call the move constructor.

That seems wrong; just because a type is or is not const has nothing
to do whether
it's nothrow_move_constructible.

I don't understand what problem this is solving, and how it's not
introducing new problems.

[Patch] Bug 88521 - gcc 9.0 from r266355 miscompile x265 for mingw-w64 target

[Lokesh Janghel]

Hi Mateuszb,

I tested with your proposition patch and it is working right.
I also added the patch with test case.
Please let me know your thoughts/suggestions.


Thanks
Lokesh


88521.patch
Description: Binary data

Re: [Patch] Bug 88521 - gcc 9.0 from r266355 miscompile x265 for mingw-w64 target

[Mateusz]

W dniu 20.12.2018 o 09:12, Lokesh Janghel pisze:
> Hi Mateuszb,
> 
> I tested with your proposition patch and it is working right.
> I also added the patch with test case.
> Please let me know your thoughts/suggestions.
> 
> 
> Thanks
> Lokesh
 
Patch looks good to me, thanks!

On 64-bit target we should be OK.

We could take a look on 32-bit target.
I've attached patch that do the same for 32- and 64-bit targets.
Sample result:
$ cat t.cpp
float fun1(void)
{
return 4.14f;
}

typedef struct {float x;} Float;

Float fun2(void)
{
Float v;
v.x = 4.14f;
return v;
}

double fun3(void)
{
return 3.13;
}

typedef struct {double x;} Double;

Double fun4(void)
{
Double v;
v.x = 3.13;
return v;
}
Mateusz@Mateusz-i7 /c/temp
$ g++ -c -Wall -O2 -o t.o t.cpp

Mateusz@Mateusz-i7 /c/temp
$ objdump -dr t.o

t.o: file format pe-x86-64


Disassembly of section .text:

 <_Z4fun1v>:
   0:   f3 0f 10 05 00 00 00movss  0x0(%rip),%xmm0# 8 <_Z4fun1v+0x8>
   7:   00
4: R_X86_64_PC32.rdata
   8:   c3  retq
   9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)

0010 <_Z4fun2v>:
  10:   8b 05 00 00 00 00   mov0x0(%rip),%eax# 16 <_Z4fun2v+0x6>
12: R_X86_64_PC32   .rdata
  16:   c3  retq
  17:   66 0f 1f 84 00 00 00nopw   0x0(%rax,%rax,1)
  1e:   00 00

0020 <_Z4fun3v>:
  20:   f2 0f 10 05 08 00 00movsd  0x8(%rip),%xmm0# 30 <_Z4fun4v>
  27:   00
24: R_X86_64_PC32   .rdata
  28:   c3  retq
  29:   0f 1f 80 00 00 00 00nopl   0x0(%rax)

0030 <_Z4fun4v>:
  30:   48 8b 05 08 00 00 00mov0x8(%rip),%rax# 3f <_Z4fun4v+0xf>
33: R_X86_64_PC32   .rdata
  37:   c3  retq
  38:   90  nop
  39:   90  nop
  3a:   90  nop
  3b:   90  nop
  3c:   90  nop
  3d:   90  nop
  3e:   90  nop
  3f:   90  nop

Mateusz@Mateusz-i7 /c/temp
$ m32- 900

Mateusz@Mateusz-i7 /c/temp
$ g++ -c -Wall -O2 -o t32.o t.cpp

Mateusz@Mateusz-i7 /c/temp
$ objdump -dr t32.o

t32.o: file format pe-i386


Disassembly of section .text:

 <__Z4fun1v>:
   0:   d9 05 00 00 00 00   flds   0x0
2: dir32.rdata
   6:   c3  ret
   7:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
   e:   66 90   xchg   %ax,%ax

0010 <__Z4fun2v>:
  10:   a1 00 00 00 00  mov0x0,%eax
11: dir32   .rdata
  15:   c3  ret
  16:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  1d:   8d 76 00lea0x0(%esi),%esi

0020 <__Z4fun3v>:
  20:   dd 05 08 00 00 00   fldl   0x8
22: dir32   .rdata
  26:   c3  ret
  27:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  2e:   66 90   xchg   %ax,%ax

0030 <__Z4fun4v>:
  30:   b8 0a d7 a3 70  mov$0x70a3d70a,%eax
  35:   ba 3d 0a 09 40  mov$0x40090a3d,%edx
  3a:   c3  ret
  3b:   90  nop
  3c:   90  nop
  3d:   90  nop
  3e:   90  nop
  3f:   90  nop
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 267291)
+++ gcc/config/i386/i386.c  (working copy)
@@ -8990,6 +8990,66 @@
 }
 
 static rtx
+function_value_ms_32 (machine_mode orig_mode, machine_mode mode,
+ const_tree fntype, const_tree fn, const_tree valtype)
+{
+  unsigned int regno;
+
+  /* 8-byte vector modes in %mm0. See ix86_return_in_memory for where
+ we normally prevent this case when mmx is not available.  However
+ some ABIs may require the result to be returned like DImode.  */
+  if (VECTOR_MODE_P (mode) && GET_MODE_SIZE (mode) == 8)
+regno = FIRST_MMX_REG;
+
+  /* 16-byte vector modes in %xmm0.  See ix86_return_in_memory for where
+ we prevent this case when sse is not available.  However some ABIs
+ may require the result to be returned like integer TImode.  */
+  else if (mode == TImode
+  || (VECTOR_MODE_P (mode) && GET_MODE_SIZE (mode) == 16))
+regno = FIRST_SSE_REG;
+
+  /* 32-byte vector modes in %ymm0.   */
+  else if (VECTOR_MODE_P (mode) && GET_MODE_SIZE (mode) == 32)
+regno = FIRST_SSE_REG;
+
+  /* 64-byte vector modes in %zmm0.   */
+  else if (VECTOR_MODE_P (mode) && GET_MODE_SIZE (mode) == 64)
+regno = FIRST_SSE_REG;
+
+  /* Floating point return values in %st(0)
+ (unless -mno-fp-ret-in-387 or aggregate type of up to 8 bytes).  */
+  else if (X87_FLOAT_MODE_P (

Re: [PATCH] LWG 3171: restore stream insertion for filesystem::directory_entry

[Tim Song]

On Tue, Dec 18, 2018 at 10:57 AM Jonathan Wakely  wrote:

> * include/bits/fs_dir.h (operator<<): Overload for directory_entry,
> as per LWG 3171.
> * testsuite/27_io/filesystem/directory_entry/lwg3171.cc: New test.
>
> Tested x86_64-linux, committed to trunk.
>
>
>
The test seems to be missing from the patch.

Re: [PATCH][rs6000] avoid using unaligned vsx or lxvd2x/stxvd2x for memcpy/memmove inline expansion

[Segher Boessenkool]

On Wed, Dec 19, 2018 at 01:53:05PM -0600, Aaron Sawdey wrote:
> Because of POWER9 dd2.1 issues with certain unaligned vsx instructions
> to cache inhibited memory, here is a patch that keeps memmove (and memcpy)
> inline expansion from doing unaligned vector or using vector load/store
> other than lvx/stvx. More description of the issue is here:
> 
> https://patchwork.ozlabs.org/patch/814059/
> 
> OK for trunk if bootstrap/regtest ok?

Okay, but see below.

> 2018-12-19  Aaron Sawdey  
> 
>   * config/rs6000/rs6000-string.c (expand_block_move): Don't use
>   unaligned vsx and avoid lxvd2x/stxvd2x.
>   (gen_lvx_v4si_move): New function.

> +static rtx
> +gen_lvx_v4si_move (rtx dest, rtx src)
> +{
> +  rtx rv = NULL;
> +  if (MEM_P (dest))
> +{
> +  gcc_assert (!MEM_P (src));
> +  gcc_assert (GET_MODE (src) == V4SImode);
> +  rv = gen_altivec_stvx_v4si_internal (dest, src);
> +}
> +  else if (MEM_P (src))
> +{
> +  gcc_assert (!MEM_P (dest));
> +  gcc_assert (GET_MODE (dest) == V4SImode);
> +  rv = gen_altivec_lvx_v4si_internal (dest, src);
> +}
> +  else
> +gcc_unreachable ();
> +
> +  return rv;
> +}

This is extraordinarily clumsy :-)  Maybe something like:

static rtx
gen_lvx_v4si_move (rtx dest, rtx src)
{
  gcc_assert (!(MEM_P (dest) && MEM_P (src));
  gcc_assert (GET_MODE (dest) == V4SImode && GET_MODE (src) == V4SImode);
  if (MEM_P (dest))
return gen_altivec_stvx_v4si_internal (dest, src);
  else if (MEM_P (src))
return gen_altivec_lvx_v4si_internal (dest, src);
  else
gcc_unreachable ();
}

(Or do you allow VOIDmode for src as well?)  Anyway, at least get rid of
the useless extra variable.

Thanks!


Segher

Fwd: [RFC, openacc] Ensure oacc_replace_fn_attrib replaces

[Tom de Vries]

[ add gcc-patches ]
 Forwarded Message 
Subject: [RFC, openacc] Ensure oacc_replace_fn_attrib replaces
Date: Thu, 20 Dec 2018 00:40:56 +0100
From: Tom de Vries 
To: Thomas Schwinge 

Hi,

this looks like a good cleanup.

WDYT?

Thanks,
- Tom

[openacc] Ensure oacc_replace_fn_attrib replaces

Atm, in oacc_replace_fn_attrib we only replace the oacc function attribute if
it's the first.

So, for a parallel region we have:
...
__attribute__((oacc function (, 20, ), omp target entrypoint))
...
which is replaced by:
...
__attribute__((oacc function (1, 20, 32), omp target entrypoint))
...

But for a routine:
...
__attribute__((omp declare target, oacc function (0 1, 0 1, 0 1)))
...
we get instead:
...
__attribute__((oacc function (0 1, 0 1, 0 1), omp declare target,
	   oacc function (0 1, 0 1, 0 1)))
...

Fix this confusing behaviour by ensuring the oacc function attribute is
indeed replaced.

---
 gcc/omp-general.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/gcc/omp-general.c b/gcc/omp-general.c
index 99d8226ef21..e37a6e0b96c 100644
--- a/gcc/omp-general.c
+++ b/gcc/omp-general.c
@@ -545,9 +545,13 @@ oacc_replace_fn_attrib (tree fn, tree dims)
   tree ident = get_identifier (OACC_FN_ATTRIB);
   tree attribs = DECL_ATTRIBUTES (fn);
 
-  /* If we happen to be present as the first attrib, drop it.  */
-  if (attribs && TREE_PURPOSE (attribs) == ident)
-attribs = TREE_CHAIN (attribs);
+  tree *elem = &attribs;
+  while (*elem && TREE_PURPOSE (*elem) != ident)
+elem = &TREE_CHAIN (attribs);
+
+  if (*elem)
+*elem = TREE_CHAIN (*elem);
+
   DECL_ATTRIBUTES (fn) = tree_cons (ident, dims, attribs);
 }
 

[PATCH, middle-end/i386]: Fix PR88556, Inline built-in sinh, cosh, tanh for -ffast-math

[Uros Bizjak]

Attached patch inlines calls to asinh{,f,l}, acosh{,f,l} and
atanh{,f,l} using x87 XFmode arithmetic. The expanders are modelled
after the removed inlines in glibc [1].

2018-12-20  Uros Bizjak  

PR target/88556
* internal-fn.def (COSH): New.
(SINH): Ditto.
(TANH): Ditto.
* optabs.def (cosh_optab): New.
(sinh_optab): Ditto.
(tanh_optab): Ditto.
* config/i386/i386-protos.h (ix86_emit_i387_sinh): New prototype.
(ix86_emit_i387_cosh): Ditto.
(ix86_emit_i387_tanh): Ditto.
* config/i386/i386.c (ix86_emit_i387_sinh): New function.
(ix86_emit_i387_cosh): Ditto.
(ix86_emit_i387_tanh): Ditto.
* config/i386/i386.md (sinhxf2): New expander.
(sinh2):Ditto.
(coshxf2): Ditto.
(cosh2): Ditto.
(tanhxf2): Ditto.
(tanh2): Ditto.

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

The patch also needs approval for its straightforward middle-end parts.

[1] https://sourceware.org/ml/libc-alpha/2018-12/msg00772.html

Uros.
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index ae118079b34..1e802bac1ea 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -170,6 +170,9 @@ extern void x86_function_profiler (FILE *, int);
 extern void x86_emit_floatuns (rtx [2]);
 extern void ix86_emit_fp_unordered_jump (rtx);
 
+extern void ix86_emit_i387_sinh (rtx, rtx);
+extern void ix86_emit_i387_cosh (rtx, rtx);
+extern void ix86_emit_i387_tanh (rtx, rtx);
 extern void ix86_emit_i387_asinh (rtx, rtx);
 extern void ix86_emit_i387_acosh (rtx, rtx);
 extern void ix86_emit_i387_atanh (rtx, rtx);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b3c86761e25..958980319ef 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -44199,6 +44199,122 @@ ix86_emit_fp_unordered_jump (rtx label)
   JUMP_LABEL (insn) = label;
 }
 
+/* Output code to perform an sinh XFmode calculation.  */
+
+void ix86_emit_i387_sinh (rtx op0, rtx op1)
+{
+  rtx e1 = gen_reg_rtx (XFmode);
+  rtx e2 = gen_reg_rtx (XFmode);
+  rtx scratch = gen_reg_rtx (HImode);
+  rtx flags = gen_rtx_REG (CCNOmode, FLAGS_REG);
+  rtx half = const_double_from_real_value (dconsthalf, XFmode);
+  rtx cst1, tmp;
+  rtx_code_label *jump_label = gen_label_rtx ();
+  rtx_insn *insn;
+
+  /* scratch = fxam (op1) */
+  emit_insn (gen_fxamxf2_i387 (scratch, op1));
+
+  /* e1 = expm1 (|op1|) */
+  emit_insn (gen_absxf2 (e2, op1));
+  emit_insn (gen_expm1xf2 (e1, e2));
+
+  /* e2 = e1 / (e1 + 1.0) + e1 */
+  cst1 = force_reg (XFmode, CONST1_RTX (XFmode));
+  emit_insn (gen_addxf3 (e2, e1, cst1));
+  emit_insn (gen_divxf3 (e2, e1, e2));
+  emit_insn (gen_addxf3 (e2, e2, e1));
+
+  /* flags = signbit (op1) */
+  emit_insn (gen_testqi_ext_1_ccno (scratch, GEN_INT (0x02)));
+
+  /* if (flags) then e2 = -e2 */
+  tmp = gen_rtx_IF_THEN_ELSE (VOIDmode,
+ gen_rtx_EQ (VOIDmode, flags, const0_rtx),
+ gen_rtx_LABEL_REF (VOIDmode, jump_label),
+ pc_rtx);
+  insn = emit_jump_insn (gen_rtx_SET (pc_rtx, tmp));
+  predict_jump (REG_BR_PROB_BASE * 50 / 100);
+  JUMP_LABEL (insn) = jump_label;
+
+  emit_insn (gen_negxf2 (e2, e2));
+
+  emit_label (jump_label);
+  LABEL_NUSES (jump_label) = 1;
+
+  /* op0 = 0.5 * e2 */
+  half = force_reg (XFmode, half);
+  emit_insn (gen_mulxf3 (op0, e2, half));
+}
+
+/* Output code to perform an cosh XFmode calculation.  */
+
+void ix86_emit_i387_cosh (rtx op0, rtx op1)
+{
+  rtx e1 = gen_reg_rtx (XFmode);
+  rtx e2 = gen_reg_rtx (XFmode);
+  rtx half = const_double_from_real_value (dconsthalf, XFmode);
+  rtx cst1;
+
+  /* e1 = exp (op1) */
+  emit_insn (gen_expxf2 (e1, op1));
+
+  /* e2 = e1 + 1.0 / e1 */
+  cst1 = force_reg (XFmode, CONST1_RTX (XFmode));
+  emit_insn (gen_divxf3 (e2, cst1, e1));
+  emit_insn (gen_addxf3 (e2, e1, e2));
+
+  /* op0 = 0.5 * e2 */
+  half = force_reg (XFmode, half);
+  emit_insn (gen_mulxf3 (op0, e2, half));
+}
+
+/* Output code to perform an tanh XFmode calculation.  */
+
+void ix86_emit_i387_tanh (rtx op0, rtx op1)
+{
+  rtx e1 = gen_reg_rtx (XFmode);
+  rtx e2 = gen_reg_rtx (XFmode);
+  rtx scratch = gen_reg_rtx (HImode);
+  rtx flags = gen_rtx_REG (CCNOmode, FLAGS_REG);
+  rtx cst2, tmp;
+  rtx_code_label *jump_label = gen_label_rtx ();
+  rtx_insn *insn;
+
+  /* scratch = fxam (op1) */
+  emit_insn (gen_fxamxf2_i387 (scratch, op1));
+
+  /* e1 = expm1 (-|2 * op1|) */
+  emit_insn (gen_addxf3 (e2, op1, op1));
+  emit_insn (gen_absxf2 (e2, e2));
+  emit_insn (gen_negxf2 (e2, e2));
+  emit_insn (gen_expm1xf2 (e1, e2));
+
+  /* e2 = e1 / (e1 + 2.0) */
+  cst2 = force_reg (XFmode, CONST2_RTX (XFmode));
+  emit_insn (gen_addxf3 (e2, e1, cst2));
+  emit_insn (gen_divxf3 (e2, e1, e2));
+
+  /* flags = signbit (op1) */
+  emit_insn (gen_testqi_ext_1_ccno (scratch, GEN_INT (0x02)));
+
+  /* if (!flags) then e2 = -e2 */
+  tmp = gen_rtx_IF_THEN_ELSE (VOIDmode,
+ gen_rtx_NE (V

Re: [patch][aarch64-*-*freebsd*] Enable TARGET_DEFAULT_ASYNC_UNWIND_TABLES

[Richard Earnshaw (lists)]

On 12/12/2018 21:32, Andreas Tobler wrote:
> Hi all,
> 
> I have this patch since a longer time in my tree. No obvious fallout
> visible.
> 
> I'm going to commit this patch in the next days if no one objects.
> 
> TIA,
> Andreas
> 
> 2018-12-12  Andreas Tobler  
> 
> * config.gcc: Enable TARGET_DEFAULT_ASYNC_UNWIND_TABLES on
> aarch64*-*-freebsd*.
> 

This is OK (we already do it for linux, so I suggest you just go ahead).

R.

> 
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc    (revision 267063)
> +++ gcc/config.gcc    (working copy)
> @@ -1012,6 +1012,7 @@
>  tm_file="${tm_file} dbxelf.h elfos.h ${fbsd_tm_file}"
>  tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-freebsd.h"
>  tmake_file="${tmake_file} aarch64/t-aarch64 aarch64/t-aarch64-freebsd"
> +    tm_defines="${tm_defines}  TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
>  ;;
>  aarch64*-*-linux*)
>  tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h
> glibc-stdint.h"

Re: [PATCH, middle-end/i386]: Fix PR88556, Inline built-in sinh, cosh, tanh for -ffast-math

[Richard Biener]

On Thu, Dec 20, 2018 at 11:08 AM Uros Bizjak  wrote:
>
> Attached patch inlines calls to asinh{,f,l}, acosh{,f,l} and
> atanh{,f,l} using x87 XFmode arithmetic. The expanders are modelled
> after the removed inlines in glibc [1].
>
> 2018-12-20  Uros Bizjak  
>
> PR target/88556
> * internal-fn.def (COSH): New.
> (SINH): Ditto.
> (TANH): Ditto.
> * optabs.def (cosh_optab): New.
> (sinh_optab): Ditto.
> (tanh_optab): Ditto.
> * config/i386/i386-protos.h (ix86_emit_i387_sinh): New prototype.
> (ix86_emit_i387_cosh): Ditto.
> (ix86_emit_i387_tanh): Ditto.
> * config/i386/i386.c (ix86_emit_i387_sinh): New function.
> (ix86_emit_i387_cosh): Ditto.
> (ix86_emit_i387_tanh): Ditto.
> * config/i386/i386.md (sinhxf2): New expander.
> (sinh2):Ditto.
> (coshxf2): Ditto.
> (cosh2): Ditto.
> (tanhxf2): Ditto.
> (tanh2): Ditto.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> The patch also needs approval for its straightforward middle-end parts.

Consider those "obvious".

Richard.

>
> [1] https://sourceware.org/ml/libc-alpha/2018-12/msg00772.html
>
> Uros.

Re: [PATCH, ARM] Fix PR77904 testcase failure

[Richard Earnshaw (lists)]

On 14/12/2018 23:28, Thomas Preudhomme wrote:
> Hi,
> 
> Commit r242693 forced fp to be saved/restored when needed due to an
> instance of GCC using fp as a scratch register to save sp while it's
> being clobbered by an inline asm. The normal path in
> thumb1_compute_save_reg_mask saving callee-saved registers which are
> live in the function does not work in that case because fp is chosen to
> hold sp after that function is called.
> 
> Since clobbering sp is now errored out by the compiler and this was the
> only case reported where fp was live but not marked as such when
> thumb1_compute_save_reg_mask is called, I believe the whole commit
> r242693 should be reverted.
> 
> ChangeLog entries are as follows:
> 
> *** gcc/ChangeLog ***
> 
> 2018-12-14  Thomas Preud'homme  
> 
> Revert:
> 2016-11-22  Thomas Preud'homme  
> 
> PR target/77904
> * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer
> in save register mask if it is needed.
> 
> *** gcc/testsuite/ChangeLog ***
> 
> 2018-12-14  Thomas Preud'homme  
> 
> Revert:
> 2016-11-22  Thomas Preud'homme  
> 
> PR target/77904
> * gcc.target/arm/pr77904.c: New test.
> 
> Testing: Built an arm-none-eabi GCC cross-compiler targeting Armv6S-M
> and regression testsuite does not show any regression.
> 
> Ok for stage3?

OK.

R.

> 
> Best regards,
> 
> Thomas
> 
> 
> fix_pr77904_test_failure.patch
> 
> From 63c52e7bf932947be7122cdc63f6cdc913479259 Mon Sep 17 00:00:00 2001
> From: Thomas Preud'homme 
> Date: Fri, 14 Dec 2018 16:02:59 +
> Subject: [PATCH] [PATCH, ARM] Fix PR77904 testcase failure
> 
> Hi,
> 
> Commit r242693 forced fp to be saved/restored when needed due to an
> instance of GCC using fp as a scratch register to save sp while it's
> being clobbered by an inline asm. The normal path in
> thumb1_compute_save_reg_mask saving callee-saved registers which are
> live in the function does not work in that case because fp is chosen to
> hold sp after that function is called.
> 
> Since clobbering sp is now errored out by the compiler and this was the
> only case reported where fp was live but not marked as such when
> thumb1_compute_save_reg_mask is called, I believe the whole commit
> r242693 should be reverted.
> 
> ChangeLog entries are as follows:
> 
> *** gcc/ChangeLog ***
> 
> 2018-12-14  Thomas Preud'homme  
> 
> Revert:
> 2016-11-22  Thomas Preud'homme  
> 
> PR target/77904
> * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer
> in save register mask if it is needed.
> 
> *** gcc/testsuite/ChangeLog ***
> 
> 2018-12-14  Thomas Preud'homme  
> 
> Revert:
> 2016-11-22  Thomas Preud'homme  
> 
> PR target/77904
> * gcc.target/arm/pr77904.c: New test.
> 
> Testing: Built an arm-none-eabi GCC cross-compiler targeting Armv6S-M
> and regression testsuite does not show any regression.
> 
> Ok for stage3?
> 
> Best regards,
> 
> Thomas
> ---
>  gcc/ChangeLog  |  9 ++
>  gcc/config/arm/arm.c   |  4 ---
>  gcc/testsuite/ChangeLog|  8 +
>  gcc/testsuite/gcc.target/arm/pr77904.c | 45 --
>  4 files changed, 17 insertions(+), 49 deletions(-)
>  delete mode 100644 gcc/testsuite/gcc.target/arm/pr77904.c
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index d8e374fb15f..9caeb1d5e18 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,12 @@
> +2018-12-14  Thomas Preud'homme  
> +
> + Revert:
> + 2016-11-22  Thomas Preud'homme  
> +
> + PR target/77904
> + * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer
> + in save register mask if it is needed.
> +
>  2018-11-27  Alan Modra  
>  
>   * config/rs6000/aix71.h (ASM_SPEC): Don't select default -maix64
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 40f0574e32e..2ab5d8abc33 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -19553,10 +19553,6 @@ thumb1_compute_save_core_reg_mask (void)
>  if (df_regs_ever_live_p (reg) && callee_saved_reg_p (reg))
>mask |= 1 << reg;
>  
> -  /* Handle the frame pointer as a special case.  */
> -  if (frame_pointer_needed)
> -mask |= 1 << HARD_FRAME_POINTER_REGNUM;
> -
>if (flag_pic
>&& !TARGET_SINGLE_PIC_BASE
>&& arm_pic_register != INVALID_REGNUM
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 9e1f6d05a45..4e58c8940da 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,11 @@
> +2018-12-14  Thomas Preud'homme  
> +
> + Revert:
> + 2016-11-22  Thomas Preud'homme  
> +
> + PR target/77904
> + * gcc.target/arm/pr77904.c: New test.
> +
>  2018-11-27  Jozef Lawrynowicz  
>  
>   * lib/target-supports.exp
> diff --git a/gcc/testsuite/gcc.target/arm/pr77904.c 
> b/gcc/testsuite/gcc.target/arm/pr77904.c
> deleted file mode 100644
> index 76728c07e73..000
> --- a/gcc/testsuite/gcc.target

Re: LRA patch for PR87718

[Sam Tebbs]

On 11/24/18 11:29 AM, Christophe Lyon wrote:

> On Thu, 22 Nov 2018 at 18:30, Vladimir Makarov  
> wrote:
>> The following patch fixes
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
>>
>> The patch adds a special treatment for moves with a hard register in
>> register cost and class calculation.
>>
>> The patch was bootstrapped and tested on x86-64 and ppc64.
>>
>> I found two testsuite regressions because of the patch. The expected
>> generated code for PR82361 test is too specific. GCC with the patch
>> generates the same quality code but with a different hard register on
>> x86-64. So I just changed the test for PR82361.
>>
>> Another test is for ppc64. I think the expected generated code for
>> this test is wrong. I'll submit a changed test for a discussion later.
>>
>> Although I spent much time on the solution and I think it is the
>> right one, the patch is in very sensitive area of RA and may affect
>> expected code generation for many targets. I am ready to work on the
>> new regressions as soon as they are found.
>>
>> The patch was committed as rev. 260385.
>>
> Hi,
>
> This patch introduced at least several ICEs on arm targets:
> on arm-none-linux-gnueabi --with-cpu=cortex-a9:

> There are other regressions on the same targets, but not ICEs.
> I can report them later.
>
> Thanks,
>
> Christophe

Hi Christophe and Vladimir,

Here are the regressions seen on arm-none-linux-gnueabihf and arm-none-eabi.

FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times 
ldrh\\tr[0-9]+ 2
FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times 
vld1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2
FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times 
vmov\\.f16\\ts[0-9]+, r[0-9]+ 2
FAIL: gcc.target/arm/fp16-aapcs-1.c scan-assembler 
vmov(\\.f16)?\\tr[0-9]+, s[0-9]+
FAIL: gcc.target/arm/fp16-aapcs-1.c scan-assembler vmov(\\.f16)?\\ts0, 
r[0-9]+
FAIL: gcc.target/arm/fp16-aapcs-3.c scan-assembler-times vmov\\tr[0-9]+, 
s[0-2] 2
FAIL: gcc.target/arm/fp16-aapcs-3.c scan-assembler-times vmov\\ts0, 
r[0-9]+ 2

I didn't see a bug report for these, so I will open one.

It is not clear if the test cases should be adjusted because of your 
patch or if they are failing because of incorrect codegen. Attached is 
the code generated for armv8_2-fp16-move-1.c (one of the test files 
failing) with and without your patch.

Full command line used to compile and test armv8_2-fp16-move-1.c:

bin/gcc armv8_2-fp16-move-1.c -fno-diagnostics-show-caret 
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 
-mfpu=fp-armv8 -march=armv8.2-a+fp16 -mfloat-abi=hard -ffat-lto-objects 
-fno-ident -S -o armv8_2-fp16-move-1.s.



.arch armv8.2-a
.eabi_attribute 28, 1
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 38, 1
.eabi_attribute 18, 4
.file   "armv8_2-fp16-move-1.c"
.text
.align  1
.p2align 2,,3
.global test_load_1
.arch armv8.2-a
.syntax unified
.thumb
.thumb_func
.fpu fp-armv8
.type   test_load_1, %function
test_load_1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vld1.16 {d0[0]}, [r0]
bx  lr
.size   test_load_1, .-test_load_1
.align  1
.p2align 2,,3
.global test_load_2
.syntax unified
.thumb
.thumb_func
.fpu fp-armv8
.type   test_load_2, %function
test_load_2:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add r3, r0, r1, lsl #1
vld1.16 {d0[0]}, [r3]
bx  lr
.size   test_load_2, .-test_load_2
.align  1
.p2align 2,,3
.global test_store_1
.syntax unified
.thumb
.thumb_func
.fpu fp-armv8
.type   test_store_1, %function
test_store_1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vst1.16 {d0[0]}, [r0]
bx  lr
.size   test_store_1, .-test_store_1
.align  1
.p2align 2,,3
.global test_store_2
.syntax unified
.thumb
.thumb_func
.fpu fp-armv8
.type   test_store_2, %function
test_store_2:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vmov.f16r3, s0  @ __fp16
strhr3, [r0, r1, lsl #1]@ __fp16
bx  lr
.size   test_store_2, .-test_store_2
.align  1
.p2align 2,,3
.global test_

Re: LRA patch for PR87718

[Sam Tebbs]

On 12/20/18 10:38 AM, Sam Tebbs wrote:
> On 11/24/18 11:29 AM, Christophe Lyon wrote:
>
>> On Thu, 22 Nov 2018 at 18:30, Vladimir Makarov 
>> wrote:
>>> The following patch fixes
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
>>>
>>> The patch adds a special treatment for moves with a hard register in
>>> register cost and class calculation.
>>>
>>> The patch was bootstrapped and tested on x86-64 and ppc64.
>>>
>>> I found two testsuite regressions because of the patch. The expected
>>> generated code for PR82361 test is too specific. GCC with the patch
>>> generates the same quality code but with a different hard register on
>>> x86-64. So I just changed the test for PR82361.
>>>
>>> Another test is for ppc64. I think the expected generated code for
>>> this test is wrong. I'll submit a changed test for a discussion later.
>>>
>>> Although I spent much time on the solution and I think it is the
>>> right one, the patch is in very sensitive area of RA and may affect
>>> expected code generation for many targets. I am ready to work on the
>>> new regressions as soon as they are found.
>>>
>>> The patch was committed as rev. 260385.
>>>
>> Hi,
>>
>> This patch introduced at least several ICEs on arm targets:
>> on arm-none-linux-gnueabi --with-cpu=cortex-a9:
> 
>> There are other regressions on the same targets, but not ICEs.
>> I can report them later.
>>
>> Thanks,
>>
>> Christophe
> Hi Christophe and Vladimir,
>
> Here are the regressions seen on arm-none-linux-gnueabihf and arm-none-eabi.
>
> FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
> ldrh\\tr[0-9]+ 2
> FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
> vld1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2
> FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
> vmov\\.f16\\ts[0-9]+, r[0-9]+ 2
> FAIL: gcc.target/arm/fp16-aapcs-1.c scan-assembler
> vmov(\\.f16)?\\tr[0-9]+, s[0-9]+
> FAIL: gcc.target/arm/fp16-aapcs-1.c scan-assembler vmov(\\.f16)?\\ts0,
> r[0-9]+
> FAIL: gcc.target/arm/fp16-aapcs-3.c scan-assembler-times vmov\\tr[0-9]+,
> s[0-2] 2
> FAIL: gcc.target/arm/fp16-aapcs-3.c scan-assembler-times vmov\\ts0,
> r[0-9]+ 2
>
> I didn't see a bug report for these, so I will open one.
>
> It is not clear if the test cases should be adjusted because of your
> patch or if they are failing because of incorrect codegen. Attached is
> the code generated for armv8_2-fp16-move-1.c (one of the test files
> failing) with and without your patch.
>
> Full command line used to compile and test armv8_2-fp16-move-1.c:
>
> bin/gcc armv8_2-fp16-move-1.c -fno-diagnostics-show-caret
> -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2
> -mfpu=fp-armv8 -march=armv8.2-a+fp16 -mfloat-abi=hard -ffat-lto-objects
> -fno-ident -S -o armv8_2-fp16-move-1.s.
Reported as PR 88560 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560).

[PATCH] Fix PR84362

[Richard Biener]

There's a long-standing issue with LIM which isn't very good at 
recognizing same memory references esp. when they are in MEM vs.
traditional form.  The following rectifies this for the class
of refs we can compute get_addr_base_and_unit_offset on (that
makes it easy to create a canonical ref).

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2018-12-20  Richard Biener  

PR tree-optimization/84362
* tree-ssa-loop-im.c: Include alias.h, builtins.h and tree-dfa.h.
(struct im_mem_ref): add ref_canonical flag.
(struct mem_ref_hasher): Use ao_ref as compare_type.
(mem_ref_hasher::equal): Adjust and add variant comparing ao_ref
parts.
(mem_ref_alloc): Take ao_ref parameter, initialize ref_canonical
member.
(gather_mem_refs_stmt): Set up ao_ref early and do the lookup
using it.  If we have non-equal refs canonicalize the one
in the hashtable used for insertion.
(tree_ssa_lim_initialize): Adjust.

* g++.dg/vect/pr84362.cc: New testcase.

Index: gcc/testsuite/g++.dg/vect/pr84362.cc
===
--- gcc/testsuite/g++.dg/vect/pr84362.cc(nonexistent)
+++ gcc/testsuite/g++.dg/vect/pr84362.cc(working copy)
@@ -0,0 +1,28 @@
+// { dg-do compile }
+// { dg-require-effective-target c++11 }
+
+constexpr unsigned int capacity = 1000;
+
+struct vec
+{
+  int values[capacity];
+  unsigned int _size = 0;
+  unsigned int size() const noexcept { return _size; }
+  void push(int x)
+{
+  values[size()] = x;
+  ++_size;
+}
+};
+
+int main()
+{
+  vec v;
+  for(unsigned int i{0}; i != capacity; ++i)
+{
+  v.push(i);
+}
+  asm volatile("" : : "g"(&v) : "memory");
+}
+
+// { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" { 
target vect_int } } }
Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c  (revision 267262)
+++ gcc/tree-ssa-loop-im.c  (working copy)
@@ -45,6 +45,9 @@ along with GCC; see the file COPYING3.
 #include "gimple-fold.h"
 #include "tree-scalar-evolution.h"
 #include "tree-ssa-loop-niter.h"
+#include "alias.h"
+#include "builtins.h"
+#include "tree-dfa.h"
 
 /* TODO:  Support for predicated code motion.  I.e.
 
@@ -112,8 +115,9 @@ struct mem_ref_loc
 
 struct im_mem_ref
 {
-  unsigned id; /* ID assigned to the memory reference
+  unsigned id : 31;/* ID assigned to the memory reference
   (its index in memory_accesses.refs_list)  */
+  unsigned ref_canonical : 1;   /* Whether mem.ref was canonicalized.  */
   hashval_t hash;  /* Its hash value.  */
 
   /* The memory access itself and associated caching of alias-oracle
@@ -149,9 +153,9 @@ struct im_mem_ref
 
 struct mem_ref_hasher : nofree_ptr_hash 
 {
-  typedef tree_node *compare_type;
+  typedef ao_ref *compare_type;
   static inline hashval_t hash (const im_mem_ref *);
-  static inline bool equal (const im_mem_ref *, const tree_node *);
+  static inline bool equal (const im_mem_ref *, const ao_ref *);
 };
 
 /* A hash function for struct im_mem_ref object OBJ.  */
@@ -166,9 +170,19 @@ mem_ref_hasher::hash (const im_mem_ref *
memory reference OBJ2.  */
 
 inline bool
-mem_ref_hasher::equal (const im_mem_ref *mem1, const tree_node *obj2)
+mem_ref_hasher::equal (const im_mem_ref *mem1, const ao_ref *obj2)
 {
-  return operand_equal_p (mem1->mem.ref, (const_tree) obj2, 0);
+  if (obj2->max_size_known_p ())
+return (operand_equal_p (mem1->mem.base, obj2->base, 0)
+   && known_eq (mem1->mem.offset, obj2->offset)
+   && known_eq (mem1->mem.size, obj2->size)
+   && known_eq (mem1->mem.max_size, obj2->max_size)
+   && mem1->mem.volatile_p == obj2->volatile_p
+   && mem1->mem.ref_alias_set == obj2->ref_alias_set
+   && types_compatible_p (TREE_TYPE (mem1->mem.ref),
+  TREE_TYPE (obj2->ref)));
+  else
+return operand_equal_p (mem1->mem.ref, obj2->ref, 0);
 }
 
 
@@ -1356,11 +1370,15 @@ memref_free (struct im_mem_ref *mem)
value is HASH and id is ID.  */
 
 static im_mem_ref *
-mem_ref_alloc (tree mem, unsigned hash, unsigned id)
+mem_ref_alloc (ao_ref *mem, unsigned hash, unsigned id)
 {
   im_mem_ref *ref = XOBNEW (&mem_ref_obstack, struct im_mem_ref);
-  ao_ref_init (&ref->mem, mem);
+  if (mem)
+ref->mem = *mem;
+  else
+ao_ref_init (&ref->mem, error_mark_node);
   ref->id = id;
+  ref->ref_canonical = false;
   ref->hash = hash;
   ref->stored = NULL;
   bitmap_initialize (&ref->indep_loop, &lim_bitmap_obstack);
@@ -1436,17 +1454,79 @@ gather_mem_refs_stmt (struct loop *loop,
 }
   else
 {
-  hash = iterative_hash_expr (*mem, 0);
-  slot = memory_accesses.refs->find_slot_with_hash (*mem, hash, INSERT);
+  /* We are looking for equal refs that migh

[patch] Fix PR rtl-optimization/87727

[Eric Botcazou]

Hi,

this is a regression introduced on the SPARC by the somewhat controversial 
combiner change for hard registers: the compiler can no longer apply the leaf 
registers optimization to a small function so a register window is now used.

The combiner change might be an overall win, but my understanding is that it's 
dependent on the target and SPARC seems to be in the wrong basket: almost all 
changes to the gcc.c-torture/compile testsuite at -O2 are pessimizations in 
the form of additional move instructions between registers on function entry.

Clearly that's counter-productive for a LEAF_REGISTERS target like SPARC so 
the proposed fix is to re-enable hard register combining for leaf registers.

Tested on SPARC/Solaris 11, OK for the mainline?


2018-12-20  Eric Botcazou  

PR rtl-optimization/87727
* combine.c (cant_combine_insn_p): On a LEAF_REGISTERS target, combine
again moves from leaf hard registers.

-- 
Eric BotcazouIndex: combine.c
===
--- combine.c	(revision 267029)
+++ combine.c	(working copy)
@@ -2349,7 +2349,12 @@ cant_combine_insn_p (rtx_insn *insn)
 dest = SUBREG_REG (dest);
   if (REG_P (src) && REG_P (dest)
   && ((HARD_REGISTER_P (src)
-	   && ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (src)))
+	   && ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (src))
+#ifdef LEAF_REGISTERS
+	   && ! LEAF_REGISTERS [REGNO (src)])
+#else
+	   )
+#endif
 	  || (HARD_REGISTER_P (dest)
 	  && ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (dest))
 	  && targetm.class_likely_spilled_p (REGNO_REG_CLASS (REGNO (dest))

Re: [Patch] Bug 88521 - gcc 9.0 from r266355 miscompile x265 for mingw-w64 target

[Jakub Jelinek]

On Thu, Dec 20, 2018 at 01:42:15PM +0530, Lokesh Janghel wrote:
> Hi Mateuszb,
> 
> I tested with your proposition patch and it is working right.
> I also added the patch with test case.
> Please let me know your thoughts/suggestions.

ChangeLog entry is missing, please write it (and mention there
Mateusz's name/mail as he wrote the i386.c part).

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b3c8676..e54c489 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -9063,6 +9063,13 @@ function_value_ms_64 (machine_mode orig_mode, 
machine_mode mode,
  && !COMPLEX_MODE_P (mode))
regno = FIRST_SSE_REG;
  break;
+   case 8:
+   case 4:
+ if (valtype != NULL_TREE && AGGREGATE_TYPE_P (valtype))
+   break;
+ if (mode == SFmode || mode == DFmode)
+   regno = FIRST_SSE_REG;
+ break;
default:
  break;
 }
diff --git a/gcc/testsuite/gcc.target/i386/pr88521.c 
b/gcc/testsuite/gcc.target/i386/pr88521.c
new file mode 100644
index 000..f42703a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr88521.c
@@ -0,0 +1,30 @@
+/* { dg-do compile { target lp64 } } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-times "movl\[^\n\r]*, %eax|mov\[ \t]*eax," 1 } 
} */

You try here to handle both -masm=att and -masm=intel

+/* { dg-final { scan-assembler-times "movss\[^\n\r]*, %xmm" 1 } } */
+/* { dg-final { scan-assembler-times "movsd\[^\n\r]*, %xmm" 1 } } */

but not here.  For that it would need to be "movss\[^\n\r]*(?:, %xmm|xmm, )"
and similarly for movsd (please verify with
make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-m32/-masm=att,-m32/-masm=intel,-m64/-masm=att,-m64/-masm=intel\}
 i386.exp=pr88521.c'

I'll defer the final review to Uros.

Jakub

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

[Richard Biener]

On Thu, Dec 20, 2018 at 12:43 PM Eric Botcazou  wrote:
>
> Hi,
>
> this is a regression introduced on the SPARC by the somewhat controversial
> combiner change for hard registers: the compiler can no longer apply the leaf
> registers optimization to a small function so a register window is now used.
>
> The combiner change might be an overall win, but my understanding is that it's
> dependent on the target and SPARC seems to be in the wrong basket: almost all
> changes to the gcc.c-torture/compile testsuite at -O2 are pessimizations in
> the form of additional move instructions between registers on function entry.
>
> Clearly that's counter-productive for a LEAF_REGISTERS target like SPARC so
> the proposed fix is to re-enable hard register combining for leaf registers.
>
> Tested on SPARC/Solaris 11, OK for the mainline?

This only affects xtensa besides sparc so unless Segher objects this is OK.

Does this solve most of the pessimizations?

Please add a testcase if it doesn't solve existing FAILs.

Thanks,
Richard.

>
> 2018-12-20  Eric Botcazou  
>
> PR rtl-optimization/87727
> * combine.c (cant_combine_insn_p): On a LEAF_REGISTERS target, combine
> again moves from leaf hard registers.
>
> --
> Eric Botcazou

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

[Jakub Jelinek]

On Thu, Dec 20, 2018 at 01:15:53PM +0100, Richard Biener wrote:
> On Thu, Dec 20, 2018 at 12:43 PM Eric Botcazou  wrote:
> > this is a regression introduced on the SPARC by the somewhat controversial
> > combiner change for hard registers: the compiler can no longer apply the 
> > leaf
> > registers optimization to a small function so a register window is now used.
> >
> > The combiner change might be an overall win, but my understanding is that 
> > it's
> > dependent on the target and SPARC seems to be in the wrong basket: almost 
> > all
> > changes to the gcc.c-torture/compile testsuite at -O2 are pessimizations in
> > the form of additional move instructions between registers on function 
> > entry.
> >
> > Clearly that's counter-productive for a LEAF_REGISTERS target like SPARC so
> > the proposed fix is to re-enable hard register combining for leaf registers.
> >
> > Tested on SPARC/Solaris 11, OK for the mainline?
> 
> This only affects xtensa besides sparc so unless Segher objects this is OK.
> 
> Does this solve most of the pessimizations?
> 
> Please add a testcase if it doesn't solve existing FAILs.

Generally it would be better to deal with that in RA, but if Vlad doesn't
have cycles for it right now, your hack isn't that bad.

> > 2018-12-20  Eric Botcazou  
> >
> > PR rtl-optimization/87727
> > * combine.c (cant_combine_insn_p): On a LEAF_REGISTERS target, 
> > combine
> > again moves from leaf hard registers.

Jakub

Re: [PATCH] LWG 3171: restore stream insertion for filesystem::directory_entry

[Jonathan Wakely]

On 20/12/18 04:08 -0500, Tim Song wrote:

On Tue, Dec 18, 2018 at 10:57 AM Jonathan Wakely  wrote:


* include/bits/fs_dir.h (operator<<): Overload for directory_entry,
as per LWG 3171.
* testsuite/27_io/filesystem/directory_entry/lwg3171.cc: New test.

Tested x86_64-linux, committed to trunk.




The test seems to be missing from the patch.


Thanks, I forgot to 'git add' it. Fixed by this, committed to trunk.


commit 7274fd7de0a1ea4c8ab12cec8a6a5ae38bcbdea1
Author: Jonathan Wakely 
Date:   Thu Dec 20 12:13:17 2018 +

Add missing test from previous commit

* testsuite/27_io/filesystem/directory_entry/lwg3171.cc: New test
(missed from previous commit).

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/directory_entry/lwg3171.cc b/libstdc++-v3/testsuite/27_io/filesystem/directory_entry/lwg3171.cc
new file mode 100644
index 000..d9adffbac4d
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/filesystem/directory_entry/lwg3171.cc
@@ -0,0 +1,40 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++17 -lstdc++fs" }
+// { dg-do run { target c++17 } }
+// { dg-require-filesystem-ts "" }
+
+#include 
+#include 
+#include 
+
+void
+test01()
+{
+  std::filesystem::directory_entry ent("foo/bar");
+  std::ostringstream os1, os2;
+  os1 << ent;
+  os2 << ent.path();
+  VERIFY( os1.str() == os2.str() );
+}
+
+int
+main()
+{
+  test01();
+}

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

[Wilco Dijkstra]

Hi Martin,

> There is a similar mechanism for pointer-to-member-functions
> used by C++. Is this correct on aarch64?

/* By default, the C++ compiler will use the lowest bit of the pointer
   to function to indicate a pointer-to-member-function points to a
   virtual member function.  However, if FUNCTION_BOUNDARY indicates
   function addresses aren't always even, the lowest bit of the delta
   field will be used.  */
#ifndef TARGET_PTRMEMFUNC_VBIT_LOCATION
#define TARGET_PTRMEMFUNC_VBIT_LOCATION \
  (FUNCTION_BOUNDARY >= 2 * BITS_PER_UNIT \
   ? ptrmemfunc_vbit_in_pfn : ptrmemfunc_vbit_in_delta)
#endif

AArch64 overrides this like Arm to ptrmemfunc_vbit_in_delta.

But yes that's yet another example of GCC using the wrong default.
The assumption that FUNCTION_BOUNDARY implies no use of low
bits is simply false - a generic default should be safe for all targets
(and if that's not possible, there should not be a default).

Cheers,
Wilco

Re: [PATCH] Shuffle ieee_arithmetic.F90

[Thomas Koenig]

Hi Steve,


The attach patch shuffles lines around to eliminate 80
lines of #ifdef...#endif; thereby making the file more
readable.  Tested on i586-*-freebsd and x86_64-*-freebsd.
Patch is a pre-requisite to fixing issues and adding
missing functionality.  OK to commit?

2018-12-18  Steven G. Kargl  

* libgfortran/ieee/ieee_arithmetic.F90: Re-organize file to
eliminate excessive #ifdef ... #endif.



OK. Thanks for the patch!

Regards

Thomas

RFA: Avoid versioning loop with unaligned step

[Joern Wolfgang Rennecke]

eSi-RISC has vector permute functionality, but no unaligned loads. We 
see execution failures on gcc.dg/vect/slp-perm-12.c because loop 
versioning is used to make the tptr aligned for the first loop 
iteration, and then with a step of originally 11, 22 after 
vectorization, and a vector alignment of 8 bytes, the second iteration 
causes an AlignmentError exception.
The attached patch to tree-vect-data-refs.c suppresses attempts to align 
data accesses where the
step alignment times the vectorization factor is insufficient to sustain 
the alignment during the loop.

Bootstrapped and regression tested on x86_64-pc-linux-gnu .

I have also attached a matching testsuite patch to not expect SLP 
vectorization for slp-perm-12 when
no unaligned loads are available, although in terms of testing, I can 
only say that it works for us.
2018-12-15  Joern Rennecke  

* tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Don't do
versioning for data accesses with misaligned step.

Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c   (revision 267262)
+++ tree-vect-data-refs.c   (working copy)
@@ -2160,6 +2160,20 @@ vect_enhance_data_refs_alignment (loop_v
  break;
}
 
+ /* Forcing alignment in the first iteration is no good if
+we don't keep it across iterations.  For now, just disable
+versioning in this case.
+?? We could actually unroll the loop to archive the required
+overall step alignemnt, and forcing the alignment could be
+done by doing some iterations of the non-vectorized loop.  */
+ if (maybe_lt (LOOP_VINFO_VECT_FACTOR (loop_vinfo)
+   * DR_STEP_ALIGNMENT (dr),
+   TYPE_ALIGN_UNIT (vectype)))
+   {
+ do_versioning = false;
+ break;
+   }
+
   /* The rightmost bits of an aligned address must be zeros.
  Construct the mask needed for this test.  For example,
  GET_MODE_SIZE for the vector mode V4SI is 16 bytes so the
2018-12-15  Joern Rennecke  

* testsuite/gcc.dg/vect/slp-perm-12.c (dg-final): Don't expect SLP
vectorization for ! vect_no_align.

Index: testsuite/gcc.dg/vect/slp-perm-12.c
===
--- testsuite/gcc.dg/vect/slp-perm-12.c (revision 5616)
+++ testsuite/gcc.dg/vect/slp-perm-12.c (revision 5617)
@@ -49,4 +49,4 @@ int main()
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" { 
target vect_perm } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" { 
target { vect_perm  && {! vect_no_align } } } } } */

[committed, og8] Disable libstdc++ dependency for libffi

[Maciej W. Rozycki]

Disable AC_PROG_CXX and consequently a libstdc++ dependency for libffi, 
introduced with upstream libffi commit 7d698125b1f0 ("Use the proper C++ 
compiler to run C++ tests").  This is only needed for the libffi test 
suite, which we don't have to support in the GCC tree, as libffi is 
maintained as a separate project.  The dependency causes a build failure
with the `powerpc64le-linux-gnu' target due to a circular dependency:

make[1]: Circular configure-target-libffi <- maybe-all-target-libstdc++-v3 
dependency dropped.
make[1]: *** [configure-target-libffi] Error 1
make: *** [all] Error 2

due to a libgomp dependency for libstdc++ and then a libffi dependency 
for libgomp, introduced with commit 998eb38b265d ("Use functional 
parameters for data mappings in OpenACC child functions").

/
* Makefile.def (lang_env_dependencies): Disable `cxx' dependency
for `libffi'.
* Makefile.in: Regenerate.

libffi/
* configure.ac: Disable AC_PROG_CXX.
* configure: Regenerate.
* Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* man/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
---
 Makefile.def |5 
 Makefile.in  |1 
 libffi/Makefile.in   |5 
 libffi/configure | 3821 ---
 libffi/configure.ac  |5 
 libffi/include/Makefile.in   |5 
 libffi/man/Makefile.in   |5 
 libffi/testsuite/Makefile.in |5 
 8 files changed, 14 insertions(+), 3838 deletions(-)

gcc-openacc-libffi-nolibstdcxx.diff
Index: gcc-openacc-gcc-8-branch/Makefile.def
===
--- gcc-openacc-gcc-8-branch.orig/Makefile.def
+++ gcc-openacc-gcc-8-branch/Makefile.def
@@ -530,7 +530,10 @@ dependencies = { module=all-m4; on=all-b
 // environment (e.g. on libstdc++).  By default target modules depend
 // on libgcc and newlib/libgloss.
 lang_env_dependencies = { module=libitm; cxx=true; };
-lang_env_dependencies = { module=libffi; cxx=true; };
+// Disable libstdc++ dependency for libffi as it's only needed for
+// the library's test suite and it can cause a dependency loop when
+// libgomp, needed by libstdc++, uses libffi.
+// lang_env_dependencies = { module=libffi; cxx=true; };
 lang_env_dependencies = { module=liboffloadmic; cxx=true; };
 lang_env_dependencies = { module=newlib; no_c=true; };
 lang_env_dependencies = { module=libgloss; no_c=true; };
Index: gcc-openacc-gcc-8-branch/Makefile.in
===
--- gcc-openacc-gcc-8-branch.orig/Makefile.in
+++ gcc-openacc-gcc-8-branch/Makefile.in
@@ -58940,7 +58940,6 @@ configure-target-winsup: maybe-all-targe
 
 
 configure-target-libffi: maybe-all-target-newlib maybe-all-target-libgloss
-configure-target-libffi: maybe-all-target-libstdc++-v3
 
 configure-target-zlib: maybe-all-target-newlib maybe-all-target-libgloss
 
Index: gcc-openacc-gcc-8-branch/libffi/Makefile.in
===
--- gcc-openacc-gcc-8-branch.orig/libffi/Makefile.in
+++ gcc-openacc-gcc-8-branch/libffi/Makefile.in
@@ -209,10 +209,6 @@ CCDEPMODE = @CCDEPMODE@
 CFLAGS = @CFLAGS@
 CPP = @CPP@
 CPPFLAGS = @CPPFLAGS@
-CXX = @CXX@
-CXXCPP = @CXXCPP@
-CXXDEPMODE = @CXXDEPMODE@
-CXXFLAGS = @CXXFLAGS@
 CYGPATH_W = @CYGPATH_W@
 DEFS = @DEFS@
 DEPDIR = @DEPDIR@
@@ -274,7 +270,6 @@ abs_srcdir = @abs_srcdir@
 abs_top_builddir = @abs_top_builddir@
 abs_top_srcdir = @abs_top_srcdir@
 ac_ct_CC = @ac_ct_CC@
-ac_ct_CXX = @ac_ct_CXX@
 ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
 am__include = @am__include@
 am__leading_dot = @am__leading_dot@
Index: gcc-openacc-gcc-8-branch/libffi/configure
===
--- gcc-openacc-gcc-8-branch.orig/libffi/configure
+++ gcc-openacc-gcc-8-branch/libffi/configure
@@ -633,7 +633,6 @@ TESTSUBDIR_TRUE
 MAINT
 MAINTAINER_MODE_FALSE
 MAINTAINER_MODE_TRUE
-CXXCPP
 CPP
 OTOOL64
 OTOOL
@@ -658,12 +657,6 @@ am__fastdepCCAS_TRUE
 CCASDEPMODE
 CCASFLAGS
 CCAS
-am__fastdepCXX_FALSE
-am__fastdepCXX_TRUE
-CXXDEPMODE
-ac_ct_CXX
-CXXFLAGS
-CXX
 am__fastdepCC_FALSE
 am__fastdepCC_TRUE
 CCDEPMODE
@@ -786,8 +779,7 @@ target_alias
 CCAS
 CCASFLAGS
 CPP
-CPPFLAGS
-CXXCPP'
+CPPFLAGS'
 
 
 # Initialize some variables set by options.
@@ -1447,12 +1439,9 @@ if test -n "$ac_init_help"; then
   LIBSlibraries to pass to the linker, e.g. -l
   CPPFLAGSC/C++/Objective C preprocessor flags, e.g. -I if
   you have headers in a nonstandard directory 
-  CXX C++ compiler command
-  CXXFLAGSC++ compiler flags
   CCASassembler compiler command (defaults to CC)
   CCASFLAGS   assembler compiler flags (defaults to CFLAGS)
   CPP C preprocessor
-  CXXCPP  C++ preprocessor
 
 Use these variables to override the choices made by `configure' or to help
 it to find libraries 

Re: [PATCH, og8] Add OpenACC 2.6 `acc_get_property' support

[Maciej W. Rozycki]

On Mon, 10 Dec 2018, Chung-Lin Tang wrote:

> I think the patch is okay, although still needs approval from Thomas and Tom
> to commit.

 I have committed this change now, thank you for your review.

  Maciej

Re: [PR 88214] Check that an argument is pointer before attempting agg jf construction from it

[Martin Jambor]

Hi,

On Mon, Dec 10 2018, Richard Biener wrote:
> On Fri, Dec 7, 2018 at 3:59 PM Martin Jambor  wrote:
>>

...

>>
>> On a related note, would people object to adding the following assert,
>> which would have made this bug much more straightforward to find?
>
> That's fine with me.

Thanks, I have just committed the following as r267298 after
bootstrapping and testing it on x86_64-linux.

Martin


2018-12-20  Martin Jambor  

PR ipa/88214
* tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Assert that
ptr is a pointer.
---
 gcc/tree-ssa-alias.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index 85a5de7ce05..66cf2f2c669 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -710,6 +710,7 @@ ao_ref_init_from_ptr_and_size (ao_ref *ref, tree ptr, tree 
size)
 }
   else
 {
+  gcc_assert (POINTER_TYPE_P (TREE_TYPE (ptr)));
   ref->base = build2 (MEM_REF, char_type_node,
  ptr, null_pointer_node);
   ref->offset = 0;
-- 
2.19.2

Re: [PATCH] -Wtautological-compare: fix comparison of macro expansions

[David Malcolm]

On Wed, 2018-12-19 at 22:01 -0500, David Malcolm wrote:
> On Wed, 2018-12-19 at 17:27 -0600, Aaron Sawdey wrote:
> > Assuming you applied this as svn 267273, it causes bootstrap
> > failure
> > on powerpc64le-unknown-linux-gnu. Stage 2 fails with multiple
> > instances
> > of this error:
> > 
> > ../../trunk-base/gcc/c-family/c-pragma.c: In function ‘void
> > handle_pragma_scalar_storage_order(cpp_reader*)’:
> > ../../trunk-base/gcc/c-family/c-pragma.c:417:24: error: self-
> > comparison always evaluates to false [-Werror=tautological-compare]
> >   417 |   if (BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN)
> >   |^~
> > ../../trunk-base/gcc/c-family/c-attribs.c: In function ‘tree_node*
> > handle_scalar_storage_order_attribute(tree_node**, tree, tree, int,
> > bool*)’:
> > ../../trunk-base/gcc/c-family/c-attribs.c:1401:24: error: self-
> > comparison always evaluates to false [-Werror=tautological-compare]
> >  1401 |   if (BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN)
> >   |^~
> > ../../trunk-base/gcc/builtins.c: In function ‘rtx_def*
> > c_readstr(const char*, scalar_int_mode)’:
> > ../../trunk-base/gcc/builtins.c:830:28: error: self-comparison
> > always
> > evaluates to false [-Werror=tautological-compare]
> >   830 |   if (BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN
> >   |^~
> > ../../trunk-base/gcc/combine.c: In function ‘int
> > rtx_equal_for_field_assignment_p(rtx, rtx, bool)’:
> > ../../trunk-base/gcc/combine.c:9668:28: error: self-comparison
> > always
> > evaluates to false [-Werror=tautological-compare]
> >  9668 |   if (BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN)
> >   |^~
> > 
> > Aaron
> 
> Sorry about that.
> 
> Does the following patch help?  (testing in progress here)
[...snip...]

According to comments within PR c++/87504, the patch fixes the
bootstrap on aarch64, and fixes a similar issue on Solaris/SPARC.

It also passed bootstrap®rtesting on x86_64-pc-linux-gnu.

Given that, I've committed it to trunk as r267299.

Aaron, does this fix the issue you saw?

Thanks, and sorry again about the breakage.
Dave

[og8] Report errors on missing OpenACC reduction clauses in nested reductions

[Thomas Schwinge]

Hi!

On behalf of Gergő (who doesn't have write access yet) I've pushed the
attached to openacc-gcc-8-branch.


Grüße
 Thomas


From a9e48066198ffb1e7bc2b137167a61a6cb47748c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerg=C3=B6=20Barany?= 
Date: Thu, 20 Dec 2018 15:07:34 +0100
Subject: [PATCH] Report errors on missing OpenACC reduction clauses in nested
 reductions

..., as suggested by OpenACC 2.6, 2.9.11. "reduction clause".

In gcc/testsuite/c-c++-common/goacc/reduction-6.c, we remove the erroneous
reductions on variable b; adding a reduction clause to make it compile cleanly
would make it a duplicate of the test for variable c.

	gcc/
	* omp-low.c (struct omp_context): New fields
	local_reduction_clauses, outer_reduction_clauses.
	(new_omp_context): Initialize these.
	(scan_sharing_clauses): Record reduction clauses on OpenACC
	constructs.
	(scan_omp_for): Check reduction clauses for incorrect nesting.
	gcc/testsuite/
	* c-c++-common/goacc/nested-reductions-fail.c: New test.
	* c-c++-common/goacc/nested-reductions.c: New test.
	* c-c++-common/goacc/reduction-6.c: Adjust.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/par-loop-comb-reduction-1.c:
	Add missing reduction clauses.
	* testsuite/libgomp.oacc-c-c++-common/par-loop-comb-reduction-2.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/par-loop-comb-reduction-3.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/par-loop-comb-reduction-4.c:
	Likewise.
---
 gcc/ChangeLog.openacc |   9 +
 gcc/omp-low.c | 105 
 gcc/testsuite/ChangeLog.openacc   |   7 +
 .../goacc/nested-reductions-fail.c| 492 ++
 .../c-c++-common/goacc/nested-reductions.c| 420 +++
 .../c-c++-common/goacc/reduction-6.c  |  11 -
 libgomp/ChangeLog.openacc |  12 +
 .../par-loop-comb-reduction-1.c   |   2 +-
 .../par-loop-comb-reduction-2.c   |   2 +-
 .../par-loop-comb-reduction-3.c   |   2 +-
 .../par-loop-comb-reduction-4.c   |   2 +-
 11 files changed, 1049 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/goacc/nested-reductions-fail.c
 create mode 100644 gcc/testsuite/c-c++-common/goacc/nested-reductions.c

diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
index e57971ce4cf2..597362505bb3 100644
--- a/gcc/ChangeLog.openacc
+++ b/gcc/ChangeLog.openacc
@@ -1,3 +1,12 @@
+2018-12-20  Gergö Barany  
+
+	* omp-low.c (struct omp_context): New fields
+	local_reduction_clauses, outer_reduction_clauses.
+	(new_omp_context): Initialize these.
+	(scan_sharing_clauses): Record reduction clauses on OpenACC
+	constructs.
+	(scan_omp_for): Check reduction clauses for incorrect nesting.
+
 2018-12-20  Julian Brown  
 	Maciej W. Rozycki  
 
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 967916521001..6b7b23e6909b 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -129,6 +129,12 @@ struct omp_context
 
   /* Hash map of dynamic arrays in this context.  */
   hash_map *dynamic_arrays;
+
+  /* A tree_list of the reduction clauses in this context.  */
+  tree local_reduction_clauses;
+
+  /* A tree_list of the reduction clauses in outer contexts.  */
+  tree outer_reduction_clauses;
 };
 
 static splay_tree all_contexts;
@@ -1040,6 +1046,8 @@ new_omp_context (gimple *stmt, omp_context *outer_ctx)
   ctx->cb = outer_ctx->cb;
   ctx->cb.block = NULL;
   ctx->depth = outer_ctx->depth + 1;
+  ctx->local_reduction_clauses = NULL;
+  ctx->outer_reduction_clauses = ctx->outer_reduction_clauses;
 }
   else
 {
@@ -1053,6 +1061,8 @@ new_omp_context (gimple *stmt, omp_context *outer_ctx)
   ctx->cb.eh_lp_nr = 0;
   ctx->cb.transform_call_graph_edges = CB_CGE_MOVE;
   ctx->depth = 1;
+  ctx->local_reduction_clauses = NULL;
+  ctx->outer_reduction_clauses = NULL;
 }
 
   ctx->cb.decl_map = new hash_map;
@@ -1276,6 +1286,9 @@ scan_sharing_clauses (tree clauses, omp_context *ctx,
 	  goto do_private;
 
 	case OMP_CLAUSE_REDUCTION:
+  if (is_oacc_parallel (ctx) || is_oacc_kernels (ctx))
+ctx->local_reduction_clauses
+	  = tree_cons (NULL, c, ctx->local_reduction_clauses);
 	  decl = OMP_CLAUSE_DECL (c);
 	  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_REDUCTION
 	  && TREE_CODE (decl) == MEM_REF)
@@ -2458,6 +2471,98 @@ scan_omp_for (gomp_for *stmt, omp_context *outer_ctx)
 	  gimple_omp_for_set_clauses (stmt, clauses);
 	  check_oacc_kernel_gwv (stmt, ctx);
 	}
+
+  /* Collect all variables named in reductions on this loop.  Ensure
+ that, if this loop has a reduction on some variable v, and there is
+ a reduction on v somewhere in an outer context, then there is a
+ reduction on v on all intervening loops as well.  */
+  tree local_reduction_clauses = NULL;
+  for (tree c = gimple_omp_for_clauses (stmt); c; c = OMP_CLAUSE_CHAIN (c))
+{
+  if (OMP_CLAUSE_CODE (c) 

Re: [PATCH, og8] Add OpenACC 2.6 `serial' construct support

[Maciej W. Rozycki]

Hi Chung-Lin,

> My only issue is should "serial" really be promoted to such a visible
> construct
> in the middle-end? It's just a special case of parallel, and user debug errors
> can be dealt with specifically. I don't see much value of it being preserved
> past the front-ends into gimplify/omp-low, just more testing to be done to
> guard
> various conditions that are specific to OpenACC...

 Thank you for your review.  I think your input is valuable and it may be 
worth it to revise the implementation at the time of merging it to trunk.  
However I think that perfect is the enemy of good, so for the time being I 
have committed this change.

  Maciej

Re: [PATCH, og8] Add OpenACC 2.6 `no_create' clause support

[Maciej W. Rozycki]

On Wed, 19 Dec 2018, Maciej W. Rozycki wrote:

>  This has passed regression-testing with the `x86_64-linux-gnu' target and
> the `nvptx-none' offload target, across the `gcc', `g++', `gfortran' and
> `libgomp' test suites.  I will appreciate feedback and if none has been
> given shortly, then I will commit this change to the og8 branch.

 I have committed this change now.

  Maciej

Re: [PR 87615] Limit AA walking in hopefully all of IPA summary generation

[Martin Jambor]

Hi,

Ping:

On Fri, Dec 07 2018, Martin Jambor wrote:
Hi,

the patch below adds alias analysis (AA) walk limiting to all
walk_alias_vdefs calls invoked as IPA-CP and ipa-fnsummary summary
generation.  Eventually the two should be unified into just one phase
but that is something for stage1.  This patch gives them both
independent budgets, both initialized to
PARAM_VALUE(PARAM_IPA_MAX_AA_STEPS) - as a consequence, the real limit
is twice the given value.

I'm not sure whether the ipa-prop AA limiting was written before
walk_alias_vdefs had its limit parameter added, but I changed the code
to use it and also modified the budget counter to go from the parameter
value down to zero as opposed to incrementing it and checking manually
before each call into AA.  I always pass the current budget + 1 to
walk_alias_vdefs limit so that I do not have to check whether it is zero
which means no limiting at all, and also so that loads from a parameter
right at the top of a function get detected as unmodified even if some
previous analysis already used up all the budget.

As far as the testcase for PR 87615 is concerned, this patch makes the
compile time go down from approx. 340 seconds to about 160 seconds on my
desktop and IPA-CP gets zeros in -ftime-reportbut we still do not reach
the 40 second compile time we get with -fno-ipa-cp -fno-inline.

Bootstrapped and tested on x86_64-linux.  OK for trunk?

Thanks,

Martin


2018-12-06  Martin Jambor  

PR ipa/87615
* ipa-prop.h (struct ipa_func_body_info): Replaced field aa_walked
with aa_walk_budget.
* cgraph.h (ipa_polymorphic_call_context::get_dynamic_type): Add
aa_walk_budget_p parameter.
* ipa-fnsummary.c (unmodified_parm_1): New parameter fbi.  Limit AA
walk.  Updated all callers.
(unmodified_parm): New parameter fbi, pass it to unmodified_parm_1.
(eliminated_by_inlining_prob): New parameter fbi, pass it on to
unmodified_parm.
(will_be_nonconstant_expr_predicate): New parameter fbi, removed
parameter info.  Extract info from fbi.  Pass fbi to recursive calls
and to unmodified_parm.
(phi_result_unknown_predicate): New parameter fbi, removed parameter
info, updated call to will_be_nonconstant_expr_predicate.
(param_change_prob): New parameter fbi, limit AA walking.
(analyze_function_body): Initialize aa_walk_budget in fbi.  Update
calls to various above functions.
* ipa-polymorphic-call.c (get_dynamic_type): Add aa_walk_budget_p
parameter.  Use it to limit AA walking.
* ipa-prop.c (detect_type_change_from_memory_writes): New parameter
fbi, limit AA walk.
(detect_type_change): New parameter fbi, pass it on to
detect_type_change_from_memory_writes.
(detect_type_change_ssa): Likewise.
(aa_overwalked): Removed.
(parm_preserved_before_stmt_p): Assume fbi is never NULL, stream line
accordingly, adjust to the neew AA limiting scheme.
(parm_ref_data_preserved_p): Likewise.
(ipa_compute_jump_functions_for_edge): Adjust call to
get_dynamic_type.
(ipa_analyze_call_uses): Likewise.
(ipa_analyze_virtual_call_uses): Pass fbi to detect_type_change_ssa.
(ipa_analyze_node): Initialize aa_walk_budget.
(ipcp_transform_function): Likewise.
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Update call
to get_dynamic_type.
---
 gcc/cgraph.h   |   2 +-
 gcc/ipa-fnsummary.c| 111 +++-
 gcc/ipa-polymorphic-call.c |  28 ++--
 gcc/ipa-prop.c | 128 +
 gcc/ipa-prop.h |   5 +-
 gcc/tree-ssa-sccvn.c   |   2 +-
 6 files changed, 154 insertions(+), 122 deletions(-)

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index b8e23cc338a..028899e44b1 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -1548,7 +1548,7 @@ public:
 
   /* Look for vtable stores or constructor calls to work out dynamic type
  of memory location.  */
-  bool get_dynamic_type (tree, tree, tree, gimple *);
+  bool get_dynamic_type (tree, tree, tree, gimple *, unsigned *);
 
   /* Make context non-speculative.  */
   void clear_speculation ();
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index 23b7821dcc1..f4cc4df5cda 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -941,7 +941,8 @@ mark_modified (ao_ref *ao ATTRIBUTE_UNUSED, tree vdef 
ATTRIBUTE_UNUSED,
PARM_DECL) will be stored to *SIZE_P in that case too.  */
 
 static tree
-unmodified_parm_1 (gimple *stmt, tree op, HOST_WIDE_INT *size_p)
+unmodified_parm_1 (ipa_func_body_info *fbi, gimple *stmt, tree op,
+  HOST_WIDE_INT *size_p)
 {
   /* SSA_NAME referring to parm default def?  */
   if (TREE_CODE (op) == SSA_NAME
@@ -959,8 +960,14 @@ unmodified_parm_1 (gimple *stmt, tree op, HOST_WIDE_INT 
*size_p)
 
   ao_ref refd;
   ao_re

Re: [PR 87615] Limit AA walking in hopefully all of IPA summary generation

[Jan Hubicka]

Dne 2018-12-20 15:36, Martin Jambor napsal:

Hi,

Ping:

On Fri, Dec 07 2018, Martin Jambor wrote:
Hi,

the patch below adds alias analysis (AA) walk limiting to all
walk_alias_vdefs calls invoked as IPA-CP and ipa-fnsummary summary
generation.  Eventually the two should be unified into just one phase
but that is something for stage1.  This patch gives them both
independent budgets, both initialized to
PARAM_VALUE(PARAM_IPA_MAX_AA_STEPS) - as a consequence, the real limit
is twice the given value.

I'm not sure whether the ipa-prop AA limiting was written before
walk_alias_vdefs had its limit parameter added, but I changed the code
to use it and also modified the budget counter to go from the parameter
value down to zero as opposed to incrementing it and checking manually
before each call into AA.  I always pass the current budget + 1 to
walk_alias_vdefs limit so that I do not have to check whether it is 
zero

which means no limiting at all, and also so that loads from a parameter
right at the top of a function get detected as unmodified even if some
previous analysis already used up all the budget.

As far as the testcase for PR 87615 is concerned, this patch makes the
compile time go down from approx. 340 seconds to about 160 seconds on 
my

desktop and IPA-CP gets zeros in -ftime-reportbut we still do not reach
the 40 second compile time we get with -fno-ipa-cp -fno-inline.

Bootstrapped and tested on x86_64-linux.  OK for trunk?

Thanks,

Martin


2018-12-06  Martin Jambor  

PR ipa/87615
* ipa-prop.h (struct ipa_func_body_info): Replaced field aa_walked
with aa_walk_budget.
* cgraph.h (ipa_polymorphic_call_context::get_dynamic_type): Add
aa_walk_budget_p parameter.
* ipa-fnsummary.c (unmodified_parm_1): New parameter fbi.  Limit AA
walk.  Updated all callers.
(unmodified_parm): New parameter fbi, pass it to unmodified_parm_1.
(eliminated_by_inlining_prob): New parameter fbi, pass it on to
unmodified_parm.
(will_be_nonconstant_expr_predicate): New parameter fbi, removed
parameter info.  Extract info from fbi.  Pass fbi to recursive calls
and to unmodified_parm.
(phi_result_unknown_predicate): New parameter fbi, removed parameter
info, updated call to will_be_nonconstant_expr_predicate.
(param_change_prob): New parameter fbi, limit AA walking.
(analyze_function_body): Initialize aa_walk_budget in fbi.  Update
calls to various above functions.
* ipa-polymorphic-call.c (get_dynamic_type): Add aa_walk_budget_p
parameter.  Use it to limit AA walking.
* ipa-prop.c (detect_type_change_from_memory_writes): New parameter
fbi, limit AA walk.
(detect_type_change): New parameter fbi, pass it on to
detect_type_change_from_memory_writes.
(detect_type_change_ssa): Likewise.
(aa_overwalked): Removed.
(parm_preserved_before_stmt_p): Assume fbi is never NULL, stream line
accordingly, adjust to the neew AA limiting scheme.
(parm_ref_data_preserved_p): Likewise.
(ipa_compute_jump_functions_for_edge): Adjust call to
get_dynamic_type.
(ipa_analyze_call_uses): Likewise.
(ipa_analyze_virtual_call_uses): Pass fbi to detect_type_change_ssa.
(ipa_analyze_node): Initialize aa_walk_budget.
(ipcp_transform_function): Likewise.
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Update call
to get_dynamic_type.


OK


--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -941,7 +941,8 @@ mark_modified (ao_ref *ao ATTRIBUTE_UNUSED, tree
vdef ATTRIBUTE_UNUSED,
PARM_DECL) will be stored to *SIZE_P in that case too.  */


I guess to make coding standards happy, you should document new 
parametrs.

Honza

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

[Christophe Lyon]

On Thu, 20 Dec 2018 at 01:04, Alexandre Oliva  wrote:
>
> Christophe,
>
> Thanks again for the report.  This was quite an adventure to figure
> out ;-)  See below.
>

Glad I've helped. I wouldn't have been able to do the analysis :)


>
> [PR88146] avoid diagnostics diffs if cdtor_returns_this
>
> Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
> platforms.  Specifically, on ARM, the diagnostics within the subtest
> derived_ctor::inherited_derived_ctor::constexpr_noninherited_ctor did
> not match those displayed on other platforms, and the test failed.
>
> The difference seemed to have to do with locations assigned to ctors,
> but it was more subtle: on ARM, the instantiation of bor's template
> ctor was nested within the instantiation of bar's template ctor
> inherited from bor.  The reason turned out to be related with the
> internal return type of ctors: arm_cxx_cdtor_returns_this is enabled
> for because of AAPCS, while cxx.cdtor_returns_this is disabled on most
> other platforms.  While convert_to_void returns early with a VOID
> expr, the non-VOID return type of the base ctor CALL_EXPR causes
> convert_to_void to inspect the called decl for nodiscard attributes:
> maybe_warn_nodiscard -> cp_get_fndecl_from_callee ->
> maybe_constant_init -> cxx_eval_outermost_constant_expr ->
> instantiate_constexpr_fns -> nested instantiation.
>
> The internal return type assigned to a cdtor should not affect
> instantiation (constexpr or template) decisions, IMHO.  We know it
> affects diagnostics, but I have a hunch this might bring deeper issues
> with it, so I've arranged for the CALL_EXPR handler in convert_to_void
> to disregard cdtors, regardless of the ABI.
>
>
> The patch is awkward on purpose: it's meant to illustrate both
> portions of the affected code, to draw attention to a potential
> problem, and to get bootstrap-testing coverage for the path that will
> be taken on ARM.  I envision removing the first hunk, and the else
> from the second hunk, once testing is done.
>
> The first hunk is there to highlight where convert_to_void returns
> early on x86, instead of handling the CALL_EXPR.
>
> BTW (here's the potential problem), shouldn't we go into the CALL_EXPR
> case for the volatile void mentioned in comments next to the case, or
> won't that match VOID_TYPE_P?
>
> Finally, I shall mention the possibility of taking the opposite
> direction, and actually looking for nodiscard in cdtor calls so as to
> trigger the constexpr side effects that we've inadvertently triggered
> and observed with the inh-ctor32.C testcase.  It doesn't feel right to
> me, but I've been wrong many times before ;-)
>
> Would a rearranged version of the patch, dropping the redundant tests
> and retaining only the addition of the test for cdtor identifiers, be
> ok to install, provided that it passes regression testing?
>
>
> Note this patch does NOT carry a ChangeLog entry.  That's also on
> purpose, to indicate it's not meant to be included as is.
> ---
>  gcc/cp/cvt.c |   21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
> index eb1687377c3e..1a15af8a6e99 100644
> --- a/gcc/cp/cvt.c
> +++ b/gcc/cp/cvt.c
> @@ -1112,7 +1112,8 @@ convert_to_void (tree expr, impl_conv_void implicit, 
> tsubst_flags_t complain)
>  error_at (loc, "pseudo-destructor is not called");
>return error_mark_node;
>  }
> -  if (VOID_TYPE_P (TREE_TYPE (expr)))
> +  if (VOID_TYPE_P (TREE_TYPE (expr))
> +  && TREE_CODE (expr) != CALL_EXPR)
>  return expr;
>switch (TREE_CODE (expr))
>  {
> @@ -1169,6 +1170,24 @@ convert_to_void (tree expr, impl_conv_void implicit, 
> tsubst_flags_t complain)
>break;
>
>  case CALL_EXPR:   /* We have a special meaning for volatile void fn().  
> */
> +  /* cdtors may return this or void, depending on
> +targetm.cxx.cdtor_returns_this, but this shouldn't affect our
> +decisions here: nodiscard cdtors are nonsensical, and we
> +don't want to call maybe_warn_nodiscard because it may
> +trigger constexpr or template instantiation in a way that
> +changes their instantiaton nesting.  This changes the way
> +contexts are printed in diagnostics, with bad consequences
> +for the testsuite, but there may be other undesirable
> +consequences of visiting referenced ctors too soon.  */
> +  if (DECL_P (TREE_OPERAND (expr, 0))
> + && IDENTIFIER_CDTOR_P (DECL_NAME (TREE_OPERAND (expr, 0
> +   return expr;
> +  /* FIXME: Move this test before the one above, after a round of
> +testing as it is, to get coverage of the behavior we'd get on
> +ARM.  */
> +  else if (VOID_TYPE_P (TREE_TYPE (expr)))
> +   return expr;
> +
>maybe_warn_nodiscard (expr, implicit);
>break;
>
>
>
> --
> Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
> Be the change, be Free! FSF Lati

Re: [C++ PATCH] Constexpr fold even some TREE_CONSTANT ctors (PR c++/87934)

[Jason Merrill]

On 12/19/18 6:14 PM, Jakub Jelinek wrote:

On Tue, Dec 18, 2018 at 10:27:56PM -0500, Jason Merrill wrote:

On 12/18/18 6:19 PM, Jakub Jelinek wrote:

On Tue, Dec 18, 2018 at 05:40:03PM -0500, Jason Merrill wrote:

On 12/18/18 3:45 PM, Jakub Jelinek wrote:

The following testcase FAILs, because parsing creates a TREE_CONSTANT
CONSTRUCTOR that contains CONST_DECL elts.  cp_fold_r can handle that,
but constexpr evaluation doesn't touch those CONSTRUCTORs.

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


OK.  I also wonder if store_init_value should use cp_fold_r rather than just
cp_fully_fold.


I've been thinking about that already when working on the PR88410 bug.

Do you mean something like following completely untested patch?
Perhaps I could add a helper inline so that there is no code repetition
between cp_fully_fold and this new function.


Something like that, yes.


The following does the job too (even the PR88410 ICE is gone with the
cp-gimplify.c change from that patch reverted) and is shorter.

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


OK, thanks.

Jason

Re: [C++ PATCH] Fix up cp_parser_class_specifier_1 error recovery (PR c++/88180, take 2)

[Jason Merrill]

On 12/19/18 6:12 PM, Jakub Jelinek wrote:

Hi!

On Tue, Dec 18, 2018 at 05:29:41PM -0500, Jason Merrill wrote:

So, we end up calling ggc_collect because we're processing a member function
in a context where defining a type is not allowed.  One solution would be to
not do late parsing of members in such a context.

We don't have this problem with lambdas because cp_parser_lambda_body
already increments function_depth to avoid GC in the middle of an
expression.


So like this?  We already have similar treatment for error-recovery
if template arguments are erroneous.

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


OK.

Jason

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

[Jason Merrill]

On 12/19/18 7:04 PM, Alexandre Oliva wrote:

Christophe,

Thanks again for the report.  This was quite an adventure to figure
out ;-)  See below.


[PR88146] avoid diagnostics diffs if cdtor_returns_this

Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
platforms.  Specifically, on ARM, the diagnostics within the subtest
derived_ctor::inherited_derived_ctor::constexpr_noninherited_ctor did
not match those displayed on other platforms, and the test failed.

The difference seemed to have to do with locations assigned to ctors,
but it was more subtle: on ARM, the instantiation of bor's template
ctor was nested within the instantiation of bar's template ctor
inherited from bor.  The reason turned out to be related with the
internal return type of ctors: arm_cxx_cdtor_returns_this is enabled
for because of AAPCS, while cxx.cdtor_returns_this is disabled on most
other platforms.  While convert_to_void returns early with a VOID
expr, the non-VOID return type of the base ctor CALL_EXPR causes
convert_to_void to inspect the called decl for nodiscard attributes:
maybe_warn_nodiscard -> cp_get_fndecl_from_callee ->
maybe_constant_init -> cxx_eval_outermost_constant_expr ->
instantiate_constexpr_fns -> nested instantiation.


I think the bug is in calling instantiate_constexpr_fns in this case.  I 
think that should only happen when ctx->manifestly_const_eval.


Jason

Re: RFA: Avoid versioning loop with unaligned step

[Richard Biener]

On Thu, Dec 20, 2018 at 2:43 PM Joern Wolfgang Rennecke  wrote:
>
> eSi-RISC has vector permute functionality, but no unaligned loads. We
> see execution failures on gcc.dg/vect/slp-perm-12.c because loop
> versioning is used to make the tptr aligned for the first loop
> iteration, and then with a step of originally 11, 22 after
> vectorization, and a vector alignment of 8 bytes, the second iteration
> causes an AlignmentError exception.
> The attached patch to tree-vect-data-refs.c suppresses attempts to align
> data accesses where the
> step alignment times the vectorization factor is insufficient to sustain
> the alignment during the loop.
> Bootstrapped and regression tested on x86_64-pc-linux-gnu .
>
> I have also attached a matching testsuite patch to not expect SLP
> vectorization for slp-perm-12 when
> no unaligned loads are available, although in terms of testing, I can
> only say that it works for us.

vect_compute_data_ref_alignment uses DR_TARGET_ALIGNMENT
and DR_STEP_ALIGNMENT () % dr_target-alignment == 0 as check.

I think it's preferable to use the same or similar values for the desired
alignment.

Otherwise this looks OK to me.

Richard.

[AArch64][SVE] Fix IFN_COND_FMLA movprfx alternative

[Richard Sandiford]

This patch fixes a cut-&-pasto in the (match_dup 4) version of
"cond_".  (It's a shame
that there's so much cut-&-paste in these patterns, but it's hard
to avoid without more infrastructure.)

Applied after testing on aarch64-linux-gnu and aarch64_be-elf.

Richard


2018-12-20  Richard Sandiford  

gcc/
* config/aarch64/aarch64-sve.md (*cond__4): Use
sve_fmla_op rather than sve_fmad_op for the movprfx alternative.

gcc/testsuite/
* gcc.target/aarch64/sve/fmla_2.c: New test.
* gcc.target/aarch64/sve/fmla_2_run.c: Likewise

Index: gcc/config/aarch64/aarch64-sve.md
===
--- gcc/config/aarch64/aarch64-sve.md   2018-12-07 15:03:10.893433419 +
+++ gcc/config/aarch64/aarch64-sve.md   2018-12-20 16:31:20.946744405 +
@@ -3021,7 +3021,7 @@ (define_insn "*cond__4"
   "TARGET_SVE"
   "@
\t%0., %1/m, %2., %3.
-   movprfx\t%0, %4\;\t%0., %1/m, %2., %3."
+   movprfx\t%0, %4\;\t%0., %1/m, %2., %3."
   [(set_attr "movprfx" "*,yes")]
 )
 
Index: gcc/testsuite/gcc.target/aarch64/sve/fmla_2.c
===
--- /dev/null   2018-11-29 13:15:04.463550658 +
+++ gcc/testsuite/gcc.target/aarch64/sve/fmla_2.c   2018-12-20 
16:31:20.946744405 +
@@ -0,0 +1,19 @@
+/* { dg-options "-O3" } */
+
+#include 
+
+#define N 55
+
+void __attribute__ ((noipa))
+f (double *restrict a, double *restrict b, double *restrict c,
+   double *restrict d, double *restrict e, int64_t *restrict cond)
+{
+  for (int i = 0; i < N; ++i)
+{
+  a[i] = cond[i] ? __builtin_fma (c[i], d[i], e[i]) : e[i];
+  b[i] = cond[i] ? __builtin_fma (c[i], e[i], d[i]) : d[i];
+}
+}
+
+/* { dg-final { scan-assembler-times {\tfmla\tz[0-9]+\.d, p[0-7]/m, 
z[0-9]+\.d, z[0-9]+\.d\n} 2 } } */
+/* { dg-final { scan-assembler-not {\tfmad\t} } } */
Index: gcc/testsuite/gcc.target/aarch64/sve/fmla_2_run.c
===
--- /dev/null   2018-11-29 13:15:04.463550658 +
+++ gcc/testsuite/gcc.target/aarch64/sve/fmla_2_run.c   2018-12-20 
16:31:20.946744405 +
@@ -0,0 +1,28 @@
+/* { dg-do run { target aarch64_sve_hw } } */
+/* { dg-options "-O3" } */
+
+#include "fmla_2.c"
+
+int __attribute__ ((optimize (1)))
+main (void)
+{
+  double a[N], b[N], c[N], d[N], e[N];
+  int64_t cond[N];
+
+  for (int i = 0; i < N; ++i)
+{
+  c[i] = i + i % 5;
+  d[i] = i + i % 7;
+  e[i] = i + i % 9;
+  cond[i] = i % 3;
+}
+
+  f (a, b, c, d, e, cond);
+
+  for (int i = 0; i < N; ++i)
+if (a[i] != (cond[i] ? __builtin_fma (c[i], d[i], e[i]) : e[i])
+   || b[i] != (cond[i] ? __builtin_fma (c[i], e[i], d[i]) : d[i]))
+  __builtin_abort ();
+
+  return 0;
+}

[AArch64][SVE] Add ABS support

[Richard Sandiford]

For some reason we missed ABS out of the list of supported integer
operations when adding the SVE port initially.

Applied after testing on aarch64-linux-gnu and aarch64_be-elf.

Richard


2018-12-20  Richard Sandiford  

gcc/
* config/aarch64/iterators.md (SVE_INT_UNARY, fp_int_op): Add abs.
(SVE_FP_UNARY): Sort.

gcc/testsuite/
* gcc.target/aarch64/pr64946.c: Force nosve.
* gcc.target/aarch64/ssadv16qi.c: Likewise.
* gcc.target/aarch64/usadv16qi.c: Likewise.
* gcc.target/aarch64/vect-abs-compile.c: Likewise.
* gcc.target/aarch64/sve/abs_1.c: New test.

Index: gcc/config/aarch64/iterators.md
===
--- gcc/config/aarch64/iterators.md 2018-12-11 15:49:18.249550929 +
+++ gcc/config/aarch64/iterators.md 2018-12-20 16:33:03.401872968 +
@@ -1209,10 +1209,10 @@ (define_code_iterator UCOMPARISONS [ltu
 (define_code_iterator FAC_COMPARISONS [lt le ge gt])
 
 ;; SVE integer unary operations.
-(define_code_iterator SVE_INT_UNARY [neg not popcount])
+(define_code_iterator SVE_INT_UNARY [abs neg not popcount])
 
 ;; SVE floating-point unary operations.
-(define_code_iterator SVE_FP_UNARY [neg abs sqrt])
+(define_code_iterator SVE_FP_UNARY [abs neg sqrt])
 
 ;; SVE integer binary operations.
 (define_code_iterator SVE_INT_BINARY [plus minus mult smax umax smin umin
@@ -1401,6 +1401,7 @@ (define_code_attr sve_int_op [(plus "add
  (mult "mul")
  (div "sdiv")
  (udiv "udiv")
+ (abs "abs")
  (neg "neg")
  (smin "smin")
  (smax "smax")
Index: gcc/testsuite/gcc.target/aarch64/pr64946.c
===
--- gcc/testsuite/gcc.target/aarch64/pr64946.c  2018-06-18 15:22:36.634299637 
+0100
+++ gcc/testsuite/gcc.target/aarch64/pr64946.c  2018-12-20 16:33:03.401872968 
+
@@ -1,7 +1,8 @@
-
 /* { dg-do compile } */
 /* { dg-options "-O3" } */
 
+#pragma GCC target "+nosve"
+
 signed char a[100],b[100];
 void absolute_s8 (void)
 {
Index: gcc/testsuite/gcc.target/aarch64/ssadv16qi.c
===
--- gcc/testsuite/gcc.target/aarch64/ssadv16qi.c2018-06-14 
12:27:25.264162082 +0100
+++ gcc/testsuite/gcc.target/aarch64/ssadv16qi.c2018-12-20 
16:33:03.401872968 +
@@ -1,6 +1,8 @@
 /* { dg-do compile } */
 /* { dg-options "-O3" } */
 
+#pragma GCC target "+nosve"
+
 #define N 1024
 
 signed char pix1[N], pix2[N];
Index: gcc/testsuite/gcc.target/aarch64/usadv16qi.c
===
--- gcc/testsuite/gcc.target/aarch64/usadv16qi.c2018-06-14 
12:27:25.236162328 +0100
+++ gcc/testsuite/gcc.target/aarch64/usadv16qi.c2018-12-20 
16:33:03.401872968 +
@@ -1,6 +1,8 @@
 /* { dg-do compile } */
 /* { dg-options "-O3" } */
 
+#pragma GCC target "+nosve"
+
 #define N 1024
 
 unsigned char pix1[N], pix2[N];
Index: gcc/testsuite/gcc.target/aarch64/vect-abs-compile.c
===
--- gcc/testsuite/gcc.target/aarch64/vect-abs-compile.c 2018-06-18 
15:22:36.638299602 +0100
+++ gcc/testsuite/gcc.target/aarch64/vect-abs-compile.c 2018-12-20 
16:33:03.401872968 +
@@ -1,7 +1,8 @@
-
 /* { dg-do compile } */
 /* { dg-options "-O3 -fno-vect-cost-model" } */
 
+#pragma GCC target "+nosve"
+
 #define N 16
 
 #include "vect-abs.x"
Index: gcc/testsuite/gcc.target/aarch64/sve/abs_1.c
===
--- /dev/null   2018-11-29 13:15:04.463550658 +
+++ gcc/testsuite/gcc.target/aarch64/sve/abs_1.c2018-12-20 
16:33:03.401872968 +
@@ -0,0 +1,21 @@
+/* { dg-do assemble { target aarch64_asm_sve_ok } } */
+/* { dg-options "-O3 --save-temps" } */
+
+#include 
+
+#define DO_OPS(TYPE)   \
+void vneg_##TYPE (TYPE *dst, TYPE *src, int count) \
+{  \
+  for (int i = 0; i < count; ++i)  \
+dst[i] = src[i] < 0 ? -src[i] : src[i];\
+}
+
+DO_OPS (int8_t)
+DO_OPS (int16_t)
+DO_OPS (int32_t)
+DO_OPS (int64_t)
+
+/* { dg-final { scan-assembler-times {\tabs\tz[0-9]+\.b, p[0-7]/m, 
z[0-9]+\.b\n} 1 } } */
+/* { dg-final { scan-assembler-times {\tabs\tz[0-9]+\.h, p[0-7]/m, 
z[0-9]+\.h\n} 1 } } */
+/* { dg-final { scan-assembler-times {\tabs\tz[0-9]+\.s, p[0-7]/m, 
z[0-9]+\.s\n} 1 } } */
+/* { dg-final { scan-assembler-times {\tabs\tz[0-9]+\.d, p[0-7]/m, 
z[0-9]+\.d\n} 1 } } */

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

[Sam Tebbs]

On 11/22/18 4:54 PM, Sam Tebbs wrote:
> On 11/12/18 6:24 PM, Sudakshina Das wrote:
>> Hi Sam
>>
>> On 02/11/18 17:31, Sam Tebbs wrote:
>>> Hi all,
>>>
>>> The -mbranch-protection option combines the functionality of
>>> -msign-return-address and the BTI features new in Armv8.5 to better reflect
>>> their relationship. This new option therefore supersedes and deprecates the
>>> existing -msign-return-address option.
>>>
>>> -mbranch-protection=[none|standard|] - Turns on different types of 
>>> branch
>>> protection available where:
>>>
>>> * "none": Turn of all types of branch protection
>>> * "standard" : Turns on all the types of protection to their 
>>> respective
>>>   standard levels.
>>> *  can be "+" separated protection types:
>>>
>>> * "bti" : Branch Target Identification Mechanism.
>>> * "pac-ret{+leaf+b-key}": Return Address Signing. The default return
>>>   address signing is enabled by signing functions that save the return
>>>   address to memory (non-leaf functions will practically always do this)
>>>   using the a-key. The optional tuning arguments allow the user to
>>>   extend the scope of return address signing to include leaf functions
>>>   and to change the key to b-key. The tuning arguments must proceed the
>>>   protection type "pac-ret".
>>>
>>> Thus -mbranch-protection=standard -> -mbranch-protection=bti+pac-ret.
>>>
>>> Its mapping to -msign-return-address is as follows:
>>>
>>> * -mbranch-protection=none -> -msign-return-address=none
>>> * -mbranch-protection=standard -> -msign-return-address=leaf
>>> * -mbranch-protection=pac-ret -> -msign-return-address=non-leaf
>>> * -mbranch-protection=pac-ret+leaf -> -msign-return-address=all
>>>
>>> This patch implements the option's skeleton and the "none", "standard" and
>>> "pac-ret" types (along with its "leaf" subtype).
>>>
>>> The previous patch in this series is here:
>>> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00103.html
>>>
>>> Bootstrapped successfully and tested on aarch64-none-elf with no 
>>> regressions.
>>>
>>> OK for trunk?
>>>
>> Thank for doing this. I am not a maintainer so you will need a
>> maintainer's approval. Only nit, that I would add is that it would
>> be good to have more test coverage, specially for the new parsing
>> functions that have been added and the errors that are added.
>>
>> Example checking a few valid and invalid combinations of the options
>> like:
>> -mbranch-protection=pac-ret -mbranch-protection=none //disables
>> everything
>> -mbranch-protection=leaf  //errors out
>> -mbranch-protection=none+pac-ret //errors out
>> ... etc
>> Also instead of removing all the old deprecated options, you can keep
>> one (or a copy of one) to check for the deprecated warning.
> Hi Sudi,
>
> Thanks for the feedback, I've incorporated your suggestions into the
> attached patch and the updated changelog.
>
> gcc/ChangeLog:
>
> 2018-11-22  Sam Tebbs
>
>   * config/aarch64/aarch64.c (BRANCH_PROTEC_STR_MAX,
>   aarch64_parse_branch_protection,
>   struct aarch64_branch_protec_type,
>   aarch64_handle_no_branch_protection,
>   aarch64_handle_standard_branch_protection,
>   aarch64_validate_mbranch_protection,
>   aarch64_handle_pac_ret_protection,
>   aarch64_handle_attr_branch_protection,
>   accepted_branch_protection_string,
>   aarch64_pac_ret_subtypes,
>   aarch64_branch_protec_types,
>   aarch64_handle_pac_ret_leaf): Define.
>   (aarch64_override_options_after_change_1): Add check for
>   accepted_branch_protection_string.
>   (aarch64_override_options): Add check for
>   accepted_branch_protection_string.
>   (aarch64_option_save): Save accepted_branch_protection_string.
>   (aarch64_option_restore): Save
>   accepted_branch_protection_string.
>   * config/aarch64/aarch64.c (aarch64_attributes): Add branch-protection.
>   * config/aarch64/aarch64.opt: Add mbranch-protection. Deprecate
>   msign-return-address.
>   * doc/invoke.texi: Add mbranch-protection.
>
> gcc/testsuite/ChangeLog:
>
> 2018-11-22  Sam Tebbs
>
>   * (gcc.target/aarch64/return_address_sign_1.c,
>   gcc.target/aarch64/return_address_sign_2.c,
>   gcc.target/aarch64/return_address_sign_3.c (__attribute__)): Change
>   option to -mbranch-protection.
>   * gcc.target/aarch64/(branch-protection-option.c,
>   branch-protection-option-2.c, branch-protection-attr.c,
>   branch-protection-attr-2.c): New file.

Hi all,

Attached is an updated patch with branch_protec_type renamed to 
branch_protect_type, some unneeded ATTRIBUTE_USED removed and an added 
use of ARRAY_SIZE.

Below is the updated changelog.

OK for trunk? I have committed the preceding patch in the series.

gcc/ChangeLog:

2018-12-20  Sam Tebbs

* config/aarch64/aarch64.c (BRANCH_PROTECT_STR_MAX,
aarch64_parse_branch_protection,
struct aarc

Re: [PATCH, GCC, AARCH64, 5/6] Enable BTI : Add new pass for BTI.

[Sudakshina Das]

Hi James

On 19/12/18 3:40 PM, James Greenhalgh wrote:
> On Fri, Dec 14, 2018 at 10:09:03AM -0600, Sudakshina Das wrote:
> 
> 
> 
>> I have updated the patch according to our discussions offline.
>> The md pattern is now split into 4 patterns and i have added a new
>> test for the setjmp case along with some comments where missing.
> 
> This is OK for trunk.
> 

Thanks for the approvals. With this my series is ready to go in trunk. I 
will wait for Sam's options patch to go in trunk before I commit mine.

Thanks
Sudi

> Thanks,
> James
> 
>> *** gcc/ChangeLog ***
>>
>> 2018-xx-xx  Sudakshina Das  
>>  Ramana Radhakrishnan  
>>
>>  * config.gcc (aarch64*-*-*): Add aarch64-bti-insert.o.
>>  * gcc/config/aarch64/aarch64.h: Update comment for
>>  TRAMPOLINE_SIZE.
>>  * config/aarch64/aarch64.c (aarch64_asm_trampoline_template):
>>  Update if bti is enabled.
>>  * config/aarch64/aarch64-bti-insert.c: New file.
>>  * config/aarch64/aarch64-passes.def (INSERT_PASS_BEFORE): Insert
>>  bti pass.
>>  * config/aarch64/aarch64-protos.h (make_pass_insert_bti):
>>  Declare the new bti pass.
>>  * config/aarch64/aarch64.md (unspecv): Add UNSPECV_BTI_NOARG,
>>  UNSPECV_BTI_C, UNSPECV_BTI_J and UNSPECV_BTI_JC.
>>  (bti_noarg, bti_j, bti_c, bti_jc): New define_insns.
>>  * config/aarch64/t-aarch64: Add rule for aarch64-bti-insert.o.
>>
>> *** gcc/testsuite/ChangeLog ***
>>
>> 2018-xx-xx  Sudakshina Das  
>>
>>  * gcc.target/aarch64/bti-1.c: New test.
>>  * gcc.target/aarch64/bti-2.c: New test.
>>  * gcc.target/aarch64/bti-3.c: New test.
>>  * lib/target-supports.exp
>>  (check_effective_target_aarch64_bti_hw): Add new check for
>>  BTI hw.
>>
>> Thanks
>> Sudi

[PATCH] fix compile error with clang

[Dave Murphy]

Cross compiling for macOS using osxcross gives errors of the form
"error: default initialization of an object of ... without a
user-provided default constructor"

Fixed by attached patch, tested compile with mingw-w64, osxcross and
linux native builds.

2018-12-20  Dave Murphy  

* gdb/dtrace-probe.c (dtrace_static_probe_ops): explicit zero initialise.
* gdb/probe.c (any_static_probe_ops): ditto
* gdb/record-btrace.c (record_btrace_thread_observer_token): ditto
* gdb/stap-probe.c (stap_static_probe_ops): ditto
* gdb/tui/tui-hooks.c (tui_observers_token): ditto
* gdb/unittests/observable-selftests.c (token1, token2, token3): ditto


clang-fixes.patch
Description: Binary data

[committed] new test for PR84053

[Martin Sebor]

PR84053 - [7/8/9 Regression] missing -Warray-bounds accessing
a local array across inlined function boundaries, started to
pass with r262893 (a fix for a couple of different -Warray-bounds
bugs) but a test case for it was never added.  After putting one
together I noticed that although it passes in LP64 it still fails
in ILP32.

I added the test in r267302 to prevent regressions in LP64 and
xfailed it for ILP32.  I also reopened the bug to make sure it
doesn't get forgotten.

Martin

Re: [PATCH] Shuffle ieee_arithmetic.F90

[Steve Kargl]

On Thu, Dec 20, 2018 at 02:29:40PM +0100, Thomas Koenig wrote:
> 
> > The attach patch shuffles lines around to eliminate 80
> > lines of #ifdef...#endif; thereby making the file more
> > readable.  Tested on i586-*-freebsd and x86_64-*-freebsd.
> > Patch is a pre-requisite to fixing issues and adding
> > missing functionality.  OK to commit?
> > 
> > 2018-12-18  Steven G. Kargl  
> > 
> > * libgfortran/ieee/ieee_arithmetic.F90: Re-organize file to
> > eliminate excessive #ifdef ... #endif.
> > 
> 
> OK. Thanks for the patch!
> 

Thanks.  I'll commit shortly.

-- 
Steve

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

[Martin Sebor]

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

On 12/15/18 3:36 AM, Bernd Edlinger wrote:
this patch implements an error message, for non-static initialization 
of a flexible array member.
This duplicates the existing error message from the C-FE, to avoid ICE 
and wrong code generation

issues, as pointed out in the PR.

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


Martin, thoughts?


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

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

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

Martin

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

[Martin Sebor]

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

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

On 12/15/18 3:36 AM, Bernd Edlinger wrote:
this patch implements an error message, for non-static initialization 
of a flexible array member.
This duplicates the existing error message from the C-FE, to avoid 
ICE and wrong code generation

issues, as pointed out in the PR.

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


Martin, thoughts?


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


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

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



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

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

Martin

patch to fix PR88457

[Vladimir Makarov]

  The following patch fixes

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

  The patch was successfully bootstrapped and tested on x86-64 and ppc64.

  Committed as rev. 267307


Index: ChangeLog
===
--- ChangeLog	(revision 267306)
+++ ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2018-12-20  Vladimir Makarov  
+
+	PR target/88457
+	* ira-color.c (fast_allocation): Choose the best cost hard reg.
+
 2018-12-20  Richard Sandiford  
 
 	* config/aarch64/iterators.md (SVE_INT_UNARY, fp_int_op): Add abs.
Index: ira-color.c
===
--- ira-color.c	(revision 267245)
+++ ira-color.c	(working copy)
@@ -4852,7 +4852,8 @@ color (void)
 static void
 fast_allocation (void)
 {
-  int i, j, k, num, class_size, hard_regno;
+  int i, j, k, num, class_size, hard_regno, best_hard_regno, cost, min_cost;
+  int *costs;
 #ifdef STACK_REGS
   bool no_stack_reg_p;
 #endif
@@ -4903,6 +4904,9 @@ fast_allocation (void)
   no_stack_reg_p = ALLOCNO_NO_STACK_REG_P (a);
 #endif
   class_size = ira_class_hard_regs_num[aclass];
+  costs = ALLOCNO_HARD_REG_COSTS (a);
+  min_cost = INT_MAX;
+  best_hard_regno = -1;
   for (j = 0; j < class_size; j++)
 	{
 	  hard_regno = ira_class_hard_regs[aclass][j];
@@ -4915,16 +4919,28 @@ fast_allocation (void)
 	  || (TEST_HARD_REG_BIT
 		  (ira_prohibited_class_mode_regs[aclass][mode], hard_regno)))
 	continue;
-	  ALLOCNO_HARD_REGNO (a) = hard_regno;
-	  for (l = 0; l < nr; l++)
+	  if (costs == NULL)
 	{
-	  ira_object_t obj = ALLOCNO_OBJECT (a, l);
-	  for (r = OBJECT_LIVE_RANGES (obj); r != NULL; r = r->next)
-		for (k = r->start; k <= r->finish; k++)
-		  IOR_HARD_REG_SET (used_hard_regs[k],
-ira_reg_mode_hard_regset[hard_regno][mode]);
+	  best_hard_regno = hard_regno;
+	  break;
 	}
-	  break;
+	  cost = costs[j];
+	  if (min_cost > cost)
+	{
+	  min_cost = cost;
+	  best_hard_regno = hard_regno;
+	}
+	}
+  if (best_hard_regno < 0)
+	continue;
+  ALLOCNO_HARD_REGNO (a) = hard_regno = best_hard_regno;
+  for (l = 0; l < nr; l++)
+	{
+	  ira_object_t obj = ALLOCNO_OBJECT (a, l);
+	  for (r = OBJECT_LIVE_RANGES (obj); r != NULL; r = r->next)
+	for (k = r->start; k <= r->finish; k++)
+	  IOR_HARD_REG_SET (used_hard_regs[k],
+ira_reg_mode_hard_regset[hard_regno][mode]);
 	}
 }
   ira_free (sorted_allocnos);
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 267306)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2018-12-20  Vladimir Makarov  
+
+	PR target/88457
+	* gcc.target/powerpc/pr88457.c: New.
+
 2018-12-20  Jakub Jelinek  
 
 	PR c++/88180
Index: testsuite/gcc.target/powerpc/pr88457.c
===
--- testsuite/gcc.target/powerpc/pr88457.c	(revision 0)
+++ testsuite/gcc.target/powerpc/pr88457.c	(working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile  { target { powerpc64*-*-* } } } */
+/* { dg-options "-m32 -mcpu=power7 -O1 -fexpensive-optimizations --param ira-max-conflict-table-size=0 --param max-cse-insns=3 -c -mcpu=e300c3" } */
+
+__attribute__((target_clones("cpu=power9,default")))
+long mod_func (long a, long b)
+{
+  return a % b;
+}
+
+long mod_func_or (long a, long b, long c)
+{
+  return mod_func (a, b) | c;
+}

[PATCH] Fix filesystem::path tests that fail on Windows

[Jonathan Wakely]

* testsuite/27_io/filesystem/operations/proximate.cc: Fix test for
MinGW.
* testsuite/27_io/filesystem/path/append/source.cc: Likewise.
* testsuite/27_io/filesystem/path/compare/lwg2936.cc: Likewise.

Tested x86_64-linux and mingw-w64, committed to trunk.


commit 2ca9c650bb91616a8c24ece0df1fdd812d785a21
Author: Jonathan Wakely 
Date:   Thu Dec 20 17:57:31 2018 +

Fix filesystem::path tests that fail on Windows

* testsuite/27_io/filesystem/operations/proximate.cc: Fix test for
MinGW.
* testsuite/27_io/filesystem/path/append/source.cc: Likewise.
* testsuite/27_io/filesystem/path/compare/lwg2936.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/proximate.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/proximate.cc
index 457cd2d0641..980161c9ead 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/proximate.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/proximate.cc
@@ -26,15 +26,27 @@
 using std::filesystem::proximate;
 using __gnu_test::compare_paths;
 
+// Normalize directory-separators
+std::string operator""_norm(const char* s, std::size_t n)
+{
+  std::string str(s, n);
+#if defined(__MING32__) || defined(__MINGW64__)
+  for (auto& c : str)
+if (c == '/')
+  c = '\\';
+#endif
+  return str;
+}
+
 void
 test01()
 {
-  compare_paths( proximate("/a/d", "/a/b/c"), "../../d" );
-  compare_paths( proximate("/a/b/c", "/a/d"), "../b/c" );
-  compare_paths( proximate("a/b/c", "a"), "b/c" );
-  compare_paths( proximate("a/b/c", "a/b/c/x/y"), "../.." );
+  compare_paths( proximate("/a/d", "/a/b/c"), "../../d"_norm );
+  compare_paths( proximate("/a/b/c", "/a/d"), "../b/c"_norm );
+  compare_paths( proximate("a/b/c", "a"), "b/c"_norm );
+  compare_paths( proximate("a/b/c", "a/b/c/x/y"), "../.."_norm );
   compare_paths( proximate("a/b/c", "a/b/c"), "." );
-  compare_paths( proximate("a/b", "c/d"), "../../a/b" );
+  compare_paths( proximate("a/b", "c/d"), "../../a/b"_norm );
 }
 
 void
@@ -42,22 +54,22 @@ test02()
 {
   const std::error_code bad_ec = make_error_code(std::errc::invalid_argument);
   std::error_code ec = bad_ec;
-  compare_paths( proximate("/a/d", "/a/b/c", ec), "../../d" );
+  compare_paths( proximate("/a/d", "/a/b/c", ec), "../../d"_norm );
   VERIFY( !ec );
   ec = bad_ec;
-  compare_paths( proximate("/a/b/c", "/a/d", ec), "../b/c" );
+  compare_paths( proximate("/a/b/c", "/a/d", ec), "../b/c"_norm );
   VERIFY( !ec );
   ec = bad_ec;
-  compare_paths( proximate("a/b/c", "a", ec), "b/c" );
+  compare_paths( proximate("a/b/c", "a", ec), "b/c"_norm );
   VERIFY( !ec );
   ec = bad_ec;
-  compare_paths( proximate("a/b/c", "a/b/c/x/y", ec), "../.." );
+  compare_paths( proximate("a/b/c", "a/b/c/x/y", ec), "../.."_norm );
   VERIFY( !ec );
   ec = bad_ec;
   compare_paths( proximate("a/b/c", "a/b/c", ec), "." );
   VERIFY( !ec );
   ec = bad_ec;
-  compare_paths( proximate("a/b", "c/d", ec), "../../a/b" );
+  compare_paths( proximate("a/b", "c/d", ec), "../../a/b"_norm );
   VERIFY( !ec );
 }
 
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/append/source.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/append/source.cc
index 21ae6be3d97..578d1350178 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/append/source.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/append/source.cc
@@ -120,24 +120,31 @@ test05()
   path p = "0/1/2/3/4/5/6";
   // The string_view aliases the path's internal string:
   s = p.native();
+  path::string_type expected(s);
+  expected += path::preferred_separator;
+  expected += s;
   // Append that string_view, which must work correctly even though the
   // internal string will be reallocated during the operation:
   p /= s;
-  VERIFY( p.string() == "0/1/2/3/4/5/6/0/1/2/3/4/5/6" );
+  compare_paths(p, expected);
 
   // Same again with a trailing slash:
   path p2 = "0/1/2/3/4/5/";
   s = p2.native();
+  expected = s;
+  expected += s;
   p2 /= s;
-  VERIFY( p2.string() == "0/1/2/3/4/5/0/1/2/3/4/5/" );
+  compare_paths(p2, expected);
 
   // And aliasing one of the components of the path:
   path p3 = "0/123456789/a";
   path::iterator second = std::next(p3.begin());
   s = second->native();
+  expected = p3.native() + path::preferred_separator;
+  expected += s;
   p3 /= s;
-  VERIFY( p3.string() == "0/123456789/a/123456789" );
-  }
+  compare_paths(p3, expected);
+}
 
 void
 test06()
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc
index 8a11043f143..a62f01c3fb6 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc
@@ -60,7 +60,11 @@ test01()
   check("c:", "d:", -1);
   check("c:", "c:/", -1);
   check("d:", "c:/", +1);
+#if defined(__MING32__) || defined(__MINGW64__)
+  check("c:/a/b", "c:a/b", +1);
+#els

Re: V9 [PATCH] C/C++: Add -Waddress-of-packed-member

[Jason Merrill]

On 12/19/18 12:35 PM, H.J. Lu wrote:

+  while (handled_component_p (rhs))
+{
+  if (TREE_CODE (rhs) == COMPONENT_REF)
+   break;
+  rhs = TREE_OPERAND (rhs, 0);
+}
+
+  if (TREE_CODE (rhs) != COMPONENT_REF)
+return NULL_TREE;
+
+  object = TREE_OPERAND (rhs, 0);
+  field = TREE_OPERAND (rhs, 1);
+
+  tree context = check_alignment_of_packed_member (type, field);
+  if (context)
+return context;


All the above looks unnecessary; it will be handled by the loop below.


+  /* Check alignment of the object.  */
+  while (handled_component_p (object))
+{
+  if (TREE_CODE (object) == COMPONENT_REF)
+   {
+ do
+   {
+ field = TREE_OPERAND (object, 1);
+ context = check_alignment_of_packed_member (type, field);
+ if (context)
+   return context;
+ object = TREE_OPERAND (object, 0);
+   }
+ while (TREE_CODE (object) == COMPONENT_REF);


This inner loop also seems unnecessary.


+   }
+  else
+   object = TREE_OPERAND (object, 0);
+}


Jason

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

[Eric Botcazou]

> Does this solve most of the pessimizations?

Yes, it does.

> Please add a testcase if it doesn't solve existing FAILs.

It fixes gcc.target/sparc/overflow-2.c.

-- 
Eric Botcazou

Re: [PATCH] Shuffle ieee_arithmetic.F90

[Steve Kargl]

On Thu, Dec 20, 2018 at 02:29:40PM +0100, Thomas Koenig wrote:
> Hi Steve,
> 
> > The attach patch shuffles lines around to eliminate 80
> > lines of #ifdef...#endif; thereby making the file more
> > readable.  Tested on i586-*-freebsd and x86_64-*-freebsd.
> > Patch is a pre-requisite to fixing issues and adding
> > missing functionality.  OK to commit?
> > 
> > 2018-12-18  Steven G. Kargl  
> > 
> > * libgfortran/ieee/ieee_arithmetic.F90: Re-organize file to
> > eliminate excessive #ifdef ... #endif.
> > 
> 
> OK. Thanks for the patch!
> 

Committed revision 267312.

-- 
Steve

Re: RFA: Avoid versioning loop with unaligned step

[Richard Sandiford]

Richard Biener  writes:
> On Thu, Dec 20, 2018 at 2:43 PM Joern Wolfgang Rennecke  
> wrote:
>>
>> eSi-RISC has vector permute functionality, but no unaligned loads. We
>> see execution failures on gcc.dg/vect/slp-perm-12.c because loop
>> versioning is used to make the tptr aligned for the first loop
>> iteration, and then with a step of originally 11, 22 after
>> vectorization, and a vector alignment of 8 bytes, the second iteration
>> causes an AlignmentError exception.
>> The attached patch to tree-vect-data-refs.c suppresses attempts to align
>> data accesses where the
>> step alignment times the vectorization factor is insufficient to sustain
>> the alignment during the loop.
>> Bootstrapped and regression tested on x86_64-pc-linux-gnu .
>>
>> I have also attached a matching testsuite patch to not expect SLP
>> vectorization for slp-perm-12 when
>> no unaligned loads are available, although in terms of testing, I can
>> only say that it works for us.
>
> vect_compute_data_ref_alignment uses DR_TARGET_ALIGNMENT
> and DR_STEP_ALIGNMENT () % dr_target-alignment == 0 as check.
>
> I think it's preferable to use the same or similar values for the desired
> alignment.

Yeah, I agree testing for a multiple is better than maybe_lt,
and that we should be using DR_TARGET_ALIGNMENT rather than
TYPE_ALIGN_UNIT.

(TYPE_ALIGN_UNIT is the ABI alignment, which might be higher or lower
than the alignment the vectoriser is aiming for.  And I think the
reasons for bailing out apply whenever the vectoriser can't reach
the alignment it's aiming for, even if the alignment isn't needed
for correctness.)

Thanks,
Richard

Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446)

[Jason Merrill]

On 12/12/18 5:30 PM, Jakub Jelinek wrote:

Hi!

The following patch fixes __builtin_is_constant_evaluated and
__builtin_constant_p handling during static_assert evaluation.
finish_static_assert calls fold_non_dependent_expr and complains if the
result is not a constant expression, instead of requiring a constant
expression, which causes __builtin_is_constant_evaluated () during the
evaluation to be not considered as constant expression and
__builtin_constant_p calls too if they appear in constexpr functions.

The patch makes sure that manifestly_const_eval is true while evaluating
the expression and also makes sure to fold __builtin_constant_p when that is
true even when in constexpr functions.

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

2018-12-12  Jakub Jelinek  

PR c++/86524
PR c++/88446
* cp-tree.h (fold_non_dependent_expr): Add manifestly_const_eval
argument.
* constexpr.c (cxx_eval_builtin_function_call): Evaluate
__builtin_constant_p if ctx->manifestly_const_eval even in constexpr
functions.  For arguments to builtins, if ctx->manifestly_const_eval
try to first evaluate arguments with it, but if that doesn't result
in a constant expression, retry without it.  Fix comment typo.
(fold_non_dependent_expr): Add manifestly_const_eval argument, pass
it through to cxx_eval_outermost_constant_expr and
maybe_constant_value.
* semantics.c (finish_static_assert): Call fold_non_dependent_expr
with true as manifestly_const_eval.

* g++.dg/cpp1y/constexpr-86524.C: New test.
* g++.dg/cpp2a/is-constant-evaluated4.C: New test.
* g++.dg/cpp2a/is-constant-evaluated5.C: New test.
* g++.dg/cpp2a/is-constant-evaluated6.C: New test.

--- gcc/cp/cp-tree.h.jj 2018-12-12 09:32:27.408535853 +0100
+++ gcc/cp/cp-tree.h2018-12-12 11:07:24.250459779 +0100
@@ -7665,7 +7665,9 @@ extern tree cxx_constant_value(tree,
  extern tree cxx_constant_init (tree, tree = NULL_TREE);
  extern tree maybe_constant_value  (tree, tree = NULL_TREE, bool = 
false);
  extern tree maybe_constant_init   (tree, tree = 
NULL_TREE, bool = false);
-extern tree fold_non_dependent_expr(tree, tsubst_flags_t = 
tf_warning_or_error);
+extern tree fold_non_dependent_expr(tree,
+tsubst_flags_t = 
tf_warning_or_error,
+bool = false);
  extern tree fold_simple   (tree);
  extern bool is_sub_constant_expr(tree);
  extern bool reduced_constant_expression_p   (tree);
--- gcc/cp/constexpr.c.jj   2018-12-12 09:34:17.531736075 +0100
+++ gcc/cp/constexpr.c  2018-12-12 11:30:33.986756914 +0100
@@ -1198,6 +1198,7 @@ cxx_eval_builtin_function_call (const co
   in a constexpr function until we have values for the parameters.  */
if (bi_const_p
&& ctx->quiet
+  && !ctx->manifestly_const_eval


I think we want to replace the "quiet" check with manifestly_const_eval, 
rather than adding to it.



@@ -1222,7 +1223,6 @@ cxx_eval_builtin_function_call (const co
   return constant false for a non-constant argument.  */
constexpr_ctx new_ctx = *ctx;
new_ctx.quiet = true;
-  bool dummy1 = false, dummy2 = false;
for (i = 0; i < nargs; ++i)
  {
args[i] = CALL_EXPR_ARG (t, i);
@@ -1231,10 +1231,23 @@ cxx_eval_builtin_function_call (const co
 of the builtin, verify it here.  */
if (!builtin_valid_in_constant_expr_p (fun)
  || potential_constant_expression (args[i]))
-   args[i] = cxx_eval_constant_expression (&new_ctx, args[i], false,
-   &dummy1, &dummy2);
+   {
+ bool non_cst_p = false, ovf_p = false;
+ tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
+&non_cst_p, &ovf_p);
+ if ((non_cst_p || ovf_p) && ctx->manifestly_const_eval)
+   {
+ new_ctx.manifestly_const_eval = false;
+ non_cst_p = false;
+ ovf_p = false;
+ a = cxx_eval_constant_expression (&new_ctx, args[i], false,
+   &non_cst_p, &ovf_p);
+ new_ctx.manifestly_const_eval = true;
+   }


Why retry without manifestly_const_eval?  For static initialization we 
don't want to try constant evaluation again with 
__builtin_is_constant_evaluated false if it failed with it true.


Jason

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

[Segher Boessenkool]

On Thu, Dec 20, 2018 at 01:23:57PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 20, 2018 at 01:15:53PM +0100, Richard Biener wrote:
> > On Thu, Dec 20, 2018 at 12:43 PM Eric Botcazou  
> > wrote:
> > > this is a regression introduced on the SPARC by the somewhat controversial
> > > combiner change for hard registers: the compiler can no longer apply the 
> > > leaf
> > > registers optimization to a small function so a register window is now 
> > > used.
> > >
> > > The combiner change might be an overall win, but my understanding is that 
> > > it's
> > > dependent on the target and SPARC seems to be in the wrong basket: almost 
> > > all
> > > changes to the gcc.c-torture/compile testsuite at -O2 are pessimizations 
> > > in
> > > the form of additional move instructions between registers on function 
> > > entry.
> > >
> > > Clearly that's counter-productive for a LEAF_REGISTERS target like SPARC 
> > > so
> > > the proposed fix is to re-enable hard register combining for leaf 
> > > registers.
> > >
> > > Tested on SPARC/Solaris 11, OK for the mainline?
> > 
> > This only affects xtensa besides sparc so unless Segher objects this is OK.
> > 
> > Does this solve most of the pessimizations?
> > 
> > Please add a testcase if it doesn't solve existing FAILs.
> 
> Generally it would be better to deal with that in RA, but if Vlad doesn't
> have cycles for it right now, your hack isn't that bad.

It's not a terrible workaround, no.  It looks like it will make some asm
once again fail though?  If argument registers are forwarded to in the asm.


Segher

V10 [PATCH] C/C++: Add -Waddress-of-packed-member

[H.J. Lu]

On Thu, Dec 20, 2018 at 11:28 AM Jason Merrill  wrote:
>
> On 12/19/18 12:35 PM, H.J. Lu wrote:
> > +  while (handled_component_p (rhs))
> > +{
> > +  if (TREE_CODE (rhs) == COMPONENT_REF)
> > + break;
> > +  rhs = TREE_OPERAND (rhs, 0);
> > +}
> > +
> > +  if (TREE_CODE (rhs) != COMPONENT_REF)
> > +return NULL_TREE;
> > +
> > +  object = TREE_OPERAND (rhs, 0);
> > +  field = TREE_OPERAND (rhs, 1);
> > +
> > +  tree context = check_alignment_of_packed_member (type, field);
> > +  if (context)
> > +return context;
>
> All the above looks unnecessary; it will be handled by the loop below.
>
> > +  /* Check alignment of the object.  */
> > +  while (handled_component_p (object))
> > +{
> > +  if (TREE_CODE (object) == COMPONENT_REF)
> > + {
> > +   do
> > + {
> > +   field = TREE_OPERAND (object, 1);
> > +   context = check_alignment_of_packed_member (type, field);
> > +   if (context)
> > + return context;
> > +   object = TREE_OPERAND (object, 0);
> > + }
> > +   while (TREE_CODE (object) == COMPONENT_REF);
>
> This inner loop also seems unnecessary.
>
> > + }
> > +  else
> > + object = TREE_OPERAND (object, 0);
> > +}
>
> Jason

I changed it to

static tree
check_address_of_packed_member (tree type, tree rhs)
{
  if (INDIRECT_REF_P (rhs))
rhs = TREE_OPERAND (rhs, 0);

  if (TREE_CODE (rhs) == ADDR_EXPR)
rhs = TREE_OPERAND (rhs, 0);

  tree context = NULL_TREE;

  /* Check alignment of the object.  */
  while (handled_component_p (rhs))
{
  if (TREE_CODE (rhs) == COMPONENT_REF)
{
  tree field = TREE_OPERAND (rhs, 1);
  context = check_alignment_of_packed_member (type, field);
  if (context)
break;
}
  rhs = TREE_OPERAND (rhs, 0);
}

  return context;
}

Here is the updated patch.  OK for trunk?

Thanks.

-- 
H.J.
From f2982a694a2fab4dd1ce2a6819006b451fa0c9a7 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Fri, 12 Jan 2018 21:12:05 -0800
Subject: [PATCH] C/C++: Add -Waddress-of-packed-member
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When address of packed member of struct or union is taken, it may result
in an unaligned pointer value.  This patch adds -Waddress-of-packed-member
to check alignment at pointer assignment and warn unaligned address as
well as unaligned pointer:

$ cat x.i
struct pair_t
{
  char c;
  int i;
} __attribute__ ((packed));

extern struct pair_t p;
int *addr = &p.i;
$ gcc -O2 -S x.i
x.i:8:13: warning: taking address of packed member of ‘struct pair_t’ may result in an unaligned pointer value [-Waddress-of-packed-member]
8 | int *addr = &p.i;
  | ^

$ cat c.i
struct B { int i; };
struct C { struct B b; } __attribute__ ((packed));

long* g8 (struct C *p) { return p; }
$ gcc -O2 -S c.i -Wno-incompatible-pointer-types
c.i: In function ‘g8’:
c.i:4:18: warning: converting a packed ‘struct C *’ pointer (alignment 1) to ‘long int *’ (alignment 8) may may result in an unaligned pointer value [-Waddress-of-packed-member]
4 | long* g8 (struct C *p) { return p; }
  |  ^
c.i:2:8: note: defined here
2 | struct C { struct B b; } __attribute__ ((packed));
  |^
$

This warning is enabled by default.  Since read_encoded_value_with_base
in unwind-pe.h has

  union unaligned
{
  void *ptr;
  unsigned u2 __attribute__ ((mode (HI)));
  unsigned u4 __attribute__ ((mode (SI)));
  unsigned u8 __attribute__ ((mode (DI)));
  signed s2 __attribute__ ((mode (HI)));
  signed s4 __attribute__ ((mode (SI)));
  signed s8 __attribute__ ((mode (DI)));
} __attribute__((__packed__));
  _Unwind_Internal_Ptr result;

and GCC warns:

gcc/libgcc/unwind-pe.h:210:37: warning: taking address of packed member of 'union unaligned' may result in an unaligned pointer value [-Waddress-of-packed-member]
result = (_Unwind_Internal_Ptr) u->ptr;
^
we need to add GCC pragma to ignore -Waddress-of-packed-member.

gcc/c/

	PR c/51628
	* doc/invoke.texi: Document -Wno-address-of-packed-member.

gcc/c-family/

	PR c/51628
	* c-common.h (warn_for_address_or_pointer_of_packed_member): New.
	* c-warn.c (check_alignment_of_packed_member): New function.
	(check_address_of_packed_member): Likewise.
	(check_and_warn_address_of_packed_member): Likewise.
	(warn_for_address_or_pointer_of_packed_member): Likewise.
	* c.opt: Add -Wno-address-of-packed-member.

gcc/c/

	PR c/51628
	* c-typeck.c (convert_for_assignment): Call
	warn_for_address_or_pointer_of_packed_member.

gcc/cp/

	PR c/51628
	* call.c (convert_for_arg_passing): Call
	warn_for_address_or_pointer_of_packed_member.
	* typeck.c (convert_for_assignment): Likewise.

gcc/testsuite/

	PR c/51628
	* c-c++-common/pr51628-1.c: New test.
	* c-c++-common/pr51628-2.c: Likewise.
	* c-c++-common/pr51628-3.c: Likewise.
	* c-c++-common/pr51628-4.c: Li

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

[Eric Botcazou]

> It's not a terrible workaround, no.  It looks like it will make some asm
> once again fail though?  If argument registers are forwarded to in the asm.

The combiner change looks like a big hammer for such a corner case though.

-- 
Eric Botcazou

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

[Segher Boessenkool]

On Thu, Dec 20, 2018 at 09:07:41PM +0100, Eric Botcazou wrote:
> > It's not a terrible workaround, no.  It looks like it will make some asm
> > once again fail though?  If argument registers are forwarded to in the asm.
> 
> The combiner change looks like a big hammer for such a corner case though.

That isn't the primary goal, no; the primary goal is to get better RA (by
not having the combiner do RA's work, and doing a mediocre job of it).  It
does solve these problems though.


Segher

Re: [PATCH] Fix unwind info in x86 interrupt functions (PR debug/83728)

[Andreas Krebbel]

On 1/19/18 12:28 AM, Jakub Jelinek wrote:
+#ifndef DEFAULT_INCOMING_FRAME_SP_OFFSET
+#define DEFAULT_INCOMING_FRAME_SP_OFFSET INCOMING_FRAME_SP_OFFSET
+#endif
...
+  /* If the current function starts with a non-standard incoming frame
+ sp offset, emit a note before the first instruction.  */
+  if (entry
+  && DEFAULT_INCOMING_FRAME_SP_OFFSET != INCOMING_FRAME_SP_OFFSET)
+{

This triggers a warning on s390x:

/home/andreas/build/../gcc/gcc/dwarf2cfi.c: In function ‘void 
scan_trace(dw_trace_info*, bool)’:
/home/andreas/build/../gcc/gcc/dwarf2cfi.c:2541:43: error: self-comparison 
always evaluates to false
[-Werror=tautol
ogical-compare]
 2541 |   && DEFAULT_INCOMING_FRAME_SP_OFFSET != INCOMING_FRAME_SP_OFFSET)
  |   ^~


Andreas

Re: [PATCH] Use proper print formatter in main function in fixincl.c

[Joseph Myers]

This is still changing the wrong format specifier (the one corresponding 
to apply_ct, which is an int).

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

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

[Bernd Edlinger]

On 12/20/18 6:50 PM, Martin Sebor wrote:
> On 12/20/18 10:46 AM, Martin Sebor wrote:
>> On 12/17/18 7:58 AM, Jason Merrill wrote:
>>> On 12/15/18 3:36 AM, Bernd Edlinger wrote:
 this patch implements an error message, for non-static initialization of a 
 flexible array member.
 This duplicates the existing error message from the C-FE, to avoid ICE and 
 wrong code generation
 issues, as pointed out in the PR.

 It is a bit funny that a non-functional feature like that has already 
 rather much test coverage.
 The most easy adjustment seems to change the existing test cases to use 
 static declarations.
>>>
>>> Martin, thoughts?
>>
>> Our high-level goal when tightening up how flexible array members
>> are handled in C++ was to accept what's accepted in standard C mode
>> and reject (or, at a minimum, warn for) C++ extensions that could
>> be relied on in existing code.
> 
> I meant "reject what couldn't be relied on" and "warn for that could
> be."
> 

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

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

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

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


> (Sorry for the delay, by the way.  I've been migrating to a new machine
> this week and things aren't yet working quite like I'm used to.)
> 
>>
>> The flexarray tests I added back then were for features that looked
>> like intentional extensions and that seemed to work for at least
>> some use cases as far as I could tell.  What I noticed didn't work
>> I created bugs for: 69338, 69696, and 69338 look related, but there
>> are others.
>>
>> I think all these bugs should all be reviewed and a decision made
>> about what's intended to work and what continues to be accepted as
>> an accident and should be rejected.  After that, we can adjust
>> the existing tests.
>>

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


Thanks
Bernd.

Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446)

[Jakub Jelinek]

On Thu, Dec 20, 2018 at 02:47:01PM -0500, Jason Merrill wrote:
> > --- gcc/cp/constexpr.c.jj   2018-12-12 09:34:17.531736075 +0100
> > +++ gcc/cp/constexpr.c  2018-12-12 11:30:33.986756914 +0100
> > @@ -1198,6 +1198,7 @@ cxx_eval_builtin_function_call (const co
> >in a constexpr function until we have values for the parameters.  */
> > if (bi_const_p
> > && ctx->quiet
> > +  && !ctx->manifestly_const_eval
> 
> I think we want to replace the "quiet" check with manifestly_const_eval,
> rather than adding to it.

Will change that.

> > -   args[i] = cxx_eval_constant_expression (&new_ctx, args[i], false,
> > -   &dummy1, &dummy2);
> > +   {
> > + bool non_cst_p = false, ovf_p = false;
> > + tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
> > +&non_cst_p, &ovf_p);
> > + if ((non_cst_p || ovf_p) && ctx->manifestly_const_eval)
> > +   {
> > + new_ctx.manifestly_const_eval = false;
> > + non_cst_p = false;
> > + ovf_p = false;
> > + a = cxx_eval_constant_expression (&new_ctx, args[i], false,
> > +   &non_cst_p, &ovf_p);
> > + new_ctx.manifestly_const_eval = true;
> > +   }
> 
> Why retry without manifestly_const_eval?  For static initialization we don't
> want to try constant evaluation again with __builtin_is_constant_evaluated
> false if it failed with it true.

The point is that we don't actually require arguments of the builtins to be
constant expressions.  So the above was an attempt - if the argument of a
builtin is a constant expression, then __builtin_is_constant_evaluated
will evaluate to true in there, if it is something different, we can still
try to fold it to something (like maybe_constant_value would be), in
a non-manifestly constant evaluated context; either the whole builtin will
not fold and we give up anyway, or it folds to some constant.
Essentially arguments to the builtin would be treated like separate
constexpr evaluations.

But if you think this is a bad idea, I can remove it, I haven't been
successful in constructing a testcase where this would matter.

Jakub

Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446)

[Jason Merrill]

On 12/20/18 4:08 PM, Jakub Jelinek wrote:

On Thu, Dec 20, 2018 at 02:47:01PM -0500, Jason Merrill wrote:

--- gcc/cp/constexpr.c.jj   2018-12-12 09:34:17.531736075 +0100
+++ gcc/cp/constexpr.c  2018-12-12 11:30:33.986756914 +0100
@@ -1198,6 +1198,7 @@ cxx_eval_builtin_function_call (const co
in a constexpr function until we have values for the parameters.  */
 if (bi_const_p
 && ctx->quiet
+  && !ctx->manifestly_const_eval


I think we want to replace the "quiet" check with manifestly_const_eval,
rather than adding to it.


Will change that.


-   args[i] = cxx_eval_constant_expression (&new_ctx, args[i], false,
-   &dummy1, &dummy2);
+   {
+ bool non_cst_p = false, ovf_p = false;
+ tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
+&non_cst_p, &ovf_p);
+ if ((non_cst_p || ovf_p) && ctx->manifestly_const_eval)
+   {
+ new_ctx.manifestly_const_eval = false;
+ non_cst_p = false;
+ ovf_p = false;
+ a = cxx_eval_constant_expression (&new_ctx, args[i], false,
+   &non_cst_p, &ovf_p);
+ new_ctx.manifestly_const_eval = true;
+   }


Why retry without manifestly_const_eval?  For static initialization we don't
want to try constant evaluation again with __builtin_is_constant_evaluated
false if it failed with it true.


The point is that we don't actually require arguments of the builtins to be
constant expressions.


Right, but they either are or they aren't.  Doing this isn't likely to 
help anything, and can lead to paradoxical results in contrived testcases.



But if you think this is a bad idea, I can remove it, I haven't been
successful in constructing a testcase where this would matter.


Please.  OK with those changes.

Jason

Re: V10 [PATCH] C/C++: Add -Waddress-of-packed-member

[Jason Merrill]

On 12/20/18 2:52 PM, H.J. Lu wrote:

On Thu, Dec 20, 2018 at 11:28 AM Jason Merrill  wrote:


On 12/19/18 12:35 PM, H.J. Lu wrote:

+  while (handled_component_p (rhs))
+{
+  if (TREE_CODE (rhs) == COMPONENT_REF)
+ break;
+  rhs = TREE_OPERAND (rhs, 0);
+}
+
+  if (TREE_CODE (rhs) != COMPONENT_REF)
+return NULL_TREE;
+
+  object = TREE_OPERAND (rhs, 0);
+  field = TREE_OPERAND (rhs, 1);
+
+  tree context = check_alignment_of_packed_member (type, field);
+  if (context)
+return context;


All the above looks unnecessary; it will be handled by the loop below.


+  /* Check alignment of the object.  */
+  while (handled_component_p (object))
+{
+  if (TREE_CODE (object) == COMPONENT_REF)
+ {
+   do
+ {
+   field = TREE_OPERAND (object, 1);
+   context = check_alignment_of_packed_member (type, field);
+   if (context)
+ return context;
+   object = TREE_OPERAND (object, 0);
+ }
+   while (TREE_CODE (object) == COMPONENT_REF);


This inner loop also seems unnecessary.


+ }
+  else
+ object = TREE_OPERAND (object, 0);
+}


Jason


I changed it to

static tree
check_address_of_packed_member (tree type, tree rhs)
{
   if (INDIRECT_REF_P (rhs))
 rhs = TREE_OPERAND (rhs, 0);

   if (TREE_CODE (rhs) == ADDR_EXPR)
 rhs = TREE_OPERAND (rhs, 0);

   tree context = NULL_TREE;

   /* Check alignment of the object.  */
   while (handled_component_p (rhs))
 {
   if (TREE_CODE (rhs) == COMPONENT_REF)
 {
   tree field = TREE_OPERAND (rhs, 1);
   context = check_alignment_of_packed_member (type, field);
   if (context)
 break;
 }
   rhs = TREE_OPERAND (rhs, 0);
 }

   return context;
}

Here is the updated patch.  OK for trunk?


OK.

Jason

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

[Peter Bergner]

On 12/20/18 2:26 PM, Segher Boessenkool wrote:
> On Thu, Dec 20, 2018 at 09:07:41PM +0100, Eric Botcazou wrote:
>>> It's not a terrible workaround, no.  It looks like it will make some asm
>>> once again fail though?  If argument registers are forwarded to in the asm.
>>
>> The combiner change looks like a big hammer for such a corner case though.
> 
> That isn't the primary goal, no; the primary goal is to get better RA (by
> not having the combiner do RA's work, and doing a mediocre job of it).  It
> does solve these problems though.

My recent RA patches improved conflict information by noticing when we
don't need a conflict for a copy insn between a hard reg and a pseudo
when the source operand is live past the copy.  However, conflict info
for copies between two pseudos wasn't affected because IRA/LRA computes
liveness differently for pseudos than for hard regs.  I have seen copies
between two pseudos still get to RA and we're not able to do anything
about them at the moment because we still think they conflict.

For stage1, I'd like to fix that conflict wart if I can.  I have also
wondered about adding a copy coalesce phase just before we enter RA,
which would ensure the copies are removed, instead of hoping RA assigns
the same reg to the source and destination of the copy making it a nop
that can be removed.

Peter

Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446)

[Jakub Jelinek]

On Thu, Dec 20, 2018 at 04:26:21PM -0500, Jason Merrill wrote:
> Right, but they either are or they aren't.  Doing this isn't likely to help
> anything, and can lead to paradoxical results in contrived testcases.
> 
> > But if you think this is a bad idea, I can remove it, I haven't been
> > successful in constructing a testcase where this would matter.
> 
> Please.  OK with those changes.

Actually, the main reason for any changes in that block was mainly that I 
thought
it is a bad idea to fold the argument with __builtin_is_const_evaluated ()
folded into true if that argument isn't a constant expression.

So are you ok with what is in the patch below, i.e.
   {
 bool non_cst_p = false, ovf_p = false;
 tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
&non_cst_p, &ovf_p);
 if ((!non_cst_p && !ovf_p) || !ctx->manifestly_const_eval)
   args[i] = a;
   }
, or perhaps without the || !ctx->manifestly_const_eval?  So, if the
argument is a constant expression, fold to that, if it is not, just do
cp_fully_fold on it if it is __builtin_constant_p, otherwise nothing?

2018-12-20  Jakub Jelinek  

PR c++/86524
PR c++/88446
* cp-tree.h (fold_non_dependent_expr): Add manifestly_const_eval
argument.
* constexpr.c (cxx_eval_builtin_function_call): Evaluate
__builtin_constant_p if ctx->manifestly_const_eval even in constexpr
functions.  For arguments to builtins, if ctx->manifestly_const_eval
and argument is not a constant expression, use original argument.
Fix comment typo.
(fold_non_dependent_expr): Add manifestly_const_eval argument, pass
it through to cxx_eval_outermost_constant_expr and
maybe_constant_value.
* semantics.c (finish_static_assert): Call fold_non_dependent_expr
with true as manifestly_const_eval.

* g++.dg/cpp1y/constexpr-86524.C: New test.
* g++.dg/cpp2a/is-constant-evaluated4.C: New test.
* g++.dg/cpp2a/is-constant-evaluated5.C: New test.
* g++.dg/cpp2a/is-constant-evaluated6.C: New test.

--- gcc/cp/cp-tree.h.jj 2018-12-20 18:29:24.069715207 +0100
+++ gcc/cp/cp-tree.h2018-12-20 22:10:46.686521475 +0100
@@ -7668,7 +7668,9 @@ extern tree cxx_constant_value(tree,
 extern tree cxx_constant_init  (tree, tree = NULL_TREE);
 extern tree maybe_constant_value   (tree, tree = NULL_TREE, bool = 
false);
 extern tree maybe_constant_init(tree, tree = 
NULL_TREE, bool = false);
-extern tree fold_non_dependent_expr(tree, tsubst_flags_t = 
tf_warning_or_error);
+extern tree fold_non_dependent_expr(tree,
+tsubst_flags_t = 
tf_warning_or_error,
+bool = false);
 extern tree fold_simple(tree);
 extern bool is_sub_constant_expr(tree);
 extern bool reduced_constant_expression_p   (tree);
--- gcc/cp/constexpr.c.jj   2018-12-20 08:50:29.695444227 +0100
+++ gcc/cp/constexpr.c  2018-12-20 22:12:43.754615737 +0100
@@ -1197,7 +1197,7 @@ cxx_eval_builtin_function_call (const co
   /* If we aren't requiring a constant expression, defer __builtin_constant_p
  in a constexpr function until we have values for the parameters.  */
   if (bi_const_p
-  && ctx->quiet
+  && !ctx->manifestly_const_eval
   && current_function_decl
   && DECL_DECLARED_CONSTEXPR_P (current_function_decl))
 {
@@ -1222,7 +1222,6 @@ cxx_eval_builtin_function_call (const co
  return constant false for a non-constant argument.  */
   constexpr_ctx new_ctx = *ctx;
   new_ctx.quiet = true;
-  bool dummy1 = false, dummy2 = false;
   for (i = 0; i < nargs; ++i)
 {
   args[i] = CALL_EXPR_ARG (t, i);
@@ -1231,10 +1230,16 @@ cxx_eval_builtin_function_call (const co
 of the builtin, verify it here.  */
   if (!builtin_valid_in_constant_expr_p (fun)
  || potential_constant_expression (args[i]))
-   args[i] = cxx_eval_constant_expression (&new_ctx, args[i], false,
-   &dummy1, &dummy2);
+   {
+ bool non_cst_p = false, ovf_p = false;
+ tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
+&non_cst_p, &ovf_p);
+ if ((!non_cst_p && !ovf_p) || !ctx->manifestly_const_eval)
+   args[i] = a;
+   }
+
   if (bi_const_p)
-   /* For __built_in_constant_p, fold all expressions with constant values
+   /* For __builtin_constant_p, fold all expressions with constant values
   even if they aren't C++ constant-expressions.  */
args[i] = cp_fully_fold (args[i]);
 }
@@ -5340,6 +5345,7 @@ clear_cv_and_fold_caches (void)
(t, complain) followed by maybe_constant_value

Re: V10 [PATCH] C/C++: Add -Waddress-of-packed-member

[H.J. Lu]

On Thu, Dec 20, 2018 at 1:28 PM Jason Merrill  wrote:
>
> On 12/20/18 2:52 PM, H.J. Lu wrote:
> > On Thu, Dec 20, 2018 at 11:28 AM Jason Merrill  wrote:
> >>
> >> On 12/19/18 12:35 PM, H.J. Lu wrote:
> >>> +  while (handled_component_p (rhs))
> >>> +{
> >>> +  if (TREE_CODE (rhs) == COMPONENT_REF)
> >>> + break;
> >>> +  rhs = TREE_OPERAND (rhs, 0);
> >>> +}
> >>> +
> >>> +  if (TREE_CODE (rhs) != COMPONENT_REF)
> >>> +return NULL_TREE;
> >>> +
> >>> +  object = TREE_OPERAND (rhs, 0);
> >>> +  field = TREE_OPERAND (rhs, 1);
> >>> +
> >>> +  tree context = check_alignment_of_packed_member (type, field);
> >>> +  if (context)
> >>> +return context;
> >>
> >> All the above looks unnecessary; it will be handled by the loop below.
> >>
> >>> +  /* Check alignment of the object.  */
> >>> +  while (handled_component_p (object))
> >>> +{
> >>> +  if (TREE_CODE (object) == COMPONENT_REF)
> >>> + {
> >>> +   do
> >>> + {
> >>> +   field = TREE_OPERAND (object, 1);
> >>> +   context = check_alignment_of_packed_member (type, field);
> >>> +   if (context)
> >>> + return context;
> >>> +   object = TREE_OPERAND (object, 0);
> >>> + }
> >>> +   while (TREE_CODE (object) == COMPONENT_REF);
> >>
> >> This inner loop also seems unnecessary.
> >>
> >>> + }
> >>> +  else
> >>> + object = TREE_OPERAND (object, 0);
> >>> +}
> >>
> >> Jason
> >
> > I changed it to
> >
> > static tree
> > check_address_of_packed_member (tree type, tree rhs)
> > {
> >if (INDIRECT_REF_P (rhs))
> >  rhs = TREE_OPERAND (rhs, 0);
> >
> >if (TREE_CODE (rhs) == ADDR_EXPR)
> >  rhs = TREE_OPERAND (rhs, 0);
> >
> >tree context = NULL_TREE;
> >
> >/* Check alignment of the object.  */
> >while (handled_component_p (rhs))
> >  {
> >if (TREE_CODE (rhs) == COMPONENT_REF)
> >  {
> >tree field = TREE_OPERAND (rhs, 1);
> >context = check_alignment_of_packed_member (type, field);
> >if (context)
> >  break;
> >  }
> >rhs = TREE_OPERAND (rhs, 0);
> >  }
> >
> >return context;
> > }
> >
> > Here is the updated patch.  OK for trunk?
>
> OK.
>

Checked in.  Thanks for everyone, especially Jason.

-- 
H.J.

Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446)

[Jason Merrill]

On 12/20/18 4:40 PM, Jakub Jelinek wrote:

On Thu, Dec 20, 2018 at 04:26:21PM -0500, Jason Merrill wrote:

Right, but they either are or they aren't.  Doing this isn't likely to help
anything, and can lead to paradoxical results in contrived testcases.


But if you think this is a bad idea, I can remove it, I haven't been
successful in constructing a testcase where this would matter.


Please.  OK with those changes.


Actually, the main reason for any changes in that block was mainly that I 
thought
it is a bad idea to fold the argument with __builtin_is_const_evaluated ()
folded into true if that argument isn't a constant expression.

So are you ok with what is in the patch below, i.e.
{
  bool non_cst_p = false, ovf_p = false;
  tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
 &non_cst_p, &ovf_p);
  if ((!non_cst_p && !ovf_p) || !ctx->manifestly_const_eval)
args[i] = a;
}
, or perhaps without the || !ctx->manifestly_const_eval?


I don't see how that makes a difference from what was there before; if 
the argument to cxx_eval_constant_expression is non-constant, it returns 
the argument unchanged.



So, if the
argument is a constant expression, fold to that, if it is not, just do
cp_fully_fold on it if it is __builtin_constant_p, otherwise nothing?


Hmm, cp_fully_fold probably also needs to add a manifestly_const_eval 
parameter to pass along to maybe_constant_value.


Jason

[PATCH] fortran/69121 -- Make IEEE_SCALB generic

[Steve Kargl]

The attached patch has been tested on x86_64-*-freebsd.

It provides the missing pieces for IEEE_SCALB to allow
it to be generic function.  Briefly, when FX contributed
IEEE_SCALB, he implemented a casting of the integer
argument to the default integer kind.  For integer(1)
and integer(2), this is a simple cast.  For integer(8)
and integer(16), he first checks to see if the value 
is in the range of default integer kind.  So, one
essentially has

ieee_scalb(x, 2_1) --> ieee_scalb(x, int(2_1, 4)) 
ieee_scalb(x, 2_8) --> ieee_scalb(x, int(max(min(2_8,huge(0)),-huge(0)), 4)

Unfortnately, the interface exposed by the IEEE_ARITHMETIC
module did not allow for non-default integer kind arguments.
The patch corrects that omission.

OK to commit?

2018-12-20  Steven G. Kargl  

PR fortran/69121
* libgfortran/ieee/ieee_arithmetic.F90: Provide missing functions
in interface for IEEE_SCALB.

2018-12-20  Steven G. Kargl  

PR fortran/69121
* gfortran.dg/ieee/ieee_9.f90: New test.
-- 
Steve
Index: libgfortran/ieee/ieee_arithmetic.F90
===
--- libgfortran/ieee/ieee_arithmetic.F90	(revision 267312)
+++ libgfortran/ieee/ieee_arithmetic.F90	(working copy)
@@ -532,37 +532,170 @@ REM_MACRO(4,4,4)
   ! IEEE_SCALB
 
   interface
-elemental real(kind=4) function _gfortran_ieee_scalb_4 (X, I)
+#ifdef HAVE_GFC_INTEGER_16
+#ifdef HAVE_GFC_REAL_16
+elemental real(kind=16) function _gfortran_ieee_scalb_16_16 (X, I)
+  real(kind=16), intent(in) :: X
+  integer(kind=16), intent(in) :: I
+end function
+#endif
+#ifdef HAVE_GFC_REAL_10
+elemental real(kind=10) function _gfortran_ieee_scalb_10_16 (X, I)
+  real(kind=10), intent(in) :: X
+  integer(kind=16), intent(in) :: I
+end function
+#endif
+elemental real(kind=8) function _gfortran_ieee_scalb_8_16 (X, I)
+  real(kind=8), intent(in) :: X
+  integer(kind=16), intent(in) :: I
+end function
+elemental real(kind=4) function _gfortran_ieee_scalb_4_16 (X, I)
   real(kind=4), intent(in) :: X
-  integer, intent(in) :: I
+  integer(kind=16), intent(in) :: I
 end function
-elemental real(kind=8) function _gfortran_ieee_scalb_8 (X, I)
+#endif
+
+#ifdef HAVE_GFC_INTEGER_8
+#ifdef HAVE_GFC_REAL_16
+elemental real(kind=16) function _gfortran_ieee_scalb_16_8 (X, I)
+  real(kind=16), intent(in) :: X
+  integer(kind=8), intent(in) :: I
+end function
+#endif
+#ifdef HAVE_GFC_REAL_10
+elemental real(kind=10) function _gfortran_ieee_scalb_10_8 (X, I)
+  real(kind=10), intent(in) :: X
+  integer(kind=8), intent(in) :: I
+end function
+#endif
+elemental real(kind=8) function _gfortran_ieee_scalb_8_8 (X, I)
   real(kind=8), intent(in) :: X
-  integer, intent(in) :: I
+  integer(kind=8), intent(in) :: I
 end function
+elemental real(kind=4) function _gfortran_ieee_scalb_4_8 (X, I)
+  real(kind=4), intent(in) :: X
+  integer(kind=8), intent(in) :: I
+end function
+#endif
+
+#ifdef HAVE_GFC_INTEGER_2
+#ifdef HAVE_GFC_REAL_16
+elemental real(kind=16) function _gfortran_ieee_scalb_16_2 (X, I)
+  real(kind=16), intent(in) :: X
+  integer(kind=2), intent(in) :: I
+end function
+#endif
 #ifdef HAVE_GFC_REAL_10
-elemental real(kind=10) function _gfortran_ieee_scalb_10 (X, I)
+elemental real(kind=10) function _gfortran_ieee_scalb_10_2 (X, I)
   real(kind=10), intent(in) :: X
-  integer, intent(in) :: I
+  integer(kind=2), intent(in) :: I
 end function
 #endif
+elemental real(kind=8) function _gfortran_ieee_scalb_8_2 (X, I)
+  real(kind=8), intent(in) :: X
+  integer(kind=2), intent(in) :: I
+end function
+elemental real(kind=4) function _gfortran_ieee_scalb_4_2 (X, I)
+  real(kind=4), intent(in) :: X
+  integer(kind=2), intent(in) :: I
+end function
+#endif
+
+#ifdef HAVE_GFC_INTEGER_1
 #ifdef HAVE_GFC_REAL_16
-elemental real(kind=16) function _gfortran_ieee_scalb_16 (X, I)
+elemental real(kind=16) function _gfortran_ieee_scalb_16_1 (X, I)
   real(kind=16), intent(in) :: X
+  integer(kind=1), intent(in) :: I
+end function
+#endif
+#ifdef HAVE_GFC_REAL_10
+elemental real(kind=10) function _gfortran_ieee_scalb_10_1 (X, I)
+  real(kind=10), intent(in) :: X
+  integer(kind=1), intent(in) :: I
+end function
+#endif
+elemental real(kind=8) function _gfortran_ieee_scalb_8_1 (X, I)
+  real(kind=8), intent(in) :: X
+  integer(kind=1), intent(in) :: I
+end function
+elemental real(kind=4) function _gfortran_ieee_scalb_4_1 (X, I)
+  real(kind=4), intent(in) :: X
+  integer(kind=1), intent(in) :: I
+end function
+#endif
+
+#ifdef HAVE_GFC_REAL_16
+elemental real(kind=16) function _gfortran_ieee_scalb_16_4 (X, I)
+  real(kind=16), intent(in) :: X
   integer, intent(in) :: I
 end function
 #endif
+#ifdef HAVE_GFC_REAL_10
+elemental 

Re: Relax std::move_if_noexcept for std::pair

[François Dumont]

On 12/20/18 9:04 AM, Ville Voutilainen wrote:

On Thu, 20 Dec 2018 at 08:29, François Dumont  wrote:

Hi

  I eventually find out what was the problem with the
std::move_if_noexcept within associative containers.

  The std::pair move default constructor might not move both first
and second member. If any is not moveable it will just copy it. And then

..as it should..


the noexcept qualification of the copy constructor will participate in
the noexcept qualification of the std::pair move constructor. So
std::move_if_noexcept can eventually decide to not use move because a
_copy_ constructor not noexcept qualified.

..and again, as it should.


  This is why I am partially specializing __move_if_noexcept_cond. As
there doesn't seem to exist any Standard meta function to find out if
move will take place I resort using std::is_const as in this case for
sure the compiler won't call the move constructor.

That seems wrong; just because a type is or is not const has nothing
to do whether
it's nothrow_move_constructible.


Indeed, I am not changing that.




I don't understand what problem this is solving, and how it's not
introducing new problems.

The problem I am trying to solve is shown by the tests I have adapted. 
Allow more move semantic in associative container where key are stored 
as const.


But if I make counter_type copy constructor noexcept then I also get the 
move on the pair.second instance, great. I am just surprise to have to 
make a copy constructor noexcept to have std::move_if_noexcept work as I 
expect.


I think I just need to understand why we need std::move_if_noexcept in 
unordered containers or even rb_tree. Couldn't we just use std::move ? I 
don't understand what we are trying to avoid with this noexcept check.


François

C++ PATCH for c++/88196, ICE with class non-type template parameter

[Marek Polacek]

This testcase breaks in C++20 because convert_nontype_argument gets a PTRMEM_CST
as the expression, and we're trying to convert it to a class type, which
doesn't work, but because of the PTRMEM_CST check below we never diagnosed it.

The comment says a PTRMEM_CST is a valid template argument for a parameter of
pointer to member type, but it doesn't check that that's what we're converting
it to.  Fixed by adding such a check.

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

2018-12-20  Marek Polacek  

PR c++/88196 - ICE with class non-type template parameter.
* pt.c (convert_nontype_argument): If the expr is a PTRMEM_CST, also
check if the type we're converting it to is TYPE_PTRMEM_P.

* g++.dg/cpp0x/ptrmem-cst-arg1.C: Tweak dg-error.
* g++.dg/cpp2a/nontype-class10.C: New test.
* g++.dg/template/pr54858.C: Tweak dg-error.

diff --git gcc/cp/pt.c gcc/cp/pt.c
index d4ac034671a..18b093e7d2d 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -6775,7 +6775,7 @@ convert_nontype_argument (tree type, tree expr, 
tsubst_flags_t complain)
  to a null value, but otherwise still need to be of a specific form.  */
   if (cxx_dialect >= cxx11)
 {
-  if (TREE_CODE (expr) == PTRMEM_CST)
+  if (TREE_CODE (expr) == PTRMEM_CST && TYPE_PTRMEM_P (type))
/* A PTRMEM_CST is already constant, and a valid template
   argument for a parameter of pointer to member type, we just want
   to leave it in that form rather than lower it to a
diff --git gcc/testsuite/g++.dg/cpp0x/ptrmem-cst-arg1.C 
gcc/testsuite/g++.dg/cpp0x/ptrmem-cst-arg1.C
index ed12655af32..38b3e24241c 100644
--- gcc/testsuite/g++.dg/cpp0x/ptrmem-cst-arg1.C
+++ gcc/testsuite/g++.dg/cpp0x/ptrmem-cst-arg1.C
@@ -5,5 +5,5 @@ template struct A {};
 struct B
 {
 int i;
-A<&B::i> a; // { dg-error "could not convert template argument" }
+A<&B::i> a; // { dg-error "could not convert" }
 };
diff --git gcc/testsuite/g++.dg/cpp2a/nontype-class10.C 
gcc/testsuite/g++.dg/cpp2a/nontype-class10.C
new file mode 100644
index 000..5cc179300ca
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/nontype-class10.C
@@ -0,0 +1,6 @@
+// PR c++/88196
+// { dg-do compile { target c++2a } }
+
+struct C { C *c; };
+template  struct D;
+D <&C::c> d; // { dg-error "could not convert" }
diff --git gcc/testsuite/g++.dg/template/pr54858.C 
gcc/testsuite/g++.dg/template/pr54858.C
index 51610ad689a..6d23decfbb9 100644
--- gcc/testsuite/g++.dg/template/pr54858.C
+++ gcc/testsuite/g++.dg/template/pr54858.C
@@ -5,17 +5,17 @@ template  struct A {};
 template  struct B {};
 template  struct C
 {
-  A<0> c0; B, &C::c0> d0; // { dg-error "could not convert template 
argument" }
-  A<0> c1; B, &C::c1> d1; // { dg-error "could not convert template 
argument" }
-  A<0> c2; B, &C::c2> d2; // { dg-error "could not convert template 
argument" }
-  A<0> c3; B, &C::c3> d3; // { dg-error "could not convert template 
argument" }
-  A<0> c4; B, &C::c4> d4; // { dg-error "could not convert template 
argument" }
-  A<0> c5; B, &C::c5> d5; // { dg-error "could not convert template 
argument" }
-  A<0> c6; B, &C::c6> d6; // { dg-error "could not convert template 
argument" }
-  A<0> c7; B, &C::c7> d7; // { dg-error "could not convert template 
argument" }
-  A<0> c8; B, &C::c8> d8; // { dg-error "could not convert template 
argument" }
-  A<0> c9; B, &C::c9> d9; // { dg-error "could not convert template 
argument" }
-  A<0> ca; B, &C::ca> da; // { dg-error "could not convert template 
argument" }
-  A<0> cb; B, &C::cb> db; // { dg-error "could not convert template 
argument" }
+  A<0> c0; B, &C::c0> d0; // { dg-error "could not convert" }
+  A<0> c1; B, &C::c1> d1; // { dg-error "could not convert" }
+  A<0> c2; B, &C::c2> d2; // { dg-error "could not convert" }
+  A<0> c3; B, &C::c3> d3; // { dg-error "could not convert" }
+  A<0> c4; B, &C::c4> d4; // { dg-error "could not convert" }
+  A<0> c5; B, &C::c5> d5; // { dg-error "could not convert" }
+  A<0> c6; B, &C::c6> d6; // { dg-error "could not convert" }
+  A<0> c7; B, &C::c7> d7; // { dg-error "could not convert" }
+  A<0> c8; B, &C::c8> d8; // { dg-error "could not convert" }
+  A<0> c9; B, &C::c9> d9; // { dg-error "could not convert" }
+  A<0> ca; B, &C::ca> da; // { dg-error "could not convert" }
+  A<0> cb; B, &C::cb> db; // { dg-error "could not convert" }
 };
 C e;

Re: [PATCH] Use proper print formatter in main function in fixincl.c

[nick]

On 2018-12-20 4:02 p.m., Joseph Myers wrote:
> This is still changing the wrong format specifier (the one corresponding 
> to apply_ct, which is an int).
> 

Sorry for the dumb mistakes as I seem to have miscounted the variables over
in my understanding of the code.

I will resend again and sorry for wasting your time Joseph,

Nick

Re: Relax std::move_if_noexcept for std::pair

[Ville Voutilainen]

On Thu, 20 Dec 2018 at 23:53, François Dumont  wrote:
> >>   This is why I am partially specializing __move_if_noexcept_cond. As
> >> there doesn't seem to exist any Standard meta function to find out if
> >> move will take place I resort using std::is_const as in this case for
> >> sure the compiler won't call the move constructor.
> > That seems wrong; just because a type is or is not const has nothing
> > to do whether
> > it's nothrow_move_constructible.
>
> Indeed, I am not changing that.

Well, if you're not changing that, then I have no idea what is_const
is doing in your patch. :)

> > I don't understand what problem this is solving, and how it's not
> > introducing new problems.
> >
> The problem I am trying to solve is shown by the tests I have adapted.
> Allow more move semantic in associative container where key are stored
> as const.

I'm not sure what you're trying to achieve is doable. The element of
an associative container is a pair,
and it has pair's semantics. It's also a pair, and
has those semantics. Those semantics
are observable.

> But if I make counter_type copy constructor noexcept then I also get the
> move on the pair.second instance, great. I am just surprise to have to
> make a copy constructor noexcept to have std::move_if_noexcept work as I
> expect.

Well, move construction/assignment via std::move or
std::move_if_noexcept is not necessarily
going to invoke just move constructors. Especially not for subobjects,
like pair's members.

> I think I just need to understand why we need std::move_if_noexcept in
> unordered containers or even rb_tree. Couldn't we just use std::move ? I
> don't understand what we are trying to avoid with this noexcept check.

We are trying to avoid data corruption on exceptions; if you move a
subobject and have to copy another,
and then that copy operation throws, you can't reliably move the
already-moved subobject back. See
http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3050.html
and also
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html

[PATCH] Use proper print formatter in main function in fixincl.c

[Nicholas Krause]

This fixes the bug id, 71176 to use the proper known
code print formatter type, %lu for size_t rather than
%d which is considered best pratice for print statements.

Signed-off-by: Nicholas Krause 
---
 fixincludes/fixincl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 6dba2f6e830..5b8b77a77f0 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -158,11 +158,11 @@ main (int argc, char** argv)
   if (VLEVEL( VERB_PROGRESS )) {
 tSCC zFmt[] =
   "\
-Processed %5d files containing %d bytes\n\
+Processed %5d files containing %lu bytes\n\
 Applying  %5d fixes to %d files\n\
 Altering  %5d of them\n";
 
-fprintf (stderr, zFmt, process_ct, ttl_data_size, apply_ct,
+fprintf (stderr, zFmt, process_ct, (unsigned int long) ttl_data_size, 
apply_ct,
  fixed_ct, altered_ct);
   }
 #endif /* DO_STATS */
-- 
2.17.1

Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446)

[Jakub Jelinek]

On Thu, Dec 20, 2018 at 04:47:29PM -0500, Jason Merrill wrote:
> > So are you ok with what is in the patch below, i.e.
> > {
> >   bool non_cst_p = false, ovf_p = false;
> >   tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
> >  &non_cst_p, &ovf_p);
> >   if ((!non_cst_p && !ovf_p) || !ctx->manifestly_const_eval)
> > args[i] = a;
> > }
> > , or perhaps without the || !ctx->manifestly_const_eval?
> 
> I don't see how that makes a difference from what was there before; if the
> argument to cxx_eval_constant_expression is non-constant, it returns the
> argument unchanged.

If that is guaranteed, then it is ok to keep it as is I guess.
Will change it then.

> > So, if the
> > argument is a constant expression, fold to that, if it is not, just do
> > cp_fully_fold on it if it is __builtin_constant_p, otherwise nothing?
> 
> Hmm, cp_fully_fold probably also needs to add a manifestly_const_eval
> parameter to pass along to maybe_constant_value.

But if we need cp_fully_fold, doesn't that mean that the earlier
cxx_eval_constant_expression failed and thus the argument is not a constant
expression?  Should __builtin_is_constant_evaluated () evaluate to true
even if the argument is not a constant expression?
Say if there is
int v;
constexpr int foo (void)
{
  return __builtin_constant_p (v * (__builtin_is_constant_evaluated () ? 1 : 
0));
}
Because v is not a constant expression,
v * (__builtin_is_constant_evaluated () ? 1 : 0) shouldn't be either.

cp_fully_fold does:
  /* FIXME cp_fold ought to be a superset of maybe_constant_value so we don't
 have to call both.  */
  if (cxx_dialect >= cxx11)
{
  x = maybe_constant_value (x);
  /* Sometimes we are given a CONSTRUCTOR but the call above wraps it into
 a TARGET_EXPR; undo that here.  */
  if (TREE_CODE (x) == TARGET_EXPR)
x = TARGET_EXPR_INITIAL (x);
  else if (TREE_CODE (x) == VIEW_CONVERT_EXPR
   && TREE_CODE (TREE_OPERAND (x, 0)) == CONSTRUCTOR
   && TREE_TYPE (TREE_OPERAND (x, 0)) == TREE_TYPE (x))
x = TREE_OPERAND (x, 0);
}
  return cp_fold_rvalue (x);
Is there a reason to call that maybe_constant_value at all when we've called
cxx_eval_constant_expression first?  Wouldn't cp_fold_rvalue (or
c_fully_fold with false as last argument) be sufficient there?

Jakub

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

[Jeff Law]

On 12/20/18 2:30 PM, Peter Bergner wrote:
> On 12/20/18 2:26 PM, Segher Boessenkool wrote:
>> On Thu, Dec 20, 2018 at 09:07:41PM +0100, Eric Botcazou wrote:
 It's not a terrible workaround, no.  It looks like it will make some asm
 once again fail though?  If argument registers are forwarded to in the asm.
>>>
>>> The combiner change looks like a big hammer for such a corner case though.
>>
>> That isn't the primary goal, no; the primary goal is to get better RA (by
>> not having the combiner do RA's work, and doing a mediocre job of it).  It
>> does solve these problems though.
> 
> My recent RA patches improved conflict information by noticing when we
> don't need a conflict for a copy insn between a hard reg and a pseudo
> when the source operand is live past the copy.  However, conflict info
> for copies between two pseudos wasn't affected because IRA/LRA computes
> liveness differently for pseudos than for hard regs.  I have seen copies
> between two pseudos still get to RA and we're not able to do anything
> about them at the moment because we still think they conflict.
> 
> For stage1, I'd like to fix that conflict wart if I can.  I have also
> wondered about adding a copy coalesce phase just before we enter RA,
> which would ensure the copies are removed, instead of hoping RA assigns
> the same reg to the source and destination of the copy making it a nop
> that can be removed.
The difficulty with coalescing is that if you get too aggressive then
you end up removing degrees of freedom from the allocator and you can
easily make the final results worse.

Jeff

[PATCH] Avoid carrying around jump functions with no information

[Martin Jambor]

Hi Honza,

the patch below avoids keeping jump functions that do not hold any
interesting value.  For all users such dropped jump function vectors
will then appear as empty ones, which they should handle gracefully
because they already can deal with parameter count mismatches
(especially during LTO).

It also changes the vector allocation to use vec_safe_reserve_exact,
which could save a few bytes here and there too.

I have bootstrapped and tested it on x86-64-linux, LTO bootstrap is in
progress.  If you like it and if it helps with memory use, feel free to
commit it to trunk.

Martin


2018-12-20  Martin Jambor  

* ipa-prop.c (determine_locally_known_aggregate_parts): Return
true iff any aggregate value has been discovered.
(ipa_compute_jump_functions_for_edge): Assert that jump_functions
have not been already calculated, use vec_safe_reserve_exact to
allocate vectors, only store them if there is a useful value.
---
 gcc/ipa-prop.c | 98 +++---
 1 file changed, 69 insertions(+), 29 deletions(-)

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 05e666e0588..402f8cbd969 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1541,9 +1541,10 @@ build_agg_jump_func_from_list (struct 
ipa_known_agg_contents_list *list,
in ARG is filled in with constant values.  ARG can either be an aggregate
expression or a pointer to an aggregate.  ARG_TYPE is the type of the
aggregate.  JFUNC is the jump function into which the constants are
-   subsequently stored.  */
+   subsequently stored.  Return true if any known aggregate value has been
+   discovered.  */
 
-static void
+static bool
 determine_locally_known_aggregate_parts (gcall *call, tree arg,
 tree arg_type,
 struct ipa_jump_func *jfunc)
@@ -1557,7 +1558,7 @@ determine_locally_known_aggregate_parts (gcall *call, 
tree arg,
   ao_ref r;
 
   if (PARAM_VALUE (PARAM_IPA_MAX_AGG_ITEMS) == 0)
-return;
+return false;
 
   /* The function operates in three stages.  First, we prepare check_ref, r,
  arg_base and arg_offset based on what is actually passed as an actual
@@ -1571,7 +1572,7 @@ determine_locally_known_aggregate_parts (gcall *call, 
tree arg,
  tree type_size;
   if (!tree_fits_uhwi_p (TYPE_SIZE (TREE_TYPE (arg_type)))
  || !POINTER_TYPE_P (TREE_TYPE (arg)))
-return;
+return false;
  check_ref = true;
  arg_base = arg;
  arg_offset = 0;
@@ -1587,17 +1588,17 @@ determine_locally_known_aggregate_parts (gcall *call, 
tree arg,
  arg_base = get_ref_base_and_extent_hwi (arg, &arg_offset,
  &arg_size, &reverse);
  if (!arg_base)
-   return;
+   return false;
  if (DECL_P (arg_base))
{
  check_ref = false;
  ao_ref_init (&r, arg_base);
}
  else
-   return;
+   return false;
}
   else
-   return;
+   return false;
 }
   else
 {
@@ -1610,7 +1611,7 @@ determine_locally_known_aggregate_parts (gcall *call, 
tree arg,
   arg_base = get_ref_base_and_extent_hwi (arg, &arg_offset,
  &arg_size, &reverse);
   if (!arg_base)
-   return;
+   return false;
 
   ao_ref_init (&r, arg);
 }
@@ -1697,7 +1698,9 @@ determine_locally_known_aggregate_parts (gcall *call, 
tree arg,
 {
   jfunc->agg.by_ref = by_ref;
   build_agg_jump_func_from_list (list, const_count, arg_offset, jfunc);
+  return true;
 }
+  return false;
 }
 
 /* Return the Ith param type of callee associated with call graph
@@ -1827,18 +1830,24 @@ ipa_compute_jump_functions_for_edge (struct 
ipa_func_body_info *fbi,
   struct ipa_edge_args *args = IPA_EDGE_REF (cs);
   gcall *call = cs->call_stmt;
   int n, arg_num = gimple_call_num_args (call);
+  bool useful_value = false;
   bool useful_context = false;
 
-  if (arg_num == 0 || args->jump_functions)
+  if (arg_num == 0
+  || gimple_call_internal_p (call)
+  || ipa_func_spec_opts_forbid_analysis_p (cs->caller))
 return;
-  vec_safe_grow_cleared (args->jump_functions, arg_num);
-  if (flag_devirtualize)
-vec_safe_grow_cleared (args->polymorphic_call_contexts, arg_num);
+  gcc_checking_assert (!args->jump_functions
+  && !args->polymorphic_call_contexts);
 
-  if (gimple_call_internal_p (call))
-return;
-  if (ipa_func_spec_opts_forbid_analysis_p (cs->caller))
-return;
+  vec_safe_reserve_exact (args->jump_functions, arg_num);
+  args->jump_functions->quick_grow_cleared (arg_num);
+
+  if (flag_devirtualize)
+{
+  vec_safe_reserve_exact (args->polymorphic_call_contexts, arg_num);
+  vec_safe_grow_cleared (args->polymorphic_call_contexts, arg_num);
+}
 
   for (n = 0; n < arg_num; n+

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

[Peter Bergner]

On 12/20/18 4:41 PM, Jeff Law wrote:
> On 12/20/18 2:30 PM, Peter Bergner wrote:
>> For stage1, I'd like to fix that conflict wart if I can.  I have also
>> wondered about adding a copy coalesce phase just before we enter RA,
>> which would ensure the copies are removed, instead of hoping RA assigns
>> the same reg to the source and destination of the copy making it a nop
>> that can be removed.
> The difficulty with coalescing is that if you get too aggressive then
> you end up removing degrees of freedom from the allocator and you can
> easily make the final results worse.

I agree, but being too aggressive leading to bad decisions/code is
true for a lot of optimizations. :-)   I do plan on first attacking
the conservative conflict info for pseudos first and seeing what
that buys us before attempting any coalescing.

As for removing degrees of freedom for the allocator, sometimes that can
be a good thing, if it can makes the allocator simpler.  For example, I
think we have forced the allocator to do too much by not only being an RA,
but being an instruction selector as well.  Doing both RA and instruction
selection at the same time makes everything very complicated and I think
we probably don't compute allocation costs correctly, since we seem to
calculate costs on a per alternative per insn basis and I don't think we
ever see what the ramifications of using an alternative in one insn
has on the costs of another alternative in another insn.  Sometimes using
the cheapest alternative in one insn and the cheapest alternative in
another insn can lead us into a situation that requires spilling to
resolve the conflicting choices.

I've wondered if running something like lra_constraints() (but using
pseudos for fixups rather than hard regs) early in the rtl passes as
a pseudo instruction selection pass wouldn't make things easier for
the following passes like RA, etc?

Peter

Re: [PATCH] fix compile error with clang

[Dave Murphy]

Sorry, fatfingered the address for this patch. Thanks to everyone who
let me know off list, it's been sent to the right list now. :)

Dave

On Thu, Dec 20, 2018 at 4:43 PM Dave Murphy  wrote:
>
> Cross compiling for macOS using osxcross gives errors of the form
> "error: default initialization of an object of ... without a
> user-provided default constructor"
>
> Fixed by attached patch, tested compile with mingw-w64, osxcross and
> linux native builds.
>
> 2018-12-20  Dave Murphy  
>
> * gdb/dtrace-probe.c (dtrace_static_probe_ops): explicit zero initialise.
> * gdb/probe.c (any_static_probe_ops): ditto
> * gdb/record-btrace.c (record_btrace_thread_observer_token): ditto
> * gdb/stap-probe.c (stap_static_probe_ops): ditto
> * gdb/tui/tui-hooks.c (tui_observers_token): ditto
> * gdb/unittests/observable-selftests.c (token1, token2, token3): ditto

Re: [PATCH] -Wtautological-compare: fix comparison of macro expansions

[Aaron Sawdey]

On 12/20/18 8:25 AM, David Malcolm wrote:
> According to comments within PR c++/87504, the patch fixes the
> bootstrap on aarch64, and fixes a similar issue on Solaris/SPARC.
> 
> It also passed bootstrap®rtesting on x86_64-pc-linux-gnu.
> 
> Given that, I've committed it to trunk as r267299.
> 
> Aaron, does this fix the issue you saw?
> 
> Thanks, and sorry again about the breakage.
> Dave
> 

Dave,
  Thanks for the quick response, the build issue is fixed with r267299.

  Aaron

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain

Re: [PATCH][rs6000] avoid using unaligned vsx or lxvd2x/stxvd2x for memcpy/memmove inline expansion

[Aaron Sawdey]

On 12/20/18 3:51 AM, Segher Boessenkool wrote:
> On Wed, Dec 19, 2018 at 01:53:05PM -0600, Aaron Sawdey wrote:
>> Because of POWER9 dd2.1 issues with certain unaligned vsx instructions
>> to cache inhibited memory, here is a patch that keeps memmove (and memcpy)
>> inline expansion from doing unaligned vector or using vector load/store
>> other than lvx/stvx. More description of the issue is here:
>>
>> https://patchwork.ozlabs.org/patch/814059/
>>
>> OK for trunk if bootstrap/regtest ok?
> 
> Okay, but see below.
> 
[snip]
> 
> This is extraordinarily clumsy :-)  Maybe something like:
> 
> static rtx
> gen_lvx_v4si_move (rtx dest, rtx src)
> {
>   gcc_assert (!(MEM_P (dest) && MEM_P (src));
>   gcc_assert (GET_MODE (dest) == V4SImode && GET_MODE (src) == V4SImode);
>   if (MEM_P (dest))
> return gen_altivec_stvx_v4si_internal (dest, src);
>   else if (MEM_P (src))
> return gen_altivec_lvx_v4si_internal (dest, src);
>   else
> gcc_unreachable ();
> }
> 
> (Or do you allow VOIDmode for src as well?)  Anyway, at least get rid of
> the useless extra variable.

I think this should be better:

static rtx
gen_lvx_v4si_move (rtx dest, rtx src)
{
  gcc_assert ((MEM_P (dest) && !MEM_P (src)) || (MEM_P (src) && !MEM_P(dest)));
  gcc_assert (GET_MODE (dest) == V4SImode && GET_MODE (src) == V4SImode);
  if (MEM_P (dest))
  return gen_altivec_stvx_v4si_internal (dest, src);
  else if (MEM_P (src))
  return gen_altivec_lvx_v4si_internal (dest, src);
  gcc_unreachable ();
}

I'll commit after I re-regstrap.

Thanks!
   Aaron

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain

Re: [PATCH][rs6000] avoid using unaligned vsx or lxvd2x/stxvd2x for memcpy/memmove inline expansion

[Segher Boessenkool]

On Thu, Dec 20, 2018 at 05:34:54PM -0600, Aaron Sawdey wrote:
> On 12/20/18 3:51 AM, Segher Boessenkool wrote:
> > On Wed, Dec 19, 2018 at 01:53:05PM -0600, Aaron Sawdey wrote:
> >> Because of POWER9 dd2.1 issues with certain unaligned vsx instructions
> >> to cache inhibited memory, here is a patch that keeps memmove (and memcpy)
> >> inline expansion from doing unaligned vector or using vector load/store
> >> other than lvx/stvx. More description of the issue is here:
> >>
> >> https://patchwork.ozlabs.org/patch/814059/
> >>
> >> OK for trunk if bootstrap/regtest ok?
> > 
> > Okay, but see below.
> > 
> [snip]
> > 
> > This is extraordinarily clumsy :-)  Maybe something like:
> > 
> > static rtx
> > gen_lvx_v4si_move (rtx dest, rtx src)
> > {
> >   gcc_assert (!(MEM_P (dest) && MEM_P (src));
> >   gcc_assert (GET_MODE (dest) == V4SImode && GET_MODE (src) == V4SImode);
> >   if (MEM_P (dest))
> > return gen_altivec_stvx_v4si_internal (dest, src);
> >   else if (MEM_P (src))
> > return gen_altivec_lvx_v4si_internal (dest, src);
> >   else
> > gcc_unreachable ();
> > }
> > 
> > (Or do you allow VOIDmode for src as well?)  Anyway, at least get rid of
> > the useless extra variable.
> 
> I think this should be better:

The gcc_unreachable at the end catches the non-mem to non-mem case.

> static rtx
> gen_lvx_v4si_move (rtx dest, rtx src)
> {
>   gcc_assert ((MEM_P (dest) && !MEM_P (src)) || (MEM_P (src) && 
> !MEM_P(dest)));

But if you prefer this, how about

{
  gcc_assert (MEM_P (dest) ^ MEM_P (src));
  gcc_assert (GET_MODE (dest) == V4SImode && GET_MODE (src) == V4SImode);

  if (MEM_P (dest))
return gen_altivec_stvx_v4si_internal (dest, src);
  else
return gen_altivec_lvx_v4si_internal (dest, src);
}

:-)


Segher

Re: RFA: Avoid versioning loop with unaligned step

[Jakub Jelinek]

On Thu, Dec 20, 2018 at 07:46:31PM +, Richard Sandiford wrote:
> > vect_compute_data_ref_alignment uses DR_TARGET_ALIGNMENT
> > and DR_STEP_ALIGNMENT () % dr_target-alignment == 0 as check.
> >
> > I think it's preferable to use the same or similar values for the desired
> > alignment.
> 
> Yeah, I agree testing for a multiple is better than maybe_lt,
> and that we should be using DR_TARGET_ALIGNMENT rather than
> TYPE_ALIGN_UNIT.
> 
> (TYPE_ALIGN_UNIT is the ABI alignment, which might be higher or lower
> than the alignment the vectoriser is aiming for.  And I think the
> reasons for bailing out apply whenever the vectoriser can't reach
> the alignment it's aiming for, even if the alignment isn't needed
> for correctness.)

r267314 seems to have broken build:
../../gcc/tree-vect-data-refs.c: In function ‘opt_result 
vect_enhance_data_refs_alignment(loop_vec_info)’:
../../gcc/tree-vectorizer.h:1255:40: error: ‘struct data_reference’ has no 
member named ‘target_alignment’
 #define DR_TARGET_ALIGNMENT(DR) ((DR)->target_alignment)
^
../../gcc/tree-vect-data-refs.c:2171:11: note: in expansion of macro 
‘DR_TARGET_ALIGNMENT’
   DR_TARGET_ALIGNMENT (dr)))
   ^~~

The following patch makes it build again, will commit as obvious if it
passes bootstrap/regtest:

2018-12-21  Jakub Jelinek  

* tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Use
DR_TARGET_ALIGNMENT on dr_info rather than dr.

--- gcc/tree-vect-data-refs.c.jj2018-12-21 00:40:50.0 +0100
+++ gcc/tree-vect-data-refs.c   2018-12-21 00:43:35.786222062 +0100
@@ -2168,7 +2168,7 @@ vect_enhance_data_refs_alignment (loop_v
 done by doing some iterations of the non-vectorized loop.  */
  if (!multiple_p (LOOP_VINFO_VECT_FACTOR (loop_vinfo)
   * DR_STEP_ALIGNMENT (dr),
-  DR_TARGET_ALIGNMENT (dr)))
+  DR_TARGET_ALIGNMENT (dr_info)))
{
  do_versioning = false;
  break;


Jakub

Re: [PATCH][rs6000] avoid using unaligned vsx or lxvd2x/stxvd2x for memcpy/memmove inline expansion

[Aaron Sawdey]

On 12/20/18 5:44 PM, Segher Boessenkool wrote:
> On Thu, Dec 20, 2018 at 05:34:54PM -0600, Aaron Sawdey wrote:
>> On 12/20/18 3:51 AM, Segher Boessenkool wrote:
>>> On Wed, Dec 19, 2018 at 01:53:05PM -0600, Aaron Sawdey wrote:
 Because of POWER9 dd2.1 issues with certain unaligned vsx instructions
 to cache inhibited memory, here is a patch that keeps memmove (and memcpy)
 inline expansion from doing unaligned vector or using vector load/store
 other than lvx/stvx. More description of the issue is here:

 https://patchwork.ozlabs.org/patch/814059/

 OK for trunk if bootstrap/regtest ok?
>>>
>>> Okay, but see below.
>>>
>> [snip]
>>>
>>> This is extraordinarily clumsy :-)  Maybe something like:
>>>
>>> static rtx
>>> gen_lvx_v4si_move (rtx dest, rtx src)
>>> {
>>>   gcc_assert (!(MEM_P (dest) && MEM_P (src));
>>>   gcc_assert (GET_MODE (dest) == V4SImode && GET_MODE (src) == V4SImode);
>>>   if (MEM_P (dest))
>>> return gen_altivec_stvx_v4si_internal (dest, src);
>>>   else if (MEM_P (src))
>>> return gen_altivec_lvx_v4si_internal (dest, src);
>>>   else
>>> gcc_unreachable ();
>>> }
>>>
>>> (Or do you allow VOIDmode for src as well?)  Anyway, at least get rid of
>>> the useless extra variable.
>>
>> I think this should be better:
> 
> The gcc_unreachable at the end catches the non-mem to non-mem case.
> 
>> static rtx
>> gen_lvx_v4si_move (rtx dest, rtx src)
>> {
>>   gcc_assert ((MEM_P (dest) && !MEM_P (src)) || (MEM_P (src) && 
>> !MEM_P(dest)));
> 
> But if you prefer this, how about
> 
> {
>   gcc_assert (MEM_P (dest) ^ MEM_P (src));
>   gcc_assert (GET_MODE (dest) == V4SImode && GET_MODE (src) == V4SImode);
> 
>   if (MEM_P (dest))
> return gen_altivec_stvx_v4si_internal (dest, src);
>   else
> return gen_altivec_lvx_v4si_internal (dest, src);
> }
> 
> :-)
> 
> 
> Segher
> 

I like that even better, thanks!

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain

Re: [PATCH] PR fortran/85798 -- Check for allocatable components in data statement

[Steve Kargl]

On Sun, Dec 16, 2018 at 11:04:44AM -0800, Steve Kargl wrote:
> The attached patch has been tested on i586-*-freebsd and x86_64-*-freebsd.
> If a data-statement-object is a component of a derived type, it checks if
> that component is allocatable.
> 
> 2018-12-16  Steven G . Kargl  
> 
>   PR fortran/85798
>   * decl.c (gfc_match_data): If a component of a derived type entity
>   appears in data statement, check that does not have the allocatable
>   attribute.
>  
> 2018-12-16  Steven G . Kargl  
> 
>   PR fortran/85798
>   * gfortran.dg/pr85798.f90: New test.
> 

Ping.

-- 
Steve

Re: RFA: Avoid versioning loop with unaligned step

[Jakub Jelinek]

On Fri, Dec 21, 2018 at 12:46:41AM +0100, Jakub Jelinek wrote:
> The following patch makes it build again, will commit as obvious if it
> passes bootstrap/regtest:
> 
> 2018-12-21  Jakub Jelinek  
> 
>   * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Use
>   DR_TARGET_ALIGNMENT on dr_info rather than dr.
> 
> --- gcc/tree-vect-data-refs.c.jj  2018-12-21 00:40:50.0 +0100
> +++ gcc/tree-vect-data-refs.c 2018-12-21 00:43:35.786222062 +0100
> @@ -2168,7 +2168,7 @@ vect_enhance_data_refs_alignment (loop_v
>done by doing some iterations of the non-vectorized loop.  */
> if (!multiple_p (LOOP_VINFO_VECT_FACTOR (loop_vinfo)
>  * DR_STEP_ALIGNMENT (dr),
> -DR_TARGET_ALIGNMENT (dr)))
> +DR_TARGET_ALIGNMENT (dr_info)))
>   {
> do_versioning = false;
> break;
> 

Here is what I've actually committed, some spelling errors fixed too:

2018-12-21  Jakub Jelinek  

* tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Use
DR_TARGET_ALIGNMENT on dr_info rather than dr.  Spelling fixes.

--- gcc/tree-vect-data-refs.c.jj2018-12-21 00:40:50.0 +0100
+++ gcc/tree-vect-data-refs.c   2018-12-21 00:43:35.786222062 +0100
@@ -2163,12 +2163,12 @@ vect_enhance_data_refs_alignment (loop_v
  /* Forcing alignment in the first iteration is no good if
 we don't keep it across iterations.  For now, just disable
 versioning in this case.
-?? We could actually unroll the loop to archive the required
-overall step alignemnt, and forcing the alignment could be
+?? We could actually unroll the loop to achieve the required
+overall step alignment, and forcing the alignment could be
 done by doing some iterations of the non-vectorized loop.  */
  if (!multiple_p (LOOP_VINFO_VECT_FACTOR (loop_vinfo)
   * DR_STEP_ALIGNMENT (dr),
-  DR_TARGET_ALIGNMENT (dr)))
+  DR_TARGET_ALIGNMENT (dr_info)))
{
  do_versioning = false;
  break;


Jakub

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

[Martin Sebor]

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

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

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

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

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

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

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


Martin, thoughts?


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


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



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

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

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

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


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


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



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

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



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


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

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

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

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

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

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

should be updated and the referenced bug and any others that this
change prevents should be resolved.

Martin

Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446)

[Jason Merrill]

On 12/20/18 5:27 PM, Jakub Jelinek wrote:

On Thu, Dec 20, 2018 at 04:47:29PM -0500, Jason Merrill wrote:

So are you ok with what is in the patch below, i.e.
 {
   bool non_cst_p = false, ovf_p = false;
   tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
  &non_cst_p, &ovf_p);
   if ((!non_cst_p && !ovf_p) || !ctx->manifestly_const_eval)
 args[i] = a;
 }
, or perhaps without the || !ctx->manifestly_const_eval?


I don't see how that makes a difference from what was there before; if the
argument to cxx_eval_constant_expression is non-constant, it returns the
argument unchanged.


If that is guaranteed, then it is ok to keep it as is I guess.
Will change it then.


So, if the
argument is a constant expression, fold to that, if it is not, just do
cp_fully_fold on it if it is __builtin_constant_p, otherwise nothing?


Hmm, cp_fully_fold probably also needs to add a manifestly_const_eval
parameter to pass along to maybe_constant_value.


But if we need cp_fully_fold, doesn't that mean that the earlier
cxx_eval_constant_expression failed and thus the argument is not a constant
expression?  Should __builtin_is_constant_evaluated () evaluate to true
even if the argument is not a constant expression?


Ah, no, good point.


Say if there is
int v;
constexpr int foo (void)
{
   return __builtin_constant_p (v * (__builtin_is_constant_evaluated () ? 1 : 
0));
}
Because v is not a constant expression,
v * (__builtin_is_constant_evaluated () ? 1 : 0) shouldn't be either.

cp_fully_fold does:
   /* FIXME cp_fold ought to be a superset of maybe_constant_value so we don't
  have to call both.  */
   if (cxx_dialect >= cxx11)
 {
   x = maybe_constant_value (x);
   /* Sometimes we are given a CONSTRUCTOR but the call above wraps it into
  a TARGET_EXPR; undo that here.  */
   if (TREE_CODE (x) == TARGET_EXPR)
 x = TARGET_EXPR_INITIAL (x);
   else if (TREE_CODE (x) == VIEW_CONVERT_EXPR
&& TREE_CODE (TREE_OPERAND (x, 0)) == CONSTRUCTOR
&& TREE_TYPE (TREE_OPERAND (x, 0)) == TREE_TYPE (x))
 x = TREE_OPERAND (x, 0);
 }
   return cp_fold_rvalue (x);
Is there a reason to call that maybe_constant_value at all when we've called
cxx_eval_constant_expression first?  Wouldn't cp_fold_rvalue (or
c_fully_fold with false as last argument) be sufficient there?


I think that would be better, yes.

Jason

Re: C++ PATCH for c++/88196, ICE with class non-type template parameter

[Jason Merrill]

On 12/20/18 4:54 PM, Marek Polacek wrote:

This testcase breaks in C++20 because convert_nontype_argument gets a PTRMEM_CST
as the expression, and we're trying to convert it to a class type, which
doesn't work, but because of the PTRMEM_CST check below we never diagnosed it.

The comment says a PTRMEM_CST is a valid template argument for a parameter of
pointer to member type, but it doesn't check that that's what we're converting
it to.  Fixed by adding such a check.

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


OK.

Jason

Re: [PATCH] handle expressions in __builtin_has_attribute (PR 88383)

[Martin Sebor]

Jeff, did this and the rest of the discussion answer your question
and if so, is the patch okay to commit?

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

Martin

On 12/13/18 12:48 PM, Martin Sebor wrote:

On 12/13/18 12:20 PM, Martin Sebor wrote:

On 12/13/18 11:59 AM, Jeff Law wrote:

On 12/5/18 8:55 PM, Martin Sebor wrote:

The __builtin_has_attribute function fails with an ICE when
its first argument is an expression such as INDIRECT_REF, or
many others.  The code simply assumes it's either a type or
a decl.  The attached patch corrects this oversight.

While testing the fix I also noticed the C++ front end expects
the first operand to be a unary expression, which causes most
other kinds of expressions to be rejected.  The patch fixes
that as well.

Finally, while testing the fix even more I realized that
the built-in considers the underlying array itself in ARRAY_REF
expressions rather than its type, which leads to inconsistent
results for overaligned arrays (it's the array itself that's
overaligned, not its elements).  So I fixed that too and
adjusted the one test designed to verify this.

Tested on x86_64-linux.

Martin

gcc-88383.diff

PR c/88383 - ICE calling __builtin_has_attribute on a reference

gcc/c-family/ChangeLog:

PR c/88383
* c-attribs.c (validate_attribute): Handle expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .

gcc/cp/ChangeLog:

PR c/88383
* parser.c (cp_parser_has_attribute_expression): Handle assignment
expressions.

gcc/testsuite/ChangeLog:

PR c/88383
* c-c++-common/builtin-has-attribute-4.c: Adjust expectations.
* c-c++-common/builtin-has-attribute-6.c: New test.

Well, the high level question here is do we want to support this builtin
on expressions at all.  Generally attributes apply to types and decls,
not expressions.

Clearly we shouldn't fault, but my first inclination is that the
attribute applies to types or decls, not expressions.  In that case we
should just be issuing an error.

I could be convinced otherwise, so if you think we should support
passing expressions to this builtin, make your case.


The support is necessary in order to determine the attributes
in expressions such as:

   struct S { __attribute__ ((packed)) int a[32]; };

   extern struct S s;

   _Static_assert (__builtin_has_attribute (s.a, packed));


An example involving types might be a better one:

   typedef __attribute__ ((may_alias)) int* BadInt;

   void f (BadInt *p)
   {
     _Static_assert (__builtin_has_attribute (*p, may_alias));
   }

Martin

Re: [patch,openacc] Fix PR71959: lto dump of callee counts

[Julian Brown]

On Tue, 25 Sep 2018 14:59:18 +0200
Martin Jambor  wrote:

> Hi,
> 
> I have noticed a few things...
> 
> On Thu, Sep 20 2018, Cesar Philippidis wrote:
> > This is another old gomp4 patch that demotes an ICE in PR71959 to a
> > linker warning. One problem here is that it is not clear if OpenACC
> > allows individual member functions in C++ classes to be marked as
> > acc routines. There's another issue accessing member data inside
> > offloaded regions. We'll add some support for member data OpenACC
> > 2.6, but some of the OpenACC C++ semantics are still unclear.
> >
> > Is this OK for trunk? I bootstrapped and regtested it for x86_64
> > Linux with nvptx offloading.
> [...]

The testcase associated with this bug appears to be fixed by the
following patch:

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

So, it's unclear if there's anything left to do here, and this patch
can probably be withdrawn.

Thanks,

Julian

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

[Martin Sebor]

The enhancement to detect mismatched attributes between function
aliases and their targets triggers (expected) warnings in GCC
builds due to aliases being declared with fewer attributes than
their targets.

Using attribute copy as recommended to copy the attributes from
the target to the alias triggers another warning, this time due
to applying attribute leaf to static functions (the attribute
only applies to extern functions).  This is due to an oversight
in both the handler for attribute copy and in
the -Wmissing-attributes warning.

In addition, the copy attribute handler doesn't account for C11
_Noreturn and C++ throw() specifications, both of which set
the corresponding tree bits but don't attach the synonymous
attribute to it.  This also leads to warnings in GCC builds
(in libgfortran).

The attached patch corrects all of these problems: the attribute
copy handler to avoid copying attribute leaf to declarations of
static functions, and to set the noreturn and nonthrow bits, and
the missing attribute warning to avoid triggering for static
weakref aliases whose targets are decorated wiwth attribute leaf.

With this patch, GCC should build with no -Wmissing-attributes
warnings.

Tested on x86_64-linux.

Martin
PR c/88546 - Copy attribute unusable for weakrefs

gcc/c-family/ChangeLog:

	PR c/88546
	* c-attribs.c (handle_copy_attribute): Avoid copying attribute leaf.

gcc/ChangeLog:

	PR c/88546
	* attribs.c (decls_mismatched_attributes): Avoid warning for attribute
	leaf.

libgcc/ChangeLog:

	PR c/88546
	* gthr-posix.h (__gthrw2): Use attribute copy.

libgfortran/ChangeLog:

	PR c/88546
	* libgfortran.h (iexport2): Use attribute copy.

gcc/testsuite/ChangeLog:

	PR c/88546
	* gcc.dg/attr-copy-6.c: New test.

Index: gcc/attribs.c
===
--- gcc/attribs.c	(revision 267282)
+++ gcc/attribs.c	(working copy)
@@ -1912,6 +1912,12 @@ decls_mismatched_attributes (tree tmpl, tree decl,
 
   for (unsigned i = 0; blacklist[i]; ++i)
 {
+  /* Attribute leaf only applies to extern functions.  Avoid mentioning
+	 it when it's missing from a static declaration.  */
+  if (!TREE_PUBLIC (decl)
+	  && !strcmp ("leaf", blacklist[i]))
+	continue;
+
   for (unsigned j = 0; j != 2; ++j)
 	{
 	  if (!has_attribute (tmpls[j], tmpl_attrs[j], blacklist[i]))
Index: gcc/c-family/c-attribs.c
===
--- gcc/c-family/c-attribs.c	(revision 267282)
+++ gcc/c-family/c-attribs.c	(working copy)
@@ -2455,6 +2455,12 @@ handle_copy_attribute (tree *node, tree name, tree
 	  || is_attribute_p ("weakref", atname))
 	continue;
 
+	  /* Aattribute leaf only applies to extern functions.
+	 Avoid copying it to static ones.  */
+	  if (!TREE_PUBLIC (decl)
+	  && is_attribute_p ("leaf", atname))
+	continue;
+
 	  tree atargs = TREE_VALUE (at);
 	  /* Create a copy of just the one attribute ar AT, including
 	 its argumentsm and add it to DECL.  */
Index: gcc/testsuite/gcc.dg/attr-copy-6.c
===
--- gcc/testsuite/gcc.dg/attr-copy-6.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/attr-copy-6.c	(working copy)
@@ -0,0 +1,68 @@
+/* PR middle-end/88546 - Copy attribute unusable for weakrefs
+   { dg-do compile }
+   { dg-options "-O2 -Wall" }
+   { dg-require-weak "" } */
+
+#define ATTR(...)   __attribute__ ((__VA_ARGS__))
+#define ASRT(expr)   _Static_assert (expr, #expr)
+
+/* Variable that is local to this translation unit but that can
+   be modified from other units by calling reset_unit_local().  */
+static int unit_local;
+
+void reset_unit_local (void)
+{
+  unit_local = 0;
+}
+
+/* Attribute leaf implies that fleaf() doesn't modify unit_local().  */
+ATTR (leaf, returns_nonnull)
+void* fleaf_retnz (void);
+
+/* Verify both attributes have been applied.  */
+ASRT (__builtin_has_attribute (fleaf_retnz, leaf));
+ASRT (__builtin_has_attribute (fleaf_retnz, returns_nonnull));
+
+/* Verify that attribute leaf has the expected effect.  */
+void call_fleaf_retnz (void)
+{
+  int i = unit_local;
+  void *p = fleaf_retnz ();
+
+  /* Expect both tests to be folded to false and the calls eliminated.  */
+  extern void call_fleaf_retnz_test_leaf_eliminated (void);
+  if (i != unit_local)
+call_fleaf_retnz_test_leaf_eliminated ();
+
+  extern void call_fleaf_retnz_test_nonnull_eliminated (void);
+  if (p == 0)
+call_fleaf_retnz_test_nonnull_eliminated ();
+}
+
+
+/* Verify that attribute copy copies the returns_nonnull attribute
+   but doesn't try to copy attribute leaf which only applies to extern
+   function.  */
+static ATTR (copy (fleaf_retnz), weakref ("fleaf_retnz"))
+void* fweakref_fleaf_retnz_copy (void);
+
+ASRT (!__builtin_has_attribute (fweakref_fleaf_retnz_copy, leaf));
+ASRT (__builtin_has_attribute (fweakref_fleaf_retnz_copy, returns_nonnull));
+
+void call_fweakref_fleaf_retnz_copy (void)
+{
+  int i = unit_local;
+  void *

Re: [RFC] support --with-multilib-list=@/path/name

[Alexandre Oliva]

On Dec  7, 2018, Alexandre Oliva  wrote:

> Any objections, further requests or advice, before I put it in and

FTR, I've just checked it in.

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Re: [PATCH] fortran/69121 -- Make IEEE_SCALB generic

[Steve Kargl]

On Thu, Dec 20, 2018 at 01:47:39PM -0800, Steve Kargl wrote:
> The attached patch has been tested on x86_64-*-freebsd.
> 
> OK to commit?
> 
> 2018-12-20  Steven G. Kargl  
> 
>   PR fortran/69121
>   * libgfortran/ieee/ieee_arithmetic.F90: Provide missing functions
>   in interface for IEEE_SCALB.
> 
> 2018-12-20  Steven G. Kargl  
> 
>   PR fortran/69121
>   * gfortran.dg/ieee/ieee_9.f90: New test.

Now, tested on i586-*-freebsd.

-- 
Steve

[PATCH v5][C][ADA] use function descriptors instead of trampolines in C

[Uecker, Martin]

Am Montag, den 17.12.2018, 10:28 -0700 schrieb Jeff Law:

> > But the alignment increase itself on 'i386' and 'aarch64'
> > might be unacceptable. In this case, the only safe change
> > is to make the higher alignment also depend on
> > "-fno-trampolines".  Would this be acceptable?
> 
> Unclear at this point.

Hi Jeff,

in any case, here is another revision of this patch for
consideration which implements just this.

The lang hook is not activated for C anymore which means
that this patch is a no-op when -fno-trampolines is not
given. So the test about achieving the minimum alignment on
i386 does not fail anymore. 

With -fno-trampolines the minimum alignment is increased
as needed on platforms which support descriptors. 
For C and Ada (where it is the default) function
descriptors are created instead of trampolines.

If -fno-trampolines is given on platforms which do not
support descriptors a warning is given (before the flag
was silently ignored.)

I also made the existing warnings about the ABI change
more visible (similar to -freg-struct-return or similar
flags). 

I consider the current behavior broken, where the flag
is a silent no-op for most languages and on some targets
while the documentation implies otherwise.

Bootstrapped and regression tested on x86.

I also tested -fno-trampolines on a project of mine which
uses nested functions and has a test suite and there it
works perfectly and removes the need for the executable stack.

Finally, this patch is a tiny and self-contained change which
could easily be reverted if there should be any unanticipated
failures.

Best,
Martin



diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4be16c15f86..8825d87b44f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,16 @@
+2018-12-20  Martin Uecker  
+
+   * common.opt (flag_trampolines): Change default.
+   * calls.c (prepare_call_address): Remove check for
+   flag_trampolines.  Decision is now made in FEs.
+   * defaults.h (FUNCTION_ALIGNMENT): Add test for flag_trampolines.
+   * tree-nested.c (convert_tramp_reference_op): Likewise.
+   * toplev.c (process_options): Add warning for -fno-trampolines on
+   unsupported targets.
+   * doc/invoke.texi (-fno-trampolines): Document support for C.
+   * doc/sourcebuild.texi (target attributes): Document new
+   "notrampolines" effective target keyword.
+
 2018-12-20  Vladimir Makarov  
 
    PR target/88457
diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog
index ba974cdcb03..c2f3d0db281 100644
--- a/gcc/ada/ChangeLog
+++ b/gcc/ada/ChangeLog
@@ -1,3 +1,8 @@
+2018-12-20  Martin Uecker  
+
+   * gcc-interface/trans.c (Attribute_to_gnu): Add check for
+   flag_trampolines.
+
 2018-12-14  Eric Botcazou  
 
    * gcc-interface/decl.c (rm_size): Take into account the padding in
diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-interface/trans.c
index 620dbd3d36d..ae4139e9b84 100644
--- a/gcc/ada/gcc-interface/trans.c
+++ b/gcc/ada/gcc-interface/trans.c
@@ -2239,7 +2239,8 @@ Attribute_to_gnu (Node_Id gnat_node, tree 
*gnu_result_type_p, int attribute)
      if ((attribute == Attr_Access
       || attribute == Attr_Unrestricted_Access)
      && targetm.calls.custom_function_descriptors > 0
-     && Can_Use_Internal_Rep (Etype (gnat_node)))
+     && Can_Use_Internal_Rep (Etype (gnat_node))
+  && flag_trampolines != 1)
    FUNC_ADDR_BY_DESCRIPTOR (gnu_expr) = 1;
 
      /* Otherwise, we need to check that we are not violating the
@@ -5050,7 +5051,8 @@ Call_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p, 
tree gnu_target,
   /* If the access type doesn't require foreign-compatible representation,
     be prepared for descriptors.  */
   if (targetm.calls.custom_function_descriptors > 0
-     && Can_Use_Internal_Rep (Etype (Prefix (Name (gnat_node)
+     && Can_Use_Internal_Rep (Etype (Prefix (Name (gnat_node
+  && flag_trampolines != 1)
    by_descriptor = true;
 }
   else if (Nkind (Name (gnat_node)) == N_Attribute_Reference)
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index 6e12dda2331..71443846799 100644
--- a/gcc/c/ChangeLog
+++ b/gcc/c/ChangeLog
@@ -1,3 +1,9 @@
+2018-12-20  Martin Uecker  
+
+   * c-typeck.c (function_to_pointer_conversion): If using descriptors
+   instead of trampolines, amend function address with
+   FUNC_ADDR_BY_DESCRIPTOR and calls with ALL_EXPR_BY_DESCRIPTOR.
+
 2018-12-19  Segher Boessenkool  
 
    * c-parser.c (c_parser_asm_statement) : Give
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 1ae5ede81e6..6363dfda3b8 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -1913,7 +1913,14 @@ function_to_pointer_conversion (location_t loc, tree exp)
   if (TREE_NO_WARNING (orig_exp))
 TREE_NO_WARNING (exp) = 1;
 
-  return build_unary_op (loc, ADDR_EXPR, exp, false);
+  tree r = build_unary_op (loc, ADDR_EXPR, ex