Re: [PATCH 1/7] C-SKY: Add fpuv3 instructions and CK860 arch

[Cooper Qu via Gcc-patches]

Hi gengqi,

I could not find the patchs [3/7], [4/7] and [7/7]. Could you check the 
emails and send them again ?



On 10/29/20 9:22 PM, gengqi via Gcc-patches wrote:

gcc/ChangeLog:

* config/csky/constraints.md ("W"): New constriant for mem operand
with base reg, index register.
("Q"): Renamed and modified "csky_valid_fpuv2_mem_operand" to
"csky_valid_mem_constraint_operand" to deal with both "Q" and "W"
constraint.
("Dv"): New constraint for const double value that can be used at
fmovi instruction.
* config/csky/csky-modes.def (HFmode): New mode.
* config/csky/csky-protos.h (csky_valid_fpuv2_mem_operand): Rename
to "csky_valid_mem_constraint_operand" and new support for constraint
"W".
(get_output_csky_movedouble_length): New.
(fpuv3_output_move): New.
(fpuv3_const_double): New.
* config/csky/csky.c (csky_option_override): New arch CK860 with fpv3.
(decompose_csky_address): Robustness adjust.
(csky_print_operand): New "CONST_DOUBLE" operand.
(csky_output_move): New support for fpv3 instructions.
(get_output_csky_movedouble_length): New.
(fpuv3_output_move): New.
(fpuv3_const_double): New.
(csky_emit_compare): New cover for float comparsion.
(csky_emit_compare_float): Refine.
(csky_vaild_fpuv2_mem_operand): Rename to
"csky_valid_mem_constraint_operand" and new support for constraint "W".
(ck860_rtx_costs): New.
(csky_rtx_costs): New subcall for CK860.
(regno_reg_class): New vregs for fpuv3.
(csky_dbx_regno): Likewise.
(csky_cpu_cpp_builtins): New builtin macro for fpuv3.
(csky_conditional_register_usage): New suporrot for fpuv3.
(csky_dwarf_register_span): New suporrot for fpuv3.
(csky_init_builtins, csky_mangle_type): New support for "__fp16" type.
(ck810_legitimate_index_p): New support for fp16.
* gcc/config/csky/csky.h (TARGET_TLS): ADD CK860.
(CSKY_VREG_P, CSKY_VREG_LO_P, CSKY_VREG_HI_P): New support for fpuv3.
(TARGET_SINGLE_FPU): New support for fpuv3.
(TARGET_SUPPORT_FPV3): New macro.
(FIRST_PSEUDO_REGISTER): Value change, since the new fpuv3 regs.
(FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS, REGISTER_NAMES,
 REG_CLASS_CONTENTS): Support for fpuv3.
* gcc/config/csky/csky.md (movsf): Move to cksy_insn_fpu.md and adjust.
(csky_movsf_fpv2): Likewise.
(ck801_movsf): Likewise.
(csky_movsf): Likewise.
(movdf): Likewise.
(csky_movdf_fpv2): Likewise.
(ck801_movdf): Likewise.
(csky_movdf): Likewise.
(movsicc): Refine. Use "comparison_operatior" instead of
"ordered_comparison_operatior".
(addsicc): Likewise.
(CSKY_FIRST_VFP3_REGNUM, CSKY_LAST_VFP3_REGNUM): New constant.
(call_value_internal_vh): New insn.
* config/csky/csky_cores.def (CK860): New arch and cpu.
(fpv3): New 4 fpus: fpv3_hf, fpv3_hsf, fpv3_sdf and fpv3.
* config/csky/csky_insn_fpu.md (mov): Move the float mov
patterns from csky.md here.
(fpuv2 instructions): Refactor. Separate all float patterns into
emit-patterns and match-patterns, remain the emit-patterns here, and
move the match-patterns to csky_insn_fpuv2.md.
(fpuv3 instructions): Add patterns and fuse part of them with the
fpuv2's.
* config/csky/csky_insn_fpuv2.md: New file for fpuv2 instructions.
* config/csky/csky_insn_fpuv3.md: New flie and new patterns for fpuv3
isntructions.
* config/csky/csky_isa.def (fcr): New.
(fpv3): New 4 isa sets: fpv3_hi, fpv3_hf, fpv3_sf and fpv3_df.
(CK860): New definition for ck860.
* gcc/config/csky/csky_tables.opt (ck860): New processors ck860,
ck860f. And new arch ck860.
(fpv3): New 4 fpus: fpv3_hf, fpv3_hsf, fpv3_sdf and fpv3.
* config/csky/predicates.md (csky_float_comparsion_operator): Delete
"geu", "gtu", "leu", "ltu", which will never appear at float comparison.
* config/cksy/t-csky-elf, config/csky/t-csky-linux: New for ck860.
* doc/md.texi: Add "Q" and "W" constraints for C-SKY.
---
  gcc/config/csky/constraints.md |  13 +-
  gcc/config/csky/csky-modes.def |   2 +
  gcc/config/csky/csky-protos.h  |   7 +-
  gcc/config/csky/csky.c | 650 ++
  gcc/config/csky/csky.h | 162 ++--
  gcc/config/csky/csky.md| 127 ++
  gcc/config/csky/csky_cores.def |  13 +
  gcc/config/csky/csky_insn_fpu.md   | 798 +++--
  gcc/config/csky/csky_insn_fpuv2.md | 470 ++
  gcc/config/csky/csky_insn_fpuv3.md | 506 +++
  gcc/config/csky/csky_isa.def   |  15 +
  gcc/config/csky/csky_tables.opt|  21 +
  

[r11-4516 Regression] FAIL: gcc.dg/vect/bb-slp-pr65935.c scan-tree-dump-times slp1 "Using a splat" 1 on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

1e1e1edf88a7c40ae4ae0de9e6077179e13ccf6d is the first bad commit
commit 1e1e1edf88a7c40ae4ae0de9e6077179e13ccf6d
Author: Richard Biener 
Date:   Thu Oct 29 08:48:15 2020 +0100

More BB vectorization tweaks

caused

FAIL: gcc.dg/vect/bb-slp-pr65935.c -flto -ffat-lto-objects  
scan-tree-dump-times slp1 "Using a splat" 1
FAIL: gcc.dg/vect/bb-slp-pr65935.c scan-tree-dump-times slp1 "Using a splat" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-4516/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-pr65935.c --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-pr65935.c --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

[Marek Polacek via Gcc-patches]

On Thu, Oct 29, 2020 at 02:25:33PM -0400, Jason Merrill via Gcc-patches wrote:
> On 10/29/20 2:11 PM, Marek Polacek wrote:
> > On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches 
> > wrote:
> > > On 10/28/20 7:40 PM, Marek Polacek wrote:
> > > > On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote:
> > > > > On 10/28/20 1:58 PM, Marek Polacek wrote:
> > > > > > On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via 
> > > > > > Gcc-patches wrote:
> > > > > > > On 10/24/20 7:40 PM, Marek Polacek wrote:
> > > > > > > > On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason Merrill via 
> > > > > > > > Gcc-patches wrote:
> > > > > > > > > On 10/23/20 3:01 PM, Marek Polacek wrote:
> > > > > > > > > > This patch implements the -Wvexing-parse warning to warn 
> > > > > > > > > > about the
> > > > > > > > > > sneaky most vexing parse rule in C++: the cases when a 
> > > > > > > > > > declaration
> > > > > > > > > > looks like a variable definition, but the C++ language 
> > > > > > > > > > requires it
> > > > > > > > > > to be interpreted as a function declaration.  This warning 
> > > > > > > > > > is on by
> > > > > > > > > > default (like clang++).  From the docs:
> > > > > > > > > > 
> > > > > > > > > >void f(double a) {
> > > > > > > > > >  int i();// extern int i (void);
> > > > > > > > > >  int n(int(a));  // extern int n (int);
> > > > > > > > > >}
> > > > > > > > > > 
> > > > > > > > > >Another example:
> > > > > > > > > > 
> > > > > > > > > >struct S { S(int); };
> > > > > > > > > >void f(double a) {
> > > > > > > > > >  S x(int(a));   // extern struct S x (int);
> > > > > > > > > >  S y(int());// extern struct S y (int (*) 
> > > > > > > > > > (void));
> > > > > > > > > >  S z(); // extern struct S z (void);
> > > > > > > > > >}
> > > > > > > > > > 
> > > > > > > > > > You can find more on this in [dcl.ambig.res].
> > > > > > > > > > 
> > > > > > > > > > I spent a fair amount of time on fix-it hints so that GCC 
> > > > > > > > > > can recommend
> > > > > > > > > > various ways to resolve such an ambiguity.  Sometimes 
> > > > > > > > > > that's tricky.
> > > > > > > > > > E.g., suggesting default-initialization when the class 
> > > > > > > > > > doesn't have
> > > > > > > > > > a default constructor would not be optimal.  Suggesting 
> > > > > > > > > > {}-init is also
> > > > > > > > > > not trivial because it can use an initializer-list 
> > > > > > > > > > constructor if no
> > > > > > > > > > default constructor is available (which ()-init wouldn't 
> > > > > > > > > > do).  And of
> > > > > > > > > > course, pre-C++11, we shouldn't be recommending {}-init at 
> > > > > > > > > > all.
> > > > > > > > > 
> > > > > > > > > What do you think of, instead of passing the type down into 
> > > > > > > > > the declarator
> > > > > > > > > parse, adding the paren locations to cp_declarator::function 
> > > > > > > > > and giving the
> > > > > > > > > diagnostic from cp_parser_init_declarator instead?
> > > > > > > 
> > > > > > > Oops, now I see there's already cp_declarator::parenthesized; 
> > > > > > > might as well
> > > > > > > reuse that.  And maybe change it to a range, while we're at it.
> > > > > > 
> > > > > > I'm afraid I can't reuse it because grokdeclarator uses it to warn 
> > > > > > about
> > > > > > "unnecessary parentheses in declaration".  So when we have:
> > > > > > 
> > > > > >  int (x());
> > > > > > 
> > > > > > declarator->parenthesized points to the outer parens (if any), 
> > > > > > whereas
> > > > > > declarator->u.function.parens_loc should point to the inner ones.  
> > > > > > We also
> > > > > > have declarator->id_loc but I think we should only use it for 
> > > > > > declarator-ids.
> > > > > 
> > > > > Makes sense.
> > > > > 
> > > > > > (We should still adjust ->parenthesized to be a range to generate a 
> > > > > > better
> > > > > > diagnostic; I shall send a patch soon.)
> > > > > > 
> > > > > > > Hmm, I wonder why we have the parenthesized_p parameter to some 
> > > > > > > of these
> > > > > > > functions, since we can look at the declarator to find that 
> > > > > > > information...
> > > > > > 
> > > > > > That would be a nice cleanup.
> > > > > > 
> > > > > > > > Interesting idea.  I suppose it's better, and makes the 
> > > > > > > > implementation
> > > > > > > > more localized.  The approach here is that if the 
> > > > > > > > .function.parens_loc
> > > > > > > > is UNKNOWN_LOCATION, we've not seen a vexing parse.
> > > > > > > 
> > > > > > > I'd rather always set the parens location, and then analyze the
> > > > > > > cp_declarator in warn_about_ambiguous_parse to see if it's a 
> > > > > > > vexing parse;
> > > > > > > we should have all the information we need.
> > > > > > 
> > > > > > I could always set .parens_loc, but then I'd still need another 
> > > > > > flag telling
> > > > > > me whether we had an ambiguity. 

[PATCH] [tree-optimization] Fix for PR96701

[Eugene Rozenfeld via Gcc-patches]

This patch adds a pattern for folding 
x >> x
to
  0
as described in PR96701.

Without this patch the x86_64-pc-linux-gnu code generated for this function

int
foo (int i)
{
  return i >> i;
}

is

mov    ecx,edi
sar    edi,cl
test   edi,edi
setne  al
ret

With the patch the code is 

xor    eax,eax
ret  

Tested on x86_64-pc-linux-gnu.

Eugene


0001-Optimize-self-right-shift-to-0.patch
Description: 0001-Optimize-self-right-shift-to-0.patch

[PATCH] c++: Tweaks for value_dependent_expression_p.

[Marek Polacek via Gcc-patches]

We may not call value_dependent_expression_p on expressions that are
not potential constant expressions, otherwise value_d could crash,
as I saw recently (in C++98).  So beef up the checking in i_d_e_p.

This revealed a curious issue: when we have __PRETTY_FUNCTION__ in
a template function, we set its DECL_VALUE_EXPR to error_mark_node
(cp_make_fname_decl), so potential_c_e returns false when it gets it,
but value_dependent_expression_p handles it specially and says true.
This broke lambda-generic-pretty1.C.  So take care of that.

And then also tweak uses_template_parms.

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

gcc/cp/ChangeLog:

* constexpr.c (potential_constant_expression_1): Treat
__PRETTY_FUNCTION__ inside a template function as
potentially-constant.
* pt.c (uses_template_parms): Call
instantiation_dependent_expression_p instead of
value_dependent_expression_p.
(instantiation_dependent_expression_p): Check
potential_constant_expression before calling
value_dependent_expression_p.
---
 gcc/cp/constexpr.c | 5 +
 gcc/cp/pt.c| 5 +++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index b46824f128d..c257dfcb2e6 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -7716,6 +7716,11 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
}
  return false;
}
+ /* Treat __PRETTY_FUNCTION__ inside a template function as
+potentially-constant.  */
+ else if (DECL_PRETTY_FUNCTION_P (t)
+  && DECL_VALUE_EXPR (t) == error_mark_node)
+   return true;
  return RECUR (DECL_VALUE_EXPR (t), rval);
}
   if (want_rval
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b569644514c..c419fb470ee 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10755,7 +10755,7 @@ uses_template_parms (tree t)
   else if (t == error_mark_node)
 dependent_p = false;
   else
-dependent_p = value_dependent_expression_p (t);
+dependent_p = instantiation_dependent_expression_p (t);
 
   processing_template_decl = saved_processing_template_decl;
 
@@ -27293,7 +27293,8 @@ bool
 instantiation_dependent_expression_p (tree expression)
 {
   return (instantiation_dependent_uneval_expression_p (expression)
- || value_dependent_expression_p (expression));
+ || (potential_constant_expression (expression)
+ && value_dependent_expression_p (expression)));
 }
 
 /* Like type_dependent_expression_p, but it also works while not processing

base-commit: 4f0606fe4bbf1346f83dd4d0c9060c6b46672a7d
-- 
2.28.0

[PATCH] c++: Disable -Winit-list-lifetime in unevaluated operand [PR97632]

[Marek Polacek via Gcc-patches]

Jon suggested turning this warning off when we're not actually
evaluating the operand.  This patch does that.

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

gcc/cp/ChangeLog:

PR c++/97632
* init.c (build_new_1): Disable -Winit-list-lifetime for an unevaluated
operand.

gcc/testsuite/ChangeLog:

PR c++/97632
* g++.dg/warn/Winit-list4.C: New test.
---
 gcc/cp/init.c   |  2 +-
 gcc/testsuite/g++.dg/warn/Winit-list4.C | 15 +++
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Winit-list4.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 1bddb6555dc..ffb84ea5b09 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2957,7 +2957,7 @@ build_new_1 (vec **placement, tree type, 
tree nelts,
   return error_mark_node;
 }
 
-  if (is_std_init_list (elt_type))
+  if (is_std_init_list (elt_type) && !cp_unevaluated_operand)
 warning (OPT_Winit_list_lifetime,
 "% of % does not "
 "extend the lifetime of the underlying array");
diff --git a/gcc/testsuite/g++.dg/warn/Winit-list4.C 
b/gcc/testsuite/g++.dg/warn/Winit-list4.C
new file mode 100644
index 000..d136187e2c6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Winit-list4.C
@@ -0,0 +1,15 @@
+// PR c++/97632
+// { dg-do compile { target c++20 } }
+// Test we don't warn in an unevaluated operand.
+
+#include 
+
+template
+concept default_initializable
+  = requires
+{
+  _Tp{};
+  (void) ::new _Tp; // { dg-bogus "does not extend the lifetime" }
+};
+
+static_assert(default_initializable>);

base-commit: dec1eb4c276f1b3c003154c159b539eb7110a13f
-- 
2.28.0

[PATCH] [tree-optimization] Fix for PR96701

[Eugene Rozenfeld via Gcc-patches]

This patch adds a pattern for folding

x >> x

to

  0

as described in PR96701.


Without this patch the x86_64-pc-linux-gnu code generated for this function



int

foo (int i)

{

  return i >> i;

}



is



movecx,edi

saredi,cl

test   edi,edi

setne  al

ret



With the patch the code is


xoreax,eax
ret


Tested on x86_64-pc-linux-gnu.

Eugene


0001-Optimize-self-right-shift-to-0.patch
Description: 0001-Optimize-self-right-shift-to-0.patch

Re: PowerPC: Update __float128 and __ibm128 error messages.

[Michael Meissner via Gcc-patches]

On Thu, Oct 29, 2020 at 02:18:58PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 29, 2020 at 01:03:25PM -0400, Michael Meissner wrote:
> > On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote:
> > > > +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> > > 
> > > Use *-*-linux* instead?  (In all relevant tests.)
> > 
> > Ok.
> > 
> > > Is there any reason these tests should only run on Linux?  If not, it
> > > should not restrict itself like this; and if so, you may want another
> > > selsector (something ieee128 perhaps), or at the very least add a
> > > comment why you do this.
> > 
> > Right now the float128 emulation is only built on Linux, because it needs 
> > the
> > support in GLIBC.  If/when other systems add support for float128 in there
> > C/C++ libraries, we can widen the tests.
> 
> It still helps to use some new selector -- you only have to change the
> implementation of that when such a day will come, instead of 34638
> separate testcases.  Also, it is good documentation, helping every
> reader (people trying to make sense if the tests, for example).

This is the patch that I commited, combining this patch with the patch to allow
users with GLIBC 2.32 or newer to not get warnings if they change the long
double type.

Note, it turns out the patch submitted previously had other changes to the
tests for the new power10 instructions (scalar-extract-exp-4,
scalar-extract-sig-4, scalar-test-data-class-11, and scalar-test-neg-5).  Those
patches will be part of the re-implementation of those built-in functions.

I did remove the line from float128-mix*.c:
{ dg-do compile { target { powerpc*-*-linux* } } }

and I added:
{ dg-require-effective-target ppc_float128_sw }

To more properly check whether we can do float128.

Subject: [PATCH] PowerPC: Adjust float128/ibm128 warnings.

This patch ccombines two patches:

1) If GLIBC is 2.32 or newer, and the language is C or C++, allow the user to
   change the long double type without having to use -Wno-psabi.

2) Adjust the warnings for intermixing __float128 and __ibm128 to accomidate
   the future change to allow long double to use the IEEE 128-bit format.

gcc/
2020-10-29  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_option_override_internal): Allow
long double type to be changed for C/C++ if glibc 2.32 or newer.
(rs6000_invalid_binary_op): Update error messages about mixing IBM
long double and IEEE 128-bit.

gcc/testsuite/
2020-10-27  Michael Meissner  

* gcc.target/powerpc/float128-mix-2.c: New test.
* gcc.target/powerpc/float128-mix-3.c: New test.
* gcc.target/powerpc/float128-mix.c: Update failure messages.
---
 gcc/config/rs6000/rs6000.c| 29 ---
 .../gcc.target/powerpc/float128-mix-2.c   | 16 ++
 .../gcc.target/powerpc/float128-mix-3.c   | 16 ++
 .../gcc.target/powerpc/float128-mix.c | 20 +++--
 4 files changed, 55 insertions(+), 26 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-mix-2.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-mix-3.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 4d528a39a37..bcd4c4a82b3 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4158,8 +4158,15 @@ rs6000_option_override_internal (bool global_init_p)
 
   if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT && TARGET_LONG_DOUBLE_128)
{
+ /* Determine if the user can change the default long double type at
+compilation time.  Only C and C++ support this, and you need GLIBC
+2.32 or newer.  Only issue one warning.  */
  static bool warned_change_long_double;
- if (!warned_change_long_double)
+
+ if (!warned_change_long_double
+ && (!OPTION_GLIBC
+ || (!lang_GNU_C () && !lang_GNU_CXX ())
+ || ((TARGET_GLIBC_MAJOR * 1000) + TARGET_GLIBC_MINOR) < 2032))
{
  warned_change_long_double = true;
  if (TARGET_IEEEQUAD)
@@ -14392,22 +14399,10 @@ rs6000_invalid_binary_op (int op ATTRIBUTE_UNUSED,
 
   if (!TARGET_FLOAT128_CVT)
 {
-  if ((mode1 == KFmode && mode2 == IFmode)
- || (mode1 == IFmode && mode2 == KFmode))
-   return N_("__float128 and __ibm128 cannot be used in the same "
- "expression");
-
-  if (TARGET_IEEEQUAD
- && ((mode1 == IFmode && mode2 == TFmode)
- || (mode1 == TFmode && mode2 == IFmode)))
-   return N_("__ibm128 and long double cannot be used in the same "
- "expression");
-
-  if (!TARGET_IEEEQUAD
- && ((mode1 == KFmode && mode2 == TFmode)
- || (mode1 == TFmode && mode2 == KFmode)))
-   return N_("__float128 and long double cannot be used in the same "
- "expression");
+  if ((FLOAT128_IEEE_P (mode1) && FLOAT128_IBM_P 

[PATCH 1/5] [PR target/96342] Change field "simdlen" into poly_uint64

[yangyang (ET)]

Hi,

This is the first patch for PR96698.

In order to support the generating of SVE functions for "omp declare 
simd", this patch changes the type of the field "simdlen" of struct 
cgraph_simd_clone from unsigned int to poly_uint64.

Although Richard mentioned in the PR that poly_uint64 will naturally 
decay to a uint64_t in i386 target files, it seems that operation /= is not 
supported yet, so I change "clonei->simdlen /= GET_MODE_BITSIZE (TYPE_MODE 
(base_type));" into "clonei->simdlen = clonei->simdlen / GET_MODE_BITSIZE 
(TYPE_MODE (base_type));". Also calls of to_constant () is added in printf to 
pass the bootstrap. However, I have no idea whether these are the best ways to 
do so, any suggestion?

Richard also suggested to define a new macro to calculate a vector multiple 
instead of using constant_multiple_p in part2 patch, while I found that there 
are similar situations in part1 patch as well, so I do this in part1 patch. I 
didn't think of a better name, so I use "vector_unroll_factor".

Bootstrap and tested on both aarch64 and x86 Linux platform, no new 
regression witnessed.

Ok for trunk?

Thanks,
Yang Yang


PR96342-part1-v1.patch
Description: PR96342-part1-v1.patch

[PATCH] AIX xfail for_overwrite.cc libstdc++ testcase

[David Edelsohn via Gcc-patches]

The 20_util/unique_ptr/creation/for_overwrite.cc test relies on
operator new, which requires special features on AIX.  This patch
disables the testcase.

Thanks, David

--- a/libstdc++-v3/testsuite/20_util/unique_ptr/creation/for_overwrite.cc
+++ b/libstdc++-v3/testsuite/20_util/unique_ptr/creation/for_overwrite.cc
@@ -1,5 +1,6 @@
 // { dg-options "-std=gnu++20" }
 // { dg-do run { target c++2a } }
+// { dg-xfail-run-if "AIX operator new" { powerpc-ibm-aix* } }

 // Copyright (C) 2020 Free Software Foundation, Inc.
 //

Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding

[JeanHeyd Meneide via Gcc-patches]

(Very very gentle ping, just to make sure it's still on anyone's radar...!)

On Fri, Oct 9, 2020 at 8:39 AM JeanHeyd Meneide  wrote:
>
> Hello,
>
> > Typo:  comple-time
> >
> > >2020-10-08  JeanHeyd "ThePhD" Meneide  
> > >
> > >* gcc/c-family/c-cppbuiltin.c: Add predefined macro
> > >definitions for charsets
> >
> > I think you should put the macro names in braces after the filename and 
> > drop the trailing "for charsets".
>
>  Can do!
>
> >
> > >* gcc/doc/cpp.texi: Document new predefined macro.
> > >* gcc/testsuite/c-c++-common/cpp/wide-narrow-predef-macros.c (new):
> >
> > I think you should drop "(new)" above.
> > thanks,
>
>  I saw that in previous changelogs, but I can change it! Fixed up
> the typos, too.
>
> Sincerely,
> JeanHeyd
>
> 2020-10-09  JeanHeyd "ThePhD" Meneide  
>
> * gcc/c-family/c-cppbuiltin.c: Add predefined
>   {__GNUC_EXECUTION_CHARSET_NAME} and
>   {__GNUC_WIDE_EXECUTION_CHARSET_NAME} macros
> * gcc/doc/cpp.texi: Document above new predefined macros
> * gcc/testsuite/c-c++-common/cpp/wide-narrow-predef-macros.c:
>   New test for macro definitions to always exist and be strings
> * libcpp/include/cpplib.h: Add functions declarations for
>   retrieving charset names
> * libcpp/directives.c: Add function definitions to retrieve charset
>   names
> * libcpp/internal.h: Add to/from name preservations

[PATCH][middle-end][i386][version 6]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

[Qing Zhao via Gcc-patches]

Hi, 

This is the 6th version of the implementation of patch -fzero-call-used-regs.

The X86 part is exactly the same as 5th version. (And it has been approved by 
Uros already).

The major change compared to the previous version (5th version) are:

1. Documentation change per Richard’s suggestion;
2. Other minor changes. 
3.  general testing cases update per Richard’s suggestion;


I have tested this new GCC on both x86 and arm64, no regression. 

Richard, Please let me know whether it’s ready for stage 1 gcc11?

thanks.

Qing

In order to make it easier for you to review the change, I list the changes I 
added compared to the 5th version first, and then the whole patch followed.

*The patch compared to 5th version:

From 3545cc92b327e11af0dde832a60161da92cc4262 Mon Sep 17 00:00:00 2001
From: qing zhao 
Date: Thu, 29 Oct 2020 18:40:27 +0100
Subject: [PATCH] fix all issues raised by Richard on 10/29

---
 gcc/c-family/c-attribs.c   |  8 +-
 gcc/common.opt |  2 +-
 gcc/doc/extend.texi| 72 -
 gcc/doc/invoke.texi|  6 +-
 gcc/emit-rtl.h |  3 -
 gcc/flag-types.h   |  2 +-
 gcc/function.c | 56 +++---
 gcc/opts.c |  2 +-
 gcc/targhooks.c|  2 +-
 gcc/testsuite/c-c++-common/zero-scratch-regs-11.c  | 90 +-
 gcc/testsuite/c-c++-common/zero-scratch-regs-2.c   | 13 +---
 gcc/testsuite/c-c++-common/zero-scratch-regs-3.c   | 13 +---
 gcc/testsuite/c-c++-common/zero-scratch-regs-4.c   | 13 +---
 gcc/testsuite/c-c++-common/zero-scratch-regs-5.c   | 13 +---
 gcc/testsuite/c-c++-common/zero-scratch-regs-6.c   | 13 +---
 gcc/testsuite/c-c++-common/zero-scratch-regs-7.c   | 13 +---
 gcc/testsuite/c-c++-common/zero-scratch-regs-8.c   | 13 +---
 gcc/testsuite/c-c++-common/zero-scratch-regs-9.c   | 13 +---
 .../c-c++-common/zero-scratch-regs-attr-usages.c   | 10 ++-
 19 files changed, 90 insertions(+), 267 deletions(-)

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 1b05e8c..8da1dc7 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -4979,13 +4979,15 @@ handle_zero_call_used_regs_attribute (tree *node, tree 
name, tree args,
   error_at (DECL_SOURCE_LOCATION (decl),
"%qE attribute applies only to functions", name);
   *no_add_attrs = true;
+  return NULL_TREE;
 }
 
   if (TREE_CODE (id) != STRING_CST)
 {
   error_at (DECL_SOURCE_LOCATION (decl),
-   "attribute %qE arguments not a string", name);
+   "%qE argument not a string", name);
   *no_add_attrs = true;
+  return NULL_TREE;
 }
 
   bool found = false;
@@ -5000,8 +5002,8 @@ handle_zero_call_used_regs_attribute (tree *node, tree 
name, tree args,
   if (!found)
 {
   error_at (DECL_SOURCE_LOCATION (decl),
-   "unrecognized zero_call_used_regs attribute: %qs",
-   TREE_STRING_POINTER (id));
+   "unrecognized %qE attribute argument %qs",
+   name, TREE_STRING_POINTER (id));
   *no_add_attrs = true;
 }
 
diff --git a/gcc/common.opt b/gcc/common.opt
index 4a13f32..d716ea1 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -228,7 +228,7 @@ unsigned int flag_sanitize_coverage
 Variable
 bool dump_base_name_prefixed = false
 
-; What subset of registers should be zeroed
+; What subset of registers should be zeroed on function return
 Variable
 unsigned int flag_zero_call_used_regs
 
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b011c17..25b3909 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3996,22 +3996,19 @@ with a named @code{target} must be @code{static}.
 @cindex @code{zero_call_used_regs} function attribute
 
 The @code{zero_call_used_regs} attribute causes the compiler to zero
-a subset of all call-used registers at function return according to
-@var{choice}.
-This is used to increase the program security by either mitigating
-Return-Oriented Programming (ROP) or preventing information leak
+a subset of all call-used registers@footnote{A ``call-used'' register
+is a register whose contents can be changed by a function call;
+therefore, a caller cannot assume that the register has the same contents
+on return from the function as it had before calling the function.  Such
+registers are also called ``call-clobbered'', ``caller-saved'', or
+``volatile''.} at function return.
+This is used to increase program security by either mitigating
+Return-Oriented Programming (ROP) attacks or preventing information leakage
 through registers.
 
-A ``call-used'' register is a register whose contents can be changed by
-a function call; therefore, a caller cannot assume that the register has
-the same contents on return from the 

Re: [PATCH] libstdc++: Fix the default constructor of ranges::__detail::__box

[Patrick Palka via Gcc-patches]

On Thu, 29 Oct 2020, Patrick Palka wrote:

> The class template semiregular-box of [range.semi.wrap] is specified
> to value-initialize the underlying object whenever its type is default-
> initializable.  Our primary template for __detail::__box respects this
> requirement, but the recently added partial specialization (for types
> which are already semiregular) does not.
> 
> This patch fixes this issue, and additionally makes the in place
> constructor explicit (as in the primary template).
> 
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> 
> libstdc++-v3/ChangeLog:
> 
>   * include/std/ranges (__detail::__box): For the partial
>   specialization for types that are already semiregular,
>   make the default constructor value-initialize the underlying
>   object instead of default-initializing it.  Make the
>   corresponding in place constructor explicit.
>   * testsuite/std/ranges/detail/semiregular_box.cc: New test.
> ---
>  libstdc++-v3/include/std/ranges   |  4 +--
>  .../std/ranges/detail/semiregular_box.cc  | 33 +++
>  2 files changed, 35 insertions(+), 2 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc
> 
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index df02b03cada..59aac326309 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -141,7 +141,7 @@ namespace ranges
>struct __box<_Tp>
>{
>private:
> - [[no_unique_address]] _Tp _M_value;
> + [[no_unique_address]] _Tp _M_value = {};

It would be more consistent with the rest of the header to do = _Tp()
instead:

Tested on x86_64-pc-linux-gnu.

-- >8 --

---
 libstdc++-v3/include/std/ranges   |  4 +--
 .../std/ranges/detail/semiregular_box.cc  | 33 +++
 2 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index df02b03cada..579280d16fb 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -141,7 +141,7 @@ namespace ranges
   struct __box<_Tp>
   {
   private:
-   [[no_unique_address]] _Tp _M_value;
+   [[no_unique_address]] _Tp _M_value = _Tp();
 
   public:
__box() = default;
@@ -160,7 +160,7 @@ namespace ranges
 
template
  requires constructible_from<_Tp, _Args...>
- constexpr
+ constexpr explicit
  __box(in_place_t, _Args&&... __args)
  noexcept(is_nothrow_constructible_v<_Tp, _Args...>)
  : _M_value{std::forward<_Args>(__args)...}
diff --git a/libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc 
b/libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc
new file mode 100644
index 000..2a909d6ae50
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc
@@ -0,0 +1,33 @@
+// Copyright (C) 2020 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++2a" }
+// { dg-do compile { target c++2a } }
+
+#include 
+
+using std::ranges::__detail::__box;
+
+constexpr bool
+test01()
+{
+  // Verify the default constructor value-initializes the underlying object.
+  __box x;
+  __glibcxx_assert(*x == 0);
+  return true;
+}
+static_assert(test01());
-- 
2.29.0.rc0

[PATCH] libstdc++: Fix the default constructor of ranges::__detail::__box

[Patrick Palka via Gcc-patches]

The class template semiregular-box of [range.semi.wrap] is specified
to value-initialize the underlying object whenever its type is default-
initializable.  Our primary template for __detail::__box respects this
requirement, but the recently added partial specialization (for types
which are already semiregular) does not.

This patch fixes this issue, and additionally makes the in place
constructor explicit (as in the primary template).

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::__box): For the partial
specialization for types that are already semiregular,
make the default constructor value-initialize the underlying
object instead of default-initializing it.  Make the
corresponding in place constructor explicit.
* testsuite/std/ranges/detail/semiregular_box.cc: New test.
---
 libstdc++-v3/include/std/ranges   |  4 +--
 .../std/ranges/detail/semiregular_box.cc  | 33 +++
 2 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index df02b03cada..59aac326309 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -141,7 +141,7 @@ namespace ranges
   struct __box<_Tp>
   {
   private:
-   [[no_unique_address]] _Tp _M_value;
+   [[no_unique_address]] _Tp _M_value = {};
 
   public:
__box() = default;
@@ -160,7 +160,7 @@ namespace ranges
 
template
  requires constructible_from<_Tp, _Args...>
- constexpr
+ constexpr explicit
  __box(in_place_t, _Args&&... __args)
  noexcept(is_nothrow_constructible_v<_Tp, _Args...>)
  : _M_value{std::forward<_Args>(__args)...}
diff --git a/libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc 
b/libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc
new file mode 100644
index 000..2a909d6ae50
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/detail/semiregular_box.cc
@@ -0,0 +1,33 @@
+// Copyright (C) 2020 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++2a" }
+// { dg-do compile { target c++2a } }
+
+#include 
+
+using std::ranges::__detail::__box;
+
+constexpr bool
+test01()
+{
+  // Verify the default constructor value-initializes the underlying object.
+  __box x;
+  __glibcxx_assert(*x == 0);
+  return true;
+}
+static_assert(test01());
-- 
2.29.0.rc0

[committed] libstdc++: Avoid narrowing conversion in subrange constructor

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* include/bits/ranges_util.h (subrange::subrange(R&&)): Use
direct-initialization instead of list-initialization, so a
potential narrowing conversion from ranges::size(r) to the
stored size isn't ill-formed.

Tested powerpc64le-linux. Committed to trunk.

commit a55cda891d69b5a238d2e237903829995ca7249c
Author: Jonathan Wakely 
Date:   Thu Oct 29 22:47:22 2020

libstdc++: Avoid narrowing conversion in subrange constructor

libstdc++-v3/ChangeLog:

* include/bits/ranges_util.h (subrange::subrange(R&&)): Use
direct-initialization instead of list-initialization, so a
potential narrowing conversion from ranges::size(r) to the
stored size isn't ill-formed.

diff --git a/libstdc++-v3/include/bits/ranges_util.h 
b/libstdc++-v3/include/bits/ranges_util.h
index cc50e2ad4e4..416c3346254 100644
--- a/libstdc++-v3/include/bits/ranges_util.h
+++ b/libstdc++-v3/include/bits/ranges_util.h
@@ -247,7 +247,7 @@ namespace ranges
  && convertible_to, _Sent>
constexpr
subrange(_Rng&& __r) requires _S_store_size && sized_range<_Rng>
-   : subrange{__r, ranges::size(__r)}
+   : subrange(__r, ranges::size(__r))
{ }
 
   template<__detail::__not_same_as _Rng>

[committed] libstdc++: Fix some warnings in headers

[Jonathan Wakely via Gcc-patches]

These are usually suppressed in system headers, but should be fixed
anyway.

libstdc++-v3/ChangeLog:

* include/bits/parse_numbers.h (_Select_int_base): Avoid
narrowing conversion in constant expression.
* include/experimental/buffer (buffer_copy): Avoid narrowing
conversion.
* include/experimental/internet (hash<>::operator()): Do not
use deprecated 'argument_type' member.
* include/std/variant (variant::emplace): Use cast instead
of implicit conversion from size_t to narrower unsigned type.

Tested powerpc64le-linux. Committed to trunk.

commit d7aa21a3c78874743a42ffc1af3493ecb665496f
Author: Jonathan Wakely 
Date:   Thu Oct 29 22:47:22 2020

libstdc++: Fix some warnings in headers

These are usually suppressed in system headers, but should be fixed
anyway.

libstdc++-v3/ChangeLog:

* include/bits/parse_numbers.h (_Select_int_base): Avoid
narrowing conversion in constant expression.
* include/experimental/buffer (buffer_copy): Avoid narrowing
conversion.
* include/experimental/internet (hash<>::operator()): Do not
use deprecated 'argument_type' member.
* include/std/variant (variant::emplace): Use cast instead
of implicit conversion from size_t to narrower unsigned type.

diff --git a/libstdc++-v3/include/bits/parse_numbers.h 
b/libstdc++-v3/include/bits/parse_numbers.h
index 5e80907af09..923a56c5a9f 100644
--- a/libstdc++-v3/include/bits/parse_numbers.h
+++ b/libstdc++-v3/include/bits/parse_numbers.h
@@ -266,7 +266,7 @@ namespace __select_int
   template
 struct _Select_int_base<_Val, _IntType, _Ints...>
 : conditional_t<(_Val <= __gnu_cxx::__int_traits<_IntType>::__max),
-   integral_constant<_IntType, _Val>,
+   integral_constant<_IntType, (_IntType)_Val>,
_Select_int_base<_Val, _Ints...>>
 { };
 
diff --git a/libstdc++-v3/include/experimental/buffer 
b/libstdc++-v3/include/experimental/buffer
index 8ccdb28cc5b..08d3a365e8d 100644
--- a/libstdc++-v3/include/experimental/buffer
+++ b/libstdc++-v3/include/experimental/buffer
@@ -315,7 +315,7 @@ inline namespace v1
 inline size_t
 buffer_copy(const _MutableBufferSequence& __dest,
const _ConstBufferSequence& __source) noexcept
-{ return net::buffer_copy(__dest, __source, size_t{-1}); }
+{ return net::buffer_copy(__dest, __source, size_t(-1)); }
 
 
   // buffer arithmetic:
diff --git a/libstdc++-v3/include/experimental/internet 
b/libstdc++-v3/include/experimental/internet
index f1153b8ff6a..1143ef41a5a 100644
--- a/libstdc++-v3/include/experimental/internet
+++ b/libstdc++-v3/include/experimental/internet
@@ -2393,7 +2393,7 @@ namespace ip
 : __hash_base
 {
   size_t
-  operator()(const argument_type& __a) const
+  operator()(const experimental::net::v1::ip::address& __a) const
   {
if (__a.is_v4())
  return _Hash_impl::hash(__a.to_v4());
@@ -2407,7 +2407,7 @@ namespace ip
 : __hash_base
 {
   size_t
-  operator()(const argument_type& __a) const
+  operator()(const experimental::net::v1::ip::address_v4& __a) const
   { return _Hash_impl::hash(__a.to_bytes()); }
 };
 
@@ -2415,7 +2415,7 @@ namespace ip
 : __hash_base
 {
   size_t
-  operator()(const argument_type& __a) const
+  operator()(const experimental::net::v1::ip::address_v6& __a) const
   { return _Hash_impl::hash(__a.to_bytes()); }
 };
 
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 17f8bcd638b..4455ff4f073 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1512,7 +1512,8 @@ namespace __variant
}
  __catch (...)
{
- this->_M_index = variant_npos;
+ using __index_type = decltype(this->_M_index);
+ this->_M_index = static_cast<__index_type>(variant_npos);
  __throw_exception_again;
}
}
@@ -1559,7 +1560,8 @@ namespace __variant
}
  __catch (...)
{
- this->_M_index = variant_npos;
+ using __index_type = decltype(this->_M_index);
+ this->_M_index = static_cast<__index_type>(variant_npos);
  __throw_exception_again;
}
}

[committed] libstdc++: Prevent deprecation warnings from

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* include/tr1/shared_ptr.h (__shared_count, __shared_ptr)
(shared_ptr): Add diagnostic pragmas around uses of auto_ptr.
* testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc:
Adust dg-error line numbers.

Tested powerpc64le-linux. Committed to trunk.

commit 52ddf0d458f063f6c9e07e726f9b46206f71e4c4
Author: Jonathan Wakely 
Date:   Thu Oct 29 22:47:22 2020

libstdc++: Prevent deprecation warnings from 

libstdc++-v3/ChangeLog:

* include/tr1/shared_ptr.h (__shared_count, __shared_ptr)
(shared_ptr): Add diagnostic pragmas around uses of auto_ptr.
* testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc:
Adust dg-error line numbers.

diff --git a/libstdc++-v3/include/tr1/shared_ptr.h 
b/libstdc++-v3/include/tr1/shared_ptr.h
index 4c9372de11a..4d018df7da8 100644
--- a/libstdc++-v3/include/tr1/shared_ptr.h
+++ b/libstdc++-v3/include/tr1/shared_ptr.h
@@ -321,6 +321,9 @@ namespace tr1
}
}
 
+#if (__cplusplus < 201103L) || _GLIBCXX_USE_DEPRECATED
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
   // Special case for auto_ptr<_Tp> to provide the strong guarantee.
   template
 explicit
@@ -328,6 +331,8 @@ namespace tr1
: _M_pi(new _Sp_counted_base_impl<_Tp*,
_Sp_deleter<_Tp>, _Lp >(__r.get(), _Sp_deleter<_Tp>()))
 { __r.release(); }
+#pragma GCC diagnostic pop
+#endif
 
   // Throw bad_weak_ptr when __r._M_get_use_count() == 0.
   explicit
@@ -583,6 +588,8 @@ namespace tr1
}
 
 #if (__cplusplus < 201103L) || _GLIBCXX_USE_DEPRECATED
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
   // Postcondition: use_count() == 1 and __r.get() == 0
   template
 explicit
