Re: [RS6000] VSX_MM_SUFFIX

2020-10-24 Thread Alan Modra via Gcc-patches
On Sat, Oct 24, 2020 at 12:31:43PM -0500, Segher Boessenkool wrote:
> On Sat, Oct 24, 2020 at 02:59:34PM +1030, Alan Modra wrote:
> > Those instructions aren't generated, we don't see them anywhere on a
> > power10 all-lang bootstrap except in one testcase designed to exercise
> > them.
> 
> But that is completely not relevant :-)
> 
> If you use a macro that doesn't exist, the compiler simply does not
> build!

My empirical evidence to the contrary says your theoretical arguments
are invalid.  :-)

$ gcc/xgcc -Bgcc/ -S 
~/src/gcc/gcc/testsuite/gcc.target/powerpc/vsx_mask-count-runnable.c -O2 
-mcpu=power10
$ grep VSX_MM vsx_mask-count-runnable.s
vcntmb 9,0,1
vcntmb 9,0,1
vcntmb 9,0,1
vcntmb 9,0,1

-- 
Alan Modra
Australia Development Lab, IBM


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

2020-10-24 Thread Marek Polacek via Gcc-patches
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?

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.

The tests haven't changed at all in this patch.

Thanks,

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

-- >8 --
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.

I also uncovered a bug in cp_parser_declarator, where we were setting
*parenthesized_p to true despite the comment saying the exact opposite.

gcc/c-family/ChangeLog:

PR c++/25814
* c.opt (Wvexing-parse): New option.

gcc/cp/ChangeLog:

PR c++/25814
* cp-tree.h (struct cp_declarator): Add the function::parens_loc
member.
* parser.c (make_call_declarator): New location_t parameter.  Use it
to set declarator->u.function.parens_loc.
(cp_parser_lambda_declarator_opt): Pass UNKNOWN_LOCATION to
make_call_declarator.
(warn_about_ambiguous_parse): New function.
(cp_parser_init_declarator): Call warn_about_ambiguous_parse.
(cp_parser_declarator): Set *parenthesized_p to false rather than to
true.
(cp_parser_direct_declarator): Have
cp_parser_parameter_declaration_clause set a flag if it encountered
a vexing parse.  Crate a location for the function's parentheses and
pass it to make_call_declarator.
(cp_parser_parameter_declaration_clause): New bool * parameter with
a default value.  Set it.  Pass it to
cp_parser_parameter_declaration_list.
(cp_parser_parameter_declaration_list): New bool * parameter.  Set it.
(cp_parser_cache_defarg): Adjust the call to
cp_parser_parameter_declaration_list.

gcc/ChangeLog:

PR c++/25814
* doc/invoke.texi: Document -Wvexing-parse.

gcc/testsuite/ChangeLog:

PR c++/25814
* g++.dg/cpp2a/fn-template16.C: Add a dg-warning.
* g++.dg/cpp2a/fn-template7.C: Likewise.
* g++.dg/lookup/pr80891-5.C: Likewise.
* g++.dg/lto/pr79050_0.C: Add extern.
* g++.dg/lto/pr84805_0.C: Likewise.
* g++.dg/parse/pr58898.C: Add a dg-warning.
* g++.dg/template/scope5.C: 

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

2020-10-24 Thread Marek Polacek via Gcc-patches
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));
+   --processing_template_decl;
tree op0 = RECUR (TREE_OPERAND (t, 0));
tree op1 = RECUR (TREE_OPERAND (t, 1));
 
diff --git a/gcc/testsuite/g++.dg/warn/Wdiv-by-zero-3.C 
b/gcc/testsuite/g++.dg/warn/Wdiv-by-zero-3.C
index 424eb0c3d49..01f691f2878 100644
--- a/gcc/testsuite/g++.dg/warn/Wdiv-by-zero-3.C
+++ b/gcc/testsuite/g++.dg/warn/Wdiv-by-zero-3.C
@@ -5,8 +5,10 @@ foo (T t, int i)
 {
   int m1 = 10 / t;
   int m2 = 10 / i;
-  int m3 = 10 / (sizeof(T) - sizeof(int)); // { dg-warning "division by" }
-  int m4 = 10 / N; // { dg-warning "division by" }
+  // People don't want to see warnings for type- or value-dependent
+  // expressions.
+  int m3 = 10 / (sizeof(T) - sizeof(int)); // { dg-bogus "division by" }
+  int m4 = 10 / N; // { dg-bogus "division by" }
   return m1 + m2 + m3 + m4;
 }
 
diff --git a/gcc/testsuite/g++.dg/warn/Wtautological-compare3.C 
b/gcc/testsuite/g++.dg/warn/Wtautological-compare3.C
new file mode 100644
index 000..89bf1b619a6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wtautological-compare3.C
@@ -0,0 +1,11 @@
+// PR c++/96675
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-Wtautological-compare" }
+
+template
+constexpr bool f(char d) {
+return 'a' <= c && c <= 'z' ? (d | 0x20) == c :
+'A' <= c && c <= 'Z' ? (d & ~0x20) == c :
+d == c;
+}
+static_assert(f<'p'>('P'), "");
diff --git a/gcc/testsuite/g++.dg/warn/Wtype-limits5.C 
b/gcc/testsuite/g++.dg/warn/Wtype-limits5.C
new file mode 100644
index 000..5e79123b622
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wtype-limits5.C
@@ -0,0 +1,11 @@
+// PR c++/96742
+// { dg-additional-options "-Wtype-limits" }
+
+template 
+bool f(unsigned x) {
+return unsigned(x < N);
+}
+
+int main() {
+f<0>(1);
+}
diff --git a/gcc/testsuite/g++.old-deja/g++.pt/crash10.C 
b/gcc/testsuite/g++.old-deja/g++.pt/crash10.C
index 012e3d0c11b..a84b19004ee 100644
--- a/gcc/testsuite/g++.old-deja/g++.pt/crash10.C
+++ b/gcc/testsuite/g++.old-deja/g++.pt/crash10.C
@@ -6,7 +6,6 @@ public:
   enum { val = (N == 0) ? M : GCD::val };
 // { dg-error "constant expression" "valid" { target *-*-* } .-1 }
 // { dg-message "template argument" "valid" { target *-*-* } .-2 }
-// { dg-warning "division by" "" { target *-*-* } .-3 }
 };
 
 int main() {

base-commit: 1aeb7d7d67d167297ca2f4a97ef20f68e7546b4c
-- 
2.26.2



Re: [patch, fortran] Partial fix for PR97454, declarations of some library functions

2020-10-24 Thread Thomas Koenig via Gcc-patches

Hello world,


here's a patch which corrects some wrong declarations (and fixes
the segfault for FINDLOC on Darwin ARM).

