https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #23 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Feb 20 12:04:21 2015
New Revision: 220854
URL: https://gcc.gnu.org/viewcvs?rev=220854&root=gcc&view=rev
Log:
Backport from mainline
2015-01-22 Wei Mi
PR rtl-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #21 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov 5 12:02:17 2014
New Revision: 217119
URL: https://gcc.gnu.org/viewcvs?rev=217119&root=gcc&view=rev
Log:
Backport from mainline:
2014-10-20 Uros Bizjak
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Oct 10 17:36:21 2014
New Revision: 216100
URL: https://gcc.gnu.org/viewcvs?rev=216100&root=gcc&view=rev
Log:
PR rtl-optimization/63483
* alias.c (true_dependence_1):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #19 from Uroš Bizjak ---
(In reply to rguent...@suse.de from comment #18)
> Looks ok with all the explanation. I wonder when is the appropriate
> time to retire support for architectures without byte granular
> memory access.
Thank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #18 from rguenther at suse dot de ---
On Thu, 9 Oct 2014, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
>
> Uroš Bizjak changed:
>
>What|Removed |Added
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #17 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #15)
> ... but the attached test check one location only.
I shoud say:
... but the test from the Description depends specifically on the code, touched
by the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
Uroš Bizjak changed:
What|Removed |Added
Attachment #33665|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #15 from Uroš Bizjak ---
(In reply to rguent...@suse.de from comment #14)
> I see. But you don't touch write_dependence which has a similar check.
I have in fact changed all these places (I will attach the patch momentarily),
but t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #14 from rguenther at suse dot de ---
On Thu, 9 Oct 2014, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
>
> --- Comment #13 from Uroš Bizjak ---
> (In reply to Richard Biener from comment #12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #13 from Uroš Bizjak ---
(In reply to Richard Biener from comment #12)
> I still don't get it. What we end up doing is
>
> reg:DI 72 = /u load from 'a' (insn 6)
> reg:DI 78 = /u load from 'b' (insn 15)
> ...
> RMW sequence o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #12 from Richard Biener ---
I still don't get it. What we end up doing is
reg:DI 72 = /u load from 'a' (insn 6)
reg:DI 78 = /u load from 'b' (insn 15)
...
RMW sequence on (mem:DI (reg:DI 72 ...
store to (mem:SI (reg:DI 78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #11 from Uroš Bizjak ---
(In reply to Richard Biener from comment #10)
> Ok, I believe that even
>
> char * const a;
> int * const b;
>
> void foo (void)
> {
> a[1] = 1;
> b[2] = 1;
> }
>
> int bar (void)
> {
> return a && b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #10 from Richard Biener ---
Ok, I believe that even
char * const a;
int * const b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a && b;
}
does not reproduces the issue.
$foo..ng:
.prologue 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> How can I reproduce this? Even with -mcpu=ev4 I get
>
> $foo..ng:
> foo:
> .frame $30,0,$26,0
> $LFB0:
> .cfi_startproc
> .prologue 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #8 from Richard Biener ---
How can I reproduce this? Even with -mcpu=ev4 I get
$foo..ng:
foo:
.frame $30,0,$26,0
$LFB0:
.cfi_startproc
.prologue 0
mov $31,$2
ldq_u $1,1($2)
zapnot $1,2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #7 from rguenther at suse dot de ---
On Wed, 8 Oct 2014, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
>
> --- Comment #6 from Uroš Bizjak ---
> (In reply to Richard Biener from comment #5)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #6 from Uroš Bizjak ---
(In reply to Richard Biener from comment #5)
> The bug is clearly in
>
> "
> > Btw, if the mem is MEM_READONLY_P how can it be part of
> > a {un}aligned_store sequence?
>
> This flag is copied from the origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
Richard Biener changed:
What|Removed |Added
Target||alpha
Component|rtl-optimizati
19 matches
Mail list logo