@@ -595,7 +602,7 @@ namespace tr1
  _M_refcount = __shared_count<_Lp>(__r);
  __enable_shared_from_this_helper(_M_refcount, __tmp, __tmp);
}
-
+#pragma GCC diagnostic pop
 #endif
 
   template
@@ -629,6 +636,8 @@ namespace tr1
}
 
 #if (__cplusplus < 201103L) || _GLIBCXX_USE_DEPRECATED
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
   template
 __shared_ptr&
 operator=(std::auto_ptr<_Tp1>& __r)
@@ -636,6 +645,7 @@ namespace tr1
  __shared_ptr(__r).swap(*this);
  return *this;
}
+#pragma GCC diagnostic pop
 #endif
 
   void
@@ -1006,10 +1016,13 @@ namespace tr1
: __shared_ptr<_Tp>(__r) { }
 
 #if (__cplusplus < 201103L) || _GLIBCXX_USE_DEPRECATED
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
   template
 explicit
 shared_ptr(std::auto_ptr<_Tp1>& __r)
: __shared_ptr<_Tp>(__r) { }
+#pragma GCC diagnostic pop
 #endif
 
   template
@@ -1033,6 +1046,8 @@ namespace tr1
}
 
 #if (__cplusplus < 201103L) || _GLIBCXX_USE_DEPRECATED
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
   template
 shared_ptr&
 operator=(std::auto_ptr<_Tp1>& __r)
@@ -1040,6 +1055,7 @@ namespace tr1
  this->__shared_ptr<_Tp>::operator=(__r);
  return *this;
}
+#pragma GCC diagnostic pop
 #endif
 };
 
diff --git 
a/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc 
b/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc
index c1c503022c1..6310be7a2a5 100644
--- 
a/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc
+++ 
b/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc
@@ -32,10 +32,10 @@ void test01()
 {
   X* px = 0;
   std::tr1::shared_ptr p1(px);   // { dg-error "here" }
-  // { dg-error "incomplete" "" { target *-*-* } 554 }
+  // { dg-error "incomplete" "" { target *-*-* } 559 }
 
   std::tr1::shared_ptr p9(ap());  // { dg-error "here" }
-  // { dg-error "incomplete" "" { target *-*-* } 593 }
+  // { dg-error "incomplete" "" { target *-*-* } 600 }
 }
 
 // Ignore additional diagnostic given with -Wsystem-headers:

[committed] libstdc++: Avoid warnings in tests

[Jonathan Wakely via Gcc-patches]

This fixes some warnings emitted when testing with warning flags added.
Some of these are only necessary when testing with -Wsystem-headers, but
either way it cleans up the tests to be less noisy under non-default
flags.

Tested powerpc64le-linux. Committed to trunk.

commit 13feb0234b136fbdc1dbfba3a9663fb4e1043f75
Author: Jonathan Wakely 
Date:   Thu Oct 29 22:47:21 2020

libstdc++: Avoid warnings in tests

This fixes some warnings emitted when testing with warning flags added.
Some of these are only necessary when testing with -Wsystem-headers, but
either way it cleans up the tests to be less noisy under non-default
flags.

libstdc++-v3/ChangeLog:

* testsuite/18_support/96817.cc: Avoid -Wunused warnings.
* testsuite/20_util/any/assign/2.cc: Likewise.
* testsuite/20_util/any/cons/2.cc: Likewise.
* testsuite/20_util/align/1.cc: Avoid -Wsign-compare warning.
* testsuite/20_util/function/65760.cc: Avoid -Wunused warning.
* testsuite/20_util/function/1.cc: Avoid -Wcatch-value warning.
* testsuite/20_util/function/cons/move_target.cc: Avoid -Wunused
warning.
* testsuite/20_util/headers/memory/synopsis.cc: Add exception
specification.
* testsuite/20_util/monotonic_buffer_resource/allocate.cc: Avoid
-Wsign-compare warning.
* testsuite/20_util/tuple/cons/deduction.cc: Avoid -Wunused
warning.
* 
testsuite/20_util/specialized_algorithms/uninitialized_copy/808590-cxx11.cc:
Avoid -Wdeprecated-copy warning.
* testsuite/21_strings/basic_string/56166.cc: Avoid
-Wcatch-value warning.
* 
testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc:
Avoid -Wcatch-value warnings.
* 
testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/char/stoul.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/char/stoull.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stod.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stof.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoi.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stol.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stold.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoll.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoul.cc:
Likewise.
* 
testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoull.cc:
Likewise.
* 
testsuite/21_strings/basic_string_view/operations/compare/char/nonnull.cc:
Prune additional diagnostics.
* 
testsuite/21_strings/basic_string_view/operations/find/char/nonnull.cc:
Likewise.
* 
testsuite/21_strings/basic_string_view/operations/rfind/char/nonnull.cc:
Likewise.
* testsuite/21_strings/headers/string/synopsis.cc: Add exception
specifications.
* testsuite/22_locale/locale/cons/12352.cc: Define sized
delete operators to avoid warnings.
* testsuite/23_containers/deque/modifiers/swap/1.cc: Add
exception specification.
* testsuite/23_containers/forward_list/cons/11.cc: Avoid
-Wdeprecated-copy warning.
* testsuite/23_containers/headers/bitset/synopsis.cc: Add
exception specification.
* testsuite/23_containers/headers/deque/synopsis.cc: Likewise.
* testsuite/23_containers/headers/forward_list/synopsis.cc:
Likewise.
* testsuite/23_containers/headers/list/synopsis.cc: Likewise.
* testsuite/23_containers/headers/map/synopsis.cc: Likewise.
* testsuite/23_containers/headers/queue/synopsis.cc: Likewise.
* testsuite/23_containers/headers/set/synopsis.cc: Likewise.
* testsuite/23_containers/headers/vector/synopsis.cc: Likewise.
* testsuite/23_containers/list/modifiers/swap/1.cc: Likewise.
  

Re: [PATCH] libstdc++: Implement C++20 features for

[Jonathan Wakely via Gcc-patches]

On 29/10/20 21:41 +, Jonathan Wakely wrote:

On 29/10/20 21:06 +0100, Rainer Orth wrote:

Tightening the patterns as in the attached patch at least allows
libstdc++.so.6 to link on i386-pc-solaris2.11; full bootstrap still
running.  However, I can't tell if this is really correct.


I think we want this attached patch instead. It tightens them up to
exactly the symbols we actually need to export and no more. This will
avoid needing to tighten them again in the near future when the new
overloads of str() are added.





diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 80994b203df..4dddfd3d263 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1791,11 +1791,11 @@ GLIBCXX_3.4.21 {

_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]ESt13_Ios_Openmode;

_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EED[012]Ev;

_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE[a34]*;
-_ZNKSt7__cxx1115basic_stringbuf*;
+_ZNKSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE3strEv;
_ZNKSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE3strEv;

_ZNKSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE5rdbufEv;
-_ZNKSt7__cxx1119basic_istringstream*;
-_ZNKSt7__cxx1119basic_ostringstream*;
+
_ZNKSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE3strEv;
+
_ZNKSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE5rdbufEv;
_ZT[ISTV]NSt7__cxx1115basic_stringbuf*;
_ZT[ISTV]NSt7__cxx1118basic_stringstream*;
_ZT[ISTV]NSt7__cxx1119basic_istringstream*;



Pushed to trunk now.

Re: Fix thunk_info with PCH

[Jeff Law via Gcc-patches]

On 10/29/20 3:32 PM, Jan Hubicka wrote:
> Hi,
> symbol summaries are not PCH safe and thus thunk_info summary can not be
> created before parsing is finished.  This patch stores thunk infos into
> a vector before they are attachd to actual symbol nodes at symtab
> construction time.
>
> I am not sure how to add the testcase - I did not find similar one in
> pch subdirectory...
>
> Bootstrapped/regtested x86_64-linux, will commit it tomrrow.
> gcc/ChangeLog:
>
> 2020-10-29  Jan Hubicka  
>
>   PR pch/97593
>   * cgraph.c (cgraph_node::create_thunk): Register thunk as early during
>   parsing.
>   * cgraphunit.c (analyze_functions): Call
>   thunk_info::process_early_thunks.
>   * symtab-thunks.cc (struct unprocessed_thunk): New struct.
>   (thunks): New static variable.
>   (thunk_info::register_early): New member function.
>   (thunk_info::process_early_thunks): New member function.
>   * symtab-thunks.h (thunk_info::register_early): Declare.
>   (thunk_info::process_early_thunks): Declare.

Ohh thanks.  I don't need to bisect this one.  I've seen this trip in a
few packages during this week's testing.


jeff

Re: PowerPC: Add __float128 conversions to/from Decimal

[Joseph Myers]

On Thu, 29 Oct 2020, Segher Boessenkool wrote:

> > Doing these conversions accurately is nontrivial.  Converting via strings 
> > is the simple approach (i.e. the one that moves the complexity somewhere 
> > else).  There are more complicated but more efficient approaches that can 
> > achieve correct conversions with smaller bounds on resource usage (and 
> > there are various papers published in this area), but those involve a lot 
> > more code (and precomputed data, with a speed/space trade-off in how much 
> > you precompute; the BID code in libgcc has several MB of precomputed data 
> > for that purpose).
> 
> Does the printf code in libgcc handle things correctly for IEEE QP float
> as long double, do you know?

As far as I know, the code in libgcc for conversions *from* decimal *to* 
binary (so the direction that uses strtof128 as opposed to the one using 
strfrom128, in the binary128 case) works correctly, if the underlying libc 
has accurate string/numeric conversion operations.

Binary to decimal is another matter, even for cases such as float to 
_Decimal64.  I've just filed bug 97635 for that.

Also note that if you want to use printf as opposed to strfromf128 for 
IEEE binary128 you'll need to use __printfieee128 (the version that 
expects long double to be IEEE binary128) which was introduced in glibc 
2.32, so that doesn't help with the glibc version dependencies.

When I investigated and reported several bugs in the conversion operations 
in libdfp, I noted (e.g. https://github.com/libdfp/libdfp/issues/29 ) that 
the libgcc versions were working correctly for those tests (and filed and 
subsequently fixed one glibc strtod bug, missing inexact exceptions, that 
I'd noticed while looking at such issues in libdfp).  But the specific 
case I tested for badly rounded conversions was the case of conversions 
from decimal to binary, not the case of conversions from binary to 
decimal, which, as noted above, turn out to be buggy in libgcc.

Lots of bugs have been fixed in the glibc conversion code over the years 
(more on the strtod side than in the code shared by printf and strfrom 
functions).  That code uses multiple-precision operations from GMP, which 
avoids some complications but introduces others (it also needs to e.g. 
deal with locale issues, which are irrelevant for libgcc conversions).

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

[PATCH] SPARC: add leon3v7 libgcc to leon3-elf

[Pat Bernardi]

This patch adds the leon3v7 version of libgcc to the leon3-elf target.

If approved, I'll need a maintainer to kindly commit on my behalf.

Thanks,

Pat Bernardi
Senior Software Engineer, AdaCore


2020-10-29  Pat Bernardi  mailto:berna...@adacore.com>>

gcc/ChangeLog

* config/sparc/t-leon3: Add leon3v7 version of libgcc.

libgcc/Changelog

* config.host (sparc-*-elf*): Use sparc/t-softmul on leon3

---
gcc/config/sparc/t-leon3 | 4 ++--
libgcc/config.host   | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/sparc/t-leon3 b/gcc/config/sparc/t-leon3
index 283ca6c45c3..e5bad3d99cf 100644
--- a/gcc/config/sparc/t-leon3
+++ b/gcc/config/sparc/t-leon3
@@ -17,6 +17,6 @@
# >.

# Multilibs for LEON3
-MULTILIB_OPTIONS = msoft-float
-MULTILIB_DIRNAMES = soft
+MULTILIB_OPTIONS = mcpu=leon3v7 msoft-float
+MULTILIB_DIRNAMES = leon3v7 soft
MULTILIB_MATCHES = msoft-float=mno-fpu
diff --git a/libgcc/config.host b/libgcc/config.host
index 5576c8c3723..e58ba75c873 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1283,7 +1283,7 @@ sparc64-*-openbsd*)
;;
sparc-*-elf*)
case ${host} in
-   *-leon[3-9]*)
+   *-leon[4-9]*)
;;
*)
tmake_file="sparc/t-softmul"

Re: [PATCH] libstdc++: Implement C++20 features for

[Jonathan Wakely via Gcc-patches]

On 29/10/20 21:06 +0100, Rainer Orth wrote:

Tightening the patterns as in the attached patch at least allows
libstdc++.so.6 to link on i386-pc-solaris2.11; full bootstrap still
running.  However, I can't tell if this is really correct.


I think we want this attached patch instead. It tightens them up to
exactly the symbols we actually need to export and no more. This will
avoid needing to tighten them again in the near future when the new
overloads of str() are added.


diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index 80994b203df..4dddfd3d263 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1791,11 +1791,11 @@ GLIBCXX_3.4.21 {
 _ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]ESt13_Ios_Openmode;
 _ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EED[012]Ev;
 _ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE[a34]*;
-_ZNKSt7__cxx1115basic_stringbuf*;
+_ZNKSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE3strEv;
 _ZNKSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE3strEv;
 _ZNKSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE5rdbufEv;
-_ZNKSt7__cxx1119basic_istringstream*;
-_ZNKSt7__cxx1119basic_ostringstream*;
+_ZNKSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE3strEv;
+_ZNKSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE5rdbufEv;
 _ZT[ISTV]NSt7__cxx1115basic_stringbuf*;
 _ZT[ISTV]NSt7__cxx1118basic_stringstream*;
 _ZT[ISTV]NSt7__cxx1119basic_istringstream*;

Fix thunk_info with PCH

[Jan Hubicka]

Hi,
symbol summaries are not PCH safe and thus thunk_info summary can not be
created before parsing is finished.  This patch stores thunk infos into
a vector before they are attachd to actual symbol nodes at symtab
construction time.

I am not sure how to add the testcase - I did not find similar one in
pch subdirectory...

Bootstrapped/regtested x86_64-linux, will commit it tomrrow.
gcc/ChangeLog:

2020-10-29  Jan Hubicka  

PR pch/97593
* cgraph.c (cgraph_node::create_thunk): Register thunk as early during
parsing.
* cgraphunit.c (analyze_functions): Call
thunk_info::process_early_thunks.
* symtab-thunks.cc (struct unprocessed_thunk): New struct.
(thunks): New static variable.
(thunk_info::register_early): New member function.
(thunk_info::process_early_thunks): New member function.
* symtab-thunks.h (thunk_info::register_early): Declare.
(thunk_info::process_early_thunks): Declare.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index d1a773d386f..9129bcf12d2 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -633,13 +633,20 @@ cgraph_node::create_thunk (tree alias, tree, bool 
this_adjusting,
   node->thunk = true;
   node->definition = true;
 
-  thunk_info *i = thunk_info::get_create (node);
+  thunk_info *i;
+  thunk_info local_info;
+  if (symtab->state < CONSTRUCTION)
+i = _info;
+  else
+i = thunk_info::get_create (node);
   i->fixed_offset = fixed_offset;
   i->virtual_value = virtual_value;
   i->indirect_offset = indirect_offset;
   i->alias = real_alias;
   i->this_adjusting = this_adjusting;
   i->virtual_offset_p = virtual_offset != NULL;
+  if (symtab->state < CONSTRUCTION)
+i->register_early (node);
 
   return node;
 }
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 08b93cb00ee..3a9895825b1 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1155,6 +1155,8 @@ analyze_functions (bool first_time)
   symtab->state = CONSTRUCTION;
   input_location = UNKNOWN_LOCATION;
 
+  thunk_info::process_early_thunks ();
+
   /* Ugly, but the fixup cannot happen at a time same body alias is created;
  C++ FE is confused about the COMDAT groups being right.  */
   if (symtab->cpp_implicit_aliases_done)
diff --git a/gcc/symtab-thunks.cc b/gcc/symtab-thunks.cc
index 1a4aaa2d80b..b11fd4a2cc2 100644
--- a/gcc/symtab-thunks.cc
+++ b/gcc/symtab-thunks.cc
@@ -52,6 +52,14 @@ along with GCC; see the file COPYING3.  If not see
 
 /* Used for vtable lookup in thunk adjusting.  */
 static GTY (()) tree vtable_entry_type;
+struct GTY (()) unprocessed_thunk
+{
+  cgraph_node *node;
+  thunk_info *info;
+};
+/* To be PCH safe we store thunks into a vector before end of compilation
+   unit.  */
+static vec  GTY (()) *thunks;
 
 namespace {
 
@@ -147,6 +155,33 @@ thunk_info::hash ()
   return hstate.end ();
 }
 
+/* Add unprocessed thunk.  */
+void
+thunk_info::register_early (cgraph_node *node)
+{
+  unprocessed_thunk entry = {node, new (ggc_alloc  ()) thunk_info};
+  *entry.info = *this;
+  vec_safe_push (thunks, entry);
+}
+
+/* Attach recorded thunks to cgraph_nodes.
+   All this is done only to avoid need to stream summaries to PCH.  */
+void
+thunk_info::process_early_thunks ()
+{
+  unprocessed_thunk *e;
+  unsigned int i;
+  if (!thunks)
+return;
+
+  FOR_EACH_VEC_ELT (*thunks, i, e)
+{
+  *thunk_info::get_create (e->node) = *e->info;
+}
+  vec_free (thunks);
+  thunks = NULL;
+}
+
 /* Adjust PTR by the constant FIXED_OFFSET, by the vtable offset indicated by
VIRTUAL_OFFSET, and by the indirect offset indicated by INDIRECT_OFFSET, if
it is non-null. THIS_ADJUSTING is nonzero for a this adjusting thunk and 
zero
diff --git a/gcc/symtab-thunks.h b/gcc/symtab-thunks.h
index a23fc552950..41a684995b3 100644
--- a/gcc/symtab-thunks.h
+++ b/gcc/symtab-thunks.h
@@ -77,6 +77,7 @@ struct GTY(()) thunk_info {
 fixed_offset = other.fixed_offset;
 virtual_value = other.virtual_value;
 indirect_offset = other.indirect_offset;
+alias = other.alias;
 this_adjusting = other.this_adjusting;
 virtual_offset_p = other.virtual_offset_p;
 return *this;
@@ -133,6 +134,12 @@ struct GTY(()) thunk_info {
   /* Remove thunk_info.  */
   static void remove (cgraph_node *node);
 
+  /* Add unprocessed thunk.  */
+  void register_early (cgraph_node *node);
+
+  /* Attach recorded thunks to cgraph_nodes.  */
+  static void process_early_thunks ();
+
   /* Release all thunk_infos.  */
   static void release (void);
 };

Re: [Patch] Fortran: Update omp atomic for OpenMP 5

[Tobias Burnus]

Forgot to add fortran@.

On 29.10.20 18:05, Tobias Burnus wrote:

The parser partially anticipates the upcoming OpenMP 5.1 changes, which
adds some more clauses - but otherwise does not update it for OpenMP 5.1,
yet. In particular, the "omp end atomic" for capture is still required
and
the memory-order-clause restrictions still apply.

I am a bit unsure about how to handle 'capture' (= update capture) and
the internal 'swap' in the internal representation; the current one is
not ideal, but others did not seem to be ideal, either.

OK?

Tobias

PS:
* On the C/C++ side, 'capture' (or update capture') restrictions are
  not checked (are the same as 'update' – and both are gone with
OpenMP 5.1,
  which also permits ACQ_REL for read/write)
* On the C/C++ side, OpenACC's atomic piggybacks on OpenMP's which
accepts
  too much.
* Fortran as C/C++: hint(hint-expr) is parsed but not actually used.


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
Fortran: Update omp atomic for OpenMP 5

gcc/fortran/ChangeLog:

	* dump-parse-tree.c (show_omp_clauses): Handle atomic clauses.
	(show_omp_node): Call it for atomic.
	* gfortran.h (enum gfc_omp_atomic_op): Add GFC_OMP_ATOMIC_UNSET,
	remove GFC_OMP_ATOMIC_SEQ_CST and GFC_OMP_ATOMIC_ACQ_REL.
	(enum gfc_omp_memorder): Replace OMP_MEMORDER_LAST by
	OMP_MEMORDER_UNSET, add OMP_MEMORDER_SEQ_CST/OMP_MEMORDER_RELAXED.
	(gfc_omp_clauses): Add capture and atomic_op.
	(gfc_code): remove omp_atomic.
	* openmp.c (enum omp_mask1): Add atomic, capture, memorder clauses.
	(gfc_match_omp_clauses): Match them.
	(OMP_ATOMIC_CLAUSES): Add.
	(gfc_match_omp_flush): Update for 'last' to 'unset' change.
	(gfc_match_omp_oacc_atomic): Removed and placed content ..
	(gfc_match_omp_atomic): ... here. Update for OpenMP 5 clauses.
	(gfc_match_oacc_atomic): Match directly here.
	(resolve_omp_atomic, gfc_resolve_omp_directive): Update.
	* parse.c (parse_omp_oacc_atomic): Update for struct gfc_code changes.
	* resolve.c (gfc_resolve_blocks): Update assert.
	* st.c (gfc_free_statement): Also call for EXEC_O{ACC,MP}_ATOMIC.
	* trans-openmp.c (gfc_trans_omp_atomic): Update.
	(gfc_trans_omp_flush): Update for 'last' to 'unset' change.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/atomic-2.f90: New test.
	* gfortran.dg/gomp/atomic.f90: New test.

 gcc/fortran/dump-parse-tree.c   |  34 
 gcc/fortran/gfortran.h  |  30 ++--
 gcc/fortran/openmp.c| 250 +---
 gcc/fortran/parse.c |   9 +-
 gcc/fortran/resolve.c   |   7 +-
 gcc/fortran/st.c|   4 +-
 gcc/fortran/trans-openmp.c  |  41 ++---
 gcc/testsuite/gfortran.dg/gomp/atomic-2.f90 |  33 
 gcc/testsuite/gfortran.dg/gomp/atomic.f90   | 111 
 9 files changed, 409 insertions(+), 110 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 6e265f4520d..43b97ba26ff 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1715,6 +1715,36 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
 }
   if (omp_clauses->depend_source)
 fputs (" DEPEND(source)", dumpfile);