Regression-tested. OK for trunk?


ping?

Regards

Thomas


Re: [RS6000] VSX_MM_SUFFIX

2020-10-24 Thread Segher Boessenkool
On Sat, Oct 24, 2020 at 02:59:34PM +1030, Alan Modra wrote:
> On Fri, Oct 23, 2020 at 04:06:57PM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 23, 2020 at 09:41:30AM +1030, Alan Modra wrote:
> > > On Thu, Oct 22, 2020 at 11:03:14AM -0500, Segher Boessenkool wrote:
> > > > On Thu, Oct 22, 2020 at 08:58:10AM -0700, Carl Love wrote:
> > > > > OK, looks like VSX_MM_SUFFIX doesn't exist anymore.  Don't know what
> > > > > happed to it.  Thanks.
> > > > 
> > > > It never existed on trunk.  Please always regstrap patches on trunk
> > > > before committing.  It feels unnecessary at times, but now you know
> > > > why :-)
> > > 
> > > Regression testing wouldn't have caught the problem, unless Carl had
> > > done so on power10.
> > 
> > "regstrap" is "bootstrap + regression check".  It won't bootstrap (won't
> > cross build even afaics?)
> 
> Those instructions aren't generated, we don't see them anywhere on a
> power10 all-lang bootstrap except in one testcase designed to exercise
> them.

But that is completely not relevant :-)

If you use a macro that doesn't exist, the compiler simply does not
build!


Segher


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

2020-10-24 Thread Uros Bizjak via Gcc-patches
On Sat, Oct 24, 2020 at 6:05 PM Qing Zhao  wrote:
>
> Hi,
>
> This is the 4th version of the implementation of patch -fzero-call-used-regs.
>
> The major change compared to the previous version are:
>
> 1.  Documentation change per Richard’s suggestion;
> 2.  Command sub options handling per Richard’s suggestion;
> 3.  I386 part, clearing ST registers per Uros’s suggestion;
> 4. Some minor spelling and style fix.
>
> I have tested this new GCC on both x86 and arm64, no regression.
>
> Please let me know whether it’s ready for stage 1 gcc11?
>
> Thanks.
>
>
> **The changelog:
>
> gcc/ChangeLog:
>
> 2020-10-24  Qing Zhao  
> H.J.Lu  
>
> * common.opt: Add new option -fzero-call-used-regs
> * config/i386/i386.c (zero_call_used_regno_p): New function.
> (zero_call_used_regno_mode): Likewise.
> (zero_all_vector_registers): Likewise.
> (zero_all_st_mm_registers): Likewise.
> (ix86_zero_call_used_regs): Likewise.
> (TARGET_ZERO_CALL_USED_REGS): Define.
> * df-scan.c (df_epilogue_uses_p): New function.
> (df_get_exit_block_use_set): Replace EPILOGUE_USES with
> df_epilogue_uses_p.
> * df.h (df_epilogue_uses_p): Declare.
> * doc/extend.texi: Document the new zero_call_used_regs attribute.
> * doc/invoke.texi: Document the new -fzero-call-used-regs option.
> * doc/tm.texi: Regenerate.
> * doc/tm.texi.in (TARGET_ZERO_CALL_USED_REGS): New hook.
> * emit-rtl.h (struct rtl_data): New fields zero_call_used_regs
> and must_be_zero_on_return.
> * flag-types.h (enum  zero_call_used_regs_code): New type.
> * function.c (gen_call_used_regs_seq): New function.
> (rest_of_zero_call_used_regs): Likewise.
> (class pass_zero_call_used_regs): New class.
> (pass_zero_call_used_regs::gate): New function.
> (make_pass_zero_call_used_regs): New function.
> * optabs.c (expand_asm_reg_clobber_mem_blockage): New function.
> * optabs.h (expand_asm_reg_clobber_mem_blockage): Declare.
> * opts.c (zero_call_used_regs_opts): New structure array
> initialization.
> (parse_zero_call_used_regs_options): New function.
> (common_handle_option): Handle fzero_call_used_regs_.
> * opts.h (zero_call_used_regs_opts): New structure array.
> * passes.def: Add new pass pass_zero_call_used_regs.
> * resource.c (init_resource_info): Replace EPILOGUE_USES with
> df_epilogue_uses_p.
> * target.def (zero_call_used_regs): New hook.
> * targhooks.c (default_zero_call_used_regs): New function.
> * targhooks.h (default_zero_call_used_regs): Declare.
> * tree-pass.h (make_pass_zero_call_used_regs): Declare.
>
> gcc/c-family/ChangeLog:
>
> 2020-10-24  Qing Zhao  
> H.J.Lu  
>
> * c-attribs.c (c_common_attribute_table): Add new attribute
> zero_call_used_regs.
> (handle_zero_call_used_regs_attribute): New function.
>
> gcc/testsuite/ChangeLog:
>
> 2020-10-24  Qing Zhao  
> H.J.Lu  
>
> * gcc.target/i386/zero-scratch-regs-1.c: New test.
> * gcc.target/i386/zero-scratch-regs-10.c: New test.
> * gcc.target/i386/zero-scratch-regs-11.c: New test.
> * gcc.target/i386/zero-scratch-regs-12.c: New test.
> * gcc.target/i386/zero-scratch-regs-13.c: New test.
> * gcc.target/i386/zero-scratch-regs-14.c: New test.
> * gcc.target/i386/zero-scratch-regs-15.c: New test.
> * gcc.target/i386/zero-scratch-regs-16.c: New test.
> * gcc.target/i386/zero-scratch-regs-17.c: New test.
> * gcc.target/i386/zero-scratch-regs-18.c: New test.
> * gcc.target/i386/zero-scratch-regs-19.c: New test.
> * gcc.target/i386/zero-scratch-regs-2.c: New test.
> * gcc.target/i386/zero-scratch-regs-20.c: New test.
> * gcc.target/i386/zero-scratch-regs-21.c: New test.
> * gcc.target/i386/zero-scratch-regs-22.c: New test.
> * gcc.target/i386/zero-scratch-regs-23.c: New test.
> * gcc.target/i386/zero-scratch-regs-24.c: New test.
> * gcc.target/i386/zero-scratch-regs-25.c: New test.
> * gcc.target/i386/zero-scratch-regs-26.c: New test.
> * gcc.target/i386/zero-scratch-regs-27.c: New test.
> * gcc.target/i386/zero-scratch-regs-3.c: New test.
> * gcc.target/i386/zero-scratch-regs-4.c: New test.
> * gcc.target/i386/zero-scratch-regs-5.c: New test.
> * gcc.target/i386/zero-scratch-regs-6.c: New test.
> * gcc.target/i386/zero-scratch-regs-7.c: New test.
> * gcc.target/i386/zero-scratch-regs-8.c: New test.
> * gcc.target/i386/zero-scratch-regs-9.c: New test.
>
> **the patch:
>
> From 0da0f0f2203b1e3bb2be8c12a0a1addd3c20a534 Mon Sep 17 00:00:00 2001
> From: qing zhao 
> Date: Thu, 1 Oct 2020 00:27:57 +
> Subject: [PATCH] The 4th version of 

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

