[Bug c++/107147] [13 Regression] ICE in register_local_var_uses, at cp/coroutines.cc:3923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107147 Arsen Arsenović changed: What|Removed |Added CC||arsen at aarsen dot me --- Comment #3 from Arsen Arsenović --- (In reply to Martin Liška from comment #2) > It's there since coroutines were added in r10-6063-g49789fd08378e3ff. I don't think it was, I can't reprod on 12.2.0 but can on trunk (a few days behind though, rebuilding newest currently)
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 Jakub Jelinek changed: What|Removed |Added Attachment #53675|0 |1 is obsolete|| --- Comment #15 from Jakub Jelinek --- Created attachment 53679 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53679&action=edit gcc13-pr106654-gimple-wip.patch Updated patch with the ICE fixed (DECL_ARG_TYPE on the PARM_DECLs wasn't set) and 1) and 5) implemented.
[Bug c++/107147] [13 Regression] ICE in register_local_var_uses, at cp/coroutines.cc:3923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107147 --- Comment #4 from Arsen Arsenović --- Ah, my bad, I had checking off in my 12.2.0 build.
[Bug tree-optimization/107184] New: Copy warnings in dump files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107184 Bug ID: 107184 Summary: Copy warnings in dump files Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- One irritation with warnings like -Wuse-after-free and all the other optimization-based warnings is how hard they are to track. Yes, it tells me where the call is in my code, but that's far from enough. With -fdump-tree-waccess, I can have some idea of what the code looks like, after various optimizations, that makes the compiler warn. However, identifying the relevant statements in the dump file can take a long time, and it remains faster to break out the debugger on the compiler :-( It seems that a small thing that could help a bit would be to print a copy of the warnings and notes in the dump file, next to the relevant statements. Or at least some easy to find marker. I most certainly don't claim that this will solve anything, I just see it as a low (?) hanging fruit.
[Bug target/107185] New: [13 Regression] during RTL pass: vregs ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffast-math and lrintf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107185 Bug ID: 107185 Summary: [13 Regression] during RTL pass: vregs ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffast-math and lrintf() Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 53680 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53680&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -ffast-math testcase.c testcase.c: In function 'foo': testcase.c:5:1: error: unrecognizable insn: 5 | } | ^ (insn 7 6 0 2 (set (mem/c:DI (plus:DI (reg/f:DI 77 virtual-stack-vars) (const_int -8 [0xfff8])) [1 l+0 S8 A64]) (unspec:DI [ (reg:SF 82) ] UNSPEC_FIX_NOTRUNC)) "testcase.c":4:12 -1 (nil)) during RTL pass: vregs testcase.c:5:1: internal compiler error: in extract_insn, at recog.cc:2791 0x782279 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:108 0x7822f5 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:116 0x770eaa extract_insn(rtx_insn*) /repo/gcc-trunk/gcc/recog.cc:2791 0x103f6c9 instantiate_virtual_regs_in_insn /repo/gcc-trunk/gcc/function.cc:1611 0x103f6c9 instantiate_virtual_regs /repo/gcc-trunk/gcc/function.cc:1985 0x103f6c9 execute /repo/gcc-trunk/gcc/function.cc:2034 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-3175-20221007202551-g6ffbf87ca66-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-3175-20221007202551-g6ffbf87ca66-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20221008 (experimental) (GCC)
[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409 --- Comment #12 from kargl at gcc dot gnu.org --- (In reply to Jeff Hammond from comment #11) > > program foo > >use f > >integer i > >call test(i) > > end program > > > > which specific subroutine is called based on TKR? > > I understand there is an ambiguity here, but what if I never make this call? > Is the module code incorrect? > 21-007.pdf:C1514 is sufficiently opaque that I cannot easily decide if a compiler needs to catch this or not. OTOH, the TKR information is present during compilation, it would seem appropriate that a compiler will complain about the issue. BTW, the original code from Chris MacMackin compiles, so at least that portion of the PR has been fixed.
[Bug c++/107186] New: GCC rejects use of static constexpr member function in noexcept complete-class context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107186
Bug ID: 107186
Summary: GCC rejects use of static constexpr member function
in noexcept complete-class context
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following valid program is rejected by gcc as well as other compilers:
```
struct A {
constexpr static bool func()
{
return true;
}
//--vv--->works as expected #1
void f(bool V1 = func())
{
bool V2 = func(); //works as expected #2
}
//-vv>DOESN'T WORK? #3
void g() noexcept(func())
{
;
}
};
```
>From [class.mem.general](https://eel.is/c++draft/class.mem.general#7.4):
> A complete-class context of a class is a
>
> * noexcept specifier
As we can see the noexcept speficier is included in the complete-class context
so the `#3` should work.
[Bug fortran/100040] Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:07da38566232cc11901c3eeb9fc2860f02f2e31f commit r12-8813-g07da38566232cc11901c3eeb9fc2860f02f2e31f Author: José Rui Faustino de Sousa Date: Sun Sep 25 22:48:55 2022 +0200 Fortran: Fix ICE and wrong code for assumed-rank arrays [PR100029, PR100040] gcc/fortran/ChangeLog: PR fortran/100040 PR fortran/100029 * trans-expr.cc (gfc_conv_class_to_class): Add code to have assumed-rank arrays recognized as full arrays and fix the type of the array assignment. (gfc_conv_procedure_call): Change order of code blocks such that the free of ALLOCATABLE dummy arguments with INTENT(OUT) occurs first. gcc/testsuite/ChangeLog: PR fortran/100029 * gfortran.dg/PR100029.f90: New test. PR fortran/100040 * gfortran.dg/PR100040.f90: New test. (cherry picked from commit 5299155bb80e90df822e1eebc9f9a0c8e4505a46)
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:07da38566232cc11901c3eeb9fc2860f02f2e31f commit r12-8813-g07da38566232cc11901c3eeb9fc2860f02f2e31f Author: José Rui Faustino de Sousa Date: Sun Sep 25 22:48:55 2022 +0200 Fortran: Fix ICE and wrong code for assumed-rank arrays [PR100029, PR100040] gcc/fortran/ChangeLog: PR fortran/100040 PR fortran/100029 * trans-expr.cc (gfc_conv_class_to_class): Add code to have assumed-rank arrays recognized as full arrays and fix the type of the array assignment. (gfc_conv_procedure_call): Change order of code blocks such that the free of ALLOCATABLE dummy arguments with INTENT(OUT) occurs first. gcc/testsuite/ChangeLog: PR fortran/100029 * gfortran.dg/PR100029.f90: New test. PR fortran/100040 * gfortran.dg/PR100040.f90: New test. (cherry picked from commit 5299155bb80e90df822e1eebc9f9a0c8e4505a46)
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1167c14d598021581e984cbe46273ade4bc54126 commit r11-10295-g1167c14d598021581e984cbe46273ade4bc54126 Author: José Rui Faustino de Sousa Date: Sun Sep 25 22:48:55 2022 +0200 Fortran: Fix ICE and wrong code for assumed-rank arrays [PR100029, PR100040] gcc/fortran/ChangeLog: PR fortran/100040 PR fortran/100029 * trans-expr.c (gfc_conv_class_to_class): Add code to have assumed-rank arrays recognized as full arrays and fix the type of the array assignment. (gfc_conv_procedure_call): Change order of code blocks such that the free of ALLOCATABLE dummy arguments with INTENT(OUT) occurs first. gcc/testsuite/ChangeLog: PR fortran/100029 * gfortran.dg/PR100029.f90: New test. PR fortran/100040 * gfortran.dg/PR100040.f90: New test. (cherry picked from commit 5299155bb80e90df822e1eebc9f9a0c8e4505a46)
[Bug fortran/100040] Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1167c14d598021581e984cbe46273ade4bc54126 commit r11-10295-g1167c14d598021581e984cbe46273ade4bc54126 Author: José Rui Faustino de Sousa Date: Sun Sep 25 22:48:55 2022 +0200 Fortran: Fix ICE and wrong code for assumed-rank arrays [PR100029, PR100040] gcc/fortran/ChangeLog: PR fortran/100040 PR fortran/100029 * trans-expr.c (gfc_conv_class_to_class): Add code to have assumed-rank arrays recognized as full arrays and fix the type of the array assignment. (gfc_conv_procedure_call): Change order of code blocks such that the free of ALLOCATABLE dummy arguments with INTENT(OUT) occurs first. gcc/testsuite/ChangeLog: PR fortran/100029 * gfortran.dg/PR100029.f90: New test. PR fortran/100040 * gfortran.dg/PR100040.f90: New test. (cherry picked from commit 5299155bb80e90df822e1eebc9f9a0c8e4505a46)
[Bug fortran/100040] Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a880f9a44ecad385d4273f96f76c5c900d716941 commit r10-11024-ga880f9a44ecad385d4273f96f76c5c900d716941 Author: José Rui Faustino de Sousa Date: Sun Sep 25 22:48:55 2022 +0200 Fortran: Fix ICE and wrong code for assumed-rank arrays [PR100029, PR100040] gcc/fortran/ChangeLog: PR fortran/100040 PR fortran/100029 * trans-expr.c (gfc_conv_class_to_class): Add code to have assumed-rank arrays recognized as full arrays and fix the type of the array assignment. (gfc_conv_procedure_call): Change order of code blocks such that the free of ALLOCATABLE dummy arguments with INTENT(OUT) occurs first. gcc/testsuite/ChangeLog: PR fortran/100029 * gfortran.dg/PR100029.f90: New test. PR fortran/100040 * gfortran.dg/PR100040.f90: New test. (cherry picked from commit 5299155bb80e90df822e1eebc9f9a0c8e4505a46)
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a880f9a44ecad385d4273f96f76c5c900d716941 commit r10-11024-ga880f9a44ecad385d4273f96f76c5c900d716941 Author: José Rui Faustino de Sousa Date: Sun Sep 25 22:48:55 2022 +0200 Fortran: Fix ICE and wrong code for assumed-rank arrays [PR100029, PR100040] gcc/fortran/ChangeLog: PR fortran/100040 PR fortran/100029 * trans-expr.c (gfc_conv_class_to_class): Add code to have assumed-rank arrays recognized as full arrays and fix the type of the array assignment. (gfc_conv_procedure_call): Change order of code blocks such that the free of ALLOCATABLE dummy arguments with INTENT(OUT) occurs first. gcc/testsuite/ChangeLog: PR fortran/100029 * gfortran.dg/PR100029.f90: New test. PR fortran/100040 * gfortran.dg/PR100040.f90: New test. (cherry picked from commit 5299155bb80e90df822e1eebc9f9a0c8e4505a46)
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.5 Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the patch!
[Bug fortran/100040] Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |RESOLVED Target Milestone|--- |10.5 Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the patch!
[Bug d/105413] gdc extended assembler cannot constraints r8 - r15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105413
--- Comment #3 from Witold Baryluk ---
It works. Thank you.
Any chance this will be in gcc 12.x? I work a lot on Debian Linux, and I doubt
I will have gcc trunk or gcc 13 available any time soon.
Also weirdly gcc does not inline this function, unless I add
@attribute("always_inline") on syscall, or @attribute("flatten") on
openatdummy.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #24 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:705ed42a1ad950860f46c51216ff69dbe0f4857a commit r13-3176-g705ed42a1ad950860f46c51216ff69dbe0f4857a Author: Harald Anlauf Date: Tue Oct 4 23:04:06 2022 +0200 Fortran: error recovery for invalid types in array constructors [PR107000] gcc/fortran/ChangeLog: PR fortran/107000 * arith.cc (gfc_arith_error): Define error message for ARITH_INVALID_TYPE. (reduce_unary): Catch arithmetic expressions with invalid type. (reduce_binary_ac): Likewise. (reduce_binary_ca): Likewise. (reduce_binary_aa): Likewise. (eval_intrinsic): Likewise. (gfc_real2complex): Source expression must be of type REAL. * gfortran.h (enum arith): Add ARITH_INVALID_TYPE. gcc/testsuite/ChangeLog: PR fortran/107000 * gfortran.dg/pr107000.f90: New test. Co-authored-by: Mikael Morin
[Bug fortran/87659] Memory corruption in array component of intent(in) unlimited polymorphic with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- Seems to work now...
[Bug fortran/102275] Assumed rank, unlimited polymorphic pointer gives incorrect behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102275 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Seems to work now...
[Bug c++/107187] New: [feature request] Add `trivial_abi` attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107187 Bug ID: 107187 Summary: [feature request] Add `trivial_abi` attribute Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nikolasklauser at berlin dot de Target Milestone: --- This attribute is implemented by clang. It changes the calling convention of non-trivial class types to be trivial for the purpose of calls (with some caveats). libc++ has used it in the unstable ABI for some time now, and we'd like to use it for new types in the stable ABI too, since it can improve performance dramatically. I'm sure libstdc++ (and other libraries) will find it useful too. See https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/ for a more detailed explanation of it's benefits and drawbacks and https://clang.llvm.org/docs/AttributeReference.html#trivial-abi for the clang documentation.
[Bug c++/107187] [feature request] Add `trivial_abi` attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107187 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/107187] [feature request] Add `trivial_abi` attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107187 --- Comment #1 from Andrew Pinski --- I think a better way of implementing an abi specific attribute is in the shared c++ abi forum and then have it accepted there too. Then it could be the shared abi namespace like other c++ abi features are done.
[Bug c++/107188] New: using concept type-constraint declared in nested namespace causes incorrect compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107188
Bug ID: 107188
Summary: using concept type-constraint declared in nested
namespace causes incorrect compilation error
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Mark_B53 at yahoo dot com
Target Milestone: ---
#include
#include
#include
namespace ns1 {
template
concept RangeV = std::ranges::range &&
std::same_as, V>;
}
namespace ns2 {
ns1::RangeV auto fn() { return std::vector{}; } // compiles
struct X {
ns1::RangeV auto fn() { return std::vector{}; } // fails to
compile (bug!)
};
using ns1::RangeV;
struct Y {
RangeV auto fn() { return std::vector{}; } // compiles
};
}
-
:11:10: error: wrong number of template arguments (1, should be 2)
11 | ns1::RangeV auto fn() { return std::vector{}; } // fails
to compile (bug!)
| ^~~
:6:9: note: provided for 'template concept
ns1::RangeV'
6 | concept RangeV = std::ranges::range &&
std::same_as, V>;
-
g++ a.cpp -std=c++20
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20221008/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,d --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc-895dd027d5dda51a95d242aec8a49a6dfa5db58d-binutils-2.38
--enable-libstdcxx-backtrace=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221007 (experimental)
(Compiler-Explorer-Build-gcc-895dd027d5dda51a95d242aec8a49a6dfa5db58d-binutils-2.38)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-v' '-std=c++20' '-isystem'
'/opt/compiler-explorer/libs/boost_1_80_0' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' '/app/'
/opt/compiler-explorer/gcc-trunk-20221008/bin/../libexec/gcc/x86_64-linux-gnu/13.0.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20221008/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/
-D_GNU_SOURCE -isystem /opt/compiler-explorer/libs/boost_1_80_0 -quiet
-dumpdir /app/ -dumpbase output.cpp -dumpbase-ext .cpp -masm=intel
-mtune=generic -march=x86-64 -g -std=c++20 -version -fdiagnostics-color=always
-o /app/output.s
GNU C++20
(Compiler-Explorer-Build-gcc-895dd027d5dda51a95d242aec8a49a6dfa5db58d-binutils-2.38)
version 13.0.0 20221007 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 9.4.0, GMP version 6.2.1, MPFR version 4.1.0,
MPC version 1.2.1, isl version isl-0.24-GMP
[Bug target/107185] [13 Regression] during RTL pass: vregs ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffast-math and lrintf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107185 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug libstdc++/107189] New: Inconsistent range insertion implementations in std::_Rb_tree in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107189
Bug ID: 107189
Summary: Inconsistent range insertion implementations in
std::_Rb_tree in
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
//#if __cplusplus >= 201103L
template
__enable_if_t<__same_value_type<_InputIterator>::value>
_M_insert_range_unique(_InputIterator __first, _InputIterator __last)
{
_Alloc_node __an(*this);
for (; __first != __last; ++__first)
_M_insert_unique_(end(), *__first, __an);
}
template
__enable_if_t::value>
_M_insert_range_unique(_InputIterator __first, _InputIterator __last)
{
for (; __first != __last; ++__first)
_M_emplace_unique(*__first);
}
template
__enable_if_t<__same_value_type<_InputIterator>::value>
_M_insert_range_equal(_InputIterator __first, _InputIterator __last)
{
_Alloc_node __an(*this);
for (; __first != __last; ++__first)
_M_insert_equal_(end(), *__first, __an);
}
template
__enable_if_t::value>
_M_insert_range_equal(_InputIterator __first, _InputIterator __last)
{
_Alloc_node __an(*this);
for (; __first != __last; ++__first)
_M_emplace_equal(*__first);
}
__an is not used in the 2nd overload of _M_insert_range_equal.
And is there any reason about not using _M_emplace_hint_{unique,equal} for
!__same_value_type cases?
[Bug tree-optimization/107184] Copy warnings in dump files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107184 --- Comment #1 from Andrew Pinski --- This is where analyzer comes into hand really. Maybe the warning should suggest using analyzer for more details? Even if they are two different code bases for the warning and analyzer it seems like they could work together
[Bug target/107185] [13 Regression] during RTL pass: vregs ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffast-math and lrintf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107185
--- Comment #1 from Hongtao.liu ---
Looks like there's mismatch between
20147(define_expand "lrint2"
20148 [(set (match_operand:SWI48 0 "nonimmediate_operand")
20149 (unspec:SWI48 [(match_operand:MODEF 1 "register_operand")]
20150 UNSPEC_FIX_NOTRUNC))]
20151 "SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH")
and
7770(define_insn "sse_cvtss2si_2"
7771 [(set (match_operand:SWI48 0 "register_operand" "=r,r")
7772(unspec:SWI48 [(match_operand:SF 1 "nonimmediate_operand" "v,m")]
7773 UNSPEC_FIX_NOTRUNC))]
...
...
8215(define_insn "sse2_cvtsd2si_2"
8216 [(set (match_operand:SWI48 0 "register_operand" "=r,r")
8217(unspec:SWI48 [(match_operand:DF 1 "nonimmediate_operand" "v,m")]
8218 UNSPEC_FIX_NOTRUNC))]
8219 "TARGET_SSE2"
8220 "%vcvtsd2si\t{%1, %0|%0, %q1}"
Need to swap predicates for operands[0] and operand[1] of
"lrint2"