+  if (omp_clauses->capture)
+fputs (" CAPTURE", dumpfile);
+  if (omp_clauses->atomic_op != GFC_OMP_ATOMIC_UNSET)
+{
+  const char *atomic_op;
+  switch (omp_clauses->atomic_op)
+	{
+	case GFC_OMP_ATOMIC_READ: atomic_op = "READ"; break;
+	case GFC_OMP_ATOMIC_WRITE: atomic_op = "WRITE"; break;
+	case GFC_OMP_ATOMIC_UPDATE: atomic_op = "UPDATE"; break;
+	default: gcc_unreachable ();
+	}
+  fputc (' ', dumpfile);
+  fputs (atomic_op, dumpfile);
+}
+  if (omp_clauses->memorder != OMP_MEMORDER_UNSET)
+{
+  const char *memorder;
+  switch (omp_clauses->memorder)
+	{
+	case OMP_MEMORDER_ACQ_REL: memorder = "ACQ_REL"; break;
+	case OMP_MEMORDER_ACQUIRE: memorder = "AQUIRE"; break;
+	case OMP_MEMORDER_RELAXED: memorder = "RELAXED"; break;
+	case OMP_MEMORDER_RELEASE: memorder = "RELEASE"; break;
+	case OMP_MEMORDER_SEQ_CST: memorder = "SEQ_CST"; break;
+	default: gcc_unreachable ();
+	}
+  fputc (' ', dumpfile);
+  fputs (memorder, dumpfile);
+}
 }
 
 /* Show a single OpenMP or OpenACC directive node and everything underneath it
@@ -1880,6 +1910,10 @@ show_omp_node (int level, gfc_code *c)
 case EXEC_OMP_TASKWAIT:
 case EXEC_OMP_TASKYIELD:
   return;
+case EXEC_OACC_ATOMIC:
+case EXEC_OMP_ATOMIC:
+  omp_clauses = c->block ? c->block->ext.omp_clauses : NULL;
+  break;
 default:
   break;
 }
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 73b6ffd870c..9500032f0e3 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1343,6 +1343,16 @@ enum gfc_omp_if_kind
   OMP_IF_LAST
 };
 
+enum gfc_omp_atomic_op
+{
+  

[PATCH] libstdc++: Add c++2a

[Thomas Rodgers]

From: Thomas Rodgers 

Addresses latest patch feedback. Changes  to also work on
single threaded configurations.

libstdc++/ChangeLog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am (std_headers): Add new header.
libstdc++-v3/include/Makefile.in: Regenerate.
libstdc++-v3/include/precompiled/stdc++.h: Include new header.
(basic_streambuf): Befriend __detail::__streambuf_core_access.
libstdc++-v3/include/std/syncstream: New header.
libstdc++-v3/include/std/version: Add __cpp_lib_syncbuf:
libstdc++-v3/testsuite/27_io/basic_syncbuf/1.cc: New test.
libstdc++-v3/testsuite/27_io/basic_syncbuf/2.cc: Likewise.
libstdc++-v3/testsuite/27_io/basic_syncbuf/basic_ops/1.cc:
Likewise.
libstdc++-v3/testsuite/27_io/basic_syncbuf/requirements/types.cc:
Likewise.
libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc:
Likewise.
libstdc++-v3/testsuite/27_io/basic_syncstream/1.cc: Likewise.
libstdc++-v3/testsuite/27_io/basic_syncstream/2.cc: Likewise.
libstdc++-v3/testsuite/27_io/basic_syncstream/basic_ops/1.cc:
Likewise.
libstdc++-v3/testsuite/27_io/basic_syncstream/requirements/types.cc:
Likewise.
---
 libstdc++-v3/doc/doxygen/user.cfg.in  |   1 +
 libstdc++-v3/include/Makefile.am  |   1 +
 libstdc++-v3/include/Makefile.in  |   1 +
 libstdc++-v3/include/precompiled/stdc++.h |   2 +-
 libstdc++-v3/include/std/syncstream   | 328 ++
 libstdc++-v3/include/std/version  |   4 +
 .../testsuite/27_io/basic_syncbuf/1.cc|  28 ++
 .../testsuite/27_io/basic_syncbuf/2.cc|  28 ++
 .../27_io/basic_syncbuf/basic_ops/1.cc| 137 
 .../27_io/basic_syncbuf/requirements/types.cc |  42 +++
 .../27_io/basic_syncbuf/sync_ops/1.cc | 130 +++
 .../testsuite/27_io/basic_syncstream/1.cc |  28 ++
 .../testsuite/27_io/basic_syncstream/2.cc |  28 ++
 .../27_io/basic_syncstream/basic_ops/1.cc | 134 +++
 .../basic_syncstream/requirements/types.cc|  43 +++
 15 files changed, 934 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/include/std/syncstream
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncbuf/1.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncbuf/2.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncbuf/basic_ops/1.cc
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_syncbuf/requirements/types.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncstream/1.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncstream/2.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncstream/basic_ops/1.cc
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_syncstream/requirements/types.cc

diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in 
b/libstdc++-v3/doc/doxygen/user.cfg.in
index 9b49a15d31b..320f6dea688 100644
--- a/libstdc++-v3/doc/doxygen/user.cfg.in
+++ b/libstdc++-v3/doc/doxygen/user.cfg.in
@@ -897,6 +897,7 @@ INPUT  = @srcdir@/doc/doxygen/doxygroups.cc 
\
  include/streambuf \
  include/string \
  include/string_view \
+ include/syncstream \
  include/system_error \
  include/thread \
  include/tuple \
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index c90ac555e15..8652b921274 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -73,6 +73,7 @@ std_headers = \
${std_srcdir}/shared_mutex \
${std_srcdir}/span \
${std_srcdir}/sstream \
+   ${std_srcdir}/syncstream \
${std_srcdir}/stack \
${std_srcdir}/stdexcept \
${std_srcdir}/stop_token \
diff --git a/libstdc++-v3/include/precompiled/stdc++.h 
b/libstdc++-v3/include/precompiled/stdc++.h
index 7518a98c25a..8899c323a28 100644
--- a/libstdc++-v3/include/precompiled/stdc++.h
+++ b/libstdc++-v3/include/precompiled/stdc++.h
@@ -141,6 +141,6 @@
 #include 
 #include 
 #include 
-// #include 
+#include 
 #include 
 #endif
diff --git a/libstdc++-v3/include/std/syncstream 
b/libstdc++-v3/include/std/syncstream
new file mode 100644
index 000..88452c2ed10
--- /dev/null
+++ b/libstdc++-v3/include/std/syncstream
@@ -0,0 +1,328 @@
+//  -*- C++ -*-
+
+// Copyright (C) 2020 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 

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

[Joseph Myers]

On Wed, 22 Jul 2020, Asher Gordon via Gcc-patches wrote:

> Hello Joseph, Martin,
> 
> Asher Gordon  writes:
> 
> > Joseph Myers  writes:
> >
> >> I don't see you in the FSF copyright assignment list; could you
> >> complete
> >> https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
> >> (unless you're already covered by an employer assignment)?
> >
> > Done.
> 
> My copyright assignment finally got finished, so you should be able to
> apply my patches now.
> 
> For your convenience, I have attached the three patches below:

I've tested and committed the first patch.  The second one introduces some 
test failures:

< PASS: gcc.dg/Wdesignated-init-2.c  (test for warnings, line 14)
< PASS: gcc.dg/Wdesignated-init-2.c  (test for warnings, line 15)
---
> FAIL: gcc.dg/Wdesignated-init-2.c  (test for warnings, line 14)
> FAIL: gcc.dg/Wdesignated-init-2.c  (test for warnings, line 15)

< PASS: gcc.dg/init-excess-2.c  (test for warnings, line 30)
---
> FAIL: gcc.dg/init-excess-2.c  (test for warnings, line 30)

Could you investigate those and send versions of the second and third 
patches that don't introduce any test regressions?

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

Re: PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

[Michael Meissner via Gcc-patches]

On Thu, Oct 29, 2020 at 03:08:07PM -0500, Segher Boessenkool wrote:
> It isn't set anywhere else.
> 
> Mike, the patch is okay for trunk with that line restored.  Thanks!
> (And thanks for spotting the problem Will!)

It is set since the variable is a static.  The whole point is to only raise the
error once, even if the options code gets called multiple times.

Ah right, it got missed.  Thanks.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

[Michael Meissner via Gcc-patches]

On Thu, Oct 29, 2020 at 01:32:53PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 29, 2020 at 12:50:10PM -0400, Michael Meissner wrote:
> > On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote:
> > > On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote:
> > > > This patch adds long double variants of the power10 __float128 built-in
> > > > functions.  This is needed when long double uses IEEE 128-bit because
> > > > __float128 uses TFmode in this case instead of KFmode.  If this patch 
> > > > is not
> > > > applied, these built-in functions can't be used when long double is IEEE
> > > > 128-bit.
> > > 
> > > But now they still cannot, you need new builtins, instead.
> > > 
> > > TFmode is an implementation detail at this level (functions use types,
> > > not modes), so you do not need new builtins at all afaics?  Just define
> > > the existing ones with TFmode as well (if that is the same as KFmode)?
> > 
> > In order to add new overloaded built-ins, you have to add a new built-in 
> > with a
> > new name.
> 
> I do not follow?  Just delete the old non-overloaded one and add the
> overloaded one with that same old name at the same time.

You have to have 3 names for the built-in function:

  * A name specific to KFmode;
  * A name specific to long double with IEEE 128-bit; (and)
  * The generic name.

And the generic name (from the user point of view, not the insn name) needs to
be the generic name.

> TF is a nasty name, it means a different thing externally (in the libgcc
> function names, say: always IFmode) and internally (it varies what it
> means).
> 
> > Maybe when Bill finally reorganizes the built-in functions, we can do anyway
> > with having to create new named functions.  But for now, in order to add 
> > them,
> > you need a name.
> 
> Of course.  And there already is a name :-)

One name, but as I said, we will now need three insn names, and these names
spill out to the built-in names.  Even if we don't document the names, they
still exist and determined users can call them.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping: [PATCH] i386: Cleanup i386/i386elf.h and align it's return convention with the SVR4 ABI

[Pat Bernardi]

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552186.html 


Thanks.

> On 18 Aug 2020, at 6:02 pm, Pat Bernardi  wrote:
> 
> As observed a number of years ago in the following thread, i386/i386elf.h has 
> not been kept up to date:
> 
> https://gcc.gnu.org/pipermail/gcc/2013-August/209981.html
> 
> This patch does the following cleanup:
> 
> 1. The return convention now follows the i386 and x86_64 SVR4 ABIs again. As 
> discussed in the above thread, the current return convention does not match 
> any other target or existing ABI, which is problematic since the current 
> approach is inefficient (particularly on x86_64-elf) and confuses other tools 
> like GDB (unfortunately that thread did not lead to any fix at the time). 
> 
> 2. The default version of ASM_OUTPUT_ASCII from elfos.h is used. As mentioned 
> in the cleanup of i386/sysv4.h [1] the ASM_OUTPUT_ASCII implementation then 
> used by sysv4.h, and currently used by i386elf.h, has a significantly higher 
> computation complexity than the default version provided by elfos.h.
> 
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2011-February/305559.html

Re: Avoid char[] array in tree_def

[Jason Merrill via Gcc-patches]

On 10/29/20 1:40 PM, Richard Biener wrote:

On Thu, 29 Oct 2020, Jakub Jelinek wrote:


On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:


That's ugly and will for sure defeat warning / access code
when we access this as char[], no?  I mean, we could
as well use 'int str[1];' here?


Well, we always get char pointer via macro that is IMO OK, but I am also
not very much in love with this.


Do we treat signed char [...]; as typeless storage too, or just
what the C++ standard requires (i.e. char, unsigned char and std::byte
where the last one is enum type with unsigned char underlying type)?


All that is covered by is_byte_access_type which includes all
character types (including char16_t and wchar it seems) and std::byte.


Well, that's a bug, apparently from the PR94923 patch (r11-499); 
previously it was char, signed char, and unsigned char.  And even that 
is too much; even C++98 said just char and unsigned char could be used 
for bytewise access.


When C++17 clarified this with the notion of "provides storage", it 
applied to only unsigned char and std::byte, not even the full set of 
byte-access types.  We still need to allow bytewise access using plain 
char, but perhaps we don't need to treat plain char arrays as typeless.


Attributes to say that a particular array does or does not provide 
storage for objects of other types do sound useful.


Jason

[patch] gcc.dg/analyzer tests: relax dependency on alloca.h

[Olivier Hainque]

Hello,

Some of the tests in gcc.dg/analyzer exercize alloca
and #include .

Some systems, e.g. VxWorks, don't feature alloca.h and
the aforementioned tests fail.

Other tests in the suite have been in this situation and
the usual way around consists in resorting to __builtin_alloca
directly.

This patch is a proposal in this direction for gcc.dg/analyzer.

It introduces a common "analyzer-alloca.h" where we can
stick a common comment and a macro to redirect "alloca"
directly to "__builtin_alloca".

The intermediate macro in a non system header unfortunately
diverts some of the warning expectations, as the allocation
point for "x = alloca(128);" is shown on the macro definition
and not at the macro invocation point.

The patch circumvents this by calling __builtin_alloca
directly from the points where the tests perform a warning
check.

I have verified that all the tests adjusted by the change
now pass in a run for a powerpc-vxworks configuration.

I'll gladly perform an extra regression test on a native
system if the patch is considered ok.

Would this be ok to commit ?

Thanks in advance,

With Kind Regards,

Olivier

2020-10-29  Olivier Hainque  

gcc/testsuite/
* gcc.dg/analyzer/analyzer-alloca.h: New file.
* gcc.dg/analyzer/alloca-leak.c: Use it.
* gcc.dg/analyzer/data-model-1.c: Use it.
* gcc.dg/analyzer/malloc-1.c: Use it and replace call to
be tracked by a direct call to __builtin_alloca.
* gcc.dg/analyzer/malloc-paths-8.c: Likewise.

diff --git a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c 
b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
index 93319932d44a..e990cbc642b9 100644
--- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
+++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target alloca } */
 
-#include 
+#include "analyzer-alloca.h"
 
 void *test (void)
 {
diff --git a/gcc/testsuite/gcc.dg/analyzer/analyzer-alloca.h 
b/gcc/testsuite/gcc.dg/analyzer/analyzer-alloca.h
new file mode 100644
index ..edb20b118db3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/analyzer-alloca.h
@@ -0,0 +1,8 @@
+
+/* This header is provided to circumvent the absence of alloca.h on
+   some systems.  Spots that rely on the ability to designate
+   allocation points within tests can use __builtin_alloca directly
+   to prevent the diagnostic redirection to the local macro definition
+   here, as this is not a system header.  */
+
+#define alloca(n) __builtin_alloca(n)
diff --git a/gcc/testsuite/gcc.dg/analyzer/data-model-1.c 
b/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
index 3f16a38ab14d..f4ba96b1e997 100644
--- a/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
@@ -3,7 +3,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "analyzer-alloca.h"
 #include "analyzer-decls.h"
 
 struct foo
diff --git a/gcc/testsuite/gcc.dg/analyzer/malloc-1.c 
b/gcc/testsuite/gcc.dg/analyzer/malloc-1.c
index 38ce1a52987b..b0039597c5fb 100644
--- a/gcc/testsuite/gcc.dg/analyzer/malloc-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/malloc-1.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target alloca } */
 
-#include 
+#include "analyzer-alloca.h"
 #include 
 
 extern int foo (void);
@@ -273,7 +273,7 @@ int *test_23a (int n)
 
 int test_24 (void)
 {
-  void *ptr = alloca (sizeof (int)); /* { dg-message "memory is allocated on 
the stack here" } */
+  void *ptr = __builtin_alloca (sizeof (int)); /* { dg-message "memory is 
allocated on the stack here" } */
   free (ptr); /* { dg-warning "'free' of memory allocated on the stack by 
'alloca' \\('ptr'\\) will corrupt the heap \\\[CWE-590\\\]" } */
 }
 
diff --git a/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c 
b/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c
index 35c9385b2061..417459edf8cc 100644
--- a/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c
+++ b/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c
@@ -2,7 +2,7 @@
 /* { dg-require-effective-target alloca } */
 
 #include 
-#include 
+#include "analyzer-alloca.h"
 #include 
 
 extern void do_stuff (const void *);
