[Bug c++/94490] New: Ternary expression with 3 consts is “not” a constant expression

[bisqwit at iki dot fi]

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

Bug ID: 94490
   Summary: Ternary expression with 3 consts is “not” a constant
expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

Versions tested: GCC 9.3.0, GCC 10.0.1 20200324 (experimental) [master revision
596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]

Error message:

test6.cc: In instantiation of ‘auto Mul(const T&, const T2&) [with T =
std::array; T2 = std::array]’:
test6.cc:20:58:   required from here
test6.cc:16:78: error: ‘(false ?  std::tuple_size_v > :
std::tuple_size_v >)’ is not a constant expression
   16 |  return typename arith_result::type {
std::get(vec) ... };
  |
 ^
test6.cc:20:6: error: ‘void x’ has incomplete type
   20 | auto x = Mul(std::array{}, std::array{});
  |  ^


Compiler is erroneously claiming that an expression of type (x ? y : z) where
all of x,y,z are constant expressions, is not a constant expression.



Code:

#include 
#include 

template, std::size_t
B=std::tuple_size_v, std::size_t N = std::min(A,B), class S =
std::make_index_sequence<(A>
struct arith_result
{
using type = std::conditional_t(std::index_sequence) ->
std::array...,
std::tuple_element_t...>, N>{}(S{})),
decltype([](std::index_sequence) ->
std::tuple,
std::tuple_element_t>...>{}(S{}))>;
};

template, typename T2 = T>
auto Mul(const T& vec, const T2& val)
{
return [&](std::index_sequence) {
 return typename arith_result::type { std::get(vec) ... };
} (std::make_index_sequence<2>{});
}

auto x = Mul(std::array{}, std::array{});


Note that if I replace the Mul function with this (inline the lambda call), the
problem goes away:

template, typename T2 = T>
auto Mul(const T& vec, const T2& val)
{
return typename arith_result::type {
std::get<0>(vec),std::get<1>(vec) };
}

Somehow the compiler forgets to do constant folding while it is processing the
lambda.

[Bug c++/94489] New: ICE: unexpected expression ‘std::min’ of kind overload

[bisqwit at iki dot fi]

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

Bug ID: 94489
   Summary: ICE: unexpected expression ‘std::min’ of kind overload
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

On GCC 9.3.0:

$ g++-9 test5.cc -std=c++2a -g -fconcepts
test5.cc: In instantiation of ‘auto Mul(const T&, const T2&) [with T =
std::array; T2 = std::array]’:
test5.cc:33:62:   required from here
test5.cc:28:117: internal compiler error: unexpected expression ‘std::min’ of
kind overload
   28 |  return typename arith_result::type {
std::plus(std::get(vec), std::get(val)) ... };
  |
^
0x7f78e300ce0a __libc_start_main
../csu/libc-start.c:308

On 10.0.1 20200324 (experimental) [master revision
596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]:

$ g++-10 test5.cc -std=c++20 -g
test5.cc: In instantiation of ‘auto Mul(const T&, const T2&) [with T =
std::array; T2 = std::array]’:
test5.cc:33:62:   required from here
test5.cc:28:117: internal compiler error: unexpected expression ‘std::min’ of
kind overload
   28 |  return typename arith_result::type {
std::plus(std::get(vec), std::get(val)) ... };
  |
^
0x63d82b cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:6301
0x637ded cxx_eval_call_expression
../../src/gcc/cp/constexpr.c:2055
0x63ad65 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:5483
0x63ccc2 cxx_eval_indirect_ref
../../src/gcc/cp/constexpr.c:4213
0x63ccc2 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:5704
0x63dbe0 cxx_eval_outermost_constant_expr
../../src/gcc/cp/constexpr.c:6502
0x63e5ec cxx_constant_value(tree_node*, tree_node*)
../../src/gcc/cp/constexpr.c:6659
0x733823 expand_integer_pack
../../src/gcc/cp/pt.c:3751
0x733823 expand_builtin_pack_call
../../src/gcc/cp/pt.c:3790
0x733823 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:12714
0x735561 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13078
0x73a678 tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13040
0x735534 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13090
0x7356e5 tsubst_aggr_type
../../src/gcc/cp/pt.c:13295
0x72c6f4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:20100
0x7304e4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:15745
0x7304e4 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15745
0x735466 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13092
0x7356e5 tsubst_aggr_type
../../src/gcc/cp/pt.c:13295
0x7307fe tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15633

Code is listed below.

#include 
#include 
#include 

template
concept IsTuple = requires(T t) { {std::get<0>(t) };} and
(std::tuple_size_v>-MinSz) <= (MaxSz-MinSz);

template,std::tuple_size_v),
 class seq = decltype(std::make_index_sequence{})>
struct arith_result
{
template
static auto t(std::index_sequence)
-> std::tuple,
std::tuple_element_t>...>;

template
static auto a(std::index_sequence)
-> std::array...,
std::tuple_element_t...>, dim>;

using type = std::conditional_t;
};

template, typename T2 = T>
auto Mul(const T& vec, const T2& val)
{
return [&](std::index_sequence) {
 return typename arith_result::type {
std::plus(std::get(vec), std::get(val)) ... };
}
(std::make_index_sequence>,

std::tuple_size_v>)>{});
}

auto x = Mul(std::array{}, std::array{});

[Bug c++/94415] Implement DR 2237: Can a template-id name a constructor?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Marek Polacek  ---
Patch posted:

[Bug c++/67825] [concepts] expression constraint bug when taking address of a member function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Actually fixed for GCC 10.

[Bug c++/91377] [8/9/10 Regression] ICE with non-static block scope constexpr, captured in lambda, used as template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #10 from Jason Merrill  ---
Fixed for 8.5/9.4/10.

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

[jason at gcc dot gnu.org]

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

Bug 67825 Summary: [concepts] expression constraint bug when taking address of 
a member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67825

   What|Removed |Added

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

[Bug c++/91966] [8 Regression] pack expansion for Cartesian product breaks if certain indirections are involved since r6-1487-g1a4cd2cd7e7266b0

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r8-10165-gc4f6911d39089c5f500977d9fc0e36c72f2018a7
Author: Jason Merrill 
Date:   Thu Apr 2 23:40:46 2020 -0400

c++: alias template and parameter packs (PR91966).

In this testcase, when we do a pack expansion of count_better_mins,
nums appears both in the definition of count_better_mins and as its
template
argument.  The intent is that we get a expansion over pairs of elements of
the pack, i.e. less<2,2>, less<2,7>, less<7,2>,   But if we substitute
into the definition of count_better_mins when parsing the template, we end
up with sum...>, which never gives us less<2,7>.  We could
deal with this by somehow marking up the use of 'nums' as an argument for
'num', but it's simpler to mark the alias as complex, so we need to
instantiate it later with all its arguments rather than replace it early
with its expansion.

gcc/cp/ChangeLog
2020-04-03  Jason Merrill  

