[Bug c++/106366] New: CTAD fails to prioritize initializer_list when done via Deduction guide and inherited CTORS

[peter.cpp at sommerlad dot ch via Gcc-bugs]

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

Bug ID: 106366
   Summary: CTAD fails to prioritize initializer_list when done
via Deduction guide and inherited CTORS
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.cpp at sommerlad dot ch
  Target Milestone: ---

The following code fails to compile on trunk, 12.1 and all 11 versions of g++ I
tried and compiles fine with clang and msvc:

#include 
template
struct Adapter: std::vector{
using std::vector::vector;
// Adapter(std::initializer_list l)
// :std::vector::vector(l){}
};
template
Adapter(std::initializer_list) -> Adapter;

int main(){
Adapter x{1,2,3};
}

see https://compiler-explorer.com/z/hj9zPPa8d

defining the constructor instead of the (not yet inherited) deduction guide
makes it work.

[Bug libstdc++/100795] ranges::sample should not use std::sample directly

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #10 from 康桓瑋  ---
For non-std::sample branches, we still have to consider that _Out only works
with its difference_type, so an explicit casting is missing here.

1580 | return __out + __sample_sz;
 |~~^

https://godbolt.org/z/T4s99GMrP

[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file

[sen2403 at hotmail dot com via Gcc-bugs]

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

Eason Lai  changed:

   What|Removed |Added

 CC||sen2403 at hotmail dot com

--- Comment #8 from Eason Lai  ---
This problem can be reproduced by arm-none-eabi-gcc 10.2.1-q4 toolchain.

The weak definition in LTO object is been inline directly even there is a
strong definition in normal object. And, the problem is gone if changing
optimization from (-Os) to (-O1 or -O0).

[Bug c/106264] [10/11/12/13 Regression] spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result since r9-1295-g781ff3d80e88d7d0

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|10.5|13.0

--- Comment #7 from Roger Sayle  ---
This has now been fixed on mainline for GCC 13.  Please feel free to reopen
this PR if folks consider this problem serious enough to backport the fix to
the release branches.

[Bug tree-optimization/106365] New: Miss to handle ifn .LEN_STORE in FRE

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

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

Bug ID: 106365
   Summary: Miss to handle ifn .LEN_STORE in FRE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

In regression testing for the patch to add unroll factor suggestion to
vectorizer for port rs6000, one failure got exposed on Power10 (with partial
vector in length supported). 

The test case is gcc/testsuite/gcc.dg/tree-ssa/pr84512.c

The option can be: -O3 -mcpu=power10 -fno-vect-cost-model

The resulted IR in optimized:

   [local count: 97603129]:
  MEM  [(int *)&a] = { 0, 1, 4, 9 };
  MEM  [(int *)&a + 16B] = { 16, 25, 36, 49 };
  .LEN_STORE (&MEM  [(void *)&a + 32B], 128B, 8, { 64, 0, 0, 0, 81, 0,
0, 0, 100, 0, 0, 0, 121, 0, 0, 0 }, 0);
  vect__2.10_6 = MEM  [(int *)&a];
  vect__2.10_30 = MEM  [(int *)&a + 16B];
  vect_res_10.11_31 = vect__2.10_6 + vect__2.10_30;
  _33 = VEC_PERM_EXPR ;
  _34 = vect_res_10.11_31 + _33;
  _35 = VEC_PERM_EXPR <_34, { 0, 0, 0, 0 }, { 1, 2, 3, 4 }>;
  _36 = _34 + _35;
  stmp_res_10.12_37 = BIT_FIELD_REF <_36, 32, 0>;
  _13 = a[8];
  res_3 = _13 + stmp_res_10.12_37;
  _8 = a[9];
  res_23 = res_3 + _8;
  a ={v} {CLOBBER(eol)};
  return res_23;

instead of:

int foo ()
{
   [local count: 97603129]:
  return 285;

}

[Bug rtl-optimization/106364] New: ICE when compiling inline asm with -m32

[tlwang at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 106364
   Summary: ICE when compiling inline asm with -m32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tlwang at uwaterloo dot ca
  Target Milestone: ---

See below.

// Target: x86_64-pc-linux-gnu
// Configured with: /tmp/tmp.KjYQzLjtrV-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
// Thread model: posix
// Supported LTO compression algorithms: zlib
// gcc version 13.0.0 20220719 (experimental) [master -g2180cdd8a] (GCC)
//
// inline_asm_program0_preprocessed.c: In function ‘l’:
// inline_asm_program0_preprocessed.c:6:5: error: ‘asm’ operand has impossible
constraints
// 6 | asm(""
//   | ^~~
// during RTL pass: reload
// inline_asm_program0_preprocessed.c:9:1: internal compiler error: maximum
number of LRA assignment passes is achieved (30)
// 9 | }
//   | ^
// 0xe5fd80 lra_assign(bool&)
//  /tmp/tmp.KjYQzLjtrV-gcc-builder/gcc/gcc/lra-assigns.cc:1694
// 0xe5a76c lra(_IO_FILE*)
//  /tmp/tmp.KjYQzLjtrV-gcc-builder/gcc/gcc/lra.cc:2426
// 0xe0e159 do_reload
//  /tmp/tmp.KjYQzLjtrV-gcc-builder/gcc/gcc/ira.cc:5940
// 0xe0e159 execute
//  /tmp/tmp.KjYQzLjtrV-gcc-builder/gcc/gcc/ira.cc:6126
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See <https://gcc.gnu.org/bugs/> for instructions.

// /scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/cc1
-quiet -imultilib 32 -imultiarch i386-linux-gnu
inline_asm_program0_preprocessed.c -quiet -dumpdir a- -dumpbase
inline_asm_program0_preprocessed.c -dumpbase-ext .c -m32 -mtune=generic
-march=x86-64 -O0 -w -freport-bug -o - -frandom-seed=0 -fdump-noaddr

# 0 "inline_asm_program0_preprocessed.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "inline_asm_program0_preprocessed.c"
a, b, c, d, e, f, g, h, i;
long long j;
char k;
l() {
  for (;; l())
asm(""
: "+a"(h), "+r"(b), "=r"(a), "+r"(f), "+r"(e), "+r"(i), "=r"(g),
  "+r"(j), "=r"(d), "+r"(b), "+r"(k), "=r"(c));
}

[Bug c++/106363] New: [modules] Can't selectively reexport imported declaration in same namespace

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 106363
   Summary: [modules] Can't selectively reexport imported
declaration in same namespace
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/a3GqTEs5P, which Clang accepts:
https://godbolt.org/z/svaGvz1bz.

mod2.cpp:
```C++
export module mod2;
namespace ns {
export int x = 0;
}
```

mod.cpp:
```C++
export module mod;
import mod2;
namespace ns {
export using ns::x;
}
```

test.cpp:
```C++
import mod;
int main() { return ns::x; }
```

Output:
```
[ 62%] Building CXX object CMakeFiles/mod.dir/mod.cpp.o
mod.cpp:1:8: internal compiler error: in decl_node, at cp/module.cc:8678
1 | export module mod;
  |^~
0x221f229 internal_error(char const*, ...)
???:0
0x74c10d fancy_abort(char const*, int, char const*)
???:0
0x8fcc60 trees_out::decl_node(tree_node*, walk_kind)
???:0
0x8fd01d trees_out::tree_node(tree_node*)
???:0
0x905086 module_state::write_cluster(elf_out*, depset**, unsigned int,
depset::hash&, unsigned int*, unsigned int*)
???:0
0x906ace module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
???:0
0x9079f2 finish_module_processing(cpp_reader*)
???:0
0x87253d c_parse_final_cleanups()
???:0
0xb2d060 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.
```

[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9

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

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

--- Comment #2 from Kewen Lin  ---
Two more failures related to required tuning setting:

PASS->FAIL: gcc.target/powerpc/compress-float-ppc.c scan-assembler lfs
PASS->FAIL: gcc.target/powerpc/compress-float-ppc-pic.c scan-assembler lfs

[Bug analyzer/106359] -fanalyzer takes a very long time on Linux kernel: sound/soc/codecs/cs47l{85,90}.c

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

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

David Malcolm  changed:

   What|Removed |Added

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

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

[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer

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

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

Bug 106359 Summary: -fanalyzer takes a very long time on Linux kernel: 
sound/soc/codecs/cs47l{85,90}.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106359

   What|Removed |Added

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

[Bug analyzer/106359] -fanalyzer takes a very long time on Linux kernel: sound/soc/codecs/cs47l{85,90}.c

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

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

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

https://gcc.gnu.org/g:68871a008e686dbe56ff0b502f2864176a140716

commit r13-1761-g68871a008e686dbe56ff0b502f2864176a140716
Author: David Malcolm 
Date:   Tue Jul 19 20:22:18 2022 -0400

analyzer: don't track string literals in the store [PR106359]

Doing so speeds up -fanalyzer from taking over 4 hours to under a
minute on the Linux kernel's sound/soc/codecs/cs47l90.c

gcc/analyzer/ChangeLog:
PR analyzer/106359
* region.h (string_region::tracked_p): New.
* store.cc (binding_cluster::binding_cluster): Move here from
store.h.  Add assertion that base_region is tracked_p.
* store.h (binding_cluster::binding_cluster): Move to store.cc.

Signed-off-by: David Malcolm 

[Bug tree-optimization/105651] [12/13 Regression] bogus "may overlap" memcpy warning with std::string and operator+ at -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||me+gccbugzilla at s5 dot pm

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

[Bug tree-optimization/106350] O3 memcpy warning when prepending a length-1 string literal to a constant std::string

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

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

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

[Bug c++/106202] [11/12/13 Regression] ICE in move_fn_p, at cp/decl.cc:14907 since r12-885-gf71ca97def69b8ae

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||leo at adberg dot com

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

[Bug c++/106361] [11/12/13 Regression] Internal compiler error when creating an out-of-line operator==() = default

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Duplicate of bug 106202.

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

[Bug c++/106361] [11/12/13 Regression] Internal compiler error when creating an out-of-line operator==() = default

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
No worries, thanks for the report (and the reduced test).

Started with r12-885-gf71ca97def69b8ae.

[Bug c++/106202] [11/12/13 Regression] ICE in move_fn_p, at cp/decl.cc:14907 since r12-885-gf71ca97def69b8ae

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

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

--- Comment #5 from Andrew Pinski  ---
The reduced testcase from PR 106361:
struct foo {
int x;
};

struct bar {
foo f;
friend bool operator==(const bar& a, const bar& b);
};

bool operator==(const bar& a, const bar& b) = default;

int main() {
return bar{} == bar{};
}

[Bug c++/106361] [11/12/13 Regression] Internal compiler error when creating an out-of-line operator==() = default

[leo at adberg dot com via Gcc-bugs]

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

--- Comment #4 from Leo Adberg  ---
(In reply to Andrew Pinski from comment #2)
> Confirmed. Please next time, either put the testcase inline or attach it. 
> Having a goldbolt link is not enough.

Will do next time! Sorry, first time here.

[Bug c++/106202] [11/12/13 Regression] ICE in move_fn_p, at cp/decl.cc:14907 since r12-885-gf71ca97def69b8ae

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.2.0, 12.1.0
   Keywords||ice-on-invalid-code
   Target Milestone|--- |11.4
  Known to work||11.1.0
Summary|[12/13 Regression] ICE in   |[11/12/13 Regression] ICE
   |move_fn_p, at   |in move_fn_p, at
   |cp/decl.cc:14907 since  |cp/decl.cc:14907 since
   |r12-885-gf71ca97def69b8ae   |r12-885-gf71ca97def69b8ae

[Bug c++/106361] [11/12/13 Regression] Internal compiler error when creating an out-of-line operator==() = default

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

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

--- Comment #3 from Andrew Pinski  ---
The ICE is:
: In function 'int main()':
:13:25: internal compiler error: in move_fn_p, at cp/decl.cc:15025
   13 | return bar{} == bar{};
  | ^
0x221f229 internal_error(char const*, ...)
???:0
0x74c10d fancy_abort(char const*, int, char const*)
???:0
0x82c49a move_fn_p(tree_node const*)
???:0
0x7801be build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xa8c9d1 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0x99690d c_parse_file()
???:0

[Bug c++/106361] [11/12/13 Regression] Internal compiler error when creating an out-of-line operator==() = default

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Last reconfirmed||2022-07-19
   Target Milestone|--- |11.4
 Ever confirmed|0   |1
  Known to fail||11.2.0, 12.1.0
Summary|Internal compiler error |[11/12/13 Regression]
   |when creating an|Internal compiler error
   |out-of-line operator==() =  |when creating an
   |default |out-of-line operator==() =
   ||default
  Known to work||11.1.0
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed. Please next time, either put the testcase inline or attach it. 
Having a goldbolt link is not enough.

[Bug c++/106361] Internal compiler error when creating an out-of-line operator==() = default

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 53320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53320&action=edit
testcase

[Bug c++/106362] New: -Wc++20-compat should not warn with __extension__

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

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

Bug ID: 106362
   Summary: -Wc++20-compat should not warn with __extension__
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As noted here:
, the
following should probably not generate a warning:

__extension__ int char8_t;

$ ./cc1plus -quiet g.C -Wc++20-compat
g.C:1:19: warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat]
1 | __extension__ int char8_t;
  |   ^~~

[Bug c++/106361] New: Internal compiler error when creating an out-of-line operator==() = default

[leo at adberg dot com via Gcc-bugs]

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

Bug ID: 106361
   Summary: Internal compiler error when creating an out-of-line
operator==() = default
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leo at adberg dot com
  Target Milestone: ---

I was trying to define a default equality operator out of line for a struct
that contains a member without an equality operator. Clang errors with the
correct reason because it shouldn't be possible:
"defaulted 'operator==' is implicitly deleted because there is no viable
three-way comparison function for member 'f'"

GCC 11.1 correctly errors too, but 11.2 and above all crash with an internal
compiler error. See the example here: https://godbolt.org/z/WcbTaGonK

[Bug c++/92434] [DR 2355] noexcept couldn't be deduced in function template

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

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||12.1.1
 Resolution|--- |FIXED
   Target Milestone|--- |12.0
  Known to fail||11.3.1
 Status|NEW |RESOLVED

--- Comment #7 from Jason Merrill  ---
Fixed in GCC 12.

[Bug fortran/101330] [openmp]ICE in free_expr0(): Bad expr type

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

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

--- Comment #5 from Tobias Burnus  ---
(In reply to anlauf from comment #4)
> (In reply to kargl from comment #1)
...
> > - step = gfc_get_expr ();
> >   if (gfc_match (": %e ", &step) != MATCH_YES)

> Yeah, this obviously fixes it.  Looks like a left-over from development.
> I can commit it.

LGTM and please commit. – Thanks to the four of you for, respectively, the
testcase, the bisecting, the code fix, and for packaging the testcase.

[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails

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

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

--- Comment #1 from seurer at gcc dot gnu.org ---
*** Bug 105837 has been marked as a duplicate of this bug. ***

[Bug testsuite/105837] New test c-c++-common/diagnostic-format-sarif-file-4.c in r13-967-g6cf276ddf22066 fails

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from seurer at gcc dot gnu.org ---
Sorry, I opened this one twice.

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

[Bug fortran/103590] ICE: find_array_spec(): Missing spec

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed for gcc-13.

Thanks for the report!

[Bug fortran/103590] ICE: find_array_spec(): Missing spec

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

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

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

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

commit r13-1757-gf838d15641d256e21ffc126c3277b290ed743928
Author: Harald Anlauf 
Date:   Mon Jul 18 22:34:53 2022 +0200

Fortran: error recovery on invalid array reference of non-array [PR103590]

gcc/fortran/ChangeLog:

PR fortran/103590
* resolve.cc (find_array_spec): Change function result to bool to
enable error recovery.  Generate error message for invalid array
reference of non-array entity instead of an internal error.
(gfc_resolve_ref): Use function result from find_array_spec for
error recovery.

gcc/testsuite/ChangeLog:

PR fortran/103590
* gfortran.dg/associate_54.f90: Adjust.
* gfortran.dg/associate_59.f90: New test.

[Bug tree-optimization/106360] New: [13 regression] ICE in many test cases after r13-1745-g4c323130257744

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

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

Bug ID: 106360
   Summary: [13 regression] ICE in many test cases after
r13-1745-g4c323130257744
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4c3231302577445417715a7c22e879e4159376d3, r13-1745-g4c323130257744

I saw this on a power 9 LE machine:

FAIL: gcc.dg/vect/slp-reduc-sad-2.c (internal compiler error: in fold_vec_perm,
at fold-const.cc:10548)
FAIL: gcc.dg/vect/slp-reduc-sad-2.c (test for excess errors)
FAIL: gcc.dg/vect/slp-reduc-sad-2.c -flto -ffat-lto-objects (internal compiler
error: in fold_vec_perm, at fold-const.cc:10548)
FAIL: gcc.dg/vect/slp-reduc-sad-2.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.target/powerpc/vec-perm-ctor-run.c (internal compiler error: in
fold_vec_perm, at fold-const.cc:10548)
FAIL: gcc.target/powerpc/vec-perm-ctor-run.c (test for excess errors)
FAIL: gcc.target/powerpc/vec-perm-ctor.c (internal compiler error: in
fold_vec_perm, at fold-const.cc:10548)
FAIL: gcc.target/powerpc/vec-perm-ctor.c (test for excess errors)

There were some similar errors for other test cases on other hardware, too.

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c
-fdiagnostics-plain-output -maltivec -mpower9-vector -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details --param vect-epilogues-nomask=0 -S -o
slp-reduc-sad-2.s^M
during GIMPLE pass: forwprop^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c: In
function 'x264_pixel_sad_8x8':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c:9:5:
internal compiler error: in fold_vec_perm, at fold-const.cc:10548^M
0x1073188b fold_vec_perm(tree_node*, tree_node*, tree_node*, vec_perm_indices
const&)^M
/home/seurer/gcc/git/gcc-test/gcc/fold-const.cc:10546^M
0x1177bb17 generic_simplify_VEC_PERM_EXPR^M
/home/seurer/gcc/git/build/gcc-test/gcc/generic-match.cc:98733^M
0x1073a8bb fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)^M
/home/seurer/gcc/git/gcc-test/gcc/fold-const.cc:12844^M
0x10e31dfb simplify_permutation^M
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-forwprop.cc:2665^M
0x10e3ec63 execute^M
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-forwprop.cc:3748^M


commit 4c3231302577445417715a7c22e879e4159376d3 (HEAD, refs/bisect/bad)
Author: Prathamesh Kulkarni 
Date:   Tue Jul 19 17:43:26 2022 +0530

forwprop: Use lhs type instead of arg0 in folding VEC_PERM_EXPR.

[Bug fortran/101330] [openmp]ICE in free_expr0(): Bad expr type

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
> index 357a1e15e01..37056ac035f 100644
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -1074,7 +1074,6 @@ gfc_match_iterator (gfc_namespace **ns, bool
> permit_var)
>   }
>if (':' == gfc_peek_ascii_char ())
>   {
> -   step = gfc_get_expr ();
> if (gfc_match (": %e ", &step) != MATCH_YES)
>   {
> gfc_free_expr (begin);

Yeah, this obviously fixes it.  Looks like a left-over from development.
I can commit it.

[Bug analyzer/106359] -fanalyzer takes a very long time on Linux kernel: sound/soc/codecs/cs47l{85,90}.c

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

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

--- Comment #1 from David Malcolm  ---
Dumping the store shows huge numbers of clusters of the form:

  cluster for: "RXANCL Input": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"RXANCL Input") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "AEC2 Loopback": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"AEC2 Loopback") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "Route": CONJURED(madera_free_bus_error_irq (_6, i_29);,
"Route") (ESCAPED) (TOUCHED)
  cluster for: "RXANC NG Source": CONJURED(madera_free_bus_error_ir

[Bug analyzer/106359] New: -fanalyzer takes a very long time on Linux kernel: sound/soc/codecs/cs47l{85,90}.c

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

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

Bug ID: 106359
   Summary: -fanalyzer takes a very long time on Linux kernel:
sound/soc/codecs/cs47l{85,90}.c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
  Target Milestone: ---

I've been testing -fanalyzer trunk with my trust boundaries patches on the
upstream Linux kernel, with "allyesconfig".

-fanalyzer seems to take a *very* long time on:
sound/soc/codecs/cs47l85.c and sound/soc/codecs/cs47l90.c (admittedly with a
debug build of gcc).

I saw it take roughly 4 hours to analyze the former, and I stopped the latter
after four hours to investigate with gdb.

The latter had:

(gdb) p *eg.m_nodes.m_vec
$4 = {m_vecpfx = {m_alloc = 609, m_using_auto_storage = 0, m_num = 408},
m_vecdata = {0x611a7e0}}
(gdb) p *eg.m_edges.m_vec
$5 = {m_vecpfx = {m_alloc = 609, m_using_auto_storage = 0, m_num = 427},
m_vecdata = {0x6265af0}}

which is reasonable, but:

(gdb) p m_store.m_cluster_map
$9 = {m_table = {m_entries = 0xadc1260, m_size = 262139, m_n_elements = 144088,
m_n_deleted = 0, m_searches = 1008610, m_collisions = 534316, 
m_size_prime_index = 15, m_ggc = false, m_sanitize_eq_and_hash = true,
static m_gather_mem_stats = false}}

which is a ludicrously large number of clusters in the store, and thus
presumably responsible for the slowdown.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug analyzer/106358] New: [meta-bug] tracker bug for building the Linux kernel with -fanalyzer

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

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

Bug ID: 106358
   Summary: [meta-bug] tracker bug for building the Linux kernel
with -fanalyzer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Depends on: 106204, 106218, 106225, 106229, 106319, 106284, 106321
  Target Milestone: ---

I've creating this tracker bug to help organize issues I'm running into whilst
building the Linux kernel with -fanalyzer.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204
[Bug 106204] False positive from -Wanalyzer-use-of-uninitialized-value with
-ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106218
[Bug 106218] Analyzer false positives with Linux kernel's err.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106225
[Bug 106225] False positives from -Wanalyzer-tainted-divisor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106229
[Bug 106229] False positives from -Wanalyzer-tainted-array-index with unsigned
char index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106284
[Bug 106284] False positives from -Wanalyzer-tainted-array-index with optimized
conditionals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106319
[Bug 106319] False positives from -Wanalyzer-va-arg-type-mismatch on int
promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106321
[Bug 106321] False positives from -Wanalyzer-tainted-array-index with switch
with ranged cases

[Bug c++/105634] [9/10/11 Regression] ICE: Floating point exception in maybe_warn_class_memaccess

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression] ICE:
   |ICE: Floating point |Floating point exception in
   |exception in|maybe_warn_class_memaccess
   |maybe_warn_class_memaccess  |
 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #7 from Marek Polacek  ---
Fixed for GCC 12.2 as well.

[Bug c++/105634] [9/10/11/12 Regression] ICE: Floating point exception in maybe_warn_class_memaccess

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

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

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

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

commit r12-8585-gdeafa40eb57b39626e116ca6a15d34a34c57c9f6
Author: Marek Polacek 
Date:   Tue Jul 19 14:24:25 2022 -0400

c++: fix SIGFPE with -Wclass-memaccess [PR105634]

Here we crash because we attempt to % by 0.  Thus fixed.

PR c++/105634

gcc/cp/ChangeLog:

* call.cc (maybe_warn_class_memaccess): Avoid % by zero.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wclass-memaccess-7.C: New test.

[Bug fortran/106353] [suboptimal] Why is a 3D array initialized, use case 2 two-layer loop?

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
For code like

  rhogvx=2

where we know that we initialize a full (and here contiguous) array, is
there something the frontend can do, e.g. to annotate that a collapse
of the loop nest is possible?

[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791

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

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

--- Comment #3 from Marek Polacek  ---
Ah, -march=z14 is needed:

$ ./cc1 -quiet -O2 pr104612.c -Iinclude -march=z14 -mtune=z15
pr104612.c: In function ‘foo’:
pr104612.c:15:1: error: unrecognizable insn:
   15 | }
  | ^
(insn 9 8 10 2 (set (reg:V2SF 61 [ vect__2.10 ])
(ior:V2SF (and:V2SF (subreg:V2SF (reg/v:DI 63 [ v ]) 0)
(reg:V2SF 65))
(and:V2SF (not:V2SF (reg:V2SF 65))
(reg:V2SF 64 "pr104612.c":12:11 -1
 (nil))
during RTL pass: vregs
pr104612.c:15:1: internal compiler error: in extract_insn, at recog.cc:2791
0x68616c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mpolacek/src/gcc/gcc/rtl-error.cc:108
0x686188 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/mpolacek/src/gcc/gcc/rtl-error.cc:116
0x684bf1 extract_insn(rtx_insn*)
/home/mpolacek/src/gcc/gcc/recog.cc:2791
0xaabc10 instantiate_virtual_regs_in_insn
/home/mpolacek/src/gcc/gcc/function.cc:1611
0xaabc10 instantiate_virtual_regs
/home/mpolacek/src/gcc/gcc/function.cc:1985
0xaabc10 execute
/home/mpolacek/src/gcc/gcc/function.cc:2034

[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?

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

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

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

https://gcc.gnu.org/g:68f37670eff0b872ce5dfd382c8d8f3206bdfc27

commit r13-1755-g68f37670eff0b872ce5dfd382c8d8f3206bdfc27
Author: Patrick Palka 
Date:   Tue Jul 19 14:04:13 2022 -0400

c++: shortcut bad reference binding [PR94894]

In case of l/rvalue or cv-qual mismatch during reference binding, we
try to give more helpful diagnostics by computing a bad conversion that
allows the mismatch.  But in doing so, we may end up considering and
instantiating a conversion function that could induce a hard error and
in turn cause us to reject otherwise valid code.  We could just give up
on producing a better diagnostic here, but ideally we'd preserve the
better diagnostics for invalid code while avoiding unnecessary template
instantiations for valid code.

To that end, this patch adapts the bad conversion shortcutting mechanism
from r12-3346-g47543e5f9d1fc5 to additionally handle this situation.
The main observation from there is that during overload resolution, if we
know we have a strictly viable candidate then we don't need to distinguish
between an unviable and non-strictly viable candidate.  Thus we don't
need to distinguish between an invalid and bad conversion either, which
is what this patch exploits.  Of course, we don't know whether we have a
strictly viable candidate until after the fact, so we still need to
remember when we deferred distinguishing between an invalid and bad
conversion.  This patch adds a special conversion kind ck_deferred_bad
for this purpose.

PR c++/94894
PR c++/105766
PR c++/106201

gcc/cp/ChangeLog:

* call.cc (enum conversion_kind): Add ck_deferred_bad enumerator.
(has_next): Return false for it.
(reference_binding): Return a ck_deferred_bad conversion instead
of an actual bad conversion when LOOKUP_SHORTCUT_BAD_CONVS is set.
Remove now obsolete early exit for the incomplete TO case.
(implicit_conversion_1): Don't mask out LOOKUP_SHORTCUT_BAD_CONVS.
(add_function_candidate): Set LOOKUP_SHORTCUT_BAD_CONVS iff
shortcut_bad_convs.
(missing_conversion_p): Also return true for a ck_deferred_bad
conversion.
* cp-tree.h (LOOKUP_SHORTCUT_BAD_CONVS): Define.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref8.C: New test.
* g++.dg/conversion/ref9.C: New test.

[Bug c++/105766] requires std::is_constructible<> reports 'constraint depends on itself' error.

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

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

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

https://gcc.gnu.org/g:68f37670eff0b872ce5dfd382c8d8f3206bdfc27

commit r13-1755-g68f37670eff0b872ce5dfd382c8d8f3206bdfc27
Author: Patrick Palka 
Date:   Tue Jul 19 14:04:13 2022 -0400

c++: shortcut bad reference binding [PR94894]

In case of l/rvalue or cv-qual mismatch during reference binding, we
try to give more helpful diagnostics by computing a bad conversion that
allows the mismatch.  But in doing so, we may end up considering and
instantiating a conversion function that could induce a hard error and
in turn cause us to reject otherwise valid code.  We could just give up
on producing a better diagnostic here, but ideally we'd preserve the
better diagnostics for invalid code while avoiding unnecessary template
instantiations for valid code.

To that end, this patch adapts the bad conversion shortcutting mechanism
from r12-3346-g47543e5f9d1fc5 to additionally handle this situation.
The main observation from there is that during overload resolution, if we
know we have a strictly viable candidate then we don't need to distinguish
between an unviable and non-strictly viable candidate.  Thus we don't
need to distinguish between an invalid and bad conversion either, which
is what this patch exploits.  Of course, we don't know whether we have a
strictly viable candidate until after the fact, so we still need to
remember when we deferred distinguishing between an invalid and bad
conversion.  This patch adds a special conversion kind ck_deferred_bad
for this purpose.

PR c++/94894
PR c++/105766
PR c++/106201

gcc/cp/ChangeLog:

* call.cc (enum conversion_kind): Add ck_deferred_bad enumerator.
(has_next): Return false for it.
(reference_binding): Return a ck_deferred_bad conversion instead
of an actual bad conversion when LOOKUP_SHORTCUT_BAD_CONVS is set.
Remove now obsolete early exit for the incomplete TO case.
(implicit_conversion_1): Don't mask out LOOKUP_SHORTCUT_BAD_CONVS.
(add_function_candidate): Set LOOKUP_SHORTCUT_BAD_CONVS iff
shortcut_bad_convs.
(missing_conversion_p): Also return true for a ck_deferred_bad
conversion.
* cp-tree.h (LOOKUP_SHORTCUT_BAD_CONVS): Define.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref8.C: New test.
* g++.dg/conversion/ref9.C: New test.

[Bug c++/94894] avoidable instantiation of conversion function template during overload resolution

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

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

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

https://gcc.gnu.org/g:68f37670eff0b872ce5dfd382c8d8f3206bdfc27

commit r13-1755-g68f37670eff0b872ce5dfd382c8d8f3206bdfc27
Author: Patrick Palka 
Date:   Tue Jul 19 14:04:13 2022 -0400

c++: shortcut bad reference binding [PR94894]

In case of l/rvalue or cv-qual mismatch during reference binding, we
try to give more helpful diagnostics by computing a bad conversion that
allows the mismatch.  But in doing so, we may end up considering and
instantiating a conversion function that could induce a hard error and
in turn cause us to reject otherwise valid code.  We could just give up
on producing a better diagnostic here, but ideally we'd preserve the
better diagnostics for invalid code while avoiding unnecessary template
instantiations for valid code.

To that end, this patch adapts the bad conversion shortcutting mechanism
from r12-3346-g47543e5f9d1fc5 to additionally handle this situation.
The main observation from there is that during overload resolution, if we
know we have a strictly viable candidate then we don't need to distinguish
between an unviable and non-strictly viable candidate.  Thus we don't
need to distinguish between an invalid and bad conversion either, which
is what this patch exploits.  Of course, we don't know whether we have a
strictly viable candidate until after the fact, so we still need to
remember when we deferred distinguishing between an invalid and bad
conversion.  This patch adds a special conversion kind ck_deferred_bad
for this purpose.

PR c++/94894
PR c++/105766
PR c++/106201

gcc/cp/ChangeLog:

* call.cc (enum conversion_kind): Add ck_deferred_bad enumerator.
(has_next): Return false for it.
(reference_binding): Return a ck_deferred_bad conversion instead
of an actual bad conversion when LOOKUP_SHORTCUT_BAD_CONVS is set.
Remove now obsolete early exit for the incomplete TO case.
(implicit_conversion_1): Don't mask out LOOKUP_SHORTCUT_BAD_CONVS.
(add_function_candidate): Set LOOKUP_SHORTCUT_BAD_CONVS iff
shortcut_bad_convs.
(missing_conversion_p): Also return true for a ck_deferred_bad
conversion.
* cp-tree.h (LOOKUP_SHORTCUT_BAD_CONVS): Define.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref8.C: New test.
* g++.dg/conversion/ref9.C: New test.

[Bug target/81708] The x86 stack canary location should be customizable

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #17 from H.J. Lu  ---
(In reply to Alexandre Oliva from comment #15)
> Uroš,
> 
> stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard
> is loaded from the GOT, instead of appearing as %gs:my_guard.
> 

When PIC/PIE is used, my_guard is loaded from GOT, regardless of -m32 or -m64.

[Bug c++/105634] [9/10/11/12 Regression] ICE: Floating point exception in maybe_warn_class_memaccess

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
I will actually backport to 12; this problem showed up in Fedora.

[Bug c++/106357] [12/13 Regression] direct-list-initialization of enum class from a variable of another enum class type fails

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

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

--- Comment #4 from Jonathan Wakely  ---
This changed intentionally with r12-85-g5f8aed72e76970

c++: Refine enum direct-list-initialization [CWG2374]

This implements the wording changes of CWG2374, which clarifies the
wording of P0138 to forbid e.g. direct-list-initialization of a scoped
enumeration from a different scoped enumeration.

This was a change in the standard: https://wg21.link/cwg2374

[Bug c++/106357] [12/13 Regression] direct-list-initialization of enum class from a variable of another enum class type fails

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> I think the testcase is invalid as the enum does not have "fixed underlying
> type"

Scoped enums always have a fixed underlying type.

[Bug target/81708] The x86 stack canary location should be customizable

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Uroš Bizjak  ---
(In reply to Alexandre Oliva from comment #15)
> Uroš,
> 
> stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard
> is loaded from the GOT, instead of appearing as %gs:my_guard.
> 
> After being confused by the expectation that my_guard should be a LE TLS
> symbol, I'm coming to the conclusion that my expectation was incorrect, and
> it is indeed supposed to be a plain offset, so the code is correct, if not
> as efficient as on PDC.  Does that sound right?
> 
> I'm undecided as to whether avoiding the GOT reference, and requiring the
> symbol to be usable as a link-time constant, would be desirable/doable. 
> Thoughts?

The current implementation was implemented specifically for linux, as requested
in Comment #0, without any other usages in mind. Also, I'm not deeply familiar
with the details of symbol linking, so perhaps HJ can help here.

[Bug c++/106357] [12/13 Regression] direct-list-initialization of enum class from a variable of another enum class type fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
scoped enums also cannot be implicitly converted to another type.

So GCC is correct.

[Bug c++/106357] [12/13 Regression] direct-list-initialization of enum class from a variable of another enum class type fails

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

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

--- Comment #1 from Andrew Pinski  ---
I think the testcase is invalid as the enum does not have "fixed underlying
type"

[Bug c++/106357] New: [12/13 Regression] direct-list-initialization of enum class from a variable of another enum class type fails

[enolan at alumni dot cmu.edu via Gcc-bugs]

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

Bug ID: 106357
   Summary: [12/13 Regression] direct-list-initialization of enum
class from a variable of another enum class type fails
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enolan at alumni dot cmu.edu
  Target Milestone: ---

This example fails with GCC 12:

enum class A {
a
};
enum class B {
b
};

int main() {
A a{};
B b{a}; 
}

---

P0138 added this language to the standard for C++17 (see:
https://eel.is/c++draft/dcl.init.list#3.8)

> if T is an enumeration with a fixed underlying type ([dcl.enum]) U, the
> initializer-list has a single element v, v can be implicitly converted to U,
> and the initialization is direct-list-initialization, the object is
> initialized with the value T(v) ([expr.type.conv]);

The above test case works in GCC 7-11 but appears to have regressed in GCC 12
and on trunk.

---

> the exact version of GCC

gcc version 12.1.1 20220507 (Red Hat 12.1.1-1) (GCC)

> the system type

Fedora release 37 (Rawhide)

> the options given when GCC was configured/built

Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.1.1-20220507/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1

> the complete command line that triggers the bug

g++ -std=c++17 poc2.cpp

> the compiler output (error messages, warnings, etc.)

poc2.cpp: In function ‘int main()’:
poc2.cpp:10:9: error: cannot convert ‘A’ to ‘B’ in initialization
   10 | B b{a};
  | ^
  | |
  | A

> the preprocessed file (*.i*) that triggers the bug, generated by adding 
> -save-temps to the complete compilation command, or, in the case of a bug 
> report for the GNAT frontend, a complete set of source files (see below).

# 0 "poc2.cpp"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "poc2.cpp"
enum class A {
a
};
enum class B {
b
};

int main() {
A a{};
B b{a};
}

[Bug target/81708] The x86 stack canary location should be customizable

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||aoliva at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #15 from Alexandre Oliva  ---
Uroš,

stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard is
loaded from the GOT, instead of appearing as %gs:my_guard.

After being confused by the expectation that my_guard should be a LE TLS
symbol, I'm coming to the conclusion that my expectation was incorrect, and it
is indeed supposed to be a plain offset, so the code is correct, if not as
efficient as on PDC.  Does that sound right?

I'm undecided as to whether avoiding the GOT reference, and requiring the
symbol to be usable as a link-time constant, would be desirable/doable. 
Thoughts?

[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Alexandre Oliva from comment #8)
> I'm running into some problems that are related with this PR.
> 
> First off, on i686-linux-gnu with --enable-default-pie, attr-ifunc-3.c fails
> to link with e.g. binutils 2.30 (the linker in Trisquel 9), from before
> binutils commit 4ec0995016801cc5d5cf13baf6e10163861e6852.  The error was
> "relocation R_386_GOTOFF against STT_GNU_IFUNC symbol `foo' isn't supported".
> 
> Using a binutils 2.38.50 from May 2022, it doesn't fail to link, but it
> fails at runtime.  The @GOTOFF relocation to the IFUNC appears to be handled
> correctly only in PDEs.
> 

-fpie -pie -O0 -m32 and -fpie -pie -O2 -m32 work for me with
gcc.dg/attr-ifunc-3.c
on Fedora 36 and binutils 20220703.  Please provide the broken attr-ifunc-3.o
and
the command line used to compile it.

[Bug target/106356] static-pie for arm not implemented

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

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

--- Comment #1 from Andrew Pinski  ---
Patches goto gcc-patches@ after read https://gcc.gnu.org/contribute.html

[Bug driver/106356] New: static-pie for arm not implemented

[lancethepants at gmail dot com via Gcc-bugs]

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

Bug ID: 106356
   Summary: static-pie for arm not implemented
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lancethepants at gmail dot com
  Target Milestone: ---

Created attachment 53319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53319&action=edit
Add -static-pie handling for arm

This is a patch I'm using to implement -static-pie handling for arm.  This is
just copy/paste from the aarch code, so hardly copyrightable, if someone would
like to review it and submit it, I don't care about attribution.

https://github.com/lancethepants/gcc/commit/043704d5f827af775cf796b9ec144b72fc8d524f

[Bug tree-optimization/106352] SLP seems to need temporary variables

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

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

--- Comment #3 from Andrew Pinski  ---
Oh the non loop based slp, does not add alias checks. And you just enabled
that.

I think this is a won't fix as adding of aliasing checks for non loop based
slp, adds way too much overhead and might (will) be slower

[Bug tree-optimization/106352] SLP seems to need temporary variables

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

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

--- Comment #2 from Andrew Pinski  ---
I have to double check but the testcase might be hard to produce alias checks
too.
Marking the incoming arguments with restrict will also "fix" the code gen.

[Bug c++/95454] type-level nodiscard not applied to constructors

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Johel Ernesto Guerrero Peña  ---
> A workaround would be to declare the constructor(s) [[nodiscard]]:

That's generally a [better
recommendation](https://github.com/mpusz/units/issues/136). Though I think
you'd have to `= default` SMFs to get the same effects as the  type-level
annotation.

[Bug other/106355] New: Linux s390x -O2 argument passing miscompile

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 106355
   Summary: Linux s390x -O2 argument passing miscompile
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

(I ran into this when trying to build recent LibreOffice 7.5 master on Fedora
36 on s390x causing a crash in one of the executables generated during the
build.  I tracked that down to a member function S::f2(arg1,args2,arg3) calling
S::f1(arg1,arg2,arg3,std::nullopt) but within
S::f1(arg1,arg2,arg3,std::optional x) then x.has_value()
evaluates to true, or even to some random non-zero value like 163:)

At least with gcc-c++-12.1.1-1.fc36.s390x:

> $ cat test.cc
> #include 
> #include 
> int f1(int, int, int, int, std::optional x) {
>   if (x) std::abort();
>   return 0;
> }
> int f2(int a, int b, int c, int d) {
>   return f1(a, b, c, d, std::nullopt);
> }

> $ g++ -std=c++17 -O2 -fpic -S test.cc

> $ cat test.s
> .file   "test.cc"
> .machinemode zarch
> .machine "zEC12"
> .text
> .align  8
> .align  16
> .globl _Z2f1St8optionalItE
> .type   _Z2f1St8optionalItE, @function
> _Z2f1St8optionalItE:
> .LFB284:
> .cfi_startproc
> tmll%r6,65280
> jne .L7
> lghi%r2,0
> br  %r14
> .L7:
> stmg%r14,%r15,112(%r15)
> .cfi_offset 14, -48
> .cfi_offset 15, -40
> lay %r15,-168(%r15)
> .cfi_def_cfa_offset 328
> brasl   %r14,abort@PLT
> .cfi_endproc
> .LFE284:
> .size   _Z2f1St8optionalItE, .-_Z2f1St8optionalItE
> .align  8
> .align  16
> .globl _Z2f2
> .type   _Z2f2, @function
> _Z2f2:
> .LFB287:
> .cfi_startproc
> ldgr%f0,%r15
> .cfi_register 15, 16
> lay %r15,-168(%r15)
> .cfi_def_cfa_offset 328
> mvi 166(%r15),0
> lgdr%r15,%f0
> .cfi_restore 15
> .cfi_def_cfa_offset 160
> jg  _Z2f1St8optionalItE@PLT
> .cfi_endproc
> .LFE287:
> .size   _Z2f2, .-_Z2f2
> .ident  "GCC: (GNU) 12.1.1 20220507 (Red Hat 12.1.1-1)"
> .section.note.GNU-stack,"",@progbits

With my limited understanding of s390x assembly, f2 sets the optional's bool
_M_engaged flag byte to 0 on the stack with

lay %r15,-168(%r15)
mvi 166(%r15),0

but then f1 expects to test that byte in %r6 with

tmll%r6,65280

[Bug analyzer/106321] False positives from -Wanalyzer-tainted-array-index with switch with ranged cases

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed on trunk by the above patch.  Given that taint detection is
merely experimental in GCC 12 I don't plan to backport this to the GCC 12
branch; marking as resolved.

[Bug c++/106354] Diagnostic could be more user friendly

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed||2022-07-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug libstdc++/96766] std::swap(std::variant, std::variant) triggers undefined behavior sanitizer

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:20ab3972240aff596a3fa98e9fb09ddc0658fbb3

commit r13-1749-g20ab3972240aff596a3fa98e9fb09ddc0658fbb3
Author: Marco Falke 
Date:   Tue Jul 19 10:10:39 2022 +0100

libstdc++: Make __from_chars_alnum_to_val conversion explicit

The optimizations from commit r12-8175-ga54137c88061c7 introduced a
clang integer sanitizer error.

Fix this with an explicit static_cast, similar to the fix for PR 96766.

libstdc++-v3/ChangeLog:

* include/std/charconv (__from_chars_alnum_to_val): Replace
implicit conversion from int to unsigned char with explicit
cast.

[Bug analyzer/106284] False positives from -Wanalyzer-tainted-array-index with optimized conditionals

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

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

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

https://gcc.gnu.org/g:434d521d118fc7e7759b2b42bdddfa70caec637b

commit r13-1747-g434d521d118fc7e7759b2b42bdddfa70caec637b
Author: David Malcolm 
Date:   Tue Jul 19 09:53:39 2022 -0400

analyzer: log out-edge description in exploded_graph::process_node

I found this logging tweak very helpful when working on
PR analyzer/106284.

gcc/analyzer/ChangeLog:
* engine.cc (exploded_graph::process_node): Show any description
of the out-edge when logging it for consideration.

Signed-off-by: David Malcolm 

[Bug analyzer/106321] False positives from -Wanalyzer-tainted-array-index with switch with ranged cases

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

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

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

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

commit r13-1748-g2c044ff123ee573b7cd63d88f544091b7aeeb8f6
Author: David Malcolm 
Date:   Tue Jul 19 09:53:39 2022 -0400

analyzer: fix taint handling of switch statements [PR106321]

PR analyzer/106321 reports false positives from
-Wanalyzer-tainted-array-index on switch statements, seen e.g.
in the Linux kernel in drivers/vfio/pci/vfio_pci_core.c, where
vfio_pci_core_ioctl has:

|  744 | switch (info.index) {
|  | ~~  ~~
|  | |   |
|  | |   (8) ...to here
|  | (9) following âcase 0 ... 5:â branch...
|..
|  751 | case VFIO_PCI_BAR0_REGION_INDEX ...
VFIO_PCI_BAR5_REGION_INDEX:
|  | 
|  | |
|  | (10) ...to here

and then a false complaint about "use of attacker-controlled value
âinfo.indexâ in array lookup without upper-bounds checking", where
info.index has clearly had its bounds checked by the switch/case.

It turns out that when I rewrote switch handling for the analyzer in
r12-3101-g8ca7fa84a3af35, I removed notifications to state machines
about the constraints on cases.

This patch fixes that oversight by adding a new on_bounded_ranges vfunc
for region_model_context, called on switch statement edges, which calls
a new state_machine vfunc.  It implements it for the "taint" state
machine, so that it updates the "has bounds" flags at out-edges for
switch statements, based on whether the bounds from the edge appear to
actually constrain the switch index.

gcc/analyzer/ChangeLog:
PR analyzer/106321
* constraint-manager.h (bounded_ranges::get_count): New.
(bounded_ranges::get_range): New.
* engine.cc (impl_region_model_context::on_bounded_ranges): New.
* exploded-graph.h (impl_region_model_context::on_bounded_ranges):
New decl.
* region-model.cc (region_model::apply_constraints_for_gswitch):
Potentially call ctxt->on_bounded_ranges.
* region-model.h (region_model_context::on_bounded_ranges): New
vfunc.
(noop_region_model_context::on_bounded_ranges): New.
(region_model_context_decorator::on_bounded_ranges): New.
* sm-taint.cc: Include "analyzer/constraint-manager.h".
(taint_state_machine::on_bounded_ranges): New.
* sm.h (state_machine::on_bounded_ranges): New.

gcc/testsuite/ChangeLog:
PR analyzer/106321
* gcc.dg/analyzer/torture/taint-read-index-2.c: Add test coverage
for switch statements.

Signed-off-by: David Malcolm 

[Bug c++/106354] New: Diagnostic could be more user friendly

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 106354
   Summary: Diagnostic could be more user friendly
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider:

template 
constexpr bool some_check() {
return true;
}

struct C { };

static_assert(some_check::value);

This is (obviously) wrong: some_check is a function template, not a type trait,
so the correct way to validate it is some_check() and not
some_check::value. But there's a lot of code uses type traits, so this sort
of thing happens.

gcc 12 tells me:

:8:15: error: function template-id 'some_check' in
nested-name-specifier
8 | static_assert(some_check::value);
  |   ^
:2:16: note: 'template constexpr bool some_check()' declared
here
2 | constexpr bool some_check() {
  |^~

Now, technically, this is all... correct. You can't use a function template-id
in a nested-name-specifier, and the error does point me to the declaration of
the function template in question which helped me realize my error. 

But it'd be nice to provide this error in less grammatical terms (especially
since the problem here was that I didn't realize some_check was a function
template). Maybe something like:

error: can only access nested names on class types or namespaces, but
some_check is a function template.

This can probably be improved further.

[Bug target/106346] Potential regression on vectorization of left shift with constants

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

--- Comment #2 from manolis.tsamis at vrull dot eu ---
I bisected the changes from GCC 10.3 onwards and the first commit that results
in the "worse" version of the generated code is
9fc9573f9a5e9432e53c7de93985cfbd267f0309:

[2/3] [vect] Add widening add, subtract patterns

Add widening add, subtract patterns to tree-vect-patterns. Update the
widened code of patterns that detect PLUS_EXPR to also detect
WIDEN_PLUS_EXPR. These patterns take 2 vectors with N elements of size
S and perform an add/subtract on the elements, storing the results as N
elements of size 2*S (in 2 result vectors). This is implemented in the
aarch64 backend as addl,addl2 and subl,subl2 respectively. Add aarch64
tests for patterns.

[Bug fortran/106353] [suboptimal] Why is a 3D array initialized, use case 2 two-layer loop?

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

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

--- Comment #2 from Michael Matz  ---
True, but in this case it could also be emitted in a better way by the fortran
frontend.

[Bug tree-optimization/106352] SLP seems to need temporary variables

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
dst and src[12] alias but when you have the temporaries all reads happen before
the writes.

[Bug fortran/106353] [suboptimal] Why is a 3D array initialized, use case 2 two-layer loop?

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
GCC unrolls the outer loop it seems.  We fail to have a "loop reorg" pass to
flatten the loop hierarchy when that's possible.  We might do unroll-and-jam
for the outer loop (thus fuse the loops after unrolling).

[Bug c++/95454] type-level nodiscard not applied to constructors

[kyrylo.bohdanenko at gmail dot com via Gcc-bugs]

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

Kyrylo Bohdanenko  changed:

   What|Removed |Added

 CC||kyrylo.bohdanenko at gmail dot 
com

--- Comment #2 from Kyrylo Bohdanenko  ---
Still relevant as of the current trunk.

A workaround would be to declare the constructor(s) [[nodiscard]]:

struct Data {
[[nodiscard]] Data() {}
};

int main() {
Data{};
}

This actually issues a warning:

: In function 'int main()':
:6:11: warning: ignoring return value of 'Data::Data()', declared with
attribute 'nodiscard' [-Wunused-result]

Sandbox: https://godbolt.org/z/3Koj8rra7

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

--- Comment #11 from Andreas Krebbel  ---
I've tried to change our movstrict backend patterns to use a predicate on the
dest operand which enforces a subreg. However, since reload strips the subreg
away when assigning hard regs we end up with a STRICT_LOW_PART of a reg again.
At least after reload something like this should be acceptable - right?

298r.ira:
(insn 8 16 17 3 (set (strict_low_part (subreg:SI (reg/v:DI 64 [ e ]) 4))
(const_int 0 [0])) "t.cc":37:17 1485 {movstrictsi}
 (nil))

299r.reload:
(insn 8 16 17 3 (set (strict_low_part (reg:SI 11 %r11 [orig:64 e+4 ] [64]))
(mem/u/c:SI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"t.cc":37:17 1485 {movstrictsi}
 (nil))

[Bug middle-end/106331] [10/11 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] Whole |[10/11 Regression] Whole
   |array assignment of empty   |array assignment of empty
   |string segfaults with -Og   |string segfaults with -Og
   |since   |since
   |r12-2633-ge5e164effa30fd2b  |r12-2633-ge5e164effa30fd2b
  Known to fail|12.1.1  |12.1.0
  Known to work||12.1.1

--- Comment #12 from Richard Biener  ---
Fixed - as said, the latent bug makes it worth backporting further even if we
sofar lack a testcase that makes it a problem.

[Bug c/105969] [12 Regression] ICE in Floating point exception since r13-750-g10d1986aee47c5

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.1.1
  Known to fail|12.1.1  |12.1.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug tree-optimization/105971] [12 Regression] ICE in bitmap_check_index, at sbitmap.h:104

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||12.1.0
 Resolution|--- |FIXED
  Known to work||12.1.1

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/105965] [10/11 Regression] x86: single-element vectors don't have scalar FMA insns used anymore

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] x86:  |[10/11 Regression] x86:
   |single-element vectors  |single-element vectors
   |don't have scalar FMA insns |don't have scalar FMA insns
   |used anymore|used anymore
  Known to work||12.1.1

--- Comment #9 from Richard Biener  ---
Fixed on the GCC 12 branch as well.  I'm not considering to backport further to
the more mature branches.

[Bug middle-end/105604] [10/11 Regression] ICE: in tree_to_shwi with vla in struct and sprintf

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

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

Bug 105969 Summary: [12 Regression] ICE in Floating point exception since 
r13-750-g10d1986aee47c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105969

   What|Removed |Added

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

[Bug middle-end/106331] [10/11/12 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8584-g1a7200da71550e6f92da66f0b328bb20d3bcdf35
Author: Richard Biener 
Date:   Tue Jul 19 09:57:22 2022 +0200

middle-end/106331 - fix mem attributes for string op arguments

get_memory_rtx tries hard to come up with a MEM_EXPR to record
in the memory attributes but in the last fallback fails to properly
account for an unknown offset and thus, as visible in this testcase,
incorrect alignment computed from set_mem_attributes.  The following
rectifies both parts.

PR middle-end/106331
* builtins.cc (get_memory_rtx): Compute alignment from
the original address and set MEM_OFFSET to unknown when
we create a MEM_EXPR from the base object of the address.

* gfortran.dg/pr106331.f90: New testcase.

(cherry picked from commit e4ff11a8f2e80adb8ada69bf35ee6a1ab18a9c85)

[Bug c++/105946] [12 Regression] ICE in maybe_warn_pass_by_reference, at tree-ssa-uninit.cc:843

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||12.1.1
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug tree-optimization/106112] [10/11/12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r10-2711-g3ed01d5408045d80

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

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

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

https://gcc.gnu.org/g:854ab8be5d9ddfc5b4d57a5c040d1811a89fbe4f

commit r12-8582-g854ab8be5d9ddfc5b4d57a5c040d1811a89fbe4f
Author: Richard Biener 
Date:   Tue Jun 28 13:57:29 2022 +0200

tree-optimization/106112 - fix CSE from wider operation

The following fixes a mistake in looking up an extended operand
in the CSE of a truncated operation.

2022-06-28  Richard Biener  

PR tree-optimization/106112
* tree-ssa-sccvn.cc (valueized_wider_op): Properly extend
a constant operand according to its type.

* gcc.dg/torture/pr106112.c: New testcase.

(cherry picked from commit 2dbb45d6dc0d20dc159b3d8e27ebb6825074827a)

[Bug tree-optimization/106131] [10/11/12 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8583-gec9287ba9718871aa64900d6168105802e1ca941
Author: Richard Biener 
Date:   Thu Jun 30 10:33:40 2022 +0200

tree-optimization/106131 - wrong code with FRE rewriting

The following makes sure to not use the original TBAA type for
looking up a value across an aggregate copy when we had to offset
the read.

2022-06-30  Richard Biener  

PR tree-optimization/106131
* tree-ssa-sccvn.cc (vn_reference_lookup_3): Force alias-set
zero when offsetting the read looking through an aggregate
copy.

* g++.dg/torture/pr106131.C: New testcase.

(cherry picked from commit 9701432ff79926a5dd3303be3417e0bd0c24140b)

[Bug c/105969] [12 Regression] ICE in Floating point exception since r13-750-g10d1986aee47c5

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

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

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

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

commit r12-8579-g4f34a9e8d5ffcef99a212180d58718b00bdbb7d2
Author: Richard Biener 
Date:   Wed Jun 15 10:54:48 2022 +0200

tree-optimization/105969 - FPE with array diagnostics

For a [0][0] array we have to be careful when dividing by the element
size which is zero for the outermost dimension.  Luckily the division
is only for an overflow check which is pointless for array size zero.

2022-06-15  Richard Biener  

PR tree-optimization/105969
* gimple-ssa-sprintf.cc (get_origin_and_offset_r): Avoid division
by zero in overflow check.

* gcc.dg/pr105969.c: New testcase.

(cherry picked from commit edb9330c29fe8a0a0b76df6fafd6a223a4d0e41f)

[Bug rtl-optimization/105459] [12 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||12.1.1
 Resolution|--- |FIXED
  Known to fail||12.1.0

--- Comment #16 from Richard Biener  ---
Fixed.

[Bug tree-optimization/105965] [10/11/12 Regression] x86: single-element vectors don't have scalar FMA insns used anymore

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8578-g1fe7321a6ce0dcb05763c8f1850a066824516342
Author: Richard Biener 
Date:   Tue Jun 14 10:59:49 2022 +0200

middle-end/105965 - add missing v_c_e <{ el }> simplification

When we got the simplification of bit-field-ref to view-convert
we lost the ability to detect FMAs since we cannot look through

  _1 = {_10};
  _11 = VIEW_CONVERT_EXPR(_1);

the following amends the (view_convert CONSTRUCTOR) pattern
to handle this case.

2022-06-14  Richard Biener  

PR middle-end/105965
* match.pd (view_convert CONSTRUCTOR): Handle single-element
CTOR case.

* gcc.target/i386/pr105965.c: New testcase.

(cherry picked from commit 90467f0ad649d0817f9e034596a0fb85605b55af)

[Bug middle-end/106027] [11/12 Regression] ICE: 'verify_gimple' failed (error: mismatching comparison operand types) since r11-2450-g10231958fcfb13bc

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

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

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

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

commit r12-8581-g71c6baa9abc8c378a1aa913398a8f1a2277946e0
Author: Richard Biener 
Date:   Mon Jun 20 13:40:50 2022 +0200

middle-end/106027 - fix types in needle folding

The fold_to_nonsharp_ineq_using_bound folding ends up creating invalid
typed IL which confuses later foldings.  The following fixes that.

2022-06-20  Richard Biener  

PR middle-end/106027
* fold-const.cc (fold_to_nonsharp_ineq_using_bound): Use the
type of the prevailing comparison for the new comparison type.
(fold_binary_loc): Use proper types for the A < X && A + 1 > Y
to A < X && A >= Y folding.

* gcc.dg/pr106027.c: New testcase.

(cherry picked from commit 713f2fd923442b1be620a44240ddf786ae0ab476)

[Bug tree-optimization/105971] [12 Regression] ICE in bitmap_check_index, at sbitmap.h:104

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8580-g8dd1c404ec77c6d2cdaaf93d219e3250081355c0
Author: Richard Biener 
Date:   Wed Jun 15 11:27:31 2022 +0200

tree-optimization/105971 - less surprising refs_may_alias_p_2

When DSE asks whether __real a is using __imag a it gets a surprising
result when a is a FUNCTION_DECL.  The following makes sure this case
is less surprising to callers but keeping the bail-out for the
non-decl case where it is true that PTA doesn't track aliases to code
correctly.

2022-06-15  Richard Biener  

PR tree-optimization/105971
* tree-ssa-alias.cc (refs_may_alias_p_2): Put bail-out for
FUNCTION_DECL and LABEL_DECL refs after decl-decl disambiguation
to leak less surprising alias results.

* gcc.dg/torture/pr106971.c: New testcase.

(cherry picked from commit 8c2733e16ec1c0cdda3db4cdc5ad158a96a658e8)

[Bug c++/105946] [12 Regression] ICE in maybe_warn_pass_by_reference, at tree-ssa-uninit.cc:843

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

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

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

https://gcc.gnu.org/g:92aa9490315d969d6e7580fb6e8d006415877bd6

commit r12-8577-g92aa9490315d969d6e7580fb6e8d006415877bd6
Author: Richard Biener 
Date:   Tue Jun 14 11:10:13 2022 +0200

tree-optimization/105946 - avoid accessing excess args from uninit diag

uninit diagnostics uses passing via reference and access attributes
but that iterates over function type arguments which can in some
cases appearantly outrun the actual arguments leading to ICEs.
The following simply ignores not present arguments.

2022-06-14  Richard Biener  

PR tree-optimization/105946
* tree-ssa-uninit.cc (maybe_warn_pass_by_reference):
Do not look at arguments not specified in the function call.

(cherry picked from commit e07a876c07601e1f3a27420f7d055d20193c362c)

[Bug rtl-optimization/105459] [12 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8576-g4ed850a568e4d27a2df566f13843714ca80d437e
Author: Richard Biener 
Date:   Fri Jul 1 14:11:35 2022 +0200

target/105459 - allow delayed target option node fixup

The following avoids the need to massage the target optimization
node at WPA time when we fixup the optimization node, copying
FP related flags from callee to caller.  The target is already
set up to fixup, but that only works when not switching between
functions.  After fixing that the fixup is then done at LTRANS
time when materializing the function.

2022-07-01  Richard Biener  

PR target/105459
* config/i386/i386-options.cc (ix86_set_current_function):
Rebuild the target optimization node whenever necessary,
not only when the optimization node didn't change.

* gcc.dg/lto/pr105459_0.c: New testcase.

(cherry picked from commit 4c94382a132a4b2b9d020806549a006fa6764d1b)

[Bug fortran/106353] New: [suboptimal] Why is a 3D array initialized, use case 2 two-layer loop?

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 106353
   Summary: [suboptimal] Why is a 3D array initialized, use case 2
two-layer loop?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

We can see that, the icc use a two-layer loop to initialize a 3D array, and the
inner loop initialize the low 2D of the array (48552 = 1156 * 42); 
while the gfortran use 2 two-layer loop, it is obviously not efficient,
although I don't understand this logic.

test case, see detail in https://godbolt.org/z/nqKansKan
```
program small
  implicit none
  integer, parameter :: ADM_gall = 1156
  integer, parameter :: ADM_kall = 42
  integer, parameter :: ADM_lall = 2
  integer, parameter :: ADM_gall_pl = 6 
  integer, parameter :: ADM_lall_pl = 2

  real(8) :: rhogvx   (ADM_gall,   ADM_kall,ADM_lall   ) ! rho*Vx ( gam2 X
G^{1/2} )
  real(8) :: rhogvx_pl(ADM_gall_pl,ADM_kall,ADM_lall_pl)

  rhogvx=2
  !rhogvx_pl=2

  call src_flux_convergence(rhogvx, rhogvx_pl)
endprogram small
```

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #4 from Roger Sayle  ---
No, it's not PR 106278 that this PR is similar to (which concerned REG_EQUAL
notes and is now fixed), but PR 106303 (which concerns STV converting some
mentions of a TImode register/memory, and not others, due to data flow analysis
and rtx sharing) which is still open/unresolved.

My apologies for the inconvenience, figuring out why the pre-existing STV
infrastructure is making some of these counter-intuitive decisions, and what
the intended behavior should be, is taking some time.  Obviously -mno-stv is a
work around.

[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791

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

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

--- Comment #2 from Martin Liška  ---
Hm, can you see it with a cross compiler (me now)?

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |ix86_output_ssemov, at  |ix86_output_ssemov, at
   |config/i386/i386.cc:5565,   |config/i386/i386.cc:5565,
   |or ICE in   |or ICE in
   |final_scan_insn_1, at   |final_scan_insn_1, at
   |final.cc:2860 (error: could |final.cc:2860 (error: could
   |not split insn) |not split insn) since
   ||r13-1607-gc3ed9e0d6e96d869
   Last reconfirmed||2022-07-19
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r13-1607-gc3ed9e0d6e96d869.

[Bug c++/106351] ICE in fold expression involving templatized lambda

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2022-07-19

--- Comment #1 from Martin Liška  ---
Fixed in r13-1390-g07ac550393d00fca where we rejected the code:

g++ pr106351.C -c
pr106351.C: In member function ‘void C::f()’:
pr106351.C:9:15: warning: expected ‘template’ keyword before dependent template
name [-Wmissing-template-keyword]
9 | }.operator()(),
  |   ^~~~
  |   template
pr106351.C:9:30: error: expected primary-expression before ‘>’ token
9 | }.operator()(),
  |  ^
pr106351.C:9:32: error: expected primary-expression before ‘)’ token
9 | }.operator()(),
  |^
pr106351.C:9:30: error: binary expression in operand of fold-expression
9 | }.operator()(),
pr106351.C:9:30: error: operand of fold expression has no unexpanded parameter
packs

[Bug c++/106341] Template argument deduction of template value parameter crashes compiler

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Liška  ---
Fixed with r12-100-gbcd77b7b9f35bd5b.

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

[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||lissheidr.spam at gmail dot com

--- Comment #17 from Martin Liška  ---
*** Bug 106341 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/106352] New: SLP seems to need temporary variables

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

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

Bug ID: 106352
   Summary: SLP seems to need temporary variables
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eochoa at gcc dot gnu.org
  Target Milestone: ---

Hi,

I am looking at how SLP works and I'm finding this interesting case which I
believe is a bug. 

I've added all examples to this compiler explorer link:
https://godbolt.org/z/zrPKEYvds

Compiling the following function with `-O3 -fverbose-asm -march=armv8.4-a
-fno-tree-loop-vectorize -ftree-slp-vectorize`:

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;

void foo ( uint8_t *dst,  int i_dst_stride,
  uint8_t *src1, int i_src1_stride,
  uint8_t *src2, int i_src2_stride,
  int i_width, int i_height )
{
for( int y = 0; y < i_height; y++ )
{

dst[0] = ( src1[0] + src2[0] + 1 );
dst[1] = ( src1[1] + src2[1] + 1 );
dst[2] = ( src1[2] + src2[2] + 1 );
dst[3] = ( src1[3] + src2[3] + 1 );
dst[4] = ( src1[4] + src2[4] + 1 );
dst[5] = ( src1[5] + src2[5] + 1 );
dst[6] = ( src1[6] + src2[6] + 1 );
dst[7] = ( src1[7] + src2[7] + 1 );
dst  += i_dst_stride;
src1 += i_src1_stride;
src2 += i_src2_stride;
}
}

Produces the following scalar code:

ldrbw9, [x4]// MEM[(uint8_t *)src2_68], MEM[(uint8_t
*)src2_68]
add w3, w3, 1 // y, y,
ldrbw1, [x2]//, MEM[(uint8_t *)src1_67]
add w1, w1, w9// tmp138, MEM[(uint8_t *)src1_67],
MEM[(uint8_t *)src2_68]
add w1, w1, 1 // tmp141, tmp138,
strbw1, [x0]// tmp141, MEM[(uint8_t *)dst_66]
ldrbw9, [x4, 1] // MEM[(uint8_t *)src2_68 + 1B], MEM[(uint8_t
*)src2_68 + 1B]
ldrbw1, [x2, 1] //, MEM[(uint8_t *)src1_67 + 1B]
add w1, w1, w9// tmp145, MEM[(uint8_t *)src1_67 + 1B],
MEM[(uint8_t *)src2_68 + 1B]
add w1, w1, 1 // tmp148, tmp145,
strbw1, [x0, 1] // tmp148, MEM[(uint8_t *)dst_66 + 1B]
ldrbw9, [x4, 2] // MEM[(uint8_t *)src2_68 + 2B], MEM[(uint8_t
*)src2_68 + 2B]
ldrbw1, [x2, 2] //, MEM[(uint8_t *)src1_67 + 2B]
add w1, w1, w9// tmp152, MEM[(uint8_t *)src1_67 + 2B],
MEM[(uint8_t *)src2_68 + 2B]
add w1, w1, 1 // tmp155, tmp152,
strbw1, [x0, 2] // tmp155, MEM[(uint8_t *)dst_66 + 2B]
ldrbw9, [x4, 3] // MEM[(uint8_t *)src2_68 + 3B], MEM[(uint8_t
*)src2_68 + 3B]
ldrbw1, [x2, 3] //, MEM[(uint8_t *)src1_67 + 3B]
add w1, w1, w9// tmp159, MEM[(uint8_t *)src1_67 + 3B],
MEM[(uint8_t *)src2_68 + 3B]
add w1, w1, 1 // tmp162, tmp159,
strbw1, [x0, 3] // tmp162, MEM[(uint8_t *)dst_66 + 3B]
ldrbw9, [x4, 4] // MEM[(uint8_t *)src2_68 + 4B], MEM[(uint8_t
*)src2_68 + 4B]
ldrbw1, [x2, 4] //, MEM[(uint8_t *)src1_67 + 4B]
add w1, w1, w9// tmp166, MEM[(uint8_t *)src1_67 + 4B],
MEM[(uint8_t *)src2_68 + 4B]
add w1, w1, 1 // tmp169, tmp166,
strbw1, [x0, 4] // tmp169, MEM[(uint8_t *)dst_66 + 4B]
ldrbw9, [x4, 5] // MEM[(uint8_t *)src2_68 + 5B], MEM[(uint8_t
*)src2_68 + 5B]
ldrbw1, [x2, 5] //, MEM[(uint8_t *)src1_67 + 5B]
add w1, w1, w9// tmp173, MEM[(uint8_t *)src1_67 + 5B],
MEM[(uint8_t *)src2_68 + 5B]
add w1, w1, 1 // tmp176, tmp173,
strbw1, [x0, 5] // tmp176, MEM[(uint8_t *)dst_66 + 5B]
ldrbw9, [x4, 6] // MEM[(uint8_t *)src2_68 + 6B], MEM[(uint8_t
*)src2_68 + 6B]
ldrbw1, [x2, 6] //, MEM[(uint8_t *)src1_67 + 6B]
add w1, w1, w9// tmp180, MEM[(uint8_t *)src1_67 + 6B],
MEM[(uint8_t *)src2_68 + 6B]
add w1, w1, 1 // tmp183, tmp180,
strbw1, [x0, 6] // tmp183, MEM[(uint8_t *)dst_66 + 6B]
ldrbw1, [x2, 7] //, MEM[(uint8_t *)src1_67 + 7B]
add x2, x2, x6// src1, src1, _62
ldrbw9, [x4, 7] // MEM[(uint8_t *)src2_68 + 7B], MEM[(uint8_t
*)src2_68 + 7B]
add x4, x4, x5// src2, src2, _64
add w1, w1, w9// tmp187, MEM[(uint8_t *)src1_67 + 7B],
MEM[(uint8_t *)src2_68 + 7B]
add w1, w1, 1 // tmp190, tmp187,
strbw1, [x0, 7] // tmp190, MEM[(uint8_t *)dst_66 + 7B]
add x0, x0, x8// dst, dst, _61
cmp w7, w3// i_height, y
bne .L3 //,

