[Bug c++/95434] ICE for CTAD in generic lambda within variadic lambda

[johelegp at gmail dot com]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

 CC||johelegp at gmail dot com

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
Perhaps it's related to the following snippet that errors. I don't see why it
shouldn't work. Should I open a separate bug report on this?
```C++
template  class... Ts>
void g()
{
(..., Ts{0}); // error: operand of fold expression has no unexpanded
parameter packs
}
```

[Bug c++/95434] New: ICE for CTAD in generic lambda within variadic lambda

[johelegp at gmail dot com]

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

Bug ID: 95434
   Summary: ICE for CTAD in generic lambda within variadic lambda
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
  Target Milestone: ---

The following snippet ICEs. See https://godbolt.org/z/-fZVX4.
```C++
template  struct type { T value; };
template  type(T) -> type;
void f()
{
[] class... Ts>()
{
(..., [] class T>() {
T{0};
}.template operator()());
}
.template operator()();
}

```

[Bug c++/94128] ICE on C++20 "requires requires" with lambda

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |10.2

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 10.2+.

[Bug c++/54367] [meta-bug] lambda expressions

[ppalka at gcc dot gnu.org]

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

Bug 92652 Summary: function call to lambda expression that return true does not 
satisfy the constraint in requires-clause if using return type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92652

   What|Removed |Added

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

[Bug c++/92652] function call to lambda expression that return true does not satisfy the constraint in requires-clause if using return type deduction

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 10.2+.

[Bug c++/95386] [10/11 Regression] ICE: in satisfaction_value, while compiling function with a requires clause since r10-3735-gcb57504a55015891

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 10.2+.

[Bug c++/67491] [meta-bug] concepts issues

[ppalka at gcc dot gnu.org]

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

Bug 92652 Summary: function call to lambda expression that return true does not 
satisfy the constraint in requires-clause if using return type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92652

   What|Removed |Added

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

[Bug c++/93698] ICE on concept using generic lambda

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |10.2

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 10.2+.