PR c++/91966
* pt.c (complex_pack_expansion_r): New.
(complex_alias_template_p): Use it.

[Bug c++/91377] [8/9/10 Regression] ICE with non-static block scope constexpr, captured in lambda, used as template parameter

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r8-10166-ge42d142f421c132c3aca3a5b3f0176bd363d
Author: Jason Merrill 
Date:   Sat Apr 4 11:45:41 2020 -0400

c++: Mangling of dependent conversions [PR91377]

We skip over other conversion codes when mangling expressions, we should do
the same with IMPLICIT_CONV_EXPR.

gcc/cp/ChangeLog
2020-04-04  Jason Merrill  

PR c++/91377
* mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR.

[Bug c++/91377] [8/9/10 Regression] ICE with non-static block scope constexpr, captured in lambda, used as template parameter

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8453-gab525ec30f0a80e7a4b5e4d00010d83145b87e8c
Author: Jason Merrill 
Date:   Sat Apr 4 11:45:41 2020 -0400

c++: Mangling of dependent conversions [PR91377]

We skip over other conversion codes when mangling expressions, we should do
the same with IMPLICIT_CONV_EXPR.

gcc/cp/ChangeLog
2020-04-04  Jason Merrill  

PR c++/91377
* mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR.

[Bug c++/94453] [10 Regression] ICE in make_decl_rtl since r10-3591

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5ed8c71b53a5ac93c68179770cb047227b587bcb

commit r9-8452-g5ed8c71b53a5ac93c68179770cb047227b587bcb
Author: Jason Merrill 
Date:   Sat Apr 4 11:04:55 2020 -0400

c++: Fix reuse of class constants [PR94453]

The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached
from
the other lambda-expression.  This patch fixes this in two ways:

1) Avoid reusing a TARGET_EXPR from another function.
2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become
>>, which doesn't make any
sense.

gcc/cp/ChangeLog
2020-04-04  Jason Merrill  

PR c++/94453
* constexpr.c (maybe_constant_value): Use break_out_target_exprs.
* expr.c (mark_use) [VIEW_CONVERT_EXPR]: Don't wrap a TARGET_EXPR
in
NON_LVALUE_EXPR.

[Bug debug/94459] Missing c++ debug information for 'auto&' return type

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug debug/94459] Missing c++ debug information for 'auto&' return type

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:0be9efad938726721fd8c8c35609b1e1d7d30035

commit r10-7560-g0be9efad938726721fd8c8c35609b1e1d7d30035
Author: Jakub Jelinek 
Date:   Sun Apr 5 00:28:28 2020 +0200

debug: Improve debug info of c++14 deduced return type [PR94459]

On the following testcase, in gdb ptype S::m1 prints long as return
type, but all the other methods show void instead.
PR53756 added code to add_type_attribute if the return type is
auto/decltype(auto), but we actually should look through references,
pointers and qualifiers.
Haven't included there DW_TAG_atomic_type, because I think at least ATM
one can't use that in C++.  Not sure about DW_TAG_array_type or what else
could be deduced.

> http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a
> decl-specifier.
>
> http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a
template
> argument can be deduced.
>
> Looks like you are missing arrays, pointers to members, and function
return
> types.

2020-04-04  Hannes Domani  
Jakub Jelinek  

PR debug/94459
* dwarf2out.c (gen_subprogram_die): Look through references,
pointers,
arrays, pointer-to-members, function types and qualifiers when
checking if in-class DIE had an 'auto' or 'decltype(auto)' return
type
to emit type again on definition.

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

Co-Authored-By: Hannes Domani 

[Bug target/94482] Inserting into vector with optimization enabled on x86 generates incorrect result

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Known to work||10.0
  Known to fail||8.4.1, 9.2.1
   Keywords||needs-bisection

--- Comment #4 from Uroš Bizjak  ---
Current mainline (gcc-10) works OK, possibly latent, needs bisection for
revision that fixed the failure.

[Bug target/94482] Inserting into vector with optimization enabled on x86 generates incorrect result

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Uroš Bizjak  ---
Confirmed, needs -m32 -mno-sse.

[Bug translation/90528] ICE caused b bad format string in gimple-ssa-warn-restrict.c:1803 for 'es' locale

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

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

--- Comment #1 from Sergei Trofimovich  ---
Was fixed for gcc-9.2.0:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a750cf5f4fe06781fee6c409591753b75ca98191

[Bug c++/91377] [8/9/10 Regression] ICE with non-static block scope constexpr, captured in lambda, used as template parameter

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:75c8d6e54a14d090853b998cfd335511b1d8ae5f

commit r10-7558-g75c8d6e54a14d090853b998cfd335511b1d8ae5f
Author: Jason Merrill 
Date:   Sat Apr 4 11:45:41 2020 -0400

c++: Mangling of dependent conversions [PR91377]

We skip over other conversion codes when mangling expressions, we should do
the same with IMPLICIT_CONV_EXPR.

gcc/cp/ChangeLog
2020-04-04  Jason Merrill  

PR c++/91377
* mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR.

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

[Jan Hubicka]

> Which ARM target has 16-bit int?
> I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
> BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
> 16-bit and int is 32-bit.

Hmm, you are right - I messed up target triplets. With arm-linux-gnueabi
I see 4 byte int and the testcase calls abort.
However it is still missed optimization.  I will check why we end up
with different code than x86 LTO.

Honza

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

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka  ---
> Which ARM target has 16-bit int?
> I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
> BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
> 16-bit and int is 32-bit.

Hmm, you are right - I messed up target triplets. With arm-linux-gnueabi
I see 4 byte int and the testcase calls abort.
However it is still missed optimization.  I will check why we end up
with different code than x86 LTO.

Honza

[Bug tree-optimization/94488] [AArch64] ICE from OpenMP SIMD right shift of uint64_t

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase, -O1 and higher:

typedef unsigned long V __attribute__((__vector_size__(16)));

V
foo (V x, unsigned long y)
{
  return x >> y;
}

[Bug ipa/94486] [10 regression] bootstrap build failure after r10-7552

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |10.0

--- Comment #1 from H.J. Lu  ---
Fixed by r10-7555

[Bug tree-optimization/94488] [AArch64] ICE from OpenMP SIMD right shift of uint64_t

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|rtl-optimization|tree-optimization
   Keywords||ice-on-valid-code
   Last reconfirmed||2020-04-04
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Self contained source:
#define a(b) __attribute__((__vector_size__(b)))
#define c(aa, ab, d) memcpy(aa, ab, d)
typedef __SIZE_TYPE__ size_t;
#define memcpy __builtin_memcpy
typedef unsigned long long uint64_t;
typedef struct {
  uint64_t e a(16);
} f;
f ae, af;
int g;
int l() {
  f aj, ak = af, al = ae;
  int k = al.e[0];
  _Pragma("omp simd") for (size_t i = 0; i < sizeof(aj) / sizeof(aj.e[0]); i++)
  aj.e[i] = ak.e[i] >> k;
  f j = aj;
  c(, , g);
  return g;
}

