[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic
[Bug target/96189] Failure to use eflags from cmpxchg on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189
Uroš Bizjak changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #5 from Uroš Bizjak ---
Hm...
Please note that peephole2 scanning require exact RTL sequences, and already
fails for e.g.:
_Bool
foo (unsigned int *x, unsigned int z)
{
unsigned int y = 0;
__atomic_compare_exchange_n (x, &y, z, 0, __ATOMIC_RELAXED,
__ATOMIC_RELAXED);
return y == 0;
}
(which is used in a couple of places throughout glibc), due to early peephole2
optimization that converts:
(insn 7 4 8 2 (set (reg:SI 0 ax [90])
(const_int 0 [0])) "cmpx0.c":5:3 75 {*movsi_internal}
to:
(insn 31 4 8 2 (parallel [
(set (reg:DI 0 ax [90])
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
Other than that, the required sequence is broken quite often by various
reloads, due to the complexity of CMPXCHG insn.
However, __atomic_compare_exchange_n returns a boolean value that is exactly
what the first function is testing, so the following two functions are
equivalent:
--cut here--
_Bool
foo (unsigned int *x, unsigned int y, unsigned int z)
{
unsigned int old_y = y;
__atomic_compare_exchange_n (x, &y, z, 0, __ATOMIC_RELAXED,
__ATOMIC_RELAXED);
return y == old_y;
}
_Bool
bar (unsigned int *x, unsigned int y, unsigned int z)
{
return __atomic_compare_exchange_n (x, &y, z, 0, __ATOMIC_RELAXED,
__ATOMIC_RELAXED);
}
--cut here--
I wonder, if the above transformation can happen on the tree level, so it would
apply universally for all targets, and would also handle CMPXCHG[8,16]B
doubleword instructions on x86 targets.
Let's ask experts.
[Bug target/96189] Failure to use eflags from cmpxchg on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189
--- Comment #6 from rguenther at suse dot de ---
On July 16, 2020 9:05:52 AM GMT+02:00, ubizjak at gmail dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189
>
>Uroš Bizjak changed:
>
> What|Removed |Added
>
> CC||jakub at gcc dot gnu.org,
> ||rguenth at gcc dot gnu.org
> Status|RESOLVED|REOPENED
> Resolution|FIXED |---
>
>--- Comment #5 from Uroš Bizjak ---
>Hm...
>
>Please note that peephole2 scanning require exact RTL sequences, and
>already
>fails for e.g.:
>
>_Bool
>foo (unsigned int *x, unsigned int z)
>{
> unsigned int y = 0;
> __atomic_compare_exchange_n (x, &y, z, 0, __ATOMIC_RELAXED,
>__ATOMIC_RELAXED);
> return y == 0;
>}
>
>(which is used in a couple of places throughout glibc), due to early
>peephole2
>optimization that converts:
>
>(insn 7 4 8 2 (set (reg:SI 0 ax [90])
>(const_int 0 [0])) "cmpx0.c":5:3 75 {*movsi_internal}
>
>to:
>
>(insn 31 4 8 2 (parallel [
>(set (reg:DI 0 ax [90])
>(const_int 0 [0]))
>(clobber (reg:CC 17 flags))
>
>Other than that, the required sequence is broken quite often by various
>reloads, due to the complexity of CMPXCHG insn.
>
>However, __atomic_compare_exchange_n returns a boolean value that is
>exactly
>what the first function is testing, so the following two functions are
>equivalent:
>
>--cut here--
>_Bool
>foo (unsigned int *x, unsigned int y, unsigned int z)
>{
> unsigned int old_y = y;
> __atomic_compare_exchange_n (x, &y, z, 0, __ATOMIC_RELAXED,
>__ATOMIC_RELAXED);
> return y == old_y;
>}
>
>_Bool
>bar (unsigned int *x, unsigned int y, unsigned int z)
>{
> return __atomic_compare_exchange_n (x, &y, z, 0, __ATOMIC_RELAXED,
>__ATOMIC_RELAXED);
>}
>--cut here--
>
>I wonder, if the above transformation can happen on the tree level, so
>it would
>apply universally for all targets, and would also handle CMPXCHG[8,16]B
>doubleword instructions on x86 targets.
>
>Let's ask experts.
In principle value numbering can make the comparison available at the cmpxchg
and replace the later comparison. We've pondered with this trick for memcpy
results for example.
Richard.
[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #7 from Sergei Trofimovich ---
Similar example from xmms2 project, dynamic_cast<> version:
#include
// main loop interface
struct I {
virtual void run();
};
struct M : public I {
virtual void run();
void setup_M();
};
struct Client
{
// In real code Client() always initializes mainloop_ with non-NULL 'M*'
pointer;
I* mainloop_;
Client();
void run_client();
void connect() {
if (mainloop_ && typeid(mainloop_) == typeid(M)) {
dynamic_cast(mainloop_)->setup_M( );
}
}
};
$ LANG=C x86_64-pc-linux-gnu-g++-11.0.0 -c bug.cpp -o a.o -Werror=nonnull
bug.cpp: In member function 'void Client::connect()':
bug.cpp:22:49: error: 'this' pointer null [-Werror=nonnull]
22 | dynamic_cast(mainloop_)->setup_M( );
| ^
bug.cpp:10:10: note: in a call to non-static member function 'void
M::setup_M()'
10 | void setup_M();
| ^~~
cc1plus: some warnings being treated as errors
Original code is from
https://github.com/xmms2/xmms2-devel/blob/dedc33d7408e140bce714c2c3eb5bcc793f1af6c/src/clients/lib/xmmsclient%2B%2B/client.cpp#L85
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 --- Comment #7 from Matthias Klose --- Please could you elaborate how this should be revisited?
[Bug c++/95491] coroutines: awaited temporaries are never destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95491 --- Comment #1 from Max Kellermann --- Bug still occurs with "gcc version 10.1.0 (Debian 10.1.0-6)"
[Bug other/96217] New: undefined reference to `_Unwind_Resume'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96217 Bug ID: 96217 Summary: undefined reference to `_Unwind_Resume' Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: legarrec.vincent at gmail dot com Target Milestone: --- Created attachment 48880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48880&action=edit glibc-build.zip I work on Gentoo. I compiled gcc with -O0 and I was able to complete the build (I didn't executed tests). But I try to compile glibc with gcc built with -O0. The log says : /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/32/libgcc.a(_divdi3.o): in function `__divdi3': /var/tmp/portage/sys-devel/gcc-10.1.0-r2/work/gcc-10.1.0/libgcc/libgcc2.c:1246: undefined reference to `_Unwind_Resume' /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/32/libgcc.a(_divdi3.o):(.data.rel.local.DW.ref.__gcc_personality_v0[DW.ref.__gcc_personality_v0]+0x0): undefined reference to `__gcc_personality_v0' /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/32/libgcc.a(_moddi3.o): in function `__moddi3': /var/tmp/portage/sys-devel/gcc-10.1.0-r2/work/gcc-10.1.0/libgcc/libgcc2.c:1269: undefined reference to `_Unwind_Resume' A simple test case is really hard because gcc successfully built small other packages and I have no idea why I have this "undefined reference". I was able to compiling gcc with -O2 (with gcc built with -O0) then to build glibc successfully. Please find enclosed the build.log of glibc.
[Bug c++/96218] New: DR 2032: Default template-arguments of variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96218 Bug ID: 96218 Summary: DR 2032: Default template-arguments of variable templates Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- // DR 2032 - Default template-arguments of variable templates // [temp.param]/14: If a template-parameter of a class template, variable // template, or alias template has a default template-argument, each subsequent // template-parameter shall either have a default template-argument supplied or // be a template parameter pack. template // error T vt; // [temp.param]/14: If a template-parameter of a primary class template, // primary variable template, or alias template is a template parameter pack, // it shall be the last template-parameter. template // error int vt2; Here we should give two errors under DR 2032, but we only give the first one.
[Bug c++/96218] DR 2032: Default template-arguments of variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96218 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-07-16
[Bug libgcc/96001] aarch64: bti is missing from lse.S when built with branch protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96001 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:315a7e8cca13530d4d3c5b5f39775c7a62877f3d commit r9-8742-g315a7e8cca13530d4d3c5b5f39775c7a62877f3d Author: Szabolcs Nagy Date: Thu Jul 2 17:11:56 2020 +0100 aarch64: Fix BTI support in libgcc [PR96001] lse.S did not have the GNU property note markup and the BTI c instructions that are necessary when it is built with branch protection. The notes are only added when libgcc is built with branch protection, because old linkers mishandle the note (merge them incorrectly or emit warnings), the BTI instructions are added unconditionally. Note: BTI c is only necessary at function entry if the function may be called indirectly, currently lse functions are not called indirectly, but BTI is added for ABI reasons e.g. to allow linkers later to emit stub code with indirect jump. 2020-07-09 Szabolcs Nagy libgcc/ChangeLog: PR target/96001 * config/aarch64/lse.S: Add BTI marking and related definitions, and add BTI c to function entries. (cherry picked from commit f0f62fa0320762119446893c67cb52934bc5a05e)
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:a0ae6c76529ccee9ee53c32dc115aec263ee633b commit r9-8745-ga0ae6c76529ccee9ee53c32dc115aec263ee633b Author: Szabolcs Nagy Date: Thu Jun 4 13:42:16 2020 +0100 aarch64: fix __builtin_eh_return with pac-ret [PR94891] Currently __builtin_eh_return takes a signed return address, which can cause ABI and API issues: 1) pointer representation problems if the address is passed around before eh return, 2) the source code needs pac-ret specific changes and needs to know if pac-ret is used in the current frame, 3) signed address may not be representible as void * (with ilp32 abi). Using address signing to protect eh return is ineffective because the instruction sequence in the unwinder that starts from the address signing and ends with a ret can be used as a return to anywhere gadget. Using indirect branch istead of ret with bti j landing pads at the target can reduce the potential of such gadget, which also implies that __builtin_eh_return should not take a signed address. This is a big hammer fix to the ABI and API issues: it turns pac-ret off for the caller completely (not just on the eh return path). To harden the caller against ROP attacks, it should use indirect branch instead of ret, this is not attempted so the patch remains small and backportable. 2020-07-13 Szabolcs Nagy gcc/ChangeLog: PR target/94891 * config/aarch64/aarch64.c (aarch64_return_address_signing_enabled): Disable return address signing if __builtin_eh_return is used. gcc/testsuite/ChangeLog: PR target/94891 * gcc.target/aarch64/return_address_sign_1.c: Update test. (cherry picked from commit 2bc95be3bb8c8138e2e87c1c11c84bfede989d61)
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:f5cab5862172176c49814214cc7df2fa6d6b5e56 commit r9-8746-gf5cab5862172176c49814214cc7df2fa6d6b5e56 Author: Szabolcs Nagy Date: Thu Jun 4 09:33:35 2020 +0100 libgcc: fix the handling of return address mangling [PR94891] Mangling, currently only used on AArch64 for return address signing, is an internal representation that should not be exposed via __builtin_return_address return value, __builtin_eh_return handler argument, _Unwind_DebugHook handler argument. Note that a mangled address might not even fit into a void *, e.g. with AArch64 ilp32 ABI the return address is stored as 64bit, so the mangled return address cannot be accessed via _Unwind_GetPtr. This patch changes the unwinder hooks as follows: MD_POST_EXTRACT_ROOT_ADDR is removed: root address comes from __builtin_return_address which is not mangled. MD_POST_EXTRACT_FRAME_ADDR is renamed to MD_DEMANGLE_RETURN_ADDR, it now operates on _Unwind_Word instead of void *, so the hook should work when return address signing is enabled on AArch64 ilp32. (But for that __builtin_aarch64_autia1716 should be fixed to operate on 64bit input instead of a void *.) MD_POST_FROB_EH_HANDLER_ADDR is removed: it is the responsibility of __builtin_eh_return to do the mangling if necessary. 2020-07-13 Szabolcs Nagy libgcc/ChangeLog: PR target/94891 * config/aarch64/aarch64-unwind.h (MD_POST_EXTRACT_ROOT_ADDR): Remove. (MD_POST_FROB_EH_HANDLER_ADDR): Remove. (MD_POST_EXTRACT_FRAME_ADDR): Rename to ... (MD_DEMANGLE_RETURN_ADDR): This. (aarch64_post_extract_frame_addr): Rename to ... (aarch64_demangle_return_addr): This. (aarch64_post_frob_eh_handler_addr): Remove. * unwind-dw2.c (uw_update_context): Demangle return address. (uw_frob_return_addr): Remove. (cherry picked from commit b097c7a27fb0796b2653a1d003cbf6b7a69d8961)
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:a6a2935076b192109171310db5159183e5ab059b commit r9-8747-ga6a2935076b192109171310db5159183e5ab059b Author: Szabolcs Nagy Date: Thu May 28 10:28:30 2020 +0100 doc: Clarify __builtin_return_address [PR94891] The expected semantics and valid usage of __builtin_return_address is not clear since it exposes implementation internals that are normally not meaningful to portable c code. This documentation change tries to clarify the semantics in case the return address is stored in a mangled form. This affects AArch64 when pointer authentication is used for the return address signing (i.e. -mbranch-protection=pac-ret). 2020-07-13 Szabolcs Nagy gcc/ChangeLog: PR target/94891 * doc/extend.texi: Update the text for __builtin_return_address. (cherry picked from commit 6a391e06f953c3390b14020d8cacb6d55f81b2b9)
[Bug target/94791] aarch64: -pg profiling is broken with pac-ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94791 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:a70d5d81c41048556fd86eaa1036018a6bfba115 commit r9-8744-ga70d5d81c41048556fd86eaa1036018a6bfba115 Author: Szabolcs Nagy Date: Tue Jun 2 16:44:41 2020 +0100 aarch64: fix return address access with pac [PR94891][PR94791] This is a big hammer fix for __builtin_return_address (PR target/94891) returning signed addresses (sometimes, depending on wether lr happens to be signed or not at the time of call which depends on optimizations), and similarly -pg may pass signed return address to _mcount (PR target/94791). At the time of return address expansion we don't know if it's signed or not so it is done unconditionally. 2020-07-13 Szabolcs Nagy gcc/ChangeLog: PR target/94891 PR target/94791 * config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx): Declare. * config/aarch64/aarch64.c (aarch64_return_addr_rtx): New. (aarch64_return_addr): Use aarch64_return_addr_rtx. * config/aarch64/aarch64.h (PROFILE_HOOK): Likewise. (cherry picked from commit 463a54e5d4956143f81c1f23b91cbd2d93855741)
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:a70d5d81c41048556fd86eaa1036018a6bfba115 commit r9-8744-ga70d5d81c41048556fd86eaa1036018a6bfba115 Author: Szabolcs Nagy Date: Tue Jun 2 16:44:41 2020 +0100 aarch64: fix return address access with pac [PR94891][PR94791] This is a big hammer fix for __builtin_return_address (PR target/94891) returning signed addresses (sometimes, depending on wether lr happens to be signed or not at the time of call which depends on optimizations), and similarly -pg may pass signed return address to _mcount (PR target/94791). At the time of return address expansion we don't know if it's signed or not so it is done unconditionally. 2020-07-13 Szabolcs Nagy gcc/ChangeLog: PR target/94891 PR target/94791 * config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx): Declare. * config/aarch64/aarch64.c (aarch64_return_addr_rtx): New. (aarch64_return_addr): Use aarch64_return_addr_rtx. * config/aarch64/aarch64.h (PROFILE_HOOK): Likewise. (cherry picked from commit 463a54e5d4956143f81c1f23b91cbd2d93855741)
[Bug libgcc/96001] aarch64: bti is missing from lse.S when built with branch protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96001 nsz at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED --- Comment #4 from nsz at gcc dot gnu.org --- fixed for gcc-11, gcc-10.2, gcc-9.4
[Bug target/94791] aarch64: -pg profiling is broken with pac-ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94791 nsz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #4 from nsz at gcc dot gnu.org --- fixed for gcc-11, gcc-10.2, gcc-9.4
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 nsz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #13 from nsz at gcc dot gnu.org --- fixed for gcc-11, gcc-10.2, gcc-9.4
[Bug c++/96106] [10/11 Regression] A friend abbreviated template function denies access to private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96106 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/96219] New: New Feature (c++ core 727): explicit specialization in class definition should be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96219
Bug ID: 96219
Summary: New Feature (c++ core 727): explicit specialization in
class definition should be allowed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi,all.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#727
According to above link, explicit specialization in class definition should be
allowed.
For example,
$cat test.cc
class A {
template void F(){};
template <> void F();
};
$g++ -std=c++17 test.cc
test.cc:3:15: error: explicit specialization in non-namespace scope 'class A'
3 | template <> void F();
| ^
test.cc:3:22: error: template-id 'F' in declaration of primary template
3 | template <> void F();
| ^~
I report this because of the related discussion in llvm:
https://bugs.llvm.org/show_bug.cgi?id=46728
Thanks,
Haoxin
[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 Marek Polacek changed: What|Removed |Added CC||haoxintu at gmail dot com --- Comment #8 from Marek Polacek --- *** Bug 96219 has been marked as a duplicate of this bug. ***
[Bug c++/96219] New Feature (c++ core 727): explicit specialization in class definition should be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96219 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Dup. *** This bug has been marked as a duplicate of bug 85282 ***
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 --- Comment #8 from H.J. Lu --- Created attachment 48881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48881&action=edit Something like this
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 --- Comment #9 from Matthias Klose --- Comment on attachment 48881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48881 Something like this please could you update gcc/doc/invoke.texi? is error only supposed to be passed in LDFLAGS, not in CFLAGS? What would be the semantics if error passed in CFLAGS?
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 --- Comment #10 from H.J. Lu --- (In reply to Matthias Klose from comment #9) > Comment on attachment 48881 [details] > Something like this > > please could you update gcc/doc/invoke.texi? It needs more than documentation. > is error only supposed to be passed in LDFLAGS, not in CFLAGS? What would be > the semantics if error passed in CFLAGS? CF_ERROR should be treated like CF_NONE outside of lto-wrapper.c.
[Bug fortran/96220] New: -fc-prototypes forgets types for doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96220
Bug ID: 96220
Summary: -fc-prototypes forgets types for doubles
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
$ cat foo.f90
module f_global_vars_m
use, intrinsic :: iso_c_binding, sp => c_float, dp => c_double
implicit none
real(dp), bind(c) :: one= 1.0_dp, four= 4.0_dp ! Error in gfortran v.10.1
end module f_global_vars_m
$ gfortran -fc-prototypes -c foo.f90
#include
#ifdef __cplusplus
#include
#define __GFORTRAN_FLOAT_COMPLEX std::complex
#define __GFORTRAN_DOUBLE_COMPLEX std::complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX std::complex
extern "C" {
#else
#define __GFORTRAN_FLOAT_COMPLEX float _Complex
#define __GFORTRAN_DOUBLE_COMPLEX double _Complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX long double _Complex
#endif
extern four;
extern one;
#ifdef __cplusplus
}
#endif
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-07-16 CC||mpolacek at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- Confirmed. Let me CC Marek who implemented -Wduplicated-branches for his thoughts.
[Bug fortran/96220] -fc-prototypes forgets types for doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96220 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2020-07-16 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/96221] New: Constructor attribute priority is ignored if additional prototypes omit attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96221
Bug ID: 96221
Summary: Constructor attribute priority is ignored if
additional prototypes omit attribute
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: srk31 at srcf dot ucam.org
Target Milestone: ---
Created attachment 48882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48882&action=edit
Minimal test case
I was surprised to find that my __attribute__((constructor(101))) on a function
was not giving it priority over another constructor whose attribute used a
higher number. It turns out this was owing to an additional prototype that did
not mention the function as a constructor.
This caused a really subtle initialization bug in my code, and was tough to
track down. At the least, I would expect a warning when the information is
discarded.
I haven't tried on 8.4, but didn't see any relevant changelog entries.
Note that this is not a duplicate of 87592, which is about when the priority is
specified multiple times.
$ cat test.c
// comment these for correct behaviour, i.e. 1 then 2
static void do_init1(void);
static void do_init2(void);
static void do_init2(void) __attribute__((constructor(102)));
static void do_init2(void)
{
printf("Init 2!\n");
}
static void do_init1(void) __attribute__((constructor(101)));
static void do_init1(void)
{
printf("Init 1!\n");
}
int main(void)
{
return 0;
}
$ cc -save-tempstest.c -o test
$ ./test
Init 2!
Init 1!
$ grep -B2 init_array test.s
.LFE0:
.size do_init2, .-do_init2
.section.init_array,"aw"
--
.LFE1:
.size do_init1, .-do_init1
.section.init_array
The attribute's priority argument is being discarded. It should be visible in
the section name (".init_array.0101" etc.). If the extra prototypes are
removed, the programmer-intended behaviour is restored.
[Bug c++/95417] Static storage duration objects that are constant initialized should be destroyed after the destruction of dynamically initialized object.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95417 Olivier Kannengieser changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Olivier Kannengieser --- I have just found a paragraph in the standard that specifies that GCC behavior is standard compliant, [basic.start.term]/3: "If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized."
[Bug c++/95417] Static storage duration objects that are constant initialized should be destroyed after the destruction of dynamically initialized object.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95417 Olivier Kannengieser changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Olivier Kannengieser --- It is thus an invalid bug.
[Bug libstdc++/93121] std::bit_cast missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 48883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48883&action=edit gcc11-pr93121-wip.patch Untested WIP on this (well, only the compiler builtin). What needs still doing is 1) handle bitfields (both in the middle-end in native_encode_initializer and in 2) punt on trying to read padding bits - perhaps if arg is a CONSTRUCTOR compute in addition to the memory representation a mask which bits are uninitialized, and diagnose if we try to read from those 3) verify handling of flexible array members and zero length arrays
[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #5 from Mark Wielaard --- This is also one of the issues that prevent elfutils to build with LTO. The workaround is to compile with -Wno-error=stack-usage= added to CFLAGS: https://sourceware.org/pipermail/elfutils-devel/2020q2/002733.html
[Bug c++/96222] New: std::filesystem::directory_iterator shares state
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96222
Bug ID: 96222
Summary: std::filesystem::directory_iterator shares state
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sogartary at yahoo dot com
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.3.0-11ubuntu0~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-11ubuntu0~18.04.1)
OS: Ubuntu 18.04, Linux 5.3.0
---
I don't know if this is supposed to be a bug, but I was surprised to find out
that std::filesystem::directory_iterator has a shared state.
For example the below code would advance both iterators.
std::filesystem::directory_iterator it("some-path");
std::filesystem::directory_iterator it2 = it;
++it2;
[Bug c++/50370] [C++0x] Multiple declarations with default template arguments accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50370 Marek Polacek changed: What|Removed |Added CC||ec13n at my dot fsu.edu --- Comment #3 from Marek Polacek --- *** Bug 82850 has been marked as a duplicate of this bug. ***
[Bug c++/82850] g++ permits redefinition of default arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- Closing. *** This bug has been marked as a duplicate of bug 50370 ***
[Bug c++/50370] [C++0x] Multiple declarations with default template arguments accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50370 Marek Polacek changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #4 from Marek Polacek --- *** Bug 87234 has been marked as a duplicate of this bug. ***
[Bug c++/87234] GCC should warn if template parameter redefines default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87234 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Marek Polacek --- Dup. *** This bug has been marked as a duplicate of bug 50370 ***
[Bug target/96189] Failure to use eflags from cmpxchg on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189 --- Comment #7 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:cc1ef413a859433a8313fa9c15aaff41bdc837dc commit r11-2181-gcc1ef413a859433a8313fa9c15aaff41bdc837dc Author: Uros Bizjak Date: Thu Jul 16 20:11:43 2020 +0200 i386: Additional peephole2 to use flags from CMPXCHG more [PR96189] CMPXCHG instruction sets ZF flag if the values in the destination operand and EAX register are equal; otherwise the ZF flag is cleared and value from destination operand is loaded to EAX. Following assembly: xorl%eax, %eax lock cmpxchgl %edx, (%rdi) testl %eax, %eax sete%al can be optimized by removing the unneeded comparison, since set ZF flag signals that no update to EAX happened. This patch adds peephole2 pattern to also handle XOR zeroing and load of -1 by OR. 2020-07-16 Uroš Bizjak gcc/ChangeLog: PR target/96189 * config/i386/sync.md (peephole2 to remove unneded compare after CMPXCHG): New pattern, also handle XOR zeroing and load of -1 by OR. gcc/testsuite/ChangeLog: PR target/96189 * gcc.target/i386/pr96189-1.c: New test.
[Bug debug/54734] Debug info for C++ and LTO misses types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54734 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- This seems fixed with recent GCC. At least with GNU C++14 10.1.1 20200507 (Red Hat 10.1.1-1) I now get: [6b]typedef abbrev: 2 name (strp) "sstring" decl_file(data1) t.cc (1) decl_line(data1) 2 decl_column (data1) 28 type (ref4) [77] [77]class_type abbrev: 3 name (strp) "basic_string" byte_size(data1) 1 decl_file(data1) t.cc (1) decl_line(data1) 5 decl_column (data1) 7 sibling (ref4) [99] [84] typedef abbrev: 4 name (strp) "type" decl_file(data1) t.cc (1) decl_line(data1) 8 decl_column (data1) 13 type (ref4) [99] accessibility(data1) public (1) [91] template_type_parameter abbrev: 5 name (string) "T" type (ref4) [99] [99]base_typeabbrev: 6 byte_size(data1) 1 encoding (data1) signed_char (6) name (strp) "char"
[Bug lto/58528] lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #10 from Mark Wielaard --- It isn't entirely clear to me how to replicate this. Is this still an issue with newer gcc?
[Bug c++/96223] New: DR 1787 and indeterminate values in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96223
Bug ID: 96223
Summary: DR 1787 and indeterminate values in constexpr context
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Use -std=c++20:
// DR 1787
#include
constexpr int
fn1 ()
{
unsigned char foo;
unsigned char u = foo; // OK: u has an indeterminate value
return u; // UB: copy-init -> standard conversion to int
}
constexpr int
fn2 ()
{
unsigned char foo;
int i = foo; // UB
return 0;
}
constexpr int
fn3 ()
{
unsigned char foo;
char8_t u = foo; // UB: char8_t not an unsigned ordinary character type
return 0;
}
constexpr int
fn4 ()
{
std::byte foo;
std::byte b = foo; // OK
return 0;
}
constexpr int w1 = fn1 ();
constexpr int w2 = fn2 ();
constexpr int w3 = fn3 ();
constexpr int w4 = fn4 ();
DR 1787 says that if an indeterminate value is produced by an evaluation, the
behavior is undefined except in certain cases. In fn1 and fn4 we issue errors
even for some of the "certain cases" (the lines marked with OK) and I think
it's a bug. Uninitialized variables in a constexpr context are OK since C++20
P1331R2.
[Bug c++/96223] DR 1787 and indeterminate values in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96223 --- Comment #1 from Marek Polacek --- Note that is_byte_access_type won't do, because it includes char8_t too.
[Bug fortran/96224] New: -fdump-tree-original could use more sophisticated or mangled procedure names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96224
Bug ID: 96224
Summary: -fdump-tree-original could use more sophisticated or
mangled procedure names
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
Consider the following code:
module mod
contains
subroutine init
end subroutine
end module
module init
use mod, only : mod_init => init
implicit none
contains
subroutine sub
call mod_init
call init
contains
subroutine init
end subroutine
end subroutine
end module
Compiling the above (after applying my patch for PR89574; otherwise module init
needs to be renamed) leads to:
init ()
{
}
init ()
{
}
sub ()
{
static void init (void);
init ();
init ();
}
Grepping the resulting assembler suggests that the proper calls are generated:
% grep call foo.s
call__mod_MOD_init
callinit.0
So this is likely only a cosmetic problem, although an annoying one.
[Bug fortran/96224] -fdump-tree-original could use more sophisticated or mangled procedure names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96224 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5
[Bug c++/96213] GCC doesn't complain about ill-formed non-dependent template default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96213 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Keywords||accepts-invalid Last reconfirmed||2020-07-16 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Your observation makes sense to me, so confirmed.
[Bug c++/96222] std::filesystem::directory_iterator shares state
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96222 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- That's because it's iterator category is input_iterator_tag and input iterators are single pass. See https://en.cppreference.com/w/cpp/named_req/InputIterator So this is not a bug.
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214 --- Comment #2 from Jonny Grant --- Thank you. Saw there is -Wdangling-else already as well
[Bug testsuite/96014] [11 regression] g++.dg/analyzer/pr94028.C excess errors starting with r11-1697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96014 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:75edc31f9ebe7f8b933860981a124f7f0993214b commit r11-2182-g75edc31f9ebe7f8b933860981a124f7f0993214b Author: Jonathan Wakely Date: Thu Jul 16 11:44:32 2020 +0100 analyzer: Use noexcept instead of throw() for C++11 and later (PR 96014) gcc/testsuite/ChangeLog: PR testsuite/96014 * g++.dg/analyzer/pr94028.C: Replace dynamic exception specification with noexcept-specifier for C++11 and later.
[Bug libstdc++/86742] Documented function std::to_chars(char* first, char* last, double value) is not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86742 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-07-16 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |11.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Keywords||patch --- Comment #2 from Jonathan Wakely --- Patches have been submitted for this now: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550030.html
[Bug target/95458] Inline strncmp is *much* slower than glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95458 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Alexandre Oliva --- https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00701.html seems relevant
[Bug c++/96225] New: ice in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96225 Bug ID: 96225 Summary: ice in extract_insn, at recog.c:2294 Product: gcc Version: unknown 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 48884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48884&action=edit gzipped C++ source code The attached gzipped C++ code, with recent gcc trunk and flags -march=sapphirerapids -O3 -ansi -ffast-math, does this: usr/include/endian.h: In member function ‘void DSODatabase::findVisibleDSOs(DSOHandler&, const Point3d&, const Quatf&, float, float, float) const’: /usr/include/endian.h:54245:1: error: unrecognizable insn: (insn 131 130 132 2 (set (reg:V4DF 252) (unspec:V4DF [ (reg:V4DF 153 [ vect__170.1094 ]) ] UNSPEC_RSQRT)) "/usr/include/endian.h":11544:23 -1 (nil)) during RTL pass: vregs /usr/include/endian.h:54245:1: internal compiler error: in extract_insn, at recog.c:2294
[Bug c++/95895] internal compiler error: in captures_temporary, at cp/coroutines.cc:2717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95895 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:0f66b8486cea8668020e4bd48f261b760cb579be commit r11-2183-g0f66b8486cea8668020e4bd48f261b760cb579be Author: Iain Sandoe Date: Sat Jul 11 08:49:33 2020 +0100 coroutines: Correct frame capture of compiler temps [PR95591+4]. When a full expression contains a co_await (or co_yield), this means that it might be suspended; which would destroy temporary variables (on a stack for example). However the language guarantees that such temporaries are live until the end of the expression. In order to preserve this, we 'promote' temporaries where necessary so that they are saved in the coroutine frame (which allows them to remain live potentially until the frame is destroyed). In addition, sub-expressions that produce control flow (such as TRUTH_AND/OR_IF or COND_EXPR) must be handled specifically to ensure that await expressions are properly expanded. This patch corrects two mistakes in which we were (a) failing to promote some temporaries and (b) we we failing to sequence DTORs for the captures properly. This manifests in a number of related (but not exact duplicate) PRs. The revised code collects the actions into one place and maps all the control flow into one form - a benefit of this is that co_returns are now expanded earlier (which provides an opportunity to address PR95517 in some future patch). We replace a statement that contains await expression(s) with a bind scope that has a variable list describing the temporaries that have been 'promoted' and a statement list that contains a series of cleanup expressions for each of those. Where we encounter nested conditional expressions, these are wrapped in a try-finally block with a guard var for each sub-expression variable that needs a DTOR. The guards are all declared and initialized to false before the first conditional sub- expression. The 'finally' block contains a series of if blocks (one per guard variable) enclosing the relevant DTOR. Variables listed in a bind scope in this manner are automatically moved to a coroutine frame version by existing code (so we re-use that rather than having a separate mechanism). gcc/cp/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * coroutines.cc (struct coro_ret_data): Delete. (coro_maybe_expand_co_return): Delete. (co_return_expander): Delete. (expand_co_returns): Delete. (co_await_find_in_subtree): Remove unused name. (build_actor_fn): Remove unused parm, remove handling for co_return expansion. (register_await_info): Demote duplicate info message to a warning. (coro_make_frame_entry): Move closer to use site. (struct susp_frame_data): Add fields for final suspend label and a flag to indicate await expressions with initializers. (captures_temporary): Delete. (register_awaits): Remove unused code, update comments. (find_any_await): New. (tmp_target_expr_p): New. (struct interesting): New. (find_interesting_subtree): New. (struct var_nest_node): New. (flatten_await_stmt): New. (handle_nested_conditionals): New. (process_conditional): New. (replace_statement_captures): Rename to... (maybe_promote_temps): ... this. (maybe_promote_captured_temps): Delete. (analyze_expression_awaits): Check for await expressions with initializers. Simplify handling for truth-and/or-if. (expand_one_truth_if): Simplify (map cases that need expansion to COND_EXPR). (await_statement_walker): Handle CO_RETURN_EXPR. Simplify the handling for truth-and/or-if expressions. (register_local_var_uses): Ensure that we create names in the implementation namespace. (morph_fn_to_coro): Add final suspend label to suspend frame callback data and remove it from the build_actor_fn call. gcc/testsuite/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * g++.dg/coroutines/pr95591.C: New test. * g++.dg/coroutines/pr95599.C: New test. * g++.dg/coroutines/pr95823.C: New test. * g++.dg/coroutines/pr95824.C: New test.
[Bug c++/95599] [coroutines] destructor for temporary operand to co_yield expression called before end of full-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95599 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:0f66b8486cea8668020e4bd48f261b760cb579be commit r11-2183-g0f66b8486cea8668020e4bd48f261b760cb579be Author: Iain Sandoe Date: Sat Jul 11 08:49:33 2020 +0100 coroutines: Correct frame capture of compiler temps [PR95591+4]. When a full expression contains a co_await (or co_yield), this means that it might be suspended; which would destroy temporary variables (on a stack for example). However the language guarantees that such temporaries are live until the end of the expression. In order to preserve this, we 'promote' temporaries where necessary so that they are saved in the coroutine frame (which allows them to remain live potentially until the frame is destroyed). In addition, sub-expressions that produce control flow (such as TRUTH_AND/OR_IF or COND_EXPR) must be handled specifically to ensure that await expressions are properly expanded. This patch corrects two mistakes in which we were (a) failing to promote some temporaries and (b) we we failing to sequence DTORs for the captures properly. This manifests in a number of related (but not exact duplicate) PRs. The revised code collects the actions into one place and maps all the control flow into one form - a benefit of this is that co_returns are now expanded earlier (which provides an opportunity to address PR95517 in some future patch). We replace a statement that contains await expression(s) with a bind scope that has a variable list describing the temporaries that have been 'promoted' and a statement list that contains a series of cleanup expressions for each of those. Where we encounter nested conditional expressions, these are wrapped in a try-finally block with a guard var for each sub-expression variable that needs a DTOR. The guards are all declared and initialized to false before the first conditional sub- expression. The 'finally' block contains a series of if blocks (one per guard variable) enclosing the relevant DTOR. Variables listed in a bind scope in this manner are automatically moved to a coroutine frame version by existing code (so we re-use that rather than having a separate mechanism). gcc/cp/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * coroutines.cc (struct coro_ret_data): Delete. (coro_maybe_expand_co_return): Delete. (co_return_expander): Delete. (expand_co_returns): Delete. (co_await_find_in_subtree): Remove unused name. (build_actor_fn): Remove unused parm, remove handling for co_return expansion. (register_await_info): Demote duplicate info message to a warning. (coro_make_frame_entry): Move closer to use site. (struct susp_frame_data): Add fields for final suspend label and a flag to indicate await expressions with initializers. (captures_temporary): Delete. (register_awaits): Remove unused code, update comments. (find_any_await): New. (tmp_target_expr_p): New. (struct interesting): New. (find_interesting_subtree): New. (struct var_nest_node): New. (flatten_await_stmt): New. (handle_nested_conditionals): New. (process_conditional): New. (replace_statement_captures): Rename to... (maybe_promote_temps): ... this. (maybe_promote_captured_temps): Delete. (analyze_expression_awaits): Check for await expressions with initializers. Simplify handling for truth-and/or-if. (expand_one_truth_if): Simplify (map cases that need expansion to COND_EXPR). (await_statement_walker): Handle CO_RETURN_EXPR. Simplify the handling for truth-and/or-if expressions. (register_local_var_uses): Ensure that we create names in the implementation namespace. (morph_fn_to_coro): Add final suspend label to suspend frame callback data and remove it from the build_actor_fn call. gcc/testsuite/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * g++.dg/coroutines/pr95591.C: New test. * g++.dg/coroutines/pr95599.C: New test. * g++.dg/coroutines/pr95823.C: New test. * g++.dg/coroutines/pr95824.C: New test.
[Bug c++/95591] [coroutines] ICE when co_yielding string literal from generator coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95591 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:0f66b8486cea8668020e4bd48f261b760cb579be commit r11-2183-g0f66b8486cea8668020e4bd48f261b760cb579be Author: Iain Sandoe Date: Sat Jul 11 08:49:33 2020 +0100 coroutines: Correct frame capture of compiler temps [PR95591+4]. When a full expression contains a co_await (or co_yield), this means that it might be suspended; which would destroy temporary variables (on a stack for example). However the language guarantees that such temporaries are live until the end of the expression. In order to preserve this, we 'promote' temporaries where necessary so that they are saved in the coroutine frame (which allows them to remain live potentially until the frame is destroyed). In addition, sub-expressions that produce control flow (such as TRUTH_AND/OR_IF or COND_EXPR) must be handled specifically to ensure that await expressions are properly expanded. This patch corrects two mistakes in which we were (a) failing to promote some temporaries and (b) we we failing to sequence DTORs for the captures properly. This manifests in a number of related (but not exact duplicate) PRs. The revised code collects the actions into one place and maps all the control flow into one form - a benefit of this is that co_returns are now expanded earlier (which provides an opportunity to address PR95517 in some future patch). We replace a statement that contains await expression(s) with a bind scope that has a variable list describing the temporaries that have been 'promoted' and a statement list that contains a series of cleanup expressions for each of those. Where we encounter nested conditional expressions, these are wrapped in a try-finally block with a guard var for each sub-expression variable that needs a DTOR. The guards are all declared and initialized to false before the first conditional sub- expression. The 'finally' block contains a series of if blocks (one per guard variable) enclosing the relevant DTOR. Variables listed in a bind scope in this manner are automatically moved to a coroutine frame version by existing code (so we re-use that rather than having a separate mechanism). gcc/cp/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * coroutines.cc (struct coro_ret_data): Delete. (coro_maybe_expand_co_return): Delete. (co_return_expander): Delete. (expand_co_returns): Delete. (co_await_find_in_subtree): Remove unused name. (build_actor_fn): Remove unused parm, remove handling for co_return expansion. (register_await_info): Demote duplicate info message to a warning. (coro_make_frame_entry): Move closer to use site. (struct susp_frame_data): Add fields for final suspend label and a flag to indicate await expressions with initializers. (captures_temporary): Delete. (register_awaits): Remove unused code, update comments. (find_any_await): New. (tmp_target_expr_p): New. (struct interesting): New. (find_interesting_subtree): New. (struct var_nest_node): New. (flatten_await_stmt): New. (handle_nested_conditionals): New. (process_conditional): New. (replace_statement_captures): Rename to... (maybe_promote_temps): ... this. (maybe_promote_captured_temps): Delete. (analyze_expression_awaits): Check for await expressions with initializers. Simplify handling for truth-and/or-if. (expand_one_truth_if): Simplify (map cases that need expansion to COND_EXPR). (await_statement_walker): Handle CO_RETURN_EXPR. Simplify the handling for truth-and/or-if expressions. (register_local_var_uses): Ensure that we create names in the implementation namespace. (morph_fn_to_coro): Add final suspend label to suspend frame callback data and remove it from the build_actor_fn call. gcc/testsuite/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * g++.dg/coroutines/pr95591.C: New test. * g++.dg/coroutines/pr95599.C: New test. * g++.dg/coroutines/pr95823.C: New test. * g++.dg/coroutines/pr95824.C: New test.
[Bug c++/95823] [coroutines] compiler internal error in captures_temporary,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95823 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:0f66b8486cea8668020e4bd48f261b760cb579be commit r11-2183-g0f66b8486cea8668020e4bd48f261b760cb579be Author: Iain Sandoe Date: Sat Jul 11 08:49:33 2020 +0100 coroutines: Correct frame capture of compiler temps [PR95591+4]. When a full expression contains a co_await (or co_yield), this means that it might be suspended; which would destroy temporary variables (on a stack for example). However the language guarantees that such temporaries are live until the end of the expression. In order to preserve this, we 'promote' temporaries where necessary so that they are saved in the coroutine frame (which allows them to remain live potentially until the frame is destroyed). In addition, sub-expressions that produce control flow (such as TRUTH_AND/OR_IF or COND_EXPR) must be handled specifically to ensure that await expressions are properly expanded. This patch corrects two mistakes in which we were (a) failing to promote some temporaries and (b) we we failing to sequence DTORs for the captures properly. This manifests in a number of related (but not exact duplicate) PRs. The revised code collects the actions into one place and maps all the control flow into one form - a benefit of this is that co_returns are now expanded earlier (which provides an opportunity to address PR95517 in some future patch). We replace a statement that contains await expression(s) with a bind scope that has a variable list describing the temporaries that have been 'promoted' and a statement list that contains a series of cleanup expressions for each of those. Where we encounter nested conditional expressions, these are wrapped in a try-finally block with a guard var for each sub-expression variable that needs a DTOR. The guards are all declared and initialized to false before the first conditional sub- expression. The 'finally' block contains a series of if blocks (one per guard variable) enclosing the relevant DTOR. Variables listed in a bind scope in this manner are automatically moved to a coroutine frame version by existing code (so we re-use that rather than having a separate mechanism). gcc/cp/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * coroutines.cc (struct coro_ret_data): Delete. (coro_maybe_expand_co_return): Delete. (co_return_expander): Delete. (expand_co_returns): Delete. (co_await_find_in_subtree): Remove unused name. (build_actor_fn): Remove unused parm, remove handling for co_return expansion. (register_await_info): Demote duplicate info message to a warning. (coro_make_frame_entry): Move closer to use site. (struct susp_frame_data): Add fields for final suspend label and a flag to indicate await expressions with initializers. (captures_temporary): Delete. (register_awaits): Remove unused code, update comments. (find_any_await): New. (tmp_target_expr_p): New. (struct interesting): New. (find_interesting_subtree): New. (struct var_nest_node): New. (flatten_await_stmt): New. (handle_nested_conditionals): New. (process_conditional): New. (replace_statement_captures): Rename to... (maybe_promote_temps): ... this. (maybe_promote_captured_temps): Delete. (analyze_expression_awaits): Check for await expressions with initializers. Simplify handling for truth-and/or-if. (expand_one_truth_if): Simplify (map cases that need expansion to COND_EXPR). (await_statement_walker): Handle CO_RETURN_EXPR. Simplify the handling for truth-and/or-if expressions. (register_local_var_uses): Ensure that we create names in the implementation namespace. (morph_fn_to_coro): Add final suspend label to suspend frame callback data and remove it from the build_actor_fn call. gcc/testsuite/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * g++.dg/coroutines/pr95591.C: New test. * g++.dg/coroutines/pr95599.C: New test. * g++.dg/coroutines/pr95823.C: New test. * g++.dg/coroutines/pr95824.C: New test.
[Bug c++/95824] [coroutines] compiler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95824 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:0f66b8486cea8668020e4bd48f261b760cb579be commit r11-2183-g0f66b8486cea8668020e4bd48f261b760cb579be Author: Iain Sandoe Date: Sat Jul 11 08:49:33 2020 +0100 coroutines: Correct frame capture of compiler temps [PR95591+4]. When a full expression contains a co_await (or co_yield), this means that it might be suspended; which would destroy temporary variables (on a stack for example). However the language guarantees that such temporaries are live until the end of the expression. In order to preserve this, we 'promote' temporaries where necessary so that they are saved in the coroutine frame (which allows them to remain live potentially until the frame is destroyed). In addition, sub-expressions that produce control flow (such as TRUTH_AND/OR_IF or COND_EXPR) must be handled specifically to ensure that await expressions are properly expanded. This patch corrects two mistakes in which we were (a) failing to promote some temporaries and (b) we we failing to sequence DTORs for the captures properly. This manifests in a number of related (but not exact duplicate) PRs. The revised code collects the actions into one place and maps all the control flow into one form - a benefit of this is that co_returns are now expanded earlier (which provides an opportunity to address PR95517 in some future patch). We replace a statement that contains await expression(s) with a bind scope that has a variable list describing the temporaries that have been 'promoted' and a statement list that contains a series of cleanup expressions for each of those. Where we encounter nested conditional expressions, these are wrapped in a try-finally block with a guard var for each sub-expression variable that needs a DTOR. The guards are all declared and initialized to false before the first conditional sub- expression. The 'finally' block contains a series of if blocks (one per guard variable) enclosing the relevant DTOR. Variables listed in a bind scope in this manner are automatically moved to a coroutine frame version by existing code (so we re-use that rather than having a separate mechanism). gcc/cp/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * coroutines.cc (struct coro_ret_data): Delete. (coro_maybe_expand_co_return): Delete. (co_return_expander): Delete. (expand_co_returns): Delete. (co_await_find_in_subtree): Remove unused name. (build_actor_fn): Remove unused parm, remove handling for co_return expansion. (register_await_info): Demote duplicate info message to a warning. (coro_make_frame_entry): Move closer to use site. (struct susp_frame_data): Add fields for final suspend label and a flag to indicate await expressions with initializers. (captures_temporary): Delete. (register_awaits): Remove unused code, update comments. (find_any_await): New. (tmp_target_expr_p): New. (struct interesting): New. (find_interesting_subtree): New. (struct var_nest_node): New. (flatten_await_stmt): New. (handle_nested_conditionals): New. (process_conditional): New. (replace_statement_captures): Rename to... (maybe_promote_temps): ... this. (maybe_promote_captured_temps): Delete. (analyze_expression_awaits): Check for await expressions with initializers. Simplify handling for truth-and/or-if. (expand_one_truth_if): Simplify (map cases that need expansion to COND_EXPR). (await_statement_walker): Handle CO_RETURN_EXPR. Simplify the handling for truth-and/or-if expressions. (register_local_var_uses): Ensure that we create names in the implementation namespace. (morph_fn_to_coro): Add final suspend label to suspend frame callback data and remove it from the build_actor_fn call. gcc/testsuite/ChangeLog: PR c++/95591 PR c++/95599 PR c++/95823 PR c++/95824 PR c++/95895 * g++.dg/coroutines/pr95591.C: New test. * g++.dg/coroutines/pr95599.C: New test. * g++.dg/coroutines/pr95823.C: New test. * g++.dg/coroutines/pr95824.C: New test.
[Bug tree-optimization/96226] New: Failure to optimize shift+not to rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
Bug ID: 96226
Summary: Failure to optimize shift+not to rotate
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int32_t f(int32_t x)
{
return ~(1 << (x & 0x1F));
}
This can be transformed to doing a rotate of -2 and x. This transformation is
done by LLVM, but not by GCC.
PS: GCC seems capable of doing this optimization, but only if `x & 0x1F` is
replaced with `x`, which either means that GCC is underoptimizing this or that
LLVM is somehow wrong.
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 --- Comment #11 from H.J. Lu --- Created attachment 48885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48885&action=edit A patch
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 H.J. Lu changed: What|Removed |Added Last reconfirmed||2020-07-16 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #12 from H.J. Lu --- Please this patch.
[Bug c++/96215] Wrong mangling for non-dependent return type involving decltype(g.x) or decltype(p->x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96215 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- We consider those COMPONENT_REFs as instantiation-dependent because: instantiation_dependent_r: case COMPONENT_REF: if (identifier_p (TREE_OPERAND (*tp, 1))) /* In a template, finish_class_member_access_expr creates a COMPONENT_REF with an IDENTIFIER_NODE for op1 even if it isn't type-dependent, so that we can check access control at instantiation time (PR 42277). See also Core issue 1273. */ return *tp;
[Bug debug/87726] -fdebug-prefix-map doesn't work with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 CC||mark at gcc dot gnu.org Blocks||47819 Last reconfirmed||2020-07-16 Status|UNCONFIRMED |NEW --- Comment #1 from Mark Wielaard --- Replicated. With -flto added the result is a linker error: g++ -g -o app/app app/app.o -L./lib -lA /usr/bin/ld: /tmp/app.BSgkYr.ltrans0.ltrans.o: in function `main': //app.cpp:6: undefined reference to `Lib::func()' collect2: error: ld returned 1 exit status Removing -fdebug-prefix-map (but keeping -flto) things build fine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819 [Bug 47819] [meta-bug] LTO debug information issues
[Bug c++/96227] New: Comma operation sequencing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96227
Bug ID: 96227
Summary: Comma operation sequencing issue
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Filing on behalf of @lunasorcery (on twitter):
The following code:
```
#include
struct S {
S(char const* message) {
puts(message);
}
};
void operator,(S,S){}
int main() {
S("first"), S("second");
operator,(S("FIRST"), S("SECOND"));
}
```
Should produce the output:
first
second
FIRST
SECOND
But instead produces:
second
first
SECOND
FIRST
quotations from N4861:
[expr.comma]
"The left expression is sequenced before the right expression."
[over.match.oper]
"If either operand has a type that is a class or an enumeration,
a user-defined operator function might be declared that implements this
operator [...]
However, the operands are sequenced in the order prescribed for the built-in
operator."
[expr.call]
"If an operator function is invoked using operator notation, argument
evaluation is
sequenced as specified for the built-in operator; see 12.4.1.2."
https://gcc.godbolt.org/z/fdTG8q
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #8 from Mark Wielaard --- Both the minimal and original reproducer seem to build fine with gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
[Bug c++/96215] Wrong mangling for non-dependent return type involving decltype(g.x) or decltype(p->x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96215
--- Comment #2 from Arthur O'Dwyer ---
WG21's commentary on CWG 1273 (which is now
http://cwg-issue-browser.herokuapp.com/cwg1172
) seems completely bizarre to me. Sure, `decltype(g.x)` could theoretically
refer to a private member of `g`; but so could `decltype(g+1)` or
`decltype(*g)` or any other expression that might involve a private member.
(In `g+1`, there might be a private member `S::operator+(int)`.)
https://godbolt.org/z/ehd9fr
GCC happily accepts
template constexpr decltype (a.i) f() { return 1; }
template constexpr decltype (b.i) f() { return 2; }
as an overload set, but rejects
template constexpr decltype (a+1) g() { return 3; }
template constexpr decltype (b+1) g() { return 4; }
and also rejects
template constexpr decltype (&A::i, 0) h() { return 5; }
template constexpr decltype (&B::i, 0) h() { return 6; }
Clang sensibly rejects all three, all for the same reason.
Normally I'd be all for GCC injecting some implementation divergence into this
poorly specified area of the standard; but since this affects name-mangling and
thus causes GCC to be unable to link against (hypothetical) code compiled with
Clang and vice versa, I think it might be worth trying to reconcile.
To be clear: This name-mangling issue doesn't affect any real-world codebase
AFAIK. I discovered it purely by accident while messing around in Godbolt.
[Bug analyzer/96228] New: -Wstack-usage does not understand constant __builtin_alloca calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96228
Bug ID: 96228
Summary: -Wstack-usage does not understand constant
__builtin_alloca calls
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: renat at idrisov dot info
Target Milestone: ---
Hi All,
when compiling the following piece of code:
```
#include
int main(void) {
char *a = __builtin_alloca(4);
a[0] = 0;
printf("%c", a[0]);
return 0;
}
```
with:
$ gcc -Wstack-usage=2048 stack.c
gives:
stack.c:3:5: warning: stack usage might be unbounded [-Wstack-usage=]
3 | int main(void) {
which is too pessimistic on `__builtin_alloca` behavior.
No warning when "char *a = __builtin_alloca(4);" is changed to "char a[4];"
Thank you!
[Bug middle-end/96228] -Wstack-usage does not understand constant __builtin_alloca calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96228 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot gnu.org Component|analyzer|middle-end --- Comment #1 from Andrew Pinski --- -Wstack-usage is done on the RTL level, this means __builtin_alloca with a constant is not converted into always allocation. Usually because of __builtin_alloca can be conditional.
[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #18 from Mark Wielaard --- Since this patch has been included in gcc10 (I verified it works now, but fails with gcc9) can this issue be closed? Or does it need backporting to earlier versions?
[Bug middle-end/96228] -Wstack-usage does not understand constant __builtin_alloca calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96228 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Oh wait this is at -O0. Well the warning is correct and won't be fixed really. -Wstack-usage is done on the RTL level so it can take into account register spilling and all.
[Bug target/96139] Vector element extract mistypes long long int down to long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139 Will Schmidt changed: What|Removed |Added CC||willschm at gcc dot gnu.org --- Comment #5 from Will Schmidt --- (In reply to Bill Schmidt from comment #2) > Have you tried it for -m32, out of curiosity? Local experimentation indicates building with -m32 does not report the warning.
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Jonny Grant from comment #2) > Thank you. Saw there is -Wdangling-else already as well -Wdangling-else is something different; it's more of a split-off from -Wparentheses, i.e. missing braces
[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720 --- Comment #10 from Alexandre Oliva --- Created attachment 48886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48886&action=edit patch that hopefully fixes the problem Does this fix the problem in your testglue-requiring test runs?
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214
--- Comment #4 from Jonny Grant ---
I realised there could be many else {} that can't be executed, added one more
to the example.
int main(void)
{
const int i = 1;
if(1 == i)
{
return 1;
}
else if(1 != i)
{
return 2;
}
else if(2 != i)
{
return 2;
}
else
{
return 3;
}
}
[Bug target/93372] cris performance regressions due to de-cc0 work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93372 --- Comment #6 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:84c5396d4bdbf9f1d628c77db4421808f9a9dcb6 commit r11-2185-g84c5396d4bdbf9f1d628c77db4421808f9a9dcb6 Author: Segher Boessenkool Date: Thu Jul 16 23:42:46 2020 + combine: Use single_set for is_just_move Since we now only call is_just_move on the original instructions, we always have an rtx_insn* (not just a pattern), so we can use single_set on it. This makes no detectable difference at all on all thirty Linux targets I test, but it does help cris, and it is simpler, cleaner code anyway. 2020-07-16 Hans-Peter Nilsson Segher Boessenkool PR target/93372 * combine.c (is_just_move): Take an rtx_insn* as argument. Use single_set on it.
[Bug d/96229] New: Invalid specialization accepted when also constrained in base template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96229
Bug ID: 96229
Summary: Invalid specialization accepted when also constrained
in base template template parameter
Product: gcc
Version: 10.1.0
URL: https://godbolt.org/z/W1zh9n
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/W1zh9n.
```C++
template concept Int = requires { T{0}; };
template class T> struct X{ };
template/* ^~~ */struct Y : X { };
struct Z{ };
void f() { Y x; }
```
[Bug c++/39970] gcc accepts the . dot operator in template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39970 --- Comment #10 from Brandon Nickell --- Well I did open this bug 11 years ago (time flies!) and C++0x was still in mid flight before it turned into C++11, so quite a bit has changed since this was originally reported (for instance there was no constexpr or decltype which is used in the previous comment). At the time there was nothing in the name mangling scheme that clarified how you would even handle mangling the global.member template parameter as it was unusual that it would even be accepted. FWIW, I suspect this test case is correctly rejected in Edison Design Group's front end but cannot immediately confirm. Thanks.
[Bug driver/96230] New: driver: ICE in process_command, at gcc.c:5095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96230
Bug ID: 96230
Summary: driver: ICE in process_command, at gcc.c:5095
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
For the case：
cat foo.c
void foo (void)
{
return;
}
$gcc foo.c -S -dumpbase "" -dumpbase-ext .c -o foo.o
gcc: internal compiler error: in process_command, at gcc.c:5095
0x40ca3b process_command
../.././gcc/gcc.c:5095
0x41335b driver::set_up_specs() const
../.././gcc/gcc.c:8077
0x403b03 driver::main(int, char**)
../.././gcc/gcc.c:7885
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug debug/54734] Debug info for C++ and LTO misses types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54734 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Known to work||8.1.0 --- Comment #2 from Richard Biener --- This was fixed with LTO early debug in GCC 8.
[Bug tree-optimization/96208] non-power-of-2 group size can be vectorized for 2-element vectors case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96208 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Version|unknown |11.0 Blocks||53947 Keywords||missed-optimization --- Comment #1 from Richard Biener --- Note the code path you are changing will go away and "improving" it puts burden onto the replacement implementation ... The testcase suggests the issue is missing SLP support for the not grouped load of *k, something I've been looking at recently. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #8 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #6)
> (In reply to Martin Sebor from comment #4)
> > The warning in the test case in comment #3 looks correct to me.
>
> Thank you! I'll try to re-reduce and not introduce new NULLs.
Here is the second attempt at reducing firefox case, also related to
static_cast<>:
struct D;
struct B {
B* next;
D* Next();
};
struct D : public B {
virtual ~D();
};
struct Iterator {
D* current;
void advance() {
current = static_cast(current)->Next();
}
};
$ x86_64-pc-linux-gnu-g++ -o bug.o -c bug.cpp -Werror=nonnull
-fno-strict-aliasing
bug.cpp: In member function 'void Iterator::advance()':
bug.cpp:14:46: error: 'this' pointer null [-Werror=nonnull]
14 | current = static_cast(current)->Next();
| ^
bug.cpp:4:6: note: in a call to non-static member function 'D* B::Next()'
4 | D* Next();
| ^~~~
cc1plus: some warnings being treated as errors
Also, the "'this' pointer null" error wording is not very clear. Should it be
"'this' pointer is null"? Or "'this' pointer may be null"?
[Bug other/96217] undefined reference to `_Unwind_Resume'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96217 --- Comment #1 from Richard Biener --- I think you should report this to glibc, not GCC.
[Bug target/96225] ice in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96225
--- Comment #1 from David Binderman ---
Reduced C++ code is:
extern "C" double sqrt(double);
template class a {
public:
a();
void b();
double c, m;
};
template void a::b() {
d e = 1 / sqrt(m);
c = e;
}
class f {
public:
void g() const;
};
class h {
void j() const;
f k;
};
void h::j() const {
a l[1];
for (int i = 0; i < 5; ++i)
l[i].b();
k.g();
}
[Bug target/96225] ice in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96225 Richard Biener changed: What|Removed |Added Target|x86_64 |x86_64-*-* CC||hjl.tools at gmail dot com --- Comment #2 from Richard Biener --- Sounds awfully close to a similar report involving i386.exp testsuite fails.
[Bug driver/96230] driver: ICE in process_command, at gcc.c:5095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96230 Richard Biener changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Richard Biener --- But then an empty dumpbase should be OK?
