[Bug c++/101595] ICE: in tsubst_pack_expansion, at cp/pt.c:13124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101595 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101764 --- Comment #2 from Andrew Pinski --- This seems to be fixed on the trunk. I suspect r12-3488-gc8b2b89358481d36755.
[Bug c++/91867] Internal compiler error in simple for(auto) loop when using -std=c++11 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91867 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- This is a dup of bug 101099. *** This bug has been marked as a duplicate of bug 101099 ***
[Bug c++/101099] [9/10/11/12 Regression] ICE in type_unification_real, at cp/pt.c:22173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101099 Andrew Pinski changed: What|Removed |Added CC||nwentzell@flatironinstitute ||.org --- Comment #2 from Andrew Pinski --- *** Bug 91867 has been marked as a duplicate of this bug. ***
[Bug c++/95292] ICE in expand_expr_real_2, at expr.c:8538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95292 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed in GCC 8.5.0, 9.4.0, 10.3.0 and 11+. Dup of bug 99790. *** This bug has been marked as a duplicate of bug 99790 ***
[Bug c++/99790] [8/9 Regression] internal compiler error: in expand_expr_real_2 since r7-3811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 Andrew Pinski changed: What|Removed |Added CC||tilin97 at yandex dot ru --- Comment #12 from Andrew Pinski --- *** Bug 95292 has been marked as a duplicate of this bug. ***
[Bug c++/101071] [9/10/11/12 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 Andrew Pinski changed: What|Removed |Added Target Milestone|10.4|9.5 Summary|[10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |in |in |gimplify_init_constructor, |gimplify_init_constructor, |at gimplify.c:5228 |at gimplify.c:5228 Known to work||9.3.0 Known to fail||10.1.0, 9.4.0 Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, also started to ICE in GCC 9.4.0. Note the full command line needed to get the ICE is: -fno-elide-constructors -O2 -std=c++14 using -std=c++11 the code does not ICE. Also note in GCC 9.3 and before -fno-elide-constructors -std=c++14 rejects the code.
[Bug c++/101073] [9/10/11/12 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101073 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug bootstrap/72848] profiledbootstrap: internal compiler error: in streamer_write_gcov_count_stream, at data-streamer-out.c:366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72848 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 64636 which is fixed in GCC 9.4.0 *** This bug has been marked as a duplicate of bug 64636 ***
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 Andrew Pinski changed: What|Removed |Added CC||mikulas at artax dot karlin.mff.cu ||ni.cz --- Comment #20 from Andrew Pinski --- *** Bug 72848 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 Andrew Pinski changed: What|Removed |Added Known to work||10.3.0 Target Milestone|--- |9.4
[Bug bootstrap/57683] Parallel build failure: generated prerequisite header not built in time (insn-opinit.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57683 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.3 Resolution|--- |FIXED Keywords||build Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- Fixed so closing.
[Bug c++/102562] New: [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 Bug ID: 102562 Summary: [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Likely since I see the following failures on x86_64-linux-gnu: g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header_b.C -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-02 --- Comment #1 from Martin Liška --- Started likely with r12-4067-gc46ecb0112e91c8.
[Bug c/102103] missing warning comparing array address to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- This should probably get a note in gcc-12/changes.html IMO
[Bug c/102563] New: ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Bug ID: 102563 Summary: ice during GIMPLE pass: vrp-thread 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 source code: int _bdf_parse_glyphs_bp; long _bdf_parse_glyphs_nibbles; void _bdf_parse_glyphs_p() { long p_2; _bdf_parse_glyphs_nibbles = p_2 << 1; for (; 0 < _bdf_parse_glyphs_nibbles;) if (1 < _bdf_parse_glyphs_nibbles) _bdf_parse_glyphs_bp = _bdf_parse_glyphs_p; } compiled by recent gcc trunk and compiler flag -O2, does this: $ /home/dcb/gcc/results/bin/gcc -c -O2 bug762.c bug762.c: In function ‘_bdf_parse_glyphs_p’: bug762.c:12:28: warning: assignment to ‘int’ from ‘void (*)()’ makes integer from pointer without a cast [-Wint-conversion] 12 | _bdf_parse_glyphs_bp = _bdf_parse_glyphs_p; |^ during GIMPLE pass: vrp-thread bug762.c:4:6: internal compiler error: in upper_bound, at value-range.h:531 4 | void _bdf_parse_glyphs_p() | ^~~ 0x1b7a732 irange::upper_bound() const ../../trunk.git/gcc/value-range.h:531 The bug first seems to occur sometime between git hash 6de9f0c13b27c343 and 5f02854189405771.
[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 --- Comment #2 from Jonathan Wakely --- Oh,I saw these failures but thought they were already happening. I guess I made it worse. I think the library code is correct but I'll check it
[Bug tree-optimization/102564] New: Missed loop vectorization with reduction and ptr load/store inside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102564 Bug ID: 102564 Summary: Missed loop vectorization with reduction and ptr load/store inside loop Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: david.bolvansky at gmail dot com Target Milestone: --- void test1(int *p, int *t, int N) { for (int i = 0; i != N; i++) *t += p[i]; } void test2(int *p, int *t, int N) { if (N > 1024) // hint, N is not small for (int i = 0; i != N; i++) *t += p[i]; } void test3(int *p, int *t, int N) { if (N > 1024) { // hint, N is not small int s = 0; for (int i = 0; i != N; i++) s += p[i]; *t += s; } } test3 is successfully vectorized with LLVM, GCC, ICC. Sadly, only ICC can catch test1 and test2. https://godbolt.org/z/PzoYd4eEK
[Bug tree-optimization/102565] New: ICE: in upper_bound, at value-range.h:531 under -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102565 Bug ID: 102565 Summary: ICE: in upper_bound, at value-range.h:531 under -O2 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: suochenyao at 163 dot com Target Milestone: --- *** OS and Platform: CentOS Linux release 7.8.2003 (Core).0, x86_64 GNU/Linux *** Program: struct a { signed b; }; char c; short d; int e; long(f)() { return 0; } void g() { struct a h = {1}; short *i = &d; *i = 0; e = c << h.b; f(e == 1 || d) == c; } void main() {} *** version: $ gcc -v Using built-in specs. COLLECT_GCC=/data/bin/gcc-dev/bin/gcc COLLECT_LTO_WRAPPER=/data/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --prefix=/data/bin/gcc-dev/ --disable-multilib --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20211002 (experimental) (GCC) git ver: 9d116bcc5556c7df32803f7bf8e6e238ea1c13fb *** Command Lines: $ gcc -O2 a.c during GIMPLE pass: evrp a.c: In function ‘g’: a.c:15:1: internal compiler error: in upper_bound, at value-range.h:531 15 | void main() {} | ^~~~ 0xbc9939 irange::upper_bound() const ../../gcc/value-range.h:531 0x1be6f03 operator_lshift::op1_range(irange&, tree_node*, irange const&, irange const&, tree_code) const ../../gcc/range-op.cc:2131 0x1ae0b0b gori_compute::compute_operand1_range(irange&, gimple*, irange const&, tree_node*, fur_source&) ../../gcc/gimple-range-gori.cc:1011 0x1ae0b9e gori_compute::compute_operand_range(irange&, gimple*, irange const&, tree_node*, fur_source&) ../../gcc/gimple-range-gori.cc:689 0x1ae0b9e gori_compute::compute_operand1_range(irange&, gimple*, irange const&, tree_node*, fur_source&) ../../gcc/gimple-range-gori.cc:1064 0x1ae1bc1 gori_compute::compute_operand_range(irange&, gimple*, irange const&, tree_node*, fur_source&) ../../gcc/gimple-range-gori.cc:689 0x1ae1bc1 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*, range_query&) ../../gcc/gimple-range-gori.cc:1245 0x1ad5b93 ranger_cache::range_on_edge(irange&, edge_def*, tree_node*) ../../gcc/gimple-range-cache.cc:979 0x1ad62f5 ranger_cache::range_on_edge(irange&, edge_def*, tree_node*) ../../gcc/gimple-range-fold.h:97 0x1ad62f5 ranger_cache::propagate_cache(tree_node*) ../../gcc/gimple-range-cache.cc:1078 0x1ad6c6d ranger_cache::fill_block_cache(tree_node*, basic_block_def*, basic_block_def*) ../../gcc/gimple-range-cache.cc:1290 0x1ad6dcf ranger_cache::block_range(irange&, basic_block_def*, tree_node*, bool) ../../gcc/gimple-range-cache.cc:1022 0x1ad2b39 gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*) ../../gcc/gimple-range.cc:131 0x1ad32a8 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*) ../../gcc/gimple-range.cc:105 0x1adc712 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&) ../../gcc/gimple-range-fold.cc:604 0x1addc09 fold_using_range::fold_stmt(irange&, gimple*, fur_source&, tree_node*) ../../gcc/gimple-range-fold.cc:556 0x1ad290d gimple_ranger::fold_range_internal(irange&, gimple*, tree_node*) ../../gcc/gimple-range.cc:226 0x1ad290d gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*) ../../gcc/gimple-range.cc:269 0x1ad33ff gimple_ranger::range_of_expr(irange&, tree_node*, gimple*) ../../gcc/gimple-range.cc:100 0x11abbdf range_query::value_of_expr(tree_node*, gimple*) ../../gcc/value-query.cc:87 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 m.cencora at gmail dot com changed: What|Removed |Added CC||m.cencora at gmail dot com --- Comment #5 from m.cencora at gmail dot com --- code review comment: the change in file 'fs_ops.cc', func: 'fs::create_directory' to use 'function_function_not_supported' looks like a typo, isn't it?
[Bug c/53871] Please warn about endless loops if they are obvious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||egallager at gcc dot gnu.org, ||kuq03132 at qoika dot com --- Comment #10 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #3) > (In reply to Tim Ruehsen from comment #2) > > Maybe it's time for a gcc static analyzer... > > In terms of technology, never has been a better time than now: GCC internals > have never been as clean and re-usable, there is some interest in > modularization, there is now the possibility of creating powerful plugins, > etc. However, in terms of human resources, there is simply no one interested > in working on this, for the reasons given above. Hence, someone new will > need to appear: either a new company, a new group of developers, or a > charismatic and committed developer that can rally existing developers > around him/her. So, David Malcolm has contributed a static analyzer to GCC now; cc-ing him...
[Bug c++/84898] Fix-it hints for '.' vs '->'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84898 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to David Malcolm from comment #4) > Candidate patch: > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01909.html > which implements the fix-it hints for C++, but doesn't change the wording. Does this patch still apply/work?
[Bug c++/101765] ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Iain Sandoe --- For the record, general VLAs are not supported by clang coroutines either. the following coroutine fails to compile there as well. //using test-suite convenience headers. #include "coro.h" #include "coro1-ret-int-yield-int.h" struct coro1 foo (int arg) noexcept { PRINTF ("foo arg = %d\n", arg); char arr[arg]; if (arg < 4) co_return -6174; else for (int i = 0; i < arg; ++i) arr[i] = (char) i; co_yield (int) arr[2]; co_return (int) arr[3]; }
[Bug c++/101765] ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #2 from Dominique d'Humieres --- New failures between r12-4031 and r12-4090: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors)
[Bug tree-optimization/102564] Missed loop vectorization with reduction and ptr load/store inside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102564 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Blocks||53947 Keywords||alias, missed-optimization --- Comment #1 from Andrew Pinski --- I suspect the vectorizer is not adding an alias check in the case of reduction. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||ice-on-valid-code Component|c |tree-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102561 Summary|ice during GIMPLE pass: |[12 Regression] ice during |vrp-thread |GIMPLE pass: vrp-thread
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 Andrew Pinski changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com Target Milestone|--- |12.0
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #3 from Jonathan Wakely --- See PR 102562
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Jonathan Wakely --- Indeed, thanks.
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 --- Comment #1 from Aldy Hernandez --- Created attachment 51534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51534&action=edit untested patch
[Bug tree-optimization/102561] [12 Regression] ICE Segmentation fault during GIMPLE pass: evrp (on -O2 and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102561 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Aldy Hernandez --- duplicate *** This bug has been marked as a duplicate of bug 102563 ***
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Aldy Hernandez changed: What|Removed |Added CC||haoxintu at gmail dot com --- Comment #2 from Aldy Hernandez --- *** Bug 102561 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-02 --- Comment #3 from Aldy Hernandez --- mine. we're clobbering the final range while calculating the intermediate range.
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Aldy Hernandez changed: What|Removed |Added Attachment #51534|0 |1 is obsolete|| --- Comment #4 from Aldy Hernandez --- Created attachment 51535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51535&action=edit untested 2
[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127 --- Comment #4 from Iain Sandoe --- (In reply to Riccardo Brugo from comment #0) > Created attachment 50621 [details] Of course, we should not ICE - but ... > struct promise_type { > std::optional _value = std::nullopt; > > future get_return_object() { > return future{handle_type::from_promise(*this)}; > } > void return_value(value_type val) { > _value = static_cast(val); > } > auto initial_suspend() noexcept { > class awaiter { > std::optional & value; > public: > explicit awaiter(std::optional & val) noexcept : > value{val} {} > bool await_ready() noexcept { return value.has_value(); } > void await_suspend(handle_type) noexcept { } > value_type & await_resume() noexcept { return *value; } > }; > > return awaiter{_value}; > } The ICE is caused by the code handling a reference from the co_await - where it was not expecting any value to be returned from the initial or final await_resume() functions. --- How do you expect to use the value returned by value_type & await_resume() noexcept { return *value; } in this? see: https://eel.is/c++draft/dcl.fct.def.coroutine#5 essentially the value(s) of the initial and final co_await expressions are discarded. So of course, you can have any side-effect you like from the evaluation of the expressions - but there is no way for you to see the result of the await_resume(). Ergo it might as well be void... however, let's fix the ICE anyway.
[Bug target/102566] New: [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 Bug ID: 102566 Summary: [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: thiago at kde dot org Target Milestone: --- Simple test: $ cat test.cpp #include bool tbit(std::atomic &i) { return i.fetch_or(1, std::memory_order_relaxed) & 1; } The sequence x.fetch_or(singlebit_constant) & singlebit_constant can be implemented by a LOCK BTS sequence. The above should emit: lock bts $1, (%rdi) setb %al ret But instead it emits a cmpxchg loop - see https://gcc.godbolt.org/z/99enKaffa. This was found reviewing MariaDB lightweight-mutex code, which uses the sign bit to indicate a contended mutex. See this commit[1] by one of their maintainers for the removal of fetch_or because it emits an extra loop. Bonus: LOCK BTR can be used in the sequence x.fetch_and(~single_bit_constant) & single_bit_constant [1] https://github.com/dr-m/atomic_sync/commit/d5e22b2d42cdbac7a15d242bf1446377555c4041
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 Aldy Hernandez changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW --- Comment #1 from Aldy Hernandez --- confirmed
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 --- Comment #2 from Aldy Hernandez --- Going up the backtrace we see: (gdb) #3 0x01b43aff in irange::intersect (this=0x7fffc8e0, other=0x3c7aa40 ) at /home/aldyh/src/gcc/gcc/value-range.cc:1514 (gdb) #4 0x01b3e1e8 in irange::intersect (this=0x7fffc8e0, r=...) at /home/aldyh/src/gcc/gcc/value-range.h:549 (gdb) #5 0x02a78c33 in alloca_call_type (stmt=, is_vla=false) at /home/aldyh/src/gcc/gcc/gimple-ssa-warn-alloca.c:229 We're intersecting with invalid_range which is a static member: static int_range<2> invalid_range (build_int_cst (size_type_node, 0), build_int_cst (size_type_node, max_size), VR_ANTI_RANGE); It looks like it has members that have been GC freed: (gdb) print invalid_range $9 = { = {m_num_ranges = 1 '\001', m_max_ranges = 2 '\002', m_kind = VR_RANGE, m_base = 0x3c7aa50 }, m_ranges = { , , , }} (gdb) The m_ranges bits are trees in int_range, which live in GC, and trees are inherently GC'ish.
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 --- Comment #7 from TC --- (In reply to Jonathan Wakely from comment #6) > I have looked in detail (I have the 3rd, 4th and 5th editions here) but my > brain started oozing out of my ears. > > 15.10.2.15 NonemptyClassRanges and 15.10.2.16 NonemptyClassRangesNoDash are > the relevant sections of the 1999 3rd edition. The former defines: > > The internal helper function CharacterRange takes two CharSet parameters > A and B and performs the following: > 1. If A does not contain exactly one character or B does not contain > exactly > one character then throw a SyntaxError exception. > > And the latter has this note: > > Informative comments: ClassRanges can expand into single ClassAtoms and/or > ranges of two ClassAtoms separated by dashes. In the latter case the > ClassRanges includes all characters between the first ClassAtom and the > second ClassAtom, inclusive; an error occurs if either ClassAtom does not > represent a single character (for example, if one is \w) or if the first > ClassAtom's code point value is greater than the second ClassAtom's code > point value. > > > > The ClassAtom \w does not contain exactly one character, so I think it's a > syntax error. > > The 3rd edition doesn't mention any legacy features of RegExp, but it does > seem to require the strict behaviour. I've looked at the 1999 spec now, and agree with your reading.
[Bug c++/99575] [coroutines] unexpected move when co_awaiting a nonmoveable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99575 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/101133] [coroutines] co_await doesn't accept a valid awaitable object if await_resume()'s return type is not a built-in type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101133 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/100673] [coroutines] Non-template, UDT await_suspend return-type results in ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100673 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99710 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/101765] ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
[Bug middle-end/65410] "Short local string array" optimization doesn't happen if string has NULs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65410 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed for GCC 9 by r9-2897-gd01b568a78351beb6b6.
[Bug middle-end/86145] Inefficient homogeneous struct return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86145 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-02 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed, might be a dup of a few others.
[Bug rtl-optimization/93455] aarch64: Q constraint address is recomputed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93455 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-02 Known to fail||5.4.0 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521 --- Comment #4 from anlauf at gcc dot gnu.org --- Tentative patch: diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index b3c65b7175b..cebc59e4ab5 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -2228,12 +2228,15 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus) gfc_expr *array; int n; if (sym->attr.flavor == FL_PARAMETER - && init->expr_type == EXPR_CONSTANT - && spec_size (sym->as, &size) - && mpz_cmp_si (size, 0) > 0) + && (init->expr_type == EXPR_CONSTANT + || init->expr_type == EXPR_STRUCTURE) + && spec_size (sym->as, &size) + && mpz_cmp_si (size, 0) > 0) { array = gfc_get_array_expr (init->ts.type, init->ts.kind, &init->where); + if (init->ts.type == BT_DERIVED) + array->ts.u.derived = init->ts.u.derived; for (n = 0; n < (int)mpz_get_si (size); n++) gfc_constructor_append_expr (&array->value.constructor, n == 0
[Bug libstdc++/102567] New: Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 Bug ID: 102567 Summary: Missing noexcept specialization of std::function Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- When C++17 made noexcept part of the type system, std::function was not updated accordingly. As a result, this program fails to compile: #include std::function f; t.cc:2:32: error: aggregate ‘std::function f’ has incomplete type and cannot be defined 2 | std::function f; |^ In earlier language versions, code like this used to compile because noexcept was not part of the type system. Seen with: gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)
[Bug c++/102568] New: "taking address of temporary array" error when passing temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102568 Bug ID: 102568 Summary: "taking address of temporary array" error when passing temporary array Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kamkaz at windowslive dot com Target Milestone: --- void foo(int* arr); int main() { using array = int[5]; foo((array{1, 2, 3, 4, 5})); } Gives an error: : In function 'int main()': :6:31: error: taking address of temporary array Problem occurs on all GCC versions 4.7.1 up.
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 --- Comment #5 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:6c0dd02964a624c65859808f9a40721c3796319a commit r12-4095-g6c0dd02964a624c65859808f9a40721c3796319a Author: Aldy Hernandez Date: Sat Oct 2 16:59:26 2021 +0200 [PR102563] Do not clobber range in operator_lshift::op1_range. We're clobbering the final range before we're done calculating it. Tested on x86-64 Linux. gcc/ChangeLog: PR tree-optimization/102563 * range-op.cc (operator_lshift::op1_range): Do not clobber range. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr102563.c: New test.
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Aldy Hernandez --- fixed
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 --- Comment #3 from Aldy Hernandez --- Probably needs GTY markers, and possibly putting it invalid_range in file scope.
[Bug c++/102568] "taking address of temporary array" error when passing temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102568 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 94264. *** This bug has been marked as a duplicate of bug 94264 ***
[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264 Andrew Pinski changed: What|Removed |Added CC||kamkaz at windowslive dot com --- Comment #3 from Andrew Pinski --- *** Bug 102568 has been marked as a duplicate of this bug. ***
[Bug target/92061] build of gencondmd fails with clang-9.0 (trunk, gcc 9.2.1, probably other older versions of gcc as yet untested) with undefined symbols for ix86_binary_operator_ok and related.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92061 fink at snaggledworks dot com changed: What|Removed |Added CC||fink at snaggledworks dot com --- Comment #7 from fink at snaggledworks dot com --- For the record, Apple-clang-13.0.0 from Xcode13 fails to build gcc-9.4 and gcc-10.3 (gcc-11.2 builds) getting this error. The patch to gcc/genconditions.c in comment #5 fixes the missing symbol failure.
[Bug target/94174] Missed ccmp optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-02 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug target/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed at r12-4096, thanks again.
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- This is not a libstdc++ bug, we implement what the standard says. Maybe it used to compile, but it was meaningless. You could say it was a function of void() noexcept, but you could still store a target function that throwed, and its operator() could still throw. Both std::move_only_function (P0288) and std::function_ref (P0792) support using a function type that is optionally const-qualified and optionally noexcept, and it actually means something (it affects what you can store in there, and whether they can modify a stateful target object, and whether their operator() is noexcept or not). std::function is not going to get updated though.
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #2 from Jonathan Wakely --- (In reply to Florian Weimer from comment #0) > In earlier language versions, code like this used to compile because > noexcept was not part of the type system. This also used to compile: void f() noexcept(false); void (*p)() noexcept = &f; But it was meaningless, p() could still throw. In C++17 it doesn't work.
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #3 from Florian Weimer --- (In reply to Jonathan Wakely from comment #1) > This is not a libstdc++ bug, we implement what the standard says. > > Maybe it used to compile, but it was meaningless. You could say it was a > function of void() noexcept, but you could still store a target function > that throwed, and its operator() could still throw. Sure, but in my code, I did not do this. The call operator was invoked in a noexcept context, and the type was expected to match (but of course the compiler did not check this). > Both std::move_only_function (P0288) and std::function_ref (P0792) support > using a function type that is optionally const-qualified and optionally > noexcept, and it actually means something (it affects what you can store in > there, and whether they can modify a stateful target object, and whether > their operator() is noexcept or not). std::function is not going to get > updated though. Neither paper seems to cover a polymorphic function type that takes ownership, though, so I don't quite see how these replace std::function. Or is std::function semi-deprecated because it poorly matches capture-by-reference in lambdas?
[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||ice-on-valid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99496 --- Comment #3 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #2) > I think the library code is correct but I'll check it My bet is some latent bug in the C++ front-end exposing this.
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #4 from Jonathan Wakely --- (In reply to Florian Weimer from comment #3) > (In reply to Jonathan Wakely from comment #1) > > This is not a libstdc++ bug, we implement what the standard says. > > > > Maybe it used to compile, but it was meaningless. You could say it was a > > function of void() noexcept, but you could still store a target function > > that throwed, and its operator() could still throw. > > Sure, but in my code, I did not do this. The call operator was invoked in a > noexcept context, and the type was expected to match (but of course the > compiler did not check this). Then you need to stop doing it, the C++17 changes make it no longer possible to use that extra annotation in the type to signify something that wasn't checked, or even necessarily true. > Neither paper seems to cover a polymorphic function type that takes > ownership, though, so I don't quite see how these replace std::function. They're not supposed to replace it, they supplement it for additional scenarios (non-owning, or owning a movable but non-copyable target). My point is just that the newer facilities being added do allow you to use noexcept the way you want to, but std::function doesn't. And I doubt anybody is going to propose extending it that way. Either way, it's not a libstdc++ bug.
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #5 from Jonathan Wakely --- (In reply to Florian Weimer from comment #3) > Neither paper seems to cover a polymorphic function type that takes > ownership, though, so I don't quite see how these replace std::function. To be clear, std::move_only_function is exactly a polymorphic function type that takes ownership. Without the constraint that the target type it takes ownership of needs to be copy-constructible.
[Bug middle-end/98649] Trivial jump table not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98649 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-02 --- Comment #3 from Andrew Pinski --- Confirmed. Interesting LLVM does not do the optimization either ...
[Bug tree-optimization/98703] Failure to optimize out non-zero check after multiplication overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98703 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Ever confirmed|0 |1 Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed. Note the released version of GCC 11, f2 does not produce the extra compare.
[Bug tree-optimization/102569] New: Missed redudant add with add_overflow on the tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102569 Bug ID: 102569 Summary: Missed redudant add with add_overflow on the tree level Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization, TREE Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Take: bool f1(unsigned x, unsigned y, unsigned *res) { bool t = __builtin_add_overflow(x, y, res); *res -= (x+y); return t; } - CUT We currently get: _7 = .ADD_OVERFLOW (x_5(D), y_6(D)); _1 = REALPART_EXPR <_7>; _2 = IMAGPART_EXPR <_7>; t_10 = (bool) _2; _3 = x_5(D) + y_6(D); _4 = _1 - _3; But _3 and _1 are the same _4 should be optimized to 0 as it is on the RTL level. The way I see this being done is during the late fre add x+y in the table for REALPART_EXPR<_7> and it will be done correctly.
[Bug tree-optimization/96397] GCC Fails to exploit ranges from overflow tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96397 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-02 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 fink at snaggledworks dot com changed: What|Removed |Added CC||fink at snaggledworks dot com --- Comment #26 from fink at snaggledworks dot com --- Current gcc-11.2 builds with Xcode 13 w/out having to use `--without-build-config`. Exact same setup failed w/ Xcode 12.5.1.
[Bug tree-optimization/102570] New: missed fully redudant with internal function of add_overflow in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102570 Bug ID: 102570 Summary: missed fully redudant with internal function of add_overflow in FRE Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Take: bool f1(unsigned x, unsigned y, unsigned *res) { bool t = __builtin_add_overflow(x, y, res); unsigned res1; bool t1 = __builtin_add_overflow(x, y, &res1); *res -= res1; return t==t1; } This should be optimized at fre1 but currently takes into DOM to optimize it to just *res = 0; return 1; FRE does not handle some of the internal functions. Note this is different from PR 102569 but related.
[Bug libgomp/102571] New: FAIL: libgomp.c/../libgomp.c-c++-common/atomic-21.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102571 Bug ID: 102571 Summary: FAIL: libgomp.c/../libgomp.c-c++-common/atomic-21.c execution test Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- Target: i686,x86-64 libgomp.c-c++-common/atomic-21.c always fails with -m32 -mfpmath=sse
[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 --- Comment #4 from H.J. Lu --- spawn -ignore SIGHUP /export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/gcc/testsuite/g++8/../../xg++ -B/export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/gcc/testsuite/g++8/../../ /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-header-3_a.H -fdiagnostics-plain-output -nostdinc++ -I/export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/i686-linux/libstdc++-v3/include/i686-linux -I/export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodule-header -S -o xtreme-header-3_a.s /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-header-3_a.H: internal compiler error: tree check: expected var_decl or function_decl or field_decl or type_decl or concept_decl or template_decl, have namespace_decl in get_merge_kind, at cp/module.cc:10072 0x8475867 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /export/gnu/import/git/gitlab/x86-gcc/gcc/tree.c:8689 0x82e6ccc template_info_decl_check(tree_node const*, char const*, int, char const*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/cp-tree.h:651 0x82e8183 template_info_decl_check(tree_node const*, char const*, int, char const*) /export/gnu/import/git/gitlab/x86-gcc/gcc/tree.h:3433 0x82e8183 trees_out::get_merge_kind(tree_node*, depset*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:10070 0x86609a8 trees_out::decl_value(tree_node*, depset*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:7501 0x8661b44 trees_out::decl_node(tree_node*, walk_kind) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:8536 0x8662b8a trees_out::tree_node(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:9091 0x8662ed9 trees_out::chained_decls(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:4840 0x8663cf1 trees_out::core_vals(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:6060 0x86669ba trees_out::tree_node_vals(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:7062 0x86669ba trees_out::tree_value(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:8898 0x86629fd trees_out::tree_node(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:9096 0x8666ad6 trees_out::write_function_def(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:11352 0x8668bad depset::hash::find_dependencies(module_state*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:13128 0x8668fc0 module_state::write(elf_out*, cpp_reader*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:17615 0x866a5fa finish_module_processing(cpp_reader*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:19871 0x85fea25 c_parse_final_cleanups() /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/decl2.c:5222 Please submit a full bug report, with preprocessed source if appropriate.
[Bug tree-optimization/92979] bswap not finding a bswap with a memory load at the beginging of the instruction stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92979 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 93040. *** This bug has been marked as a duplicate of bug 93040 ***
[Bug tree-optimization/93040] gcc doesn't optimize unaligned accesses to a 16-bit value on the x86 as well as it does a 32-bit value (or clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040 --- Comment #7 from Andrew Pinski --- *** Bug 92979 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/92949] bswap/store merging does not handle BIT_INSERT_EXPR/BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949 Bug 92949 depends on bug 92979, which changed state. Bug 92979 Summary: bswap not finding a bswap with a memory load at the beginging of the instruction stream https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92979 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug testsuite/93216] [10 regression] gcc.dg/optimize-bswaphi-1.c fails starting with r280034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93216 Bug 93216 depends on bug 92979, which changed state. Bug 92979 Summary: bswap not finding a bswap with a memory load at the beginging of the instruction stream https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92979 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug target/101716] lea does not have a zero_extend version of it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101716 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed.
[Bug c++/101595] ICE: in tsubst_pack_expansion, at cp/pt.c:13124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101595 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- (In reply to Andrew Pinski from comment #2) > This seems to be fixed on the trunk. I suspect > r12-3488-gc8b2b89358481d36755. Indeed it's fixed by that commit, and the testcase is very similar to PR101764. I suppose I'll mark this one as a dup then. *** This bug has been marked as a duplicate of bug 101764 ***
[Bug c++/101764] ICE for constexpr if within fold expression within lambda expression within a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101764 Patrick Palka changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #4 from Patrick Palka --- *** Bug 101595 has been marked as a duplicate of this bug. ***
[Bug middle-end/44690] -fzero-initialized-in-bss does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44690 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #4 from Andrew Pinski --- Fixed by r8-2857-g2ec399d8a6c9c26 (there was a few followups patches which fix problems with this patch too).
[Bug middle-end/43476] -ffixed-xxx etc processed too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43476 --- Comment #2 from Andrew Pinski --- Code has changed slightly but it still seems to apply today: /* After switches have been processed, which perhaps alter `fixed_regs' and `call_used_regs', convert them to HARD_REG_SETs. */ static void init_reg_sets_1 (void) { unsigned int i, j; unsigned int /* machine_mode */ m; restore_register_info (); #ifdef REG_ALLOC_ORDER for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) inv_reg_alloc_order[reg_alloc_order[i]] = i; #endif /* Let the target tweak things if necessary. */ targetm.conditional_register_usage ();
[Bug tree-optimization/102572] New: ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572 Bug ID: 102572 Summary: ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vsevolod.livinskij at frtk dot ru Target Milestone: --- Reproducer: int a, b, c, f; void g(bool h, int d[][5]) { for (short i = f; i; i += 1) { a = h && d[0][i]; for (int j = 0; j < 4; j += c) b = 0; } } Error: >$ g++ -O3 -march=skylake-avx512 -c func.cpp during GIMPLE pass: vect func.cpp: In function 'void g(bool, int (*)[5])': func.cpp:2:6: internal compiler error: in vect_build_gather_load_calls, at tree-vect-stmts.c:2835 2 | void g(bool h, int d[][5]) { | ^ 0x906a36 vect_build_gather_load_calls /testing/gcc/gcc_src/gcc/tree-vect-stmts.c:2835 0x906a36 vectorizable_load /testing/gcc/gcc_src/gcc/tree-vect-stmts.c:8785 0x1500240 vect_transform_stmt(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*, _slp_tree*, _slp_instance*) /testing/gcc/gcc_src/gcc/tree-vect-stmts.c:11060 0x1503e6a vect_transform_loop_stmt /testing/gcc/gcc_src/gcc/tree-vect-loop.c:9362 0x151fd67 vect_transform_loop(_loop_vec_info*, gimple*) /testing/gcc/gcc_src/gcc/tree-vect-loop.c:9798 0x1553a8f try_vectorize_loop_1 /testing/gcc/gcc_src/gcc/tree-vectorizer.c:1109 0x1554591 vectorize_loops() /testing/gcc/gcc_src/gcc/tree-vectorizer.c:1248 GCC version: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/testing/gcc/bin/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /testing/gcc/gcc_src/configure --enable-multilib --prefix=/testing/gcc/bin --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20211002 (d7705b0ada9e9852b580ca25a45570c82152f287) (GCC)
[Bug libstdc++/102573] New: optimized code removes the underlying elements of the std::initializer_list being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102573 Bug ID: 102573 Summary: optimized code removes the underlying elements of the std::initializer_list being copied Product: gcc Version: 4.8.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: 13508417 at qq dot com Target Milestone: --- Using clang++ compiler with libstdc++, the output of below program differs whether use -O option. code: #include #include using namespace std; int main() { initializer_list il; il = {111, 222}; cout << "initializer_list size: " << il.size() << endl; cout << "initializer_list underlying elements: " << endl; for (auto i : il) cout << i << endl; return 0; } command: ➜ clang++ test_2.cpp -std=c++11 -O1 -v clang version 10.0.0 Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/4.8.2 Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5 Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5 ... output without -O: initializer_list size: 2 initializer_list underlying elements: 111 222 output with -O1: initializer_list size: 2 initializer_list underlying elements: 1402476368 32767 Question: >From https://timsong-cpp.github.io/cppwp/n4659/dcl.init.list, I know that the reason is because the lifetime of the underlying array should be same as the temporary initializer_list constructed directly from the "{111, 222}", and the variable "il" only copy the address and length of the underlying array using the default copy member, but cannot affect the lifetime of the underlying array. But my question is, since the copied initializer_list can't affect the lifetime of the underlying array bound to the original initializer_list, can we just prohibit the copy member in the library implementation of std::initializer_list? It seems to me that the copy member makes not much sense, but probably lures the user to make mistakes.
[Bug libstdc++/102573] optimized code removes the underlying elements of the std::initializer_list being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102573 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- GCC warns: : In function 'int main()': :9:19: warning: assignment from temporary 'initializer_list' does not extend the lifetime of the underlying array [-Winit-list-lifetime] 9 | il = {111, 222}; | ^ Plus at runtime with -fsanitize=address: = ==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffcff6b4e10 at pc 0x0040147d bp 0x7ffcff6b4dc0 sp 0x7ffcff6b4db8 READ of size 4 at 0x7ffcff6b4e10 thread T0 #0 0x40147c in main /app/example.cpp:13 #1 0x7f5915fc70b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #2 0x40118d in _start (/app/output.s+0x40118d) Address 0x7ffcff6b4e10 is located in stack of thread T0 at offset 32 in frame #0 0x401255 in main /app/example.cpp:7 This frame has 2 object(s): [32, 40) '' <== Memory access at offset 32 is inside this variable [64, 80) 'il' (line 8) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-use-after-scope /app/example.cpp:13 in main Shadow bytes around the buggy address: 0x10001fece970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001fece980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001fece990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001fece9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001fece9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 =>0x10001fece9c0: f1 f1[f8]f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 0x10001fece9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001fece9e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001fece9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001fecea00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001fecea10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==1==ABORTING initializer_list size: 2 initializer_list underlying elements: clang also errors out the same way.
[Bug libstdc++/102573] optimized code removes the underlying elements of the std::initializer_list being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102573 --- Comment #2 from wjf <13508417 at qq dot com> --- (In reply to Andrew Pinski from comment #1) > GCC warns: > : In function 'int main()': > :9:19: warning: assignment from temporary 'initializer_list' does > not extend the lifetime of the underlying array [-Winit-list-lifetime] > 9 | il = {111, 222}; > | ^ > > Plus at runtime with -fsanitize=address: > > = > ==1==ERROR: AddressSanitizer: stack-use-after-scope on address > 0x7ffcff6b4e10 at pc 0x0040147d bp 0x7ffcff6b4dc0 sp 0x7ffcff6b4db8 > READ of size 4 at 0x7ffcff6b4e10 thread T0 > #0 0x40147c in main /app/example.cpp:13 > #1 0x7f5915fc70b2 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) > #2 0x40118d in _start (/app/output.s+0x40118d) > > Address 0x7ffcff6b4e10 is located in stack of thread T0 at offset 32 in frame > #0 0x401255 in main /app/example.cpp:7 > > This frame has 2 object(s): > [32, 40) '' <== Memory access at offset 32 is inside this > variable > [64, 80) 'il' (line 8) > HINT: this may be a false positive if your program uses some custom stack > unwind mechanism, swapcontext or vfork > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: stack-use-after-scope /app/example.cpp:13 in main > Shadow bytes around the buggy address: > 0x10001fece970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10001fece980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10001fece990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10001fece9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10001fece9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 > =>0x10001fece9c0: f1 f1[f8]f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 > 0x10001fece9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10001fece9e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10001fece9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10001fecea00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10001fecea10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user:f7 > Container overflow: fc > Array cookie:ac > Intra object redzone:bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone:cb > ==1==ABORTING > initializer_list size: 2 > initializer_list underlying elements: > > > clang also errors out the same way. Hi Andrew, I know that adding "-fsanitize=address" could detect the stack-use-after-scope in runtime. But why not just delete the copy member in std::initializer_list implementation? I don't see much sense to permit the copy operation.
[Bug libstdc++/102573] optimized code removes the underlying elements of the std::initializer_list being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102573 --- Comment #3 from Andrew Pinski --- (In reply to wjf from comment #2) > Hi Andrew, > > I know that adding "-fsanitize=address" could detect the > stack-use-after-scope in runtime. But why not just delete the copy member in > std::initializer_list implementation? I don't see much sense to permit the > copy operation. Because this is how std::initializer_list works. Note even using LLVM's libc++ with clang produces the same runtime failure. This is also why GCC has a warning at compile time explicitly for this case: : In function 'int main()': :9:19: warning: assignment from temporary 'initializer_list' does not extend the lifetime of the underlying array [-Winit-list-lifetime] 9 | il = {111, 222}; | ^
[Bug tree-optimization/102572] [11/12 Regression] ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-03 Ever confirmed|0 |1 Known to fail||11.1.0, 11.2.0 Known to work||10.3.0 Target Milestone|--- |11.3 Summary|ICE for skx in |[11/12 Regression] ICE for |vect_build_gather_load_call |skx in |s, at |vect_build_gather_load_call |tree-vect-stmts.c:2835 |s, at ||tree-vect-stmts.c:2835 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/102572] [11/12 Regression] ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572 --- Comment #2 from Andrew Pinski --- if (!useless_type_conversion_p (masktype, TREE_TYPE (vec_mask))) { poly_uint64 sub1 = TYPE_VECTOR_SUBPARTS (TREE_TYPE (mask_op)); poly_uint64 sub2 = TYPE_VECTOR_SUBPARTS (masktype); gcc_assert (known_eq (sub1, sub2));