[Bug rtl-optimization/94488] New: [AArch64] ICE from OpenMP SIMD right shift of uint64_t

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

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

Bug ID: 94488
   Summary: [AArch64] ICE from OpenMP SIMD right shift of uint64_t
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Created attachment 48199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48199=edit
Test case

On AArch64 with optimizations enabled (-O1 is enough), attempting to
right-shift an unsigned 64-bit value in an OpenMP SIMD loop generates an
internal compiler error.

This happens on at least GCC 9 and 10, and I've tried it cross-compiling to
AArch64 and natively (on a Raspberry Pi running Fedora 31 with gcc 9.3.1).

I'm attaching a test case.  Here is the full output from attempting to compile
it with `aarch64-linux-gnu-gcc-10 -v -fopenmp-simd -O2 -c -o test.o srl.c`:

Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc-10
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10-20200324-1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --without-target-system-zlib
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=aarch64-linux-gnu --program-prefix=aarch64-linux-gnu-
--includedir=/usr/aarch64-linux-gnu/include
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200324 (experimental) [master revision
596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536] (Debian
10-20200324-1) 
COLLECT_GCC_OPTIONS='-v' '-fopenmp-simd' '-O2' '-c' '-o' 'test.o'
'-mlittle-endian' '-mabi=lp64'
 /usr/lib/gcc-cross/aarch64-linux-gnu/10/cc1 -quiet -v -imultiarch
aarch64-linux-gnu srl.c -quiet -dumpbase srl.c -mlittle-endian -mabi=lp64
-auxbase-strip test.o -O2 -version -fopenmp-simd -fasynchronous-unwind-tables
-o /tmp/ccGROOBh.s
GNU C17 (Debian 10-20200324-1) version 10.0.1 20200324 (experimental) [master
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]
(aarch64-linux-gnu)
compiled by GNU C version 10.0.1 20200324 (experimental) [master
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536], GMP
version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version
isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/aarch64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-cross/aarch64-linux-gnu/10/include-fixed"
ignoring nonexistent directory "/usr/include/aarch64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-cross/aarch64-linux-gnu/10/include
 /usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/include
 /usr/include
End of search list.
GNU C17 (Debian 10-20200324-1) version 10.0.1 20200324 (experimental) [master
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]
(aarch64-linux-gnu)
compiled by GNU C version 10.0.1 20200324 (experimental) [master
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536], GMP
version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version
isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b59507ef9cd435e859f115f5f55f1a57
during RTL pass: expand
srl.c: In function ‘l’:
srl.c:14:15: internal compiler error: in expand_shift_1, at expmed.c:2654
   14 |   aj.e[i] = ak.e[i] >> k;
  |   ^~
0x613d01 expand_shift_1
../../src/gcc/expmed.c:2654
0x83dce5 expand_variable_shift(tree_code, machine_mode, rtx_def*, tree_node*,
rtx_def*, int)
../../src/gcc/expmed.c:2695
0x85053b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../src/gcc/expr.c:9477
0x85725d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:10049
0x864dc1 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../src/gcc/expr.c:8353
0x864dc1 expand_normal
../../src/gcc/expr.h:288
0x864dc1 store_field
../../src/gcc/expr.c:7097
0x86178e expand_assignment(tree_node*, tree_node*, bool)
   

[Bug target/94482] Inserting into vector with optimization enabled on x86 generates incorrect result

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

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

--- Comment #2 from Evan Nemerson  ---
Created attachment 48195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48195=edit
Output from cc -v

Sure.  It's just -O2, and of course if you're on x86_64 you'll need to pass
-m32.  For example:

  cc -m32 -O2 -o 94482 94482.c

I've attached the output when adding -v.