2020-10-24 Thread Qing Zhao via Gcc-patches
Hi, 

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

The major change compared to the previous version are:

1.  Documentation change per Richard’s suggestion;
2.  Command sub options handling per Richard’s suggestion;
3.  I386 part, clearing ST registers per Uros’s suggestion;
4. Some minor spelling and style fix.

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

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

Thanks.


**The changelog:

gcc/ChangeLog:

2020-10-24  Qing Zhao  
H.J.Lu  

* common.opt: Add new option -fzero-call-used-regs
* config/i386/i386.c (zero_call_used_regno_p): New function.
(zero_call_used_regno_mode): Likewise.
(zero_all_vector_registers): Likewise.
(zero_all_st_mm_registers): Likewise.
(ix86_zero_call_used_regs): Likewise.
(TARGET_ZERO_CALL_USED_REGS): Define.
* df-scan.c (df_epilogue_uses_p): New function.
(df_get_exit_block_use_set): Replace EPILOGUE_USES with
df_epilogue_uses_p.
* df.h (df_epilogue_uses_p): Declare.
* doc/extend.texi: Document the new zero_call_used_regs attribute.
* doc/invoke.texi: Document the new -fzero-call-used-regs option.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_ZERO_CALL_USED_REGS): New hook. 
* emit-rtl.h (struct rtl_data): New fields zero_call_used_regs
and must_be_zero_on_return.
* flag-types.h (enum  zero_call_used_regs_code): New type.
* function.c (gen_call_used_regs_seq): New function.
(rest_of_zero_call_used_regs): Likewise.
(class pass_zero_call_used_regs): New class.
(pass_zero_call_used_regs::gate): New function.
(make_pass_zero_call_used_regs): New function.
* optabs.c (expand_asm_reg_clobber_mem_blockage): New function.
* optabs.h (expand_asm_reg_clobber_mem_blockage): Declare.
* opts.c (zero_call_used_regs_opts): New structure array 
initialization.  
(parse_zero_call_used_regs_options): New function.
(common_handle_option): Handle fzero_call_used_regs_.
* opts.h (zero_call_used_regs_opts): New structure array.
* passes.def: Add new pass pass_zero_call_used_regs.
* resource.c (init_resource_info): Replace EPILOGUE_USES with
df_epilogue_uses_p.
* target.def (zero_call_used_regs): New hook.
* targhooks.c (default_zero_call_used_regs): New function.
* targhooks.h (default_zero_call_used_regs): Declare.
* tree-pass.h (make_pass_zero_call_used_regs): Declare.

gcc/c-family/ChangeLog:

2020-10-24  Qing Zhao  
H.J.Lu  

* c-attribs.c (c_common_attribute_table): Add new attribute
zero_call_used_regs.
(handle_zero_call_used_regs_attribute): New function.

gcc/testsuite/ChangeLog:

2020-10-24  Qing Zhao  
H.J.Lu  

* gcc.target/i386/zero-scratch-regs-1.c: New test.
* gcc.target/i386/zero-scratch-regs-10.c: New test.
* gcc.target/i386/zero-scratch-regs-11.c: New test.
* gcc.target/i386/zero-scratch-regs-12.c: New test.
* gcc.target/i386/zero-scratch-regs-13.c: New test.
* gcc.target/i386/zero-scratch-regs-14.c: New test.
* gcc.target/i386/zero-scratch-regs-15.c: New test.
* gcc.target/i386/zero-scratch-regs-16.c: New test.
* gcc.target/i386/zero-scratch-regs-17.c: New test.
* gcc.target/i386/zero-scratch-regs-18.c: New test.
* gcc.target/i386/zero-scratch-regs-19.c: New test.
* gcc.target/i386/zero-scratch-regs-2.c: New test.
* gcc.target/i386/zero-scratch-regs-20.c: New test.
* gcc.target/i386/zero-scratch-regs-21.c: New test.
* gcc.target/i386/zero-scratch-regs-22.c: New test.
* gcc.target/i386/zero-scratch-regs-23.c: New test.
* gcc.target/i386/zero-scratch-regs-24.c: New test.
* gcc.target/i386/zero-scratch-regs-25.c: New test.
* gcc.target/i386/zero-scratch-regs-26.c: New test.
* gcc.target/i386/zero-scratch-regs-27.c: New test.
* gcc.target/i386/zero-scratch-regs-3.c: New test.
* gcc.target/i386/zero-scratch-regs-4.c: New test.
* gcc.target/i386/zero-scratch-regs-5.c: New test.
* gcc.target/i386/zero-scratch-regs-6.c: New test.
* gcc.target/i386/zero-scratch-regs-7.c: New test.
* gcc.target/i386/zero-scratch-regs-8.c: New test.
* gcc.target/i386/zero-scratch-regs-9.c: New test.

**the patch:

From 0da0f0f2203b1e3bb2be8c12a0a1addd3c20a534 Mon Sep 17 00:00:00 2001
From: qing zhao 
Date: Thu, 1 Oct 2020 00:27:57 +
Subject: [PATCH] The 4th version of -fzero-call-used-regs
We will provide a new feature into GCC:

Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg
   |all-arg|used-gpr|all-gpr|used|all] 
command-line option
and

Re: V2 [PATCH] Update check for working assembler --gdwarf-4 option

2020-10-24 Thread Jakub Jelinek via Gcc-patches
On Sat, Oct 24, 2020 at 08:28:08AM -0700, H.J. Lu wrote:
> The updated patch to check
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=26778
> 
> OK for master?

Ok, thanks.

