[Bug tree-optimization/113186] [13/14 Regression] `(a^c) & (a^!c)` is not optimized to 0 for bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-January ||/641612.html --- Comment #4 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641612.html I will fix the regression with the IR from the C++ front-end seperately.
[Bug tree-optimization/86274] [7 Regression] SEGFAULT when logging std::to_string(NAN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274
Jason Liam changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #22 from Jason Liam ---
Same issue. But also seg faults with o4 and gcc 7.5
https://godbolt.org/z/G7G7nx1Tf
#include
#include
#include
#include
void test() {
std::cout << std::to_string(0.f) << '\n'; // make it "0" and it wont crash
}
int main() {
std::cout << std::to_string(INFINITY) << '\n';
}
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Eric Gallager changed: What|Removed |Added See Also||https://github.com/apple/sw ||ift-corelibs-libdispatch/is ||sues/765 --- Comment #25 from Eric Gallager --- Cross-referencing against https://github.com/apple/swift-corelibs-libdispatch/issues/765
[Bug tree-optimization/113186] [13/14 Regression] `(a^c) & (a^!c)` is not optimized to 0 for bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186 --- Comment #3 from Andrew Pinski --- So for the C testcase, we don't need to create a new pattern, just extend gimple_bitwise_inverted_equal_p to catch `a == b` and `a ^ b` are inverted equals like we already do for `a == b` and `a != b`. This allows for other patterns to work too ...
[Bug tree-optimization/113072] `(a ^ CST0) & (~a ^ CST0)` is not optimized to 0 at the gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113072
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Looks like bool sometimes produces != or ^ :)
> ```
> bool foo(bool a, int b)
> {
> bool b1 = b == 1;
> bool b2 = !b1;
> bool c = (a ^ b1);
> return c & (a ^ b2);
> }
> ```
> Though that is PR 49 .
I filed a related testcase to the above as PR 113186 but it does not handle the
above I think.
[Bug testsuite/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 --- Comment #7 from Jonathan Wakely --- (In reply to Xi Ruoyao from comment #4) > IIRC the "signed_rep_t = __int128;" case has really detected a compiler bug, > so IMO we shouldn't just disable it. > > Maybe my memory is flawed though. I think it was the opposite. Using `signed rep_t` relied on a compiler bug. When that bug was fixed we had to introduce a typedef for that type. I have no idea why it would make the test slower though.
[Bug testsuite/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108099 --- Comment #6 from Jonathan Wakely --- PR108099 I think
[Bug target/43644] __uint128_t missed optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43644
--- Comment #5 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:79e1b23b91477b29deccf2cae92a7e8dd816c54a
commit r14-6874-g79e1b23b91477b29deccf2cae92a7e8dd816c54a
Author: Roger Sayle
Date: Sun Dec 31 21:37:24 2023 +
i386: Tweak define_insn_and_split to fix FAIL of
gcc.target/i386/pr43644-2.c
This patch resolves the failure of pr43644-2.c in the testsuite, a code
quality test I added back in July, that started failing as the code GCC
generates for 128-bit values (and their parameter passing) has been in
flux.
The function:
unsigned __int128 foo(unsigned __int128 x, unsigned long long y) {
return x+y;
}
currently generates:
foo:movq%rdx, %rcx
movq%rdi, %rax
movq%rsi, %rdx
addq%rcx, %rax
adcq$0, %rdx
ret
and with this patch, we now generate:
foo:movq%rdi, %rax
addq%rdx, %rax
movq%rsi, %rdx
adcq$0, %rdx
which is optimal.
2023-12-31 Uros Bizjak
Roger Sayle
gcc/ChangeLog
PR target/43644
* config/i386/i386.md (*add3_doubleword_concat_zext): Tweak
order of instructions after split, to minimize number of moves.
gcc/testsuite/ChangeLog
PR target/43644
* gcc.target/i386/pr43644-2.c: Expect 2 movq instructions.
[Bug tree-optimization/113186] [13/14 Regression] `(a^c) & (a^!c)` is not optimized to 0 for bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186 --- Comment #2 from Andrew Pinski --- Note for `~a != b` (for boolean size) we should just convert that into: `a == b` . And then we would have the form for both C++ and C at -O1 in forwprop1 .
[Bug tree-optimization/113186] [13/14 Regression] `(a^c) & (a^!c)` is not optimized to 0 for bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |14.0 Last reconfirmed||2023-12-31 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- I am going to fix this next week.
[Bug tree-optimization/113186] New: [13/14 Regression] `(a^c) & (a^!c)` is not optimized to 0 for bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
Bug ID: 113186
Summary: [13/14 Regression] `(a^c) & (a^!c)` is not optimized
to 0 for bool
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
bool f(bool a, bool c)
{
bool b = (a^c);
bool d = (a^!c);
return b & d;
}
```
This should optimize to 0 but does not since GCC 13. With the C++ front-end, I
suspect since r13-1779-g375668e0508fbe . With the C front-end, it started on
the trunk.
For C have in forwprop1:
b_7 = a_5(D) ^ c_6(D);
_11 = a_5(D) ^ c_6(D);
_12 = a_5(D) == c_6(D);
_13 = b_7 & _12;
For C++ we have (at -O1):
b_7 = a_5(D) != c_6(D);
_1 = ~c_6(D);
d_8 = _1 != a_5(D);
_11 = b_7 & d_8;
For C++ at -O2 in forwprop2, we have similar as what with the C front-end.
[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065 --- Comment #7 from Tommy Murphy --- (In reply to palmer from comment #3) > The Linux and ELF multilibs are different: for Linux we assumed ISA > compatibility was up to the distro, so multilib just handles the ABI side of > things. That said, C does bleed into the ABI so we should really fix that > -- presumably we'd need some psABI work there, compatibility is going to be > a bit clunky so it's probably best to just add two explicit ABI variants. FYI this issue has cropped up again here: * https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1393
[Bug testsuite/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 --- Comment #5 from Hans-Peter Nilsson --- (In reply to Xi Ruoyao from comment #4) > IIRC the "signed_rep_t = __int128;" case has really detected a compiler bug, > so IMO we shouldn't just disable it. Maybe I should have been explicit: that was just for investigation purposes. > Maybe my memory is flawed though. Please link that PR here if you have it!
[Bug testsuite/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #4 from Xi Ruoyao --- (In reply to Hans-Peter Nilsson from comment #3) > There's one single regression event, bringing the host runtime to about 1.63 > seconds. Then some time later, an additional 0.1 second was added > (accumulated). > I did not look into that latter regression. The big one is clouded by a > large range of commits where max_size_type failed, due to > r14-159-g03cebd304955a6. > This was fixed in r14-205-g83470a5cd4c3d2, at which time there the big > regression is seen for the first time. That is also the "cause" for the > commit, because applying that commit to r14-158-g7d115e01411156 shows the > same number as for r14-205-g83470a5cd4c3d2. > > Actually, it's the testsuite part of that patch, because with that reverted > the execution time backs down to 0.33 seconds. IOW, this while PR is > /testsuites. Not sure what to do to improve the execution time, as plain > disabling the using "signed_rep_t = __int128;" by making the first line > "+#if 0 && __SIZEOF_INT128__" yields > /x/testsuite/std/ranges/iota/max_size_type.cc:36: note: the comparison > reduces to '(16 == 8)' > > Maybe the higher number for the execution time is actually the "right" one > and the range should be cut down to -100..100 for *all* targets? > > HNY! IIRC the "signed_rep_t = __int128;" case has really detected a compiler bug, so IMO we shouldn't just disable it. Maybe my memory is flawed though.
[Bug testsuite/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 Hans-Peter Nilsson changed: What|Removed |Added Component|libstdc++ |testsuite --- Comment #3 from Hans-Peter Nilsson --- There's one single regression event, bringing the host runtime to about 1.63 seconds. Then some time later, an additional 0.1 second was added (accumulated). I did not look into that latter regression. The big one is clouded by a large range of commits where max_size_type failed, due to r14-159-g03cebd304955a6. This was fixed in r14-205-g83470a5cd4c3d2, at which time there the big regression is seen for the first time. That is also the "cause" for the commit, because applying that commit to r14-158-g7d115e01411156 shows the same number as for r14-205-g83470a5cd4c3d2. Actually, it's the testsuite part of that patch, because with that reverted the execution time backs down to 0.33 seconds. IOW, this while PR is /testsuites. Not sure what to do to improve the execution time, as plain disabling the using "signed_rep_t = __int128;" by making the first line "+#if 0 && __SIZEOF_INT128__" yields /x/testsuite/std/ranges/iota/max_size_type.cc:36: note: the comparison reduces to '(16 == 8)' Maybe the higher number for the execution time is actually the "right" one and the range should be cut down to -100..100 for *all* targets? HNY!
[Bug c++/86440] -Wignored-qualifiers diagnostic highlights wrong token with pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86440
--- Comment #4 from Yohei Kojima ---
Also, -Wignored-qualifiers messages disappeared with g++ compiling b.c.
Probably it is a bug caused by the same reason as this bug.
$ g++ -c -Wall -Wextra -Wignored-qualifiers b.c
b.c: In function 'void g(void* const (*)())':
b.c:4:22: warning: unused parameter 'h' [-Wunused-parameter]
4 | void g(void *const (*h)(void)) {
|~~^~~~
[Bug c++/86440] -Wignored-qualifiers diagnostic highlights wrong token with pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86440
Yohei Kojima changed:
What|Removed |Added
CC||y.koj.eel at gmail dot com
--- Comment #3 from Yohei Kojima ---
gcc 13.2.0 reports warnings as follows:
$ g++ -Wignored-qualifiers -c a.cc
a.cc:1:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
1 | int const f() { return 0; }
| ^~~
a.cc:3:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
3 | int * const g() { return 0; }
| ^~~
Also, with the following C source b.c, gcc reports errors at the wrong
confusing location.
$ cat b.c
void f(void *const (*)(void)) {
}
void g(void *const (*h)(void)) {
}
The reported error was like below. Error report on g() is fine,
but gcc points to the return type of outer function on f(), which was confusing
to me.
$ gcc -c -Wignored-qualifiers b.c
b.c:1:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
1 | void f(void *const (*)(void)) {
| ^~~~
b.c:4:22: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
4 | void g(void *const (*h)(void)) {
| ^
Tested environment is gcc 13.2.0 on Docker (The current latest release
available from https://hub.docker.com/_/gcc):
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (GCC)
I'm interested in fixing this bug, and I've started digging into the code.
[Bug c++/113170] ICE: Segfault (template template parameter, alias template, default template argument)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113170 Andrew Pinski changed: What|Removed |Added Keywords|ice-on-invalid-code | --- Comment #3 from Andrew Pinski --- I am not 100% sure this is valid or not; I suspect it is not valid but MSVC looks like goes into an similar infinite recusion too. While clang errors out: ``` :11:8: error: template template argument has different template parameters than its corresponding template template parameter 11 | SS ss; |^ :6:1: note: too many template parameters in template template argument 6 | template typename TT = SSS> | ^~~~ :8:10: note: previous template template parameter is here 8 | template typename TT = S, typename T = int> | ^~ ``` But that error message seems wrong.
[Bug c++/113170] ICE: Segfault (template template parameter, alias template, default template argument)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113170 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code Last reconfirmed||2023-12-31 --- Comment #2 from Andrew Pinski --- ``` #5 0x00c4dd6b in coerce_template_parms (parms=0x773097f8, args=0x76ba4800, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/cp/pt.cc:9115 #6 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #7 0x00c4c375 in convert_template_argument (parm=0x77fb7180, arg=0x77fb7100, args=0x76ba5898, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #8 0x00c4e294 in coerce_template_parms (parms=0x77309af0, args=0x76ba47e0, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/tree.h:3613 #9 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #10 0x00c4c375 in convert_template_argument (parm=0x77fb7080, arg=0x77fb7200, args=0x76ba5870, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #11 0x00c4e294 in coerce_template_parms (parms=0x773097f8, args=0x76ba47c0, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/tree.h:3613 #12 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #13 0x00c4c375 in convert_template_argument (parm=0x77fb7180, arg=0x77fb7100, args=0x76ba5848, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #14 0x00c4e294 in coerce_template_parms (parms=0x77309af0, args=0x76ba47a0, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/tree.h:3613 #15 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #16 0x00c4c375 in convert_template_argument (parm=0x77fb7080, arg=0x77fb7200, args=0x76ba5820, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #17 0x00c4e294 in coerce_template_parms (parms=0x773097f8, args=0x76ba4780, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/tree.h:3613 #18 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #19 0x00c4c375 in convert_template_argument (parm=0x77fb7180, arg=0x77fb7100, args=0x76ba57f8, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #20 0x00c4e294 in coerce_template_parms (parms=0x77309af0, args=0x76ba4760, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/tree.h:3613 #21 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #22 0x00c4c375 in convert_template_argument (parm=0x77fb7080, arg=0x77fb7200, args=0x76ba57d0, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #23 0x00c4e294 in coerce_template_parms (parms=0x773097f8, args=0x76ba4740, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/tree.h:3613 #24 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #25 0x00c4c375 in convert_template_argument (parm=0x77fb7180, arg=0x77fb7100, args=0x76ba57a8, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #26 0x00c4e294 in coerce_template_parms (parms=0x77309af0, args=0x76ba4720, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/tree.h:3613 #27 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #28 0x00c4c375 in convert_template_argument (parm=0x77fb7080, arg=0x77fb7200, args=0x76ba5780, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #29 0x00c4e294 in coerce_template_parms (parms=0x773097f8, args=0x76ba4700, in_decl=0x0, complain=0, require_all_args=true) at ../../gcc/tree.h:3613 #30 0x00c74bdb in coerce_template_template_parms (parm_tmpl=, arg_tmpl=, complain=0, in_decl=0x0, outer_args=) at ../../gcc/cp/pt.cc:8211 #31 0x00c4c375 in convert_template_argument (parm=0x77fb7180, arg=0x77fb7100, args=0x76ba5758, complain=0, i=1, in_decl=0x0) at ../../gcc/cp/pt.cc:8653 #32 0x00c4e294 in coerce_template_parms (parms=0x77309af0, args=0x76ba46e0, in_decl=0x0, complain=0, require_all_args=true) at
