[Bug tree-optimization/105793] Missed vectorisation with conditional-select inside loop

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
Guess vectorizer expects something like

tmp1 = cond ? b : -b;
a_5 = a_4 + tmp1;

from ifcvt instead of current

  a_13 = b_10 + a_16;
  # DEBUG a => NULL
  _4 = b_10 < 1.0e+1;
  # DEBUG BEGIN_STMT
  a_12 = a_16 - b_10;
  # DEBUG a => NULL
  a_5 = _4 ? a_13 : a_12;

[Bug rtl-optimization/105799] New: Miss optimization to simplify (v + A) * B + C in rtl.

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 105799
   Summary: Miss optimization to simplify (v + A) * B + C in rtl.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

This case is from pr53533

int foo (int a)
{
  int tmp = a + 12345;
  tmp *= 914237;
  tmp += 12332;
  tmp *= 914237;
  tmp += 12332;
  tmp *= 914237;
  tmp -= 13;
  tmp *= 8000;
  return tmp;
}

with -O2, gcc generates

add edi, 12345
imuledi, edi, -1564285888
lea eax, [rdi-333519936]

llvm generates:

imuleax, edi, -1564285888
add eax, -1269844480

It looks like rtl simplifies (v * A + B ) * C -> AC * v + BC
but not (v + A) * B + C -> B * v + ABC.

[Bug target/105792] SPARC GCC 12.1.0 fails with internal compiler error: in expand_expr_real_2, at expr.cc:10160

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #3 from Sam James  ---
Might be related to bug 105292. Could you try gcc 12.1.1 (one of the snapshots,
ideally the latest)?

[Bug c++/105798] New: Add new -Wshadow for data member

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

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

Bug ID: 105798
   Summary: Add new -Wshadow for data member
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

While refactoring gdb -- changing a function to a method --
I accidentally introduced a self-assign, because the function
used local variables that had the same name as the class members.

gdb uses -Wshadow=local... I don't recall why but it seems like
it would be nice to have a level between 'local' and 'global'
so we could prevent locals from shadowing class members but
still not care about globals.

Test case:

struct x {
  int f;
  int y(int x) {
int f = x;
return f;
  }
};


This warns with -Wshadow but not -Wshadow=local.

[Bug c++/105797] [11/12/13 Regression] Internal compiler error: Segmentation fault ( fn_type_unification -> satisfaction_cache::satisfaction_cache -> iterative_hash_template_arg )

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

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

--- Comment #2 from Marek Polacek  ---
// PR c++/105797

namespace std {
template  struct integral_constant {
  static constexpr int value = __v;
};
template  struct decay { typedef _Tp type; };
template  using decay_t = typename decay<_Tp>::type;
template 
constexpr bool is_integral_v = integral_constant::value;
template 
concept integral = is_integral_v<_Tp>;
} // namespace std
template  struct AStruct { using value_type = int; };
template 
void fc1(AStruct v) requires
std::integral::value_type>;
template 
void fc2(AStruct v1, T2_) requires
std::integral::value_type>;
AStruct test_v1, test2_v;
int test_v2;
void test() { fc2(test_v1, test_v2); }
void test2() { fc1(test2_v); }

[Bug c++/56190] GCC fails deducing a "void(*)(int, float, double)" to a "void(*)(T..., float, double)" with T={int}

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

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

--- Comment #6 from Andrew Pinski  ---
Simplier example:
```
int func(int, char);

template
int testFunc(int (*)(TArgs..., char));

int x = testFunc(func);
```

[Bug c++/105797] [11/12/13 Regression] Internal compiler error: Segmentation fault ( fn_type_unification -> satisfaction_cache::satisfaction_cache -> iterative_hash_template_arg )

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Priority|P3  |P2
Summary|Internal compiler error:|[11/12/13 Regression]
   |Segmentation fault (|Internal compiler error:
   |fn_type_unification ->  |Segmentation fault (
   |satisfaction_cache::satisfa |fn_type_unification ->
   |ction_cache ->  |satisfaction_cache::satisfa
   |iterative_hash_template_arg |ction_cache ->
   |)   |iterative_hash_template_arg
   ||)
   Target Milestone|--- |11.4
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-05-31

--- Comment #1 from Marek Polacek  ---
Started with r11-4859-gd3fd75d8694800:

commit d3fd75d869480044213553000d2c9dc236a4f7af
Author: Patrick Palka 
Date:   Mon Nov 9 18:16:48 2020 -0500

c++: Consider only relevant template arguments in sat_hasher

[Bug c++/56190] GCC fails deducing a "void(*)(int, float, double)" to a "void(*)(T..., float, double)" with T={int}

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 105796 has been marked as a duplicate of this bug. ***

[Bug c++/105796] error: no matching function for call with variadic template function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 56190.

*** This bug has been marked as a duplicate of bug 56190 ***

[Bug c++/105796] error: no matching function for call with variadic template function

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-05-31
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Keywords||rejects-valid

--- Comment #1 from Marek Polacek  ---
Doesn't look like a regression.

[Bug c++/105797] New: Internal compiler error: Segmentation fault ( fn_type_unification -> satisfaction_cache::satisfaction_cache -> iterative_hash_template_arg )

[northon_patrick3 at yahoo dot ca via Gcc-bugs]

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

Bug ID: 105797
   Summary: Internal compiler error: Segmentation fault (
fn_type_unification ->
satisfaction_cache::satisfaction_cache ->
iterative_hash_template_arg )
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: northon_patrick3 at yahoo dot ca
  Target Milestone: ---

Created attachment 53061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53061&action=edit
Result from -freport-bug

The code:
```
#include 
#include 

template 
struct AStruct
{
using value_type = T_;
};

template 
constexpr auto fc1(AStruct v)
requires std::integral::value_type>
//requires std::integral
{ return v; }

template 
constexpr auto fc2(AStruct v1, AStruct v2)
requires std::integral::value_type>
{ return v1; }

void test(AStruct v1, AStruct v2)
{ fc2(v1, v2); }

void test2(AStruct v)
{ fc1(v); }
```


The command line:

```
g++ -std=c++20 test.cpp
```


The error:

```
test.cpp: In substitution of ‘template constexpr auto
fc1(AStruct) requires  integral::type::value_type> [with T_ = int]’:
test.cpp:25:7:   required from here
test.cpp:25:14: internal compiler error: Segmentation fault
   25 | { fc1(v); }
  |   ~~~^~~
0x1ac4724 internal_error(char const*, ...)
???:0
0x7f1693 iterative_hash_template_arg(tree_node*, unsigned int)
???:0
0x6bf9da satisfaction_cache::satisfaction_cache(tree_node*, tree_node*,
sat_info)
???:0
0x81bbd4 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x69d051 build_new_function_call(tree_node*, vec**, int)
???:0
0x836c31 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x7eaa63 c_parse_file()
???:0
0x914adb c_common_parse_file()
???:0
```