[Bug c++/95241] [10 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 10.2+.

[Bug c++/95241] [10 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:798a9da416bbfd8996da9a5d53955b082d5b94fe

commit r10-8213-g798a9da416bbfd8996da9a5d53955b082d5b94fe
Author: Patrick Palka 
Date:   Fri May 29 09:44:09 2020 -0400

c++: constexpr ctor with RANGE_EXPR index [PR95241]

In the testcase below, the CONSTRUCTOR for 'field' contains a RANGE_EXPR
index:

  {{aggr_init_expr<...>, [1...2]={.off=1}}}

but get_or_insert_ctor_field isn't prepared to handle looking up a
RANGE_EXPR index.

This patch adds limited support to get_or_insert_ctor_field for looking
up a RANGE_EXPR index.  The limited scope of this patch should make it
more suitable for backporting, and more extensive support would be
needed only to handle self-modifying CONSTRUCTORs that contain a
RANGE_EXPR index, but I haven't yet been able to come up with a testcase
that actually creates such a CONSTRUCTOR.

gcc/cp/ChangeLog:

PR c++/95241
* constexpr.c (get_or_insert_ctor_field): Add limited support
for RANGE_EXPR index lookups.

gcc/testsuite/ChangeLog:

PR c++/95241
* g++.dg/cpp0x/constexpr-array25.C: New test.

(cherry picked from commit e069285cdf457cc85070e522380c4e25b0d2ed25)

[Bug c++/95386] [10/11 Regression] ICE: in satisfaction_value, while compiling function with a requires clause since r10-3735-gcb57504a55015891

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:6632f2920f08f5b45ffd1ada7006d4591ef9b172

commit r10-8215-g6632f2920f08f5b45ffd1ada7006d4591ef9b172
Author: Patrick Palka 
Date:   Fri May 29 13:09:20 2020 -0400

c++: satisfaction value of type typedef to bool [PR95386]

In the testcase below, the satisfaction value of fn1's constraint
is INTEGER_CST '1' of type BOOLEAN_TYPE value_type, which is a typedef
to the standard boolean_type_node.  But satisfaction_value expects to
see exactly boolean_true_node or integer_one_node, which this value is
neither, causing us to trip over the assert therein.

This patch relaxes satisfaction_value to accept any INTEGER_CST which
satisfies integer_zerop or integer_onep.

gcc/cp/ChangeLog:

PR c++/95386
* constraint.cc (satisfaction_value): Relax to accept any
INTEGER_CST that satisfies integer_zerop or integer_onep.

gcc/testsuite/ChangeLog:

PR c++/95386
* g++.dg/concepts/pr95386.C: New test.

[Bug c++/92652] function call to lambda expression that return true does not satisfy the constraint in requires-clause if using return type deduction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:03c344ad180e094140be514a5e7cbaf95b5dcd2e

commit r10-8214-g03c344ad180e094140be514a5e7cbaf95b5dcd2e
Author: Patrick Palka 
Date:   Fri May 29 14:17:02 2020 -0400

c++: lambdas inside constraints [PR92652]

When parsing a constraint-expression, a requires-clause or a
requires-expression, we temporarily increment processing_template_decl
so that we always obtain template trees which we could later reduce via
substitution even when not inside a template.

But incrementing processing_template_decl when we're already inside a
template has the unintended side effect of shifting up the template
parameter levels of a lambda defined inside one of these constructs,
which leads to confusion later during substitution into the lambda.

This patch fixes this issue by incrementing processing_template_decl
during parsing of these constructs only if it is 0.

gcc/cp/ChangeLog:

PR c++/92652
PR c++/93698
PR c++/94128
* parser.c (cp_parser_requires_clause_expression): Temporarily
increment processing_template_decl only if it is 0.
(cp_parser_constraint_expression): Likewise.
(cp_parser_requires_expression): Likewise.

gcc/testsuite/ChangeLog:

PR c++/92652
PR c++/93698
PR c++/94128
* g++.dg/cpp2a/concepts-lambda8.C: New test.
* g++.dg/cpp2a/concepts-lambda9.C: New test.
* g++.dg/cpp2a/concepts-lambda10.C: New test.

(cherry picked from commit 020d86db8896f088435830595640e6fc21bc64ad)

[Bug c++/94128] ICE on C++20 "requires requires" with lambda

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:03c344ad180e094140be514a5e7cbaf95b5dcd2e

commit r10-8214-g03c344ad180e094140be514a5e7cbaf95b5dcd2e
Author: Patrick Palka 
Date:   Fri May 29 14:17:02 2020 -0400

c++: lambdas inside constraints [PR92652]

When parsing a constraint-expression, a requires-clause or a
requires-expression, we temporarily increment processing_template_decl
so that we always obtain template trees which we could later reduce via
substitution even when not inside a template.

But incrementing processing_template_decl when we're already inside a
template has the unintended side effect of shifting up the template
parameter levels of a lambda defined inside one of these constructs,
which leads to confusion later during substitution into the lambda.

This patch fixes this issue by incrementing processing_template_decl
during parsing of these constructs only if it is 0.

gcc/cp/ChangeLog:

PR c++/92652
PR c++/93698
PR c++/94128
* parser.c (cp_parser_requires_clause_expression): Temporarily
increment processing_template_decl only if it is 0.
(cp_parser_constraint_expression): Likewise.
(cp_parser_requires_expression): Likewise.

gcc/testsuite/ChangeLog:

PR c++/92652
PR c++/93698
PR c++/94128
* g++.dg/cpp2a/concepts-lambda8.C: New test.
* g++.dg/cpp2a/concepts-lambda9.C: New test.
* g++.dg/cpp2a/concepts-lambda10.C: New test.

(cherry picked from commit 020d86db8896f088435830595640e6fc21bc64ad)

[Bug c++/93698] ICE on concept using generic lambda

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:03c344ad180e094140be514a5e7cbaf95b5dcd2e

commit r10-8214-g03c344ad180e094140be514a5e7cbaf95b5dcd2e
Author: Patrick Palka 
Date:   Fri May 29 14:17:02 2020 -0400

c++: lambdas inside constraints [PR92652]

When parsing a constraint-expression, a requires-clause or a
requires-expression, we temporarily increment processing_template_decl
so that we always obtain template trees which we could later reduce via
substitution even when not inside a template.

But incrementing processing_template_decl when we're already inside a
template has the unintended side effect of shifting up the template
parameter levels of a lambda defined inside one of these constructs,
which leads to confusion later during substitution into the lambda.

This patch fixes this issue by incrementing processing_template_decl
during parsing of these constructs only if it is 0.

gcc/cp/ChangeLog:

PR c++/92652
PR c++/93698
PR c++/94128
* parser.c (cp_parser_requires_clause_expression): Temporarily
increment processing_template_decl only if it is 0.
(cp_parser_constraint_expression): Likewise.
(cp_parser_requires_expression): Likewise.

gcc/testsuite/ChangeLog:

PR c++/92652
PR c++/93698
PR c++/94128
* g++.dg/cpp2a/concepts-lambda8.C: New test.
* g++.dg/cpp2a/concepts-lambda9.C: New test.
* g++.dg/cpp2a/concepts-lambda10.C: New test.

(cherry picked from commit 020d86db8896f088435830595640e6fc21bc64ad)

[Bug tree-optimization/95433] New: Failure to completely optimize simple compare after operations

[gabravier at gmail dot com]

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

Bug ID: 95433
   Summary: Failure to completely optimize simple compare after
operations
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

auto f(int x)
{
return (2 * x) + 5 == 3;
}

This can be optimized to `x == -1`. This transformation is done by LLVM, but
not by GCC.

[Bug debug/95431] inconsistent behaviors at -O2

[yangyibiao at hust dot edu.cn]

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

Yibiao Yang  changed:

   What|Removed |Added

 CC||yangyibiao at hust dot edu.cn

--- Comment #1 from Yibiao Yang  ---
Created attachment 48640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48640=edit
a.out

[Bug debug/95432] inconsistent behaviors at -O2

[yangyibiao at hust dot edu.cn]

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

Yibiao Yang  changed:

   What|Removed |Added

 CC||yangyibiao at hust dot edu.cn

--- Comment #1 from Yibiao Yang  ---
Created attachment 48639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48639=edit
a.out

[Bug debug/95432] New: inconsistent behaviors at -O2

[yangyibiao at hust dot edu.cn]

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

Bug ID: 95432
   Summary: inconsistent behaviors at -O2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
  Target Milestone: ---

Consider test case:
...
$ cat small.c
__attribute__ ((noinline, noclone)) 
int foo (char *c)
{
  asm volatile ("" : : "r" (c) : "memory");
  return 1;
}

int main ()
{
  char tpl1[20] = "/tmp/test.XXX";
  char tpl2[20] = "/tmp/test.XXX";
  int fd1 = foo (tpl1);
  int fd2 = foo (tpl2);
  if (fd1 == -1) {
return 1;
  }

  return 0;
}
...



When stepping with step, line 13 is not hit by gdb.
...
$ gcc -O2 -g small.c; gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401020: file small.c, line 10.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:10
10char tpl1[20] = "/tmp/test.XXX";
(gdb) step
11char tpl2[20] = "/tmp/test.XXX";
(gdb) 
12int fd1 = foo (tpl1);
(gdb) 
foo (c=c@entry=0x7fffdea0 "/tmp/test.XXX") at small.c:5
5 return 1;
(gdb) 
foo (c=c@entry=0x7fffdec0 "/tmp/test.XXX") at small.c:5
5 return 1;
(gdb) 
main () at small.c:14
14if (fd1 == -1) {
(gdb) 
0x77df4023 in __libc_start_main () from /usr/lib/libc.so.6
(gdb) 
Single stepping until exit from function __libc_start_main,
which has no line number information.
[Inferior 1 (process 1852557) exited normally]
...



When stepping with stepi, line 13 is hit by gdb as follow.
...
$ gcc -O2 -g small.c; gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401020: file small.c, line 10.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:10
10char tpl1[20] = "/tmp/test.XXX";
(gdb) stepi
0x00401024  10char tpl1[20] = "/tmp/test.XXX";
(gdb) 
0x0040102c  12int fd1 = foo (tpl1);
(gdb) 
0x0040102f  10char tpl1[20] = "/tmp/test.XXX";
(gdb) 
11char tpl2[20] = "/tmp/test.XXX";
(gdb) 
12int fd1 = foo (tpl1);
(gdb) 
0x00401043  11char tpl2[20] = "/tmp/test.XXX";
(gdb) 
0x00401048  12int fd1 = foo (tpl1);
(gdb) 
foo (c=c@entry=0x7fffdea0 "/tmp/test.XXX") at small.c:5
5 return 1;
(gdb) 
0x00401165  5 return 1;
(gdb) 
0x0040104d in main () at small.c:13
13int fd2 = foo (tpl2);
(gdb) 
...


$ gcc --version
gcc (GCC) 10.0.1 20200419 (experimental)
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.

$ gdb --version
GNU gdb (GDB) 10.0.50.20200517-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Bug debug/95431] New: inconsistent behaviors at -O2

[yangyibiao at hust dot edu.cn]

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

Bug ID: 95431
   Summary: inconsistent behaviors at -O2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
  Target Milestone: ---

Consider test case:
...
$ cat small.c
#include 

volatile int one = 1;

int main() {
  char a1[] = {(char)one, 2, 3, 4};
  char a2[] = {1, (char)(2*one), 3, 4};
  int res = memcmp (a1, a2, 5 + one);
  return res;
}
...

When stepping using step Line 7 is not hit by gdb.
...
$ gcc -O2 -g small.c; gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401040: file small.c, line 6.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:6
6 char a1[] = {(char)one, 2, 3, 4};
(gdb) step
8 int res = memcmp (a1, a2, 5 + one);
(gdb) 
...

When stepping using stepi, Line 7 is hit after Line 6 by gdb.
...
$ gcc -O2 -g small.c; gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401040: file small.c, line 6.
(gdb) si
The program is not being run.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:6
6 char a1[] = {(char)one, 2, 3, 4};
(gdb) si
0x00401044  6 char a1[] = {(char)one, 2, 3, 4};
(gdb) si
0x0040104a  7 char a2[] = {1, (char)(2*one), 3, 4};
(gdb) 



$ gcc --version
gcc (GCC) 10.0.1 20200419 (experimental)
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.

$ gdb --version
GNU gdb (GDB) 10.0.50.20200517-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Bug sanitizer/95430] New: [UBSAN] doesn't detect out of bounds in a simple case

[haoxintu at gmail dot com]

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

Bug ID: 95430
   Summary: [UBSAN] doesn't detect out of bounds in a simple case
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

This case test.cc

#include

int main () {
int a[10];
int *p1 = a - 100; // UB
int *p2 = a + 100; // UB
std::cout << "ok" << std::endl;
return 0;
}

$g++ -fsanitize=undefined test.cc ; ./a.out
ok

While in Clang

$clang++ -fsanitize=undefined test.cc ; ./a.out
test.cc:5:17: runtime error: index -100 out of bounds for type 'int [10]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.cc:5:17 in 
test.cc:6:17: runtime error: index 100 out of bounds for type 'int [10]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.cc:6:17 in 
ok

My GCC version is

$g++ --version
g++ (GCC) 11.0.0 20200526 (experimental)
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.

GCC doesn't trigger warning or runtime error in out of bounds in an array.

[Bug c++/95371] [10/11 Regression] ICE concepts with template template parameter since r10-3735-gcb57504a55015891

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-8211-gc07c745b1ef62f633024824b7e125027f10c969b
Author: Jason Merrill 
Date:   Fri May 29 16:55:52 2020 -0400

c++: Template template parameter in constraint [PR95371]

gcc/cp/ChangeLog:

PR c++/95371
* pt.c (process_template_parm): Set DECL_TEMPLATE_INFO
on the DECL_TEMPLATE_RESULT.

gcc/testsuite/ChangeLog:

PR c++/95371
* g++.dg/cpp2a/concepts-ttp1.C: New test.

(cherry picked from commit d91b3aea7a5bdfbdaec746af2d62894812e6fd86)

[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-8212-g9e81c820a3e48ead478dabbd6988482747f7a521
Author: Patrick Palka 
Date:   Fri May 22 10:28:19 2020 -0400

c++: P0848R3 and member function templates [PR95181]

When comparing two special member function templates to see if one hides
the other (as per P0848R3), we need to check satisfaction which we can't
do on templates.  So this patch makes add_method skip the eligibility
test on member function templates and just lets them coexist.

gcc/cp/ChangeLog:

PR c++/95181
* class.c (add_method): Let special member function templates
coexist if they are not equivalently constrained, or in a class
template.

gcc/testsuite/ChangeLog:

PR c++/95181
* g++.dg/concepts/pr95181.C: New test.
* g++.dg/concepts/pr95181-2.C: New test.

Co-authored-by: Jason Merrill 
(cherry picked from commit 6b449b74c590f5a6f66c73aed894e5b5b36aa59d)

[Bug c++/95386] [10/11 Regression] ICE: in satisfaction_value, while compiling function with a requires clause since r10-3735-gcb57504a55015891

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-738-gaef6e234a8a78db39b4ba034cc4c100c07c294a7
Author: Patrick Palka 
Date:   Fri May 29 21:12:21 2020 -0400

c++: satisfaction value of type typedef to bool [PR95386]

In the testcase below, the satisfaction value of fn1's constraint
is INTEGER_CST '1' of type BOOLEAN_TYPE value_type, which is a typedef
to the standard boolean_type_node.  But satisfaction_value expects to
see exactly boolean_true_node or integer_one_node, which this value is
neither, causing us to trip over the assert therein.

This patch changes satisfaction_value to accept INTEGER_CST of any
boolean type.

gcc/cp/ChangeLog:

PR c++/95386
* constraint.cc (satisfaction_value): Accept INTEGER_CST of any
boolean type.

gcc/testsuite/ChangeLog:

PR c++/95386
* g++.dg/concepts/pr95386.C: New test.

[Bug c/95429] New: Wrong code generated for -Os with target m68k on Ubuntu

[i...@abp-labs.com]

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

Bug ID: 95429
   Summary: Wrong code generated for -Os with target m68k on
Ubuntu
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i...@abp-labs.com
  Target Milestone: ---

Created attachment 48638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48638=edit
C source file compiled with -E option.

Hello,

I am using m68k-linux-gnu-gcc to compile code for my homebrew computer.

With the version gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04), the assembly
for the following code is correct:

RTC_Msg1.nbBytes = 9;
RTC_buffer[0] = 8;
RTC_buffer[1] = RTC_buffer[5] = (uint8_t)(year_bcd >> 24);
RTC_buffer[2] = RTC_buffer[6] = (uint8_t)(year_bcd >> 16);
RTC_buffer[3] = RTC_buffer[7] = (uint8_t)(year_bcd >> 8);
RTC_buffer[4] = RTC_buffer[8] = (uint8_t)(year_bcd);

gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
157c 0009 0001  moveb #9,%a2@(1)
1f7c 0008 0012  moveb #8,%sp@(18)
2002movel %d2,%d0
4240clrw %d0
4840swap %d0
e048lsrw #8,%d0
1f40 0017   moveb %d0,%sp@(23)
1f40 0013   moveb %d0,%sp@(19)
2002movel %d2,%d0
4240clrw %d0
4840swap %d0
1f40 0018   moveb %d0,%sp@(24)
1f40 0014   moveb %d0,%sp@(20)
2002movel %d2,%d0
e088lsrl #8,%d0
1f40 0019   moveb %d0,%sp@(25)
1f40 0015   moveb %d0,%sp@(21)
1f42 001a   moveb %d2,%sp@(26)
1f42 0016   moveb %d2,%sp@(22)

With the version 9.3.0 provided in Ubuntu 20.04 packages, the following code is
generated and there is an illegal address trap during execution (write a long
at an odd address in the stack):

gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu1)
157c 0009 0001  moveb #9,%a2@(1)
1f7c 0008 001c  moveb #8,%sp@(28)
2f42 001d   movel %d2,%sp@(29) /* long on odd address! */
2f42 0021   movel %d2,%sp@(33) /* long on odd address! */