> From 7130dea1f39692a8a00e48ef119233595f9284c9 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Fri, 16 Oct 2020 05:59:51 -0700
> Subject: [PATCH] Update check for working assembler --gdwarf-4 option
> 
> Rename HAVE_AS_WORKING_DWARF_4_FLAG to HAVE_AS_WORKING_DWARF_N_FLAG
> Don't set HAVE_AS_WORKING_DWARF_N_FLAG if --gdwarf-5/--gdwarf-4 generate
> an extra assembly input file in debug info from compiler generated
> .debug_line or fail with the APP marker:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=25878
> https://sourceware.org/bugzilla/show_bug.cgi?id=26740
> https://sourceware.org/bugzilla/show_bug.cgi?id=26778
> 
> Also replace success with dwarf4_success in the 32-bit --gdwarf-4 check.
> 
>   PR bootstrap/97451
>   * configure.ac (HAVE_AS_WORKING_DWARF_4_FLAG): Renamed to ...
>   (HAVE_AS_WORKING_DWARF_N_FLAG): This.  Don't define if there is
>   an extra assembly input file in debug info.  Replace success
>   with dwarf4_success in the 32-bit --gdwarf-4 check.
>   * dwarf2out.c (asm_outputs_debug_line_str): Check
>   HAVE_AS_WORKING_DWARF_N_FLAG instead of
>   HAVE_AS_WORKING_DWARF_4_FLAG.
>   * gcc.c (ASM_DEBUG_SPEC): Likewise.
>   (ASM_DEBUG_OPTION_SPEC): Likewise.
>   * config.in: Regenerated.
>   * configure: Likewise.
> ---
>  gcc/config.in|   6 +--
>  gcc/configure| 106 +--
>  gcc/configure.ac |  59 --
>  gcc/dwarf2out.c  |   2 +-
>  gcc/gcc.c|   4 +-
>  5 files changed, 164 insertions(+), 13 deletions(-)
> 
> diff --git a/gcc/config.in b/gcc/config.in
> index 3657c46f349..b7c3107bfe3 100644
> --- a/gcc/config.in
> +++ b/gcc/config.in
> @@ -719,10 +719,10 @@
>  #endif
>  
>  
> -/* Define if your assembler supports --gdwarf-4 even with compiler generated
> -   .debug_line */
> +/* Define if your assembler supports --gdwarf-4/--gdwarf-5 even with compiler
> +   generated .debug_line. */
>  #ifndef USED_FOR_TARGET
> -#undef HAVE_AS_WORKING_DWARF_4_FLAG
> +#undef HAVE_AS_WORKING_DWARF_N_FLAG
>  #endif
>  
>  
> diff --git a/gcc/configure b/gcc/configure
> index abff47d30eb..f96a89e8c37 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -28701,7 +28701,7 @@ fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
> $gcc_cv_as_debug_line_32_flag" >&5
>  $as_echo "$gcc_cv_as_debug_line_32_flag" >&6; }
>  if test $gcc_cv_as_debug_line_32_flag = yes; then
> -  success=yes
> +  dwarf4_success=yes
>  fi
>  
> else
> @@ -28741,6 +28741,7 @@ fi
>  
> fi
> if test $dwarf4_success = yes; then
> + dwarf4_success=no
>   { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for 
> --gdwarf-4 not refusing compiler generated .debug_line" >&5
>  $as_echo_n "checking assembler for --gdwarf-4 not refusing compiler 
> generated .debug_line... " >&6; }
>  if ${gcc_cv_as_dwarf_4_debug_line_flag+:} false; then :
> @@ -28772,9 +28773,7 @@ fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
> $gcc_cv_as_dwarf_4_debug_line_flag" >&5
>  $as_echo "$gcc_cv_as_dwarf_4_debug_line_flag" >&6; }
>  if test $gcc_cv_as_dwarf_4_debug_line_flag = yes; then
> -
> -$as_echo "#define HAVE_AS_WORKING_DWARF_4_FLAG 1" >>confdefs.h
> -
> +  dwarf4_success=yes
>  fi
>  
>   break
> @@ -28785,6 +28784,105 @@ fi
> dwarf4_line_sz=5
>   done
>  
> + if test $dwarf4_success = yes; then
> +   conftest_s="\
> + .file   \"foo.c\"
> + .text
> +bar:
> +#APP
> +# 82 \"xxx.h\" 1
> + $insn
> +# 0 \"\" 2
> +#NO_APP
> + $insn
> +foo:
> + .file 1 \"foo.c\"
> + $insn
> + .file 2 \"foo.h\"
> + ret
> +"
> +   dwarf4_success=no
> +   { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for 
> --gdwarf-4 with the APP marker" >&5
> +$as_echo_n "checking assembler for --gdwarf-4 with the APP marker... " >&6; }
> +if ${gcc_cv_as_dwarf_4_app_flag+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  gcc_cv_as_dwarf_4_app_flag=no
> +  if test x$gcc_cv_as != x; then
> +$as_echo "$conftest_s" > conftest.s
> +if { ac_try='$gcc_cv_as $gcc_cv_as_flags --gdwarf-4 -o conftest.o 
> conftest.s >&5'
> +  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> +  (eval $ac_try) 2>&5
> +  ac_status=$?
> +  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> +  test $ac_status = 0; }; }
> +then
> + gcc_cv_as_dwarf_4_app_flag=yes
> +else
> +  echo "configure: failed program was" >&5
> +  cat conftest.s >&5
> +fi
> +rm -f conftest.o conftest.s
> +  fi
> +fi
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
> $gcc_cv_as_dwarf_4_app_flag" >&5
> +$as_echo "$gcc_cv_as_dwarf_4_app_flag" >&6; }
> +if test $gcc_cv_as_dwarf_4_app_flag = yes; then
> +  dwarf4_success=yes
> +fi
> +
> + fi
> +
> + if test $dwarf4_success = 

Re: [PATCH] g++, libstdc++: implement __is_nothrow_{constructible, assignable}

2020-10-24 Thread Marek Polacek via Gcc-patches
On Sat, Oct 24, 2020 at 03:11:29AM +0300, Ville Voutilainen wrote:
> On Sat, 24 Oct 2020 at 03:07, Marek Polacek  wrote:
> > > Ha, we have the same thing in is_trivially_xible, so I'll drive-by
> > > change that one as well.
> >
> > Please.  Thanks!
> 
> The tree is also on a separated line in is_trivially_xible and
> is_nothrow_xible, but not
> in is_xible. What do we think about line-whitespace changes mixed with
> 'real' changes?

I like to do such cleanups when they are nearby the code I'm changing.  In this
case, I think it's totally fine (though I know not everybody feels the same
way).  Clearly you wouldn't do cleanups in different source files or 1000 lines
away from where you're making your change.

Marek



Re: [PATCH] rs6000, Add bcd builtings listed in appendix B of the ABI

2020-10-24 Thread David Edelsohn via Gcc-patches
Hi, Carl

Not commenting on the implementation.

Please stop using powerpc*-*-* in the test cases.  The test cases
already are in the gcc.target/powerpc directory.

Do the test cases really need lp64, or should this require something
like int128?

Thanks, David

