[Bug other/105527] configure option --with-zstd is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #6 from Fabian Vogt --- I had a quick debugging session: The DMD lexer code doesn't really care about the size of the buffer and instead runs until it encounters either a 0 or 0x1A byte. The stdin read loop in d_parse_file doesn't explicitly 0-terminate the buffer, which means that it works randomly... With explicit termination it works: ~> echo -e "pragma(msg, int(__VERSION__));\0" | /usr/bin/gdc -x d - 2076 /usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64/Scrt1.o: in function `_start': /home/abuild/rpmbuild/BUILD/glibc-2.35/csu/../sysdeps/x86_64/start.S:103: undefined reference to `main' collect2: error: ld returned 1 exit status This also explains the huge amount of diagnostic messages, which are random based on the content past the module source buffer. It just runs until it encounters a terminator by accident. strace -k shows that the attempts to open "" are actually caused by the printing of diagnostic messages itself, arguably a separate bug.
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #7 from Martin Liška --- Seen by valgrind: ==23477== Conditional jump or move depends on uninitialised value(s) ==23477==at 0x159B539: Lexer::scan(Token*) (lexer.c:267) ==23477==by 0x15CE1F3: UnknownInlinedFun (lexer.c:161) ==23477==by 0x15CE1F3: Parser::parseDeclDefs(int, Dsymbol**, PrefixAttributes*) (parse.c:858) ==23477==by 0x15CE44C: Parser::parseModule() (parse.c:204) ==23477==by 0x14EA392: Module::parse() (dmodule.c:623) ==23477==by 0x166B7F8: d_parse_file() [clone .lto_priv.0] (d-lang.cc:983) ==23477==by 0x1385B54: compile_file() [clone .lto_priv.0] (toplev.c:457) ==23477==by 0x1370773: UnknownInlinedFun (toplev.c:2201) ==23477==by 0x1370773: toplev::main(int, char**) (toplev.c:2340) ==23477==by 0x136F9B3: main (main.c:39) ==23477== ==23477== Use of uninitialised value of size 8 ==23477==at 0x159B543: Lexer::scan(Token*) (lexer.c:267) ==23477==by 0x15CE1F3: UnknownInlinedFun (lexer.c:161) ==23477==by 0x15CE1F3: Parser::parseDeclDefs(int, Dsymbol**, PrefixAttributes*) (parse.c:858) ==23477==by 0x15CE44C: Parser::parseModule() (parse.c:204) ==23477==by 0x14EA392: Module::parse() (dmodule.c:623) ==23477==by 0x166B7F8: d_parse_file() [clone .lto_priv.0] (d-lang.cc:983) ==23477==by 0x1385B54: compile_file() [clone .lto_priv.0] (toplev.c:457) ==23477==by 0x1370773: UnknownInlinedFun (toplev.c:2201) ==23477==by 0x1370773: toplev::main(int, char**) (toplev.c:2340) ==23477==by 0x136F9B3: main (main.c:39) ==23477== 2076
[Bug target/105572] [12/13 Regression] timeout with -march=bdver2 since r12-155-gd8e1f1d24179690f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105572 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|timeout with -march=bdver2 |[12/13 Regression] timeout ||with -march=bdver2 since ||r12-155-gd8e1f1d24179690f Ever confirmed|0 |1 Last reconfirmed||2022-05-12 --- Comment #2 from Martin Liška --- Started with r12-155-gd8e1f1d24179690f. Apparently GAS takes ages in: 81.66% as [.] symbol_clone_if_forward_ref.part.0
[Bug c++/105574] Internal compiler error when co_yield a r-value vector of non-POD type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105574 Martin Liška changed: What|Removed |Added Known to work||12.1.0, 13.0 Last reconfirmed||2022-05-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Fixed with r12-618-g14ed21f8749ae359.
[Bug c++/105577] New: [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577
Bug ID: 105577
Summary: [12 Regression] ICE in delete_unmarked_insns, at
dce.cc:653
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: curdeius at gmail dot com
Target Milestone: ---
Similar to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90082.
GCC 12.1.0 ICEs when compiling this code with:
```
g++ -DROCKSDB_PLATFORM_POSIX -isystem rocksdb-cloud -isystem
rocksdb-cloud/include -O3 -march=haswell -fnon-call-exceptions -c
rocksdb-cloud/db/db_impl/db_impl_compaction_flush.cc
```
All the three flags are important, as the ICE doesn't happen with -O2, nor
without -march, nor with -march=skylake, but it does happen with microarchs
older than haswell.
ICE doesn't happen without -fnon-call-exceptions either.
Version:
```
$ g++ --version
g++ (GCC) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
The minimized repro (couldn't do better for the moment, preprocessed source
attached of both minimal repro and the full file attached):
```
#include "db/db_impl/db_impl.h"
namespace ROCKSDB_NAMESPACE {
void DBImpl::InstallSuperVersionAndScheduleWork(
ColumnFamilyData* cfd, SuperVersionContext* sv_context,
const MutableCFOptions& mutable_cf_options) {
if (UNLIKELY(sv_context->new_superversion == nullptr)) {
sv_context->NewSuperVersion();
}
bottommost_files_mark_threshold_ = kMaxSequenceNumber;
for (auto* my_cfd : *versions_->GetColumnFamilySet()) {
bottommost_files_mark_threshold_ = std::min(
bottommost_files_mark_threshold_,
my_cfd->current()->storage_info()->bottommost_files_mark_threshold());
}
}
} // namespace ROCKSDB_NAMESPACE
```
[Bug c++/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 Curdeius Curdeius changed: What|Removed |Added CC||curdeius at gmail dot com --- Comment #1 from Curdeius Curdeius --- Created attachment 52965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52965&action=edit Preprocessed source of the full reproducer
[Bug c++/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #2 from Curdeius Curdeius --- Created attachment 52966 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52966&action=edit Preprocessed source of the minimal reproducer
[Bug other/97309] Improve documentation of -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309 --- Comment #4 from Jonathan Wakely --- I think this is still unclear. What does "new data races" mean? Can it introduce races in code that had none previously? Or only add new ones to code that already has them? Does this make -Ofast incompatible with multithreaded programs? Does this only apply to non-atomic loads and stores? If all accesses to a variable use atomic ops, does that mean it's immune from the unsafe optimizations enabled by this flag? If no, that makes -Ofast unusable in MT code. If yes, good, but why is the flag needed? If there are non-atomic accesses to a variable, we can already assume it's not concurrently accessed, because any such potentially concurrent conflicting action would already be a data race and UB. If we already have data races with UB, can't we just introduce more? Is this flag saying "allow the compiler to make existing UB even worse"? If not, what is it saying?
[Bug c++/105578] New: `constexpr` does not work on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105578 Bug ID: 105578 Summary: `constexpr` does not work on powerpc Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: liushuyu011 at gmail dot com Target Milestone: --- `constexpr` does not work on PowerPC when you use `-mabi=ibmlongdouble`. Example code (this code snippet is considered well-formed by GCC on other architectures): #include constexpr long double LD_E = 2.71828182845904523536028747135266249775724709369995; constexpr long double LD_E_R = 1.0 / LD_E; GCC will produce an error: test.c:4:36: error: '(1.0e+0l / 2.71828182845904509079559829842765e+0l)' is not a constant expression 4 | constexpr long double LD_E_R = 1.0 / LD_E; |^~
[Bug c++/105575] Segment when riscv64-g++ compile .cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105575 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-05-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #8 from Martin Liška --- I can reproduce it on x86_64-linux-gnu where it ends with stack overflow: Program received signal SIGSEGV, Segmentation fault. 0x011795b3 in comp_template_parms_position (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150) at ../../gcc/cp/typeck.c:1205 1205 if (cxx_dialect >= cxx14 && (is_auto (t1) || is_auto (t2))) (gdb) bt #0 0x011795b3 in comp_template_parms_position (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150) at ../../gcc/cp/typeck.c:1205 #1 0x01178e83 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1358 #2 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #3 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 #4 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #5 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 #6 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #7 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 #8 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #9 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 #10 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #11 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 #12 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #13 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 #14 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #15 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 #16 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #17 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 #18 0x012ab40a in comp_template_parms (parms1=, parms2=) at ../../gcc/cp/pt.c:3369 #19 0x01178eb9 in structural_comptypes (t1=0x7fffd2fa9c78, t2=0x7fffd2fb1150, strict=0) at ../../gcc/cp/typeck.c:1361 While GCC 12.1 rejects the code with: g++ pipeline.ii -c -std=gnu++17 -c In file included from ../../buildtools/third_party/libc++/trunk/include/__locale:15, from ../../buildtools/third_party/libc++/trunk/include/ios:215, from ../../buildtools/third_party/libc++/trunk/include/ostream:137, from ../../src/common/globals.h:12, from ../../src/compiler/pipeline.h:12, from ../../src/compiler/pipeline.cc:5: ../../buildtools/third_party/libc++/trunk/include/string:742:13: error: anonymous struct with base classes Rejected since r12-2627-g3ead06c1cff8fb42.
[Bug other/97309] Improve documentation of -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > If all accesses to a variable use atomic ops, does that mean it's immune > from the unsafe optimizations enabled by this flag? If no, that makes -Ofast > unusable in MT code. If yes, good, but why is the flag needed? If there are > non-atomic accesses to a variable, we can already assume it's not > concurrently accessed, because any such potentially concurrent conflicting > action would already be a data race and UB. If we already have data races > with UB, can't we just introduce more? Is this flag saying "allow the > compiler to make existing UB even worse"? If not, what is it saying? Or maybe this flag is relevant for languages that don't use the C and C++ memory models, where the rules are different?
[Bug c++/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-05-12 Status|UNCONFIRMED |NEW --- Comment #3 from Martin Liška --- Confirmed, reducing right now..
[Bug c/105579] New: make check failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105579 Bug ID: 105579 Summary: make check failed Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lidehua5 at huawei dot com Target Milestone: --- After the source code is compiled and gcc 10.2.0 is installed, the make check command is executed, and 11 use cases report errors. make[4]: Entering directory '/home/stage/root/spack-stage-gcc-10.2.0-6voek42ha7h5bfzq3uyv64zgk2vynxnh/spack-src/spack-build/libbacktrace' PASS: allocfail.sh FAIL: b2test_buildid FAIL: btest_gnudebuglink PASS: test_elf_32 PASS: test_elf_64 PASS: test_xcoff_32 PASS: test_xcoff_64 PASS: test_pecoff PASS: test_unknown PASS: unittest PASS: unittest_alloc FAIL: btest FAIL: btest_lto FAIL: btest_alloc PASS: stest PASS: stest_alloc PASS: ztest PASS: ztest_alloc PASS: edtest PASS: edtest_alloc PASS: ttest PASS: ttest_alloc FAIL: ctestg FAIL: ctesta FAIL: ctestg_alloc FAIL: ctesta_alloc FAIL: dwarf5 FAIL: dwarf5_alloc Testsuite summary for package-unused version-unused # TOTAL: 28 # PASS: 17 # SKIP: 0 # XFAIL: 0 # FAIL: 11 # XPASS: 0 # ERROR: 0 See ./test-suite.log Makefile:1728: recipe for target 'test-suite.log' faile The content of test-suite.log is as follows: FAIL: b2test_buildid ERROR: descriptor 3 still open after tests complete PASS: backtrace_full noinline PASS: backtrace_full inline PASS: backtrace_simple noinline PASS: backtrace_simple inline PASS: backtrace_syminfo variable FAIL b2test_buildid (exit status: 1) FAIL: btest_gnudebuglink ERROR: descriptor 3 still open after tests complete PASS: backtrace_full noinline PASS: backtrace_full inline PASS: backtrace_simple noinline PASS: backtrace_simple inline PASS: backtrace_syminfo variable FAIL btest_gnudebuglink (exit status: 1) FAIL: btest === ERROR: descriptor 3 still open after tests complete PASS: backtrace_full noinline PASS: backtrace_full inline PASS: backtrace_simple noinline PASS: backtrace_simple inline PASS: backtrace_syminfo variable FAIL btest (exit status: 1) FAIL: btest_lto === ERROR: descriptor 3 still open after tests complete PASS: backtrace_full noinline PASS: backtrace_full inline PASS: backtrace_simple noinline PASS: backtrace_simple inline PASS: backtrace_syminfo variable FAIL btest_lto (exit status: 1) FAIL: btest_alloc = ERROR: descriptor 3 still open after tests complete PASS: backtrace_full noinline PASS: backtrace_full inline
[Bug c++/105578] `constexpr` does not work on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105578 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 19779 which I filed over 17 years ago. *** This bug has been marked as a duplicate of bug 19779 ***
[Bug middle-end/19779] IBM 128bit long double format is not constant folded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779 Andrew Pinski changed: What|Removed |Added CC||liushuyu011 at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 105578 has been marked as a duplicate of this bug. ***
[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
>From what I can see, the warning is on dead code.
[local count: 1073741824]:
MEM[(struct _State_base *)&__tmp] ={v} {CLOBBER};
MEM[(struct _State_base *)&__tmp]._M_opcode = 9;
MEM[(struct _State_base *)&__tmp]._M_next = -1;
_12 = MEM[(long unsigned int * const &)this_3(D) + 8];
_1 = MEM[(value_type &)_12 + 18446744073709551608];
__tmp.D.93077.D.69952._M_subexpr = _1;
_11 = _12 + 18446744073709551608;
MEM[(struct vector *)this_3(D)].D.71153._M_impl.D.70460._M_finish = _11;
MEM[(struct _State *)&D.93141] ={v} {CLOBBER};
MEM[(struct _State *)&D.93141].D.93077 = MEM[(struct _State
&)&__tmp].D.93077;
_43 = MEM[(const struct _State *)&__tmp].D.93077._M_opcode;
if (_43 == 11)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 708669600]:
goto ; [100.00%]
[local count: 365072224]:
MEM[(struct function *)&D.93141 + 16B] ={v} {CLOBBER};
MEM[(struct function *)&D.93141 + 16B].D.69910 = {};
_44 = MEM[(struct function &)&__tmp + 16]._M_invoker;
MEM[(struct function *)&D.93141 + 16B]._M_invoker = _44;
__tmp has:
struct _State_base
{
protected:
_Opcode _M_opcode; // type of outgoing transition
public:
_StateIdT_M_next; // outgoing transition
union // Since they are mutually exclusive.
{
size_t _M_subexpr;// for _S_opcode_subexpr_*
size_t _M_backref_index; // for _S_opcode_backref
struct
{
// for _S_opcode_alternative, _S_opcode_repeat and
// _S_opcode_subexpr_lookahead
_StateIdT _M_alt;
// for _S_opcode_word_boundary or _S_opcode_subexpr_lookahead or
// quantifiers (ungreedy if set true)
bool _M_neg;
};
// For _S_opcode_match
__gnu_cxx::__aligned_membuf<_Matcher> _M_matcher_storage;
};
type where _StateIdT is some pointer and _M_matcher_storage is 32 bytes large,
the union is at offset 16.
Now, bb 2 initializes it to be _M_opcode 9 (aka _S_opcode_subexpr_end) with the
_M_subexpr as active
union field (so everything but the first 8 bytes of the union are
uninitialized).
But at the end of the bb we test _M_opcode against 11 (aka _S_opcode_match) and
if it is that
value, we extract std::function's _M_invoker (which is a pointer at offset 16
bytes into the union).
So obviously it is uninitialized but dead.
At -O1 we don't do PRE, but I wonder why fre3 doesn't optimize this.
[local count: 1073741824]:
MEM[(struct _State_base *)&__tmp] ={v} {CLOBBER};
MEM[(struct _State_base *)&__tmp]._M_opcode = 9;
MEM[(struct _State_base *)&__tmp]._M_next = -1;
_12 = MEM[(long unsigned int * const &)this_3(D) + 8];
_1 = MEM[(value_type &)_12 + 18446744073709551608];
__tmp.D.93077.D.69952._M_subexpr = _1;
_11 = _12 + 18446744073709551608;
MEM[(struct vector *)this_3(D)].D.71153._M_impl.D.70460._M_finish = _11;
MEM[(long unsigned int *)_12 + -8B] ={v} {CLOBBER};
MEM[(struct _State *)&D.93141] ={v} {CLOBBER};
MEM[(struct _State *)&D.93141].D.93077 = MEM[(struct _State
&)&__tmp].D.93077;
_43 = MEM[(const struct _State *)&__tmp].D.93077._M_opcode;
if (_43 == 11)
there are 3 stores into __tmp, one to offset 0 4 bytes _M_opcode = 9, one to
offset 8 8 bytes _M_next = -1 and one to offset 16 8 bytes _M_subexpr = _1,
it doesn't seem like other stores could alias with that, so why don't we
optimize _43 = 9; ?
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 Andrew Pinski changed: What|Removed |Added Component|c++ |rtl-optimization Keywords||EH, ice-on-valid-code Summary|[12 Regression] ICE in |[12/13 Regression] ICE in |delete_unmarked_insns, at |delete_unmarked_insns, at |dce.cc:653 |dce.cc:653 Target Milestone|--- |12.2
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #8 from ibuclaw at gcc dot gnu.org --- (In reply to Fabian Vogt from comment #6) > I had a quick debugging session: The DMD lexer code doesn't really care > about the size of the buffer and instead runs until it encounters either a 0 > or 0x1A byte. The stdin read loop in d_parse_file doesn't explicitly > 0-terminate the buffer, which means that it works randomly... > OK, so the suggestion would be to zero the padding at the end of the input buffer then. --- a/gcc/d/d-lang.cc +++ b/gcc/d/d-lang.cc @@ -1072,6 +1072,10 @@ d_parse_file (void) global.params.doHdrGeneration); modules.push (m); + /* Zero the padding past the end of the buffer so the D lexer has a +sentinel. The lexer only reads up to 4 bytes at a time. */ + memset (buffer + len, '\0', 16); + /* Overwrite the source file for the module, the one created by Module::create would have a forced a `.d' suffix. */ m->src.length = len;
[Bug target/105572] [12/13 Regression] timeout with -march=bdver2 since r12-155-gd8e1f1d24179690f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105572 --- Comment #3 from Andrew Pinski --- This should be reported to binutils and closed as moved since this is not a gcc bug.
[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #9 from Jakub Jelinek --- Perhaps with -fno-strict-aliasing we think the store to *this might alias with it? Though, that shouldn't be about TBAA but simple points-to analysis, where obviously this as function argument can't point to a local var in the function.
[Bug testsuite/102742] ERROR: descriptor 3 still open after tests complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102742 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/104371] [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0xFFFF pattern to ptest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371 --- Comment #7 from CVS Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:3c9364f29e7e47eb9de33f2d8843d5b00284ceca commit r13-338-g3c9364f29e7e47eb9de33f2d8843d5b00284ceca Author: Haochen Jiang Date: Tue Feb 8 10:51:26 2022 +0800 i386: Add combine splitter to transform pxor/pcmpeqb/pmovmskb/cmp 0x to ptest. gcc/ChangeLog: PR target/104371 * config/i386/sse.md (vi1avx2const): New define_mode_attr. (pxor/pcmpeqb/pmovmskb/cmp 0x to ptest splitter): New define_split pattern. gcc/testsuite/ChangeLog: PR target/104371 * gcc.target/i386/pr104371-1.c: New test. * gcc.target/i386/pr104371-2.c: Ditto.
[Bug libbacktrace/105579] make check failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105579 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 102742. The problem is just a testsuite issue so it was not backported. Basically make opens fd3 for communication to the jobserver. Anyways see the other bug for more details. *** This bug has been marked as a duplicate of bug 102742 ***
[Bug testsuite/102742] ERROR: descriptor 3 still open after tests complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102742 Andrew Pinski changed: What|Removed |Added CC||lidehua5 at huawei dot com --- Comment #4 from Andrew Pinski --- *** Bug 105579 has been marked as a duplicate of this bug. ***
[Bug c++/105580] New: False warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580
Bug ID: 105580
Summary: False warning "potential null pointer dereference"
raised when using istreambuf_iterator and any "-O"
flag
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: j.gaffiot at laposte dot net
Target Milestone: ---
I found what I believe is a false positive with g++ 12 when using the
"null-dereference" warning and istreambuf_iterator with any level of
optimisation. And of course the "-Werror" flag is mandatory in my company
process.
I have searched for such similar bug report.
This behavior does not show up with g++ 11.2.0 or g++ 9.4.0.
Minimal example (basically the first lines of the cppreference example for
istreambuf_iterator):
#include
#include
int main()
{
std::istringstream in{"Hello, world"};
std::istreambuf_iterator it(in), end;
std::string ss{it, end};
return 0;
}
Compiled with:
g++-12 -O -Wnull-dereference
Compiler version (default g++-12 on Ubuntu 22.04):
g++ (Ubuntu 12-20220319-1ubuntu1) 12.0.1 20220319 (experimental) [master
r12-7719-g8ca61ad148f]
Full version:
Using built-in specs.
COLLECT_GCC=g++-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12-20220319-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--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 --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-OcsLtf/gcc-12-12-20220319/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-OcsLtf/gcc-12-12-20220319/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f]
(Ubuntu 12-20220319-1ubuntu1)
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #9 from Fabian Vogt --- (In reply to ibuclaw from comment #8) > (In reply to Fabian Vogt from comment #6) > > I had a quick debugging session: The DMD lexer code doesn't really care > > about the size of the buffer and instead runs until it encounters either a 0 > > or 0x1A byte. The stdin read loop in d_parse_file doesn't explicitly > > 0-terminate the buffer, which means that it works randomly... > > > > OK, so the suggestion would be to zero the padding at the end of the input > buffer then. > > --- a/gcc/d/d-lang.cc > +++ b/gcc/d/d-lang.cc > @@ -1072,6 +1072,10 @@ d_parse_file (void) > global.params.doHdrGeneration); > modules.push (m); > > + /* Zero the padding past the end of the buffer so the D lexer has a > + sentinel. The lexer only reads up to 4 bytes at a time. */ > + memset (buffer + len, '\0', 16); > + > /* Overwrite the source file for the module, the one created by >Module::create would have a forced a `.d' suffix. */ > m->src.length = len; Yep, that should work. Though I wonder why 16B of padding and not just a single byte for the 0. FWICT the lexer reads a single byte at a time only (utf8_t is an unsigned char), so it should stop at the first 0. The comment above explaining the padding mentions a "final '\n'" which should probably be adjusted with the change to \0.
[Bug target/104371] [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0xFFFF pattern to ptest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371 --- Comment #8 from Haochen Jiang --- Fixed for GCC 13.
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #4 from Curdeius Curdeius --- Created attachment 52967 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52967&action=edit A slightly reduced case A bit more reduced reproducer. Not sure it helps.
[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> Perhaps with -fno-strict-aliasing we think the store to *this might alias
> with it? Though, that shouldn't be about TBAA but simple points-to
> analysis, where obviously this as function argument can't point to a local
> var in the function.
It's the
MEM[(long unsigned int *)_12 + -8B] ={v} {CLOBBER};
store, __tmp escapes in the indirect call
_48 (&MEM[(struct _Function_base *)&__tmp + 16B]._M_functor,
&MEM[(struct _Function_base *)&__tmp + 16B]._M_functor, 3);
and _12 points to escaped (its loaded from this).
I guess since a CLOBBER isn't technically a "store" we could ignore it
and continue looking for data to load. If it would alias then we'd
access (partly) 'uninitialized' memory which would invoke undefined
behavior.
[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
--- Comment #11 from Richard Biener ---
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index d4d0aba880c..9f7f12846cb 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -2593,6 +2593,11 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*data_,
bool lhs_ref_ok = false;
poly_int64 copy_size;
+ /* We can optimistically disambiguate against CLOBBERs, when there
+ is any overlap it would be undefined behavior. */
+ if (gimple_clobber_p (def_stmt))
+return NULL;
+
/* First try to disambiguate after value-replacing in the definitions LHS.
*/
if (is_gimple_assign (def_stmt))
{
avoids the diagnostics.
[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #12 from Richard Biener ---
I'm going to test this.
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index d4d0aba880c..c9965549fce 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -2620,6 +2620,16 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*data_,
return NULL;
}
+ /* When the def is a CLOBBER we can optimistically disambiguate
+against it since any overlap it would be undefined behavior.
+Avoid this for obvious must aliases to save compile-time though. */
+ if (gimple_clobber_p (def_stmt)
+ && !operand_equal_p (ao_ref_base (&lhs_ref), base, OEP_ADDRESS_OF))
+ {
+ *disambiguate_only = TR_DISAMBIGUATE;
+ return NULL;
+ }
+
/* Besides valueizing the LHS we can also use access-path based
disambiguation on the original non-valueized ref. */
if (!ref->ref
[Bug c/105581] New: boolean types and relational operators problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105581
Bug ID: 105581
Summary: boolean types and relational operators problem
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: ---
For this C code:
void g( int );
void f( bool a, bool b)
{
if (a < b)
g( 1);
}
recent gcc doesn't find a problem:
$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -pedantic may12a.cc
$
Here is cppcheck complaining:
$ /home/dcb/cppcheck/trunk.git/cppcheck --enable=all may12a.cc
may12a.cc:6:8: style: Comparison of a variable having boolean value using
relational (<, >, <= or >=) operator. [comparisonOfBoolWithBoolError]
if (a < b)
^
$
There is an example in the gcc source code:
trunk.git/gcc/sreal.h:72:25: style: Comparison of a variable having boolean
value using relational (<, >, <= or >=) operator.
[comparisonOfBoolWithBoolError]
Source code is
return negative > other_negative;
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #5 from Martin Liška --- (In reply to Curdeius Curdeius from comment #4) > Created attachment 52967 [details] > A slightly reduced case > > A bit more reduced reproducer. > Not sure it helps. No, we would need a pre-processed source file reproducer.
[Bug c++/105578] `constexpr` does not work on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105578 --- Comment #2 from Jonathan Wakely --- (In reply to shuyu liu from comment #0) > `constexpr` does not work on PowerPC when you use `-mabi=ibmlongdouble`. That's a pretty bold claim! **Some** long double arithmetic does not work in constant expressions.
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 Martin Liška changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in |delete_unmarked_insns, at |delete_unmarked_insns, at |dce.cc:653 |dce.cc:653 since ||r12-248-gb58dc0b803057c0e --- Comment #6 from Martin Liška --- With -fdelete-dead-exceptions, it started with r12-248-gb58dc0b803057c0e. The reduction is pretty slow..
[Bug c/105581] boolean types and relational operators problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105581 --- Comment #1 from Andrew Pinski --- Well. There is a meaning for the code though. That is negative > other_negative Means negative is true while other_negative is false the result will be true which is exactly what it is testing here.
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #7 from Andrew Pinski --- (In reply to Martin Liška from comment #6) > With -fdelete-dead-exceptions, it started with r12-248-gb58dc0b803057c0e. > The reduction is pretty slow.. That just exposed the issue I think since the failure is at the rtl level while that change effects things way before in gimple.
[Bug c/105581] boolean types and relational operators problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105581 --- Comment #2 from Andreas Schwab --- Equivalent to negative && !other_negative.
[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #13 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:94b8a37fa16f7638cc1965718f4ec71719506743 commit r13-340-g94b8a37fa16f7638cc1965718f4ec71719506743 Author: Richard Biener Date: Thu May 12 12:13:29 2022 +0200 tree-optimization/105562 - avoid uninit diagnostic with better FRE We can avoid some uninit diagnostics by making FRE disambiguate against CLOBBERs since any aliasing there would invoke undefined behavior for a read we are looking up. 2022-05-12 Richard Biener PR tree-optimization/105562 * tree-ssa-sccvn.cc (vn_reference_lookup_3): Disambiguate against all CLOBBER defs if there's not an obvious must-alias and we are not doing redundant store elimination. (vn_walk_cb_data::redundant_store_removal_p): New field. (vn_reference_lookup_pieces): Initialize it. (vn_reference_lookup): Add argument to specify if we are doing redundant store removal. (eliminate_dom_walker::eliminate_stmt): Specify we do. * tree-ssa-sccvn.h (vn_reference_lookup): Adjust. * g++.dg/warn/uninit-pr105562.C: New testcase.
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 Richard Biener changed: What|Removed |Added Known to fail||12.1.0 Known to work||11.3.0, 13.0 Summary|std::function:: |[12 Regression] |_M_invoker may be used |std::function:: |uninitialized in std::regex |_M_invoker may be used |move with |uninitialized in std::regex |-fno-strict-aliasing|move with ||-fno-strict-aliasing --- Comment #14 from Richard Biener --- Fixed on trunk sofar.
[Bug target/105572] [12/13 Regression] timeout with -march=bdver2 since r12-155-gd8e1f1d24179690f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105572 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.2
[Bug target/105572] [12/13 Regression] timeout with -march=bdver2 since r12-155-gd8e1f1d24179690f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105572 --- Comment #4 from Martin Liška --- I bisected that and it's fixed in master (not present in any release branch): commit fb0e49d8e05e61ca2af9b5f60b01ad5fb6d274ff Author: Alan Modra Date: Tue Mar 8 22:48:51 2022 +1030 Constant fold view increment expressions The idea here is to replace expressions like v + 1 + 1 + 1 with v + 3. * dwarf2dbg.c (set_or_check_view): Remove useless assertion. Resolve multiple view increments. * testsuite/gas/elf/dwarf2-18.d: Don't xfail mep.
[Bug target/105572] [12/13 Regression] timeout with -march=bdver2 since r12-155-gd8e1f1d24179690f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105572 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Martin Liška --- Fixed in binutils master.
[Bug target/105573] ICE when building numpy on SPARC64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105573 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Richard Biener --- Doing the dup honor. *** This bug has been marked as a duplicate of bug 105312 ***
[Bug tree-optimization/105312] [11 Regression] ICE in gimple_expand_vec_cond_expr on arm-linux since r12-834-ga6eacbf1055520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105312 --- Comment #10 from Richard Biener --- *** Bug 105573 has been marked as a duplicate of this bug. ***
[Bug c/105581] boolean types and relational operators problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105581 --- Comment #3 from David Binderman --- (In reply to Andrew Pinski from comment #1) > Well. There is a meaning for the code though. > That is negative > other_negative > Means negative is true while other_negative is false the result will be true > which is exactly what it is testing here. In abstract, false and true can't be compared with "<". In the implementation choice of false as 0 and true as 1, then relying on the implementation values does make "<" valid. I think that's the bad style cppcheck is complaining about. It's just better style to have it as a logical expression, as Andreas shows.
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577
--- Comment #8 from Richard Biener ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Martin Liška from comment #6)
> > With -fdelete-dead-exceptions, it started with r12-248-gb58dc0b803057c0e.
> > The reduction is pretty slow..
>
> That just exposed the issue I think since the failure is at the rtl level
> while that change effects things way before in gimple.
So the insn removed that triggers the must_clean is
(insn/v 27 23 30 3 (set (reg:V2DI 107)
(const_vector:V2DI [
(const_int 0 [0]) repeated x2
])) "/usr/local/include/c++/12.1.0/bits/shared_ptr_base.h":1463:9
1700 {movv2di_internal}
(nil))
we first remove that and then call purge_dead_edges which then runs into
the newly(!) last insn:
(call_insn 23 22 30 3 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("memset") [flags 0x41] ) [0 __builtin_memset S1 A8])
(const_int 0 [0])))
"../../thirdparty/rocksdb-cloud/db/job_context.h":49:29 909 {*call_value}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:SI 4 si)
(expr_list:REG_DEAD (reg:DI 1 dx)
(expr_list:REG_UNUSED (reg:DI 0 ax)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("memset") [flags
0x41] )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:DI (set (reg:DI 0 ax)
(reg:DI 5 di))
(expr_list:DI (use (reg:DI 5 di))
(expr_list:SI (use (reg:SI 4 si))
(expr_list:DI (use (reg:DI 1 dx))
(nil))
which cannot throw. But we still have an EH edge out of this block which
is the real issue here. Somebody forgot to clean the EH edge earlier.
In fact before DSE we have
(insn 27 23 28 3 (set (reg:V2DI 107)
(const_vector:V2DI [
(const_int 0 [0]) repeated x2
])) "/usr/local/include/c++/12.1.0/bits/shared_ptr_base.h":1463:9
1700 {movv2di_internal}
(nil))
(insn 28 27 29 3 (set (mem:V2DI (plus:DI (reg/f:DI 94 [ _34 ])
(const_int 96 [0x60])) [0 MEM
[(void *)_34 + 96B]+0 S16 A64])
(reg:V2DI 107))
"/usr/local/include/c++/12.1.0/bits/shared_ptr_base.h":1463:9 1700
{movv2di_internal}
(expr_list:REG_DEAD (reg:V2DI 107)
(expr_list:REG_EH_REGION (const_int -15 [0xfff1])
(nil
(insn 29 28 30 3 (set (mem:QI (plus:DI (reg/f:DI 94 [ _34 ])
(const_int 112 [0x70])) [26 MEM[(struct MutableCFOptions *)_34
+ 32B].disable_auto_compactions+0 S1 A64])
(const_int 0 [0]))
"../../thirdparty/rocksdb-cloud/options/cf_options.h":173:9 83
{*movqi_internal}
(expr_list:REG_EH_REGION (const_int 3 [0x3])
(nil)))
;; succ: 4 [always] count:1459806 (estimated locally) (FALLTHRU)
;; 49 [never] count:0 (precise) (ABNORMAL,EH)
so DSE removes insn 28 and insn 29 but forgets to clean EH.
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #9 from Richard Biener ---
So DSE does
/* DSE can eliminate potentially-trapping MEMs.
Remove any EH edges associated with them. */
if ((locally_deleted || globally_deleted)
&& cfun->can_throw_non_call_exceptions
&& purge_all_dead_edges ())
{
free_dominance_info (CDI_DOMINATORS);
cleanup_cfg (0);
which should do the trick, but the fast-DCE is invoked via
dse_step0 ();
dse_step1 ();
dse_step2_init ();
if (dse_step2 ())
{
df_set_flags (DF_LR_RUN_DCE);
df_analyze ();
and dse_step0/1 already removed the stores, exposing the bad IL. One
way to fix this might be to run cleanup_cfg after dse_step1 already,
or just remove_unreachable_blocks.
I'm going to test
diff --git a/gcc/dse.cc b/gcc/dse.cc
index b8914a3ae24..bb658a85959 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -3682,6 +3682,16 @@ rest_of_handle_dse (void)
dse_step0 ();
dse_step1 ();
+ /* DSE can eliminate potentially-trapping MEMs.
+ Remove any EH edges associated with them, since otherwise
+ DF_LR_RUN_DCE will complain later. */
+ if ((locally_deleted || globally_deleted)
+ && cfun->can_throw_non_call_exceptions
+ && purge_all_dead_edges ())
+{
+ free_dominance_info (CDI_DOMINATORS);
+ delete_unreachable_blocks ();
+}
dse_step2_init ();
if (dse_step2 ())
{
[Bug c/105581] boolean types and relational operators problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105581 --- Comment #4 from Andreas Schwab --- There is nothing abstractly wrong with ordering false and true.
[Bug fortran/105582] New: ICE on procedure pointer assignment inside block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105582 Bug ID: 105582 Summary: ICE on procedure pointer assignment inside block Product: gcc Version: og11 (devel/omp/gcc-11) Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rnhmjoj at eurofusion dot eu Target Milestone: --- Compiling this program: program pointer_block__crash abstract interface subroutine f() end subroutine end interface block procedure(f), pointer :: p p => nop end block contains subroutine nop() end subroutine end program with gfortran results in an internal compiler error, producing this error message: crash.f90:1:28: 1 | program pointer_block__crash |^ internal compiler error: Segmentation fault 0x1666927 internal_error(char const*, ...) ???:0 0xe9c083 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ???:0 0x9bd1d6 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ???:0 0x9bd37a walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ???:0 0x9bd510 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ???:0 0x9bd409 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ???:0 0x9bd510 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ???:0 0xcb199e lower_nested_functions(tree_node*) ???:0 0x86a856 cgraph_node::analyze() ???:0 0x86da1d symbol_table::finalize_compilation_unit() ???:0 I tested on GCC 9.3.0, 10.3.0, 11.2.0 and all versions result in the same error.
[Bug c++/97938] [9/10 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 Jason Merrill changed: What|Removed |Added Target Milestone|9.4 |10.4 --- Comment #10 from Jason Merrill --- Not actually fixed on 9 branch.
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #10 from ibuclaw at gcc dot gnu.org --- (In reply to Fabian Vogt from comment #9) > (In reply to ibuclaw from comment #8) > > (In reply to Fabian Vogt from comment #6) > > > I had a quick debugging session: The DMD lexer code doesn't really care > > > about the size of the buffer and instead runs until it encounters either > > > a 0 > > > or 0x1A byte. The stdin read loop in d_parse_file doesn't explicitly > > > 0-terminate the buffer, which means that it works randomly... > > > > > > > OK, so the suggestion would be to zero the padding at the end of the input > > buffer then. > > > > --- a/gcc/d/d-lang.cc > > +++ b/gcc/d/d-lang.cc > > @@ -1072,6 +1072,10 @@ d_parse_file (void) > > global.params.doHdrGeneration); > > modules.push (m); > > > > + /* Zero the padding past the end of the buffer so the D lexer has a > > +sentinel. The lexer only reads up to 4 bytes at a time. */ > > + memset (buffer + len, '\0', 16); > > + > > /* Overwrite the source file for the module, the one created by > > Module::create would have a forced a `.d' suffix. */ > > m->src.length = len; > > Yep, that should work. Though I wonder why 16B of padding and not just a > single byte for the 0. FWICT the lexer reads a single byte at a time only > (utf8_t is an unsigned char), so it should stop at the first 0. > > The comment above explaining the padding mentions a "final '\n'" which > should probably be adjusted with the change to \0. The lexer scans spaces 4 bytes at a time (*cast(uint*)p == 0x20202020). So should zero at least 4 bytes to avoid asan complaining about reading uninitialized memory.
[Bug c++/105580] [12/13 Regression] False warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.2 Keywords||diagnostic Summary|False warning "potential|[12/13 Regression] False |null pointer dereference" |warning "potential null |raised when using |pointer dereference" raised |istreambuf_iterator and any |when using |"-O" flag |istreambuf_iterator and any ||"-O" flag
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:dfda40f8147412328f699628a54b0aaa584776e7 commit r13-373-gdfda40f8147412328f699628a54b0aaa584776e7 Author: Richard Biener Date: Thu May 12 14:03:32 2022 +0200 rtl-optimization/105577 - RTL DSE and non-call EH When one of the first two stages of DSE removes a throwing stmt we have to purge dead EH edges before the DF re-analyze fires off a fast DCE since that cannot cope with the situation. 2022-05-12 Richard Biener PR rtl-optimization/105577 * dse.cc (rest_of_handle_dse): Make sure to purge dead EH edges before running fast DCE via df_analyze.
[Bug rtl-optimization/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 Richard Biener changed: What|Removed |Added Known to work||13.0 Priority|P3 |P2 Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |delete_unmarked_insns, at |delete_unmarked_insns, at |dce.cc:653 since|dce.cc:653 since |r12-248-gb58dc0b803057c0e |r12-248-gb58dc0b803057c0e Known to fail||12.1.0 --- Comment #11 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/105583] New: Syntax error when alias template in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105583
Bug ID: 105583
Summary: Syntax error when alias template in requires-clause
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
template
constexpr bool v = true;
template
using A = decltype([] { return 0; }());
template
using B = decltype([] {
if (requires { v&>; }) { }
}());
https://godbolt.org/z/WseWqKMcG
gcc rejects the above legal syntax.
[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918 Jason Merrill changed: What|Removed |Added Target Milestone|9.5 |11.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jason Merrill --- The patch for this ended up causing a lot of problems, so I reverted it on the 10 branch and am not going to try to fix it in 9/10.
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #11 from Fabian Vogt --- (In reply to ibuclaw from comment #10) > (In reply to Fabian Vogt from comment #9) > > (In reply to ibuclaw from comment #8) > > > (In reply to Fabian Vogt from comment #6) > > > > I had a quick debugging session: The DMD lexer code doesn't really care > > > > about the size of the buffer and instead runs until it encounters > > > > either a 0 > > > > or 0x1A byte. The stdin read loop in d_parse_file doesn't explicitly > > > > 0-terminate the buffer, which means that it works randomly... > > > > > > > > > > OK, so the suggestion would be to zero the padding at the end of the input > > > buffer then. > > > > > > --- a/gcc/d/d-lang.cc > > > +++ b/gcc/d/d-lang.cc > > > @@ -1072,6 +1072,10 @@ d_parse_file (void) > > > global.params.doHdrGeneration); > > > modules.push (m); > > > > > > + /* Zero the padding past the end of the buffer so the D lexer has a > > > + sentinel. The lexer only reads up to 4 bytes at a time. */ > > > + memset (buffer + len, '\0', 16); > > > + > > > /* Overwrite the source file for the module, the one created by > > >Module::create would have a forced a `.d' suffix. */ > > > m->src.length = len; > > > > Yep, that should work. Though I wonder why 16B of padding and not just a > > single byte for the 0. FWICT the lexer reads a single byte at a time only > > (utf8_t is an unsigned char), so it should stop at the first 0. > > > > The comment above explaining the padding mentions a "final '\n'" which > > should probably be adjusted with the change to \0. > > The lexer scans spaces 4 bytes at a time (*cast(uint*)p == 0x20202020). So > should zero at least 4 bytes to avoid asan complaining about reading > uninitialized memory. Indeed, that's the case with GCC 12. I've been looking at the code from GCC 11, where it doesn't do that yet (and the frontend is still in C).
[Bug c++/105583] Syntax error when alias template in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105583 --- Comment #1 from 康桓瑋 --- It may be a duplicate of PR102881 since decltype lambda is also used.
[Bug modula2/105411] gm2 testsuite should use TEST_ALWAYS_FLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105411 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Gaius Mulley --- > I've added TEST_ALWAYS_FLAGS to the gcc/testsuite/lib/gm2.exp as per other > tests. Looks good now. Thanks.
[Bug target/104862] extern thread_local (emutls) code crashes with ASLR on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104862 Alvin Wong changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Alvin Wong --- I found from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697#c25 that there was a change that seems related to the issue observed in this report. Can anyone check? > The master branch has been updated by Eric Botcazou : > > https://gcc.gnu.org/g:021ad8e5cf9ab66e1a0a41dce3a54586facb86e0 > > commit r12-4036-g021ad8e5cf9ab66e1a0a41dce3a54586facb86e0 > Author: Eric Botcazou > Date: Fri Oct 1 10:49:34 2021 +0200 > > Fix PR c++/64697 at -O1 or above > > The BFD fix eliminates the link failure and working code is generated at > -O0, but _not_ when optimization is enabled because the optimizer > changes: > > movq.refptr._ZTH1s(%rip), %rax > testq %rax, %rax > je .L2 > call_ZTH1s > > into: > > leaq_ZTH1s(%rip), %rax > testq %rax, %rax > je .L2 > call_ZTH1s > > and the leaq now also gets the relocation overflow. So the fix is to > teach legitimate_pic_address_disp_p to reject the transformation when > the symbol is an external weak function, which yields: > > cmpq$0, .refptr._ZTH1s(%rip) > je .L2 > call_ZTH1s > > and the cmpq keeps a relocation that does not overflow. > > gcc/ > PR c++/64697 > * config/i386/i386.c (legitimate_pic_address_disp_p): For > PE-COFF do > not return true for external weak function symbols in medium > model.
[Bug rtl-optimization/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577
--- Comment #12 from Martin Liška ---
There's a reduced test case, can you please include it in testsuite?
namespace {
typedef long size_t;
}
typedef char uint8_t;
typedef long uint64_t;
namespace {
template struct integral_constant {
static constexpr _Tp value = __v;
};
template using __bool_constant = integral_constant;
template struct __conditional {
template using type = _Tp;
};
template
using __conditional_t = typename __conditional<_Cond>::type<_If, _Else>;
template struct __and_;
template
struct __and_<_B1, _B2> : __conditional_t<_B1::value, _B2, _B1> {};
template struct __not_ : __bool_constant {};
template
struct __is_constructible_impl : __bool_constant<__is_constructible(_Tp)> {};
template
struct is_default_constructible : __is_constructible_impl<_Tp> {};
template struct remove_extent { typedef _Tp type; };
template struct enable_if;
} // namespace
namespace std {
template struct allocator_traits { using pointer = _Tp; };
template struct __alloc_traits : allocator_traits<_Alloc> {};
template struct _Vector_base {
typedef typename __alloc_traits<_Alloc>::pointer pointer;
struct {
pointer _M_finish;
pointer _M_end_of_storage;
};
};
template
class vector : _Vector_base<_Tp, _Alloc> {
public:
_Tp value_type;
typedef size_t size_type;
};
template class __uniq_ptr_impl {
template struct _Ptr { using type = _Up *; };
public:
using _DeleterConstraint =
enable_if<__and_<__not_<_Dp>, is_default_constructible<_Dp>>::value>;
using pointer = typename _Ptr<_Tp, _Dp>::type;
};
template class unique_ptr {
public:
using pointer = typename __uniq_ptr_impl<_Tp, _Dp>::pointer;
pointer operator->();
};
enum _Lock_policy { _S_atomic } const __default_lock_policy = _S_atomic;
template <_Lock_policy = __default_lock_policy> class _Sp_counted_base;
template class __shared_ptr;
template <_Lock_policy> class __shared_count { _Sp_counted_base<> *_M_pi; };
template class __shared_ptr {
using element_type = typename remove_extent<_Tp>::type;
element_type *_M_ptr;
__shared_count<_Lp> _M_refcount;
};
template class shared_ptr : __shared_ptr<_Tp> {
public:
shared_ptr() noexcept : __shared_ptr<_Tp>() {}
};
enum CompressionType : char;
class SliceTransform;
enum Temperature : uint8_t;
struct MutableCFOptions {
MutableCFOptions()
: soft_pending_compaction_bytes_limit(),
hard_pending_compaction_bytes_limit(level0_file_num_compaction_trigger),
level0_slowdown_writes_trigger(level0_stop_writes_trigger),
max_compaction_bytes(target_file_size_base),
target_file_size_multiplier(max_bytes_for_level_base),
max_bytes_for_level_multiplier(ttl), compaction_options_fifo(),
min_blob_size(blob_file_size), blob_compression_type(),
enable_blob_garbage_collection(blob_garbage_collection_age_cutoff),
max_sequential_skip_in_iterations(check_flush_compaction_key_order),
paranoid_file_checks(bottommost_compression), bottommost_temperature(),
sample_for_compression() {}
shared_ptr prefix_extractor;
uint64_t soft_pending_compaction_bytes_limit;
uint64_t hard_pending_compaction_bytes_limit;
int level0_file_num_compaction_trigger;
int level0_slowdown_writes_trigger;
int level0_stop_writes_trigger;
uint64_t max_compaction_bytes;
uint64_t target_file_size_base;
int target_file_size_multiplier;
uint64_t max_bytes_for_level_base;
double max_bytes_for_level_multiplier;
uint64_t ttl;
vector compaction_options_fifo;
uint64_t min_blob_size;
uint64_t blob_file_size;
CompressionType blob_compression_type;
bool enable_blob_garbage_collection;
double blob_garbage_collection_age_cutoff;
uint64_t max_sequential_skip_in_iterations;
bool check_flush_compaction_key_order;
bool paranoid_file_checks;
CompressionType bottommost_compression;
Temperature bottommost_temperature;
uint64_t sample_for_compression;
};
template class autovector {
using value_type = T;
using size_type = typename vector::size_type;
size_type buf_[kSize * sizeof(value_type)];
};
class MemTable;
class ColumnFamilyData;
struct SuperVersion {
MutableCFOptions write_stall_condition;
autovector to_delete;
};
class ColumnFamilySet {
public:
class iterator {
public:
iterator operator++();
bool operator!=(iterator);
ColumnFamilyData *operator*();
ColumnFamilyData *current_;
};
iterator begin();
iterator end();
};
class VersionSet {
public:
ColumnFamilySet *GetColumnFamilySet();
};
struct SuperVersionContext {
void NewSuperVersion() { new SuperVersion(); }
};
class DBImpl {
unique_ptr versions_;
void InstallSuperVersionAndScheduleWork(ColumnFamilyData *,
SuperVersionContext *,
const MutableCFOptions &);
};
void DBImpl::InstallSuperVersionAndScheduleWork(ColumnFamilyData *,
SuperVe
[Bug tree-optimization/104017] unexpected -Warray-bounds popping a fixed number of std::deque elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104017 --- Comment #6 from Lars Gullik Bjønnes --- This is from a report I made in private to Martin, for GCC12. That tidbit seems to have been lost in the bug creation.
[Bug target/104862] extern thread_local (emutls) code crashes with ASLR on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104862 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-12 --- Comment #2 from Eric Botcazou --- > I found from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697#c25 that > there was a change that seems related to the issue observed in this report. Yes, this looks like the same issue, so the fix needs to be extended.
[Bug tree-optimization/105545] [12/13 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545 Ed Catmur changed: What|Removed |Added CC||ed at catmur dot uk --- Comment #3 from Ed Catmur --- I don't think _GLIBCXX_ASSERTIONS is necessary; you just need -Werror=restrict and -O2 (not sure what exactly). https://godbolt.org/z/TvfYzbcf6
[Bug target/105573] ICE when building numpy on SPARC64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105573 --- Comment #7 from Sam James --- 1. Could you consider the fix for backporting please to 11? It works for me as-is. 2. Will the testcase be committed?
[Bug tree-optimization/105545] [12/13 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545 --- Comment #4 from Tom Hughes --- You don't need -D_GLIBCXX_ASSERTIONS in C++20 mode but you do in C++17 mode it seems.
[Bug tree-optimization/105545] [12/13 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545 --- Comment #5 from Tom Hughes --- On top of -O1 you seem to need all of -fexpensive-optimizations -ftree-vrp -fipa-sra to trigger it.
[Bug c++/105584] New: libcxx needs using_if_exist attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105584 Bug ID: 105584 Summary: libcxx needs using_if_exist attribute Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://github.com/llvm/llvm-project/blob/14e83ada16b3944a4431617ed4ce7088f7f7cd9a/libcxx/include/__config#L772 #if __has_attribute(using_if_exists) # define _LIBCPP_USING_IF_EXISTS __attribute__((using_if_exists)) #else # define _LIBCPP_USING_IF_EXISTS #endif libcxx recently switches a lot of C usings with the new using_if_exists attribute in clang, but GCC does not support it, causing compilation to fail if these global definitions do not exist. /home/cqwrteur/toolchains/native/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/v1/cstdlib:139:9: error: 'aligned_alloc' has not been declared in '::' 139 | using ::aligned_alloc _LIBCPP_USING_IF_EXISTS; | ^ /home/cqwrteur/toolchains/native/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/v1/ctime:75:9: error: 'timespec_get' has not been declared in '::' 75 | using ::timespec_get _LIBCPP_USING_IF_EXISTS; | ^~~~ I think GCC should add this attribute to support libcxx correctly.
[Bug c++/105584] libcxx needs using_if_exist attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105584 --- Comment #1 from cqwrteur --- [clang] Implement the using_if_exists attribute https://github.com/llvm/llvm-project/commit/369c64839946d89cf5697550b6feeea031b2f270 This shows how the attribute works. Hope GCC could add it. Also probably need __clang__::__using_if_exists__ too to avoid name collisions.
[Bug c++/105584] libcxx needs using_if_exist attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105584 --- Comment #2 from cqwrteur --- https://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html According to the proposal, it looks like this attribute could benefit libstdc++ too since I do see similar issues before.
[Bug c/105585] New: [12/13 Regression] Spurious stringop-overflow warning with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105585
Bug ID: 105585
Summary: [12/13 Regression] Spurious stringop-overflow warning
with
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
Reduced (from code in abseil-cpp):
#include
struct S {
int i;
std::atomic a;
};
S* q();
void f();
void g(bool b) {
auto p = b ? q() : nullptr;
++p->a;
if (p)
f();
}
In file included from atomic:41,
from :1:
In member function 'std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::operator++() [with _ITp = int]',
inlined from 'void g(bool)' at :10:3:
bits/atomic_base.h:385:34: warning: 'unsigned int __atomic_add_fetch_4(volatile
void*, unsigned int, int)' writing 4 bytes into a region of size 0 overflows
the destination [-Wstringop-overflow=]
385 | { return __atomic_add_fetch(&_M_i, 1, int(memory_order_seq_cst));
}
|~~^
[Bug c/105585] [12/13 Regression] Spurious stringop-overflow warning with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105585 --- Comment #1 from Ed Catmur --- Flags: -O1 -Wstringop-overflow=1 https://godbolt.org/z/8r8roz7Pa
[Bug c/105585] [12/13 Regression] Spurious stringop-overflow warning with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105585 --- Comment #2 from Ed Catmur --- Affected code: https://github.com/abseil/abseil-cpp/issues/1175 The proposed patch to abseil-cpp corresponds to adding an assumption that `b` is true above.
[Bug c++/105584] libcxx needs using_if_exist attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105584 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Jonathan Wakely --- libc++ should be using __has_cpp_attribute if they still expect to build with GCC.
[Bug libstdc++/17632] Non-portable whitespace in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17632 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a0080f0285dfa9b7f0b7a6c5ec79e28eb662b953 commit r13-375-ga0080f0285dfa9b7f0b7a6c5ec79e28eb662b953 Author: Jonathan Wakely Date: Thu May 12 17:37:33 2022 +0100 libstdc++: Remove whitespace before preprocessor directives These are harmless, but also unnecessary and inconsistent (and their removal was requested by PR libstdc++/17632). libstdc++-v3/ChangeLog: * config/locale/dragonfly/numeric_members.cc: Remove whitespace. * config/locale/gnu/numeric_members.cc: Likewise. * include/bits/locale_facets_nonio.h: Likewise. * libsupc++/typeinfo: Likewise.
[Bug debug/105586] New: [11/12/13 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586
Bug ID: 105586
Summary: [11/12/13 Regression] -fcompare-debug failure (length)
with -O2 -fno-if-conversion -mtune=power4
-fno-guess-branch-probability
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu
Created attachment 52968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52968&action=edit
reduced testcase
Compiler output:
$ powerpc64le-unknown-linux-gnu-gcc -O2 -fno-if-conversion -mtune=power4
-fno-guess-branch-probability -fcompare-debug testcase.c
powerpc64le-unknown-linux-gnu-gcc: error: testcase.c: '-fcompare-debug' failure
(length)
$ diff -u *gkd
--- a-testcase.c.gkd2022-05-12 21:05:45.139502516 +0200
+++ a-testcase.gk.c.gkd 2022-05-12 21:05:45.172835666 +0200
@@ -128,21 +128,23 @@
(and:SI (reg:SI 10 10 [orig:136 u128_1 ] [136])
(const_int 8 [0x8]))) "testcase.c":14:78# {andsi3_mask}
(nil))
-(insn:TI # 0 0 (set (reg:DI 3 3 [orig:161 u64_4 ] [161])
-(ashift:DI (reg:DI 3 3 [147])
-(reg:SI 10 10 [160]))) "testcase.c":14:7# {ashldi3}
- (expr_list:REG_DEAD (reg:SI 10 10 [160])
-(nil)))
-(insn # 0 0 (set (reg:DI 30 30 [162])
+(insn:TI # 0 0 (set (reg:DI 30 30 [162])
(plus:DI (reg/v:DI 30 30 [orig:145 b ] [145])
(reg/v:DI 9 9 [orig:134 u64_3 ] [134]))) "testcase.c":15:17#
{*adddi3}
(expr_list:REG_DEAD (reg/v:DI 9 9 [orig:134 u64_3 ] [134])
(nil)))
+(insn # 0 0 (set (reg:DI 9 9 [orig:161 u64_4 ] [161])
+(ashift:DI (reg:DI 3 3 [147])
+(reg:SI 10 10 [160]))) "testcase.c":14:7# {ashldi3}
+ (expr_list:REG_DEAD (reg:SI 10 10 [160])
+(expr_list:REG_DEAD (reg:DI 3 3 [147])
+(nil
(insn # 0 0 (set (reg:DI 3 3 [orig:163 u64_r ] [163])
-(plus:DI (reg:DI 3 3 [orig:161 u64_4 ] [161])
+(plus:DI (reg:DI 9 9 [orig:161 u64_4 ] [161])
(reg:DI 30 30 [162]))) "testcase.c":15:7# {*adddi3}
(expr_list:REG_DEAD (reg:DI 30 30 [162])
-(nil)))
+(expr_list:REG_DEAD (reg:DI 9 9 [orig:161 u64_4 ] [161])
+(nil
(insn # 0 0 (set (reg:SI 3 3 [orig:164 u64_r ] [164])
(sign_extend:SI (reg:HI 3 3 [orig:163 u64_r ] [163])))
"testcase.c":16:7# {*extendhisi2}
(nil))
$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-333-20220511161459-g25addf8352e-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/13.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-333-20220511161459-g25addf8352e-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220511 (experimental) (GCC)
[Bug c++/104142] [9/10/11 Regression] Spurious warning unused-variable on const static variable and defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5296b77556da4682d5a1e2318c0643affaa00563 commit r11-9981-g5296b77556da4682d5a1e2318c0643affaa00563 Author: Jason Merrill Date: Mon Apr 11 14:50:14 2022 -0400 c++: rodata and defaulted ctor [PR104142] Trivial initialization shouldn't bump a variable out of .rodata; if the result of build_aggr_init is an empty STATEMENT_LIST, throw it away. PR c++/104142 gcc/cp/ChangeLog: * decl.c (check_initializer): Check TREE_SIDE_EFFECTS. gcc/testsuite/ChangeLog: * g++.dg/opt/const7.C: New test.
[Bug c++/102071] [10/11 Regression] crash when combining -faligned-new=N with array cookie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102071 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:394c852a6b4bed8117c790c2cd1553e224975ad5 commit r11-9982-g394c852a6b4bed8117c790c2cd1553e224975ad5 Author: Jason Merrill Date: Sun Mar 27 12:36:13 2022 -0400 c++: low -faligned-new [PR102071] This test ICEd after the constexpr new patch (r10-3661) because alloc_call had a NOP_EXPR around it; fixed by moving the NOP_EXPR to alloc_expr. And the PR pointed out that the size_t cookie might need more alignment, so I fix that as well. PR c++/102071 gcc/cp/ChangeLog: * init.c (build_new_1): Include cookie in alignment. Omit constexpr wrapper from alloc_call. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/aligned-new9.C: New test.
[Bug c++/104669] [11 Regression] ICE in is_function_default_version, at attribs.cc:1219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104669 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0c45820ead85b8bc6f8283f7692a85d0c12ded4f commit r11-9983-g0c45820ead85b8bc6f8283f7692a85d0c12ded4f Author: Jason Merrill Date: Tue Apr 12 16:40:14 2022 -0400 c++: local function versioning [PR104669] There were two problems with this testcase: we weren't copying the target attribute from the second declaration to the global alias for the first one (duplicate_decls hunk), and then we were treating the third one as matching the earlier one even though both are versioned (decls_match hunk). The latter change required a fix to find_last_decl (used for attribute mismatch warnings) to give up if we see a versioned function, as in that case we can't determine whether the decls match, because we are still in the process of setting the attributes on the new decl. PR c++/104669 gcc/cp/ChangeLog: * decl.c (decls_match): Compare versions even if not recording. (duplicate_decls): Propagate attributes to alias. * decl2.c (find_last_decl): Give up if versioned. gcc/testsuite/ChangeLog: * g++.target/i386/mv31.C: New test.
[Bug c++/100111] [10 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fe81f5bd3c3e764d1355eda3e44e37cec99cd23c commit r11-9984-gfe81f5bd3c3e764d1355eda3e44e37cec99cd23c Author: Jason Merrill Date: Tue Apr 12 17:46:59 2022 -0400 c++: empty base constexpr -fno-elide-ctors [PR105245] The patch for 100111 extended our handling of empty base elision to the case where the derived class has no other fields, but we still need to make sure that there's some initializer for the derived object. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.c (cxx_eval_store_expression): Build a CONSTRUCTOR as needed in empty base handling. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.
[Bug c++/105245] [10/11 Regression] ICE in clear_no_implicit_zero, in cp/constexpr.cc:1892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105245 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fe81f5bd3c3e764d1355eda3e44e37cec99cd23c commit r11-9984-gfe81f5bd3c3e764d1355eda3e44e37cec99cd23c Author: Jason Merrill Date: Tue Apr 12 17:46:59 2022 -0400 c++: empty base constexpr -fno-elide-ctors [PR105245] The patch for 100111 extended our handling of empty base elision to the case where the derived class has no other fields, but we still need to make sure that there's some initializer for the derived object. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.c (cxx_eval_store_expression): Build a CONSTRUCTOR as needed in empty base handling. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.
[Bug c++/100838] [11 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:728f97cf0431ff342beceea4f91afa1707133248 commit r11-9985-g728f97cf0431ff342beceea4f91afa1707133248 Author: Jason Merrill Date: Wed Apr 13 20:18:33 2022 -0400 c++: temp cleanup in new [PR105265] The patch for PR100838 in GCC 11 was limited to -fno-elide-constructors for safety, but this testcase demonstrates that it's also needed without that flag. So let's switch to the GCC 12 patch for PR100838. PR c++/105265 PR c++/100838 gcc/cp/ChangeLog: * call.c (build_user_type_conversion_1): Drop flag_elide_constructors check. (convert_like_internal): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-new6.C: New test.
[Bug c++/105265] [9/10/11 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:728f97cf0431ff342beceea4f91afa1707133248 commit r11-9985-g728f97cf0431ff342beceea4f91afa1707133248 Author: Jason Merrill Date: Wed Apr 13 20:18:33 2022 -0400 c++: temp cleanup in new [PR105265] The patch for PR100838 in GCC 11 was limited to -fno-elide-constructors for safety, but this testcase demonstrates that it's also needed without that flag. So let's switch to the GCC 12 patch for PR100838. PR c++/105265 PR c++/100838 gcc/cp/ChangeLog: * call.c (build_user_type_conversion_1): Drop flag_elide_constructors check. (convert_like_internal): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-new6.C: New test.
[Bug c++/82980] [9/10/11 Regression] template keyword should not be required for captured decl of the "base" type since r6-6866-gff2faafcf689b6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82980 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:dc8739c2ab14f0108e4fabbd565fa0918e4425ee commit r11-9986-gdc8739c2ab14f0108e4fabbd565fa0918e4425ee Author: Jason Merrill Date: Thu Apr 14 08:16:45 2022 -0400 c++: lambda and the current instantiation [PR82980] When a captured variable is type-dependent, we've expressed the type of the capture field and proxy with a decltype variant. But if the type is "the current instantiation", we need to be able to see that so that we can do lookup inside it just like we could with the captured variable itself. I also tried looking through lambda capture in cp_parser_postfix_dot_deref_expression, but this way seems cleaner. I plan to treat more types as deducible in stage 1. I considered also using this in do_auto_deduction, but think that would be wrong: [temp.dep.expr] says an id-expression is type-dependent if it is "associated by name lookup with a variable declared with a type that contains a placeholder type where the initializer is type-dependent". That doesn't clearly exclude deducing a dependent type from the initializer, but it seems like a barrier, and other implementations agree. PR c++/82980 gcc/cp/ChangeLog: * lambda.c (type_deducible_expression_p): New. (lambda_capture_field_type): Check it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-current-inst1.C: New test.
[Bug c++/104646] [9/10/11 Regression] ICE in cx_check_missing_mem_inits, at cp/constexpr.cc:845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104646 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a67bc6320d34b20fe838d479a6a1e110f1160c89 commit r11-9987-ga67bc6320d34b20fe838d479a6a1e110f1160c89 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++/102629] [10/11 Regression] ICE: tree check in lookup_base, at cp/search.c:233 since r10-2194-g10acaf4db9f8b54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f0484f60e6409ef6e837e4712d212a5d827767ba commit r11-9988-gf0484f60e6409ef6e837e4712d212a5d827767ba Author: Jason Merrill Date: Tue Apr 26 00:19:40 2022 -0400 c++: pack init-capture of unresolved overload [PR102629] Here we were failing to diagnose that the initializer for the capture pack is an unresolved overload. It turns out that the reason we didn't recognize the deduction failure in do_auto_deduction was that the individual 'auto' in the expansion of the capture pack was still marked as a parameter pack, so we were deducing it to an empty pack instead of failing. PR c++/102629 gcc/cp/ChangeLog: * pt.c (gen_elem_of_pack_expansion_instantiation): Clear TEMPLATE_TYPE_PARAMETER_PACK on auto. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-pack-init7.C: New test.
[Bug c++/104669] [11 Regression] ICE in is_function_default_version, at attribs.cc:1219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104669 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed for 11.4.
[Bug c++/97246] [10 regression] mismatched argument pack lengths since r10-7865-gaedd04caa945260e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97246 Jason Merrill changed: What|Removed |Added Target Milestone|10.4|10.3 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed in 10.3.
[Bug c++/98717] [10 Regression] [c++20] variadic concept can't take empty pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98717 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|10.4|10.3 --- Comment #5 from Jason Merrill --- Fixed in 10.3.
[Bug c++/101767] [11 Regression] Aggregate initialization fails for struct that has both unnamed struct and union fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101767 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:846bff4d4659d9b2026da574194599f38a00cc79 commit r10-10718-g846bff4d4659d9b2026da574194599f38a00cc79 Author: Jason Merrill Date: Fri Mar 18 14:36:19 2022 -0400 c++: designator and anon struct [PR101767] We found .x in the anonymous struct, but then didn't find .y there; we should decide that means we're done with the struct rather than that the code is wrong. PR c++/101767 gcc/cp/ChangeLog: * decl.c (reshape_init_class): Back out of anon struct if a designator doesn't match. gcc/testsuite/ChangeLog: * g++.dg/ext/anon-struct10.C: New test.
[Bug c++/98249] [9/10 Regression] Improper ADL on the `arg` in `new (arg) T`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6c69f7c449cc1c0d48e13b8680023a59f541260e commit r10-10719-g6c69f7c449cc1c0d48e13b8680023a59f541260e 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++/100608] [10 Regression] -Wshadow=compatible-local false positive: function local type declaration shadows variable of different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100608 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b01044ec7fbed24e9394bcf49e524acdd52849e7 commit r10-10720-gb01044ec7fbed24e9394bcf49e524acdd52849e7 Author: Jason Merrill Date: Tue Apr 5 16:02:04 2022 -0400 c++: -Wshadow=compatible-local type vs var [PR100608] The patch for PR92024 changed -Wshadow=compatible-local to warn if either new or old decl was a type, but the rationale only talked about the case where both are types. If only one is, they aren't compatible. PR c++/100608 gcc/cp/ChangeLog: * name-lookup.c (check_local_shadow): Use -Wshadow=local if exactly one of 'old' and 'decl' is a type. gcc/testsuite/ChangeLog: * g++.dg/warn/Wshadow-compatible-local-3.C: New test.
[Bug c++/101717] [9/10 Regression] ICE capturing static member within stateless generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101717 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:20dc7a2119cc0a4e5ddc4a6899a7350621f05440 commit r10-10721-g20dc7a2119cc0a4e5ddc4a6899a7350621f05440 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++/100111] [10 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6c7905a9f10d28dfd27ddf21d3bf38a3e261ee10 commit r10-10722-g6c7905a9f10d28dfd27ddf21d3bf38a3e261ee10 Author: Jason Merrill Date: Tue Apr 12 17:46:59 2022 -0400 c++: empty base constexpr -fno-elide-ctors [PR105245] The patch for 100111 extended our handling of empty base elision to the case where the derived class has no other fields, but we still need to make sure that there's some initializer for the derived object. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.c (cxx_eval_store_expression): Build a CONSTRUCTOR as needed in empty base handling. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.
[Bug c++/105245] [10 Regression] ICE in clear_no_implicit_zero, in cp/constexpr.cc:1892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105245 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6c7905a9f10d28dfd27ddf21d3bf38a3e261ee10 commit r10-10722-g6c7905a9f10d28dfd27ddf21d3bf38a3e261ee10 Author: Jason Merrill Date: Tue Apr 12 17:46:59 2022 -0400 c++: empty base constexpr -fno-elide-ctors [PR105245] The patch for 100111 extended our handling of empty base elision to the case where the derived class has no other fields, but we still need to make sure that there's some initializer for the derived object. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.c (cxx_eval_store_expression): Build a CONSTRUCTOR as needed in empty base handling. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.
[Bug c++/59950] [9/10 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:080e737a851d57697d0aac55749296c5c454c421 commit r10-10723-g080e737a851d57697d0aac55749296c5c454c421 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++/102629] [10 Regression] ICE: tree check in lookup_base, at cp/search.c:233 since r10-2194-g10acaf4db9f8b54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:93ec7bf22530610ef697fd3a64a28bebd589c790 commit r10-10724-g93ec7bf22530610ef697fd3a64a28bebd589c790 Author: Jason Merrill Date: Tue Apr 26 00:19:40 2022 -0400 c++: pack init-capture of unresolved overload [PR102629] Here we were failing to diagnose that the initializer for the capture pack is an unresolved overload. It turns out that the reason we didn't recognize the deduction failure in do_auto_deduction was that the individual 'auto' in the expansion of the capture pack was still marked as a parameter pack, so we were deducing it to an empty pack instead of failing. PR c++/102629 gcc/cp/ChangeLog: * pt.c (gen_elem_of_pack_expansion_instantiation): Clear TEMPLATE_TYPE_PARAMETER_PACK on auto. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-pack-init7.C: New test.
[Bug c++/104646] [9/10 Regression] ICE in cx_check_missing_mem_inits, at cp/constexpr.cc:845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104646 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:d939233ef460133e012d8f40f9d8c8fcb73bb7b8 commit r10-10725-gd939233ef460133e012d8f40f9d8c8fcb73bb7b8 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.