Options are:
-MMD -Os -m68000 -Wall -mpcrel -fdata-sections -ffunction-sections
-fomit-frame-pointer -fno-builtin -fno-ident -Iarch/m68k/include

If I use -O0 instead of -Os, the assembly is OK:

13fc 0009 0006  moveb #9,639fb
39fb 
1ebc 0008   moveb #8,%sp@
202f 000a   movel %sp@(10),%d0
4240clrw %d0
4840swap %d0
e048lsrw #8,%d0
2000movel %d0,%d0
1f40 0005   moveb %d0,%sp@(5)
102f 0005   moveb %sp@(5),%d0
1f40 0001   moveb %d0,%sp@(1)
202f 000a   movel %sp@(10),%d0
4240clrw %d0
4840swap %d0
2000movel %d0,%d0
1f40 0006   moveb %d0,%sp@(6)
102f 0006   moveb %sp@(6),%d0
1f40 0002   moveb %d0,%sp@(2)
202f 000a   movel %sp@(10),%d0
e088lsrl #8,%d0
2000movel %d0,%d0
1f40 0007   moveb %d0,%sp@(7)
102f 0007   moveb %sp@(7),%d0
1f40 0003   moveb %d0,%sp@(3)
202f 000a   movel %sp@(10),%d0
1f40 0008   moveb %d0,%sp@(8)
102f 0008   moveb %sp@(8),%d0
1f40 0004   moveb %d0,%sp@(4)

Attached the C source file compiled with -E option.

Thanks in advance for the support!

[Bug c++/95428] New: ABI breakage for "base object constructor" for final classes

[P at draigBrady dot com]

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

Bug ID: 95428
   Summary: ABI breakage for "base object constructor" for final
classes
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: P at draigBrady dot com
  Target Milestone: ---

The change to elide the "base object constructor" for final classes in bug
#70462 introduces an ABI incompatibility with clang 9 at least.

I'm seeing this with kuduraft-1.8 compiled with GCC 10, giving linker errors
from clang 9.0.20190721 like:

  error: undefined symbol: kudu::consensus::OpId::OpId()

Reverting the change in #70462 fixes the issue

[Bug target/95427] New: Failure to avoid emitting rbp initialization when doing 256-bit memory store

[gabravier at gmail dot com]

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

Bug ID: 95427
   Summary: Failure to avoid emitting rbp initialization when
doing 256-bit memory store
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

void f(int64_t *p)
{
p[0] = 0;
p[1] = 0;
p[2] = 0;
p[3] = 0;
}

With -O3 -max, LLVM produces this : 

f(long*): # @f(long*)
  vxorps xmm0, xmm0, xmm0
  vmovups ymmword ptr [rdi], ymm0
  vzeroupper
  ret

GCC produces this :

f(long*):
  push rbp
  vpxor xmm0, xmm0, xmm0
  vmovdqu XMMWORD PTR [rdi], xmm0
  vextractf128 XMMWORD PTR [rdi+16], ymm0, 0x1
  mov rbp, rsp
  vzeroupper
  pop rbp
  ret

[Bug jit/95426] New: libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN

[bouanto at zoho dot com]

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

Bug ID: 95426
   Summary: libgccjit.so: error: RTL check: expected elt 2 type
'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
I found this bug that happens when generating some code with libgccjit:

during RTL pass: expand
libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier)
in BLOCK_FOR_INSN, at rtl.h:1485
0x7f2a2317d365 rtl_check_failed_type1(rtx_def const*, int, int, char const*,
int, char const*)
../../gcc/gcc/rtl.c:860
0x7f2a23091bf7 BLOCK_FOR_INSN(rtx_def*)
../../gcc/gcc/rtl.h:1485
0x7f2a23091f82 BLOCK_FOR_INSN(rtx_def*)
../../gcc/gcc/rtl.h:1469
0x7f2a23091f82 rtl_verify_bb_pointers
../../gcc/gcc/cfgrtl.c:2778
0x7f2a2359e6e6 rtl_verify_flow_info_1
../../gcc/gcc/cfgrtl.c:2832
0x7f2a2359e6e6 rtl_verify_flow_info
../../gcc/gcc/cfgrtl.c:3076
0x7f2a23582a06 verify_flow_info()
../../gcc/gcc/cfghooks.c:267
0x7f2a244a966d checking_verify_flow_info
../../gcc/gcc/cfghooks.h:212
0x7f2a244a966d try_optimize_cfg
../../gcc/gcc/cfgcleanup.c:3009
0x7f2a244a966d cleanup_cfg(int)
../../gcc/gcc/cfgcleanup.c:3174
0x7f2a2357f90a execute
../../gcc/gcc/cfgexpand.c:6732

I'm not sure what causes this issue and, again, dumping a reproducer dumps a
file with an empty create_code function.
Is there any compile-time option I need to enable to be able to create a
reproducer?

