[Bug c++/99901] [8/9/10/11 Regression] static const class var implemented with constexpr doesn't emit symbols in C++17 mode

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

[Bug tree-optimization/88975] ICE: Segmentation fault (in dominated_by_p)

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Solokha  ---
gcc-11.0.1-alpha20210404 snapshot (g:c3d3bb0f03dbd02512ab46979088ee8e22520c24)
accepts all three testcases w/o ICE. Is it a duplicate of PR99007?

[Bug c++/91241] [8/9/10 Regression] internal compiler error: symtab_node::verify failed

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |internal compiler error:|internal compiler error:
   |symtab_node::verify failed  |symtab_node::verify failed

--- Comment #15 from Jason Merrill  ---
Fixed for GCC 11 so far.

[Bug target/99924] New: ICE in vect_schedule_slp_node, at tree-vect-slp.c:6040

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 99924
   Summary: ICE in vect_schedule_slp_node, at tree-vect-slp.c:6040
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gfortran-11.0.1-alpha20210404 snapshot
(g:c3d3bb0f03dbd02512ab46979088ee8e22520c24) ICEs when compiling the following
testcase w/ -march=armv8.3-a -O1 -ftree-slp-vectorize
-fvect-cost-model=unlimited:

subroutine cunhj (tfn, asum, bsum)
  implicit none
  complex :: up, tfn, asum, bsum
  real :: ar

  up = tfn * ar
  bsum = up + ar
  asum = up + asum
  return
end subroutine cunhj

% aarch64-linux-gnu-gfortran-11.0.1 -march=armv8.3-a -O1 -ftree-slp-vectorize
-fvect-cost-model=unlimited -c ufhzvqzb.f90
during GIMPLE pass: slp
ufhzvqzb.f90:1:16:

1 | subroutine cunhj (tfn, asum, bsum)
  |^
internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.c:6040
0x7c377c vect_schedule_slp_node
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6040
0x123a4fc vect_schedule_scc
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6355
0x123a26f vect_schedule_scc
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6336
0x123a26f vect_schedule_scc
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6336
0x123a26f vect_schedule_scc
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6336
0x123a26f vect_schedule_scc
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6336
0x123ab5f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6471
0x123c4db vect_slp_region
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:4985
0x123c4db vect_slp_bbs
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:5095
0x123db1c vect_slp_function(function*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:5181
0x12444fa execute
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vectorizer.c:1450

[Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:55f40d968b0bd3be4478a9481e829a99ee0fa04f

commit r11-7998-g55f40d968b0bd3be4478a9481e829a99ee0fa04f
Author: Jason Merrill 
Date:   Mon Apr 5 22:50:44 2021 -0400

c++: mangling of lambdas in default args [PR91241]

In this testcase, the parms remembered in LAMBDA_EXPR_EXTRA_SCOPE are no
longer the parms of the FUNCTION_DECL they have as their DECL_CONTEXT, so
we
were mangling both lambdas as parm #0.  But since the parms are numbered
from right to left we don't need to need to find them in the FUNCTION_DECL,
we can measure their own DECL_CHAIN.

gcc/cp/ChangeLog:

PR c++/91241
* mangle.c (write_compact_number): Add sanity check.
(write_local_name): Use list_length for parm number.

gcc/testsuite/ChangeLog:

PR c++/91241
* g++.dg/abi/lambda-defarg1.C: New test.

[pushed] c++: mangling of lambdas in default args [PR91241]

[Jason Merrill via Gcc-patches]

In this testcase, the parms remembered in LAMBDA_EXPR_EXTRA_SCOPE are no
longer the parms of the FUNCTION_DECL they have as their DECL_CONTEXT, so we
were mangling both lambdas as parm #0.  But since the parms are numbered
from right to left we don't need to need to find them in the FUNCTION_DECL,
we can measure their own DECL_CHAIN.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/91241
* mangle.c (write_compact_number): Add sanity check.
(write_local_name): Use list_length for parm number.

gcc/testsuite/ChangeLog:

PR c++/91241
* g++.dg/abi/lambda-defarg1.C: New test.
---
 gcc/cp/mangle.c   | 11 ++-
 gcc/testsuite/g++.dg/abi/lambda-defarg1.C | 11 +++
 2 files changed, 13 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/abi/lambda-defarg1.C

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 6c111342b97..4399165ee23 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -1628,6 +1628,7 @@ write_literal_operator_name (tree identifier)
 static void
 write_compact_number (int num)
 {
+  gcc_checking_assert (num >= 0);
   if (num > 0)
 write_unsigned_number (num - 1);
   write_char ('_');
@@ -2027,15 +2028,7 @@ write_local_name (tree function, const tree local_entity,
   /* For this purpose, parameters are numbered from right-to-left.  */
   if (parm)
 {
-  tree t;
-  int i = 0;
-  for (t = DECL_ARGUMENTS (function); t; t = DECL_CHAIN (t))
-   {
- if (t == parm)
-   i = 1;
- else if (i)
-   ++i;
-   }
+  int i = list_length (parm);
   write_char ('d');
   write_compact_number (i - 1);
 }
diff --git a/gcc/testsuite/g++.dg/abi/lambda-defarg1.C 
b/gcc/testsuite/g++.dg/abi/lambda-defarg1.C
new file mode 100644
index 000..8c538581240
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/lambda-defarg1.C
@@ -0,0 +1,11 @@
+// PR c++/91241
+// { dg-do compile { target c++11 } }
+
+struct A {
+  int *b(const int & = []() -> int { return 0; }(),
+const int & = []() -> int { return 0; }());
+};
+int *A::b(const int &, const int &) { b(); return 0; }
+// { dg-final { scan-assembler "_ZN1A1bERKiS1_" } }
+// { dg-final { scan-assembler "_ZZN1A1bERKiS1_Ed_NKUlvE_clEv" } }
+// { dg-final { scan-assembler "_ZZN1A1bERKiS1_Ed0_NKUlvE_clEv" } }

base-commit: b07dd9b0d0e501a0083da79e2bca17041c007ec8
-- 
2.27.0

[Bug c++/99899] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29630

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Patrick Palka  ---
Fixed.

[Bug c++/99899] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29630

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:66de517b1c1dd22df7914f8e9a083cd5a73adbe2

commit r11-7997-g66de517b1c1dd22df7914f8e9a083cd5a73adbe2
Author: Patrick Palka 
Date:   Mon Apr 5 23:35:56 2021 -0400

c++: placeholder type constraint in structured binding [PR99899]

In this PR, we're crashing because the constraint handling inside
do_auto_deduction doesn't expect to see an adc_decomp_type context.
This patch fixes this by treating adc_decomp_type like adc_variable_type
or adc_return_type during placeholder type constraint checking.

Meanwhile, I noticed we weren't checking constraints at all when binding
an array via a structured binding, since do_auto_deduction would exit
early and bypass the constraint check.  This patch fixes this by
replacing the early exit with an appropriate setup of the 'targs'
vector.

gcc/cp/ChangeLog:

PR c++/99899
* pt.c (do_auto_deduction): Don't exit early when deducing the
array type of a structured binding.  Also handle adc_decomp_type
during constraint checking.

gcc/testsuite/ChangeLog:

PR c++/99899
* g++.dg/cpp2a/concepts-placeholder7.C: New test.
* g++.dg/cpp2a/concepts-placeholder8.C: New test.

[Bug c++/99901] [8/9/10/11 Regression] static const class var implemented with constexpr doesn't emit symbols in C++17 mode

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
 Ever confirmed|0   |1
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2021-04-06
Summary|static const class var  |[8/9/10/11 Regression]
   |implemented with constexpr  |static const class var
   |doesn't emit symbols in |implemented with constexpr
   |C++17 mode  |doesn't emit symbols in
   ||C++17 mode

--- Comment #1 from Patrick Palka  ---
Confirmed.  Seems to have started with r7-3808.

[Bug c++/99923] New: Rejects valid if statement with default argument concept

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99923
   Summary: Rejects valid if statement with default argument
concept
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/zPPMEaa33

template   concept C = true;
void foo() { if (C<>) return; }

gcc rejects this valid grammar with:

: In function 'void foo()':
:2:18: error: expected 'auto' or 'decltype(auto)' after 'C<>'
2 | void foo() { if (C<>) return; }
  |  ^~~

[Bug fortran/99922] Bind(C) with assumed length character should work

[kargl at gcc dot gnu.org via Gcc-bugs]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-04-06
 Status|UNCONFIRMED |NEW
 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Brad Richardson from comment #0)
> 
> So this is supposed to be allowed, and I can confirm that I can compile and
> execute the above example and obtain the expected result with Intel (ifort
> and icc).
> 

What result did Intel produce?

This patch suppresses the error message, which allows the code
to compile.  gfortran may produces wrong code.  Someone else can
investigate that issue

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 9039c9dca2a..b10a92ca234 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1549,19 +1549,21 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
 sym->ns->proc_name->name);
}

-  /* Character strings are only C interoperable if they have a
- length of 1.  */
-  if (sym->ts.type == BT_CHARACTER && !sym->attr.dimension)
+  /* In F2008 (and earlier?) a character string is only C
+interoperable if it has a length of 1.  With F2018, if the
+string is a dummy argument, it can have an assumed length if
+the formal argument is CFI_cdesc_t.  */
+  if (sym->ts.type == BT_CHARACTER && !sym->attr.dimension
+ && !((gfc_option.allow_std & GFC_STD_F2018) && sym->attr.dummy))
{
  gfc_charlen *cl = sym->ts.u.cl;
+
  if (!cl || !cl->length || cl->length->expr_type != EXPR_CONSTANT
   || mpz_cmp_si (cl->length->value.integer, 1) != 0)
{
- gfc_error ("Character argument %qs at %L "
-"must be length 1 because "
-"procedure %qs is BIND(C)",
-sym->name, >declared_at,
-sym->ns->proc_name->name);
+ gfc_error ("Character argument %qs at %L must be length 1 "
+"because procedure %qs is BIND(C)", sym->name, 
+>declared_at, sym->ns->proc_name->name);
  retval = false;
}
}

My GSoC proposal for the Rust frontend

[PKU via Gcc]

It’s about improving compiler dumps for the Rust frontend. Full proposal here: 
https://docs.google.com/document/d/1gyAOM-f3RyZh3HVpjmIMDSuQ5gBscal71sFY6XUMcHI/edit#

Yizhe

[Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

[Bug c++/86485] [8 Regression] "anonymous" maybe-uninitialized false positive with ternary operator

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|9.0 |
  Known to work||9.1.0
 CC||msebor at gcc dot gnu.org
   Last reconfirmed|2018-07-11 00:00:00 |2021-4-5

--- Comment #10 from Martin Sebor  ---
Confirming this is fixed in GCC 9 but still present in GCC 8.

[Bug middle-end/85872] False positive for -Wmaybe-unitialized (compile-time limit)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail|7.2.1, 8.1.0|10.2.0, 11.0, 5.5.0, 7.2.0,
   ||8.3.0, 9.1.0
   Last reconfirmed|2018-09-10 00:00:00 |2021-4-5

--- Comment #4 from Martin Sebor  ---
Confirmed with GCC 11 and that bumping up the conservative MAX_CHAIN_LEN limit
avoids the false positive.

[Bug fortran/99922] New: Bind(C) with assumed length character should work

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Bug ID: 99922
   Summary: Bind(C) with assumed length character should work
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: everythingfunctional at protonmail dot com
  Target Milestone: ---

As of (at least) Fortran 2018, bind(C) should be allowed for procedures with
assumed length character variables, as one can pass CFI_cdesc_t* from the C
side and it's supposed to work.

MWE below

! main.f90
program main
implicit none

interface
subroutine say_hello_c() bind(C)
end subroutine
end interface

call say_hello_c()
end program

! say_hello_fortran.f90
subroutine say_hello_fortran(name) bind(C)
use iso_c_binding, only: c_char

implicit none

character(len=*, kind=c_char), intent(in) :: name

print *, "Hello from Fortran, " // name // "!"
end subroutine

! say_hello_c.c
#include 
#include 

extern void say_hello_fortran(CFI_cdesc_t * name_descriptor);

void say_hello_c() {
char * name = "World";
CFI_cdesc_t name_descriptor;
int error_code = CFI_establish(
_descriptor,
name,
CFI_attribute_other,
CFI_type_char,
strlen(name),
0,
NULL);
say_hello_fortran(_descriptor);
}

Compiling say_hello_fortran.f90 gives the error

say_hello_fortran.f90:1:33:

1 | subroutine say_hello_fortran(name) bind(C)
  | 1
Error: Character argument ‘name’ at (1) must be length 1 because procedure
‘say_hello_fortran’ is BIND(C)

But the relevant text from the standard says (from section 18.3.6):

any dummy argument without the VALUE attribute corresponds to a formal
parameter of the prototype that is of a pointer type, and either
the dummy argument is a nonallocatable nonpointer variable of type CHARACTER
with assumed character length and the formal parameter is a pointer to
CFI_cdesc_t,

So this is supposed to be allowed, and I can confirm that I can compile and
execute the above example and obtain the expected result with Intel (ifort and
icc).

output of gfortran --version:
GNU Fortran (Ubuntu 10.2.0-13ubuntu1) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/99921] New: PowerPC xxeval has the wrong predicates

[meissner at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99921
   Summary: PowerPC xxeval has the wrong predicates
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I noticed that the insn that supports the PowerPC xxeval instruction uses the
predicate "altivec_register_operand".  It should use the predicate
"vsx_register_operand" (or "gpc_reg_operand") to allow the register allocator
to chose traditional floating point registers along with traditional Altivec
registers.

[Bug bootstrap/99920] New: [10 regression] ICE building gcc 10 on power 7 BE

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99920
   Summary: [10 regression] ICE building gcc 10 on power 7 BE
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:6aa75d3740c309aeead9c430a6779f4a347f4403, r10-9659

This occurs at this commit but it is not the source of it (I am still looking).

Configure used:  /home/seurer/gcc/git/gcc-10-test/configure
--enable-languages=c,fortran,c++ --with-cpu=power7 --enable-bootstrap
--enable-multilib

A whole bunch of ICEs like the following occur when building gcc on power 7 BE.
 It does not occurs on power 8 BE.

/home/seurer/gcc/git/build/gcc-10-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-10-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/sys-include
  -fno-checking -g -O2 -m32 -O2  -g -O2 -DIN_GCC-W -Wall -Wwrite-strings
-Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC
-mlong-double-128 -mno-minimal-toc -I. -I. -I../../.././gcc
-I/home/seurer/gcc/git/gcc-10-test/libgcc
-I/home/seurer/gcc/git/gcc-10-test/libgcc/.
-I/home/seurer/gcc/git/gcc-10-test/libgcc/../gcc
-I/home/seurer/gcc/git/gcc-10-test/libgcc/../include
-I/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/dpd
-I/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber -DHAVE_CC_TLS  -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
during GIMPLE pass: store-merging
In file included from /home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:56:
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c: In function '__muldi3':
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.h:219:20: internal compiler
error: Segmentation fault
  219 | #define __NDW(a,b) __ ## a ## di ## b
  |^~
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.h:273:18: note: in expansion of
macro '__NDW'
  273 | #define __muldi3 __NDW(mul,3)
  |  ^
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:548:1: note: in expansion of
macro '__muldi3'
  548 | __muldi3 (DWtype u, DWtype v)
  | ^~~~
0x111d588f crash_signal
/home/seurer/gcc/git/gcc-10-test/gcc/toplev.c:328
0x125d1930 trim_filename(char const*)
/home/seurer/gcc/git/gcc-10-test/gcc/diagnostic.c:1223
0x125d4273 fancy_abort(char const*, int, char const*)
/home/seurer/gcc/git/gcc-10-test/gcc/diagnostic.c:1778
0x10a76dab operand_compare::hash_operand(tree_node const*, inchash::hash&,
unsigned int)
/home/seurer/gcc/git/gcc-10-test/gcc/fold-const.c:3768
0x10a7766b inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
/home/seurer/gcc/git/gcc-10-test/gcc/fold-const.c:3919
0x1122c2af iterative_hash_expr
/home/seurer/gcc/git/gcc-10-test/gcc/tree.h:5207
0x11232c77 tree_operand_hash::hash(tree_node* const&)
/home/seurer/gcc/git/gcc-10-test/gcc/tree-hash-traits.h:34
0x1231a2af hash
/home/seurer/gcc/git/gcc-10-test/gcc/hash-map-traits.h:50
0x1231b97b get
/home/seurer/gcc/git/gcc-10-test/gcc/hash-map.h:184
0x1232fbaf process_store
/home/seurer/gcc/git/gcc-10-test/gcc/gimple-ssa-store-merging.c:4883
0x123304a7 execute
/home/seurer/gcc/git/gcc-10-test/gcc/gimple-ssa-store-merging.c:5040

[Bug middle-end/99883] A couple of minor misspellings

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-04-05
  Component|other   |middle-end
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #1 from Martin Sebor  ---
Confirmed.  Let me fix them.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 85777, which changed state.

Bug 85777 Summary: [8/9/10/11 Regression] -fsanitize=undefined makes a 
-Wmaybe-uninitialized warning disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug sanitizer/85777] [8/9/10/11 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #15 from Martin Sebor  ---
Based on comment #14 it sounds like the originally reported problem has been
resolved.  The test case in that comment doesn't trigger a warning in GCC 11
one way or the other, but also doesn't seem related to the original problem
report (if what you see is not what you  expect please open a separate bug for
just that problem.)

[Bug c++/99795] [8/9/10/11 Regression] -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

Re: [PATCH 2/3] x86: Update memcpy/memset inline strategies for Skylake family CPUs

[H.J. Lu via Gcc-patches]

On Mon, Apr 5, 2021 at 2:14 PM Jan Hubicka  wrote:
>
> > >  /* skylake_cost should produce code tuned for Skylake familly of CPUs.  
> > > */
> > >  static stringop_algs skylake_memcpy[2] =   {
> > > -  {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
> > > -  {libcall, {{16, loop, false}, {512, unrolled_loop, false},
> > > - {-1, libcall, false;
> > > +  {libcall,
> > > +   {{256, rep_prefix_1_byte, true},
> > > +{256, loop, false},
> > > +{-1, libcall, false}}},
> > > +  {libcall,
> > > +   {{256, rep_prefix_1_byte, true},
> > > +{256, loop, false},
> > > +{-1, libcall, false;
> > >
> > >  static stringop_algs skylake_memset[2] = {
> > > -  {libcall, {{6, loop_1_byte, true},
> > > - {24, loop, true},
> > > - {8192, rep_prefix_4_byte, true},
> > > - {-1, libcall, false}}},
> > > -  {libcall, {{24, loop, true}, {512, unrolled_loop, false},
> > > - {-1, libcall, false;
> > > +  {libcall,
> > > +   {{256, rep_prefix_1_byte, true},
> > > +{256, loop, false},
> > > +{-1, libcall, false}}},
> > > +  {libcall,
> > > +   {{256, rep_prefix_1_byte, true},
> > > +{256, loop, false},
> > > +{-1, libcall, false;
> > >
> >
> > If there are no objections, I will check it in on Wednesday.
>
> On my skylake notebook if I run the benchmarking script I get:
>
> jan@skylake:~/trunk/contrib> ./bench-stringop 64 64000 gcc -march=native
> memcpy
>   block size  libcall rep1noalg   rep4noalg   rep8noalg   loop
> noalg   unrlnoalg   sse noalg   bytePGO dynamicBEST
>  8192000  0:00.23 0:00.21 0:00.21 0:00.21 0:00.21 0:00.22 0:00.24 0:00.28 
> 0:00.22 0:00.20 0:00.21 0:00.19 0:00.19 0:00.77 0:00.18 0:00.180:00.19 sse
>   819200  0:00.09 0:00.18 0:00.18 0:00.18 0:00.18 0:00.18 0:00.20 0:00.19 
> 0:00.16 0:00.15 0:00.16 0:00.13 0:00.14 0:00.63 0:00.09 0:00.090:00.09 
> libcall
>81920  0:00.06 0:00.07 0:00.07 0:00.06 0:00.06 0:00.06 0:00.06 0:00.12 
> 0:00.11 0:00.11 0:00.10 0:00.07 0:00.08 0:00.66 0:00.11 0:00.060:00.06 
> libcall
>20480  0:00.06 0:00.07 0:00.05 0:00.06 0:00.07 0:00.07 0:00.08 0:00.14 
> 0:00.14 0:00.10 0:00.11 0:00.06 0:00.07 0:01.11 0:00.07 0:00.090:00.05 
> rep1noalign
> 8192  0:00.06 0:00.05 0:00.04 0:00.05 0:00.06 0:00.07 0:00.07 0:00.12 
> 0:00.15 0:00.11 0:00.10 0:00.06 0:00.06 0:00.64 0:00.06 0:00.050:00.04 
> rep1noalign
> 4096  0:00.05 0:00.05 0:00.05 0:00.06 0:00.07 0:00.05 0:00.05 0:00.09 
> 0:00.14 0:00.11 0:00.10 0:00.07 0:00.06 0:00.61 0:00.05 0:00.070:00.05 
> libcall
> 2048  0:00.04 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.10 
> 0:00.14 0:00.09 0:00.09 0:00.09 0:00.07 0:00.64 0:00.06 0:00.070:00.04 
> libcall
> 1024  0:00.06 0:00.08 0:00.08 0:00.10 0:00.11 0:00.06 0:00.06 0:00.12 
> 0:00.15 0:00.09 0:00.09 0:00.16 0:00.09 0:00.63 0:00.05 0:00.060:00.06 
> libcall
>  512  0:00.06 0:00.07 0:00.08 0:00.12 0:00.08 0:00.10 0:00.09 0:00.13 
> 0:00.16 0:00.10 0:00.10 0:00.28 0:00.18 0:00.66 0:00.13 0:00.080:00.06 
> libcall
>  256  0:00.10 0:00.12 0:00.11 0:00.14 0:00.11 0:00.12 0:00.13 0:00.14 
> 0:00.16 0:00.13 0:00.12 0:00.49 0:00.30 0:00.68 0:00.14 0:00.120:00.10 
> libcall
>  128  0:00.15 0:00.19 0:00.18 0:00.20 0:00.19 0:00.20 0:00.18 0:00.19 
> 0:00.21 0:00.17 0:00.15 0:00.49 0:00.43 0:00.72 0:00.17 0:00.170:00.15 
> libcall
>   64  0:00.29 0:00.28 0:00.29 0:00.33 0:00.33 0:00.34 0:00.29 0:00.25 
> 0:00.29 0:00.26 0:00.26 0:01.01 0:00.97 0:01.13 0:00.32 0:00.280:00.25 
> loop
>   48  0:00.37 0:00.39 0:00.38 0:00.45 0:00.41 0:00.45 0:00.44 0:00.45 
> 0:00.33 0:00.32 0:00.33 0:02.21 0:02.22 0:00.87 0:00.32 0:00.310:00.32 
> unrl
>   32  0:00.54 0:00.52 0:00.50 0:00.60 0:00.62 0:00.61 0:00.52 0:00.42 
> 0:00.43 0:00.40 0:00.42 0:01.18 0:01.16 0:01.14 0:00.39 0:00.400:00.40 
> unrl
>   24  0:00.71 0:00.74 0:00.77 0:00.83 0:00.78 0:00.81 0:00.75 0:00.52 
> 0:00.52 0:00.52 0:00.50 0:02.28 0:02.27 0:00.94 0:00.49 0:00.500:00.50 
> unrlnoalign
>   16  0:00.97 0:01.03 0:01.20 0:01.52 0:01.37 0:01.84 0:01.10 0:00.90 
> 0:00.86 0:00.79 0:00.77 0:01.27 0:01.32 0:01.25 0:00.91 0:00.910:00.77 
> unrlnoalign
>   14  0:01.35 0:01.37 0:01.39 0:01.76 0:01.44 0:01.53 0:01.58 0:01.01 
> 0:00.99 0:00.94 0:00.94 0:01.34 0:01.29 0:01.28 0:01.01 0:00.990:00.94 
> unrl
>   12  0:01.48 0:01.55 0:01.55 0:01.70 0:01.55 0:02.01 0:01.52 0:01.11 
> 0:01.07 0:01.02 0:01.04 0:02.21 0:02.25 0:01.19 0:01.11 0:01.100:01.02 
> unrl
>   10  0:01.73 0:01.90 0:01.88 0:02.05 0:01.86 0:02.09 0:01.78 0:01.32 
> 0:01.41 0:01.25 0:01.23 0:02.46 0:02.25 0:01.36 0:01.50 0:01.380:01.23 
> unrlnoalign
>8  0:02.22 0:02.17 0:02.18 0:02.43 0:02.09 0:02.55 0:01.92 0:01.54 
> 0:01.46 0:01.38 0:01.38 0:01.51 0:01.62 0:01.54 0:01.55 0:01.550:01.38 

[Bug c++/98810] [9/10 Regression] [C++20] ICE in tsubst_copy, at cp/pt.c:16771

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Jason Merrill  ---
Fixed for 9.4/10.3/11.

[Bug c++/98481] [10 Regression] std::vector::size_type as return type gets tagged with abi:cxx11

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jason Merrill  ---
Fixed in 10.3 with explicit -fabi-version=0 or =15.
Fixed in 11 by default.

[Bug c++/95870] [8/9/10 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE
   |(segmentation fault) in |(segmentation fault) in
   |most_general_template(), in |most_general_template(), in
   |gcc/cp/pt.c |gcc/cp/pt.c

--- Comment #9 from Jason Merrill  ---
Fixed for 11 so far.

[Bug c++/98440] [9/10 Regression] Accepts ill-formed reinterpret_cast(1)

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11 Regression]|[9/10 Regression] Accepts
   |Accepts ill-formed  |ill-formed
   |reinterpret_cast(1)  |reinterpret_cast(1)
  Known to fail|11.0|
  Known to work||11.0

--- Comment #3 from Jason Merrill  ---
Fixed for 11 so far.

[Bug c++/96311] [8/9/10 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression]  |[8/9/10 Regression] false
   |false positive for  |positive for
   |-Wunused-but-set-variable   |-Wunused-but-set-variable
   |(const/constexpr identifier |(const/constexpr identifier
   |used in generic lambda) |used in generic lambda)

--- Comment #7 from Jason Merrill  ---
Fixed for 11 so far.

[Bug c++/96311] [8/9/10/11 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:b07dd9b0d0e501a0083da79e2bca17041c007ec8

commit r11-7995-gb07dd9b0d0e501a0083da79e2bca17041c007ec8
Author: Jason Merrill 
Date:   Mon Apr 5 16:22:51 2021 -0400

c++: -Wunused, constant, and generic lambda [PR96311]

We never called mark_use for a return value in a function with dependent
return type.  In that situation we don't know if the use is as an rvalue or
lvalue, but we can use mark_exp_read instead.

gcc/cp/ChangeLog:

PR c++/96311
* typeck.c (check_return_expr): Call mark_exp_read in dependent
case.

gcc/testsuite/ChangeLog:

PR c++/96311
* g++.dg/cpp1y/lambda-generic-Wunused.C: New test.

[Bug c++/98440] [9/10/11 Regression] Accepts ill-formed reinterpret_cast(1)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:07f56824fd4da14a48030e698c8eb58de951c741

commit r11-7994-g07f56824fd4da14a48030e698c8eb58de951c741
Author: Jason Merrill 
Date:   Mon Apr 5 15:50:48 2021 -0400

c++: reinterpret_cast from prvalue to rvalue ref [PR98440]

In r260622 I allowed this under the general principle that [basic.lval]
"Whenever a prvalue appears as an operand of an operator that expects a
glvalue for that operand, the temporary materialization conversion (7.3.4)
is applied to convert the expression to an xvalue."  But
[expr.reinterpret.cast] specifically excludes creating a temporary in this
case.

gcc/cp/ChangeLog:

PR c++/98440
* typeck.c (build_reinterpret_cast_1): Don't perform
temporary materialization.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/rv-cast6.C: Expect reinterpret_cast error.
* g++.dg/cpp0x/reinterpret_cast2.C: Adjust message.
* g++.old-deja/g++.jason/rvalue3.C: Likewise.

[pushed] c++: -Wunused, constant, and generic lambda [PR96311]

[Jason Merrill via Gcc-patches]

We never called mark_use for a return value in a function with dependent
return type.  In that situation we don't know if the use is as an rvalue or
lvalue, but we can use mark_exp_read instead.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/96311
* typeck.c (check_return_expr): Call mark_exp_read in dependent
case.

gcc/testsuite/ChangeLog:

PR c++/96311
* g++.dg/cpp1y/lambda-generic-Wunused.C: New test.
---
 gcc/cp/typeck.c|  3 +++
 .../g++.dg/cpp1y/lambda-generic-Wunused.C  | 18 ++
 2 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-Wunused.C

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 8535ecc2d93..11dee7d8753 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -10215,6 +10215,9 @@ check_return_expr (tree retval, bool *no_warning)
 dependent:
   /* We should not have changed the return value.  */
   gcc_assert (retval == saved_retval);
+  /* We don't know if this is an lvalue or rvalue use, but
+either way we can mark it as read.  */
+  mark_exp_read (retval);
   return retval;
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-Wunused.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-Wunused.C
new file mode 100644
index 000..b43cbe6b675
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-Wunused.C
@@ -0,0 +1,18 @@
+// PR c++/96311
+// { dg-do compile { target c++14 } }
+// { dg-additional-options -Wunused }
+
+auto foo()
+{
+  constexpr int used = 0;
+  return
+[](auto unused)
+{
+  return used;
+};
+}
+
+int main()
+{
+  foo()(42);
+}

base-commit: 9f4c41147a41d08a74990eafe69a1064a3c13435
prerequisite-patch-id: 3be338a0d789cd159b27785251afb4e692b30d15
-- 
2.27.0

[pushed] c++: reinterpret_cast from prvalue to rvalue ref [PR98440]

[Jason Merrill via Gcc-patches]

In r260622 I allowed this under the general principle that [basic.lval]
"Whenever a prvalue appears as an operand of an operator that expects a
glvalue for that operand, the temporary materialization conversion (7.3.4)
is applied to convert the expression to an xvalue."  But
[expr.reinterpret.cast] specifically excludes creating a temporary in this
case.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/98440
* typeck.c (build_reinterpret_cast_1): Don't perform
temporary materialization.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/rv-cast6.C: Expect reinterpret_cast error.
---
 gcc/cp/typeck.c| 18 +++---
 gcc/testsuite/g++.dg/cpp0x/reinterpret_cast2.C |  2 +-
 gcc/testsuite/g++.dg/cpp0x/rv-cast6.C  |  2 +-
 gcc/testsuite/g++.old-deja/g++.jason/rvalue3.C |  2 +-
 4 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index dff4e9b63ca..8535ecc2d93 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -7938,22 +7938,18 @@ build_reinterpret_cast_1 (location_t loc, tree type, 
tree expr,
 type = cv_unqualified (type);
 
   /* [expr.reinterpret.cast]
- A glvalue expression of type T1 can be cast to the type
+ A glvalue of type T1, designating an object x, can be cast to the type
  "reference to T2" if an expression of type "pointer to T1" can be
- explicitly converted to the type "pointer to T2" using a
- reinterpret_cast.  */
+ explicitly converted to the type "pointer to T2" using a reinterpret_cast.
+ The result is that of *reinterpret_cast(p) where p is a pointer to x
+ of type "pointer to T1". No temporary is created, no copy is made, and no
+ constructors (11.4.4) or conversion functions (11.4.7) are called.  */
   if (TYPE_REF_P (type))
 {
-  if (TYPE_REF_IS_RVALUE (type) && !VOID_TYPE_P (intype))
-   {
- if (!obvalue_p (expr))
-   /* Perform the temporary materialization conversion.  */
-   expr = get_target_expr_sfinae (expr, complain);
-   }
-  else if (!lvalue_p (expr))
+  if (!glvalue_p (expr))
{
   if (complain & tf_error)
-error_at (loc, "invalid cast of an rvalue expression of type "
+   error_at (loc, "invalid cast of a prvalue expression of type "
  "%qT to type %qT",
  intype, type);
  return error_mark_node;
diff --git a/gcc/testsuite/g++.dg/cpp0x/reinterpret_cast2.C 
b/gcc/testsuite/g++.dg/cpp0x/reinterpret_cast2.C
index c173576e287..5402e825aa5 100644
--- a/gcc/testsuite/g++.dg/cpp0x/reinterpret_cast2.C
+++ b/gcc/testsuite/g++.dg/cpp0x/reinterpret_cast2.C
@@ -6,5 +6,5 @@ struct S { };
 void
 foo ()
 {
-  auto a = reinterpret_cast(foo ());  // { dg-error "12:invalid cast 
of an rvalue expression of type 'void' to type" }
+  auto a = reinterpret_cast(foo ()); // { dg-error "12:invalid cast of a 
prvalue expression of type 'void' to type" }
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-cast6.C 
b/gcc/testsuite/g++.dg/cpp0x/rv-cast6.C
index 3ae5691c5fd..3adf683f881 100644
--- a/gcc/testsuite/g++.dg/cpp0x/rv-cast6.C
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-cast6.C
@@ -5,7 +5,7 @@ struct A { virtual void f(); };
 struct B : A {};
 
 auto && a = static_cast(B());
-auto && b = reinterpret_cast(B());
+auto && b = reinterpret_cast(B()); // { dg-error "prvalue" }
 auto && c = dynamic_cast(B());
 auto && d = dynamic_cast(static_cast(B()));
 auto && e = const_cast(B());
diff --git a/gcc/testsuite/g++.old-deja/g++.jason/rvalue3.C 
b/gcc/testsuite/g++.old-deja/g++.jason/rvalue3.C
index 49191c9e408..77969bc60ee 100644
--- a/gcc/testsuite/g++.old-deja/g++.jason/rvalue3.C
+++ b/gcc/testsuite/g++.old-deja/g++.jason/rvalue3.C
@@ -2,5 +2,5 @@
 int main ()
 {
int i;
-   int  = (int&)(int)i; // { dg-error "14:invalid cast of an rvalue 
expression" } casting rvalue to reference type
+   int  = (int&)(int)i; // { dg-error "14:invalid cast of a prvalue 
expression" } casting rvalue to reference type
 }

base-commit: 9f4c41147a41d08a74990eafe69a1064a3c13435
-- 
2.27.0

Re: [PATCH 2/3] x86: Update memcpy/memset inline strategies for Skylake family CPUs

[Jan Hubicka]

> >  /* skylake_cost should produce code tuned for Skylake familly of CPUs.  */
> >  static stringop_algs skylake_memcpy[2] =   {
> > -  {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
> > -  {libcall, {{16, loop, false}, {512, unrolled_loop, false},
> > - {-1, libcall, false;
> > +  {libcall,
> > +   {{256, rep_prefix_1_byte, true},
> > +{256, loop, false},
> > +{-1, libcall, false}}},
> > +  {libcall,
> > +   {{256, rep_prefix_1_byte, true},
> > +{256, loop, false},
> > +{-1, libcall, false;
> >
> >  static stringop_algs skylake_memset[2] = {
> > -  {libcall, {{6, loop_1_byte, true},
> > - {24, loop, true},
> > - {8192, rep_prefix_4_byte, true},
> > - {-1, libcall, false}}},
> > -  {libcall, {{24, loop, true}, {512, unrolled_loop, false},
> > - {-1, libcall, false;
> > +  {libcall,
> > +   {{256, rep_prefix_1_byte, true},
> > +{256, loop, false},
> > +{-1, libcall, false}}},
> > +  {libcall,
> > +   {{256, rep_prefix_1_byte, true},
> > +{256, loop, false},
> > +{-1, libcall, false;
> >
> 
> If there are no objections, I will check it in on Wednesday.

On my skylake notebook if I run the benchmarking script I get:

jan@skylake:~/trunk/contrib> ./bench-stringop 64 64000 gcc -march=native
memcpy
  block size  libcall rep1noalg   rep4noalg   rep8noalg   loop
noalg   unrlnoalg   sse noalg   bytePGO dynamicBEST
 8192000  0:00.23 0:00.21 0:00.21 0:00.21 0:00.21 0:00.22 0:00.24 0:00.28 
0:00.22 0:00.20 0:00.21 0:00.19 0:00.19 0:00.77 0:00.18 0:00.180:00.19 sse
  819200  0:00.09 0:00.18 0:00.18 0:00.18 0:00.18 0:00.18 0:00.20 0:00.19 
0:00.16 0:00.15 0:00.16 0:00.13 0:00.14 0:00.63 0:00.09 0:00.090:00.09 
libcall
   81920  0:00.06 0:00.07 0:00.07 0:00.06 0:00.06 0:00.06 0:00.06 0:00.12 
0:00.11 0:00.11 0:00.10 0:00.07 0:00.08 0:00.66 0:00.11 0:00.060:00.06 
libcall
   20480  0:00.06 0:00.07 0:00.05 0:00.06 0:00.07 0:00.07 0:00.08 0:00.14 
0:00.14 0:00.10 0:00.11 0:00.06 0:00.07 0:01.11 0:00.07 0:00.090:00.05 
rep1noalign
8192  0:00.06 0:00.05 0:00.04 0:00.05 0:00.06 0:00.07 0:00.07 0:00.12 
0:00.15 0:00.11 0:00.10 0:00.06 0:00.06 0:00.64 0:00.06 0:00.050:00.04 
rep1noalign
4096  0:00.05 0:00.05 0:00.05 0:00.06 0:00.07 0:00.05 0:00.05 0:00.09 
0:00.14 0:00.11 0:00.10 0:00.07 0:00.06 0:00.61 0:00.05 0:00.070:00.05 
libcall
2048  0:00.04 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.10 
0:00.14 0:00.09 0:00.09 0:00.09 0:00.07 0:00.64 0:00.06 0:00.070:00.04 
libcall
1024  0:00.06 0:00.08 0:00.08 0:00.10 0:00.11 0:00.06 0:00.06 0:00.12 
0:00.15 0:00.09 0:00.09 0:00.16 0:00.09 0:00.63 0:00.05 0:00.060:00.06 
libcall
 512  0:00.06 0:00.07 0:00.08 0:00.12 0:00.08 0:00.10 0:00.09 0:00.13 
0:00.16 0:00.10 0:00.10 0:00.28 0:00.18 0:00.66 0:00.13 0:00.080:00.06 
libcall
 256  0:00.10 0:00.12 0:00.11 0:00.14 0:00.11 0:00.12 0:00.13 0:00.14 
0:00.16 0:00.13 0:00.12 0:00.49 0:00.30 0:00.68 0:00.14 0:00.120:00.10 
libcall
 128  0:00.15 0:00.19 0:00.18 0:00.20 0:00.19 0:00.20 0:00.18 0:00.19 
0:00.21 0:00.17 0:00.15 0:00.49 0:00.43 0:00.72 0:00.17 0:00.170:00.15 
libcall
  64  0:00.29 0:00.28 0:00.29 0:00.33 0:00.33 0:00.34 0:00.29 0:00.25 
0:00.29 0:00.26 0:00.26 0:01.01 0:00.97 0:01.13 0:00.32 0:00.280:00.25 loop
  48  0:00.37 0:00.39 0:00.38 0:00.45 0:00.41 0:00.45 0:00.44 0:00.45 
0:00.33 0:00.32 0:00.33 0:02.21 0:02.22 0:00.87 0:00.32 0:00.310:00.32 unrl
  32  0:00.54 0:00.52 0:00.50 0:00.60 0:00.62 0:00.61 0:00.52 0:00.42 
0:00.43 0:00.40 0:00.42 0:01.18 0:01.16 0:01.14 0:00.39 0:00.400:00.40 unrl
  24  0:00.71 0:00.74 0:00.77 0:00.83 0:00.78 0:00.81 0:00.75 0:00.52 
0:00.52 0:00.52 0:00.50 0:02.28 0:02.27 0:00.94 0:00.49 0:00.500:00.50 
unrlnoalign
  16  0:00.97 0:01.03 0:01.20 0:01.52 0:01.37 0:01.84 0:01.10 0:00.90 
0:00.86 0:00.79 0:00.77 0:01.27 0:01.32 0:01.25 0:00.91 0:00.910:00.77 
unrlnoalign
  14  0:01.35 0:01.37 0:01.39 0:01.76 0:01.44 0:01.53 0:01.58 0:01.01 
0:00.99 0:00.94 0:00.94 0:01.34 0:01.29 0:01.28 0:01.01 0:00.990:00.94 unrl
  12  0:01.48 0:01.55 0:01.55 0:01.70 0:01.55 0:02.01 0:01.52 0:01.11 
0:01.07 0:01.02 0:01.04 0:02.21 0:02.25 0:01.19 0:01.11 0:01.100:01.02 unrl
  10  0:01.73 0:01.90 0:01.88 0:02.05 0:01.86 0:02.09 0:01.78 0:01.32 
0:01.41 0:01.25 0:01.23 0:02.46 0:02.25 0:01.36 0:01.50 0:01.380:01.23 
unrlnoalign
   8  0:02.22 0:02.17 0:02.18 0:02.43 0:02.09 0:02.55 0:01.92 0:01.54 
0:01.46 0:01.38 0:01.38 0:01.51 0:01.62 0:01.54 0:01.55 0:01.550:01.38 unrl
So indeed rep byte seems consistently outperforming rep4/rep8 however
urolled variant seems to be better than rep byte for small block sizes.
Do you have some data for blocks in size 8...256 to be faster with rep1
compared to unrolled loop for 

Re: Default debug format for AVR

[Simon Marchi via Gcc]

On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat, Apr 3, 2021 at 6:24 PM 
Simon Marchi via Gcc mailto:gcc@gcc.gnu.org>> wrote:
> 
> The default debug format (when using only -g) for the AVR target is
> stabs.  Is there a reason for it not being DWARF, and would it be
> possible to maybe consider possibly thinking about making it default to
> DWARF?  I am asking because the support for stabs in GDB is pretty much
> untested and bit-rotting, so I think it would be more useful for
> everyone to use DWARF.
> 
> 
> I tried to deprecate the stabs support a little over 4 years ago.
> https://gcc.gnu.org/pipermail/gcc-patches/2017-December/489296.html 
> 
> There was a suggestion to change the error to a warning, but my startup 
> company job kept me so busy I never had a chance to follow up on this.
> 
> I would like to see the stabs support deprecated and the later removed from 
> gcc.  No new features have been added in a long time, and it is only being 
> maintained in the sense that when it fails it is fixed to ignore source code 
> constructs that it doesn't support.  The longer it survives in this state, 
> the less useful it becomes.
> 
> Jim

You have 100% my suppose on this.  The longer stabs survives (especially
as the default for an arch), the longer some people who don't know the
intricacies of debug formats could use it without knowing, and that
does them a disservice.

Simon

[Bug rtl-optimization/12754] Faulty register allocation under certain circumstances

[shorne at gcc dot gnu.org via Gcc-bugs]

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

Stafford Horne  changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

[Bug rtl-optimization/12754] Faulty register allocation under certain circumstances

[shorne at gcc dot gnu.org via Gcc-bugs]

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

Stafford Horne  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/99919] [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||99918

--- Comment #1 from Martin Sebor  ---
The IL below shows there is enough information in the IL for the warning to
determine that x_5 is never read from.

void g (struct B b)
{
  _Bool b$j;
  _Bool b$i;
  _Bool x;
  unsigned char _1;
  unsigned char _2;
  unsigned char _3;
  unsigned char _4;

   [local count: 1073741824]:
  b$i_11 = b.i;
  _1 = VIEW_CONVERT_EXPR(b);
  _2 = _1 & 1;
  if (_2 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1073741824]:
  # x_5 = PHI 
  # b$j_10 = PHI <0(2), b$i_11(3)>
  b.j = b$j_10;
  _3 = VIEW_CONVERT_EXPR(b);
  _4 = _3 & 2;
  if (_4 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  z = x_5;

   [local count: 1073741824]:
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
[Bug 99918] [9/10/11 Regression] suboptimal code for bool bitfield tests

[Bug rtl-optimization/12754] Faulty register allocation under certain circumstances

[shorne at gcc dot gnu.org via Gcc-bugs]

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

Stafford Horne  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |shorne at gcc dot 
gnu.org
 Status|NEW |SUSPENDED

--- Comment #6 from Stafford Horne  ---
Suspending as this is on the old re-written port.

[Bug tree-optimization/99918] [9/10/11 Regression] suboptimal code for bool bitfield tests

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Martin Sebor  ---
(In reply to Andrew Pinski from comment #1)
> This comes down to lowering bitfields too soon.
> my bet it will happen even integer bitfields will have a problem.

Yes, unsigned bit-fields suffer the same problem but unlike for _Bool, GCC
never emitted optimal code for those for this test case.

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2018-04-09 00:00:00 |2021-4-5
  Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99919
 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
Reconfirmed with GCC 11 with the ever-so-slightly slightly simplified program
below and enhanced output.  The warning has been issued since at least GCC 4.1
and so is not a regression.

$ cat pr85301.c && gcc -O2 -S -Wall -DUSE_BITFIELD  pr85301.c
struct A
{
#ifdef USE_BITFIELD
  unsigned i : 1;
  unsigned j : 1;
#else
  unsigned i;
  unsigned j;
#endif
};

int z, f (void);

struct A a;

void h (void)
{
  int y;

  if (a.j || a.i)
y = f ();

  if (a.i)
z = y;
}

pr85301.c: In function ‘h’:
pr85301.c:24:7: warning: ‘y’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   24 | z = y;
  | ~~^~~
pr85301.c:18:7: note: when ‘!(((unsigned char*))[0] & 3)’
   18 |   int y;
  |   ^
pr85301.c:18:7: note: used when ‘prephitmp_15 = PHI <_1(7), pretmp_14(3)> & 1’
pr85301.c:18:7: note: ‘y’ was declared here

Jump threading and other optimization opportunities aside (I have raised
pr99918 for one of those), there does also seem to be a limitation in the
warning code in that it doesn't understand BIT_FIELD_REF expressions.  The
warning sees the IL below from which it should be able to determine that y's
use is conditional on its definition (i.e., the use predicate a strict subset
of the predicate controlling the definition).

void h ()
{
  int y;
  unsigned char _1;
  unsigned char _2;
  unsigned char _4;
  unsigned char pretmp_14;
  unsigned char prephitmp_15;

   [local count: 1073741824]:
  # VUSE <.MEM_8(D)>
  _1 = BIT_FIELD_REF ;
  _2 = _1 & 3;
  if (_2 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719407024]:
  goto ; [100.00%]

   [local count: 354334800]:
  # .MEM_10 = VDEF <.MEM_8(D)>
  y_11 = f ();
  # VUSE <.MEM_10>
  pretmp_14 = BIT_FIELD_REF ;

   [local count: 1073741824]:
  # y_5 = PHI 
  # .MEM_6 = PHI <.MEM_8(D)(7), .MEM_10(3)>
  # prephitmp_15 = PHI <_1(7), pretmp_14(3)>
  _4 = prephitmp_15 & 1;
  if (_4 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  goto ; [100.00%]

   [local count: 536870913]:
  ## y_5 = PHI 
  ## uninit when: _2 == 0
  ##: BIT_FIELD_REF  & 3 == 0
  ##
  ## used when: prephitmp_15 & != 0
  ##  : PHI <_1(7), pretmp_14(3)>
  ##  : _1(7) != 0 || pretmp_14 != 0
  ##  : BIT_FIELD_REF  != 0 || BIT_FIELD_REF  != 0
  ##  : BIT_FIELD_REF  != 0
  # .MEM_12 = VDEF <.MEM_6>
  z = y_5;

   [local count: 1073741824]:
  # .MEM_7 = PHI <.MEM_6(8), .MEM_12(5)>
  # VUSE <.MEM_7>
  return;

}

[Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99919
   Summary: [9/10/11 Regression] bogus -Wmaybe-uninitialized with
a _Bool bit-field
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is the -Wmaybe-uninitialized subset of pr99918 showing how the failure to
fail _Bool bit-field expressions can cause bogus warnings.  (Like pr99918, this
was most likely caused by r225825.)

$ cat z.c && gcc -O2 -S -Wall z.c
struct B { _Bool i: 1; _Bool j: 1; };

_Bool z;

void g (struct B b)
{
  _Bool x;

  if (b.i)
b.j = 0;
  else
{
  b.j = b.i;
  x = b.i;
}

  if (b.j)
z = x;
}

z.c: In function ‘g’:
z.c:18:7: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   18 | z = x;
  | ~~^~~
z.c:7:9: note: ‘x’ was declared here
7 |   _Bool x;
  | ^

[Bug tree-optimization/99918] [9/10/11 Regression] suboptimal code for bool bitfield tests

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Sebor  ---
This only seems to affect C _Bool bit-fields and not C++ bool.

[Bug tree-optimization/99918] [9/10/11 Regression] suboptimal code for bool bitfield tests

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1,
   ||8.3.0, 9.3.0
Summary|suboptimal code for bool|[9/10/11 Regression]
   |bitfield tests  |suboptimal code for bool
   ||bitfield tests

--- Comment #2 from Martin Sebor  ---
Bisection points to r225825 as the revision where GCC started to fail to fold
the code in g().

[Bug tree-optimization/99918] suboptimal code for bool bitfield tests

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
This comes down to lowering bitfields too soon.
my bet it will happen even integer bitfields will have a problem.

[Bug tree-optimization/99918] New: suboptimal code for bool bitfield tests

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99918
   Summary: suboptimal code for bool bitfield tests
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC does a better job folding operations involving plain Booleans than it does
with bool bit-fields.  The example below shows that in f() the return statement
is folded to zero while in g() it's not.  This is behind a class of
-Wmaybe-uninitialized warnings.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
struct A { _Bool i, j; };

_Bool f (struct A a)
{
  if (a.i)
a.j = 0;
  else
a.j = a.i;

  return a.j;// folded to 0
}

struct B { _Bool i: 1, j: 1; };

_Bool g (struct B b)
{
  if (b.i)
b.j = 0;
  else
b.j = b.i;

  return b.j;// not folded
}


;; Function f (f, funcdef_no=0, decl_uid=1946, cgraph_uid=1, symbol_order=0)

_Bool f (struct A a)
{
   [local count: 1073741824]:
  return 0;

}



;; Function g (g, funcdef_no=1, decl_uid=1953, cgraph_uid=2, symbol_order=1)

Removing basic block 5
_Bool g (struct B b)
{
  _Bool b$j;
  unsigned char _1;
  unsigned char _2;
  _Bool _3;

   [local count: 1073741824]:
  _1 = VIEW_CONVERT_EXPR(b);
  _2 = _1 & 1;
  if (_2 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _3 = b.i;

   [local count: 1073741824]:
  # b$j_5 = PHI <0(2), _3(3)>
  return b$j_5;

}

[Bug c++/96311] [8/9/10/11 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug d/99917] gcc/d/dmd/mtype.c:5223: missing call to va_end ?

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
(In reply to David Binderman from comment #0)
> trunk.git/gcc/d/dmd/mtype.c:5223:30: error: va_list 'ap' was opened but not
> closed by va_end(). [va_end_missing]
> 
> Source code is
> 
> va_list ap;
> va_start(ap, format);
> buf.vprintf(format, ap);
> return buf.extractChars();

Had a look and confirmed, raised a change in upstream dmd and awaiting for it
to be reviewed.

[Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

[the_gamester28 at msn dot com via Gcc-bugs]

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

--- Comment #4 from the_gamester28 at msn dot com ---
(In reply to Jason Merrill from comment #2)
> (In reply to the_gamester28 from comment #0)
> > It seems that the template requirements of invoke_tag(bar_tag, int) are
> > considered while evaluating line marked "here". Requirements of irrelevant
> > overloads should not be considered, as it can potentially lead to falsely
> > reporting a cyclic dependency.
> 
> This is as specified by http://wg21.link/cwg2369
> 
> I think it would be reasonable to allow a compiler to accept the testcase
> under a generalization of 13.9.1/9: "If the function selected by overload
> resolution (12.4) can be determined without instantiating a class template
> definition, it is unspecified whether that instantiation actually takes
> place."
> 
> But that does not require a compiler to accept it.
> 
> It might make sense to check non-dependent conversions that don't require
> template instantiation, then constraints, then non-dependent conversions
> that do require template instantiation.  But that's a matter for the
> committee; G++ is conforming to the current working paper.

Perhaps I was too quick to assert what I expected the implementation details to
be.

The fooable concept should be satisfied for any (T it) for which
invoke_tag(foo_tag{}, it) is unambiguously applicable. The fact that the
invoke_tag(bar_tag, T) overload exists should not preclude that. It is not up
to me how the compiler comes to that end, but that is the desired outcome.

It is still possible to ban recursive constraints, keep the new GCC 11
implementation, and still have this particular code compile with a small
alteration in behaviour:

The compiler does not immediately bail out as soon as it sees recursion in an
overload candidate, but marks that particular candidate as invalid.

If there are no applicable overloads (because they are all recursive, or they
are invalid for some other reason), then the compiler can reject the code and
list all of the reasons why all of the candidates are invalid.

In this case, it would mark invoke_tag(bar_tag, int) as not-applicable due to
the constraint recursion, and carry on checking the rest of the overloads for
applicability, until it is sure that there is one and only one applicable
overload: invoke_tag(foo_tag, int).

[Bug c++/98440] [9/10/11 Regression] Accepts ill-formed reinterpret_cast(1)

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

[PATCH 3/3] d: Add TARGET_D_REGISTER_OS_TARGET_INFO

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds TARGET_D_REGISTER_OS_TARGET_INFO as a new D front-end
target hook, implementing `__traits(getTargetInfo, "objectFormat")' for
all targets that have D support files.

This trait was added earlier in the front-end as a stub, however the
target-specific implementation was left out until now.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
tested on x86_64-darwin for getting the libphobos port set-up.

Any issues with this, or OK to commit?

Regards
Iain.

---
gcc/ChangeLog:

* config/darwin-d.c (darwin_d_handle_target_object_format): New
function.
(darwin_d_register_target_info): New function.
(TARGET_D_REGISTER_OS_TARGET_INFO): Define.
* config/dragonfly-d.c (dragonfly_d_handle_target_object_format): New
function.
(dragonfly_d_register_target_info): New function.
(TARGET_D_REGISTER_OS_TARGET_INFO): Define.
* config/freebsd-d.c (freebsd_d_handle_target_object_format): New
function.
(freebsd_d_register_target_info): New function.
(TARGET_D_REGISTER_OS_TARGET_INFO): Define.
* config/glibc-d.c (glibc_d_handle_target_object_format): New
function.
(glibc_d_register_target_info): New function.
(TARGET_D_REGISTER_OS_TARGET_INFO): Define.
* config/netbsd-d.c (netbsd_d_handle_target_object_format): New
function.
(netbsd_d_register_target_info): New function.
(TARGET_D_REGISTER_OS_TARGET_INFO): Define.
* config/sol2-d.c (solaris_d_handle_target_object_format): New
function.
(solaris_d_register_target_info): New function.
(TARGET_D_REGISTER_OS_TARGET_INFO): Define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (D language and ABI): Add @hook for
TARGET_D_REGISTER_OS_TARGET_INFO.

gcc/d/ChangeLog:

* d-target.cc (Target::_init): Call new targetdm hook to register OS
specific target info keys.
* d-target.def (d_register_os_target_info): New hook.
---
 gcc/config/darwin-d.c| 26 ++
 gcc/config/dragonfly-d.c | 26 ++
 gcc/config/freebsd-d.c   | 26 ++
 gcc/config/glibc-d.c | 26 ++
 gcc/config/netbsd-d.c| 26 ++
 gcc/config/sol2-d.c  | 26 ++
 gcc/d/d-target.cc|  1 +
 gcc/d/d-target.def   |  8 
 gcc/doc/tm.texi  |  5 +
 gcc/doc/tm.texi.in   |  2 ++
 10 files changed, 172 insertions(+)

diff --git a/gcc/config/darwin-d.c b/gcc/config/darwin-d.c
index afc32da4ad8..67d69b721b5 100644
--- a/gcc/config/darwin-d.c
+++ b/gcc/config/darwin-d.c
@@ -32,9 +32,35 @@ darwin_d_os_builtins (void)
   d_add_builtin_version ("darwin");
 }
 
+/* Handle a call to `__traits(getTargetInfo, "objectFormat")'.  */
+
+static tree
+darwin_d_handle_target_object_format (void)
+{
+  const char *objfmt = "macho";
+
+  return build_string_literal (strlen (objfmt) + 1, objfmt);
+}
+
+/* Implement TARGET_D_REGISTER_OS_TARGET_INFO for Darwin targets.  */
+
+static void
+darwin_d_register_target_info (void)
+{
+  const struct d_target_info_spec handlers[] = {
+{ "objectFormat", darwin_d_handle_target_object_format },
+{ NULL, NULL },
+  };
+
+  d_add_target_info_handlers (handlers);
+}
+
 #undef TARGET_D_OS_VERSIONS
 #define TARGET_D_OS_VERSIONS darwin_d_os_builtins
 
+#undef TARGET_D_REGISTER_OS_TARGET_INFO
+#define TARGET_D_REGISTER_OS_TARGET_INFO darwin_d_register_target_info
+
 /* Define TARGET_D_MINFO_SECTION for Darwin targets.  */
 
 #undef TARGET_D_MINFO_SECTION
diff --git a/gcc/config/dragonfly-d.c b/gcc/config/dragonfly-d.c
index 76f4cc02ff7..dc301b54e8f 100644
--- a/gcc/config/dragonfly-d.c
+++ b/gcc/config/dragonfly-d.c
@@ -31,7 +31,33 @@ dragonfly_d_os_builtins (void)
   d_add_builtin_version ("Posix");
 }
 
+/* Handle a call to `__traits(getTargetInfo, "objectFormat")'.  */
+
+static tree
+dragonfly_d_handle_target_object_format (void)
+{
+  const char *objfmt = "elf";
+
+  return build_string_literal (strlen (objfmt) + 1, objfmt);
+}
+
+/* Implement TARGET_D_REGISTER_OS_TARGET_INFO for DragonFly targets.  */
+
+static void
+dragonfly_d_register_target_info (void)
+{
+  const struct d_target_info_spec handlers[] = {
+{ "objectFormat", dragonfly_d_handle_target_object_format },
+{ NULL, NULL },
+  };
+
+  d_add_target_info_handlers (handlers);
+}
+
 #undef TARGET_D_OS_VERSIONS
 #define TARGET_D_OS_VERSIONS dragonfly_d_os_builtins
 
+#undef TARGET_D_REGISTER_OS_TARGET_INFO
+#define TARGET_D_REGISTER_OS_TARGET_INFO dragonfly_d_register_target_info
+
 struct gcc_targetdm targetdm = TARGETDM_INITIALIZER;
diff --git a/gcc/config/freebsd-d.c b/gcc/config/freebsd-d.c
index 8a8ddd92884..8bebe79c895 100644
--- a/gcc/config/freebsd-d.c
+++ b/gcc/config/freebsd-d.c
@@ -37,7 +37,33 @@ freebsd_d_os_builtins (void)
   d_add_builtin_version ("Posix");
 }
 
+/* Handle a call to 

[PATCH 2/3] d: Add TARGET_D_REGISTER_CPU_TARGET_INFO

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds TARGET_D_REGISTER_CPU_TARGET_INFO as a new D front-end
target hook, implementing `__traits(getTargetInfo, "floatAbi")' for all
targets that have D support files.

This trait was added earlier in the front-end as a stub, however the
target-specific implementation was left out until now.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
tested on x86_64-darwin for getting the libphobos port set-up.

Any issues with this, or OK to commit?

Regards
Iain.

---
gcc/ChangeLog:

* config/aarch64/aarch64-d.c (aarch64_d_handle_target_float_abi): New
function.
(aarch64_d_register_target_info): New function.
* config/aarch64/aarch64-protos.h (aarch64_d_register_target_info):
Declare.
* config/aarch64/aarch64.h (TARGET_D_REGISTER_CPU_TARGET_INFO):
Define.
* config/arm/arm-d.c (arm_d_handle_target_float_abi): New function.
(arm_d_register_target_info): New function.
* config/arm/arm-protos.h (arm_d_register_target_info): Declare.
* config/arm/arm.h (TARGET_D_REGISTER_CPU_TARGET_INFO): Define.
* config/i386/i386-d.c (ix86_d_handle_target_float_abi): New function.
(ix86_d_register_target_info): New function.
* config/i386/i386-protos.h (ix86_d_register_target_info): Declare.
* config/i386/i386.h (TARGET_D_REGISTER_CPU_TARGET_INFO): Define.
* config/mips/mips-d.c (mips_d_handle_target_float_abi): New function.
(mips_d_register_target_info): New function.
* config/mips/mips-protos.h (mips_d_register_target_info): Declare.
* config/mips/mips.h (TARGET_D_REGISTER_CPU_TARGET_INFO): Define.
* config/pa/pa-d.c (pa_d_handle_target_float_abi): New function.
(pa_d_register_target_info): New function.
* config/pa/pa-protos.h (pa_d_register_target_info): Declare.
* config/pa/pa.h (TARGET_D_REGISTER_CPU_TARGET_INFO): Define.
* config/riscv/riscv-d.c (riscv_d_handle_target_float_abi): New
function.
(riscv_d_register_target_info): New function.
* config/riscv/riscv-protos.h (riscv_d_register_target_info): Declare.
* config/riscv/riscv.h (TARGET_D_REGISTER_CPU_TARGET_INFO): Define.
* config/rs6000/rs6000-d.c (rs6000_d_handle_target_float_abi): New
function.
(rs6000_d_register_target_info): New function.
* config/rs6000/rs6000-protos.h (rs6000_d_register_target_info):
Declare.
* config/rs6000/rs6000.h (TARGET_D_REGISTER_CPU_TARGET_INFO): Define.
* config/s390/s390-d.c (s390_d_handle_target_float_abi): New function.
(s390_d_register_target_info): New function.
* config/s390/s390-protos.h (s390_d_register_target_info): Declare.
* config/s390/s390.h (TARGET_D_REGISTER_CPU_TARGET_INFO): Define.
* config/sparc/sparc-d.c (sparc_d_handle_target_float_abi): New
function.
(sparc_d_register_target_info): New function.
* config/sparc/sparc-protos.h (sparc_d_register_target_info): Declare.
* config/sparc/sparc.h (TARGET_D_REGISTER_CPU_TARGET_INFO): Define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (D language and ABI): Add @hook for
TARGET_D_REGISTER_CPU_TARGET_INFO.

gcc/d/ChangeLog:

* d-target.cc (Target::_init): Call new targetdm hook to register CPU
specific target info keys.
* d-target.def (d_register_cpu_target_info): New hook.
---
 gcc/config/aarch64/aarch64-d.c  | 23 ++
 gcc/config/aarch64/aarch64-protos.h |  1 +
 gcc/config/aarch64/aarch64.h|  3 +-
 gcc/config/arm/arm-d.c  | 42 ++
 gcc/config/arm/arm-protos.h |  1 +
 gcc/config/arm/arm.h|  3 +-
 gcc/config/i386/i386-d.c| 28 +
 gcc/config/i386/i386-protos.h   |  1 +
 gcc/config/i386/i386.h  |  1 +
 gcc/config/mips/mips-d.c| 30 ++
 gcc/config/mips/mips-protos.h   |  1 +
 gcc/config/mips/mips.h  |  3 +-
 gcc/config/pa/pa-d.c| 28 +
 gcc/config/pa/pa-protos.h   |  1 +
 gcc/config/pa/pa.h  |  3 +-
 gcc/config/riscv/riscv-d.c  | 47 +
 gcc/config/riscv/riscv-protos.h |  1 +
 gcc/config/riscv/riscv.h|  3 +-
 gcc/config/rs6000/rs6000-d.c| 30 ++
 gcc/config/rs6000/rs6000-protos.h   |  1 +
 gcc/config/rs6000/rs6000.h  |  3 +-
 gcc/config/s390/s390-d.c| 30 ++
 gcc/config/s390/s390-protos.h   |  1 +
 gcc/config/s390/s390.h  |  3 +-
 gcc/config/sparc/sparc-d.c  | 28 +
 gcc/config/sparc/sparc-protos.h |  1 +
 gcc/config/sparc/sparc.h|  3 +-
 gcc/d/d-target.cc   |  1 +
 gcc/d/d-target.def  | 12 
 gcc/doc/tm.texi |  9 ++
 

[PATCH 1/3] d: Add TARGET_D_HAS_STDCALL_CONVENTION

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds TARGET_D_HAS_STDCALL_CONVENTION as a new D front-end
target hook.  It replaces the use of the D front-end `is64bit' parameter
in determining whether to insert the "stdcall" function attribute.

It is also used to determine whether `extern(System)' should be the same
as `extern(Windows)' in the implementation of Target::systemLinkage.

Both are prerequesites for being able to compile libphobos on MinGW.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
tested on x86_64-w64-mingw64 for getting the libphobos port set-up.

Any issues with the implementation, or OK to commit?

Regards,
Iain.

---
gcc/ChangeLog:

* config/i386/i386-d.c (ix86_d_has_stdcall_convention): New function.
* config/i386/i386-protos.h (ix86_d_has_stdcall_convention): Declare.
* config/i386/i386.h (TARGET_D_HAS_STDCALL_CONVENTION): Define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (D language and ABI): Add @hook for
TARGET_D_HAS_STDCALL_CONVENTION.

gcc/d/ChangeLog:

* d-target.cc (Target::systemLinkage): Return LINKwindows if
d_has_stdcall_convention applies to LINKsystem.
* d-target.def (d_has_stdcall_convention): New hook.
* types.cc (TypeVisitor::visit (TypeFunction *)): Insert "stdcall"
function attribute if d_has_stdcall_convention applies to LINKwindows.
---
 gcc/config/i386/i386-d.c  | 20 
 gcc/config/i386/i386-protos.h |  1 +
 gcc/config/i386/i386.h|  3 ++-
 gcc/d/d-target.cc | 12 +++-
 gcc/d/d-target.def| 13 +
 gcc/d/types.cc| 19 +--
 gcc/doc/tm.texi   |  8 
 gcc/doc/tm.texi.in|  2 ++
 8 files changed, 70 insertions(+), 8 deletions(-)

diff --git a/gcc/config/i386/i386-d.c b/gcc/config/i386/i386-d.c
index b79be85e661..58b4790fdad 100644
--- a/gcc/config/i386/i386-d.c
+++ b/gcc/config/i386/i386-d.c
@@ -44,3 +44,23 @@ ix86_d_target_versions (void)
   else
 d_add_builtin_version ("D_SoftFloat");
 }
+
+/* Implement TARGET_D_HAS_STDCALL_CONVENTION for x86 targets.  */
+
+bool
+ix86_d_has_stdcall_convention (unsigned int *link_system,
+  unsigned int *link_windows)
+{
+  if (ix86_abi == MS_ABI)
+{
+  *link_system = 1;
+  *link_windows = (!TARGET_64BIT) ? 1 : 0;
+}
+  else
+{
+  *link_system = 0;
+  *link_windows = 0;
+}
+
+  return true;
+}
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 9f8a69ea7dc..acfb9f5fe87 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -264,6 +264,7 @@ extern void ix86_register_pragmas (void);
 
 /* In i386-d.c  */
 extern void ix86_d_target_versions (void);
+extern bool ix86_d_has_stdcall_convention (unsigned int *, unsigned int *);
 
 /* In winnt.c  */
 extern void i386_pe_unique_section (tree, int);
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index b4001d21b70..17e233a4e74 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -801,8 +801,9 @@ extern const char *host_detect_local_cpu (int argc, const 
char **argv);
 /* Target Pragmas.  */
 #define REGISTER_TARGET_PRAGMAS() ix86_register_pragmas ()
 
-/* Target CPU versions for D.  */
+/* Target hooks for D language.  */
 #define TARGET_D_CPU_VERSIONS ix86_d_target_versions
+#define TARGET_D_HAS_STDCALL_CONVENTION ix86_d_has_stdcall_convention
 
 #ifndef CC1_SPEC
 #define CC1_SPEC "%(cc1_cpu) "
diff --git a/gcc/d/d-target.cc b/gcc/d/d-target.cc
index a1dc2ee286f..f1814df110d 100644
--- a/gcc/d/d-target.cc
+++ b/gcc/d/d-target.cc
@@ -435,11 +435,21 @@ TargetCPP::derivedClassOffset(ClassDeclaration 
*base_class)
   return base_class->structsize;
 }
 
-/* Return the default system linkage for the target.  */
+/* Return the default `extern (System)' linkage for the target.  */
 
 LINK
 Target::systemLinkage (void)
 {
+  unsigned link_system, link_windows;
+
+  if (targetdm.d_has_stdcall_convention (_system, _windows))
+{
+  /* In [attribute/linkage], `System' is the same as `Windows' on Windows
+platforms, and `C' on other platforms.  */
+  if (link_system)
+   return LINKwindows;
+}
+
   return LINKc;
 }
 
diff --git a/gcc/d/d-target.def b/gcc/d/d-target.def
index d1426a17e99..f79ffb9cd7d 100644
--- a/gcc/d/d-target.def
+++ b/gcc/d/d-target.def
@@ -71,5 +71,18 @@ as the name of the symbol indicating the end address of the 
module info\n\
 section",
  const char *, NULL)
 
+/* The "stdcall" convention is really supported on 32-bit x86/Windows only.
+   The following hook is a helper to determine whether to apply the attribute
+   on declarations with `extern(System)' and `extern(Windows)' linkage.  */
+DEFHOOK
+(d_has_stdcall_convention,
+ "Returns @code{true} if the target supports the stdcall calling convention.\n\
+The hook should also set @var{link_system} to @code{1} if the @code{stdcall}\n\
+attribute 

[Bug c++/95317] [8/9/10 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE on
   |on valid C++14 code, in |valid C++14 code, in
   |tsubst_copy, at |tsubst_copy, at
   |cp/pt.c:15649   |cp/pt.c:15649
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
Fixed for 11 so far.

[Bug c++/95317] [8/9/10/11 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:9f4c41147a41d08a74990eafe69a1064a3c13435

commit r11-7993-g9f4c41147a41d08a74990eafe69a1064a3c13435
Author: Jason Merrill 
Date:   Mon Apr 5 14:26:03 2021 -0400

c++: enum in generic lambda in template [PR95317]

Here we weren't instantiating the enumerators because the arglist still had
the template parameter for the generic lambda, so looking one up failed. 
We
need to instantiate if the non-lambda enclosing scope is non-dependent.

gcc/cp/ChangeLog:

PR c++/95317
* pt.c (lookup_template_class_1): Do tsubst_enum when
tsubsting a generic lambda.

gcc/testsuite/ChangeLog:

PR c++/95317
* g++.dg/cpp1y/lambda-generic-enum1.C: New test.

[Bug c++/95870] [8/9/10/11 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:62d60246e53778db6ee613377dd013ba4b264968

commit r11-7992-g62d60246e53778db6ee613377dd013ba4b264968
Author: Jason Merrill 
Date:   Mon Apr 5 11:34:48 2021 -0400

c++: lambda in DMI in class template [PR95870]

Here enclosing_instantiation_of was failing to find a match because otctx
is
struct S and current_function_decl is S::S(), so the latter has
more
function contexts, and we end up trying to compare S() to NULL_TREE.

After spending a bit of time working on establishing the correspondence in
this case (class <=> constructor), it occurred to me that we could just use
DECL_SOURCE_LOCATION, which is unique for lambdas, since they cannot be
redeclared.  Since we're so close to release, for now I'm only doing this
for the case that was failing before.

gcc/cp/ChangeLog:

PR c++/95870
* pt.c (enclosing_instantiation_of): Compare DECL_SOURCE_LOCATION
if
there is no enclosing non-lambda function.

gcc/testsuite/ChangeLog:

PR c++/95870
* g++.dg/cpp0x/lambda/lambda-nsdmi10.C: New test.

[pushed] c++: enum in generic lambda in template [PR95317]

[Jason Merrill via Gcc-patches]

Here we weren't instantiating the enumerators because the arglist still had
the template parameter for the generic lambda, so looking one up failed.  We
need to instantiate if the non-lambda enclosing scope is non-dependent.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/95317
* pt.c (lookup_template_class_1): Do tsubst_enum when
tsubsting a generic lambda.

gcc/testsuite/ChangeLog:

PR c++/95317
* g++.dg/cpp1y/lambda-generic-enum1.C: New test.
---
 gcc/cp/pt.c   |  3 ++-
 gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum1.C | 10 ++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum1.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d6a8ede386d..41bc633cfce 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10173,7 +10173,8 @@ lookup_template_class_1 (tree d1, tree arglist, tree 
in_decl, tree context,
= tree_cons (arglist, t,
 DECL_TEMPLATE_INSTANTIATIONS (found));
 
-  if (TREE_CODE (template_type) == ENUMERAL_TYPE && !is_dependent_type
+  if (TREE_CODE (template_type) == ENUMERAL_TYPE
+ && !uses_template_parms (current_nonlambda_scope ())
  && !DECL_ALIAS_TEMPLATE_P (gen_tmpl))
/* Now that the type has been registered on the instantiations
   list, we set up the enumerators.  Because the enumeration
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum1.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum1.C
new file mode 100644
index 000..de15443bfcf
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum1.C
@@ -0,0 +1,10 @@
+// PR c++/95317
+// { dg-do compile { target c++14 } }
+
+template  void fn1() {
+  [](auto) {
+enum { VALUE };
+VALUE;
+  };
+}
+int main() { fn1; }

base-commit: 7ebdef2076fda56cb4cffb941f6c2576f980f3b3
prerequisite-patch-id: 22fd889eedb29aa662bdfc0fcc38e7a1072b47b4
-- 
2.27.0

[pushed] c++: lambda in DMI in class template [PR95870]

[Jason Merrill via Gcc-patches]

Here enclosing_instantiation_of was failing to find a match because otctx is
struct S and current_function_decl is S::S(), so the latter has more
function contexts, and we end up trying to compare S() to NULL_TREE.

After spending a bit of time working on establishing the correspondence in
this case (class <=> constructor), it occurred to me that we could just use
DECL_SOURCE_LOCATION, which is unique for lambdas, since they cannot be
redeclared.  Since we're so close to release, for now I'm only doing this
for the case that was failing before.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/95870
* pt.c (enclosing_instantiation_of): Compare DECL_SOURCE_LOCATION if
there is no enclosing non-lambda function.

gcc/testsuite/ChangeLog:

PR c++/95870
* g++.dg/cpp0x/lambda/lambda-nsdmi10.C: New test.
---
 gcc/cp/pt.c| 13 +
 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi10.C | 12 
 2 files changed, 25 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi10.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 396e622c4db..d6a8ede386d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14371,6 +14371,19 @@ enclosing_instantiation_of (tree otctx)
  || instantiated_lambda_fn_p (tctx));
tctx = decl_function_context (tctx))
 ++lambda_count;
+
+  if (!tctx)
+{
+  /* Match using DECL_SOURCE_LOCATION, which is unique for all lambdas.
+
+For GCC 11 the above condition limits this to the previously failing
+case where all enclosing functions are lambdas (95870).  FIXME.  */
+  for (tree ofn = fn; ofn; ofn = decl_function_context (ofn))
+   if (DECL_SOURCE_LOCATION (ofn) == DECL_SOURCE_LOCATION (otctx))
+ return ofn;
+  gcc_unreachable ();
+}
+
   for (; fn; fn = decl_function_context (fn))
 {
   tree ofn = fn;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi10.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi10.C
new file mode 100644
index 000..810ed538719
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi10.C
@@ -0,0 +1,12 @@
+// PR c++/95870
+// { dg-do compile { target c++11 } }
+
+template  struct S {
+  S();
+  int b = []() -> int { enum E {}; return 1; }();
+};
+struct C : S {
+  C();
+};
+template  S::S() = default;
+C::C() {}

base-commit: 7ebdef2076fda56cb4cffb941f6c2576f980f3b3
-- 
2.27.0

Re: Default debug format for AVR

[Jim Wilson]

On Sat, Apr 3, 2021 at 6:24 PM Simon Marchi via Gcc  wrote:

> The default debug format (when using only -g) for the AVR target is
> stabs.  Is there a reason for it not being DWARF, and would it be
> possible to maybe consider possibly thinking about making it default to
> DWARF?  I am asking because the support for stabs in GDB is pretty much
> untested and bit-rotting, so I think it would be more useful for
> everyone to use DWARF.
>

I tried to deprecate the stabs support a little over 4 years ago.
https://gcc.gnu.org/pipermail/gcc-patches/2017-December/489296.html
There was a suggestion to change the error to a warning, but my startup
company job kept me so busy I never had a chance to follow up on this.

I would like to see the stabs support deprecated and the later removed from
gcc.  No new features have been added in a long time, and it is only being
maintained in the sense that when it fails it is fixed to ignore source
code constructs that it doesn't support.  The longer it survives in this
state, the less useful it becomes.

Jim

[Bug c++/99066] [8/9/10 Regression] non-weak definition emitted for explicit instantiation declaration

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #3)
> r104041, yes.  Bizarre that this went unnoticed for over 15 years.

Very surprising, isn't it!

Re: [PATCH] c++: placeholder type constraint on structured binding [PR99899]

[Jason Merrill via Gcc-patches]

On 4/5/21 12:31 PM, Patrick Palka wrote:

On Mon, 5 Apr 2021, Patrick Palka wrote:


In this PR, we're crashing because the constraint handling inside
do_auto_deduction doesn't expect to see an adc_decomp_type context.
This patch fixes this by treating adc_decomp_type like adc_variable_type
and adc_return_type during the constraint handling.

Meanwhile, I noticed we weren't checking constraints at all when binding
an array via a structured binding, since do_auto_deduction would exit
early and bypass the constraint check.  This patch fixes this by
replacing the early exit with an appropriate setup of the 'targs'
vector.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?


OK.


gcc/cp/ChangeLog:

PR c++/99899
* pt.c (do_auto_deduction): Don't exit early when deducing the
array type of a structured binding.  Also handle adc_decomp_type
during constraint checking.

gcc/testsuite/ChangeLog:

PR c++/99899
* g++.dg/cpp2a/concepts-placeholder7.C: New test.
---
  gcc/cp/pt.c   | 22 +++-
  .../g++.dg/cpp2a/concepts-placeholder7.C  | 34 +++
  2 files changed, 48 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1d19a59dd62..0f9f5858038 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29438,8 +29438,6 @@ do_auto_deduction (tree type, tree init, tree auto_node,
 tsubst_flags_t complain, auto_deduction_context context,
   tree outer_targs, int flags)
  {
-  tree targs;
-
if (init == error_mark_node)
  return error_mark_node;
  
@@ -29503,14 +29501,19 @@ do_auto_deduction (tree type, tree init, tree auto_node,

else
  init = resolve_nondeduced_context (init, complain);
  
+  tree targs;

if (context == adc_decomp_type
&& auto_node == type
&& init != error_mark_node
&& TREE_CODE (TREE_TYPE (init)) == ARRAY_TYPE)
-/* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
-   and initializer has array type, deduce cv-qualified array type.  */
-return cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
-complain);
+{
+  /* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
+and initializer has array type, deduce cv-qualified array type.  */
+  targs = make_tree_vec (1);
+  TREE_VEC_ELT (targs, 0)
+   = cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
+   complain);


On second thought, I think we can get away with using just TREE_TYPE (init)
here and leaving the propagation of type qualifiers to tsubst.  This has
the effect of making us reject the testcase placeholder8.C below, which
is consistent with the non-array case.  IIUC, the type qualifiers on a
constrained 'auto' shouldn't be relevant during constraint checking.

I'm testing the following:

-- >8 --

gcc/cp/ChangeLog:

PR c++/99899
* pt.c (do_auto_deduction): Don't exit early when deducing the
array type of a structured binding.  Also handle adc_decomp_type
during constraint checking.

gcc/testsuite/ChangeLog:

PR c++/99899
* g++.dg/cpp2a/concepts-placeholder7.C: New test.
* g++.dg/cpp2a/concepts-placeholder8.C: New test.
---
  gcc/cp/pt.c   | 20 +++-
  .../g++.dg/cpp2a/concepts-placeholder7.C  | 32 +++
  .../g++.dg/cpp2a/concepts-placeholder8.C  | 10 ++
  3 files changed, 54 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder8.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1d19a59dd62..fd1e4db42cf 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29438,8 +29438,6 @@ do_auto_deduction (tree type, tree init, tree auto_node,
 tsubst_flags_t complain, auto_deduction_context context,
   tree outer_targs, int flags)
  {
-  tree targs;
-
if (init == error_mark_node)
  return error_mark_node;
  
@@ -29503,14 +29501,17 @@ do_auto_deduction (tree type, tree init, tree auto_node,

else
  init = resolve_nondeduced_context (init, complain);
  
+  tree targs;

if (context == adc_decomp_type
&& auto_node == type
&& init != error_mark_node
&& TREE_CODE (TREE_TYPE (init)) == ARRAY_TYPE)
-/* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
-   and initializer has array type, deduce cv-qualified array type.  */
-return cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
-complain);
+{
+  /* [dcl.struct.bind]/1 - if decomposition declaration has no 
ref-qualifiers
+and initializer 

[c-family] Fix small regression with -fdump-ada-spec

[Eric Botcazou]

When the enumeration constants of an enumeration type are defined by explicit 
values, the binding generated by -fdump-ada-spec does not use an enumeration 
type on the Ada side, because the set of allowed values in C/C++ is larger 
than the set of allowed values in Ada, but instead use an integer subtype and 
defines a set of explicit constants, which used to be of this subtype but were 
changed to the base type at some point.  This reinstates the subtype for them.

Tested on x86-64/Linux, applied on the mainline.


2021-04-05  Eric Botcazou  

* c-ada-spec.c (is_simple_enum): Minor tweaks.
(dump_ada_enum_type): Add TYPE and PARENT parameters.  For non-simple
enumeral types, use again the type name for the enumeration constants.
(dump_ada_node): Adjust call to dump_ada_enum_type.
(dump_nested_type): Likewise.

-- 
Eric Botcazoudiff --git a/gcc/c-family/c-ada-spec.c b/gcc/c-family/c-ada-spec.c
index dd8e8bbd90a..9fef5f05cc8 100644
--- a/gcc/c-family/c-ada-spec.c
+++ b/gcc/c-family/c-ada-spec.c
@@ -1932,8 +1932,8 @@ dump_ada_template (pretty_printer *buffer, tree t, int spc)
   return num_inst > 0;
 }
 
-/* Return true if NODE is a simple enum types, that can be mapped to an
-   Ada enum type directly.  */
+/* Return true if NODE is a simple enumeral type that can be mapped to an
+   Ada enumeration type directly.  */
 
 static bool
 is_simple_enum (tree node)
@@ -1947,9 +1947,7 @@ is_simple_enum (tree node)
   if (TREE_CODE (int_val) != INTEGER_CST)
 	int_val = DECL_INITIAL (int_val);
 
-  if (!tree_fits_shwi_p (int_val))
-	return false;
-  else if (tree_to_shwi (int_val) != count)
+  if (!tree_fits_shwi_p (int_val) || tree_to_shwi (int_val) != count)
 	return false;
 
   count++;
@@ -1958,11 +1956,12 @@ is_simple_enum (tree node)
   return true;
 }
 
-/* Dump in BUFFER an enumeral type NODE in Ada syntax.  SPC is the indentation
-   level.  */
+/* Dump in BUFFER the declaration of enumeral NODE of type TYPE in Ada syntax.
+   PARENT is the parent node of NODE.  SPC is the indentation level.  */
 
 static void
-dump_ada_enum_type (pretty_printer *buffer, tree node, int spc)
+dump_ada_enum_type (pretty_printer *buffer, tree node, tree type, tree parent,
+		int spc)
 {
   if (is_simple_enum (node))
 {
@@ -1993,25 +1992,29 @@ dump_ada_enum_type (pretty_printer *buffer, tree node, int spc)
 	pp_string (buffer, "unsigned");
   else
 	pp_string (buffer, "int");
+
   for (tree value = TYPE_VALUES (node); value; value = TREE_CHAIN (value))
 	{
+	  tree int_val = TREE_VALUE (value);
+
+	  if (TREE_CODE (int_val) != INTEGER_CST)
+	int_val = DECL_INITIAL (int_val);
+
 	  pp_semicolon (buffer);
 	  newline_and_indent (buffer, spc);
 
 	  pp_ada_tree_identifier (buffer, TREE_PURPOSE (value), node, false);
 	  pp_string (buffer, " : constant ");
 
-	  if (TYPE_UNSIGNED (node))
-	pp_string (buffer, "unsigned");
+	  if (TYPE_NAME (node))
+	dump_ada_node (buffer, node, NULL_TREE, spc, false, true);
+	  else if (type)
+	dump_ada_node (buffer, type, NULL_TREE, spc, false, true);
 	  else
-	pp_string (buffer, "int");
+	dump_anonymous_type_name (buffer, node, parent);
 
 	  pp_string (buffer, " := ");
-	  dump_ada_node (buffer,
-			 TREE_CODE (TREE_VALUE (value)) == INTEGER_CST
-			 ? TREE_VALUE (value)
-			 : DECL_INITIAL (TREE_VALUE (value)),
-			 node, spc, false, true);
+	  dump_ada_node (buffer, int_val, node, spc, false, true);
 	}
 }
 }
@@ -2098,7 +2101,7 @@ dump_ada_node (pretty_printer *buffer, tree node, tree type, int spc,
   if (name_only)
 	dump_ada_node (buffer, TYPE_NAME (node), node, spc, false, true);
   else
-	dump_ada_enum_type (buffer, node, spc);
+	dump_ada_enum_type (buffer, node, type, NULL_TREE, spc);
   break;
 
 case REAL_TYPE:
@@ -2577,7 +2580,7 @@ dump_nested_type (pretty_printer *buffer, tree field, tree t, tree parent,
   else
 	dump_anonymous_type_name (buffer, field_type, parent);
   pp_string (buffer, " is ");
-  dump_ada_enum_type (buffer, field_type, spc);
+  dump_ada_enum_type (buffer, field_type, NULL_TREE, parent, spc);
   pp_semicolon (buffer);
   newline_and_indent (buffer, spc);
   break;

[Bug d/99917] New: gcc/d/dmd/mtype.c:5223: missing call to va_end ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 99917
   Summary: gcc/d/dmd/mtype.c:5223: missing call to va_end ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk.git/gcc/d/dmd/mtype.c:5223:30: error: va_list 'ap' was opened but not
closed by va_end(). [va_end_missing]

Source code is

va_list ap;
va_start(ap, format);
buf.vprintf(format, ap);
return buf.extractChars();

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 85233, which changed state.

Bug 85233 Summary: Incorrect -Wmaybe-uninitialized with -fpartial-inlining 
-finline-small-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85233

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug ipa/85233] Incorrect -Wmaybe-uninitialized with -fpartial-inlining -finline-small-functions

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||7.3.0, 8.3.0, 9.2.0
 Status|NEW |RESOLVED
   Target Milestone|--- |10.0
   Keywords||missed-optimization
 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
The warning disappeared with r276416 (10.0.0 20191001) so this can be resolved
as fixed.

[Bug middle-end/84078] false positive for -Wmaybe-uninitialized with __asm__

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0, 4.1.0, 4.8.4,
   ||4.9.4, 5.5.0, 6.4.0, 7.2.0,
   ||8.3.0, 9.1.0
   Keywords||missed-optimization
   Last reconfirmed|2018-01-29 00:00:00 |2021-4-5
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Reconfirmed with GCC 11 and -O1/-O2 and the slightly reduced test case below. 
I don't see anything in the IL that could be used to prove the uninitialized
variable isn't used: a_3 is uninitialized when b_6 != 0 || x == 0, and a_3 is
used when b_2 == 0 && c_9 == 0.  The two predicates aren't mutually exclusive
so the warning triggers.

$ cat pr84078.c && gcc -O2  -S -Wall -fdump-tree-uninit=/dev/stdout pr84078.c
int x, z;

int f (void);

void g (int b)
{
  int a;

  if (!b)
{
  if (x)
a = x;
  else
b = 1;
}

  {
int c;
__asm __volatile("" : "=r" (c));
if (c)
  f ();
  }

  if (b)
return;

  z = a;
}

;; Function g (g, funcdef_no=0, decl_uid=1947, cgraph_uid=1, symbol_order=2)

[AFTER NORMALIZATION -- [DEF]:
 (.NOT.) b_6(D) == 0


[AFTER NORMALIZATION -- [DEF]:
a_3 = PHI 
is guarded by :

x.0_1 != 0 (.AND.) b_6(D) == 0


[AFTER NORMALIZATION -- [USE]:
z = a_3;
is guarded by :

 (.NOT.) b_2 != 0


pr84078.c: In function ‘g’:
pr84078.c:27:5: warning: ‘a’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   27 |   z = a;
  |   ~~^~~
pr84078.c:7:7: note: ‘a’ was declared here
7 |   int a;
  |   ^
void g (int b)
{
  int c;
  int a;
  int x.0_1;

   [local count: 1073741824]:
  if (b_6(D) == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  goto ; [100.00%]

   [local count: 536870913]:
  x.0_1 = x;
  if (x.0_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 268435457]:
  goto ; [100.00%]

   [local count: 268435457]:

   [local count: 1073741824]:
  # b_2 = PHI 
  # a_3 = PHI 
  __asm__ __volatile__("" : "=r" c_9);
  if (c_9 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719407024]:
  goto ; [100.00%]

   [local count: 354334800]:
  f ();

   [local count: 1073741824]:
  if (b_2 != 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 365072224]:
  goto ; [100.00%]

   [local count: 708669601]:
  z = a_3;

   [local count: 1073741824]:
  return;

}

Re: [PATCH] c++: placeholder type constraint on structured binding [PR99899]

[Patrick Palka via Gcc-patches]

On Mon, 5 Apr 2021, Patrick Palka wrote:

> In this PR, we're crashing because the constraint handling inside
> do_auto_deduction doesn't expect to see an adc_decomp_type context.
> This patch fixes this by treating adc_decomp_type like adc_variable_type
> and adc_return_type during the constraint handling.
> 
> Meanwhile, I noticed we weren't checking constraints at all when binding
> an array via a structured binding, since do_auto_deduction would exit
> early and bypass the constraint check.  This patch fixes this by
> replacing the early exit with an appropriate setup of the 'targs'
> vector.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
> 
> gcc/cp/ChangeLog:
> 
>   PR c++/99899
>   * pt.c (do_auto_deduction): Don't exit early when deducing the
>   array type of a structured binding.  Also handle adc_decomp_type
>   during constraint checking.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/99899
>   * g++.dg/cpp2a/concepts-placeholder7.C: New test.
> ---
>  gcc/cp/pt.c   | 22 +++-
>  .../g++.dg/cpp2a/concepts-placeholder7.C  | 34 +++
>  2 files changed, 48 insertions(+), 8 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C
> 
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 1d19a59dd62..0f9f5858038 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -29438,8 +29438,6 @@ do_auto_deduction (tree type, tree init, tree 
> auto_node,
> tsubst_flags_t complain, auto_deduction_context context,
>  tree outer_targs, int flags)
>  {
> -  tree targs;
> -
>if (init == error_mark_node)
>  return error_mark_node;
>  
> @@ -29503,14 +29501,19 @@ do_auto_deduction (tree type, tree init, tree 
> auto_node,
>else
>  init = resolve_nondeduced_context (init, complain);
>  
> +  tree targs;
>if (context == adc_decomp_type
>&& auto_node == type
>&& init != error_mark_node
>&& TREE_CODE (TREE_TYPE (init)) == ARRAY_TYPE)
> -/* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
> -   and initializer has array type, deduce cv-qualified array type.  */
> -return cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
> -  complain);
> +{
> +  /* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
> +  and initializer has array type, deduce cv-qualified array type.  */
> +  targs = make_tree_vec (1);
> +  TREE_VEC_ELT (targs, 0)
> + = cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
> + complain);

On second thought, I think we can get away with using just TREE_TYPE (init)
here and leaving the propagation of type qualifiers to tsubst.  This has
the effect of making us reject the testcase placeholder8.C below, which
is consistent with the non-array case.  IIUC, the type qualifiers on a
constrained 'auto' shouldn't be relevant during constraint checking.

I'm testing the following:

-- >8 --

gcc/cp/ChangeLog:

PR c++/99899
* pt.c (do_auto_deduction): Don't exit early when deducing the
array type of a structured binding.  Also handle adc_decomp_type
during constraint checking.

gcc/testsuite/ChangeLog:

PR c++/99899
* g++.dg/cpp2a/concepts-placeholder7.C: New test.
* g++.dg/cpp2a/concepts-placeholder8.C: New test.
---
 gcc/cp/pt.c   | 20 +++-
 .../g++.dg/cpp2a/concepts-placeholder7.C  | 32 +++
 .../g++.dg/cpp2a/concepts-placeholder8.C  | 10 ++
 3 files changed, 54 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder8.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1d19a59dd62..fd1e4db42cf 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29438,8 +29438,6 @@ do_auto_deduction (tree type, tree init, tree auto_node,
tsubst_flags_t complain, auto_deduction_context context,
   tree outer_targs, int flags)
 {
-  tree targs;
-
   if (init == error_mark_node)
 return error_mark_node;
 
@@ -29503,14 +29501,17 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
   else
 init = resolve_nondeduced_context (init, complain);
 
+  tree targs;
   if (context == adc_decomp_type
   && auto_node == type
   && init != error_mark_node
   && TREE_CODE (TREE_TYPE (init)) == ARRAY_TYPE)
-/* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
-   and initializer has array type, deduce cv-qualified array type.  */
-return cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
-complain);
+{
+  /* [dcl.struct.bind]/1 - if decomposition declaration has no 
ref-qualifiers
+

Re: Remove RMS from the GCC Steering Committee

[Nathan Sidwell]

Ian,
thank you for taking the time to write this.  I appreciate that you have 
reached out.  I do have a couple of comments though.


On 4/1/21 3:19 PM, Ian Lance Taylor wrote:

On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell  wrote:



I think you want the steering committee to issue a statement about
RMS's behavior.  I think that is approximately as likely as collecting
the GCC maintainers together to issue a statement about RMS's
behavior.  It's not impossible.  But it's not something anybody is
really trying to do.


And that speaks volumes.  The one thing we have in the form of structure 
is not trying to do that thing.



Going back to the GCC steering committee, you make several accusations
(I think that is a fair word to use here).  Again I'm going to give my
own personal reactions.  I'm telling the truth to the best of my
recollection, but I can't prove what I say.


That's understandable.

  /You/ gave him controlling rights.


No, we didn't.  The pattern of his interactions with the steering
committee, which were infrequent, was that he would ask us to do
something, and we would explain why we were not going to do that.


The appearance is that the SC did.  Another event that I've now 
remembered concerns powerpc floating point.  My understanding is that 
RMS vetoed something, and an SC member reached out to me, as if the 
personal interactions of another SC member was something I could 
control.  If RMS had no power, that conversation need not have happened.



Sorry, I don't quite understand this one.  It's not clear to me how
the committee misled anyone.


by observable behaviour, including the listing on the web page -- who 
other than the SC could tell it was incorrect?  (perhaps you're 
associating intent with 'misled'?  I'm associating 'impact')


You're quite likely right about the timing of the C++ change, but the 
earlier interaction caused damage.



2) Last year, I asked for libcody to be added as a subcomponent, with
its Apachev2 license intact.  AFAICT RMS was involved in that licensing
discussion, /for which I never received a response/.  He was not at the
FSF then, so he could not render any FSF licensing opinion.  Why was he
involved?  If he was not involved, how did he learn of it in order to
ask me questions about C++ modules?  I only emailed the SC and the
timing is too coincidental to draw a different conclusion.


Yes, we definitely dropped the ball on that.  Sorry.  If that ever
happens again I would encourage you to ping.

I checked the mailing list archives.  Jeff and I expressed support for
using libcody.  Nobody else said anything.  Certainly RMS didn't say
anything, and it would have been astonishing if he had.  But, yes, he
was CC'ed.


I've realized what happened was that I very quickly received an email 
saying just 'looks good to me'.  Which didn't read like an SC blessing 
at all.  I thought it was just personal comment.   You're right, I 
should have pinged, but one reason I didn't was because I was concerned 
RMS would veto the whole shebang.  Don't poke the sleeping bear.   Fault 
all round.


nathan
--
Nathan Sidwell

[PATCH] c++: placeholder type constraint on structured binding [PR99899]

[Patrick Palka via Gcc-patches]

In this PR, we're crashing because the constraint handling inside
do_auto_deduction doesn't expect to see an adc_decomp_type context.
This patch fixes this by treating adc_decomp_type like adc_variable_type
and adc_return_type during the constraint handling.

Meanwhile, I noticed we weren't checking constraints at all when binding
an array via a structured binding, since do_auto_deduction would exit
early and bypass the constraint check.  This patch fixes this by
replacing the early exit with an appropriate setup of the 'targs'
vector.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

PR c++/99899
* pt.c (do_auto_deduction): Don't exit early when deducing the
array type of a structured binding.  Also handle adc_decomp_type
during constraint checking.

gcc/testsuite/ChangeLog:

PR c++/99899
* g++.dg/cpp2a/concepts-placeholder7.C: New test.
---
 gcc/cp/pt.c   | 22 +++-
 .../g++.dg/cpp2a/concepts-placeholder7.C  | 34 +++
 2 files changed, 48 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1d19a59dd62..0f9f5858038 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29438,8 +29438,6 @@ do_auto_deduction (tree type, tree init, tree auto_node,
tsubst_flags_t complain, auto_deduction_context context,
   tree outer_targs, int flags)
 {
-  tree targs;
-
   if (init == error_mark_node)
 return error_mark_node;
 
@@ -29503,14 +29501,19 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
   else
 init = resolve_nondeduced_context (init, complain);
 
+  tree targs;
   if (context == adc_decomp_type
   && auto_node == type
   && init != error_mark_node
   && TREE_CODE (TREE_TYPE (init)) == ARRAY_TYPE)
-/* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
-   and initializer has array type, deduce cv-qualified array type.  */
-return cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
-complain);
+{
+  /* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
+and initializer has array type, deduce cv-qualified array type.  */
+  targs = make_tree_vec (1);
+  TREE_VEC_ELT (targs, 0)
+   = cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
+   complain);
+}
   else if (AUTO_IS_DECLTYPE (auto_node))
 {
   tree stripped_init = tree_strip_any_location_wrapper (init);
@@ -29596,7 +29599,8 @@ do_auto_deduction (tree type, tree init, tree auto_node,
   if (processing_template_decl)
{
  gcc_checking_assert (context == adc_variable_type
-  || context == adc_return_type);
+  || context == adc_return_type
+  || context == adc_decomp_type);
  gcc_checking_assert (!type_dependent_expression_p (init));
  /* If the constraint is dependent, we need to wait until
 instantiation time to resolve the placeholder.  */
@@ -29604,7 +29608,9 @@ do_auto_deduction (tree type, tree init, tree auto_node,
return type;
}
 
-  if ((context == adc_return_type || context == adc_variable_type)
+  if ((context == adc_return_type
+  || context == adc_variable_type
+  || context == adc_decomp_type)
  && current_function_decl
  && DECL_TEMPLATE_INFO (current_function_decl))
outer_targs = DECL_TI_ARGS (current_function_decl);
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C
new file mode 100644
index 000..db352a01e83
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C
@@ -0,0 +1,34 @@
+// PR c++/99899
+// { dg-do compile { target c++20 } }
+
+template  concept C1 = sizeof(T) > sizeof(int[1]);
+
+template 
+void f() {
+  int x[] = {1,2};
+  int y[] = {3};
+  C1 auto [a,b] = x;
+  C1 auto [c] = y; // { dg-error "constraints" }
+}
+
+template 
+void g() {
+  T x[] = {1,2};
+  T y[] = {3};
+  C1 auto [a,b] = x;
+  C1 auto [c] = y; // { dg-error "constraints" }
+}
+
+template void g();
+
+
+template  concept C2 = sizeof...(Ts) > 1;
+
+struct S { int a, b; } s;
+
+template 
+void h() {
+  const C2 auto& [a, b] = s;
+}
+
+template void h();
-- 
2.31.1.189.g2e36527f23

[Bug c++/99899] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29630

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE: in do_auto_deduction,  |[11 Regression] ICE: in
   |at cp/pt.c:29630|do_auto_deduction, at
   ||cp/pt.c:29630
   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
   Target Milestone|--- |11.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2021-04-05

--- Comment #1 from Patrick Palka  ---
Confirmed, started with r11-7540.

[committed] analyzer: fix ICE on zero-arg calls passed to __attribute__((nonnull)) [PR 99906]

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7988-g7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb.

gcc/analyzer/ChangeLog:
PR analyzer/99906
* analyzer.cc (maybe_reconstruct_from_def_stmt): Fix NULL
dereference on calls with zero arguments.
* sm-malloc.cc (malloc_state_machine::on_stmt): When handling
__attribute__((nonnull)), only call get_diagnostic_tree if the
result will be used.

gcc/testsuite/ChangeLog:
PR analyzer/99906
* gcc.dg/analyzer/pr99906.c: New test.
---
 gcc/analyzer/analyzer.cc| 2 +-
 gcc/analyzer/sm-malloc.cc   | 3 ++-
 gcc/testsuite/gcc.dg/analyzer/pr99906.c | 3 +++
 3 files changed, 6 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr99906.c

diff --git a/gcc/analyzer/analyzer.cc b/gcc/analyzer/analyzer.cc
index 2b4cffd08f5..12c03f6cfbd 100644
--- a/gcc/analyzer/analyzer.cc
+++ b/gcc/analyzer/analyzer.cc
@@ -148,7 +148,7 @@ maybe_reconstruct_from_def_stmt (tree ssa_name,
  }
return build_call_array_loc (gimple_location (call_stmt),
 return_type, fn,
-num_args, [0]);
+num_args, args.address ());
   }
   break;
 }
diff --git a/gcc/analyzer/sm-malloc.cc b/gcc/analyzer/sm-malloc.cc
index ae03b068a88..1d5b8601b1f 100644
--- a/gcc/analyzer/sm-malloc.cc
+++ b/gcc/analyzer/sm-malloc.cc
@@ -1600,11 +1600,11 @@ malloc_state_machine::on_stmt (sm_context *sm_ctxt,
  if (bitmap_empty_p (nonnull_args)
  || bitmap_bit_p (nonnull_args, i))
{
- tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
  state_t state = sm_ctxt->get_state (stmt, arg);
  /* Can't use a switch as the states are non-const.  */
  if (unchecked_p (state))
{
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
  sm_ctxt->warn (node, stmt, arg,
 new possible_null_arg (*this, diag_arg,
callee_fndecl,
@@ -1616,6 +1616,7 @@ malloc_state_machine::on_stmt (sm_context *sm_ctxt,
}
  else if (state == m_null)
{
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
  sm_ctxt->warn (node, stmt, arg,
 new null_arg (*this, diag_arg,
   callee_fndecl, i));
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr99906.c 
b/gcc/testsuite/gcc.dg/analyzer/pr99906.c
new file mode 100644
index 000..bb399a3e2ff
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr99906.c
@@ -0,0 +1,3 @@
+void bar(void *) __attribute__((__nonnull__));
+void *baz(void);
+void foo(void) { bar(baz()); }
-- 
2.26.2

[committed] analyzer: fix apparent hang with -fanalyzer-verbosity=0 [PR analyzer/99886]

[David Malcolm via Gcc-patches]

The analyzer appeared to enter an infinite loop on malloc-1.c
when -fanalyzer-verbosity=0 was used.  In fact, it was slowly
counting from 0 to 0x.

Root cause is looping up to effectively ((unsigned)0) - 1 in
diagnostic_manager::consolidate_conditions when there are no events
in the path.

Fixed by the following, which uses signed integers when subtracting
from path->num_events () when simplifying checker_paths.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7987-g69b66ff02353a87585329bb3cf4ac20d6dee1b16.

gcc/analyzer/ChangeLog:
PR analyzer/99886
* diagnostic-manager.cc
(diagnostic_manager::prune_interproc_events): Use signed integers
when subtracting one from path->num_events ().
(diagnostic_manager::consolidate_conditions): Likewise.  Convert
next_idx to a signed int.

gcc/testsuite/ChangeLog:
PR analyzer/99886
* gcc.dg/analyzer/pr99886.c: New test.
---
 gcc/analyzer/diagnostic-manager.cc  |  8 +---
 gcc/testsuite/gcc.dg/analyzer/pr99886.c | 21 +
 2 files changed, 26 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr99886.c

diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index 9ec3e899e85..443ff058f65 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -2081,7 +2081,7 @@ diagnostic_manager::prune_interproc_events (checker_path 
*path) const
   do
 {
   changed = false;
-  int idx = path->num_events () - 1;
+  int idx = (signed)path->num_events () - 1;
   while (idx >= 0)
{
  /* Prune [..., call, function-entry, return, ...] triples.  */
@@ -2200,7 +2200,9 @@ diagnostic_manager::consolidate_conditions (checker_path 
*path) const
   if (flag_analyzer_verbose_edges)
 return;
 
-  for (unsigned start_idx = 0; start_idx < path->num_events () - 1; 
start_idx++)
+  for (int start_idx = 0;
+   start_idx < (signed)path->num_events () - 1;
+   start_idx++)
 {
   if (path->cfg_edge_pair_at_p (start_idx))
{
@@ -2231,7 +2233,7 @@ diagnostic_manager::consolidate_conditions (checker_path 
*path) const
   [start_idx, next_idx)
 where all apart from the final event are on the same line,
 and all are either TRUE or FALSE edges, matching the initial.  */
- unsigned next_idx = start_idx + 2;
+ int next_idx = start_idx + 2;
  while (path->cfg_edge_pair_at_p (next_idx)
 && same_line_as_p (start_exp_loc, path, next_idx))
{
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr99886.c 
b/gcc/testsuite/gcc.dg/analyzer/pr99886.c
new file mode 100644
index 000..da768ba6298
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr99886.c
@@ -0,0 +1,21 @@
+/* Regression test for hang with -fanalyzer-verbosity=0.  */
+/* { dg-additional-options "-fanalyzer-verbosity=0" } */
+
+#include 
+
+struct coord {
+  float x;
+  float y;
+};
+
+void test_34 (void)
+{
+  float *q;
+  struct coord *p = malloc (sizeof (struct coord));
+  if (!p)
+return;
+  p->x = 0.0f;
+  q = >x;
+  free (p);
+  *q = 1.0f; /* { dg-warning "use after 'free' of 'q'" } */
+};
-- 
2.26.2

[Bug c++/99380] [modules] Unexpected MODULE-EXPORT request when partially preprocessing header unit

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Nathan Sidwell  ---
* dd6f588a7b8 2021-04-05 | c++: Unneeded export query [PR 99380]

[Bug c++/99380] [modules] Unexpected MODULE-EXPORT request when partially preprocessing header unit

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:dd6f588a7b8878d677af51ff4d1c1e3f9f6f40db

commit r11-7989-gdd6f588a7b8878d677af51ff4d1c1e3f9f6f40db
Author: Nathan Sidwell 
Date:   Mon Apr 5 07:51:28 2021 -0700

c++: Unneeded export query [PR 99380]

This problem got introduced fixing a module numbering problem.  When
preprocessing a header unit, we don't need to send an EXPORT query
unless we're also determining dependencies, or the mapper asked us
to.  Sadly the testsuite isn't set up to test this kind of subtlety.
I manually did that with stdin/stdout.

PR c++/99380
gcc/cp/
* module.cc (name_pending_imports): Drop 'atend' parm.  Don't
query export when not needed.
(preprocess_module, preprocessed_module): Adjust.

c++: Unneeded export query [PR 99380]

[Nathan Sidwell]

This problem got introduced fixing a module numbering problem.	When 
preprocessing a header unit, we don't need to send an EXPORT query 
unless we're also determining dependencies, or the mapper askedus to. 
Sadly the testsuite isn't set up to test this kind of subtlety. I 
manually did that with stdin/stdout.


PR c++/99380
gcc/cp/
* module.cc (name_pending_imports): Drop 'atend' parm.  Don't
query export when not needed.
(preprocess_module, preprocessed_module): Adjust.

--
Nathan Sidwell
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index d5b7d28ded5..c80c7bcc70f 100644
--- i/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -19262,15 +19262,11 @@ module_begin_main_file (cpp_reader *reader, line_maps *lmaps,
filenames.   */
 
 static void
-name_pending_imports (cpp_reader *reader, bool at_end)
+name_pending_imports (cpp_reader *reader)
 {
   auto *mapper = get_mapper (cpp_main_loc (reader));
 
-  bool only_headers = (flag_preprocess_only
-		   && !bool (mapper->get_flags () & Cody::Flags::NameOnly)
-		   && !cpp_get_deps (reader));
-  if (at_end
-  && (!vec_safe_length (pending_imports) || only_headers))
+  if (!vec_safe_length (pending_imports))
 /* Not doing anything.  */
 return;
 
@@ -19278,40 +19274,56 @@ name_pending_imports (cpp_reader *reader, bool at_end)
 
   auto n = dump.push (NULL);
   dump () && dump ("Resolving direct import names");
+  bool want_deps = (bool (mapper->get_flags () & Cody::Flags::NameOnly)
+		|| cpp_get_deps (reader));
+  bool any = false;
 
-  mapper->Cork ();
   for (unsigned ix = 0; ix != pending_imports->length (); ix++)
 {
   module_state *module = (*pending_imports)[ix];
   gcc_checking_assert (module->is_direct ());
-  if (!module->filename
-	  && !module->visited_p
-	  && (module->is_header () || !only_headers))
+  if (!module->filename && !module->visited_p)
 	{
-	  module->visited_p = true;
-	  Cody::Flags flags = (flag_preprocess_only
-			   ? Cody::Flags::None : Cody::Flags::NameOnly);
+	  bool export_p = (module->module_p
+			   && (module->is_partition () || module->exported_p));
 
-	  if (module->module_p
-	  && (module->is_partition () || module->exported_p))
+	  Cody::Flags flags = Cody::Flags::None;
+	  if (flag_preprocess_only
+	  && !(module->is_header () && !export_p))
+	{
+	  if (!want_deps)
+		continue;
+	  flags = Cody::Flags::NameOnly;
+	}
+
+	  if (!any)
+	{
+	  any = true;
+	  mapper->Cork ();
+	}
+	  if (export_p)
 	mapper->ModuleExport (module->get_flatname (), flags);
 	  else
 	mapper->ModuleImport (module->get_flatname (), flags);
+	  module->visited_p = true;
 	}
 }
-  
-  auto response = mapper->Uncork ();
-  auto r_iter = response.begin ();
-  for (unsigned ix = 0; ix != pending_imports->length (); ix++)
+
+  if (any)
 {
-  module_state *module = (*pending_imports)[ix];
-  if (module->visited_p)
+  auto response = mapper->Uncork ();
+  auto r_iter = response.begin ();
+  for (unsigned ix = 0; ix != pending_imports->length (); ix++)
 	{
-	  module->visited_p = false;
-	  gcc_checking_assert (!module->filename);
+	  module_state *module = (*pending_imports)[ix];
+	  if (module->visited_p)
+	{
+	  module->visited_p = false;
+	  gcc_checking_assert (!module->filename);
 
-	  module->set_filename (*r_iter);
-	  ++r_iter;
+	  module->set_filename (*r_iter);
+	  ++r_iter;
+	}
 	}
 }
 
@@ -19384,7 +19396,7 @@ preprocess_module (module_state *module, location_t from_loc,
 	  unsigned n = dump.push (NULL);
 
 	  dump () && dump ("Reading %M preprocessor state", module);
-	  name_pending_imports (reader, false);
+	  name_pending_imports (reader);
 
 	  /* Preserve the state of the line-map.  */
 	  unsigned pre_hwm = LINEMAPS_ORDINARY_USED (line_table);
@@ -19446,7 +19458,7 @@ preprocessed_module (cpp_reader *reader)
 
   dump () && dump ("Completed phase-4 (tokenization) processing");
 
-  name_pending_imports (reader, true);
+  name_pending_imports (reader);
   vec_free (pending_imports);
 
   spans.maybe_init ();

[Bug analyzer/99906] [11 Regression] ICE: SIGSEGV in maybe_reconstruct_from_def_stmt with -fanalyzer

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/99886] Delay loop in -fanalyzer seen on gcc.dg/analyzer/malloc-1.c with -fanalyzer-verbosity=0

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/99906] [11 Regression] ICE: SIGSEGV in maybe_reconstruct_from_def_stmt with -fanalyzer

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb

commit r11-7988-g7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb
Author: David Malcolm 
Date:   Mon Apr 5 10:51:46 2021 -0400

analyzer: fix ICE on zero-arg calls passed to __attribute__((nonnull)) [PR
99906]

gcc/analyzer/ChangeLog:
PR analyzer/99906
* analyzer.cc (maybe_reconstruct_from_def_stmt): Fix NULL
dereference on calls with zero arguments.
* sm-malloc.cc (malloc_state_machine::on_stmt): When handling
__attribute__((nonnull)), only call get_diagnostic_tree if the
result will be used.

gcc/testsuite/ChangeLog:
PR analyzer/99906
* gcc.dg/analyzer/pr99906.c: New test.

[Bug analyzer/99886] Delay loop in -fanalyzer seen on gcc.dg/analyzer/malloc-1.c with -fanalyzer-verbosity=0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:69b66ff02353a87585329bb3cf4ac20d6dee1b16

commit r11-7987-g69b66ff02353a87585329bb3cf4ac20d6dee1b16
Author: David Malcolm 
Date:   Mon Apr 5 10:48:01 2021 -0400

analyzer: fix apparent hang with -fanalyzer-verbosity=0 [PR analyzer/99886]

The analyzer appeared to enter an infinite loop on malloc-1.c
when -fanalyzer-verbosity=0 was used.  In fact, it was slowly
counting from 0 to 0x.

Root cause is looping up to effectively ((unsigned)0) - 1 in
diagnostic_manager::consolidate_conditions when there are no events
in the path.

Fixed by the following, which uses signed integers when subtracting
from path->num_events () when simplifying checker_paths.

gcc/analyzer/ChangeLog:
PR analyzer/99886
* diagnostic-manager.cc
(diagnostic_manager::prune_interproc_events): Use signed integers
when subtracting one from path->num_events ().
(diagnostic_manager::consolidate_conditions): Likewise.  Convert
next_idx to a signed int.

gcc/testsuite/ChangeLog:
PR analyzer/99886
* gcc.dg/analyzer/pr99886.c: New test.

[Bug c++/95870] [8/9/10/11 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c

[viktor.rosendahl at bmw dot de via Gcc-bugs]

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

--- Comment #7 from Viktor Rosendahl  ---
Thanks for your message. I am on vacation. I will be working again on 6th of
April 2021.

[Bug c++/95870] [8/9/10/11 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

Re: [PATCH 2/3] x86: Update memcpy/memset inline strategies for Skylake family CPUs

[H.J. Lu via Gcc-patches]

On Mon, Mar 22, 2021 at 6:16 AM H.J. Lu  wrote:
>
> Simply memcpy and memset inline strategies to avoid branches for
> Skylake family CPUs:
>
> 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
>load and store for up to 16 * 16 (256) bytes when the data size is
>fixed and known.
> 2. Inline only if data size is known to be <= 256.
>a. Use "rep movsb/stosb" with simple code sequence if the data size
>   is a constant.
>b. Use loop if data size is not a constant.
> 3. Use memcpy/memset libray function if data size is unknown or > 256.
>
> On Cascadelake processor with -march=native -Ofast -flto,
>
> 1. Performance impacts of SPEC CPU 2017 rate are:
>
> 500.perlbench_r  0.17%
> 502.gcc_r   -0.36%
> 505.mcf_r0.00%
> 520.omnetpp_r0.08%
> 523.xalancbmk_r -0.62%
> 525.x264_r   1.04%
> 531.deepsjeng_r  0.11%
> 541.leela_r -1.09%
> 548.exchange2_r -0.25%
> 557.xz_r 0.17%
> Geomean -0.08%
>
> 503.bwaves_r 0.00%
> 507.cactuBSSN_r  0.69%
> 508.namd_r  -0.07%
> 510.parest_r 1.12%
> 511.povray_r 1.82%
> 519.lbm_r0.00%
> 521.wrf_r   -1.32%
> 526.blender_r   -0.47%
> 527.cam4_r   0.23%
> 538.imagick_r   -1.72%
> 544.nab_r   -0.56%
> 549.fotonik3d_r  0.12%
> 554.roms_r   0.43%
> Geomean  0.02%
>
> 2. Significant impacts on eembc benchmarks are:
>
> eembc/idctrn01   9.23%
> eembc/nnet_test  29.26%
>
> gcc/
>
> * config/i386/x86-tune-costs.h (skylake_memcpy): Updated.
> (skylake_memset): Likewise.
> (skylake_cost): Change CLEAR_RATIO to 17.
> * config/i386/x86-tune.def (X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB):
> Replace m_CANNONLAKE, m_ICELAKE_CLIENT, m_ICELAKE_SERVER,
> m_TIGERLAKE and m_SAPPHIRERAPIDS with m_SKYLAKE and m_CORE_AVX512.
>
> gcc/testsuite/
>
> * gcc.target/i386/memcpy-strategy-9.c: New test.
> * gcc.target/i386/memcpy-strategy-10.c: Likewise.
> * gcc.target/i386/memcpy-strategy-11.c: Likewise.
> * gcc.target/i386/memset-strategy-7.c: Likewise.
> * gcc.target/i386/memset-strategy-8.c: Likewise.
> * gcc.target/i386/memset-strategy-9.c: Likewise.
> ---
>  gcc/config/i386/x86-tune-costs.h  | 27 ---
>  gcc/config/i386/x86-tune.def  |  3 +--
>  .../gcc.target/i386/memcpy-strategy-10.c  | 11 
>  .../gcc.target/i386/memcpy-strategy-11.c  | 18 +
>  .../gcc.target/i386/memcpy-strategy-9.c   |  9 +++
>  .../gcc.target/i386/memset-strategy-7.c   | 11 
>  .../gcc.target/i386/memset-strategy-8.c   |  9 +++
>  .../gcc.target/i386/memset-strategy-9.c   | 17 
>  8 files changed, 93 insertions(+), 12 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/memcpy-strategy-11.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/memcpy-strategy-9.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/memset-strategy-7.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/memset-strategy-8.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/memset-strategy-9.c
>
> diff --git a/gcc/config/i386/x86-tune-costs.h 
> b/gcc/config/i386/x86-tune-costs.h
> index 0e00ff99df3..ffe810f2bcb 100644
> --- a/gcc/config/i386/x86-tune-costs.h
> +++ b/gcc/config/i386/x86-tune-costs.h
> @@ -1822,17 +1822,24 @@ struct processor_costs znver3_cost = {
>
>  /* skylake_cost should produce code tuned for Skylake familly of CPUs.  */
>  static stringop_algs skylake_memcpy[2] =   {
> -  {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
> -  {libcall, {{16, loop, false}, {512, unrolled_loop, false},
> - {-1, libcall, false;
> +  {libcall,
> +   {{256, rep_prefix_1_byte, true},
> +{256, loop, false},
> +{-1, libcall, false}}},
> +  {libcall,
> +   {{256, rep_prefix_1_byte, true},
> +{256, loop, false},
> +{-1, libcall, false;
>
>  static stringop_algs skylake_memset[2] = {
> -  {libcall, {{6, loop_1_byte, true},
> - {24, loop, true},
> - {8192, rep_prefix_4_byte, true},
> - {-1, libcall, false}}},
> -  {libcall, {{24, loop, true}, {512, unrolled_loop, false},
> - {-1, libcall, false;
> +  {libcall,
> +   {{256, rep_prefix_1_byte, true},
> +{256, loop, false},
> +{-1, libcall, false}}},
> +  {libcall,
> +   {{256, rep_prefix_1_byte, true},
> +{256, loop, false},
> +{-1, libcall, false;
>
>  static const
>  struct processor_costs skylake_cost = {
> @@ -1889,7 +1896,7 @@ struct processor_costs skylake_cost = {
>COSTS_N_INSNS (0),   /* cost of movzx */
>8,   /* "large" insn */
>17,  /* MOVE_RATIO */
> -  6,   /* CLEAR_RATIO */
> +  17,  /* CLEAR_RATIO */
>{4, 4, 4},  

[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Patrick Palka  ---
Fixed.

[Bug c++/99201] [8/9/10 Regression] ICE in tsubst_copy, at cp/pt.c:16581 since r8-7613-g1456e764105702a0

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
   |in tsubst_copy, at  |tsubst_copy, at
   |cp/pt.c:16581 since |cp/pt.c:16581 since
   |r8-7613-g1456e764105702a0   |r8-7613-g1456e764105702a0

--- Comment #8 from Jason Merrill  ---
Fixed for 11 so far.

[Bug c++/99066] [8/9/10 Regression] non-weak definition emitted for explicit instantiation declaration

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |non-weak definition emitted |non-weak definition emitted
   |for explicit instantiation  |for explicit instantiation
   |declaration |declaration

--- Comment #5 from Jason Merrill  ---
Fixed for 11 so far.

[Bug c++/99066] [8/9/10/11 Regression] non-weak definition emitted for explicit instantiation declaration

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:bd89b8fe9efbdf0a95d827553d1a84fd3cefaa16

commit r11-7986-gbd89b8fe9efbdf0a95d827553d1a84fd3cefaa16
Author: Jason Merrill 
Date:   Sun Apr 4 23:32:32 2021 -0400

c++: extern template and static data member [PR99066]

'extern template' should mean that the relevant symbols are never emitted.
But in this case we were assuming that DECL_EXTERNAL was already set on the
variable, so we just needed to clear DECL_NOT_REALLY_EXTERN.  Since
DECL_EXTERNAL was not set, we emitted a definition of npos.

gcc/cp/ChangeLog:

PR c++/99066
* pt.c (mark_decl_instantiated): Set DECL_EXTERNAL.

gcc/testsuite/ChangeLog:

PR c++/99066
* g++.dg/cpp0x/extern_template-6.C: New test.

[pushed] c++: extern template and static data member [PR99066]

[Jason Merrill via Gcc-patches]

'extern template' should mean that the relevant symbols are never emitted.
But in this case we were assuming that DECL_EXTERNAL was already set on the
variable, so we just needed to clear DECL_NOT_REALLY_EXTERN.  Since
DECL_EXTERNAL was not set, we emitted a definition of npos.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/99066
* pt.c (mark_decl_instantiated): Set DECL_EXTERNAL.

gcc/testsuite/ChangeLog:

PR c++/99066
* g++.dg/cpp0x/extern_template-6.C: New test.
---
 gcc/cp/pt.c|  5 -
 gcc/testsuite/g++.dg/cpp0x/extern_template-6.C | 17 +
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/extern_template-6.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1d19a59dd62..396e622c4db 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24204,7 +24204,10 @@ mark_decl_instantiated (tree result, int extern_p)
   DECL_COMDAT (result) = 0;
 
   if (extern_p)
-DECL_NOT_REALLY_EXTERN (result) = 0;
+{
+  DECL_EXTERNAL (result) = 1;
+  DECL_NOT_REALLY_EXTERN (result) = 0;
+}
   else
 {
   mark_definable (result);
diff --git a/gcc/testsuite/g++.dg/cpp0x/extern_template-6.C 
b/gcc/testsuite/g++.dg/cpp0x/extern_template-6.C
new file mode 100644
index 000..8aff3ae6b02
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/extern_template-6.C
@@ -0,0 +1,17 @@
+// PR c++/99066
+// { dg-do compile { target c++11 } }
+
+template  struct basic_string {
+  static const int npos = 1;
+};
+template  const int basic_string::npos;
+
+struct e { template  int f() const; };
+
+template  int e::f() const {
+  return basic_string::npos;
+}
+
+extern template class basic_string;
+
+// { dg-final { scan-assembler-not "_ZN12basic_stringIcE4nposE" } }

base-commit: a99a7b0afe9a1f6f866e25b8572856ae8c1d3f8d
-- 
2.27.0

[Bug c++/99066] [8/9/10/11 Regression] non-weak definition emitted for explicit instantiation declaration

[jason at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps caused by PR23691 changes?

r104041, yes.  Bizarre that this went unnoticed for over 15 years.

[Bug c++/99201] [8/9/10/11 Regression] ICE in tsubst_copy, at cp/pt.c:16581 since r8-7613-g1456e764105702a0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:a99a7b0afe9a1f6f866e25b8572856ae8c1d3f8d

commit r11-7985-ga99a7b0afe9a1f6f866e25b8572856ae8c1d3f8d
Author: Jason Merrill 
Date:   Sun Apr 4 01:01:56 2021 -0400

c++: constexpr if and nested generic lambda [PR99201]

When building up *_EXTRA_ARGS for a constexpr if or pack expansion, we need
to walk into the body of a lambda to find all the local_specializations
that
we need to remember, like we do in find_parameter_packs_r.

gcc/cp/ChangeLog:

PR c++/99201
* pt.c (class el_data): Add visited field.
(extract_local_specs): Pass it to cp_walk_tree.
(extract_locals_r): Walk into the body of a lambda.

gcc/testsuite/ChangeLog:

PR c++/99201
* g++.dg/cpp1z/constexpr-if-lambda4.C: New test.

[pushed] c++: constexpr if and nested generic lambda [PR99201]

[Jason Merrill via Gcc-patches]

When building up *_EXTRA_ARGS for a constexpr if or pack expansion, we need
to walk into the body of a lambda to find all the local_specializations that
we need to remember, like we do in find_parameter_packs_r.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/99201
* pt.c (class el_data): Add visited field.
(extract_local_specs): Pass it to cp_walk_tree.
(extract_locals_r): Walk into the body of a lambda.

gcc/testsuite/ChangeLog:

PR c++/99201
* g++.dg/cpp1z/constexpr-if-lambda4.C: New test.
---
 gcc/cp/pt.c   | 15 -
 .../g++.dg/cpp1z/constexpr-if-lambda4.C   | 22 +++
 2 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda4.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2763aa15f1f..1d19a59dd62 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -12757,7 +12757,11 @@ tsubst_binary_right_fold (tree t, tree args, 
tsubst_flags_t complain,
 class el_data
 {
 public:
+  /* Set of variables declared within the pattern.  */
   hash_set internal;
+  /* Set of AST nodes that have been visited by the traversal.  */
+  hash_set visited;
+  /* List of local_specializations used within the pattern.  */
   tree extra;
   tsubst_flags_t complain;
 
@@ -12777,6 +12781,15 @@ extract_locals_r (tree *tp, int */*walk_subtrees*/, 
void *data_)
 
   if (TREE_CODE (*tp) == DECL_EXPR)
 data.internal.add (DECL_EXPR_DECL (*tp));
+  else if (TREE_CODE (*tp) == LAMBDA_EXPR)
+{
+  /* Since we defer implicit capture, look in the parms and body.  */
+  tree fn = lambda_function (*tp);
+  cp_walk_tree (_TYPE (fn), _locals_r, ,
+   );
+  cp_walk_tree (_SAVED_TREE (fn), _locals_r, ,
+   );
+}
   else if (tree spec = retrieve_local_specialization (*tp))
 {
   if (data.internal.contains (*tp))
@@ -12833,7 +12846,7 @@ static tree
 extract_local_specs (tree pattern, tsubst_flags_t complain)
 {
   el_data data (complain);
-  cp_walk_tree_without_duplicates (, extract_locals_r, );
+  cp_walk_tree (, extract_locals_r, , );
   return data.extra;
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda4.C 
b/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda4.C
new file mode 100644
index 000..99408025629
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda4.C
@@ -0,0 +1,22 @@
+// PR c++/99201
+// { dg-do compile { target c++17 } }
+
+template 
+  auto
+  make_tester(const RefF& reffun)
+  {
+return [=](auto in) {
+  auto&& expected = [&](const auto&... vs) {
+if constexpr (sizeof(in) > 0)
+  return [&](int i) { return reffun(vs[i]...); }(0);
+else
+  return [&](int i) { return reffun(vs[i]...); }(0);
+  };
+};
+  }
+
+int main()
+{
+  make_tester([](int x) { return x; })(0);
+  return 0;
+}

base-commit: a44a753a35542f86e82e198595ce3553f6d718f6
-- 
2.27.0

[Bug c++/99916] New: ICE Segmentation fault when erroneous structured bindings appears in requires-clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99916
   Summary: ICE Segmentation fault when erroneous structured
bindings appears in requires-clause
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/cW8367TTr

struct S {} s;
template  concept C = requires { [a] = s; };
static_assert(C);


:2:41: internal compiler error: Segmentation fault
2 | template  concept C = requires { [a] = s; };
  | ^~~
0x1cfcba9 internal_error(char const*, ...)
???:0
0x7779e3 pp_cxx_parameter_mapping(cxx_pretty_printer*, tree_node*)
???:0
0x7e2a68 maybe_print_single_constraint_context(diagnostic_context*, tree_node*)
???:0
0x1cfb736 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x1cfc13d inform(unsigned int, char const*, ...)
???:0
0x73f30f diagnose_constraints(unsigned int, tree_node*, tree_node*)
???:0
0x98aba3 finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
???:0
0x8e14fd c_parse_file()
???:0
0xa60102 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug d/99914] d: Template symbols not overridable by normal symbols

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Iain Buclaw  ---
Fix committed.

Re: [PATCH RFC] c++: Fix print-tree module handling for TEMPLATE_DECL

[Nathan Sidwell]

On 4/3/21 10:54 AM, Jason Merrill wrote:

The if allows TEMPLATE_DECL, but then checking DECL_MODULE_IMPORT_P crashes
on TEMPLATE_DECL.  Fixed by stripping TEMPLATE_DECL first.

Nathan, does this look right to you?

gcc/cp/ChangeLog:

* ptree.c (cxx_print_decl): Check DECL_MODULE_IMPORT_P on
template result.


Yes, this is probably more useful than just not looking at 
template_decl's instance of these flags.  Just shows how little I've had 
to use the printer recently :)



---
  gcc/cp/ptree.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/cp/ptree.c b/gcc/cp/ptree.c
index 95a4fdf284a..33b73fb24b6 100644
--- a/gcc/cp/ptree.c
+++ b/gcc/cp/ptree.c
@@ -59,16 +59,16 @@ cxx_print_decl (FILE *file, tree node, int indent)
  
bool need_indent = true;
  
-  if (TREE_CODE (node) == FUNCTION_DECL

-  || TREE_CODE (node) == VAR_DECL
-  || TREE_CODE (node) == TYPE_DECL
-  || TREE_CODE (node) == TEMPLATE_DECL
-  || TREE_CODE (node) == CONCEPT_DECL
-  || TREE_CODE (node) == NAMESPACE_DECL)
+  tree ntnode = STRIP_TEMPLATE (node);
+  if (TREE_CODE (ntnode) == FUNCTION_DECL
+  || TREE_CODE (ntnode) == VAR_DECL
+  || TREE_CODE (ntnode) == TYPE_DECL
+  || TREE_CODE (ntnode) == CONCEPT_DECL
+  || TREE_CODE (ntnode) == NAMESPACE_DECL)
  {
unsigned m = 0;
-  if (DECL_LANG_SPECIFIC (node) && DECL_MODULE_IMPORT_P (node))
-   m = get_importing_module (node, true);
+  if (DECL_LANG_SPECIFIC (ntnode) && DECL_MODULE_IMPORT_P (ntnode))
+   m = get_importing_module (ntnode, true);
  
if (const char *name = m == ~0u ? "" : module_name (m, true))

{
@@ -78,7 +78,7 @@ cxx_print_decl (FILE *file, tree node, int indent)
  need_indent = false;
}
  
-  if (DECL_LANG_SPECIFIC (node) && DECL_MODULE_PURVIEW_P (node))

+  if (DECL_LANG_SPECIFIC (ntnode) && DECL_MODULE_PURVIEW_P (ntnode))
{
  if (need_indent)
indent_to (file, indent + 3);

base-commit: a40015780f8cc49476741b6914bd5ee97bd10f1d




--
Nathan Sidwell

[committed] d: Use weak linkage for template symbols instead of gnu.linkonce (PR99914)

[Iain Buclaw via Gcc-patches]

Hi,

This patch changes the default linkage of templates in the D language to
be DECL_WEAK instead of DECL_ONE_ONLY, if supported.  This better
matches the expected override semantics of template symbols compiled to
object code.  For example:

 module rt.config;
 template rt_flag()
 {
   pragma(mangle, "rt_flag") __gshared bool rt_flag = true;
 }

 module main;
 extern(C) __gshared bool rt_flag = false;

The above currently does not succeed in linking due to there being
multiple definitions of `rt_flag' in different sections that aren't
considered mergeable.

The compiler flag enabling toggling of this has been given a clearer
name `-fweak-templates', distinguishing itself from G++ `-fweak', which
is intended for testing only.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

PR d/99914
* d-lang.cc (d_init): Disable flag_weak_templates if no support for
weak or one-only symbols.
* d-tree.h (VAR_OR_FUNCTION_DECL_CHECK): New macro.
(DECL_INSTANTIATED): New macro.
(d_comdat_linkage): Remove declaration.
(d_linkonce_linkage): Remove declaration.
(set_linkage_for_decl): New declaration.
* decl.cc (DeclVisitor::visit (StructDeclaration *)): Replace call to
d_linkonce_linkage with setting DECL_INSTANTIATED.
(DeclVisitor::visit (ClassDeclaration *)): Likewise.
(DeclVisitor::visit (EnumDeclaration *)): Likewise.
(DeclVisitor::visit (InterfaceDeclaration *)): Remove call to
d_linkonce_linkage.
(get_symbol_decl): Call set_linkage_for_decl instead of
d_linkonce_linkage.
(d_finish_decl): Call set_linkage_for_decl.
(d_comdat_linkage): Made function static.  Only set DECL_COMDAT for
DECL_INSTANTIATED decls.
(d_linkonce_linkage): Remove function.
(d_weak_linkage): New function.
(set_linkage_for_decl): New function.
* gdc.texi (Runtime Options): Rename -fno-weak to -fno-weak-templates,
update documentation of option.
* lang.opt (fweak): Rename option to ...
(fweak-templates): ... this.  Update help string.
* modules.cc (get_internal_fn): Add Prot parameter.  Set generated
function flag.
(build_internal_fn): Update call to get_internal_fn.
(build_dso_cdtor_fn): Likewise.
(register_moduleinfo): Call d_finish_decl on dso_slot_node and
dso_initialized_node.
* typeinfo.cc (TypeInfoVisitor::internal_reference): Call
set_linkage_for_decl instead of d_comdat_linkage.
(TypeInfoDeclVisitor::visit (TypeInfoDeclaration *)): Remove calls to
d_linkonce_linkage and d_comdat_linkage.
(get_cpp_typeinfo_decl): Likewise.

gcc/testsuite/ChangeLog:

PR d/99914
* gdc.dg/pr99914.d: New test.
---
 gcc/d/d-lang.cc|  2 +-
 gcc/d/d-tree.h | 15 --
 gcc/d/decl.cc  | 92 +-
 gcc/d/gdc.texi | 14 +++---
 gcc/d/lang.opt |  6 +--
 gcc/d/modules.cc   | 20 +++-
 gcc/d/typeinfo.cc  | 12 +
 gcc/testsuite/gdc.dg/pr99914.d |  5 ++
 8 files changed, 94 insertions(+), 72 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr99914.d

diff --git a/gcc/d/d-lang.cc b/gcc/d/d-lang.cc
index 5028698a5bc..a65af290cb8 100644
--- a/gcc/d/d-lang.cc
+++ b/gcc/d/d-lang.cc
@@ -386,7 +386,7 @@ d_init (void)
 using_eh_for_cleanups ();
 
   if (!supports_one_only ())
-flag_weak = 0;
+flag_weak_templates = 0;
 
   /* This is the C main, not the D main.  */
   main_identifier_node = get_identifier ("main");
diff --git a/gcc/d/d-tree.h b/gcc/d/d-tree.h
index 724a0bfd87b..c1b6f275149 100644
--- a/gcc/d/d-tree.h
+++ b/gcc/d/d-tree.h
@@ -59,7 +59,13 @@ typedef Array  Expressions;
Usage of DECL_LANG_FLAG_?:
0: LABEL_VARIABLE_CASE (in LABEL_DECL).
   DECL_BUILT_IN_CTFE (in FUNCTION_DECL).
-   1: DECL_IN_UNITTEST_CONDITION_P (in FUNCTION_DECL).  */
+   1: DECL_IN_UNITTEST_CONDITION_P (in FUNCTION_DECL).
+   2: DECL_INSTANTIATED (in FUNCTION_DECL, VAR_DECL).  */
+
+/* Language-specific tree checkers.  */
+
+#define VAR_OR_FUNCTION_DECL_CHECK(NODE) \
+  TREE_CHECK2 (NODE, VAR_DECL, FUNCTION_DECL)
 
 /* The kinds of scopes we recognize.  */
 
@@ -388,6 +394,10 @@ lang_tree_node
 #define DECL_IN_UNITTEST_CONDITION_P(NODE) \
   (DECL_LANG_FLAG_1 (FUNCTION_DECL_CHECK (NODE)))
 
+/* True if the decl comes from a template instance.  */
+#define DECL_INSTANTIATED(NODE) \
+  (DECL_LANG_FLAG_1 (VAR_OR_FUNCTION_DECL_CHECK (NODE)))
+
 enum d_tree_index
 {
   DTI_VTABLE_ENTRY_TYPE,
@@ -631,8 +641,7 @@ extern tree enum_initializer_decl (EnumDeclaration *);
 extern tree build_artificial_decl (tree, tree, const char * = NULL);
 extern tree create_field_decl (tree, const char *, int, int);
 extern void build_type_decl (tree, Dsymbol *);
-extern 

[Bug d/99914] d: Template symbols not overridable by normal symbols

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:76a7e7e706ac4c01cead3c6514322aaad88f9a63

commit r11-7983-g76a7e7e706ac4c01cead3c6514322aaad88f9a63
Author: Iain Buclaw 
Date:   Sun Mar 14 22:51:56 2021 +0100

d: Use weak linkage for template symbols instead of gnu.linkonce (PR99914)

The default linkage of templates in the D language is now DECL_WEAK
instead of  DECL_ONE_ONLY, if supported.  This better matches the
expected override semantics of template symbols compiled to object code.

For example:

 module rt.config;
 template rt_flag()
 {
   pragma(mangle, "rt_flag") __gshared bool rt_flag = true;
 }

 module main;
 extern(C) __gshared bool rt_flag = false;

The above currently does not succeed in linking due to there being
multiple definitions of `rt_flag' in different sections that aren't
considered mergeable.

The compiler flag enabling toggling of this has been given a clearer
named `-fweak-templates', which distinguishes itself from G++ `-fweak',
which is intended only for testing.

gcc/d/ChangeLog:

PR d/99914
* d-lang.cc (d_init): Disable flag_weak_templates if no support for
weak or one-only symbols.
* d-tree.h (VAR_OR_FUNCTION_DECL_CHECK): New macro.
(DECL_INSTANTIATED): New macro.
(d_comdat_linkage): Remove declaration.
(d_linkonce_linkage): Remove declaration.
(set_linkage_for_decl): New declaration.
* decl.cc (DeclVisitor::visit (StructDeclaration *)): Replace call
to
d_linkonce_linkage with setting DECL_INSTANTIATED.
(DeclVisitor::visit (ClassDeclaration *)): Likewise.
(DeclVisitor::visit (EnumDeclaration *)): Likewise.
(DeclVisitor::visit (InterfaceDeclaration *)): Remove call to
d_linkonce_linkage.
(get_symbol_decl): Call set_linkage_for_decl instead of
d_linkonce_linkage.
(d_finish_decl): Call set_linkage_for_decl.
(d_comdat_linkage): Made function static.  Only set DECL_COMDAT for
DECL_INSTANTIATED decls.
(d_linkonce_linkage): Remove function.
(d_weak_linkage): New function.
(set_linkage_for_decl): New function.
* gdc.texi (Runtime Options): Rename -fno-weak to
-fno-weak-templates,
update documentation of option.
* lang.opt (fweak): Rename option to ...
(fweak-templates): ... this.  Update help string.
* modules.cc (get_internal_fn): Add Prot parameter.  Set generated
function flag.
(build_internal_fn): Update call to get_internal_fn.
(build_dso_cdtor_fn): Likewise.
(register_moduleinfo): Call d_finish_decl on dso_slot_node and
dso_initialized_node.
* typeinfo.cc (TypeInfoVisitor::internal_reference): Call
set_linkage_for_decl instead of d_comdat_linkage.
(TypeInfoDeclVisitor::visit (TypeInfoDeclaration *)): Remove calls
to
d_linkonce_linkage and d_comdat_linkage.
(get_cpp_typeinfo_decl): Likewise.

gcc/testsuite/ChangeLog:

PR d/99914
* gdc.dg/pr99914.d: New test.

[Bug c++/99861] [modules] ICE in hashtab_chk_error

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #2 from Alexander Lelyakin  ---
There is a shorter sequence:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm

hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In file included from /usr/local/include/c++/11.0.1/vector:66,
 from /usr/local/include/c++/11.0.1/functional:62,
 from
/usr/local/include/c++/11.0.1/pstl/glue_algorithm_defs.h:13,
 from /usr/local/include/c++/11.0.1/algorithm:74:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h: In static member
function ‘static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator)’:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h:110:23: internal
compiler error: in hashtab_chk_error, at hash-table.c:137
  110 | { return std::copy(__first, __last, __result); }
  |   ^~~~
0x92db09 hashtab_chk_error()
../../gcc/gcc/hash-table.c:137
0xb3c135 hash_table::verify(spec_entry*
const&, unsigned int)
../../gcc/gcc/hash-table.h:1033
0xb3c6be hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:968
0xaf957b match_mergeable_specialization(bool, spec_entry*)
../../gcc/gcc/cp/pt.c:29908
0xa72a58 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
../../gcc/gcc/cp/module.cc:10670
0xa76654 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7903
0xa6f4b7 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9153
0xa75adb module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14811
0xa75fdd module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7609f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa70320 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa757db module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa75fdd module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7609f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa70320 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa757db module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa75fdd module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7609f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa70320 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa757db module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

g++ (GCC) 11.0.1 20210405 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/99915] New: [modules] ICE in write_location

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 99915
   Summary: [modules] ICE in write_location
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

This ICE is very similar to 99246, but it is closed as fixed.
So I assume that it is a new bug with similar symptoms.

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bit
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header istream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bitset
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header new
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ciso646
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header fstream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header thread
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex

In module imported at /usr/local/include/c++/11.0.1/sstream:38:1,
included from /usr/local/include/c++/11.0.1/regex:46:
/usr/local/include/c++/11.0.1/istream: note: unable to represent further
imported source locations
/usr/local/include/c++/11.0.1/regex: internal compiler error: in
write_location, at cp/module.cc:15607
0x6de279 module_state::write_location(bytes_out&, unsigned int)
../../gcc/gcc/cp/module.cc:15607
0xa67153 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5904
0xa6a5c4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7054
0xa6a5c4 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:8890
0xa66654 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9088
0xa6a9aa trees_out::write_var_def(tree_node*)
../../gcc/gcc/cp/module.cc:11475
0xa6bc45 module_state::write_cluster(elf_out*, depset**, unsigned int,
depset::hash&, unsigned int*, unsigned int*)
../../gcc/gcc/cp/module.cc:14662
0xa6d5ce module_state::write(elf_out*, cpp_reader*)
../../gcc/gcc/cp/module.cc:17734
0xa6e338 finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:19845
0xa014cb c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:5175
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

g++ (GCC) 11.0.1 20210405 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug d/99914] New: d: Template symbols not overridable by normal symbols

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 99914
   Summary: d: Template symbols not overridable by normal symbols
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Currently, the following does not link:

 extern(C) __gshared bool rt_cmdline_enabled = false;

Because the symbol conflicts with a template symbol of the same name in the D
runtime library.

 template rt_cmdline_enabled()
 {
 pragma(mangle, "rt_cmdline_enabled")
 __gshared bool rt_cmdline_enabled = true;
 }

Template symbols are made DECL_ONE_ONLY, which ends up in the gnu.linkonce
section as a unique global symbol.  However, the linker only considers other
symbols in gnu.linkonce as being candidates for discarding duplicates.

The expected and correct behaviour is for all instantiations to be declared
weak.

[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #3 from Brecht Sanders  
---
Just to clarify: libwinpthread is built as part of the GCC build against
MinGW-w64.
MinGW-w64 also already has a libwinpthread (including libwinpthread-1.dll which
can be found in the PATH).

[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Brecht Sanders  
---
By the time I get to that error the build process already generated these
files:
- mingw-w64/mingw/lib/libwinpthread.a
- mingw-w64/mingw/lib/libwinpthread.dll.a
- mingw-w64/mingw/lib/libwinpthread.la
However I couldn't find a matching DLL, which I assume should be here:
- mingw-w64/mingw/bin/libwinpthread-1.dll

[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
I Noticed:
--enable-threads=posix 
and the error message is:

D:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\bin\ld.exe:
R:/winlibs32_stage/gcc-11-20210404/build_mingw/gcc/libgcc_eh.a(unwind-dw2.o):
in function `_gthread_once':
R:\winlibs32_stage\gcc-11-20210404\build_mingw\i686-w64-mingw32\libgcc/./gthr-default.h:700:
undefined reference to `pthread_once'

More undefined references to pthread_*

Either pthreads-win32 is not installed correctly or is not being linked
correctly here.