[Bug c++/107579] [11 Regression] ICE on fold-expression on .* member access operator since r12-2862-g9707d2e5dbb92d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Patrick Palka --- Fixed for GCC 11.4+
[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295 Patrick Palka changed: What|Removed |Added Target Milestone|12.3|11.4
[Bug c++/107179] [11 Regression] requires-expression gives hard error for inaccessible constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107179 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 11.4+
[Bug c++/100474] ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Patrick Palka --- Fixed for GCC 11.4+
[Bug c++/104527] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 11.4+
[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:58d2a4cdbbafa4431eb9cff3778099d185f9f391 commit r11-10804-g58d2a4cdbbafa4431eb9cff3778099d185f9f391 Author: Patrick Palka Date: Thu Dec 15 16:02:05 2022 -0500 c++: extract_local_specs and unevaluated contexts [PR100295] Here during partial instantiation of the constexpr if, extra_local_specs walks the statement looking for local specializations within to capture. However, we're thwarted by the fact that 'ts' first appears inside an unevaluated context, and so the calls to process_outer_var_ref for its local specializations are a no-op. And since we walk each tree exactly once, we end up not capturing the local specializations despite 'ts' later occurring in an evaluated context. This patch fixes this by making extract_local_specs walk evaluated contexts first before walking unevaluated contexts. We could probably get away with not walking unevaluated contexts at all, but this approach seems more clearly safe. PR c++/100295 PR c++/107579 gcc/cp/ChangeLog: * pt.c (el_data::skip_unevaluated_operands): New data member. (extract_locals_r): If skip_unevaluated_operands is true, don't walk into unevaluated contexts. (extract_local_specs): Walk the pattern twice, first with skip_unevaluated_operands true followed by it set to false. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-if-lambda5.C: New test. (cherry picked from commit 18499b9f848707aee42d810e99ac0a4c9788433c)
[Bug c++/108998] [12 Regression] ICE in tsubst, at cp/pt.cc:16037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:143179f27ebe6707d833802aaf4efb5d30a55001
commit r11-10805-g143179f27ebe6707d833802aaf4efb5d30a55001
Author: Patrick Palka
Date: Fri Mar 3 11:37:02 2023 -0500
c++: thinko in extract_local_specs [PR108998]
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
each local specialization once even if it appears multiple times in the
pattern).
But there's a thinko in the patch, namely that we don't actually walk
the pattern twice since we don't clear the visited set for the second
walk (to avoid processing a local specialization twice) and so the root
node (and any node leading up to an unevaluated operand) is considered
visited already. So the patch effectively made extract_local_specs
ignore unevaluated operands altogether, which this testcase demonstrates
isn't quite safe (extract_local_specs never sees 'aa' and we don't record
its local specialization, so later we try to specialize 'aa' on the spot
with the args {{int},{17}} which causes us to nonsensically substitute
its auto with 17.)
This patch fixes this by refining the second walk to start from the
trees we skipped over during the first walk.
PR c++/108998
gcc/cp/ChangeLog:
* pt.c (el_data::skipped_trees): New data member.
(extract_locals_r): Push to skipped_trees any unevaluated
contexts that we skipped over.
(extract_local_specs): For the second walk, start from each
tree in skipped_trees.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-generic11.C: New test.
(cherry picked from commit 341e6cd8d603a334fd34657a6b454176be1c6437)
[Bug c++/107864] [10/11 Regression] ICE (seg fault) in check_return_expr or instantiate_body with concepts and specialized version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:17e3edd6a25e47eed56678f25f6f8ab29b0ac5fc commit r11-10803-g17e3edd6a25e47eed56678f25f6f8ab29b0ac5fc Author: Patrick Palka Date: Tue Nov 29 09:55:21 2022 -0500 c++: explicit specialization and trailing requirements [PR107864] Here we're crashing when using the explicit specialization of the function template g with trailing requirements ultimately because earlier decls_match (called indirectly from register_specialization) for for the explicit specialization returned false since the template has trailing requirements whereas the specialization doesn't. In r12-2230-gddd25bd1a7c8f4, we fixed a similar issue concerning template requirements instead of trailing requirements. We could extend that fix to ignore trailing requirement mismatches for explicit specializations as well, but it seems cleaner to just propagate constraints from the specialized template to the specialization when declaring an explicit specialization so that decls_match will naturally return true in this case. And it looks like determine_specialization already does this, albeit inconsistently (only when specializing a non-template member function of a class template as in cpp2a/concepts-explicit-spec4.C). So this patch makes determine_specialization consistently propagate constraints from the specialized template to the specialization, which in turn lets us get rid of the function_requirements_equivalent_p special case added by r12-2230. PR c++/107864 gcc/cp/ChangeLog: * decl.c (function_requirements_equivalent_p): Don't check DECL_TEMPLATE_SPECIALIZATION. * pt.c (determine_specialization): Propagate constraints when specializing a function template too. Simplify by using add_outermost_template_args. gcc/testsuite/ChangeLog: * g++.dg/concepts/explicit-spec1a.C: New test. (cherry picked from commit 36cabc257dfb7dd4f7625896891f6c5b195a0241)
[Bug c++/107579] [11 Regression] ICE on fold-expression on .* member access operator since r12-2862-g9707d2e5dbb92d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:58d2a4cdbbafa4431eb9cff3778099d185f9f391 commit r11-10804-g58d2a4cdbbafa4431eb9cff3778099d185f9f391 Author: Patrick Palka Date: Thu Dec 15 16:02:05 2022 -0500 c++: extract_local_specs and unevaluated contexts [PR100295] Here during partial instantiation of the constexpr if, extra_local_specs walks the statement looking for local specializations within to capture. However, we're thwarted by the fact that 'ts' first appears inside an unevaluated context, and so the calls to process_outer_var_ref for its local specializations are a no-op. And since we walk each tree exactly once, we end up not capturing the local specializations despite 'ts' later occurring in an evaluated context. This patch fixes this by making extract_local_specs walk evaluated contexts first before walking unevaluated contexts. We could probably get away with not walking unevaluated contexts at all, but this approach seems more clearly safe. PR c++/100295 PR c++/107579 gcc/cp/ChangeLog: * pt.c (el_data::skip_unevaluated_operands): New data member. (extract_locals_r): If skip_unevaluated_operands is true, don't walk into unevaluated contexts. (extract_local_specs): Walk the pattern twice, first with skip_unevaluated_operands true followed by it set to false. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-if-lambda5.C: New test. (cherry picked from commit 18499b9f848707aee42d810e99ac0a4c9788433c)
[Bug c++/100474] ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c06cb992797903b4759dd26ad28e966babdc2b17 commit r11-10801-gc06cb992797903b4759dd26ad28e966babdc2b17 Author: Patrick Palka Date: Wed Mar 30 10:13:11 2022 -0400 c++: ICE with failed __is_constructible constraint [PR100474] Here we're crashing when diagnosing an unsatisfied __is_constructible constraint because diagnose_trait_expr doesn't recognize this trait (along with a bunch of other traits). Fix this by adding handling for all remaining traits and removing the default case so that when adding a new trait we'll get a warning that diagnose_trait_expr needs to handle it. PR c++/100474 gcc/cp/ChangeLog: * constraint.cc (diagnose_trait_expr): Handle all remaining traits appropriately. Remove default case. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-traits3.C: New test. (cherry picked from commit 3aaf9bf77047aecc23072fe3db7f13ecff72a7cf)
[Bug c++/107179] [11 Regression] requires-expression gives hard error for inaccessible constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107179 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c0658801e10d2e7e8b137e555d4c2817bf090ea9 commit r11-10802-gc0658801e10d2e7e8b137e555d4c2817bf090ea9 Author: Patrick Palka Date: Thu Nov 3 15:35:18 2022 -0400 c++: requires-expr and access checking [PR107179] Like during satisfaction, we also need to avoid deferring access checks during substitution of a requires-expr because the outcome of an access check can determine the value of the requires-expr. Otherwise (in deferred access checking contexts such as within a base-clause), the requires-expr may evaluate to the wrong result, and along the way a failed access check may leak out from it into a non-SFINAE context and cause a hard error (as in the below testcase). PR c++/107179 gcc/cp/ChangeLog: * constraint.cc (tsubst_requires_expr): Make sure we're not deferring access checks. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires31.C: New test. (cherry picked from commit 40c34beef620ed13c4113c893ed4335ccc1b8f92)
[Bug c++/104527] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9cfb9378b93c01a4afff5b330bb4adf4904edf62 commit r11-10800-g9cfb9378b93c01a4afff5b330bb4adf4904edf62 Author: Patrick Palka Date: Sat Mar 12 15:00:40 2022 -0500 c++: return-type-req in constraint using only outer tparms [PR104527] Here the template context for the atomic constraint has two levels of template parameters, but since it depends only on the innermost parameter T we use a single-level argument vector (built by get_mapped_args) during substitution into the atom. We eventually pass this vector to do_auto_deduction as part of checking the return-type-requirement within the atom, but do_auto_deduction expects outer_targs to be a full set of arguments for sake of satisfaction. This patch fixes this by making get_mapped_args always return an argument vector whose depth corresponds to the template depth of the context in which the atomic constraint expression was written, instead of the highest parameter level that the expression happens to use. PR c++/104527 gcc/cp/ChangeLog: * constraint.cc (normalize_atom): Set ATOMIC_CONSTR_EXPR_FROM_CONCEPT_P appropriately. (get_mapped_args): Make static, adjust parameters. Always return a vector whose depth corresponds to the template depth of the context of the atomic constraint expression. Micro-optimize by passing false as exact to safe_grow_cleared and by collapsing a multi-level depth-one argument vector. (satisfy_atom): Adjust call to get_mapped_args and diagnose_atomic_constraint. (diagnose_atomic_constraint): Replace map parameter with an args parameter. * cp-tree.h (ATOMIC_CONSTR_EXPR_FROM_CONCEPT_P): Define. (get_mapped_args): Remove declaration. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-return-req4.C: New test. (cherry picked from commit 9413bb55185b9e88d84e91d5145d59f9f83b884a)
[Bug c++/92752] [10/11 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92752 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d0a586ba9d9bd44d5e4d523ed2326bd6639493d8 commit r11-10799-gd0a586ba9d9bd44d5e4d523ed2326bd6639493d8 Author: Patrick Palka Date: Fri Jan 28 15:41:15 2022 -0500 c++: bogus warning with value init of const pmf [PR92752] Here we're emitting a -Wignored-qualifiers warning for an intermediate compiler-generated cast of nullptr to 'method-type* const' as part of value initialization of a const pmf. This patch suppresses the warning by instead casting to the corresponding unqualified type. PR c++/92752 gcc/cp/ChangeLog: * typeck.c (build_ptrmemfunc): Cast a nullptr constant to the unqualified pointer type not the qualified one. gcc/testsuite/ChangeLog: * g++.dg/warn/Wignored-qualifiers2.C: New test. Co-authored-by: Jason Merrill (cherry picked from commit e971990cbda091b4caf5e1a5bded5121068934e4)
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 Andrew Pinski changed: What|Removed |Added Keywords||build Component|bootstrap |target --- Comment #1 from Andrew Pinski --- I wonder if splitting up gimple-match that happened on the trunk fixes this issue.
[Bug bootstrap/109927] New: Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 Bug ID: 109927 Summary: Bootstrap fails for m68k in stage2 compilation of gimple-match.cc Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: userm57 at yahoo dot com Target Milestone: --- Hello, Bootstrap of gcc 13.1.0 fails during compilation of gimple-match.cc. The error message is "virtual memory exhausted: Cannot allocate memory", possibly from the assembler. However, virtual memory is not really exhausted. A slightly different version of (possibly) the same error occurs during stage3 compilation of gimple-match.cc (see below). Setup: 1) Install QEMU. I'm using QEMU version 7.2.1 on an HP Z2 workstation (32 GiB, eight i7 CPUs) running Debian SID. 2) Install Gentoo to a disk image or a separate disk (using whatever your usual procedure is for installing Gentoo). I used the latest Gentoo stage3 for m68k for the first procedure below, and a fully installed Gentoo for the second procedure. For swap space, I tried many options, ending up with two 512 MiB swap partitions. Regardless of how much swap space is used, compilation of gimple-match.cc will fail with the same error. To generate the error in stage2 gcc bootstrap, the following steps can be used: 1) Create a QEMU virtual machine (VM) configured as q800 (e.g. "-M q800 -m 1004M") or as virt (e.g. "-M virt -m 3399672K"). Using q800, you can use the latest default Debian kernel for m68k; otherwise, you'll need a virt kernel. They will have the same error. 2) It's not necessary to configure the network, users, etc. in the Gentoo QEMU VM (instead use the chroot environment). After installation of the Gentoo stage3 as per the Gentoo installation instructions, you can run "emerge-webrsync" then "emerge gcc" from the chroot. Compilation will fail in gcc stage2. To generate the error in a manual gcc compilation, the following steps can be used: 1) If you have a completed installation of Gentoo or Debian, you can download the latest gcc. I used Gentoo's configure options (but not their patches): "../gcc-13.1.0/configure --host=m68k-unknown-linux-gnu --build=m68k-unknown-linux-gnu --prefix=/usr --bindir=/usr/m68k-unknown-linux-gnu/gcc-bin/13 --includedir=/usr/lib/gcc/m68k-unknown-linux-gnu/13/include --datadir=/usr/share/gcc-data/m68k-unknown-linux-gnu/13 --mandir=/usr/share/gcc-data/m68k-unknown-linux-gnu/13/man --infodir=/usr/share/gcc-data/m68k-unknown-linux-gnu/13/info --with-gxx-include-dir=/usr/lib/gcc/m68k-unknown-linux-gnu/13/include/g++-v13 --with-python-dir=/share/gcc-data/m68k-unknown-linux-gnu/13/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --disable-libunwind-exceptions --with-gcc-major-version-only --disable-esp --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp" followed by "make bootstrap". 2) The compilation should eventually fail in stage3 gcc bootstrap while compiling gimple-match.cc. I'll be happy to provide any additional details or clarifications that you may require. Thank you for your help. -Stan Johnson
[Bug fortran/103794] ICE in gfc_check_reshape, at fortran/check.c:4727
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103794 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Keywords||wrong-code --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-May/059317.html
[Bug libstdc++/104605] _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for canadian cross freestanding C++ toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605 cqwrteur changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #18 from cqwrteur --- (In reply to Jonathan Wakely from comment #17) > (In reply to Jonathan Wakely from comment #16) > > This should be fixed now, please check. Fixed confirm
[Bug tree-optimization/90886] loop/while/for problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #13 from Andrew Pinski --- This is a really interesting case as it works for GCC 6.x just fine but it was broken in GCC 5.x and GCC 7.x. From looking at the IR, it looks like it was broken in two different ways before.
[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > Where are the target header installed? The problem is that djgpp crx does not provide fenv.h libstdc++ provides a fenv.h, however, the build system cannot find it with canadian compilation.
[Bug tree-optimization/90886] loop/while/for problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886 Georg-Johann Lay changed: What|Removed |Added Component|target |tree-optimization --- Comment #12 from Georg-Johann Lay --- As explained in comment #11, this is a tree optimizaton issue: (In reply to Georg-Johann Lay from comment #11) > [...] > Reason appears to be that the C++ front-end expand the loop variable as > signed char, and later passes think that there is some signed overflow und > Undefined Behaviour. > > With -fwrapv, correct code is generated. > > Also, the C front end also uses signed char, but for some reason the C > version works. > > A work-around is to use -fwrapv so that signed overflow wraps around. > > This is not a target issue, it's some tree optimization where GCC falls in > its own pit as it tries to exploit signed overflow. > > I could not reproduce this with later version of the compiler. The next > version I tried was v8.5 (I don't have other versions handy). > > I leave this bug open for now. Maybe the tree folks can pin down which PR > this actually is, and when it was fixed.
[Bug target/90886] loop/while/for problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
--- Comment #11 from Georg-Johann Lay ---
Created attachment 55132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55132=edit
C++ test case for v5.4 -Os
I can confirm this with avr-g++-5.4.0 and the attached test case:
> avr-gcc-5.4.0 -xc++ loop.c -Os -S -dp -da -fdump-tree-all
volatile unsigned char x;
void callee (unsigned char);
void f128 (void)
{
while (1)
for (unsigned char i = 0; i < 128; i++)
x = i;
}
void f128_call (void)
{
while (1)
for (unsigned char i = 0; i < 128; i++)
callee (i);
}
The generated assembly is:
_Z4f128v:
sts x,__zero_reg__ ; 5 movqi_insn/3[length = 2]
_Z9f128_callv:
ldi r24,0; 5 movqi_insn/1[length = 1]
rcall _Z6calleeh ; 6 call_insn/2 [length = 1]
This is all of the code because in dump loop.c.073t.cunrolli there is:
void f128() ()
{
unsigned char i;
:
:
:
x ={v} 0;
i_7 = 1;
__builtin_unreachable ();
}
and similar for the other function.
Reason appears to be that the C++ front-end expand the loop variable as signed
char, and later passes think that there is some signed overflow und Undefined
Behaviour.
With -fwrapv, correct code is generated.
Also, the C front end also uses signed char, but for some reason the C version
works.
A work-around is to use -fwrapv so that signed overflow wraps around.
This is not a target issue, it's some tree optimization where GCC falls in its
own pit as it tries to exploit signed overflow.
I could not reproduce this with later version of the compiler. The next version
I tried was v8.5 (I don't have other versions handy).
I leave this bug open for now. Maybe the tree folks can pin down which PR this
actually is, and when it was fixed.
[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #3 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > Where are the target header installed? The headers are installed in the cross toolchain
[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-05-21 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- Where are the target header installed?
[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #1 from cqwrteur --- /home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/i586-msdosdjgpp/artifacts/hostbuild/x86_64-w64-mingw32/gcc/i586-msdosdjgpp/libstdc++-v3/include/fenv.h:36:16: fatal error: fenv.h: No such file or directory 36 | # include_next |^~~~ compilation terminated. make[4]: *** [Makefile:1928: i586-msdosdjgpp/bits/stdc++.h.gch/O2g.gch] Error 1 make[4]: Leaving directory '/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/i586-msdosdjgpp/artifacts/hostbuild/x86_64-w64-mingw32/gcc/i586-msdosdjgpp/libstdc++-v3/include' make[3]: *** [Makefile:576: all-recursive] Error 1
[Bug libstdc++/109926] New: fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 Bug ID: 109926 Summary: fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 55131 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55131=edit i586-msdosdjgpp bug i586-msdosdjgpp bug
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #19 from Iain Sandoe --- fixed on open branches
[Bug libgomp/109875] [OpenMP] nteams-var / OMP_NUM_TEAMS → ICV not passed to the device / default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109875 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Tobias Burnus --- FIXED the issue that the number of teams in target regions exceeded the limit set by the nteams-var ICV. (→ GCC mainline/14). Unsolved: Checking whether the omp_get_max_teams() returns the proper value or not. — This depends on the outcome of OpenMP Spec Issue 3619. Still close this issue as a likely solution could be to keep the current implementation (init = 0, return value of the ICV, which is 0), possibly except for permitting 0 for the env var (0 is already accepted for omp_set_num_devices), but the outcome should be tracked in a new issue.
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #18 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:34608a771216b40307bcbee767605a328265a940 commit r10-11414-g34608a771216b40307bcbee767605a328265a940 Author: Iain Sandoe Date: Wed Jan 18 19:58:33 2023 + Darwin, fixincludes: Handle MacOS13 SDK Apple-specific deprecations [PR107568]. The SDK for MacOS13 includes Apple-specific deprecations of some functions that are not deprecated in Posix, C or C++ and widely used in GCC. The fix makes the deprecation conditional on __APPLE_LOCAL_DEPRECATIONS so that end users may still observe them but they are hidden from normal compilations. Signed-off-by: Iain Sandoe PR target/107568 fixincludes/ChangeLog: * fixincl.x: Regenerate. * inclhack.def: Add a fix for MacOS13 SDK function deprecations in stdio.h. * tests/base/stdio.h (__deprecated_msg): New test. (cherry picked from commit 442d2bdc1d2a98aba0b18aeaa3e87fa946ac8031)
[Bug libgomp/109875] [OpenMP] nteams-var / OMP_NUM_TEAMS → ICV not passed to the device / default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109875 --- Comment #3 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:ad0f80d945cc36fbb60fd1e04d90681d4302de8b commit r14-1026-gad0f80d945cc36fbb60fd1e04d90681d4302de8b Author: Tobias Burnus Date: Sun May 21 20:36:19 2023 +0200 libgomp: Honor OpenMP's nteams-var ICV as upper limit on num teams [PR109875] The nteams-var ICV exists per device and can be set either via the routine omp_set_num_teams or as environment variable (OMP_NUM_TEAMS with optional _ALL/_DEV/_DEV_ suffix); it is default-initialized to zero. The number of teams created is described under the num_teams clause. If the clause is absent, the number of teams is implementation defined but at least one team must exist and, if nteams-var is positive, at most nteams-var teams may exist. The latter condition was not honored in a target region before this commit, such that too many teams were created. Already before this commit, both the num_teams([lower:]upper) clause (on the host and in target regions) and, only on the host, the nteams-var ICV were honored. And as only one teams is created for host fallback, unless the clause specifies otherwise, the nteams-var ICV was and is effectively honored. libgomp/ChangeLog: PR libgomp/109875 * config/gcn/target.c (GOMP_teams4): Honor nteams-var ICV. * config/nvptx/target.c (GOMP_teams4): Likewise. * testsuite/libgomp.c-c++-common/teams-nteams-icv-1.c: New test. * testsuite/libgomp.c-c++-common/teams-nteams-icv-2.c: New test. * testsuite/libgomp.c-c++-common/teams-nteams-icv-3.c: New test. * testsuite/libgomp.c-c++-common/teams-nteams-icv-4.c: New test.
[Bug tree-optimization/109920] [14 Regression] value-range.h: Mismatched new [] and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920 Andrew Pinski changed: What|Removed |Added Summary|value-range.h: Mismatched |[14 Regression] |new [] and delete |value-range.h: Mismatched ||new [] and delete Version|unknown |14.0 Keywords||ice-checking, ||ice-on-valid-code Target Milestone|--- |14.0
[Bug target/90622] Suboptimal code generated for __builtin_avr_insert_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90622 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #3 from Georg-Johann Lay --- Fixed in v14.
[Bug target/90622] Suboptimal code generated for __builtin_avr_insert_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90622 --- Comment #2 from CVS Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:dad3c18fbb481ab31f1586b8f980940fa55951b8 commit r14-1025-gdad3c18fbb481ab31f1586b8f980940fa55951b8 Author: Georg-Johann Lay Date: Sun May 21 18:54:21 2023 +0200 target/90622: __builtin_avr_insert bits: Use BLD/BST for one bit in place. If just one bit is inserted in the same position like with: __builtin_avr_insert_bits (0xF2FF, src, dst); a BLD/BST sequence is better than XOR/AND/XOR. Thus, don't fold that case to the latter sequence. gcc/ PR target/90622 * config/avr/avr.cc (avr_fold_builtin) [AVR_BUILTIN_INSERT_BITS]: Don't fold to XOR / AND / XOR if just one bit is copied to the same position.
[Bug tree-optimization/109778] [10/11/12/13 Regression] Wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109778 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Jakub Jelinek --- Fixed.
[Bug libobjc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 --- Comment #7 from Iain Sandoe --- I'd think that the simple local fix would be reaosnable for now - Andrew has noted on IRC that we really should have a better way to get the target-specific info (better than replicating the logic for each target that needs it; likely imcompletely, certainly w.r.t any user-defined alignment changes)
[Bug libobjc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 Iain Sandoe changed: What|Removed |Added Build|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||powerpc*-apple-darwin* Last reconfirmed||2023-05-21 Status|UNCONFIRMED |NEW Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||powerpc*-apple-darwin* Ever confirmed|0 |1 Host|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||powerpc*-apple-darwin* CC||iains at gcc dot gnu.org
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #23 from Georg-Johann Lay ---
Created attachment 55130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55130=edit
Test case for -Os -mmcu=attiny40
As it appears, this bug is not fixed completely. For the -mmcu=avrtiny
architecture, there is still bloat for even the smallest test cases like:
$ avr-gcc bloat.c -mmcu=attiny40 -Os -S
char func3 (char c)
{
return 1 + c;
}
"GCC: (GNU) 14.0.0 20230520 (experimental)" compiles this to:
func3:
push r28 ; 22 [c=4 l=1] pushqi1/0
push r29 ; 23 [c=4 l=1] pushqi1/0
push __tmp_reg__ ; 27 [c=4 l=1] *addhi3_sp
in r28,__SP_L__ ; 38 [c=4 l=2] *movhi/7
in r29,__SP_H__
/* prologue: function */
/* frame size = 1 */
/* stack size = 3 */
mov r20,r24 ; 18 [c=4 l=1] movqi_insn/0
subi r20,lo8(-(1)) ; 19 [c=4 l=1] *addqi3/1
mov r24,r20 ; 21 [c=4 l=1] movqi_insn/0
/* epilogue start */
pop __tmp_reg__ ; 33 [c=4 l=1] *addhi3_sp
pop r29 ; 34 [c=4 l=1] popqi
pop r28 ; 35 [c=4 l=1] popqi
ret ; 36 [c=0 l=1] return_from_epilogue
For reference, avr-gcc v8 generates for this function:
func3:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
subi r24,lo8(-(1)) ; 6 [c=4 l=1] addqi3/1
/* epilogue start */
ret ; 17 [c=0 l=1] return
[Bug c++/98644] [10/11 Regression] [concepts] ICE in satisfaction_value, at cp/constraint.cc:2825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98644 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|10.5|12.0 Resolution|--- |FIXED --- Comment #7 from Patrick Palka --- Fixed for GCC 12+, this doesn't seem worthwhile to backport since it's ICE-on-invalid.
[Bug tree-optimization/109925] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu since GCC-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109925
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Target Milestone|--- |10.5
Component|c |tree-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-21
Summary|Wrong code at -O2 on|[10/11/12/13/14 Regression]
|x86_64-linux-gnu since |Wrong code at -O2 on
|GCC-12 |x86_64-linux-gnu since
||GCC-12
--- Comment #1 from Jakub Jelinek ---
With
int a, c, f;
int
main ()
{
int g[2];
for (c = 0; c < 2; c++)
{
{
char h[20], *b = h;
int d = 48, e = 0;
while (d && e < 5)
b[e++] = d /= 10;
f = e;
}
g[f - 2 + c] = 0;
}
for (;;)
{
for (; a <= 4; a++)
if (g[0])
break;
break;
}
if (a != 5)
__builtin_abort ();
return 0;
}
at -O2 this started with r7-1513-g1dc8d15bc6d7d55c7731093e
[Bug c++/103631] [11 Regression] ICE in C++20 class NTTP + concept since r12-100-gbcd77b7b9f35bd5b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103631 Patrick Palka changed: What|Removed |Added Target Milestone|11.4|12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 12+ (r12-6773 is not being backported).
[Bug c++/103672] [10/11 Regression] using with template class> causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103672 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|10.5|12.0 Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed for GCC 12+. This doesn't seem suitable for backporting, and never properly worked before anyway so it's hardly a regression.
[Bug c++/105491] [10/11 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491 Patrick Palka changed: What|Removed |Added Target Milestone|10.5|12.2 Known to fail||10.4.0, 11.3.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Patrick Palka --- Fixed for GCC 12.2+. The patch unfortunately doesn't apply cleanly to older release branches, and would be non-trivial to adapt.
[Bug c/109925] New: Wrong code at -O2 on x86_64-linux-gnu since GCC-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109925
Bug ID: 109925
Summary: Wrong code at -O2 on x86_64-linux-gnu since GCC-12
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
For the following code, gcc trunk emits wrong code at -O2.
Compiler explorer: https://godbolt.org/z/hcnaxoPaP
$ cat a.c
int printf(const char *, ...);
int a, c, f;
int main() {
int g[2];
c = 0;
for (; c < 2; c++) {
{
char h[20];
char *b = h;
int d = 48, e = 0;
while (d && e < 5)
b[e++] = d /= 10;
f = e;
}
g[f - 2 + c] = 0;
}
for (;;) {
for (; a <= 4; a++)
if (g[0])
break;
break;
}
printf("%d\n", a);
}
$
$ gcc-tk -O0 a.c && ./a.out
5
$ gcc-tk -O2 a.c && ./a.out
0
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-f211757f6fa9515e3fd1a4f66f1a8b48e500c9de/bin/gcc
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-f211757f6fa9515e3fd1a4f66f1a8b48e500c9de/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-f211757f6fa9515e3fd1a4f66f1a8b48e500c9de
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230521 (experimental) (GCC)
$
[Bug c++/109924] missing __builtin_nanf16b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109924
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Why do you need that?
The std::bfloat16_t builtins are intentionally limited to only what is really
required, there is no support in libc for that type whatever and only minimum
needed in libgcc.
A quiet NaN can be created as (decltype (0.0bf16)) __builtin_nanf ("") etc.
The reason there is __builtin_nansf16b builtin is that the above doesn't really
work for signalling NaNs, as on the cast an exception is emitted and the sNaN
turned into a qNaN.
Similarly, there is __builtin_nextafterf16b builtin so that this operation can
be folded for constexpr. Most other operations on bfloat16_t as can be seen on
the libstdc++ implementation or even what gcc emits for such arithmetics on the
type is promote to std::float32_t, perform operation in the wider mode and then
cast back (and the fact that the compiler implements excess precision for that
type).
[Bug c++/105289] [11 Regression] ICE on partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Fixed -- PR86193 remains open to deal with the question of validity of such partial specializations.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #19 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f211757f6fa9515e3fd1a4f66f1a8b48e500c9de commit r14-1023-gf211757f6fa9515e3fd1a4f66f1a8b48e500c9de Author: Jakub Jelinek Date: Sun May 21 13:36:56 2023 +0200 atch.pd: Ensure (op CONSTANT_CLASS_P CONSTANT_CLASS_P) is simplified [PR109505] On the following testcase we hang, because POLY_INT_CST is CONSTANT_CLASS_P, but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) simplification actually relies on the (CST1 & CST2) simplification, otherwise it is a deoptimization, trading 2 ops for 3 and furthermore running into /* Given a bit-wise operation CODE applied to ARG0 and ARG1, see if both operands are another bit-wise operation with a common input. If so, distribute the bit operations to save an operation and possibly two if constants are involved. For example, convert (A | B) & (A | C) into A | (B & C) Further simplification will occur if B and C are constants. */ simplification which simplifies that (x & CST2) | (CST1 & CST2) back to CST2 & (x | CST1). I went through all other places I could find where we have a simplification with 2 CONSTANT_CLASS_P operands and perform some operation on those two, while the other spots aren't that severe (just trade 2 operations for another 2 if the two constants don't simplify, rather than as in the above case trading 2 ops for 3), I still think all those spots really intend to optimize only if the 2 constants simplify. So, the following patch adds to those a ! modifier to ensure that, even at GENERIC that modifier means !EXPR_P which is exactly what we want IMHO. 2023-05-21 Jakub Jelinek PR tree-optimization/109505 * match.pd ((x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2), Combine successive equal operations with constants, (A +- CST1) +- CST2 -> A + CST3, (CST1 - A) +- CST2 -> CST3 - A, CST1 - (CST2 - A) -> CST3 + A): Use ! on ops with 2 CONSTANT_CLASS_P operands. * gcc.target/aarch64/sve/pr109505.c: New test.
[Bug c++/109924] New: missing __builtin_nanf16b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109924 Bug ID: 109924 Summary: missing __builtin_nanf16b Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: g.peterh...@t-online.de Target Milestone: --- like __builtin_nansf16b regards Gero
[Bug c++/109923] New: Template friend function defined in a template class becomes a friend of all instantiations, not one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109923
Bug ID: 109923
Summary: Template friend function defined in a template class
becomes a friend of all instantiations, not one
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor_suvorov at mail dot ru
Target Milestone: ---
The following code is accepted by all versions of GCC that I tried (including
"trunk" and 4.1.2 on Godbolt), but rejected by Clang and Visual Studio
(https://godbolt.org/z/z9f9qbPqb):
template
struct MyTemplate {
private:
int x;
public:
MyTemplate() : x(0) {}
friend void non_templ_friend(MyTemplate val, MyTemplate weird) {
// MyTemplate is a friend of non_templ_friend(MyTemplate,
MyTempl)
val.x++; // always works
weird.x++; // should only work when T=void
}
};
int main() {
non_templ_friend(MyTemplate(), MyTemplate());
}
I expect that a new `non_templ_friend` is defined for each `T`. Each
`non_templ_friend` is a friend of the `MyTemplate` it was created within.
Hence, it can only access internals of `MyTemplate` if `T=void`. Hence,
`main()` should not compile: I call `non_templ_friend` created with `T=int`, it
should not be a friend of `MyTemplate`.
[Bug libstdc++/109922] New: : consider removing operator>> for istream >> setfill(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109922
Bug ID: 109922
Summary: : consider removing operator>> for istream >>
setfill(c)
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fsb4000 at yandex dot ru
Target Milestone: ---
Hi.
This is a mirror of a bug report: https://github.com/microsoft/STL/issues/3724
I noticed that libstdc++ has the same bug but LLVM libc++ doesn't have.
Look at the code
#include
#include
int main()
{
std::cin >> std::setfill('*');
}
According to the
standard(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4944.pdf),
std::setfill is only for ostreams. Therefore, istream >> setfill(c) has no
well-defined meaning and can lead to confusion:
https://stackoverflow.com/questions/42530114/stdsetfill-and-stdsetw-for-input-streams
Initially reported by @achabense (https://github.com/achabense)
[Bug libstdc++/109921] New: c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921 Bug ID: 109921 Summary: c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: br015 at umbiko dot net Target Milestone: --- This was observed in 13.1.0, but code is the same as git master. Line numbers and code snippets refer to git master. /observed error/ Cross-compiling gcc 13.1 for a system without locales, libstdc++ fails to build with the following error: >Making all in c++17 >/bin/bash ../../libtool --tag CXX --tag disable-shared --mode=compile >/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/./gcc/xgcc >-shared-libgcc >-B/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/./gcc >-nostdinc++ >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/src > >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/src/.libs > >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/libsupc++/.libs > -B/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/bin/ >-B/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/lib/ -isystem >/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/include >-isystem >/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/sys-include >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/libstdc++-v3/../libgcc > >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/include/x86_64-buildroot-linux-uclibc > >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/include > >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/libstdc++-v3/libsupc++ > -std=gnu++17 -nostdinc++ -prefer-pic -D_GLIBCXX_SHARED >-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 >-fdiagnostics-show-location=once -ffunction-sections -fdata-sections >-frandom-seed=floating_from_chars.lo -fimplicit-templates -D_LARGEFILE_SOURCE >-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_GNU_SOURCE >-fcf-protection -mshstk -c -o floating_from_chars.lo >../../../../../libstdc++-v3/src/c++17/floating_from_chars.cc >libtool: compile: >/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/./gcc/xgcc >-shared-libgcc >-B/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/./gcc >-nostdinc++ >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/src > >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/src/.libs > >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/libsupc++/.libs > -B/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/bin/ >-B/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/lib/ -isystem >/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/include >-isystem >/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/sys-include >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/libstdc++-v3/../libgcc > >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstlibtool: > compile: >/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/./gcc/xgcc >-shared-libgcc >-B/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/./gcc >-nostdinc++ >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/src > >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/src/.libs > >-L/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/libsupc++/.libs > -B/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/bin/ >-B/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/lib/ -isystem >/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/include >-isystem >/home/data/buildroot.x86_64/host/x86_64-buildroot-linux-uclibc/sys-include >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/libstdc++-v3/../libgcc > >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/include/x86_64-buildroot-linux-uclibc > >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/build/x86_64-buildroot-linux-uclibc/libstdc++-v3/include > >-I/home/data/buildroot.x86_64/build/host-gcc-final-13.1.0/libstdc++-v3/libsupc++ > -std=gnu++17
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #18 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #16)
> But that still fails because combine really does not like subregs:
> [...]
> Failed to match this instruction:
> (set (reg/i:QI 24 r24)
> (subreg:QI (lshiftrt:SI (reg:SI 48)
> (const_int 31 [0x1f])) 0))
Eons ago I solved the canonicalization problem during combine as follow:
Prior to recog_for_combine, there was a target hook that could canonicalize
combined rtx's to a canonical form. This was achieved by means of special
split patterns (wrapped in some unspec_canonicalize and insn condition). If
there was a match, combine would proceed with the canonicalized form.
IMO, trying to target-independent canonicalize in combine itself just works to
some degree, because combine is well in target-specigic land, and targets are
very different.
;; Combine's "smart" method to extract the MSB.
(define_insn_and_split "*extzv.neg.subreg-msb."
[(set (match_operand:QI 0 "register_operand" "=r")
(neg:QI (subreg:QI
(ashiftrt:HISI (match_operand:HISI 1 "register_operand" "r")
(match_operand:QI 2 "const_operand" "n"))
0)))]
""
"#"
"&& reload_completed"
[; "*extzv"
(parallel [(set (match_dup 0)
(zero_extract:QI (match_dup 1)
(const_int 1)
(match_dup 2)))
(clobber (reg:CC REG_CC))])]
{
...;
})
Such patterns work, bit the problem is that you are pushing combine away from a
(target-)canonical form.
Next best match would be a pre-reload matching split. If that works, it might
be superior to a post-reload split, but it happens at split1 which runs after
reload.
The closest match to canonicalization are the non-matching splits that will run
during combine. The problem with these is that such splits must have very
special for (like split 1 pattern into exactly 2, additional restrictios
apply), and in many cases non-matching splits will fail or are not possible.
Such a target-specific canonicalization would push combine towards a
target-canonical form, instead of encouraging it to go further astray and try
even more crazy, none-canonical combinations.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #17 from Georg-Johann Lay --- Created attachment 55129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55129=edit Patch for AVR backend: combine patterns, "extzv", test case For now I have the attaches patch that resolves all cases of the included test-case. Iknow that the maintainers are not very fond of such combine patterns though... Provide more patterns to improve extracting (negated) single bits. Deprecated insn "extzv" is replaced by "extzv". The patterns now also allow lower I/O memory because both the insns and the instructions for I/O like SBIC/SBIS and the ones for REGs like SBRC/SBRS. Even in the presence of "extzv" there is no canonical form for single bit extractions, even less for extracting the insersed bit. So more than one mathod is provided. gcc/ PR target/109907 * config/avr/avr-protos.h (avr_out_extr, avr_out_extr_not): New protos. * config/avr/avr.cc (avr_out_extr, avr_out_extr_not): New functions. (avr_adjust_insn_length) [ADJUST_LEN_EXTR_NOT, ADJUST_LEN_EXTR]: Handle cases. * config/avr/avr.md (adjust_len) [extr, extr_not]: Add to define_attr. (extzv): Turn into extzv. (MSB): New mode attribute. (*extzv_split, *extzv): Allow lower I/O addresses in operand 1. Unify constraints to a single case, as avr_out_extr() will now handle the alternatives. (*extzv.not_split, *extzv_not): New insn and its post-reload split. (*extzv.subreg., *extzv.neg.subreg-msb., *extzv.ge): New insns and post-reload splits. (*extzv.xor, *extzv.io.lsr): New insns and pre-reload split. * config/avr/constraints.md (Yil): New constraint for reg or low I/O. * config/avr/predicates.md (reg_or_low_io_operand, const7_operand) (const15_operand, const23_operand, const31_operand) (const_0_to_7_operand, const_0_to_15_operand, const_0_to_23_operand) (const_0_to_31_operand): New predicates. gcc/testsuite/ PR target/109907 * gcc.target/avr/pr109907.c: New test.
[Bug target/100332] mcore-elf: error: 'prev_addr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100332 Jan-Benedict Glaw changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jan-Benedict Glaw --- Looking at ma latest builds, this issue is fixed already.
[Bug c/109920] value-range.h: Mismatched new [] and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920 David Binderman changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #1 from David Binderman --- Aldy's new value range code.
[Bug c/109920] New: value-range.h: Mismatched new [] and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
Bug ID: 109920
Summary: value-range.h: Mismatched new [] and delete
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I just did a valgrind build of gcc trunk. It said
=91612== Mismatched free() / delete / delete []
==91612==at 0x484498A: operator delete(void*, unsigned long)
(vg_replace_malloc.c:1072)
==91612==by 0x18D285B: ~int_range (value-range.h:493)
==91612==by 0x18D285B: ~Value_Range (value-range.h:516)
==91612==by 0x18D285B: ranger_cache::fill_block_cache(tree_node*,
basic_block_def*, basic_block_def*) (gimple-range-cache.cc:1479)
Source code is
inline void
irange::maybe_resize (int needed)
{
if (!m_resizable || m_max_ranges == HARD_MAX_RANGES)
return;
if (needed > m_max_ranges)
{
m_max_ranges = HARD_MAX_RANGES;
wide_int *newmem = new wide_int[m_max_ranges * 2];
memcpy (newmem, m_base, sizeof (wide_int) * num_pairs () * 2);
m_base = newmem;
}
}
template
inline
int_range::~int_range ()
{
if (RESIZABLE && m_base != m_ranges)
delete m_base;
}
Note use of new [] and delete.