Thanks to fix this issue.

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #20 from Richard Smith  
---
(In reply to Andrew Downing from comment #19)
> Not that it would make a difference in this particular situation, but is the
> intent of P0593R6 to only allow implicitly creating an object in the
> relevant storage location where one hasn't already been implicitly or
> explicitly created?

No, the new objects are allowed to replace existing objects. For example, this
implementation would also be correct:

std::uint64_t* s3(double* p) {
std::memmove(p, p, sizeof(double));
return std::launder(reinterpret_cast(p));
}

... on the basis that it has defined behavior if the memmove implicitly creates
an 'uint64_t' object in the underlying storage after it (notionally) copies the
contents elsewhere and before it (notionally) copies the contents back again.
(The 'launder' is necessary in order to form a pointer to the
implicitly-created uint64_t object, because p doesn't point to that object.)

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[andrew2085 at gmail dot com]

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

--- Comment #19 from Andrew Downing  ---
Not that it would make a difference in this particular situation, but is the
intent of P0593R6 to only allow implicitly creating an object in the relevant
storage location where one hasn't already been implicitly or explicitly
created? e.g. could the first memcpy implicitly create a double object in
storage? Doing so would result in the same behavior in this situation, I'm not
sure if that would be considered more defined. I'm also not sure if there could
be other situations where implicitly creating a new object where another object
exists would result in more defined, but unintended behavior.

[Bug tree-optimization/95425] New: Failure to optimize bit twiddling on statics that does nothing

[gabravier at gmail dot com]

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

Bug ID: 95425
   Summary: Failure to optimize bit twiddling on statics that does
nothing
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

uint32_t f()
{
static uint32_t x = 0;
x = (x >> 16) | (x << 16);
return x;
}

This can be optimized to `return 0;`. This transformation is done by LLVM, but
not by GCC.

[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||m...@3am-software.com

--- Comment #1 from Eric Gallager  ---
cc-ing vax maintainer listed in MAINTAINERS

[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-735-gc75ebe76ae12ac4020f20a24f34606a594a40d15
Author: Patrick Palka 
Date:   Fri May 22 10:28:19 2020 -0400

c++: P0848R3 and member function templates [PR95181]

When comparing two special member function templates to see if one hides
the other (as per P0848R3), we need to check satisfaction which we can't
do on templates.  So this patch makes add_method skip the eligibility
test on member function templates and just lets them coexist.

gcc/cp/ChangeLog:

PR c++/95181
* class.c (add_method): Let special member function templates
coexist if they are not equivalently constrained, or in a class
template.

gcc/testsuite/ChangeLog:

PR c++/95181
* g++.dg/concepts/pr95181.C: New test.
* g++.dg/concepts/pr95181-2.C: New test.

Co-authored-by: Jason Merrill 

[Bug c++/95371] [10/11 Regression] ICE concepts with template template parameter since r10-3735-gcb57504a55015891

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2fb595f8348e164d2f06536ba98322616eeaeeb6

commit r11-734-g2fb595f8348e164d2f06536ba98322616eeaeeb6
Author: Jason Merrill 
Date:   Fri May 29 16:55:52 2020 -0400

c++: Template template parameter in constraint [PR95371]

any_template_parm_r was assuming that the DECL_TEMPLATE_RESULT of a
template
will have a suitable TEMPLATE_INFO from which we can look at the generic
arguments for that template.  But that wasn't true for a template template
parameter; this patch makes it so.

gcc/cp/ChangeLog:

PR c++/95371
* pt.c (process_template_parm): Set DECL_TEMPLATE_INFO
on the DECL_TEMPLATE_RESULT.

gcc/testsuite/ChangeLog:

PR c++/95371
* g++.dg/cpp2a/concepts-ttp1.C: New test.

[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #18 from Richard Smith  
---
(In reply to Andrew Downing from comment #17)
> Also none of the behavior described in p0593 is required for this C++
> program to be well defined. All objects that are required to exists here are
> created explicitly. It's not relying on the implicit creation of any
> objects. This is valid C++17 code.

I agree, for what it's worth. I think the only thing that might suggest
otherwise is the wording in the C standard that says that memcpy copies the
effective type, but that doesn't mean anything in C++ (and it's also specified
in the language section of C, not the library section, so isn't part of the
wording that C++ incorporates by reference).

C++ doesn't have any wording that says what value an object has after you
memcpy the representation of a value of a different type over it, but there
isn't any provision for memcpy to change the dynamic type of the object prior
to P0593 (and after P0593, memcpy is only allowed to change the dynamic type if
doing so makes the program's behavior more defined).

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #21 from Eric Gallager  ---
(In reply to Segher Boessenkool from comment #20)
> We are in stage 1 now (for GCC 11), so nothing should be deferred now.

I thought the "deferred" keyword was a backward-looking one, meant to mark bugs
that had been deferred from previous releases and thus deserve a higher
priority now, not ones that are currently being deferred to something in the
future (that's what the SUSPENDED status is for). cc-ing David Malcolm who
originally came up with the keyword

[Bug tree-optimization/95423] Failure to optimize separated multiplications by x and square of x

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
We manage it with -fwrapv. This should happen late when we don't care about
overflow anymore, or it needs to introduce casts to an unsigned type.

[Bug tree-optimization/95423] Failure to optimize separated multiplications by x and square of x

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Could there be overflows which don't happen originally?

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[andrew2085 at gmail dot com]

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

--- Comment #17 from Andrew Downing  ---
Also none of the behavior described in p0593 is required for this C++ program
to be well defined. All objects that are required to exists here are created
explicitly. It's not relying on the implicit creation of any objects. This is
valid C++17 code.

[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #7)
> This causes regressions on arm and aarch64:

Followup fix to cure this:

https://gcc.gnu.org/pipermail/fortran/2020-May/054420.html

Sorry for that.

[Bug libstdc++/94749] std::istream::ignore discards too many characters

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I have a patch but was waiting until after the GCC 11 release.

I'll look into it next week.

[Bug tree-optimization/95424] New: Failure to optimize division with numerator of 1

[gabravier at gmail dot com]

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

Bug ID: 95424
   Summary: Failure to optimize division with numerator of 1
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

unsigned f(unsigned x)
{
return 1 / x;
}

This can be optimized to `return (x == 1);`, and for `int` to `return
(unsigned)(x + 1) < 3 ? x : 0;`. This transformation is done by LLVM, but not
by GCC.

[Bug libstdc++/94749] std::istream::ignore discards too many characters

[serpent7776 at gmail dot com]

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

--- Comment #2 from serpent7776 at gmail dot com ---
any update?

[Bug c++/95371] [10/11 Regression] ICE concepts with template template parameter since r10-3735-gcb57504a55015891

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/95423] Failure to optimize separated multiplications by x and square of x

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
I've hit a similar thing with this function :

int f(int x)
{
return (x * x * x) - (3 * x) - 1;
}

Which can be optimized to `return (((x * x) - 3) * x) - 1;`, but isn't

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #10 from H.J. Lu  ---
Fixed.

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:9051b548274bffef9f41e720e1894d12cf68a47c

commit r11-732-g9051b548274bffef9f41e720e1894d12cf68a47c
Author: H.J. Lu 
Date:   Fri May 29 12:23:33 2020 -0700

Avoid nested save_CFLAGS and save_LDFLAGS

Avoid nested save_CFLAGS and save_LDFLAGS by replacing save_CFLAGS and
save_LDFLAGS with cet_save_CFLAGS and cet_save_LDFLAGS in cet.m4.

config/

PR bootstrap/95413
* cet.m4: Replace save_CFLAGS and save_LDFLAGS with
cet_save_CFLAGS and cet_save_LDFLAGS.

gcc/

PR bootstrap/95413
* configure: Regenerated.

libatomic/

PR bootstrap/95413
* configure: Regenerated.

libbacktrace/

PR bootstrap/95413
* configure: Regenerated.

libcc1/

PR bootstrap/95413
* configure: Regenerated.

libcpp/

PR bootstrap/95413
* configure: Regenerated.

libdecnumber/

PR bootstrap/95413
* configure: Regenerated.

libgcc/

PR bootstrap/95413
* configure: Regenerated.

libgfortran/

PR bootstrap/95413
* configure: Regenerated.

libgomp/

PR bootstrap/95413
* configure: Regenerated.

libiberty/

PR bootstrap/95413
* configure: Regenerated.

libitm/

PR bootstrap/95413
* configure: Regenerated.

libobjc/

PR bootstrap/95413
* configure: Regenerated.

libphobos/

PR bootstrap/95413
* configure: Regenerated.

libquadmath/

PR bootstrap/95413
* configure: Regenerated.

libsanitizer/

PR bootstrap/95413
* configure: Regenerated.

libssp/

PR bootstrap/95413
* configure: Regenerated.

libstdc++-v3/

PR bootstrap/95413
* configure: Regenerated.

libvtv/

PR bootstrap/95413
* configure: Regenerated.

lto-plugin/

PR bootstrap/95413
* configure: Regenerated.

zlib/

PR bootstrap/95413
* configure: Regenerated.

[Bug tree-optimization/95423] New: Failure to optimize separated multiplications by x and square of x

[gabravier at gmail dot com]

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

Bug ID: 95423
   Summary: Failure to optimize separated multiplications by x and
square of x
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int a, int b, int x)
{
return a * (x * x) + (b * x);
}

This can be optimized to `return (((a * x) + b) * x);`. LLVM does this
transformation, but GCC does not.

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-May/546
   ||849.html
   Keywords||patch

--- Comment #8 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546849.html

[Bug middle-end/95052] [9/10/11 Regression] Excess padding of partially initialized strings/char arrays

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Reduced testcase with -O2 -fconserve-stack:

void bar (char *);

void
foo (void)
{
  char buf[70] = "";
  bar (buf);
}

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[segher at gcc dot gnu.org]

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

--- Comment #20 from Segher Boessenkool  ---
We are in stage 1 now (for GCC 11), so nothing should be deferred now.

[Bug fortran/95090] ICE: identifier overflow: 129

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-731-g7deca8c0b3765787627b11387b56b97b01a8bf33
Author: Harald Anlauf 
Date:   Fri May 29 21:19:31 2020 +0200

PR fortran/95090 - ICE: identifier overflow

The initial fix for this PR uncovered several latent issues with further
too small string buffers which showed up only when testing on i686.
Provide sufficiently large temporaries.

2020-05-29  Harald Anlauf  

gcc/fortran/
PR fortran/95090
* class.c (get_unique_type_string): Enlarge temporary for
name-mangling.  Use strncpy to prevent buffer overrun.
(get_unique_hashed_string): Enlarge temporary.
(gfc_hash_value): Enlarge temporary for name-mangling.

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from H.J. Lu  ---
> I am testing this:
[...]

Seems to work fine: at least configuring and building the 32 and 64-bit
libgomp multilibs now succeeds.

Thanks.
Rainer

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Manfred Schwarb from comment #10)
> Is there a way to get useful backtraces? "--enable-checking=yes,extra"
> seems not to be enough...

Maybe some "fortify" option or a "sanitized" version of the compiler?

I tried valgrind, but failed.

Then I decided to do it the hard way running the example under gdb,
and found a third function which needs adjustment.

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 9aa3eb7282c..db395624a16 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -479,11 +479,12 @@ gfc_class_initializer (gfc_typespec *ts, gfc_expr
*init_expr)
 static void
 get_unique_type_string (char *string, gfc_symbol *derived)
 {
-  char dt_name[GFC_MAX_SYMBOL_LEN+1];
+  /* Provide sufficient space to hold "Pdtsymbol".  */
+  char dt_name[GFC_MAX_SYMBOL_LEN+4];
   if (derived->attr.unlimited_polymorphic)
 strcpy (dt_name, "STAR");
   else
-strcpy (dt_name, gfc_dt_upper_string (derived->name));
+strncpy (dt_name, gfc_dt_upper_string (derived->name), sizeof (dt_name));
   if (derived->attr.unlimited_polymorphic)
 sprintf (string, "_%s", dt_name);
   else if (derived->module)
@@ -501,7 +502,8 @@ get_unique_type_string (char *string, gfc_symbol *derived)
 static void
 get_unique_hashed_string (char *string, gfc_symbol *derived)
 {
-  char tmp[2*GFC_MAX_SYMBOL_LEN+2];
+  /* Provide sufficient space to hold "symbol_Pdtsymbol".  */
+  char tmp[2*GFC_MAX_SYMBOL_LEN+5];
   get_unique_type_string ([0], derived);
   /* If string is too long, use hash value in hex representation (allow for
  extra decoration, cf. gfc_build_class_symbol & gfc_find_derived_vtab).
@@ -523,7 +525,8 @@ unsigned int
 gfc_hash_value (gfc_symbol *sym)
 {
   unsigned int hash = 0;
-  char c[2*(GFC_MAX_SYMBOL_LEN+1)];
+  /* Provide sufficient space to hold "symbol_Pdtsymbol".  */
+  char c[2*GFC_MAX_SYMBOL_LEN+5];
   int i, len;

   get_unique_type_string ([0], sym);


I have added one protection using strncpy to avoid a buffer overflow.
One could "protect" the temporary buffers by setting the last byte to \0
and add an assert later to detect an overrun.

I'll regtest the above and commit as "obvious" later.

Thanks, Manfred, for providing pointers.

[Bug target/95399] [ARM] 32/64-bit vcvtnq_* functions are missing

[e...@coeus-group.com]

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

Evan Nemerson  changed:

   What|Removed |Added

  Attachment #48635|0   |1
is obsolete||

--- Comment #4 from Evan Nemerson  ---
Created attachment 48637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48637=edit
List of functions missing from 32-bit arm_{neon,fp16,bf16}.h

Sure, I just filed #95421 for AArch64.

Thanks for the note about arm_fp16.h and arm_bf16.h; I hadn't realized those
functions were in separate headers.  That bring the total down to 264
functions, of which 236 are present in the AArch64 version.  Here is the
updated list.

[Bug target/95421] [AArch64] Missing NEON functions documented on ARM's web site

[e...@coeus-group.com]

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

--- Comment #1 from Evan Nemerson  ---
> Several functions are actually present in arm but not aarch64, I'm guessing
> that will be an easy place to start.  Here is that list:

I pasted the wrong list here; that is actually the list of functions which are
missing from both arm and aarch64.  The attached list is accurate (AFAICT).  It
looks like the majority of functions missing from aarch64 are present in arm
(and vice versa), so hopefully this should be a bit easier to fix than I
thought.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[egallager at gcc dot gnu.org]

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

--- Comment #19 from Eric Gallager  ---
(In reply to Martin Liška from comment #18)
> @egallager: Why did you add 'deferred' keyword? I sent a patch for it to GCC
> patches mailing list.

because:

(In reply to Richard Biener from comment #16)
> Re-target to GCC 10, definitely not material for backporting unless we
> discover critical issues (that should be individually backported). 
> Eventually fully fixed only for GCC 11.

[Bug c++/95422] New: Possible false positive for -Waddress-of-packed-member.

[ldalessandro at gmail dot com]

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

Bug ID: 95422
   Summary: Possible false positive for
-Waddress-of-packed-member.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

I get some confusing results from the following code.

https://godbolt.org/z/p5uZgH

>  struct [[ gnu::packed ]] Foo { 
>  Foo() : x{} {} // <-- #1, x{}
>  void* x[1];
>  } foo;
>  
>  struct [[ gnu::packed ]] Bar { 
>  Bar() : x() {} // <-- #2, x() !!!-Waddress-of-packed-member!!!
>  void* x[1];
>  } bar;
>  
>  struct FooBar { 
>  FooBar() : x() {} // <-- #3, x(), no packed attr
>  void* x[1];
>  } foobar;
I'm seeing the -Waddress-of-packed-member trigger for #2 with g++ (clang++
never produces it), and I can't figure out why this particular use is special.

[Bug target/95421] New: [AArch64] Missing NEON functions documented on ARM's web site

[e...@coeus-group.com]

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

Bug ID: 95421
   Summary: [AArch64] Missing NEON functions documented on ARM's
web site
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Created attachment 48636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48636=edit
Full list of missing functions

This is a companion to #95399 (which is for the arm headers instead of
aarch64).

Quite a few functions listed in ARM's documentation
()
don't seem to be included in GCC's AArch64 arm_{neon,bf16,fp16}.h.

The attached list of 253 functions was generated by just grepping
arm_{neon,bf16,fp16}.h for each function in ARM's documentation so it's
possible there are some false positives, but the ones I've checked manually
seem correct. I'm also not sure how accurate ARM's documentation is.

Several functions are actually present in arm but not aarch64, I'm guessing
that will be an easy place to start.  Here is that list:

  vadd_p16
  vadd_p64
  vadd_p8
  vaddq_p128
  vaddq_p16
  vaddq_p64
  vaddq_p8
  vceqq_p64
  vceqz_p64
  vceqzq_p64
  vcvt_high_bf16_f32
  vcvt_low_bf16_f32
  vld2_lane_bf16
  vld2q_lane_bf16
  vld3_lane_bf16
  vld3q_lane_bf16
  vld4_lane_bf16
  vld4q_lane_bf16
  vrndns_f32
  vst2_lane_bf16
  vst2q_lane_bf16
  vst3_lane_bf16
  vst3q_lane_bf16
  vst3q_lane_p8
  vst3q_lane_s8
  vst3q_lane_u8
  vst4_lane_bf16
  vst4q_lane_bf16

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #16 from Richard Smith  
---
Per p0593, memcpy implicitly creates objects (of any implicit lifetime type) in
the destination. It does not propagate the objects in the source memory to the
destination memory, and can therefore be used to perform a bit cast. (This is
different from C, where memcpy either preserves or copies the effective type
depending on whether the destination has a declared type.)

The s3 function in comment#1 looks correct to me (with or without the launder).
Optimizing it to { return (uint64t *)p; } is incorrect, because it loses the
erasure of dynamic type information that p0593 requires from memcpy in C++.

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
I am testing this:

diff --git a/config/cet.m4 b/config/cet.m4
index 2bb2c8a95ac..911fbd46475 100644
--- a/config/cet.m4
+++ b/config/cet.m4
@@ -7,13 +7,14 @@ GCC_ENABLE(cet, auto, ,[enable Intel CET in target
libraries],
   permit yes|no|auto)
 AC_MSG_CHECKING([for CET support])

+# NB: Avoid nested save_CFLAGS and save_LDFLAGS.
 case "$host" in
   i[[34567]]86-*-linux* | x86_64-*-linux*)
 case "$enable_cet" in
   auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
-   save_CFLAGS="$CFLAGS"
+   cet_save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -fcf-protection"
AC_COMPILE_IFELSE(
 [AC_LANG_PROGRAM(
@@ -27,7 +28,7 @@ asm ("setssbsy");
  ])],
 [enable_cet=yes],
 [enable_cet=no])
-   CFLAGS="$save_CFLAGS"
+   CFLAGS="$cet_save_CFLAGS"
;;
   yes)
# Check if assembler supports CET.
@@ -64,7 +65,7 @@ AC_MSG_CHECKING([for CET support])
 case "$host" in
   i[[34567]]86-*-linux* | x86_64-*-linux*)
 may_have_cet=yes
-save_CFLAGS="$CFLAGS"
+cet_save_CFLAGS="$CFLAGS"
 CFLAGS="$CFLAGS -fcf-protection"
 case "$enable_cet" in
   auto)
@@ -93,7 +94,7 @@ asm ("setssbsy");
 [AC_MSG_ERROR([assembler with CET support is required for
--enable-cet])])
;;
 esac
-CFLAGS="$save_CFLAGS"
+CFLAGS="$cet_save_CFLAGS"
 ;;
   *)
 may_have_cet=no
@@ -101,9 +102,9 @@ asm ("setssbsy");
 ;;
 esac

-save_CFLAGS="$CFLAGS"
+cet_save_CFLAGS="$CFLAGS"
 CFLAGS="$CFLAGS -fcf-protection=none"
-save_LDFLAGS="$LDFLAGS"
+cet_save_LDFLAGS="$LDFLAGS"
 LDFLAGS="$LDFLAGS -Wl,-z,ibt,-z,shstk"
 if test x$may_have_cet = xyes; then
   # Check whether -fcf-protection=none -Wl,-z,ibt,-z,shstk work.
@@ -159,6 +160,6 @@ if test x$enable_cet = xyes; then
 else
   AC_MSG_RESULT([no])
 fi
-CFLAGS="$save_CFLAGS"
-LDFLAGS="$save_LDFLAGS"
+CFLAGS="$cet_save_CFLAGS"
+LDFLAGS="$cet_save_LDFLAGS"
 ])