It happens from GCC 11.1 and onward to GCC 13 at commit
271072ca259dd285e7723d9bf6da7295e4090dfa.

GCC is configured with:

```
configure --prefix=/opt/pat-gcc --libdir=/opt/pat-gcc/lib
--libexecdir=/opt/pat-gcc/lib --enable-languages=c,c++,lto --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/opt/pat-gcc/include/dlang/gdc
```


If I comment out either one of test or test2 functions, it compiles. If I
change either one of the requires clause to use T_ or T1_ instead of decltype,
it compiles. If I change either one of fc1 or fc2 to use auto instead of a
template<> clause, it compiles. So it seem to crash at a very specific
condition.

[Bug c++/105796] New: error: no matching function for call with template function

[hiraditya at msn dot com via Gcc-bugs]

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

Bug ID: 105796
   Summary: error: no matching function for call with template
function
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

test.cpp
```
int func(int, char);

template
int testFunc(int (*)(TArgs..., char));

int x = testFunc(func);
```

With gcc trunk:
g++ -std=c++20 test.cpp -c


:6:22: error: no matching function for call to 'testFunc(int
(&)(int, char))'
6 | int x = testFunc(func);
  | ~^~
:4:5: note: candidate: 'template int testFunc(int
(*)(TArgs ..., char))'
4 | int testFunc(int (*)(TArgs..., char));
  | ^~~~
:4:5: note:   template argument deduction/substitution failed:
:6:22: note:   mismatched types 'char' and 'int'
6 | int x = testFunc(func);
  | ~^~
Compiler returned: 1

[Bug c++/105758] [12/13 Regression] ICE in build_baselink since r12-6897

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

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

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

https://gcc.gnu.org/g:4f84f12066953186cce4328b7f178d3daa2fe96e

commit r13-871-g4f84f12066953186cce4328b7f178d3daa2fe96e
Author: Patrick Palka 
Date:   Tue May 31 16:49:08 2022 -0400

c++: non-dep call with empty TYPE_BINFO [PR105758]

Here the out-of-line definition of Z::z causes duplicate_decls to
change z's type from using the primary template type Z (which is also
the type of the injected class name) to the implicit instantiation Z,
and this latter type lacks a TYPE_BINFO (although its TYPE_CANONICAL was
set by a special case in lookup_template_class to point to the former).

Later, when processing the non-dependent call z->foo(0), build_over_call
relies on the object argument's TYPE_BINFO to build the templated form
for this call, which fails because the object argument type has empty
TYPE_BINFO due to the above.

It seems weird that the implicit instantiation Z doesn't have the
same TYPE_BINFO as the primary template type Z, despite them being
proclaimed equivalent via TYPE_CANONICAL.  So I tried also setting
TYPE_BINFO in the special case in lookup_template_class, but that led to
some problems with constrained partial specializations of the form Z.
I'm not sure what, if anything, we ought to do about the subtle
differences between these two versions of the same type.

Fortunately it seems we don't need to rely on TYPE_BINFO at all in
build_over_call here -- the z_candidate struct already contains the
exact binfos we need to rebuild the BASELINK for the templated form.

PR c++/105758

gcc/cp/ChangeLog:

* call.cc (build_over_call): Use z_candidate::conversion_path
and ::access_path instead of TYPE_BINFO when building the
BASELINK for the templated form.

gcc/testsuite/ChangeLog:

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

[Bug c++/105794] Spurious "control reaches end of non-void function" warning with a combination of destructor, try/catch and if (true)

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

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

--- Comment #2 from Marek Polacek  ---
Probably the same issue:

struct C {
  ~C();
};
int foo() {
  C c;
  return 1;
  if (true)
;
}

[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/105794] Spurious "control reaches end of non-void function" warning with a combination of destructor, try/catch and if (true)

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-05-31
 CC||mpolacek at gcc dot gnu.org
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.2
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
Confirmed, started with r12-5638-ga3e75c1491cd2d

commit a3e75c1491cd2d501081210925a89a65b1c1e5e5
Author: Jason Merrill 
Date:   Thu Nov 25 10:50:59 2021 -0500

c++: don't fold away 'if' with constant condition

It changed:

--- 105794.ii.005t.original 2022-05-31 16:12:51.932479674 -0400
+++ 105794.ii.005t.original.1   2022-05-31 16:10:21.158400398 -0400
@@ -502,13 +502,16 @@ if (<>> >>>;
-  <;,
*(struct exception *) D.7348 = TARGET_EXPR >> ;>>;, __cxa_throw
(D.7348, (void *) &_ZTISt9exception, __dt_comp ); >>> >;
+}
 }
   finally
 {

[Bug c++/101803] CTAD fails for nested designated initializers

[h2+bugs at fsfe dot org via Gcc-bugs]

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

--- Comment #6 from Hannes Hauswedell  ---
Since it seems like 10.4 is around the corner... any chance this will make it?

Thanks a lot!

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

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

--- Comment #19 from Hannes Hauswedell  ---
Thanks a lot!

[Bug c++/102307] [10/11 Regression] internal compiler error: in reshape_init_r since r10-6388-ge98ebda074bf8fc5

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||10.3.1, 11.3.1

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

[Bug c++/102307] [10/11 Regression] internal compiler error: in reshape_init_r since r10-6388-ge98ebda074bf8fc5

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

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

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

https://gcc.gnu.org/g:3c10dc751e8670c7cc02a1b6db9abffb59d2fc42

commit r11-10042-g3c10dc751e8670c7cc02a1b6db9abffb59d2fc42
Author: Jason Merrill 
Date:   Tue Apr 26 11:15:04 2022 -0400

c++: constexpr ref to array of array [PR102307]

The problem here is that first check_initializer calls
build_aggr_init_full_exprs, which does overload resolution, but then in the
case of failed constexpr throws away the result and does it again in
build_functional_cast.  But in the first overload resolution,
reshape_init_array_1 decided to reuse the inner CONSTRUCTORs because
tf_error is set, so we know we're committed.  But the second pass gets
confused by the CONSTRUCTORs with non-init-list types.

Fixed by avoiding a second pass: instead, pass the call from
build_aggr_init
to build_cplus_new, which will turn it into a TARGET_EXPR.  I don't bother
to change the object argument because it will be replaced later in
simplify_aggr_init_expr.

PR c++/102307

gcc/cp/ChangeLog:

* decl.c (check_initializer): Use build_cplus_new in case of
constexpr failure.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-array2.C: New test.

[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/105655] [12 Regression] ICE on invalid deduction

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for 12.2/13.

[Bug c++/105623] [12/13 regression][rejects valid] invalid use of auto when deducing return type of base class template

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 12.2/13.

[Bug c++/105652] [12/13 Regression] ICE: in is_base_type, at dwarf2out.cc:13400 since r12-1937-gc28e1d288ab727de

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 12.2/13.

[Bug c++/105652] [12/13 Regression] ICE: in is_base_type, at dwarf2out.cc:13400 since r12-1937-gc28e1d288ab727de

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

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

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

https://gcc.gnu.org/g:102a1472ab393c89bd74c06ff92bef55fa61812c

commit r12-8443-g102a1472ab393c89bd74c06ff92bef55fa61812c
Author: Jason Merrill 
Date:   Thu May 26 22:43:05 2022 -0400

c++: lambda in concept [PR105652]

We currently check satisfaction in the context of the constrained
declaration (which may be wrong, see PR104111).  When checking C
for S, we currently substitute into the lambda in the context of
S (rather than S, which seems wrong if the above isn't wrong), so
the new closure type thinks its context is S, which confuses debug
output.  For the moment, let's work around all of this by overriding the
context of the closure.

PR c++/105652

gcc/cp/ChangeLog:

* pt.cc (tsubst_lambda_expr): Don't let a namespace-scope lambda
instantiate into a class-scope lambda.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda20.C: New test.

[Bug c++/105655] [12 Regression] ICE on invalid deduction

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

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

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

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

commit r12-8442-gd81be519fd6547654f1eda6976e95524db7d39b7
Author: Jason Merrill 
Date:   Wed May 25 12:38:58 2022 -0400

c++: CTAD with alias and nested template [PR105655]

Here, alias_ctad_tweaks expect tsubst_decl of a FUNCTION_DECL to return a
FUNCTION_DECL.  A reasonable expectation, but in this case we were
replacing
the template args of the class-scope deduction guide with equivalent args,
so looking in the hash table we found the partial instantiation stored when
instantiating A, which is a TEMPLATE_DECL.  It's fine for that to be
what is stored, but tsubst_function_decl should never return it.

PR c++/105655

gcc/cp/ChangeLog:

* pt.cc (build_template_decl): Add assert.
(tsubst_function_decl): Don't return a template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias13.C: New test.

[Bug c++/105623] [12/13 regression][rejects valid] invalid use of auto when deducing return type of base class template

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

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

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

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

commit r12-8441-gd90576952356735a2152c318ef1d60221b958b15
Author: Jason Merrill 
Date:   Tue May 24 17:37:58 2022 -0400

c++: deduction from auto fn [PR105623]

Since my patch for PR90451, we defer mark_used of single functions as late
as possible.  And since my r12-1273, we keep BASELINK from lookup around
rather than reconstruct it later.  These both made us try to instantiate g
with a function type that still had 'auto' as its return type.

PR c++/105623

gcc/cp/ChangeLog:

* decl2.cc (mark_used): Copy type from fn to BASELINK.
* pt.cc (unify_one_argument): Call mark_single_function.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/auto-fn62.C: New test.

[Bug c++/102307] [10/11/12 Regression] internal compiler error: in reshape_init_r since r10-6388-ge98ebda074bf8fc5

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

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

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

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

commit r12-8440-ga578b17b59651144a7b2737475d993184600a802
Author: Jason Merrill 
Date:   Tue Apr 26 11:15:04 2022 -0400

c++: constexpr ref to array of array [PR102307]

The problem here is that first check_initializer calls
build_aggr_init_full_exprs, which does overload resolution, but then in the
case of failed constexpr throws away the result and does it again in
build_functional_cast.  But in the first overload resolution,
reshape_init_array_1 decided to reuse the inner CONSTRUCTORs because
tf_error is set, so we know we're committed.  But the second pass gets
confused by the CONSTRUCTORs with non-init-list types.

Fixed by avoiding a second pass: instead, pass the call from
build_aggr_init
to build_cplus_new, which will turn it into a TARGET_EXPR.  I don't bother
to change the object argument because it will be replaced later in
simplify_aggr_init_expr.

PR c++/102307

gcc/cp/ChangeLog:

* decl.cc (check_initializer): Use build_cplus_new in case of
constexpr failure.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-array2.C: New test.

[Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|Concept evaluation depends  |[DR2589] Concept evaluation
   |on context where it was |depends on context where it
   |first checked   |was first checked

--- Comment #7 from Jason Merrill  ---
https://cplusplus.github.io/CWG/issues/2589.html

[Bug target/105778] Shift by register --- unnecessary AND instruction

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #4)
> It is the same thing done a few lines later in the preexisting code too.
> Shall I all of those change to gen_lowpart (QImode, force_reg (GET_MODE
> (operands[2]), operands[2])) then?

Yes, please. A "register_operand" predicate accepts SUBREGs of some strange
mode (usually FP mode) registers, and gen_lowpart chokes on these.

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #18 from Patrick Palka  ---
Now backported for 10.4/11.3.

[Bug libstdc++/101231] _CachedPosition::_M_get() should not return {} when range adapter does not model forward_range

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|12.0|10.4

[Bug libstdc++/101231] _CachedPosition::_M_get() should not return {} when range adapter does not model forward_range

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

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

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

https://gcc.gnu.org/g:656cd10436260de997f5202b6737c7b8aebdfb4f

commit r10-10809-g656cd10436260de997f5202b6737c7b8aebdfb4f
Author: Patrick Palka 
Date:   Fri Jul 16 09:44:42 2021 -0400

libstdc++: invalid default init in _CachedPosition [PR101231]

The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_value) are unreachable.

Still, to suppress a "control reaches end of non-void function" warning
I made _M_get return {}, but after P2325 input iterators are no longer
necessarily default constructible so this workaround now breaks valid
programs.

This patch fixes this by instead using __builtin_unreachable to squelch
the warning.

PR libstdc++/103904
PR libstdc++/101231

libstdc++-v3/ChangeLog:

* include/std/ranges (_CachedPosition::_M_get): For non-forward
ranges, just call __builtin_unreachable.
* testsuite/std/ranges/istream_view.cc (test05): New test.

(cherry picked from commit 1af937eb6246ad7f63ebff03590e9eede33aca81)

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

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

https://gcc.gnu.org/g:656cd10436260de997f5202b6737c7b8aebdfb4f

commit r10-10809-g656cd10436260de997f5202b6737c7b8aebdfb4f
Author: Patrick Palka 
Date:   Fri Jul 16 09:44:42 2021 -0400

libstdc++: invalid default init in _CachedPosition [PR101231]

The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_value) are unreachable.

Still, to suppress a "control reaches end of non-void function" warning
I made _M_get return {}, but after P2325 input iterators are no longer
necessarily default constructible so this workaround now breaks valid
programs.

This patch fixes this by instead using __builtin_unreachable to squelch
the warning.

PR libstdc++/103904
PR libstdc++/101231

libstdc++-v3/ChangeLog:

* include/std/ranges (_CachedPosition::_M_get): For non-forward
ranges, just call __builtin_unreachable.
* testsuite/std/ranges/istream_view.cc (test05): New test.

(cherry picked from commit 1af937eb6246ad7f63ebff03590e9eede33aca81)

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

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

https://gcc.gnu.org/g:22b86cdc4d7fddb4991a08515e47e66fe5c41def

commit r10-10808-g22b86cdc4d7fddb4991a08515e47e66fe5c41def
Author: Patrick Palka 
Date:   Tue May 31 14:38:11 2022 -0400

libstdc++: Implement P2325 changes to default-constructibility of views

NB: This backport of r12-1606 to the 10 branch deliberately omits parts
of P2325R3 so as to maximize backward compatibility with pre-P2325R3 code.
In particular, we don't remove the default ctors for back_insert_iterator,
front_insert_iterator, ostream_iterator, ref_view and basic_istream_view.
And in the 10 branch we we don't have __non_propagating_cache or the
partial specialization of __box, so the changes to them are omitted too.
Finally, we don't update __cpp_lib_ranges to 202106L because many
significant 202106 Ranges changes still aren't implemented in the 10
branch, e.g. P2281R1 and P2210R2.

===

This implements the wording changes of P2325R3 "Views should not be
required to be default constructible".  Changes are relatively
straightforward, besides perhaps those to __box (which now stands
for copyable-box instead of semiregular-box) and __non_propagating_cache.

For __box, this patch implements the recommended practice to also avoid
std::optional when the boxed type is nothrow_move/copy_constructible.

For __non_propagating_cache, now that it's used by split_view::_M_current,
we need to add assignment from a value of the underlying type to the
subset of the std::optional API implemented for the cache (needed by
split_view::begin()).  Hence the new __non_propagating_cache::operator=
overload.

In passing, this fixes the undesirable list-init in the constructors of
the partial specialization of __box as reported in PR100475 comment #7.

PR libstdc++/103904

libstdc++-v3/ChangeLog:

* include/bits/iterator_concepts.h (weakly_incrementable): Remove
default_initializable requirement.
* include/bits/stl_iterator.h (common_iterator): Constrain the
default ctor.
(counted_iterator): Likewise.
* include/std/ranges (ranges::view): Remove default_initializable
requirement.
(subrange): Constrain the default ctor.
(__detail::__box::operator=): Handle self-assignment.
(single_view): Constraint the default ctor.
(iota_view): Relax semiregular constraint to copyable.
Constrain the default ctor.
(iota_view::_Iterator): Constraint the default ctor.
(filter_view): Likewise.
(filter_view::_Iterator): Likewise.
(transform_view): Likewise.
(transform_view::_Iterator): Likewise.
(take_view): Likewise.
(take_view::_Iterator): Likewise.
(take_while_view): Likewise.
(take_while_view::_Iterator): Likewise.
(drop_while_view): Likewise.
(drop_while_view::_Iterator): Likewise.
(join_view): Likewise.
(split_view): Constrain the default ctor.
(common_view): Likewise.
(reverse_view): Likewise.
(elements_view): Likewise.
(elements_view::_Iterator): Likewise.
* include/std/span (enable_view>):
Define this partial specialization to true unconditionally.
* testsuite/std/ranges/p2325.cc: New test.
* testsuite/std/ranges/single_view.cc (test06): New test.
* testsuite/std/ranges/view.cc: Adjust now that view doesn't
require default_initializable.

(cherry picked from commit 4b4f5666b4c2f3aab2a9f3d53d394e390b9b682d)

[Bug objc/101718] Objective-C frontend emits wrong code to call methods returning scalar types returned in memory

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

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

--- Comment #7 from Iain Sandoe  ---
still needed on 11.x.

[Bug objc/101718] Objective-C frontend emits wrong code to call methods returning scalar types returned in memory

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:903c18c65c4eb135eb3c67a3c14fb6c20f537feb

commit r10-10807-g903c18c65c4eb135eb3c67a3c14fb6c20f537feb
Author: Iain Sandoe 
Date:   Mon Aug 16 21:22:13 2021 +0100

Objective-C, NeXT: Fix messenging non-aggregate return-in-memory.

When a method returns a type that the platform ABI says should be
returned in memory, and that is done by a hidden 'sret' parameter,
the message send calls must be adjusted to inform the runtime that
the sret parameter is present.  As reported in the PR, this is not
working for non-aggregate types that use this mechanism.  The fix
here is to adjust the logic such that all return values that flag
'in memory' are considered to use the mechanism *unless* they
provide a struct_value_rtx *and* the return object is an aggregate.

Signed-off-by: Iain Sandoe 

PR objc/101718 - Objective-C frontend emits wrong code to call methods
returning scalar types returned in memory

PR objc/101718

gcc/objc/ChangeLog:

* objc-next-runtime-abi-02.c (build_v2_build_objc_method_call):
Revise for cases where scalar objects use an sret parameter.
(next_runtime_abi_02_build_objc_method_call): Likwise.

(cherry picked from commit 1cef3039b880a21fbdf4153e6fc42026619fd4ad)

[Bug c++/105756] [12/13 Regression] ICE in cxx_eval_constant_expression at cp/constexpr.cc:7586: unexpected expression ‘ElemSize’ of kind template_parm_index

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug objc/97854] [11 regression] ODR violation in stub-objc.c

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

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

