http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #22 from H.J. Lu ---
(In reply to H.J. Lu from comment #21)
>
> > HAS_SAFE_BCOPY will fix it?
>
No, it doesn't work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #21 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #20)
> > --- Comment #19 from H.J. Lu ---
> > Adding -fno-strict-aliasing fixed the problem.
>
> If using Perl_my_bcopy is the problem then maybe defining
I can give i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #20 from rguenther at suse dot de ---
On Mon, 9 Dec 2013, hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>
> H.J. Lu changed:
>
>What|Removed |Added
> -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #18 from H.J. Lu ---
(In reply to H.J. Lu from comment #17)
> Perl_my_bcopy (len=31, to=0xf7fd801d "\021q", from=0x8023f0 "\264\005q")
> is miscompiled when inlined:
>
> Old value = 19935280
> New value = 808464432
> Perl_my_bcopy (le
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #17 from H.J. Lu ---
Perl_my_bcopy (len=31, to=0xf7fd801d "\021q", from=0x8023f0 "\264\005q")
is miscompiled when inlined:
Old value = 19935280
New value = 808464432
Perl_my_bcopy (len=-1, to=0xf7fd803c "\260Vx", from=) at
util.c:1559
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #16 from H.J. Lu ---
(In reply to H.J. Lu from comment #15)
> This
>
> char *
> my_bcopy(register char *from,register char *to,register I32 len)
> {
> char *retval = to;
>
> if (from - to >= 0) {
> while (len--)
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #15 from H.J. Lu ---
This
char *
my_bcopy(register char *from,register char *to,register I32 len)
{
char *retval = to;
if (from - to >= 0) {
while (len--)
*to++ = *from++;
}
else {
to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #14 from H.J. Lu ---
(In reply to H.J. Lu from comment #13)
> loop in Perl_pp_aassign is miscompiled:
>
> 44098a: e8 91 38 05 00 callq 494220
> 44098f: 67 89 03mov%eax,(%ebx)
> 440992:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #13 from H.J. Lu ---
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220
44098f: 67 89 03mov%eax,(%ebx)
440992: 83 c3 04add$0x4,%ebx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #12 from H.J. Lu ---
This function:
SV *
sv_mortalcopy(SV *oldstr)
{
dTHR;
register SV *sv;
new_SV(sv);
SvANY(sv) = 0;
SvREFCNT(sv) = 1;
SvFLAGS(sv) = 0;
sv_setsv(sv,oldstr);
if (++PL_tmps_ix >= PL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #11 from H.J. Lu ---
latch execution count can be an expression like "if (b)" in
gcc.dg/torture/pr59058.c. Will such an expression be possible
negative at run-time?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #10 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #9)
> >
> >Is that ever possible to have latch execution count < 0
> >and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
>
> That should be impossible.
>
That is wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #9 from rguenther at suse dot de ---
"hjl.tools at gmail dot com" wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>
>--- Comment #8 from H.J. Lu ---
>(In reply to rguent...@suse.de from comment #7)
>> "hjl.tools at gmail do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #8 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #7)
> "hjl.tools at gmail dot com" wrote:
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
> >
> >--- Comment #3 from H.J. Lu ---
> >slpeel_tree_peel_loop_to_edge ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #7 from rguenther at suse dot de ---
"hjl.tools at gmail dot com" wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>
>--- Comment #3 from H.J. Lu ---
>slpeel_tree_peel_loop_to_edge has comments:
>
> The first guard is:
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #6 from H.J. Lu ---
Starting program:
/export/project/git/gcc-regression/spec/2000/spec/benchspec/CINT2000/253.perlbmk/run/0002/../0002/perlbmk_peak.lto
-I./lib diffmail.pl 2 550 15 24 23 100 > /dev/null
Program received signa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> Should it consider both *first_niters and scalar_loop_iters?
Something like this
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 380fd22..3f85cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #4 from H.J. Lu ---
Should it consider both *first_niters and scalar_loop_iters?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J. Lu ---
slpeel_tree_peel_loop_to_edge has comments:
The first guard is:
if (FIRST_NITERS == 0) then skip the first loop,
and go directly to the second loop.
This is removed by r205730.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #2 from H.J. Lu ---
Revert
--
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index f2fdc99..380fd22 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -1061,7 +1061,6 @@ slpeel_tree_peel_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
22 matches
Mail list logo
