https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
Bug 59859 depends on bug 86865, which changed state.
Bug 86865 Summary: [9 Regression] Wrong code w/ -O2 -floop-parallelize-all
-fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts
-fno-tree-loop-ivcanon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
Richard Biener changed:
What|Removed |Added
Attachment #45523|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109
Martin Liška changed:
What|Removed |Added
CC||boazstud at yahoo dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89046
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643
--- Comment #5 from Sebastian Huber ---
I think the basic problem is that the LD --wrap feature works only with
undefined symbols references and not relocations:
See also:
https://www.sourceware.org/ml/binutils/2019-01/msg00204.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049
Richard Biener changed:
What|Removed |Added
CC|segher at gcc dot gnu.org |
--- Comment #6 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89058
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057
--- Comment #1 from ktkachov at gcc dot gnu.org ---
*** Bug 89058 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89058
Bug ID: 89058
Summary: GCC 7->8 regression: ARM(64) ld3 st4 less optimized
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057
Bug ID: 89057
Summary: GCC 7->8 regression: ARM(64) ld3 st4 less optimized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049
Richard Biener changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049
--- Comment #4 from Richard Biener ---
With -mtune=core-avx2 we do
vmovups (%rdi), %xmm1
vmovups (%rdi), %ymm3
...
vextractf128$0x1, %ymm3, %xmm1
with -mtune=intel the even more weird
vmovups (%rdi), %xmm1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049
--- Comment #3 from Richard Biener ---
In the assembly I notice
vinsertf128 $0x1, 16(%rdi), %ymm4, %ymm2
...
vextractf128$0x1, %ymm2, %xmm1
somehow we fail to elide the initial %ymm2 build with the upper half
extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #49 from Eric Botcazou ---
> Just to remind where we're coming from - we have
>
> unData.strMemHead.b30AddrL= ulAddr >> 2;
>
> where this is a 30bit bitfield store (at bit offset % BITS_PER_UNIT == 0)
> from a unsigned :30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88937
Martin Liška changed:
What|Removed |Added
CC||3dw4rd at verizon dot net,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049
--- Comment #2 from Richard Biener ---
Created attachment 45531
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45531=edit
scalar loop cost patch
I'm testing this patch (not fixing the testcase, just improving costs).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88937
Martin Liška changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #48 from Eric Botcazou ---
> OK, we can certainly try to enforce this. Just to make sure - this
> refers to TREE_TYPE (TREE_OPERAND (bfr, 0)), not the base of the
> component-ref chain eventually rooted here?
Yes, formally it's the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #6 from Andrey Belevantsev ---
(In reply to Alexander Monakov from comment #4)
> Thanks. This broke when the patch for PR 85458 was applied, and Andreas
> raised it on the gcc-patches thread:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044
--- Comment #2 from Andoni ---
8.2.0 I updated the version field too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89045
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89043
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044
Richard Biener changed:
What|Removed |Added
Keywords||build
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86865
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Fri Jan 25 08:13:34 2019
New Revision: 268257
URL: https://gcc.gnu.org/viewcvs?rev=268257=gcc=rev
Log:
2019-01-25 Richard Biener
PR tree-optimization/86865
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #47 from Richard Biener ---
(In reply to Eric Botcazou from comment #45)
> > So to get back to this - my thinking was that for a reference REF I can do
> >
> > base = get_inner_reference (ref, , , , ,
> > , , );
> >
> > and get
101 - 128 of 128 matches
Mail list logo