On Fri, Oct 23, 2020 at 9:56 PM Carl Love  wrote:
>
>
> Gcc maintainers:
>
> The following patch adds support for the built-ins listed in Table B.1,
> "Binary-Coded Decimal Built-In Functions" of the "64-Bit ELF V2 ABI
> Specification", July 30, 2019.
>
> The built-ins adds support the V16QI type for addition, subtraction and
> comparison as sepcified in the Table B.1.  Note, the V1TI type was
> previously supported for add, subtract and comparison.  The builtins
> for test for valid value, multiply by 10, divide by 10 and conversion
> to DFP value are also added for the V16QI type as specified in Table
> B.1.
>
> The patch includes adding the #include  to the existing bcd-
> 2.c and bcd-3.c tests so they will pass the regression tests as the
> builtins names are now listed in altivec.h rather then just using
> internal names.
>
> The patch was compiled and tested on:
>
>   powerpc64le-unknown-linux-gnu (Power 9 LE)
>
> with no regressions.
>
> Please let me know if this patch is acceptable for mainline.  Thanks.
>
> Carl Love
> --
>
> gcc/ChangeLog
>
> 2020-10-22  Carl Love  
>
> * config/rs6000/altivec.h (__builtin_bcdadd, __builtin_bcdadd_lt,
> __builtin_bcdadd_eq, __builtin_bcdadd_gt, __builtin_bcdadd_ofl,
> __builtin_bcdadd_ov, __builtin_bcdsub, __builtin_bcdsub_lt,
> __builtin_bcdsub_eq, __builtin_bcdsub_gt, __builtin_bcdsub_ofl,
> __builtin_bcdsub_ov, __builtin_bcdinvalid, __builtin_bcdmul10,
> __builtin_bcddiv10, __builtin_bcd2dfp, __builtin_bcdcmpeq,
> __builtin_bcdcmpgt, __builtin_bcdcmplt, __builtin_bcdcmpge,
> __builtin_bcdcmple): Add defines.
> * config/rs6000/altivec.md: Add UNSPEC_BCDSHIFT.
> (BCD_TEST): Add le, ge to code iterator.
> Add VBCD mode iterator.
> (bcd_test, *bcd_test2,
> bcd_, bcd_): Add mode to name.
> Change iterator from V1TI to VBCD.
> (*bcdinvalid_, bcdshift_v16qi): New define_insn.
> (bcdinvalid_, bcdmul10_v16qi, bcddiv10_v16qi): New define.
> config/rs6000/dfp.md (dfp_denbcd_v16qi_inst): New define_insn.
> (dfp_denbcd_v16qi): New define_expand.
> * confit/rs6000/rs6000-builtin.def (BU_P8V_MISC_1): New define.
> (BCDADD): Replaced with BCDADD_V1TI and BCDADD_V16QI.
> (BCDADD_LT): Replaced with BCDADD_LT_V1TI and BCDADD_LT_V16QI.
> (BCDADD_EQ): Replaced with BCDADD_EQ_V1TI and BCDADD_EQ_V16QI.
> (BCDADD_GT): Replaced with BCDADD_GT_V1TI and BCDADD_GT_V16QI.
> (BCDADD_OV): Replaced with BCDADD_OV_V1TI and BCDADD_OV_V16QI.
> (BCDSUB_V1TI, BCDSUB_V16QI, BCDSUB_LT_V1TI, BCDSUB_LT_V16QI,
> BCDSUB_LE_V1TI, BCDSUB_LE_V16QI, BCDSUB_EQ_V1TI, BCDSUB_EQ_V16QI,
> BCDSUB_GT_V1TI, BCDSUB_GT_V16QI, BCDSUB_GE_V1TI, BCDSUB_GE_V16QI,
> BCDSUB_OV_V1TI, BCDSUB_OV_V16QI, BCDINVALID_V1TI, BCDINVALID_V16QI,
> BCDMUL10_V16QI, BCDDIV10_V16QI, DENBCD_V16QI): New builtin 
> definitions.
> (BCDADD, BCDADD_LT, BCDADD_EQ, BCDADD_GT, BCDADD_OV, BCDSUB, 
> BCDSUB_LT,
> BCDSUB_LE, BCDSUB_EQ, BCDSUB_GT, BCDSUB_GE, BCDSUB_OV, BCDINVALID,
> BCDMUL10, BCDDIV10, DENBCD): New overload definitions.
> config/rs6000/rs6000-call.c (P8V_BUILTIN_VEC_BCDADD, 
> P8V_BUILTIN_VEC_BCDADD_LT,
> P8V_BUILTIN_VEC_BCDADD_EQ, P8V_BUILTIN_VEC_BCDADD_GT, 
> P8V_BUILTIN_VEC_BCDADD_OV,
> P8V_BUILTIN_VEC_BCDINVALID, P9V_BUILTIN_VEC_BCDMUL10, 
> P8V_BUILTIN_VEC_DENBCD.
> P8V_BUILTIN_VEC_BCDSUB, P8V_BUILTIN_VEC_BCDSUB_LT, 
> P8V_BUILTIN_VEC_BCDSUB_LE,
> P8V_BUILTIN_VEC_BCDSUB_EQ, P8V_BUILTIN_VEC_BCDSUB_GT, 
> P8V_BUILTIN_VEC_BCDSUB_GE,
> P8V_BUILTIN_VEC_BCDSUB_OV): New overloaded specifications.
> (CODE_FOR_bcdadd): Replaced with CODE_FOR_bcdadd_v16qi and 
> CODE_FOR_bcdadd_v1ti.
> (CODE_FOR_bcdadd_lt): Replaced with CODE_FOR_bcdadd_lt_v16qi and 
> CODE_FOR_bcdadd_lt_v1ti.
> (CODE_FOR_bcdadd_eq): Replaced with CODE_FOR_bcdadd_eq_v16qi and 
> CODE_FOR_bcdadd_eq_v1ti.
> (CODE_FOR_bcdadd_gt): Replaced with CODE_FOR_bcdadd_gt_v16qi and 
> CODE_FOR_bcdadd_gt_v1ti.
> (CODE_FOR_bcdsub): Replaced with CODE_FOR_bcdsub_v16qi and 
> CODE_FOR_bcdsub_v1ti.
> (CODE_FOR_bcdsub_lt): Replaced with CODE_FOR_bcdsub_lt_v16qi and 
> CODE_FOR_bcdsub_lt_v1ti.
> (CODE_FOR_bcdsub_eq): Replaced with CODE_FOR_bcdsub_eq_v16qi and 
> CODE_FOR_bcdsub_eq_v1ti.
> (CODE_FOR_bcdsub_gt): Replaced with CODE_FOR_bcdsub_gt_v16qi and 
> CODE_FOR_bcdsub_gt_v1ti.
> (rs6000_expand_ternop_builtin):  Add CODE_FOR_dfp_denbcd_v16qi to 
> else if.
> * doc/extend.texi: Add 

V2 [PATCH] Update check for working assembler --gdwarf-4 option