[Bug libfortran/95390] _gfortran_{,m,s}findloc[01]_c10 not exported from libgfortran.so.5

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Should be fixed now.

[Bug libfortran/95390] _gfortran_{,m,s}findloc[01]_c10 not exported from libgfortran.so.5

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

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

commit r10-8209-gf123dbb2dd2b3f7be81c90258ade9e6099ba19e3
Author: Jakub Jelinek 
Date:   Fri May 29 19:01:50 2020 +0200

libgfortran: Export forgotten _gfortran_{,m,s}findloc{0,1}_c10 [PR95390]

I have noticed we don't export these 6 symbols and thus the testcase
below fails to link.

2020-05-29  Jakub Jelinek  

PR libfortran/95390
* gfortran.dg/findloc_8.f90: New test.

* Makefile.am (i_findloc0_c): Add findloc0_i10.c.
(i_findloc1_c): Add findloc1_i10.c.
* gfortran.map (GFORTRAN_10.2): New symbol version, export
_gfortran_{,m,s}findloc{0,1}_c10 symbols.
* Makefile.in: Regenerated.
* generated/findloc0_c10.c: Generated.
* generated/findloc1_c10.c: Generated.

(cherry picked from commit 316fe6b40165c26b30375f8ad85384379133f89b)

[Bug libfortran/95390] _gfortran_{,m,s}findloc[01]_c10 not exported from libgfortran.so.5

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:316fe6b40165c26b30375f8ad85384379133f89b

commit r11-730-g316fe6b40165c26b30375f8ad85384379133f89b
Author: Jakub Jelinek 
Date:   Fri May 29 19:01:50 2020 +0200

