https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107891
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107888
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
--- Comment #1 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892
Bug ID: 107892
Summary: Unnecessary move between ymm registers in loop using
AVX2 intrinsic
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107882
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #9 from Hongtao.liu ---
expand_expr_real_1 generates (const_int 255) without considering the target
mode.
I guess it's on purpose, so I'll leave that alone and only change the expander
in the backend. After applying convert_modes to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107891
--- Comment #1 from Hongtao.liu ---
commemt25 from PR97832
I guess that's possible but the SLP vectorizer has a permute optimization
phase (and SLP discovery itself), it would be nice to see why the former
doesn't elide the permutes here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #26 from Hongtao.liu ---
> I guess that's possible but the SLP vectorizer has a permute optimization
> phase (and SLP discovery itself), it would be nice to see why the former
> doesn't elide the permutes here.
I've opened PR107891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #25 from rguenther at suse dot de ---
On Mon, 28 Nov 2022, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
>
> --- Comment #24 from Hongtao.liu ---
> _233 = {f_im_36, f_re_35, f_re_35, f_re_3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107889
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107882
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876
Martin Liška changed:
What|Removed |Added
Summary|[13 Regression] ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107891
Bug ID: 107891
Summary: Redudant "double" permutation from PR97832
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #24 from Hongtao.liu ---
_233 = {f_im_36, f_re_35, f_re_35, f_re_35};
_217 = {f_re_35, f_im_36, f_im_36, f_im_36};
...
vect_x_re_55.15_227 = VEC_PERM_EXPR ;
vect_x_re_55.23_211 = VEC_PERM_EXPR ;
...
vect_y_re_69.17_224 = .FNMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #23 from Hongtao.liu ---
> the blends do not look like no-ops so I wonder if this is really computing
> the same thing ... (it swaps lane 0 from the two loads from x but not the
> stores)
They're computing the same thing since we al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #12 from cuilili ---
This regression caused by the store forwarding issue, we eliminate the
redundant two pairs of loads and stores which have store forwarding issue by
inlining.
This regression has been fixed by
https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105145
--- Comment #2 from Andrew Pinski ---
*** Bug 105248 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105248
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107494
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|-ffinite-loops is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91882
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107887
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|pinskia at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|pinskia at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107887
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881
--- Comment #6 from Andrew Pinski ---
I was thinking about having reassociation changing bool == bool, bool < bool,
and bool <= bool into ~(bool ^ bool), !bool & bool, !bool | bool to
"linearizing" so then reassociation can handle the rest (with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107748
--- Comment #11 from Hongtao.liu ---
Fixed in GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107748
--- Comment #10 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:a1ecc5600464f6a62faab246d522b6328badda90
commit r13-4314-ga1ecc5600464f6a62faab246d522b6328badda90
Author: liuhongt
Date: Wed Nov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890
--- Comment #2 from Jonathan Wakely ---
You should read https://blog.regehr.org/archives/213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890
Bug ID: 107890
Summary: UB on integer overflow impacts code flow
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Rainer Orth ---
> It did in last night's Solaris bootstraps (sparc and x86). macOS bootstraps
> are
> super-slow, so I'll wait for tomorrow night's weekly bootstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #5 from Steve Kargl ---
On Sun, Nov 27, 2022 at 08:00:35PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
>
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #16 from dave.anglin at bell dot net ---
This is what the test prints:
6.47518e-4966 6e-4966
xxx.cc:79: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4
== ptr1' failed.
ABORT instruction (core dumped)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following patch fixes comment#3:
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 9c2fea8c5f2..2f69c4369ab 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #15 from Jakub Jelinek ---
(In reply to dave.anglin from comment #14)
> /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/
> float128_c++23.cc
> :77: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #14 from dave.anglin at bell dot net ---
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
:77: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 ==
ptr1
' failed.
FAIL: 20_util/to_char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Harald, you are likely right the patch can be moved down. I'll programmed
> up the example from the Fortran 2018 standard, which works as expected. So,
> th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107889
Bug ID: 107889
Summary: Incorrect parsing of qualified friend function
returning decltype(auto)
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107888
Bug ID: 107888
Summary: [12/13 Regression] Missed min/max transformation in
phiopt due to VRP
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107887
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107887
Bug ID: 107887
Summary: (bool0 > bool1) | bool1 is not optimized to bool0 |
bool1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #6 from Jamaika ---
I don't understand something. Why _GLIBCXX_HAS_GTHREADS works for std::jthread
but not for std::latch
```
#if defined _GLIBCXX_HAS_GTHREADS || defined _GLIBCXX_HAVE_LINUX_FUTEX
# define __cpp_lib_atomic_wait 20190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #5 from Jamaika ---
I test gcc 13.0.0. No change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #4 from Jamaika ---
I test gcc 13.0.0. No change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #3 from Jamaika ---
(In reply to Andrew Pinski from comment #2)
> Also it might be the case mingw work is needed to support
> __cpp_lib_atomic_wait and all.
I test gcc 13.0.0. No change.
http://msystem.waw.pl/x265/mingw-gcc1300-2022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #2 from Andrew Pinski ---
Also it might be the case mingw work is needed to support __cpp_lib_atomic_wait
and all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #1 from Andrew Pinski ---
Have you tried GCC 12? As C++20 support was barely there for GCC 11.
For an example r12-10-gb52aef3a8cbcc8 improved latch support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
Bug ID: 107886
Summary: Problem witch std::latch, std::binary_semaphores in
C++2a
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
--- Comment #11 from Adrian Perl ---
Yeah, my mistake. My IDE failed to look up the function and a short search on
the internet revealed only builtin_trap
(https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html)
You just saved me hours with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
--- Comment #10 from Iain Sandoe ---
(In reply to Adrian Perl from comment #9)
> Thanks for the advice.
>
> I hope you meant __builtin_trap() as I can't find a __builtin_abort()
> function.
hmm .. I meant __builtin_abort () ... it is widely use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
--- Comment #9 from Adrian Perl ---
Thanks for the advice.
I hope you meant __builtin_trap() as I can't find a __builtin_abort() function.
I have now written test applications for all relevant bug reports (99576,
100611, 101976, 101367). I also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
--- Comment #2 from SASANO Takayoshi ---
Hello, can you tell me more details to do?
I think "some better way" seems to be one of them as follows.
1) change "#if __INT_WIDTH__ > 16 ~ #else ~ #endif" to
"#if defined(__INT_WIDTH__) && (__INT_WI
58 matches
Mail list logo