@@ -41,7 +41,7 @@ void test_3 (size_t sz)
 {
   void *ptr;
   if (sz <= LIMIT)
-ptr = alloca (sz); /* { dg-message "memory is allocated on the stack here" 
} */
+ptr = __builtin_alloca (sz); /* { dg-message "memory is allocated on the 
stack here" } */
   else
 ptr = malloc (sz);
 
-- 
2.17.1

Re: [RS6000] Don't be too clever with dg-do run and dg-do compile

[Segher Boessenkool]

On Thu, Oct 29, 2020 at 09:09:13AM +1030, Alan Modra wrote:
> On Wed, Oct 28, 2020 at 12:16:00PM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 28, 2020 at 09:20:56PM +1030, Alan Modra wrote:
> > > Otherwise some versions of dejagnu go ahead and run the vsx tests
> > > below when they should not.  To best cope with older dejagnu, put
> > > "run" before "compile", the idea being that if the second dg-do always
> > > wins then that won't cause fails.
> > 
> > If they are mutually exclusive, does the order still matter?  (Just FMI.)
> 
> Yes, it does.  Older dejagnu takes the last action regardless of the
> target selector success.  Newer dejagnu uses the last action of a line
> with a successful target selector.
> 
> commit 569f8718b534a2cd9511a7d640352eb0126ff492
> Author: Dominik Vogt 
> Date:   Mon Mar 28 17:31:07 2016 +1100
> 
> * dg.exp (dg-do): Do not change the previously selected action if
> a de-selected dg-do is encountered.
> 
> Signed-off-by: Ben Elliston 

So fixed in 1.6 and later.  Thanks!


Segher

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

[Qing Zhao via Gcc-patches]

Hi, Segher,

> On Oct 29, 2020, at 2:31 PM, Segher Boessenkool  
> wrote:
> 
> On Thu, Oct 29, 2020 at 06:02:58PM +, Richard Sandiford wrote:
>> Qing Zhao via Gcc-patches  writes:
> +Return-Oriented Programming (ROP) or preventing information leak
 
 leakage
 
 (FWIW, I'm not sure “mitigating ROP” is really correct usage, but I don't
 have any better suggestions.)
>>> 
>>> Do you mean whether “mitigating ROP’ is one of the major purpose of this 
>>> new feature?
>> 
>> No, I meant just the English usage.  E.g., I think you mitigate the
>> damage caused by earthquakes rather than mitigate earthquakes themselves.
>> But I could be wrong.  It's not a word I use very often ;-)
> 
> "Mitigating ROP attacks" is a phrase often used in the literature, sadly
> (what is really meant is not "mitigating the effects of ROP attacks",
> but simply "making ROP attacks less likely to succeed" -- it is almost
> always a binary thing, either it succeeds or it doesn't).

Thanks.

I will change “Mitigating ROP” to “Mitigating ROP attacks” in the 
documentation. 

Qing
> 
> 
> Segher

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

[Qing Zhao via Gcc-patches]

> On Oct 29, 2020, at 1:06 PM, Richard Sandiford  
> wrote:
> 
> Qing Zhao  writes:
>> Now, the documentation (gcc.info) is like following, let me know any issue 
>> there:
> 
> Yeah, looks good apart from merging
> 
>> In order to satisfy users with different security needs and control
>> the run-time overhead at the same time, CHOICE parameter provides a
>> flexible way to choose the subset of the call-used registers to be
>> zeroed.
>> 
>> The three basic values of CHOICE are:
> 
> this into a single paragraph.

Okay, will do.

Qing
> 
> Thanks,
> Richard

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

[Qing Zhao via Gcc-patches]

> On Oct 29, 2020, at 1:02 PM, Richard Sandiford  
> wrote:
> 
> Qing Zhao via Gcc-patches  writes:
 +Return-Oriented Programming (ROP) or preventing information leak
>>> 
>>> leakage
>>> 
>>> (FWIW, I'm not sure “mitigating ROP” is really correct usage, but I don't
>>> have any better suggestions.)
>> 
>> Do you mean whether “mitigating ROP’ is one of the major purpose of this new 
>> feature?
> 
> No, I meant just the English usage.  E.g., I think you mitigate the
> damage caused by earthquakes rather than mitigate earthquakes themselves.
> But I could be wrong.  It's not a word I use very often ;-)

Okay.
I see. 
> 
 +In order to satisfy users with different security needs and control the
 +run-time overhead at the same time, GCC provides a flexible way to choose
 +the subset of the call-used registers to be zeroed.
>>> 
>>> Maybe s/GCC/the @var{choice} parameter/.
>> Okay.
>>> 
 +
 +The three basic values of @var{choice} are:
>>> 
>>> After which, I think this should be part of the previous paragraph.
>> 
>> Don’t understand here, could you explain a little bit more?
> 
> I meant:
> 
> In order to satisfy users with different security needs and control the
> run-time overhead at the same time, @var{choice} provides a flexible way
> to choose the subset of the call-used registers to be zeroed.  The three
> basic values of @var{choice} are:
> 

Oh. :-)

 +  /* If gpr_only is true, only zero call-used registers that are
 + general-purpose registers; if used_only is true, only zero
 + call-used registers that are used in the current function;
 + if arg_only is true, only zero call-used registers that pass
 + parameters defined by the flatform's calling conversion.  */
 +
 +  gpr_only = crtl->zero_call_used_regs & ONLY_GPR;
 +  used_only = crtl->zero_call_used_regs & ONLY_USED;
 +  arg_only = crtl->zero_call_used_regs & ONLY_ARG;
>>> 
>>> Guess it would be nice to be consistent about which side the “only”
>>> goes on.  FWIW, I don't mind which way: GPR_ONLY etc. would be
>>> OK with me if you prefer that.
>> The current names are okay for me.
> 
> OK.  But I think one of them should change to match the other.
> E.g. either the local variable should be “only_gpr” or the
> flag should be “GPR_ONLY”.
Okay, I see what you mean, will make them consistent.

Qing
> 
> Thanks,
> Richard

Re: PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

[Segher Boessenkool]

On Thu, Oct 29, 2020 at 02:11:47PM -0500, will schmidt wrote:
> On Thu, 2020-10-29 at 13:05 -0400, Michael Meissner wrote:
> > On Mon, Oct 26, 2020 at 05:48:48PM -0500, will schmidt wrote:
> > > On Thu, 2020-10-22 at 18:15 -0400, Michael Meissner via Gcc-patches 
> > > wrote:
> > > > PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.
> > > > 
> > > > This is a new patch.  It turns off the warning about switching
> > > > the long double
> > > > type via compile line if the GLIBC is 2.32 or newer.  It only
> > > > does this if the
> > > > languages are C or C++, since those language libraries support
> > > > switching the
> > > > long double type.  Other languages like Fortran don't have any
> > > > current support
> > > > to provide both sets of interfaces to the library.
> > > > 
> > > > 2020-10-21  Michael Meissner  
> > > > 
> > > > * config/rs6000/rs6000.c (rs6000_option_override_internal):
> > > > Allow
> > > > long double type to be changed for C/C++ if glibc 2.32 or
> > > > newer.
> > > > ---
> > > >  gcc/config/rs6000/rs6000.c | 10 --
> > > >  1 file changed, 8 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/gcc/config/rs6000/rs6000.c
> > > > b/gcc/config/rs6000/rs6000.c
> > > > index 50039c0a53d..940c15f3265 100644
> > > > --- a/gcc/config/rs6000/rs6000.c
> > > > +++ b/gcc/config/rs6000/rs6000.c
> > > > @@ -4158,10 +4158,16 @@ rs6000_option_override_internal (bool
> > > > global_init_p)
> > > > 
> > > >if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT &&
> > > > TARGET_LONG_DOUBLE_128)
> > > > {
> > > > + /* Determine if the user can change the default long double
> > > > type at
> > > > +compilation time.  Only C and C++ support this, and you
> > > > need GLIBC
> > > > +2.32 or newer.  Only issue one warning.  */
> > > >   static bool warned_change_long_double;
> > > > - if (!warned_change_long_double)
> > > > +
> > > > + if (!warned_change_long_double
> > > > + && (!OPTION_GLIBC
> > > > + || (!lang_GNU_C () && !lang_GNU_CXX ())
> > > > + || ((TARGET_GLIBC_MAJOR * 1000) + TARGET_GLIBC_MINOR)
> > > > < 2032))
> > > > {
> > > > - warned_change_long_double = true;
> > > 
> > > Does this need to be added back elsewhere? 
> > 
> > At the present time, we are not contemplating adding the full support
> > to enable
> > configuring GCC to use IEEE 128-bit long double in GCC 10 or
> > earlier.  This may
> > change depending on customer demands.
> > 
> 
> My question was/is specific with the removal of the assignment
> 
> -   warned_change_long_double = true;
> 
> I didn't see where that line or an equvalent was added back.  It's
> either set elsewhere (ok), or no longer used.

It isn't set anywhere else.

Mike, the patch is okay for trunk with that line restored.  Thanks!
(And thanks for spotting the problem Will!)


Segher

Re: [PATCH] libstdc++: Implement C++20 features for

[Rainer Orth]

Hi Jonathan,

> On > The patch that was committed broke the linker script. The attached
> patch restores the piece that got lost, and removes the duplicate
> patterns added for the new symbols. Pushed to trunk.

even this fixed version broke Solaris bootstrap:

ld: fatal: libstdc++-symbols.ver-sun: 7318: symbol 
'_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE13get_allocatorEv': 
symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 7319: symbol 
'_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE13get_allocatorEv': 
symbol version conflict

  matched by


##_ZNKSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE13get_allocatorEv
 (glob)
_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE13get_allocatorEv;
_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE13get_allocatorEv;

  and


##_ZNKSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE[0-35-9]* 
(glob)

  which matches

_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE13get_allocatorEv;
_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE3strEv;
_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE13get_allocatorEv;
_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE3strEv;

ld: fatal: libstdc++-symbols.ver-sun: 7321: symbol 
'_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE4viewEv': symbol 
version conflict
ld: fatal: libstdc++-symbols.ver-sun: 7322: symbol 
'_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE4viewEv': symbol 
version conflict

  matched by

##_ZNKSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE4viewEv 
(glob)
_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE4viewEv;
_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE4viewEv;

  and

##_ZNKSt7__cxx1115basic_stringbuf* (glob)

  which matches

_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE13get_allocatorEv;
_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE3strEv;
_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE4viewEv;
_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE13get_allocatorEv;
_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE3strEv;
_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE4viewEv;

ld: fatal: libstdc++-symbols.ver-sun: 7342: symbol 
'_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE4viewEv': symbol 
version conflict
ld: fatal: libstdc++-symbols.ver-sun: 7343: symbol 
'_ZNKSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE4viewEv': symbol 
version conflict

  matched by


##_ZNKSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE4viewEv
 (glob)
_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE4viewEv;
_ZNKSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE4viewEv;
_ZNKSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEE4viewEv;
_ZNKSt7__cxx1119basic_ostringstreamIwSt11char_traitsIwESaIwEE4viewEv;

  and

##_ZNKSt7__cxx1119basic_istringstream* (glob)
##_ZNKSt7__cxx1119basic_ostringstream* (glob)

  which match

_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE3strEv;
_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE4viewEv;
_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE5rdbufEv;
_ZNKSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE3strEv;
_ZNKSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE4viewEv;
_ZNKSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE5rdbufEv;
_ZNKSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEE3strEv;
_ZNKSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEE4viewEv;
_ZNKSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEE5rdbufEv;
_ZNKSt7__cxx1119basic_ostringstreamIwSt11char_traitsIwESaIwEE3strEv;
_ZNKSt7__cxx1119basic_ostringstreamIwSt11char_traitsIwESaIwEE4viewEv;
_ZNKSt7__cxx1119basic_ostringstreamIwSt11char_traitsIwESaIwEE5rdbufEv;

Tightening the patterns as in the attached patch at least allows
libstdc++.so.6 to link on i386-pc-solaris2.11; full bootstrap still
running.  However, I can't tell if this is really correct.

Rainer

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


diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1791,11 +1791,11 @@ GLIBCXX_3.4.21 {
 _ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]ESt13_Ios_Openmode;
 _ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EED[012]Ev;
 _ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE[a34]*;
-_ZNKSt7__cxx1115basic_stringbuf*;
+_ZNKSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE[0235-9]*;
 

Re: [PATCH v2] c++: Deducing type from initializer_list [PR93107]

[Jason Merrill via Gcc-patches]

On 10/29/20 3:55 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 03:18:18PM -0400, Jason Merrill via Gcc-patches wrote:

On 10/16/20 11:31 AM, Marek Polacek wrote:

In this testcase we weren't able to deduce b's type:

template void Task() { }
auto b = {  };

because resolve_nondeduced_context doesn't iterate on the {}'s elements.
So make sure to look into {} too.  We don't need to handle nested {}
here.


Why don't we?  That rationale should be in a comment.


I don't think we can deduce from a nested init-list; none of the following
work:

   #include 

   template
   void fn() {};

   struct X { } x;

   auto a = { { fn } }; // unable to deduce std::initializer_list from 
{{fn}}
   auto b = { { x, x } }; // unable to deduce std::initializer_list from 
{{x, x}}
   auto c = { { 1 } }; // unable to deduce std::initializer_list from 
{{1}}

clang++ says "cannot deduce actual type for variable 'a' with type 'auto'
from initializer list".

I've added a comment:


OK.


-- >8 --
In this testcase we weren't able to deduce b's type:

   template void Task() { }
   auto b = {  };

because resolve_nondeduced_context doesn't iterate on the {}'s elements.
So make sure to look into {} too.  We don't need to handle nested {}
here.

We could either tweak resolve_nondeduced_context to handle CONSTRUCTORs
or add a _ctor version, but then resolve_nondeduced_context_or_error
would need some changes too -- it'd have to check the result of a call
to r_n_c for each element.

gcc/cp/ChangeLog:

PR c++/93107
* pt.c (do_auto_deduction): Call resolve_nondeduced_context for
the elements of a { } list.

gcc/testsuite/ChangeLog:

PR c++/93107
* g++.dg/cpp0x/initlist-deduce3.C: New test.
---
  gcc/cp/pt.c   |  8 ++-
  gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C | 22 +++
  2 files changed, 29 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 531554d702d..b569644514c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29241,7 +29241,13 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
if (type == error_mark_node)
  return error_mark_node;
  
-  init = resolve_nondeduced_context (init, complain);

+  if (BRACE_ENCLOSED_INITIALIZER_P (init))
+/* We don't recurse here because we can't deduce from a nested
+   initializer_list.  */
+for (constructor_elt  : *CONSTRUCTOR_ELTS (init))
+  elt.value = resolve_nondeduced_context (elt.value, complain);
+  else
+init = resolve_nondeduced_context (init, complain);
  
if (context == adc_decomp_type

&& auto_node == type
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C
new file mode 100644
index 000..b8417d7bf0c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C
@@ -0,0 +1,22 @@
+// PR c++/93107
+// { dg-do compile { target c++11 } }
+
+using size_t = decltype(sizeof 0);
+
+namespace std {
+  template struct initializer_list {
+const T *ptr;
+size_t n;
+initializer_list(const T*, size_t);
+  };
+}
+
+template
+void Task() {}
+
+auto a = ;
+auto b = {  };
+auto e{  };
+auto f = { ,  };
+std::initializer_list c = {  };
+auto d = { static_cast() };

base-commit: 79991e2348a864ace6ea2bf108a7502862f1129f

Re: [PATCH v2] c++: Deducing type from initializer_list [PR93107]

[Marek Polacek via Gcc-patches]

On Wed, Oct 28, 2020 at 03:18:18PM -0400, Jason Merrill via Gcc-patches wrote:
> On 10/16/20 11:31 AM, Marek Polacek wrote:
> > In this testcase we weren't able to deduce b's type:
> > 
> >template void Task() { }
> >auto b = {  };
> > 
> > because resolve_nondeduced_context doesn't iterate on the {}'s elements.
> > So make sure to look into {} too.  We don't need to handle nested {}
> > here.
> 
> Why don't we?  That rationale should be in a comment.

I don't think we can deduce from a nested init-list; none of the following
work:

  #include 

  template
  void fn() {};

  struct X { } x;

  auto a = { { fn } }; // unable to deduce std::initializer_list 
from {{fn}}
  auto b = { { x, x } }; // unable to deduce std::initializer_list from 
{{x, x}}
  auto c = { { 1 } }; // unable to deduce std::initializer_list from {{1}}

clang++ says "cannot deduce actual type for variable 'a' with type 'auto'
from initializer list".

I've added a comment:

-- >8 --
In this testcase we weren't able to deduce b's type:

  template void Task() { }
  auto b = {  };

because resolve_nondeduced_context doesn't iterate on the {}'s elements.
So make sure to look into {} too.  We don't need to handle nested {}
here.

We could either tweak resolve_nondeduced_context to handle CONSTRUCTORs
or add a _ctor version, but then resolve_nondeduced_context_or_error
would need some changes too -- it'd have to check the result of a call
to r_n_c for each element.

gcc/cp/ChangeLog:

PR c++/93107
* pt.c (do_auto_deduction): Call resolve_nondeduced_context for
the elements of a { } list.

gcc/testsuite/ChangeLog:

PR c++/93107
* g++.dg/cpp0x/initlist-deduce3.C: New test.
---
 gcc/cp/pt.c   |  8 ++-
 gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C | 22 +++
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 531554d702d..b569644514c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29241,7 +29241,13 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
   if (type == error_mark_node)
 return error_mark_node;
 
-  init = resolve_nondeduced_context (init, complain);
+  if (BRACE_ENCLOSED_INITIALIZER_P (init))
+/* We don't recurse here because we can't deduce from a nested
+   initializer_list.  */
+for (constructor_elt  : *CONSTRUCTOR_ELTS (init))
+  elt.value = resolve_nondeduced_context (elt.value, complain);
+  else
+init = resolve_nondeduced_context (init, complain);
 
   if (context == adc_decomp_type
   && auto_node == type
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C
new file mode 100644
index 000..b8417d7bf0c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-deduce3.C
@@ -0,0 +1,22 @@
+// PR c++/93107
+// { dg-do compile { target c++11 } }
+
+using size_t = decltype(sizeof 0);
+
+namespace std {
+  template struct initializer_list {
+const T *ptr;
+size_t n;
+initializer_list(const T*, size_t);
+  };
+}
+
+template
+void Task() {}
+
+auto a = ;
+auto b = {  };
+auto e{  };
+auto f = { ,  };
+std::initializer_list c = {  };
+auto d = { static_cast() };

base-commit: 79991e2348a864ace6ea2bf108a7502862f1129f
-- 
2.28.0

RE: [EXTERNAL] Re: [PATCH] [tree-optimization] Fix for PR97223

[Eugene Rozenfeld via Gcc-patches]

Thank you for the review Richard!

I re-worked the patch based on your suggestions. I combined the two patterns. 
Neither one requires a signedness check as long as the type of the 'add' has 
overflow wrap semantics.

I had to modify the regular expression in no-strict-overflow-4.c test. In that 
test the following function is compiled with -fno-strict-overflow :

int
foo (int i)
{
  return i + 1 > i;
}

We now optimize this function so that the tree-optimized dump has

;; Function foo (foo, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=0)

foo (int i)
{
  _Bool _1;
  int _3;

   [local count: 1073741824]:
  _1 = i_2(D) != 2147483647;
  _3 = (int) _1;
  return _3;
}

This is a correct optimization since -fno-strict-overflow implies -fwrapv.

Eugene

-Original Message-
From: Richard Biener  
Sent: Tuesday, October 27, 2020 2:23 AM
To: Eugene Rozenfeld 
Cc: gcc-patches@gcc.gnu.org
Subject: [EXTERNAL] Re: [PATCH] [tree-optimization] Fix for PR97223

On Sat, Oct 24, 2020 at 2:20 AM Eugene Rozenfeld via Gcc-patches 
 wrote:
>
> This patch adds a pattern for folding
> x < (short) ((unsigned short)x + const) to
>  x <= SHORT_MAX - const
> (and similarly for other integral types) if const is not 0.
> as described in PR97223.
>
> For example, without this patch the x86_64-pc-linux code generated for 
> this function
>
> bool f(char x)
> {
> return x < (char)(x + 12);
> }
>
> is
>
> leaeax,[rdi+0xc]
> cmpal,dil
> setg   al
> ret
>
> With the patch the code is
>
> cmpdil,0x73
> setle  al
> ret
>
> Tested on x86_64-pc-linux.

+/* Similar to the previous pattern but with additional casts. */ (for 
+cmp (lt le ge gt)
+ out (gt gt le le)
+ (simplify
+  (cmp:c (convert@3 (plus@2 (convert@4 @0) INTEGER_CST@1)) @0)
+  (if (!TYPE_UNSIGNED (TREE_TYPE (@0))
+   && types_match (TREE_TYPE (@0), TREE_TYPE (@3))
+   && types_match (TREE_TYPE (@4), unsigned_type_for (TREE_TYPE (@0)))
+   && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@4))
+   && wi::to_wide (@1) != 0
+   && single_use (@2))
+   (with { unsigned int prec = TYPE_PRECISION (TREE_TYPE (@0)); }
+(out @0 { wide_int_to_tree (TREE_TYPE (@0),
+   wi::max_value (prec, SIGNED)
+   - wi::to_wide (@1)); })

I think it's reasonable but the comment can be made more precise.
In particular I wonder why we require a signed comparison here while the 
previous pattern requires an unsigned comparison.  It might be an artifact and 
the restriction instead only applies to the plus?

Note that

+   && types_match (TREE_TYPE (@4), unsigned_type_for (TREE_TYPE 
+ (@0)))

unsigned_type_for should be avoided since it's quite expensive.  May I suggest

  && TYPE_UNSIGNED (TREE_TYPE (@4))
  && tree_nop_conversion_p (TREE_TYPE (@4), TREE_TYPE (@0))

instead?

I originally wondered if "but with additional casts" could be done in a single 
pattern via (convert? ...) uses but then I noticed the strange difference in 
the comparison signedness requirement ...

Richard.

> Eugene
>


0001-Add-a-tree-optimization-described-in-PR97223.patch
Description: 0001-Add-a-tree-optimization-described-in-PR97223.patch

Re: PowerPC: Add __float128 conversions to/from Decimal

[Segher Boessenkool]

On Thu, Oct 29, 2020 at 06:31:54PM +, Joseph Myers wrote:
> On Thu, 29 Oct 2020, Segher Boessenkool wrote:
> > On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote:
> > > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote:
> > > > > +#if HAVE_KF_MODE
> > > > > +  strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x);
> > > > > +#else
> > > > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x);
> > > > > +#endif
> > > > 
> > > > Does strfromf128 exist everywhere we build this?  It isn't a standard
> > > > function.
> > > 
> > > Yes, it is in ISO/IEC TS 18661-3, which is the document that describes 
> > > most of
> > > the *f128 functions.
> > 
> > But this means it does *not* exist most places we build this?  Not the
> > whole world is Linux (and even then, it is probably a too recent
> > addition).
> 
> strfromf128 and strtof128 were added for powerpc64le-linux-gnu in glibc 
> 2.26.  (The variants that are namespace-clean in the absence of 18661-3, 
> which may be relevant when being used for long double, __strfromieee128 
> and __strtoieee128, were added in 2.32.)

And we otherwise support at least glibc 2.17 still (that is what RHEL 7
has).

> Doing these conversions accurately is nontrivial.  Converting via strings 
> is the simple approach (i.e. the one that moves the complexity somewhere 
> else).  There are more complicated but more efficient approaches that can 
> achieve correct conversions with smaller bounds on resource usage (and 
> there are various papers published in this area), but those involve a lot 
> more code (and precomputed data, with a speed/space trade-off in how much 
> you precompute; the BID code in libgcc has several MB of precomputed data 
> for that purpose).

Does the printf code in libgcc handle things correctly for IEEE QP float
as long double, do you know?


Segher

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

[Segher Boessenkool]

On Thu, Oct 29, 2020 at 06:02:58PM +, Richard Sandiford wrote:
> Qing Zhao via Gcc-patches  writes:
> >>> +Return-Oriented Programming (ROP) or preventing information leak
> >> 
> >> leakage
> >> 
> >> (FWIW, I'm not sure “mitigating ROP” is really correct usage, but I don't
> >> have any better suggestions.)
> >
> > Do you mean whether “mitigating ROP’ is one of the major purpose of this 
> > new feature?
> 
> No, I meant just the English usage.  E.g., I think you mitigate the
> damage caused by earthquakes rather than mitigate earthquakes themselves.
> But I could be wrong.  It's not a word I use very often ;-)

"Mitigating ROP attacks" is a phrase often used in the literature, sadly
(what is really meant is not "mitigating the effects of ROP attacks",
but simply "making ROP attacks less likely to succeed" -- it is almost
always a binary thing, either it succeeds or it doesn't).


Segher

Re: PowerPC: Update __float128 and __ibm128 error messages.

[Segher Boessenkool]

On Thu, Oct 29, 2020 at 01:03:25PM -0400, Michael Meissner wrote:
> On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote:
> > > +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> > 
> > Use *-*-linux* instead?  (In all relevant tests.)
> 
> Ok.
> 
> > Is there any reason these tests should only run on Linux?  If not, it
> > should not restrict itself like this; and if so, you may want another
> > selsector (something ieee128 perhaps), or at the very least add a
> > comment why you do this.
> 
> Right now the float128 emulation is only built on Linux, because it needs the
> support in GLIBC.  If/when other systems add support for float128 in there
> C/C++ libraries, we can widen the tests.

It still helps to use some new selector -- you only have to change the
implementation of that when such a day will come, instead of 34638
separate testcases.  Also, it is good documentation, helping every
reader (people trying to make sense if the tests, for example).


Segher

Re: [PATCH] arm: Fix multiple inheritance thunks for thumb-1 with -mpure-code

[Richard Earnshaw via Gcc-patches]

On 28/10/2020 18:10, Christophe Lyon via Gcc-patches wrote:
> On Wed, 28 Oct 2020 at 18:44, Richard Earnshaw
>  wrote:
>>
>> On 27/10/2020 15:42, Richard Earnshaw via Gcc-patches wrote:
>>> On 26/10/2020 10:52, Christophe Lyon via Gcc-patches wrote:
 On Thu, 22 Oct 2020 at 17:22, Richard Earnshaw
  wrote:
>
> On 22/10/2020 09:45, Christophe Lyon via Gcc-patches wrote:
>> On Wed, 21 Oct 2020 at 19:36, Richard Earnshaw
>>  wrote:
>>>
>>> On 21/10/2020 17:11, Christophe Lyon via Gcc-patches wrote:
 On Wed, 21 Oct 2020 at 18:07, Richard Earnshaw
  wrote:
>
> On 21/10/2020 16:49, Christophe Lyon via Gcc-patches wrote:
>> On Tue, 20 Oct 2020 at 13:25, Richard Earnshaw
>>  wrote:
>>>
>>> On 20/10/2020 12:22, Richard Earnshaw wrote:
 On 19/10/2020 17:32, Christophe Lyon via Gcc-patches wrote:
> On Mon, 19 Oct 2020 at 16:39, Richard Earnshaw
>  wrote:
>>
>> On 12/10/2020 08:59, Christophe Lyon via Gcc-patches wrote:
>>> On Thu, 8 Oct 2020 at 11:58, Richard Earnshaw
>>>  wrote:

 On 08/10/2020 10:07, Christophe Lyon via Gcc-patches wrote:
> On Tue, 6 Oct 2020 at 18:02, Richard Earnshaw
>  wrote:
>>
>> On 29/09/2020 20:50, Christophe Lyon via Gcc-patches wrote:
>>> When mi_delta is > 255 and -mpure-code is used, we cannot 
>>> load delta
>>> from code memory (like we do without -mpure-code).
>>>
>>> This patch builds the value of mi_delta into r3 with a 
>>> series of
>>> movs/adds/lsls.
>>>
>>> We also do some cleanup by not emitting the function 
>>> address and delta
>>> via .word directives at the end of the thunk since we don't 
>>> use them
>>> with -mpure-code.
>>>
>>> No need for new testcases, this bug was already identified 
>>> by
>>> eg. pr46287-3.C
>>>
>>> 2020-09-29  Christophe Lyon  
>>>
>>>   gcc/
>>>   * config/arm/arm.c (arm_thumb1_mi_thunk): Build 
>>> mi_delta in r3 and
>>>   do not emit function address and delta when 
>>> -mpure-code is used.
>>
> Hi Richard,
>
> Thanks for your comments.
>
>> There are some optimizations you can make to this code.
>>
>> Firstly, for values between 256 and 510 (inclusive), it 
>> would be better
>> to just expand a mov of 255 followed by an add.
> I now see the splitted for the "Pe" constraint which I hadn't 
> noticed
> before, so I can write something similar indeed.
>
> However, I'm note quite sure to understand the benefit in the 
> split
> when -mpure-code is NOT used.
> Consider:
> int f3_1 (void) { return 510; }
> int f3_2 (void) { return 511; }
> Compile with -O2 -mcpu=cortex-m0:
> f3_1:
> movsr0, #255
> lslsr0, r0, #1
> bx  lr
> f3_2:
> ldr r0, .L4
> bx  lr
>
> The splitter makes the code bigger, does it "compensate" for 
> this by
> not having to load the constant?
> Actually the constant uses 4 more bytes, which should be 
> taken into
> account when comparing code size,

 Yes, the size of the literal pool entry needs to be taken into 
 account.
  It might happen that the entry could be shared with another 
 use of that
 literal, but in general that's rare.

> so f3_1 uses 6 bytes, and f3_2 uses 8, so as you say below 
> three
> thumb1 instructions would be equivalent in size compared to 
> loading
> from the literal pool. Should the 256-510 range be extended?

 It's a bit borderline at three instructions when literal pools 
 are not
 expensive to use, but in thumb1 literal pools tend to be quite 
 small due
 to the limited pc offsets we can use.  I think on balance we 

[PATCH 0/3] Enable PGO/LTO build for binutils+gdb

[H.J. Lu via Gcc-patches]

Add the --enable-pgo-build[=lto] configure option.  When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:

0. Pass --plugin to AR and RANLIB.
1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data.
3. Use "make clean" to remove the previous build.
4. Rebuild with -fprofile-use.


H.J. Lu (3):
  GCC: Pass --plugin to AR and RANLIB
  Binutils: Pass --plugin to AR and RANLIB
  Support the PGO build for binutils+gdb

 Makefile.in|  63 -
 Makefile.tpl   |  63 -
 bfd/configure  |  27 +-
 binutils/configure |  27 +-
 config/gcc-plugin.m4   |  28 ++
 configure  | 139 ++-
 configure.ac   |  80 
 gas/configure  |  27 +-
 gprof/configure|  27 +-
 ld/configure   |  27 +-
 libctf/configure   |  27 +-
 libiberty/Makefile.in  |   5 +-
 libiberty/aclocal.m4   |   1 +
 libiberty/configure|  37 
 libiberty/configure.ac |  12 +++
 libtool.m4 |  25 -
 opcodes/configure  |  27 +-
 zlib/configure | 206 -
 18 files changed, 818 insertions(+), 30 deletions(-)

-- 
2.28.0

[PATCH 1/3] GCC: Pass --plugin to AR and RANLIB

[H.J. Lu via Gcc-patches]

Detect GCC LTO plugin.  Pass --plugin to AR and RANLIB to support LTO
build.

* Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@
(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
* configure.ac: Include config/gcc-plugin.m4.
AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION.
* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Pass --plugin to AR and
RANLIB if possible.
* Makefile.in: Regenerated.
* configure: Likewise.

config/

* gcc-plugin.m4 (GCC_PLUGIN_OPTION): New.

libiberty/

* Makefile.in (AR): Add @AR_PLUGIN_OPTION@
(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
(configure_deps): Depend on ../config/gcc-plugin.m4.
* aclocal.m4: Include ../config/gcc-plugin.m4.
* configure.ac: AC_SUBST AR_PLUGIN_OPTION and
RANLIB_PLUGIN_OPTION.
* configure: Regenerated.

zlib/

* configure: Regenerated.
---
 Makefile.in|   5 +-
 Makefile.tpl   |   5 +-
 config/gcc-plugin.m4   |  28 ++
 configure  |  39 
 configure.ac   |  15 +++
 libiberty/Makefile.in  |   5 +-
 libiberty/aclocal.m4   |   1 +
 libiberty/configure|  37 
 libiberty/configure.ac |  12 +++
 libtool.m4 |  25 -
 zlib/configure | 206 -
 11 files changed, 368 insertions(+), 10 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index fe34132f9e..978e777338 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -387,7 +387,7 @@ MAKEINFOFLAGS = --split-size=500
 # -
 
 AS = @AS@
-AR = @AR@
+AR = @AR@ @AR_PLUGIN_OPTION@
 AR_FLAGS = rc
 CC = @CC@
 CXX = @CXX@
@@ -396,7 +396,7 @@ LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
 OBJDUMP = @OBJDUMP@
-RANLIB = @RANLIB@
+RANLIB = @RANLIB@ @RANLIB_PLUGIN_OPTION@
 READELF = @READELF@
 STRIP = @STRIP@
 WINDRES = @WINDRES@
@@ -52633,6 +52633,7 @@ AUTOCONF = autoconf
 $(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/config/acx.m4 \
$(srcdir)/config/override.m4 $(srcdir)/config/proginstall.m4 \
$(srcdir)/config/elf.m4 $(srcdir)/config/isl.m4 \
+   $(srcdir)/config/gcc-plugin.m4 \
$(srcdir)/libtool.m4 $(srcdir)/ltoptions.m4 $(srcdir)/ltsugar.m4 \
$(srcdir)/ltversion.m4 $(srcdir)/lt~obsolete.m4
cd $(srcdir) && $(AUTOCONF)
diff --git a/Makefile.tpl b/Makefile.tpl
index 5b118a8ba4..a280a1498c 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -390,7 +390,7 @@ MAKEINFOFLAGS = --split-size=500
 # -
 
 AS = @AS@
-AR = @AR@
+AR = @AR@ @AR_PLUGIN_OPTION@
 AR_FLAGS = rc
 CC = @CC@
 CXX = @CXX@
@@ -399,7 +399,7 @@ LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
 OBJDUMP = @OBJDUMP@
-RANLIB = @RANLIB@
+RANLIB = @RANLIB@ @RANLIB_PLUGIN_OPTION@
 READELF = @READELF@
 STRIP = @STRIP@
 WINDRES = @WINDRES@
@@ -1967,6 +1967,7 @@ AUTOCONF = autoconf
 $(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/config/acx.m4 \
$(srcdir)/config/override.m4 $(srcdir)/config/proginstall.m4 \
$(srcdir)/config/elf.m4 $(srcdir)/config/isl.m4 \
+   $(srcdir)/config/gcc-plugin.m4 \
$(srcdir)/libtool.m4 $(srcdir)/ltoptions.m4 $(srcdir)/ltsugar.m4 \
$(srcdir)/ltversion.m4 $(srcdir)/lt~obsolete.m4
cd $(srcdir) && $(AUTOCONF)
diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
index 8f27871911..c5b72e9a13 100644
--- a/config/gcc-plugin.m4
+++ b/config/gcc-plugin.m4
@@ -124,3 +124,31 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
  fi
fi
 ])
+
+dnl
+dnl
+dnl GCC_PLUGIN_OPTION
+dnl(SHELL-CODE_HANDLER)
+dnl
+AC_DEFUN([GCC_PLUGIN_OPTION],[dnl
+AC_MSG_CHECKING([for -plugin option])
+
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+plugin_option=
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+if test -n "$plugin_option"; then
+  $1="$plugin_option"
+  AC_MSG_RESULT($plugin_option)
+else
+  AC_MSG_RESULT([no])
+fi
+])
diff --git a/configure b/configure
index 68779feb42..4c9297d378 100755
--- a/configure
+++ b/configure
@@ -616,6 +616,8 @@ GFORTRAN_FOR_TARGET
 GCC_FOR_TARGET
 CXX_FOR_TARGET
 CC_FOR_TARGET
+RANLIB_PLUGIN_OPTION
+AR_PLUGIN_OPTION
 READELF
 OBJDUMP
 OBJCOPY
@@ -10007,6 +10009,43 @@ fi
 
 
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -plugin option" >&5
+$as_echo_n "checking for -plugin option... " >&6; }
+
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+plugin_option=
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  

Re: PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

[will schmidt via Gcc-patches]

On Thu, 2020-10-29 at 13:05 -0400, Michael Meissner wrote:
> On Mon, Oct 26, 2020 at 05:48:48PM -0500, will schmidt wrote:
> > On Thu, 2020-10-22 at 18:15 -0400, Michael Meissner via Gcc-patches 
> > wrote:
> > > PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.
> > > 
> > > This is a new patch.  It turns off the warning about switching
> > > the long double
> > > type via compile line if the GLIBC is 2.32 or newer.  It only
> > > does this if the
> > > languages are C or C++, since those language libraries support
> > > switching the
> > > long double type.  Other languages like Fortran don't have any
> > > current support
> > > to provide both sets of interfaces to the library.
> > > 
> > > 2020-10-21  Michael Meissner  
> > > 
> > >   * config/rs6000/rs6000.c (rs6000_option_override_internal):
> > > Allow
> > >   long double type to be changed for C/C++ if glibc 2.32 or
> > > newer.
> > > ---
> > >  gcc/config/rs6000/rs6000.c | 10 --
> > >  1 file changed, 8 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/gcc/config/rs6000/rs6000.c
> > > b/gcc/config/rs6000/rs6000.c
> > > index 50039c0a53d..940c15f3265 100644
> > > --- a/gcc/config/rs6000/rs6000.c
> > > +++ b/gcc/config/rs6000/rs6000.c
> > > @@ -4158,10 +4158,16 @@ rs6000_option_override_internal (bool
> > > global_init_p)
> > > 
> > >if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT &&
> > > TARGET_LONG_DOUBLE_128)
> > >   {
> > > +   /* Determine if the user can change the default long double
> > > type at
> > > +  compilation time.  Only C and C++ support this, and you
> > > need GLIBC
> > > +  2.32 or newer.  Only issue one warning.  */
> > > static bool warned_change_long_double;
> > > -   if (!warned_change_long_double)
> > > +
> > > +   if (!warned_change_long_double
> > > +   && (!OPTION_GLIBC
> > > +   || (!lang_GNU_C () && !lang_GNU_CXX ())
> > > +   || ((TARGET_GLIBC_MAJOR * 1000) + TARGET_GLIBC_MINOR)
> > > < 2032))
> > >   {
> > > -   warned_change_long_double = true;
> > 
> > Does this need to be added back elsewhere? 
> 
> At the present time, we are not contemplating adding the full support
> to enable
> configuring GCC to use IEEE 128-bit long double in GCC 10 or
> earlier.  This may
> change depending on customer demands.
> 

My question was/is specific with the removal of the assignment

- warned_change_long_double = true;

I didn't see where that line or an equvalent was added back.  It's
either set elsewhere (ok), or no longer used.

Thanks,
-Will

[PATCH 3/3] Support the PGO build for binutils+gdb

[H.J. Lu via Gcc-patches]

Add the --enable-pgo-build[=lto] configure option.  When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:

1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data.
3. Use "make clean" to remove the previous build.
4. Rebuild with -fprofile-use.

With --enable-pgo-build=lto, -flto=jobserver is used together with
-fprofile-generate and -fprofile-use.  Add '+' to the command line for
recursive make to support -flto=jobserver.

NB: --enable-pgo-build=lto enables the PGO build with LTO while
--enable-lto enables LTO support in toolchain.

PR binutils/26766
* Makefile.tpl (BUILD_CFLAGS): New.
(CFLAGS): Append $(BUILD_CFLAGS).
(CXXFLAGS): Likewise.
(PGO_BUILD_GEN_FLAGS_TO_PASS): New.
(PGO_BUILD_TRAINING_CFLAGS): Likewise.
(PGO_BUILD_TRAINING_CXXFLAGS): Likewise.
(PGO_BUILD_TRAINING_FLAGS_TO_PASS): Likewise.
(PGO_BUILD_USE_FLAGS_TO_PASS): Likewise.
(PGO-TRAINING-TARGETS): Likewise.
(PGO_BUILD_TRAINING): Likewise.
(all): Add '+' to the command line for recursive make.  Support
the PGO build.
* configure.ac: Add --enable-pgo-build[=lto].
AC_SUBST PGO_BUILD_GEN_CFLAGS, PGO_BUILD_USE_CFLAGS and
PGO_BUILD_LTO_CFLAGS.  Enable the PGO build in Makefile.
* Makefile.in: Regenerated.
* configure: Likewise.
---
 Makefile.in  |  58 --
 Makefile.tpl |  58 --
 configure| 100 +--
 configure.ac |  65 +
 4 files changed, 275 insertions(+), 6 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 978e777338..2b0633a177 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -412,6 +412,45 @@ CXXFLAGS = @CXXFLAGS@
 LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
 GOCFLAGS = $(CFLAGS)
 
+# Pass additional PGO and LTO compiler options to the PGO build.
+BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
+override CFLAGS += $(BUILD_CFLAGS)
+override CXXFLAGS += $(BUILD_CFLAGS)
+
+# Additional PGO and LTO compiler options to generate profiling data
+# for the PGO build.
+PGO_BUILD_GEN_FLAGS_TO_PASS = \
+   PGO_BUILD_CFLAGS="@PGO_BUILD_GEN_CFLAGS@" \
+   PGO_BUILD_LTO_CFLAGS="@PGO_BUILD_LTO_CFLAGS@"
+
+# NB: Filter out any compiler options which may fail PGO training runs.
+PGO_BUILD_TRAINING_CFLAGS:= \
+   $(filter-out -Werror=%,$(CFLAGS))
+PGO_BUILD_TRAINING_CXXFLAGS:=\
+   $(filter-out -Werror=%,$(CXXFLAGS))
+PGO_BUILD_TRAINING_CFLAGS:= \
+   $(filter-out -Wall,$(PGO_BUILD_TRAINING_CFLAGS))
+PGO_BUILD_TRAINING_CXXFLAGS:= \
+   $(filter-out -Wall,$(PGO_BUILD_TRAINING_CXXFLAGS))
+PGO_BUILD_TRAINING_CFLAGS:= \
+   $(filter-out -specs=%,$(PGO_BUILD_TRAINING_CFLAGS))
+PGO_BUILD_TRAINING_CXXFLAGS:= \
+   $(filter-out -specs=%,$(PGO_BUILD_TRAINING_CXXFLAGS))
+PGO_BUILD_TRAINING_FLAGS_TO_PASS = \
+   CFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CFLAGS)" \
+   CXXFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CXXFLAGS)"
+
+# Additional PGO and LTO compiler options to use profiling data for the
+# PGO build.
+PGO_BUILD_USE_FLAGS_TO_PASS = \
+   PGO_BUILD_CFLAGS="@PGO_BUILD_USE_CFLAGS@" \
+   PGO_BUILD_LTO_CFLAGS="@PGO_BUILD_LTO_CFLAGS@"
+
+# PGO training targets for the PGO build.  FIXME: Add gold tests to
+# training.
+PGO-TRAINING-TARGETS = binutils gas gdb ld sim
+PGO_BUILD_TRAINING = $(addprefix maybe-check-,$(PGO-TRAINING-TARGETS))
+
 CREATE_GCOV = create_gcov
 
 TFLAGS =
@@ -985,6 +1024,12 @@ configure-target:  \
 
 # The target built for a native non-bootstrap build.
 .PHONY: all
+
+# --enable-pgo-build enables the PGO build.
+# 1. First build with -fprofile-generate.
+# 2. Use "make maybe-check-*" to generate profiling data.
+# 3. Use "make clean" to remove the previous build.
+# 4. Rebuild with -fprofile-use.
 all:
 @if gcc-bootstrap
[ -f stage_final ] || echo stage3 > stage_final
@@ -993,7 +1038,7 @@ all:
$(MAKE) $(RECURSE_FLAGS_TO_PASS) `cat stage_final`-bubble
 @endif gcc-bootstrap
@: $(MAKE); $(unstage)
-   @r=`${PWD_COMMAND}`; export r; \
+   +@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
 @if gcc-bootstrap
if [ -f stage_last ]; then \
@@ -1001,7 +1046,16 @@ all:
  $(MAKE) $(TARGET_FLAGS_TO_PASS) all-host all-target; \
else \
 @endif gcc-bootstrap
- $(MAKE) $(RECURSE_FLAGS_TO_PASS) all-host all-target \
+ $(MAKE) $(RECURSE_FLAGS_TO_PASS) \
+   $(PGO_BUILD_GEN_FLAGS_TO_PASS) all-host all-target \
+@if pgo-build
+   && $(MAKE) $(RECURSE_FLAGS_TO_PASS) \
+   $(PGO_BUILD_TRAINING_FLAGS_TO_PASS) \
+   $(PGO_BUILD_TRAINING) \
+   && $(MAKE) $(RECURSE_FLAGS_TO_PASS) clean \
+   && $(MAKE) $(RECURSE_FLAGS_TO_PASS) \
+   $(PGO_BUILD_USE_FLAGS_TO_PASS) all-host all-target \

[PATCH 2/3] Binutils: Pass --plugin to AR and RANLIB

[H.J. Lu via Gcc-patches]

Detect GCC LTO plugin.  Pass --plugin to AR and RANLIB to support LTO
build.

bfd/

* configure: Regenerated.

binutils/

* configure: Regenerated.

gas/

* configure: Regenerated.

gprof/

* configure: Regenerated.

ld/

* configure: Regenerated.

libctf/

* configure: Regenerated.

opcodes/

* configure: Regenerated.
---
 bfd/configure  | 27 +--
 binutils/configure | 27 +--
 gas/configure  | 27 +--
 gprof/configure| 27 +--
 ld/configure   | 27 +--
 libctf/configure   | 27 +--
 opcodes/configure  | 27 +--
 7 files changed, 175 insertions(+), 14 deletions(-)

diff --git a/bfd/configure b/bfd/configure
index 864e78851c..c518d9e5be 100755
--- a/bfd/configure
+++ b/bfd/configure
@@ -6824,6 +6824,19 @@ test -z "$deplibs_check_method" && 
deplibs_check_method=unknown
 
 
 
+plugin_option=
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+
 if test -n "$ac_tool_prefix"; then
   # Extract the first word of "${ac_tool_prefix}ar", so it can be a program 
name with args.
 set dummy ${ac_tool_prefix}ar; ac_word=$2
@@ -6917,6 +6930,11 @@ else
 fi
 
 test -z "$AR" && AR=ar
+if test -n "$plugin_option"; then
+  if $AR --help 2>&1 | grep -q "\--plugin"; then
+AR="$AR $plugin_option"
+  fi
+fi
 test -z "$AR_FLAGS" && AR_FLAGS=cru
 
 
@@ -7121,6 +7139,11 @@ else
 fi
 
 test -z "$RANLIB" && RANLIB=:
+if test -n "$plugin_option" && test "$RANLIB" != ":"; then
+  if $RANLIB --help 2>&1 | grep -q "\--plugin"; then
+RANLIB="$RANLIB $plugin_option"
+  fi
+fi
 
 
 
@@ -11729,7 +11752,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11732 "configure"
+#line 11755 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11835,7 +11858,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11838 "configure"
+#line 11861 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/binutils/configure b/binutils/configure
index 7c3113c6af..c4d19e406e 100755
--- a/binutils/configure
+++ b/binutils/configure
@@ -6616,6 +6616,19 @@ test -z "$deplibs_check_method" && 
deplibs_check_method=unknown
 
 
 
+plugin_option=
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+
 if test -n "$ac_tool_prefix"; then
   # Extract the first word of "${ac_tool_prefix}ar", so it can be a program 
name with args.
 set dummy ${ac_tool_prefix}ar; ac_word=$2
@@ -6709,6 +6722,11 @@ else
 fi
 
 test -z "$AR" && AR=ar
+if test -n "$plugin_option"; then
+  if $AR --help 2>&1 | grep -q "\--plugin"; then
+AR="$AR $plugin_option"
+  fi
+fi
 test -z "$AR_FLAGS" && AR_FLAGS=cru
 
 
@@ -6913,6 +6931,11 @@ else
 fi
 
 test -z "$RANLIB" && RANLIB=:
+if test -n "$plugin_option" && test "$RANLIB" != ":"; then
+  if $RANLIB --help 2>&1 | grep -q "\--plugin"; then
+RANLIB="$RANLIB $plugin_option"
+  fi
+fi
 
 
 
@@ -11552,7 +11575,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11555 "configure"
+#line 11578 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11658,7 +11681,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11661 "configure"
+#line 11684 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/gas/configure b/gas/configure
index c1fff579c6..6b87cc2401 100755
--- a/gas/configure
+++ b/gas/configure
@@ -6408,6 +6408,19 @@ test -z "$deplibs_check_method" && 
deplibs_check_method=unknown
 
 
 
+plugin_option=
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+
 if test -n "$ac_tool_prefix"; then
   # Extract the first word of "${ac_tool_prefix}ar", so it can be a program 
name with args.
 set dummy 

Re: PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.

[Segher Boessenkool]

On Thu, Oct 29, 2020 at 12:56:03PM -0400, Michael Meissner wrote:
> On Wed, Oct 28, 2020 at 04:58:46PM -0500, Segher Boessenkool wrote:
> > >  #if defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IBM128__)
> > > \
> > >  && !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__))
> > >return __builtin_pack_longdouble (dh, dl);
> > > +#elif defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IEEE128__) 
> > > \
> > > +&& !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__))
> > > +  return __builtin_pack_ibm128 (dh, dl);
> > 
> > Given the above, _SOFT_FLOAT etc. are wrong.
> > 
> > Just use some more portable thing to repack?  Is __builtin_pack_ibm128
> > not defined always here anyway?
> 
> That is the problem.  If you build a big endian PowerPC compiler where VSX is
> not default, the __ibm128 stuff is not defined.  It is only defined when
> __float128 is a possibility.  Hence __builtin_pack_ibm128 and
> __builtin_unpack_ibm128 are not defined.

So fix that?  When ibm128 is the only thing supported there is no reason
why __builtin_{un,}pack_ibm128 should not be supported (the ieee128
functions of course not, but there is no reason to not define the normal
names for the one supported thing).

> > /* 128-bit __ibm128 floating point builtins (use -mfloat128 to indicate that
> >__ibm128 is available).  */
> > #define BU_IBM128_2(ENUM, NAME, ATTR, ICODE)\
> >   RS6000_BUILTIN_2 (MISC_BUILTIN_ ## ENUM,  /* ENUM */  \
> > "__builtin_" NAME,  /* NAME */  \
> > (RS6000_BTM_HARD_FLOAT  /* MASK */  \
> >  | RS6000_BTM_FLOAT128),\
> > (RS6000_BTC_ ## ATTR/* ATTR */  \
> >  | RS6000_BTC_BINARY),  \
> > CODE_FOR_ ## ICODE) /* ICODE */
> > 
> > (so just HARD_FLOAT and FLOAT128 are needed)
> > 
> > What am I missing?
> 
> As I said, the __ibm128 keyword is not enabled on non-VSX systems.

So fix that?  It can easily be supported everywhere, after all.


Segher

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

[Segher Boessenkool]

On Thu, Oct 29, 2020 at 12:50:10PM -0400, Michael Meissner wrote:
> On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote:
> > On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote:
> > > This patch adds long double variants of the power10 __float128 built-in
> > > functions.  This is needed when long double uses IEEE 128-bit because
> > > __float128 uses TFmode in this case instead of KFmode.  If this patch is 
> > > not
> > > applied, these built-in functions can't be used when long double is IEEE
> > > 128-bit.
> > 
> > But now they still cannot, you need new builtins, instead.
> > 
> > TFmode is an implementation detail at this level (functions use types,
> > not modes), so you do not need new builtins at all afaics?  Just define
> > the existing ones with TFmode as well (if that is the same as KFmode)?
> 
> In order to add new overloaded built-ins, you have to add a new built-in with 
> a
> new name.

I do not follow?  Just delete the old non-overloaded one and add the
overloaded one with that same old name at the same time.

TF is a nasty name, it means a different thing externally (in the libgcc
function names, say: always IFmode) and internally (it varies what it
means).

> Maybe when Bill finally reorganizes the built-in functions, we can do anyway
> with having to create new named functions.  But for now, in order to add them,
> you need a name.

Of course.  And there already is a name :-)


Segher

Re: PowerPC: Add __float128 conversions to/from Decimal

[Joseph Myers]

On Thu, 29 Oct 2020, Segher Boessenkool wrote:

> Hi!
> 
> On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote:
> > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote:
> > > > +#if HAVE_KF_MODE
> > > > +  strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x);
> > > > +#else
> > > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x);
> > > > +#endif
> > > 
> > > Does strfromf128 exist everywhere we build this?  It isn't a standard
> > > function.
> > 
> > Yes, it is in ISO/IEC TS 18661-3, which is the document that describes most 
> > of
> > the *f128 functions.
> 
> But this means it does *not* exist most places we build this?  Not the
> whole world is Linux (and even then, it is probably a too recent
> addition).

