[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[stephen at networkplumber dot org]

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

--- Comment #4 from Stephen Hemminger  ---
X86

On Thu, Mar 26, 2020, 5:38 PM pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94350
>
> --- Comment #2 from Andrew Pinski  ---
> Also which target is this on?  x86_64 or aarch64?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug web/94349] Bugzilla user preferences are blank

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
hm, maybe this is why bugzilla has been acting strangely for me lately? 
(forgetting my "last visited" date on bugs, randomly un-cc-ing me without it
showing up in the bug history...)

[Bug middle-end/86715] ICE passing too large argument on stack

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org,
   ||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
Hi,

This does not seem to be happening in the middle end but in RTL expand. I've
tried on x86_64 trunk and now powerpc. Seems to only happen on PowerPC now as
seen here:
test.cpp: In function ‘int main(int, char**)’:
test.cpp:33:23: sorry, unimplemented: passing too large argument on stack
   33 |   result = mulm(m1, m2);
  |   ^
during RTL pass: expand
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


I'm not aware of stack size limitations on Power so I'm CCed the maintainer to
take a look. Not sure if this occurs on other architectures in expand like ARM
as well. Segher would you please take a look at this for me.

[Bug c++/94336] template keyword accepted before destructor names

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:71d69548a1b2c85220ac6354564fd272beb9263f

commit r10-7408-g71d69548a1b2c85220ac6354564fd272beb9263f
Author: Marek Polacek 
Date:   Thu Mar 26 16:07:17 2020 -0400

c++: template keyword accepted before destructor names [PR94336]

This came up on the C++ core list recently.  We don't diagnose the case
when 'template' is followed by a destructor name which is not permitted
by [temp.names]/5.

PR c++/94336 - template keyword accepted before destructor names.
* parser.c (cp_parser_unqualified_id): Give an error when
'template'
is followed by a destructor name.

* g++.dg/template/template-keyword2.C: New test.

[Bug c++/94336] template keyword accepted before destructor names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/94346] [9/10 Regression] ICE due to handle_copy_attribute since r9-3982

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542782.html

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Also, which version of the compiler?  I've fixed a few similar-looking problems
to this recently.

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Also which target is this on?  x86_64 or aarch64?

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-27

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source?

