[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation

[daniel.f.starke at freenet dot de via Gcc-bugs]

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

--- Comment #8 from Daniel Starke  ---
This bug was fixes in mingw-w64. The bug fix is included since versions 8.0.1.
See
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/bb03f15f-db70-a511-a10d-396fbd8cf3c1%40126.com/#msg37259429
The bug report here can be closed.

[Bug c++/105550] Missing copy elision with conditional operator

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

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

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

struct A {
  const A *p = this;
};

struct B {
  const B *p = this;
  constexpr operator A() { return {}; }
};

struct E {
  A a1 = true ? A{} : A{};
  A a2 = true ? A{} : B{};
  A a3 = false ? A{} : B{};
  A a4 = false ? B{} : B{};
  A a5 = A{};
  A a6 = B{};
  A a7 = false ? B{} : (true ? A{} : A{});
  A a8 = false ? (true ? A{} : B{}) : (true ? A{} : A{});
};

constexpr E e{};

constexpr A
foo (A a)
{
  return a;
}

constexpr A
bar (A)
{
  return {};
}

constexpr A baz() { return {}; }

constexpr A a1 = true ? A{} : A{};
constexpr A a2 = true ? A{} : B{};
constexpr A a3 = false ? A{} : B{};
constexpr A a4 = false ? B{} : B{};
constexpr A a5 = A{};
constexpr A a6 = B{};
constexpr A a7 = false ? B{} : (true ? A{} : A{});
constexpr A a8 = false ? (true ? A{} : B{}) : (true ? A{} : A{});
constexpr A a9 = (A{});
constexpr A a10 = (true, A{});
constexpr A a11 = bar (A{});
//static_assert(a10.p == &a10, ""); // bug?
constexpr A a12 = baz ();
//static_assert(a11.p == &a11, ""); // bug?

//constexpr A a13 = foo (A{}); // error!

[Bug c++/81952] copy elision used when constructor needs to be called

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/81952] copy elision used when constructor needs to be called

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

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

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

https://gcc.gnu.org/g:62ecd2b8d46aaf96caef5fa78953216629e49ebd

commit r13-460-g62ecd2b8d46aaf96caef5fa78953216629e49ebd
Author: Marek Polacek 
Date:   Fri May 13 19:45:03 2022 -0400

c++: Add fixed test [PR81952]

This was fixed by r258755:
PR c++/81311 - wrong C++17 overload resolution.

PR c++/81952

gcc/testsuite/ChangeLog:

* g++.dg/overload/conv-op4.C: New test.

[Bug c++/81311] [7 Regression] An std::ref argument calls copy constructor instead of template constructor in C++17 mode

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

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

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

https://gcc.gnu.org/g:62ecd2b8d46aaf96caef5fa78953216629e49ebd

commit r13-460-g62ecd2b8d46aaf96caef5fa78953216629e49ebd
Author: Marek Polacek 
Date:   Fri May 13 19:45:03 2022 -0400

c++: Add fixed test [PR81952]

This was fixed by r258755:
PR c++/81311 - wrong C++17 overload resolution.

PR c++/81952

gcc/testsuite/ChangeLog:

* g++.dg/overload/conv-op4.C: New test.

[Bug c++/81952] copy elision used when constructor needs to be called

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed by

commit 2170d4b6ddca526b53e87215dbf6fab5973000c7
Author: Jason Merrill 
Date:   Wed Mar 21 23:53:19 2018 -0400

PR c++/81311 - wrong C++17 overload resolution.

* call.c (build_user_type_conversion_1): Remove C++17 code.
(conv_binds_ref_to_prvalue): New.
(build_over_call): Handle C++17 copy elision.
(build_special_member_call): Only do C++17 copy elision here if the
argument is already the right type.

From-SVN: r258755

Adjusted test:

template 
struct opt {
opt() { }
opt(opt const& ) { __builtin_abort (); }
opt(opt&& ) { __builtin_abort (); }

template 
opt(U&& ) { }
};

struct foo 
{
explicit operator opt() { __builtin_abort (); return {}; }
};

int main()
{
opt o(foo{});
}

[Bug target/105599] g++ by itself is not producing "fatal error: no input files" for darwin target

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Sandoe  ---
gcc version 12.0.1 20220429 (prerelease) [gcc-12-1rc1 revision
r12-8321-g621650f64fb6] (GCC) 
gcc-12-1-darwin mini-07-cat:gcc-git-12 isandoe$
/opt/iains/x86_64-apple-darwin19/gcc-12-1rc1/bin/gcc
gcc: fatal error: no input files
compilation terminated.

$ /opt/iains/x86_64-apple-darwin19/gcc-12-1rc1/bin/g++
ld: -rpath can only be used when targeting Mac OS X 10.5 or later
collect2: error: ld returned 1 exit status

So, we have some addition to the command line from the g++ driver that is
causing this (the actual reported problem is not significant, the reason is
that the command line is not being seen as empty by the darwin driver)

[Bug bootstrap/88633] stage2 failure due to undefined reference to libintl_dgettext on armv7l-linux-gnueabihf

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |WORKSFORME

--- Comment #2 from Jonathan Wakely  ---
Not FIXED because nothing was changed. WORKSFORME is the right resolution.

[Bug go/83308] Missing platform definitions for SH in libgo

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #22 from Ian Lance Taylor  ---
Yes, closing this issue.

[Bug target/105599] g++ by itself is not producing "fatal error: no input files" for darwin target

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

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

--- Comment #2 from Iain Sandoe  ---
hmm .. that issue had been found and fixed, I will have to check what happened.