strfromf128 and strtof128 were added for powerpc64le-linux-gnu in glibc 
2.26.  (The variants that are namespace-clean in the absence of 18661-3, 
which may be relevant when being used for long double, __strfromieee128 
and __strtoieee128, were added in 2.32.)

Doing these conversions accurately is nontrivial.  Converting via strings 
is the simple approach (i.e. the one that moves the complexity somewhere 
else).  There are more complicated but more efficient approaches that can 
achieve correct conversions with smaller bounds on resource usage (and 
there are various papers published in this area), but those involve a lot 
more code (and precomputed data, with a speed/space trade-off in how much 
you precompute; the BID code in libgcc has several MB of precomputed data 
for that purpose).

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

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

[Segher Boessenkool]

On Thu, Oct 29, 2020 at 12:47:20PM -0400, Michael Meissner wrote:
> On Tue, Oct 27, 2020 at 09:38:20AM -0500, will schmidt wrote:
> > > @@ -2420,6 +2423,8 @@ BU_P9V_64BIT_VSX_2 (VSIEDPF,
> > > "scalar_insert_exp_dp", CONST,  xsiexpdpf)
> > > 
> > >  BU_FLOAT128_HW_VSX_2 (VSIEQP,"scalar_insert_exp_q",  CONST,  
> > > xsiexpqp_kf)
> > >  BU_FLOAT128_HW_VSX_2 (VSIEQPF,   "scalar_insert_exp_qp", CONST,  
> > > xsiexpqpf_kf)
> > > +BU_FLOAT128_HW_VSX_2 (VSIETF,"scalar_insert_exp_tf", CONST,  
> > > xsiexpqp_tf)
> > > +BU_FLOAT128_HW_VSX_2 (VSIETFF,   "scalar_insert_exp_tfp", CONST, 
> > > xsiexpqpf_tf)
> > 
> > Ok if its ok, but the pattern catches my eye.  Should that be VSIETFP ?
> > (or named "scalar_insert_exp_tff")?
> 
> That is the existing function in the library.  All I'm doing is adding TF
> versions of the existing functions.

Sure, but logically the macro for scalar_insert_exp_tfp would be VSIETFP
(instead of VSIETF) (and that is a new macro name fwiw).  So please fix
that?


Segher

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

[Jason Merrill via Gcc-patches]

On 10/29/20 2:11 PM, Marek Polacek wrote:

On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches wrote:

On 10/28/20 7:40 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote:

On 10/28/20 1:58 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches wrote:

On 10/24/20 7:40 PM, Marek Polacek wrote:

On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason Merrill via Gcc-patches wrote:

On 10/23/20 3:01 PM, Marek Polacek wrote:

This patch implements the -Wvexing-parse warning to warn about the
sneaky most vexing parse rule in C++: the cases when a declaration
looks like a variable definition, but the C++ language requires it
to be interpreted as a function declaration.  This warning is on by
default (like clang++).  From the docs:

   void f(double a) {
 int i();// extern int i (void);
 int n(int(a));  // extern int n (int);
   }

   Another example:

   struct S { S(int); };
   void f(double a) {
 S x(int(a));   // extern struct S x (int);
 S y(int());// extern struct S y (int (*) (void));
 S z(); // extern struct S z (void);
   }

You can find more on this in [dcl.ambig.res].