[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848

[stilor at att dot net]

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

--- Comment #8 from Alexey Neyman  ---
Created attachment 48129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48129=edit
Patch

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[wilson at gcc dot gnu.org]

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

--- Comment #24 from Jim Wilson  ---
Joel Sherrill offered to create a binutils bug report for this.

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[vhaisman at gmail dot com]

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

--- Comment #23 from Václav Haisman  ---
I am not sure what to report. I do not understand the background of linker and
relocations enough. Also, I don't have access to Windows and Cygwin any more.

[Bug c++/94336] template keyword accepted before destructor names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542767.html

[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.  I don't think I want to backport this one.  To make it work with G++ 9,
add the template keyword.

[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:517f5356bb0ca717f51e937be880e38a828edbf7

commit r10-7403-g517f5356bb0ca717f51e937be880e38a828edbf7
Author: Marek Polacek 
Date:   Wed Mar 18 19:28:14 2020 -0400

c++: DR1710, template keyword in a typename-specifier [PR94057]

Consider

  template  class A {
template  class B {
  void fn(typename A::B);
};
  };

which is rejected with
error: 'typename A::B' names 'template template class
A::B', which is not a type
whereas clang/icc/msvc accept it.

"typename A::B" is a typename-specifier.  Sadly, our comments
don't mention it anywhere, because the typename-specifier wasn't in C++11;
it was only added to the language in N1376.  Instead, we handle it as
an elaborated-type-specifier (not a problem thus far).   So we get to
cp_parser_nested_name_specifier_opt which has a loop that breaks if we
don't see a < or ::, but that means we can -- tentatively -- parse even
B which is not a nested-name-specifier (it doesn't end with a ::).

I think this should compile because [temp.names]/4 says: "In a qualified-id
used as the name in a typename-specifier, elaborated-type-specifier,
using-declaration, or class-or-decltype, an optional keyword template
appearing at the top level is ignored.", added in DR 1710.  Also see
DR 1812.

This issue on its own is not a significant problem or a regression.
However, in C++20, the typename here becomes optional, and so this test
is rejected in C++20, but accepted in C++17:

  template  class A {
template  class B {
  void fn(A::B);
};
  };

Here we morph A::B into a typename-specifier, but that happens
in cp_parser_simple_type_specifier and we never handle it as above.
To fake the template keyword I'm afraid we need to use
cp_parser_template_id
with template_keyword_p=true as in the patch below.  The tricky thing
is to avoid breaking concepts.

To handle DR 1710, I made cp_parser_nested_name_specifier_opt assume that
when we're naming a type, the template keyword is present, too.  That
revealed a bug: DR 1710 also says that the template keyword can be followed
by an alias template, but we weren't prepared to handle that. 
alias-decl?.C
exercise this.

gcc/cp:

DR 1710
PR c++/94057 - template keyword in a typename-specifier.
* parser.c (check_template_keyword_in_nested_name_spec): New.
(cp_parser_nested_name_specifier_opt): Implement DR1710, optional
'template'.  Call check_template_keyword_in_nested_name_spec.
(cp_parser_simple_type_specifier): Assume that a <
following a qualified-id in a typename-specifier begins
a template argument list.

gcc/testsuite:

DR 1710
PR c++/94057 - template keyword in a typename-specifier.
* g++.dg/cpp1y/alias-decl1.C: New test.
* g++.dg/cpp1y/alias-decl2.C: New test.
* g++.dg/cpp1y/alias-decl3.C: New test.
* g++.dg/parse/missing-template1.C: Update dg-error.
* g++.dg/parse/template3.C: Likewise.
* g++.dg/template/error4.C: Likewise.
* g++.dg/template/meminit2.C: Likewise.
* g++.dg/template/dependent-name5.C: Likewise.
* g++.dg/template/dependent-name7.C: New test.
* g++.dg/template/dependent-name8.C: New test.
* g++.dg/template/dependent-name9.C: New test.
* g++.dg/template/dependent-name10.C: New test.
* g++.dg/template/dependent-name11.C: New test.
* g++.dg/template/dependent-name12.C: New test.
* g++.dg/template/dependent-name13.C: New test.
* g++.dg/template/dr1794.C: New test.
* g++.dg/template/dr314.C: New test.
* g++.dg/template/dr1710.C: New test.
* g++.dg/template/dr1710-2.C: New test.
* g++.old-deja/g++.pt/crash38.C: Update dg-error.

[Bug c/94350] New: internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[stephen at networkplumber dot org]

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

Bug ID: 94350
   Summary: internal compiler error: in
make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4874
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stephen at networkplumber dot org
  Target Milestone: ---

Compiling the DPDK project git://dpdk.org/dpdk
fails with internal compiler error with -fanalyzer

= Build lib/librte_eal/linux/eal
  CC eal.o
  CC eal_cpuflags.o
  CC eal_hugepage_info.o
  CC eal_memory.o
  CC eal_thread.o
  CC eal_log.o
  CC eal_vfio.o
  CC eal_vfio_mp_sync.o
  CC eal_memalloc.o
during IPA pass: analyzer
cc1: internal compiler error: in make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4874

[Bug fortran/94348] gfortran 8/9 reject module procedure definition in same module as function interface

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
Thanks for the quick reply, Steve. My apologies for not providing any text.  I
dashed this off during a call with the person who reported the problem to me. 
I think the code is legal, but I'm very open to the possibility that I'm wrong
here. It's hard to understand the relevant parts of the standard.   The Intel
compiler accepts the code, but the NAG compiler gives an error message similar
to gfortran, which is a strong hint that it could be invalid code.  What's
confusing is that moving the procedure definition to a submodule works with
gfortran:

$ cat foo.f90 
module foo_module
  implicit none

  interface
 module function foo() result(bar)
   implicit none
   integer bar
 end function
  end interface

end module

submodule(foo_module) foo_submodule
  implicit none
contains
  module procedure foo
bar = 0
  end procedure
end submodule

  use foo_module, only : foo
  implicit none
  print *,foo()
end
$ gfortran foo.f90
$ ./a.out
   0

Thoughts?

[Bug web/94349] Bugzilla user preferences are blank

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||overseers at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #22 from Jim Wilson  ---
This looks like a binutils bug to me.  A call to an undefined weak function
should never be executed, so it is OK for the linker to convert that call
instruction into anything convenient.  There is no need for a relocation that
can reach an address of zero.  We can convert the call instruction to call
itself, or the next instruction, or change it to a nop, what ever is
convenient, it doesn't really matter.

A number of binutils ports already have code to handle related problems.  ARM
and RISC-V for sure.  Probably others.  It looks like this support is missing
from the x86_64 port.  I'd suggest refiling this as a binutils bug.  See for
instance
  https://sourceware.org/bugzilla/show_bug.cgi?id=23244
for a RISC-V example of the same problem.  But we need a new bug for the x86_64
problem.  RISC-V has a register hard wired to zero, so I rewrite the call
instruction to use x0 as the base address.  The arm port turns the call into a
nop.

[Bug fortran/94348] gfortran 8/9 reject module procedure definition in same module as function interface

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Don't understand what you consider the problem.

You need to declare bar in the 'module procedure foo'.

Isn't the interface-body a scoping unit?  Isn't bar
a local variable in that scoping unit?

[Bug web/94349] Bugzilla user preferences are blank

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-26

[Bug web/94349] New: Bugzilla user preferences are blank

[mirh at protonmail dot ch]

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

Bug ID: 94349
   Summary: Bugzilla user preferences are blank
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mirh at protonmail dot ch
  Target Milestone: ---

https://gcc.gnu.org/bugzilla/userprefs.cgi

[Bug fortran/94348] New: gfortran 8/9 reject module procedure definition in same module as function interface

[damian at sourceryinstitute dot org]

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

Bug ID: 94348
   Summary: gfortran 8/9 reject module procedure definition in
same module as function interface
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

$ cat foo.f90 
module foo_module
  implicit none

  interface
 module function foo() result(bar)
   implicit none
   integer bar
 end function
  end interface

contains
  module procedure foo
bar = 0
  end procedure
end module
localhost:modules rouson$ gfortran -c foo.f90 
foo.f90:13:7:

   13 | bar = 0
  |   1
Error: Symbol 'bar' at (1) has no IMPLICIT type
localhost:modules rouson$ gfortran --version
GNU Fortran (Homebrew GCC 9.2.0_3) 9.2.0

[Bug c++/94346] [9/10 Regression] ICE due to handle_copy_attribute since r9-3982

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The COMPOUND_EXPRs should be handled like their second operand by
handle_copy_attribute.

[Bug c++/94346] [9/10 Regression] ICE due to handle_copy_attribute since r9-3982

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to fail||10.0, 9.2.0
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #3 from Martin Sebor  ---
The change below avoids the ICE with no regressions in the attribute or warning
tests:

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 9abf81d0248..c1294de2f49 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -2625,7 +2625,7 @@ handle_copy_attribute (tree *node, tree name, tree args,

   /* Copy type attributes from REF to DECL.  */
   for (tree at = attrs; at; at = TREE_CHAIN (at))
-decl_attributes (node, at, flags, ref);
+decl_attributes (node, at, flags, DECL_P (ref) ? ref : NULL_TREE);

   return NULL_TREE;
 }

[Bug c++/94346] [9/10 Regression] ICE due to handle_copy_attribute since r9-3982

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #2 from Martin Sebor  ---
diag_attr_exclusions() expects either a DECL or a TYPE but here it gets an
expression:

$ gcc -S pr94346.c
pr94346.c:8:33: internal compiler error: tree check: expected class ‘type’,
have ‘expression’ (compound_expr) in diag_attr_exclusions, at attribs.c:396
8 |   ATTR (copy ((bar (), ((struct A *)(0))[0]))) int m;
  | ^
pr94346.c:1:35: note: in definition of macro ‘ATTR’
1 | #define ATTR(...) __attribute__ ((__VA_ARGS__))
  |   ^~~
0x16c3530 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/src/gcc/trunk/gcc/tree.c:9745
0x8c8271 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/src/gcc/trunk/gcc/tree.h:3401
0x8c1c5c diag_attr_exclusions
/src/gcc/trunk/gcc/attribs.c:396
0x8c1b67 diag_attr_exclusions
/src/gcc/trunk/gcc/attribs.c:379
0x8c2b75 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/src/gcc/trunk/gcc/attribs.c:694
0xa45e02 handle_copy_attribute
/src/gcc/trunk/gcc/c-family/c-attribs.c:2628
0x8c2c55 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/src/gcc/trunk/gcc/attribs.c:713
0x95422d c_parser_struct_declaration
/src/gcc/trunk/gcc/c/c-parser.c:3620
0x953a6b c_parser_struct_or_union_specifier
/src/gcc/trunk/gcc/c/c-parser.c:3413
0x9528fb c_parser_declspecs(c_parser*, c_declspecs*, bool, bool, bool, bool,
bool, bool, bool, c_lookahead_kind)
/src/gcc/trunk/gcc/c/c-parser.c:2962
0x95031f c_parser_declaration_or_fndef
/src/gcc/trunk/gcc/c/c-parser.c:1960
0x94fe3c c_parser_external_declaration
/src/gcc/trunk/gcc/c/c-parser.c:1745
0x94f95d c_parser_translation_unit
/src/gcc/trunk/gcc/c/c-parser.c:1618
0x98da25 c_parse_file()
/src/gcc/trunk/gcc/c/c-parser.c:21718
0xa19299 c_common_parse_file()
/src/gcc/trunk/gcc/c-family/c-opts.c:1186
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/94347] Assignment pointer at declaration

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||10.0, 9.2.1
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Upgrade to a newer version.  This will likely get closed as WONTFIX in a year
or two.

[Bug libstdc++/94295] use __builtin_operator_new and __builtin_operator_delete when available

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2020-03-26
   Severity|normal  |enhancement
 Ever confirmed|0   |1

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-26

--- Comment #4 from Martin Sebor  ---
Sounds like there's agreement that the code should at least get a warning then,
so confirmed. 

The attribute aligned section of the manual describing the variable attribute
says:

  When used on a struct, or struct member, the aligned attribute can only
increase the alignment...

It's not clear whether struct here refers to a type or a variable (I'm guessing
it's former but it's in the Common Variable Attribute section so it could
easily be read as the latter).  Either way, reducing the alignment of an object
whose members explicitly ask for stricter alignment seems like a dangerous
thing to do without a warning.

I'll see if I can do this for GCC 11.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
--- gcc/testsuite/gcc.target/i386/avx512f-pr94343.c.jj  2020-03-26
17:47:40.008654504 +0100
+++ gcc/testsuite/gcc.target/i386/avx512f-pr94343.c 2020-03-26
17:48:37.169811375 +0100
@@ -0,0 +1,12 @@
+/* PR target/94343 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx512f -mno-avx512vl" } */
+/* { dg-final { scan-assembler-not "vpternlogd\[^\n\r]*xmm\[0-9]*" } } */
+
+typedef int __v4si __attribute__((vector_size (16)));
+
+__v4si
+foo (__v4si a)
+{
+  return ~a;
+}
--- gcc/testsuite/gcc.target/i386/avx512vl-pr94343.c.jj 2020-03-26
17:48:53.232573115 +0100
+++ gcc/testsuite/gcc.target/i386/avx512vl-pr94343.c2020-03-26
17:49:08.034352968 +0100
@@ -0,0 +1,12 @@
+/* PR target/94343 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx512vl" } */
+/* { dg-final { scan-assembler "vpternlogd\[^\n\r]*xmm\[0-9]*" } } */
+
+typedef int __v4si __attribute__((vector_size (16)));
+
+__v4si
+foo (__v4si a)
+{
+  return ~a;
+}

is enough.

[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Few middle-end warnings consider control flow -- most simply look at a single
statement at a time and consider ranges of argument values (if any).  Those
that do consider control flow (e.g., -Wreturn-local-addr) only do so for PHI
nodes that, for the most part, are the result of ?: expressions.  We have work
underway to improve the way GCC computes and exposes range information that we
expect will help improve the accuracy in cases where there's more than a single
range.  I've also been thinking about changing some existing warnings to
consider control flow to improve both their accuracy and efficacy, but this
would only make a difference for PHI nodes.

I haven't thought too much about using branch probabilities to decide whether
to issue a maybe kind of a warning.  Right now, a statement in the IL with a
constant out-of-bounds argument triggers a definitive warning regardless of how
likely the branch it's in is executed.  It might be something to explore,
though I would expect it to quickly turn most warnings in non-trivial code into
the maybe kind.

Using 'if (condition) __builtin_unreachable ();' shouldn't have an adverse
effect on efficiency.  Rather I'd expect it to improve codegen since it tells
GCC that and any code that would otherwise be reachable after it can be
eliminated.  I would expect its effects to be comparable to __builtin_assume
(condition).

[Bug fortran/94347] New: Assignment pointer at declaration

[rondam at yandex dot ru]

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

Bug ID: 94347
   Summary: Assignment pointer at declaration
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rondam at yandex dot ru
  Target Milestone: ---

I am trying to compile the code:
program main
character(10), target :: a
character(:), pointer :: p => null()
p => a
end program main

gfortran version 8.3.0 produces:
internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1820 
gfortran version 7.5.0 produces:
internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1777

But this:
program main
character(10), target :: a
character(:), pointer :: p
p => null()
p => a
end program main

or this:

program main
character, dimension(10), target :: a
character, dimension(:), pointer :: p => null()
p => a
end program main

is compliled ok.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[kretz at kde dot org]

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

--- Comment #9 from Matthias Kretz (Vir)  ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 48128 [details]
> gcc10-pr94343.patch

The avx512vl-pr94343.c test should ideally fail because `_mm_andnot_si128
((__m128i) (~v ^ a), (__m128i) ~w)` is equal to `a`. Maybe the test should
simply `return ~v ^ a;` and thus emit a single vpternlogd?

[Bug c++/94346] [9/10 Regression] ICE due to handle_copy_attribute since r9-3982

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-26
   Priority|P3  |P2
 CC||msebor at gcc dot gnu.org
   Target Milestone|--- |9.4

--- Comment #1 from Jakub Jelinek  ---
Ran into this with PR94339 fix on attr-copy-2.C testcase, but as this adjusted
testcase shows, the issue has been there before.

[Bug c++/94346] New: [9/10 Regression] ICE due to handle_copy_attribute since r9-3982

[jakub at gcc dot gnu.org]

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

Bug ID: 94346
   Summary: [9/10 Regression] ICE due to handle_copy_attribute
since r9-3982
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

#define ATTR(...) __attribute__ ((__VA_ARGS__))

typedef struct ATTR (packed) A { ATTR (packed) unsigned bf: 1; } A;
int bar (void);

struct C
{
  ATTR (copy ((bar (), ((struct A *)(0))[0]))) int m;
};

ICEs since r9-3982-g79a2c4281c7dcaa6a138d24fd037c62453a12bde (before that it
has been accepted with a warning).

[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848

[stilor at att dot net]

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

--- Comment #7 from Alexey Neyman  ---
(In reply to Richard Biener from comment #6)
> (In reply to Alexey Neyman from comment #4)
> > Or add a similar "return if debug level is terse" at the beginning of
> > `gen_type_die` - I didn't notice that in C++ it could also get called not
> > through the `add_type_attribute`:
> > 
> > ```
> > diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> > index 89e52a41508..b0f6680bd61 100644
> > --- a/gcc/dwarf2out.c
> > +++ b/gcc/dwarf2out.c
> > @@ -25709,6 +25709,9 @@ gen_type_die_with_usage (tree type, dw_die_ref
> > context_die,
> >  static void
> >  gen_type_die (tree type, dw_die_ref context_die)
> >  {
> > +  if (debug_info_level <= DINFO_LEVEL_TERSE)
> > +return;
> > +
> >if (type != error_mark_node)
> >  {
> >gen_type_die_with_usage (type, context_die, DINFO_USAGE_DIR_USE);
> > ```
> > 
> > I verified that it makes the attached test case compile successfully.
> 
> But then the static var is improperly scoped in the debug info?  IMHO
> it's better left out.

First, which static variable? The test case for this PR does not have any
static vars:

```
class a {
  virtual void c() {}
} extern b;
a b;
```

As to DECL_FILE_SCOPE_P check, do you mean something like this?

```
@@ -26360,7 +26365,8 @@ gen_decl_die (tree decl, tree origin, struct
vlr_context *ctx,
 variable declarations or definitions unless it is external.  */
   if (debug_info_level < DINFO_LEVEL_TERSE
  || (debug_info_level == DINFO_LEVEL_TERSE
- && !TREE_PUBLIC (decl_or_origin)))
+ && (!TREE_PUBLIC (decl_or_origin)
+  || !DECL_FILE_SCOPE_P(decl_or_origin
break;

   if (debug_info_level > DINFO_LEVEL_TERSE) {
@@ -26841,7 +26847,8 @@ dwarf2out_decl (tree decl)
 variable declarations or definitions unless it is external.  */
   if (debug_info_level < DINFO_LEVEL_TERSE
  || (debug_info_level == DINFO_LEVEL_TERSE
- && !TREE_PUBLIC (decl)))
+ && (!TREE_PUBLIC (decl)
+  || !DECL_FILE_SCOPE_P(decl
return;
   break;

```

This change doesn't resolve the ICE with that test.

I am going to attach a patch with what I suggested. Whether it is accepted, or
something different needs to be done - I don't have commit access, so somebody
else will have to commit it.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #48127|0   |1
is obsolete||

--- Comment #8 from Jakub Jelinek  ---
Created attachment 48128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48128=edit
gcc10-pr94343.patch

Updated patch.  A variant to that would be 4 separate patterns I guess, not
sure if that would be shorter.

[Bug target/94282] [amdgcn] ld: error: undefined symbol: __gxx_personality_v0

[ams at gcc dot gnu.org]

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

--- Comment #3 from Andrew Stubbs  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Tobias Burnus from comment #1)
> > The symbol __gxx_personality_v0 is part of libsupc++ – which I believe is
> > not build to to lacking/restricted C++ support.
> 
> It is also exception handling related.  Does amdgcn have EH support?

No, it does not. No unwind support, nor sjlj either (the register file is very
large, and has variable size, so it's not trivial to implement, IIUC).

[Bug target/94282] [amdgcn] ld: error: undefined symbol: __gxx_personality_v0

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Tobias Burnus from comment #1)
> The symbol __gxx_personality_v0 is part of libsupc++ – which I believe is
> not build to to lacking/restricted C++ support.

It is also exception handling related.  Does amdgcn have EH support?

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Though, there are other issues.  There is only vpternlog{d,q}, so for
V*[QH]Imode we shouldn't pretend we have masking support.

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
It's a mistake to be referring to the C standard for the interpretation of 
alignment attributes.  The C standard way of specifying alignment is 
_Alignas, not __attribute__, and if you write equivalent code using 
_Alignas you get an error "error: '_Alignas' specifiers cannot reduce 
alignment of 'A'", which corresponds to the constraint "The combined 
effect of all alignment specifiers in a declaration shall not specify an 
alignment that is less strict than the alignment that would otherwise be 
required for the type of the object or member being declared.".

[Bug libstdc++/94345] std::chrono overflows due to c++14 non-compliance

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-26
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
That was https://cplusplus.github.io/LWG/issue2094

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[bikineev at google dot com]

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

--- Comment #6 from Anton  ---
I also don't understand why all the parts of a template instantiation need to
be kept in the same COMDAT group. Neither clang nor gcc does it:

template
void Index(int i) { 
  static int VAR1 = i;
  static int VAR2 = i; 
   
 }  

template void Index(int);
template void Index(int);

This gives:

COMDAT group section [1] `.group' [void Index(int)] contains 2
sections:
   [Index]Name
   [   14]   .text._Z5IndexIiEvi
   [   15]   .rela.text._Z5IndexIiEvi

COMDAT group section [2] `.group' [void Index(int)] contains 2
sections:
   [Index]Name
   [   16]   .text._Z5IndexIfEvi
   [   17]   .rela.text._Z5IndexIfEvi

COMDAT group section [3] `.group' [Index(int)::VAR] contains 1
sections:
   [Index]Name
   [   18]   .bss._ZZ5IndexIiEviE3VAR

COMDAT group section [4] `.group' [guard variable for Index(int)::VAR]
contains 1 sections:
   [Index]Name
   [   19]   .bss._ZGVZ5IndexIiEviE3VAR

COMDAT group section [5] `.group' [Index(int)::VAR2] contains 1
sections:
   [Index]Name
   [   20]   .bss._ZZ5IndexIiEviE4VAR2

COMDAT group section [6] `.group' [guard variable for
Index(int)::VAR2] contains 1 sections:
   [Index]Name
   [   21]   .bss._ZGVZ5IndexIiEviE4VAR2

COMDAT group section [7] `.group' [Index(int)::VAR] contains 1
sections:
   [Index]Name
   [   22]   .bss._ZZ5IndexIfEviE3VAR

COMDAT group section [8] `.group' [guard variable for
Index(int)::VAR] contains 1 sections:
   [Index]Name
   [   23]   .bss._ZGVZ5IndexIfEviE3VAR

COMDAT group section [9] `.group' [Index(int)::VAR2] contains 1
sections:
   [Index]Name
   [   24]   .bss._ZZ5IndexIfEviE4VAR2

COMDAT group section [   10] `.group' [guard variable for
Index(int)::VAR2] contains 1 sections:
   [Index]Name
   [   25]   .bss._ZGVZ5IndexIfEviE4VAR2


I might have misunderstood, but I think that COMDAT groups are orthogonal to
section naming.

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[bikineev at google dot com]

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

--- Comment #5 from Anton  ---
Looking at the COMDAT groups for the example with 2 instantiations (Index
and Index), I think this is what is actually expected: section for
Index must not be grouped with section for Index. In general,
different instantiations must be kept in different COMDAT groups. Otherwise, it
would not work e.g. if one TU instantiates Index, the other TU
instantiates Index and Index.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 48127 [details]
> gcc10-pr94343.patch
> 
> That of course doesn't work if the input operand is memory.  This should.

LGTM.  Thanks.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 48127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48127=edit
gcc10-pr94343.patch

That of course doesn't work if the input operand is memory.  This should.

[Bug libstdc++/94345] New: std::chrono overflows due to c++14 non-compliance

[jaapaap at freemail dot hu]

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

Bug ID: 94345
   Summary: std::chrono overflows due to c++14 non-compliance
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaapaap at freemail dot hu
  Target Milestone: ---

The code below does not compile, as the introduction of operator+(const years&
x, const year& y) into the overload set causes the instantiation of the
chrono::duration converting constructor that tries to convert picoseconds to
years. Since C++14 this constructor has been specified to not participate in
overload resolution unless the conversion (factor) does not cause overflow (The
overflow clause was absent in C++11). It seems GCC hasn't implemented the
overflow clause. Thanks and credits go to Howard Hinnant for identifying this
during my discussion with him here:
https://gitter.im/HowardHinnant/date?at=5cb306ffa0790b29c9b4d3fd and who
provided the standalone minimum test case below.

#include 

namespace date {

using days = std::chrono::duration
, std::chrono::hours::period>>;

using weeks = std::chrono::duration
, days::period>>;

using years = std::chrono::duration
, days::period>>;


class year
{
};

constexpr year  operator+(const years&  x, const year& y) noexcept;

}  // namespace date

void this_compiles()
{
   using TDuration = std::chrono::duration;
   TDuration d1, d2;
   using namespace date;
   TDuration d3 = d1 + d2;
}

void this_does_not_compile()
{
   using TDuration = std::chrono::duration<__int128_t, std::pico>;
   TDuration d1, d2;
   using namespace date; // removing this line makes it compile

   TDuration d3 = d1 + d2; // does not compile
}

int
main()
{
}

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
I was thinking about
--- gcc/config/i386/sse.md.jj   2020-03-06 11:35:46.284074858 +0100
+++ gcc/config/i386/sse.md  2020-03-26 17:35:23.690515228 +0100
@@ -12800,10 +12800,18 @@
(xor:VI (match_operand:VI 1 "nonimmediate_operand" "vm")
(match_operand:VI 2 "vector_all_ones_operand" "BC")))]
   "TARGET_AVX512F"
-  "vpternlog\t{$0x55, %1, %0,
%0|%0, %0, %1, 0x55}"
+{
+  if (TARGET_AVX512VL)
+return "vpternlog\t{$0x55, %1, %0,
%0|%0, %0, %1, 0x55}";
+  else
+return "vpternlog\t{$0x55, %g1, %g0,
%g0|%g0, %g0, %g1, 0x55}";
+}
   [(set_attr "type" "sselog")
(set_attr "prefix" "evex")
-   (set_attr "mode" "")])
+   (set (attr "mode")
+(if_then_else (match_test "TARGET_AVX512VL")
+ (const_string "")
+ (const_string "XI")))])

 (define_expand "_andnot3"
   [(set (match_operand:VI_AVX2 0 "register_operand")
instead.  I'm aware that from performance POV we are trying to avoid 512-bit
vectors, but don't all such affected CPUs support AVX512VL already?  Does KNL
care if it will do a 512-bit operation instead of 128-bit or 256-bit?

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 48126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48126=edit
A patch

Jakub, this is what I have. Feel free to ignore it.

[Bug rtl-optimization/94344] [9/10 Regression] Rotate pattern not recognized anymore

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Rotate pattern not  |[9/10 Regression] Rotate
   |recognized anymore  |pattern not recognized
   ||anymore
   Target Milestone|--- |9.4
   Keywords||missed-optimization

--- Comment #2 from Andrew Pinski  ---
It would be better if this is recognized at the tree level.

[Bug rtl-optimization/94344] Rotate pattern not recognized anymore

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
g:c4c5ad1d6d1

[Bug rtl-optimization/94344] New: Rotate pattern not recognized anymore

[stefansf at linux dot ibm.com]

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

Bug ID: 94344
   Summary: Rotate pattern not recognized anymore
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---

Consider the following MWE:

int64_t f (int64_t x)   
{   
  int64_t y = x & -49;  
  return (y << 5) | (int64_t)((uint64_t)y >> 59);   
}

Prior to patch c4c5ad1d6d1 combine successfully recognized the rotate pattern
and suggested amongst other the following insn (using `gcc -O3 -S
-fdump-rtl-combine-details test.c`):

(set (reg:DI 67)
(rotate:DI (reg/v:DI 64 [ y ])  
(const_int 5 [0x5])))

However, with patch c4c5ad1d6d1 applied, this is not the case anymore. Thus,
only combinations of shifts+and+ior are emitted.

This is reproducible for s390x on HEAD (16948c54b75) by simply reverting the
patch. Any idea how we could tweak combine back to the old behaviour where it
detected a rotate successfully?

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Looking.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jbeulich at suse dot com,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2020-03-26
 Ever confirmed|0   |1
   Target Milestone|--- |10.0
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
  Known to work||9.3.0
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
You are right, AVX512VL is not supported with knl.
It started with r10-2016-gff8f129bc2f57fdf:

vpternlogd  $0x55, %xmm0, %xmm0, %xmm0
vpcmpeqd%xmm1, %xmm1, %xmm1
vpandn  %xmm1, %xmm0, %xmm0
ret

before the revision we emitted:

vpcmpeqd%xmm1, %xmm1, %xmm1
vpxor   %xmm1, %xmm0, %xmm0
vpcmpeqd%xmm1, %xmm1, %xmm1
vpandn  %xmm1, %xmm0, %xmm0
ret

[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 since r10-5567

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work|9.2.0   |9.3.0
  Known to fail|9.3.0   |

--- Comment #7 from Martin Liška  ---
No, I used bogus prebuilt binary.

[Bug target/94343] New: [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[kretz at kde dot org]

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

Bug ID: 94343
   Summary: [10 Regression] invalid AVX512VL vpternlogd
instruction emitted for -march=knl
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---
Target: i386,x86-64

Test case (`-O1 -march=knl`, cf. https://godbolt.org/z/qQc3Sf):

using W [[gnu::vector_size(16)]] = long long;
using V [[gnu::vector_size(16)]] = int;

auto f(V a) {
return __builtin_ia32_pandn128(reinterpret_cast(~V() ^ a), ~W());
}


This emits a XMM variant of `vpternlogd` which requires AVX512VL. But it was
supposed to compile for KNL.

Besides the bug, there's also a missed optimization here: `~V() ^ a` flips all
bits and pandn flips all bits again. Thus it should compile to a single `ret`
instruction. Note that the variation:

auto f(V a) {
return ~reinterpret_cast(~V() ^ a) & ~W();
}

compiles to

  vpternlogd xmm0, xmm0, xmm0, 0x55
  vpternlogq xmm0, xmm0, xmm0, 0x55

for KNL.

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[barry.revzin at gmail dot com]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #11 from Barry Revzin  ---
Here's an interesting reduction:

#include 
struct any {
any();
any(any const&);
  template 
, class = std::enable_if_t<
!std::is_same::value
&& std::is_copy_constructible::value
#ifdef LIBSTDCXX
&& std::is_constructible::value
#endif
>
>
  any(ValueType&& value);
};

struct X {
  X(X const&);
  X(any);
};
static_assert(std::is_copy_constructible_v);


This compiles fine, fails if you add -DLIBSTDCXX. I laid it out this way
because libstdc++ has that check but libc++ doesn't. Although, this is
especially weird because in this program, there is only one instantiation of
any's constructor template and it's with ValueType=X const&, which means that
we're checking is_copy_constructible && is_constructible...
which should be identical and yet are somehow not.

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Wilco from comment #2)
> (In reply to Martin Liška from comment #1)
> > I've just run the test-case on aarch64 and it works fine (-O2, -O2 -flto,
> > -O3 -flto -fno-early-inlining). And lto.exp testsuite works fine on aarch64.
> > @Wilco: Can you please double-check?
> 
> Yes it now works on AArch64, but I still see failures on Arm.

Can you please analyze (or bisect that) what happens?

[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 since r10-5567

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.0, 9.3.0
  Known to work||9.2.0

--- Comment #6 from Martin Liška  ---
Apparently, GCC 9 branch is also affected since 9.3.0 release.

[Bug debug/94329] [8/9/10 Regression] error: use_only.f90: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|gcc-9: error: use_only.f90: |[8/9/10 Regression] error:
   |‘-fcompare-debug’ failure   |use_only.f90:
   |(length)|‘-fcompare-debug’ failure
   ||(length)
   Target Milestone|--- |8.5

--- Comment #1 from Jakub Jelinek  ---
Started with my r0-126015-g5e40da4f64effc4104fd5d787c37da9cd04c06fe
Will have a look.

[Bug target/94282] [amdgcn] ld: error: undefined symbol: __gxx_personality_v0

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
The symbol __gxx_personality_v0 is part of libsupc++ – which I believe is not
build to to lacking/restricted C++ support.

[Bug c++/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
--- gcc/cp/call.c.jj2020-03-25 08:05:07.153731580 +0100
+++ gcc/cp/call.c   2020-03-26 15:03:42.432909693 +0100
@@ -333,11 +333,14 @@ set_flags_from_callee (tree call)
   && internal_fn_flags (CALL_EXPR_IFN (call)) & ECF_NOTHROW)
 nothrow = true;

-  if (!nothrow && at_function_scope_p () && cfun && cp_function_chain)
-cp_function_chain->can_throw = 1;
+  if (cfun && cp_function_chain && !cp_unevaluated_operand)
+{
+  if (!nothrow && at_function_scope_p ())
+   cp_function_chain->can_throw = 1;

-  if (decl && TREE_THIS_VOLATILE (decl) && cfun && cp_function_chain)
-current_function_returns_abnormally = 1;
+  if (decl && TREE_THIS_VOLATILE (decl))
+   current_function_returns_abnormally = 1;
+}

   TREE_NOTHROW (call) = nothrow;
 }

seems to work, but not sure if that is what we want.

[Bug c++/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
And the reason for the differences is that with -Wno-return-local-addr (or -w
etc.) m_fn1 is marked TREE_NOTHROW (fndecl) in finish_function, while with
-Wreturn-local-addr (and without -w) it is not.
The difference is in cp_function_chain->can_throw , which set not set in the no
warning case, and is set in:
#0  set_flags_from_callee (call=) at
../../gcc/cp/call.c:324
#1  0x00966d3b in build_call_a (function=,
n=2, argarray=0x7fffb1e0) at ../../gcc/cp/call.c:365
#2  0x0098936f in build_cxx_call (fn=,
nargs=2, argarray=0x7fffb1e0, complain=128, orig_fndecl=)
at ../../gcc/cp/call.c:9578
#3  0x009877cc in build_over_call (cand=0x3763930, flags=3, complain=0)
at ../../gcc/cp/call.c:9082
#4  0x0098c868 in build_new_method_call_1 (instance=, fns=, 
args=0x7fffb860 = {...}, conversion_path=,
flags=1, fn_p=0x0, complain=128) at ../../gcc/cp/call.c:10335
#5  0x0098cd56 in build_new_method_call (instance=, fns=, 
args=0x7fffb860 = {...}, conversion_path=, flags=1, fn_p=0x0,
complain=128) at ../../gcc/cp/call.c:10410
#6  0x00c41d6f in tsubst_copy_and_build (t=,
args=, complain=128, in_decl=, 
function_p=false, integral_constant_expression_p=false) at
../../gcc/cp/pt.c:19812
#7  0x00c2ae69 in tsubst (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:15746
#8  0x00ac831c in dump_template_bindings (pp=0x34be940
, parms=, args=, 
typenames=0x7fffea950a28 = {...}) at ../../gcc/cp/error.c:414
#9  0x00ace590 in dump_substitution (pp=0x34be940
, t=, 
template_parms=, template_args=, flags=132) at ../../gcc/cp/error.c:1560
#10 0x00ad0138 in dump_function_decl (pp=0x34be940
, t=, flags=132)
at ../../gcc/cp/error.c:1718
#11 0x00acd485 in dump_decl (pp=0x34be940 ,
t=, flags=132)
at ../../gcc/cp/error.c:1290
#12 0x00ad6ba8 in decl_to_string (decl=, verbose=1) at ../../gcc/cp/error.c:3092
#13 0x00ada974 in cp_printer (pp=0x370bbb0, text=0x7fffc550,
spec=0x3721f62 "D", precision=0, wide=false, set_locus=false, 
verbose=true, quoted=0x7fffc19f, buffer_ptr=0x3721d70) at
../../gcc/cp/error.c:4260
#14 0x026f5fe2 in pp_format (pp=0x370bbb0, text=0x7fffc550) at
../../gcc/pretty-print.c:1458
#15 0x026f63b2 in pp_format_verbatim (pp=0x370bbb0,
text=0x7fffc550) at ../../gcc/pretty-print.c:1519
#16 0x026f6c1d in pp_verbatim (pp=0x370bbb0, msg=0x2813680 "required
from %q#D\n") at ../../gcc/pretty-print.c:1773
#17 0x00ad8b73 in print_instantiation_partial_context_line
(context=0x36bc320 , t=0x7fffea956440, 
loc=2147483653, recursive_p=false) at ../../gcc/cp/error.c:3537
#18 0x00ad8e6d in print_instantiation_partial_context
(context=0x36bc320 , t0=0x7fffea936860,
loc=2147483653)
at ../../gcc/cp/error.c:3625
#19 0x00ad89fb in print_instantiation_full_context (context=0x36bc320
) at ../../gcc/cp/error.c:3505
#20 0x00ad8eec in maybe_print_instantiation_context (context=0x36bc320
) at ../../gcc/cp/error.c:3642
#21 0x00ad74c6 in cp_diagnostic_starter (context=0x36bc320
, diagnostic=0x7fffc880)
at ../../gcc/cp/error.c:3341
#22 0x026cfced in diagnostic_report_diagnostic (context=0x36bc320
, diagnostic=0x7fffc880)
at ../../gcc/diagnostic.c:1160
#23 0x026d02f2 in diagnostic_impl (richloc=0x7fffc8f0,
metadata=0x0, opt=635, gmsgid=0x284c5f8 "returning reference to temporary", 
ap=0x7fffc9a0, kind=DK_WARNING) at ../../gcc/diagnostic.c:1309
#24 0x026d0b70 in warning_at (location=247168, opt=635,
gmsgid=0x284c5f8 "returning reference to temporary")