[Bug go/83308] Missing platform definitions for SH in libgo

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #21 from Eric Gallager  ---
(In reply to Ian Lance Taylor from comment #20)
> This will be in GCC 8.
> 
> Backports to GCC 7 are fine with me but I'm not going to do them myself.

GCC 7 branch is closed now, isn't it?

[Bug target/105599] g++ by itself is not producing "fatal error: no input files" for darwin target

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |target
   Keywords||diagnostic
Summary|g++ binary: undefined   |g++ by itself is not
   |symbols _main referenced|producing "fatal error: no
   |from __start in crt1.0  |input files" for darwin
   ||target
 Target||x86_64-darwin*
   Severity|normal  |trivial

--- Comment #1 from Andrew Pinski  ---
On Linux this produces:
apinski@xeond:~/src/p4/octeontxkpu$ ~/upstream-gcc/bin/g++
g++: fatal error: no input files
compilation terminated.

So it is a darwin specific issue but it is a minor one as it is just a
diagnostic issue with invalid invocation anyways.

[Bug bootstrap/88633] stage2 failure due to undefined reference to libintl_dgettext on armv7l-linux-gnueabihf

[dclarke at blastwave dot org via Gcc-bugs]

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

Dennis Clarke  changed:

   What|Removed |Added

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

--- Comment #1 from Dennis Clarke  ---

I have never seen this again and I have since been able to do a
full bootstrap of gcc 12.1.0 on the very same armv7l hardware.

May as well close this as "fixed".


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

[Bug lto/105600] ICE with LTO when building Mumble from git on arm64

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

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

--- Comment #1 from Andrew Pinski  ---
>One issue is it seems like I can't find a way to keep all the temporary files 
>required.

-save-temps is the best option there.
Also see
https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs for
maybe better help of reducing the testcase.

[Bug libbacktrace/105590] GCC should give backtraces on Darwin when it ICEs

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88745

--- Comment #2 from Eric Gallager  ---
Was thinking this was a duplicate of bug 88745 but that's already supposed to
be fixed, so maybe there's something else going on...

[Bug tree-optimization/83907] missing strlen optimization for non-zero memset followed by a nul byte store

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r13-455-g1fe04c497d5a16baee6af48a0b08ca99b75724e4
Author: Roger Sayle 
Date:   Fri May 13 22:20:16 2022 +0100

PR tree-optimization/83907: Improved memset handling in strlen pass.

This patch implements the missed optimization enhancement PR 83907,
by handling memset with a constant byte value in tree-ssa's strlen
optimization pass.  Effectively, this treats memset(dst,'x',3) as
it would memcpy(dst,"xxx",3).

This patch also includes a tweak to handle_store to address another
missed optimization observed in the related test case pr83907-2.c.
The consecutive byte stores to memory get coalesced into a vector
write of a vector const, but unfortunately tree-ssa-strlen's
handle_store didn't previously handle the (unusual) case where the
stored "string" starts with a zero byte but also contains non-zero
bytes.

2022-05-13  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/83907
* tree-ssa-strlen.cc (handle_builtin_memset): Record a strinfo
for memset with an constant char value.
(handle_store): Improved handling of stores with a first byte
of zero, but not storing_all_zeros_p.

gcc/testsuite/ChangeLog
PR tree-optimization/83907
* gcc.dg/tree-ssa/pr83907-1.c: New test case.
* gcc.dg/tree-ssa/pr83907-2.c: New test case.

[Bug lto/105600] New: ICE with LTO when building Mumble from git on arm64

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 105600
   Summary: ICE with LTO when building Mumble from git on arm64
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Reported this downstream at https://bugs.gentoo.org/843974 initially.

Apologies for not being able to give more information yet. I'm familiar with
reducing "normal" ICEs but I'm getting stuck with how to get more info because
of LTO.

One issue is it seems like I can't find a way to keep all the temporary files
required.

The bug seems similar to bug 102067 (same stacktrace?).

ICE occurs when building Mumble from their git repo
(https://github.com/mumble-voip/mumble) at
4f50172c5c8bc7c425efb350377106d3e83a7e79.

Needs LTO.

Occurs on arm64 with GCC 11.3.0 and GCC 12.1.0.

I've reduced it down to:
```
$ /usr/bin/c++ -freport-bug -flto=99 -o /dev/null -O2 -fsanitize=undefined -O3
-DNDEBUG -Wl,-z,relro -Wl,-z,now
/root/mumble/build/src/tests/TestSettingsJSONSerialization/CMakeFiles/TestSettingsJSONSerialization.dir/TestSettingsJSONSerialization.cpp.o
/root/mumble/build/src/tests/TestSettingsJSONSerialization/../../mumble/CMakeFiles/mumble_client_object_lib.dir/JSONSerialization.cpp.o
during IPA pass: icf
lto1: internal compiler error: Segmentation fault
0xb13af3 crash_signal
/usr/src/debug/sys-devel/gcc-12.1.0/gcc-12.1.0/gcc/toplev.cc:322
0xdc3e64 varpool_node::get_constructor()
/usr/src/debug/sys-devel/gcc-12.1.0/gcc-12.1.0/gcc/varpool.cc:300
0x15b8f53 ipa_icf::sem_variable::equals(ipa_icf::sem_item*,
hash_map, ipa_icf::sem_item*>
>&)
/usr/src/debug/sys-devel/gcc-12.1.0/gcc-12.1.0/gcc/ipa-icf.cc:1695
0x15b9f67 ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool)
/usr/src/debug/sys-devel/gcc-12.1.0/gcc-12.1.0/gcc/ipa-icf.cc:2732
0x15c0683 ipa_icf::sem_item_optimizer::execute()
/usr/src/debug/sys-devel/gcc-12.1.0/gcc-12.1.0/gcc/ipa-icf.cc:2464
0x15c1d6f ipa_icf_driver
/usr/src/debug/sys-devel/gcc-12.1.0/gcc-12.1.0/gcc/ipa-icf.cc:3600
0x15c1d6f ipa_icf::pass_ipa_icf::execute(function*)
/usr/src/debug/sys-devel/gcc-12.1.0/gcc-12.1.0/gcc/ipa-icf.cc:3647
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/c++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../aarch64-unknown-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

What more information do you need? I can give access to the environment if
required. Cheers.

[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

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

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

--- Comment #2 from Jonathan Wakely  ---
Might be due to the changes in r253417

[Bug c++/105599] New: g++ binary: undefined symbols _main referenced from __start in crt1.0

[mario_grgic at hotmail dot com via Gcc-bugs]

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

Bug ID: 105599
   Summary: g++ binary: undefined symbols _main referenced from
__start in crt1.0
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario_grgic at hotmail dot com
  Target Milestone: ---

I have compiled gcc 12.1.0 from source on macOS 10.15.7 (Catalina) with XCode
12.1. I used the following configuration:

```
../configure --prefix=/usr/local --with-gmp=/usr/local --with-mpfr=/usr/local
--with-mpc=/usr/local --with-isl-prefix=/usr/local --with-cloog=/usr/local
--enable-checking=release --enable-languages=c,c++,fortran
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
--with-system-zlib --with-zsstd=/usr/local --disable-multilib --disable-nls 

```

Everything builds and installs correctly. gcc and other binaries work, however
invoking g++ without any arguments produces

```
$ /usr/local/bin/g++
Undefined symbols for architecture x86_64:
  "_main", referenced from:
  __start in crt1.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
```

Note that g++ works correctly and compiles and produces working binaries when
invoked with correct arguments.

Similar thing happens with c++ binary.

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[egor.pugin at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Egor Pugin  ---
Iain, any chance of publishing your blocks patches as is?

Also what's the status of apple m1 support?
As I understand homebrew's gcc uses your patches, but I met blocks errors when
building cmake in file that includes apple frameworks.

[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

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

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

Jason Merrill  changed:

   What|Removed |Added

  Component|c++ |libstdc++
Summary|[12/13 Regression] False|[12/13 Regression] warning
   |warning "potential null |"potential null pointer
   |pointer dereference" raised |dereference" raised when
   |when using  |using istreambuf_iterator
   |istreambuf_iterator and any |and any "-O" flag
   |"-O" flag   |
 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
The theory of the warning seems to be that if istreambuf_iterator::_M_get,
called from operator* for *__beg in _M_construct, hits EOF, it clears _M_sbuf,
and then ++__beg will try to refer to members of the now-null __beg._M_sbuf. 
At first glance, this seems like a plausible theory.  Why does _M_get clear
_M_sbuf?

  int_type
  _M_get() const
  {
int_type __ret = _M_c;
if (_M_sbuf && _S_is_eof(__ret) && _S_is_eof(__ret = _M_sbuf->sgetc()))
  _M_sbuf = 0;
return __ret;
  }

[Bug c++/91706] [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782

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

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

Bug 101078 Summary: [9/10 Regression] Rejected code since 
r12-1272-gf07edb5d7f3e7721
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101078

   What|Removed |Added

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

[Bug c++/101078] [9/10 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #10 from Jason Merrill  ---
Fixed for 9.5/10.4/11.2/12.

[Bug c++/101078] [9/10 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

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

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

commit r9-10180-g5b98dd6703aa1c4aa54de7b6079fd3dc39f7e66d
Author: Jason Merrill 
Date:   Wed Jun 16 16:09:59 2021 -0400

c++: static memfn from non-dependent base [PR101078]

After my patch for PR91706, or before that with the qualified call,
tsubst_baselink returned a BASELINK with BASELINK_BINFO indicating a base
of
a still-dependent derived class.  We need to look up the relevant base
binfo
in the substituted class.

PR c++/101078

gcc/cp/ChangeLog:

* pt.c (tsubst_baselink): Update binfos in non-dependent case.

gcc/testsuite/ChangeLog:

* g++.dg/template/access39.C: New test.

[Bug c++/105589] [12/13 Regression] [ICE] templated type alias over std::array with bound type in template function fails

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/101078] [9/10 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

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

https://gcc.gnu.org/g:259852261ed0044af584da91d30ae80f069a77c8

commit r10-10739-g259852261ed0044af584da91d30ae80f069a77c8
Author: Jason Merrill 
Date:   Wed Jun 16 16:09:59 2021 -0400

c++: static memfn from non-dependent base [PR101078]

After my patch for PR91706, or before that with the qualified call,
tsubst_baselink returned a BASELINK with BASELINK_BINFO indicating a base
of
a still-dependent derived class.  We need to look up the relevant base
binfo
in the substituted class.

PR c++/101078

gcc/cp/ChangeLog:

* pt.c (tsubst_baselink): Update binfos in non-dependent case.

gcc/testsuite/ChangeLog:

* g++.dg/template/access39.C: New test.

[Bug fortran/105582] ICE on procedure pointer assignment inside block

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  All versions since at least gcc-7 ICE.
No ICE without the enclosing block.

[Bug fortran/105230] [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634

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

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

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

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

commit r12-8375-g0b9bdcf6857b48bb7a147a9778963c942ecb2dd9
Author: Harald Anlauf 
Date:   Tue May 10 23:41:57 2022 +0200

Fortran: fix error recovery on invalid array section

gcc/fortran/ChangeLog:

PR fortran/105230
* expr.cc (find_array_section): Correct logic to avoid NULL
pointer dereference on invalid array section.

gcc/testsuite/ChangeLog:

PR fortran/105230
* gfortran.dg/pr105230.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit 0acdbe29f66017fc5cca40dcbd72a0dd41491d07)

[Bug target/105552] munmap_chunk(): invalid pointer in __gmp_default_free on ia64

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

matoro  changed:

   What|Removed |Added

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

--- Comment #2 from matoro  ---
While trying to get a better stacktrace, I reduced the optimizations on
mpfr/gmp.  Turns out I forgot I had gmp at -O3.  Reducing it to -O2 solves the
issue.

[Bug c/105597] ice in type, at value-range.h:223

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Macleod  ---
fixed.

[Bug c/105597] ice in type, at value-range.h:223

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r13-449-ge97e99296505e6015bc9e281364818bb89ca8a49
Author: Andrew MacLeod 
Date:   Fri May 13 13:11:18 2022 -0400

Check operand for type, not LHS.

When folding, the LHS has not been set, so we should be checking the type
of
op1.  We should also make sure op1 is not undefined.

PR tree-optimization/105597
gcc/
* range-op.cc (operator_minus::lhs_op1_relation): Use op1 instead
of the lhs and make sure it is not undefined.
gcc/testsuite/
* gcc.dg/pr105597.c: New.

[Bug c++/99066] [9 Regression] non-weak definition emitted for explicit instantiation declaration

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug c++/105265] [9 Regression] temporary object not destructed causing memory leaks

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #13 from Jason Merrill  ---
Fixed for 9.5/10.4/11.4/12.

[Bug c/105598] [11 Regression] Flag -O2 causes code to misbehave

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.4
   Keywords||wrong-code
Summary|Flag -O2 causes code to |[11 Regression] Flag -O2
   |misbehave   |causes code to misbehave
 Status|UNCONFIRMED |NEW
   Priority|P3  |P2
 Ever confirmed|0   |1
   Last reconfirmed||2022-05-13
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This went away with r12-3918-g5b8b1522e04adc20980f396571be1929a32d148a
on the trunk and started r11-3772-gc8fd2be174a15ff154a3102decb0e643f67cad02
typedef struct { unsigned int num; } info_t;
typedef struct { unsigned int flag, type; } block_t;
info_t info;
block_t blocks[] = { {2,0}, {3,0}, {1,0}, {1,0} };

static block_t *
f (info_t *i, block_t *b) {
  while (1) {
unsigned int is_last = b->flag & 0x01;
i->num++;
if (b->flag & 0x02) {
  if (b->type != 0x1) b->type = b->type;
  b = f (i, b+1);
}
if (is_last)
  break;
b++;
  }
  return b;
}

int
main () {
  f(&info, &blocks[0]);
  if (info.num != 4)
__builtin_abort ();
}

[Bug c++/99066] [9 Regression] non-weak definition emitted for explicit instantiation declaration

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

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

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

https://gcc.gnu.org/g:950a97a5039c7b96602edfdf8984b5800f5837f3

commit r9-10179-g950a97a5039c7b96602edfdf8984b5800f5837f3
Author: Jason Merrill 
Date:   Sun Apr 4 23:32:32 2021 -0400

c++: extern template and static data member [PR99066]

'extern template' should mean that the relevant symbols are never emitted.
But in this case we were assuming that DECL_EXTERNAL was already set on the
variable, so we just needed to clear DECL_NOT_REALLY_EXTERN.  Since
DECL_EXTERNAL was not set, we emitted a definition of npos.

gcc/cp/ChangeLog:

PR c++/99066
* pt.c (mark_decl_instantiated): Set DECL_EXTERNAL.

gcc/testsuite/ChangeLog:

PR c++/99066
* g++.dg/cpp0x/extern_template-6.C: New test.

[Bug c++/100838] [11 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291

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

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

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

https://gcc.gnu.org/g:200d477d3cb1593dbaa7739c6270e0a7f6c564cf

commit r9-10178-g200d477d3cb1593dbaa7739c6270e0a7f6c564cf
Author: Jason Merrill 
Date:   Mon May 31 12:36:25 2021 -0400

c++: missing dtor with -fno-elide-constructors [PR100838]

tf_no_cleanup only applies to the outermost TARGET_EXPR, and we already
clear it for nested calls in build_over_call, but in this case both
constructor calls came from convert_like, so we need to clear it in the
recursive call as well.  This revealed that we were adding an extra
ck_rvalue in direct-initialization cases where it was wrong.

PR c++/100838
PR c++/105265

gcc/cp/ChangeLog:

* call.c (convert_like_internal): Clear tf_no_cleanup when
recursing.
(build_user_type_conversion_1): Only add ck_rvalue if
LOOKUP_ONLYCONVERTING.

gcc/testsuite/ChangeLog:

* g++.dg/init/no-elide2.C: New test.
* g++.dg/cpp0x/initlist-new6.C: New test.

[Bug c++/105265] [9 Regression] temporary object not destructed causing memory leaks

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

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

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

https://gcc.gnu.org/g:200d477d3cb1593dbaa7739c6270e0a7f6c564cf

commit r9-10178-g200d477d3cb1593dbaa7739c6270e0a7f6c564cf
Author: Jason Merrill 
Date:   Mon May 31 12:36:25 2021 -0400

c++: missing dtor with -fno-elide-constructors [PR100838]

tf_no_cleanup only applies to the outermost TARGET_EXPR, and we already
clear it for nested calls in build_over_call, but in this case both
constructor calls came from convert_like, so we need to clear it in the
recursive call as well.  This revealed that we were adding an extra
ck_rvalue in direct-initialization cases where it was wrong.

PR c++/100838
PR c++/105265

gcc/cp/ChangeLog:

* call.c (convert_like_internal): Clear tf_no_cleanup when
recursing.
(build_user_type_conversion_1): Only add ck_rvalue if
LOOKUP_ONLYCONVERTING.

gcc/testsuite/ChangeLog:

* g++.dg/init/no-elide2.C: New test.
* g++.dg/cpp0x/initlist-new6.C: New test.

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

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

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

Bug 91217 Summary: [9 Regression] Returning std::array from lambda results in 
an extra copy step on return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91217

   What|Removed |Added

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

[Bug c++/91217] [9 Regression] Returning std::array from lambda results in an extra copy step on return

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug tree-optimization/105596] Loop counter widened to 128-bit unnecessarily

[peter at cordes dot ca via Gcc-bugs]

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

--- Comment #1 from Peter Cordes  ---
https://godbolt.org/z/aoG55T5Yq
gcc -O3 -m32 has the same problem with  unsigned long long total  and unsigned
i.

Pretty much identical instruction sequences in the loop for all 3 versions,
doing add/adc to increment i, for example.  (Plus a bit of spilling). 
fact_gcc_handhold still compiles without the unnecessary widening.

Perhaps should retitle to widen to a "2-register type".

IDK how easily this occurs in real-world loops with 64 and 32-bit integers on
32-bit machines, but that's probably more of a concern for wasting more clock
cycles worldwide.

[Bug c++/99643] [9 Regression] internal compiler error in build_over_call, involving array new and copy elision

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug c++/65211] [9 Regression] Type alignment lost inside templated function

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed for 9.5/10.4/11.4/12.

[Bug c++/101698] [9 Regression] Template type conversion operator from base class preferred over matching overload

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 9.5/10.4/11.4/12.

[Bug c++/101442] [9 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #10 from Jason Merrill  ---
Fixed for 9.5/10.4/11.4/12.

[Bug c++/98249] [9 Regression] Improper ADL on the `arg` in `new (arg) T`

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 9.5/10.4/11.4/12.

[Bug c++/104646] [9 Regression] ICE in cx_check_missing_mem_inits, at cp/constexpr.cc:845

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 9.5/10.4/11.4/12.

[Bug c++/59950] [9 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #12 from Jason Merrill  ---
Fixed for 9.5/10.4/11.3/12.

[Bug c/105598] New: Flag -O2 causes code to misbehave

[greenfoo at u92 dot eu via Gcc-bugs]

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

Bug ID: 105598
   Summary: Flag -O2 causes code to misbehave
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: greenfoo at u92 dot eu
  Target Milestone: ---

Created attachment 52974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52974&action=edit
Small example that triggers the issue when using -O2 in gcc 11.x

I found a situation where the "-O2" flag was causing trouble at least in
x86_64.

The attached file "example.c" code is expected to print "4" when compiled and
executed, but it would print "2" when compiled with "-02".

This happens with gcc 11.1, 11.2 and 11.3, but works correctly with gcc 10.3
and 12.1:

> $ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp gcc:10.3 gcc -o 
> example example.c && ./example
> 4 
> $ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp gcc:11.1 gcc -o 
> example example.c && ./example
> 2
> $ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp gcc:11.2 gcc -o 
> example example.c && ./example
> 2
> $ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp gcc:11.3 gcc -o 
> example example.c && ./example
> 2
> $ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp gcc:12.1 gcc -o 
> example example.c && ./example
> 4

I don't know if this deserves further investigation. If not, please feel free
to discard this bug report.

Thanks!

[Bug c++/99901] [9 Regression] static const class var implemented with constexpr doesn't emit symbols in C++17 mode

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

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

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

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

Bug 101717 Summary: [9 Regression] ICE capturing static member within stateless 
generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101717

   What|Removed |Added

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

[Bug c++/101717] [9 Regression] ICE capturing static member within stateless generic lambda

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed for 9.5/10.4/11.3/12.

[Bug c++/90664] [9 regression] noexcept confuses template argument deduction

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug c++/95870] [9 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #15 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

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

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

Bug 96311 Summary: [9 Regression] false positive for -Wunused-but-set-variable 
(const/constexpr identifier used in generic lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311

   What|Removed |Added

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

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 96311 Summary: [9 Regression] false positive for -Wunused-but-set-variable 
(const/constexpr identifier used in generic lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311

   What|Removed |Added

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

[Bug c++/96311] [9 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #12 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug c++/96673] [9 Regression] Friend class with templates and default constructor not recognized in C++14 or later

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 91933 Summary: [9 Regression] ICE: tree check: expected class 'type', have 
'exceptional' (error_mark) in build_simple_base_path, at cp/class.c:541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91933

   What|Removed |Added

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

[Bug c++/91933] [9 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_simple_base_path, at cp/class.c:541

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #12 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug c++/100032] [9/10 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 9.5/10.4/11.

[Bug c++/91217] [9 Regression] Returning std::array from lambda results in an extra copy step on return

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

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

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

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

commit r9-10177-gda999d938e516ff12b39a0aa7e8f6d97fbee60df
Author: Jason Merrill 
Date:   Sat Apr 3 01:07:36 2021 -0400

c++: NRV in lambda in template [PR91217]

tsubst_lambda_expr was producing a function with two blocks that claimed to
be the outermost block in the function body, one from the call to
start_lambda_function in tsubst_lambda_expr, and one from tsubsting the
block added by start_lambda_function when we first parsed the lambda.  This
messed with the named return value optimization, which only works for
variables in the outermost block.

gcc/cp/ChangeLog:

PR c++/91217
* pt.c (tsubst_lambda_expr): Skip the body block from
DECL_SAVED_TREE.

gcc/testsuite/ChangeLog:

PR c++/91217
* g++.dg/opt/nrv20.C: New test.

[Bug c++/99643] [9 Regression] internal compiler error in build_over_call, involving array new and copy elision

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

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

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

https://gcc.gnu.org/g:4231a43fd4ac6ccffd4d4b7cca70d45b2368cede

commit r9-10176-g4231a43fd4ac6ccffd4d4b7cca70d45b2368cede
Author: Jason Merrill 
Date:   Sat Apr 3 16:17:29 2021 -0400

c++: array new initialized from a call [PR99643]

Here the get_foo() call results in a TARGET_EXPR, which we strip in
massage_init_elt, but then when build_vec_init tries to use it to
initialize
the array element we crash because build_aggr_init expects a class rvalue
to
have a TARGET_EXPR.  So don't strip it.

The stripping was added in r206639 for PR59659, so I checked that removing
it didn't significantly increase compile time or memory usage for that
testcase; compile time was unaffected, memory usage increased by 0.4%.

gcc/cp/ChangeLog:

PR c++/99643
* typeck2.c (massage_init_elt): Don't strip TARGET_EXPR.

gcc/testsuite/ChangeLog:

PR c++/99643
* g++.dg/cpp0x/initlist-new5.C: New test.

[Bug c++/65211] [9 Regression] Type alignment lost inside templated function

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

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

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

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

commit r9-10175-g2a9658132c449e48e1c3532190c8ab72f4bbe788
Author: Jason Merrill 
Date:   Wed Apr 13 21:56:03 2022 -0400

c++: alignment of local typedef in template [PR65211]

Because common_handle_aligned_attribute only applies the alignment to the
TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it
explicitly in tsubst.

PR c++/65211

gcc/cp/ChangeLog:

* pt.c (tsubst_decl) [TYPE_DECL]: Copy TYPE_ALIGN.

gcc/testsuite/ChangeLog:

* g++.target/i386/vec-tmpl1.C: New test.

[Bug c++/101698] [9 Regression] Template type conversion operator from base class preferred over matching overload

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

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

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

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

commit r9-10174-gde0b78d1e75e9483b4550abc38b9199c96465dc5
Author: Jason Merrill 
Date:   Wed Apr 13 14:49:04 2022 -0400

c++: template conversion op [PR101698]

Asking for conversion to a dependent type also makes a BASELINK dependent.

PR c++/101698

gcc/cp/ChangeLog:

* pt.c (tsubst_baselink): Also check dependent optype.

gcc/testsuite/ChangeLog:

* g++.dg/template/conv19.C: New test.

[Bug c++/101442] [9 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO

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

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

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

https://gcc.gnu.org/g:48b8d5e028abee8869de946bbd7d24d746655d88

commit r9-10173-g48b8d5e028abee8869de946bbd7d24d746655d88
Author: Jason Merrill 
Date:   Wed Apr 13 13:23:08 2022 -0400

c++: NRV and ref-extended temps [PR101442]

This issue goes back to r83221, where the cleanup for extended ref temps
changed from being unconditional to being tied to the declaration they
formed part of the initializer for.

The named return value optimization changes the cleanup for the NRV
variable
to only run on the EH path; we don't want that change to affect temporary
cleanups.  The perform_member_init change isn't necessary (there 'decl' is
a
COMPONENT_REF), it's just for consistency.

PR c++/101442

gcc/cp/ChangeLog:

* decl.c (cp_finish_decl): Don't pass decl to push_cleanup.
* init.c (perform_member_init): Likewise.
* semantics.c (push_cleanup): Adjust comment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-nrv1.C: New test.

[Bug c++/98249] [9 Regression] Improper ADL on the `arg` in `new (arg) T`

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

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

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

https://gcc.gnu.org/g:86d50501e487597d8b97f40d1c87dfcd694a9441

commit r9-10172-g86d50501e487597d8b97f40d1c87dfcd694a9441
Author: Jason Merrill 
Date:   Mon Apr 11 13:06:05 2022 -0400

c++: operator new lookup [PR98249]

The standard says, as we quote in the comment just above, that if we don't
find operator new in the allocated type, it should be looked up in the
global scope.  This is specifically ::, not just any namespace, and we
already give an error for an operator new declared in any other namespace.

PR c++/98249

gcc/cp/ChangeLog:

* call.c (build_operator_new_call): Just look in ::.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/new3.C: New test.

[Bug c++/104646] [9 Regression] ICE in cx_check_missing_mem_inits, at cp/constexpr.cc:845

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

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

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

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

commit r9-10171-g7b4bd8dbd8d07e298528b0f033102ce8f693e739
Author: Jason Merrill 
Date:   Thu Apr 14 15:34:14 2022 -0400

c++: constexpr trivial -fno-elide-ctors [PR104646]

The constexpr constructor checking code got confused by the expansion of a
trivial copy constructor; we don't need to do that checking for defaulted
ctors, anyway.

PR c++/104646

gcc/cp/ChangeLog:

* constexpr.c (maybe_save_constexpr_fundef): Don't do extra
checks for defaulted ctors.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-fno-elide-ctors1.C: New test.

[Bug c++/59950] [9 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class

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

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

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

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

commit r9-10170-g3daf541e8fe2dd0807a3dd49a9b8c065d7d46731
Author: Jason Merrill 
Date:   Mon Jan 24 00:01:40 2022 -0500

c++: assignment to temporary [PR59950]

Given build_this of a TARGET_EXPR, cp_build_fold_indirect_ref returns the
TARGET_EXPR.  But that's the wrong value category for the result of the
defaulted class assignment operator, which returns an lvalue, so we need to
actually build the INDIRECT_REF.

PR c++/59950

gcc/cp/ChangeLog:

* call.c (build_over_call): Use cp_build_indirect_ref.

gcc/testsuite/ChangeLog:

* g++.dg/init/assign2.C: New test.

[Bug c++/99901] [9 Regression] static const class var implemented with constexpr doesn't emit symbols in C++17 mode

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

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

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

https://gcc.gnu.org/g:623842bead8452c03f2b1c6817f2a86a1d2d4d12

commit r9-10169-g623842bead8452c03f2b1c6817f2a86a1d2d4d12
Author: Jason Merrill 
Date:   Tue Apr 6 01:21:05 2021 -0400

c++: C++17 constexpr static data member linkage [PR99901]

C++17 makes constexpr static data members implicitly inline variables.  In
C++14, a subsequent out-of-class declaration is the definition.  We want to
continue emitting a symbol for such a declaration in C++17 mode, for ABI
compatibility with C++14 code that wants to refer to it.

Normally I'd distinguish in- and out-of-class declarations by looking at
DECL_IN_AGGR_P, but we never set DECL_IN_AGGR_P on inline variables.  I
think that's wrong, but don't want to mess with it so close to release.
Conveniently, we already have a test for in-class declaration earlier in
the
function.

gcc/cp/ChangeLog:

PR c++/99901
* decl.c (cp_finish_decl): mark_needed an implicitly inline
static data member with an out-of-class redeclaration.

gcc/testsuite/ChangeLog:

PR c++/99901
* g++.dg/cpp1z/inline-var9.C: New test.

[Bug c++/101717] [9 Regression] ICE capturing static member within stateless generic lambda

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

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

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

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

commit r9-10168-g7ce3d2ab2a1a144f94a3a9be716fb831cb76603b
Author: Jason Merrill 
Date:   Wed Apr 6 22:20:49 2022 -0400

c++: nested generic lambda in DMI [PR101717]

We were already checking COMPLETE_TYPE_P to recognize instantiation of a
generic lambda, but didn't consider that we might be nested in a
non-generic
lambda.

PR c++/101717

gcc/cp/ChangeLog:

* lambda.c (lambda_expr_this_capture): Check all enclosing
lambdas for completeness.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/lambda-generic-this4.C: New test.

[Bug c++/90664] [9 regression] noexcept confuses template argument deduction

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

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

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

https://gcc.gnu.org/g:45fb36bf93a7cc6506c2a12f9c4aa3981f4e6b44

commit r9-10167-g45fb36bf93a7cc6506c2a12f9c4aa3981f4e6b44
Author: Jason Merrill 
Date:   Fri Apr 2 17:07:12 2021 -0400

c++: PMF template parm and noexcept [PR90664]

The constexpr code only wants to preserve PTRMEM_CST in conversions if the
conversions are only qualification conversions; dropping noexcept counts as
a qualification adjustment in overload resolution, so let's include it
here.

gcc/cp/ChangeLog:

PR c++/90664
* cvt.c (can_convert_qual): Check fnptr_conv_p.

gcc/testsuite/ChangeLog:

PR c++/90664
* g++.dg/cpp1z/noexcept-type24.C: New test.

[Bug c++/95870] [9 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c

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

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

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

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

commit r9-10166-gcf475f6e23581b1766e508dba81171de8f81b180
Author: Jason Merrill 
Date:   Mon Apr 5 11:34:48 2021 -0400

c++: lambda in DMI in class template [PR95870]

Here enclosing_instantiation_of was failing to find a match because otctx
is
struct S and current_function_decl is S::S(), so the latter has
more
function contexts, and we end up trying to compare S() to NULL_TREE.

After spending a bit of time working on establishing the correspondence in
this case (class <=> constructor), it occurred to me that we could just use
DECL_SOURCE_LOCATION, which is unique for lambdas, since they cannot be
redeclared.  Since we're so close to release, for now I'm only doing this
for the case that was failing before.

gcc/cp/ChangeLog:

PR c++/95870
* pt.c (enclosing_instantiation_of): Compare DECL_SOURCE_LOCATION
if
there is no enclosing non-lambda function.

gcc/testsuite/ChangeLog:

PR c++/95870
* g++.dg/cpp0x/lambda/lambda-nsdmi10.C: New test.

[Bug c++/96311] [9 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)

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

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

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

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

commit r9-10165-gaa3e2a211933efaeb6ecd0a69f196606b8a40b43
Author: Jason Merrill 
Date:   Mon Apr 5 16:22:51 2021 -0400

c++: -Wunused, constant, and generic lambda [PR96311]

We never called mark_use for a return value in a function with dependent
return type.  In that situation we don't know if the use is as an rvalue or
lvalue, but we can use mark_exp_read instead.

gcc/cp/ChangeLog:

PR c++/96311
* typeck.c (check_return_expr): Call mark_exp_read in dependent
case.

gcc/testsuite/ChangeLog:

PR c++/96311
* g++.dg/cpp1y/lambda-generic-Wunused.C: New test.

[Bug c++/96673] [9 Regression] Friend class with templates and default constructor not recognized in C++14 or later

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10 Regression] Friend|[9 Regression] Friend class
   |class with templates and|with templates and default
   |default constructor not |constructor not recognized
   |recognized in C++14 or  |in C++14 or later
   |later   |

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

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

commit r9-10164-ge0cc2713a4076edd4f20b80b0fe217c9ab1676b2
Author: Jason Merrill 
Date:   Tue Apr 6 15:13:02 2021 -0400

c++: access checking in aggregate initialization [PR96673]

We were deferring access checks while parsing B{}, didn't adjust that
when we went to instantiate the default member initializer for B::c,
deferred access checking for C::C, and then checked it after parsing
B{}, back in the main() context which has no access.  We need to do
the
access checks in the class context of the DMI.

I tried fixing this in push_to/pop_from_top_level, but that caused several
regressions.

gcc/cp/ChangeLog:

PR c++/96673
* init.c (get_nsdmi): Don't defer access checking.

gcc/testsuite/ChangeLog:

PR c++/96673
* g++.dg/cpp1y/nsdmi-aggr13.C: New test.

[Bug c++/91933] [9 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_simple_base_path, at cp/class.c:541

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

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

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

https://gcc.gnu.org/g:370440f9f9860b59686138cf5213601cf6dda812

commit r9-10163-g370440f9f9860b59686138cf5213601cf6dda812
Author: Jason Merrill 
Date:   Mon Apr 12 17:43:51 2021 -0400

c++: constexpr, inheritance, and local class [PR91933]

Here we complained about referring to nm3 from the local class member
function because referring to the base class subobject involved taking the
variable's address.  Let's shortcut this case to avoid that.

gcc/cp/ChangeLog:

PR c++/91933
* class.c (build_base_path): Shortcut simple non-pointer case.

gcc/testsuite/ChangeLog:

PR c++/91933
* g++.dg/cpp0x/constexpr-base7.C: New test.

[Bug c++/100032] [9/10 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template

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

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

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

https://gcc.gnu.org/g:945c2afcb390dd040510ee7a2dc996ad204031c5

commit r9-10162-g945c2afcb390dd040510ee7a2dc996ad204031c5
Author: Jason Merrill 
Date:   Tue Apr 13 14:49:29 2021 -0400

c++: alias template equivalence and cv-quals [PR100032]

We also need to check that the cv-qualifiers are the same.

gcc/cp/ChangeLog:

PR c++/100032
* pt.c (get_underlying_template): Compare TYPE_QUALS.

gcc/testsuite/ChangeLog:

PR c++/100032
* g++.dg/cpp0x/alias-decl-equiv1.C: New test.

[Bug c++/67184] Missed optimization with C++11 final specifier

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

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

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

https://gcc.gnu.org/g:30a100abe48cebcdf3d685e856850d4192f05ad9

commit r9-10161-g30a100abe48cebcdf3d685e856850d4192f05ad9
Author: Jakub Jelinek 
Date:   Fri Jul 5 22:51:44 2019 +0200

re PR c++/67184 (Missed optimization with C++11 final specifier)

PR c++/67184
PR c++/69445
* call.c (build_new_method_call_1): Remove set but not used
variable
binfo.

[Bug tree-optimization/69445] Fail to devirtualize call to base class function even though derived class type is 'final'

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

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

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

https://gcc.gnu.org/g:30a100abe48cebcdf3d685e856850d4192f05ad9

commit r9-10161-g30a100abe48cebcdf3d685e856850d4192f05ad9
Author: Jakub Jelinek 
Date:   Fri Jul 5 22:51:44 2019 +0200

re PR c++/67184 (Missed optimization with C++11 final specifier)

PR c++/67184
PR c++/69445
* call.c (build_new_method_call_1): Remove set but not used
variable
binfo.

[Bug c/105597] ice in type, at value-range.h:223

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Confirmed then.

[Bug c/105597] ice in type, at value-range.h:223

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Reduced C code seems to be:

typedef struct {
  int allocated;
} vvec;
int vvneeds_want, mgpssort;
void vvinit(vvec *v, int minelems) { v->allocated = -minelems; }
void vvneeds(vvec *v, int needed) {
  if (needed > v->allocated)
if (v->allocated < 0)
  ;
else {
  int next = v->allocated + (v->allocated >> 1);
  vvneeds_want = next;
}
}
void mgpssort_1() {
  vvinit(&mgpssort, mgpssort_1);
  vvneeds(&mgpssort, mgpssort_1);
}

[Bug fortran/105594] -Wuse-without-only issued for any submodule

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-05-13
 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
This patch suppresses the warning and allows the code to compile.

diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
index 85aa153bd77..98c056ac7e5 100644
--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.cc
@@ -7261,7 +7261,7 @@ gfc_use_module (gfc_use_list *module)
   only_flag = module->only_flag;
   current_intmod = INTMOD_NONE;

-  if (!only_flag)
+  if (!only_flag && gfc_state_stack->state != COMP_SUBMODULE)
 gfc_warning_now (OPT_Wuse_without_only,
 "USE statement at %C has no ONLY qualifier");

[Bug c/105597] ice in type, at value-range.h:223

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #2 from Andrew Macleod  ---
Created attachment 52973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52973&action=edit
proposed patch

Fix is here.  Testing in progress.

A reduced testcase would be helpful for the testsuite when I check it in.

[Bug c++/65211] [9/10 Regression] Type alignment lost inside templated function

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

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

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

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

commit r10-10738-g4b0c04f6b1c96f9baa7620c152b28e723212f955
Author: Jason Merrill 
Date:   Wed Apr 13 21:56:03 2022 -0400

c++: alignment of local typedef in template [PR65211]

Because common_handle_aligned_attribute only applies the alignment to the
TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it
explicitly in tsubst.

PR c++/65211

gcc/cp/ChangeLog:

* pt.c (tsubst_decl) [TYPE_DECL]: Copy TYPE_ALIGN.

gcc/testsuite/ChangeLog:

* g++.target/i386/vec-tmpl1.C: New test.

[Bug c++/101698] [9/10 Regression] Template type conversion operator from base class preferred over matching overload

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

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

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

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

commit r10-10737-gf06e1ff97cb383118afed4c87dfa104e7c4b141d
Author: Jason Merrill 
Date:   Wed Apr 13 14:49:04 2022 -0400

c++: template conversion op [PR101698]

Asking for conversion to a dependent type also makes a BASELINK dependent.

PR c++/101698

gcc/cp/ChangeLog:

* pt.c (tsubst_baselink): Also check dependent optype.

gcc/testsuite/ChangeLog:

* g++.dg/template/conv19.C: New test.

[Bug c++/101442] [9/10 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO

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

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

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

https://gcc.gnu.org/g:54d1992376d7880a88778dab20a7cfe8cde32bc3

commit r10-10736-g54d1992376d7880a88778dab20a7cfe8cde32bc3
Author: Jason Merrill 
Date:   Wed Apr 13 13:23:08 2022 -0400

c++: NRV and ref-extended temps [PR101442]

This issue goes back to r83221, where the cleanup for extended ref temps
changed from being unconditional to being tied to the declaration they
formed part of the initializer for.

The named return value optimization changes the cleanup for the NRV
variable
to only run on the EH path; we don't want that change to affect temporary
cleanups.  The perform_member_init change isn't necessary (there 'decl' is
a
COMPONENT_REF), it's just for consistency.

PR c++/101442

gcc/cp/ChangeLog:

* decl.c (cp_finish_decl): Don't pass decl to push_cleanup.
* init.c (perform_member_init): Likewise.
* semantics.c (push_cleanup): Adjust comment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-nrv1.C: New test.

[Bug c++/99066] [9/10 Regression] non-weak definition emitted for explicit instantiation declaration

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

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

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

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

commit r10-10735-g20b503f1125c0b0a7f4b2bb1214d4a3cc6fd9f70
Author: Jason Merrill 
Date:   Sun Apr 4 23:32:32 2021 -0400

c++: extern template and static data member [PR99066]

'extern template' should mean that the relevant symbols are never emitted.
But in this case we were assuming that DECL_EXTERNAL was already set on the
variable, so we just needed to clear DECL_NOT_REALLY_EXTERN.  Since
DECL_EXTERNAL was not set, we emitted a definition of npos.

gcc/cp/ChangeLog:

PR c++/99066
* pt.c (mark_decl_instantiated): Set DECL_EXTERNAL.

gcc/testsuite/ChangeLog:

PR c++/99066
* g++.dg/cpp0x/extern_template-6.C: New test.

[Bug c++/91241] [9/10 Regression] internal compiler error: symtab_node::verify failed

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

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

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

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

commit r10-10734-ga86e0cadefe5a2469bb9872bb5b93017ccb23935
Author: Jason Merrill 
Date:   Mon Apr 5 22:50:44 2021 -0400

c++: mangling of lambdas in default args [PR91241]

In this testcase, the parms remembered in LAMBDA_EXPR_EXTRA_SCOPE are no
longer the parms of the FUNCTION_DECL they have as their DECL_CONTEXT, so
we
were mangling both lambdas as parm #0.  But since the parms are numbered
from right to left we don't need to need to find them in the FUNCTION_DECL,
we can measure their own DECL_CHAIN.

gcc/cp/ChangeLog:

PR c++/91241
* mangle.c (write_compact_number): Add sanity check.
(write_local_name): Use list_length for parm number.

gcc/testsuite/ChangeLog:

PR c++/91241
* g++.dg/abi/lambda-defarg1.C: New test.

[Bug c++/86355] [9/10 Regression] Internal compiler error with pack expansion and fold expression

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

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

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

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

commit r10-10733-gaa030fca4b7257656aa6bfe879d79a332b3c39ea
Author: Jason Merrill 
Date:   Wed May 26 17:38:42 2021 -0400

c++: argument pack with expansion [PR86355]

This testcase revealed that we were using PACK_EXPANSION_EXTRA_ARGS a lot
more than necessary; use_pack_expansion_extra_args_p meant to use it in the
case of corresponding arguments in different argument packs differing in
whether they are pack expansions, but it was mistakenly also returning true
for the case of a single argument pack containing both expansion and
non-expansion elements.

Surprisingly, just disabling that didn't lead to any regressions in the
testsuite; it seems other changes have prevented us getting to this point
for code that used to exercise it.  So this patch limits the check to
arguments in the same position in the packs, and asserts that we never
actually see a mismatch.

PR c++/86355

gcc/cp/ChangeLog:

* pt.c (use_pack_expansion_extra_args_p): Don't compare
args from the same argument pack.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-variadic2.C: New test.

[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Sebastian Pop :

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

commit r13-446-gbc25483c055d62f94f8c289f80843dda3c4a6ff4
Author: Sebastian Pop 
Date:   Mon Apr 18 15:13:20 2022 +

[AArch64] add barriers to ool __sync builtins

2022-05-13  Sebastian Pop  

gcc/
PR target/105162
* config/aarch64/aarch64-protos.h (atomic_ool_names): Increase
dimension
of str array.
* config/aarch64/aarch64.cc (aarch64_atomic_ool_func): Call
memmodel_from_int and handle MEMMODEL_SYNC_*.
(DEF0): Add __aarch64_*_sync functions.

gcc/testsuite/
PR target/105162
* gcc.target/aarch64/sync-comp-swap-ool.c: New.
* gcc.target/aarch64/sync-op-acquire-ool.c: New.
* gcc.target/aarch64/sync-op-full-ool.c: New.
* gcc.target/aarch64/target_attr_20.c: Update check.
* gcc.target/aarch64/target_attr_21.c: Same.

libgcc/
PR target/105162
* config/aarch64/lse.S: Define BARRIER and handle memory MODEL 5.
* config/aarch64/t-lse: Add a 5th memory model for _sync functions.

[Bug target/105576] x86: Support a machine constraint to get raw symbol name

[i at maskray dot me via Gcc-bugs]

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

--- Comment #5 from Fangrui Song  ---
(In reply to Hongtao.liu from comment #4)
> constraint "i" + "%p0"?
> 
>   asm (".pushsection .xxx,\"aw\"; .dc.a %p0; .popsection" :: "i"(addr)); //
> supported on aarch64 and riscv
>   asm (".pushsection .xxx,\"aw\"; .dc.a %p0; .popsection" :: "i"(&var)); //
> supported on aarch64

constraint "i" + "%p0" does not work with -mcmodel=large:

a.c:11:3: warning: ‘asm’ operand 0 probably does not match constraints
   11 |   asm volatile(".quad %p0" :: "i"(foo));
  |   ^~~
a.c:11:3: error: impossible constraint in ‘asm’

On aarch64, `asm volatile(".quad %0" :: "S"(foo));` works with -mcmodel=large
-fno-pic (note: PIC large code model has not been implemented).

[Bug c/105597] ice in type, at value-range.h:223

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
The bug seems to have started recently, between git hash 5b2a24ebfc0b2b4c
and 98e475a8f58ca3ba, a distance of 111 commits.

[Bug target/105593] avx512 math function raises uninitialized variable warning

[rogerio.souza at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Rogério de Souza Moraes  ---
The code attached in the previous comment triggers the "warning: '__Y' is used
uninitialized [-Wuninitialized]".

The command line to compile it is:

/grid/common/test/gcc-v12.1.0d1rh74_lnx86/bin/gcc -c -O3 -Wall ./a.C

Using "-O1/-O2/-O3" the warning below is raised:

In file included from
/grid/common/test/gcc-v12.1.0d1rh74_lnx86/lib/gcc/x86_64-redhat-linux/12.1.0/include/immintrin.h:49,
 from ./a.C:1:
In function '__m512i _mm512_permutexvar_epi64(__m512i, __m512i)',
inlined from 'void UINT512_t::ithBit(int)' at ./a.C:12:40,
inlined from 'WORD_t ithBitWORD(int) [with WORD_t = UINT512_t]' at
./a.C:27:13:
/grid/common/test/gcc-v12.1.0d1rh74_lnx86/lib/gcc/x86_64-redhat-linux/12.1.0/include/avx512fintrin.h:6994:10:
warning: '__Y' is used uninitialized [-Wuninitialized]
 6994 |   return (__m512i) __builtin_ia32_permvardi512_mask ((__v8di) __Y,
  |  ^
 6995 |  (__v8di) __X,
  |  ~
 6996 |  (__v8di)
  |  
 6997 | 
_mm512_undefined_epi32 (),
  | 
~~
 6998 |  (__mmask8) -1);
  |  ~~
/grid/common/test/gcc-v12.1.0d1rh74_lnx86/lib/gcc/x86_64-redhat-linux/12.1.0/include/avx512fintrin.h:
In function 'WORD_t ithBitWORD(int) [with WORD_t = UINT512_t]':
/grid/common/test/gcc-v12.1.0d1rh74_lnx86/lib/gcc/x86_64-redhat-linux/12.1.0/include/avx512fintrin.h:206:11:
note: '__Y' was declared here
  206 |   __m512i __Y = __Y;
  |   ^~~


When compiling with -O0, the warning does not happen, so I believe it is due to
the optimization that probably reduces the assembly code and triggers the
warning. Is it correct? If so, what would be the best approach to suppress it?
Would it be '#pragma GCC diagnostic ignored "-Wuninitialized"'?

[Bug c/105597] New: ice in type, at value-range.h:223

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 105597
   Summary: ice in type, at value-range.h:223
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 52972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52972&action=edit
C source code

For the attached C code, recent gcc trunk with flag -O2 does this:

during GIMPLE pass: vrp
mgpswindows.c: In function 'mgps_initpsdevice':
mgpswindows.c:48:5: internal compiler error: in type, at value-range.h:223
   48 | int mgps_initpsdevice()
  | ^
0x1c9b178 irange::type() const
../../trunk.git/gcc/value-range.h:223
0x1c9b178 operator_minus::lhs_op1_relation(irange const&, irange const&, irange
const&, tree_code) const
/home/dcb/gcc/working/gcc/../../trunk.git/gcc/range-op.cc:1349

I will have my usual go at reducing the code and finding a range of git
hashes where the problem starts.

[Bug target/105593] avx512 math function raises uninitialized variable warning

[rogerio.souza at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Rogério de Souza Moraes  ---
Created attachment 52971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52971&action=edit
C code to trigger the uninitialized warning

The C code attached reproduces the uninitialized warning when compiled with
-O3.

[Bug debug/105586] [11/12/13 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

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

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

--- Comment #2 from Segher Boessenkool  ---
We have

+(debug_insn 11 10 81 2 (var_location:QI u8_1 (mem/c:QI (plus:DI (unspec:DI [
+(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
+(reg:DI 2 2)
+] UNSPEC_TOCREL)
+(const_int 3 [0x3])) [1 g+3 S1 A8])) "../105586.c":11:8 -1
+ (nil))

(the first such unspec in the file), and sched1 does

+;;   0--> b  0: i  11 loc [unspec[`*.LANCHOR0',%2] 47+0x3]   
:nothing:GENERAL_REGS+0(0)FLOAT_REGS+0(0)CR_REGS+0(0)SPECIAL_REGS+0(0)

with it.  Things in debug_insns should not influence code generation.

[Bug tree-optimization/105596] New: Loop counter widened to 128-bit unnecessarily

[peter at cordes dot ca via Gcc-bugs]

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

Bug ID: 105596
   Summary: Loop counter widened to 128-bit unnecessarily
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

For  total *= i  with a u128 total and a u32 loop counter, GCC pessimizes by
widening i and doing a full 128x128 => 128-bit multiply, and having to do a
128-bit increment and compare.

uint64_t i to make it a full register width doesn't help.

unsigned __int128 fact(unsigned n){
unsigned __int128 total = n;
for (unsigned i=2 ; i < n ; i++)
total *= i;
return total;
}
// 0! = 0  isn't mathematically correct, but that's not the point

https://godbolt.org/z/W4MW9b6T3  (gcc trunk 13.0.0 20220508 (experimental) and
clang 14, which makes efficient asm for all of these.)

# gcc -O3
fact:
movl%edi, %r9d
xorl%r11d, %r11d
movq%r9, %r10   # total = n  zext into  R11:R10
cmpl$2, %edi
jbe .L7 # if n<=2 return r11:r10
movl$2, %esi# i = 2  in  RDI:RSI
xorl%edi, %edi
.L9:  # do{
movq%r11, %rcx
movq%rdi, %rdx
movq%r10, %rax
movq%r9, %r8  # copy original n to destroy later
imulq   %r10, %rdx  # 128x128 multiply with 2x imul, 1x
widening mul
imulq   %rsi, %rcx
addq%rdx, %rcx
mulq%rsi
movq%rdx, %r11  # update total in r11:r10
movq%rax, %r10
addq%rcx, %r11  # last partial product

addq$1, %rsi# i++ as a 128-bit integer
adcq$0, %rdi
xorq%rsi, %r8   #  r8 = n^i
movq%rdi, %rcx   # useless copy, we're already destroying
r8
orq %r8, %rcx# hi(i^n) | lo(i^n)
jne .L9   # }while(i != n);
.L7:
movq%r10, %rax
movq%r11, %rdx
ret

So as well as creating extra work to do, it's not even doing it very
efficiently, with multiple unnecessary mov instructions.

This doesn't seem to be x86-64 specific.  It also compiles similarly for
AArch64 and MIPS64.  For some ISAs, I'm not sure if potentially-infinite loops
are making a difference, e.g. PowerPC is hard for me to read.  RV64 has three
multiply instructions in both versions.

I haven't tested a 32-bit equivalent with uint64_t total and uint32_t i.


This anti-optimization goes back to GCC4.6.  With GCC4.5 and earlier, the above
C compiles to a tight loop with the expected mul reg + imul reg,reg and 1
register loop counter: https://godbolt.org/z/6KheaqTx4  (using __uint128_t,
since unsigned __int128 wasn't supported on GCC4.4 or 4.1)

GCC 4.1 does an inefficient multiply, but one of the chunks is a freshly
xor-zeroed register.  It's still just incrementing and comparing a 32-bit loop
counter, but widening it for a 128x128-bit multiply recipe.  GCC4.4 optimizes
away the parts that are useless for the high 64 bits of (u128)i being zero.


-

A different version compiles efficiently with GCC6 and earlier, only becoming
slow like the above with GCC7 and later.

unsigned __int128 fact_downcount(unsigned n){
unsigned __int128 total = n;
for (unsigned i=n-1 ; i > 1 ; i--)
total *= i;
return total;  // 0! = 0 isn't mathematically correct
}


-

When the loop condition is possibly always-true, GCC can't prove the loop is
non-infinite, and as usual can't widen the loop counter.  In this case, that's
a good thing:

unsigned __int128 fact_gcc_handhold(unsigned n){
unsigned __int128 total = 1;   // loop does do final n
for (unsigned i=2 ; i <= n ; i++)  // potentially infinite loop defeats
this pessimization
total *= i;
return total;  // fun fact:  0! = 1  is mathematically correct
}


fact_gcc_handhold:
cmpl$1, %edi
jbe .L4
movl$2, %ecx   # i = 2   inECX
movl$1, %eax   # total = 1  in RDX:RAX
xorl%edx, %edx
.L3: #do{
movl%ecx, %esi# copy i instead of just incrementing it
later :/

movq%rdx, %r8   # save high half of total
addl$1, %ecx  # i++
imulq   %rsi, %r8   # lo x hi cross product
mulq%rsi# lo x lo widening
addq%r8, %rdx   # 128x64-bit multiply

cmpl%ecx, %edi
jnb .L3   # }while(i < n)
ret

Allocating total in RDX:RAX is nice, putting the lo part where we need it for
mulq anyway.

[Bug sanitizer/105592] array out of bound not detected by ubsan

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

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

--- Comment #3 from Jakub Jelinek  ---
Note, the -fsanitize=bounds instrumentation is done when taking the address, at
that point the compiler doesn't know if it will be dereferenced or not, and
especially with -O0 it won't at all.  As #c2 says, this may then be caught in
ASan instead.  Or when optimizing -fsanitize=object-size can catch that too.
Or if you just return a[1];

[Bug c++/101442] [9/10/11 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO

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

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

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

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

commit r11-9995-gf9e356458d8f14b5a82f3244385ce814903fc02b
Author: Jason Merrill 
Date:   Wed Apr 13 13:23:08 2022 -0400

c++: NRV and ref-extended temps [PR101442]

This issue goes back to r83221, where the cleanup for extended ref temps
changed from being unconditional to being tied to the declaration they
formed part of the initializer for.

The named return value optimization changes the cleanup for the NRV
variable
to only run on the EH path; we don't want that change to affect temporary
cleanups.  The perform_member_init change isn't necessary (there 'decl' is
a
COMPONENT_REF), it's just for consistency.

PR c++/101442

gcc/cp/ChangeLog:

* decl.c (cp_finish_decl): Don't pass decl to push_cleanup.
* init.c (perform_member_init): Likewise.
* semantics.c (push_cleanup): Adjust comment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-nrv1.C: New test.

[Bug c++/101698] [9/10/11 Regression] Template type conversion operator from base class preferred over matching overload

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

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

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

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

commit r11-9994-g5c6577dcf1d413582775063c905d917e21bf0eba
Author: Jason Merrill 
Date:   Wed Apr 13 14:49:04 2022 -0400

c++: template conversion op [PR101698]

Asking for conversion to a dependent type also makes a BASELINK dependent.

PR c++/101698

gcc/cp/ChangeLog:

* pt.c (tsubst_baselink): Also check dependent optype.

gcc/testsuite/ChangeLog:

* g++.dg/template/conv19.C: New test.

[Bug c++/65211] [9/10/11 Regression] Type alignment lost inside templated function

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

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

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

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

commit r11-9993-ge60f7127b3282e0201a1bba8ff550dc3c3fdbe61
Author: Jason Merrill 
Date:   Wed Apr 13 21:56:03 2022 -0400

c++: alignment of local typedef in template [PR65211]

Because common_handle_aligned_attribute only applies the alignment to the
TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it
explicitly in tsubst.

PR c++/65211

gcc/cp/ChangeLog:

* pt.c (tsubst_decl) [TYPE_DECL]: Copy TYPE_ALIGN.

gcc/testsuite/ChangeLog:

* g++.target/i386/vec-tmpl1.C: New test.