I spent a fair amount of time on fix-it hints so that GCC can recommend
various ways to resolve such an ambiguity.  Sometimes that's tricky.
E.g., suggesting default-initialization when the class doesn't have
a default constructor would not be optimal.  Suggesting {}-init is also
not trivial because it can use an initializer-list constructor if no
default constructor is available (which ()-init wouldn't do).  And of
course, pre-C++11, we shouldn't be recommending {}-init at all.


What do you think of, instead of passing the type down into the declarator
parse, adding the paren locations to cp_declarator::function and giving the
diagnostic from cp_parser_init_declarator instead?


Oops, now I see there's already cp_declarator::parenthesized; might as well
reuse that.  And maybe change it to a range, while we're at it.


I'm afraid I can't reuse it because grokdeclarator uses it to warn about
"unnecessary parentheses in declaration".  So when we have:

 int (x());

declarator->parenthesized points to the outer parens (if any), whereas
declarator->u.function.parens_loc should point to the inner ones.  We also
have declarator->id_loc but I think we should only use it for declarator-ids.


Makes sense.


(We should still adjust ->parenthesized to be a range to generate a better
diagnostic; I shall send a patch soon.)


Hmm, I wonder why we have the parenthesized_p parameter to some of these
functions, since we can look at the declarator to find that information...


That would be a nice cleanup.


Interesting idea.  I suppose it's better, and makes the implementation
more localized.  The approach here is that if the .function.parens_loc
is UNKNOWN_LOCATION, we've not seen a vexing parse.


I'd rather always set the parens location, and then analyze the
cp_declarator in warn_about_ambiguous_parse to see if it's a vexing parse;
we should have all the information we need.


I could always set .parens_loc, but then I'd still need another flag telling
me whether we had an ambiguity.  Otherwise I don't know how I would tell
apart e.g. "int f()" (warn) v. "int f(void)" (don't warn), etc.


Ah, I was thinking that we still had the parameter declarators, but now I
see that cp_parser_parameter_declaration_list groks them and returns a
TREE_LIST.  We could set a TREE_LANG_FLAG on each TREE_LIST if its parameter
declarator was parenthesized?


I think so, looks like we have a bunch of free TREE_LANG_FLAG slots on
a TREE_LIST.  But cp_parser_parameter_declaration_clause can return
a void_list_node, so I assume I'd have to copy_node it before setting
some new flag in it.  Do you think that'd be fine?


There's no declarator in a void_list_node, so we shouldn't need to set a
"declarator is parenthesized" flag on it.


I guess I'm still not clear on how I would distinguish between
int f() and int f(void).  When I look at the cdk_function declarator,
all I can see is the .parameters TREE_LIST, which for both cases will
be the same void_list_node, but we should only warn for the former.

What am I missing?


I'm just being dense.  You're right that we would need to distinguish 
those two.  Perhaps an explicit_void_parms_node or something like that 
for during parsing; it looks like grokparms will turn it into 
void_list_node as other code expects.


Jason

[PATCH] LTO: get_section: add new argument

[Martin Liška]

One more backport I've just tested:

gcc/ChangeLog:

PR lto/97508
* langhooks.c (lhd_begin_section): Call get_section with
not_existing = true.
* output.h (get_section): Add new argument.
* varasm.c (get_section): Fail when NOT_EXISTING is true
and a section already exists.
* ipa-cp.c (ipcp_write_summary): Remove.
(ipcp_read_summary): Likewise.
* ipa-fnsummary.c (ipa_fn_summary_read): Always read jump
functions summary.
(ipa_fn_summary_write): Always stream it.

(cherry picked from commit 568de14d2e74cfdd600b8995ff6ac08c98ddef48)
---
 gcc/ipa-cp.c| 20 ++--
 gcc/ipa-fnsummary.c |  6 ++
 gcc/langhooks.c |  2 +-
 gcc/output.h|  3 ++-
 gcc/varasm.c|  9 +++--
 5 files changed, 14 insertions(+), 26 deletions(-)

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index c7867dbed9b..b1f0881bd70 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -5946,22 +5946,6 @@ ipcp_generate_summary (void)
 ipa_analyze_node (node);
 }
 
-/* Write ipcp summary for nodes in SET.  */

-
-static void
-ipcp_write_summary (void)
-{
-  ipa_prop_write_jump_functions ();
-}
-
-/* Read ipcp summary.  */
-
-static void
-ipcp_read_summary (void)
-{
-  ipa_prop_read_jump_functions ();
-}
-
 namespace {
 
 const pass_data pass_data_ipa_cp =

@@ -5983,8 +5967,8 @@ public:
   pass_ipa_cp (gcc::context *ctxt)
 : ipa_opt_pass_d (pass_data_ipa_cp, ctxt,
  ipcp_generate_summary, /* generate_summary */
- ipcp_write_summary, /* write_summary */
- ipcp_read_summary, /* read_summary */
+ NULL, /* write_summary */
+ NULL, /* read_summary */
  ipcp_write_transformation_summaries, /*
  write_optimization_summary */
  ipcp_read_transformation_summaries, /*
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index 55a0b272a96..e07c9b3bba0 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -4346,6 +4346,7 @@ ipa_fn_summary_read (void)
   struct lto_file_decl_data *file_data;
   unsigned int j = 0;
 
+  ipa_prop_read_jump_functions ();

   ipa_fn_summary_alloc ();
 
   while ((file_data = file_data_vec[j++]))

@@ -4364,8 +4365,6 @@ ipa_fn_summary_read (void)
 "ipa inline summary is missing in input file");
 }
   ipa_register_cgraph_hooks ();
-  if (!flag_ipa_cp)
-ipa_prop_read_jump_functions ();
 
   gcc_assert (ipa_fn_summaries);

   ipa_fn_summaries->enable_insertion_hook ();
@@ -4500,8 +4499,7 @@ ipa_fn_summary_write (void)
   produce_asm (ob, NULL);
   destroy_output_block (ob);
 
-  if (!flag_ipa_cp)

-ipa_prop_write_jump_functions ();
+  ipa_prop_write_jump_functions ();
 }
 
 
diff --git a/gcc/langhooks.c b/gcc/langhooks.c

index 5e3216da631..70a554c4447 100644
--- a/gcc/langhooks.c
+++ b/gcc/langhooks.c
@@ -777,7 +777,7 @@ lhd_begin_section (const char *name)
 saved_section = text_section;
 
   /* Create a new section and switch to it.  */

-  section = get_section (name, SECTION_DEBUG | SECTION_EXCLUDE, NULL);
+  section = get_section (name, SECTION_DEBUG | SECTION_EXCLUDE, NULL, true);
   switch_to_section (section);
 }
 
diff --git a/gcc/output.h b/gcc/output.h

index eb253c50329..2f2f1697fd8 100644
--- a/gcc/output.h
+++ b/gcc/output.h
@@ -523,7 +523,8 @@ extern GTY(()) bool in_cold_section_p;
 
 extern section *get_unnamed_section (unsigned int, void (*) (const void *),

 const void *);
-extern section *get_section (const char *, unsigned int, tree);
+extern section *get_section (const char *, unsigned int, tree,
+bool not_existing = false);
 extern section *get_named_section (tree, const char *, int);
 extern section *get_variable_section (tree, bool);
 extern void place_block_symbol (rtx);
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 5bf4e96a773..0e7531926f8 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -276,10 +276,12 @@ get_noswitch_section (unsigned int flags, 
noswitch_section_callback callback)
 }
 
 /* Return the named section structure associated with NAME.  Create

-   a new section with the given fields if no such structure exists.  */
+   a new section with the given fields if no such structure exists.
+   When NOT_EXISTING, then fail if the section already exists.  */
 
 section *

-get_section (const char *name, unsigned int flags, tree decl)
+get_section (const char *name, unsigned int flags, tree decl,
+bool not_existing)
 {
   section *sect, **slot;
 
@@ -296,6 +298,9 @@ get_section (const char *name, unsigned int flags, tree decl)

 }
   else
 {
+  if (not_existing)
+   internal_error ("Section already exists: %qs", name);
+
   sect = *slot;
   /* It is fine if one of the sections has SECTION_NOTYPE as long as
  the other has none of the contrary flags (see the logic at the end

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

[Marek Polacek via Gcc-patches]

On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches wrote:
> On 10/28/20 7:40 PM, Marek Polacek wrote:
> > On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote:
> > > On 10/28/20 1:58 PM, Marek Polacek wrote:
> > > > On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches 
> > > > wrote:
> > > > > On 10/24/20 7:40 PM, Marek Polacek wrote:
> > > > > > On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason Merrill via 
> > > > > > Gcc-patches wrote:
> > > > > > > On 10/23/20 3:01 PM, Marek Polacek wrote:
> > > > > > > > This patch implements the -Wvexing-parse warning to warn about 
> > > > > > > > the
> > > > > > > > sneaky most vexing parse rule in C++: the cases when a 
> > > > > > > > declaration
> > > > > > > > looks like a variable definition, but the C++ language requires 
> > > > > > > > it
> > > > > > > > to be interpreted as a function declaration.  This warning is 
> > > > > > > > on by
> > > > > > > > default (like clang++).  From the docs:
> > > > > > > > 
> > > > > > > >   void f(double a) {
> > > > > > > > int i();// extern int i (void);
> > > > > > > > int n(int(a));  // extern int n (int);
> > > > > > > >   }
> > > > > > > > 
> > > > > > > >   Another example:
> > > > > > > > 
> > > > > > > >   struct S { S(int); };
> > > > > > > >   void f(double a) {
> > > > > > > > S x(int(a));   // extern struct S x (int);
> > > > > > > > S y(int());// extern struct S y (int (*) (void));
> > > > > > > > S z(); // extern struct S z (void);
> > > > > > > >   }
> > > > > > > > 
> > > > > > > > You can find more on this in [dcl.ambig.res].
> > > > > > > > 
> > > > > > > > I spent a fair amount of time on fix-it hints so that GCC can 
> > > > > > > > recommend
> > > > > > > > various ways to resolve such an ambiguity.  Sometimes that's 
> > > > > > > > tricky.
> > > > > > > > E.g., suggesting default-initialization when the class doesn't 
> > > > > > > > have
> > > > > > > > a default constructor would not be optimal.  Suggesting {}-init 
> > > > > > > > is also
> > > > > > > > not trivial because it can use an initializer-list constructor 
> > > > > > > > if no
> > > > > > > > default constructor is available (which ()-init wouldn't do).  
> > > > > > > > And of
> > > > > > > > course, pre-C++11, we shouldn't be recommending {}-init at all.
> > > > > > > 
> > > > > > > What do you think of, instead of passing the type down into the 
> > > > > > > declarator
> > > > > > > parse, adding the paren locations to cp_declarator::function and 
> > > > > > > giving the
> > > > > > > diagnostic from cp_parser_init_declarator instead?
> > > > > 
> > > > > Oops, now I see there's already cp_declarator::parenthesized; might 
> > > > > as well
> > > > > reuse that.  And maybe change it to a range, while we're at it.
> > > > 
> > > > I'm afraid I can't reuse it because grokdeclarator uses it to warn about
> > > > "unnecessary parentheses in declaration".  So when we have:
> > > > 
> > > > int (x());
> > > > 
> > > > declarator->parenthesized points to the outer parens (if any), whereas
> > > > declarator->u.function.parens_loc should point to the inner ones.  We 
> > > > also
> > > > have declarator->id_loc but I think we should only use it for 
> > > > declarator-ids.
> > > 
> > > Makes sense.
> > > 
> > > > (We should still adjust ->parenthesized to be a range to generate a 
> > > > better
> > > > diagnostic; I shall send a patch soon.)
> > > > 
> > > > > Hmm, I wonder why we have the parenthesized_p parameter to some of 
> > > > > these
> > > > > functions, since we can look at the declarator to find that 
> > > > > information...
> > > > 
> > > > That would be a nice cleanup.
> > > > 
> > > > > > Interesting idea.  I suppose it's better, and makes the 
> > > > > > implementation
> > > > > > more localized.  The approach here is that if the 
> > > > > > .function.parens_loc
> > > > > > is UNKNOWN_LOCATION, we've not seen a vexing parse.
> > > > > 
> > > > > I'd rather always set the parens location, and then analyze the
> > > > > cp_declarator in warn_about_ambiguous_parse to see if it's a vexing 
> > > > > parse;
> > > > > we should have all the information we need.
> > > > 
> > > > I could always set .parens_loc, but then I'd still need another flag 
> > > > telling
> > > > me whether we had an ambiguity.  Otherwise I don't know how I would tell
> > > > apart e.g. "int f()" (warn) v. "int f(void)" (don't warn), etc.
> > > 
> > > Ah, I was thinking that we still had the parameter declarators, but now I
> > > see that cp_parser_parameter_declaration_list groks them and returns a
> > > TREE_LIST.  We could set a TREE_LANG_FLAG on each TREE_LIST if its 
> > > parameter
> > > declarator was parenthesized?
> > 
> > I think so, looks like we have a bunch of free TREE_LANG_FLAG slots on
> > a TREE_LIST.  But cp_parser_parameter_declaration_clause can return
> > a void_list_node, so I assume I'd have 

Re: PowerPC: Add __float128 conversions to/from Decimal

[Segher Boessenkool]

Hi!

On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote:
> On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote:
> > > +#if HAVE_KF_MODE
> > > +  strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x);
> > > +#else
> > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x);
> > > +#endif
> > 
> > Does strfromf128 exist everywhere we build this?  It isn't a standard
> > function.
> 
> Yes, it is in ISO/IEC TS 18661-3, which is the document that describes most of
> the *f128 functions.

But this means it does *not* exist most places we build this?  Not the
whole world is Linux (and even then, it is probably a too recent
addition).

Does it need something in libibiberty maybe?  At least _doprnt handles
long double (whatever type it uses for that, but that can be fixed :-) )
(_doprint is used by all the libiberty versions of the printf family,
and it handles %lf etc. for long double.)

> We have to use str* instead of sprintf or scanf, because I don't believe their
> is a float128 format specifier.

No standard one at least, yes.

> > > +/* Support PowerPC KF mode, which is __float128 when long double is
> > > +   IBM extended double.  */
> > > +#if defined (L_sd_to_kf) || defined (L_dd_to_kf) || defined (L_td_to_kf) 
> > > \
> > > + || defined (L_kf_to_sd) || defined (L_kf_to_dd) || defined (L_kf_to_td)
> > > +#define HAVE_KF_MODE 1
> > > +#endif
> > 
> > This might want a better name, other targets can have a KFmode as well,
> > for some completely different purpose, since it is not a standard mode.
> 
> Given everything else uses *F, including XF on the x86, I figured it was 
> easier
> than creating a new name.

I mean the name for the macro.  "HAVE_KF_MODE" is not great.

Anyway, some libgcc maintainer needs to review this, you may be lucky
with this ;-)


Segher

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

[Richard Sandiford via Gcc-patches]

Qing Zhao  writes:
> Now, the documentation (gcc.info) is like following, let me know any issue 
> there:

Yeah, looks good apart from merging

>  In order to satisfy users with different security needs and control
>  the run-time overhead at the same time, CHOICE parameter provides a
>  flexible way to choose the subset of the call-used registers to be
>  zeroed.
>
>  The three basic values of CHOICE are:

this into a single paragraph.

Thanks,
Richard

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

[Richard Sandiford via Gcc-patches]

Qing Zhao via Gcc-patches  writes:
>>> +Return-Oriented Programming (ROP) or preventing information leak
>> 
>> leakage
>> 
>> (FWIW, I'm not sure “mitigating ROP” is really correct usage, but I don't
>> have any better suggestions.)
>
> Do you mean whether “mitigating ROP’ is one of the major purpose of this new 
> feature?

No, I meant just the English usage.  E.g., I think you mitigate the
damage caused by earthquakes rather than mitigate earthquakes themselves.
But I could be wrong.  It's not a word I use very often ;-)

>>> +In order to satisfy users with different security needs and control the
>>> +run-time overhead at the same time, GCC provides a flexible way to choose
>>> +the subset of the call-used registers to be zeroed.
>> 
>> Maybe s/GCC/the @var{choice} parameter/.
> Okay.
>> 
>>> +
>>> +The three basic values of @var{choice} are:
>> 
>> After which, I think this should be part of the previous paragraph.
>
> Don’t understand here, could you explain a little bit more?

I meant:

In order to satisfy users with different security needs and control the
run-time overhead at the same time, @var{choice} provides a flexible way
to choose the subset of the call-used registers to be zeroed.  The three
basic values of @var{choice} are:

>>> +  /* If gpr_only is true, only zero call-used registers that are
>>> + general-purpose registers; if used_only is true, only zero
>>> + call-used registers that are used in the current function;
>>> + if arg_only is true, only zero call-used registers that pass
>>> + parameters defined by the flatform's calling conversion.  */
>>> +
>>> +  gpr_only = crtl->zero_call_used_regs & ONLY_GPR;
>>> +  used_only = crtl->zero_call_used_regs & ONLY_USED;
>>> +  arg_only = crtl->zero_call_used_regs & ONLY_ARG;
>> 
>> Guess it would be nice to be consistent about which side the “only”
>> goes on.  FWIW, I don't mind which way: GPR_ONLY etc. would be
>> OK with me if you prefer that.
> The current names are okay for me.

OK.  But I think one of them should change to match the other.
E.g. either the local variable should be “only_gpr” or the
flag should be “GPR_ONLY”.

Thanks,
Richard

Re: [PATCH][AArch64] ACLE intrinsics: convert from BFloat16 to Float32

[Richard Sandiford via Gcc-patches]

Dennis Zhang  writes:
> diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def 
> b/gcc/config/aarch64/aarch64-simd-builtins.def
> index 5bc596dbffc..b68c3ca7f4b 100644
> --- a/gcc/config/aarch64/aarch64-simd-builtins.def
> +++ b/gcc/config/aarch64/aarch64-simd-builtins.def
> @@ -732,3 +732,8 @@
>VAR1 (UNOP, bfcvtn_q, 0, ALL, v8bf)
>VAR1 (BINOP, bfcvtn2, 0, ALL, v8bf)
>VAR1 (UNOP, bfcvt, 0, ALL, bf)
> +
> +  /* Implemented by aarch64_{v}bfcvt{_high}.  */
> +  VAR2 (UNOP, vbfcvt, 0, ALL, v4bf, v8bf)
> +  VAR1 (UNOP, vbfcvt_high, 0, ALL, v8bf)
> +  VAR1 (UNOP, bfcvt, 0, ALL, sf)

New intrinsics should use something more specific than “ALL”.
Since these functions are pure non-trapping integer operations,
I think they should use “AUTO_FP” instead.  (On reflection,
we should probably change the name.)

> +(define_insn "aarch64_bfcvtsf"
> +  [(set (match_operand:SF 0 "register_operand" "=w")
> + (unspec:SF [(match_operand:BF 1 "register_operand" "w")]
> + UNSPEC_BFCVT))]
> +  "TARGET_BF16_FP"
> +  "shl\\t%d0, %d1, #16"
> +  [(set_attr "type" "neon_shift_reg")]

I think this should be neon_shift_imm instead.

OK with those changes, thanks.

Richard

Re: Avoid char[] array in tree_def

[Richard Biener]

On Thu, 29 Oct 2020, Jakub Jelinek wrote:

> On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> > > 
> > > That's ugly and will for sure defeat warning / access code
> > > when we access this as char[], no?  I mean, we could
> > > as well use 'int str[1];' here?
> > 
> > Well, we always get char pointer via macro that is IMO OK, but I am also
> > not very much in love with this.
> 
> Do we treat signed char [...]; as typeless storage too, or just
> what the C++ standard requires (i.e. char, unsigned char and std::byte
> where the last one is enum type with unsigned char underlying type)?

All that is covered by is_byte_access_type which includes all
character types (including char16_t and wchar it seems) and std::byte.

Richard.

>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend

Re: [PATCH] libstdc++: remove an ignored qualifier on function return type

[Jonathan Wakely via Gcc-patches]

On Fri, 28 Aug 2020 at 07:56, Krystian Kuźniarek via Libstdc++
 wrote:
>
> > So then you need to produce a changelog entry by hand.
> I had this problem on some old Ubuntu 18.04. Anyway, here's new ChangeLog:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/variant: Fix -Wignored-qualifiers
> in system headers.
>
>
> >That doesn't test this header at all.
> It does but indirectly. What I meant by manual test was:
> ${GCC_GIT} -E contains_only_stdcpp_include.cpp > preprocessed.cpp
> ${GCC_GIT} -Wall -Wextra -pedantic -fsyntax-only preprocessed.cpp
> By manipulating GCC_GIT variable to trunk GCC and patched GCC, I checked if
> the warning is gone.
>
> >What about the libstdc++ testsuite?
> I hope you mean calling make bootstrap and make check. If that's ok, I
> confirm it works on Manjaro and Ubuntu 18.04 with gcc10 and gcc8
> respectively.
>
> >I don't remember exactly why I put it there, but I seem to recall it
> >was necessary.
> I don't know your reasons but I can only tell that this patch seems to
> compile and work just fine.

I see new test failures with that change:

include/variant:1039: error: invalid conversion from
'std::enable_if_t (*)(test02()::Visitor&&,
std::variant&)' {aka 'void (*)(test02()::Visitor&&,
std::variant&)'} to
'std::__detail::__variant::_Multi_array&)>::__untag_result&)>::element_type' {aka 'const void
(*)(test02()::Visitor&&, std::variant&)'} [-fpermissive]
UNRESOLVED: 20_util/variant/visit_r.cc compilation failed to produce executable


So I still think it's there for a reason.

[PATCH] aarch64: Add backend support for expanding __builtin_memset

[Sudakshina Das via Gcc-patches]

Hi

This patch implements aarch64 backend expansion for __builtin_memset. Most of 
the
implementation is based on the expansion of __builtin_memcpy. We change the 
values of
SET_RATIO and MOVE_RATIO for cases where we do not have to strictly align and 
where
we can benefit from NEON instructions in the backend.

So for a test case like:

void foo (void* p) { __builtin_memset (p, 1, 7); }

instead of generating:
mov w3, 16843009
mov w2, 257
mov w1, 1
str w3, [x0]
strhw2, [x0, 4]
strbw1, [x0, 6]
ret
we now generate
moviv0.16b, 0x1
str s0, [x0]
str s0, [x0, 3]
ret

Bootstrapped and regression tested on aarch64-none-linux-gnu.
With this patch I have seen an overall improvement of 0.27% in Spec2017 Int
and 0.19% in Spec2017 FP benchmarks on Neoverse N1.

Is this ok for trunk?

gcc/ChangeLog:

2020-xx-xx  Sudakshina Das  

* config/aarch64/aarch64-protos.h (aarch64_expand_setmem): New
declaration.
* config/aarch64/aarch64.c (aarch64_gen_store_pair): Add case for
E_V16QImode.
(aarch64_set_one_block_and_progress_pointer): New helper for
aarch64_expand_setmem.
(aarch64_expand_setmem): Define the expansion for memset.
* config/aarch64/aarch64.h (CLEAR_RATIO): Tweak to favor
aarch64_expand_setmem when allowed and profitable.
(SET_RATIO): Likewise.
* config/aarch64/aarch64.md: Define pattern for setmemdi.

gcc/testsuite/ChangeLog:

2020-xx-xx  Sudakshina Das  

* g++.dg/tree-ssa/pr90883.C: Remove xfail for aarch64.
* gcc.dg/tree-prof/stringop-2.c: Add xfail for aarch64.
* gcc.target/aarch64/memset-corner-cases.c: New test.
* gcc.target/aarch64/memset-q-reg.c: New test.

Thanks
Sudi

### Attachment also inlined for ease of reply###

diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 
7a34c841355bad88365381912b163c61c5a35811..2aa3f1fddaafae58f0bfb26e5b33fe6a94e85e06
 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -510,6 +510,7 @@ bool aarch64_emit_approx_div (rtx, rtx, rtx);
 bool aarch64_emit_approx_sqrt (rtx, rtx, bool);
 void aarch64_expand_call (rtx, rtx, rtx, bool);
 bool aarch64_expand_cpymem (rtx *);
+bool aarch64_expand_setmem (rtx *);
 bool aarch64_float_const_zero_rtx_p (rtx);
 bool aarch64_float_const_rtx_p (rtx);
 bool aarch64_function_arg_regno_p (unsigned);
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 
00b5f8438863bb52c348cfafd5d4db478fe248a7..bcb654809c9662db0f51fc1368e37e42969efd29
 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -1024,16 +1024,18 @@ typedef struct
 #define MOVE_RATIO(speed) \
   (!STRICT_ALIGNMENT ? 2 : (((speed) ? 15 : AARCH64_CALL_RATIO) / 2))
 
-/* For CLEAR_RATIO, when optimizing for size, give a better estimate
-   of the length of a memset call, but use the default otherwise.  */
+/* Like MOVE_RATIO, without -mstrict-align, make decisions in "setmem" when
+   we would use more than 3 scalar instructions.
+   Otherwise follow a sensible default: when optimizing for size, give a better
+   estimate of the length of a memset call, but use the default otherwise.  */
 #define CLEAR_RATIO(speed) \
-  ((speed) ? 15 : AARCH64_CALL_RATIO)
+  (!STRICT_ALIGNMENT ? 4 : (speed) ? 15 : AARCH64_CALL_RATIO)
 
 /* SET_RATIO is similar to CLEAR_RATIO, but for a non-zero constant, so when
optimizing for size adjust the ratio to account for the overhead of loading
the constant.  */
 #define SET_RATIO(speed) \
-  ((speed) ? 15 : AARCH64_CALL_RATIO - 2)
+  (!STRICT_ALIGNMENT ? 0 : (speed) ? 15 : AARCH64_CALL_RATIO - 2)
 
 /* Disable auto-increment in move_by_pieces et al.  Use of auto-increment is
rarely a good idea in straight-line code since it adds an extra address
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 
a8cc545c37044345c3f1d3bf09151c8a9578a032..16ac0c076adcc82627af43473a938e78d3a7ecdc
 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -7058,6 +7058,9 @@ aarch64_gen_store_pair (machine_mode mode, rtx mem1, rtx 
reg1, rtx mem2,
 case E_V4SImode:
   return gen_vec_store_pairv4siv4si (mem1, reg1, mem2, reg2);
 
+case E_V16QImode:
+  return gen_vec_store_pairv16qiv16qi (mem1, reg1, mem2, reg2);
+
 default:
   gcc_unreachable ();
 }
@@ -21373,6 +21376,134 @@ aarch64_expand_cpymem (rtx *operands)
   return true;
 }
 
+/* Like aarch64_copy_one_block_and_progress_pointers, except for memset where
+   *src is a register we have created with the duplicated value to be set.  */
+static void
+aarch64_set_one_block_and_progress_pointer (rtx *src, rtx *dst,
+   machine_mode mode)
+{
+  /* If we are copying 128bits or 256bits, we can do that 

Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

[Richard Sandiford via Gcc-patches]

Jakub Jelinek  writes:
> On Tue, Oct 27, 2020 at 11:13:21AM +, Richard Sandiford via Gcc-patches 
> wrote:
>> Sorry to stick my oar in, but I think we should reconsider the
>> bcst_mem_operand approach.  It seems like these patches (and the
>> previous one) are fighting against the principle that operands
>> cannot be arbitrary expressions.
>
> Many operands already are fairly complex expressions, so it is unclear how
> this changes that.

But the things subject to constraint matching currently have to be
SCRATCHes, SUBREGs, REGs, MEMs or constants.  The address inside
a MEM can be complex, but even that has certain limits (so that LRA
knows what to do with addresses that need reloading).

Matching something like VEC_DUPLICATE in a constraint is new in
that thing being constrained isn't conceptually an object
(only the operand of the VEC_DUPLICATE is).

> And LRA etc. already handles SUBREGs of MEM which is kind of similar to
> this.

Yeah, but SUBREGs of MEMs are a bit of a legacy feature :-)
It would be great to remove them at some point…

>> This kind of thing was attempted long ago (even before my time!)
>> for SIGN_EXTEND on MIPS.  It ended up causing more problems than
>> it solved and in the end it had to be taken out.  I'm worried that
>> we might end up going through the same cycle again.
>> 
>> Also, this LRA code is extremely performance-sensitive in terms
>> of compile time: it's often at the top or near the top of the profile.
>> So adding calls to new functions like extract_mem_from_operand for
>> a fairly niche case probably isn't a good trade-off.
>
> It can be just an inline function that looks through just the target
> selected rtxes rather than arbitrary ones (derived from *.md properties or
> something).

Having something in the .md file sounds good.  The more information the
generators have, the more chance they have to do something efficient.

>> I think we should instead find a nice(?) syntax for generating separate
>> patterns for the two bcst_vector_operand alternatives from a single
>> .md pattern.  That would fit the existing model much more closely.
>
> That would result in thousands of new patterns, I'm not sure it is a good
> idea.  Pretty much all AVX512* instructions allow those.

Yeah, I hadn't realised that.

Thanks,
Richard

[Patch] Fortran: Update omp atomic for OpenMP 5

[Tobias Burnus]

The parser partially anticipates the upcoming OpenMP 5.1 changes, which
adds some more clauses - but otherwise does not update it for OpenMP 5.1,
yet. In particular, the "omp end atomic" for capture is still required and
the memory-order-clause restrictions still apply.

I am a bit unsure about how to handle 'capture' (= update capture) and
the internal 'swap' in the internal representation; the current one is
not ideal, but others did not seem to be ideal, either.

OK?

Tobias

PS:
* On the C/C++ side, 'capture' (or update capture') restrictions are
  not checked (are the same as 'update' – and both are gone with OpenMP 5.1,
  which also permits ACQ_REL for read/write)
* On the C/C++ side, OpenACC's atomic piggybacks on OpenMP's which accepts
  too much.
* Fortran as C/C++: hint(hint-expr) is parsed but not actually used.

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
Fortran: Update omp atomic for OpenMP 5

gcc/fortran/ChangeLog:

	* dump-parse-tree.c (show_omp_clauses): Handle atomic clauses.
	(show_omp_node): Call it for atomic.
	* gfortran.h (enum gfc_omp_atomic_op): Add GFC_OMP_ATOMIC_UNSET,
	remove GFC_OMP_ATOMIC_SEQ_CST and GFC_OMP_ATOMIC_ACQ_REL.
	(enum gfc_omp_memorder): Replace OMP_MEMORDER_LAST by
	OMP_MEMORDER_UNSET, add OMP_MEMORDER_SEQ_CST/OMP_MEMORDER_RELAXED.
	(gfc_omp_clauses): Add capture and atomic_op.
	(gfc_code): remove omp_atomic.
	* openmp.c (enum omp_mask1): Add atomic, capture, memorder clauses.
	(gfc_match_omp_clauses): Match them.
	(OMP_ATOMIC_CLAUSES): Add.
	(gfc_match_omp_flush): Update for 'last' to 'unset' change.
	(gfc_match_omp_oacc_atomic): Removed and placed content ..
	(gfc_match_omp_atomic): ... here. Update for OpenMP 5 clauses.
	(gfc_match_oacc_atomic): Match directly here.
	(resolve_omp_atomic, gfc_resolve_omp_directive): Update.
	* parse.c (parse_omp_oacc_atomic): Update for struct gfc_code changes.
	* resolve.c (gfc_resolve_blocks): Update assert.
	* st.c (gfc_free_statement): Also call for EXEC_O{ACC,MP}_ATOMIC.
	* trans-openmp.c (gfc_trans_omp_atomic): Update.
	(gfc_trans_omp_flush): Update for 'last' to 'unset' change.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/atomic-2.f90: New test.
	* gfortran.dg/gomp/atomic.f90: New test.

 gcc/fortran/dump-parse-tree.c   |  34 
 gcc/fortran/gfortran.h  |  30 ++--
 gcc/fortran/openmp.c| 250 +---
 gcc/fortran/parse.c |   9 +-
 gcc/fortran/resolve.c   |   7 +-
 gcc/fortran/st.c|   4 +-
 gcc/fortran/trans-openmp.c  |  41 ++---
 gcc/testsuite/gfortran.dg/gomp/atomic-2.f90 |  33 
 gcc/testsuite/gfortran.dg/gomp/atomic.f90   | 111 
 9 files changed, 409 insertions(+), 110 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 6e265f4520d..43b97ba26ff 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1715,6 +1715,36 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
 }
   if (omp_clauses->depend_source)
 fputs (" DEPEND(source)", dumpfile);
+  if (omp_clauses->capture)
+fputs (" CAPTURE", dumpfile);
+  if (omp_clauses->atomic_op != GFC_OMP_ATOMIC_UNSET)
+{
+  const char *atomic_op;
+  switch (omp_clauses->atomic_op)
+	{
+	case GFC_OMP_ATOMIC_READ: atomic_op = "READ"; break;
+	case GFC_OMP_ATOMIC_WRITE: atomic_op = "WRITE"; break;
+	case GFC_OMP_ATOMIC_UPDATE: atomic_op = "UPDATE"; break;
+	default: gcc_unreachable ();
+	}
+  fputc (' ', dumpfile);
+  fputs (atomic_op, dumpfile);
+}
+  if (omp_clauses->memorder != OMP_MEMORDER_UNSET)
+{
+  const char *memorder;
+  switch (omp_clauses->memorder)
+	{
+	case OMP_MEMORDER_ACQ_REL: memorder = "ACQ_REL"; break;
+	case OMP_MEMORDER_ACQUIRE: memorder = "AQUIRE"; break;
+	case OMP_MEMORDER_RELAXED: memorder = "RELAXED"; break;
+	case OMP_MEMORDER_RELEASE: memorder = "RELEASE"; break;
+	case OMP_MEMORDER_SEQ_CST: memorder = "SEQ_CST"; break;
+	default: gcc_unreachable ();
+	}
+  fputc (' ', dumpfile);
+  fputs (memorder, dumpfile);
+}
 }
 
 /* Show a single OpenMP or OpenACC directive node and everything underneath it
@@ -1880,6 +1910,10 @@ show_omp_node (int level, gfc_code *c)
 case EXEC_OMP_TASKWAIT:
 case EXEC_OMP_TASKYIELD:
   return;
+case EXEC_OACC_ATOMIC:
+case EXEC_OMP_ATOMIC:
+  omp_clauses = c->block ? c->block->ext.omp_clauses : NULL;
+  break;
 default:
   break;
 }
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 73b6ffd870c..9500032f0e3 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1343,6 +1343,16 @@ enum gfc_omp_if_kind
   OMP_IF_LAST
 };
 
+enum gfc_omp_atomic_op
+{
+  GFC_OMP_ATOMIC_UNSET = 0,
+  GFC_OMP_ATOMIC_UPDATE = 1,
+  

Re: PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

[Michael Meissner via Gcc-patches]

On Mon, Oct 26, 2020 at 05:48:48PM -0500, will schmidt wrote:
> On Thu, 2020-10-22 at 18:15 -0400, Michael Meissner via Gcc-patches wrote:
> > PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.
> > 
> > This is a new patch.  It turns off the warning about switching the long 
> > double
> > type via compile line if the GLIBC is 2.32 or newer.  It only does this if 
> > the
> > languages are C or C++, since those language libraries support switching the
> > long double type.  Other languages like Fortran don't have any current 
> > support
> > to provide both sets of interfaces to the library.
> > 
> > 2020-10-21  Michael Meissner  
> > 
> > * config/rs6000/rs6000.c (rs6000_option_override_internal): Allow
> > long double type to be changed for C/C++ if glibc 2.32 or newer.
> > ---
> >  gcc/config/rs6000/rs6000.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> > index 50039c0a53d..940c15f3265 100644
> > --- a/gcc/config/rs6000/rs6000.c
> > +++ b/gcc/config/rs6000/rs6000.c
> > @@ -4158,10 +4158,16 @@ rs6000_option_override_internal (bool global_init_p)
> > 
> >if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT && 
> > TARGET_LONG_DOUBLE_128)
> > {
> > + /* Determine if the user can change the default long double type at
> > +compilation time.  Only C and C++ support this, and you need GLIBC
> > +2.32 or newer.  Only issue one warning.  */
> 
> >   static bool warned_change_long_double;
> > - if (!warned_change_long_double)
> > +
> > + if (!warned_change_long_double
> > + && (!OPTION_GLIBC
> > + || (!lang_GNU_C () && !lang_GNU_CXX ())
> > + || ((TARGET_GLIBC_MAJOR * 1000) + TARGET_GLIBC_MINOR) < 2032))
> > {
> > - warned_change_long_double = true;
> 
> Does this need to be added back elsewhere? 

At the present time, we are not contemplating adding the full support to enable
configuring GCC to use IEEE 128-bit long double in GCC 10 or earlier.  This may
change depending on customer demands.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Improve vec::copy mem stat annotations

[Jan Hubicka]

Hi,
this patch annotates vec::copy so it shows better in stats.  I still do
not see how auto vecs gets miscounted.

Bootstrapped/regtested x86_64-linux, comitted.

Honza

* vec.h (vec::copy): Pass mem stat info.
diff --git a/gcc/vec.h b/gcc/vec.h
index 3ad26972a62..14d77e87342 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1731,7 +1731,7 @@ vec::copy (ALONE_MEM_STAT_DECL) const
 {
   vec new_vec = vNULL;
   if (length ())
-new_vec.m_vec = m_vec->copy ();
+new_vec.m_vec = m_vec->copy (ALONE_PASS_MEM_STAT);
   return new_vec;
 }
 

Re: PowerPC: Update __float128 and __ibm128 error messages.

[Michael Meissner via Gcc-patches]

On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Oct 22, 2020 at 06:11:35PM -0400, Michael Meissner wrote:
> > This patch attempts to make the error messages for intermixing IEEE 128-bit
> > floating point with IBM 128-bit extended double types to be clearer if the 
> > long
> > double type uses the IEEE 128-bit format.
> 
> > We have gotten some requests to back port these changes to GCC 10.x.  At the
> > moment, I am not planning to do the back port, but I may need to in the 
> > future.
> 
> Ping the patches if/when that happens?

Certainly.

> > +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> 
> Use *-*-linux* instead?  (In all relevant tests.)

Ok.

> Is there any reason these tests should only run on Linux?  If not, it
> should not restrict itself like this; and if so, you may want another
> selsector (something ieee128 perhaps), or at the very least add a
> comment why you do this.

Right now the float128 emulation is only built on Linux, because it needs the
support in GLIBC.  If/when other systems add support for float128 in there
C/C++ libraries, we can widen the tests.

> >  /* { dg-do compile { target { powerpc*-*-linux* } } } */
> > -/* { dg-require-effective-target powerpc_vsx_ok } */
> > -/* { dg-options "-O2 -mvsx" } */
> > +/* { dg-require-effective-target ppc_float128_sw } */
> 
> Removing powerpc_vsx_ok is wrong, you still use -mvsx.  That the only
> current soft float QP stuff requires VSX is irrelevant.
> 
> Please fix those everywhere.  Okay for trunk with that.  Thanks!

IIRC, these tests were added very early in the float128 cycle, before we had
the target supports for float128.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

[Richard Sandiford via Gcc-patches]

Hongtao Liu via Gcc-patches  writes:
> On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford
>  wrote:
>>
>> Hongtao Liu via Gcc-patches  writes:
>> > Hi:
>> >   For inline asm, there could be an operand like (not (mem:)), it's
>> > not a valid operand for normal memory constraint.
>> >   Bootstrap is ok, regression test is ok for make check
>> > RUNTESTFLAGS="--target_board='unix{-m32,}'"
>> >
>> > gcc/ChangeLog
>> > PR target/97540
>> > * ira.c: (ira_setup_alts): Extract memory from operand only
>> > for special memory constraint.
>> > * recog.c (asm_operand_ok): Ditto.
>> > * lra-constraints.c (process_alt_operands): MEM_P is
>> > required for normal memory constraint.
>> >
>> > gcc/testsuite/ChangeLog
>> > * gcc.target/i386/pr97540.c: New test.
>>
>> Sorry to stick my oar in, but I think we should reconsider the
>> bcst_mem_operand approach.  It seems like these patches (and the
>> previous one) are fighting against the principle that operands
>> cannot be arbitrary expressions.
>>
>> This kind of thing was attempted long ago (even before my time!)
>> for SIGN_EXTEND on MIPS.  It ended up causing more problems than
>> it solved and in the end it had to be taken out.  I'm worried that
>> we might end up going through the same cycle again.
>>
>
> Could you provide the thread link for the issue of SIGN_EXTEND on
> MIPS, then I can take a look to see if it's exactly the same issue as
> mine.

I couldn't find anything, sorry.  The patch that finally removed
the MIPS handling was:

  https://gcc.gnu.org/pipermail/gcc-patches/2002-October/088178.html

I know there was some discussion about the problems around then,
but some of it might have been private rather than on-list.
I can't remember the details now.

Thanks,
Richard

Re: Avoid char[] array in tree_def

[Jan Hubicka]

> On Thu, 29 Oct 2020, Jan Hubicka wrote:
> 
> > > 
> > > That's ugly and will for sure defeat warning / access code
> > > when we access this as char[], no?  I mean, we could
> > > as well use 'int str[1];' here?
> > 
> > Well, we always get char pointer via macro that is IMO OK, but I am also
> > not very much in love with this.
> > > 
> > > Maybe we can invent some C++ attribute for this?
> > > 
> > > [[gnu::string]]
> > > 
> > > or so that marks it as actual char and not typeless storage?
> > 
> > Attribute would probably make sense.  Not sure if gnu::string is best
> > name given that it can be also meaningful for array of small integers
> > (such as in wide_int).
> 
> OK, maybe [[gnu::strictly_typed]] then?

This looks like good idea to me (and probably also making difference
with signed char as Jakub suggests).

I am adding Jason to CC, since he may know better.
Honza

Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

[Richard Sandiford via Gcc-patches]

Hongtao Liu via Gcc-patches  writes:
> On Thu, Oct 29, 2020 at 2:46 AM Richard Sandiford
>  wrote:
>>
>> Hongtao Liu  writes:
>> > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford
>> >  wrote:
>> >>
>> >> Hongtao Liu via Gcc-patches  writes:
>> >> > Hi:
>> >> >   For inline asm, there could be an operand like (not (mem:)), it's
>> >> > not a valid operand for normal memory constraint.
>> >> >   Bootstrap is ok, regression test is ok for make check
>> >> > RUNTESTFLAGS="--target_board='unix{-m32,}'"
>> >> >
>> >> > gcc/ChangeLog
>> >> > PR target/97540
>> >> > * ira.c: (ira_setup_alts): Extract memory from operand only
>> >> > for special memory constraint.
>> >> > * recog.c (asm_operand_ok): Ditto.
>> >> > * lra-constraints.c (process_alt_operands): MEM_P is
>> >> > required for normal memory constraint.
>> >> >
>> >> > gcc/testsuite/ChangeLog
>> >> > * gcc.target/i386/pr97540.c: New test.
>> >>
>> >> Sorry to stick my oar in, but I think we should reconsider the
>> >> bcst_mem_operand approach.  It seems like these patches (and the
>> >> previous one) are fighting against the principle that operands
>> >> cannot be arbitrary expressions.
>> >>
>> >> This kind of thing was attempted long ago (even before my time!)
>> >> for SIGN_EXTEND on MIPS.  It ended up causing more problems than
>> >> it solved and in the end it had to be taken out.  I'm worried that
>> >> we might end up going through the same cycle again.
>> >>
>> >> Also, this LRA code is extremely performance-sensitive in terms
>> >> of compile time: it's often at the top or near the top of the profile.
>> >> So adding calls to new functions like extract_mem_from_operand for
>> >> a fairly niche case probably isn't a good trade-off.
>> >>
>> >> I think we should instead find a nice(?) syntax for generating separate
>> >> patterns for the two bcst_vector_operand alternatives from a single
>> >> .md pattern.  That would fit the existing model much more closely.
>> >>
>> >
>> > We have define_subst for RTL template transformations, but it's not
>> > suitable for this case(too many define_subst templates need to
>> > be added, and it doesn't show any advantage compared to adding
>> > separate bcst patterns.). I don't find other workable existing syntax for 
>> > it.
>>
>> Yeah, I think it would need to be new syntax.  I was wondering if it
>> would help if we had somethine like (strawman suggestion):
>>
>>   (one_of 0
>> [(match_operand:VI_AVX2 1 "vector_operand" "...")
>>  (vec_duplicate:VI_AVX2
>>(match_operand:<...> 1 "..." "..."))]
>>
>> where all instances of (one_of N ...) for a given N are required
>> to have the same number of alternatives.
>>
>> This could be handled in a similar way to define_subst, with the
>> one_of being expanded before the main generator routines see it.
>>
>> But maybe it wouldn't help that much.  E.g. for:
>>
>> (define_insn "*3"
>>   [(set (match_operand:VI_AVX2 0 "register_operand" "=x,v")
>> (plusminus:VI_AVX2
>>   (match_operand:VI_AVX2 1 "bcst_vector_operand" "0,v")
>>   (match_operand:VI_AVX2 2 "bcst_vector_operand" "xBm,vmBr")))]
>>
>> the vec_duplicate version should only really have one alternative.
> It would be guaranteed by it's attribute (set_attr "isa" "noavx,avx"),
> since bcst_mem_operand implies avx512f, which of course implies avx,
> therefore the first alternative would never be enabled under avx.

Ah, OK.

>> I guess we could handle that by using a:
>>
>>   (one_of 0
>> [(set_attr "enabled" "*,*")
>>  (set_attr "enabled" "0,*")])
>>
>> or some variant of that that uses a derived attribute.  But it feels
>> a bit clunky…
>>
>> Without that, I guess the only pattern that would benefit directly is:
>>
>> (define_insn "avx512dq_mul3"
>>   [(set (match_operand:VI8_AVX512VL 0 "register_operand" "=v")
>> (mult:VI8_AVX512VL
>>   (match_operand:VI8_AVX512VL 1 "bcst_vector_operand" "%v")
>>   (match_operand:VI8_AVX512VL 2 "bcst_vector_operand" "vmBr")))]
>>
>> > So suppose I should revert my former 2 patches and add separate bcst 
>> > patterns.
>>
>> Are there going to more patterns that need bcst_vector_operand,
>
> Almost all AVX512 instructions need corresponding bcst patterns except
> for those with 8-bit/16-bit data elements.

OK, that changes things.  Sorry, not knowing the architecture,
I wasn't sure how far this was from being complete.

>> or is the current set complete?
>>
>> I definitely think we should have a better way of handling this in the
>> .md files, and I'd be happy to hack something up on the generator side
>> (given that I'm being the awkward one here).  But I guess the answer to
>> the question above will decide whether it make things better or not.
>>
>> FWIW, I think having separate patterns (whether they're produced from
>> one .md construct or from several) might better optimisation results.
>
> With proper extending for 

Re: Avoid char[] array in tree_def

[Jan Hubicka]

> On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> > > 
> > > That's ugly and will for sure defeat warning / access code
> > > when we access this as char[], no?  I mean, we could
> > > as well use 'int str[1];' here?
> > 
> > Well, we always get char pointer via macro that is IMO OK, but I am also
> > not very much in love with this.
> 
> Do we treat signed char [...]; as typeless storage too, or just
> what the C++ standard requires (i.e. char, unsigned char and std::byte
> where the last one is enum type with unsigned char underlying type)?
struct a {signed char b[10];int d;} c;
void
test ()
{
  c.d=1;
}

still leads to alias set 0 access, so perhaps this can be improved.
Where the standard specifies this? (also coincidentally I have no idea
where C++ sets typeless storage to 1 :)

Honza
> 
>   Jakub
> 

Re: PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.

[Michael Meissner via Gcc-patches]

On Tue, Oct 27, 2020 at 09:30:03AM -0500, will schmidt wrote:
> On Thu, 2020-10-22 at 18:10 -0400, Michael Meissner via Gcc-patches wrote:
> > PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
> > 
> > I have split all of these patches into separate patches to hopefully get 
> > them
> > into the tree.
> > 
> > This patch changes the __ibm128 emulator to use __builtin_pack_ieee128
> > instead of __builtin_pack_longdouble if long double is IEEE 128-bit, and
> > we need to use the __ibm128 type.  The code will run without this patch,
> > but this patch slightly optimizes it better.
> > 
> > I have tested this patch with bootstrap builds on a little endian power9 
> > system
> > running Linux.  With the other patches, I have built two full bootstrap 
> > builds
> > using this patch and the patches after this patch.  One build used the 
> > current
> > default for long double (IBM extended double) and the other build switched 
> > the
> > default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as 
> > the
> > library used by this compiler.  There are no regressions between the tests.
> > There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
> > default_format_denormal_2.f90) that now pass.
> 
> good. :-)A quick search of gcc bugzilla shows there is an existing
> PR 67531 that includes ieee rounding support for powerpc long double. 
> Does this (partially?) address that? 
>   
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67531

In theory, once the full system uses IEEE 128-bit floating point for long
double, all of the various rounding issues will be fixed.

However, we have to get to that step, and this is just one of a long line of
intermediate steps to get to that goal.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.

[Michael Meissner via Gcc-patches]

On Wed, Oct 28, 2020 at 04:58:46PM -0500, Segher Boessenkool wrote:
> Hi Mike,
> 
> On Thu, Oct 22, 2020 at 06:10:37PM -0400, Michael Meissner wrote:
> > PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
> 
> This title makes no sense, and thankfully is not what the patch does :-)

Thanks, every so often I accidently type __ieee128 instead of __ibm128.

> > This patch changes the __ibm128 emulator to use __builtin_pack_ieee128
> > instead of __builtin_pack_longdouble if long double is IEEE 128-bit, and
> > we need to use the __ibm128 type.  The code will run without this patch,
> > but this patch slightly optimizes it better.
> 
> It uses __builtin_pack_ibm128, instead?

Yes.

> > libgcc/
> > 2020-10-22  Michael Meissner  
> > 
> > * config/rs6000/ibm-ldouble.c (pack_ldouble): Use
> > __builtin_pack_ieee128 if long double is IEEE 128-bit.
> 
> Here, too.
> 
> > ---
> >  libgcc/config/rs6000/ibm-ldouble.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/libgcc/config/rs6000/ibm-ldouble.c 
> > b/libgcc/config/rs6000/ibm-ldouble.c
> > index dd2a02373f2..767fdd72683 100644
> > --- a/libgcc/config/rs6000/ibm-ldouble.c
> > +++ b/libgcc/config/rs6000/ibm-ldouble.c
> > @@ -102,9 +102,17 @@ __asm__ (".symver __gcc_qadd,_xlqadd@GCC_3.4\n\t"
> >  static inline IBM128_TYPE
> >  pack_ldouble (double dh, double dl)
> >  {
> > +  /* If we are building on a non-VSX system, the __ibm128 type is not 
> > defined.
> 
> "Building on" does not matter in the least.  The compiler should
> generate the same code, no matter what it runs on.  Target matters, not
> host (and build not at all).

Yes.

> > + This means we can't always use __builtin_pack_ibm128.  Instead, we use
> > + __builtin_pack_longdouble if long double uses the IBM extended double
> > + 128-bit format, and use the explicit __builtin_pack_ibm128 if long 
> > double
> > + is IEEE 128-bit.  */
> 
> And this comment is about the *next* case?
> 
> >  #if defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IBM128__)  
> > \
> >  && !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__))
> >return __builtin_pack_longdouble (dh, dl);
> > +#elif defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IEEE128__) \
> > +&& !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__))
> > +  return __builtin_pack_ibm128 (dh, dl);
> 
> Given the above, _SOFT_FLOAT etc. are wrong.
> 
> Just use some more portable thing to repack?  Is __builtin_pack_ibm128
> not defined always here anyway?

That is the problem.  If you build a big endian PowerPC compiler where VSX is
not default, the __ibm128 stuff is not defined.  It is only defined when
__float128 is a possibility.  Hence __builtin_pack_ibm128 and
__builtin_unpack_ibm128 are not defined.

> /* 128-bit __ibm128 floating point builtins (use -mfloat128 to indicate that
>__ibm128 is available).  */
> #define BU_IBM128_2(ENUM, NAME, ATTR, ICODE)\
>   RS6000_BUILTIN_2 (MISC_BUILTIN_ ## ENUM,  /* ENUM */  \
> "__builtin_" NAME,  /* NAME */  \
> (RS6000_BTM_HARD_FLOAT  /* MASK */  \
>  | RS6000_BTM_FLOAT128),\
> (RS6000_BTC_ ## ATTR/* ATTR */  \
>  | RS6000_BTC_BINARY),  \
> CODE_FOR_ ## ICODE) /* ICODE */
> 
> (so just HARD_FLOAT and FLOAT128 are needed)
> 
> What am I missing?

As I said, the __ibm128 keyword is not enabled on non-VSX systems.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

[Michael Meissner via Gcc-patches]

On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote:
> > This patch adds long double variants of the power10 __float128 built-in
> > functions.  This is needed when long double uses IEEE 128-bit because
> > __float128 uses TFmode in this case instead of KFmode.  If this patch is not
> > applied, these built-in functions can't be used when long double is IEEE
> > 128-bit.
> 
> But now they still cannot, you need new builtins, instead.
> 
> TFmode is an implementation detail at this level (functions use types,
> not modes), so you do not need new builtins at all afaics?  Just define
> the existing ones with TFmode as well (if that is the same as KFmode)?

In order to add new overloaded built-ins, you have to add a new built-in with a
new name.  Hence I have to add TF variants for these functions when __float128
is the same as long double.

Maybe when Bill finally reorganizes the built-in functions, we can do anyway
with having to create new named functions.  But for now, in order to add them,
you need a name.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

[Michael Meissner via Gcc-patches]

On Tue, Oct 27, 2020 at 09:38:20AM -0500, will schmidt wrote:
> > @@ -2420,6 +2423,8 @@ BU_P9V_64BIT_VSX_2 (VSIEDPF,  "scalar_insert_exp_dp", 
> > CONST,  xsiexpdpf)
> > 
> >  BU_FLOAT128_HW_VSX_2 (VSIEQP,  "scalar_insert_exp_q",  CONST,  
> > xsiexpqp_kf)
> >  BU_FLOAT128_HW_VSX_2 (VSIEQPF, "scalar_insert_exp_qp", CONST,  
> > xsiexpqpf_kf)
> > +BU_FLOAT128_HW_VSX_2 (VSIETF,  "scalar_insert_exp_tf", CONST,  
> > xsiexpqp_tf)
> > +BU_FLOAT128_HW_VSX_2 (VSIETFF, "scalar_insert_exp_tfp", CONST, 
> > xsiexpqpf_tf)
> 
> Ok if its ok, but the pattern catches my eye.  Should that be VSIETFP ?
> (or named "scalar_insert_exp_tff")?

That is the existing function in the library.  All I'm doing is adding TF
versions of the existing functions.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Add __float128 conversions to/from Decimal

[Michael Meissner via Gcc-patches]

On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 22, 2020 at 06:06:03PM -0400, Michael Meissner wrote:
> > This patch adds the various decimal to/from IEEE 128-bit conversions.  I
> > had to make some changes to the infrastructure, since that infrastructure
> > assumed that there is a sprintf/scanf format modifier to convert floating
> > point.  Instead, I used to str* conversion functions.
> 
> > --- /dev/null
> > +++ b/libgcc/config/rs6000/_dd_to_kf.c
> 
> > +/* Decimal64 -> _Float128 conversion.  */
> > +#define FINE_GRAINED_LIBRARIES 1
> 
> This isn't defined in any other source file (instead, it is put in the
> Makefile).  Why should it be different here?

I'll check it out.

> > +# Force the TF mode to/from decimal functions to be compiled with IBM long
> > +# double.  Add building the KF mode to/from decimal conversions with 
> > explict
> 
> (typo, "explicit")
> 
> > +#if HAVE_KF_MODE
> > +  strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x);
> > +#else
> >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x);
> > +#endif
> 
> Does strfromf128 exist everywhere we build this?  It isn't a standard
> function.

Yes, it is in ISO/IEC TS 18661-3, which is the document that describes most of
the *f128 functions.

We have to use str* instead of sprintf or scanf, because I don't believe their
is a float128 format specifier.

> > +/* Support PowerPC KF mode, which is __float128 when long double is
> > +   IBM extended double.  */
> > +#if defined (L_sd_to_kf) || defined (L_dd_to_kf) || defined (L_td_to_kf) \
> > + || defined (L_kf_to_sd) || defined (L_kf_to_dd) || defined (L_kf_to_td)
> > +#define HAVE_KF_MODE 1
> > +#endif
> 
> This might want a better name, other targets can have a KFmode as well,
> for some completely different purpose, since it is not a standard mode.

Given everything else uses *F, including XF on the x86, I figured it was easier
than creating a new name.

> (Some libgcc maintainer needs to approve the generic parts, not all of
> it can obviously only trigger for us.)
> 
> 
> Segher

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

[Qing Zhao via Gcc-patches]

Hi, Richard,


Now, the documentation (gcc.info) is like following, let me know any issue 
there:

thanks.

Qing
==

'zero_call_used_regs ("CHOICE")'

 The 'zero_call_used_regs' attribute causes the compiler to zero a
 subset of all call-used registers(1) at function return.  This is
 used to increase program security by either mitigating
 Return-Oriented Programming (ROP) or preventing information leakage
 through registers.

 In order to satisfy users with different security needs and control
 the run-time overhead at the same time, CHOICE parameter provides a
 flexible way to choose the subset of the call-used registers to be
 zeroed.

 The three basic values of CHOICE are:

* 'skip' doesn't zero any call-used registers.

* 'used' only zeros call-used registers that are used in the
  function.  A "used" register is one whose content has been set
  or referenced in the function.

* 'all' zeros all call-used registers.

 In addition to these three basic choices, it is possible to modify
 'used' or 'all' as follows:

* Adding '-gpr' restricts the zeroing to general-purpose
  registers.

* Adding '-arg' restricts the zeroing to registers that can
  sometimes be used to pass function arguments.  This includes
  all argument registers defined by the platform's calling
  conversion, regardless of whether the function uses those
  registers for function arguments or not.

 The modifiers can be used individually or together.  If they are
 used together, they must appear in the order above.

 The full list of CHOICEs is therefore:

 'skip'
  doesn't zero any call-used register.

 'used'
  only zeros call-used registers that are used in the function.

 'used-gpr'
  only zeros call-used general purpose registers that are used
  in the function.

 'used-arg'
  only zeros call-used registers that are used in the function
  and pass arguments.

 'used-gpr-arg'
  only zeros call-used general purpose registers that are used
  in the function and pass arguments.

 'all'
  zeros all call-used registers.

 'all-gpr'
  zeros all call-used general purpose registers.

 'all-arg'
  zeros all call-used registers that pass arguments.

 'all-gpr-arg'
  zeros all call-used general purpose registers that pass
  arguments.

 Of this list, 'used-arg', 'used-gpr-arg', 'all-arg', and
 'all-gpr-arg' are mainly used for ROP mitigation.

 The default for the attribute is controlled by
 '-fzero-call-used-regs'.

   -- Footnotes --

   (1) A "call-used" register is a register whose contents can be
changed by a function call; therefore, a caller cannot assume that the
register has the same contents on return from the function as it had
before calling the function.  Such registers are also called
"call-clobbered", "caller-saved", or "volatile”.


'-fzero-call-used-regs=CHOICE'
 Zero call-used registers at function return to increase program
 security by either mitigating Return-Oriented Programming (ROP) or
 preventing information leakage through registers.

 The possible values of CHOICE are the same as for the
 'zero_call_used_regs' attribute (*note Function Attributes::).  The
 default is 'skip'.

 You can control this behavior for a specific function by using the
 function attribute 'zero_call_used_regs' (*note Function
 Attributes::).

Re: [PATCH] libstdc++: Add c++2a

[Jonathan Wakely via Gcc-patches]

On 21/10/20 09:53 -0700, Thomas Rodgers wrote:

From: Thomas Rodgers 

libstdc++/Changelog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am (std_headers): Add new header.
libstdc++-v3/include/Makefile.in: Regenerate.
libstdc++-v3/include/precompiled/stdc++.h: Include new header.
libstdc++-v3/include/std/streambuf
   (__detail::__streambuf_core_access): Define.
   (basic_streambuf): Befriend __detail::__streambuf_core_access.
libstdc++-v3/include/std/syncstream: New header.
libstdc++-v3/include/std/version: Add __cpp_lib_syncbuf:
libstdc++-v3/testsuite/27_io/basic_syncbuf/1.cc: New test.
libstdc++-v3/testsuite/27_io/basic_syncbuf/2.cc: Likewise.
libstdc++-v3/testsuite/27_io/basic_syncbuf/basic_ops/1.cc:
   Likewise.
libstdc++-v3/testsuite/27_io/basic_syncbuf/requirements/types.cc:
   Likewise.
libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc:
   Likewise.
libstdc++-v3/testsuite/27_io/basic_syncstream/1.cc: Likewise.
libstdc++-v3/testsuite/27_io/basic_syncstream/2.cc: Likewise.
libstdc++-v3/testsuite/27_io/basic_syncstream/basic_ops/1.cc:
   Likewise.
libstdc++-v3/testsuite/27_io/basic_syncstream/requirements/types.cc:
   Likewise.

---
libstdc++-v3/doc/doxygen/user.cfg.in  |   1 +
libstdc++-v3/include/Makefile.am  |   1 +
libstdc++-v3/include/Makefile.in  |   1 +
libstdc++-v3/include/precompiled/stdc++.h |   2 +-
libstdc++-v3/include/std/syncstream   | 279 ++
libstdc++-v3/include/std/version  |   4 +
.../testsuite/27_io/basic_syncbuf/1.cc|  28 ++
.../testsuite/27_io/basic_syncbuf/2.cc|  27 ++
.../27_io/basic_syncbuf/basic_ops/1.cc| 138 +
.../27_io/basic_syncbuf/requirements/types.cc |  42 +++
.../27_io/basic_syncbuf/sync_ops/1.cc | 130 
.../testsuite/27_io/basic_syncstream/1.cc |  28 ++
.../testsuite/27_io/basic_syncstream/2.cc |  27 ++
.../27_io/basic_syncstream/basic_ops/1.cc | 135 +
.../basic_syncstream/requirements/types.cc|  43 +++
15 files changed, 885 insertions(+), 1 deletion(-)
create mode 100644 libstdc++-v3/include/std/syncstream
create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncbuf/1.cc
create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncbuf/2.cc
create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncbuf/basic_ops/1.cc
create mode 100644 
libstdc++-v3/testsuite/27_io/basic_syncbuf/requirements/types.cc
create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc
create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncstream/1.cc
create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncstream/2.cc
create mode 100644 libstdc++-v3/testsuite/27_io/basic_syncstream/basic_ops/1.cc
create mode 100644 
libstdc++-v3/testsuite/27_io/basic_syncstream/requirements/types.cc

diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in 
b/libstdc++-v3/doc/doxygen/user.cfg.in
index 9b49a15d31b..320f6dea688 100644
--- a/libstdc++-v3/doc/doxygen/user.cfg.in
+++ b/libstdc++-v3/doc/doxygen/user.cfg.in
@@ -897,6 +897,7 @@ INPUT  = @srcdir@/doc/doxygen/doxygroups.cc 
\
 include/streambuf \
 include/string \
 include/string_view \
+ include/syncstream \
 include/system_error \
 include/thread \
 include/tuple \
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 28d273924ee..61aaff7a2f4 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -73,6 +73,7 @@ std_headers = \
${std_srcdir}/shared_mutex \
${std_srcdir}/span \
${std_srcdir}/sstream \
+   ${std_srcdir}/syncstream \
${std_srcdir}/stack \
${std_srcdir}/stdexcept \
${std_srcdir}/stop_token \
diff --git a/libstdc++-v3/include/precompiled/stdc++.h 
b/libstdc++-v3/include/precompiled/stdc++.h
index 7518a98c25a..8899c323a28 100644
--- a/libstdc++-v3/include/precompiled/stdc++.h
+++ b/libstdc++-v3/include/precompiled/stdc++.h
@@ -141,6 +141,6 @@
#include 
#include 
#include 
-// #include 
+#include 
#include 
#endif
diff --git a/libstdc++-v3/include/std/syncstream 
b/libstdc++-v3/include/std/syncstream
new file mode 100644
index 000..3f78cef1d8d
--- /dev/null
+++ b/libstdc++-v3/include/std/syncstream
@@ -0,0 +1,279 @@
+//  -*- C++ -*-
+
+// Copyright (C) 2020 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.
+
+// 

Re: [PATCH 2/2] c++: Clean up constraint normalization routines

[Jason Merrill via Gcc-patches]

On 10/19/20 6:08 PM, Patrick Palka wrote:

Many of the high-level constraint normalization routines allow the
caller to supply the initial template arguments for normalization, but
in practice all of the callers ultimately supply either NULL_TREE or a
set of generic template arguments (*).  Since the previous patch made
NULL_TREE act like a set of generic template arguments during
normalization, we can just make get_normalized_constraints pass
NULL_TREE to normalize_expression and remove the 'args' parameter from
the routines that wrap it.

(*): Except one of the overloads of normalize_constraint_expression uses
the template arguments of a concept check for normalizing the concept
check, which doesn't seem right, since if a substitution failure happens
during normalization then it will become a hard error instead of a
SFINAE error.  This patch does away with this overload.

Bootstrapped and regtested on x86_64-pc-linux-gnu and tested on the
cmcstl2 testsuite.  Also verified that the concepts diagnostics remain
unchanged across our testsuite.  Doest this look OK to commit?


OK.


gcc/cp/ChangeLog:

* constraint.cc (get_normalized_constraints): Remove 'args'
parameter.  Pass NULL_TREE as the initial template arguments to
normalize_expression.
(get_normalized_constraints_from_info): Remove 'args' parameter
and adjust the call to get_normalized_constraints.
(get_normalized_constraints_from_decl): Remove 'args' local
variable and adjust call to get_normalized_constraints_from_info.
(normalize_concept_definition): Remove 'args' local variable
and adjust call to get_normalized_constraints.
(normalize_constraint_expression): Remove the two-argument
overload.  Remove 'args' parameter from the three-argument
overload and update function comment accordingly.  Remove
default argument from 'diag' parameter. Adjust call to
get_normalized_constraints accordingly.
(finish_nested_requirement): Adjust call to
normalize_constraint_expression accordingly.
(strictly_subsumes): Remove 'args' parameter.  Adjust call to
get_normalized_constraints_from_info accordingly.
(weakly_subsumes): Likewise.
* cp-tree.h (strictly_subsumes): Remove 'args' parameter.
(weakly_subsumes): Likewise.
* pt.c (process_partial_specialization): Adjust call to
strictly_subsumes accordingly.
(is_compatible_template_arg): Adjust call to weakly_subsumes
accordingly.
---
  gcc/cp/constraint.cc | 69 +---
  gcc/cp/cp-tree.h |  4 +--
  gcc/cp/pt.c  |  5 ++--
  3 files changed, 24 insertions(+), 54 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 75457a2dd60..d6354edbe6f 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -759,20 +759,18 @@ normalize_expression (tree t, tree args, norm_info info)
  static GTY((deletable)) hash_map *normalized_map;
  
  static tree

-get_normalized_constraints (tree t, tree args, norm_info info)
+get_normalized_constraints (tree t, norm_info info)
  {
auto_timevar time (TV_CONSTRAINT_NORM);
-  return normalize_expression (t, args, info);
+  return normalize_expression (t, NULL_TREE, info);
  }
  
  /* Returns the normalized constraints from a constraint-info object

-   or NULL_TREE if the constraints are null. ARGS provide the initial
-   arguments for normalization and IN_DECL provides the declaration
-   to which the constraints belong.  */
+   or NULL_TREE if the constraints are null. IN_DECL provides the
+   declaration to which the constraints belong.  */
  
  static tree

-get_normalized_constraints_from_info (tree ci, tree args, tree in_decl,
- bool diag = false)
+get_normalized_constraints_from_info (tree ci, tree in_decl, bool diag = false)
  {
if (ci == NULL_TREE)
  return NULL_TREE;
@@ -780,8 +778,7 @@ get_normalized_constraints_from_info (tree ci, tree args, 
tree in_decl,
/* Substitution errors during normalization are fatal.  */
++processing_template_decl;
norm_info info (in_decl, diag ? tf_norm : tf_none);
-  tree t = get_normalized_constraints (CI_ASSOCIATED_CONSTRAINTS (ci),
-  args, info);
+  tree t = get_normalized_constraints (CI_ASSOCIATED_CONSTRAINTS (ci), info);
--processing_template_decl;
  
return t;

@@ -843,9 +840,8 @@ get_normalized_constraints_from_decl (tree d, bool diag = 
false)
  
push_nested_class_guard pncs (DECL_CONTEXT (d));
  
-  tree args = generic_targs_for (tmpl);

tree ci = get_constraints (decl);
-  tree norm = get_normalized_constraints_from_info (ci, args, tmpl, diag);
+  tree norm = get_normalized_constraints_from_info (ci, tmpl, diag);
  
if (!diag)

  hash_map_safe_put (normalized_map, tmpl, norm);
@@ -866,11 +862,10 @@ normalize_concept_definition (tree tmpl, bool diag = 

Re: [PATCH 1/2] c++: Tolerate empty initial targs during normalization [PR97412]

[Jason Merrill via Gcc-patches]

On 10/29/20 11:21 AM, Patrick Palka wrote:

On Mon, 19 Oct 2020, Patrick Palka wrote:


When normalizing the constraint-expression of a nested-requirement, we
pass NULL_TREE as the initial template arguments for normalization, but
tsubst_argument_pack is not prepared to handle a NULL_TREE targ vector.
This causes us to ICE when normalizing a variadic concept as part of a
nested-requirement.

This patch fixes the ICE by guarding the call to tsubst_template_args in
normalize_concept_check appropriately.  This will also enables us to
simplify many of the normalization routines to pass NULL_TREE instead of
a set of generic template arguments as the initial template arguments,
which will be done in a subsequent patch.


Ping.  For some reason I confusingly referred to 'targs' in the commit
message when the variable in question is actually 'args'.  So I've
adjusted the commit message below:


OK.


-- >8 --

Subject: [PATCH] c++: Tolerate empty initial args during normalization
  [PR97412]

When normalizing the constraint-expression of a nested-requirement, we
pass NULL_TREE as the initial template arguments for normalization, but
tsubst_argument_pack is not prepared to handle a NULL_TREE args vector.
This causes us to ICE when normalizing a variadic concept as part of a
nested-requirement.

This patch fixes the ICE by guarding the call to tsubst_template_args in
normalize_concept_check appropriately.  This will also enable us to
simplify many of the normalization routines to just pass NULL_TREE
(instead of a set of generic template arguments) as the initial template
arguments.

gcc/cp/ChangeLog:

PR c++/97412
* constraint.cc (normalize_concept_check): Don't call
tsubst_template_args when 'args' is NULL.

gcc/testsuite/ChangeLog:

PR c++/97412
* g++.dg/cpp2a/concepts-variadic2.C: New test.
---
  gcc/cp/constraint.cc|  3 ++-
  gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C | 12 
  2 files changed, 14 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index f4f5174eff3..75457a2dd60 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -686,7 +686,8 @@ normalize_concept_check (tree check, tree args, norm_info 
info)
  }
  
/* Substitute through the arguments of the concept check. */

-  targs = tsubst_template_args (targs, args, info.complain, info.in_decl);
+  if (args)
+targs = tsubst_template_args (targs, args, info.complain, info.in_decl);
if (targs == error_mark_node)
  return error_mark_node;
  
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C b/gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C

new file mode 100644
index 000..ce61aef5481
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C
@@ -0,0 +1,12 @@
+// PR c++/97412
+// { dg-do compile { target c++20 } }
+
+template 
+concept call_bar_with = requires(T t, TArgs... args) {
+  t.bar(args...);
+};
+
+template 
+concept foo = requires {
+  requires call_bar_with;
+};

Re: [PATCH] c++: Fix up constexpr evaluation of arguments passed by invisible reference [PR97388]

[Jason Merrill via Gcc-patches]

On 10/29/20 11:40 AM, Jakub Jelinek wrote:

On Thu, Oct 29, 2020 at 11:09:05AM -0400, Jason Merrill wrote:

I think this isn't enough; if bar calls foo twice, the second call will find
the value in the hash table and not change the temporary, so the destructor
will throw.  I think we also need to set non_constant_args if the argument
type has a non-trivial destructor, so we don't try to memoize the call.


For the testcases with constexpr new in there it wouldn't be memoized
already, but you are right that for other cases making it non_constant_args
is desirable.


Then setting arg back to orig_arg isn't needed, because we don't do the
first unsharing for the hash table.


Yes.


And then I think that the second unsharing is unnecessary for an argument in
a non-memoized call, because we will have already unshared it when making
the copy in the caller.


I'm not sure about this one, but if it works, I'm not against that, the less
unsharing the better for compile time memory unless it breaks stuff.

I'll bootstrap/regtest your patchset (or do you want to do that)?


I already did, thanks.

Jason

Re: Avoid char[] array in tree_def

[Jakub Jelinek via Gcc-patches]

On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> > 
> > That's ugly and will for sure defeat warning / access code
> > when we access this as char[], no?  I mean, we could
> > as well use 'int str[1];' here?
> 
> Well, we always get char pointer via macro that is IMO OK, but I am also
> not very much in love with this.

Do we treat signed char [...]; as typeless storage too, or just
what the C++ standard requires (i.e. char, unsigned char and std::byte
where the last one is enum type with unsigned char underlying type)?

Jakub

Re: Avoid char[] array in tree_def

[Richard Biener]

On Thu, 29 Oct 2020, Jan Hubicka wrote:

> > 
> > That's ugly and will for sure defeat warning / access code
> > when we access this as char[], no?  I mean, we could
> > as well use 'int str[1];' here?
> 
> Well, we always get char pointer via macro that is IMO OK, but I am also
> not very much in love with this.
> > 
> > Maybe we can invent some C++ attribute for this?
> > 
> > [[gnu::string]]
> > 
> > or so that marks it as actual char and not typeless storage?
> 
> Attribute would probably make sense.  Not sure if gnu::string is best
> name given that it can be also meaningful for array of small integers
> (such as in wide_int).

OK, maybe [[gnu::strictly_typed]] then?

> Honza
> > 
> > Richard.
> > 
> > >  };
> > >  
> > >  struct GTY(()) tree_complex {
> > > diff --git a/gcc/tree.c b/gcc/tree.c
> > > index 81f867ddded..84115630184 100644
> > > --- a/gcc/tree.c
> > > +++ b/gcc/tree.c
> > > @@ -2273,7 +2273,7 @@ build_string (unsigned len, const char *str /*= 
> > > NULL */)
> > >  memcpy (s->string.str, str, len);
> > >else
> > >  memset (s->string.str, 0, len);
> > > -  s->string.str[len] = '\0';
> > > +  s->string.str[len].c = '\0';
> > >  
> > >return s;
> > >  }
> > > 
> > 
> > -- 
> > Richard Biener 
> > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> > Germany; GF: Felix Imend
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend

[PATCH] Fix some memleaks

[Richard Biener]

This fixes some memleaks, one older, one recently introduced.

Bootstrap / regtest in progress on x86_64-unknown-linux-gnu.

2020-10-29  Richard Biener  

* tree-ssa-pre.c (compute_avail): Free operands consistently.
* tree-vect-loop.c (vectorizable_phi): Make sure all operand
defs vectors are released.
---
 gcc/tree-ssa-pre.c   | 5 -
 gcc/tree-vect-loop.c | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-ssa-pre.c b/gcc/tree-ssa-pre.c
index 63f3a81e94c..bcef9720095 100644
--- a/gcc/tree-ssa-pre.c
+++ b/gcc/tree-ssa-pre.c
@@ -3953,7 +3953,10 @@ compute_avail (void)
 adding the reference to EXP_GEN.  */
  if (BB_MAY_NOTRETURN (block)
  && vn_reference_may_trap (ref))
-   continue;
+   {
+ operands.release ();
+ continue;
+   }
 
  /* If the value of the reference is not invalidated in
 this block until it is computed, add the expression
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 75b731407ba..5ab125d15c6 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -7570,7 +7570,6 @@ vectorizable_phi (vec_info *,
   tree scalar_dest = gimple_phi_result (stmt_info->stmt);
   basic_block bb = gimple_bb (stmt_info->stmt);
   tree vec_dest = vect_create_destination_var (scalar_dest, vectype);
-  auto_vec vec_oprnds;
   auto_vec new_phis;
   for (unsigned i = 0; i < gimple_phi_num_args (stmt_info->stmt); ++i)
 {
@@ -7581,6 +7580,7 @@ vectorizable_phi (vec_info *,
  && SLP_TREE_VEC_STMTS (child).is_empty ())
continue;
 
+  auto_vec vec_oprnds;
   vect_get_slp_defs (SLP_TREE_CHILDREN (slp_node)[i], _oprnds);
   if (!new_phis.exists ())
{
-- 
2.26.2

Re: Avoid char[] array in tree_def

[Jan Hubicka]

> 
> That's ugly and will for sure defeat warning / access code
> when we access this as char[], no?  I mean, we could
> as well use 'int str[1];' here?

Well, we always get char pointer via macro that is IMO OK, but I am also
not very much in love with this.
> 
> Maybe we can invent some C++ attribute for this?
> 
> [[gnu::string]]
> 
> or so that marks it as actual char and not typeless storage?

Attribute would probably make sense.  Not sure if gnu::string is best
name given that it can be also meaningful for array of small integers
(such as in wide_int).

Honza
> 
> Richard.
> 
> >  };
> >  
> >  struct GTY(()) tree_complex {
> > diff --git a/gcc/tree.c b/gcc/tree.c
> > index 81f867ddded..84115630184 100644
> > --- a/gcc/tree.c
> > +++ b/gcc/tree.c
> > @@ -2273,7 +2273,7 @@ build_string (unsigned len, const char *str /*= NULL 
> > */)
> >  memcpy (s->string.str, str, len);
> >else
> >  memset (s->string.str, 0, len);
> > -  s->string.str[len] = '\0';
> > +  s->string.str[len].c = '\0';
> >  
> >return s;
> >  }
> > 
> 
> -- 
> Richard Biener 
> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> Germany; GF: Felix Imend

[Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

[Paul Richard Thomas via Gcc-patches]

Hi Everyone,

I am afraid that this is a rather long sad story, mainly due to my efforts
with gfortran being interrupted by daytime work. I posted the first version
of the patch nearly a year ago but this was derailed by Tobias's question
at: https://gcc.gnu.org/legacy-ml/fortran/2019-11/msg00098.html

(i) The attached fixes the original problem and is tested by
gfortran.dg/unlimited_polymorphic_32.f03.
(ii) In fixing the original problem, a fair amount of effort was required
to get the element length correct for class temporaries produced by
dependencies in class assignment (see footnote). This is reflected in the
changes to trans_array.c(gfc_alloc_allocatable_for_assignment).
(iii) Tobias's testcase in the above posting to the list didn't address
itself to class arrays of the original problem. However, it revealed that
reallocation was not occuring at all for scalar assignments.  This is fixed
by the large chunk in trans-expr.c(trans_class_assignment). The array case
is 'fixed' by testing for unequal element sizes between lhs and rhs before
reallocation in gfc_alloc_allocatable_for_assignment. This is difficult to
test for since, in most cases, the system returns that same address after
reallocation.
(iv) dependency_57.f90 segfaulted at runtime. The other work in
trans_class_assignment was required to fix this.
(v) A number of minor tidy ups were done including the new function
gfc_resize_class_size_with_len to eliminate some repeated code.

This all bootstraps and regtests on FC31/x86_64 - OK for master?

Cheers

Paul

This patch fixes PR83118 and fixes one or two other niggles in handling
class objects - most importantly class array temporaries required, where
dependences occur in class assignment, and a correct implementation of
reallocation on assignment.

2020-10-29  Paul Thomas  

gcc/fortran
PR fortran/83118
* resolve.c (resolve_ordinary_assign): Generate a vtable if
necessary for scalar non-polymorphic rhs's to unlimited lhs's.
* trans-array.c (gfc_trans_allocate_array_storage): Defer
obtaining class element type until all sources of class exprs.
are tried. Use class API rather than TREE_OPERAND. Look for
class expressions in ss->info. After this, obtain the element
size for class payloads. Cast the data as character(len=size)
to overcome unlimited polymorphic problems.
(structure_alloc_comps): Replace code that replicates the new
function gfc_resize_class_size_with_len.
(gfc_alloc_allocatable_for_assignment): Obtain element size
for lhs in cases of deferred characters and class enitities.
Move code for the element size of rhs to start of block. Clean
up extraction of class parmateres throughout this function.
After the shape check test whether or not the lhs and rhs
element sizes are the same. Use earlier evaluation of
'cond_null'. Reallocation of lhs only to happen if siz changes
or element size changes.
* trans-expr.c (gfc_resize_class_size_with_len): New function.
(gfc_conv_procedure_call): Ensure the vtable is present for
passing a non-class actual to an unlimited formal.
(trans_class_vptr_len_assignment): For expressions of type
BT_CLASS, extract the class expression if necessary. Use a
statement block outside the loop body. Ensure that 'rhs' is
of the correct type. Obtain rhs vptr in all circumstances.
(gfc_trans_assignment_1): Simplify some of the logic with
'realloc_flag'. Set 'vptr_copy' for all array assignments to
unlimited polymorphic lhs.
* trans-c (gfc_build_array_ref): Call gfc_resize_class_size_
with_len to correct span for unlimited polymorphic decls.
* trans.h : Add prototype for gfc_resize_class_size_with_len.

gcc/testsuite/
PR fortran/83118
* gfortran.dg/dependency_57.f90: Change to dg-run and test
for correct result.
* gfortran.dg/unlimited_polymorphic_32.f03: New test.

Footnote: I have come to the conclusion that
gfc_trans_allocate_array_storage is the last place that we should be
dealing with class array temporaries, or directly at least. I will give
some thought as to how to do it better. Also, chunks of code are coming
within scalarization loops that should be outside:
  x->_vptr = (struct __vtype__STAR * {ref-all})
&__vtab_INTEGER_4_;
  x->_len = 0;
  D.3977 = x->_vptr->_size;
  D.3978 = x->_len;
  D.3979 = D.3978 > 0 ? D.3977 * D.3978 : D.3977;


Change2.Logs
Description: Binary data


unlimited_polymorphic_32.f03
Description: Binary data

Re: Avoid char[] array in tree_def

[Jan Hubicka]

> On Thu, Oct 29, 2020 at 04:50:54PM +0100, Jan Hubicka wrote:
> > * tree.c (build_string): Update.
> > * tree-core.h (tree_fixed_cst): Avoid typeless storage.
> 
> Is it valid then to
> #define TREE_STRING_POINTER(NODE) \
>   ((const char *)(STRING_CST_CHECK (NODE)->string.str))
> and strcpy etc. it around though?
> Maybe yes, because stores through char can alias anything.

Yep, I think it should be valid for that reason.  The whole thing is not
terribly pretty (the wide-int change was better), but I do not know of
better solution and it affects our core datastructure.  Typeless storage
is really complicated concept.  Forutnately it seems that there are no
more hacks like this needed: both tree and gimple now gets non-zero
alias set.

Honza
> 
> > diff --git a/gcc/tree-core.h b/gcc/tree-core.h
> > index c9280a8d3b1..63dbb5b8eab 100644
> > --- a/gcc/tree-core.h
> > +++ b/gcc/tree-core.h
> > @@ -1401,7 +1401,8 @@ struct GTY(()) tree_fixed_cst {
> >  struct GTY(()) tree_string {
> >struct tree_typed typed;
> >int length;
> > -  char str[1];
> > +  /* Avoid char array that would make whole type to be typeless storage.  
> > */
> > +  struct {char c;} str[1];
> >  };
> >  
> >  struct GTY(()) tree_complex {
> > diff --git a/gcc/tree.c b/gcc/tree.c
> > index 81f867ddded..84115630184 100644
> > --- a/gcc/tree.c
> > +++ b/gcc/tree.c
> > @@ -2273,7 +2273,7 @@ build_string (unsigned len, const char *str /*= NULL 
> > */)
> >  memcpy (s->string.str, str, len);
> >else
> >  memset (s->string.str, 0, len);
> > -  s->string.str[len] = '\0';
> > +  s->string.str[len].c = '\0';
> >  
> >return s;
> >  }
> 
>   Jakub
> 

Re: Avoid char[] array in tree_def

[Richard Biener]

On Thu, 29 Oct 2020, Jan Hubicka wrote:

> Hi,
> this patch removes second char array from tree_def union and makes it
> !TYPELESS_STORAGE.  Now all accesses to anything in tree no longer have alias
> set 0, but they all have alias set 1 :)
> This is because the way we handle unions. However it still increases TBAA
> effectivity by about 12%. From:
> 
> Alias oracle query stats:
>   refs_may_alias_p: 65066258 disambiguations, 74846942 queries
>   ref_maybe_used_by_call_p: 152444 disambiguations, 65966862 queries
>   call_may_clobber_ref_p: 22546 disambiguations, 28559 queries
>   nonoverlapping_component_refs_p: 0 disambiguations, 36816 queries
>   nonoverlapping_refs_since_match_p: 27230 disambiguations, 58300 must 
> overlaps, 86300 queries
>   aliasing_component_refs_p: 66090 disambiguations, 2048800 queries
>   TBAA oracle: 25578632 disambiguations 59483650 queries
>12219919 are in alias set 0
>10534575 queries asked about the same object
>125 queries asked about the same alias set
>0 access volatile
>9491563 are dependent in the DAG
>1658836 are aritificially in conflict with void *
> 
> Modref stats:
>   modref use: 14421 disambiguations, 48129 queries
>   modref clobber: 1528229 disambiguations, 1926907 queries
>   3881547 tbaa queries (2.014392 per modref query)
>   565057 base compares (0.293246 per modref query)
> 
> PTA query stats:
>   pt_solution_includes: 947491 disambiguations, 13119151 queries
>   pt_solutions_intersect: 1043695 disambiguations, 13221495 queries
> 
> To:
> 
> Alias oracle query stats:
>   refs_may_alias_p: 66455561 disambiguations, 75202803 queries
>   ref_maybe_used_by_call_p: 155301 disambiguations, 67370278 queries
>   call_may_clobber_ref_p: 22550 disambiguations, 28587 queries
>   nonoverlapping_component_refs_p: 0 disambiguations, 37058 queries
>   nonoverlapping_refs_since_match_p: 28126 disambiguations, 59906 must 
> overlaps, 88990 queries
>   aliasing_component_refs_p: 66375 disambiguations, 2440039 queries
>   TBAA oracle: 28800751 disambiguations 64328055 queries
>8053661 are in alias set 0
>11181983 queries asked about the same object
>125 queries asked about the same alias set
>0 access volatile
>13905691 are dependent in the DAG
>2385844 are aritificially in conflict with void *
> 
> Modref stats:
>   modref use: 16781 disambiguations, 52031 queries
>   modref clobber: 1745589 disambiguations, 2149518 queries
>   4192266 tbaa queries (1.950328 per modref query)
>   559148 base compares (0.260127 per modref query)
> 
> PTA query stats:
>   pt_solution_includes: 906487 disambiguations, 13105994 queries
>   pt_solutions_intersect: 1041144 disambiguations, 13659726 queries
> 
> Bootstrapped/regtested x86_64-linux, OK?
> 
>   * tree.c (build_string): Update.
>   * tree-core.h (tree_fixed_cst): Avoid typeless storage.
> 
> diff --git a/gcc/tree-core.h b/gcc/tree-core.h
> index c9280a8d3b1..63dbb5b8eab 100644
> --- a/gcc/tree-core.h
> +++ b/gcc/tree-core.h
> @@ -1401,7 +1401,8 @@ struct GTY(()) tree_fixed_cst {
>  struct GTY(()) tree_string {
>struct tree_typed typed;
>int length;
> -  char str[1];
> +  /* Avoid char array that would make whole type to be typeless storage.  */
> +  struct {char c;} str[1];

That's ugly and will for sure defeat warning / access code
when we access this as char[], no?  I mean, we could
as well use 'int str[1];' here?

Maybe we can invent some C++ attribute for this?

[[gnu::string]]

or so that marks it as actual char and not typeless storage?

Richard.

>  };
>  
>  struct GTY(()) tree_complex {
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 81f867ddded..84115630184 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -2273,7 +2273,7 @@ build_string (unsigned len, const char *str /*= NULL */)
>  memcpy (s->string.str, str, len);
>else
>  memset (s->string.str, 0, len);
> -  s->string.str[len] = '\0';
> +  s->string.str[len].c = '\0';
>  
>return s;
>  }
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend

Re: [committed] libstdc++: Make std::function work better with -fno-rtti

[Jonathan Wakely via Gcc-patches]

On 29/10/20 14:49 +, Jonathan Wakely wrote:

This change allows std::function::target() to work even without RTTI,
using the same approach as std::any. Because we know what the manager
function would be for a given type, we can check if the stored pointer
has the expected address. If it does, we don't need to use RTTI. If it
isn't equal, we still need to do the RTTI check (when RTTI is enabled)
to handle the case where the same function has different addresses in
different shared objects.

This also changes the implementation of the manager function to return a
null pointer result when asked for the type_info of the target object.
This not only avoids a warning with -Wswitch -Wsystem-headers, but also
avoids prevents std::function::target_type() from dereferencing an
uninitialized pointer when the linker keeps an instantiation of the
manager function that was compiled without RTTI.

Finally, this fixes a bug in the non-const overload of function::target
where calling it with a function type F was ill-formed, due to
attempting to use const_cast(ptr). The standard only allows
const_cast when T is an object type.  The solution is to use
*const_cast() instead, because F* is an object type even if F
isn't. I've also used _GLIBCXX17_CONSTEXPR in function::target so that
it doesn't bother instantiating anything for types that can never be a
valid target.

libstdc++-v3/ChangeLog:

* include/bits/std_function.h (_Function_handler):
Define explicit specialization used for invalid target types.
(_Base_manager::_M_manager) [!__cpp_rtti]: Return null.
(function::target_type()): Check for null pointer.
(function::target()): Define unconditionall. Fix bug with
const_cast of function pointer type.
(function::target() const): Define unconditionally, but
only use RTTI if enabled.
* testsuite/20_util/function/target_no_rtti.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

2
1
0


Oops, sorry for the duplicate mail about this. My mailer ate my
attempt to script something.

Re: Avoid char[] array in tree_def

[Jakub Jelinek via Gcc-patches]

On Thu, Oct 29, 2020 at 04:50:54PM +0100, Jan Hubicka wrote:
>   * tree.c (build_string): Update.
>   * tree-core.h (tree_fixed_cst): Avoid typeless storage.

Is it valid then to
#define TREE_STRING_POINTER(NODE) \
  ((const char *)(STRING_CST_CHECK (NODE)->string.str))
and strcpy etc. it around though?
Maybe yes, because stores through char can alias anything.

> diff --git a/gcc/tree-core.h b/gcc/tree-core.h
> index c9280a8d3b1..63dbb5b8eab 100644
> --- a/gcc/tree-core.h
> +++ b/gcc/tree-core.h
> @@ -1401,7 +1401,8 @@ struct GTY(()) tree_fixed_cst {
>  struct GTY(()) tree_string {
>struct tree_typed typed;
>int length;
> -  char str[1];
> +  /* Avoid char array that would make whole type to be typeless storage.  */
> +  struct {char c;} str[1];
>  };
>  
>  struct GTY(()) tree_complex {
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 81f867ddded..84115630184 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -2273,7 +2273,7 @@ build_string (unsigned len, const char *str /*= NULL */)
>  memcpy (s->string.str, str, len);
>else
>  memset (s->string.str, 0, len);
> -  s->string.str[len] = '\0';
> +  s->string.str[len].c = '\0';
>  
>return s;
>  }

Jakub

Avoid char[] array in tree_def

[Jan Hubicka]

Hi,
this patch removes second char array from tree_def union and makes it
!TYPELESS_STORAGE.  Now all accesses to anything in tree no longer have alias
set 0, but they all have alias set 1 :)
This is because the way we handle unions. However it still increases TBAA
effectivity by about 12%. From:

Alias oracle query stats:
  refs_may_alias_p: 65066258 disambiguations, 74846942 queries
  ref_maybe_used_by_call_p: 152444 disambiguations, 65966862 queries
  call_may_clobber_ref_p: 22546 disambiguations, 28559 queries
  nonoverlapping_component_refs_p: 0 disambiguations, 36816 queries
  nonoverlapping_refs_since_match_p: 27230 disambiguations, 58300 must 
overlaps, 86300 queries
  aliasing_component_refs_p: 66090 disambiguations, 2048800 queries
  TBAA oracle: 25578632 disambiguations 59483650 queries
   12219919 are in alias set 0
   10534575 queries asked about the same object
   125 queries asked about the same alias set
   0 access volatile
   9491563 are dependent in the DAG
   1658836 are aritificially in conflict with void *

Modref stats:
  modref use: 14421 disambiguations, 48129 queries
  modref clobber: 1528229 disambiguations, 1926907 queries
  3881547 tbaa queries (2.014392 per modref query)
  565057 base compares (0.293246 per modref query)

PTA query stats:
  pt_solution_includes: 947491 disambiguations, 13119151 queries
  pt_solutions_intersect: 1043695 disambiguations, 13221495 queries

To:

Alias oracle query stats:
  refs_may_alias_p: 66455561 disambiguations, 75202803 queries
  ref_maybe_used_by_call_p: 155301 disambiguations, 67370278 queries
  call_may_clobber_ref_p: 22550 disambiguations, 28587 queries
  nonoverlapping_component_refs_p: 0 disambiguations, 37058 queries
  nonoverlapping_refs_since_match_p: 28126 disambiguations, 59906 must 
overlaps, 88990 queries
  aliasing_component_refs_p: 66375 disambiguations, 2440039 queries
  TBAA oracle: 28800751 disambiguations 64328055 queries
   8053661 are in alias set 0
   11181983 queries asked about the same object
   125 queries asked about the same alias set
   0 access volatile
   13905691 are dependent in the DAG
   2385844 are aritificially in conflict with void *

Modref stats:
  modref use: 16781 disambiguations, 52031 queries
  modref clobber: 1745589 disambiguations, 2149518 queries
  4192266 tbaa queries (1.950328 per modref query)
  559148 base compares (0.260127 per modref query)

PTA query stats:
  pt_solution_includes: 906487 disambiguations, 13105994 queries
  pt_solutions_intersect: 1041144 disambiguations, 13659726 queries

Bootstrapped/regtested x86_64-linux, OK?

* tree.c (build_string): Update.
* tree-core.h (tree_fixed_cst): Avoid typeless storage.

diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index c9280a8d3b1..63dbb5b8eab 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1401,7 +1401,8 @@ struct GTY(()) tree_fixed_cst {
 struct GTY(()) tree_string {
   struct tree_typed typed;
   int length;
-  char str[1];
+  /* Avoid char array that would make whole type to be typeless storage.  */
+  struct {char c;} str[1];
 };
 
 struct GTY(()) tree_complex {
diff --git a/gcc/tree.c b/gcc/tree.c
index 81f867ddded..84115630184 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -2273,7 +2273,7 @@ build_string (unsigned len, const char *str /*= NULL */)
 memcpy (s->string.str, str, len);
   else
 memset (s->string.str, 0, len);
-  s->string.str[len] = '\0';
+  s->string.str[len].c = '\0';
 
   return s;
 }

Re: [PATCH] c++: Fix up constexpr evaluation of arguments passed by invisible reference [PR97388]

[Jakub Jelinek via Gcc-patches]

On Thu, Oct 29, 2020 at 11:09:05AM -0400, Jason Merrill wrote:
> I think this isn't enough; if bar calls foo twice, the second call will find
> the value in the hash table and not change the temporary, so the destructor
> will throw.  I think we also need to set non_constant_args if the argument
> type has a non-trivial destructor, so we don't try to memoize the call.

For the testcases with constexpr new in there it wouldn't be memoized
already, but you are right that for other cases making it non_constant_args
is desirable.

> Then setting arg back to orig_arg isn't needed, because we don't do the
> first unsharing for the hash table.

Yes.

> And then I think that the second unsharing is unnecessary for an argument in
> a non-memoized call, because we will have already unshared it when making
> the copy in the caller.

I'm not sure about this one, but if it works, I'm not against that, the less
unsharing the better for compile time memory unless it breaks stuff.

I'll bootstrap/regtest your patchset (or do you want to do that)?

Jakub

Re: [PATCH v2] c++: Implement CWG 625: Use of auto as template-arg [PR97479]

[Jason Merrill via Gcc-patches]

On 10/28/20 10:56 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 02:34:15PM -0400, Jason Merrill via Gcc-patches wrote:

On 10/28/20 2:02 PM, Marek Polacek wrote:

This patch implements CWG 625 which prohibits using auto in a template
argument.  A few tests used this construction.  We could perhaps only
give an error in C++20, but not in C++17 with -fconcepts.


We should not give an error with -fconcepts-ts, this was allowed by the
Concepts TS.


Ah, I see.  Presumably we should only get the errors on { target c++20 }.


...which won't happen in c++17_only tests, so no need to change auto[134].C.


Does just changing !flag_concepts to !flag_concepts_ts work?


Almost: one issue is that it would regress the error message for
something like

   using T = auto;

for which we have dedicated code in grokdeclarator, which is nicer than just
the terse "invalid use."  So I think if flag_concepts is on, we should still
check in_template_argument_list_p.  Since the logic has gotten a bit tricky,
I've introduced a new variable, rather than to play hard-to-read games with
?: in the if.

Thanks,

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

-- >8 --
This patch implements CWG 625 which prohibits using auto in a template
argument.  A few tests used this construction.  Since this usage was
allowed by the Concepts TS, we only give an error in C++20.

gcc/cp/ChangeLog:

DR 625
PR c++/97479
* parser.c (cp_parser_type_id_1): Reject using auto as
a template-argument in C++20.

gcc/testsuite/ChangeLog:

DR 625
PR c++/97479
* g++.dg/concepts/auto1.C: Add dg-error.
* g++.dg/concepts/auto3.C: Likewise.
* g++.dg/concepts/auto4.C: Likewise.
* g++.dg/cpp0x/auto3.C: Update dg-error.
* g++.dg/cpp0x/auto9.C: Likewise.
* g++.dg/cpp2a/concepts-pr84979-2.C: Likewise.
* g++.dg/cpp2a/concepts-pr84979-3.C: Likewise.
* g++.dg/cpp2a/concepts-pr84979.C: Likewise.
* g++.dg/DRs/dr625.C: New test.
---
  gcc/cp/parser.c | 15 +--
  gcc/testsuite/g++.dg/DRs/dr625.C| 15 +++
  gcc/testsuite/g++.dg/concepts/auto1.C   |  4 ++--
  gcc/testsuite/g++.dg/concepts/auto3.C   |  6 +++---
  gcc/testsuite/g++.dg/concepts/auto4.C   |  2 +-
  gcc/testsuite/g++.dg/cpp0x/auto3.C  |  2 +-
  gcc/testsuite/g++.dg/cpp0x/auto9.C  |  2 +-
  gcc/testsuite/g++.dg/cpp2a/concepts-pr84979-2.C | 12 ++--
  gcc/testsuite/g++.dg/cpp2a/concepts-pr84979-3.C | 12 ++--
  gcc/testsuite/g++.dg/cpp2a/concepts-pr84979.C   |  2 +-
  10 files changed, 49 insertions(+), 23 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/DRs/dr625.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 234079559b9..6570b0af889 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -22417,9 +22417,17 @@ cp_parser_type_id_1 (cp_parser *parser, 
cp_parser_flags flags,
if (!cp_parser_parse_definitely (parser))
  abstract_declarator = NULL;
  
+  bool auto_typeid_ok = false;

+  /* The concepts TS allows 'auto' as a type-id.  */
+  if (flag_concepts_ts)
+auto_typeid_ok = !parser->in_type_id_in_expr_p;
+  /* DR 625 prohibits use of auto as a template-argument.  */


In this comment, please mention that we're only allowing it here for the 
better diagnostic.  OK with this and dropping the unnecessary testsuite 
changes.



+  else if (flag_concepts)
+auto_typeid_ok = (!parser->in_type_id_in_expr_p
+ && !parser->in_template_argument_list_p);
+
if (type_specifier_seq.type
-  /* The concepts TS allows 'auto' as a type-id.  */
-  && (!flag_concepts || parser->in_type_id_in_expr_p)
+  && !auto_typeid_ok
/* None of the valid uses of 'auto' in C++14 involve the type-id
 nonterminal, but it is valid in a trailing-return-type.  */
&& !(cxx_dialect >= cxx14 && is_trailing_return))
@@ -22446,6 +22454,9 @@ cp_parser_type_id_1 (cp_parser *parser, cp_parser_flags 
flags,
inform (DECL_SOURCE_LOCATION (tmpl), "%qD declared here",
tmpl);
  }
+   else if (parser->in_template_argument_list_p)
+ error_at (loc, "%qT not permitted in template argument",
+   auto_node);
else
  error_at (loc, "invalid use of %qT", auto_node);
return error_mark_node;
diff --git a/gcc/testsuite/g++.dg/DRs/dr625.C b/gcc/testsuite/g++.dg/DRs/dr625.C
new file mode 100644
index 000..ce30a9258e6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/DRs/dr625.C
@@ -0,0 +1,15 @@
+// DR 625 - Use of auto as a template-argument
+// PR c++/97479
+// { dg-do compile { target c++14 } }
+
+template
+struct A { };
+
+void f(int);
+
+int main()
+{
+  A x = A(); // { dg-error "not permitted|invalid|cannot 
convert" }
+  A a = A(); // { dg-error "not permitted|invalid|cannot convert" }
+  void 

Re: [PATCH 1/2] c++: Tolerate empty initial targs during normalization [PR97412]

[Patrick Palka via Gcc-patches]

On Mon, 19 Oct 2020, Patrick Palka wrote:

> When normalizing the constraint-expression of a nested-requirement, we
> pass NULL_TREE as the initial template arguments for normalization, but
> tsubst_argument_pack is not prepared to handle a NULL_TREE targ vector.
> This causes us to ICE when normalizing a variadic concept as part of a
> nested-requirement.
> 
> This patch fixes the ICE by guarding the call to tsubst_template_args in
> normalize_concept_check appropriately.  This will also enables us to
> simplify many of the normalization routines to pass NULL_TREE instead of
> a set of generic template arguments as the initial template arguments,
> which will be done in a subsequent patch.

Ping.  For some reason I confusingly referred to 'targs' in the commit
message when the variable in question is actually 'args'.  So I've
adjusted the commit message below:

-- >8 --

Subject: [PATCH] c++: Tolerate empty initial args during normalization
 [PR97412]

When normalizing the constraint-expression of a nested-requirement, we
pass NULL_TREE as the initial template arguments for normalization, but
tsubst_argument_pack is not prepared to handle a NULL_TREE args vector.
This causes us to ICE when normalizing a variadic concept as part of a
nested-requirement.

This patch fixes the ICE by guarding the call to tsubst_template_args in
normalize_concept_check appropriately.  This will also enable us to
simplify many of the normalization routines to just pass NULL_TREE
(instead of a set of generic template arguments) as the initial template
arguments.

gcc/cp/ChangeLog:

PR c++/97412
* constraint.cc (normalize_concept_check): Don't call
tsubst_template_args when 'args' is NULL.

gcc/testsuite/ChangeLog:

PR c++/97412
* g++.dg/cpp2a/concepts-variadic2.C: New test.
---
 gcc/cp/constraint.cc|  3 ++-
 gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index f4f5174eff3..75457a2dd60 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -686,7 +686,8 @@ normalize_concept_check (tree check, tree args, norm_info 
info)
 }
 
   /* Substitute through the arguments of the concept check. */
-  targs = tsubst_template_args (targs, args, info.complain, info.in_decl);
+  if (args)
+targs = tsubst_template_args (targs, args, info.complain, info.in_decl);
   if (targs == error_mark_node)
 return error_mark_node;
 
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C
new file mode 100644
index 000..ce61aef5481
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-variadic2.C
@@ -0,0 +1,12 @@
+// PR c++/97412
+// { dg-do compile { target c++20 } }
+
+template 
+concept call_bar_with = requires(T t, TArgs... args) {
+  t.bar(args...);
+};
+
+template 
+concept foo = requires {
+  requires call_bar_with;
+};
-- 
2.29.0.rc0

Re: [PATCH] c++: Deprecate arithmetic convs on different enums [PR97573]

[Jason Merrill via Gcc-patches]

On 10/28/20 10:46 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 02:43:30PM -0400, Jason Merrill wrote:

On 10/28/20 2:01 PM, Marek Polacek wrote:

I noticed that C++20 P1120R0 deprecated certain arithmetic conversions
as outlined in [depr.arith.conv.enum], but we don't warn about them.  In
particular, "If one operand is of enumeration type and the other operand
is of a different enumeration type or a floating-point type, this
behavior is deprecated."  These will likely become ill-formed in C++23,
so we should warn by default in C++20.  To this effect, this patch adds
two new warnings (like clang++): -Wdeprecated-enum-enum-conversion and
-Wdeprecated-enum-float-conversion.  They are enabled by default in
C++20.  In older dialects, to enable these warnings you can now use
-Wenum-conversion which I made available in C++ too.  Note that unlike
C, in C++ it is not enabled by -Wextra, because that breaks bootstrap.

We already warn about comparisons of two different enumeration types via
-Wenum-compare, the rest is handled in this patch: we're performing the
usual arithmetic conversions in these contexts:
- an arithmetic operation,
- a bitwise operation,
- a comparison,
- a conditional operator,
- a compound assign operator.

Using the spaceship operator as enum <=> real_type is ill-formed but we
don't reject it yet.


Hmm, oops.  Will you fix that as well?  It should be simple to fix in the
SPACESHIP_EXPR block that starts just at the end of this patch.


Sure.

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


OK, thanks.


 From 8ae2e45f2dd35510aed3be1ab249b8612e33f00d Mon Sep 17 00:00:00 2001
From: Marek Polacek 
Date: Wed, 28 Oct 2020 19:02:29 -0400
Subject: [PATCH] c++: Reject float <=> enum.

As [depr.arith.conv.enum] says, these are ill-formed.

gcc/cp/ChangeLog:

* typeck.c (do_warn_enum_conversions): Don't warn for SPACESHIP_EXPR.
(cp_build_binary_op): Reject float <=> enum or enum <=> float.  Use
CP_INTEGRAL_TYPE_P instead of INTEGRAL_OR_ENUMERATION_TYPE_P.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/enum-conv1.C: Remove unused code.
* g++.dg/cpp2a/spaceship-err5.C: New test.
---
  gcc/cp/typeck.c | 13 ++--
  gcc/testsuite/g++.dg/cpp2a/enum-conv1.C |  3 ---
  gcc/testsuite/g++.dg/cpp2a/spaceship-err5.C | 23 +
  3 files changed, 34 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-err5.C

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 7305310ecbe..d3b701610cf 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -4512,6 +4512,9 @@ do_warn_enum_conversions (location_t loc, enum tree_code 
code, tree type0,
"with enumeration type %qT is deprecated",
type0, type1);
  return;
+   case SPACESHIP_EXPR:
+ /* This is invalid, don't warn.  */
+ return;
default:
  if (enum_first_p)
warning_at (loc, opt, "arithmetic between enumeration type %qT "
@@ -5584,6 +5587,12 @@ cp_build_binary_op (const op_location_t ,
   arithmetic conversions are applied to the operands."  So we don't do
   arithmetic conversions if the operands both have enumeral type.  */
result_type = NULL_TREE;
+  else if ((orig_code0 == ENUMERAL_TYPE && orig_code1 == REAL_TYPE)
+  || (orig_code0 == REAL_TYPE && orig_code1 == ENUMERAL_TYPE))
+   /* [depr.arith.conv.enum]: Three-way comparisons between such operands
+  [where one is of enumeration type and the other is of a different
+  enumeration type or a floating-point type] are ill-formed.  */
+   result_type = NULL_TREE;
  
if (result_type)

{
@@ -5598,12 +5607,12 @@ cp_build_binary_op (const op_location_t ,
 type to a floating point type, the program is ill-formed.  */
  bool ok = true;
  if (TREE_CODE (result_type) == REAL_TYPE
- && INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (orig_op0)))
+ && CP_INTEGRAL_TYPE_P (orig_type0))
/* OK */;
  else if (!check_narrowing (result_type, orig_op0, complain))
ok = false;
  if (TREE_CODE (result_type) == REAL_TYPE
- && INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (orig_op1)))
+ && CP_INTEGRAL_TYPE_P (orig_type1))
/* OK */;
  else if (!check_narrowing (result_type, orig_op1, complain))
ok = false;
diff --git a/gcc/testsuite/g++.dg/cpp2a/enum-conv1.C 
b/gcc/testsuite/g++.dg/cpp2a/enum-conv1.C
index d4960f334dd..4571b5e8968 100644
--- a/gcc/testsuite/g++.dg/cpp2a/enum-conv1.C
+++ b/gcc/testsuite/g++.dg/cpp2a/enum-conv1.C
@@ -110,9 +110,6 @@ enum_float (bool b)
r += b ? d : u1; // { dg-warning "conditional expression between" "" { 
target c++20 } }
r += b ? u1 : d; // { dg-warning "conditional expression between" "" { 
target c++20 } }
  