i.e. when the warning is being emitted.
The call in question is
A<>::m_fn2 (&((struct B *) this)->_M_t, TARGET_EXPR 

So, shall set_flags_from_callee be setting cp_function_chain->can_throw (or
other flags) even in cp_unevaluated_operand ?  Or shouldn't tsubst or whatever
else sets cp_unevaluated_operand?  Something else?

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #2 from Wilco  ---
(In reply to Martin Liška from comment #1)
> I've just run the test-case on aarch64 and it works fine (-O2, -O2 -flto,
> -O3 -flto -fno-early-inlining). And lto.exp testsuite works fine on aarch64.
> @Wilco: Can you please double-check?

Yes it now works on AArch64, but I still see failures on Arm.

[Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
(In reply to Kewen Lin from comment #16)
> Created attachment 48125 [details]
> untested patch

LGTM

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
So the section attribute then only provides naming of the comdat section used
and cannot be used to group things.  Not sure that is what you are looking
after.

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Hmm, I see clang produces

COMDAT group section [3] `.group' [_Z5IndexIiEvi] contains 2 sections:
   [Index]Name
   [4]   .text._Z5IndexIiEvi
   [5]   .rela.text._Z5IndexIiEvi

COMDAT group section [6] `.group' [_ZZ5IndexIiEviE3VAR] contains 1
sections:
   [Index]Name
   [7]   NEW_SECTION

COMDAT group section [8] `.group' [_ZGVZ5IndexIiEviE3VAR] contains 1
sections:
   [Index]Name
   [9]   .bss._ZGVZ5IndexIiEviE3VAR

and if I add a Index specialization it ends up emitting two
distinct sections with the same name NEW_SECTION and

COMDAT group section [3] `.group' [_Z5IndexIiEvi] contains 2 sections:
   [Index]Name
   [4]   .text._Z5IndexIiEvi
   [5]   .rela.text._Z5IndexIiEvi

COMDAT group section [6] `.group' [_Z5IndexIfEvi] contains 2 sections:
   [Index]Name
   [7]   .text._Z5IndexIfEvi
   [8]   .rela.text._Z5IndexIfEvi

COMDAT group section [9] `.group' [_ZZ5IndexIiEviE3VAR] contains 1
sections:
   [Index]Name
   [   10]   NEW_SECTION

COMDAT group section [   11] `.group' [_ZGVZ5IndexIiEviE3VAR] contains 1
sections:
   [Index]Name
   [   12]   .bss._ZGVZ5IndexIiEviE3VAR

COMDAT group section [   13] `.group' [_ZZ5IndexIfEviE3VAR] contains 1
sections:
   [Index]Name
   [   14]   NEW_SECTION

COMDAT group section [   15] `.group' [_ZGVZ5IndexIfEviE3VAR] contains 1
sections:
   [Index]Name
   [   16]   .bss._ZGVZ5IndexIfEviE3VAR

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I think it should belong to the same .comdat group as other parts of the
template instantiation (there's one static var per instantiation) so I don't
see how the section specification can be easily honored.

But at least a diagnostic would be appropriate.

That is, consider two TUs with instantiations of Index, how will you
make linking work?  Force the definition WEAK?

[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
(In reply to Alexey Neyman from comment #4)
> Or add a similar "return if debug level is terse" at the beginning of
> `gen_type_die` - I didn't notice that in C++ it could also get called not
> through the `add_type_attribute`:
> 
> ```
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index 89e52a41508..b0f6680bd61 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -25709,6 +25709,9 @@ gen_type_die_with_usage (tree type, dw_die_ref
> context_die,
>  static void
>  gen_type_die (tree type, dw_die_ref context_die)
>  {
> +  if (debug_info_level <= DINFO_LEVEL_TERSE)
> +return;
> +
>if (type != error_mark_node)
>  {
>gen_type_die_with_usage (type, context_die, DINFO_USAGE_DIR_USE);
> ```
> 
> I verified that it makes the attached test case compile successfully.

But then the static var is improperly scoped in the debug info?  IMHO
it's better left out.

[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Any progress on this?  It breaks quite a lot of stuff in real world code.

[Bug c++/94336] template keyword accepted before destructor names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

  Attachment #48122|0   |1
is obsolete||

--- Comment #16 from Kewen Lin  ---
Created attachment 48125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48125=edit
untested patch

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
I've just run the test-case on aarch64 and it works fine (-O2, -O2 -flto, -O3
-flto -fno-early-inlining). And lto.exp testsuite works fine on aarch64.
@Wilco: Can you please double-check?

[Bug c++/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
$ rm -f pr94326.C.*; ./cc1plus -quiet -std=c++11 pr94326.C -Wreturn-local-addr
-da; grep REG_EH_REGION pr94326.C.*
pr94326.C: In instantiation of ‘const int& A< 
>::m_fn1() [with  = int]’:
pr94326.C:5:45:   required from ‘void A<  >::m_fn2(_Kt)
[with _Kt = C;  = int]’
pr94326.C:12:15:   required from ‘decltype
(((B*)this)->B::_M_t.A<>::m_fn2<_Kt>(p1)) B::m_fn3(_Kt) [with _Kt = C; decltype
(((B*)this)->B::_M_t.A<>::m_fn2<_Kt>(p1)) = void]’
pr94326.C:18:14:   required from here
pr94326.C:2:31: warning: returning reference to temporary [-Wreturn-local-addr]
2 |   const int _fn1() { return 0; }
  |   ^
$ rm -f pr94326.C.*; ./cc1plus -quiet -std=c++11 pr94326.C
-Wno-return-local-addr -da; grep REG_EH_REGION pr94326.C.*
pr94326.C.236r.expand: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.236r.expand: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.237r.vregs: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.238r.into_cfglayout: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.239r.jump: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.239r.jump: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.251r.reginfo: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.274r.outof_cfglayout: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.275r.split1: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.277r.dfinit: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.278r.mode_sw: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.279r.asmcons: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.284r.ira:(expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.285r.reload: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.292r.pro_and_epilogue: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.295r.jump2: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.306r.split4: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.307r.stack: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.308r.alignments: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.310r.mach: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.311r.barriers: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.316r.shorten: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.317r.nothrow: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.318r.dwarf2: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.319r.final: (expr_list:REG_EH_REGION (const_int 0 [0])
pr94326.C.320r.dfinish: (expr_list:REG_EH_REGION (const_int 0 [0])

[Bug c++/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Component|debug   |c++

--- Comment #1 from Jakub Jelinek  ---
Indeed, I think this started failing with
r0-114389-g4b6aaa996e0d8f5abac818315b6f77cb3596db98
before which it has been rejected with sorry message.
The bug isn't debug related in this case, but -w is affecting generated code.

[Bug c++/94257] ICE in inline nested namespace

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #16 from Martin Liška  ---
I see the ODR warning being properly printed:

g++ pr64076_0.o pr64076_1.o
pr64076.H:10:8: warning: type ‘struct S’ violates the C++ One Definition Rule
[-Wodr]
   10 | struct S : public X, public Y, public Z
  |^
pr64076.H:10:8: note: a type with the same name but different number of
polymorphic bases is defined in another translation unit
   10 | struct S : public X, public Y, public Z
  |^
pr64076.H:8:8: note: the extra base is defined here
8 | struct T : public Base { };
  |^
pr64076.H:15:8: warning: type of ‘f’ does not match original declaration
[-Wlto-type-mismatch]
   15 |   void f()
  |^
pr64076_1.C:5:6: note: ‘f’ was previously declared here
5 | void S::f() { }
  |  ^
pr64076_1.C:5:6: note: code may be misoptimized unless ‘-fno-strict-aliasing’
is used

I agree with Honza that it's not P1.

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-03-26
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, it started with GCC 4.9.0 if I see correctly.

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed since r10-7344-gca6c722561ce9b9d

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 48124
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48124=edit
gcc10-pr94339.patch

Untested fix.

[Bug c++/94342] New: GCC ignores attribute((section(...))) for static variables inside templates

[bikineev at google dot com]

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

Bug ID: 94342
   Summary: GCC ignores attribute((section(...))) for static
variables inside templates
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bikineev at google dot com
  Target Milestone: ---

GCC ignores the section attribute for static variables declared inside
templates:

template
void Index(int i) { 
  static int VAR __attribute__((used,section("NEW_SECTION"))) = i; 
   
 }  

template void Index(int);

Objdump shows that the VAR symbol is still located in .bss (not NEW_SECTION):

objdump -tC result.o
...
 u O .bss._ZZ5IndexIiEviE3VAR   0004
Index(int)::VAR
...

Tested on gcc-9.2.1. Clang's behaviour is as expected.

[Bug target/94341] mve_mov can produce ICE on latest trunk

[matmal01 at gcc dot gnu.org]

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

Matthew Malcomson  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-03-26
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Matthew Malcomson  ---
Have already discussed bug privately and work is being done on it.

Just posting this so I have a public page for reference in public discussions.

[Bug target/94341] New: mve_mov can produce ICE on latest trunk

[matmal01 at gcc dot gnu.org]

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

Bug ID: 94341
   Summary: mve_mov can produce ICE on latest trunk
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: sripar01 at gcc dot gnu.org
  Reporter: matmal01 at gcc dot gnu.org
  Target Milestone: ---

The following code ICE's on fsf-trunk.

#include "arm_mve.h"

uint8x16_t test()
{
  uint8x16_t accum = (uint8x16_t)(uint32x4_t){0, 0, 0, 2};
  uint8x16_t accum2 = (uint8x16_t)(uint32x4_t){0, 0, 0, 1};
  accum += __arm_vddupq_m_n_u8 (accum2, 0, 4, (mve_pred16_t)1);
  return accum;
}


It ICE's because the first (define_insn "*mve_mov" ...)  pattern has the
following clause for it's 4th alternative:

case 4:
  if ((TARGET_HAVE_MVE_FLOAT && VALID_MVE_SF_MODE (mode))
  || (MEM_P (operands[1])
  && (GET_CODE (XEXP (operands[1], 0)) == LABEL_REF)))
return output_move_neon (operands);
  else
return "vldrb.8 %q0, %E1";



For the test above, we get an RTL pattern of

(insn 5 7 6 2 (set (reg:V16QI 28 s12 [116])
(mem:V16QI (const:SI (plus:SI (label_ref 28)
(const_int 16 [0x10]))) [0  S16 A64]))
"cde-mve-tests.c":6:12 2990 {*mve_movv16qi}
 (expr_list:REG_EQUIV (const_vector:V16QI [
(const_int 0 [0]) repeated x16
])
(nil)))


This matches the *mve_movv16qi pattern on the fourth alternative.
the clause above does not match for going into `output_move_neon` (since the
operand is not a mem of a label_ref, it's the mem of an offset to a label_ref).

Hence the compiler tries to emit "vldrb.8 %q0, %E1", but since the 'E' syntax
is for registers it does not match the RTL pattern for the operand.
This results in an ICE.


test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #1  @ movhi
movsr2, #0
vldr.64 d6, .L3
vldr.64 d7, .L3+8
during RTL pass: final
dump file: cde-mve-tests.c.314r.final
/home/matmal01/Documents/gnu-work/cde-intrinsics/cde-mve-tests.c: In function
'test':
/home/matmal01/Documents/gnu-work/cde-intrinsics/cde-mve-tests.c:9:1: internal
compiler error: in arm_print_operand, at config/arm/arm.c:23953
0x113c138 arm_print_operand
   
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/config/arm/arm.c:23953
0x9332c5 output_operand(rtx_def*, int)
   
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:4051
0x933b63 output_asm_insn(char const*, rtx_def**)
   
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:3944
0x9366b6 final_scan_insn_1
   
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:3106
0x9369a7 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
   
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:3152
0x9376ac final_1
   
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:2020
0x9378f6 rest_of_handle_final
   
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:4658
0x9378f6 execute
   
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
vldrb.8 q0, gcc [11:11:19] $

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed since r10-7344-gca6c722561ce9b9d

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #5 from Martin Liška  ---
Reduced test-case:
$ cat ada.ii
unsigned a;
void b()
{
  0 ? b(), -1 : a;
}

[Bug target/94220] libgcc FTB for ARM Thumb when optimizing for size

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Earnshaw  ---
Fixed

[Bug target/94220] libgcc FTB for ARM Thumb when optimizing for size

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

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

commit r10-7399-ge519d644999d04e0a341cb034f4d954963b1d2d2
Author: Richard Earnshaw 
Date:   Tue Mar 24 14:45:50 2020 +

arm: unified syntax for libgcc when built with -Os [PR94220]

The recent patch to convert all thumb1 code in libgcc to unified syntax
ommitted the conditional code that is used only when building the library
for minimal size.  This patch fixes this case.

I've also fixed the COND macro so that a single definition is always used
that is for unified syntax.  This eliminates a warning that is now being
seen from the assembler when compiling the ieee fp support code.

PR target/94220
* config/arm/lib1funcs.asm (COND): Use a single definition for
unified syntax.
(aeabi_uidivmod): Unified syntax when optimizing Thumb for size.
(aeabi_idivmod): Likewise.
(divsi3_skip_div0_test): Likewise.

[Bug debug/94340] [8/9/10 Regression] -fcompare-debug -O failure on cpp1z/nodiscard3.C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|9.4 |8.5
 CC||aoliva at gcc dot gnu.org
Summary|[9/10 Regression]   |[8/9/10 Regression]
   |-fcompare-debug -O failure  |-fcompare-debug -O failure
   |on cpp1z/nodiscard3.C   |on cpp1z/nodiscard3.C

--- Comment #2 from Jakub Jelinek  ---
Though, with
--- nodiscard3.C.jj 2020-01-21 04:33:32.0 -0500
+++ nodiscard3.C2020-03-26 06:35:24.0 -0400
@@ -195,7 +195,10 @@ test (void)
 return;
   if (check12 ().i)
 return;
-  if (({ check12 (); }).i)
+  if (
+  ({
+ check12 ();
+   }).i)
 return;
   check12 ();  /* { dg-warning "nodiscard" } */
   (void) check12 ();
change so that the different tokens are on different lines it started already
with the expected
r8-5241-g8697bf9f46f36168ddba5752db582e673e3cbe8c

[Bug debug/94340] [9/10 Regression] -fcompare-debug -O failure on cpp1z/nodiscard3.C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-26
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |9.4
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r9-3352-g87bd153645f393a1fe18e4fcd7f4323f83a8ac87 (which means it
has been latent before).

[Bug debug/94340] New: [9/10 Regression] -fcompare-debug -O failure on cpp1z/nodiscard3.C

[zhroma at gcc dot gnu.org]

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

Bug ID: 94340
   Summary: [9/10 Regression] -fcompare-debug -O failure on
cpp1z/nodiscard3.C
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhroma at gcc dot gnu.org
  Target Milestone: ---

This command:
gcc -c -fcompare-debug -O gcc/testsuite/g++.dg/cpp1z/nodiscard3.C

fails on master (r10-7374) and 9 branch on powerpc64le, works fine on current 8
branch.

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed since r10-7344-gca6c722561ce9b9d

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[10 regression] ICE in  |[10 regression] ICE in
   |tree_class_check_failed |tree_class_check_failed
   ||since
   ||r10-7344-gca6c722561ce9b9d
   Keywords|needs-bisection |needs-reduction
  Known to fail||10.0
  Known to work||9.3.0

--- Comment #4 from Martin Liška  ---
Started with r10-7344-gca6c722561ce9b9d.

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
I'm bisecting and reducing the test-case.

[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #8 from Martin Liška  ---
Yes, it's related to 

$ nm /home/marxin/bin/gcc/lib64/libasan.so.6 | grep report_file
001224e0 d _ZN11__sanitizer11report_fileE

$ nm /home/marxin/bin/gcc/lib64/libubsan.so.1 | grep report_file
000564e0 d _ZN11__sanitizer11report_fileE

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
Created attachment 48123
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48123=edit
ada-lang.ii.xz

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
   Last reconfirmed||2020-03-26
Version|unknown |10.0

--- Comment #1 from Richard Biener  ---
An easy fix would be to use if (TREE_OVERFLOW_P (result)) clearly the code
fails to check that result is INTEGER_CST.  Probably latent and only an
unrelated change changes the input to this function.

Testcase?

[Bug c++/94336] template keyword accepted before destructor names

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
EDG also accepts it, and clang 9.0.1 segfaults! clang 11 rejects it:

d.cc:1:50: error: unknown type name 'X'
template void f(T *p) { p->template ~X(); }
 ^
1 error generated.

[Bug lto/94320] [OpenMP][Offloading] lto1 ICE during IPA pass: inline – offline_size at gcc/ipa-inline-analysis.c:453

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #1)
> tried
> +  && !lto_stream_offload_p

With that patch, I get 6 times "has been referenced in offloaded code but
hasn't been marked to be included in the offloaded code".

Thus, that's a useful patch for the code I looked at. All those those functions
are template functions. (With -O0, the nvptx run-time compilers complains only
about 3 of those functions.)

> I'm afraid we need to actually implement properly the OpenMP 5.0
> automatic omp declare target discovery

Yes, it looks like that. I think C++ code is mostly affected as one quickly
ends up using 'operator[]' and similar functions, which are not always inlined.

Additionally, template programming makes it harder for the user to mark those
functions as 'declare target'.

[Bug debug/94323] [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’ failure since r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug driver/94330] No warning if jobserver not available

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-March/5
   ||42715.html
   Keywords||patch
   Target Milestone|--- |11.0

--- Comment #3 from Martin Liška  ---
I'm just sent the patch to the mailing list.

[Bug middle-end/94339] New: [10 regression] ICE in tree_class_check_failed

[clyon at gcc dot gnu.org]

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

Bug ID: 94339
   Summary: [10 regression] ICE in tree_class_check_failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

I've noticed this ICE while building GDB with recent GCC trunk, it appeared
between: r10-7336 and r10-7346

x86_64-unknown-linux-gnu-g++ -g -O2 -c ada-lang.ii 
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/binutils-gdb.git~gdb-8.3.1-release/gdb/ada-lang.c:
In function ‘char* ada_main_name()’:
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/binutils-gdb.git~gdb-8.3.1-release/gdb/ada-lang.c:934:386:
internal compiler error: tree check: expected class ‘constant’, have ‘unary’
(nop_expr) in warnings_for_convert_and_check, at c-family/c-warn.c:1378
  934 |   main_program_name_addr = BMSYMBOL_VALUE_ADDRESS (msym);
  |
   
   
   
 ^
0x604b15 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/tree.c:9763
0x9f8c69 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/tree.h:3401
0x9f8c69 warnings_for_convert_and_check(unsigned int, tree_node*, tree_node*,
tree_node*)
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/c-family/c-warn.c:1378
0x74330a cp_convert_and_check(tree_node*, tree_node*, int)
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/cvt.c:676
0x6b9c2e convert_like_real
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/call.c:7844
0x6bb3bb perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/call.c:11867
0x6c8794 perform_implicit_conversion(tree_node*, tree_node*, int)
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/call.c:11879
0x6c8794 build_conditional_expr_1
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/call.c:5642
0x6c90be build_conditional_expr(op_location_t const&, tree_node*, tree_node*,
tree_node*, int)
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/call.c:5705
0x9406f2 build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/typeck.c:6972
0x82a52a cp_parser_assignment_expression
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/parser.c:9828
0x82a7fc cp_parser_expression
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/parser.c:9992
0x8356ef cp_parser_primary_expression
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/parser.c:5359
0x84ec7d cp_parser_postfix_expression
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/parser.c:7219
0x831900 cp_parser_unary_expression
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/parser.c:8525
0x829312 cp_parser_cast_expression
   
/home/christophe.lyon/src/Linaro/abe/abe-master/mybuild/snapshots/gcc.git~master_rev_75fb811dfaa29d60a897924b0d1629577b90eee7/gcc/cp/parser.c:9416
0x829ddf cp_parser_simple_cast_expression
   

[Bug debug/94323] [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’ failure since r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7397-gda920d0c46c38fe25ee0b597a8698d3a4d098f3c
Author: Jakub Jelinek 
Date:   Thu Mar 26 10:35:52 2020 +0100

tree: Fix -fcompare-debug issues due to protected_set_expr_location
[PR94323]

The following testcase FAILs since recently when the C++ FE started calling
protected_set_expr_location more often.
With -g, it is called on a STATEMENT_LIST that contains a DEBUG_BEGIN_STMT
and CLEANUP_POINT_EXPR, and as STATEMENT_LISTs have !CAN_HAVE_LOCATION_P,
nothing is set.  Without -g, it is called instead on the CLEANUP_POINT_EXPR
directly and changes its location.

The following patch recurses on the single non-DEBUG_BEGIN_STMT statement
of a STATEMENT_LIST if any to make the two behave the same.

2020-03-26  Jakub Jelinek  

PR debug/94323
* tree.c (protected_set_expr_location): Recurse on STATEMENT_LIST
that contains exactly one non-DEBUG_BEGIN_STMT statement.

* g++.dg/debug/pr94323.C: New test.