However, adding a temporary variable between the arithmetic and the dst
variables (like such:)

typedef unsigned char uin

[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed on trunk - not sure if worth backporting to release branches.

[Bug middle-end/106331] [10/11/12 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|10.5
  Known to work|11.3.1  |13.0
   Priority|P3  |P2
  Component|fortran |middle-end
Summary|[12/13 Regression] Whole|[10/11/12 Regression] Whole
   |array assignment of empty   |array assignment of empty
   |string segfaults with -Og   |string segfaults with -Og
   |since   |since
   |r12-2633-ge5e164effa30fd2b  |r12-2633-ge5e164effa30fd2b

--- Comment #10 from Richard Biener  ---
As indicated the issue is latent, so queuing for further backports.

[Bug fortran/106331] [12/13 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-1743-ge4ff11a8f2e80adb8ada69bf35ee6a1ab18a9c85
Author: Richard Biener 
Date:   Tue Jul 19 09:57:22 2022 +0200

middle-end/106331 - fix mem attributes for string op arguments

get_memory_rtx tries hard to come up with a MEM_EXPR to record
in the memory attributes but in the last fallback fails to properly
account for an unknown offset and thus, as visible in this testcase,
incorrect alignment computed from set_mem_attributes.  The following
rectifies both parts.

PR middle-end/106331
* builtins.cc (get_memory_rtx): Compute alignment from
the original address and set MEM_OFFSET to unknown when
we create a MEM_EXPR from the base object of the address.

* gfortran.dg/pr106331.f90: New testcase.

[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-1742-g0f129766fdb687394f0eea04f69268b5cc034cda
Author: Richard Biener 
Date:   Tue Jul 19 10:02:40 2022 +0200

lto/106334 - relax assert during WPA tree merging

The dwarf2out map of tree to symbol + offset is populated too early
when streaming in trees so that when WPA tree merging decides to
recycle them the mapping prevails and if we are unlucky the same
address is used for another tree with a symbol + offset DIE to
record.  The following mitigates the resulting ICE by relaxing the
assert, allowing re-use of a slot during WPA.  Delaying the register
would be better but it's already somewhat hairy and uglifying this
further doesn't look too important right now.

PR lto/106334
* dwarf2out.cc (dwarf2out_register_external_die): Allow
map entry re-use during WPA.

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

--- Comment #30 from Richard Biener  ---
(In reply to Richard Earnshaw from comment #29)
> Thanks for having a look, yes, I was at a loss to understand how that change
> (which is before the problematic hunk would be the cause of the problem.  It
> looks like we can rule that change out as a real fix.
> 
> > The code at RTL expansion time looks reasonable (also from an aliasing POV),
> > if -fno-strict-aliasing fixes it, does -fno-schedule-insn{,2} also?
> 
> Yes, disabling scheduling also solves the issue.

There are several sched* debug counters, so maybe bisecting to the wrong
schedule via -fdbg-cnt=sched_insn might work.  I think the above strongly
hints at either RTL/target messing up alias info somewhere or scheduling not
properly computing dependences.

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

--- Comment #29 from Richard Earnshaw  ---
Thanks for having a look, yes, I was at a loss to understand how that change
(which is before the problematic hunk would be the cause of the problem.  It
looks like we can rule that change out as a real fix.

> The code at RTL expansion time looks reasonable (also from an aliasing POV),
> if -fno-strict-aliasing fixes it, does -fno-schedule-insn{,2} also?

Yes, disabling scheduling also solves the issue.