commit r10-10805-g5dd5507265e3b7fecd775a106a20762a5e828421
Author: Iain Sandoe 
Date:   Mon Nov 16 19:33:35 2020 +

C-family : Fix a C++ ODR violation [PR97854].

The changes in r11-4799 introduced a dummy enum rid type with
a different initial member name to the actual version (an ODR
violation).  Fixed by including the header declaring the
actual type.

gcc/c-family/ChangeLog:

PR objc/97854
* stub-objc.c: Include c-common.h to declare enum rid.

(cherry picked from commit 814e016318646d06b1662219cc716d502b76d8ce)

[Bug c++/105795] [11/12/13 Regression] Miscompilation with [[no_unique_address]]

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-05-31
 Status|UNCONFIRMED |NEW

[Bug c++/105795] [11/12/13 Regression] Miscompilation with [[no_unique_address]]

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |11.4
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
Summary|Miscompilation with |[11/12/13 Regression]
   |[[no_unique_address]]   |Miscompilation with
   ||[[no_unique_address]]
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
This changed with 

commit 2168bfb81448ae1bfa4351760a23d4ec051c2a00
Author: Jason Merrill 
Date:   Thu Jun 24 17:32:02 2021 -0400

c++: constexpr aggr init of empty class [PR101040]

[Bug c++/105795] New: Miscompilation with [[no_unique_address]]

[git at foonathan dot net via Gcc-bugs]

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

Bug ID: 105795
   Summary: Miscompilation with [[no_unique_address]]
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: git at foonathan dot net
  Target Milestone: ---

The following code should return 1:

```
struct empty
{};

template 
struct tuple_holder
{
[[no_unique_address]] T value;
};

struct tuple : tuple_holder, tuple_holder
{};

constexpr auto make_tuple(int&& i, empty&& e)
{
return tuple{i, e};
}

int main()
{
auto tuple = make_tuple(1, empty{});
return static_cast&>(tuple).value;
}
```

