http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
remove_pseudos in lra-spills.c failed to handle
REG_CFA_SET_VDRAP note.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.9.0
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 31313
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31313action=edit
A patch
I am testing this patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 31315
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31315action=edit
A patch
I don't know why this patch works.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com ---
-print-prog-name=foobar gives the path name of program, foobar.
which isn't necessarily used by the GCC driver:
[hjl@gnu-6 gcc-4.6.3-x32]$ ./bin/gcc -print-prog-name=as
as
[hjl@gnu-6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Last reconfirmed|2013-11-28 00:00:00 |2012-09-25 0:00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
I won't call it exactly a regression since -mavx is a new
option and -march=native adds -mavx implicitly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59309
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59214
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: rguenth at gcc dot gnu.org
On Linux/x86, r205486 caused:
FAIL: 22_locale/locale/cons/12438.cc execution test
FAIL: gcc.dg/tree-ssa/alias-25.c scan-tree-dump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59334
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59309
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Richard Biener from comment #4)
Likely a update_address_taken bug, eventual fix:
@@ -1329,6 +1336,10 @@ non_rewritable_mem_ref_base (tree ref)
if (DECL_P (ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 31333
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31333action=edit
A patch
This patch teaches gcc.c to append .bfd/.gold to ld if
-fuse-ld=XXX is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
This is not what I see with GCC 4.9.0:
[hjl@gnu-tools-1 tools-4.9]$ ls release/usr/gcc-4.9.0/bin/
x86_64-linux-addr2line x86_64-linux-gcc x86_64-linux-ld.gold
x86_64-linux-ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #31333|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #31335|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Summary|-fuse-ld does not have |-fuse-ld has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Summary|-fuse-ld has no effect on |-fuse-ld has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #31336|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
--- Comment #16 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 31341
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31341action=edit
A patch with ChangeLog
Add ChangeLog.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59362
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321
--- Comment #18 from H.J. Lu hjl.tools at gmail dot com ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00061.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||hjl.tools at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Richard Biener from comment #7)
Created attachment 31347 [details]
fixed patch
In testing.
It doesn't work for me:
0xdbb0f6 tree_contains_struct_check_failed(tree_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||hjl.tools at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #31346|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||harsha.jagasia at amd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #31356|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #20 from H.J. Lu hjl.tools at gmail dot com ---
expand_setmem_epilogue in i386,c has
if (TARGET_64BIT)
{
dest = change_address (destmem, DImode, destptr);
emit_insn (gen_strset (destptr, dest, value
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: davidxl at google dot com
r201645 added -mmemcpy-strategy= and -mmemset-strategy=.
But there is no documentation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59376
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: areg.melikadamyan at gmail dot com
On Linux/x86-64, when GCC revision 205645 configured with
--enable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
Symptom is msgfmt never stops:
30751 pts/0t 43:26 msgfmt -o de.mo
/export/gnu/import/git/gcc/libstdc++-
30752 pts/0R 64:42 msgfmt -o fr.mo
/export/gnu/import/git/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Markus Trippelsdorf from comment #1)
Maybe a dup of Bug59003?
Maybe.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 31372
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31372action=edit
A testcase
The outputs from stage 2 and stage 3 cc1 are different:
[hjl@gnu-mic-2 pr59379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Summary|gomp_init_num_threads is|[4.9 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59380
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59380
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||cnstar9988 at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Stupachenko Evgeny from comment #7)
Created attachment 31379 [details]
patch to ipa-inline.c for 4.8
Is this a backport from trunk? If yes, please identify which
checkin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||evstupac at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
r202807 can bootstrap. But r202811 failed with
[hjl@gnu-mic-2 libgcc]$
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/./gcc/xgcc
-B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to H.J. Lu from comment #7)
r202807 can bootstrap. But r202811 failed with
The only difference in GCC source is:
diff --git a/gcc/DATESTAMP b/gcc/DATESTAMP
index 0f54f2b
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
r205700 breaks bootstrap for x32:
http://gcc.gnu.org/ml
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
A small run-time testcase. It went into an finite loop at -O.
---
[hjl@gnu-mic-2 pr59379]$ cat main.c
#include stdlib.h
typedef unsigned long int __cpu_mask;
void *
__attribute__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #3)
(In reply to H.J. Lu from comment #2)
(In reply to Kostya Serebryany from comment #1)
Thanks for the report, H.J. I'll try to respond
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com ---
I think this is a dup of PR48397.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On x32, r205737 gave
Running 253.perlbmk ref peak lto default
*** Miscompare of 850.5.19.18.1500.out, see
/export/gnu/import/git/gcc-test-spec-lto/spec/2000
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
On a Linux/x86-64 machine with 4GB RAM, I got failures like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
On failed machine:
[hjl@gnu-ivb-1 ~]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #3)
(In reply to H.J. Lu from comment #0)
On a Linux/x86-64 machine with 4GB RAM, I got failures like:
FAIL: c-c++-common/tsan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com ---
For some reason, tsan tests aren't run on 6GB machine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #11)
4000-5000 r-xp 08:11 34221424
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #18 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #16)
Kernel is free to load PIE at ANY address it wants. But
you can specify where to load PIE via a linker switch
-Ttext-segment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #19 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to H.J. Lu from comment #18)
(In reply to Kostya Serebryany from comment #16)
Kernel is free to load PIE at ANY address it wants. But
you can specify where to load PIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #21 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #20)
# readelf -lW a.out
Your address must be sensible. Otherwise kernel will ignore it.
Please try -Ttext-segment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #23 from H.J. Lu hjl.tools at gmail dot com ---
I opened:
https://bugzilla.kernel.org/show_bug.cgi?id=66721
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #24 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #22)
That is true. The kernel change was made to fix:
https://bugzilla.kernel.org/show_bug.cgi?id=36372
Could you please explain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com ---
Should it consider both *first_niters and scalar_loop_iters?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to rguent...@suse.de from comment #7)
hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #26 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #25)
https://bugzilla.kernel.org/show_bug.cgi?id=66721
Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS.
Any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
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 #12 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #13 from H.J. Lu hjl.tools at gmail dot com ---
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220 Perl_sv_mortalcopy
44098f: 67 89 03mov%eax,(%ebx)
440992
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to H.J. Lu from comment #13)
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220 Perl_sv_mortalcopy
44098f: 67 89 03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #15 from H.J. Lu hjl.tools at gmail dot com ---
This
char *
my_bcopy(register char *from,register char *to,register I32 len)
{
char *retval = to;
if (from - to = 0) {
while (len--)
*to++ = *from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #16 from H.J. Lu hjl.tools at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #17 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #18 from H.J. Lu hjl.tools at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #21 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to rguent...@suse.de from comment #20)
--- Comment #19 from H.J. Lu hjl.tools at gmail dot com ---
Adding -fno-strict-aliasing fixed the problem.
If using Perl_my_bcopy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #31 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Jakub Jelinek from comment #29)
It is not that easy. gold before February 2013 doesn't grok -Ttext-segment,
you need -Ttext there instead. See
http://gcc.gnu.org/ml/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #22 from H.J. Lu hjl.tools at gmail dot com ---
(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=59429
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com ---
gold has
--icf [none,all,safe] Identical Code Folding. '--icf=safe' Folds ctors,
dtors and functions whose pointers are definitely not taken.
which should help it at link-time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Andrew Pinski from comment #3)
(subreg:DI
+ (match_operand:V4SF 1 register_operand
+ x,x) 0)
That is not a valid subreg and should have be rejected
301 - 400 of 7246 matches
Mail list logo