-  // FIXME 

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

[Jason Merrill via Gcc-patches]

On 10/28/20 7:40 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote:

On 10/28/20 1:58 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches wrote:

On 10/24/20 7:40 PM, Marek Polacek wrote:

On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason Merrill via Gcc-patches wrote:

On 10/23/20 3:01 PM, Marek Polacek wrote:

This patch implements the -Wvexing-parse warning to warn about the
sneaky most vexing parse rule in C++: the cases when a declaration
looks like a variable definition, but the C++ language requires it
to be interpreted as a function declaration.  This warning is on by
default (like clang++).  From the docs:

  void f(double a) {
int i();// extern int i (void);
int n(int(a));  // extern int n (int);
  }

  Another example:

  struct S { S(int); };
  void f(double a) {
S x(int(a));   // extern struct S x (int);
S y(int());// extern struct S y (int (*) (void));
S z(); // extern struct S z (void);
  }

You can find more on this in [dcl.ambig.res].

I spent a fair amount of time on fix-it hints so that GCC can recommend
various ways to resolve such an ambiguity.  Sometimes that's tricky.
E.g., suggesting default-initialization when the class doesn't have
a default constructor would not be optimal.  Suggesting {}-init is also
not trivial because it can use an initializer-list constructor if no
default constructor is available (which ()-init wouldn't do).  And of
course, pre-C++11, we shouldn't be recommending {}-init at all.


What do you think of, instead of passing the type down into the declarator
parse, adding the paren locations to cp_declarator::function and giving the
diagnostic from cp_parser_init_declarator instead?


Oops, now I see there's already cp_declarator::parenthesized; might as well
reuse that.  And maybe change it to a range, while we're at it.


I'm afraid I can't reuse it because grokdeclarator uses it to warn about
"unnecessary parentheses in declaration".  So when we have:

int (x());

declarator->parenthesized points to the outer parens (if any), whereas
declarator->u.function.parens_loc should point to the inner ones.  We also
have declarator->id_loc but I think we should only use it for declarator-ids.


Makes sense.


(We should still adjust ->parenthesized to be a range to generate a better
diagnostic; I shall send a patch soon.)


Hmm, I wonder why we have the parenthesized_p parameter to some of these
functions, since we can look at the declarator to find that information...


That would be a nice cleanup.


Interesting idea.  I suppose it's better, and makes the implementation
more localized.  The approach here is that if the .function.parens_loc
is UNKNOWN_LOCATION, we've not seen a vexing parse.


I'd rather always set the parens location, and then analyze the
cp_declarator in warn_about_ambiguous_parse to see if it's a vexing parse;
we should have all the information we need.


I could always set .parens_loc, but then I'd still need another flag telling
me whether we had an ambiguity.  Otherwise I don't know how I would tell
apart e.g. "int f()" (warn) v. "int f(void)" (don't warn), etc.


Ah, I was thinking that we still had the parameter declarators, but now I
see that cp_parser_parameter_declaration_list groks them and returns a
TREE_LIST.  We could set a TREE_LANG_FLAG on each TREE_LIST if its parameter
declarator was parenthesized?


I think so, looks like we have a bunch of free TREE_LANG_FLAG slots on
a TREE_LIST.  But cp_parser_parameter_declaration_clause can return
a void_list_node, so I assume I'd have to copy_node it before setting
some new flag in it.  Do you think that'd be fine?


There's no declarator in a void_list_node, so we shouldn't need to set a 
"declarator is parenthesized" flag on it.


Jason

Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]

[Jason Merrill via Gcc-patches]

On 10/28/20 10:45 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 05:48:08PM -0400, Jason Merrill wrote:

On 10/28/20 5:29 PM, Marek Polacek wrote:

On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote:

On 10/28/20 2:00 PM, Marek Polacek wrote:

On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote:

On 10/24/20 6:52 PM, Marek Polacek wrote:

Here, in r11-155, I changed the call to uses_template_parms to
type_dependent_expression_p_push to avoid a crash in C++98 in
value_dependent_expression_p on a non-constant expression.  But that
prompted a host of complaints that we now warn for value-dependent
expressions in templates.  Those warnings are technically valid, but
people still don't want them because they're awkward to avoid.  So let's
partially revert my earlier fix and make sure that we don't ICE in
value_dependent_expression_p by checking potential_constant_expression
first.

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

gcc/cp/ChangeLog:

PR c++/96675
PR c++/96742
* pt.c (tsubst_copy_and_build): Call uses_template_parms instead of
type_dependent_expression_p_push.  Only call uses_template_parms
for expressions that are potential_constant_expression.

gcc/testsuite/ChangeLog:

PR c++/96675
PR c++/96742
* g++.dg/warn/Wdiv-by-zero-3.C: Turn dg-warning into dg-bogus.
* g++.dg/warn/Wtautological-compare3.C: New test.
* g++.dg/warn/Wtype-limits5.C: New test.
* g++.old-deja/g++.pt/crash10.C: Remove dg-warning.
---
 gcc/cp/pt.c|  6 --
 gcc/testsuite/g++.dg/warn/Wdiv-by-zero-3.C |  6 --
 gcc/testsuite/g++.dg/warn/Wtautological-compare3.C | 11 +++
 gcc/testsuite/g++.dg/warn/Wtype-limits5.C  | 11 +++
 gcc/testsuite/g++.old-deja/g++.pt/crash10.C|  1 -
 5 files changed, 30 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wtautological-compare3.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wtype-limits5.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc664ec3798..8aa0bc2c0d8 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19618,8 +19618,10 @@ tsubst_copy_and_build (tree t,
   {
/* If T was type-dependent, suppress warnings that depend on the range
   of the types involved.  */
-   bool was_dep = type_dependent_expression_p_push (t);
-
+   ++processing_template_decl;
+   const bool was_dep = (!potential_constant_expression (t)
+ || uses_template_parms (t));


We don't want to suppress warnings for a non-constant expression that uses
no template parms.  So maybe


Fair enough.


potential_c_e ? value_d : type_d


That works for all the cases I have.


?  Or perhaps instantiation_dependent_expression_p.


i_d_e_p would still crash in C++98 :(.


Perhaps we should protect the value_d call in i_d_e_p with potential_c_e?


Yeah, probably.  But then we should also guard the call to value_d in
uses_template_parms.  I can apply such a patch if it tests fine, if you
want.


Or change uses_template_parms to use i_d.


Experimenting with this revealed a curious issue: when we have
__PRETTY_FUNCTION__ in a template function, we set its DECL_VALUE_EXPR
to error_mark_node (cp_make_fname_decl), so potential_c_e returns false
when it gets it, but value_dependent_expression_p handles it specially
and says true.  So this patch

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -27277,7 +27277,8 @@ bool
  instantiation_dependent_expression_p (tree expression)
  {
return (instantiation_dependent_uneval_expression_p (expression)
- || value_dependent_expression_p (expression));
+ || (potential_constant_expression (expression)
+ && value_dependent_expression_p (expression)));
  }
  
  /* Like type_dependent_expression_p, but it also works while not processing


breaks lambda-generic-pretty1.C.  ISTM that potential_c_e should return
true for a DECL_PRETTY_FUNCTION_P with error DECL_VALUE_EXPR.


Agreed.

Jason

Re: [PATCH] c++: Diagnose constexpr delete [] new int; and delete new int[N]; [PR95808]

[Jason Merrill via Gcc-patches]

On 10/16/20 5:42 AM, Jakub Jelinek wrote:

Hi!

This patch diagnoses delete [] new int; and delete new int[1]; in constexpr
contexts by remembering
IDENTIFIER_OVL_OP_FLAGS (DECL_NAME (fun)) & OVL_OP_FLAG_VEC
from the operator new and checking it at operator delete time.

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

2020-10-16  Jakub Jelinek  

PR c++/95808
* cp-tree.h (enum cp_tree_index): Add CPTI_HEAP_VEC_UNINIT_IDENTIFIER
and CPTI_HEAP_VEC_IDENTIFIER.
(heap_vec_uninit_identifier, heap_vec_identifier): Define.
* decl.c (initialize_predefined_identifiers): Initialize those
identifiers.
* constexpr.c (cxx_eval_call_expression): Reject array allocations
deallocated with non-array deallocation or non-array allocations
deallocated with array deallocation.
(non_const_var_error): Handle heap_vec_uninit_identifier and
heap_vec_identifier too.
(cxx_eval_constant_expression): Handle also heap_vec_uninit_identifier
and in that case during initialization replace it with
heap_vec_identifier.
(find_heap_var_refs): Handle heap_vec_uninit_identifier and
heap_vec_identifier too.

* g++.dg/cpp2a/constexpr-new15.C: New test.

--- gcc/cp/cp-tree.h.jj 2020-10-14 22:05:19.274858485 +0200
+++ gcc/cp/cp-tree.h2020-10-15 16:29:12.136899207 +0200
@@ -178,6 +178,8 @@ enum cp_tree_index
  CPTI_HEAP_UNINIT_IDENTIFIER,
  CPTI_HEAP_IDENTIFIER,
  CPTI_HEAP_DELETED_IDENTIFIER,
+CPTI_HEAP_VEC_UNINIT_IDENTIFIER,
+CPTI_HEAP_VEC_IDENTIFIER,
  
  CPTI_LANG_NAME_C,

  CPTI_LANG_NAME_CPLUSPLUS,
@@ -322,6 +324,8 @@ extern GTY(()) tree cp_global_trees[CPTI
  #define heap_uninit_identifier
cp_global_trees[CPTI_HEAP_UNINIT_IDENTIFIER]
  #define heap_identifier   
cp_global_trees[CPTI_HEAP_IDENTIFIER]
  #define heap_deleted_identifier   
cp_global_trees[CPTI_HEAP_DELETED_IDENTIFIER]
+#define heap_vec_uninit_identifier 
cp_global_trees[CPTI_HEAP_VEC_UNINIT_IDENTIFIER]
+#define heap_vec_identifier
cp_global_trees[CPTI_HEAP_VEC_IDENTIFIER]
  #define lang_name_c   cp_global_trees[CPTI_LANG_NAME_C]
  #define lang_name_cplusplus   
cp_global_trees[CPTI_LANG_NAME_CPLUSPLUS]
  
--- gcc/cp/decl.c.jj	2020-10-14 22:05:19.293858210 +0200

+++ gcc/cp/decl.c   2020-10-15 16:30:05.690125490 +0200
@@ -4242,6 +4242,8 @@ initialize_predefined_identifiers (void)
  {"heap uninit", _uninit_identifier, cik_normal},
  {"heap ", _identifier, cik_normal},
  {"heap deleted", _deleted_identifier, cik_normal},
+{"heap [] uninit", _vec_uninit_identifier, cik_normal},
+{"heap []", _vec_identifier, cik_normal},
  {NULL, NULL, cik_normal}
};
  
--- gcc/cp/constexpr.c.jj	2020-10-01 11:16:36.390959542 +0200

+++ gcc/cp/constexpr.c  2020-10-15 17:02:31.036021476 +0200
@@ -2288,7 +2288,11 @@ cxx_eval_call_expression (const constexp
{
  tree type = build_array_type_nelts (char_type_node,
  tree_to_uhwi (arg0));
- tree var = build_decl (loc, VAR_DECL, heap_uninit_identifier,
+ tree var = build_decl (loc, VAR_DECL,
+(IDENTIFIER_OVL_OP_FLAGS (DECL_NAME (fun))
+ & OVL_OP_FLAG_VEC)
+? heap_vec_uninit_identifier
+: heap_uninit_identifier,
 type);
  DECL_ARTIFICIAL (var) = 1;
  TREE_STATIC (var) = 1;
@@ -2306,6 +2310,42 @@ cxx_eval_call_expression (const constexp
  if (DECL_NAME (var) == heap_uninit_identifier
  || DECL_NAME (var) == heap_identifier)
{
+ if (IDENTIFIER_OVL_OP_FLAGS (DECL_NAME (fun))
+ & OVL_OP_FLAG_VEC)
+   {
+ if (!ctx->quiet)
+   {
+ error_at (loc, "array deallocation of object "
+"allocated with non-array "
+"allocation");
+ inform (DECL_SOURCE_LOCATION (var),
+ "allocation performed here");
+   }
+ *non_constant_p = true;
+ return t;
+   }
+ DECL_NAME (var) = heap_deleted_identifier;
+ ctx->global->values.remove (var);
+ ctx->global->heap_dealloc_count++;
+ return void_node;
+   }
+ else if (DECL_NAME (var) == heap_vec_uninit_identifier
+  || DECL_NAME (var) == heap_vec_identifier)
+   {