libgfortran: Export forgotten _gfortran_{,m,s}findloc{0,1}_c10 [PR95390]

I have noticed we don't export these 6 symbols and thus the testcase
below fails to link.

2020-05-29  Jakub Jelinek  

PR libfortran/95390
* gfortran.dg/findloc_8.f90: New test.

* Makefile.am (i_findloc0_c): Add findloc0_i10.c.
(i_findloc1_c): Add findloc1_i10.c.
* gfortran.map (GFORTRAN_10.2): New symbol version, export
_gfortran_{,m,s}findloc{0,1}_c10 symbols.
* Makefile.in: Regenerated.
* generated/findloc0_c10.c: Generated.
* generated/findloc1_c10.c: Generated.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qinzhao at gcc dot gnu.org]

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

--- Comment #15 from qinzhao at gcc dot gnu.org ---
please refer to 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qing.zhao at oracle dot com]

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

--- Comment #14 from Qing Zhao  ---
> 
> -fprofile-dir=gcc_prof_dir/%p"
> 
> So my recommendation would be not to use it and let GCOV run-time library 
> merge
> the profiles. Of course, I'll be interested in `perf report` of such a
> instrumented run..

For our application, all processes generating profiling feedback data to a
single directory seems is not a choice. 
We chose -fprofile-dir=%p and then use gcov-merge to merge them.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qing.zhao at oracle dot com]

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

--- Comment #13 from Qing Zhao  ---
> The only exception is a cross-profiling:
> https://gcc.gnu.org/onlinedocs/gcc/Cross-profiling.html
> 
> where one can use GCOV_PREFIX environment variable to save .gcda files to a
> separate location.
> 
> Do you use it? Or do you use any of -fprofile-dir options?

Yes,  We use -fprofile-dir=pd%p when compile the modules.

[Bug target/95399] [ARM] 32/64-bit vcvtnq_* functions are missing

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-29

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Thanks for this. Having this bug listing all of the missing intrinsics is fine.
If you are willing to do the same for the aarch64 functions (keep in mind there
are other include files like arm_fp16.h and arm_bf16.h involved) that would be
a  good separate report

[Bug target/95399] [ARM, AArch64] 32/64-bit vcvtnq_* functions are missing

[e...@coeus-group.com]

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

--- Comment #2 from Evan Nemerson  ---
Created attachment 48635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48635=edit
List of functions missing from 32-bit arm_neon.h

You're right, sorry.  I'm not sure why I was thinking that header was shared.

It looks like there are a *lot* more of these.  Based on a quick script to grep
arm_neon.h for each function listed on ARM's web site
()
as v7/A32 or v7/A32/A64 there are 47 functions missing (plus another 108 if you
include the *_x1/2/3/4 functions, and another 145 if you include the
poly/f16/bf16 stuff).

Here is a list of those first 47:

  vcvtaq_s32_f32
  vcvtaq_u32_f32
  vcvta_s32_f32
  vcvta_u32_f32
  vcvtmq_s32_f32
  vcvtmq_u32_f32
  vcvtm_s32_f32
  vcvtm_u32_f32
  vcvtnq_s32_f32
  vcvtnq_u32_f32
  vcvtn_s32_f32
  vcvtn_u32_f32
  vcvtpq_s32_f32
  vcvtpq_u32_f32
  vcvtp_s32_f32
  vcvtp_u32_f32
  vfma_n_f32
  vfmaq_n_f32
  vld2q_dup_f32
  vld2q_dup_s16
  vld2q_dup_s32
  vld2q_dup_s8
  vld2q_dup_u16
  vld2q_dup_u32
  vld2q_dup_u8
  vld3q_dup_f32
  vld3q_dup_s16
  vld3q_dup_s32
  vld3q_dup_s8
  vld3q_dup_u16
  vld3q_dup_u32
  vld3q_dup_u8
  vld4q_dup_f32
  vld4q_dup_s16
  vld4q_dup_s32
  vld4q_dup_s8
  vld4q_dup_u16
  vld4q_dup_u32
  vld4q_dup_u8
  vreinterpretq_f64_u64
  vrndi_f32
  vrndiq_f32
  vrndn_f64
  vrndnq_f64
  vrndns_f32
  vst3q_lane_s8
  vst3q_lane_u8

I'm not sure how reliable ARM's documentation is... I see that there are
several f64 functions in that list, and I always thought those were supposed to
be exclusive to AArch64.  Assuming ARM's documentation is accurate, though, all
the functions I've checked do seem to be legitimately missing (i.e., I haven't
seen any false positives from my script).

I'm attaching the full list (300 functions), not sure how you want me to handle
this.  Should I file separate bugs for each group (i.e., this one could be for
vcvt*, another one for vrnd*, another for vfma*, etc.)?  One for all of them? 
Or just use this bug for all of them?

[Bug c++/95344] [9/10 Regression] Wparentheses (assignment used as truth value) on parenthesized ternary conditional E2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression]|[9/10 Regression]
   |Wparentheses (assignment|Wparentheses (assignment
   |used as truth value) on |used as truth value) on
   |parenthesized ternary   |parenthesized ternary
   |conditional E2  |conditional E2

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/95344] [9/10/11 Regression] Wparentheses (assignment used as truth value) on parenthesized ternary conditional E2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:1f32d5294f51614f5637d81c522fccacc124f141

commit r11-729-g1f32d5294f51614f5637d81c522fccacc124f141
Author: Marek Polacek 
Date:   Tue May 26 19:59:26 2020 -0400

c++: Fix bogus -Wparentheses warning [PR95344]

Since r267272, which added location wrappers, cp_fold loses
TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and
that results in a bogus -Wparentheses warning.

I.e., previously we had "b = 1" but now we have "VIEW_CONVERT_EXPR(b)
= 1"
and cp_fold_maybe_rvalue folds away the location wrapper and so we do
2718 x = fold_build2_loc (loc, code, TREE_TYPE (x), op0, op1);
in cp_fold and the flag is lost.

PR c++/95344
* cp-gimplify.c (cp_fold) : Don't set
TREE_THIS_VOLATILE here.
(cp_fold): Set it here along with TREE_NO_WARNING.

* c-c++-common/Wparentheses-2.c: New test.

[Bug c++/95222] [10/11 Regression] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jason Merrill  ---
Testcase fixed.

[Bug c++/95311] [11 Regression] ICE in cp_ubsan_maybe_instrument_member_call at gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/95311] [11 Regression] ICE in cp_ubsan_maybe_instrument_member_call at gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8e915901deb3518d4bef73ea52eab2ece7a2bbf6

commit r11-728-g8e915901deb3518d4bef73ea52eab2ece7a2bbf6
Author: Jason Merrill 
Date:   Fri May 29 11:59:33 2020 -0400

c++: vptr ubsan and derived class [PR95311].

We weren't able to find OBJ_TYPE_REF_OBJECT walking through
OBJ_TYPE_REF_EXPR because we had folded away the ADDR_EXPR.

gcc/cp/ChangeLog:

PR c++/95311
PR c++/95221
* class.c (build_vfn_ref): Don't fold the INDIRECT_REF.

gcc/testsuite/ChangeLog:

PR c++/95311
* g++.dg/ubsan/vptr-16.C: New test.

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8e915901deb3518d4bef73ea52eab2ece7a2bbf6

commit r11-728-g8e915901deb3518d4bef73ea52eab2ece7a2bbf6
Author: Jason Merrill 
Date:   Fri May 29 11:59:33 2020 -0400

c++: vptr ubsan and derived class [PR95311].

We weren't able to find OBJ_TYPE_REF_OBJECT walking through
OBJ_TYPE_REF_EXPR because we had folded away the ADDR_EXPR.

gcc/cp/ChangeLog:

PR c++/95311
PR c++/95221
* class.c (build_vfn_ref): Don't fold the INDIRECT_REF.

gcc/testsuite/ChangeLog:

PR c++/95311
* g++.dg/ubsan/vptr-16.C: New test.

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
(In reply to H.J. Lu from comment #1)
> > I strongly suspect the CET patches, but haven't yet figured out what's going
> > wrong.
> 
> How did CET changes add -march=i486 -mtune=i686? Can you bisect to the
> commit?

-march=i486 -mtune=i686 is something added by libgomp/configure.tgt:
# Note that bare i386 is not included here.  We need cmpxchg.
i[456]86-*-linux*)
config_path="linux/x86 linux posix"
case " ${CC} ${CFLAGS} " in
  *" -m64 "*|*" -mx32 "*)
;;
  *)
if test -z "$with_arch"; then
  XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
fi
esac
;;
But that should enable it only when building the 32-bit libgomp and not 32-bit.
 So something else must be adding -m64 somewhere later.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
> Do you use it? Or do you use any of -fprofile-dir options?

Ah, ok, you use it. Based on the report:

-fprofile-dir=gcc_prof_dir/%p"

So my recommendation would be not to use it and let GCOV run-time library merge
the profiles. Of course, I'll be interested in `perf report` of such a
instrumented run..

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
(In reply to qinzhao from comment #9)
> (In reply to Martin Liška from comment #7)
> > 1) You should not generate profile data for each process to a different
> > folder, but rather merge it.
> 
> not sure how to do this? can you provide more details on this approach?

If you have an instrumented binary and you run it multiple times, then each
exit of the application merges profile to existing .gcda files on a disk.

The only exception is a cross-profiling:
https://gcc.gnu.org/onlinedocs/gcc/Cross-profiling.html

where one can use GCOV_PREFIX environment variable to save .gcda files to a
separate location.

Do you use it? Or do you use any of -fprofile-dir options?

> 
> > 2) I would like to know how long does one process run and what portion is
> > spent in merging (and dumping) of a profile.
> will try to get this info.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
> 
> around 14000 processes, they are not the same executable, so not all the run
>