If you drop either -m32 or -O2 from the flags, the program runs successfully. 
Otherwise, you'll get an assertion failure:

  94482: 94482.c:46: main: Assertion `r_.i64[0] == 1729' failed.
  Aborted (core dumped)

[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398

[pinskia at gcc dot gnu.org]

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

--- Comment #68 from Andrew Pinski  ---
(In reply to rsand...@gcc.gnu.org from comment #62)
> For the two bfi ones: are we really sure that the old code is better?
> It's a difference between a MOV and a BFI or an AND and an ORR.
> The BFI wins (at least for code-size) if we need the same MOV
> for something else.  But the AND/ORR sequence wins in high register
> pressure, since it only needs one register rather than two.

On some processors (ThunderX2 and OcteonTX2 and maybe others [I have not looked
into all of the micro-arches there are]), the mov/bfi case is most likely
better as the mov is removed during renaming phase and not actually issued so
it will turn into just one instruction in a latency of 1 rather than 2
instructions and latency of 2.

[Bug ipa/94486] New: [10 regression] bootstrap build failure after r10-7552

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 94486
   Summary: [10 regression] bootstrap build failure after r10-7552
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g: 2523d721cfc861a3abea6e97736446c99ba8b52d, r10-7552 

/home/seurer/gcc/git/build/gcc-test2/./prev-gcc/xg++
-B/home/seurer/gcc/git/build/gcc-test2/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-test2/powerpc64le-unknown-linux-gnu/bin/
-nostdinc++
-B/home/seurer/gcc/git/build/gcc-test2/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test2/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/seurer/gcc/git/build/gcc-test2/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home/seurer/gcc/git/build/gcc-test2/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/libsupc++
-L/home/seurer/gcc/git/build/gcc-test2/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test2/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/home/seurer/gcc/git/gcc-test2/gcc -I/home/seurer/gcc/git/gcc-test2/gcc/.
-I/home/seurer/gcc/git/gcc-test2/gcc/../include
-I/home/seurer/gcc/git/gcc-test2/gcc/../libcpp/include
-I/home/seurer/gcc/git/build/gcc-test2/./gmp
-I/home/seurer/gcc/git/gcc-test2/gmp
-I/home/seurer/gcc/git/build/gcc-test2/./mpfr/src
-I/home/seurer/gcc/git/gcc-test2/mpfr/src
-I/home/seurer/gcc/git/gcc-test2/mpc/src 
-I/home/seurer/gcc/git/gcc-test2/gcc/../libdecnumber
-I/home/seurer/gcc/git/gcc-test2/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/seurer/gcc/git/gcc-test2/gcc/../libbacktrace
-I/home/seurer/gcc/git/build/gcc-test2/./isl/include
-I/home/seurer/gcc/git/gcc-test2/isl/include  -o ipa-fnsummary.o -MT
ipa-fnsummary.o -MMD -MP -MF ./.deps/ipa-fnsummary.TPo
/home/seurer/gcc/git/gcc-test2/gcc/ipa-fnsummary.c
/home/seurer/gcc/git/gcc-test2/gcc/ipa-fnsummary.c:526:1: error: 'bool
fre_will_run_p(cgraph_node*)' defined but not used [-Werror=unused-function]
  526 | fre_will_run_p (struct cgraph_node *node)
  | ^~
cc1plus: all warnings being treated as errors

[Bug c++/94205] [8/9 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |cxx_eval_constant_expressio |cxx_eval_constant_expressio
   |n with 'this'-capturing |n with 'this'-capturing
   |lambda inside an NSDMI  |lambda inside an NSDMI
   |since r8-1251   |since r8-1251

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 10 so far.

[Bug c++/94219] ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 10.

[Bug c++/94205] [8/9/10 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251

[ppalka at gcc dot gnu.org]

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

Bug 94219 Summary: ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94219

   What|Removed |Added

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

[Bug c++/94205] [8/9/10 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:49a86fce1a879a206fb4b27f097910005d968fda

commit r10-7557-g49a86fce1a879a206fb4b27f097910005d968fda
Author: Patrick Palka 
Date:   Thu Apr 2 16:03:18 2020 -0400

c++: Refrain from using replace_placeholders in constexpr evaluation
[PR94205]

This removes the use of replace_placeholders in
cxx_eval_constant_expression
(which is causing the new test lambda-this6.C to ICE due to
replace_placeholders
mutating the shared TARGET_EXPR_INITIAL tree which then trips up the
gimplifier).

In its place, this patch adds a 'parent' field to constexpr_ctx which is
used to
store a pointer to an outer constexpr_ctx that refers to another object
under
construction.  With this new field, we can beef up lookup_placeholder to
resolve
PLACEHOLDER_EXPRs which refer to former objects under construction, which
fixes
PR94205 without needing to do replace_placeholders.  Also we can now
respect the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag when resolving PLACEHOLDER_EXPRs, and
doing so fixes the constexpr analogue of PR79937.

gcc/cp/ChangeLog:

PR c++/94205
PR c++/79937
* constexpr.c (struct constexpr_ctx): New field 'parent'.
(cxx_eval_bare_aggregate): Propagate
CONSTRUCTOR_PLACEHOLDER_BOUNDARY
flag from the original constructor to the reduced constructor.
(lookup_placeholder): Prefer to return the outermost matching
object
by recursively calling lookup_placeholder on the 'parent' context,
but don't cross CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors.
(cxx_eval_constant_expression): Link the 'ctx' context to the
'new_ctx'
context via 'new_ctx.parent' when being expanded without an
explicit
target.  Don't call replace_placeholders.
(cxx_eval_outermost_constant_expr): Initialize 'ctx.parent' to
NULL.

gcc/testsuite/ChangeLog:

PR c++/94205
PR c++/79937
* g++.dg/cpp1y/pr79937-5.C: New test.
* g++.dg/cpp1z/lambda-this6.C: New test.

[Bug c++/94205] [8/9/10 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:37244b217a7329792f4ec48027f63cf5010b0ea8

commit r10-7556-g37244b217a7329792f4ec48027f63cf5010b0ea8
Author: Patrick Palka 
Date:   Thu Apr 2 12:59:34 2020 -0400

c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression
do
not anticipate that a constructor element's initializer could mutate the
underlying CONSTRUCTOR.  Evaluation of the initializer could add new
elements to
the underlying CONSTRUCTOR, thereby potentially invalidating any pointers
to
or assumptions about the CONSTRUCTOR's elements, and so these routines
should be
prepared for that.

To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the constructor_elt pointers through
which
we're assigning, after it evaluates the initializer.  Care is taken to to
not
slow down the common case where the initializer does not modify the
underlying
CONSTRUCTOR.

gcc/cp/ChangeLog:

PR c++/94219
PR c++/94205
* constexpr.c (get_or_insert_ctor_field): Split out (while adding
support for VECTOR_TYPEs, and optimizations for the common case)
from ...
(cxx_eval_store_expression): ... here.  Rename local variable
'changed_active_union_member_p' to 'activated_union_member_p'. 
Record
the sequence of indexes into 'indexes' that yields the subobject
we're
assigning to.  Record the integer offsets of the constructor
indexes
we're assigning through into 'index_pos_hints'.  After evaluating
the
initializer of the store expression, recompute 'valp' using
'indexes'
and using 'index_pos_hints' as hints.
(cxx_eval_bare_aggregate): Tweak comments.  Use
get_or_insert_ctor_field
to recompute the constructor_elt pointer we're assigning through
after
evaluating each initializer.

gcc/testsuite/ChangeLog:

PR c++/94219
PR c++/94205
* g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
* g++.dg/cpp1z/lambda-this5.C: New test.

[Bug c++/94219] ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:37244b217a7329792f4ec48027f63cf5010b0ea8

commit r10-7556-g37244b217a7329792f4ec48027f63cf5010b0ea8
Author: Patrick Palka 
Date:   Thu Apr 2 12:59:34 2020 -0400

c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression
do
not anticipate that a constructor element's initializer could mutate the
underlying CONSTRUCTOR.  Evaluation of the initializer could add new
elements to
the underlying CONSTRUCTOR, thereby potentially invalidating any pointers
to
or assumptions about the CONSTRUCTOR's elements, and so these routines
should be
prepared for that.

To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the constructor_elt pointers through
which
we're assigning, after it evaluates the initializer.  Care is taken to to
not
slow down the common case where the initializer does not modify the
underlying
CONSTRUCTOR.

gcc/cp/ChangeLog:

PR c++/94219
PR c++/94205
* constexpr.c (get_or_insert_ctor_field): Split out (while adding
support for VECTOR_TYPEs, and optimizations for the common case)
from ...
(cxx_eval_store_expression): ... here.  Rename local variable
'changed_active_union_member_p' to 'activated_union_member_p'. 
Record
the sequence of indexes into 'indexes' that yields the subobject
we're
assigning to.  Record the integer offsets of the constructor
indexes
we're assigning through into 'index_pos_hints'.  After evaluating
the
initializer of the store expression, recompute 'valp' using
'indexes'
and using 'index_pos_hints' as hints.
(cxx_eval_bare_aggregate): Tweak comments.  Use
get_or_insert_ctor_field
to recompute the constructor_elt pointer we're assigning through
after
evaluating each initializer.

gcc/testsuite/ChangeLog:

PR c++/94219
PR c++/94205
* g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
* g++.dg/cpp1z/lambda-this5.C: New test.

[Bug c++/79937] [7 Regression] ICE in replace_placeholders_r

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:49a86fce1a879a206fb4b27f097910005d968fda

commit r10-7557-g49a86fce1a879a206fb4b27f097910005d968fda
Author: Patrick Palka 
Date:   Thu Apr 2 16:03:18 2020 -0400

c++: Refrain from using replace_placeholders in constexpr evaluation
[PR94205]

This removes the use of replace_placeholders in
cxx_eval_constant_expression
(which is causing the new test lambda-this6.C to ICE due to
replace_placeholders
mutating the shared TARGET_EXPR_INITIAL tree which then trips up the
gimplifier).

In its place, this patch adds a 'parent' field to constexpr_ctx which is
used to
store a pointer to an outer constexpr_ctx that refers to another object
under
construction.  With this new field, we can beef up lookup_placeholder to
resolve
PLACEHOLDER_EXPRs which refer to former objects under construction, which
fixes
PR94205 without needing to do replace_placeholders.  Also we can now
respect the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag when resolving PLACEHOLDER_EXPRs, and
doing so fixes the constexpr analogue of PR79937.

gcc/cp/ChangeLog:

PR c++/94205
PR c++/79937
* constexpr.c (struct constexpr_ctx): New field 'parent'.
(cxx_eval_bare_aggregate): Propagate
CONSTRUCTOR_PLACEHOLDER_BOUNDARY
flag from the original constructor to the reduced constructor.
(lookup_placeholder): Prefer to return the outermost matching
object
by recursively calling lookup_placeholder on the 'parent' context,
but don't cross CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors.
(cxx_eval_constant_expression): Link the 'ctx' context to the
'new_ctx'
context via 'new_ctx.parent' when being expanded without an
explicit
target.  Don't call replace_placeholders.
(cxx_eval_outermost_constant_expr): Initialize 'ctx.parent' to
NULL.

gcc/testsuite/ChangeLog:

PR c++/94205
PR c++/79937
* g++.dg/cpp1y/pr79937-5.C: New test.
* g++.dg/cpp1z/lambda-this6.C: New test.

[Bug c++/94205] [8/9/10 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Patrick is working on the remaining parts of this bug.

[Bug ipa/93940] [8/9 Regression] crazy codegen bug on Og with builtin_constant_p, coverage, and pthread

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:21e28527130a89491f848dfb5019afa01b252479

commit r10-7555-g21e28527130a89491f848dfb5019afa01b252479
Author: Jan Hubicka 
Date:   Sat Apr 4 15:56:52 2020 +0200

Fix previous commit.

gcc/ChangeLog:

2020-04-04  Jan Hubicka  

PR ipa/93940
* ipa-fnsummary.c (vrp_will_run_p): New function.
(fre_will_run_p): New function.
(evaluate_properties_for_edge): Use it.
* ipa-inline.c (can_inline_edge_by_limits_p): Do not inline
!optimize_debug to optimize_debug.

gcc/testsuite/ChangeLog:

2020-04-04  Jan Hubicka  

* g++.dg/tree-ssa/pr93940.C: New test.

[Bug c++/94485] [10.0.1, c++2a] g++ optimizes away necessary code, accepts arbitrary inline asm

[dimitri.gorokhovik at free dot fr]

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

--- Comment #4 from Dimitri Gorokhovik  ---
To be clear, the braces here:

 outer_ = { tess_.begin () };

are the leftover of the simplification. Plain assignment also gets removed,
only it is slightly harder to reproduce (-O3 only).

[Bug c++/94485] [10.0.1, c++2a] g++ optimizes away necessary code, accepts arbitrary inline asm

[dimitri.gorokhovik at free dot fr]

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

--- Comment #3 from Dimitri Gorokhovik  ---
(In reply to Andrew Pinski from comment #2)
> Also c++20 changes constexpr is handled which is why inline asm is accepted
> now IIRC.

This code:

constexpr auto f()
{
  asm("before:");
  constexpr auto r = 129;
  asm("after:");

  return r;
};

produces:
bug-2.cpp: In function ‘constexpr auto f()’:
bug-2.cpp:3:3: error: inline assembly is not a constant expression
3 |   asm("before:");
  |   ^~~
bug-2.cpp:3:3: note: only unevaluated inline assembly is allowed in a
‘constexpr’ function in C++2a

[Bug c++/94485] [10.0.1, c++2a] g++ optimizes away necessary code, accepts arbitrary inline asm

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Also c++20 changes constexpr is handled which is why inline asm is accepted now
IIRC.

[Bug c++/94485] [10.0.1, c++2a] g++ optimizes away necessary code, accepts arbitrary inline asm

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Without looking fully into this, it seems to me a variable is being used after
it goes out of scope.

[Bug c++/91377] [8/9/10 Regression] ICE with non-static block scope constexpr, captured in lambda, used as template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Further reduced:

struct f {
  static constexpr int d = 3;
  typedef int e;
};
template  struct x { };
template  using n = x;
template  auto v() -> n;
void af() { v(); }

[Bug c++/94485] New: [10.0.1, c++2a] g++ optimizes away the code, accepts arbitrary inline asm

[dimitri.gorokhovik at free dot fr]

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

Bug ID: 94485
   Summary: [10.0.1, c++2a] g++ optimizes away the code, accepts
arbitrary inline asm
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitri.gorokhovik at free dot fr
  Target Milestone: ---

Created attachment 48194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48194=edit
Sample code illustrating the sighting.

Version: gcc (GCC) 10.0.1 20200404 (experimental)

command line:
~/gcc-trunk/dist/bin/g++ -std=c++2a  -O3 -Wall -Wextra -W bug-202004041709.cpp
-o bug-1 && ./bug-1


The attached file (apologies, still big) contains the following code (line
425):

  constexpr iterator (tesselation const& me)
   : cube_ { me.cube_ },
 inner_ { me.as_parent ().begin () },
 tess_ {},
 outer_ { tess_ }
  {
   if (inner_)
   {
 tess_ = tesselation_of_two_cubes { cube_, *inner_ };
 asm("before:");
#if 0 // breaks only with -O3
 auto const tmp { tess_.begin () };
 asm("middle:");
 outer_ = tmp;
 
#else // breaks with -O3, -O1, fixes with -fsanitize=undefined|null
 outer_ = { tess_.begin () };
 
 asm("after:");
#endif
 inner_.next ();
 if (! outer_) throw 749;
   };
  };

(Minor remark: 'asm' statements in this constexpr method raise no brows. I
tried putting there insns that require evaluation, seems anything is silently
accepted. The same asm statements are rejected in a more simple constexpr
code.)

It seems, some optimization levels completely remove the highlighted assignment
so that 'throw 749' is executed (main() prints it then). Other passes keep the
copying code and produce expected result. This over-optimization can be fixed
by enabling certain sanitizers: undefined, null, vptr.

The asm code produced:

-- broken (compiled with -O3 or -O1):
#APP
# 425 "bug-1.cpp" 1
before:
# 0 "" 2
#NO_APP
movq%r12, 216(%rsp)
#APP
# 433 "bug-1.cpp" 1
after:
# 0 "" 2
#NO_APP

-- working (compiled with -O0 or -O1 or with -fsanitizer=null):
#APP
# 425 "bug-1.cpp" 1
before:
# 0 "" 2
#NO_APP
xorl%eax, %eax
cmpb$0, 43(%rbx)
movq%r14, 64(%rsp)
movw%ax, 72(%rsp)
movb$0, 74(%rsp)
je  .L73
cmpb$0, 63(%rbx)
je  .L73
cmpb$0, 83(%rbx)
sete%al
.L68:
movb%al, 75(%rsp)
movq64(%rsp), %rax
movdqa  64(%rsp), %xmm6
movq%rax, 88(%rbx)
movl72(%rsp), %eax
movaps  %xmm6, 96(%rsp)
movl%eax, 96(%rbx)
#APP
# 433 "bug-1.cpp" 1
after:
# 0 "" 2
#NO_APP

[Bug c++/94453] [10 Regression] ICE in make_decl_rtl since r10-3591

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/94453] [10 Regression] ICE in make_decl_rtl since r10-3591

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7553-g9f143008c73c60e02634d6b433139a035ef7bb65
Author: Jason Merrill 
Date:   Sat Apr 4 11:04:55 2020 -0400

c++: Fix reuse of class constants [PR94453]

The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached
from
the other lambda-expression.  This patch fixes this in two ways:

1) Avoid reusing a TARGET_EXPR from another function.
2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become
>>, which doesn't make any
sense.

gcc/cp/ChangeLog
2020-04-04  Jason Merrill  

PR c++/94453
* constexpr.c (maybe_constant_value): Use break_out_target_exprs.
* expr.c (mark_use) [VIEW_CONVERT_EXPR]: Don't wrap a TARGET_EXPR
in
NON_LVALUE_EXPR.

[Bug c++/67825] [concepts] expression constraint bug when taking address of a member function

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7554-gf1ad7bac76b662577e3bde78c530954099361a66
Author: Jason Merrill 
Date:   Sat Apr 4 11:04:55 2020 -0400

c++: Fix invalid pointer-to-member in requires [PR67825]

A recent change to cmcstl2 led to two tests failing due to this bug: our
valid expression checking in the context of a requires-expression wasn't
catching that an expression of member function type can only appear as the
function operand of a call expression.  Fixed by using convert_to_void to
do
the same checking as a discarded-value expression.

This patch also fixes 67825, which already had a testcase, but the testcase
was testing for the wrong behavior.

gcc/cp/ChangeLog
2020-04-04  Jason Merrill  

PR c++/67825
* constraint.cc (tsubst_valid_expression_requirement): Call
convert_to_void.

[Bug c++/94480] [10 Regression] ICE in cp_parser_abort_tentative_parse, at cp/parser.c:31858

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.0

[Bug c++/94481] [10 Regression] ICE: Segmentation fault (in cp_parser_placeholder_type_specifier)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 CC||jakub at gcc dot gnu.org

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
Which ARM target has 16-bit int?
I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
16-bit and int is 32-bit.

[Bug debug/94459] Missing c++ debug information for 'auto&' return type

[ssbssa at yahoo dot de]

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

--- Comment #5 from Hannes Domani  ---
I also should mention that this is a precursor to fix gdb_bug 24154:
https://sourceware.org/bugzilla/show_bug.cgi?id=24154

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

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
The problem is that on ARM sizeof (short) == sizeof (int)
and LTO will glob all short and int pointers together.  So this is missed
optimization only.

We do this globing sort of by design. For GCC11 I plan to refine type merging
again a bit but until then we could either xfail this testcase or change int to
long which is 4 bytes.

Not a release blocker though.

I would welcome if someone could test the testcase adjustment (I was doing LTO
by hand)

diff --git a/gcc/testsuite/g++.dg/lto/alias-4_0.C
b/gcc/testsuite/g++.dg/lto/alias-4_0.C
index 410c3140baf..0ab12adef5b 100644
--- a/gcc/testsuite/g++.dg/lto/alias-4_0.C
+++ b/gcc/testsuite/g++.dg/lto/alias-4_0.C
@@ -5,7 +5,7 @@ short *ptr_init, **ptr=_init;

 __attribute__ ((used))
 struct a {
-  int *aptr;
+  long *aptr;
 } a, *aptr=

 void

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

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
Note that to fully fix the problem we need to resolve the way aliases works.
In this case ODR violation makes one COMDAT section to contain only ctor, while
other contains ctor and its thunk.  The first COMDAT wins which makes the thunk
to call alias of a symbol prevailed by different COMDAT.
This still work w/o LTO and to immitate what happens in linker correctly
we need ability to load both constructors

https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542733.html

For invalid code like this that does not matter much, but the patch has also a
valid testcase.

I can also however patch around and silence the verifier ICE, but it would be
just symptomatic workaround

[Bug c++/94481] [10 Regression] ICE: Segmentation fault (in cp_parser_placeholder_type_specifier)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE: Segmentation fault (in |[10 Regression] ICE:
   |cp_parser_placeholder_type_ |Segmentation fault (in
   |specifier)  |cp_parser_placeholder_type_
   ||specifier)
   Last reconfirmed||2020-04-04
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-3735-gcb57504a55015891.

[Bug c++/94480] [10 Regression] ICE in cp_parser_abort_tentative_parse, at cp/parser.c:31858

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|ICE in  |[10 Regression] ICE in
   |cp_parser_abort_tentative_p |cp_parser_abort_tentative_p
   |arse, at cp/parser.c:31858  |arse, at cp/parser.c:31858
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2020-04-04
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-4424-g81a34a6b68184436.

[Bug ipa/93940] [8/9/10 Regression] crazy codegen bug on Og with builtin_constant_p, coverage, and pthread

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:2523d721cfc861a3abea6e97736446c99ba8b52d

commit r10-7552-g2523d721cfc861a3abea6e97736446c99ba8b52d
Author: Jan Hubicka 
Date:   Sat Apr 4 11:45:13 2020 +0200

ipa: Fix wrong code with failed propagation to builtin_constant_p [PR93940]

this patch fixes wrong code on a testcase where inline predicts
builtin_constant_p to be true but we fail to optimize its parameter to
constant
becuase FRE is not run and the value is passed by an aggregate.

This patch makes the inline predicates to disable aggregate tracking
when FRE is not going to be run and similarly value range when VRP is not
going to be run.

This is just partial fix.  Even with it we can arrange FRE/VRP to fail and
produce wrong code, unforutnately.

I think for GCC11 I will need to implement transformation in ipa-inline
but this is bit hard to do: predicates only tracks that value will be
constant
and do not track what constant to be.

Optimizing builtin_constant_p in a conditional is not going to do good job
when the value is used later in a place that expects it to be constant.
This is pre-existing problem that is not limited to inline tracking. For
example,
FRE may do the transofrm at one place but not in another due to alias
oracle
walking limits.

So I am not sure what full fix would be :(

gcc/ChangeLog:

2020-04-04  Jan Hubicka  

PR ipa/93940
* ipa-fnsummary.c (vrp_will_run_p): New function.
(fre_will_run_p): New function.
(evaluate_properties_for_edge): Use it.
* ipa-inline.c (can_inline_edge_by_limits_p): Do not inline
!optimize_debug to optimize_debug.

gcc/testsuite/ChangeLog:

2020-04-04  Jan Hubicka  

* g++.dg/tree-ssa/pr93940.C: New test.

[Bug c++/94483] [9/10 Regression] ICE: tree check: expected type_pack_expansion, have error_mark in add_capture, at cp/lambda.c:607

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[10 Regression] ICE: tree   |[9/10 Regression] ICE: tree
   |check: expected |check: expected
   |type_pack_expansion, have   |type_pack_expansion, have
   |error_mark in add_capture,  |error_mark in add_capture,
   |at cp/lambda.c:607  |at cp/lambda.c:607
   Last reconfirmed||2020-04-04
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r9-4041-g7de37c97b4031ba6.

[Bug c++/94484] ICE in cp_finish_decl, at cp/decl.c:7447

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug target/94482] Inserting into vector with optimization enabled on x86 generates incorrect result

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-04-04

--- Comment #1 from Martin Liška  ---
Can you please paste full command line used? And please with -v option, it will
show -march options.

[Bug c++/94484] ICE in cp_finish_decl, at cp/decl.c:7447

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

Summary|[10 Regression] ICE in  |ICE in cp_finish_decl, at
   |cp_finish_decl, at  |cp/decl.c:7447
   |cp/decl.c:7447  |

--- Comment #2 from Arseny Solokha  ---
Not a regression, then.

[Bug c++/94484] [10 Regression] ICE in cp_finish_decl, at cp/decl.c:7447

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This ICEs all the way to r6-2674-g971e17ff87337ad533b51c2dff0bbdf607fa1faf when
-fconcepts has been introduced.

[Bug ada/94419] accepting wrong programs because compiler error

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-04

--- Comment #1 from Eric Botcazou  ---
> Please, note Ada is not C, Ada is about safety. A program should be checked
> for corectness and any errors must be reported almost always, at runtime
> also. There are also cases when checks would be too hard to implement, but
> those cases are relatively rare, they ever need more arguments, than
> implementation complexity.

Well, GNAT passes 100% of the tests of the ACATS testsuites, which contain
thousands of correctness tests, so finding some bugs cannot be a pretext for
depreciating it as you do.  Every complex software has bugs, a compiler is a
complex software, ergo it has bugs.

You don't cite the clauses of the Ada RM that would make your program illegal
and you don't say which version of GNAT you use so there isn't much we can do.

> Another bad thing in GNAT is implementation of "mutable" records, they
> always need maximum memory. It is from GNAT manual:
> type Rec (D : Positive := 15) is record
>Name : String (1..D);
> end record;
> 
> Too_Large : Rec;
> 
> is flagged by the compiler with a warning: an attempt to create
> `Too_Large' will raise `Storage_Error', because the required size
> includes `Positive'Last' bytes.
> 
> It is bad. I think such records should be dynamically reallocatable. GNAT
> manual says that such way is improper, but it is not that, it is right.

No, it's just a trade off and GNAT has selected this implementation.  But you
can certainly write your own Ada compiler with another implementation.

[Bug rtl-optimization/94468] [10 Regression] ICE in remove_useless_values, at cselib.c:735 since r10-7515-g2c0fa3ecf70d199a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/94468] [10 Regression] ICE in remove_useless_values, at cselib.c:735 since r10-7515-g2c0fa3ecf70d199a

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7551-gbab8d9625f4cdeaf9bb45e28ab62abe47c3827f9
Author: Jakub Jelinek 
Date:   Sat Apr 4 10:32:41 2020 +0200

cselib: Don't consider SP_DERIVED_VALUE_P values as useless [PR94468]

The following testcase ICEs, because at one point we see the
SP_DERIVED_VALUE_P VALUE as useless (not PRESERVED_VALUE_P and no locs)
and so expect it to be discarded as useless.  But, later on we
are adding some new VALUE that is equivalent to it, and when adding
the equivalency that that new VALUE is equal to this SP_DERIVED_VALUE_P,
new_elt_loc_list has code for VALUE canonicalization and reverses addition
if uid is smaller, and at that point a new loc is added to the
SP_DERIVED_VALUE_P VALUE and it isn't discarded as useless anymore.
Now, I think we don't want to discard the SP_DERIVED_VALUE_P values
even if they have no locs, because they still have the special behaviour
that they then force other new VALUEs to be canonicalized against them,
which is what this patch implements.  I've not set PRESERVED_VALUE_P
on the SP_DERIVED_VALUE_P at the creation time, because whether a VALUE
is preserved or not is something that affects var-tracking decisions quite
a
lot and we shouldn't set it blindly on other VALUEs.

Or, to avoid the repetitive code, should I introduce
static bool
cselib_useless_value_p (cselib_val *v)
{
  return (v->locs == 0
  && !PRESERVED_VALUE_P (v->val_rtx)
  && !SP_DERIVED_VALUE_P (v->val_rtx)));
}
predicate and use it in those 6 spots?

2020-04-04  Jakub Jelinek  

PR rtl-optimization/94468
* cselib.c (references_value_p): Formatting fix.
(cselib_useless_value_p): New function.
(discard_useless_locs, discard_useless_values,
cselib_invalidate_regno_val, cselib_invalidate_mem,
cselib_record_set): Use it instead of
v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx).

* g++.dg/opt/pr94468.C: New test.

[Bug debug/94441] [10 Regression] g++: error: gcc/gcc/testsuite/g++.dg/cpp1z/constexpr-if2.C: ‘-fcompare-debug’ failure (length) since r10-7397-gda920d0c46c38fe2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/92086] Provide way to avoid saving callee-saved registers in functions without callers

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #7)
> This is related to the compiler saving the return address for noreturn
> sibcalls, like in
> 
>   void g(void) __attribute__((noreturn));
>   void f(void) { g(); }
> 
> Maybe we should have an option like "-fimprove-debugging-experience" that
> defaults to true only for -O0 and -Og (and maybe -O1)?

This was discussed in PR 10837.

[Bug c/92086] Provide way to avoid saving callee-saved registers in functions without callers

[gdisirio at gmail dot com]

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

Giovanni Di Sirio  changed:

   What|Removed |Added

 CC||gdisirio at gmail dot com

--- Comment #8 from Giovanni Di Sirio  ---
I would like to support the introduction of a "root" attribute, I can bring
several examples in embedded development where this would be beneficial:

1) Thread functions in an RTOS, callee-saved registers are just stealing
precious RAM for each thread.
2) Multiple main()-like functions in multi-core MCUs, each core has its own
entry function, saving registers is again wasting space.
3) Functions called by ASM veneers, for example ISR code called by a common ASM
entry-point.

Note that "naked" and "noreturn" attributes do not help in the above scenarios
for various reasons. I experienced all the above points while developing my
ChibiOS project.

I would suggest the following behavior:
- Root functions cannot be called by C code (warning).
- The "used" attribute is implicit for "root" functions.
- Parameters and return values would work as usual, just the callee-saved
registers stacking/unstacking is skipped.
- main() would have implicitly the "root" attribute.

[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #10 from Arseny Solokha  ---
I believe this PR can be closed.

[Bug debug/94441] [10 Regression] g++: error: gcc/gcc/testsuite/g++.dg/cpp1z/constexpr-if2.C: ‘-fcompare-debug’ failure (length) since r10-7397-gda920d0c46c38fe2

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7550-gaae5d08a8d4dcee576a85ea76febe56c53675ef2
Author: Jakub Jelinek 
Date:   Sat Apr 4 09:16:07 2020 +0200

c++: Fix further protected_set_expr_location related -fcompare-debug issues
[PR94441]

My recent protected_set_expr_location changes work well when
that function is called unconditionally, but as the testcase shows, the C++
FE has a few spots that do:
  if (!EXPR_HAS_LOCATION (stmt))
protected_set_expr_location (stmt, locus);
or similar.  Now, if we have for -g0 stmt of some expression that can
have location and has != UNKNOWN_LOCATION, while -g instead has
a STATEMENT_LIST containing some DEBUG_BEGIN_STMTs + that expression with
that location, we don't call protected_set_expr_location in the -g0 case,
but do call it in the -g case, because on the STATEMENT_LIST
!EXPR_HAS_LOCATION.
The following patch introduces a helper function which digs up the single
expression of a STATEMENT_LIST and uses that expression in the
EXPR_HAS_LOCATION check (plus changes protected_set_expr_location to
also use that helper).

Or do we want a further wrapper, perhaps C++ FE only, that would do this
protected_set_expr_location_if_unset (stmt, locus)?

2020-04-04  Jakub Jelinek  

PR debug/94441
* tree-iterator.h (expr_single): Declare.
* tree-iterator.c (expr_single): New function.
* tree.h (protected_set_expr_location_if_unset): Declare.
* tree.c (protected_set_expr_location): Use expr_single.
(protected_set_expr_location_if_unset): New function.

* parser.c (cp_parser_omp_for_loop): Use
protected_set_expr_location_if_unset.
* cp-gimplify.c (genericize_if_stmt, genericize_cp_loop): Likewise.

* g++.dg/opt/pr94441.C: New test.

[Bug c++/94484] New: [10 Regression] ICE in cp_finish_decl, at cp/decl.c:7447

[asolokha at gmx dot com]

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

Bug ID: 94484
   Summary: [10 Regression] ICE in cp_finish_decl, at
cp/decl.c:7447
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200329 snapshot (g:60c254b279e8e8443b8ad26cc46b9e4084cff66c)
ICEs when compiling the following testcase, extracted from
test/SemaTemplate/dependent-expr.cpp from the clang 10.0.0 test suite, w/
-fconcepts or -fconcepts-ts:

void i(auto a) {
  [](auto a, int = ({decltype(a) i; i * 2;})){}(a);
}

% g++-10.0.1 -fconcepts-ts -c bdtktvea.cpp
bdtktvea.cpp: In function 'void i(auto:1)':
bdtktvea.cpp:2:34: error: non-function 'i' declared as implicit template
2 |   [](auto a, int = ({decltype(a) i; i * 2;})){}(a);
  |  ^
bdtktvea.cpp:2:34: internal compiler error: in cp_finish_decl, at
cp/decl.c:7447
0x614650 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/decl.c:7447
0x9b878b cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:20909
0x998b56 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13731
0x99a8fa cp_parser_declaration_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13163
0x99b56f cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11469
0x99c4d8 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11835
0x99c5b8 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11785
0x99eed8 cp_parser_statement_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:4931
0x99eed8 cp_parser_primary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:5336
0x9a8487 cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:7257
0x98a669 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:9554
0x98c31e cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:9859
0x98b005 cp_parser_constant_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:10153
0x98b7a1 cp_parser_initializer_clause
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23218
0x98fe5f cp_parser_initializer
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23156
0x9b58d9 cp_parser_default_argument
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23037
0x9b58d9 cp_parser_parameter_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:22930
0x9b600a cp_parser_parameter_declaration_list
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:22587
0x9b641c cp_parser_parameter_declaration_clause
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:22514
0x9b6e5c cp_parser_lambda_declarator_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11047

[Bug c++/94483] New: [10 Regression] ICE: tree check: expected type_pack_expansion, have error_mark in add_capture, at cp/lambda.c:607

[asolokha at gmx dot com]

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

Bug ID: 94483
   Summary: [10 Regression] ICE: tree check: expected
type_pack_expansion, have error_mark in add_capture,
at cp/lambda.c:607
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200329 snapshot (g:60c254b279e8e8443b8ad26cc46b9e4084cff66c)
ICEs when compiling the following testcase, extracted from
test/CXX/temp/temp.decls/temp.variadic/init-capture.cpp from the clang 10.0.0
test suite, w/ -std=c++2a:

template constexpr auto x = [...z = a] (auto F) { return F(z...); };

% g++-10.0.1 -std=c++2a -c elqdcpvu.cpp
elqdcpvu.cpp:1:47: error: expansion pattern 'int' contains no parameter packs
1 | template constexpr auto x = [...z = a] (auto F) { return
F(z...); };
  |   ^
elqdcpvu.cpp:1:47: internal compiler error: tree check: expected
type_pack_expansion, have error_mark in add_capture, at cp/lambda.c:607
0x7bb258 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/tree.c:9737
0x62bdea tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/tree.h:3278
0x62bdea add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/lambda.c:607
0x99dad1 cp_parser_lambda_introducer
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:10928
0x99dad1 cp_parser_lambda_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:10530
0x99dad1 cp_parser_primary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:5413
0x9a8487 cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:7257
0x98a669 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:9554
0x98c31e cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:9859
0x98b005 cp_parser_constant_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:10153
0x98b7a1 cp_parser_initializer_clause
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23218
0x98fe5f cp_parser_initializer
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23156
0x9b8943 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:20850
0x9bf954 cp_parser_single_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:29479
0x9bfadc cp_parser_template_declaration_after_parameters
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:29051
0x9c0240 cp_parser_explicit_template_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:29317
0x9c3459 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13379
0x9c3a9f cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:4731
0x9c3a9f c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:43944
0xadbadb c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/c-family/c-opts.c:1186

[Bug c++/86594] Crash on trying to capture 'this' in instantiation of generic lambda

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
Just for the record, the only active branch where this ICE can be triggered is
gcc 8.

[Bug ipa/92981] ICE in get_partitioning_class, at symtab.c:1966

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
After looking through this with a debugger this seems odd to me:
if (alias && definition && !ultimate_alias_target ()->definition)

I'm not sure but after looking through it this seems to assume definition and
alias would be pointing  be true which does not seem to be the case with this
code and thus asserts here:
gcc_checking_assert (vnode->definition);

Seems this commit id,d3f2e41ea introduced it. Jan Hubicka are we certain
that definition and alias must both be true here as that does not appear 
to be the case for returning SYMBOL_EXTERNAL?