This is also the case with clang and GCC 11.1. However, starting with GCC 11.2,
the code returns 0 instead: https://godbolt.org/z/Gb6Kffnnc

[Bug d/105544] gdc fails to compile d source from stdin

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #14 from Iain Buclaw  ---
Committed patch posted here to mainline and backported to gcc-12.

[Bug d/105544] gdc fails to compile d source from stdin

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

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

commit r12-8439-gf106ef53024cc464ae446189fbad373caaff058e
Author: Iain Buclaw 
Date:   Tue May 31 14:45:02 2022 +0200

d: Fix D lexer sometimes fails to compile code read from stdin

As of gdc-12, the lexer expects there 4 bytes of zero padding at the end
of the source buffer to mark the end of input.  Sometimes when reading
from stdin, the data at the end of input is garbage rather than zeroes.
Fix that by explicitly calling memset past the end of the buffer.

PR d/105544

gcc/d/ChangeLog:

* d-lang.cc (d_parse_file): Zero padding past the end of the stdin
buffer so the D lexer has a sentinel to stop parsing at.

(cherry picked from commit a0bc7fd42136f124726985b1ab4dcde739cd260e)

[Bug d/105544] gdc fails to compile d source from stdin

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

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

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

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

commit r13-867-ga0bc7fd42136f124726985b1ab4dcde739cd260e
Author: Iain Buclaw 
Date:   Tue May 31 14:45:02 2022 +0200

d: Fix D lexer sometimes fails to compile code read from stdin

As of gdc-12, the lexer expects there 4 bytes of zero padding at the end
of the source buffer to mark the end of input.  Sometimes when reading
from stdin, the data at the end of input is garbage rather than zeroes.
Fix that by explicitly calling memset past the end of the buffer.

PR d/105544

gcc/d/ChangeLog:

* d-lang.cc (d_parse_file): Zero padding past the end of the stdin
buffer so the D lexer has a sentinel to stop parsing at.

[Bug fortran/105759] is_contiguous(zero_size_array(2:0)) wrongly returns .true.

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Tue, May 31, 2022 at 09:59:48AM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105759
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> JFTR: Cray and NAG also print T, so I guess this confirms Steve's analysis.
> 

I asked on Fortran Discourse.  Most answers, by non-compiler
developer, believe that the answer should be F.  I think gfortran
has it right; in particular, gfortran agrees with other implementations.

[Bug middle-end/105348] Overly aggressive -Warray-bounds after conditional

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #4 from Thiago Macieira  ---
One more Qt workaround, for the record:
https://codereview.qt-project.org/c/qt/qtbase/+/413730