Both I guess they share the majority of compiled object files, right?

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qinzhao at gcc dot gnu.org]

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #7)
> 1) You should not generate profile data for each process to a different
> folder, but rather merge it.

not sure how to do this? can you provide more details on this approach?

> 2) I would like to know how long does one process run and what portion is
> spent in merging (and dumping) of a profile.
will try to get this info.

[Bug target/95420] New: arm-wrs-vxworks7: xgcc: error: unrecognised -mcpu target: armv7-a

[ibuclaw at gdcproject dot org]

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

Bug ID: 95420
   Summary: arm-wrs-vxworks7: xgcc: error: unrecognised -mcpu
target: armv7-a
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Possibly caused by r278253.

GCC fails to pass selftests when building with --target=arm-wrs-vxworks7

Configuring with --target=arm-wrs-vxworks7 --with-cpu=arm8 and the selftests
pass.

/build/arm-wrs-vxworks7/./gcc/xgcc -B/build/arm-wrs-vxworks7/./gcc/ -xc
-nostdinc /dev/null -S -o /dev/null
-fself-test=/build/gcc/gcc/testsuite/selftests
xgcc: error: unrecognised -mcpu target: armv7-a
xgcc: note: valid arguments are: arm8 arm810 strongarm strongarm110 fa526 fa626
arm7tdmi arm7tdmi-s arm710t arm720t arm740t arm9 arm9tdmi arm920t arm920
arm922t arm940t ep9312 arm10tdmi arm1020t arm9e arm946e-s arm966e-s arm968e-s
arm10e arm1020e arm1022e xscale iwmmxt iwmmxt2 fa606te fa626te fmp626 fa726te
arm926ej-s arm1026ej-s arm1136j-s arm1136jf-s arm1176jz-s arm1176jzf-s
mpcorenovfp mpcore arm1156t2-s arm1156t2f-s cortex-m1 cortex-m0 cortex-m0plus
cortex-m1.small-multiply cortex-m0.small-multiply cortex-m0plus.small-multiply
generic-armv7-a cortex-a5 cortex-a7 cortex-a8 cortex-a9 cortex-a12 cortex-a15
cortex-a17 cortex-r4 cortex-r4f cortex-r5 cortex-r7 cortex-r8 cortex-m7
cortex-m4 cortex-m3 marvell-pj4 cortex-a15.cortex-a7 cortex-a17.cortex-a7
cortex-a32 cortex-a35 cortex-a53 cortex-a57 cortex-a72 cortex-a73 exynos-m1
xgene1 cortex-a57.cortex-a53 cortex-a72.cortex-a53 cortex-a73.cortex-a35
cortex-a73.cortex-a53 cortex-a55 cortex-a75 cortex-a76 cortex-a76ae cortex-a77
neoverse-n1 cortex-a75.cortex-a55 cortex-a76.cortex-a55 cortex-m23 cortex-m33
cortex-m35p cortex-m55 cortex-r52
xgcc: error: missing argument to ‘-march=’
compilation terminated.
make[1]: *** [/build/gcc/gcc/c/Make-lang.in:124: s-selftest-c] Error 1

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qinzhao at gcc dot gnu.org]

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #6
> Which means one run takes 100MB is size, right? As you mentioned, having
> 1000 .gcda files, it means that one takes 0.1MB?

around 14000 processes, they are not the same executable, so not all the run
take the same size. some bigger, some smaller. the bigger ones take over 100MB. 

for the bigger one, there are over 5000 .gcda files. 
> Can you please provide dump of one directory? At least for portion of .gcda 
> files?
> How is it common that an entire module is empty?
I will try to get this info for you.

[Bug c++/95386] [10/11 Regression] ICE: in satisfaction_value, while compiling function with a requires clause since r10-3735-gcb57504a55015891

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[andrew2085 at gmail dot com]

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

--- Comment #15 from Andrew Downing  ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Downing from comment #8)
> > From the C standard:
> > If a value is copied into an object having no declared type using memcpy or
> > memmove, or is copied as an array of character type, then the effective type
> > of the modified object for that access and for subsequent accesses that do
> > not modify the value is the effective type of the object from which the
> > value is copied, if it has one. For all other accesses to an object having
> > no declared type, the effective type of the object is simply the type of the
> > lvalue used for the access.
> > 
> > So even using C semantics the effective type of storage and *t should not be
> > changed, because they already have a declared type.
> 
> But in your testcases 't' is a pointer and the declared object is not
> visible.
> So the only thing an implementation can do is take advantage of the declared
> type for optimization when it is visible.

That's not exactly relevant in this case though since this is C++. In C++ new
has special semantics. Regardless of the type of the variable being assigned
to, or the declared type of the object that the pointer argument points to, it
starts the lifetime of an object of the specified type in the storage, and ends
the lifetime of whatever is there. There is no equivalent of this in C. In C
you can change the effective type of an object with allocated storage duration
since it has no declared type, but you can not change the declared type of an
object with automatic storage duration since it has a declared type. double d;
has a declared type;

>Note that for C++ types you can apply memcpy to the placement new is not
>needed since object re-use terminates lifetime of the previous object and
>starts lifetime of a new one.  This means that your example can be
>simplified to

memcpy is needed because starting the lifetime of a new object in the storage
of an existing object does not re-use the old objects representation. If the
default trivial constructor is used the standard explicitly states that the
value of the new object is indeterminate and accessing the value of the object
will result in undefined behavior. This is why in p0593r6 section 3.8 they
mention copying the object representation to another location and then copying
it back after placement new. There is no way in C++ to pun in C like you can
with a union with no intermediate steps.

Yes I expect all these operations to be elided away. They are simply there
because the standard says they have to be. In other compilers they may be
required to ensure well defined behavior. This isn't code that I'm actually
using anywhere I was just reading p0593r6 and tested their described
implementation of std::start_lifetime_as and found this strange behavior. There
is an underlying bug here, and if it's popping up in this example, it will pop
up somewhere else eventually.

This is all kind of besides the point anyway though, because gcc is handling
everything ok except for std::launder. std::launder is only supposed to be an
optimization barrier, but it's causing the opposite problem. Here, std::launder
is preventing an optimization that shouldn't be taking place from NOT taking
place. I've been looking at gcc's code for a while and have gotten as far as
seeing that the use of std::launder is preventing dse_classify_store() in
tree-ssa-dse.c from seeing the relationship between double d = 3.14159; and _6
here.

// this is right before the tree-dse3 pass (I disabled some passes to prevent
constant propagation)
f1 ()
{
  long unsigned int u;
  double d;
  long unsigned int * _6;

   [local count: 1073741824]:

  // this line is removed by tree-dse3
  d = 3.141589988261834005243144929409027099609375e+0;

  _6 = .LAUNDER ();
  u_3 = MEM[(uint64_t *)_6];
  d ={v} {CLOBBER};
  return u_3;

}

If the implementation of std::launder in gcc simply disallows optimization
passes from seeing through it, I think that is a mistake. std::launder being an
optimization barrier means disallowing checks that enable an optimization from
seeing through it as well as allowing checks that disable an optimization from
seeing through it.

[Bug target/94812] ppc incorrect mffs-based emulation of mffsl

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Thanks :-)

[Bug target/95419] New: [vax-openbsd] internal compiler error: in assemble_integer, at varasm.c:2818 with -fexceptions

[ibuclaw at gdcproject dot org]

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

Bug ID: 95419
   Summary: [vax-openbsd] internal compiler error: in
assemble_integer, at varasm.c:2818 with -fexceptions
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Any trivial code, e.g:

int somefunc();
int main()
{
  return somefunc();
}


will result in an ICE when compiling with -fexceptions on --target=vax-openbsd,
only checked when built as a cross-compiler.

Backtrace:
0x6dd8c8 assemble_integer(rtx_def*, unsigned int, unsigned int, int)
/crossbuilds/gcc/gcc/varasm.c:2818
0x964b41 dw2_asm_output_delta(int, char const*, char const*, char const*, ...)
/crossbuilds/gcc/gcc/dwarf2asm.c:141
0x9716ab output_call_frame_info
/crossbuilds/gcc/gcc/dwarf2out.c:812

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

[Bug jit/95415] Add support for thread-local variables

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Perhaps, but it looks non-trivial.

Notes to self:

c/c-tree.h: struct c_declspecs has:
  /* Whether "__thread" or "_Thread_local" was specified.  */
  BOOL_BITFIELD thread_p : 1;
  /* Whether "__thread" rather than "_Thread_local" was specified.  */
  BOOL_BITFIELD thread_gnu_p : 1;

tree.h has:

/* In a VAR_DECL, the model to use if the data should be allocated from
   thread-local storage.  */
#define DECL_TLS_MODEL(NODE) decl_tls_model (NODE)

/* In a VAR_DECL, nonzero if the data should be allocated from
   thread-local storage.  */
#define DECL_THREAD_LOCAL_P(NODE) \
  ((TREE_STATIC (NODE) || DECL_EXTERNAL (NODE)) && decl_tls_model (NODE) >=
TLS_MODEL_REAL)

decl_tls_model/set_decl_tls_model get/set a field of the varpool_node, based on
this enum in coretypes.h:

/* The thread-local storage model associated with a given VAR_DECL
   or SYMBOL_REF.  This isn't used much, but both trees and RTL refer
   to it, so it's here.  */
