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&root=gcc&view=rev
Log:
Fix off-by-one in simple-object-elf.c (PR lto/91228).
2019-07-24 Martin
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=91241
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=91237
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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&root=gcc&view=rev
Log:
2019-07-24 Prathamesh Kulkarni
PR
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=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: no
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=91240
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
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 scan-tree-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242
Martin Liška changed:
What|Removed |Added
Target||aarch64-linux-gnu
Status|ASSI
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 (calling
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 @@ poly_
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=91245
Bug ID: 91245
Summary: gnat.dg/float_value1.adb FAILs
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assig
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=91239
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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 point
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=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 (cha
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 definitio
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
Pr
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 comm
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 configurePackages(T
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 addr
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 OEP_ADDRE
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 --versi
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=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: target
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 t
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=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
@@ -1816
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 273758
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=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, whe
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=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=91250
Bug ID: 91250
Summary: Missed optimization: is not used vfnmsub213ss
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
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=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=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 d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91250
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91249
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
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: no
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=91223
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
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, I
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
Priorit
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 t
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 likely
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
Prio
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=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&root=gcc&view=rev
Log:
[Darwin] Partial reversion of 273749.
We still need to cater for pr80556,
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&root=gcc&view=rev
Log:
PR driver/80545 - option -Wstringop-overflow not recognized by Fortran
gc
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 *, real(b'101010100110
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
> > /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc
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 g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91189
Zygmunt changed:
What|Removed |Added
CC||zygmuntptak at gmail dot com
--- Comment #1 fr
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
Component:
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=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 also
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 menti
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&root=gcc&view=rev
Log:
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
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&root=gcc&view=rev
Log:
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
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&action=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=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 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 91236, which changed state.
Bug 91236 Summary: [10 Regression] ICE in walk_non_aliased_vuses at
gcc/tree-ssa-alias.c:3395 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236
--- Comment #10 from Richard Biener ---
Author: rguenth
Date: Thu Jul 25 06:57:46 2019
New Revision: 273787
URL: https://gcc.gnu.org/viewcvs?rev=273787&root=gcc&view=rev
Log:
2019-07-25 Richard Biener
PR tree-optimization/91236
78 matches
Mail list logo
