https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503
--- Comment #1 from Willy Tarreau ---
Re-reading godbolt's version more closely, it's just 1 day old (I thought I
read 20201010) so the issue is still valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503
Bug ID: 98503
Summary: [11 regression] -Warray-bounds false positive with
global variables at -O2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98502
Bug ID: 98502
Summary: Optimised memcpy breaks __scalar_storage_order__
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98501
Bug ID: 98501
Summary: potential optimization for base<->derived pointer
casts
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95768
--- Comment #8 from Martin Sebor ---
Updated patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562665.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
--- Comment #1 from Sergei Trofimovich ---
Managed to get rid of external dependency:
```
struct string {
char * _M_buf;
// local store
char _M_local_buf[16];
string(const string &__str) : _M_buf(_M_local_buf) {}
string(const char *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80016
Ivan Sorokin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
--- Comment #7 from Steve Kargl ---
On Sat, Jan 02, 2021 at 04:12:27AM +, jvdelisle at charter dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
>
> --- Comment #5 from Jerry DeLisle ---
> Patch regresses several test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986
--- Comment #7 from Steve Kargl ---
On Sat, Jan 02, 2021 at 07:53:17PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986
>
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #5)
>If the ENTRY statement is in a subroutine subprogram, an additional
>subroutine is defined by that subprogram. The name of the subroutine
>is entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393
--- Comment #10 from David Binderman ---
Reduced test case:
typedef struct {
short a;
struct {
unsigned short b;
unsigned short c
} d[]
} e;
enum { f, g, h, i };
e j;
char k, l;
e *m;
void n(void) {
int o;
char *q, *r = 0, *s,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95771
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927
Gerald Pfeifer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496
--- Comment #3 from Svante Signell ---
On Sat, 2021-01-02 at 17:49 +, doko at debian dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496
>
> Matthias Klose changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98461
--- Comment #8 from Denis Yaroshevskiy ---
Thank you for the fast fix.
I can already see that the code is in trunk and works for both 256 and 128 bit
registers.
256: https://godbolt.org/z/5sT48f
128: https://godbolt.org/z/Exo3d9
I am a bit con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496
Matthias Klose changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2021-01-02
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98493
seurer at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96921
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98500
Bug ID: 98500
Summary: ICE template template parameter with default parameter
lambda
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
Bug ID: 98499
Summary: [11 Regression] Possibly bad std::string
initialization in constructors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930
--- Comment #3 from Jakub Jelinek ---
I guess it could be either optimized using a match.pd pattern like we have for:
/* Convert (outertype)((innertype0)a+(innertype1)b)
into ((newtype)a+(newtype)b) where newtype
is the widest mode from all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498
Paul Thomas changed:
What|Removed |Added
Last reconfirmed||2021-01-02
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96782
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|prathamesh34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498
Bug ID: 98498
Summary: Interp request: defined operators and unlimited
polymorphic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697
--- Comment #3 from Jakub Jelinek ---
On the other side, we do have:
/* X % Y is smaller than Y. */
(for cmp (lt ge)
(simplify
(cmp (trunc_mod @0 @1) @1)
(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
{ constant_boolean_node (cmp == LT_EXPR, type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96696
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98443
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798
--- Comment #5 from Jakub Jelinek ---
Related to what I wrote in PR94802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802#c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802
--- Comment #5 from Jakub Jelinek ---
Even when the optimization is restricted to GIMPLE only, the single_use in
there doesn't work really well before fre1 optimizes it, because the above
mentioned testcase doesn't reuse the same expression, but
33 matches
Mail list logo