[Bug middle-end/30314] optimize multiply-by-constant overflow (wrap) test

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
More like
--- gcc/match.pd.jj 2022-05-27 11:29:49.403465453 +0200
+++ gcc/match.pd2022-05-31 17:41:04.381972072 +0200
@@ -5969,6 +5969,17 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& (!TYPE_UNSIGNED (TREE_TYPE (@2)) || TYPE_UNSIGNED (TREE_TYPE (@0
(ovf @1 @0

+/* Optimize __builtin_mul_overflow_p (x, cst, (utype) 0) if all 3 types
+   are unsigned to x > (umax / cst).  */
+(simplify
+ (imagpart (IFN_MUL_OVERFLOW:cs@2 @0 integer_nonzerop@1))
+  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
+   && TYPE_UNSIGNED (TREE_TYPE (@0))
+   && TYPE_MAX_VALUE (TREE_TYPE (@0))
+   && types_match (TREE_TYPE (@0), TREE_TYPE (TREE_TYPE (@2)))
+   && int_fits_type_p (@1, TREE_TYPE (@0)))
+   (convert (gt @0 (trunc_div! { TYPE_MAX_VALUE (TREE_TYPE (@0)); } @1)
+
 /* Simplification of math builtins.  These rules must all be optimizations
as well as IL simplifications.  If there is a possibility that the new
form could be a pessimization, the rule should go in the canonicalization

[Bug c++/105794] New: Spurious "control reaches end of non-void function" warning with a combination of destructor, try/catch and if (true)

[kamil.sliwak at codepoets dot it via Gcc-bugs]

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

Bug ID: 105794
   Summary: Spurious "control reaches end of non-void function"
warning with a combination of destructor, try/catch
and if (true)
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kamil.sliwak at codepoets dot it
  Target Milestone: ---

After switching to GCC 12 I noticed that in several places in the C++ project
I'm working on I'm now getting the `control reaches end of non-void function`
warning. This seems like a regression since it's not happening with earlier GCC
versions or with latest Clang.

I managed to distill the problematic code into a small repro (see below) and
it's reproducible via https://godbolt.org so it does not seem dependent on my
specific environment.

The original code is more complicated but in the end a combination of three
things seems to be causing this:
1. A variable of a custom class type that has an explicitly defined destructor
(which can be empty though).
2. A try/catch block with a return.
3. A `throw` wrapped in a condition that's a compile-time constant.

Removing any of the above makes the warning go away.

### Environment
- GCC version: 12.1.0
- System: Arch Linux

### Repro
 Command
```
g++ test.cpp
```

 `test.cpp`
```
#include 

class C {
public:
~C() {}
};

int foo()
{
C c;

try
{
return 1;
}
catch (std::exception const&)
{
}

if (true)
throw std::exception();
}

int main() {
return 0;
}
```

 Output
```
test.cpp: In function ‘int foo()’:
test.cpp:22:1: warning: control reaches end of non-void function
[-Wreturn-type]
   22 | }
  | ^
```

[Bug tree-optimization/105786] ICE in compute_distributive_range, at tree-data-ref.cc:593

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

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

Alex Coplan  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-31
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Known to fail||13.0
 CC||acoplan at gcc dot gnu.org

--- Comment #1 from Alex Coplan  ---
Confirmed on trunk (on aarch64). I see:

t.c: In function ‘main’:
t.c:3:5: error: invalid (pointer) operands ‘plus_expr’
3 | int main() {
  | ^~~~
_5 = _23 + 1B;
during GIMPLE pass: ldist
t.c:3:5: internal compiler error: verify_gimple failed
0xeef45f verify_gimple_in_cfg(function*, bool)
/home/alecop01/toolchain/src/gcc/gcc/tree-cfg.cc:5551
0xd79b3b execute_function_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.cc:2085
0xd7a6ab execute_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.cc:2139
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/88414] [9 Regression] ICE in lra_assign, at lra-assigns.c:1624

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #7 from Iain Sandoe  ---
On 10.x and 9.x with checking enabled

The test case for this produces the following output for i686-apple-darwin9
(actually any Darwin N from 9 - 17).

/src-local/gcc-master/gcc/testsuite/gcc.target/i386/pr88414.c:15:7: error:
‘asm’ operand has impossible constraints
   15 |   asm volatile ("" : "=d" (b), "=d" (c) : "r" (y[j]), "d" (w)); /*
{ dg-error "'asm' operand has impossible constraints" } */
  |   ^~~
during RTL pass: reload
/src-local/gcc-master/gcc/testsuite/gcc.target/i386/pr88414.c:25:1: internal
compiler error: maximum number of LRA assignment passes is achieved (30)
   25 | }
  | ^

** when checking is disabled (i.e. set to release) the case hangs (which hangs
the test suite).  **

>From 11.x+ the diagnostic is emitted and the test case finishes OK.

This is the patch that 'fixes' this:
r11-209-g74dc179a6da33cd00f6d4a93fbb97dc84f610126

Would it. or some equivalent, be appropriate for 10.4? (since IMO a hang is
less user-friendly than an ICE) - of course, the code is invalid either way ...

[Bug tree-optimization/105793] Missed vectorisation with conditional-select inside loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I think there is another bug about this. Basically it comes down to recognizing
conditional negative.

[Bug tree-optimization/105793] New: Missed vectorisation with conditional-select inside loop

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

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

Bug ID: 105793
   Summary: Missed vectorisation with conditional-select inside
loop
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

The code:
#define N 1024

float f(const float in[N], unsigned int n) {
float a = 0.0f;

for (unsigned  i = 0; i < N; ++i) {
float b = in[i];
if (b < 10.f)
a += b;
else
a -= b;
}

return a;
}

with -Ofast does not vectorise (on aarch64, for example):
f:
moviv0.2s, #0
add x1, x0, 4096
fmovs3, 1.0e+1
.L5:
ldr s1, [x0], 4
fsubs2, s0, s1
fcmpe   s1, s3
fadds0, s0, s1
fcsel   s0, s0, s2, mi
cmp x1, x0
bne .L5
ret

whereas clang can and does. Commenting out the "else a -=b;" line allows GCC to
vectorise it:
f:
moviv0.4s, 0
add x1, x0, 4096
fmovv3.4s, 1.0e+1
.L2:
ldr q2, [x0], 16
fcmgt   v1.4s, v3.4s, v2.4s
and v1.16b, v1.16b, v2.16b
faddv0.4s, v0.4s, v1.4s
cmp x1, x0
bne .L2
faddp   v0.4s, v0.4s, v0.4s
faddp   v0.4s, v0.4s, v0.4s
ret

Examples at https://gcc.godbolt.org/z/qbn6T73qE

[Bug target/105792] SPARC GCC 12.1.0 fails with internal compiler error: in expand_expr_real_2, at expr.cc:10160

[sumbera at volny dot cz via Gcc-bugs]

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

--- Comment #2 from Petr Sumbera  ---
Created attachment 53060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53060&action=edit
preprocessed source

[Bug c++/105758] [12/13 Regression] ICE in build_baselink since r12-6897

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/105792] SPARC GCC 12.1.0 fails with internal compiler error: in expand_expr_real_2, at expr.cc:10160

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

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

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

[Bug c/105792] New: SPARC GCC 12.1.0 fails with internal compiler error: in expand_expr_real_2, at expr.cc:10160

[sumbera at volny dot cz via Gcc-bugs]

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

Bug ID: 105792
   Summary: SPARC GCC 12.1.0 fails with internal compiler error:
in expand_expr_real_2, at expr.cc:10160
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sumbera at volny dot cz
  Target Milestone: ---

GDB and Qt5 fails with the same internal error when building with GCC 12.1.0 on
Solaris SPARC. GCC 11 works wiyhout problem. Following is GDB error output:

gmake[3]: Entering directory
'/scratch/psumbera/userland-test/components/gdb/build/sparcv9/readline/readline'
rm -f rltty.o
/usr/gcc/12/bin/gcc -std=gnu99 -c  -DHAVE_CONFIG_H   -I.
-I/scratch/psumbera/userland-test/components/gdb/gdb-10.2/readline/readline 
-DRL_LIBRARY_VERSION='"8.0"' -m64 -Wall -Wno-long-long -Wcast-align
-fno-omit-frame-pointer -O2 -mcpu=ultrasparc3 -mtune=niagara4
-mno-unaligned-doubles -mapp-regs -mhard-float
/scratch/psumbera/userland-test/components/gdb/gdb-10.2/readline/readline/rltty.c
during RTL pass: expand
In function 'save_tty_chars',
inlined from 'rl_prep_terminal' at
/scratch/psumbera/userland-test/components/gdb/gdb-10.2/readline/readline/rltty.c:638:3:
/scratch/psumbera/userland-test/components/gdb/gdb-10.2/readline/readline/rltty.c:370:52:
internal compiler error: in expand_expr_real_2, at expr.cc:10160
  370 |   _rl_intr_char = _rl_tty_chars.t_intr = tiop->c_cc[VINTR];
  |  ~~^~~
0x1007f0ff3 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
   
/builds/psumbera/userland-gcc-12.1.0/components/gcc12/gcc-12.1.0/gcc/expr.cc:10160
0x10069f793 expand_gimple_stmt_1
   
/builds/psumbera/userland-gcc-12.1.0/components/gcc12/gcc-12.1.0/gcc/cfgexpand.cc:3972
0x10069f793 expand_gimple_stmt
   
/builds/psumbera/userland-gcc-12.1.0/components/gcc12/gcc-12.1.0/gcc/cfgexpand.cc:4033
0x1006a5313 expand_gimple_basic_block
   
/builds/psumbera/userland-gcc-12.1.0/components/gcc12/gcc-12.1.0/gcc/cfgexpand.cc:6080
0x1006a71a7 execute
   
/builds/psumbera/userland-gcc-12.1.0/components/gcc12/gcc-12.1.0/gcc/cfgexpand.cc:6806
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
gmake[3]: *** [Makefile:105: rltty.o] Error 1
gmake[3]: Leaving directory
'/scratch/psumbera/userland-test/components/gdb/build/sparcv9/readline/readline'

--

Lowering optimization level to -O1 or -O0 helps (-O3 doesn't help).

Also when '-mcpu=ultrasparc3' isn't included it helps.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

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

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

Bug 105762 Summary: [12/13 Regression] -Warray-bounds false positives for 
integer-to-pointer casts since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug middle-end/105762] [12/13 Regression] -Warray-bounds false positives for integer-to-pointer casts since r12-2132-ga110855667782dac

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |INVALID
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99578
 Status|NEW |RESOLVED

--- Comment #2 from Martin Sebor  ---
There is no object at address 1 (or at any "made up" address) so dereferencing
that address is undefined.  The warning is designed to detect accesses at
nonzero offsets from null (e.g., p->x or p[i]).  It was relaxed to accommodate
a subset of the use cases where the offset is above 4k (see pr99578).

[Bug target/105778] Shift by register --- unnecessary AND instruction

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #53058|0   |1
is obsolete||

--- Comment #5 from Jakub Jelinek  ---
Created attachment 53059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53059&action=edit
gcc13-pr105778.patch

Adjusted patch.

[Bug target/105791] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -mxop

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #2 from Roger Sayle  ---
Doh! V1TI needs to be added to V_128_256.  I'll spin a patch.

[Bug c++/105767] gcc 12.1 ICE but not with 11.2 compiling boost

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

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

Alex Coplan  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 CC||acoplan at gcc dot gnu.org
   Last reconfirmed||2022-05-31
 Ever confirmed|0   |1
 Resolution|FIXED   |---

--- Comment #2 from Alex Coplan  ---
The compiler should never ICE. If you can reproduce the problem (by switching
the include order back), please can you attach the preprocessed source (with
-E) needed to reproduce the issue?

[Bug target/105791] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -mxop

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-31
 Status|UNCONFIRMED |NEW
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1

--- Comment #1 from Roger Sayle  ---
I believe this would be fixed by:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595382.html
but Richard Biener insists that the middle-end doesn't/shouldn't create
VEC_COND_EXPR if they are not natively supported by the target.

[Bug target/105778] Shift by register --- unnecessary AND instruction

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

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

--- Comment #4 from Jakub Jelinek  ---
It is the same thing done a few lines later in the preexisting code too.
Shall I all of those change to gen_lowpart (QImode, force_reg (GET_MODE
(operands[2]), operands[2])) then?

[Bug target/105778] Shift by register --- unnecessary AND instruction

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
Comment on attachment 53058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53058
gcc13-pr105778.patch

>+  operands[2] = gen_lowpart (QImode, operands[2]);

We have learned that pre-reload splits need to move operand to a register
before calling gen_lowpart.

>+  emit_insn (gen_ashl3_doubleword (operands[0], operands[1],
>+  operands[2]));
>+  DONE;

[Bug middle-end/105777] Failure to optimize __builtin_mul_overflow with constant operand to add+cmp check

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Right now, x86, riscv and s390 are the only targets with mulv4 and the
former 2 with umulv4 support, so perhaps it might be enough to just
compare  how those sequences compare on those 2/3 arches.

[Bug c++/105758] [12/13 Regression] ICE in build_baselink since r12-6897

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-31
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
Started with r12-1270-ga1b3484a8e6c53 (both Comment 3 and Comment 4)

commit a1b3484a8e6c53c8084723e3f1738d402374198e
Author: Jason Merrill 
Date:   Mon May 31 12:56:34 2021 -0400

c++: alias member template [PR100102]

[Bug target/105778] Shift by register --- unnecessary AND instruction

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-05-31
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 53058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53058&action=edit
gcc13-pr105778.patch

Full untested patch.

[Bug c++/105787] internal compiler error: tree check: expected enumeral_type, have record_type in tsubst_copy

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
   Last reconfirmed||2022-05-31

--- Comment #1 from Marek Polacek  ---
Confirmed, started with r11-5003-gd50310408f54e3:

commit d50310408f54e38031f34931e591c63ff36fee09
Author: Jason Merrill 
Date:   Tue Nov 10 17:17:19 2020 -0500

c++: Implement C++20 'using enum'.  [PR91367]

[Bug target/105791] New: [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -mxop

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105791
   Summary: [13 Regression] ICE: in extract_insn, at recog.cc:2791
(unrecognizable insn) with -mxop
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 53057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53057&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mxop testcase.c 
testcase.c: In function 'foo':
testcase.c:11:1: error: unrecognizable insn:
   11 | }
  | ^
(insn 36 35 40 2 (set (reg:V1TI 90 [  ])
(if_then_else:V1TI (reg:V1TI 115)
(reg:V1TI 116)
(reg:V1TI 117))) "testcase.c":10:48 -1
 (nil))
during RTL pass: vregs
testcase.c:11:1: internal compiler error: in extract_insn, at recog.cc:2791
0x76f806 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x76f882 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0x75e550 extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2791
0x1019419 instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.cc:1611
0x1019419 instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.cc:1985
0x1019419 execute
/repo/gcc-trunk/gcc/function.cc:2034
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-861-20220531001632-g0f4df800b15-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-861-20220531001632-g0f4df800b15-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220531 (experimental) (GCC)

[Bug libstdc++/105790] New: cannot constructor std::tuple of non-movable types with conversions

[hui.xie1990 at gmail dot com via Gcc-bugs]

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

Bug ID: 105790
   Summary: cannot constructor std::tuple of non-movable types
with conversions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hui.xie1990 at gmail dot com
  Target Milestone: ---

```
#include 

struct Immovable{
Immovable() = default;
Immovable(Immovable&&) = delete;
};

struct ConvToImmovable{
operator Immovable() const { return Immovable{};}
};

void test(){
   std::tuple t{ConvToImmovable{}};
}
```

The above code does not compile.

/opt/compiler-explorer/gcc-trunk-20220531/include/c++/13.0.0/tuple:91:11:
error: use of deleted function 'Immovable::Immovable(Immovable&&)'
   91 | : _M_head_impl(std::forward<_UHead>(__h)) { }
  |   ^~~
:5:5: note: declared here
5 | Immovable(Immovable&&) = delete;

According to the spec, as Immovable IS constructible from ConvToImmovable, so
the tuple's constructor that takes (UTypes&&...) should work.

[Bug fortran/105759] is_contiguous(zero_size_array(2:0)) wrongly returns .true.

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
JFTR: Cray and NAG also print T, so I guess this confirms Steve's analysis.

[Bug c++/105789] New: The instance of a deallocation function template is never a usual deallocation function

[xmh970252187 at gmail dot com via Gcc-bugs]

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

Bug ID: 105789
   Summary: The instance of a deallocation function template is
never a usual deallocation function
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xmh970252187 at gmail dot com
  Target Milestone: ---

struct S {
  // Placement allocation function:
  static void* operator new(std::size_t, std::size_t);

  // Usual (non-placement) deallocation function: it's not true
  template
  static void operator delete(void*, T);
};
int main(){
   S* p = new (0) S;
}

GCC rejects this example and reported the instance of the deallocation function
template is a usual one, as pointed out by the comment. However,
[basic.stc.dynamic.deallocation] p3 says:
> A template instance is never a usual deallocation function, regardless of its 
> signature.

That means the instance of the deallocation function template is a placement
one, which matches the placement allocation function so that this example
didn't violate [expr.new] p28. GCC ought to accept this well-formed example.

[Bug c++/105788] New: ICE: trying to capture 'args#0' in instantiation of generic lambda

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105788
   Summary: ICE: trying to capture 'args#0' in instantiation of
generic lambda
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Maybe dup of PR100291, not sure.


#include 

auto f = [](auto... args) {
  return (std::views::transform(
[&](auto r) { 
  if constexpr (std::ranges::range)
return std::views::drop(args); })
| ...);
}(0);

auto g = std::views::single(std::views::iota(0, 5)) | f;

https://godbolt.org/z/PWoeEv5ME

[Bug sanitizer/64234] Statically sanitized executable does not export ASan symbols

[mkh199740 at mail dot ru via Gcc-bugs]

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

lo1ol  changed:

   What|Removed |Added

 CC||mkh199740 at mail dot ru

--- Comment #6 from lo1ol  ---
I've the same problem when try to link at runtime shared library compiled with
static asan. Here is minimal example:

echo '
#include 
#include 

void f(){
int* x = new int;
printf("kek\n");
}' > lib.cpp

echo '
#include 
#include 
int main() {
printf("lol\n");
void* handler = dlopen("./libkek.so", RTLD_NOW);
if (!handler)
return 1;

void (* func)() = reinterpret_cast(dlsym(handler, "_Z1fv"));
printf("kek\n");
func();
printf("cheburek\n");
}' > main.cpp


g++ -fsanitize=address -static-libasan -static-libstdc++ -static-libgcc -fPIC
-shared lib.cpp -o libkek.so
g++ -fsanitize=address -static-libasan -static-libstdc++ -static-libgcc -ldl
main.cpp
LD_DEBUG=libs ./a.out; echo $?

Part of the output:
...
347802: initialize program: ./a.out
347802:
347802:
347802: transferring control: ./a.out
347802:
lol
347802: ./libkek.so: error: symbol lookup error: undefined symbol:
__asan_unregister_globals (fatal)
347802:
347802: calling fini: ./a.out [0]
347802:
347802:
347802: calling fini: /lib/x86_64-linux-gnu/libm.so.6 [0]
347802:


With clang everything is ok

GCC version 12.1
System: Ubuntu 21.10

[Bug c++/105787] New: internal compiler error: tree check: expected enumeral_type, have record_type in tsubst_copy

[tamas+gcc--- via Gcc-bugs]

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

Bug ID: 105787
   Summary: internal compiler error: tree check: expected
enumeral_type, have record_type in tsubst_copy
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tamas+...@hudson-trading.com
  Target Milestone: ---

The following code causes ICE (at least) on gcc 11.2, 11.3, 12.0 and 13.0.0
20220529 (experimental) when compiling with -std=c++20:

template  class a;
class b;
template <> class a {
public:
  enum class c { d };
  using enum c;
};
class b : public a {};
template  class e { char g = (char)b::d; };
e<0> f;

Full error from "13.0.0 20220529":

: In instantiation of 'constexpr e<0>::e()':
:10:6:   required from here
:9:44: internal compiler error: tree check: expected enumeral_type,
have record_type in tsubst_copy, at cp/pt.cc:16944
9 | template  class e { char g = (char)b::d; };
  | ~~~^
0x2200a89 internal_error(char const*, ...)
???:0
0x6fa097 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0x9c2aea tsubst_tree_list(tree_node*, tree_node*, int, tree_node*)
???:0
0x89984c get_nsdmi(tree_node*, bool, int)
???:0
0x8cd522 get_defaulted_eh_spec(tree_node*, int)
???:0
0x9c2108 maybe_instantiate_noexcept(tree_node*, int)
???:0
0x9c2093 maybe_instantiate_noexcept(tree_node*, int)
???:0
0x867369 mark_used(tree_node*, int)
???:0
0x776f5f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0x778c48 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0x8947ad build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0x850c86 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x98cded c_parse_file()
???:0
0xb22051 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Godbolt link: https://godbolt.org/z/xcTTs3s3e

[Bug c++/105786] New: ICE in compute_distributive_range, at tree-data-ref.cc:593

[gcc at olupton dot com via Gcc-bugs]

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

Bug ID: 105786
   Summary: ICE in compute_distributive_range, at
tree-data-ref.cc:593
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at olupton dot com
  Target Milestone: ---

The following example:

```
void sink(const char*);
static const char *a;
int main() {
  const char *b = a;
  for (int i = 0; i < 2; ++i)
while (*b++)
  ;
  sink(b);
  return 0;
}
```

produces an ICE at -O2 and above with 12.1:

```
during GIMPLE pass: pcom
: In function 'int main()':
:3:5: internal compiler error: in compute_distributive_range, at
tree-data-ref.cc:593
3 | int main() {
  | ^~~~
```

this is reproducible on Compiler Explorer (https://godbolt.org/z/z1zrqrrEs) and
also using 12.1.1 installed via `dnf` in a `fedora:latest` Docker container.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853 reports a similar error
message, but it says the issue is resolved so opening this new issue seems
justified.

Note that adding
```
void set_a(const char* x) {
a = x;
}
```
so that `a` can be non-null avoids the ICE.

[Bug fortran/105785] New: DIEs for local types are emitted at wrong scope in DWARF debug info

[nils-christian.kempke at intel dot com via Gcc-bugs]

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

Bug ID: 105785
   Summary: DIEs for local types are emitted at wrong scope in
DWARF debug info
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-debug
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nils-christian.kempke at intel dot com
  Target Milestone: ---

This was tested with
---
>> gfortran --version
GNU Fortran (GCC) 13.0.0 20220510 (experimental)
...
---

Compiling a Fortran program with a locally defined type as in
---
>> cat f.f90
program prog
  type :: test
 integer :: int
  end type test

  type (test) :: test_var
  test_var%int = 33
  print *, test_var
end program prog
>> gfortran -O0 -g ./f.f90
>>
---
and checking its debug info we see
---
>> objdump --dwarf=info ./a.out
...
 <0>: Abbrev Number: 3 (DW_TAG_compile_unit)
...
 <1><2f>: Abbrev Number: 4 (DW_TAG_structure_type)
<30>   DW_AT_name: (indirect string, offset: 0x117): test
...
<38>   DW_AT_sibling : <0x4a>
 <2><3c>: Abbrev Number: 5 (DW_TAG_member)
<3d>   DW_AT_name: int
...
 <2><49>: Abbrev Number: 0
 ...
 <1><9f>: Abbrev Number: 9 (DW_TAG_subprogram)
   DW_AT_name: (indirect string, offset: 0x20): prog
...
 <2>: Abbrev Number: 10 (DW_TAG_variable)
   DW_AT_name: (indirect string, offset: 0x17): test_var
...
 <2>: Abbrev Number: 0
 <1>: Abbrev Number: 0
---
The type declared inside the Fortran program prog is emitted as a child of the
whole compile unit even though its visibility is limited to the scope of prog.
It should instead be emitted as a child of the DW_TAG_subprogram prog (as to
limit its visibility appropriately).

[Bug tree-optimization/105545] [12/13 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6

[tom at compton dot nu via Gcc-bugs]

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

--- Comment #6 from Tom Hughes  ---
The reason it only happens with -D_GLIBCXX_ASSERTIONS or in C++20 mode is that
both of those stop the use of the explicit instantiations for basic_string and
cause them to be implicitly instantiated.

[Bug middle-end/105781] GCC does not unroll auto-vectorized loops.

[denis.yaroshevskij at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Denis Yaroshevskiy  ---
Pragma is not going to be used in 99.9% of cases.
TBH I think that gcc should not require -funroll-loops at least on O3. This is
not a well known flag and people expect O3 to be max speed at the expense of
size.