[PATCH] PR target/99314: Fix integer signedness issue for cpymem pattern expansion.

[Kito Cheng]

From: Sinan Lin 

Third operand of cpymem pattern is unsigned HOST_WIDE_INT, however we
are interpret that as signed HOST_WIDE_INT, that not a problem in
most case, but when the value is large than signed HOST_WIDE_INT, it
might screw up since we have using that value to calculate the buffer
size.

2021-03-05  Sinan Lin  
Kito Cheng  

gcc/ChangeLog:

* config/riscv/riscv.c (riscv_block_move_straight): Change type
to unsigned HOST_WIDE_INT for parameter and local variable with
HOST_WIDE_INT type.
(riscv_adjust_block_mem): Ditto.
(riscv_block_move_loop): Ditto.
(riscv_expand_block_move): Ditto.
---
 gcc/config/riscv/riscv.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index fffd0814eee..96fc0c0a4a0 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -3146,9 +3146,9 @@ riscv_legitimize_call_address (rtx addr)
Assume that the areas do not overlap.  */
 
 static void
-riscv_block_move_straight (rtx dest, rtx src, HOST_WIDE_INT length)
+riscv_block_move_straight (rtx dest, rtx src, unsigned HOST_WIDE_INT length)
 {
-  HOST_WIDE_INT offset, delta;
+  unsigned HOST_WIDE_INT offset, delta;
   unsigned HOST_WIDE_INT bits;
   int i;
   enum machine_mode mode;
@@ -3194,8 +3194,8 @@ riscv_block_move_straight (rtx dest, rtx src, 
HOST_WIDE_INT length)
register.  Store them in *LOOP_REG and *LOOP_MEM respectively.  */
 
 static void
-riscv_adjust_block_mem (rtx mem, HOST_WIDE_INT length,
-  rtx *loop_reg, rtx *loop_mem)
+riscv_adjust_block_mem (rtx mem, unsigned HOST_WIDE_INT length,
+   rtx *loop_reg, rtx *loop_mem)
 {
   *loop_reg = copy_addr_to_reg (XEXP (mem, 0));
 
@@ -3210,11 +3210,11 @@ riscv_adjust_block_mem (rtx mem, HOST_WIDE_INT length,
the memory regions do not overlap.  */
 
 static void
-riscv_block_move_loop (rtx dest, rtx src, HOST_WIDE_INT length,
- HOST_WIDE_INT bytes_per_iter)
+riscv_block_move_loop (rtx dest, rtx src, unsigned HOST_WIDE_INT length,
+  unsigned HOST_WIDE_INT bytes_per_iter)
 {
   rtx label, src_reg, dest_reg, final_src, test;
-  HOST_WIDE_INT leftover;
+  unsigned HOST_WIDE_INT leftover;
 
   leftover = length % bytes_per_iter;
   length -= leftover;
@@ -3259,18 +3259,19 @@ riscv_block_move_loop (rtx dest, rtx src, HOST_WIDE_INT 
length,
 bool
 riscv_expand_block_move (rtx dest, rtx src, rtx length)
 {
+  unsigned HOST_WIDE_INT hwi_length = UINTVAL (length);
   if (CONST_INT_P (length))
 {
-  HOST_WIDE_INT factor, align;
+  unsigned HOST_WIDE_INT factor, align;
 
   align = MIN (MIN (MEM_ALIGN (src), MEM_ALIGN (dest)), BITS_PER_WORD);
   factor = BITS_PER_WORD / align;
 
   if (optimize_function_for_size_p (cfun)
- && INTVAL (length) * factor * UNITS_PER_WORD > MOVE_RATIO (false))
+ && hwi_length * factor * UNITS_PER_WORD > MOVE_RATIO (false))
return false;
 
-  if (INTVAL (length) <= RISCV_MAX_MOVE_BYTES_STRAIGHT / factor)
+  if (hwi_length <= (RISCV_MAX_MOVE_BYTES_STRAIGHT / factor))
{
  riscv_block_move_straight (dest, src, INTVAL (length));
  return true;
@@ -3280,7 +3281,8 @@ riscv_expand_block_move (rtx dest, rtx src, rtx length)
  unsigned min_iter_words
= RISCV_MAX_MOVE_BYTES_PER_LOOP_ITER / UNITS_PER_WORD;
  unsigned iter_words = min_iter_words;
- HOST_WIDE_INT bytes = INTVAL (length), words = bytes / UNITS_PER_WORD;
+ unsigned HOST_WIDE_INT bytes = hwi_length;
+ unsigned HOST_WIDE_INT words = bytes / UNITS_PER_WORD;
 
  /* Lengthen the loop body if it shortens the tail.  */
  for (unsigned i = min_iter_words; i < min_iter_words * 2 - 1; i++)
-- 
2.30.0

[PATCH] aarch64 : Modify __ARM_ARCH as per latest ACLE

[naveenh--- via Gcc-patches]

From: Naveen H S 

Please find attached the patch that modifies "__ARM_ARCH" as per latest ACLE.
Built and tested the patch on aarch64-marvell-linux-gnu.
Please review the patch and let me know if it's okay.

2021-04-03  Naveen H S  

PR tree-optimization/99312

* config/aarch64/aarch64-arches.def (armv8.1-a): Modify ARCH_REV as per 
latest ACLE.
(armv8.2-a): Likewise.
(armv8.3-a): Likewise.
(armv8.4-a): Likewise.
(armv8.5-a): Likewise.
(armv8.6-a): Likewise.
---
 gcc/config/aarch64/aarch64-arches.def | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-arches.def 
b/gcc/config/aarch64/aarch64-arches.def
index b7497277bb8..acaf5566927 100644
--- a/gcc/config/aarch64/aarch64-arches.def
+++ b/gcc/config/aarch64/aarch64-arches.def
@@ -25,18 +25,19 @@
constant.  The CORE is the identifier for a core representative of
this architecture.  ARCH_IDENT is the architecture identifier.  It must be
unique and be syntactically valid to appear as part of an enum identifier.
-   ARCH_REV is an integer specifying the architecture major revision.
+   ARCH_REV is an integer (X * 100 + Y  E.g. for Armv8.1 it's 801. Except for
+   Armv8-a which is still 8) specifying the architecture major revision.
FLAGS are the flags implied by the architecture.
Due to the assumptions about the positions of these fields in config.gcc,
the NAME should be kept as the first argument and FLAGS as the last.  */
 
 AARCH64_ARCH("armv8-a",  generic,   8A,8,  
AARCH64_FL_FOR_ARCH8)
-AARCH64_ARCH("armv8.1-a", generic,  8_1A,  8,  
AARCH64_FL_FOR_ARCH8_1)
-AARCH64_ARCH("armv8.2-a", generic,  8_2A,  8,  
AARCH64_FL_FOR_ARCH8_2)
-AARCH64_ARCH("armv8.3-a", generic,  8_3A,  8,  
AARCH64_FL_FOR_ARCH8_3)
-AARCH64_ARCH("armv8.4-a", generic,  8_4A,  8,  
AARCH64_FL_FOR_ARCH8_4)
-AARCH64_ARCH("armv8.5-a", generic,  8_5A,  8,  
AARCH64_FL_FOR_ARCH8_5)
-AARCH64_ARCH("armv8.6-a", generic,  8_6A,  8,  
AARCH64_FL_FOR_ARCH8_6)
+AARCH64_ARCH("armv8.1-a", generic,  8_1A,  801,  
AARCH64_FL_FOR_ARCH8_1)
+AARCH64_ARCH("armv8.2-a", generic,  8_2A,  802,  
AARCH64_FL_FOR_ARCH8_2)
+AARCH64_ARCH("armv8.3-a", generic,  8_3A,  803,  
AARCH64_FL_FOR_ARCH8_3)
+AARCH64_ARCH("armv8.4-a", generic,  8_4A,  804,  
AARCH64_FL_FOR_ARCH8_4)
+AARCH64_ARCH("armv8.5-a", generic,  8_5A,  805,  
AARCH64_FL_FOR_ARCH8_5)
+AARCH64_ARCH("armv8.6-a", generic,  8_6A,  806,  
AARCH64_FL_FOR_ARCH8_6)
 AARCH64_ARCH("armv8-r",   generic,  8R  ,  8,  
AARCH64_FL_FOR_ARCH8_R)
 
 #undef AARCH64_ARCH
-- 
2.11.0

Re: [PATCH] c++: adc_unify deduction with constrained auto [PR99365]

[Patrick Palka via Gcc-patches]

On Thu, 4 Mar 2021, Patrick Palka wrote:

> On Thu, 4 Mar 2021, Patrick Palka wrote:
> 
> > On Thu, 4 Mar 2021, Jason Merrill wrote:
> > 
> > > On 3/4/21 11:32 AM, Patrick Palka wrote:
> > > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > > > 
> > > > > My recent r11-7454 changed the way do_auto_deduction handles 
> > > > > constrained
> > > > > placeholders during template argument deduction (context == adc_unify)
> > > > > when processing_template_decl != 0.
> > > > > 
> > > > > Before the patch, when processing_template_decl != 0 we would just
> > > > > ignore the constraints on the placeholder in this situation, and 
> > > > > proceed
> > > > > with deduction:
> > > > > 
> > > > >/* Check any placeholder constraints against the deduced type. */
> > > > >if (flag_concepts && !processing_template_decl)
> > > > >  if (tree check = NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS
> > > > > (auto_node)))
> > > > >{
> > > > >  ...
> > > > > 
> > > > > After the patch, we now punt and return the original placeholder type:
> > > > > 
> > > > >/* Check any placeholder constraints against the deduced type. */
> > > > >if (flag_concepts)
> > > > >  if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
> > > > >{
> > > > >  if (processing_template_decl)
> > > > >/* In general we can't check satisfaction until we know all
> > > > >   template arguments.  */
> > > > >return type;
> > > > >  ...
> > > > > 
> > > > > While this change fixed instances where we'd prematurely resolve a
> > > > > constrained placeholder return or variable type with non-dependent
> > > > > initializer at template parse time (such as PR96444), it broke the
> > > > > adc_unify callers that rely on this previous behavior.
> > > > > 
> > > > > So this patch restores the previous behavior during adc_unify 
> > > > > deduction
> > > > > while retaining the new behavior only during adc_variable_type or
> > > > > adc_return_type deduction.
> > > 
> > > Sure, it makes sense for adc_unify to behave differently, since in 
> > > deduction
> > > context constraints are checked after all template args have been deduced.
> > 
> > I see.
> > 
> > > 
> > > > > We additionally now need to pass outer template arguments to
> > > > > do_auto_deduction during unify, for sake of constraint checking.
> > > > > But we don't want do_auto_deduction to substitute these outer 
> > > > > arguments
> > > > > into type if it's already been done, hence the added 
> > > > > TEMPLATE_TYPE_LEVEL
> > > > > check.
> > > > > 
> > > > > This fixes partial specializations of non-nested templates with
> > > > > constrained 'auto' template parameters, but nested templates are still
> > > > > broken, ultimately because most_specialized_partial_spec passes only 
> > > > > the
> > > > > innermost template arguments to get_partial_spec_bindings, and so
> > > > > outer_targs during do_auto_deduction (called from unify) contains only
> > > > > the innermost template arguments which makes satisfaction unhappy.
> > > > > Fixing this might be too invasive at this stage, perhaps..  (Seems we
> > > > > need to make most_specialized_partial_spec pass all template arguments
> > > > > to get_partial_spec_bindings.)
> > > 
> > > How did this work before?
> > 
> > Before, it would work, but only if the constraint didn't also depend on
> > any outer template arguments.  do_auto_deduction would just "surgically"
> > replace the auto in the concept-id with the type we deduced and leave
> > the other template arguments of the concept-id alone.  So if the
> > constraint was non-dependent, satisfaction would work regardless of the
> > template nesting level.
> > 
> > Now that we try to do perform satisfaction properly, we're sensitive to
> > the template nesting level even if the constraint is otherwise
> > non-dependent, because the template nesting level determines the level
> > of the auto that appears inside the constraint.  So we rely on
> > outer_targs to contain all levels of outer template arguments, because
> > we tack on another level to the end of outer_targs which needs to
> > map to the level of the auto for satisfaction.
> > 
> > (As a hacky workaround, when outer_targs is incomplete, can probably
> > just augment it with empty levels until it's 
> > TEMPLATE_TYPE_LEVEL(auto_node)-1
> > levels deep, which would fix the nested template case as long as the
> > constraint was depended only on the innermost level of template
> > arguments.)
> > 
> > > 
> > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK 
> > > > > for
> > > > > trunk?  Also tested on range-v3 and cmcstl2.
> > > > 
> > > > Here's the same patch generated with -w which hides the noisy 
> > > > indentation
> > > > changes:
> > > > 
> > > > -- >8 --
> > > > 
> > > > PR c++/99365
> > > > * pt.c (do_auto_deduction): When processing_template_decl != 0
> > > > and context is adc_unify and we 

[PATCH] c++: -Wconversion vs value-dependent expressions [PR99331]

[Marek Polacek via Gcc-patches]

This PR complains that we issue a -Wconversion warning in

  template  struct X {};
  template  X foo();

saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not technically wrong, I suspect -Wconversion warnings aren't
all that useful for value-dependent expressions.  So this patch disables
them, though I'm open to other ideas.  This is a regression that started
with r241425:

@@ -7278,7 +7306,7 @@ convert_template_argument (tree parm,
  val = error_mark_node;
}
}
-  else if (!dependent_template_arg_p (orig_arg)
+  else if (!type_dependent_expression_p (orig_arg)
   && !uses_template_parms (t))
/* We used to call digest_init here.  However, digest_init
   will report errors, which we don't want when complain

Here orig_arg is SIZEOF_EXPR, dependent_template_arg_p (orig_arg) was
true, but type_dependent_expression_p (orig_arg) is false so we warn in
convert_nontype_argument.

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

gcc/cp/ChangeLog:

PR c++/99331
* cvt.c (cp_convert_and_check): Don't emit -Wconversion warnings
when the expression is value-dependent.

gcc/testsuite/ChangeLog:

PR c++/99331
* g++.dg/warn/Wconversion5.C: New test.
---
 gcc/cp/cvt.c |  7 ++-
 gcc/testsuite/g++.dg/warn/Wconversion5.C | 14 ++
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wconversion5.C

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index 2ea32101f07..55024b2b966 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -663,7 +663,12 @@ cp_convert_and_check (tree type, tree expr, tsubst_flags_t 
complain)
   result = cp_convert (type, expr, complain);
 
   if ((complain & tf_warning)
-  && c_inhibit_evaluation_warnings == 0)
+  && c_inhibit_evaluation_warnings == 0
+  /* Issuing conversion warnings for value-dependent expressions is
+likely too noisy.  */
+  && !(processing_template_decl
+  && potential_constant_expression (expr)
+  && value_dependent_expression_p (expr)))
 {
   tree folded = cp_fully_fold (expr);
   tree folded_result;
diff --git a/gcc/testsuite/g++.dg/warn/Wconversion5.C 
b/gcc/testsuite/g++.dg/warn/Wconversion5.C
new file mode 100644
index 000..47106a7c2fa
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wconversion5.C
@@ -0,0 +1,14 @@
+// PR c++/99331
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wconversion" }
+// Don't issue -Wconversion warnings for value-dependent expressions.
+
+template  struct X {};
+template  X foo();
+template  X foo2();
+
+template 
+struct S {
+  using t = X;
+  using u = X;
+};

base-commit: 0d737ed2171165ba39ab5647f8a94c588fc9a898
-- 
2.29.2

Committed: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c: xfail for cris

[Hans-Peter Nilsson via Gcc-patches]

Tested cris-elf and x86_64-linux to eliminate the edit being
fatfingered.

The test is still failing and is a regression on master for
cris-elf: the remedy for (all) other targets wasn't
sufficient.  I'm not myself going to put any effort into it
(debug-information being different enough for a test to
fail, is not a priority) and apparently not anyone else in
the last 5 years, so I'm just going to xfail it.

gcc/testsuite:
PR debug/8
* gcc.dg/debug/dwarf2/stacked-qualified-types-3.c: xfail for cris-*-*
---
 gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-3.c 
b/gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-3.c
index efa3fa0b1f21..98ee1169e428 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-3.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-3.c
@@ -31,4 +31,5 @@ char * _Atomic restrict h;
 char * _Atomic i;
 char * restrict j;
 
-/* { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) 
DW_TAG_(?:const|volatile|atomic|restrict)_type" 8 } } */
+/* The xfail is due to PR8.  */
+/* { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) 
DW_TAG_(?:const|volatile|atomic|restrict)_type" 8 { xfail cris-*-* } } } */
-- 
2.11.0

Re: [Patch] Fortran: Follow fixes to -freal-{4,8}-real* handling [PR99355,PR57871] (was: Re: [Patch] Fortran: Fix -freal-{4,8}-real* handling [PR99355])

[Jerry DeLisle]

OK, thanks Dominique for spotting this.

On 3/4/21 9:02 AM, Tobias Burnus wrote:

Dominique found an issue ("regression") with this patch – and a testcase
omission.

The previous patch mishandled the noncommitted testcase of PR57871 – or
in other words: It did not promote 1.0_4 or 1.0_8 – as only the
default-real-kind values 1.0 and 1.0d0 were promoted (via code in in
trans-types.c).

I have additionally updated the documentation to more accurately state
what the option does and how it interacts with other options.

OK for mainline?

Tobias

PS: Side remark: My recommendation is to avoid
-freal-{4,8}-real-{4,8,10,16} ...

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, 
Frank Thürauf

[PATCH] c++: Pointer-to-member fn conversion with noexcept [PR99374]

[Marek Polacek via Gcc-patches]

The issue in this PR is that we wrongly reject converting pointers to
member function of incomplete types, one of which has noexcept.  Recall
that pointers (including pointers to member functions) to non-throwing
functions can be implicitly converted to potentially-throwing functions
(but not vice versa).

We reject the conversion when called from can_convert_arg_bad because
standard_conversion can't create such a conversion.  It comes down to
the DERIVED_FROM_P check in the TYPE_PTRMEMFUNC_P block.  It considers
every class derived from itself, but not when the class is incomplete.
But surely we want to reach fnptr_conv_p when tbase is fbase (one of
them could be an alias to the other so use same_type_p instead of ==).

Another approach would be to not perform DERIVED_FROM_P at all when
either tbase or fbase are incomplete (so perhaps something like at the
end of ptr_reasonably_similar).

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

gcc/cp/ChangeLog:

PR c++/99374
* call.c (standard_conversion): When converting pointers to
member, don't return NULL when the bases are equivalent but
incomplete.

gcc/testsuite/ChangeLog:

PR c++/99374
* g++.dg/cpp1z/noexcept-type23.C: New test.
---
 gcc/cp/call.c|  4 +++-
 gcc/testsuite/g++.dg/cpp1z/noexcept-type23.C | 14 ++
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/noexcept-type23.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 123f06b1f2b..605cbe15f4e 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -1449,7 +1449,9 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
   tree fbase = class_of_this_parm (fromfn);
   tree tbase = class_of_this_parm (tofn);
 
-  if (!DERIVED_FROM_P (fbase, tbase))
+  /* If FBASE and TBASE are equivalent but incomplete, DERIVED_FROM_P
+yields false.  But a pointer to member of incomplete class is OK.  */
+  if (!DERIVED_FROM_P (fbase, tbase) && !same_type_p (fbase, tbase))
return NULL;
 
   tree fstat = static_fn_type (fromfn);
diff --git a/gcc/testsuite/g++.dg/cpp1z/noexcept-type23.C 
b/gcc/testsuite/g++.dg/cpp1z/noexcept-type23.C
new file mode 100644
index 000..612dd6ceb5e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/noexcept-type23.C
@@ -0,0 +1,14 @@
+// PR c++/99374
+// { dg-do compile { target c++17 } }
+
+struct S;
+struct R;
+using F1 = int (S::*)();
+using F2 = int (S::*)() noexcept;
+using F3 = int (R::*)() noexcept;
+using T = S;
+using F4 = int (T::*)() noexcept;
+F1 f21 = F2();
+F1 f41 = F4();
+F2 f12 = F1(); // { dg-error "cannot convert" }
+F1 f31 = F3(); // { dg-error "cannot convert" }

base-commit: 0d737ed2171165ba39ab5647f8a94c588fc9a898
-- 
2.29.2

Re: [PATCH] c++: adc_unify deduction with constrained auto [PR99365]

[Patrick Palka via Gcc-patches]

On Thu, 4 Mar 2021, Patrick Palka wrote:

> On Thu, 4 Mar 2021, Jason Merrill wrote:
> 
> > On 3/4/21 11:32 AM, Patrick Palka wrote:
> > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > > 
> > > > My recent r11-7454 changed the way do_auto_deduction handles constrained
> > > > placeholders during template argument deduction (context == adc_unify)
> > > > when processing_template_decl != 0.
> > > > 
> > > > Before the patch, when processing_template_decl != 0 we would just
> > > > ignore the constraints on the placeholder in this situation, and proceed
> > > > with deduction:
> > > > 
> > > >/* Check any placeholder constraints against the deduced type. */
> > > >if (flag_concepts && !processing_template_decl)
> > > >  if (tree check = NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS
> > > > (auto_node)))
> > > >{
> > > >  ...
> > > > 
> > > > After the patch, we now punt and return the original placeholder type:
> > > > 
> > > >/* Check any placeholder constraints against the deduced type. */
> > > >if (flag_concepts)
> > > >  if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
> > > >{
> > > >  if (processing_template_decl)
> > > >/* In general we can't check satisfaction until we know all
> > > >   template arguments.  */
> > > >return type;
> > > >  ...
> > > > 
> > > > While this change fixed instances where we'd prematurely resolve a
> > > > constrained placeholder return or variable type with non-dependent
> > > > initializer at template parse time (such as PR96444), it broke the
> > > > adc_unify callers that rely on this previous behavior.
> > > > 
> > > > So this patch restores the previous behavior during adc_unify deduction
> > > > while retaining the new behavior only during adc_variable_type or
> > > > adc_return_type deduction.
> > 
> > Sure, it makes sense for adc_unify to behave differently, since in deduction
> > context constraints are checked after all template args have been deduced.
> 
> I see.
> 
> > 
> > > > We additionally now need to pass outer template arguments to
> > > > do_auto_deduction during unify, for sake of constraint checking.
> > > > But we don't want do_auto_deduction to substitute these outer arguments
> > > > into type if it's already been done, hence the added TEMPLATE_TYPE_LEVEL
> > > > check.
> > > > 
> > > > This fixes partial specializations of non-nested templates with
> > > > constrained 'auto' template parameters, but nested templates are still
> > > > broken, ultimately because most_specialized_partial_spec passes only the
> > > > innermost template arguments to get_partial_spec_bindings, and so
> > > > outer_targs during do_auto_deduction (called from unify) contains only
> > > > the innermost template arguments which makes satisfaction unhappy.
> > > > Fixing this might be too invasive at this stage, perhaps..  (Seems we
> > > > need to make most_specialized_partial_spec pass all template arguments
> > > > to get_partial_spec_bindings.)
> > 
> > How did this work before?
> 
> Before, it would work, but only if the constraint didn't also depend on
> any outer template arguments.  do_auto_deduction would just "surgically"
> replace the auto in the concept-id with the type we deduced and leave
> the other template arguments of the concept-id alone.  So if the
> constraint was non-dependent, satisfaction would work regardless of the
> template nesting level.
> 
> Now that we try to do perform satisfaction properly, we're sensitive to
> the template nesting level even if the constraint is otherwise
> non-dependent, because the template nesting level determines the level
> of the auto that appears inside the constraint.  So we rely on
> outer_targs to contain all levels of outer template arguments, because
> we tack on another level to the end of outer_targs which needs to
> map to the level of the auto for satisfaction.
> 
> (As a hacky workaround, when outer_targs is incomplete, can probably
> just augment it with empty levels until it's TEMPLATE_TYPE_LEVEL(auto_node)-1
> levels deep, which would fix the nested template case as long as the
> constraint was depended only on the innermost level of template
> arguments.)
> 
> > 
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > > trunk?  Also tested on range-v3 and cmcstl2.
> > > 
> > > Here's the same patch generated with -w which hides the noisy indentation
> > > changes:
> > > 
> > > -- >8 --
> > > 
> > >   PR c++/99365
> > >   * pt.c (do_auto_deduction): When processing_template_decl != 0
> > >   and context is adc_unify and we have constraints, pretend the
> > >   constraints are satisfied instead of punting.  Add some
> > >   clarifying sanity checks.  Don't substitute outer_targs into
> > >   type if not needed.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > >   PR c++/99365
> > >   * g++.dg/cpp2a/concepts-partial-spec9.C: New test.
> > > ---
> > >   gcc/cp/pt.c 

Re: [PATCH] c++: adc_unify deduction with constrained auto [PR99365]

[Patrick Palka via Gcc-patches]

On Thu, 4 Mar 2021, Jason Merrill wrote:

> On 3/4/21 11:32 AM, Patrick Palka wrote:
> > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > 
> > > My recent r11-7454 changed the way do_auto_deduction handles constrained
> > > placeholders during template argument deduction (context == adc_unify)
> > > when processing_template_decl != 0.
> > > 
> > > Before the patch, when processing_template_decl != 0 we would just
> > > ignore the constraints on the placeholder in this situation, and proceed
> > > with deduction:
> > > 
> > >/* Check any placeholder constraints against the deduced type. */
> > >if (flag_concepts && !processing_template_decl)
> > >  if (tree check = NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS
> > > (auto_node)))
> > >{
> > >  ...
> > > 
> > > After the patch, we now punt and return the original placeholder type:
> > > 
> > >/* Check any placeholder constraints against the deduced type. */
> > >if (flag_concepts)
> > >  if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
> > >{
> > >  if (processing_template_decl)
> > >/* In general we can't check satisfaction until we know all
> > >   template arguments.  */
> > >return type;
> > >  ...
> > > 
> > > While this change fixed instances where we'd prematurely resolve a
> > > constrained placeholder return or variable type with non-dependent
> > > initializer at template parse time (such as PR96444), it broke the
> > > adc_unify callers that rely on this previous behavior.
> > > 
> > > So this patch restores the previous behavior during adc_unify deduction
> > > while retaining the new behavior only during adc_variable_type or
> > > adc_return_type deduction.
> 
> Sure, it makes sense for adc_unify to behave differently, since in deduction
> context constraints are checked after all template args have been deduced.

I see.

> 
> > > We additionally now need to pass outer template arguments to
> > > do_auto_deduction during unify, for sake of constraint checking.
> > > But we don't want do_auto_deduction to substitute these outer arguments
> > > into type if it's already been done, hence the added TEMPLATE_TYPE_LEVEL
> > > check.
> > > 
> > > This fixes partial specializations of non-nested templates with
> > > constrained 'auto' template parameters, but nested templates are still
> > > broken, ultimately because most_specialized_partial_spec passes only the
> > > innermost template arguments to get_partial_spec_bindings, and so
> > > outer_targs during do_auto_deduction (called from unify) contains only
> > > the innermost template arguments which makes satisfaction unhappy.
> > > Fixing this might be too invasive at this stage, perhaps..  (Seems we
> > > need to make most_specialized_partial_spec pass all template arguments
> > > to get_partial_spec_bindings.)
> 
> How did this work before?

Before, it would work, but only if the constraint didn't also depend on
any outer template arguments.  do_auto_deduction would just "surgically"
replace the auto in the concept-id with the type we deduced and leave
the other template arguments of the concept-id alone.  So if the
constraint was non-dependent, satisfaction would work regardless of the
template nesting level.

Now that we try to do perform satisfaction properly, we're sensitive to
the template nesting level even if the constraint is otherwise
non-dependent, because the template nesting level determines the level
of the auto that appears inside the constraint.  So we rely on
outer_targs to contain all levels of outer template arguments, because
we tack on another level to the end of outer_targs which needs to
map to the level of the auto for satisfaction.

(As a hacky workaround, when outer_targs is incomplete, can probably
just augment it with empty levels until it's TEMPLATE_TYPE_LEVEL(auto_node)-1
levels deep, which would fix the nested template case as long as the
constraint was depended only on the innermost level of template
arguments.)

> 
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > trunk?  Also tested on range-v3 and cmcstl2.
> > 
> > Here's the same patch generated with -w which hides the noisy indentation
> > changes:
> > 
> > -- >8 --
> > 
> > PR c++/99365
> > * pt.c (do_auto_deduction): When processing_template_decl != 0
> > and context is adc_unify and we have constraints, pretend the
> > constraints are satisfied instead of punting.  Add some
> > clarifying sanity checks.  Don't substitute outer_targs into
> > type if not needed.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/99365
> > * g++.dg/cpp2a/concepts-partial-spec9.C: New test.
> > ---
> >   gcc/cp/pt.c   | 24 ++-
> >   .../g++.dg/cpp2a/concepts-partial-spec9.C | 24 +++
> >   2 files changed, 42 insertions(+), 6 deletions(-)
> >   create mode 100644 

[PATCH V3] Do not build Decimal/Float128 conversions if --disable-decimal-float.

[Michael Meissner via Gcc-patches]

[PATCH 2/2 V3] Do not build Decimal/Float128 conversions if 
--disable-decimal-float.

This patch disables building the Decimal/_Float128 conversion functions if the
user configured the compiler with the --disable-decimal-float option.

This is a much simpler patch to disable building the Decimal/Float128
conversion functions if decimal floating point was installed.  It follows the
method libgcc uses in Makefile to suppress building the normal Decimal support
functions if decimal floating point is disabled.

I have built bootstrap compilers for power9 little endian systems with the
three different long double formats (IBM 128-bit, IEEE 128-bit, and 64-bit) and
there were no regressions from previous runs.  I have also build bootstrap
compilers on a big endian power8 and there was no regression there either.

I built two cross compilers from X86_64 to PowerPC, one with normal switches
and the other with decimal floating point disabled.  I verified that the
Decimal/Float128 conversions are not enable.

Finally I built a compiler on a little endian system with an older GLIBC.  I
verified that the linker reports that __strtoieee128 and __sprintfieee128 are
not present, and aborts the link.

Can I check this patch into the master branch?

libgcc/
2021-03-04  Michael Meissner  

* config/rs6000/t-float128 (fp128_dec_funcs): Do not set if
--disable-decimal-float.
(fp128_dec_objs): Do not set if --disable-decimal-float.
---
 libgcc/config/rs6000/t-float128 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
index 8b089d4433c..83fbbb68788 100644
--- a/libgcc/config/rs6000/t-float128
+++ b/libgcc/config/rs6000/t-float128
@@ -23,8 +23,10 @@ fp128_softfp_shared_obj  = $(addsuffix 
-sw_s$(objext),$(fp128_softfp_funcs))
 fp128_softfp_obj   = $(fp128_softfp_static_obj) $(fp128_softfp_shared_obj)
 
 # Decimal <-> _Float128 conversions
+ifeq ($(decimal_float),yes)
 fp128_dec_funcs= _kf_to_sd _kf_to_dd _kf_to_td \
  _sd_to_kf _dd_to_kf _td_to_kf
+endif
 
 # Decimal <-> __ibm128 conversions
 ibm128_dec_funcs   = _tf_to_sd _tf_to_dd _tf_to_td \
@@ -81,8 +83,10 @@ $(fp128_obj)  : 
$(srcdir)/config/rs6000/quad-float128.h
 # 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
 # IEEE long double.
+ifeq ($(decimal_float),yes)
 fp128_dec_objs = $(addsuffix $(objext),$(fp128_dec_funcs)) \
  $(addsuffix _s$(objext),$(fp128_dec_funcs))
+endif
 
 ibm128_dec_objs= $(addsuffix $(objext),$(ibm128_dec_funcs)) \
  $(addsuffix _s$(objext),$(ibm128_dec_funcs))
@@ -90,7 +94,9 @@ ibm128_dec_objs   = $(addsuffix 
$(objext),$(ibm128_dec_funcs)) \
 FP128_CFLAGS_DECIMAL   = -mno-gnu-attribute -Wno-psabi -mabi=ieeelongdouble
 IBM128_CFLAGS_DECIMAL  = -mno-gnu-attribute -Wno-psabi -mabi=ibmlongdouble
 
+ifeq ($(decimal_float),yes)
 $(fp128_dec_objs)  : INTERNAL_CFLAGS += $(FP128_CFLAGS_DECIMAL)
+endif
 $(ibm128_dec_objs) : INTERNAL_CFLAGS += $(IBM128_CFLAGS_DECIMAL)
 
 $(fp128_softfp_src) : $(srcdir)/soft-fp/$(subst -sw,,$(subst kf,tf,$@)) 
$(fp128_dep)
-- 
2.22.0


-- 
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] c++: adc_unify deduction with constrained auto [PR99365]

[Jason Merrill via Gcc-patches]

On 3/4/21 11:32 AM, Patrick Palka wrote:

On Thu, 4 Mar 2021, Patrick Palka wrote:


My recent r11-7454 changed the way do_auto_deduction handles constrained
placeholders during template argument deduction (context == adc_unify)
when processing_template_decl != 0.

Before the patch, when processing_template_decl != 0 we would just
ignore the constraints on the placeholder in this situation, and proceed
with deduction:

   /* Check any placeholder constraints against the deduced type. */
   if (flag_concepts && !processing_template_decl)
 if (tree check = NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
   {
 ...

After the patch, we now punt and return the original placeholder type:

   /* Check any placeholder constraints against the deduced type. */
   if (flag_concepts)
 if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
   {
 if (processing_template_decl)
   /* In general we can't check satisfaction until we know all
  template arguments.  */
   return type;
 ...

While this change fixed instances where we'd prematurely resolve a
constrained placeholder return or variable type with non-dependent
initializer at template parse time (such as PR96444), it broke the
adc_unify callers that rely on this previous behavior.

So this patch restores the previous behavior during adc_unify deduction
while retaining the new behavior only during adc_variable_type or
adc_return_type deduction.


Sure, it makes sense for adc_unify to behave differently, since in 
deduction context constraints are checked after all template args have 
been deduced.



We additionally now need to pass outer template arguments to
do_auto_deduction during unify, for sake of constraint checking.
But we don't want do_auto_deduction to substitute these outer arguments
into type if it's already been done, hence the added TEMPLATE_TYPE_LEVEL
check.

This fixes partial specializations of non-nested templates with
constrained 'auto' template parameters, but nested templates are still
broken, ultimately because most_specialized_partial_spec passes only the
innermost template arguments to get_partial_spec_bindings, and so
outer_targs during do_auto_deduction (called from unify) contains only
the innermost template arguments which makes satisfaction unhappy.
Fixing this might be too invasive at this stage, perhaps..  (Seems we
need to make most_specialized_partial_spec pass all template arguments
to get_partial_spec_bindings.)


How did this work before?


Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  Also tested on range-v3 and cmcstl2.


Here's the same patch generated with -w which hides the noisy indentation
changes:

-- >8 --

PR c++/99365
* pt.c (do_auto_deduction): When processing_template_decl != 0
and context is adc_unify and we have constraints, pretend the
constraints are satisfied instead of punting.  Add some
clarifying sanity checks.  Don't substitute outer_targs into
type if not needed.

gcc/testsuite/ChangeLog:

PR c++/99365
* g++.dg/cpp2a/concepts-partial-spec9.C: New test.
---
  gcc/cp/pt.c   | 24 ++-
  .../g++.dg/cpp2a/concepts-partial-spec9.C | 24 +++
  2 files changed, 42 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec9.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a4686e0affb..ce537e4529a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23693,7 +23693,8 @@ unify (tree tparms, tree targs, tree parm, tree arg, 
int strict,
  
  	  if (tree a = type_uses_auto (tparm))

{
- tparm = do_auto_deduction (tparm, arg, a, complain, adc_unify);
+ tparm = do_auto_deduction (tparm, arg, a,
+complain, adc_unify, targs);
  if (tparm == error_mark_node)
return 1;
}
@@ -29619,13 +29620,21 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
  }
  
/* Check any placeholder constraints against the deduced type. */

-  if (flag_concepts)
-if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
+  if (processing_template_decl && context == adc_unify)
+/* Pretend constraints are satisfied.  */;
+  else if (flag_concepts
+  && NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
  {
if (processing_template_decl)
- /* In general we can't check satisfaction until we know all
-template arguments.  */
+   {
+ /* Even though the initializer is non-dependent, we need to wait until
+instantiation time to resolve this constrained placeholder variable
+or return type, since the constraint itself may be dependent.  */


Can't we check whether the constraint is dependent, and check 
satisfaction if it isn't?  That might be necessary to make later 

[PATCH, V3] Require GLIBC 2.32 for Decimal/_Float128 conversions.

[Michael Meissner via Gcc-patches]

[PATCH V3] Require GLIBC 2.32 for Decimal/_Float128 conversions.

In the patch that I applied on March 2nd, I had code to provide support for
Decimal/_Float128 conversions if the user did not use at least GLIBC 2.32.  It
did this by using __ibm128 as an intermediate type.  The trouble is __ibm128
cannot represent all of the numbers that _Float128 can, and you lose if you do
this conversion.

This patch removes this support.  The dfp-bit.c functions now call the the
__sprintfieee128 and __strtoieee128 functions to do the conversion.  If the
user does not have GLIBC, they will get a linker error that these functions do
not exist.

The float128 support functions are only built into the static libgcc, so there
isn't an issue with having references to __strtoieee128 and __sprintfieee128
with older GLIBC libraries.

As an added bonus, this patch eliminates the __sprintfkf function which
included stdio.h to get a definition for the sprintf library function.  This
allows for building cross compilers without having to have a target stdio.h
available.

I have built bootstrap compilers for power9 little endian systems with the
three different long double formats (IBM 128-bit, IEEE 128-bit, and 64-bit) and
there were no regressions from previous runs.  I have also build bootstrap
compilers on a big endian power8 and there was no regression there either.

Can I check this patch into the master branch?

libgcc/
2021-03-04  Michael Meissner  

* config/rs6000/t-float128 (fp128_decstr_funcs): Delete.
(fp128_ppc_funcs): Do not add $(fp128_decstr_funcs).
(fp128_decstr_objs): Delete.
* dfp-bit.h: Call __sprintfieee128 to do conversions from
_Float128 to a Decimal type.  Call __strtoieee128 to do
conversions from a Decimal type to _Float128.
* config/rs6000/_sprintfkf.c: Delete file.
* config/rs6000/_sprintfkf.h: Delete file.
* config/rs6000/_strtokf.c: Delete file.
* config/rs6000/_strtokf.h: Delete file.
---
 libgcc/config/rs6000/_sprintfkf.c | 58 ---
 libgcc/config/rs6000/_sprintfkf.h | 27 --
 libgcc/config/rs6000/_strtokf.c   | 53 
 libgcc/config/rs6000/_strtokf.h   | 27 --
 libgcc/config/rs6000/t-float128   | 13 +--
 libgcc/dfp-bit.h  |  8 ++---
 6 files changed, 5 insertions(+), 181 deletions(-)
 delete mode 100644 libgcc/config/rs6000/_sprintfkf.c
 delete mode 100644 libgcc/config/rs6000/_sprintfkf.h
 delete mode 100644 libgcc/config/rs6000/_strtokf.c
 delete mode 100644 libgcc/config/rs6000/_strtokf.h

diff --git a/libgcc/config/rs6000/_sprintfkf.c 
b/libgcc/config/rs6000/_sprintfkf.c
deleted file mode 100644
index 2d624f14e25..000
--- a/libgcc/config/rs6000/_sprintfkf.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/* Copyright (C) 1989-2021 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC 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.
-
-GCC 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.
-
-Under Section 7 of GPL version 3, you are granted additional
-permissions described in the GCC Runtime Library Exception, version
-3.1, as published by the Free Software Foundation.
-
-You should have received a copy of the GNU General Public License and
-a copy of the GCC Runtime Library Exception along with this program;
-see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
-.  */
-
-/* Conversion to IEEE 128-bit floating point from string using snprintf.  */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include <_sprintfkf.h>
-
-/* This function must be built with IBM 128-bit as long double, so that we can
-   access the strfroml function if do not have an IEEE 128-bit version, and if
-   that is not available, use sprintf.  */
-#if !defined(__LONG_DOUBLE_128__) || !defined(__LONG_DOUBLE_IBM128__)
-#error "Long double is not IBM 128-bit"
-#endif
-
-/* If the user is using GLIBC 2.32, we can use the __snprintfieee128 function.
-
-   If we are linked against an earlier library, we will have fake it by
-   converting the value to long double, and using sprintf to do the conversion.
-   This isn't ideal, as IEEE 128-bit has more exponent range than IBM
-   128-bit.  */
-
-extern int __sprintfieee128 (char *restrict, const char *restrict, ...)
-  __attribute__ ((__weak__));
-
-int __sprintfkf (char *restrict string,
-const char *restrict format,
-_Float128 number)
-{
-  if (__sprintfieee128)
-return __sprintfieee128 (string, format, number);
-
-  return sprintf (string, format, (long double) number);
-}
diff 

Re: [PATCH] C++: target attribute - local decl

[Jason Merrill via Gcc-patches]

On 3/4/21 10:52 AM, Martin Liška wrote:

On 3/4/21 4:45 PM, Jason Merrill wrote:


Sure, I guess you do need to set that flag for the local decls, but 
that should be all.


Jason


Doing that also fails :/
This time likely due to how we set RECORD argument of 
maybe_version_functions function:


gcc/cp/decl.c:    && maybe_version_functions (newdecl, olddecl,
gcc/cp/decl.c-    (!DECL_FUNCTION_VERSIONED 
(newdecl)
gcc/cp/decl.c- || 
!DECL_FUNCTION_VERSIONED (olddecl


That is odd.

The other problem is that DECL_LOCAL_DECL_ALIAS isn't always set before 
we get to maybe_version_functions; it's set further down in do_pushdecl. 
 We need it to be set or things break.


This seems to work for me, what do you think?

BTW, your patch was corrupted by the mailer, so I had to apply it by hand.
>From 4227d0906d5e73d80cc0500e72e6277474948911 Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Thu, 4 Mar 2021 11:29:48 -0500
Subject: [PATCH] alias-version
To: gcc-patches@gcc.gnu.org

---
 gcc/cp/name-lookup.h |  1 +
 gcc/cp/call.c|  3 +++
 gcc/cp/decl.c| 29 +
 gcc/cp/name-lookup.c |  4 ++--
 4 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/gcc/cp/name-lookup.h b/gcc/cp/name-lookup.h
index d95472b7545..fec95f67867 100644
--- a/gcc/cp/name-lookup.h
+++ b/gcc/cp/name-lookup.h
@@ -464,6 +464,7 @@ extern void cp_emit_debug_info_for_using (tree, tree);
 
 extern void finish_nonmember_using_decl (tree scope, tree name);
 extern void finish_using_directive (tree target, tree attribs);
+void push_local_extern_decl_alias (tree decl);
 extern tree pushdecl (tree, bool hiding = false);
 extern tree pushdecl_outermost_localscope (tree);
 extern tree pushdecl_top_level (tree);
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 123f06b1f2b..33b77870644 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8467,6 +8467,9 @@ get_function_version_dispatcher (tree fn)
 {
   tree dispatcher_decl = NULL;
 
+  if (DECL_LOCAL_DECL_P (fn))
+fn = DECL_LOCAL_DECL_ALIAS (fn);
+
   gcc_assert (TREE_CODE (fn) == FUNCTION_DECL
 	  && DECL_FUNCTION_VERSIONED (fn));
 
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1742e286d9f..29461ad60b2 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1108,6 +1108,17 @@ decls_match (tree newdecl, tree olddecl, bool record_versions /* = true */)
   return types_match;
 }
 
+static void
+maybe_mark_function_versioned (tree decl)
+{
+  if (!DECL_FUNCTION_VERSIONED (decl))
+{
+  DECL_FUNCTION_VERSIONED (decl) = 1;
+  if (DECL_ASSEMBLER_NAME_SET_P (decl))
+	mangle_decl (decl);
+}
+}
+
 /* NEWDECL and OLDDECL have identical signatures.  If they are
different versions adjust them and return true.
If RECORD is set to true, record function versions.  */
@@ -1118,18 +1129,20 @@ maybe_version_functions (tree newdecl, tree olddecl, bool record)
   if (!targetm.target_option.function_versions (newdecl, olddecl))
 return false;
 
-  if (!DECL_FUNCTION_VERSIONED (olddecl))
+  maybe_mark_function_versioned (olddecl);
+  if (DECL_LOCAL_DECL_P (olddecl))
 {
-  DECL_FUNCTION_VERSIONED (olddecl) = 1;
-  if (DECL_ASSEMBLER_NAME_SET_P (olddecl))
-	mangle_decl (olddecl);
+  olddecl = DECL_LOCAL_DECL_ALIAS (olddecl);
+  maybe_mark_function_versioned (olddecl);
 }
 
-  if (!DECL_FUNCTION_VERSIONED (newdecl))
+  maybe_mark_function_versioned (newdecl);
+  if (DECL_LOCAL_DECL_P (newdecl))
 {
-  DECL_FUNCTION_VERSIONED (newdecl) = 1;
-  if (DECL_ASSEMBLER_NAME_SET_P (newdecl))
-	mangle_decl (newdecl);
+  if (!DECL_LOCAL_DECL_ALIAS (newdecl))
+	push_local_extern_decl_alias (newdecl);
+  newdecl = DECL_LOCAL_DECL_ALIAS (newdecl);
+  maybe_mark_function_versioned (newdecl);
 }
 
   if (record)
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 66c35a1c16d..bd7fd1688d8 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -3384,7 +3384,7 @@ set_decl_context_in_fn (tree ctx, tree decl)
 /* DECL is a local extern decl.  Find or create the namespace-scope
decl that it aliases.  Also, determines the linkage of DECL.  */
 
-static void
+void
 push_local_extern_decl_alias (tree decl)
 {
   if (dependent_type_p (TREE_TYPE (decl)))
@@ -3418,7 +3418,7 @@ push_local_extern_decl_alias (tree decl)
 
   if (binding && TREE_CODE (binding) != TREE_LIST)
 	for (ovl_iterator iter (binding); iter; ++iter)
-	  if (decls_match (*iter, decl))
+	  if (decls_match (decl, *iter, /*record_versions*/false))
 	{
 	  alias = *iter;
 	  break;
-- 
2.27.0

[wwwdocs] Add to libstdc++ header dependency changes

[Jonathan Wakely via Gcc-patches]

Committed to wwwdocs.

commit ed1a8d0621f5f5dee4d869393b9155f475d360f7
Author: Jonathan Wakely 
Date:   Thu Mar 4 20:51:52 2021 +

Add  to libstdc++ header dependency changes

diff --git a/htdocs/gcc-11/porting_to.html b/htdocs/gcc-11/porting_to.html
index 83227c74..4d27c163 100644
--- a/htdocs/gcc-11/porting_to.html
+++ b/htdocs/gcc-11/porting_to.html
@@ -112,6 +112,9 @@ be included explicitly when compiled with GCC 11:
   (for std::pair, std::tuple_size,
   std::index_sequence etc.)
 
+ thread
+  (for members of namespace std::this_thread.)
+
 
 
 Old iostream Members

Aw: Re: [PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on temporary array accesses invalid memory

[Harald Anlauf via Gcc-patches]

Hi Jerry,

> Yes, OK, however, have you been able to test performance. I am only
> curious. There was a test program we used back when this code was first
> implemented in bugzilla. I do not remember the PR number off hand.

as you mentioned in a private mail, it was PR51119, and the timing program

  https://gcc.gnu.org/bugzilla/attachment.cgi?id=40039

I needed to fix the source code slightly to make it work with current gfortran,
by replacing the subroutine dummy with

subroutine dummy(a,b)
  integer, parameter :: wp = selected_real_kind(4), &
   dp = selected_real_kind(8)
  real(dp), intent(in),dimension(1) :: a
  real(dp), intent(inout), dimension(1) :: b
end subroutine dummy

Testing it on my notebook with an Intel i5-8250U which has avx2, I found no
significant differences between the current master and the version with the
patch when compiling with

% gfc-11 -static -O2 -march=native -finline-matmul-limit=0 compare.f90

E.g. gcc-11 with patch to libfortran:

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  0.025  0.139  0.025  0.026
4  2000  0.191  0.799  0.743  0.741
8  2000  3.272  2.437  3.280  3.311
   16  2000  7.615  2.768  8.405  7.572
   32  2000  8.492  3.063  9.733  9.521
   64  2000 14.137  3.299 14.118 14.295
  128  2000 18.838  3.128 19.149 18.893
  256   477 17.214  3.256 17.293 17.255
  51259 17.940  3.316 17.986 17.985
 1024 7 17.672  2.665 17.691 17.698
 2048 1 17.571  2.595 17.559 17.170

With unmodified gcc-11:

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  0.024  0.194  0.025  0.025
4  2000  0.231  1.641  0.718  0.716
8  2000  3.424  2.445  3.198  3.435
   16  2000  7.715  2.718  7.615  7.845
   32  2000  8.696  3.088  9.728  9.772
   64  2000 14.171  3.275 13.995 14.447
  128  2000 18.931  3.127 18.942 19.019
  256   477 17.239  3.232 17.267 17.291
  51259 17.938  3.315 17.967 17.996
 1024 7 17.674  2.632 17.673 17.711
 2048 1 17.579  2.581 17.552 17.587

give or take.  (For those too lazy to check: refMatmul is just
the naive explicit matmul).

However, when comparing with older gccs I got better numbers!  E.g. gcc-7:

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  0.113  0.199  0.126  0.150
4  2000  0.866  0.865  0.766  0.881
8  2000  3.551  2.750  3.371  3.852
   16  2000  7.826  3.517  7.489  7.464
   32  2000  9.989  3.859 11.811 11.903
   64  2000 16.218  4.213 16.501 16.687
  128  2000 19.971  4.006 20.070 20.049
  256   477 22.804  4.139 22.949 22.894
  51259 23.637  4.047 23.800 23.765
 1024 7 23.051  3.065 23.177 23.152
 2048 1 22.953  2.784 22.946 22.960

So if I were worried that there is a performance penalty by my patch,
I'd look for other places, too.

Cheers,
Harald

Re: [PATCH] coroutines : Handle exceptions throw before the first await_resume() [PR95615].

[Nathan Sidwell]

On 2/26/21 4:24 PM, Iain Sandoe wrote:

Hi,

The coroutine body is wrapped in a try-catch block which is responsible for
handling any exceptions thrown by the original function body.  Originally, the
initial suspend expression was outside this, but an amendment to the standard
places the await_resume call inside and everything else outside.

This means that any exception thrown prior to the initial suspend expression
await_resume() will propagate to the ramp function.  However, some portion of
the coroutine state will exist at that point (how much depends on where the
exception is thrown from).  For example, we might have some frame parameter
copies, or the promise object or the return object any of which might have a
non-trivial DTOR.  Also the frame itself needs to be deallocated. This patch
fixes the handling of these cases.

tested on x86_64-darwin, x86_64-linux-gnu,
OK for master / 10.x?
thanks
Iain

gcc/cp/ChangeLog:

PR c++/95615
* coroutines.cc (struct param_info): Track parameter copies that need
a DTOR.
(coro_get_frame_dtor): New helper function factored from build_actor().
(build_actor_fn): Use coro_get_frame_dtor().
(morph_fn_to_coro): Track parameters that need DTORs on exception,
likewise the frame promise and the return object.  On exception, run the
DTORs for these, destroy the frame and then rethrow the exception.



OK.  I spotted a couple of 'VAR_DECL,get_identifier'  (lack of space 
after comma).


nathan

--
Nathan Sidwell

Re: [PATCH] coroutines : Do not accept throwing final await expressions [PR95616].

[Nathan Sidwell]

On 3/4/21 2:54 PM, Iain Sandoe wrote:

Hi,

 From the PR:

The wording of [dcl.fct.def.coroutine]/15 states:
  * The expression co_await promise.final_suspend() shall not be
potentially-throwing ([except.spec]).

See http://eel.is/c++draft/dcl.fct.def.coroutine#15
and http://eel.is/c++draft/except.spec#6

ie. all of the following must be declared noexcept (if they form part of the 
await-expression):
- promise_type::final_suspend()
- finalSuspendObj.operator co_await()
- finalSuspendAwaiter.await_ready()
- finalSuspendAwaiter.await_suspend()
- finalSuspendAwaiter.await_resume()
- finalSuspedObj destructor
- finalSuspendAwaiter destructor

This implements the checks for these cases and rejects such code with
a diagnostic.

[ accepts invalid ]
tested on x86_64-darwin, x86_64-linux-gnu,
OK for master / 10.x?
thanks
Iain


gcc/cp/ChangeLog:

PR c++/95616
* coroutines.cc (coro_diagnose_throwing_fn): New helper.
(coro_diagnose_throwing_final_aw_expr): New helper.
(build_co_await): Diagnose throwing final await expression
components.
(build_init_or_final_await): Diagnose a throwing promise
final_suspend() call.



ok.  Does this DTRT in the presence of -fno-exceptions?  (i.e. use of 
that flag means you don't have to decorate everything with noexcept)


nathan

--
Nathan Sidwell

Re: [PATCH] coroutines : Adjust constraints on when to build ctors [PR98118].

[Nathan Sidwell]

On 3/4/21 2:59 PM, Iain Sandoe wrote:

Hi,

PR98118 shows that TYPE_NEEDS_CONSTRUCTING is a necessary, but not
sufficient, condition for determining when we need to build a constructor.
Use type_build_ctor_call() instead.

tested on x86_64-darwin, x86_64-linux-gnu,

[ ice on valid ]
OK for master / 10.x?
thanks
Iain

gcc/cp/ChangeLog:

 PR c++/98118
 * coroutines.cc (build_co_await): Use type_build_ctor_call()
 to determine cases when a CTOR needs to be built.
 (flatten_await_stmt): Likewise.
 (morph_fn_to_coro): Likewise.


ok, thanks


--
Nathan Sidwell

Re: PING [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)

[Jason Merrill via Gcc-patches]

On 3/4/21 12:44 PM, Martin Sebor wrote:

On 3/3/21 10:33 PM, Jason Merrill wrote:

On 3/3/21 6:20 PM, Martin Sebor wrote:

...

I see what you mean, thanks, but I can't think of a test case to
trigger a false negative due to the smaller offset.  Any suggestions?


My only ideas involve undefined behavior, casting the address to a 
pointer to an unrelated too-large class.  I don't know if that would 
show up as a MEM_REF of this pattern.


Okay, let me see if I can come up with something based on that.




With more testing I also realized that focusing solely on an underlying
DECL like in the above doesn't prevent the warning when an object is
created in dynamically allocated memory or in a backing buffer.  So
the attached revision both adjusts the offset computation upward and
handles all kinds of backing store and moves the logic into a helper
function for better readability.  I've also added more tests.

Retested on x86_64-linux.

Thanks again for your help!

Martin

PS The TYPE_BINFO test isn't as quite as restrictive as I had hoped.
It means we consider all derived class, not just those with virtual
bases.


It's even less restrictive than that: all C++ classes have TYPE_BINFO.


I tried also requiring BINFO_VIRTUAL_P() to be true but that
doesn't work.


Right, BINFO_VIRTUAL_P is true for the binfo representing the virtual 
base in the inheritance hierarchy, not on the binfo for the derived 
class.



Using BINFO_VTABLE() does work but it still isn't the same.


Indeed, virtual functions and virtual bases both cause a class to have 
a vtable.  You could also check BINFO_N_BASE_BINFOS.


Or not bother trying to restrict this to classes with virtual bases 
(i.e. leave the patch as it is), since the result is just as correct 
for other classes.


Jason



I think I'll just go with this last version if you're okay with it
as is.  Okay to commit?


OK.


Martin

PS Let me propose a separate patch to add some text to the BINFO
comments in tree.h to clarify the macros per the above.

[PATCH] coroutines : Adjust constraints on when to build ctors [PR98118].

[Iain Sandoe]

Hi,

PR98118 shows that TYPE_NEEDS_CONSTRUCTING is a necessary, but not
sufficient, condition for determining when we need to build a constructor.
Use type_build_ctor_call() instead.

tested on x86_64-darwin, x86_64-linux-gnu,

[ ice on valid ]
OK for master / 10.x?
thanks
Iain

gcc/cp/ChangeLog:

PR c++/98118
* coroutines.cc (build_co_await): Use type_build_ctor_call()
to determine cases when a CTOR needs to be built.
(flatten_await_stmt): Likewise.
(morph_fn_to_coro): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr98118.C: New test.
---
 gcc/cp/coroutines.cc  | 14 +--
 gcc/testsuite/g++.dg/coroutines/pr98118.C | 29 +++
 2 files changed, 36 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr98118.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index f79ac60dc77..2f4208fe57c 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -949,7 +949,7 @@ build_co_await (location_t loc, tree a, suspend_point_kind 
suspend_kind)
   e_proxy = o;
   o = NULL_TREE; /* The var is already present.  */
 }
-  else if (CLASS_TYPE_P (o_type) || TYPE_NEEDS_CONSTRUCTING (o_type))
+  else if (type_build_ctor_call (o_type))
 {
   e_proxy = get_awaitable_var (suspend_kind, o_type);
   releasing_vec arg (make_tree_vector_single (rvalue (o)));
@@ -2965,7 +2965,7 @@ flatten_await_stmt (var_nest_node *n, hash_set 
*promoted,
  gcc_checking_assert (!already_present);
  tree inner = TREE_OPERAND (init, 1);
  gcc_checking_assert (TREE_CODE (inner) != COND_EXPR);
- if (TYPE_NEEDS_CONSTRUCTING (var_type))
+ if (type_build_ctor_call (var_type))
{
  releasing_vec p_in (make_tree_vector_single (init));
  init = build_special_member_call (var, complete_ctor_identifier,
@@ -2977,9 +2977,9 @@ flatten_await_stmt (var_nest_node *n, hash_set 
*promoted,
  var_nest_node *ins
= new var_nest_node (var, init, n->prev, n);
  /* We have to replace the target expr... */
- proxy_replace pr = {TREE_OPERAND (t, 0), var};
  *v.entry = var;
  /* ... and any uses of its var.  */
+ proxy_replace pr = {TREE_OPERAND (t, 0), var};
  cp_walk_tree (>init, replace_proxy, , NULL);
  /* Compiler-generated temporaries can also have uses in following
 arms of compound expressions, which will be listed in 'replace_in'
@@ -4680,7 +4680,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
   parm.frame_type, INIT_EXPR,
   DECL_SOURCE_LOCATION (arg), arg,
   DECL_ARG_TYPE (arg));
- else if (TYPE_NEEDS_CONSTRUCTING (parm.frame_type))
+ else if (type_build_ctor_call (parm.frame_type))
{
  vec *p_in;
  if (CLASS_TYPE_P (parm.frame_type)
@@ -4738,7 +4738,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
   false, tf_warning_or_error);
 
   tree promise_dtor = NULL_TREE;
-  if (TYPE_NEEDS_CONSTRUCTING (promise_type))
+  if (type_build_ctor_call (promise_type))
 {
   /* Do a placement new constructor for the promise type (we never call
 the new operator, just the constructor on the object in place in the
@@ -4819,7 +4819,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
The expression promise.get_return_object() is used to initialize the
glvalue result or... (see below)
Construct the return result directly.  */
-  if (TYPE_NEEDS_CONSTRUCTING (gro_type))
+  if (type_build_ctor_call (gro_type))
{
  vec *arg = make_tree_vector_single (get_ro);
  r = build_special_member_call (DECL_RESULT (orig),
@@ -4852,7 +4852,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
   DECL_IGNORED_P (gro) = true;
   add_decl_expr (gro);
   gro_bind_vars = gro;
-  if (TYPE_NEEDS_CONSTRUCTING (gro_type))
+  if (type_build_ctor_call (gro_type))
{
  vec *arg = make_tree_vector_single (get_ro);
  r = build_special_member_call (gro, complete_ctor_identifier,
diff --git a/gcc/testsuite/g++.dg/coroutines/pr98118.C 
b/gcc/testsuite/g++.dg/coroutines/pr98118.C
new file mode 100644
index 000..d092142
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr98118.C
@@ -0,0 +1,29 @@
+namespace std {
+inline namespace __n4861 {
+template  struct coroutine_traits : _Result {};
+template  struct coroutine_handle;
+template <> struct coroutine_handle<> {};
+template  struct coroutine_handle : coroutine_handle<> {};
+struct suspend_never {
+  bool await_ready() noexcept;
+  void await_suspend(coroutine_handle<>) noexcept;
+  void await_resume() noexcept;
+};
+} // namespace __n4861
+} // namespace std
+

[PATCH] coroutines : Do not accept throwing final await expressions [PR95616].

[Iain Sandoe]

Hi,

>From the PR:

The wording of [dcl.fct.def.coroutine]/15 states:
 * The expression co_await promise.final_suspend() shall not be
   potentially-throwing ([except.spec]).

See http://eel.is/c++draft/dcl.fct.def.coroutine#15
and http://eel.is/c++draft/except.spec#6

ie. all of the following must be declared noexcept (if they form part of the 
await-expression):
- promise_type::final_suspend()
- finalSuspendObj.operator co_await()
- finalSuspendAwaiter.await_ready()
- finalSuspendAwaiter.await_suspend()
- finalSuspendAwaiter.await_resume()
- finalSuspedObj destructor
- finalSuspendAwaiter destructor

This implements the checks for these cases and rejects such code with
a diagnostic.

[ accepts invalid ]
tested on x86_64-darwin, x86_64-linux-gnu,
OK for master / 10.x?
thanks
Iain


gcc/cp/ChangeLog:

PR c++/95616
* coroutines.cc (coro_diagnose_throwing_fn): New helper.
(coro_diagnose_throwing_final_aw_expr): New helper.
(build_co_await): Diagnose throwing final await expression
components.
(build_init_or_final_await): Diagnose a throwing promise
final_suspend() call.

gcc/testsuite/ChangeLog:

PR c++/95616
* g++.dg/coroutines/pr95616-a.C: New test.
* g++.dg/coroutines/pr95616-b.C: New test.
* g++.dg/coroutines/pr95616-c.C: New test.
* g++.dg/coroutines/pr95616-d.C: New test.
* g++.dg/coroutines/pr95616-e.C: New test.
* g++.dg/coroutines/pr95616-f.C: New test.
* g++.dg/coroutines/pr95616-g.C: New test.
---
 gcc/cp/coroutines.cc| 85 +
 gcc/testsuite/g++.dg/coroutines/pr95616-a.C | 51 +
 gcc/testsuite/g++.dg/coroutines/pr95616-b.C | 51 +
 gcc/testsuite/g++.dg/coroutines/pr95616-c.C | 51 +
 gcc/testsuite/g++.dg/coroutines/pr95616-d.C | 51 +
 gcc/testsuite/g++.dg/coroutines/pr95616-e.C | 51 +
 gcc/testsuite/g++.dg/coroutines/pr95616-f.C | 51 +
 gcc/testsuite/g++.dg/coroutines/pr95616-g.C | 51 +
 8 files changed, 442 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr95616-a.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr95616-b.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr95616-c.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr95616-d.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr95616-e.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr95616-f.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr95616-g.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index ca36c8b8b41..f79ac60dc77 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -793,6 +793,43 @@ get_awaitable_var (suspend_point_kind suspend_kind, tree 
v_type)
   return ret;
 }
 
+/* Helpers to diagnose missing noexcept on final await expressions.  */
+
+static bool
+coro_diagnose_throwing_fn (tree fndecl)
+{
+  if (!TYPE_NOTHROW_P (TREE_TYPE (fndecl)))
+{
+  location_t f_loc = cp_expr_loc_or_loc (fndecl,
+DECL_SOURCE_LOCATION (fndecl));
+  error_at (f_loc, "the expression %qE is required to be non-throwing",
+   fndecl);
+  inform (f_loc, "must be declared with %");
+  return true;
+}
+  return false;
+}
+
+static bool
+coro_diagnose_throwing_final_aw_expr (tree expr)
+{
+  tree t = TARGET_EXPR_INITIAL (expr);
+  tree fn = NULL_TREE;
+  if (TREE_CODE (t) == CALL_EXPR)
+fn = CALL_EXPR_FN(t);
+  else if (TREE_CODE (t) == AGGR_INIT_EXPR)
+fn = AGGR_INIT_EXPR_FN (t);
+  else if (TREE_CODE (t) == CONSTRUCTOR)
+return false;
+  else
+{
+  gcc_checking_assert (0 && "unhandled expression type");
+  return false;
+}
+  fn = TREE_OPERAND (fn, 0);
+  return coro_diagnose_throwing_fn (fn);
+}
+
 /*  This performs [expr.await] bullet 3.3 and validates the interface obtained.
 It is also used to build the initial and final suspend points.
 
@@ -815,6 +852,28 @@ build_co_await (location_t loc, tree a, suspend_point_kind 
suspend_kind)
   /* If no viable functions are found, o is a.  */
   if (!o || o == error_mark_node)
o = a;
+  else if (suspend_kind == FINAL_SUSPEND_POINT)
+   {
+ /* We found an overload for co_await(), diagnose throwing cases.  */
+ if (TREE_CODE (o) == TARGET_EXPR
+ && coro_diagnose_throwing_final_aw_expr (o))
+   return error_mark_node;
+
+ /* We now know that the final suspend object is distinct from the
+final awaiter, so check for a non-throwing DTOR where needed.  */
+ tree a_type = TREE_TYPE (a);
+ if (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (a_type))
+   {
+ tree dummy
+   = build_special_member_call (a, complete_dtor_identifier,
+NULL, a_type, LOOKUP_NORMAL,
+tf_none);
+ dummy = dummy 

Re: PING [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)

[Martin Sebor via Gcc-patches]

On 3/3/21 10:33 PM, Jason Merrill wrote:

On 3/3/21 6:20 PM, Martin Sebor wrote:

...

I see what you mean, thanks, but I can't think of a test case to
trigger a false negative due to the smaller offset.  Any suggestions?


My only ideas involve undefined behavior, casting the address to a 
pointer to an unrelated too-large class.  I don't know if that would 
show up as a MEM_REF of this pattern.


Okay, let me see if I can come up with something based on that.




With more testing I also realized that focusing solely on an underlying
DECL like in the above doesn't prevent the warning when an object is
created in dynamically allocated memory or in a backing buffer.  So
the attached revision both adjusts the offset computation upward and
handles all kinds of backing store and moves the logic into a helper
function for better readability.  I've also added more tests.

Retested on x86_64-linux.

Thanks again for your help!

Martin

PS The TYPE_BINFO test isn't as quite as restrictive as I had hoped.
It means we consider all derived class, not just those with virtual
bases.


It's even less restrictive than that: all C++ classes have TYPE_BINFO.


I tried also requiring BINFO_VIRTUAL_P() to be true but that
doesn't work.


Right, BINFO_VIRTUAL_P is true for the binfo representing the virtual 
base in the inheritance hierarchy, not on the binfo for the derived class.



Using BINFO_VTABLE() does work but it still isn't the same.


Indeed, virtual functions and virtual bases both cause a class to have a 
vtable.  You could also check BINFO_N_BASE_BINFOS.


Or not bother trying to restrict this to classes with virtual bases 
(i.e. leave the patch as it is), since the result is just as correct for 
other classes.


Jason



I think I'll just go with this last version if you're okay with it
as is.  Okay to commit?

Martin

PS Let me propose a separate patch to add some text to the BINFO
comments in tree.h to clarify the macros per the above.

[Patch] Fortran: Follow fixes to -freal-{4,8}-real* handling [PR99355,PR57871] (was: Re: [Patch] Fortran: Fix -freal-{4,8}-real* handling [PR99355])

[Tobias Burnus]

Dominique found an issue ("regression") with this patch – and a testcase
omission.

The previous patch mishandled the noncommitted testcase of PR57871 – or
in other words: It did not promote 1.0_4 or 1.0_8 – as only the
default-real-kind values 1.0 and 1.0d0 were promoted (via code in in
trans-types.c).

I have additionally updated the documentation to more accurately state
what the option does and how it interacts with other options.

OK for mainline?

Tobias

PS: Side remark: My recommendation is to avoid
-freal-{4,8}-real-{4,8,10,16} ...

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf
Fortran: Follow fixes to -freal-{4,8}-real* handling [PR99355,PR57871]

gcc/fortran/ChangeLog:

	PR fortran/99355
	PR fortran/57871
	* invoke.texi (-freal{4,8}-real-*): Extend description.
	* primary.c (match_real_constant): Also promote real literals
	with '_kind' number.

gcc/testsuite/ChangeLog:

	* gfortran.dg/real4-10-real8-10.f90: Add check for real literals
	with '_kind' number.
	* gfortran.dg/real4-10-real8-16.f90: Likewise.
	* gfortran.dg/real4-10-real8-4.f90: Likewise.
	* gfortran.dg/real4-10.f90: Likewise.
	* gfortran.dg/real4-16-real8-10.f90: Likewise.
	* gfortran.dg/real4-16-real8-16.f90: Likewise.
	* gfortran.dg/real4-16-real8-4.f90: Likewise.
	* gfortran.dg/real4-16.f90: Likewise.
	* gfortran.dg/real4-8-real8-10.f90: Likewise.
	* gfortran.dg/real4-8-real8-16.f90: Likewise.
	* gfortran.dg/real4-8-real8-4.f90: Likewise.
	* gfortran.dg/real4-8.f90: Likewise.
	* gfortran.dg/real8-10.f90: Likewise.
	* gfortran.dg/real8-16.f90: Likewise.
	* gfortran.dg/real8-4.f90: Likewise.

 gcc/fortran/invoke.texi | 19 +++
 gcc/fortran/primary.c   | 19 +++
 gcc/testsuite/gfortran.dg/real4-10-real8-10.f90 |  6 --
 gcc/testsuite/gfortran.dg/real4-10-real8-16.f90 |  6 --
 gcc/testsuite/gfortran.dg/real4-10-real8-4.f90  |  6 --
 gcc/testsuite/gfortran.dg/real4-10.f90  |  6 --
 gcc/testsuite/gfortran.dg/real4-16-real8-10.f90 |  6 --
 gcc/testsuite/gfortran.dg/real4-16-real8-16.f90 |  6 --
 gcc/testsuite/gfortran.dg/real4-16-real8-4.f90  |  6 --
 gcc/testsuite/gfortran.dg/real4-16.f90  |  6 --
 gcc/testsuite/gfortran.dg/real4-8-real8-10.f90  |  6 --
 gcc/testsuite/gfortran.dg/real4-8-real8-16.f90  |  6 --
 gcc/testsuite/gfortran.dg/real4-8-real8-4.f90   |  6 --
 gcc/testsuite/gfortran.dg/real4-8.f90   |  6 --
 gcc/testsuite/gfortran.dg/real8-10.f90  |  6 --
 gcc/testsuite/gfortran.dg/real8-16.f90  |  6 --
 gcc/testsuite/gfortran.dg/real8-4.f90   |  6 --
 17 files changed, 94 insertions(+), 34 deletions(-)

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 3f3ae5a7611..0fb7e1add7e 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -520,13 +520,24 @@ representation of the translated Fortran code, produced by
 @cindex options, real kind type promotion
 Promote all @code{REAL(KIND=M)} entities to @code{REAL(KIND=N)} entities.
 If @code{REAL(KIND=N)} is unavailable, then an error will be issued.
-All other real kind types are unaffected by this option.
+The @code{-freal-4-} flags also affect the default real kind and the
+@code{-freal-8-} flags also the double-precision real kind.  All other
+real-kind types are unaffected by this option.  The promotion is also
+applied to real literal constants of default and double-precision kind
+and a specified kind number of 4 or 8, respectively.
+However, @code{-fdefault-real-8}, @code{-fdefault-real-10},
+@code{-fdefault-real-10}, and @code{-fdefault-double-8} take precedence
+for the default and double-precision real kinds, both for real literal
+constants and for declarations without a kind number.
+Note that for @code{REAL(KIND=KIND(1.0))} the literal may get promoted and
+then the result may get promoted again.
 These options should be used with care and may not be suitable for your
 codes.  Areas of possible concern include calls to external procedures,
 alignment in @code{EQUIVALENCE} and/or @code{COMMON}, generic interfaces,
-BOZ literal constant conversion, and I/O.  Inspection of the intermediate
-representation of the translated Fortran code, produced by
-@option{-fdump-tree-original}, is suggested.
+BOZ literal constant conversion, and I/O and calls to intrinsic procedures
+when passing a value to the @code{kind=} dummy argument.  Inspection of the
+intermediate representation of the translated Fortran code, produced by
+@option{-fdump-fortran-original} or @option{-fdump-tree-original}, is suggested.
 
 @item -std=@var{std}
 @opindex @code{std=}@var{std} option
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index 9dd1a86f275..a6df885c80c 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -666,6 +666,25 @@ done:
   

[patch] Fix PR rtl-optimization/99376

[Eric Botcazou]

Hi,

this is an undefined behavior spotted by the sanitizer that has managed to go 
unnoticed until now.  Tested on x86-64/Linux, OK for the mainline?


2021-03-04  Eric Botcazou  

PR rtl-optimization/99376
* rtlanal.c (nonzero_bits1) : If the number
of low-order zero bits is too large, set the result to 0 directly.

-- 
Eric Botcazoudiff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index d1240b0b7c5..a8ea1d72636 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -5053,11 +5053,17 @@ nonzero_bits1 (const_rtx x, scalar_int_mode mode, const_rtx known_x,
 	gcc_unreachable ();
 	  }
 
+	/* Note that mode_width <= HOST_BITS_PER_WIDE_INT, see above.  */
 	if (result_width < mode_width)
 	  nonzero &= (HOST_WIDE_INT_1U << result_width) - 1;
 
 	if (result_low > 0)
-	  nonzero &= ~((HOST_WIDE_INT_1U << result_low) - 1);
+	  {
+	if (result_low < HOST_BITS_PER_WIDE_INT)
+	  nonzero &= ~((HOST_WIDE_INT_1U << result_low) - 1);
+	else
+	  nonzero = 0;
+	  }
   }
   break;
 

Re: [PATCH] Extract a common logger from jit and analyzer frameworks

[David Malcolm via Gcc-patches]

On Thu, 2021-03-04 at 16:17 +, Philip Herron wrote:
> In development of the Rust FE logging is useful in debugging. Instead
> of
> rolling our own logger it became clear the loggers part of analyzer
> and jit
> projects could be extracted and made generic so they could be reused
> in
> other projects.

Thanks for putting together this patch.

> To test this patch make check-jit was invoked, for analyzer the
> following
> flags were used -fanalyzer -fdump-analyzer -fanalyzer-verbosity=4.

"-fanalyzer-verbosity=" only affects what events appear in diagnostic
paths from the analyzer; it doesn't directly affect the logging (it
does indirectly, I suppose, since there are logging messages per-event
as they are processed)

> gcc/jit/ChangeLog:
> 
>     * jit-logging.h: has been extracted out to gcc/logging.h
> 
> gcc/analyzer/ChangeLog:
> 
>     * analyzer-logging.h: has been extract out to gcc/logging.h
> 
> gcc/ChangeLog:
> 
>     * logging.h: added new generic logger based off analyzer's
> logger

The ChangeLog entries are incomplete, and so the git hooks will
probably complain when you try to push this.

Various notes inline below...

[...snip...]
 
> diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
> index f50ac662516..87193268b10 100644
> --- a/gcc/analyzer/analyzer.h
> +++ b/gcc/analyzer/analyzer.h
> @@ -23,6 +23,16 @@ along with GCC; see the file COPYING3.  If not see
>  
>  class graphviz_out;
>  
> +namespace gcc {
> +  class logger;
> +  class log_scope;
> +  class log_user;
> +}
> +
> +using gcc::logger;
> +using gcc::log_scope;
> +using gcc::log_user;

Are the "using" decls for log_scope and log_user needed?  I know that
"logger" is used in a bunch of places, so the "using" decl for that is
probably useful, but my guess is that the other two are barely used in
the analyzer code, if at all.

[...]

> 
> diff --git a/gcc/analyzer/analyzer-logging.cc b/gcc/logging.c
> similarity index 76%
> rename from gcc/analyzer/analyzer-logging.cc
> rename to gcc/logging.c
> index 297319069f8..630a16d19dd 100644
> --- a/gcc/analyzer/analyzer-logging.cc
> +++ b/gcc/logging.c
[...]
>  /* Implementation of class logger.  */
>  
>  /* ctor for logger.  */
>  
> -logger::logger (FILE *f_out,
> -   int, /* flags */
> -   int /* verbosity */,
> -   const pretty_printer _pp) :
> -  m_refcount (0),
> -  m_f_out (f_out),
> -  m_indent_level (0),
> -  m_log_refcount_changes (false),
> -  m_pp (reference_pp.clone ())
> +logger::logger (FILE *f_out, int, /* flags */
> +   int /* verbosity */, const pretty_printer
> *reference_pp,
> +   const char *module)
> +  : m_refcount (0), m_f_out (f_out), m_indent_level (0),
> +    m_log_refcount_changes (false), m_pp (reference_pp->clone ()),
> +    m_mod (module)
>  {
>    pp_show_color (m_pp) = 0;
>    pp_buffer (m_pp)->stream = f_out;
> @@ -61,6 +57,15 @@ logger::logger (FILE *f_out,
>    print_version (f_out, "", false);
>  }
>  
> +logger::logger (FILE *f_out, int, /* flags */
> +   int /* verbosity */, const char *module)
> +  : m_refcount (0), m_f_out (f_out), m_indent_level (0),
> +    m_log_refcount_changes (false), m_pp (nullptr), m_mod (module)
> +{
> +  /* Begin the log by writing the GCC version.  */
> +  print_version (f_out, "", false);
> +}

Both of these pass the empty string to print_version, but the to-be-
deleted implementation in jit-logging.c passed "JIT: ".  So I think
this one needs to read something like:

 print_version (f_out, m_mod ? m_mod : "", false);

or somesuch.

I'm probably bikeshedding, but could module/m_mod be renamed to
prefix/m_prefix?

I think it would be good to have a leading comment for this new ctor.
In particular, summarizing our discussion from github, something like:

/* logger ctor for use by libgccjit.

   The module param, if non-NULL, is printed as a prefix to all log
   messages.  This is particularly useful for libgccjit, where the
   log lines are often intermingled with messages from the program
   that libgccjit is linked into.  */

or somesuch.


[...]

> @@ -144,19 +152,27 @@ logger::log_partial (const char *fmt, ...)
>  void
>  logger::log_va_partial (const char *fmt, va_list *ap)
>  {
> -  text_info text;
> -  text.format_spec = fmt;
> -  text.args_ptr = ap;
> -  text.err_no = 0;
> -  pp_format (m_pp, );
> -  pp_output_formatted_text (m_pp);

I think there's an issue here: what format codes are accepted by this
function?

> +  if (!has_pretty_printer ())
> +    vfprintf (m_f_out, fmt, *ap);

...here we're formatting using vfprintf...

> +  else
> +    {
> +  text_info text;
> +  text.format_spec = fmt;
> +  text.args_ptr = ap;
> +  text.err_no = 0;
> +  pp_format (m_pp, );

...whereas here we're formatting using pp_format, which has different
conventions.

The jit implementation decls have e.g.:
   GNU_PRINTF(2, 3);
whereas the analyzer decls have e.g.:
   ATTRIBUTE_GCC_DIAG(2, 3);

I'm not quite sure 

Re: [Patch] OpenACC: C/C++ - fix async parsing [PR99137]

[Thomas Schwinge]

Hi!

On 2021-02-19T13:59:20+0100, Tobias Burnus  wrote:
> For:
>#pragma acc parallel async(1,2)
>
> avoid with C an ICE for the original tree:
>#pragma acc parallel async(<<< Unknown tree: c_maybe_const_expr 1, 2 >>>)
>
> It did not ICE with C++, but I think the tree does not make sense, either:
>#pragma acc parallel async(<<< Unknown tree: void_cst >>>, 2)

Led by Tobias, in today's "OpenACC Technical Meeting", we discussed
 "What does
'async(1, 2)' mean?" (only visible to members of OpenACC GitHub), and
quickly came to agreement that the intention indeed is to have such
clause arguments be C/C++ base language "assignment-expressions" (like
Jakub in PR99137 had described OpenMP that does).

This will be clarified in a later OpenACC specification release.

The same issue likely also appears for other clauses (not taking a list
of expressions), so will then need to be generally reviewed -- that's for
later.

However, since Tobias has already posted a patch for 'async' (thanks!):

> OK for mainline?
> (Not a regression;

..., but does fix an ICE, and the code change is very specific, I'd say
that's good to push.

> I don't know whether it makes sense to apply to other branches).

I'd say so; I expect it to apply without any fuzz, and expect to fix the
same ICEs there.

One minor comment:

> OpenACC: C/C++ - fix async parsing [PR99137]
>
> gcc/c/ChangeLog:
>
>   PR c/99137
>   * c-parser.c (c_parser_oacc_clause_async): Reject comma expressions.
>
> gcc/cp/ChangeLog:
>
>   PR c/99137
>   * parser.c (cp_parser_oacc_clause_async): Reject comma expressions.
>
> gcc/testsuite/ChangeLog:
>
>   PR c/99137
>   * c-c++-common/goacc/asyncwait-1.c: Update dg-error.
>   * c-c++-common/goacc/async-1.c: New test.
>
>  gcc/c/c-parser.c   |  2 +-
>  gcc/cp/parser.c|  2 +-
>  gcc/testsuite/c-c++-common/goacc/async-1.c |  7 +++
>  gcc/testsuite/c-c++-common/goacc/asyncwait-1.c | 16 
>  4 files changed, 17 insertions(+), 10 deletions(-)

I suggest to merge the new 'c-c++-common/goacc/async-1.c' into the
existing 'c-c++-common/goacc/asyncwait-1.c'; no need for an extra
testcase file?  Just one '#pragma acc wait async (1,2)' variant with
"PR99137" comment after the other "comma variants" in there, seems
sufficient?


Grüße
 Thomas


> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 2a49d07bab4..5cdeb21a458 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -14332,7 +14332,7 @@ c_parser_oacc_clause_async (c_parser *parser, tree 
> list)
>  {
>c_parser_consume_token (parser);
>
> -  t = c_parser_expression (parser).value;
> +  t = c_parser_expr_no_commas (parser, NULL).value;
>if (!INTEGRAL_TYPE_P (TREE_TYPE (t)))
>   c_parser_error (parser, "expected integer expression");
>else if (t == error_mark_node
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 70775792161..6a29b6dca10 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -37991,7 +37991,7 @@ cp_parser_oacc_clause_async (cp_parser *parser, tree 
> list)
>matching_parens parens;
>parens.consume_open (parser);
>
> -  t = cp_parser_expression (parser);
> +  t = cp_parser_assignment_expression (parser);
>if (t == error_mark_node
> || !parens.require_close (parser))
>   cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
> diff --git a/gcc/testsuite/c-c++-common/goacc/async-1.c 
> b/gcc/testsuite/c-c++-common/goacc/async-1.c
> new file mode 100644
> index 000..a578dabce8c
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/goacc/async-1.c
> @@ -0,0 +1,7 @@
> +/* PR c/99137 */
> +
> +void f ()
> +{
> +  #pragma acc parallel async(1,2)  /* { dg-error "expected '\\)' before ',' 
> token" } */
> +  ;
> +}
> diff --git a/gcc/testsuite/c-c++-common/goacc/asyncwait-1.c 
> b/gcc/testsuite/c-c++-common/goacc/asyncwait-1.c
> index 2f5d4762b49..b5d789621ec 100644
> --- a/gcc/testsuite/c-c++-common/goacc/asyncwait-1.c
> +++ b/gcc/testsuite/c-c++-common/goacc/asyncwait-1.c
> @@ -9,7 +9,7 @@ f (int N, float *a, float *b)
>  b[ii] = a[ii];
>  }
>
> -#pragma acc parallel copyin (a[0:N]) copy (b[0:N]) async (1,) /* { dg-error 
> "expected (primary-|)expression before" } */
> +#pragma acc parallel copyin (a[0:N]) copy (b[0:N]) async (1,) /* { dg-error 
> "expected '\\)' before ',' token" } */
>  {
>  for (ii = 0; ii < N; ii++)
>  b[ii] = a[ii];
> @@ -21,19 +21,19 @@ f (int N, float *a, float *b)
>  b[ii] = a[ii];
>  }
>
> -#pragma acc parallel copyin (a[0:N]) copy (b[0:N]) async (1,2,) /* { 
> dg-error "expected (primary-|)expression before" } */
> +#pragma acc parallel copyin (a[0:N]) copy (b[0:N]) async (1,2,) /* { 
> dg-error "expected '\\)' before ',' token" } */
>  {
>  for (ii = 0; ii < N; ii++)
>  

Re: [PATCH] c++: adc_unify deduction with constrained auto [PR99365]

[Patrick Palka via Gcc-patches]

On Thu, 4 Mar 2021, Patrick Palka wrote:

> My recent r11-7454 changed the way do_auto_deduction handles constrained
> placeholders during template argument deduction (context == adc_unify)
> when processing_template_decl != 0.
> 
> Before the patch, when processing_template_decl != 0 we would just
> ignore the constraints on the placeholder in this situation, and proceed
> with deduction:
> 
>   /* Check any placeholder constraints against the deduced type. */
>   if (flag_concepts && !processing_template_decl)
> if (tree check = NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
>   {
> ...
> 
> After the patch, we now punt and return the original placeholder type:
> 
>   /* Check any placeholder constraints against the deduced type. */
>   if (flag_concepts)
> if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
>   {
> if (processing_template_decl)
>   /* In general we can't check satisfaction until we know all
>  template arguments.  */
>   return type;
> ...
> 
> While this change fixed instances where we'd prematurely resolve a
> constrained placeholder return or variable type with non-dependent
> initializer at template parse time (such as PR96444), it broke the
> adc_unify callers that rely on this previous behavior.
> 
> So this patch restores the previous behavior during adc_unify deduction
> while retaining the new behavior only during adc_variable_type or
> adc_return_type deduction.
> 
> We additionally now need to pass outer template arguments to
> do_auto_deduction during unify, for sake of constraint checking.
> But we don't want do_auto_deduction to substitute these outer arguments
> into type if it's already been done, hence the added TEMPLATE_TYPE_LEVEL
> check.
> 
> This fixes partial specializations of non-nested templates with
> constrained 'auto' template parameters, but nested templates are still
> broken, ultimately because most_specialized_partial_spec passes only the
> innermost template arguments to get_partial_spec_bindings, and so
> outer_targs during do_auto_deduction (called from unify) contains only
> the innermost template arguments which makes satisfaction unhappy.
> Fixing this might be too invasive at this stage, perhaps..  (Seems we
> need to make most_specialized_partial_spec pass all template arguments
> to get_partial_spec_bindings.)
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?  Also tested on range-v3 and cmcstl2.

Here's the same patch generated with -w which hides the noisy indentation
changes:

-- >8 --

PR c++/99365
* pt.c (do_auto_deduction): When processing_template_decl != 0
and context is adc_unify and we have constraints, pretend the
constraints are satisfied instead of punting.  Add some
clarifying sanity checks.  Don't substitute outer_targs into
type if not needed.

gcc/testsuite/ChangeLog:

PR c++/99365
* g++.dg/cpp2a/concepts-partial-spec9.C: New test.
---
 gcc/cp/pt.c   | 24 ++-
 .../g++.dg/cpp2a/concepts-partial-spec9.C | 24 +++
 2 files changed, 42 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec9.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a4686e0affb..ce537e4529a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23693,7 +23693,8 @@ unify (tree tparms, tree targs, tree parm, tree arg, 
int strict,
 
  if (tree a = type_uses_auto (tparm))
{
- tparm = do_auto_deduction (tparm, arg, a, complain, adc_unify);
+ tparm = do_auto_deduction (tparm, arg, a,
+complain, adc_unify, targs);
  if (tparm == error_mark_node)
return 1;
}
@@ -29619,13 +29620,21 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
 }
 
   /* Check any placeholder constraints against the deduced type. */
-  if (flag_concepts)
-if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
+  if (processing_template_decl && context == adc_unify)
+/* Pretend constraints are satisfied.  */;
+  else if (flag_concepts
+  && NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
 {
   if (processing_template_decl)
- /* In general we can't check satisfaction until we know all
-template arguments.  */
+   {
+ /* Even though the initializer is non-dependent, we need to wait until
+instantiation time to resolve this constrained placeholder variable
+or return type, since the constraint itself may be dependent.  */
+ gcc_checking_assert (context == adc_variable_type
+  || context == adc_return_type);
+ gcc_checking_assert (!type_dependent_expression_p (init));
  return type;
+   }
 
   if ((context == adc_return_type || context == 

[PATCH] c++: adc_unify deduction with constrained auto [PR99365]

[Patrick Palka via Gcc-patches]

My recent r11-7454 changed the way do_auto_deduction handles constrained
placeholders during template argument deduction (context == adc_unify)
when processing_template_decl != 0.

Before the patch, when processing_template_decl != 0 we would just
ignore the constraints on the placeholder in this situation, and proceed
with deduction:

  /* Check any placeholder constraints against the deduced type. */
  if (flag_concepts && !processing_template_decl)
if (tree check = NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
  {
...

After the patch, we now punt and return the original placeholder type:

  /* Check any placeholder constraints against the deduced type. */
  if (flag_concepts)
if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
  {
if (processing_template_decl)
  /* In general we can't check satisfaction until we know all
 template arguments.  */
  return type;
...

While this change fixed instances where we'd prematurely resolve a
constrained placeholder return or variable type with non-dependent
initializer at template parse time (such as PR96444), it broke the
adc_unify callers that rely on this previous behavior.

So this patch restores the previous behavior during adc_unify deduction
while retaining the new behavior only during adc_variable_type or
adc_return_type deduction.

We additionally now need to pass outer template arguments to
do_auto_deduction during unify, for sake of constraint checking.
But we don't want do_auto_deduction to substitute these outer arguments
into type if it's already been done, hence the added TEMPLATE_TYPE_LEVEL
check.

This fixes partial specializations of non-nested templates with
constrained 'auto' template parameters, but nested templates are still
broken, ultimately because most_specialized_partial_spec passes only the
innermost template arguments to get_partial_spec_bindings, and so
outer_targs during do_auto_deduction (called from unify) contains only
the innermost template arguments which makes satisfaction unhappy.
Fixing this might be too invasive at this stage, perhaps..  (Seems we
need to make most_specialized_partial_spec pass all template arguments
to get_partial_spec_bindings.)

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  Also tested on range-v3 and cmcstl2.

gcc/cp/ChangeLog:

PR c++/99365
* pt.c (do_auto_deduction): When processing_template_decl != 0
and context is adc_unify and we have constraints, pretend the
constraints are satisfied instead of punting.  Add some
clarifying sanity checks.  Don't substitute outer_targs into
type if not needed.

gcc/testsuite/ChangeLog:

PR c++/99365
* g++.dg/cpp2a/concepts-partial-spec9.C: New test.
---
 gcc/cp/pt.c   | 98 +++
 .../g++.dg/cpp2a/concepts-partial-spec9.C | 24 +
 2 files changed, 79 insertions(+), 43 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec9.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a4686e0affb..ce537e4529a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23693,7 +23693,8 @@ unify (tree tparms, tree targs, tree parm, tree arg, 
int strict,
 
  if (tree a = type_uses_auto (tparm))
{
- tparm = do_auto_deduction (tparm, arg, a, complain, adc_unify);
+ tparm = do_auto_deduction (tparm, arg, a,
+complain, adc_unify, targs);
  if (tparm == error_mark_node)
return 1;
}
@@ -29619,52 +29620,63 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
 }
 
   /* Check any placeholder constraints against the deduced type. */
-  if (flag_concepts)
-if (NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
-  {
-   if (processing_template_decl)
- /* In general we can't check satisfaction until we know all
-template arguments.  */
+  if (processing_template_decl && context == adc_unify)
+/* Pretend constraints are satisfied.  */;
+  else if (flag_concepts
+  && NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
+{
+  if (processing_template_decl)
+   {
+ /* Even though the initializer is non-dependent, we need to wait until
+instantiation time to resolve this constrained placeholder variable
+or return type, since the constraint itself may be dependent.  */
+ gcc_checking_assert (context == adc_variable_type
+  || context == adc_return_type);
+ gcc_checking_assert (!type_dependent_expression_p (init));
  return type;
+   }
 
-   if ((context == adc_return_type || context == adc_variable_type)
-   && current_function_decl
-   && DECL_TEMPLATE_INFO (current_function_decl))
- outer_targs = DECL_TI_ARGS (current_function_decl);
+  if 

[PATCH] Extract a common logger from jit and analyzer frameworks

[Philip Herron]

In development of the Rust FE logging is useful in debugging. Instead of
rolling our own logger it became clear the loggers part of analyzer and jit
projects could be extracted and made generic so they could be reused in
other projects.

To test this patch make check-jit was invoked, for analyzer the following
flags were used -fanalyzer -fdump-analyzer -fanalyzer-verbosity=4.

gcc/jit/ChangeLog:

* jit-logging.h: has been extracted out to gcc/logging.h

gcc/analyzer/ChangeLog:

* analyzer-logging.h: has been extract out to gcc/logging.h

gcc/ChangeLog:

* logging.h: added new generic logger based off analyzer's logger
---
 gcc/Makefile.in   |   3 +-
 gcc/analyzer/analysis-plan.cc |   2 +-
 gcc/analyzer/analyzer.h   |  11 +-
 gcc/analyzer/checker-path.cc  |   2 +-
 gcc/analyzer/complexity.cc|   2 +-
 gcc/analyzer/diagnostic-manager.cc|   2 +-
 gcc/analyzer/engine.cc|   4 +-
 gcc/analyzer/pending-diagnostic.cc|   2 +-
 gcc/analyzer/program-point.cc |   2 +-
 gcc/analyzer/program-state.cc |   2 +-
 gcc/analyzer/region-model-impl-calls.cc   |   2 +-
 gcc/analyzer/region-model-manager.cc  |   2 +-
 gcc/analyzer/region-model-reachability.cc |   2 +-
 gcc/analyzer/region-model.cc  |   2 +-
 gcc/analyzer/region.cc|   2 +-
 gcc/analyzer/sm-file.cc   |   2 +-
 gcc/analyzer/sm-malloc.cc |   2 +-
 gcc/analyzer/sm-pattern-test.cc   |   2 +-
 gcc/analyzer/sm-sensitive.cc  |   2 +-
 gcc/analyzer/sm-signal.cc |   2 +-
 gcc/analyzer/sm-taint.cc  |   2 +-
 gcc/analyzer/sm.cc|   2 +-
 gcc/analyzer/state-purge.cc   |   2 +-
 gcc/analyzer/store.cc |   2 +-
 gcc/analyzer/supergraph.cc|   2 +-
 gcc/analyzer/supergraph.h |   8 +-
 gcc/analyzer/svalue.cc|   2 +-
 gcc/jit/Make-lang.in  |   1 -
 gcc/jit/jit-common.h  |   3 +-
 gcc/jit/jit-logging.c | 171 --
 gcc/jit/jit-logging.h | 162 +
 gcc/jit/libgccjit.c   |   4 +-
 .../analyzer-logging.cc => logging.c} |  75 +---
 .../analyzer-logging.h => logging.h}  | 103 ++-
 34 files changed, 145 insertions(+), 446 deletions(-)
 delete mode 100644 gcc/jit/jit-logging.c
 rename gcc/{analyzer/analyzer-logging.cc => logging.c} (76%)
 rename gcc/{analyzer/analyzer-logging.h => logging.h} (69%)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index a63c5d9cab6..408ef6e3f0b 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1244,7 +1244,6 @@ C_COMMON_OBJS = c-family/c-common.o 
c-family/c-cppbuiltin.o c-family/c-dump.o \
 ANALYZER_OBJS = \
analyzer/analysis-plan.o \
analyzer/analyzer.o \
-   analyzer/analyzer-logging.o \
analyzer/analyzer-pass.o \
analyzer/analyzer-selftests.o \
analyzer/bar-chart.o \
@@ -1710,7 +1709,7 @@ OBJS-libcommon = diagnostic.o diagnostic-color.o 
diagnostic-show-locus.o \
pretty-print.o intl.o \
sbitmap.o \
vec.o input.o version.o hash-table.o ggc-none.o memory-block.o \
-   selftest.o selftest-diagnostic.o sort.o
+   selftest.o selftest-diagnostic.o sort.o logging.o
 
 # Objects in libcommon-target.a, used by drivers and by the core
 # compiler and containing target-dependent code.
diff --git a/gcc/analyzer/analysis-plan.cc b/gcc/analyzer/analysis-plan.cc
index 7dfc48e9c3e..40d325976ca 100644
--- a/gcc/analyzer/analysis-plan.cc
+++ b/gcc/analyzer/analysis-plan.cc
@@ -30,7 +30,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "json.h"
 #include "analyzer/analyzer.h"
 #include "diagnostic-core.h"
-#include "analyzer/analyzer-logging.h"
+#include "logging.h"
 #include "analyzer/analysis-plan.h"
 #include "ordered-hash-map.h"
 #include "options.h"
diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
index f50ac662516..87193268b10 100644
--- a/gcc/analyzer/analyzer.h
+++ b/gcc/analyzer/analyzer.h
@@ -23,6 +23,16 @@ along with GCC; see the file COPYING3.  If not see
 
 class graphviz_out;
 
+namespace gcc {
+  class logger;
+  class log_scope;
+  class log_user;
+}
+
+using gcc::logger;
+using gcc::log_scope;
+using gcc::log_user;
+
 namespace ana {
 
 /* Forward decls of common types, with indentation to show inheritance.  */
@@ -98,7 +108,6 @@ class rewind_info_t;
 
 class engine;
 class state_machine;
-class logger;
 class visitor;
 
 /* Forward decls of functions.  */
diff --git a/gcc/analyzer/checker-path.cc b/gcc/analyzer/checker-path.cc
index e6e3ec18688..ca138336fd3 100644
--- 

Re: [PATCH] expand: Fix ICE in store_bit_field_using_insv [PR93235]

[Jeff Law via Gcc-patches]

On 3/4/21 2:11 AM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on aarch64.  The problem is that
> op0 is (subreg:HI (reg:HF ...) 0) and because we can't create a SUBREG of a
> SUBREG and aarch64 doesn't have HImode insv, only SImode insv,
> store_bit_field_using_insv tries to create (subreg:SI (reg:HF ...) 0)
> which is not valid for the target and so gen_rtx_SUBREG ICEs.
>
> The following patch fixes it by punting if the to be created SUBREG
> doesn't validate, callers of store_bit_field_using_insv can handle
> the fallback.
>
> Bootstrapped/regtested on x86_64-linux, i686-linux and aarch64-linux, ok for
> trunk?
>
> 2021-03-03  Jakub Jelinek  
>
>   PR middle-end/93235
>   * expmed.c (store_bit_field_using_insv): Return false of xop0 is a
>   SUBREG and a SUBREG to op_mode can't be created.
>
>   * gcc.target/aarch64/pr93235.c: New test.
OK
jeff

Re: [PATCH] C++: target attribute - local decl

[Martin Liška]

On 3/4/21 4:45 PM, Jason Merrill wrote:


Sure, I guess you do need to set that flag for the local decls, but that should 
be all.

Jason


Doing that also fails :/
This time likely due to how we set RECORD argument of maybe_version_functions 
function:

gcc/cp/decl.c:&& maybe_version_functions (newdecl, olddecl,
gcc/cp/decl.c-(!DECL_FUNCTION_VERSIONED 
(newdecl)
gcc/cp/decl.c- || !DECL_FUNCTION_VERSIONED 
(olddecl

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 123f06b1f2b..117f1755191 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8467,6 +8467,10 @@ get_function_version_dispatcher (tree fn)
 {
   tree dispatcher_decl = NULL;
 
+  if (DECL_LOCAL_DECL_P (fn)

+  && DECL_LOCAL_DECL_ALIAS (fn) != NULL_TREE)
+fn = DECL_LOCAL_DECL_ALIAS (fn);
+
   gcc_assert (TREE_CODE (fn) == FUNCTION_DECL
  && DECL_FUNCTION_VERSIONED (fn));
 
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c

index 1742e286d9f..4fa9c2a0dcb 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1108,6 +1108,17 @@ decls_match (tree newdecl, tree olddecl, bool 
record_versions /* = true */)
   return types_match;
 }
 
+static void

+maybe_mark_function_versioned (tree decl)
+{
+  if (!DECL_FUNCTION_VERSIONED (decl))
+{
+  DECL_FUNCTION_VERSIONED (decl) = 1;
+  if (DECL_ASSEMBLER_NAME_SET_P (decl))
+   mangle_decl (decl);
+}
+}
+
 /* NEWDECL and OLDDECL have identical signatures.  If they are
different versions adjust them and return true.
If RECORD is set to true, record function versions.  */
@@ -1118,18 +1129,20 @@ maybe_version_functions (tree newdecl, tree olddecl, 
bool record)
   if (!targetm.target_option.function_versions (newdecl, olddecl))
 return false;
 
-  if (!DECL_FUNCTION_VERSIONED (olddecl))

+  maybe_mark_function_versioned (olddecl);
+  if (DECL_LOCAL_DECL_P (olddecl)
+  && DECL_LOCAL_DECL_ALIAS (olddecl) != NULL_TREE)
 {
-  DECL_FUNCTION_VERSIONED (olddecl) = 1;
-  if (DECL_ASSEMBLER_NAME_SET_P (olddecl))
-   mangle_decl (olddecl);
+  olddecl = DECL_LOCAL_DECL_ALIAS (olddecl);
+  maybe_mark_function_versioned (olddecl);
 }
 
-  if (!DECL_FUNCTION_VERSIONED (newdecl))

+  maybe_mark_function_versioned (newdecl);
+  if (DECL_LOCAL_DECL_P (newdecl)
+  && DECL_LOCAL_DECL_ALIAS (newdecl) != NULL_TREE)
 {
-  DECL_FUNCTION_VERSIONED (newdecl) = 1;
-  if (DECL_ASSEMBLER_NAME_SET_P (newdecl))
-   mangle_decl (newdecl);
+  newdecl = DECL_LOCAL_DECL_ALIAS (newdecl);
+  maybe_mark_function_versioned (newdecl);
 }
 
   if (record)

diff --git a/gcc/testsuite/g++.target/i386/pr99108.C 
b/gcc/testsuite/g++.target/i386/pr99108.C
new file mode 100644
index 000..ad9409b8799
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr99108.C
@@ -0,0 +1,18 @@
+/* PR c++/99108 */
+/* { dg-do compile { target c++20 } } */
+/* { dg-require-ifunc "" }  */
+
+struct A {
+  void foo(auto);
+};
+void A::foo(auto)
+{
+  int f(void) __attribute__((target("default")));
+  int f(void) __attribute__((target("arch=atom")));
+  int b = f();
+}
+void bar(void)
+{
+  A c;
+  c.foo(7);
+}

Re: [PATCH] Handle ERROR_MARK in direct_abstract_declarator

[Jeff Law via Gcc-patches]

On 3/4/21 5:51 AM, Richard Biener wrote:
> The gcc.dg/noncompile/pr79758.c testcase prints
>
> pr79758.c:5:6: error: redefinition of 'fn1'
> 'error_mark' not supported by 
> direct_abstract_declarator)'/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/noncompile/pr79758.c:4:6:
>  note: previous definition of 'fn1' with type
>
> which shows a) re-entry of pp_printf via pp_unsupported_tree and b) a
> bogus diagnostic.  The following handles ERROR_MARK in
> direct_abstract_declarator, yielding in the better
>
> /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/noncompile/pr79758.c:5:6: 
> error: redefinition of 'fn1'
> /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/noncompile/pr79758.c:4:6: note: 
> previous definition of 'fn1' with type 'void()'
>
> but still maybe not perfect.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> OK for trunk?  GCC 10 doesn't exhibit this issue since it doesn't
> print the 'with type ...' part.
>
> 2021-03-04  Richard Biener  
>
> gcc/c-family/
>   * c-pretty-print.c (c_pretty_printer::direct_abstract_declarator):
>   Handle ERROR_MARK.
OK
jeff

Re: [PATCH] sim: drop dep on configure-gdb

[Jeff Law via Gcc-patches]

On 3/4/21 1:53 AM, Mike Frysinger via Gcc-patches wrote:
> I'm not entirely sure why this is here since the sim doesn't use
> anything from the gdb/ dir directly, and the commit that added it
> included a bunch more changes and doesn't seem to call out this
> dep specifically.
>
> ChangeLog:
>
>   * Makefile.def: Remove all-sim dependency on configure-gdb.
>   * Makefile.in: Regenerated.
OK.
jeff

Re: [PATCH] C++: target attribute - local decl

[Jason Merrill via Gcc-patches]

On 3/4/21 10:39 AM, Martin Liška wrote:

On 3/4/21 4:03 PM, Jason Merrill wrote:
Do you really need to register all these pairs?  I was expecting that 
you'd just look through DECL_LOCAL_DECL_ALIAS and then register the 
pair you end up with.  Local decls shouldn't need a cgraph node.


Well, doing that:


commit 662c486edafa467ec41091e84857d594eaf280a2
Author: Martin Liska 
Date:   Wed Mar 3 09:38:55 2021 +0100

     c++: support target attr for DECL_LOCAL_DECL_P fns
     gcc/cp/ChangeLog:
     PR c++/99108
     * call.c (get_function_version_dispatcher): Understand
     DECL_LOCAL_DECL_ALIAS.
     * decl.c (record_function_versions): New.
     (maybe_version_functions): Call record_function_versions
     for both declarations and DECL_LOCAL_DECL_ALIAS aliases.
     gcc/testsuite/ChangeLog:
     PR c++/99108
     * g++.target/i386/pr99108.C: New test.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 123f06b1f2b..117f1755191 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8467,6 +8467,10 @@ get_function_version_dispatcher (tree fn)
  {
    tree dispatcher_decl = NULL;

+  if (DECL_LOCAL_DECL_P (fn)
+  && DECL_LOCAL_DECL_ALIAS (fn) != NULL_TREE)
+    fn = DECL_LOCAL_DECL_ALIAS (fn);
+
    gcc_assert (TREE_CODE (fn) == FUNCTION_DECL
    && DECL_FUNCTION_VERSIONED (fn));

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1742e286d9f..a092539bfa0 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1115,6 +1115,14 @@ decls_match (tree newdecl, tree olddecl, bool 
record_versions /* = true */)

  bool
  maybe_version_functions (tree newdecl, tree olddecl, bool record)
  {
+  if (DECL_LOCAL_DECL_P (olddecl)
+  && DECL_LOCAL_DECL_ALIAS (olddecl) != NULL_TREE)
+    olddecl = DECL_LOCAL_DECL_ALIAS (olddecl);
+
+  if (DECL_LOCAL_DECL_P (newdecl)
+  && DECL_LOCAL_DECL_ALIAS (newdecl) != NULL_TREE)
+    newdecl = DECL_LOCAL_DECL_ALIAS (newdecl);
+
    if (!targetm.target_option.function_versions (newdecl, olddecl))
  return false;

The compilation then fails:
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr99108.C: In 
member function ‘void A::foo(auto:2)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr99108.C:12:13: 
error: call of overloaded ‘f()’ is ambiguous

    12 |   int b = f();
   | ^
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr99108.C:10:7: 
note: candidate: ‘int f()’

    10 |   int f(void) __attribute__((target("default")));
   |   ^
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr99108.C:11:7: 
note: candidate: ‘int f()’

    11 |   int f(void) __attribute__((target("arch=atom")));
   |   ^

likely because DECL_FUNCTION_VERSIONED is missing for the local decls.


Sure, I guess you do need to set that flag for the local decls, but that 
should be all.


Jason

Re: [PATCH] C++: target attribute - local decl

[Martin Liška]

On 3/4/21 4:03 PM, Jason Merrill wrote:

Do you really need to register all these pairs?  I was expecting that you'd 
just look through DECL_LOCAL_DECL_ALIAS and then register the pair you end up 
with.  Local decls shouldn't need a cgraph node.


Well, doing that:


commit 662c486edafa467ec41091e84857d594eaf280a2
Author: Martin Liska 
Date:   Wed Mar 3 09:38:55 2021 +0100

c++: support target attr for DECL_LOCAL_DECL_P fns

gcc/cp/ChangeLog:

PR c++/99108

* call.c (get_function_version_dispatcher): Understand
DECL_LOCAL_DECL_ALIAS.
* decl.c (record_function_versions): New.
(maybe_version_functions): Call record_function_versions
for both declarations and DECL_LOCAL_DECL_ALIAS aliases.

gcc/testsuite/ChangeLog:

PR c++/99108

* g++.target/i386/pr99108.C: New test.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 123f06b1f2b..117f1755191 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8467,6 +8467,10 @@ get_function_version_dispatcher (tree fn)
 {
   tree dispatcher_decl = NULL;
 
+  if (DECL_LOCAL_DECL_P (fn)

+  && DECL_LOCAL_DECL_ALIAS (fn) != NULL_TREE)
+fn = DECL_LOCAL_DECL_ALIAS (fn);
+
   gcc_assert (TREE_CODE (fn) == FUNCTION_DECL
  && DECL_FUNCTION_VERSIONED (fn));
 
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c

index 1742e286d9f..a092539bfa0 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1115,6 +1115,14 @@ decls_match (tree newdecl, tree olddecl, bool 
record_versions /* = true */)
 bool
 maybe_version_functions (tree newdecl, tree olddecl, bool record)
 {
+  if (DECL_LOCAL_DECL_P (olddecl)
+  && DECL_LOCAL_DECL_ALIAS (olddecl) != NULL_TREE)
+olddecl = DECL_LOCAL_DECL_ALIAS (olddecl);
+
+  if (DECL_LOCAL_DECL_P (newdecl)
+  && DECL_LOCAL_DECL_ALIAS (newdecl) != NULL_TREE)
+newdecl = DECL_LOCAL_DECL_ALIAS (newdecl);
+
   if (!targetm.target_option.function_versions (newdecl, olddecl))
 return false;

The compilation then fails:
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr99108.C: In member 
function ‘void A::foo(auto:2)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr99108.C:12:13: 
error: call of overloaded ‘f()’ is ambiguous
   12 |   int b = f();
  | ^
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr99108.C:10:7: 
note: candidate: ‘int f()’
   10 |   int f(void) __attribute__((target("default")));
  |   ^
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr99108.C:11:7: 
note: candidate: ‘int f()’
   11 |   int f(void) __attribute__((target("arch=atom")));
  |   ^

likely because DECL_FUNCTION_VERSIONED is missing for the local decls.

Martin

Re: [PATCH] profiling: fix streaming of TOPN counters

[Martin Liška]

On 3/4/21 1:50 PM, Jan Hubicka wrote:

  .../gcc.dg/tree-prof/indir-call-prof-malloc.c |  2 +-
  gcc/testsuite/gcc.dg/tree-prof/pr97461.c  |  2 +-
  libgcc/libgcov-driver.c   | 56 ---
  3 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c 
b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
index 454e224c95f..7bda4aedfc8 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -ldl" } */
+/* { dg-options "-O2 -ldl -fprofile-correction" } */
  
  #define _GNU_SOURCE

  #include 
diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr97461.c 
b/gcc/testsuite/gcc.dg/tree-prof/pr97461.c
index 213fac9af04..f684be4d80f 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/pr97461.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr97461.c
@@ -1,5 +1,5 @@
  /* PR gcov-profile/97461 */
-/* { dg-options "-O2 -ldl" } */
+/* { dg-options "-O2 -ldl -fprofile-correction" } */
  
  #define _GNU_SOURCE
  
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c

index 91462350132..d2e60a5a6df 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -42,6 +42,10 @@ void __gcov_init (struct gcov_info *p __attribute__ 
((unused))) {}
  #include 
  #endif
  
+#if HAVE_SYS_MMAN_H

+#include 
+#endif
+
  #ifdef L_gcov
  
  /* A utility function for outputting errors.  */

@@ -334,30 +338,66 @@ read_error:
return -1;
  }
  
+#define MAX(X,Y) ((X) > (Y) ? (X) : (Y))

+
  /* Store all TOP N counters where each has a dynamic length.  */
  
  static void

-write_top_counters (const struct gcov_ctr_info *ci_ptr,
-   unsigned t_ix,
-   gcov_unsigned_t n_counts)
+write_topn_counters (const struct gcov_ctr_info *ci_ptr,
+unsigned t_ix,
+gcov_unsigned_t n_counts)
  {
unsigned counters = n_counts / GCOV_TOPN_MEM_COUNTERS;
gcc_assert (n_counts % GCOV_TOPN_MEM_COUNTERS == 0);
+
+  /* It can happen in a multi-threaded environment that number of counters is
+ different from the size of the corresponding linked lists.  */
+#define LIST_SIZE_MIN_LENGTH 4 * 1024
+
+  static unsigned *list_sizes = NULL;
+  static unsigned list_size_length = 0;
+
+  if (list_sizes == NULL || counters > list_size_length)
+{
+  list_size_length = MAX (LIST_SIZE_MIN_LENGTH, counters);
+#if HAVE_SYS_MMAN_H
+  list_sizes = (unsigned *)mmap (NULL, list_size_length * sizeof 
(unsigned),
+PROT_READ | PROT_WRITE,
+MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+#endif
+
+  /* Malloc fallback.  */
+  if (list_sizes == NULL)
+   list_sizes = (unsigned *)xmalloc (list_size_length * sizeof (unsigned));

I see, you switched to allocating buffer permanently. This also works.
Given that you do not deallocate the memory, I think you want to
allocate list_size_length*2 so we do not end up taking O(mn) memory
where n is the largest number of counters in a file and m is number of
sections with counters.


Yeah, I used there a minimal amount of memory that should fit all normal 
functions.
I updated that to 2 * counters.



Can you please unify the mmap code in list allocation and here, so there
is only one place in libgcov Windows folks will need to update?

Otherwise the patch looks OK.


Thanks, pushed.
Martin


Honza

Re: [PATCH] C++: target attribute - local decl

[Jason Merrill via Gcc-patches]

On 3/4/21 3:19 AM, Martin Liška wrote:

On 3/2/21 6:57 PM, Jason Merrill wrote:

On 3/2/21 5:34 AM, Martin Liška wrote:

On 3/1/21 8:58 PM, Jason Merrill wrote:

On 3/1/21 11:59 AM, Martin Liška wrote:

On 3/1/21 5:36 PM, Jason Merrill wrote:

On 3/1/21 7:43 AM, Martin Liška wrote:

On 2/22/21 11:53 PM, Jason Merrill wrote:
The problem seems to be with the handling of local decls.  If 
DECL_LOCAL_DECL_P, you need to look at DECL_LOCAL_DECL_ALIAS to 
find the namespace-scope decl.  But then if there is no 
preceding namespace-scope declaration, the new decl created by 
push_local_extern_decl_alias doesn't have a cgraph node, either. 
I guess maybe_function_versions 
also needs to look through DECL_LOCAL_DECL_ALIAS.


Ah, I see. Are you sure about the name 'maybe_function_versions'? 
I can't find it.


Ah, it's maybe_version_functions, sorry.


Thanks, I see the function now.
So about your guess:

I guess maybe_function_versions also needs to look through 
DECL_LOCAL_DECL_ALIAS.


Do you mean maybe_version_functions's argument 'record' should 
depend on DECL_LOCAL_DECL_ALIAS of newdecl/oldddecl
(if present)? Or that DECL_FUNCTION_VERSIONED should be set for 
DECL_LOCAL_DECL_ALIASes of the newdecl/olddecl

function declarations?


The latter.


I see, but will not help us. Problem is that
#2  0x015d8899 in ix86_get_function_versions_dispatcher 
(decl=0x77755000) at 
/home/marxin/Programming/gcc/gcc/config/i386/i386-features.c:2862


is called for a declaration for which

Breakpoint 5, maybe_version_functions (newdecl=0x77755000 f>, olddecl=, 
record=false) at /home/marxin/Programming/gcc/gcc/cp/decl.c:1118


is called with record=false. So that cgraph_node is not created for it.

Or is a possible solution that get_function_version_dispatcher should 
look through the DECL_LOCAL_DECL_ALIAS?


Yes, I was thinking both that function and maybe_version_functions.

Jason



All right, the following patch fixes that.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.



+  record_function_versions (olddecl, olddecl, record);
+  if (DECL_LOCAL_DECL_P (olddecl)
+  && DECL_LOCAL_DECL_ALIAS (olddecl) != NULL_TREE)
+record_function_versions (olddecl, DECL_LOCAL_DECL_ALIAS (olddecl), true);
 
+  record_function_versions (olddecl, newdecl, record);

+  if (DECL_LOCAL_DECL_P (newdecl)
+  && DECL_LOCAL_DECL_ALIAS (newdecl) != NULL_TREE)
+record_function_versions (olddecl, DECL_LOCAL_DECL_ALIAS (newdecl), true);


Do you really need to register all these pairs?  I was expecting that 
you'd just look through DECL_LOCAL_DECL_ALIAS and then register the pair 
you end up with.  Local decls shouldn't need a cgraph node.


Jason

Re: [PATCH] aarch64: Add missing error_mark_node check [PR99381]

[Richard Sandiford via Gcc-patches]

Alex Coplan  writes:
> Hi!
>
> As the PR shows, we were missing a check in
> function_resolver::require_vector_type to see if the argument type was already
> invalid. This was causing us to attempt to emit a diagnostic and subsequently
> ICE in print_type. Fixed thusly.
>
> Bootstrapped and regtested on aarch64-linux-gnu. OK for trunk?
>
> Thanks,
> Alex
>
> ---
>
> gcc/ChangeLog:
>
>   PR target/99381
>   * config/aarch64/aarch64-sve-builtins.cc
>   (function_resolver::require_vector_type): Handle error_mark_node.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/pr99381.c: New test.

OK, thanks.  It would be good to backport to GCC 10 too if possible
(pre-approved).

Richard

Re: [PATCH] middle-end/97855 - fix diagnostic with default pretty printer

[David Malcolm via Gcc-patches]

On Thu, 2021-03-04 at 09:20 -0500, David Malcolm via Gcc-patches wrote:
> On Thu, 2021-03-04 at 09:39 +0100, Richard Biener wrote:
> > On Wed, 3 Mar 2021, Richard Biener wrote:
> > 
> > > On Wed, 3 Mar 2021, David Malcolm wrote:
> > > 
> > > > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > > > > On Tue, 2 Mar 2021, Martin Sebor wrote:
> > > > > 
> > > > > > On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 3/1/21 1:39 AM, Richard Biener wrote:
> > > > > > > > The default diagnostic tree printer relies on
> > > > > > > > dump_generic_node
> > > > > > > > which
> > > > > > > > for some reason manages to clobber the diagnostic
> > > > > > > > pretty-
> > > > > > > > printer state
> > > > > > > > so we see garbled diagnostics like
> > > > > > > > 
> > > > > > > > /home/rguenther/src/trunk/gcc/calls.c: In function
> > > > > > > > 'expand_call':
> > > > > > > > D.6750.coeffs[0]'/home/rguenther/src/trunk/gcc/dojump.c
> > > > > > > > :1
> > > > > > > > 18:28:
> > > > > > > > warning:
> > > > > > > > may be used uninitialized in this function [-Wmaybe-
> > > > > > > > uninitialized]
> > > > > > > > 
> > > > > > > > when the diagnostic is emitted by the LTO fronted.  The
> > > > > > > > following
> > > > > > > > approach using a temporary pretty-printer for the
> > > > > > > > dump_generic_node
> > > > > > > > call fixes this for some unknown reason and we issue
> > > > > > > > 
> > > > > > > > /home/rguenther/src/trunk/gcc/calls.c: In function
> > > > > > > > 'expand_call':
> > > > > > > > /home/rguenther/src/trunk/gcc/dojump.c:118:28: warning:
> > > > > > > > 'MEM[(struct
> > > > > > > > poly_int *)].D.6750.coeffs[0]' may be used
> > > > > > > > uninitialized
> > > > > > > > in this
> > > > > > > > function [-Wmaybe-uninitialized]
> > > > > > > > 
> > > > > > > > [LTO] Bootstrapped and tested on x86_64-unknown-linux-
> > > > > > > > gnu, OK
> > > > > > > > for trunk?
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Richard.
> > > > > > > > 
> > > > > > > > 2021-02-26  Richard Biener  
> > > > > > > > 
> > > > > > > >  PR middle-end/97855
> > > > > > > >  * tree-diagnostic.c (default_tree_printer): Use a
> > > > > > > > temporary
> > > > > > > >  pretty-printer when formatting a tree via
> > > > > > > > dump_generic_node.
> > > > > > > It'd be good to know why this helps, but I trust your
> > > > > > > judgment
> > > > > > > that this
> > > > > > > is an improvement.
> > > > > > 
> > > > > > I don't know if it's related but pr98492 tracks a problem
> > > > > > in
> > > > > > the
> > > > > > C++
> > > > > > front end caused by reinitializing the pretty printer in a
> > > > > > number
> > > > > > of
> > > > > > functions in cp/error.c.  When one of these functions is
> > > > > > called
> > > > > > while
> > > > > > the pretty printer is formatting something, the effect of
> > > > > > the reinitialization is to drop the already formatted
> > > > > > contents
> > > > > > of the printer's buffer.
> > > > > > 
> > > > > > IIRC, I tripped over this when working on the MEM_REF
> > > > > > formatting
> > > > > > improvement for -Wuninitialized.
> > > > > 
> > > > > I've poked quite a bit with breakpoints on suspicious pretty-
> > > > > printer
> > > > > functions and watch points on the pp state but found nothing
> > > > > in
> > > > > the
> > > > > case I was looking at (curiously also -Wuninitialized).  But
> > > > > I
> > > > > also
> > > > > wasn't able to understand why the caller should work at all. 
> > > > > And
> > > > > yes, the C/C++ tree printers also simply format to the passed
> > > > > pretty-printer...
> > > > > 
> > > > > Hoping that David could shed some light on how this should
> > > > > play
> > > > > together.
> > > > 
> > > > This looks very much like the issue I ran into in
> > > > c46d057f55748520e819dcd8e04bca71be9902b2 (and, in retrospect,
> > > > that
> > > > commit may have just been papering over the problem).
> > > > 
> > > > The issue there was that pp_printf is not reentrant - if a
> > > > handler for
> > > > a pp_printf format code ends up making a nested call to
> > > > pp_printf, I
> > > > got behavior that looks like what you're seeing.
> > > > 
> > > > That said, I've been poring over the output in PR middle-
> > > > end/97855 and
> > > > comparing it to the various pretty-printer usage in the tree,
> > > > and
> > > > I'm
> > > > not seeing anywhere where a pp_printf seems to be used when
> > > > generating:
> > > >   MEM[(struct poly_int *) + 8B].D.6750.coeffs[0]
> > > 
> > > I think it's the D.6750 which is printed via
> > > 
> > >   else if (TREE_CODE (node) == DEBUG_EXPR_DECL)
> > >     {
> > >   if (flags & TDF_NOUID)
> > >     pp_string (pp, "D#");
> > >   else
> > >     pp_printf (pp, "D#%i", DEBUG_TEMP_UID (node));
> > > 
> > > because this is a DECL_DEBUG_EXPR.  One could experiment with
> > > avoiding pp_printf in dump_decl_name.
> > > 
> > > > Is there a minimal 

Re: [PATCH] middle-end/97855 - fix diagnostic with default pretty printer

[David Malcolm via Gcc-patches]

On Thu, 2021-03-04 at 09:39 +0100, Richard Biener wrote:
> On Wed, 3 Mar 2021, Richard Biener wrote:
> 
> > On Wed, 3 Mar 2021, David Malcolm wrote:
> > 
> > > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > > > On Tue, 2 Mar 2021, Martin Sebor wrote:
> > > > 
> > > > > On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> > > > > > 
> > > > > > 
> > > > > > On 3/1/21 1:39 AM, Richard Biener wrote:
> > > > > > > The default diagnostic tree printer relies on
> > > > > > > dump_generic_node
> > > > > > > which
> > > > > > > for some reason manages to clobber the diagnostic pretty-
> > > > > > > printer state
> > > > > > > so we see garbled diagnostics like
> > > > > > > 
> > > > > > > /home/rguenther/src/trunk/gcc/calls.c: In function
> > > > > > > 'expand_call':
> > > > > > > D.6750.coeffs[0]'/home/rguenther/src/trunk/gcc/dojump.c:1
> > > > > > > 18:28:
> > > > > > > warning:
> > > > > > > may be used uninitialized in this function [-Wmaybe-
> > > > > > > uninitialized]
> > > > > > > 
> > > > > > > when the diagnostic is emitted by the LTO fronted.  The
> > > > > > > following
> > > > > > > approach using a temporary pretty-printer for the
> > > > > > > dump_generic_node
> > > > > > > call fixes this for some unknown reason and we issue
> > > > > > > 
> > > > > > > /home/rguenther/src/trunk/gcc/calls.c: In function
> > > > > > > 'expand_call':
> > > > > > > /home/rguenther/src/trunk/gcc/dojump.c:118:28: warning:
> > > > > > > 'MEM[(struct
> > > > > > > poly_int *)].D.6750.coeffs[0]' may be used
> > > > > > > uninitialized
> > > > > > > in this
> > > > > > > function [-Wmaybe-uninitialized]
> > > > > > > 
> > > > > > > [LTO] Bootstrapped and tested on x86_64-unknown-linux-
> > > > > > > gnu, OK
> > > > > > > for trunk?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Richard.
> > > > > > > 
> > > > > > > 2021-02-26  Richard Biener  
> > > > > > > 
> > > > > > >  PR middle-end/97855
> > > > > > >  * tree-diagnostic.c (default_tree_printer): Use a
> > > > > > > temporary
> > > > > > >  pretty-printer when formatting a tree via
> > > > > > > dump_generic_node.
> > > > > > It'd be good to know why this helps, but I trust your
> > > > > > judgment
> > > > > > that this
> > > > > > is an improvement.
> > > > > 
> > > > > I don't know if it's related but pr98492 tracks a problem in
> > > > > the
> > > > > C++
> > > > > front end caused by reinitializing the pretty printer in a
> > > > > number
> > > > > of
> > > > > functions in cp/error.c.  When one of these functions is
> > > > > called
> > > > > while
> > > > > the pretty printer is formatting something, the effect of
> > > > > the reinitialization is to drop the already formatted
> > > > > contents
> > > > > of the printer's buffer.
> > > > > 
> > > > > IIRC, I tripped over this when working on the MEM_REF
> > > > > formatting
> > > > > improvement for -Wuninitialized.
> > > > 
> > > > I've poked quite a bit with breakpoints on suspicious pretty-
> > > > printer
> > > > functions and watch points on the pp state but found nothing in
> > > > the
> > > > case I was looking at (curiously also -Wuninitialized).  But I
> > > > also
> > > > wasn't able to understand why the caller should work at all. 
> > > > And
> > > > yes, the C/C++ tree printers also simply format to the passed
> > > > pretty-printer...
> > > > 
> > > > Hoping that David could shed some light on how this should play
> > > > together.
> > > 
> > > This looks very much like the issue I ran into in
> > > c46d057f55748520e819dcd8e04bca71be9902b2 (and, in retrospect,
> > > that
> > > commit may have just been papering over the problem).
> > > 
> > > The issue there was that pp_printf is not reentrant - if a
> > > handler for
> > > a pp_printf format code ends up making a nested call to
> > > pp_printf, I
> > > got behavior that looks like what you're seeing.
> > > 
> > > That said, I've been poring over the output in PR middle-
> > > end/97855 and
> > > comparing it to the various pretty-printer usage in the tree, and
> > > I'm
> > > not seeing anywhere where a pp_printf seems to be used when
> > > generating:
> > >   MEM[(struct poly_int *) + 8B].D.6750.coeffs[0]
> > 
> > I think it's the D.6750 which is printed via
> > 
> >   else if (TREE_CODE (node) == DEBUG_EXPR_DECL)
> >     {
> >   if (flags & TDF_NOUID)
> >     pp_string (pp, "D#");
> >   else
> >     pp_printf (pp, "D#%i", DEBUG_TEMP_UID (node));
> > 
> > because this is a DECL_DEBUG_EXPR.  One could experiment with
> > avoiding pp_printf in dump_decl_name.
> > 
> > > Is there a minimal reproducer (or a .i file?)
> > 
> > No, you need to do a LTO bootstrap, repeat the link step of
> > for example cc1 with -v -save-temps and pick an ltrans invocation
> > that exhibits the issue ...
> > 
> > I can poke at the above tomorrow again.  I suppose we could
> > also add some checking-assert into the pp_printf code at
> > the problematic place (or is any recursion bogus?) to catch
> > the case 

[PATCH v3] IBM Z: Fix usage of "f" constraint with long doubles

[Ilya Leoshkevich via Gcc-patches]

v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563799.html
v1 -> v2:
- Handle constraint modifiers, use AR constraint instead of R, add
  testcases for & and %.

v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html
v2 -> v3:
- The main prereq is now committed:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566237.html
- Dropped long-double-asm-abi.c test, because its prereq is not
  approved (yet):
  https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566218.html
- Removed superfluous constraint pointer increment.



After switching the s390 backend to store long doubles in vector
registers, "f" constraint broke when used with the former: long doubles
correspond to TFmode, which in combination with "f" corresponds to
hard regs %v0-%v15, however, asm users expect a %f0-%f15 pair.

Fix by using TARGET_MD_ASM_ADJUST hook to convert TFmode values to
FPRX2mode and back.

gcc/ChangeLog:

2020-12-14  Ilya Leoshkevich  

* config/s390/s390.c (f_constraint_p): New function.
(s390_md_asm_adjust): Implement TARGET_MD_ASM_ADJUST.
(TARGET_MD_ASM_ADJUST): Likewise.
* config/s390/vector.md (fprx2_to_tf): Rename from *fprx2_to_tf,
add memory alternative.
(tf_to_fprx2): New pattern.

gcc/testsuite/ChangeLog:

2020-12-14  Ilya Leoshkevich  

* gcc.target/s390/vector/long-double-asm-commutative.c: New
test.
* gcc.target/s390/vector/long-double-asm-earlyclobber.c: New
test.
* gcc.target/s390/vector/long-double-asm-in-out.c: New test.
* gcc.target/s390/vector/long-double-asm-inout.c: New test.
* gcc.target/s390/vector/long-double-asm-matching.c: New test.
* gcc.target/s390/vector/long-double-asm-regmem.c: New test.
* gcc.target/s390/vector/long-double-volatile-from-i64.c: New
test.
---
 gcc/config/s390/s390.c| 86 +++
 .../s390/vector/long-double-asm-commutative.c | 16 
 .../vector/long-double-asm-earlyclobber.c | 17 
 .../s390/vector/long-double-asm-in-out.c  | 14 +++
 .../s390/vector/long-double-asm-inout.c   | 14 +++
 .../s390/vector/long-double-asm-matching.c| 13 +++
 .../s390/vector/long-double-asm-regmem.c  |  8 ++
 .../vector/long-double-volatile-from-i64.c| 22 +
 8 files changed, 190 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/s390/vector/long-double-asm-commutative.c
 create mode 100644 
gcc/testsuite/gcc.target/s390/vector/long-double-asm-earlyclobber.c
 create mode 100644 
gcc/testsuite/gcc.target/s390/vector/long-double-asm-in-out.c
 create mode 100644 gcc/testsuite/gcc.target/s390/vector/long-double-asm-inout.c
 create mode 100644 
gcc/testsuite/gcc.target/s390/vector/long-double-asm-matching.c
 create mode 100644 
gcc/testsuite/gcc.target/s390/vector/long-double-asm-regmem.c
 create mode 100644 
gcc/testsuite/gcc.target/s390/vector/long-double-volatile-from-i64.c

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index f3d0d1ba596..68dc3c58c1b 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -16698,6 +16698,89 @@ s390_shift_truncation_mask (machine_mode mode)
   return mode == DImode || mode == SImode ? 63 : 0;
 }
 
+/* Return TRUE iff CONSTRAINT is an "f" constraint, possibly with additional
+   modifiers.  */
+
+static bool
+f_constraint_p (const char *constraint)
+{
+  for (size_t i = 0, c_len = strlen (constraint); i < c_len;
+   i += CONSTRAINT_LEN (constraint[i], constraint + i))
+{
+  if (constraint[i] == 'f')
+   return true;
+}
+  return false;
+}
+
+/* Implement TARGET_MD_ASM_ADJUST hook in order to fix up "f"
+   constraints when long doubles are stored in vector registers.  */
+
+static rtx_insn *
+s390_md_asm_adjust (vec , vec ,
+   vec _modes,
+   vec , vec & /*clobbers*/,
+   HARD_REG_SET & /*clobbered_regs*/)
+{
+  if (!TARGET_VXE)
+/* Long doubles are stored in FPR pairs - nothing to do.  */
+return NULL;
+
+  rtx_insn *after_md_seq = NULL, *after_md_end = NULL;
+
+  unsigned ninputs = inputs.length ();
+  unsigned noutputs = outputs.length ();
+  for (unsigned i = 0; i < noutputs; i++)
+{
+  if (GET_MODE (outputs[i]) != TFmode)
+   /* Not a long double - nothing to do.  */
+   continue;
+  const char *constraint = constraints[i];
+  bool allows_mem, allows_reg, is_inout;
+  bool ok = parse_output_constraint (, i, ninputs, noutputs,
+_mem, _reg, _inout);
+  gcc_assert (ok);
+  if (!f_constraint_p (constraint))
+   /* Long double with a constraint other than "=f" - nothing to do.  */
+   continue;
+  gcc_assert (allows_reg);
+  gcc_assert (!is_inout);
+  /* Copy output value from a FPR pair into a vector register.  */
+  rtx fprx2 = gen_reg_rtx (FPRX2mode);
+  push_to_sequence2 (after_md_seq, after_md_end);
+  emit_insn 

[PATCH] aarch64: Add missing error_mark_node check [PR99381]

[Alex Coplan via Gcc-patches]

Hi!

As the PR shows, we were missing a check in
function_resolver::require_vector_type to see if the argument type was already
invalid. This was causing us to attempt to emit a diagnostic and subsequently
ICE in print_type. Fixed thusly.

Bootstrapped and regtested on aarch64-linux-gnu. OK for trunk?

Thanks,
Alex

---

gcc/ChangeLog:

PR target/99381
* config/aarch64/aarch64-sve-builtins.cc
(function_resolver::require_vector_type): Handle error_mark_node.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr99381.c: New test.
diff --git a/gcc/config/aarch64/aarch64-sve-builtins.cc 
b/gcc/config/aarch64/aarch64-sve-builtins.cc
index 6270b51fbf4..25612d2ea52 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins.cc
+++ b/gcc/config/aarch64/aarch64-sve-builtins.cc
@@ -1467,6 +1467,9 @@ function_resolver::require_vector_type (unsigned int 
argno,
 {
   tree expected = acle_vector_types[0][type];
   tree actual = get_argument_type (argno);
+  if (actual == error_mark_node)
+return false;
+
   if (!matches_type_p (expected, actual))
 {
   error_at (location, "passing %qT to argument %d of %qE, which"
diff --git a/gcc/testsuite/gcc.target/aarch64/pr99381.c 
b/gcc/testsuite/gcc.target/aarch64/pr99381.c
new file mode 100644
index 000..8b4c5b82f68
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr99381.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv8-a" } */
+/* PR99381: we shouldn't ICE if the user forgets -march=armv8.2-a+sve. */
+
+#include 
+_Bool a;
+int main()
+{
+  a = svaddv(svptrue_b8(), svdup_s8(0)); /* { dg-error "ACLE function 
'svptrue_b8' requires ISA extension 'sve'" } */
+}

c++: Post-pending redesign cleanup [PR 99170]

[Nathan Sidwell]

With pending entities reimplemented, the remaining use of uintset can 
just use a regular hash map -- I only used a uintset because it was 
there. So one adhoc hash-table/vector structure goes away.


PR c++/99170
gcc/cp/
* module.cc (class uintset): Delete.
(typedef attached_map_t): A hash map.
(attached_table): Use attached_map_t.  Adjust uses ...
(trees_out::decl_value, trees_in::decl_value): ... here ...
(trees_out::key_mergeable): ... here ...
(trees_in::key_mergeable): ... here ...
(maybe_attach_decl): ... here ...
(direct_import): ... and here.

--
Nathan Sidwell
diff --git c/gcc/cp/module.cc w/gcc/cp/module.cc
index 3ee71e5211f..31bbf9776dd 100644
--- c/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -2697,167 +2697,11 @@ pending_map_t *pending_table;
completed.  */
 vec *post_load_decls;
 
-/* Values keyed to some unsigned integer.  This is not GTY'd, so if
-   T is tree they must be reachable via some other path.  */
-
-template
-class uintset {
-public:
-  unsigned key;  /* Entity index of the other entity.  */
-
-  /* Payload.  */
-  unsigned allocp2 : 5;  /* log(2) allocated pending  */
-  unsigned num : 27;/* Number of pending.  */
-
-  /* Trailing array of values.   */
-  T values[1];
-
-public:
-  /* Even with ctors, we're very pod-like.  */
-  uintset (unsigned uid)
-: key (uid), allocp2 (0), num (0)
-  {
-  }
-  /* Copy constructor, which is exciting because of the trailing
- array.  */
-  uintset (const uintset *from)
-  {
-size_t size = (offsetof (uintset, values)
-		   + sizeof (uintset::values) * from->num);
-memmove (this, from, size);
-if (from->num)
-  allocp2++;
-  }
-
-public:
-  struct traits : delete_ptr_hash {
-typedef unsigned compare_type;
-typedef typename delete_ptr_hash::value_type value_type;
-
-/* Hash and equality for compare_type.  */
-inline static hashval_t hash (const compare_type k)
-{
-  return hashval_t (k);
-}
-inline static hashval_t hash (const value_type v)
-{
-  return hash (v->key);
-}
-
-inline static bool equal (const value_type v, const compare_type k)
-{
-  return v->key == k;
-}
-  };
-
-public:
-  class hash : public hash_table 
-  {
-typedef typename traits::compare_type key_t;
-typedef hash_table parent;
-
-  public:
-hash (size_t size)
-  : parent (size)
-{
-}
-~hash ()
-{
-}
-
-  private:
-uintset **find_slot (key_t key, insert_option insert)
-{
-  return this->find_slot_with_hash (key, traits::hash (key), insert);
-}
-
-  public:
-uintset *get (key_t key, bool extract = false);
-bool add (key_t key, T value);
-uintset *create (key_t key, unsigned num, T init = 0);
-  };
-};
-
-/* Add VALUE to KEY's uintset, creating it if necessary.  Returns true
-   if we created the uintset.  */
-
-template
-bool
-uintset::hash::add (typename uintset::hash::key_t key, T value)
-{
-  uintset **slot = this->find_slot (key, INSERT);
-  uintset *set = *slot;
-  bool is_new = !set;
-
-  if (is_new || set->num == (1u << set->allocp2))
-{
-  if (set)
-	{
-	  unsigned n = set->num * 2;
-	  size_t new_size = (offsetof (uintset, values)
-			 + sizeof (uintset (0u).values) * n);
-	  uintset *new_set = new (::operator new (new_size)) uintset (set);
-	  delete set;
-	  set = new_set;
-	}
-  else
-	set = new (::operator new (sizeof (*set))) uintset (key);
-  *slot = set;
-}
-
-  set->values[set->num++] = value;
-
-  return is_new;
-}
-
-template
-uintset *
-uintset::hash::create (typename uintset::hash::key_t key, unsigned num,
-			  T init)
-{
-  unsigned p2alloc = 0;
-  for (unsigned v = num; v != 1; v = (v >> 1) | (v & 1))
-p2alloc++;
-
-  size_t new_size = (offsetof (uintset, values)
-		 + (sizeof (uintset (0u).values) << p2alloc));
-  uintset *set = new (::operator new (new_size)) uintset (key);
-  set->allocp2 = p2alloc;
-  set->num = num;
-  while (num--)
-set->values[num] = init;
-
-  uintset **slot = this->find_slot (key, INSERT);
-  gcc_checking_assert (!*slot);
-  *slot = set;
-
-  return set;
-}
-
-/* Locate KEY's uintset, potentially removing it from the hash table  */
-
-template
-uintset *
-uintset::hash::get (typename uintset::hash::key_t key, bool extract)
-{
-  uintset *res = NULL;
-
-  if (uintset **slot = this->find_slot (key, NO_INSERT))
-{
-  res = *slot;
-  if (extract)
-	/* We need to remove the pendset without deleting it. */
-	traits::mark_deleted (*slot);
-}
-
-  return res;
-}
-
 /* Some entities are attached to another entitity for ODR purposes.
For example, at namespace scope, 'inline auto var = []{};', that
lambda is attached to 'var', and follows its ODRness.  */
-typedef uintset attachset;
-static attachset::hash *attached_table;
+typedef hash_map> attached_map_t;
+static attached_map_t *attached_table;
 
 

Re: [PATCH] c++: Fix up [[nodiscard]] on ctors on targetm.cxx.cdtor_returns_this targets [PR99362]

[Jason Merrill via Gcc-patches]

On 3/4/21 4:53 AM, Jakub Jelinek wrote:

Hi!

In the P1771R1 changes JeanHeyd reverted part of Alex' PR88146 fix,
but that seems to be incorrect to me.
Where P1771R1 suggests warnings for [[nodiscard]] on constructors is
handled in a different place - in particular the TARGET_EXPR handling
of convert_to_void.  When we have CALL_EXPR of a ctor, on most arches
that call has void return type and so returns early, and on arm where
the ctor returns the this pointer it is undesirable to warn as it warns
about all ctor calls, not just the ones where it should warn.

The P1771R1 changes added a test for this, but as it was given *.c
extension rather than *.C, the test was never run and so this didn't get
spotted immediately.  The test also had a bug, (?n) can't be used
in dg-warning/dg-error because those are implemented by prepending
some regexp before the user provided one and (?n) must come at the start
of the regexp.  Furthermore, while -ftrack-macro-expansion=0 is useful
in one nodiscard test which uses macros, I don't see how it would be
relevant to all the other cpp2a/nodiscard* tests which don't use any
macros.

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


OK.


2021-03-03  Jakub Jelinek  

PR c++/88146
PR c++/99362
gcc/cp/
* cvt.c (convert_to_void): Revert 2019-10-17 changes.  Clarify
comment.
gcc/testsuite/
* g++.dg/cpp2a/nodiscard-constructor.c: Renamed to ...
* g++.dg/cpp2a/nodiscard-constructor1.C: ... this.  Remove
-ftrack-macro-expansion=0 from dg-options.  Don't use (?n) in
dg-warning regexps, instead replace .* with \[^\n\r]*.
* g++.dg/cpp2a/nodiscard-constructor2.C: New test.
* g++.dg/cpp2a/nodiscard-reason-only-one.C: Remove
-ftrack-macro-expansion=0 from dg-options.
* g++.dg/cpp2a/nodiscard-reason-nonstring.C: Likewise.
* g++.dg/cpp2a/nodiscard-once.C: Likewise.

--- gcc/cp/cvt.c.jj 2021-01-26 08:57:46.469172105 +0100
+++ gcc/cp/cvt.c2021-03-03 20:22:35.849086890 +0100
@@ -1231,12 +1231,14 @@ convert_to_void (tree expr, impl_conv_vo
  case CALL_EXPR:   /* We have a special meaning for volatile void fn().  */
/* cdtors may return this or void, depending on
 targetm.cxx.cdtor_returns_this, but this shouldn't affect our
-decisions here: neither nodiscard warnings (nodiscard cdtors
-are nonsensical), nor should any constexpr or template
-instantiations be affected by an ABI property that is, or at
-least ought to be transparent to the language.  */
+decisions here: neither nodiscard warnings (nodiscard dtors
+are nonsensical and ctors have a different behavior with that
+attribute that is handled in the TARGET_EXPR case), nor should
+any constexpr or template instantiations be affected by an ABI
+property that is, or at least ought to be transparent to the
+language.  */
if (tree fn = cp_get_callee_fndecl_nofold (expr))
-   if (DECL_DESTRUCTOR_P (fn))
+   if (DECL_CONSTRUCTOR_P (fn) || DECL_DESTRUCTOR_P (fn))
  return expr;
  
if (complain & tf_warning)

--- gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor.c.jj   2020-07-28 
15:39:10.008756228 +0200
+++ gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor.c  2021-03-03 
20:28:46.095046953 +0100
@@ -1,13 +0,0 @@
-/* nodiscard attribute tests  */
-/* { dg-do compile { target c++20 } } */
-/* { dg-options "-O -ftrack-macro-expansion=0" } */
-
-struct A { [[nodiscard("bad constructor")]] A() {} };
-struct B { [[nodiscard]] B() {} };
-
-void
-test (void)
-{
-  A{}; /* { dg-warning "(?n)nodiscard.*bad constructor" } */
-  B{}; /* { dg-warning "(?n)nodiscard" } */
-}
--- gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor1.C.jj  2021-03-03 
20:28:39.364120391 +0100
+++ gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor1.C 2021-03-03 
20:37:53.186077373 +0100
@@ -0,0 +1,13 @@
+/* nodiscard attribute tests  */
+/* { dg-do compile { target c++20 } } */
+/* { dg-options "-O" } */
+
+struct A { [[nodiscard("bad constructor")]] A() {} };
+struct B { [[nodiscard]] B() {} };
+
+void
+test (void)
+{
+  A{}; /* { dg-warning "nodiscard\[^\n\r]*bad constructor" } */
+  B{}; /* { dg-warning "nodiscard" } */
+}
--- gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor2.C.jj  2021-03-03 
20:32:02.781900801 +0100
+++ gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor2.C 2021-03-03 
20:34:33.416257158 +0100
@@ -0,0 +1,17 @@
+// PR c++/99362
+// { dg-do compile { target c++20 } }
+
+struct S {
+  [[nodiscard]] S() {}
+  S(int) {}
+};
+
+int main()
+{
+  S s;
+  S(); // { dg-warning "ignoring return value" }
+  (void)(S());
+  S t = 1;
+  S(1);
+  (void)(S(1));
+}
--- gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C.jj  2020-11-10 
10:21:27.272096866 +0100
+++ gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C 2021-03-03 20:31:11.115464565 
+0100
@@ -1,6 +1,6 @@
  /* nodiscard 

Re: [PATCH] c-ppoutput: Fix preprocessing ICE on very large line number [PR99325]

[Nathan Sidwell]

On 3/4/21 4:03 AM, Jakub Jelinek wrote:

Hi!

In libcpp, lines are represented as linenum_type, which is unsigned int.
The following testcases ICE because maybe_print_line_1 is sometimes called
with UNKNOWN_LOCATION (e.g. at pragma eof) and while most of the time
the
&& src_line >= print.src_line
&& src_line < print.src_line + 8
check doesn't succeed for the src_line of 0 from UNKNOWN_LOCATION, when
print.src_line is from very large line numbers (UINT_MAX - 7 and above)
it succeeds (with UB on the compiler side) but src_file is NULL for
UNKNOWN_LOCATION and so the strcmp call ICEs.
As print.src_line can easily wrap around, this patch changes its type
to unsigned int to match libcpp, so that we don't invoke UB in the compiler.
For print.src_line of UINT_MAX - 7 and above, src_line from UNKNOWN_LOCATION
will not pass that test anymore, but when it wraps around to 0, it can,
so I've also added a check for src_loc != UNKNOWN_LOCATION (or, if
preferred, could be src_file != NULL).
Besides fixing the ICE and UB in the compiler, I believe worst case the
patch will cause printing a few more line directives in the preprocessed
source around the wrapping from lines UINT_MAX - 7 to 0 (but less
around the wrapping from INT_MAX to INT_MAX + 1U), but I think those
are exceptional cases (sources with > 2billion lines are rare and
we warn or error on #line > INT_MAX).

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

2021-03-03  Jakub Jelinek  

PR c/99325
* c-ppoutput.c (print): Change src_line type from int to unsigned.
(token_streamer::stream) Likewise.
(maybe_print_line_1): Likewise.  Don't strcmp src_file if src_loc is
UNKNOWN_LOCATION.


ok.  thanks!
I think I noticed that signed/unsigned confusion when futzing around 
with modules, but didn't feel like diving in :)


nathan

--
Nathan Sidwell

[PATCH] Handle ERROR_MARK in direct_abstract_declarator

[Richard Biener]

The gcc.dg/noncompile/pr79758.c testcase prints

pr79758.c:5:6: error: redefinition of 'fn1'
'error_mark' not supported by 
direct_abstract_declarator)'/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/noncompile/pr79758.c:4:6:
 note: previous definition of 'fn1' with type

which shows a) re-entry of pp_printf via pp_unsupported_tree and b) a
bogus diagnostic.  The following handles ERROR_MARK in
direct_abstract_declarator, yielding in the better

/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/noncompile/pr79758.c:5:6: error: 
redefinition of 'fn1'
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/noncompile/pr79758.c:4:6: note: 
previous definition of 'fn1' with type 'void()'

but still maybe not perfect.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

OK for trunk?  GCC 10 doesn't exhibit this issue since it doesn't
print the 'with type ...' part.

2021-03-04  Richard Biener  

gcc/c-family/
* c-pretty-print.c (c_pretty_printer::direct_abstract_declarator):
Handle ERROR_MARK.
---
 gcc/c-family/c-pretty-print.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index 2095d4badf7..a987da46d6d 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -676,6 +676,7 @@ c_pretty_printer::direct_abstract_declarator (tree t)
 case VECTOR_TYPE:
 case COMPLEX_TYPE:
 case TYPE_DECL:
+case ERROR_MARK:
   break;
 
 default:
-- 
2.26.2

Re: [PATCH] profiling: fix streaming of TOPN counters

[Jan Hubicka]

>  .../gcc.dg/tree-prof/indir-call-prof-malloc.c |  2 +-
>  gcc/testsuite/gcc.dg/tree-prof/pr97461.c  |  2 +-
>  libgcc/libgcov-driver.c   | 56 ---
>  3 files changed, 50 insertions(+), 10 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c 
> b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
> index 454e224c95f..7bda4aedfc8 100644
> --- a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
> +++ b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
> @@ -1,4 +1,4 @@
> -/* { dg-options "-O2 -ldl" } */
> +/* { dg-options "-O2 -ldl -fprofile-correction" } */
>  
>  #define _GNU_SOURCE
>  #include 
> diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr97461.c 
> b/gcc/testsuite/gcc.dg/tree-prof/pr97461.c
> index 213fac9af04..f684be4d80f 100644
> --- a/gcc/testsuite/gcc.dg/tree-prof/pr97461.c
> +++ b/gcc/testsuite/gcc.dg/tree-prof/pr97461.c
> @@ -1,5 +1,5 @@
>  /* PR gcov-profile/97461 */
> -/* { dg-options "-O2 -ldl" } */
> +/* { dg-options "-O2 -ldl -fprofile-correction" } */
>  
>  #define _GNU_SOURCE
>  
> diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
> index 91462350132..d2e60a5a6df 100644
> --- a/libgcc/libgcov-driver.c
> +++ b/libgcc/libgcov-driver.c
> @@ -42,6 +42,10 @@ void __gcov_init (struct gcov_info *p __attribute__ 
> ((unused))) {}
>  #include 
>  #endif
>  
> +#if HAVE_SYS_MMAN_H
> +#include 
> +#endif
> +
>  #ifdef L_gcov
>  
>  /* A utility function for outputting errors.  */
> @@ -334,30 +338,66 @@ read_error:
>return -1;
>  }
>  
> +#define MAX(X,Y) ((X) > (Y) ? (X) : (Y))
> +
>  /* Store all TOP N counters where each has a dynamic length.  */
>  
>  static void
> -write_top_counters (const struct gcov_ctr_info *ci_ptr,
> - unsigned t_ix,
> - gcov_unsigned_t n_counts)
> +write_topn_counters (const struct gcov_ctr_info *ci_ptr,
> +  unsigned t_ix,
> +  gcov_unsigned_t n_counts)
>  {
>unsigned counters = n_counts / GCOV_TOPN_MEM_COUNTERS;
>gcc_assert (n_counts % GCOV_TOPN_MEM_COUNTERS == 0);
> +
> +  /* It can happen in a multi-threaded environment that number of counters is
> + different from the size of the corresponding linked lists.  */
> +#define LIST_SIZE_MIN_LENGTH 4 * 1024
> +
> +  static unsigned *list_sizes = NULL;
> +  static unsigned list_size_length = 0;
> +
> +  if (list_sizes == NULL || counters > list_size_length)
> +{
> +  list_size_length = MAX (LIST_SIZE_MIN_LENGTH, counters);
> +#if HAVE_SYS_MMAN_H
> +  list_sizes = (unsigned *)mmap (NULL, list_size_length * sizeof 
> (unsigned),
> +  PROT_READ | PROT_WRITE,
> +  MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> +#endif
> +
> +  /* Malloc fallback.  */
> +  if (list_sizes == NULL)
> + list_sizes = (unsigned *)xmalloc (list_size_length * sizeof (unsigned));
I see, you switched to allocating buffer permanently. This also works.
Given that you do not deallocate the memory, I think you want to
allocate list_size_length*2 so we do not end up taking O(mn) memory
where n is the largest number of counters in a file and m is number of
sections with counters.

Can you please unify the mmap code in list allocation and here, so there
is only one place in libgcov Windows folks will need to update?

Otherwise the patch looks OK.
Honza

c++: Redesign pending entity handling [PR 99170]

[Nathan Sidwell]

This patch addresses 99170.  with modules (and in particular header 
units), one module can provide a (maybe nested) class or template and 
another module can provide a definition or (maybe partial) 
specialization of said entity, or member thereof.  when both are 
imported into a 3rd TU, and that TU instantiates or uses the class, it 
needs to stream in those entities (in general).  But how does it key 
those entities to the original?  It can't /just/ use the entity index, 
because, when header-units and/or partitions are in play, the entity 
index /is not unique/.  I had two complicated schemes that tried to 
unify that, but it failed.  Here's a simpler scheme.  Such pending 
entities are keyed to the namespace and identifier of the 
namespace-scope entity that contains them.  Thus the final TU needs to 
find that entity and look in a hash table for lists of sections that 
need loading just before instantiating a template or looking inside a class.


I would like to make this more efficient, but given the complex scheme 
failed, I'm shooting for correctness right now.  There will be a follow 
up patch to complete the cleanup this enables.


PR c++/99170
gcc/cp/
* cp-tree.h
* lex.c (cxx_dup_lang_specific_decl): Adjust for module_attached_p
rename.
* module.cc (class pending_key): New.
(default_hash_traits): New specialization.
(pending_map_t): New typedef.
(pending_table): Replace old table.
(trees_out::lang_decl_bools): Adjust.
(trees_in::lang_decl_bools): Adjust.
(trees_in::install_entity): Drop pending member and specialization
handling.
(find_pending_key): New.
(depset::hash::fiund_dependencies): Use it.
(pendset_lazy_load): Delete.
(module_state::write_cluster): Don't count pendings here.  Bye
Duff's device-like thing.
(module_state::write_pendings): Reimplement.
(module_state::read_pendings): Reimplement.
(lazy_specializations_p): Delete.
(module_state::write): Adjust write_pendings call.
(lazy_load_pendings): New.
(lazy_load_specializations): Delete.
(lazy_load_members): Delete.
(init_modules): Adjust.
* name-lookup.c (maybe_lazily_declare): Call lazy_load_pendings
not lazy_load_members.
(note_pending_specializations): Delete.
(load_pending_specializations): Delete.
* name-lookup.h (BINDING_VECTR_PENDING_SPECIALIZATIONS_P): Delete.
(BINDING_VECTOR_PENDING_MEMBERS_P): Delete.
(BINDING_VECTR_PENDING_MEMBERS_P): Delete.
(note_pending_specializations): Delete.
(load_pending_specializations): Delete.
* pt.c (lookup_template_class_1): Call lazy_load_pendings not
lazy_load_specializations.
(instantiate_template_class_1): Likewise.
(instantiate_decl): Call lazy_load_pendings.
* typeck.c (complete_type): Likewise.
gcc/testsuite/
* g++.dg/modules/pr99170-1_a.H: New.
* g++.dg/modules/pr99170-1_b.C: New.
* g++.dg/modules/pr99170-2.h: New.
* g++.dg/modules/pr99170-2_a.C: New.
* g++.dg/modules/pr99170-2_b.C: New.
* g++.dg/modules/pr99170-3_a.H: New.
* g++.dg/modules/pr99170-3_b.C: New.
* g++.dg/modules/inst-2_b.C: Adjust scan.
* g++.dg/modules/inst-4_a.C: Adjust scan.
* g++.dg/modules/inst-4_b.C: Adjust scan.
* g++.dg/modules/member-def-1_b.C: Adjust scan.
* g++.dg/modules/member-def-1_c.C: Adjust scan.
* g++.dg/modules/tpl-spec-1_a.C: Adjust scan.
* g++.dg/modules/tpl-spec-1_b.C: Adjust scan.
* g++.dg/modules/tpl-spec-2_b.C: Adjust scan.
* g++.dg/modules/tpl-spec-2_c.C: Adjust scan.
* g++.dg/modules/tpl-spec-2_d.C: Adjust scan.
* g++.dg/modules/tpl-spec-3_a.C: Adjust scan.
* g++.dg/modules/tpl-spec-3_b.C: Adjust scan.
* g++.dg/modules/tpl-spec-4_a.C: Adjust scan.
* g++.dg/modules/tpl-spec-4_b.C: Adjust scan.
* g++.dg/modules/tpl-spec-5_a.C: Adjust scan.
* g++.dg/modules/tpl-spec-5_b.C: Adjust scan.

--
Nathan Sidwell
diff --git c/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index 699c50515e8..39e2ad83abd 100644
--- c/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -1678,21 +1678,10 @@ check_constraint_info (tree t)
 #define DECL_MODULE_ENTITY_P(NODE) \
   (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (NODE))->u.base.module_entity_p)
 
-/* True if there are unloaded specializations keyed to this template.  */
-#define DECL_MODULE_PENDING_SPECIALIZATIONS_P(NODE)	\
-  (DECL_LANG_SPECIFIC (TEMPLATE_DECL_CHECK (NODE))	\
-   ->u.base.module_pending_p)
-
-/* True if this class has unloaded members.  These should be loaded
-   before we do member lookups.   */
-#define DECL_MODULE_PENDING_MEMBERS_P(NODE)		\
-  (DECL_LANG_SPECIFIC (TYPE_DECL_CHECK (NODE))		\
-   ->u.base.module_pending_p)
-
 /* DECL that has attached decls for 

Re: [PATCH] middle-end/97855 - fix diagnostic with default pretty printer

[Richard Biener]

On Thu, 4 Mar 2021, Richard Biener wrote:

> On Wed, 3 Mar 2021, Richard Biener wrote:
> 
> > On Wed, 3 Mar 2021, David Malcolm wrote:
> > 
> > > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > > > On Tue, 2 Mar 2021, Martin Sebor wrote:
> > > > 
> > > > > On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> > > > > > 
> > > > > > 
> > > > > > On 3/1/21 1:39 AM, Richard Biener wrote:
> > > > > > > The default diagnostic tree printer relies on dump_generic_node
> > > > > > > which
> > > > > > > for some reason manages to clobber the diagnostic pretty-
> > > > > > > printer state
> > > > > > > so we see garbled diagnostics like
> > > > > > > 
> > > > > > > /home/rguenther/src/trunk/gcc/calls.c: In function
> > > > > > > 'expand_call':
> > > > > > > D.6750.coeffs[0]'/home/rguenther/src/trunk/gcc/dojump.c:118:28:
> > > > > > > warning:
> > > > > > > may be used uninitialized in this function [-Wmaybe-
> > > > > > > uninitialized]
> > > > > > > 
> > > > > > > when the diagnostic is emitted by the LTO fronted.  The
> > > > > > > following
> > > > > > > approach using a temporary pretty-printer for the
> > > > > > > dump_generic_node
> > > > > > > call fixes this for some unknown reason and we issue
> > > > > > > 
> > > > > > > /home/rguenther/src/trunk/gcc/calls.c: In function
> > > > > > > 'expand_call':
> > > > > > > /home/rguenther/src/trunk/gcc/dojump.c:118:28: warning:
> > > > > > > 'MEM[(struct
> > > > > > > poly_int *)].D.6750.coeffs[0]' may be used uninitialized
> > > > > > > in this
> > > > > > > function [-Wmaybe-uninitialized]
> > > > > > > 
> > > > > > > [LTO] Bootstrapped and tested on x86_64-unknown-linux-gnu, OK
> > > > > > > for trunk?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Richard.
> > > > > > > 
> > > > > > > 2021-02-26  Richard Biener  
> > > > > > > 
> > > > > > >  PR middle-end/97855
> > > > > > >  * tree-diagnostic.c (default_tree_printer): Use a temporary
> > > > > > >  pretty-printer when formatting a tree via dump_generic_node.
> > > > > > It'd be good to know why this helps, but I trust your judgment
> > > > > > that this
> > > > > > is an improvement.
> > > > > 
> > > > > I don't know if it's related but pr98492 tracks a problem in the
> > > > > C++
> > > > > front end caused by reinitializing the pretty printer in a number
> > > > > of
> > > > > functions in cp/error.c.  When one of these functions is called
> > > > > while
> > > > > the pretty printer is formatting something, the effect of
> > > > > the reinitialization is to drop the already formatted contents
> > > > > of the printer's buffer.
> > > > > 
> > > > > IIRC, I tripped over this when working on the MEM_REF formatting
> > > > > improvement for -Wuninitialized.
> > > > 
> > > > I've poked quite a bit with breakpoints on suspicious pretty-printer
> > > > functions and watch points on the pp state but found nothing in the
> > > > case I was looking at (curiously also -Wuninitialized).  But I also
> > > > wasn't able to understand why the caller should work at all.  And
> > > > yes, the C/C++ tree printers also simply format to the passed
> > > > pretty-printer...
> > > > 
> > > > Hoping that David could shed some light on how this should play
> > > > together.
> > > 
> > > This looks very much like the issue I ran into in
> > > c46d057f55748520e819dcd8e04bca71be9902b2 (and, in retrospect, that
> > > commit may have just been papering over the problem).
> > > 
> > > The issue there was that pp_printf is not reentrant - if a handler for
> > > a pp_printf format code ends up making a nested call to pp_printf, I
> > > got behavior that looks like what you're seeing.
> > > 
> > > That said, I've been poring over the output in PR middle-end/97855 and
> > > comparing it to the various pretty-printer usage in the tree, and I'm
> > > not seeing anywhere where a pp_printf seems to be used when generating:
> > >   MEM[(struct poly_int *) + 8B].D.6750.coeffs[0]
> > 
> > I think it's the D.6750 which is printed via
> > 
> >   else if (TREE_CODE (node) == DEBUG_EXPR_DECL)
> > {
> >   if (flags & TDF_NOUID)
> > pp_string (pp, "D#");
> >   else
> > pp_printf (pp, "D#%i", DEBUG_TEMP_UID (node));
> > 
> > because this is a DECL_DEBUG_EXPR.  One could experiment with
> > avoiding pp_printf in dump_decl_name.
> > 
> > > Is there a minimal reproducer (or a .i file?)
> > 
> > No, you need to do a LTO bootstrap, repeat the link step of
> > for example cc1 with -v -save-temps and pick an ltrans invocation
> > that exhibits the issue ...
> > 
> > I can poke at the above tomorrow again.  I suppose we could
> > also add some checking-assert into the pp_printf code at
> > the problematic place (or is any recursion bogus?) to catch
> > the case with an ICE.
> 
> It ICEs _a_ _lot_.
> 
> diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c
> index ade1933f86a..7755157a7d7 100644
> --- a/gcc/pretty-print.c
> +++ b/gcc/pretty-print.c
> @@ -1069,6 +1069,11 @@ static const char 

[PATCH][pushed] gcov: call mmap MAP_ANONYMOUS with fd equal to -1

[Martin Liška]

Pushed as obvious.

Martin

libgcc/ChangeLog:

PR gcov-profile/99385
* libgcov.h (allocate_gcov_kvp): Call mmap with fd equal to -1.
---
 libgcc/libgcov.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index 9c5fcfba4ad..acdb7cd1500 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -426,7 +426,7 @@ allocate_gcov_kvp (void)
 {
   void *ptr = mmap (NULL, MMAP_CHUNK_SIZE,
PROT_READ | PROT_WRITE,
-   MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
   if (ptr != MAP_FAILED)
{
  __gcov_kvp_dynamic_pool = ptr;
--
2.30.1

[committed] libstdc++: Fix buffer overflows in tests [PR 99382]

[Jonathan Wakely via Gcc-patches]

This seems to be a typo/thinko in the definition of the arrays used as
storage.

libstdc++-v3/ChangeLog:

PR libstdc++/99382
* 
testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc:
Make storage larger than required. Verify no write to the last
element.
* 
testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc:
Likewise.

Tested x86_64-linux. Committed to trunk.

commit 905ce0ca30cb33cddf024b0aebf4ba0b2c86fe77
Author: Jonathan Wakely 
Date:   Thu Mar 4 10:28:38 2021

libstdc++: Fix buffer overflows in tests [PR 99382]

This seems to be a typo/thinko in the definition of the arrays used as
storage.

libstdc++-v3/ChangeLog:

PR libstdc++/99382
* 
testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc:
Make storage larger than required. Verify no write to the last
element.
* 
testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc:
Likewise.

diff --git 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc
 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc
index fbe14d41ed7..1a1aba4d5b0 100644
--- 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc
+++ 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc
@@ -41,10 +41,12 @@ test02()
 int operator>(void*) { return value != 0; }
   };
 
-  int i[3];
+  int i[5] = { 1, 2, 3, 4, 5 };
   Size n = {4};
   auto j = std::__uninitialized_default_n(i, n);
   VERIFY( j == (i + 4) );
+  // i[0:3] are default-initialized so have indeterminate values.
+  VERIFY( i[4] == 5 );
 }
 
 int
diff --git 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc
 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc
index d227de4fd80..5833f7ed6c3 100644
--- 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc
+++ 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc
@@ -42,10 +42,15 @@ test02()
 int operator>(void*) { return value != 0; }
   };
 
-  int i[3];
+  int i[5] = { 1, 2, 3, 4, 5 };
   Size n = {4};
   auto j = std::__uninitialized_default_n(i, n);
   VERIFY( j == (i + 4) );
+  VERIFY( i[0] == 0 );
+  VERIFY( i[1] == 0 );
+  VERIFY( i[2] == 0 );
+  VERIFY( i[3] == 0 );
+  VERIFY( i[4] == 5 );
 }
 
 int

Re: [PATCH] middle-end/97855 - avoid recursing into pp_printf

[Richard Biener]

On Thu, 4 Mar 2021, Jakub Jelinek wrote:

> On Thu, Mar 04, 2021 at 09:08:35AM +0100, Richard Biener wrote:
> > 2021-03-04  Richard Biener  
> > 
> > PR middle-end/97855
> > * tree-pretty-print.c: Poison pp_printf.
> > (dump_decl_name): Avoid use of pp_printf.
> > (dump_block_node): Likewise.
> > (dump_generic_node): Likewise.
> 
> >   char c = TREE_CODE (node) == CONST_DECL ? 'C' : 'D';
> > + pp_character (pp, c);
> > + pp_character (pp, uid_sep);
> >   if (flags & TDF_NOUID)
> > -   pp_printf (pp, "%c.", c);
> > +   pp_string (pp, "");
> >   else
> > -   pp_printf (pp, "%c%c%u", c, uid_sep, DECL_UID (node));
> > +   pp_decimal_int (pp, (int) DECL_UID (node));
> 
> I think it would be better if this patch didn't change behavior.
> So yes, pp_decimal_int is ok for previous %d or %i, but %u
> should be done with
> pp_scalar (pp, "%u", DECL_UID (node));
> (or pp_unsigned_wide_integer (pp, DECL_UID (node));).
> 
> > }
> >  }
> >if ((flags & TDF_ALIAS) && DECL_PT_UID (node) != DECL_UID (node))
> >  {
> >if (flags & TDF_NOUID)
> > -   pp_printf (pp, "ptD.");
> > +   pp_string (pp, "ptD.");
> >else
> > -   pp_printf (pp, "ptD.%u", DECL_PT_UID (node));
> > +   {
> > + pp_string (pp, "ptD.");
> > + pp_decimal_int (pp, (int) DECL_PT_UID (node));
> 
> Ditto here, pp_scalar (pp, "%u", DECL_PT_UID (node));
> 
> > @@ -2165,9 +2207,16 @@ dump_generic_node (pretty_printer *pp, tree node, 
> > int spc, dump_flags_t flags,
> >   else
> > {
> >   if (flags & TDF_GIMPLE)
> > -   pp_printf (pp, "", DECL_UID (node));
> > +   {
> > + pp_character (pp, 'D');
> > + pp_decimal_int (pp, (int) DECL_UID (node));
> 
> Here too.
> > +   }
> >   else
> > -   pp_printf (pp, "", DECL_UID (node));
> > +   {
> > + pp_string (pp, " > + pp_decimal_int (pp, (int) DECL_UID (node));
> 
> And here.
> > + pp_character (pp, '>');
> > +   }
> > }
> > }
> >break;
> > @@ -3021,9 +3070,12 @@ dump_generic_node (pretty_printer *pp, tree node, 
> > int spc, dump_flags_t flags,
> >   pp_string (pp, ", ivdep");
> >   break;
> > case annot_expr_unroll_kind:
> > - pp_printf (pp, ", unroll %d",
> > -(int) TREE_INT_CST_LOW (TREE_OPERAND (node, 2)));
> > - break;
> > + {
> > +   pp_string (pp, ", unroll ");
> > +   pp_decimal_int (pp,
> > +   (int) TREE_INT_CST_LOW (TREE_OPERAND (node, 2)));
> > +   break;
> > + }
> > case annot_expr_no_vector_kind:
> >   pp_string (pp, ", no-vector");
> >   break;
> > @@ -3205,7 +3257,8 @@ dump_generic_node (pretty_printer *pp, tree node, int 
> > spc, dump_flags_t flags,
> >dump_generic_node (pp, CHREC_LEFT (node), spc, flags, false);
> >pp_string (pp, ", +, ");
> >dump_generic_node (pp, CHREC_RIGHT (node), spc, flags, false);
> > -  pp_printf (pp, "}_%u", CHREC_VARIABLE (node));
> > +  pp_string (pp, "}_");
> > +  pp_decimal_int (pp, (int)CHREC_VARIABLE (node));
> 
> And here.
> 
> Ok with those changes if it passes testing.

Pushed as follows.

Richard.

>From ff22c2a6eddd90085e4c97026b43bb46ca945fe4 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Thu, 4 Mar 2021 09:00:55 +0100
Subject: [PATCH] middle-end/97855 - avoid recursing into pp_printf
To: gcc-patches@gcc.gnu.org

When diagnostic messages use pretty-printer formats like %D or %E
the pp_printf invocation can end up in tree pretty-printers which
then have to avoid using pp_printf themselves since this function
is not re-entrant.

The following removes all pp_printf uses from tree-pretty-print.c
fixing the observed malformed diagnostics.  It also poisons the
identifier so new uses are less likely to creep in.

2021-03-04  Richard Biener  

PR middle-end/97855
* tree-pretty-print.c: Poison pp_printf.
(dump_decl_name): Avoid use of pp_printf.
(dump_block_node): Likewise.
(dump_generic_node): Likewise.
---
 gcc/tree-pretty-print.c | 95 -
 1 file changed, 74 insertions(+), 21 deletions(-)

diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 986f75d1d5f..62899dfa158 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -36,6 +36,11 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple.h"
 #include "fold-const.h"
 
+/* Routines in this file get invoked via the default tree printer
+   used by diagnostics and thus they are called from pp_printf which
+   isn't reentrant.  Avoid using pp_printf in this file.  */
+#pragma GCC poison pp_printf
+
 /* Disable warnings about quoting issues in the pp_xxx calls below
that (intentionally) don't follow GCC diagnostic conventions.  */
 #if __GNUC__ >= 10
@@ -293,29 +298,41 @@ dump_decl_name (pretty_printer *pp, 

Re: [PATCH] ssa-ifcombine: combining comparisons [Bug 53806]

[Richard Biener via Gcc-patches]

On Thu, Mar 4, 2021 at 1:23 AM Ivan Sučić via Gcc-patches
 wrote:
>
> Hi,
> The patch solves the bug when in ifcombine are comparisons like <= and >= 
> combined. I removed the trap check for last statement and that doesn't break 
> the solution for bug 61383. In fold-const.c i removed the trap checks becase 
> combining comparisons doesn't introduce new traps. I tested my patch on wsl2 
> debain and it doesn't have more failed tests then without my patch. Maybe the 
> only problem with testing is that i get error tcl error sourcing 
> gcc/testsuite/gcc.misc-tests/linkage.exp. That error I get without my patch, 
> too. I hope you will accept my patch.

diff --git a/ChangeLog b/ChangeLog
index 6c07275d2b4..29176bf9607 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2021-03-03 Ivan Sucic 

newline missing

+   PR 53806

should be

PR tree-optimization/53806

+   * tree-ssa-ifcombine.c: Checking trap not for
+   last statement

should be
* tree-ssa-ifcombine.c (bb_no_side_effects_p): Checking trap
not for last statement.

+   * fold-const.c: The comparison combine makes
+   new comparison correct and the trap check is
+   not required.
+   * ssa-ifcombine-14.c: Testcase for if combine
+   comparisons of double type.

we are no longer editing ChangeLog files manually, instead the
changelog entry is now embedded
within the git commit message and automatically transfered.  So please
for further submissions
use git format-patch which will include the commit message as well.

diff --git a/gcc/tree-ssa-ifcombine.c b/gcc/tree-ssa-ifcombine.c
index 21a70f4386d..f2abaf18342 100644
--- a/gcc/tree-ssa-ifcombine.c
+++ b/gcc/tree-ssa-ifcombine.c
@@ -125,7 +125,8 @@ bb_no_side_effects_p (basic_block bb)

   if (gimple_has_side_effects (stmt)
  || gimple_uses_undefined_value_p (stmt)
- || gimple_could_trap_p (stmt)
+ /* Last statement is taken care by combining ifs */
+ || (!gsi_one_before_end_p (gsi) && gimple_could_trap_p (stmt))
  || gimple_vuse (stmt)
  /* const calls don't match any of the above, yet they could
 still have some side-effects - they could contain

might be easier to start the loop from the end of the BB and skip
a gimple-cond if it appears there.

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 3744e4c2c2d..a83c98014fb 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -2860,40 +2860,6 @@ combine_comparisons (location_t loc,
   else if (compcode == COMPCODE_ORD)
compcode = COMPCODE_TRUE;
 }
-   else if (flag_trapping_math)
- {
-   /* Check that the original operation and the optimized ones will trap
-  under the same condition.  */
-   bool ltrap = (lcompcode & COMPCODE_UNORD) == 0
...
-/* If the comparison was short-circuited, and only the RHS
-  trapped, we may now generate a spurious trap.  */
-   if (rtrap && !ltrap
-   && (code == TRUTH_ANDIF_EXPR || code == TRUTH_ORIF_EXPR))
- return NULL_TREE;
-
-   /* If we changed the conditions that cause a trap, we lose.  */
-   if ((ltrap || rtrap) != trap)
- return NULL_TREE;
-  }

   if (compcode == COMPCODE_TRUE)
 return constant_boolean_node (true, truth_type);

I don't think removing all code is OK since it would
allow combining x == y || x > y to x >= y which may
trap.  The bugreport suggests to alter the last
test to something like

  if (trap && !ltrap && !rtrap)
return NULL_TREE;

thus if we manage to remove a trap (!trap) the transform
is OK.

Thanks,
Richard.

Re: [PATCH] [og10] openmp: Scale precision of collapsed iteration variable

[Tobias Burnus]

Hello Kwok,

On 01.03.21 23:28, Kwok Cheung Yeung wrote:

When two or more nested loops are collapsed using the OpenMP collapse
clause, a single iteration variable is used to represent the combined
iteration space. In the usual case (i.e. statically scheduled, no
ordered clause), the type of this variable is picked by taking the
unsigned version of the largest of the iterator types in the loop nest
[...] However, this can be problematic if the combined iteration space
of the collapsed loops is larger than can be represented by the type
of the largest individual loop iterator type.


Unfortunately, we are deeply in the implementation-defined realm.
I have now filled an OpenMP spec issue to make it possible to
avoid/mitigate those issues as user: OpenMP Issue 2693.
Namely, a way to specify the used integer type/precision
and/or refine what the user can expect.

In any case, the following applies currently:

"The iterations of some number of associated loops can be
 collapsed into one larger iteration space that is called
 the logical iteration space. The particular integer type
 used to compute the iteration count for the collapsed
 loop is implementation defined."
(2.11.1 Canonical Loop Nest Form)

Hence, both is sensible – the current behavior of GCC
and the one you have proposed and implemented:


This patch attempts to avoid this problem by setting the precision of
the combined iteration variable to the sum of the precision of the
collapsed iterators, rounded up to the nearest power of 2. This is
capped at the size of a long long (i.e. 64 bits) to avoid an excessive
performance hit. If any of the loops use a larger type (e.g.
__int128), then that is used instead.

* * *

I believe OpenACC suffers from a similar problem, but it uses a
different code-path and should be dealt with separately.

Regarding OpenACC, I think diff_type → expand_oacc_collapse_init,
expand_oacc_collapse_vars would be the equivalent. In the spec, either a
note similar to OpenMP is missing or I have just not found it.

Okay for OG10?


I think that's fine for the OG10 branch for now. Another question is how
to handle it best on mainline, which is then also Jakub's call. And also
how the OpenMP issue will be resolved.

Can you add a comment to the two testcases that the internal variable,
used to calculate the iteration count, needs a higher precision than
(32bit) 'int'? Otherwise it is not obvious.

Tobias

+ {
+   int loop_precision = TYPE_PRECISION (TREE_TYPE (loop->v));
+   int iter_type_precision = 0;
+   const int max_accum_precision
+ = TYPE_PRECISION (long_long_unsigned_type_node);
+
+   accum_iter_precision += loop_precision;
+
+   if (i == 0
+   || (loop_precision >= max_accum_precision
+   && loop_precision >= TYPE_PRECISION (iter_type)))
+ iter_type_precision = loop_precision;
+   else if (TYPE_PRECISION (iter_type) < max_accum_precision)
+ iter_type_precision
+   = MIN (1 << ceil_log2 (accum_iter_precision),
+  max_accum_precision);
+
+   if (iter_type_precision)
+ iter_type = build_nonstandard_integer_type
+   (iter_type_precision, 1);
+ }
  }
else if (iter_type != long_long_unsigned_type_node)
  {
diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index d1dcf20..0e3fd12 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,3 +1,8 @@
+2021-03-01  Kwok Cheung Yeung
+
+ * testsuite/libgomp.c-c++-common/collapse-4.c: New.
+ * testsuite/libgomp.fortran/collapse5.f90: New.
+
  2021-02-24  Julian Brown

  Backport from mainline
diff --git a/libgomp/testsuite/libgomp.c-c++-common/collapse-4.c 
b/libgomp/testsuite/libgomp.c-c++-common/collapse-4.c
new file mode 100644
index 000..04cf747
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c-c++-common/collapse-4.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+
+#include 
+
+int
+main (void)
+{
+  int i, j;
+  int count = 0;
+
+  #pragma omp parallel for collapse(2)
+for (i = 0; i < 8; i++)
+  for (j = 0; j < 8; j++)
+ if (i == 6 && j == 7)
+   count++;
+
+  if (count != 1)
+abort ();
+}
diff --git a/libgomp/testsuite/libgomp.fortran/collapse5.f90 
b/libgomp/testsuite/libgomp.fortran/collapse5.f90
new file mode 100644
index 000..c76424d
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/collapse5.f90
@@ -0,0 +1,14 @@
+! { dg-do run }
+
+  integer :: i, j
+  integer :: count = 0
+
+  !$omp parallel do collapse (2)
+do i = 0, 8
+  do j = 0, 8
+if (i .eq. 6 .and. j .eq. 7) count = count + 1
+  end do
+end do
+
+  if (count .ne. 1) stop 1
+end
-- 2.8.1

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf

[PATCH] c++: Fix up [[nodiscard]] on ctors on targetm.cxx.cdtor_returns_this targets [PR99362]

[Jakub Jelinek via Gcc-patches]

Hi!

In the P1771R1 changes JeanHeyd reverted part of Alex' PR88146 fix,
but that seems to be incorrect to me.
Where P1771R1 suggests warnings for [[nodiscard]] on constructors is
handled in a different place - in particular the TARGET_EXPR handling
of convert_to_void.  When we have CALL_EXPR of a ctor, on most arches
that call has void return type and so returns early, and on arm where
the ctor returns the this pointer it is undesirable to warn as it warns
about all ctor calls, not just the ones where it should warn.

The P1771R1 changes added a test for this, but as it was given *.c
extension rather than *.C, the test was never run and so this didn't get
spotted immediately.  The test also had a bug, (?n) can't be used
in dg-warning/dg-error because those are implemented by prepending
some regexp before the user provided one and (?n) must come at the start
of the regexp.  Furthermore, while -ftrack-macro-expansion=0 is useful
in one nodiscard test which uses macros, I don't see how it would be
relevant to all the other cpp2a/nodiscard* tests which don't use any
macros.

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

2021-03-03  Jakub Jelinek  

PR c++/88146
PR c++/99362
gcc/cp/
* cvt.c (convert_to_void): Revert 2019-10-17 changes.  Clarify
comment.
gcc/testsuite/
* g++.dg/cpp2a/nodiscard-constructor.c: Renamed to ...
* g++.dg/cpp2a/nodiscard-constructor1.C: ... this.  Remove
-ftrack-macro-expansion=0 from dg-options.  Don't use (?n) in
dg-warning regexps, instead replace .* with \[^\n\r]*.
* g++.dg/cpp2a/nodiscard-constructor2.C: New test.
* g++.dg/cpp2a/nodiscard-reason-only-one.C: Remove
-ftrack-macro-expansion=0 from dg-options.
* g++.dg/cpp2a/nodiscard-reason-nonstring.C: Likewise.
* g++.dg/cpp2a/nodiscard-once.C: Likewise.

--- gcc/cp/cvt.c.jj 2021-01-26 08:57:46.469172105 +0100
+++ gcc/cp/cvt.c2021-03-03 20:22:35.849086890 +0100
@@ -1231,12 +1231,14 @@ convert_to_void (tree expr, impl_conv_vo
 case CALL_EXPR:   /* We have a special meaning for volatile void fn().  */
   /* cdtors may return this or void, depending on
 targetm.cxx.cdtor_returns_this, but this shouldn't affect our
-decisions here: neither nodiscard warnings (nodiscard cdtors
-are nonsensical), nor should any constexpr or template
-instantiations be affected by an ABI property that is, or at
-least ought to be transparent to the language.  */
+decisions here: neither nodiscard warnings (nodiscard dtors
+are nonsensical and ctors have a different behavior with that
+attribute that is handled in the TARGET_EXPR case), nor should
+any constexpr or template instantiations be affected by an ABI
+property that is, or at least ought to be transparent to the
+language.  */
   if (tree fn = cp_get_callee_fndecl_nofold (expr))
-   if (DECL_DESTRUCTOR_P (fn))
+   if (DECL_CONSTRUCTOR_P (fn) || DECL_DESTRUCTOR_P (fn))
  return expr;
 
   if (complain & tf_warning)
--- gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor.c.jj   2020-07-28 
15:39:10.008756228 +0200
+++ gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor.c  2021-03-03 
20:28:46.095046953 +0100
@@ -1,13 +0,0 @@
-/* nodiscard attribute tests  */
-/* { dg-do compile { target c++20 } } */
-/* { dg-options "-O -ftrack-macro-expansion=0" } */
-
-struct A { [[nodiscard("bad constructor")]] A() {} };
-struct B { [[nodiscard]] B() {} };
-
-void
-test (void)
-{
-  A{}; /* { dg-warning "(?n)nodiscard.*bad constructor" } */
-  B{}; /* { dg-warning "(?n)nodiscard" } */
-}
--- gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor1.C.jj  2021-03-03 
20:28:39.364120391 +0100
+++ gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor1.C 2021-03-03 
20:37:53.186077373 +0100
@@ -0,0 +1,13 @@
+/* nodiscard attribute tests  */
+/* { dg-do compile { target c++20 } } */
+/* { dg-options "-O" } */
+
+struct A { [[nodiscard("bad constructor")]] A() {} };
+struct B { [[nodiscard]] B() {} };
+
+void
+test (void)
+{
+  A{}; /* { dg-warning "nodiscard\[^\n\r]*bad constructor" } */
+  B{}; /* { dg-warning "nodiscard" } */
+}
--- gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor2.C.jj  2021-03-03 
20:32:02.781900801 +0100
+++ gcc/testsuite/g++.dg/cpp2a/nodiscard-constructor2.C 2021-03-03 
20:34:33.416257158 +0100
@@ -0,0 +1,17 @@
+// PR c++/99362
+// { dg-do compile { target c++20 } }
+
+struct S {
+  [[nodiscard]] S() {}
+  S(int) {}
+};
+
+int main()
+{
+  S s;
+  S(); // { dg-warning "ignoring return value" }
+  (void)(S());
+  S t = 1;
+  S(1);
+  (void)(S(1));
+}
--- gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C.jj  2020-11-10 
10:21:27.272096866 +0100
+++ gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C 2021-03-03 20:31:11.115464565 
+0100
@@ -1,6 +1,6 @@
 /* nodiscard attribute tests  */
 /* { dg-do compile { target c++20 } 

[r10-9413 Regression] FAIL: gcc.dg/attr-flatten-1.c (test for warnings, line 13) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

d455130553544ee838b5215e76ccad22304cde39 is the first bad commit
commit d455130553544ee838b5215e76ccad22304cde39
Author: Jason Merrill 
Date:   Thu Feb 11 22:01:19 2021 -0500

cgraph: flatten and same_body aliases [PR96078]

caused

FAIL: gcc.dg/attr-flatten-1.c  (test for warnings, line 13)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-10/releases/gcc-10/r10-9413/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="dg.exp=gcc.dg/attr-flatten-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/attr-flatten-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/attr-flatten-1.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/attr-flatten-1.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)

[PATCH] expand: Fix ICE in store_bit_field_using_insv [PR93235]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs on aarch64.  The problem is that
op0 is (subreg:HI (reg:HF ...) 0) and because we can't create a SUBREG of a
SUBREG and aarch64 doesn't have HImode insv, only SImode insv,
store_bit_field_using_insv tries to create (subreg:SI (reg:HF ...) 0)
which is not valid for the target and so gen_rtx_SUBREG ICEs.

The following patch fixes it by punting if the to be created SUBREG
doesn't validate, callers of store_bit_field_using_insv can handle
the fallback.

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

2021-03-03  Jakub Jelinek  

PR middle-end/93235
* expmed.c (store_bit_field_using_insv): Return false of xop0 is a
SUBREG and a SUBREG to op_mode can't be created.

* gcc.target/aarch64/pr93235.c: New test.

--- gcc/expmed.c.jj 2021-01-04 10:25:39.761223316 +0100
+++ gcc/expmed.c2021-03-03 19:22:41.249301351 +0100
@@ -629,9 +629,16 @@ store_bit_field_using_insv (const extrac
   /* If xop0 is a register, we need it in OP_MODE
 to make it acceptable to the format of insv.  */
   if (GET_CODE (xop0) == SUBREG)
-   /* We can't just change the mode, because this might clobber op0,
-  and we will need the original value of op0 if insv fails.  */
-   xop0 = gen_rtx_SUBREG (op_mode, SUBREG_REG (xop0), SUBREG_BYTE (xop0));
+   {
+ /* If such a SUBREG can't be created, give up.  */
+ if (!validate_subreg (op_mode, GET_MODE (SUBREG_REG (xop0)),
+   SUBREG_REG (xop0), SUBREG_BYTE (xop0)))
+   return false;
+ /* We can't just change the mode, because this might clobber op0,
+and we will need the original value of op0 if insv fails.  */
+ xop0 = gen_rtx_SUBREG (op_mode, SUBREG_REG (xop0),
+SUBREG_BYTE (xop0));
+   }
   if (REG_P (xop0) && GET_MODE (xop0) != op_mode)
xop0 = gen_lowpart_SUBREG (op_mode, xop0);
 }
--- gcc/testsuite/gcc.target/aarch64/pr93235.c.jj   2021-03-03 
19:28:47.743300618 +0100
+++ gcc/testsuite/gcc.target/aarch64/pr93235.c  2021-03-03 19:28:27.247524328 
+0100
@@ -0,0 +1,12 @@
+/* PR middle-end/93235 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-strict-aliasing" } */
+
+struct sfp16 { __fp16 f; };
+struct sfp16
+foo (short x)
+{
+  struct sfp16 a;
+  *(short*) = x;
+  return a;
+}

Jakub

[PATCH] c-ppoutput: Fix preprocessing ICE on very large line number [PR99325]

[Jakub Jelinek via Gcc-patches]

Hi!

In libcpp, lines are represented as linenum_type, which is unsigned int.
The following testcases ICE because maybe_print_line_1 is sometimes called
with UNKNOWN_LOCATION (e.g. at pragma eof) and while most of the time
the
   && src_line >= print.src_line
   && src_line < print.src_line + 8
check doesn't succeed for the src_line of 0 from UNKNOWN_LOCATION, when
print.src_line is from very large line numbers (UINT_MAX - 7 and above)
it succeeds (with UB on the compiler side) but src_file is NULL for
UNKNOWN_LOCATION and so the strcmp call ICEs.
As print.src_line can easily wrap around, this patch changes its type
to unsigned int to match libcpp, so that we don't invoke UB in the compiler.
For print.src_line of UINT_MAX - 7 and above, src_line from UNKNOWN_LOCATION
will not pass that test anymore, but when it wraps around to 0, it can,
so I've also added a check for src_loc != UNKNOWN_LOCATION (or, if
preferred, could be src_file != NULL).
Besides fixing the ICE and UB in the compiler, I believe worst case the
patch will cause printing a few more line directives in the preprocessed
source around the wrapping from lines UINT_MAX - 7 to 0 (but less
around the wrapping from INT_MAX to INT_MAX + 1U), but I think those
are exceptional cases (sources with > 2billion lines are rare and
we warn or error on #line > INT_MAX).

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

2021-03-03  Jakub Jelinek  

PR c/99325
* c-ppoutput.c (print): Change src_line type from int to unsigned.
(token_streamer::stream) Likewise.
(maybe_print_line_1): Likewise.  Don't strcmp src_file if src_loc is
UNKNOWN_LOCATION.

* gcc.dg/cpp/line11.c: New test.
* gcc.dg/cpp/line12.c: New test.

--- gcc/c-family/c-ppoutput.c.jj2021-01-04 10:25:50.400102848 +0100
+++ gcc/c-family/c-ppoutput.c   2021-03-03 17:37:26.296185908 +0100
@@ -32,7 +32,7 @@ static struct
   FILE *outf;  /* Stream to write to.  */
   const cpp_token *prev;   /* Previous token.  */
   const cpp_token *source; /* Source token for spacing.  */
-  int src_line;/* Line number currently being written. 
 */
+  unsigned src_line;   /* Line number currently being written.  */
   bool printed;/* True if something output at line.  */
   bool first_time; /* pp_file_change hasn't been called yet.  */
   bool prev_was_system_token;  /* True if the previous token was a
@@ -213,7 +213,7 @@ token_streamer::stream (cpp_reader *pfil
   /* Subtle logic to output a space if and only if necessary.  */
   if (avoid_paste)
 {
-  int src_line = LOCATION_LINE (loc);
+  unsigned src_line = LOCATION_LINE (loc);
 
   if (print.source == NULL)
print.source = token;
@@ -237,7 +237,7 @@ token_streamer::stream (cpp_reader *pfil
 }
   else if (token->flags & PREV_WHITE)
 {
-  int src_line = LOCATION_LINE (loc);
+  unsigned src_line = LOCATION_LINE (loc);
 
   if (src_line != print.src_line
  && do_line_adjustments
@@ -437,7 +437,7 @@ static bool
 maybe_print_line_1 (location_t src_loc, FILE *stream)
 {
   bool emitted_line_marker = false;
-  int src_line = LOCATION_LINE (src_loc);
+  unsigned src_line = LOCATION_LINE (src_loc);
   const char *src_file = LOCATION_FILE (src_loc);
 
   /* End the previous line of text.  */
@@ -451,6 +451,7 @@ maybe_print_line_1 (location_t src_loc,
   if (!flag_no_line_commands
   && src_line >= print.src_line
   && src_line < print.src_line + 8
+  && src_loc != UNKNOWN_LOCATION
   && strcmp (src_file, print.src_file) == 0)
 {
   while (src_line > print.src_line)
--- gcc/testsuite/gcc.dg/cpp/line11.c.jj2021-03-03 17:45:22.353036566 
+0100
+++ gcc/testsuite/gcc.dg/cpp/line11.c   2021-03-03 17:47:27.021670988 +0100
@@ -0,0 +1,6 @@
+/* PR c/99325 */
+/* { dg-do preprocess } */
+/* { dg-options "-pedantic" } */
+
+#line 4294967295   /* { dg-warning "line number out of range" } */
+#pragma message "foo"
--- gcc/testsuite/gcc.dg/cpp/line12.c.jj2021-03-03 17:45:24.690011266 
+0100
+++ gcc/testsuite/gcc.dg/cpp/line12.c   2021-03-03 17:47:33.121604153 +0100
@@ -0,0 +1,6 @@
+/* PR c/99325 */
+/* { dg-do preprocess } */
+/* { dg-options "-pedantic" } */
+
+#line 9223372036854775807  /* { dg-warning "line number out of range" } */
+#pragma message "foo"

Jakub

[PATCH] sim: drop dep on configure-gdb

[Mike Frysinger via Gcc-patches]

I'm not entirely sure why this is here since the sim doesn't use
anything from the gdb/ dir directly, and the commit that added it
included a bunch more changes and doesn't seem to call out this
dep specifically.

ChangeLog:

* Makefile.def: Remove all-sim dependency on configure-gdb.
* Makefile.in: Regenerated.
---
 Makefile.def | 1 -
 Makefile.in  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Makefile.def b/Makefile.def
index 3e38f61193ff..df8ccfb24c3d 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -547,7 +547,6 @@ dependencies = { module=all-sim; on=all-libiberty; };
 dependencies = { module=all-sim; on=all-bfd; };
 dependencies = { module=all-sim; on=all-opcodes; };
 dependencies = { module=all-sim; on=all-readline; };
-dependencies = { module=all-sim; on=configure-gdb; };
 
 // Other host modules.
 dependencies = { module=all-fastjar; on=all-zlib; };
diff --git a/Makefile.in b/Makefile.in
index 03785200dc71..047be0255e26 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -61522,7 +61522,6 @@ install-strip-sid: maybe-install-strip-tcl
 install-sid: maybe-install-tk
 install-strip-sid: maybe-install-strip-tk
 all-sim: maybe-all-readline
-all-sim: maybe-configure-gdb
 all-fastjar: maybe-all-build-texinfo
 all-libctf: all-libiberty
 all-stage1-libctf: all-stage1-libiberty
-- 
2.30.0

[committed] libgomp: Use sizeof(void*) based checks instead of looking through $CC $CFLAGS for -m32/-mx32

[Jakub Jelinek via Gcc-patches]

On Thu, Jan 14, 2021 at 07:18:13PM +0100, Thomas Schwinge wrote:
>   libgomp/
>   PR libgomp/65099
>   * plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
>   configurations.
>   * configure: Regenerate.
>   * plugin/plugin-nvptx.c (nvptx_get_num_devices): Remove 64-bit
>   check.

Some gcc configurations default to -m32 but support -m64 too.  This patch
just makes the ILP32 tests more reliable by following what e.g. libsanitizer
configury does.  Perhaps we should incrementally also handle there
| i?86-*-*
I didn't change case to if because that would require reindenting the whole
large block.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2021-03-04  Jakub Jelinek  

* configure.ac: Add AC_CHECK_SIZEOF([void *]).
* plugin/configfrag.ac: Check $ac_cv_sizeof_void_p value instead of
checking of -m32 or -mx32 options on the command line.
* config.h.in: Regenerated.
* configure: Regenerated.

--- libgomp/configure.ac.jj 2020-07-28 15:39:10.148754303 +0200
+++ libgomp/configure.ac2021-03-03 14:41:21.964355951 +0100
@@ -221,6 +221,8 @@ if test x$libgomp_offloaded_only = xyes;
 [Define to 1 if building libgomp for an accelerator-only target.])
 fi
 
+AC_CHECK_SIZEOF([void *])
+
 m4_include([plugin/configfrag.ac])
 
 # Check for functions needed.
--- libgomp/plugin/configfrag.ac.jj 2021-01-14 19:34:06.164423884 +0100
+++ libgomp/plugin/configfrag.ac2021-03-03 14:45:45.374070228 +0100
@@ -160,8 +160,8 @@ if test x"$enable_offload_targets" != x;
   nvptx*)
case "${target}" in
  aarch64*-*-* | powerpc64le-*-* | x86_64-*-*)
-   case " ${CC} ${CFLAGS} " in
- *" -m32 "* | *" -mx32 "*)
+   case "$ac_cv_sizeof_void_p" in
+ 4)
# PR libgomp/65099: Currently, we only support offloading in
# 64-bit configurations.
PLUGIN_NVPTX=0
@@ -218,8 +218,8 @@ if test x"$enable_offload_targets" != x;
   amdgcn*)
case "${target}" in
  x86_64-*-*)
-   case " ${CC} ${CFLAGS} " in
- *" -m32 "*|*" -mx32 "*)
+   case "$ac_cv_sizeof_void_p" in
+ 4)
PLUGIN_GCN=0
;;
  *)
--- libgomp/config.h.in.jj  2020-08-03 22:54:51.483530741 +0200
+++ libgomp/config.h.in 2021-03-03 14:46:07.965788364 +0100
@@ -183,6 +183,9 @@
 /* Define if all infrastructure, needed for plugins, is supported. */
 #undef PLUGIN_SUPPORT
 
+/* The size of `void *', as computed by sizeof. */
+#undef SIZEOF_VOID_P
+
 /* Define to 1 if you have the ANSI C header files. */
 #undef STDC_HEADERS
 
--- libgomp/configure.jj2021-01-14 19:34:06.140424158 +0100
+++ libgomp/configure   2021-03-03 14:46:05.317821453 +0100
@@ -2058,60 +2058,6 @@ fi
 
 } # ac_fn_c_check_header_mongrel
 
-# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
-# ---
-# Tests whether TYPE exists after having included INCLUDES, setting cache
-# variable VAR accordingly.
-ac_fn_c_check_type ()
-{
-  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
-$as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  eval "$3=no"
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof ($2))
-return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof (($2)))
-   return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-
-else
-  eval "$3=yes"
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-eval ac_res=\$$3
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
-$as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
-
-} # ac_fn_c_check_type
-
 # ac_fn_c_compute_int LINENO EXPR VAR INCLUDES
 # 
 # Tries to find the compile-time value of EXPR in a program that includes
@@ -2294,6 +2240,60 @@ rm -f conftest.val
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_compute_int
+
+# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
+# ---
+# Tests whether TYPE exists after having included INCLUDES, setting cache
+# variable VAR accordingly.
+ac_fn_c_check_type ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval \${$3+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  eval "$3=no"
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext

Re: [PATCH] coroutines: Correct frame capture of compiler temps [PR95591+4].

[Iain Sandoe]

Iain Sandoe  wrote:

> Jason Merrill  wrote:
> 
>> I notice this patch includes
>> 
>> +  var_nest_node () = default;
>> 
>> which will break GCC 10 bootstrap with a C++98 compiler; we only
>> switched to C++11 for GCC 11.
> 
> Hmm, the patch was already backported…
> … I will fix this.
> 
> I missed the warning during testing.

We set -std=gnu++98 for the stage1 compiler, which does warn about this 
(although there
is a lot of warning output from a bootstrap, it’s easy to miss one).
I’m mostly bootstrapping with GCC-7.5 and it appears that this does not 
actually produce
any error even if one actually uses the defaulted ctor (at least in a trivial 
test).

=  anyway ….

OK for gcc-10?
this removes the warning from the stage #1.

thanks
Iain


== 

[PATCH] coroutines : Avoid a C++11ism.

The master version of the code uses a defaulted CTOR, which had
been inadvertently backported to gcc-10.  Fixed thus.

gcc/cp/ChangeLog:

* coroutines.cc (struct var_nest_node): Provide a default
CTOR.
---
 gcc/cp/coroutines.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 9133f024434..4902d1a4c4f 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2697,7 +2697,9 @@ find_interesting_subtree (tree *expr_p, int *dosub, void 
*d)
 
 struct var_nest_node
 {
-  var_nest_node () = default;
+  var_nest_node ()
+: var(NULL_TREE), init(NULL_TREE),
+  prev(NULL), next(NULL), then_cl(NULL), else_cl(NULL) {}
   var_nest_node (tree v, tree i, var_nest_node *p, var_nest_node *n)
 : var(v), init(i), prev(p), next(n)
 {
-- 
2.24.1

Re: [PATCH] middle-end/97855 - fix diagnostic with default pretty printer

[Richard Biener]

On Wed, 3 Mar 2021, Richard Biener wrote:

> On Wed, 3 Mar 2021, David Malcolm wrote:
> 
> > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > > On Tue, 2 Mar 2021, Martin Sebor wrote:
> > > 
> > > > On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> > > > > 
> > > > > 
> > > > > On 3/1/21 1:39 AM, Richard Biener wrote:
> > > > > > The default diagnostic tree printer relies on dump_generic_node
> > > > > > which
> > > > > > for some reason manages to clobber the diagnostic pretty-
> > > > > > printer state
> > > > > > so we see garbled diagnostics like
> > > > > > 
> > > > > > /home/rguenther/src/trunk/gcc/calls.c: In function
> > > > > > 'expand_call':
> > > > > > D.6750.coeffs[0]'/home/rguenther/src/trunk/gcc/dojump.c:118:28:
> > > > > > warning:
> > > > > > may be used uninitialized in this function [-Wmaybe-
> > > > > > uninitialized]
> > > > > > 
> > > > > > when the diagnostic is emitted by the LTO fronted.  The
> > > > > > following
> > > > > > approach using a temporary pretty-printer for the
> > > > > > dump_generic_node
> > > > > > call fixes this for some unknown reason and we issue
> > > > > > 
> > > > > > /home/rguenther/src/trunk/gcc/calls.c: In function
> > > > > > 'expand_call':
> > > > > > /home/rguenther/src/trunk/gcc/dojump.c:118:28: warning:
> > > > > > 'MEM[(struct
> > > > > > poly_int *)].D.6750.coeffs[0]' may be used uninitialized
> > > > > > in this
> > > > > > function [-Wmaybe-uninitialized]
> > > > > > 
> > > > > > [LTO] Bootstrapped and tested on x86_64-unknown-linux-gnu, OK
> > > > > > for trunk?
> > > > > > 
> > > > > > Thanks,
> > > > > > Richard.
> > > > > > 
> > > > > > 2021-02-26  Richard Biener  
> > > > > > 
> > > > > >  PR middle-end/97855
> > > > > >  * tree-diagnostic.c (default_tree_printer): Use a temporary
> > > > > >  pretty-printer when formatting a tree via dump_generic_node.
> > > > > It'd be good to know why this helps, but I trust your judgment
> > > > > that this
> > > > > is an improvement.
> > > > 
> > > > I don't know if it's related but pr98492 tracks a problem in the
> > > > C++
> > > > front end caused by reinitializing the pretty printer in a number
> > > > of
> > > > functions in cp/error.c.  When one of these functions is called
> > > > while
> > > > the pretty printer is formatting something, the effect of
> > > > the reinitialization is to drop the already formatted contents
> > > > of the printer's buffer.
> > > > 
> > > > IIRC, I tripped over this when working on the MEM_REF formatting
> > > > improvement for -Wuninitialized.
> > > 
> > > I've poked quite a bit with breakpoints on suspicious pretty-printer
> > > functions and watch points on the pp state but found nothing in the
> > > case I was looking at (curiously also -Wuninitialized).  But I also
> > > wasn't able to understand why the caller should work at all.  And
> > > yes, the C/C++ tree printers also simply format to the passed
> > > pretty-printer...
> > > 
> > > Hoping that David could shed some light on how this should play
> > > together.
> > 
> > This looks very much like the issue I ran into in
> > c46d057f55748520e819dcd8e04bca71be9902b2 (and, in retrospect, that
> > commit may have just been papering over the problem).
> > 
> > The issue there was that pp_printf is not reentrant - if a handler for
> > a pp_printf format code ends up making a nested call to pp_printf, I
> > got behavior that looks like what you're seeing.
> > 
> > That said, I've been poring over the output in PR middle-end/97855 and
> > comparing it to the various pretty-printer usage in the tree, and I'm
> > not seeing anywhere where a pp_printf seems to be used when generating:
> >   MEM[(struct poly_int *) + 8B].D.6750.coeffs[0]
> 
> I think it's the D.6750 which is printed via
> 
>   else if (TREE_CODE (node) == DEBUG_EXPR_DECL)
> {
>   if (flags & TDF_NOUID)
> pp_string (pp, "D#");
>   else
> pp_printf (pp, "D#%i", DEBUG_TEMP_UID (node));
> 
> because this is a DECL_DEBUG_EXPR.  One could experiment with
> avoiding pp_printf in dump_decl_name.
> 
> > Is there a minimal reproducer (or a .i file?)
> 
> No, you need to do a LTO bootstrap, repeat the link step of
> for example cc1 with -v -save-temps and pick an ltrans invocation
> that exhibits the issue ...
> 
> I can poke at the above tomorrow again.  I suppose we could
> also add some checking-assert into the pp_printf code at
> the problematic place (or is any recursion bogus?) to catch
> the case with an ICE.

It ICEs _a_ _lot_.

diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c
index ade1933f86a..7755157a7d7 100644
--- a/gcc/pretty-print.c
+++ b/gcc/pretty-print.c
@@ -1069,6 +1069,11 @@ static const char *get_end_url_string 
(pretty_printer *);
 void
 pp_format (pretty_printer *pp, text_info *text)
 {
+  /* pp_format is not reentrant.  */
+  static bool in_pp_format;
+  gcc_checking_assert (!in_pp_format);
+  in_pp_format = true;
+
   output_buffer *buffer = pp_buffer (pp);
   

Re: [PATCH] middle-end/97855 - avoid recursing into pp_printf

[Jakub Jelinek via Gcc-patches]

On Thu, Mar 04, 2021 at 09:08:35AM +0100, Richard Biener wrote:
> 2021-03-04  Richard Biener  
> 
>   PR middle-end/97855
>   * tree-pretty-print.c: Poison pp_printf.
>   (dump_decl_name): Avoid use of pp_printf.
>   (dump_block_node): Likewise.
>   (dump_generic_node): Likewise.

> char c = TREE_CODE (node) == CONST_DECL ? 'C' : 'D';
> +   pp_character (pp, c);
> +   pp_character (pp, uid_sep);
> if (flags & TDF_NOUID)
> - pp_printf (pp, "%c.", c);
> + pp_string (pp, "");
> else
> - pp_printf (pp, "%c%c%u", c, uid_sep, DECL_UID (node));
> + pp_decimal_int (pp, (int) DECL_UID (node));

I think it would be better if this patch didn't change behavior.
So yes, pp_decimal_int is ok for previous %d or %i, but %u
should be done with
pp_scalar (pp, "%u", DECL_UID (node));
(or pp_unsigned_wide_integer (pp, DECL_UID (node));).

>   }
>  }
>if ((flags & TDF_ALIAS) && DECL_PT_UID (node) != DECL_UID (node))
>  {
>if (flags & TDF_NOUID)
> - pp_printf (pp, "ptD.");
> + pp_string (pp, "ptD.");
>else
> - pp_printf (pp, "ptD.%u", DECL_PT_UID (node));
> + {
> +   pp_string (pp, "ptD.");
> +   pp_decimal_int (pp, (int) DECL_PT_UID (node));

Ditto here, pp_scalar (pp, "%u", DECL_PT_UID (node));

> @@ -2165,9 +2207,16 @@ dump_generic_node (pretty_printer *pp, tree node, int 
> spc, dump_flags_t flags,
> else
>   {
> if (flags & TDF_GIMPLE)
> - pp_printf (pp, "", DECL_UID (node));
> + {
> +   pp_character (pp, 'D');
> +   pp_decimal_int (pp, (int) DECL_UID (node));

Here too.
> + }
> else
> - pp_printf (pp, "", DECL_UID (node));
> + {
> +   pp_string (pp, " +   pp_decimal_int (pp, (int) DECL_UID (node));

And here.
> +   pp_character (pp, '>');
> + }
>   }
>   }
>break;
> @@ -3021,9 +3070,12 @@ dump_generic_node (pretty_printer *pp, tree node, int 
> spc, dump_flags_t flags,
> pp_string (pp, ", ivdep");
> break;
>   case annot_expr_unroll_kind:
> -   pp_printf (pp, ", unroll %d",
> -  (int) TREE_INT_CST_LOW (TREE_OPERAND (node, 2)));
> -   break;
> +   {
> + pp_string (pp, ", unroll ");
> + pp_decimal_int (pp,
> + (int) TREE_INT_CST_LOW (TREE_OPERAND (node, 2)));
> + break;
> +   }
>   case annot_expr_no_vector_kind:
> pp_string (pp, ", no-vector");
> break;
> @@ -3205,7 +3257,8 @@ dump_generic_node (pretty_printer *pp, tree node, int 
> spc, dump_flags_t flags,
>dump_generic_node (pp, CHREC_LEFT (node), spc, flags, false);
>pp_string (pp, ", +, ");
>dump_generic_node (pp, CHREC_RIGHT (node), spc, flags, false);
> -  pp_printf (pp, "}_%u", CHREC_VARIABLE (node));
> +  pp_string (pp, "}_");
> +  pp_decimal_int (pp, (int)CHREC_VARIABLE (node));

And here.

Ok with those changes if it passes testing.

Jakub

Re: [PATCH] C++: target attribute - local decl

[Martin Liška]

On 3/2/21 6:57 PM, Jason Merrill wrote:

On 3/2/21 5:34 AM, Martin Liška wrote:

On 3/1/21 8:58 PM, Jason Merrill wrote:

On 3/1/21 11:59 AM, Martin Liška wrote:

On 3/1/21 5:36 PM, Jason Merrill wrote:

On 3/1/21 7:43 AM, Martin Liška wrote:

On 2/22/21 11:53 PM, Jason Merrill wrote:

The problem seems to be with the handling of local decls.  If 
DECL_LOCAL_DECL_P, you need to look at DECL_LOCAL_DECL_ALIAS to find the 
namespace-scope decl.  But then if there is no preceding namespace-scope 
declaration, the new decl created by push_local_extern_decl_alias doesn't have 
a cgraph node, either. I guess maybe_function_versions also needs to look 
through DECL_LOCAL_DECL_ALIAS.


Ah, I see. Are you sure about the name 'maybe_function_versions'? I can't find 
it.


Ah, it's maybe_version_functions, sorry.


Thanks, I see the function now.
So about your guess:


I guess maybe_function_versions also needs to look through 
DECL_LOCAL_DECL_ALIAS.


Do you mean maybe_version_functions's argument 'record' should depend on 
DECL_LOCAL_DECL_ALIAS of newdecl/oldddecl
(if present)? Or that DECL_FUNCTION_VERSIONED should be set for 
DECL_LOCAL_DECL_ALIASes of the newdecl/olddecl
function declarations?


The latter.


I see, but will not help us. Problem is that
#2  0x015d8899 in ix86_get_function_versions_dispatcher 
(decl=0x77755000) at 
/home/marxin/Programming/gcc/gcc/config/i386/i386-features.c:2862

is called for a declaration for which

Breakpoint 5, maybe_version_functions (newdecl=, 
olddecl=, record=false) at 
/home/marxin/Programming/gcc/gcc/cp/decl.c:1118

is called with record=false. So that cgraph_node is not created for it.

Or is a possible solution that get_function_version_dispatcher should look 
through the DECL_LOCAL_DECL_ALIAS?


Yes, I was thinking both that function and maybe_version_functions.

Jason



All right, the following patch fixes that.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From 192a6ad5840c425a940ac724e27e0d25f7b0 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 3 Mar 2021 09:38:55 +0100
Subject: [PATCH] c++: support target attr for DECL_LOCAL_DECL_P fns

gcc/cp/ChangeLog:

	PR c++/99108
	* call.c (get_function_version_dispatcher): Understand
	DECL_LOCAL_DECL_ALIAS.
	* decl.c (record_function_versions): New.
	(maybe_version_functions): Call record_function_versions
	for both declarations and DECL_LOCAL_DECL_ALIAS aliases.

gcc/testsuite/ChangeLog:

	PR c++/99108
	* g++.target/i386/pr99108.C: New test.
---
 gcc/cp/call.c   |  4 +++
 gcc/cp/decl.c   | 40 +++--
 gcc/testsuite/g++.target/i386/pr99108.C | 18 +++
 3 files changed, 47 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/i386/pr99108.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 123f06b1f2b..117f1755191 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8467,6 +8467,10 @@ get_function_version_dispatcher (tree fn)
 {
   tree dispatcher_decl = NULL;
 
+  if (DECL_LOCAL_DECL_P (fn)
+  && DECL_LOCAL_DECL_ALIAS (fn) != NULL_TREE)
+fn = DECL_LOCAL_DECL_ALIAS (fn);
+
   gcc_assert (TREE_CODE (fn) == FUNCTION_DECL
 	  && DECL_FUNCTION_VERSIONED (fn));
 
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1742e286d9f..69bf3011a5a 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1108,6 +1108,23 @@ decls_match (tree newdecl, tree olddecl, bool record_versions /* = true */)
   return types_match;
 }
 
+/* Register function version for DECL that would point to VERSION.
+   If RECORD set to true, register function version in call graph.  */
+
+static void
+record_function_versions (tree decl, tree version, bool record)
+{
+  if (!DECL_FUNCTION_VERSIONED (version))
+{
+  DECL_FUNCTION_VERSIONED (version) = 1;
+  if (DECL_ASSEMBLER_NAME_SET_P (version))
+	mangle_decl (version);
+}
+
+  if (record && decl != version)
+cgraph_node::record_function_versions (decl, version);
+}
+
 /* NEWDECL and OLDDECL have identical signatures.  If they are
different versions adjust them and return true.
If RECORD is set to true, record function versions.  */
@@ -1118,22 +1135,15 @@ maybe_version_functions (tree newdecl, tree olddecl, bool record)
   if (!targetm.target_option.function_versions (newdecl, olddecl))
 return false;
 
-  if (!DECL_FUNCTION_VERSIONED (olddecl))
-{
-  DECL_FUNCTION_VERSIONED (olddecl) = 1;
-  if (DECL_ASSEMBLER_NAME_SET_P (olddecl))
-	mangle_decl (olddecl);
-}
-
-  if (!DECL_FUNCTION_VERSIONED (newdecl))
-{
-  DECL_FUNCTION_VERSIONED (newdecl) = 1;
-  if (DECL_ASSEMBLER_NAME_SET_P (newdecl))
-	mangle_decl (newdecl);
-}
+  record_function_versions (olddecl, olddecl, record);
+  if (DECL_LOCAL_DECL_P (olddecl)
+  && DECL_LOCAL_DECL_ALIAS (olddecl) != NULL_TREE)
+record_function_versions (olddecl, DECL_LOCAL_DECL_ALIAS (olddecl), true);
 
-  if (record)
-

[PATCH] middle-end/97855 - avoid recursing into pp_printf

[Richard Biener]

When diagnostic messages use pretty-printer formats like %D or %E
the pp_printf invocation can end up in tree pretty-printers which
then have to avoid using pp_printf themselves since this function
is not re-entrant.

The following removes all pp_printf uses from tree-pretty-print.c
fixing the observed malformed diagnostics.  It also poisons the
identifier so new uses are less likely to creep in.

{,LTO} bootstrap and regtest on x86_64-unknown-linux-gnu in progress.

2021-03-04  Richard Biener  

PR middle-end/97855
* tree-pretty-print.c: Poison pp_printf.
(dump_decl_name): Avoid use of pp_printf.
(dump_block_node): Likewise.
(dump_generic_node): Likewise.
---
 gcc/tree-pretty-print.c | 95 -
 1 file changed, 74 insertions(+), 21 deletions(-)

diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 986f75d1d5f..7843042e53c 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -36,6 +36,11 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple.h"
 #include "fold-const.h"
 
+/* Routines in this file get invoked via the default tree printer
+   used by diagnostics and thus they are called from pp_printf which
+   isn't reentrant.  Avoid using pp_printf in this file.  */
+#pragma GCC poison pp_printf
+
 /* Disable warnings about quoting issues in the pp_xxx calls below
that (intentionally) don't follow GCC diagnostic conventions.  */
 #if __GNUC__ >= 10
@@ -293,29 +298,41 @@ dump_decl_name (pretty_printer *pp, tree node, 
dump_flags_t flags)
   if ((flags & TDF_UID) || name == NULL_TREE)
 {
   if (TREE_CODE (node) == LABEL_DECL && LABEL_DECL_UID (node) != -1)
-   pp_printf (pp, "L%c%d", uid_sep, (int) LABEL_DECL_UID (node));
+   {
+ pp_character (pp, 'L');
+ pp_character (pp, uid_sep);
+ pp_decimal_int (pp, (int) LABEL_DECL_UID (node));
+   }
   else if (TREE_CODE (node) == DEBUG_EXPR_DECL)
{
  if (flags & TDF_NOUID)
pp_string (pp, "D#");
  else
-   pp_printf (pp, "D#%i", DEBUG_TEMP_UID (node));
+   {
+ pp_string (pp, "D#");
+ pp_decimal_int (pp, (int) DEBUG_TEMP_UID (node));
+   }
}
   else
{
  char c = TREE_CODE (node) == CONST_DECL ? 'C' : 'D';
+ pp_character (pp, c);
+ pp_character (pp, uid_sep);
  if (flags & TDF_NOUID)
-   pp_printf (pp, "%c.", c);
+   pp_string (pp, "");
  else
-   pp_printf (pp, "%c%c%u", c, uid_sep, DECL_UID (node));
+   pp_decimal_int (pp, (int) DECL_UID (node));
}
 }
   if ((flags & TDF_ALIAS) && DECL_PT_UID (node) != DECL_UID (node))
 {
   if (flags & TDF_NOUID)
-   pp_printf (pp, "ptD.");
+   pp_string (pp, "ptD.");
   else
-   pp_printf (pp, "ptD.%u", DECL_PT_UID (node));
+   {
+ pp_string (pp, "ptD.");
+ pp_decimal_int (pp, (int) DECL_PT_UID (node));
+   }
 }
 }
 
@@ -1328,10 +1345,16 @@ dump_block_node (pretty_printer *pp, tree block, int 
spc, dump_flags_t flags)
 {
   tree t;
 
-  pp_printf (pp, "BLOCK #%d ", BLOCK_NUMBER (block));
+  pp_string (pp, "BLOCK #");
+  pp_decimal_int (pp, BLOCK_NUMBER (block));
+  pp_character (pp, ' ');
 
   if (flags & TDF_ADDRESS)
-pp_printf (pp, "[%p] ", (void *) block);
+{
+  pp_character (pp, '[');
+  pp_scalar (pp, "%p", (void *) block);
+  pp_string (pp, "] ");
+}
 
   if (TREE_ASM_WRITTEN (block))
 pp_string (pp, "[written] ");
@@ -1650,7 +1673,11 @@ dump_generic_node (pretty_printer *pp, tree node, int 
spc, dump_flags_t flags,
   is_expr = EXPR_P (node);
 
   if (is_stmt && (flags & TDF_STMTADDR))
-pp_printf (pp, "<&%p> ", (void *)node);
+{
+  pp_string (pp, "<&");
+  pp_scalar (pp, "%p", (void *)node);
+  pp_string (pp, "> ");
+}
 
   if ((flags & TDF_LINENO) && EXPR_HAS_LOCATION (node))
 dump_location (pp, EXPR_LOCATION (node));
@@ -1857,9 +1884,13 @@ dump_generic_node (pretty_printer *pp, tree node, int 
spc, dump_flags_t flags,
  if (TYPE_IDENTIFIER (node))
dump_generic_node (pp, TYPE_NAME (node), spc, flags, false);
  else if (flags & TDF_NOUID)
-   pp_printf (pp, "");
+   pp_string (pp, "");
  else
-   pp_printf (pp, "", TYPE_UID (node));
+   {
+ pp_string (pp, "');
+   }
 
  pp_right_paren (pp);
  dump_function_declaration (pp, fnode, spc, flags);
@@ -2137,9 +2168,13 @@ dump_generic_node (pretty_printer *pp, tree node, int 
spc, dump_flags_t flags,
   else if (TYPE_NAME (node) && DECL_NAME (TYPE_NAME (node)))
dump_decl_name (pp, TYPE_NAME (node), flags);
   else if (flags & TDF_NOUID)
-   pp_printf (pp, "");
+   pp_string (pp, "");
   else
-   pp_printf (pp, "", TYPE_UID (node));
+   {
+ pp_string