https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91228
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91223
--- Comment #5 from Martin Liška ---
I have one another smaller test-case:
$ cat ice.i
int a;
void fn2(short, short);
void fn1(void) {
short b[8];
b[0] |= a & 3;
b[1] = a;
fn2(b[0], b[1]);
}
$ gcc ice.i -c -Og -fno-tree-fre
during RTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91228
--- Comment #6 from Martin Liška ---
Author: marxin
Date: Wed Jul 24 07:00:48 2019
New Revision: 273757
URL: https://gcc.gnu.org/viewcvs?rev=273757=gcc=rev
Log:
Fix off-by-one in simple-object-elf.c (PR lto/91228).
2019-07-24 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91240
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91237
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91232
--- Comment #9 from bharath appali ---
(In reply to Richard Biener from comment #5)
> It's the 0 - src computation that invokes undefined behavior and things go
> downhill from there. Use 0 - (uint32_t)src here.
Can I please have any pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91240
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91238
--- Comment #3 from Iain Buclaw ---
(In reply to Richard Biener from comment #2)
> Hm, so what exactly should ADDR_EXPR of a CALL_EXPR code-gen to? The ICE
> itself happens because add_expr, when traversing a CALL_EXPR does not
> unset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91246
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
--- Comment #4 from Martin Liška ---
It must be a miscompilation of gcc/tree-ssa-sccvn.c file. Using stage 2
compiler during boostrap is fine. Likewise, adding -O0 to gcc/tree-ssa-sccvn.c
is fine.
I'm using following host compiler:
$ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #6 from Marc Glisse ---
When we compare p>=a where a is an array (char a[3];), we can assume that p
points somewhere into the array and fold it to true (unless we decide that it
is too risky, and that for instance since we allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #7 from rguenther at suse dot de ---
On Wed, 24 Jul 2019, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
>
> --- Comment #6 from Marc Glisse ---
> When we compare p>=a where a is an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #31 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #30)
> So something is odd with how the frontend handles 'c_'.
>
> The symbol table has two:
>
> __f_MOD_c_/2 (c_) @0x7f763892d300
> Type: variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
--- Comment #5 from Martin Liška ---
So putting #pragma GCC optimize ("-O0") at line 1735 is the last position when
I don't see the ICE. So vn_walk_cb_data::push_partial_def or an inliced
function is miscompiled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91166
--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Wed Jul 24 07:20:24 2019
New Revision: 273758
URL: https://gcc.gnu.org/viewcvs?rev=273758=gcc=rev
Log:
2019-07-24 Prathamesh Kulkarni
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91245
Bug ID: 91245
Summary: gnat.dg/float_value1.adb FAILs
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91245
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91247
Bug ID: 91247
Summary: Variadic template expansion - Mistmatch argument pack
length
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #32 from rguenther at suse dot de ---
On Wed, 24 Jul 2019, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
>
> --- Comment #31 from Thomas Koenig ---
> (In reply to rguent...@suse.de from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
--- Comment #17 from Daniel Berlin ---
Not sure how i ended up on the CC list for this one, but i actually
would disagree it would be better than nothing.
Features that can only be made to work a small amount and are
incapable of being improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91244
Bug ID: 91244
Summary: gcc-ar prepends --plugin option thus triggers binutils
getopt_long bug 13256
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91238
--- Comment #1 from Iain Buclaw ---
Further reduced, always triggers ICE, so it's not something that recently
started to happen.
---
alias T = const(char)*;
T name()
{
return "";
}
void collectDependencies(ref T)
{
}
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #5 from rguenther at suse dot de ---
On Tue, 23 Jul 2019, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
>
> --- Comment #4 from Martin Sebor ---
> The results of relational expressions (<,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518
--- Comment #20 from Richard Biener ---
(In reply to Steve Ellcey from comment #19)
> Should this defect be reopened? One of the tests that was added is failing
> for me on aarch64.
>
> FAIL: g++.dg/tree-ssa/pr83518.C -std=gnu++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242
--- Comment #3 from Martin Liška ---
Must be related to hashing of the TYPE_UID, following patch fixes that:
diff --git a/gcc/tree.c b/gcc/tree.c
index 8cf75f0..7a5d6ef4625 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -1644,7 +1644,6 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242
Martin Liška changed:
What|Removed |Added
Target||aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
--- Comment #6 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #5)
> Fixing the dependency for identical=true is a Good Thing(TM), but
> will not be enough to fix the test case:
Hm, another thought.
For this special case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91246
Bug ID: 91246
Summary: vectorization failure for a small loop to search array
element
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91238
--- Comment #2 from Richard Biener ---
Hm, so what exactly should ADDR_EXPR of a CALL_EXPR code-gen to? The ICE
itself happens because add_expr, when traversing a CALL_EXPR does not
unset OEP_ADDRESS_OF when processing arguments (taking the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91248
Bug ID: 91248
Summary: __builtin___clear_cache is a no-op on SPARC
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
--- Comment #6 from Martin Liška ---
I've got it:
/* We support up to 512-bit values (for V8DFmode). */
unsigned char buffer[64];
int len;
while (!partial_defs.is_empty ())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91249
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91250
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91244
--- Comment #1 from Szőts Ákos ---
Ps.: I've just realised that it's possible to unify the loop with the next
#else section and have only lines
nargv[k + 0] = "--plugin";
nargv[k + 1] = plugin;
inside the #if condition, thus removing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91251
Bug ID: 91251
Summary: Revision 272645 on top of 9.1.0 caused ICE: in
extract_insn, at recog.c:2310
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
--- Comment #8 from Richard Biener ---
Ooops (double-oops, see 2nd hunk...). Testing the following:
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91238
--- Comment #4 from Richard Biener ---
(In reply to Iain Buclaw from comment #3)
> (In reply to Richard Biener from comment #2)
> > Hm, so what exactly should ADDR_EXPR of a CALL_EXPR code-gen to? The ICE
> > itself happens because add_expr,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91249
Bug ID: 91249
Summary: Missed optimization: division and multiplying ops in
ffast-math mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91247
--- Comment #1 from Mario Galindo ---
When expanding the pack of a variadic template, the compiler erroneously adds
an extra spurious type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
--- Comment #7 from Martin Liška ---
One can see it on x86_64 with the following patch:
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 9369c36f50e..6192540c219 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91250
Bug ID: 91250
Summary: Missed optimization: is not used vfnmsub213ss
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91232
--- Comment #10 from Andrew Pinski ---
>Can I please have any pointers which could explain why that particular
>computation is invoking an undefined behaviour ?
Signed integer overflow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91248
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91250
--- Comment #2 from Alexander Zaitsev ---
But on this example all is fine:
float foo(float a, float b, float c)
{
return -a * -b - c;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91250
--- Comment #1 from Alexander Zaitsev ---
Another example of missed optimization:
float foo(float a, float b, float c)
{
return -a * b - c;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91223
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518
--- Comment #21 from Steve Ellcey ---
(In reply to Richard Biener from comment #20)
> (In reply to Steve Ellcey from comment #19)
> It should have been fixed by r273732 (checked with a cc1 cross to aarch64,
> albeit on a not clean tree...)
OK,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91252
Bug ID: 91252
Summary: [Bug] When use -flto "weak symbol" are converted to
"t".
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #19 from Richard Earnshaw ---
Surely the real problem is that the expansion doesn't really understand about
the 'don't care' location and that we can therefore put any value in that?
That additional knowledge would allow the earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #8 from Martin Sebor ---
(In reply to rguent...@suse.de from comment #5)
> Does "unspecified" allow p > q != !(p <= q)? I think so (it's not
> implementation defined).
The exact C++ words that apply here are:
(4.3) Otherwise [if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #20 from Jeffrey A. Law ---
Just to be clear, the expansion in question happens very early, essentially
pre-gimple, not at the gimple/RTL border and it's driven by a target macro.
I guess another approach would be to write the whole
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91253
Bug ID: 91253
Summary: gfortran.dg/continuation_6.f fails when using latest
glibc
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #9 from Marc Glisse ---
(In reply to Martin Sebor from comment #8)
> I also agree that diagnosing all these unspecified (or undefined in C) cases
> would be helpful as they (at least in the straightforward instances) are
> most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #21 from Iain Sandoe ---
Author: iains
Date: Wed Jul 24 19:59:22 2019
New Revision: 273768
URL: https://gcc.gnu.org/viewcvs?rev=273768=gcc=rev
Log:
[Darwin] Partial reversion of 273749.
We still need to cater for pr80556, for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88227
--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> (In reply to Dominique d'Humieres from comment #6)
> > The following test giveS ALSO an ICE with -m32
> >
> > % cat boz_10.f90
> > print *,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91254
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545
--- Comment #7 from Martin Sebor ---
Author: msebor
Date: Wed Jul 24 20:34:03 2019
New Revision: 273771
URL: https://gcc.gnu.org/viewcvs?rev=273771=gcc=rev
Log:
PR driver/80545 - option -Wstringop-overflow not recognized by Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91254
--- Comment #2 from Alexandre Bencz ---
same problem, with -fwrapv, the program still stucked... and, for a test, I
tried to use the -fsanitize=undefined and the program still stucked...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #98 from C. Heide ---
(In reply to The Written Word from comment #97)
> (In reply to C. Heide from comment #73)
> > With that change, and some other cajoling (the previously mentioned
> > duplicate symbols and operand64 problem, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91254
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91254
--- Comment #4 from Alexandre Bencz ---
It's true ... I did not realize this ... well, for testing purposes made a test
using malloc to allocate the array and zeroed all bytes using the memset, with
the correct size and the error persists. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91189
Zygmunt changed:
What|Removed |Added
CC||zygmuntptak at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #97 from The Written Word
---
(In reply to C. Heide from comment #73)
> With that change, and some other cajoling (the previously mentioned
> duplicate symbols and operand64 problem, and -O1 to work around the ICE), I
> can now get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #96 from The Written Word
---
(In reply to dave.anglin from comment #91)
> On 2019-07-23 5:53 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > In file included from
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808
--- Comment #7 from Matthias Klose ---
a patch was posted at
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01045.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91254
Bug ID: 91254
Summary: Wrong generate code with a series of array access
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86688
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Thu Jul 25 00:29:17 2019
New Revision: 273783
URL: https://gcc.gnu.org/viewcvs?rev=273783=gcc=rev
Log:
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91183
--- Comment #4 from Martin Sebor ---
Author: msebor
Date: Thu Jul 25 00:29:17 2019
New Revision: 273783
URL: https://gcc.gnu.org/viewcvs?rev=273783=gcc=rev
Log:
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91246
--- Comment #3 from Jiangning Liu ---
Expect to vectorize the inner loop by generating the code below for x86,
vpbroadcastd [mem], ymm0
vpaddd [mem], ymm0, ymm1
vpbroadcastd reg, ymm2
vpcmpeqd ymm2, ymm1, k0
kortestw k0, k0
cmovne ...
AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #99 from The Written Word
---
(In reply to C. Heide from comment #98)
> (In reply to The Written Word from comment #97)
> > (In reply to C. Heide from comment #73)
> > > With that change, and some other cajoling (the previously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91246
--- Comment #2 from Jiangning Liu ---
Created attachment 46626
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46626=edit
A new test
Attached is a test case that is more closely matching the real-world code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
77 matches
Mail list logo
