--- Comment #2 from hjl dot tools at gmail dot com 2010-06-25 15:34 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-25 16:43 ---
Another testcase:
[...@gnu-6 44659]$ cat extract-3.c
typedef struct
{
unsigned char c1;
unsigned char c2;
unsigned char c3;
unsigned char c4;
} foo_t;
int
foo (foo_t x)
{
return x.c2 != 0;
}
[...@gnu-6
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-25 17:50 ---
It is caused by revision 150519:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00199.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44659
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-24 22:41 ---
X86 backend has special support for
(zero_extract:SI (reg:M N) (const_int 8) (const_int 8))
If backend provides zero_extract, shouldn't we preserve it?
--
hjl dot tools at gmail dot com changed
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-24 22:43 ---
Created an attachment (id=20999)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20999action=view)
A patch
With this patch, I got
[...@gnu-6 divb]$ cat umod-4.c
int
foo (unsigned char x, unsigned char y
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-25 03:38 ---
It is caused by revision 152236:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00987.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-22 17:29
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-22 17:30 ---
The patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02200.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-21 14:32 ---
Test starts to pass between revision 161046 and revision
161055 on Linux/ia64. Does anyone know which checkin fixes
this? This that a real fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
-vec-2.c and amd64-abi-3.c
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-21 16:42 ---
(In reply to comment #0)
FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t
]*%rsp
This is due to -mtune=atom generates:
leaq-88(%rsp), %rsp
instead of
subq$88
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-21 16:45 ---
(In reply to comment #0)
FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error)
FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors)
I got
/export/build/gnu/gcc-atom/build-x86_64-linux/gcc/xgcc
-B
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-21 17:23 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02058.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-21 20:57
---
Revision 161041 deosn't fix it on Linux/x86-64. I got
valgrind --tool=memcheck ./f951
/export/gnu/import/rrs/161041/src/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-21 21:00
---
Revision 161061 has the same bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-19 19:03 ---
Created an attachment (id=20943)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20943action=view)
An updated patch
8bit divide is AX / r/m8. Here is the updated patch.
Now it generates:
foo:
.LFB0
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-20 01:59 ---
Created an attachment (id=20944)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20944action=view)
Another update
This patch removes EFLAGS clobber for sign extend.
--
hjl dot tools at gmail dot com changed
: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583
: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-18 22:11 ---
I got
Starting program: /export/gnu/import/svn/gcc-test/bld/gcc/f951
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03 -auxbase
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-18 22:14 ---
On x86, I got
valgrind --tool=memcheck ../f951
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03 -mtune=generic -march=pentium4
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-19 00:47 ---
(In reply to comment #5)
Ok, actually I also get an ICE. But for some reason only when compiling by
hand, not in the testsuite.
It is fixed by this patch:
Index: gcc/fortran/resolve.c
: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44588
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-19 00:52 ---
Created an attachment (id=20941)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20941action=view)
A patch
With this patch, I got
foo:
.LFB0:
.cfi_startproc
movl%edi, %eax
divb
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-17 22:01 ---
Created an attachment (id=20934)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20934action=view)
A patch to split cast
Here is a patch to split cast. But it doesn't remove
redundant vinsertf128/vextractf128. I
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-18 00:46 ---
Can we use subreg instead of vec_select?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
--- Comment #14 from hjl dot tools at gmail dot com 2010-06-16 14:36
---
The code in question is
offset -= frame_phase;
align = offset -offset;
align *= BITS_PER_UNIT;
if (align == 0)
align = STACK_BOUNDARY;
else if (align
--- Comment #16 from hjl dot tools at gmail dot com 2010-06-16 15:38
---
(In reply to comment #15)
2) even when get_decl_align_unit returns something small, the decl might still
get a nicely aligned slot (say offset 64). If it is known at this point
that virtual_stack_vars_rtx
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-16 19:50 ---
The problem is UNSPEC_CAST. There is no good way to model it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-16 20:42 ---
You can cast 256bit to 128bit to get the lower 128bit. You can also
cast 128bit to 256bit with upper 128bit undefined. If I use union,
it will always generate 2 moves via memory.
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-15 14:46 ---
I watched crtl-stack_alignment_estimated in gdb
with the testcase in comment #2. I didn't see it
set to 256.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-15 15:39 ---
(In reply to comment #7)
Jakub was not talking about crtl-stack_alignment_estimated becoming 256,
but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.
I set the breakpoint
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-15 17:13
---
Created an attachment (id=20920)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20920action=view)
A patch to use alignment
If we already know the alignment we need, why not use it? Here is
a patch does
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-15 17:20
---
Created an attachment (id=20921)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20921action=view)
An updated patch
I don't see why expand_one_stack_var_at should compute alignment
when its callers know what
--- Comment #12 from hjl dot tools at gmail dot com 2010-06-15 17:25
---
Created an attachment (id=20922)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20922action=view)
A new patch
Fix typo and update comments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-15 18:07 ---
It is caused by revision 149035:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|4.5 ICE in extract_insn, at |[4.5/4.6 Regression] ICE in
|recog.c:2103
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-14 17:05 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01443.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-14 18:09 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-14 21:33 ---
It is caused by revision 159596:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00649.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-14 21:39 ---
It is caused by revision 160124:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00036.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-15 00:57 ---
We should consider:
1. The x86-64 psABI doesn't say how char/short should be extended
as function parameters.
2. Gcc may not touch upper bits, PR 42324.
3. Gcc never depends on the upper bits which are properly
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-12 15:21 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-12 15:21 ---
*** This bug has been marked as a duplicate of 44498 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-12 15:21 ---
*** Bug 44497 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44498
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-12 15:24 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-12 15:52 ---
It is caused by revision 149526:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00406.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-11 18:24 ---
It is caused by revision 121863:
http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00421.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-11 21:36 ---
It is caused by revision 160615:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00530.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-10 14:30
---
(In reply to comment #10)
(In reply to comment #9)
Following patch is also needed to fix conditional splitting (it does not
fix
original uncovered problem where BLOCK_FOR_INSN returns null):
I am
--- Comment #15 from hjl dot tools at gmail dot com 2010-06-10 15:43
---
(In reply to comment #14)
(In reply to comment #11)
ADD is always faster than LEA for adding a register. However
there is a special case on Atom where ADD should be avoided.
It is true that LEA doesn't
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-10 23:02 ---
I got
[...@gnu-29 testsuite]$ ../gfortran -B../ -S
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/maxlocval_2.f90
-O1
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44498
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-10 23:20 ---
From:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01081.html
if (!df_live_scratch)
-df_live_scratch = BITMAP_ALLOC (NULL);
+df_live_scratch = BITMAP_ALLOC (problem_data-live_bitmaps
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-10 22:40 ---
It is caused by revision 160549:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00464.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-10 22:54 ---
mesa in SPEC CPU 2000 failed to compile:
/export/gnu/import/rrs/160549/usr/bin/gcc -S -DSPEC_CPU2000_LP64 -O2
-ffast-math -O3 -ffast-math -funroll-loops vbfill.c
gnu-32:pts/5[189] /export/gnu/import
--- Comment #17 from hjl dot tools at gmail dot com 2010-06-10 19:16
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-10 22:02 ---
The testcase failed on Linux/ia64 at -O:
[...@gnu-12 gcc]$ ./xgcc -B./ -O
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr42461.c
/tmp/ccmdb99H.o: In function `main':
pr42461.c:(.text+0x22
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44497
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-10 22:42 ---
The error looks like:
/export/gnu/import/rrs/160549/src/libgomp/testsuite/libgomp.fortran/task1.f90:
In function 'MAIN__._omp_fn.1':^M
/export/gnu/import/rrs/160549/src/libgomp/testsuite/libgomp.fortran/task1.f90
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-09 14:13 ---
(In reply to comment #4)
(In reply to comment #1)
It may be broken by revision 160394:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
The add-lea transformation doesn't even trigger in this testcase
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-09 14:16 ---
Whatever we do, we need to preserve Atom add-lea optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 16:56 ---
It is caused by revision 142799:
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00498.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 20:30 ---
(In reply to comment #6)
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):
I am not sure this is correct. The code
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.6.0
http
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-09 21:40 ---
It is caused by revision 160124:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00036.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-09 22:06 ---
It is caused by revision 159886:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00942.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44490
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-10 05:23 ---
This patch
---
iff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index a33d3af..6f569cc 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -820,7 +820,10
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42500
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-08 16:47 ---
It is caused by revision 145494:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-08 22:00 ---
It may be broken by revision 160394:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-09 00:52 ---
(In reply to comment #1)
It may be broken by revision 160394:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
This change moved
(insn:TI 11 41 12 pr44470.i:15 (parallel [
(set (reg:SI 1 dx
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-09 00:59 ---
The old scheduler:
;; ==
;; -- basic block 2 from 37 to 42 -- after reload
;; ==
;;0--37
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-09 03:26 ---
(In reply to comment #0)
While running some tests against SSE4.2 instructions, I noticed that the
__builtin_ia32_pcmpestri128 method generates the correct pcmpestri call
followed immediately by an extraneous
g++.dg/torture/pr32304.C
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44454
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-07 21:09 ---
FAIL: gcc.dg/sms-3.c (internal compiler error)
FAIL: gcc.dg/sms-3.c (test for excess errors)
FAIL: gcc.dg/sms-4.c (internal compiler error)
FAIL: gcc.dg/sms-4.c (test for excess errors)
FAIL: gcc.dg/sms-6.c
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-04 13:08 ---
(In reply to comment #1)
Because our tree reassoc doesn't re-associate them.
The tree reassoc pass makes it slower:
[...@gnu-6 44382]$ cat x.i
extern int a, b, c, d, e, f;
void
foo ()
{
a = (b * c) * (d * e
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-04 13:26 ---
It may be caused by revision 160231:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00144.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-04 13:56 ---
(In reply to comment #3)
Yes, reassoc linearizes instead of building a tree (saves one (or was it two?)
registers at best).
Should we always build a tree? It may increase register pressure.
--
http
--- Comment #5 from hjl dot tools at gmail dot com 2010-06-04 14:40 ---
tree-ssa-reassoc.c has
2. Left linearization of the expression trees, so that (A+B)+(C+D)
becomes (((A+B)+C)+D), which is easier for us to rewrite later.
During linearization, we place the operands
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-04 16:40 ---
(In reply to comment #7)
As the author of the benchmark I can confirm that we apparently forgot
to include the proper header file. So you can call it a defect in 447.dealII.
The question is how to deal
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-04 20:15 ---
Created an attachment (id=20848)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20848action=view)
The src.alt for 447.dealII
This works for me. Can someone try it?
--
http://gcc.gnu.org/bugzilla
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44421
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-05 00:39 ---
It affects targets which define EH_USES:
ia64/ia64.h:#define EH_USES(REGNO) ia64_eh_uses (REGNO)
m32c/m32c.h:#define EH_USES(REGNO) 0 /* FIXME */
mips/mips.h:#define EH_USES(N) mips_eh_uses (N)
--
hjl dot
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-03 14:55 ---
Fixed by revision 159343:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00395.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
c_lto_20100603-2_0.o
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-03 22:12 ---
I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ c_lto_20100603-2_0.o -O0
-fwhopr -r -nostdlib -m32 -o gcc-dg-lto-20100603-2-01
++
test failures
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-04 04:38 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
501 - 600 of 3333 matches
Mail list logo
