[Bug c/95024] want a way to turn off -Werror for a specific diagnostic but only emit an warning if it was turned on before hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95024
--- Comment #4 from Alejandro Colomar ---
Sorry, I didn't make it clear; I somehow forgot about it.
Here's the problem:
$ cat err.c
int
main(void)
{
short s;
int *p;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wno-error=incompatible-pointer-types"
p = &s;
#pragma GCC diagnostic pop
}
$ gcc err.c
err.c: In function ‘main’:
err.c:8:32: warning: unknown option after ‘#pragma GCC diagnostic’ kind
[-Wpragmas]
8 | #pragma GCC diagnostic ignored "-Wno-error=incompatible-pointer-types"
|^~~
err.c:8:32: note: did you mean ‘-Wno-incompatible-pointer-types’?
err.c:9:11: warning: assignment to ‘int *’ from incompatible pointer type
‘short int *’ [-Wincompatible-pointer-types]
9 | p = &s;
| ^
[Bug tree-optimization/115097] Strange suboptimal codegen specifically at -O2 when copying struct type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115097
Richard Biener changed:
What|Removed |Added
Version|unknown |15.0
Component|c |tree-optimization
CC||jamborm at gcc dot gnu.org
Last reconfirmed||2024-05-15
Status|UNCONFIRMED |NEW
Target||x86_64-*-*
Keywords||missed-optimization
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. The IL difference is
struct A test1 (struct A & a)
{
struct A D.2842;
[local count: 1073741824]:
D.2842 = MEM[(const struct A &)a_2(D)];
return D.2842;
vs
struct A test2 (struct A & a)
{
struct A D.2873;
struct A retval.4;
[local count: 1073741824]:
D.2873 = MEM[(const struct A &)a_2(D)];
retval.4 = D.2873;
return retval.4;
so there's an additional aggregate copy. With -O2 SRA scalarizes that
copy and we're not able to elide the resulting code on RTL while without
the SRA we can handle this fine.
SRA makes test2 into
struct A test2 (struct A & a)
{
short int SR.12;
int SR.11;
struct A retval.4;
[local count: 1073741824]:
SR.11_3 = MEM[(const struct A &)a_2(D)].a;
SR.12_6 = MEM[(const struct A &)a_2(D)].b;
retval.4.a = SR.11_3;
retval.4.b = SR.12_6;
return retval.4;
The extra copy is introduced during gimplfication, the GENERIC looks the
same (but of course there's a hidden difference):
;; Function A test1(A&) (null)
;; enabled by -tree-original
< = TARGET_EXPR >>;
;; Function A test2(A&&) (null)
;; enabled by -tree-original
< = TARGET_EXPR >>;
[Bug analyzer/115089] -Wanalyzer-use-of-uninitialized-value false negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115089 --- Comment #4 from Alejandro Colomar --- Thanks, David! I'm happy that this might help improve the analyzer. :-)
[Bug c++/105760] [11/12/13/14/15 Regression] ICE: in build_function_type, at tree.cc:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760 Simon Martin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|11.5|14.2 --- Comment #5 from Simon Martin --- Fixed on trunk.
[Bug target/115071] performance regression, x86, between gcc-14 and gcc-13 using -O3 and _Pragma("GCC unroll 4") on skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115071 Haochen Jiang changed: What|Removed |Added CC||haochen.jiang at intel dot com --- Comment #3 from Haochen Jiang --- I could not reproduce the regression. For me, it is: [haochenj@shgcc101 pr115071]$ ./13.exe duration: 7.09 seconds, count = 1119566602 [haochenj@shgcc101 pr115071]$ ./trunk.exe duration: 4.97 seconds, count = 1119566602
[Bug middle-end/115095] [missed optimization] fixed processing on constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115095 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-15 --- Comment #1 from Richard Biener --- GCC isn't able to compute the number of iterations of a loop like the following which would be required for us to peel it and do the required constant folding. We're also not trying brute-force peeling for loops we cannot compute an upper bound of its number of iterations (attempting to arrive at one when evaluating the peeled stmts). [local count: 955630224]: # _26 = PHI <_9(8), 116(2)> # h_27 = PHI # s_29 = PHI _10 = (unsigned int) _26; h_12 = _10 + h_27; s_14 = s_29 + 1; h_15 = _10 * h_12; _9 = *s_14; if (_9 != 0) goto ; [89.00%] else goto ; [11.00%] [local count: 850510900]: goto ; [100.00%]
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Paul Thomas changed:
What|Removed |Added
CC||fxcoudert at gmail dot com,
||pault at gcc dot gnu.org
--- Comment #3 from Paul Thomas ---
(In reply to anlauf from comment #2)
> Replacing the scalar argument 'obs' by something with rank > 0 avoids the
> ICE,
> but then assumed-rank is not accepted with intent(out). Another bug...
The tree output with 12-branch is:
__attribute__((fn spec (". r w ")))
void __copy_my_mod_My_type (struct my_type & restrict src, struct my_type &
restrict dst)
{
*dst = *src;
}
__attribute__((fn spec (". w ")))
void my_sub (struct __class_my_mod_My_type_t & restrict obs)
{
c_char fpstate.0[33];
try
{
_gfortran_ieee_procedure_entry ((void *) &fpstate.0);
if (obs->_vptr->_final != 0B)
{
{
struct array00_my_type desc.1;
desc.1.dtype = {.elem_len=4, .rank=0, .type=5};
desc.1.data = (void * restrict) obs->_data;
desc.1.span = (integer(kind=8)) desc.1.dtype.elem_len;
obs->_vptr->_final (&desc.1, obs->_vptr->_size, 0);
}
}
(void) __builtin_memcpy ((void *) obs->_data, (void *)
obs->_vptr->_def_init, (unsigned long) obs->_vptr->_size);
}
finally
{
_gfortran_ieee_procedure_exit ((void *) &fpstate.0);
}
}
13- through 15-branches lack the default copy of the default initializer. This
disappeared with the fix for pr112407 and is required by the standard if the
derived type has no default initializer. This suggests a workaround, which
indeed "works":
type my_type
integer :: a = 0
end type my_type
I cannot see anything in the ieee procedures that would cause this but then I
know zip-all about ieee.
Putting Francois-Xavier in copy in the hope that he can shed some light.
Cheers
Paul
[Bug middle-end/115091] Support value speculation in frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091 --- Comment #1 from Richard Biener --- maybe represent this in a more formal way: node = __builtin_speculate (node + 1, node->next); and in GIMPLE: _1 = node + 1; _2 = node->next; node = .SPECULATE (_1, _2); and during RTL expansion leave the desired representation to the targets which could use an UNSPEC to avoid optimizing it away. Formally we'd say __builtin_speculate "uses" the first argument if its value is equal to the second argument value. That said, I heard CPUs have prefetchers that recognize this kind of list walking. I wonder why they wouldn't then also be able to speculate the load value like you say. Oh, and doesn't this explicit speculation of using node++ open up spectre style attacks?
[Bug middle-end/115100] New: non-target specific const_scalar_int_operand predicate is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115100 Bug ID: 115100 Summary: non-target specific const_scalar_int_operand predicate is not documented Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- While trying looking into some of the aarch64 predicates I noticed that const_scalar_int_operand generic predicate is not documented in the internals manual (https://gcc.gnu.org/onlinedocs/gccint/Machine-Independent-Predicates.html#index-general_005foperand ). This has been true since wide-int branch was merged in back in 2014.
[Bug target/112304] cinc is not being used for (small) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112304 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Patch posted: > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650081.html Maybe it should be nonmemory_operand rather than general_operand ... Or aarch64_reg_or_imm
[Bug target/115086] bic is not used when the non-not part is a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086 --- Comment #3 from Andrew Pinski --- (In reply to Richard Earnshaw from comment #2) > And perhaps more importantly the mov can even be hoisted outside of a loop. That won't be happening right away, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112304#c4 where cinc has the same issue. In this case it is very similar in that we don't pull the constant from the and (rather than add) inside LIM. Basically we don't have an early "combine" to even generate the and/not pattern, forwprop could but I Have not looked into why it does not and then we could do a split afterwards and LIM might be able to pull it out. I will definitely look into that but that will step 2 of this and the other issue.
[Bug c++/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 --- Comment #4 from Hongyu Wang --- Created attachment 58211 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58211&action=edit A patch Hi Rainer, Could you try the attachment and see if the error was solved? I tested with cross-compiled solaris gcc but it has some error on varasm with 64bit so I'm not sure it can pass all 32/64bit test.
[Bug libstdc++/115098] std::vector::iterator::reference is default-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098 --- Comment #1 from 康桓瑋 --- std::bitset has similar issues: #include std::bitset<1> bitset; typename std::bitset<1>::reference bit_ref(bitset, 0); // well-formed in libstdc++ https://godbolt.org/z/T4qvv8TcG
[Bug target/107563] __builtin_shufflevector fails to pshufd instructions under default x86_64 compilation toggle which is the sse2 one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107563 --- Comment #11 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:a71f90c5a7ae2942083921033cb23dcd63e70525 commit r15-499-ga71f90c5a7ae2942083921033cb23dcd63e70525 Author: Levy Hsu Date: Thu May 9 16:50:56 2024 +0800 x86: Add 3-instruction subroutine vector shift for V16QI in ix86_expand_vec_perm_const_1 [PR107563] Hi All We've introduced a new subroutine in ix86_expand_vec_perm_const_1 to optimize vector shifting for the V16QI type on x86. This patch uses a three-instruction sequence psrlw, psllw, and por to handle specific vector shuffle operations more efficiently. The change aims to improve assembly code generation for configurations supporting SSE2. Bootstrapped and tested on x86_64-linux-gnu, OK for trunk? Best Levy gcc/ChangeLog: PR target/107563 * config/i386/i386-expand.cc (expand_vec_perm_psrlw_psllw_por): New subroutine. (ix86_expand_vec_perm_const_1): Call expand_vec_perm_psrlw_psllw_por. gcc/testsuite/ChangeLog: PR target/107563 * g++.target/i386/pr107563-a.C: New test. * g++.target/i386/pr107563-b.C: New test.
[Bug libstdc++/115099] New: compilation error: format thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115099
Bug ID: 115099
Summary: compilation error: format thread::id
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: faithandbrave at gmail dot com
Target Milestone: ---
#include
#include
#include
int main()
{
std::cout << __cpp_lib_formatters << std::endl;
std::cout << std::format("{}", std::this_thread::get_id()) << std::endl;
std::cout << std::format("{: >30}", std::this_thread::get_id()) <<
std::endl;
}
outputs:
In file included from prog.cc:3:
/opt/wandbox/gcc-head/include/c++/15.0.0/thread: In instantiation of 'typename
std::basic_format_context<_Out, _CharT>::iterator
std::formatter::format(std::thread::id,
std::basic_format_context<_Out, _CharT>&) const [with _Out =
std::__format::_Sink_iter; _CharT = char; typename
std::basic_format_context<_Out, _CharT>::iterator =
std::basic_format_context, char>::iterator]':
/opt/wandbox/gcc-head/include/c++/15.0.0/format:3247:40: required from
'static void
std::basic_format_arg<_Context>::handle::_S_format(std::basic_format_parse_context&, _Context&, const void*) [with _Tq = const
std::thread::id; _Context =
std::basic_format_context, char>; typename
_Context::char_type = char]'
3247 | __format_ctx.advance_to(__f.format(__val, __format_ctx));
| ~~^
/opt/wandbox/gcc-head/include/c++/15.0.0/format:3255:11: required from
'std::basic_format_arg<_Context>::handle::handle(_Tp&) [with _Tp =
std::thread::id; _Context =
std::basic_format_context, char>]'
3255 | auto __func = _S_format<__maybe_const_t<_Tp>>;
| ^~
/opt/wandbox/gcc-head/include/c++/15.0.0/format:3486:13: required from
'std::basic_format_arg<_Context>::basic_format_arg(_Tp&) [with _Tp =
std::thread::id; _Context =
std::basic_format_context, char>]'
3486 | _M_set(static_cast<_Td>(__v));
|^
/opt/wandbox/gcc-head/include/c++/15.0.0/format:3743:31: required from
'static std::__format::_Arg_store<_Context, _Args>::_Element_t
std::__format::_Arg_store<_Context, _Args>::_S_make_elt(_Tp&) [with _Tp =
std::thread::id; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}; _Element_t =
std::__format::_Arg_store,
char>,
std::basic_format_arg,
char> >::handle>::_Element_t]'
3743 | basic_format_arg<_Context> __arg(__v);
| ^
/opt/wandbox/gcc-head/include/c++/15.0.0/format:3754:23: required from
'std::__format::_Arg_store<_Context, _Args>::_Arg_store(_Tp& ...) [with _Tp =
{std::thread::id}; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}]'
3754 | : _M_args{_S_make_elt(__a)...}
| ~~~^
/opt/wandbox/gcc-head/include/c++/15.0.0/format:3804:14: required from 'auto
std::make_format_args(_Args& ...) [with _Context =
basic_format_context<__format::_Sink_iter, char>; _Args = {thread::id}]'
3804 | return _Store(__fmt_args...);
| ^
/opt/wandbox/gcc-head/include/c++/15.0.0/format:4291:61: required from
'std::string std::format(format_string<_Args ...>, _Args&& ...) [with _Args =
{thread::id}; string = __cxx11::basic_string; format_string<_Args ...> =
basic_format_string]'
4291 | { return std::vformat(__fmt.get(),
std::make_format_args(__args...)); }
|~^~~
prog.cc:8:29: required from here
8 | std::cout << std::format("{}", std::this_thread::get_id()) <<
std::endl;
| ~~~^~
/opt/wandbox/gcc-head/include/c++/15.0.0/thread:334:44: error:
'std::__cxx11::basic_ostringstream __os' has incomplete type
334 | std::basic_ostringstream<_CharT> __os;
|^~~~
It seems missing include at .
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #18 from chenglulu --- (In reply to Xi Ruoyao from comment #17) > Strangely PR114074 is a wrong-code (instead of missed-optimization) and > reverting its fix seems improving performance for other targets... This is very strange. I tried turning off reg_reg addressing on the basis of r14-9540, and the performance was not much different from r14-9539. But unfortunately I still don’t know why
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Xi Ruoyao changed: What|Removed |Added Keywords|needs-bisection |missed-optimization --- Comment #17 from Xi Ruoyao --- Strangely PR114074 is a wrong-code (instead of missed-optimization) and reverting its fix seems improving performance for other targets...
[Bug libstdc++/115098] New: std::vector::iterator::reference is default-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098 Bug ID: 115098 Summary: std::vector::iterator::reference is default-constructible Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- ..which shouldn't because [vector.bool.pspc] specifies that its default constructor is private. #include typename std::vector::iterator::reference bit_ref; https://godbolt.org/z/WPxqWTjMY
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994 --- Comment #6 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c6cc6d4741a880109c4e0e64d5a189687fb526f6 commit r15-498-gc6cc6d4741a880109c4e0e64d5a189687fb526f6 Author: Patrick Palka Date: Tue May 14 22:55:16 2024 -0400 c++: lvalueness of non-dependent assignment expr [PR114994] r14-4111-g6e92a6a2a72d3b made us check non-dependent simple assignment expressions ahead of time and give them a type, as was already done for compound assignments. Unlike for compound assignments however, if a simple assignment resolves to an operator overload we represent it as a (typed) MODOP_EXPR instead of a CALL_EXPR to the selected overload. (I reckoned this was at worst a pessimization -- we'll just have to repeat overload resolution at instantiatiation time.) But this turns out to break the below testcase ultimately because MODOP_EXPR (of non-reference type) is always treated as an lvalue according to lvalue_kind, which is incorrect for the MODOP_EXPR representing x=42. We can fix this by representing such class assignment expressions as CALL_EXPRs as well, but this turns out to require some tweaking of our -Wparentheses warning logic and may introduce other fallout making it unsuitable for backporting. So this patch instead fixes lvalue_kind to consider the type of a MODOP_EXPR representing a class assignment. PR c++/114994 gcc/cp/ChangeLog: * tree.cc (lvalue_kind) : For a class assignment, consider the result type. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent32.C: New test. Reviewed-by: Jason Merrill
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #16 from chenglulu --- The performance degradation on LoongArch is caused by one commit： commit e0e9499aeffdaca88f0f29334384aa5f710a81a4 (HEAD -> trunk) Author: Richard Biener Date: Tue Mar 19 12:24:08 2024 +0100 tree-optimization/114151 - revert PR114074 fix The following reverts the chrec_fold_multiply fix and only keeps handling of constant overflow which keeps the original testcase fixed. A better solution might involve ranger improvements or tracking of assumptions during SCEV analysis similar to what niter analysis does. PR tree-optimization/114151 PR tree-optimization/114269 PR tree-optimization/114322 PR tree-optimization/114074 * tree-chrec.cc (chrec_fold_multiply): Restrict the use of unsigned arithmetic when actual overflow on constant operands is observed. * gcc.dg/pr68317.c: Revert last change. The scores before and after this patch are: （-g -Ofast -march=la464） r14-9539: 12.3 r14-9540: 9.26
[Bug c/115097] New: Strange suboptimal codegen specifically at -O2 when copying struct type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115097
Bug ID: 115097
Summary: Strange suboptimal codegen specifically at -O2 when
copying struct type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/G7qG4vvWb (C++ version)
// https://godbolt.org/z/fT793cznT (C version)
struct A { int a; short b; };
A test1(A& a) { return a; }
A test2(A&& a) { return a; }
A test3(const A& a) { return a; }
A test4(const A&& a) { return a; }
At -O1, they all have the same perfect codegen:
test2(A&&):
mov rax, QWORD PTR [rdi]
ret
At -O2, all-but-one of them have weird suboptimal (but correct) codegen:
test2(A&&):
movzx edx, WORD PTR [rdi+4]
mov eax, DWORD PTR [rdi]
sal rdx, 32
or rax, rdx
ret
What's really weird is that it really is "all but one of them." The lexically
first function will have good codegen, and then the subsequent ones will have
the suboptimal codegen. You can comment out the good one and watch GCC pick
another one to make good. You can reorder the definitions and see GCC's
decision of which one to optimize will change.
This behavior dates all the way back to GCC 5. In GCC 4.9.4, -O2 didn't have
this weird behavior; all four functions would just be optimal all the time.
The same symptom reproduces on x86-64, ARM64, and RISC-V (32 *and* 64). The
RISC-V result seems to indicate it's not specifically limited to 64-bit.
It also reproduces in C, with pointers instead of references.
It seems to have something to do with the signature of the enclosing function,
which is super weird: https://godbolt.org/z/KPac7bvTM
[Bug analyzer/115089] -Wanalyzer-use-of-uninitialized-value false negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115089
--- Comment #3 from David Malcolm ---
FWIW, adding -fno-analyzer-state-merge makes it find the issue; see
https://godbolt.org/z/Ecfe9oqjv
: In function 'main':
:16:16: warning: use of uninitialized value 'x' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
16 | return x; // maybe uninitialized use
|^
'main': events 1-4
|
| 11 | main(void)
| | ^~~~
| | |
| | (1) entry to 'main'
| 12 | {
| 13 | int x;
| | ~
| | |
| | (2) region created on stack here
| | (3) capacity: 4 bytes
| 14 |
| 15 | g(&x);
| | ~
| | |
| | (4) calling 'g' from 'main'
|
+--> 'g': events 5-7
|
|4 | g(int *x)
| | ^
| | |
| | (5) entry to 'g'
|5 | {
|6 | if (arc4random() % 2)
| |~
| ||
| |(6) following 'false' branch...
|7 | *x = 42;
|8 | }
| | ~
| | |
| | (7) ...to here
|
<--+
|
'main': events 8-9
|
| 15 | g(&x);
| | ^
| | |
| | (8) returning to 'main' from 'g'
| 16 | return x; // maybe uninitialized use
| |~
| ||
| |(9) use of uninitialized value 'x' here
|
Compiler returned: 0
Looks like we might be a bit overzealous about merging states with initialized
vs uninitialized values for variables.
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545 --- Comment #6 from AK --- > We can use memchr to find a char in a range of signed char, or even to find > an int in a range of signed char, as long as we're careful about values. +1, this approach should fix the bug i reported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #5 from AK --- > I think we're going to remove the manual loop unrolling in __find_if for GCC > 15, which should allow the compiler to optimize it better, potentially > auto-vectorizing. That might make memchr less advantageous, but I think it's > worth doing anyway. And even for code-size flags (-Os) memchr still gives best of both worlds as auto-vectorizing increases the size.
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545 --- Comment #4 from Georg Sauthoff --- Sam, thank you for the hint and surfacing it again. (In reply to Jonathan Wakely from comment #2) [..] > I would prefer to do simply: [..] Yes, please go ahead with your approach. > I think we're going to remove the manual loop unrolling in __find_if for GCC > 15, which should allow the compiler to optimize it better, potentially > auto-vectorizing. That might make memchr less advantageous, but I think it's > worth doing anyway. This is great news!
[Bug middle-end/115091] Support value speculation in frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|c++ |middle-end
[Bug c++/105760] [11/12/13/14/15 Regression] ICE: in build_function_type, at tree.cc:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0003e469d4664397b65080a66ad7d6557bd7ffce
commit r15-495-g0003e469d4664397b65080a66ad7d6557bd7ffce
Author: Simon Martin
Date: Mon May 6 15:20:10 2024 +0200
c++: ICE in build_deduction_guide for invalid template [PR105760]
We currently ICE upon the following invalid snippet because we fail to
properly handle tsubst_arg_types returning error_mark_node in
build_deduction_guide.
== cut ==
template
struct A { A(Ts...); };
A a;
== cut ==
This patch fixes this, and has been successfully tested on
x86_64-pc-linux-gnu.
PR c++/105760
gcc/cp/ChangeLog:
* pt.cc (build_deduction_guide): Check for error_mark_node
result from tsubst_arg_types.
gcc/testsuite/ChangeLog:
* g++.dg/parse/error66.C: New test.
[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 --- Comment #12 from Andrew Pinski --- *** Bug 115092 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
--- Comment #3 from Andrew Pinski ---
Trying 15 -> 20:
15: {r105:SI=sign_extract(r101:SI,0x1,0);clobber flags:CC;}
REG_UNUSED flags:CC
20: flags:CCGC=cmp(r105:SI,0x)
REG_DEAD r105:SI
Successfully matched this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (reg/v:SI 101 [ gD.2776 ])
(const_int 1 [0x1])
(const_int 0 [0]))
(const_int 0 [0])))
Successfully matched this instruction:
(set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 25)
(pc)))
allowing combination of insns 15 and 20
original costs 4 + 4 = 20
replacement cost 16
deferring deletion of insn with uid = 15.
modifying other_insn21: pc={(flags:CCZ!=0)?L25:pc}
REG_DEAD flags:CCGC
deferring rescan insn with uid = 21.
modifying insn i320: flags:CCZ=cmp(zero_extract(r101:SI,0x1,0),0)
deferring rescan insn with uid = 20.
We go from `-(r101&1) < -1` into `(r101 & 1) != 0` which is totally wrong.
So yes, it is a dup.
*** This bug has been marked as a duplicate of bug 114902 ***
[Bug c/115096] -fstrict-aliasing miscompilation or missing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115096 --- Comment #2 from Andrew Pinski --- > the warning described in that bug is not occurring. That is because in that case it had literally `(unsigned char**)&var` while in this case it is spread across function calls and that would require a lot of work to get the warning happening. Note there are a few open bug reports specifically asking for a runtime catching of this too; but that is also hard as you need to record the aliasing set of when stores and loads happen.
[Bug c/115096] -fstrict-aliasing miscompilation or missing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115096
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
So this is not a miscompiling as the pointer types "char*" and "unsigned char*"
are two distant pointer types and are not considered to be aliasing and you are
not accessing the pointer via a character type (GCC has an exception for void*
types though which you could do the store in and get the correct result).
There is no warning here because the casting between pointer types is not the
issue but rather the access.
Since test is passed a pointer to a "char*" type and only in test you do the
cast to a pointer to a "unsigned char*" type. a warning in this case would 100%
require full path analysis of the code.
Note you could rewrite the code to be:
```
static int helper(void **cursor)
{
// first character ('a') is OK
if (*(unsigned char*)*cursor > 'z')
{
return -11;
}
*cursor = ((unsigned char*)*cursor) + 1;
// second character ('b') is OK
if (*(unsigned char*)*cursor > 'z')
{
return -12;
}
// increment to third character ('.')...
*cursor = ((unsigned char*)*cursor) + 1;
return 0;
}
```
And it would work correctly as I mentioned GCC has an exception on the `void*`
type which is allowed to alias all other pointer types. (Note I am not 100%
sure if C standard says that is still undefined code or not but GCC makes it as
such).
[Bug c++/114935] [14/15 regression] Miscompilation of initializer_list in presence of exceptions since r14-1705-g2764335bd336f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114935 --- Comment #5 from Jason Merrill --- Created attachment 58210 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58210&action=edit attempt to reduce redundancy A failed attempt to avoid duplicate array cleanups in this case.
[Bug c/115096] New: -fstrict-aliasing miscompilation or missing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115096
Bug ID: 115096
Summary: -fstrict-aliasing miscompilation or missing warning
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Philip.Taff at itron dot com
Target Milestone: ---
Created attachment 58209
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58209&action=edit
minimal test case
I'm not sure whether this code is a violation of strict-aliasing, in which case
a warning would be great, or it is valid, in which case it is being
miscompiled, removing some of the increments. According to Bug #29901 a similar
cast does break strict-aliasing rules, but the warning described in that bug is
not occurring.
Built with:
$ gcc -O1 -fstrict-aliasing -Wall -Wextra test.c
No compiler warnings or errors.
Executed with: ("ab." is the test data)
$ ./a.out ab.
GCC/system information:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04)
COLLECT_GCC_OPTIONS='-O1' '-fstrict-aliasing' '-Wall' '-Wextra' '-v'
'-save-temps' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/12/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
test.c -mtune=generic -march=x86-64 -Wall -Wextra -fstrict-aliasing -O1
-fpch-preprocess -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat-security -fstack-clash-protection -fcf-protection -o a-test.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/12/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/12/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O1' '-fstrict-aliasing' '-Wall' '-Wextra' '-v'
'-save-temps' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/12/cc1 -fpreprocessed a-test.i -quiet -dumpdir a-
-dumpbase test.c -dumpbase-ext .c -mtune=generic -march=x86-64 -O1 -Wall
-Wextra -version -fstrict-aliasing -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat-security -fstack-clash-protection
-fcf-protection -o a-test.s
GNU C17 (Ubuntu 12.3.0-1ubuntu1~22.04) version 12.3.0 (x86_64-linux-gnu)
compiled by GNU C version 12.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Ubuntu 12.3.0-1ubuntu1~22.04) version 12.3.0 (x86_64-linux-gnu)
compiled by GNU C version 12.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d93534411cccf908c6f3926ba41cb359
COLLECT_GCC_OPTIONS='-O1' '-fstrict-aliasing' '-Wall' '-Wextra' '-v'
'-save-temps' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
as -v --64 -o a-test.o a-test.s
GNU assembler version 2.38 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.38
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/us
[Bug target/115094] x86_64-w64-mingw32 multilib overrides libraries for 64 and 32 since they both copy to bin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115094 --- Comment #1 from cqwrteur --- https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651670.html
[Bug middle-end/115095] [missed optimization] fixed processing on constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115095 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|c |middle-end
[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 --- Comment #11 from Segher Boessenkool --- So, is there a simplified testcase that *actually* shows any *actual* problem?
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||clange001 at gmail dot com --- Comment #15 from anlauf at gcc dot gnu.org --- *** Bug 106317 has been marked as a duplicate of this bug. ***
[Bug fortran/106317] deferred-length character array pointer in derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106317 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #1) > Confirmed to fail on 13-branch at r13-7813, but working at r13-8592. > > Also 14-mainline is ok, so must have been fixed there and backported, > possibly as r13-7986. Indeed a duplicate of 67740. Thus fixed in 13.3 and later. *** This bug has been marked as a duplicate of bug 67740 ***
[Bug c/115095] New: [missed optimization] fixed processing on constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115095
Bug ID: 115095
Summary: [missed optimization] fixed processing on constant
string
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
Created attachment 58208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58208&action=edit
source code of https://godbolt.org/z/Meqvbj8GG
I've found clang was able to compute the result of hashing a constant string at
compile time. I would have hope GCC -O3 would be able to optimize such
computation as well:
static inline unsigned int hash(unsigned int h, const char *s)
{
while (*s) {
h += *s;
h *= *s++;
}
return h;
}
#define LOCATION() hash(hash(0, __FILE__), __func__)
unsigned int location(void)
{
return LOCATION();
}
is translated by clang to
location:
movl$1418535820, %eax
retq
but not by GCC, which doesn't compute the value of LOCATION() at compile time
but emit code that compute the value at runtime.
At first, I thought it was an issue with handling __FILE__ or __func__, but
trying with other string constants, GCC is not computing the value at compile
time.
See https://godbolt.org/z/Meqvbj8GG
[Bug target/115094] New: x86_64-w64-mingw32 multilib overrides libraries for 64 and 32 since they both copy to bin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115094 Bug ID: 115094 Summary: x86_64-w64-mingw32 multilib overrides libraries for 64 and 32 since they both copy to bin. Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 58207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58207&action=edit patch Please accept my patch to fix it. This has been extremely annoying for me for many years now.
[Bug target/115093] New: RISC-V Vector ICE in extract_insn: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115093
Bug ID: 115093
Summary: RISC-V Vector ICE in extract_insn: unrecognizable insn
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremy.bennett at embecosm dot com
Target Milestone: ---
Bug found in SPEC CPU 2017 625.x264_s.
Reproducer (test.c):
int a;
void
c (char d[], char h[][0], char i[][4][4])
{
for (int b; b < 2; b++)
for (int e = 0; e < 4; e++)
for (int f = 0; f < 4; f++)
{
int g = e - 1;
if (d[e] || d[g])
i[b][e][f] = 2;
else if (h[0][g] || a)
i[b][e][f] = 0;
}
}
Compile with:
riscv64-unknown-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -c -Ofast test.c
Output:
test.c: In function 'c':
test.c:15:1: error: unrecognizable insn:
15 | }
| ^
(insn 1200 0 0 (parallel [
(set (reg:RVVMF4QI 749 [orig:240 vect__217.22 ] [240])
(unspec:RVVMF4QI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF))
(clobber (scratch:DI))
]) -1
(nil))
during RTL pass: reload
test.c:15:1: internal compiler error: in extract_insn, at recog.cc:2812
0xa95819 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/jeremy/gittrees/rise-qemu/gcc/gcc/rtl-error.cc:108
0xa9583b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/jeremy/gittrees/rise-qemu/gcc/gcc/rtl-error.cc:116
0xa94117 extract_insn(rtx_insn*)
/home/jeremy/gittrees/rise-qemu/gcc/gcc/recog.cc:2812
0x10db392 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
/home/jeremy/gittrees/rise-qemu/gcc/gcc/ira.cc:5381
0x111df4f remove_insn_scratches
/home/jeremy/gittrees/rise-qemu/gcc/gcc/lra.cc:2154
0x111df4f lra_emit_move(rtx_def*, rtx_def*)
/home/jeremy/gittrees/rise-qemu/gcc/gcc/lra.cc:513
0x112c143 match_reload
/home/jeremy/gittrees/rise-qemu/gcc/gcc/lra-constraints.cc:1184
0x11383a4 curr_insn_transform
/home/jeremy/gittrees/rise-qemu/gcc/gcc/lra-constraints.cc:4778
0x1139c8b lra_constraints(bool)
/home/jeremy/gittrees/rise-qemu/gcc/gcc/lra-constraints.cc:5481
0x1120a52 lra(_IO_FILE*, int)
/home/jeremy/gittrees/rise-qemu/gcc/gcc/lra.cc:2442
0x10d673f do_reload
/home/jeremy/gittrees/rise-qemu/gcc/gcc/ira.cc:5973
0x10d673f execute
/home/jeremy/gittrees/rise-qemu/gcc/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/92539] [11/12/13/14/15 Regression] -Warray-bounds false positive with -O3 (loop unroll?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #12 from Jeffrey A. Law ---
Just to save it for the future. I think this patch I've got lying around
implements the idea in c#6.
diff --git a/gcc/vr-values.cc b/gcc/vr-values.cc
index 3ccb77d28be..cc753e79a8a 100644
--- a/gcc/vr-values.cc
+++ b/gcc/vr-values.cc
@@ -325,6 +325,34 @@ simplify_using_ranges::fold_cond_with_ops (enum tree_code
code,
if (res == range_false (type))
return boolean_false_node;
}
+
+ /* If we're comparing pointers and one of the pointers is
+ not a valid pointer (say &MEM [(void *)"aa" + 4B)
+ return true for EQ and false for NE. */
+ if ((code == EQ_EXPR || code == NE_EXPR)
+ && POINTER_TYPE_P (type)
+ && TREE_CODE (op1) == ADDR_EXPR
+ && TREE_CODE (TREE_OPERAND (op1, 0)) == MEM_REF)
+{
+ tree mem_ref = TREE_OPERAND (op1, 0);
+ if (TREE_CODE (TREE_OPERAND (mem_ref, 0)) == ADDR_EXPR)
+ {
+ tree addr_expr = TREE_OPERAND (mem_ref, 0);
+ if (TREE_CODE (TREE_OPERAND (addr_expr, 0)) == STRING_CST)
+ {
+ tree string = TREE_OPERAND (addr_expr, 0);
+
+ if (TREE_CODE (TREE_OPERAND (mem_ref, 1)) == INTEGER_CST)
+ {
+ HOST_WIDE_INT len = TREE_STRING_LENGTH (string);
+ HOST_WIDE_INT offset = tree_to_uhwi (TREE_OPERAND (mem_ref,
1));
+ if (offset > len)
+ return code == EQ_EXPR ? boolean_false_node :
boolean_true_node;
+ }
+ }
+ }
+}
+
return NULL;
}
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 Andrew Pinski changed: What|Removed |Added Depends on||114902 --- Comment #2 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > Started with r14-4810-ge28869670c9879fe7c67caf6cc11af202509ef78 Then I am 99% sure this is a dup of bug 114902. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 [Bug 114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013 --- Comment #7 from GCC Commits --- The master branch has been updated by Dimitar Dimitrov : https://gcc.gnu.org/g:fc559584fa5b1e101a4520e88a936246458d5a5d commit r15-493-gfc559584fa5b1e101a4520e88a936246458d5a5d Author: Dimitar Dimitrov Date: Mon May 13 19:24:14 2024 +0300 pru: Implement TARGET_CLASS_LIKELY_SPILLED_P to fix PR115013 Commit r15-436-g44e7855e did not fix PR115013 for PRU because SMALL_REGISTER_CLASS_P is not returning an accurate value for the PRU backend. Word mode for PRU backend is defined as 8-bit, yet all ALU operations are preferred in 32-bit mode. Thus checking whether a register class contains a single word_mode register would not classify the actually single SImode register classes as small. This affected the multiplication source and destination register classes. Fix by implementing TARGET_CLASS_LIKELY_SPILLED_P to treat all register classes with SImode or smaller size as likely spilled. This in turn corrects the behaviour of SMALL_REGISTER_CLASS_P for PRU. PR rtl-optimization/115013 gcc/ChangeLog: * config/pru/pru.cc (pru_class_likely_spilled_p): Implement to mark classes containing one SImode register as likely spilled. (TARGET_CLASS_LIKELY_SPILLED_P): Define. Signed-off-by: Dimitar Dimitrov
[Bug tree-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2024-05-14 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org Target Milestone|--- |14.2 Summary|wrong code at -O1 with |[14/15 Regression] wrong |"-fgcse -ftree-pre |code at -O1 with "-fgcse |-fno-tree-dominator-opts|-ftree-pre |-fno-tree-fre |-fno-tree-dominator-opts |-fno-guess-branch-probabili |-fno-tree-fre |ty" on x86_64-linux-gnu |-fno-guess-branch-probabili ||ty" on x86_64-linux-gnu ||since r14-4810 Ever confirmed|0 |1 Priority|P3 |P2 --- Comment #1 from Jakub Jelinek --- Started with r14-4810-ge28869670c9879fe7c67caf6cc11af202509ef78
[Bug tree-optimization/115092] New: wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092
Bug ID: 115092
Summary: wrong code at -O1 with "-fgcse -ftree-pre
-fno-tree-dominator-opts -fno-tree-fre
-fno-guess-branch-probability" on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it only reproduces with 14.1 and trunk,
but not 13.* and earlier. It needs several flags, but hope it's still of
interest.
Compiler Explorer: https://godbolt.org/z/qTc3e6s7f
[521] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240514 (experimental) (GCC)
[522] %
[522] % gcctk -O1 small.c; ./a.out
[523] %
[523] % gcctk -O1 -fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre
-fno-guess-branch-probability small.c
[524] % ./a.out
Floating point exception
[525] %
[525] % cat small.c
int a, b, c = 1, d, e;
int main() {
int f, g = a;
b = -2;
f = -(1 >> ((c && b) & ~a));
if (f <= b)
d = g / e;
return 0;
}
[Bug c++/115091] New: Support value speculation in frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091 Bug ID: 115091 Summary: Support value speculation in frontend Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org Target Milestone: --- This blog post describes an interesting optimization technique for memory access. https://mazzo.li/posts/value-speculation.html A linked list walk is often be limited by the latency of the L1 cache. When the program can guess the next address (e.g. because the nodes are often allocated sequentially in memory) it is possible to use construct like if (node->next == node + 1) node++; else node = node->next; and rely on the CPU speculating the fast case. However this often runs into problems with the compiler, e.g. for next = node->next; node++; if (node != next) node = next; is often optimized away. While this can be worked around with some code restructuring, this may not always work for more complex cases. I wonder if it makes sense to formally support this technique with a "nocse" or similar variable attribute that is honored by optimization passes.
[Bug tree-optimization/99954] [8 Regression] Copy loop over array of unions at -O3 generates memcpy instead of memmove, resulting in incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99954 --- Comment #11 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c290e6a0b7a9de5692963affc6627a4af7dc2411 commit r15-491-gc290e6a0b7a9de5692963affc6627a4af7dc2411 Author: Richard Biener Date: Tue May 14 11:13:51 2024 +0200 tree-optimization/99954 - redo loop distribution memcpy recognition fix The following revisits the fix for PR99954 which was observed as causing missed memcpy recognition and instead using memmove for non-aliasing copies. While the original fix mitigated bogus recognition of memcpy the root cause was not properly identified. The root cause is dr_analyze_indices "failing" to handle union references and leaving the DRs indices in a state that's not correctly handled by dr_may_alias. The following mitigates this there appropriately, restoring memcpy recognition for non-aliasing copies. This makes us run into a latent issue in ptr_deref_may_alias_decl_p when the pointer is something like &MEM[0].a in which case we fail to handle non-SSA name pointers. Add code similar to what we have in ptr_derefs_may_alias_p. PR tree-optimization/99954 * tree-data-ref.cc (dr_may_alias_p): For bases that are not completely analyzed fall back to TBAA and points-to. * tree-loop-distribution.cc (loop_distribution::classify_builtin_ldst): When there is no dependence again classify as memcpy. * tree-ssa-alias.cc (ptr_deref_may_alias_decl_p): Verify the pointer is an SSA name. * gcc.dg/tree-ssa/ldist-40.c: New testcase.
[Bug tree-optimization/109071] -Warray-bounds false positive warnings due to code duplication from jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071 --- Comment #11 from qinzhao at gcc dot gnu.org --- please see discussion at: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651482.html A summary of the discussion: 1. The current warning is correct, which catches a potential source code error that should be fixed in the source code level; 2. The best way to fix the source code level error is: make the routine "warn" a non-return function, and use the attribute __noreturn __ to mark it. 3. Although the warning is correct in theory, the warning message itself is confusing to the end-user since there is information that cannot be connected to the source code directly. 4. It will be a nice improvement to add more information in the warning message to report the location info on where such index value come from, for example: warning: array index always above array bounds events 1: | 3 | if (index >= 4) | (1) when index >= 4 then the end-user will know how such out-of-bound access come from. We also need to clarify in the documentation part on how to fix such warnings in the source code level. 5. In order to implement the above 4, we might need to record the location information to somewhere (in STMT or in Block) during the code duplication phase. more details need to be worked out on this.
[Bug tree-optimization/114301] gimple_can_duplicate_bb_p check for returns twice can be moved to the check of the last statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114301 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/651 ||643.html Keywords||patch --- Comment #2 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651643.html
[Bug tree-optimization/114767] gfortran AVX2 complex multiplication by (0d0,1d0) suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767 --- Comment #7 from mjr19 at cam dot ac.uk --- Another manifestation of this issue in GCC 13.1 and 14.1 is that the loop do i=1,n c(i)=a(i)*c(i)*(0d0,1d0) enddo takes about twice as long to run as do i=1,n c(i)=a(i)*(0d0,1d0)*c(i) enddo when compiled -Ofast -mavx2. In the second case the compiler manages to merge its unnecessary desire to form separate vectors of real and imaginary components to perform the sign flips on multiplying by i, with its much more reasonable desire to form such vectors for the general complex-complex multiplication. One might also argue that, as the above expressions are mathematically identical, at -Ofast the compiler ought to chose the faster anyway.
[Bug tree-optimization/114635] OpenMP reductions fail dependency analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635 --- Comment #19 from Richard Sandiford --- (In reply to Richard Biener from comment #14) > Usually targets do have a limit on the actual length but I see > constant_upper_bound_with_limit doesn't query such. But it would > be a more appropriate way to say there might be an actual target limit here? The discussion has moved on, but FWIW: this was a deliberate choice. The thinking at the time was that VLA code should be truly “agnostic” and not hard-code an upper limit. Hard-coding a limit would be hard-coding an assumption that the architectural maximum would never increase in future. (The main counterargument was that any uses of the .B form of TBL would break down for >256-byte vectors. We hardly use such TBLs for autovec though, and could easily choose not to use them at all.) That decision is 8 or 9 years old at this point, so it might seem overly dogmatic now. Even so, I think we should have a strong reason to change tack. It shouldn't just be about trying to avoid poly_ints :)
[Bug c++/115079] unexpected error with partial specialization of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115079 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-14 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org
[Bug c++/115090] ICE in gimplify_expr, at gimplify.cc:18907 (deduced this)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115090 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2024-05-14 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Started with r14-7075: commit fbc980d85149409ce62c22f48d3693113803929e Author: waffl3x Date: Sun Jan 7 00:01:48 2024 + c++: P0847R7 (deducing this) - initial functionality. [PR102609]
[Bug ipa/113907] [11/12/13/14/15 regression] ICU miscompiled on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #78 from GCC Commits --- The releases/gcc-13 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:1db45e83021a8a87f41e22053910fcce6e8e2c2c commit r13-8774-g1db45e83021a8a87f41e22053910fcce6e8e2c2c Author: Martin Jambor Date: Tue May 14 17:01:21 2024 +0200 ipa: Compare jump functions in ICF (PR 113907) This is a manual backport of r14-9840-g1162861439fd3c from master. Manual because the bits and value range representation in jump functions have changes during the gcc 14 development cycle. In PR 113907 comment #58, Honza found a case where ICF thinks bodies of functions are equivalent but becaise of difference in aliases in a memory access, different aggregate jump functions are associated with supposedly equivalent call statements. This patch adds a way to compare jump functions and plugs it into ICF to avoid the issue. gcc/ChangeLog: 2024-05-14 Martin Jambor PR ipa/113907 * ipa-prop.h (ipa_jump_functions_equivalent_p): Declare. (values_equal_for_ipcp_p): Likewise. * ipa-prop.cc (ipa_agg_pass_through_jf_equivalent_p): New function. (ipa_agg_jump_functions_equivalent_p): Likewise. (ipa_jump_functions_equivalent_p): Likewise. * ipa-cp.cc (values_equal_for_ipcp_p): Make function public. * ipa-icf-gimple.cc: Include alloc-pool.h, symbol-summary.h, sreal.h, ipa-cp.h and ipa-prop.h. (func_checker::compare_gimple_call): Comapre jump functions. gcc/testsuite/ChangeLog: 2024-05-10 Martin Jambor PR ipa/113907 * gcc.dg/lto/pr113907_0.c: New. * gcc.dg/lto/pr113907_1.c: Likewise. * gcc.dg/lto/pr113907_2.c: Likewise.
[Bug analyzer/115089] -Wanalyzer-use-of-uninitialized-value false negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115089 --- Comment #2 from Alejandro Colomar --- I found that Clang's analyzer finds this bug, so I'm less concerned that GCC can't find it. Feel free to ignore it if it's too hard to fix. ;) $ clang-tidy ./bug.c Error while trying to load a compilation database: Could not auto-detect compilation database for file "./bug.c" No compilation database found in /home/alx/tmp/analyzer or any parent directory fixed-compilation-database: Error while opening fixed database: No such file or directory json-compilation-database: Error while opening JSON database: No such file or directory Running without flags. 1 warning generated. /home/alx/tmp/analyzer/bug.c:16:2: warning: Undefined or garbage value returned to caller [clang-analyzer-core.uninitialized.UndefReturn] return x; // maybe uninitialized use ^ ~ /home/alx/tmp/analyzer/bug.c:13:2: note: 'x' declared without an initial value int x; ^ /home/alx/tmp/analyzer/bug.c:15:2: note: Calling 'g' g(&x); ^ /home/alx/tmp/analyzer/bug.c:6:6: note: Assuming the condition is false if (arc4random() % 2) ^~~~ /home/alx/tmp/analyzer/bug.c:6:2: note: Taking false branch if (arc4random() % 2) ^ /home/alx/tmp/analyzer/bug.c:8:1: note: Returning without writing to '*x' } ^ /home/alx/tmp/analyzer/bug.c:15:2: note: Returning from 'g' g(&x); ^ /home/alx/tmp/analyzer/bug.c:16:2: note: Undefined or garbage value returned to caller return x; // maybe uninitialized use ^ ~
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||13.2.1 --- Comment #21 from Richard Biener --- yes, it looks suspiciously close to what I'd expect.
[Bug analyzer/107750] [13/14/15 Regression] Many gcc.dg/analyzer/fd-*.c tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107750 --- Comment #9 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:f97d86f897bcf0ffda4d8d2e5b78a160e9ece140 commit r15-486-gf97d86f897bcf0ffda4d8d2e5b78a160e9ece140 Author: Rainer Orth Date: Tue May 14 16:23:14 2024 +0200 testsuite: analyzer: Fix fd-glibc-byte-stream-connection-server.c on Solaris [PR107750] gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c currently FAILs on Solaris: FAIL: gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c:91:3: error: implicit declaration of function 'memset' [-Wimplicit-function-declaration] Solaris has but no declaration of memset. While one can argue that this should be fixed, it's easy enough to just include instead, which is what this patch does. Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu. 2024-05-14 Rainer Orth gcc/testsuite: PR analyzer/107750 * gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c: Include .
[Bug libstdc++/115015] [14/15 Regression] libstdc++ build with '-fno-rtti' is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed for 14.2
[Bug libstdc++/115015] [14/15 Regression] libstdc++ build with '-fno-rtti' is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015 --- Comment #2 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:eefa4c06483f95f5076687ed6aae5c6001731164 commit r14-10208-geefa4c06483f95f5076687ed6aae5c6001731164 Author: Jonathan Wakely Date: Tue May 14 14:32:23 2024 +0100 libstdc++: Guard dynamic_cast use in src/c++23/print.cc [PR115015] Do not use dynamic_cast unconditionally, in case libstdc++ is built with -fno-rtti. libstdc++-v3/ChangeLog: PR libstdc++/115015 * src/c++23/print.cc (__open_terminal(streambuf*)) [!__cpp_rtti]: Do not use dynamic_cast.
[Bug libstdc++/115015] [14/15 Regression] libstdc++ build with '-fno-rtti' is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015 --- Comment #1 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6cc8698244b522ad079675022c9de9e40de85878 commit r15-485-g6cc8698244b522ad079675022c9de9e40de85878 Author: Jonathan Wakely Date: Tue May 14 14:32:23 2024 +0100 libstdc++: Guard dynamic_cast use in src/c++23/print.cc [PR115015] Do not use dynamic_cast unconditionally, in case libstdc++ is built with -fno-rtti. libstdc++-v3/ChangeLog: PR libstdc++/115015 * src/c++23/print.cc (__open_terminal(streambuf*)) [!__cpp_rtti]: Do not use dynamic_cast.
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #20 from Mikael Pettersson --- For gcc-14 this test case was fixed by dc48d1d1d4458773f89f21b2f019f66ddf88f2e5 is the first new commit commit dc48d1d1d4458773f89f21b2f019f66ddf88f2e5 Author: Andrew MacLeod Date: Thu Aug 17 11:13:14 2023 -0400 Fix range-ops operator_addr. Lack of symbolic information prevents op1_range from beig able to draw the same conclusions as fold_range can. PR tree-optimization/111009 gcc/ * range-op.cc (operator_addr_expr::op1_range): Be more restrictive. That commit was backported to gcc-13 in 421311a31a12b96143eb901fde0e020771fe71d4, and that fixed this test case there too. Not sure if this is the proper fix or just makes the issue latent.
[Bug target/115087] dead block not eliminated in SVE intrinsics code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115087 Richard Biener changed: What|Removed |Added Target||aarch64 --- Comment #1 from Richard Biener --- If the intrinsic were pure/const it would have been eliminated. Instead we just eliminated the LHS.
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #11 from David Malcolm --- I've created a wiki page to track this project: https://gcc.gnu.org/wiki/StaticAnalyzer/CPython
[Bug libstdc++/109442] Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442 --- Comment #21 from Jan Hubicka --- This patch attempts to add __builtin_operator_new/delete. So far they are not optimized, which will need to be done by extra flag of BUILT_IN_ code. also the decl.cc code can be refactored to be less of cut&paste and I guess has_builtin hack to return proper value needs to be moved to C++ FE. However the immediate problem I run into is that libstdc++ testuiste fails due to lack of std::nothrow overrides. I wonder how to get that working?
Re: [Bug libstdc++/109442] Dead local copy of std::vector not removed from function
This patch attempts to add __builtin_operator_new/delete. So far they
are not optimized, which will need to be done by extra flag of BUILT_IN_
code. also the decl.cc code can be refactored to be less of cut&paste
and I guess has_builtin hack to return proper value needs to be moved
to C++ FE.
However the immediate problem I run into is that libstdc++ testuiste
fails due to lack of std::nothrow overrides. I wonder how to get that
working?
diff --git a/gcc/c-family/c-lex.cc b/gcc/c-family/c-lex.cc
index ff5ce2bf729..602b097059c 100644
--- a/gcc/c-family/c-lex.cc
+++ b/gcc/c-family/c-lex.cc
@@ -533,6 +533,10 @@ c_common_has_builtin (cpp_reader *pfile)
if (!name)
return 0;
+ if (!strcmp (name, "__builtin_operator_new")
+ || !strcmp (name, "__builtin_operator_delete"))
+return 201802L;
+
return names_builtin_p (name);
}
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 3fc8835154d..90b100ca3dc 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -59,6 +59,7 @@ along with GCC; see the file COPYING3. If not see
#include "omp-general.h"
#include "omp-offload.h" /* For offload_vars. */
#include "opts.h"
+#include "print-tree.h"
#include "langhooks-def.h" /* For lhd_simulate_record_decl */
/* Possible cases of bad specifiers type used by bad_specifiers. */
@@ -5048,13 +5049,27 @@ cxx_init_decl_processing (void)
DECL_IS_MALLOC (opnew) = 1;
DECL_SET_IS_OPERATOR_NEW (opnew, true);
DECL_IS_REPLACEABLE_OPERATOR (opnew) = 1;
+tree builtin_opnew = build_cp_library_fn
(get_identifier("__builtin_operator_new"),
+ NEW_EXPR, newtype, 0);
+DECL_IS_MALLOC (builtin_opnew) = 1;
+DECL_SET_IS_OPERATOR_NEW (builtin_opnew, true);
+DECL_IS_REPLACEABLE_OPERATOR (builtin_opnew) = 1;
+SET_DECL_ASSEMBLER_NAME (builtin_opnew, DECL_ASSEMBLER_NAME (opnew));
+pushdecl (builtin_opnew);
opnew = push_cp_library_fn (VEC_NEW_EXPR, newtype, 0);
DECL_IS_MALLOC (opnew) = 1;
DECL_SET_IS_OPERATOR_NEW (opnew, true);
DECL_IS_REPLACEABLE_OPERATOR (opnew) = 1;
+
tree opdel = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
DECL_SET_IS_OPERATOR_DELETE (opdel, true);
DECL_IS_REPLACEABLE_OPERATOR (opdel) = 1;
+tree builtin_opdel = build_cp_library_fn
(get_identifier("__builtin_operator_delete"),
+ DELETE_EXPR, deltype,
ECF_NOTHROW);
+DECL_SET_IS_OPERATOR_DELETE (builtin_opdel, true);
+DECL_IS_REPLACEABLE_OPERATOR (builtin_opdel) = 1;
+SET_DECL_ASSEMBLER_NAME (builtin_opdel, DECL_ASSEMBLER_NAME (opdel));
+pushdecl (builtin_opdel);
opdel = push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
DECL_SET_IS_OPERATOR_DELETE (opdel, true);
DECL_IS_REPLACEABLE_OPERATOR (opdel) = 1;
@@ -5072,6 +5087,12 @@ cxx_init_decl_processing (void)
opdel = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
DECL_SET_IS_OPERATOR_DELETE (opdel, true);
DECL_IS_REPLACEABLE_OPERATOR (opdel) = 1;
+ builtin_opdel = build_cp_library_fn
(get_identifier("__builtin_operator_delete"),
+DELETE_EXPR, deltype, ECF_NOTHROW);
+ DECL_SET_IS_OPERATOR_DELETE (builtin_opdel, true);
+ DECL_IS_REPLACEABLE_OPERATOR (builtin_opdel) = 1;
+ SET_DECL_ASSEMBLER_NAME (builtin_opdel, DECL_ASSEMBLER_NAME (opdel));
+ pushdecl (builtin_opdel);
opdel = push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
DECL_SET_IS_OPERATOR_DELETE (opdel, true);
DECL_IS_REPLACEABLE_OPERATOR (opdel) = 1;
@@ -5094,6 +5115,13 @@ cxx_init_decl_processing (void)
DECL_IS_MALLOC (opnew) = 1;
DECL_SET_IS_OPERATOR_NEW (opnew, true);
DECL_IS_REPLACEABLE_OPERATOR (opnew) = 1;
+ builtin_opnew = build_cp_library_fn
(get_identifier("__builtin_operator_new"),
+VEC_NEW_EXPR, newtype, 0);
+ DECL_IS_MALLOC (builtin_opnew) = 1;
+ DECL_SET_IS_OPERATOR_NEW (builtin_opnew, true);
+ DECL_IS_REPLACEABLE_OPERATOR (builtin_opnew) = 1;
+ SET_DECL_ASSEMBLER_NAME (builtin_opnew, DECL_ASSEMBLER_NAME (opnew));
+ pushdecl (builtin_opnew);
opnew = push_cp_library_fn (VEC_NEW_EXPR, newtype, 0);
DECL_IS_MALLOC (opnew) = 1;
DECL_SET_IS_OPERATOR_NEW (opnew, true);
@@ -5107,6 +5135,12 @@ cxx_init_decl_processing (void)
opdel = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
DECL_SET_IS_OPERATOR_DELETE (opdel, true);
DECL_IS_REPLACEABLE_OPERATOR (opdel) = 1;
+ builtin_opdel = build_cp_library_fn
(get_identifier("__builtin_operator_delete"),
+DELETE_EXPR, deltype, ECF_NOTHROW);
+ DECL_SET_IS_OPERATOR_DELETE (builtin_opdel, true);
+ DECL_IS_REPLACEABLE_OPERATOR (builtin_opdel) = 1;
+ SET_DECL_ASSEMBLER_NAME (builtin_opdel, DECL_ASSEMBLER_NAME (opdel));
+ push
[Bug c++/115090] ICE in gimplify_expr, at gimplify.cc:18907 (deduced this)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115090
--- Comment #1 from José Cruz Serrallés ---
Pasting MRE here for convenience:
struct Base {
template
constexpr void operator()(this Derived&& der) {
operator()();
}
};
int main() {
Base b;
b();
}
[Bug c++/115090] New: ICE in gimplify_expr, at gimplify.cc:18907 (deduced this)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115090 Bug ID: 115090 Summary: ICE in gimplify_expr, at gimplify.cc:18907 (deduced this) Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jose at serrall dot es Target Milestone: --- Created attachment 58205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58205&action=edit Preprocessed source When porting code to use the new `deduced this` feature, I forgot to switch `operator()` to `obj()` and got an ICE. Note that this happens even if `operator()` takes no additional arguments. Output of gcc --version: gcc-14 (Homebrew GCC 14.1.0) 14.1.0 However, this also happens on online compilers when compiling for x86_64.
[Bug c++/114480] [12/13/14/15 Regression] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #31 from Richard Biener ---
(In reply to Alexander Monakov from comment #21)
> It is possible to reduce gcc_qsort workload by improving the presorted-ness
> of the array, but of course avoiding quadratic behavior would be much better.
>
> With the following change, we go from
>
>261,250,628,954 cycles:u
>533,040,964,437 instructions:u#2.04 insn per cycle
>114,415,857,214 branches:u
>395,327,966 branch-misses:u #0.35% of all branches
>
> to
>
>256,620,517,403 cycles:u
>526,337,243,809 instructions:u#2.05 insn per cycle
>113,447,583,099 branches:u
>383,121,251 branch-misses:u #0.34% of all branches
>
> diff --git a/gcc/tree-into-ssa.cc b/gcc/tree-into-ssa.cc
> index d12a4a97f6..621793f7f4 100644
> --- a/gcc/tree-into-ssa.cc
> +++ b/gcc/tree-into-ssa.cc
> @@ -805,21 +805,22 @@ prune_unused_phi_nodes (bitmap phis, bitmap kills,
> bitmap uses)
> locate the nearest dominating def in logarithmic time by binary
> search.*/
>bitmap_ior (to_remove, kills, phis);
>n_defs = bitmap_count_bits (to_remove);
> + adef = 2 * n_defs + 1;
>defs = XNEWVEC (struct dom_dfsnum, 2 * n_defs + 1);
>defs[0].bb_index = 1;
>defs[0].dfs_num = 0;
> - adef = 1;
> + struct dom_dfsnum *head = defs + 1, *tail = defs + adef;
>EXECUTE_IF_SET_IN_BITMAP (to_remove, 0, i, bi)
> {
>def_bb = BASIC_BLOCK_FOR_FN (cfun, i);
> - defs[adef].bb_index = i;
> - defs[adef].dfs_num = bb_dom_dfs_in (CDI_DOMINATORS, def_bb);
> - defs[adef + 1].bb_index = i;
> - defs[adef + 1].dfs_num = bb_dom_dfs_out (CDI_DOMINATORS, def_bb);
> - adef += 2;
> + head->bb_index = i;
> + head->dfs_num = bb_dom_dfs_in (CDI_DOMINATORS, def_bb);
> + head++, tail--;
> + tail->bb_index = i;
> + tail->dfs_num = bb_dom_dfs_out (CDI_DOMINATORS, def_bb);
> }
> + gcc_assert (head == tail);
>BITMAP_FREE (to_remove);
> - gcc_assert (adef == 2 * n_defs + 1);
>qsort (defs, adef, sizeof (struct dom_dfsnum), cmp_dfsnum);
>gcc_assert (defs[0].bb_index == 1);
Very nice - now that we're back in stage 1 I think this is a good improvement
and should be always a win? Can you test/submit it? I'll pre-approve it
here.
[Bug libstdc++/115015] [14/15 Regression] libstdc++ build with '-fno-rtti' is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015 Jonathan Wakely changed: What|Removed |Added Summary|libstdc++ build with|[14/15 Regression] |'-fno-rtti' is broken |libstdc++ build with ||'-fno-rtti' is broken Keywords||build Target Milestone|--- |14.2
[Bug analyzer/115089] -Wanalyzer-use-of-uninitialized-value false negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115089 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=18501 --- Comment #1 from Andrew Pinski --- See pr 18501 also
[Bug analyzer/115089] New: -Wanalyzer-use-of-uninitialized-value false negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115089
Bug ID: 115089
Summary: -Wanalyzer-use-of-uninitialized-value false negative
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: alx at kernel dot org
Target Milestone: ---
For this code, which I wrote to try to trigger
-Wanalyzer-use-of-uninitialized-value:
$ cat bug.c
#include
void
g(int *x)
{
if (arc4random() % 2)
*x = 42;
}
int
main(void)
{
int x;
g(&x);
return x; // maybe uninitialized use
}
I'm having a hard time triggering the warning. No combination of flags seems
to trigger it.
$ gcc -Wall -Wextra -O3 -flto -fsanitize=undefined -fanalyzer bug.c
$ ./a.out; echo $?
42
$ ./a.out; echo $?
0
I tried 0,1,2,3 optimization levels, and nothing. Also tried both
gcc (Debian 13.2.0-24) 13.2.0
and
gcc-14 (Debian 14-20240429-1) 14.0.1 20240429 (experimental) [gcc-14
r14-10144-g41d7a8ceaaa]
[Bug c++/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 Rainer Orth changed: What|Removed |Added Summary|g++.target/i386/pr103696.C |[13/14/15 regression] |FAILs |g++.target/i386/pr103696.C ||FAILs --- Comment #3 from Rainer Orth --- Actually, this is a regression from GCC 12.
[Bug c/115088] New: Autofdo doesn't create correct cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115088 Bug ID: 115088 Summary: Autofdo doesn't create correct cfg Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andyzhenyu.zhao at mail dot utoronto.ca Target Milestone: --- Created attachment 58204 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58204&action=edit afdo cfg HI. I used the gcc 14 and autofdo-0.19. I tried to follow the steps for autofdo tutorial on this website(https://gcc.gnu.org/wiki/AutoFDO/Tutorial). And I attached the cfg I got. By the way, I used this command: gcc -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo -fdump-ipa-afdo-details. here is info for gcov: dump_gcov pmu.gcov sort_array total:8085 head:0 0: 0 1: 0 3.1: 0 4: 0 4.1: 0 7: 0 6: bubble_sort total:8085 2: 0 3: 0 4.1: 1999 5: 4246 8: 1070 9: 770
[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066 Tom de Vries changed: What|Removed |Added Target Milestone|--- |15.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Tom de Vries --- Fixed.
[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066 --- Comment #8 from GCC Commits --- The master branch has been updated by Tom de Vries : https://gcc.gnu.org/g:b7003b4cc5e263343f047fe64ed1ae12f561b2d1 commit r15-483-gb7003b4cc5e263343f047fe64ed1ae12f561b2d1 Author: Tom de Vries Date: Mon May 13 18:10:15 2024 +0200 [debug] Fix dwarf v4 .debug_macro.dwo Consider a hello world, compiled with -gsplit-dwarf and dwarf version 4, and -g3: ... $ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA ... In section .debug_macro.dwo, we have: ... .Ldebug_macro0: .value 0x4 # DWARF macro version number .byte 0x2 # Flags: 32-bit, lineptr present .long .Lskeleton_debug_line0 .byte 0x3 # Start new file .uleb128 0 # Included from line number 0 .uleb128 0x1# file /data/vries/hello.c .byte 0x5 # Define macro strp .uleb128 0 # At line number 0 .uleb128 0x1d0 # The macro: "__STDC__ 1" ... Given that we use a DW_MACRO_define_strp, we'd expect 0x1d0 to be an offset into a .debug_str.dwo section. But in fact, 0x1d0 is an index into the string offset table in section .debug_str_offsets.dwo: ... .long 0x34f0 # indexed string 0x1d0: __STDC__ 1 ... Add asserts that catch this inconsistency, and fix this by using DW_MACRO_define_strx instead. Tested on x86_64. gcc/ChangeLog: 2024-05-14 Tom de Vries PR debug/115066 * dwarf2out.cc (output_macinfo_op): Fix DW_MACRO_define_strx/strp choice for v4 .debug_macro.dwo. Add asserts to check that choice. gcc/testsuite/ChangeLog: 2024-05-14 Tom de Vries PR debug/115066 * gcc.dg/pr115066.c: New test.
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64 and x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #30 from Martin Jambor --- ...so set to fixed as well.
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64 and x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #29 from Martin Jambor --- Fixed
[Bug c++/113719] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 Rainer Orth changed: What|Removed |Added CC||hongyuw at gcc dot gnu.org --- Comment #2 from Rainer Orth --- A reghunt identified this patch as the culprit: commit 8caf155a3d6e23e47bf55068ad23c23d4655a054 Author: Hongyu Wang Date: Sat Nov 19 09:38:00 2022 +0800 i386: Only enable small loop unrolling in backend [PR 107692]
[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066 --- Comment #7 from Tom de Vries --- Submitted here ( https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651586.html ).
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64 and x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #28 from GCC Commits --- The releases/gcc-13 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:10bf53a80eefa46500bffb442719777e2640e7d7 commit r13-8773-g10bf53a80eefa46500bffb442719777e2640e7d7 Author: Martin Jambor Date: Mon Apr 8 18:53:23 2024 +0200 ICF&SRA: Make ICF and SRA agree on padding PR 113359 shows that (at least with -fno-strict-aliasing) ICF can unify two functions which copy an aggregate type of the same size but then SRA, through its total scalarization, can copy the aggregate by pieces, skipping paddding, but the padding was not the same in the two original functions that ICF unified. This patch enhances SRA with the ability to collect padding information which then can be compared from within ICF. Unfortunately SRA uses OPTION_SET_P when determining its limits, so ICF needs to switch cfuns at least once to figure it out too. gcc/ChangeLog: 2024-03-27 Martin Jambor PR ipa/113359 * ipa-icf-gimple.h (func_checker): New members safe_for_total_scalarization_p, m_total_scalarization_limit_known_p and m_total_scalarization_limit. (func_checker::func_checker): Initialize new member variables. * ipa-icf-gimple.cc: Include tree-sra.h. (func_checker::func_checker): Initialize new member variables. (func_checker::safe_for_total_scalarization_p): New function. (func_checker::compare_operand): Use the new function. * tree-sra.h (sra_get_max_scalarization_size): Declare. (sra_total_scalarization_would_copy_same_data_p): Likewise. * tree-sra.cc (prepare_iteration_over_array_elts): New function. (class sra_padding_collecting): New. (sra_padding_collecting::record_padding): Likewise. (scalarizable_type_p): Rename to totally_scalarizable_type_p. Add ability to record padding when requested. (totally_scalarize_subtree): Split out gathering information necessary to iterate over array elements to prepare_iteration_over_array_elts. Fix errornous early exit. (analyze_all_variable_accesses): Adjust the call to totally_scalarizable_type_p. Move determining of total scalariation size limit... (sra_get_max_scalarization_size): ...here. (check_ts_and_push_padding_to_vec): New function. (sra_total_scalarization_would_copy_same_data_p): Likewise. gcc/testsuite/ChangeLog: 2024-03-27 Martin Jambor PR ipa/113359 * gcc.dg/lto/pr113359-1_0.c: New. * gcc.dg/lto/pr113359-1_1.c: Likewise. * gcc.dg/lto/pr113359-2_0.c: Likewise. * gcc.dg/lto/pr113359-2_1.c: Likewise. * gcc.dg/lto/pr113359-3_0.c: Likewise. * gcc.dg/lto/pr113359-3_1.c: Likewise. * gcc.dg/lto/pr113359-4_0.c: Likewise. * gcc.dg/lto/pr113359-4_1.c: Likewise. * gcc.dg/lto/pr113359-5_0.c: Likewise. * gcc.dg/lto/pr113359-5_1.c: Likewise. (cherry picked from commit 1e3312a25a7b34d6e3f549273e1674c7114e4408)
[Bug ipa/113291] [14/15 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #10 from GCC Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:1ec49897253e093e1ef6261eb104ac0c111bac83 commit r15-482-g1ec49897253e093e1ef6261eb104ac0c111bac83 Author: Jan Hubicka Date: Tue May 14 12:58:56 2024 +0200 Reduce recursive inlining of always_inline functions this patch tames down inliner on (mutiply) self-recursive always_inline functions. While we already have caps on recursive inlning, the testcase combines early inliner and late inliner to get very wide recursive inlining tree. The basic idea is to ignore DISREGARD_INLINE_LIMITS when deciding on inlining self recursive functions (so we cut on function being large) and clear the flag once it is detected. I did not include the testcase since it still produces a lot of code and would slow down testing. It also outputs many inlining failed messages that is not very nice, but it is hard to detect self recursin cycles in full generality when indirect calls and other tricks may happen. gcc/ChangeLog: PR ipa/113291 * ipa-inline.cc (enum can_inline_edge_by_limits_flags): New enum. (can_inline_edge_by_limits_p): Take flags instead of multiple bools; add flag for forcing inlinie limits. (can_early_inline_edge_p): Update. (want_inline_self_recursive_call_p): Update; use FORCE_LIMITS mode. (check_callers): Update. (update_caller_keys): Update. (update_callee_keys): Update. (recursive_inlining): Update. (add_new_edges_to_heap): Update. (speculation_useful_p): Update. (inline_small_functions): Clear DECL_DISREGARD_INLINE_LIMITS on self recursion. (flatten_function): Update. (inline_to_all_callers_1): Update.
[Bug c++/115085] Variable unqualified-id is falsely treated as rvalue when appearing in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085 Jason Liam changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #5 from Jason Liam --- Maybe related bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64892 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78209
[Bug target/115087] New: dead block not eliminated in SVE intrinsics code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115087
Bug ID: 115087
Summary: dead block not eliminated in SVE intrinsics code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The testcase in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151 had another
"regression" in that the same loop seems to have been peeled but only for 1
iteration.
However the loops are identical so the peeling is weird.
This was caused by
f5fb9ff2396fd41fdd2e6d35a412e936d2d42f75 is the first bad commit
commit f5fb9ff2396fd41fdd2e6d35a412e936d2d42f75
Author: Jan Hubicka
Date: Fri Jul 28 16:18:32 2023 +0200
loop-split improvements, part 3
extend tree-ssa-loop-split to understand test of the form
if (i==0)
and
if (i!=0)
which triggers only during the first iteration. Naturally we should
also be able to trigger last iteration or split into 3 cases if
the test indeed can fire in the middle of the loop.
however the commit is innocent, it looks like we're not below a magic threshold
that causes the issue.
However a simpler testcase:
#include
void test(int size, char uplo, float16_t *p_mat)
{
int col_stride = uplo == 'u' ? 1 : size;
auto *a = &p_mat[0];
auto pg = svptrue_b16();
for (int j = 0; j < size; ++j) {
auto *a_j = &a[j];
if (j > 0) {
int col_i = j + 1;
auto v_a_ji_0 = svld1_vnum_f16(pg, (const float16_t *)&a_j[col_i], 0);
v_a_ji_0 = svcmla_f16_x(pg, v_a_ji_0, v_a_ji_0, v_a_ji_0, 180);
}
int col_i = j * col_stride;
auto v_a_ji_0 = svld1_vnum_f16(pg, (const float16_t *)&a_j[col_i], 0);
auto v_old_a_jj_0 = svld1_vnum_f16(pg, (const float16_t *)&a_j[j], 0);
v_a_ji_0 = svmul_f16_x(pg, v_old_a_jj_0, v_a_ji_0);
svst1_vnum_f16(pg, (float16_t *)&a_j[col_i], 0, v_a_ji_0);
}
}
shows that the change in the patch is a positive one.
The issue seems to be that GCC does not see the if block as dead code:
if (j > 0) {
int col_i = j + 1;
auto v_a_ji_0 = svld1_vnum_f16(pg, (const float16_t *)&a_j[col_i], 0);
v_a_ji_0 = svcmla_f16_x(pg, v_a_ji_0, v_a_ji_0, v_a_ji_0, 180);
}
is dead because v_a_ji_0 is overwritten before use.
_29 = MEM <__SVFloat16_t> [(__fp16 *)_88 + ivtmp.10_52 * 2];
svcmla_f16_x ({ -1, 0, ... }, _29, _29, _29, 180);
_29 is dead, but I guess it's not eliminated because it doesn't know what
svcmla_f16_x does. But are these intrinsics not marked as CONST|PURE ?
We finally eliminate it at RTL level but I think we should mark these
intrinsics as ECF_CONST
[Bug c++/115085] Variable unqualified-id is falsely treated as rvalue when appearing in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085 --- Comment #4 from Jan Schultke --- https://github.com/cplusplus/CWG/issues/536
[Bug libstdc++/115063] compilation error: std::basic_stracktrace::max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed for 13.3 and 14.2, thanks for the report.
[Bug c++/115085] Variable unqualified-id is falsely treated as rvalue when appearing in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085 --- Comment #3 from Andrew Pinski --- See https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1521 also.
[Bug libstdc++/115063] compilation error: std::basic_stracktrace::max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ccc26a1af07b34ce2e7d3b2497f27992d1b1bbc2 commit r15-481-gccc26a1af07b34ce2e7d3b2497f27992d1b1bbc2 Author: Jonathan Wakely Date: Mon May 13 16:25:13 2024 +0100 libstdc++: Fix typo in std::stacktrace::max_size [PR115063] libstdc++-v3/ChangeLog: PR libstdc++/115063 * include/std/stacktrace (basic_stacktrace::max_size): Fix typo in reference to _M_alloc member. * testsuite/19_diagnostics/stacktrace/stacktrace.cc: Check max_size() compiles.
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #14 from cqwrteur --- libgcc: /home/cqwrteur/toolchains_build/gcc/libgcc/libgcov.h:49:10: fatal error: sys/mman.h: No such file or directory 49 | #include | ^~~~ compilation terminated. make[4]: *** [Makefile:933: _gcov_interval_profiler.o] Error 1 make[4]: *** Waiting for unfinished jobs
[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359 --- Comment #7 from Jonathan Wakely --- Fixed for 13.3 and 14.1 so far, I still plan to backport this to gcc-12 too.
[Bug libstdc++/114891] Unconditional use of std::is_pointer_interconvertible_base_of_v in makes the header unusable with Clang 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jonathan Wakely --- Fixed for 14.2
[Bug libstdc++/114866] [14 Regression] & out_ptr in freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Fixed for 14.2
[Bug libstdc++/115063] compilation error: std::basic_stracktrace::max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063 --- Comment #2 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7dca716decf5a07f903610fda9457ff0422d2758 commit r13-8772-g7dca716decf5a07f903610fda9457ff0422d2758 Author: Jonathan Wakely Date: Mon May 13 16:25:13 2024 +0100 libstdc++: Fix typo in std::stacktrace::max_size [PR115063] libstdc++-v3/ChangeLog: PR libstdc++/115063 * include/std/stacktrace (basic_stacktrace::max_size): Fix typo in reference to _M_alloc member. * testsuite/19_diagnostics/stacktrace/stacktrace.cc: Check max_size() compiles. (cherry picked from commit dd9677f3343ca2a4b4aab9428b8129774accac29)
[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:71e941b0e329d3a316e465569c92e08788a68614 commit r13-8771-g71e941b0e329d3a316e465569c92e08788a68614 Author: Jonathan Wakely Date: Mon Mar 18 13:22:17 2024 + libstdc++: Fix infinite loop in std::binomial_distribution [PR114359] The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is unsigned and 4 * _M_t wraps to zero. The third operand has type double, so do the second multiplication first, so that we aren't multiplying integers. libstdc++-v3/ChangeLog: PR libstdc++/114359 * include/bits/random.tcc (binomial_distribution::param_type): Ensure arithmetic is done as type double. * testsuite/26_numerics/random/binomial_distribution/114359.cc: New test. (cherry picked from commit 07e03761a7fc1626a6a74ed957e117f56981558c)
[Bug target/115086] bic is not used when the non-not part is a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086 --- Comment #2 from Richard Earnshaw --- And perhaps more importantly the mov can even be hoisted outside of a loop.
[Bug libstdc++/114891] Unconditional use of std::is_pointer_interconvertible_base_of_v in makes the header unusable with Clang 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4d3b358fd757ddd09cbee202f47939043c78676c commit r14-10206-g4d3b358fd757ddd09cbee202f47939043c78676c Author: Jonathan Wakely Date: Tue Apr 30 09:48:00 2024 +0100 libstdc++: Guard uses of is_pointer_interconvertible_v [PR114891] This type trait isn't supported by Clang 18. It's only used in static assertions, so they can just be omitted if the trait isn't available. libstdc++-v3/ChangeLog: PR libstdc++/114891 * include/std/generator: Check feature test macro before using is_pointer_interconvertible_v. (cherry picked from commit 1fbe1a50d86df11f434351cf62461a32747f9710)
[Bug libstdc++/115063] compilation error: std::basic_stracktrace::max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063 --- Comment #1 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c60205cd4aeea586b7b1fe06baa9861b6d279648 commit r14-10207-gc60205cd4aeea586b7b1fe06baa9861b6d279648 Author: Jonathan Wakely Date: Mon May 13 16:25:13 2024 +0100 libstdc++: Fix typo in std::stacktrace::max_size [PR115063] libstdc++-v3/ChangeLog: PR libstdc++/115063 * include/std/stacktrace (basic_stacktrace::max_size): Fix typo in reference to _M_alloc member. * testsuite/19_diagnostics/stacktrace/stacktrace.cc: Check max_size() compiles. (cherry picked from commit dd9677f3343ca2a4b4aab9428b8129774accac29)
[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 --- Comment #13 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:788ccd269e0c32c33ce0c1359137fe1b35dc7a2d commit r14-10205-g788ccd269e0c32c33ce0c1359137fe1b35dc7a2d Author: Jonathan Wakely Date: Thu Apr 11 15:35:11 2024 +0100 libstdc++: Update ABI test to disallow adding to released symbol versions If we update the list of "active" symbols versions now, rather than when adding a new symbol version, we will notice if new symbols get added to the wrong version (as in PR 114692). libstdc++-v3/ChangeLog: * testsuite/util/testsuite_abi.cc: Update latest versions to new versions that should be used in future. (cherry picked from commit 6e25ca387fbbb412a2e498e28ea5db28e033a318)
[Bug c++/115085] Variable unqualified-id is falsely treated as rvalue when appearing in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085 --- Comment #2 from Andrew Pinski --- I think there is a dup of this bug already filed ...
[Bug libstdc++/114866] [14 Regression] & out_ptr in freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:95055199ee80e526da98c3458308fa345a041d9a commit r14-10203-g95055199ee80e526da98c3458308fa345a041d9a Author: Jonathan Wakely Date: Thu May 2 12:14:52 2024 +0100 libstdc++: Fix for -std=c++23 -ffreestanding [PR114866] std::shared_ptr isn't declared for freestanding, so guard uses of it with #if _GLIBCXX_HOSTED in . libstdc++-v3/ChangeLog: PR libstdc++/114866 * include/bits/out_ptr.h [!_GLIBCXX_HOSTED]: Don't refer to shared_ptr, __shared_ptr or __is_shred_ptr. * testsuite/20_util/headers/memory/114866.cc: New test. (cherry picked from commit 9927059bb88e966e0a45f09e4fd1193f93df708f)
