http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #22 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Dec 3 12:56:32 2013
New Revision: 205630
URL: http://gcc.gnu.org/viewcvs?rev=205630&root=gcc&view=rev
Log:
Adjust destination address after gen_strset
gcc/
PR target/593
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #21 from Michael Zolotukhin
---
Thanks, HJ! That seems to be the root cause of the fail.
Did I get it right, that you are testing a patch fixing the issue?
Similar issue could be in expand_movmem_epilogue, I'll take a look.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #20 from H.J. Lu ---
expand_setmem_epilogue in i386,c has
if (TARGET_64BIT)
{
dest = change_address (destmem, DImode, destptr);
emit_insn (gen_strset (destptr, dest, value));
emit_insn (gen_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu changed:
What|Removed |Added
Attachment #31356|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #18 from H
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #17 from Markus Trippelsdorf ---
(In reply to H.J. Lu from comment #15)
> It may be a latent bug in amdfam10 scheduler. Before z.i.234r.sched2.
> there are
BTW -mtune=opteron is also affected.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #16 from Andrew Pinski ---
(In reply to H.J. Lu from comment #15)
> It may be a latent bug in amdfam10 scheduler. Before z.i.234r.sched2.
> there are
The question comes down to if the aliasing oracle says if they are conflicting
ones.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu changed:
What|Removed |Added
CC||harsha.jagasia at amd dot com
--- Comment #15 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #14 from Markus Trippelsdorf ---
Further reduced:
markus@x4 tmp % cat test.i
typedef struct {
int ctxlen;
long interhunkctxlen;
int flags;
long find_func;
void *find_func_priv;
int hunk_func;
} xdemitconf_t;
__attribute__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu changed:
What|Removed |Added
Attachment #31346|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #12 from H.J. Lu ---
Smaller testcase:
[hjl@gnu-6 pr59363]$ cat x.h
typedef struct s_xdemitconf {
long ctxlen;
long interhunkctxlen;
unsigned long flags;
unsigned long find_func;
void *find_func_priv;
unsigned long hunk_func;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #11 from H.J. Lu ---
A testcase:
[hjl@gnu-6 pr59363]$ cat x.h
typedef struct s_mmbuffer {
char *ptr;
long size;
} mmbuffer_t;
typedef struct s_mmfile {
char *ptr;
long size;
} mmfile_t;
typedef struct s_xpparam {
unsigned long fl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #10 from H.J. Lu ---
valgrind reports:
==13971== Memcheck, a memory error detector
==13971== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13971== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #9 from H.J. Lu ---
Steps to reproduce this bug on Intel Core i7 processors:
1. Checkout GCC revision 203886.
2. Configure GCC with
--with-arch=corei7 --with-tune=amdfam10
3. Bootstrap/install GCC.
4. Checkout git 1.8.4.4.
5. Config
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #8 from Markus Trippelsdorf ---
To reproduce the issue:
% git clone https://github.com/git/git
% cd git
% vim Makefile (add "-march=amdfam10" to CFLAGS
and point CC to gcc trunk)
% make
% ./git-blame Makefile (cra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #7 from Markus Trippelsdorf ---
Antoine Pelisse explained the control flow:
http://thread.gmane.org/gmane.comp.version-control.git/238629/focus=238631
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #6 from Michael Zolotukhin
---
I wasn't able to reproduce the problem, though I got the same asm-files as you
showed.
However, the both asms look correct to me, and equivalent to each other.
Could the problem be in function xdi_diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #2)
> 22209 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
> 22210 xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
> 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #4 from Markus Trippelsdorf ---
git % cc -v -S -c -O2 -march=native blame.i
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr
--bind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #2 from Markus Trippelsdorf ---
22209 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
22210 xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
22211 {
22212 xpparam_t xpp = {0};
22213 xdemitconf_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #1 from Markus Trippelsdorf ---
Created attachment 31346
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31346&action=edit
preprocessed file
Testcase.
25 matches
Mail list logo