enum tls_model {
  TLS_MODEL_NONE,
  TLS_MODEL_EMULATED,
  TLS_MODEL_REAL,
  TLS_MODEL_GLOBAL_DYNAMIC = TLS_MODEL_REAL,
  TLS_MODEL_LOCAL_DYNAMIC,
  TLS_MODEL_INITIAL_EXEC,
  TLS_MODEL_LOCAL_EXEC
};

[Bug fortran/95090] ICE: identifier overflow: 129

[manfred99 at gmx dot ch]

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

--- Comment #10 from Manfred Schwarb  ---
I just tried to build a compiler with "-fno-omit-frame-pointer" to
get potentially better backtraces, but then the ICE vanishes ...

Is there a way to get useful backtraces? "--enable-checking=yes,extra"
seems not to be enough...

[Bug middle-end/95052] [9/10/11 Regression] Excess padding of partially initialized strings/char arrays

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #11 from Maxim Kuvyrkov  ---
Created attachment 48634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48634=edit
Crash testcase (from Linux kernel)

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > How did CET changes add -march=i486 -mtune=i686? Can you bisect to the 
> > commit?
> 
> Done: the reghunt identified
> 
> commit 4c1a5d8b71e29b71e0bc1004480c12c5fc427cb7
> Author: H.J. Lu 
> Date:   Fri May 15 09:06:50 2020 -0700
> 
> x86: Also check if -fcf-protection works

I can't reproduce it.

[Bug c++/95311] [11 Regression] ICE in cp_ubsan_maybe_instrument_member_call at gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Fri, 29 May 2020, ed at catmur dot uk wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
> 
> --- Comment #12 from Ed Catmur  ---
> (In reply to Richard Biener from comment #11)
> > Note that for C++ types you can apply memcpy to the placement new is not
> > needed since object re-use terminates lifetime of the previous object and
> > starts lifetime of a new one.
> 
> Under P0593R6 it has the effect of implicitly creating objects on demand.
> Effectively it is supposed to "curse" the double and "bless" the subsequent
> uint64_t. Invoking P0593 may be jumping the gun since it's still in LWG, but
> Richard (Smith) wants it retroactively applied to C++20 IS as a DR, and that
> could still happen.

I believe such "curse"/"bless" operation cannot be implemented without
overhead(*) and thus I would not recommend to make it apply to all
placement new operations.

> > Note that while your example performs memcpy dances you are probably
> > after a solution that elides all generated code?
> 
> Sure, I assume that memcpy of anything smaller than a page will be elided :)

(*) then no longer.

> > Note that I do not belive making your examples work as you intend is
> > possible in an actual implementation without sacrifying all
> > type-based alias analysis.
> 
> Ouch. You might be asked to if and when P0593 goes in (again, assuming I've
> understood it correctly). Would it be appropriate to find out what Ville
> thinks?

Definitely.

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
I successfully bootstrapped

commit c92716b2b1d117a803775a2e2336b751050ff7c2
Author: Martin Liska 
Date:   Fri May 29 13:21:41 2020 +0200

Port bugzilla-close-candidate script to git.

with

CC="cc -m32 -fno-lto" CXX="g++ -m32 -fno-lto"
RUNTESTFLAGS="--target_board='unix'"
/export/gnu/import/git/gitlab/x86-gcc/configure --enable-targets=all
--disable-lto-plugin --disable-libcc1 --disable-libsanitizer --enable-cet
--with-demangler-in-ld i686-linux --prefix=/usr/gcc-11.0.0-32bit
--with-local-prefix=/usr/local --enable-gnu-indirect-function
--enable-clocale=gnu --with-system-zlib --with-target-system-zlib
--with-fpmath=sse --enable-libmpx --enable-languages=c,c++
configure: WARNING: you should use --build, --host, --target
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu

[Bug middle-end/95052] [9/10/11 Regression] Excess padding of partially initialized strings/char arrays

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #10 from Maxim Kuvyrkov  ---
To reproduce:

1. Configure GCC for arm-linux-gnueabihf (e.g., for x86_64->armhf cross):
--with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto --enable-shared
--without-included-gettext --enable-nls --with-system-zlib
--disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id
--disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu
--enable-libstdcxx-debug --enable-long-long --with-cloog=no --with-ppl=no
--with-isl=no --disable-multilib --with-float=hard --with-fpu=vfpv3-d16
--with-mode=thumb --with-tune=cortex-a9 --with-arch=armv7-a
--enable-threads=posix --enable-multiarch --enable-libstdcxx-time=yes
--enable-gnu-indirect-function --disable-libssp --disable-libquadmath
--disable-threads --without-headers --with-newlib --disable-libmudflap
--disable-bootstrap --disable-decimal-float --disable-libgomp
--disable-libatomic --disable-libsanitizer --disable-plugins --disable-libitm
--disable-shared --with-glibc-version=2.18 --disable-libstdcxx --disable-libvtv
--enable-languages=c,c++ --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabihf

2. Try compiling attached pre-processed file:
.../cc1 -fpreprocessed libata-eh.i -quiet -dumpdir drivers/ata/ -dumpbase
libata-eh.c -dumpbase-ext .c -mlittle-endian -mabi=aapcs-linux -mfpu=vfp -marm
-mfloat-abi=soft -mtune=cortex-a9 -mtls-dialect=gnu -march=armv7-a -O2 -Wall
-Wundef -Werror=strict-prototypes -Wno-trigraphs
-Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security
-Wno-frame-address -Wformat-truncation=0 -Wformat-overflow=0
-Wno-address-of-packed-member -Wframe-larger-than=1024
-Wno-unused-but-set-variable -Wimplicit-fallthrough=3 -Wunused-const-variable=0
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation
-Wno-zero-length-bounds -Wno-array-bounds -Wstringop-overflow=0 -Wno-restrict
-Wno-maybe-uninitialized -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -Wno-packed-not-aligned -std=gnu90 -version
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -fno-dwarf2-cfi-asm
-fno-ipa-sra -funwind-tables -fno-delete-null-pointer-checks
-fno-allow-store-data-races -fstack-protector-strong -fomit-frame-pointer
-fno-var-tracking-assignments -fno-strict-overflow -fno-merge-all-constants
-fmerge-constants -fstack-check=no -fconserve-stack -fmacro-prefix-map=./=  -o
libata-eh.s

3. It should crash with:
...
during RTL pass: expand
drivers/ata/libata-eh.c: In function \u2018ata_eh_link_report\u2019:
drivers/ata/libata-eh.c:2293:8: internal compiler error: in store_expr, at
expr.c:5845
0x8e8a56 store_expr(tree_node*, rtx_def*, int, bool, bool)

[Bug libfortran/95418] New: Static assert going off on MinGW

[markus.boeck02 at gmail dot com]

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

Bug ID: 95418
   Summary: Static assert going off on MinGW
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Since commit "i386: Use generic division to generate INEXACT exception"
(d3a1459cd4f2d4997fb53e34ddef72e91a7855c1) libgfortran is not able to be
compiled with the target x86_64-w64-mingw32. This is due to a _Static_assert
going off in fpu-target.h. The exact error message is:

In file included from ../../../libgfortran/runtime/fpu.c:29:
./fpu-target.h:91:1: error: static assertion failed: "GFC_FPE_STATE_BUFFER_SIZE
is too small"
   91 | _Static_assert (sizeof(struct fenv) <= (size_t)
GFC_FPE_STATE_BUFFER_SIZE,
  | ^~

Reverting the above commit makes compilation succeed.

[Bug bootstrap/95413] [11 regression] i686-linux --enable-targets=all cannot configure m64 libgomp

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> How did CET changes add -march=i486 -mtune=i686? Can you bisect to the commit?

Done: the reghunt identified

commit 4c1a5d8b71e29b71e0bc1004480c12c5fc427cb7
Author: H.J. Lu 
Date:   Fri May 15 09:06:50 2020 -0700

x86: Also check if -fcf-protection works

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #13 from Jonathan Wakely  ---
(In reply to Ed Catmur from comment #12)
It's Richard's paper now, not Ville's, so I've CC'd him.

It's unclear whether std::start_lifetime_as is expected to be implementable in
C++ as a normal library function. If there's compiler support then it can do
things the sample implementations shows here can't do.

And start_lifetime_as isn't planned to be treated as a DR for C++20.

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[ed at catmur dot uk]

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

--- Comment #12 from Ed Catmur  ---
(In reply to Richard Biener from comment #11)
> Note that for C++ types you can apply memcpy to the placement new is not
> needed since object re-use terminates lifetime of the previous object and
> starts lifetime of a new one.

Under P0593R6 it has the effect of implicitly creating objects on demand.
Effectively it is supposed to "curse" the double and "bless" the subsequent
uint64_t. Invoking P0593 may be jumping the gun since it's still in LWG, but
Richard (Smith) wants it retroactively applied to C++20 IS as a DR, and that
could still happen.

> Note that while your example performs memcpy dances you are probably
> after a solution that elides all generated code?

Sure, I assume that memcpy of anything smaller than a page will be elided :)

> Note that I do not belive making your examples work as you intend is
> possible in an actual implementation without sacrifying all
> type-based alias analysis.

Ouch. You might be asked to if and when P0593 goes in (again, assuming I've
understood it correctly). Would it be appropriate to find out what Ville
thinks?

[Bug c++/95417] Static storage duration objects that are constant initialized should be destroyed after the destruction of dynamically initialized object.

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
GCC, Clang and EDG all destroy b before a.