2020-10-24 Thread H.J. Lu via Gcc-patches
On Sat, Oct 17, 2020 at 6:23 AM H.J. Lu  wrote:
>
> On Fri, Oct 16, 2020 at 11:29 AM H.J. Lu  wrote:
> >
> > On Fri, Oct 16, 2020 at 11:17 AM Jakub Jelinek  wrote:
> > >
> > > On Fri, Oct 16, 2020 at 10:58:34AM -0700, H.J. Lu wrote:
> > > > Don't set HAVE_AS_GDWARF_5_DEBUG_FLAG nor HAVE_AS_WORKING_DWARF_4_FLAG
> > > > if there is an extra assembly input file in debug info generated by
> > > > --gdwarf-5/--gdwarf-4:
> > > >
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=25878
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=26740
> > > >
> > > > Also replace success with dwarf4_success in the 32-bit --gdwarf-4 check.
> > > >
> > > > OK for master?
> > > >
> > > >   PR bootstrap/97451
> > > >   * configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG): Don't define if
> > > >   there is an extra assembly input file in debug info.
> > > >   (HAVE_AS_WORKING_DWARF_4_FLAG): Likewise.  Replace success with
> > > >   dwarf4_success in the 32-bit --gdwarf-4 check.
> > > >   * configure: Regenerated.
> > >
> > > The HAVE_AS_GDWARF_5_DEBUG_FLAG macro should be solely about whether
> > > -gdwarf-5 can be passed to as, nothing else.  That is because it is not 
> > > only
> > > used to decide if we can pass -gdwarf-5 to as for assembly of e.g. *.c
> > > compilation, but also if we can pass it to as when gcc driver is invoked 
> > > on
> > > *.s and *.S.  And in that case the problems with -gdwarf-N having unwanted
> > > effects on assembly with compiler generated .debug_info etc. sections.
> > > don't really matter.
> > >
> > > The HAVE_AS_WORKING_DWARF_4_FLAG perhaps could be renamed to
> > > ...DWARF_N_FLAG, it is meant to check for whether we can safely pass the
> > > option also for *.c etc. compilation when we emit debug info sections by 
> > > the
> > > compiler.
> > >
> > > For that, the question is, are all the issues already fixed on the 
> > > binutils
> > > trunk?  As in, do I get identical object files e.g. for -gdwarf-2
> >
> > Not yet.  This patch:
> >
> > https://sourceware.org/pipermail/binutils/2020-October/113744.html
> >
> > is needed for binutils master branch.  BTW, binutils 2.35 and 2.35.1 are
> > broken.
> >
> > > compilation no matter whether the compiler passes -gdwarf-2 to gas or not
> > > (assuming dwarf 2 is the default in gas) when compiling various *.c/*.C
> > > files?  Ditto for modified gas that would default to other .debug_line
> > > versions and corresponding gcc -gdwarf-N flag and passing vs. not passing
> > > that -gdwarf-N to gas?
> > >
> > > The hope is that -gdwarf-N to gas would have two functions:
> > > 1) if the assembly doesn't contain .debug* sections/.file/.loc directives,
> > >emit debug info (mainly .debug_line) for the assembler file in order to
> > >be able to debug those
> > > 2) if the assembly does contain .debug* sections/.file/.loc directives,
> > >only change the version of the .debug_line generated for the .file/.loc
> > >directives, but nothing else; keep all .debug* sections but .debug_line
> > >as is
> >
>
> Here is the updated patch.  OK for master?
>

The updated patch to check

https://sourceware.org/bugzilla/show_bug.cgi?id=26778

OK for master?


-- 
H.J.
From 7130dea1f39692a8a00e48ef119233595f9284c9 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Fri, 16 Oct 2020 05:59:51 -0700
Subject: [PATCH] Update check for working assembler --gdwarf-4 option

Rename HAVE_AS_WORKING_DWARF_4_FLAG to HAVE_AS_WORKING_DWARF_N_FLAG
Don't set HAVE_AS_WORKING_DWARF_N_FLAG if --gdwarf-5/--gdwarf-4 generate
an extra assembly input file in debug info from compiler generated
.debug_line or fail with the APP marker:

https://sourceware.org/bugzilla/show_bug.cgi?id=25878
https://sourceware.org/bugzilla/show_bug.cgi?id=26740
https://sourceware.org/bugzilla/show_bug.cgi?id=26778

Also replace success with dwarf4_success in the 32-bit --gdwarf-4 check.

	PR bootstrap/97451
	* configure.ac (HAVE_AS_WORKING_DWARF_4_FLAG): Renamed to ...
	(HAVE_AS_WORKING_DWARF_N_FLAG): This.  Don't define if there is
	an extra assembly input file in debug info.  Replace success
	with dwarf4_success in the 32-bit --gdwarf-4 check.
	* dwarf2out.c (asm_outputs_debug_line_str): Check
	HAVE_AS_WORKING_DWARF_N_FLAG instead of
	HAVE_AS_WORKING_DWARF_4_FLAG.
	* gcc.c (ASM_DEBUG_SPEC): Likewise.
	(ASM_DEBUG_OPTION_SPEC): Likewise.
	* config.in: Regenerated.
	* configure: Likewise.
---
 gcc/config.in|   6 +--
 gcc/configure| 106 +--
 gcc/configure.ac |  59 --
 gcc/dwarf2out.c  |   2 +-
 gcc/gcc.c|   4 +-
 5 files changed, 164 insertions(+), 13 deletions(-)

diff --git a/gcc/config.in b/gcc/config.in
index 3657c46f349..b7c3107bfe3 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -719,10 +719,10 @@
 #endif
 
 
-/* Define if your assembler supports --gdwarf-4 even with compiler generated
-   .debug_line */
+/* Define if your assembler supports --gdwarf-4/--gdwarf-5 even with compiler

Re: [PATCH] Hashtable PR96088

2020-10-24 Thread François Dumont via Gcc-patches

Hi

    Just a rebase of this patch.

François

On 17/10/20 6:21 pm, François Dumont wrote:

I eventually would like to propose the following resolution.

For multi-key containers I kept the same resolution build the node 
first and compute has code from the node key.


For unique-key ones I change behavior when I can't find out hash 
functor argument type. I am rather using the iterator key type and 
just hope that the user's functors are prepared for it.


For now I am using functor argument_type which is deprecated. I just 
hope that the day we remove it we will have a compiler built-in to get 
any functor argument type given an input type.


    libstdc++: Limit allocation on iterator insertion in Hashtable [PR 
96088]


    Detect Hash functor argument type to find out if it is different 
to the
    container key_type and if a temporary instance needs to be 
generated to invoke
    the functor from the iterator value_type key part. If this 
temporary generation
    can throw a key_type instance is generated at Hashtable level and 
use to call

    the functors and, if needed, move it to the storage.

    libstdc++-v3/ChangeLog:

    PR libstdc++/96088
    * include/bits/hashtable_policy.h (_Select2nd): New.
    (_NodeBuilder<>): New.
    (_ReuseOrAllocNode<>::operator()): Use varriadic template 
args.

    (_AllocNode<>::operator()): Likewise.
    (_Hash_code_base<>::_M_hash_code): Add _KType template 
parameter.
    (_Hashtable_base<>::_M_equals): Add _KType template 
parameter.

    * include/bits/hashtable.h
    (_Hashtable<>::__node_builder_t): New.
    (_Hashtable<>::_M_find_before_node): Add _KType template 
parameter.

    (_Hashtable<>::_M_find_node): Likewise.
    (_Hashtable<>::_Hash_arg_t): New.
    (_Hashtable<>::_S_forward_key): New.
(_Hashtable<>::_M_insert_unique<>(_KType&&, _Arg&&, const 
_NodeGenerator&)):

 New.
    (_Hashtable<>::_M_insert): Use latter.
    * testsuite/23_containers/unordered_map/96088.cc: New test.
    * testsuite/23_containers/unordered_multimap/96088.cc: New 
test.
    * testsuite/23_containers/unordered_multiset/96088.cc: New 
test.

    * testsuite/23_containers/unordered_set/96088.cc: New test.
    * testsuite/util/replacement_memory_operators.h
    (counter::_M_increment): New.
    (counter::_M_decrement): New.
    (counter::reset()): New.

Tested under Linux x86_64.

Ok to commit ?

François

On 01/09/20 2:36 pm, François Dumont wrote:

Hi

    I started working on PR96088 problem in Hashtable implementation.

    In the case of multi-key containers the problem is easy to 
manage. Now that we have _Scoped_node we can easily allocate the node 
first and then extract the key from it to compute hash code. It is 
quite safe as computating a hash code is rarely going to throw 
especially if there is no allocation anymore to invoke the hasher.


    In the unique-key case it is more tricky. First I only consider 
the hasher invocation, the equal_to shall be consistent with it. My 
approach is to consider that if the operation needed transform the 
inserted element key part into the hasher argument can throw then I 
better generate a key_type instance myself and move it to the node if 
it is eventually to be inserted. Note that any allocation needed to 
call the hasher from the key_type is user fault.


    Of course the tricky part here is to find out what is the hasher 
argument_type. For the moment I support hasher with a nested 
argument_type typedef and function pointer. But, as pointed out by 
the tests which are failing for the moment I am missing the support 
for a classic functor. I am pretty sure that if I support it I will 
still be missing some use cases (like std::function). So I am looking 
for help on how to determine it. Or maybe the whole approach it wrong ?


For now I am still working on it, thanks,

François





diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index 6c6c5edde0b..234b40c13b7 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -274,6 +274,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	__detail::_ReuseOrAllocNode<__node_alloc_type>;
   using __alloc_node_gen_t =
 	__detail::_AllocNode<__node_alloc_type>;
+  using __node_builder_t =
+	__detail::_NodeBuilder<_ExtractKey>;
 
   // Simple RAII type for managing a node containing an element
   struct _Scoped_node
@@ -736,18 +738,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // Find and insert helper functions and types
   // Find the node before the one matching the criteria.
-  __node_base_ptr
-  _M_find_before_node(size_type, const key_type&, __hash_code) const;
-
-  __node_ptr
-  _M_find_node(size_type __bkt, const key_type& __key,
-		   __hash_code __c) const
-  {
-	

[PATCH] Handle undefined ranges in get_size_range.

2020-10-24 Thread Aldy Hernandez via Gcc-patches
An undefined range was leaking through to the end of this function,
which leads us to use an uninitialized wide_int.

Pushed.

gcc/ChangeLog:

PR tree-optimization/97538
* calls.c (get_size_range): Handle undefined ranges.

gcc/testsuite/ChangeLog:

* g++.dg/pr97538.C: New test.
---
 gcc/calls.c| 10 --
 gcc/testsuite/g++.dg/pr97538.C | 27 +++
 2 files changed, 31 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr97538.C

diff --git a/gcc/calls.c b/gcc/calls.c
index a12b84744c0..17b8e2f7a0d 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1269,16 +1269,14 @@ get_size_range (range_query *query, tree exp, gimple 
*stmt, tree range[2],
   value_range vr;
   if (query && query->range_of_expr (vr, exp, stmt))
{
+ if (vr.undefined_p ())
+   vr.set_varying (TREE_TYPE (exp));
  range_type = vr.kind ();
- if (!vr.undefined_p ())
-   {
- min = wi::to_wide (vr.min ());
- max = wi::to_wide (vr.max ());
-   }
+ min = wi::to_wide (vr.min ());
+ max = wi::to_wide (vr.max ());
}
   else
range_type = determine_value_range (exp, , );
-
 }
   else
 range_type = VR_VARYING;
diff --git a/gcc/testsuite/g++.dg/pr97538.C b/gcc/testsuite/g++.dg/pr97538.C
new file mode 100644
index 000..b29b1e40aa4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr97538.C
@@ -0,0 +1,27 @@
+// { dg-do compile }
+// { dg-options "-fno-guess-branch-probability -fno-tree-pta -O1" }
+
+void *b, *c;
+struct H {
+  virtual bool accept(const char *, unsigned long, int *, bool);
+};
+char accept_bt[1], accept_cd[1];
+int accept_cb;
+bool accept_cb_0;
+class t : H {
+  bool accept(const char *, unsigned long bd, int *bg, bool) {
+long bu = sizeof(int) + bd;
+char *bw = bu > sizeof(accept_bt) ? new char : accept_bt,
+ *cf = bd ? new char : accept_cd;
+__builtin___memcpy_chk(b, c, bd, 0);
+if (bw != accept_bt)
+  delete bw;
+bool ci = cj((int *)cf, bg), atran = bp && accept_cb_0;
+atran & &(_cb);
+return ci;
+  }
+  bool cj(int *, int *);
+  bool cm(int *);
+  bool bp;
+};
+void bj() { new t; }
-- 
2.26.2



Re: Move thunks out of cgraph_node

2020-10-24 Thread mliska

On 2020-10-23 21:45, Jan Hubicka wrote:

Hi,
this patch moves thunk_info out of cgraph_node into a symbol summary.
I also moved it to separate hearder file since cgraph.h became really 
too
fat.  I plan to contiue with similar breakup in order to cleanup 
interfaces
and reduce WPA memory footprint (symbol table now consumes more memory 
than

trees)

Bootstrapped/regtested x86_64-linux, plan to commit it shortly.


Hello.

This broke --enable-checking=release builds, fixed in 
g:a29ff9c53a77b6e208350d8c6db0f3e988f61d1f.


Martin


Re: [PATCH v7] genemit.c (main): split insn-emit.c for compiling parallelly

2020-10-24 Thread Jojo R
Hi,

Has this patch been merged ?

I track this some weeks and the patch has reviewed still on the way ...

Could someone help me ?

Thanks so much.

Jojo
在 2020年10月8日 +0800 AM10:01,Jojo R ,写道:
> Ping …...
>
> Jojo
> 在 2020年9月27日 +0800 AM10:34,Jojo R ,写道:
> > Hi,
> >
> > Has this patch been merged ?
> >
> > Jojo
> > 在 2020年9月15日 +0800 PM5:16,Jojo R ,写道:
> > > gcc/ChangeLog:
> > >
> > > * genemit.c (main): Print 'split line'.
> > > * Makefile.in (insn-emit.c): Define split count and file
> > >
> > > ---
> > > gcc/Makefile.in | 19 +
> > > gcc/genemit.c | 104 +---
> > > 2 files changed, 83 insertions(+), 40 deletions(-)
> > >
> > > diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> > > index 79e854aa938..a7fcc7d5949 100644
> > > --- a/gcc/Makefile.in
> > > +++ b/gcc/Makefile.in
> > > @@ -1258,6 +1258,21 @@ ANALYZER_OBJS = \
> > > # We put the *-match.o and insn-*.o files first so that a parallel make
> > > # will build them sooner, because they are large and otherwise tend to be
> > > # the last objects to finish building.
> > > +
> > > +# target overrides
> > > +-include $(tmake_file)
> > > +
> > > +INSN-GENERATED-SPLIT-NUM ?= 0
> > > +
> > > +insn-generated-split-num = $(shell i=1; j=`expr 
> > > $(INSN-GENERATED-SPLIT-NUM) + 1`; \
> > > + while test $$i -le $$j; do \
> > > + echo $$i; i=`expr $$i + 1`; \
> > > + done)
> > > +
> > > +insn-emit-split-c := $(foreach o, $(shell for i in 
> > > $(insn-generated-split-num); do echo $$i; done), insn-emit$(o).c)
> > > +insn-emit-split-obj = $(patsubst %.c,%.o, $(insn-emit-split-c))
> > > +$(insn-emit-split-c): insn-emit.c
> > > +
> > > OBJS = \
> > > gimple-match.o \
> > > generic-match.o \
> > > @@ -1265,6 +1280,7 @@ OBJS = \
> > > insn-automata.o \
> > > insn-dfatab.o \
> > > insn-emit.o \
> > > + $(insn-emit-split-obj) \
> > > insn-extract.o \
> > > insn-latencytab.o \
> > > insn-modes.o \
> > > @@ -2365,6 +2381,9 @@ $(simple_generated_c:insn-%.c=s-%): s-%: 
> > > build/gen%$(build_exeext)
> > > $(RUN_GEN) build/gen$*$(build_exeext) $(md_file) \
> > > $(filter insn-conditions.md,$^) > tmp-$*.c
> > > $(SHELL) $(srcdir)/../move-if-change tmp-$*.c insn-$*.c
> > > + $*v=$$(echo $$(csplit insn-$*.c /parallel\ compilation/ -k -s 
> > > {$(INSN-GENERATED-SPLIT-NUM)} -f insn-$* -b "%d.c" 2>&1));\
> > > + [ ! "$$$*v" ] || grep "match not found" <<< $$$*v
> > > + [ -s insn-$*0.c ] || (for i in $(insn-generated-split-num); do touch 
> > > insn-$*$$i.c; done && echo "" > insn-$*.c)
> > > $(STAMP) s-$*
> > >
> > > # gencheck doesn't read the machine description, and the file produced
> > > diff --git a/gcc/genemit.c b/gcc/genemit.c
> > > index 84d07d388ee..54a0d909d9d 100644
> > > --- a/gcc/genemit.c
> > > +++ b/gcc/genemit.c
> > > @@ -847,24 +847,13 @@ handle_overloaded_gen (overloaded_name *oname)
> > > }
> > > }
> > >
> > > -int
> > > -main (int argc, const char **argv)
> > > -{
> > > - progname = "genemit";
> > > -
> > > - if (!init_rtx_reader_args (argc, argv))
> > > - return (FATAL_EXIT_CODE);
> > > -
> > > -#define DEF_INTERNAL_OPTAB_FN(NAME, FLAGS, OPTAB, TYPE) \
> > > - nofail_optabs[OPTAB##_optab] = true;
> > > -#include "internal-fn.def"
> > > -
> > > - /* Assign sequential codes to all entries in the machine description
> > > - in parallel with the tables in insn-output.c. */
> > > -
> > > - printf ("/* Generated automatically by the program `genemit'\n\
> > > -from the machine description file `md'. */\n\n");
> > > +/* Print include header. */
> > >
> > > +static void
> > > +printf_include (void)
> > > +{
> > > + printf ("/* Generated automatically by the program `genemit'\n"
> > > + "from the machine description file `md'. */\n\n");
> > > printf ("#define IN_TARGET_CODE 1\n");
> > > printf ("#include \"config.h\"\n");
> > > printf ("#include \"system.h\"\n");
> > > @@ -900,35 +889,70 @@ from the machine description file `md'. */\n\n");
> > > printf ("#include \"tm-constrs.h\"\n");
> > > printf ("#include \"ggc.h\"\n");
> > > printf ("#include \"target.h\"\n\n");
> > > +}
> > >
> > > - /* Read the machine description. */
> > > +/* Generate the `gen_...' function from GET_CODE(). */
> > >
> > > - md_rtx_info info;
> > > - while (read_md_rtx ())
> > > - switch (GET_CODE (info.def))
> > > - {
> > > - case DEFINE_INSN:
> > > - gen_insn ();
> > > - break;
> > > +static void
> > > +gen_md_rtx (md_rtx_info *info)
> > > +{
> > > + switch (GET_CODE (info->def))
> > > + {
> > > + case DEFINE_INSN:
> > > + gen_insn (info);
> > > + break;
> > >
> > > - case DEFINE_EXPAND:
> > > - printf ("/* %s:%d */\n", info.loc.filename, info.loc.lineno);
> > > - gen_expand ();
> > > - break;
> > > + case DEFINE_EXPAND:
> > > + printf ("/* %s:%d */\n", info->loc.filename, info->loc.lineno);
> > > + gen_expand (info);
> > > + break;
> > >
> > > - case DEFINE_SPLIT:
> > > - printf ("/* %s:%d */\n", info.loc.filename, info.loc.lineno);
> > > - gen_split ();
> > > - break;
> > > + case DEFINE_SPLIT:
> > >