--- Comment #4 from amylaar at gcc dot gnu dot org 2010-09-01 09:38 ---
The 'uninitialized const members' warning also affects cross builds when
using --enable-build-with-cxx, see PR44670
--
amylaar at gcc dot gnu dot org changed:
What|Removed
--- Comment #20 from amylaar at gcc dot gnu dot org 2010-07-14 20:23
---
(In reply to comment #11)
I wonder if there is any overlap with this bug and PR29404/42308?
libiberty doesn't use $(toplevel_builddir)/gcc/site.exp, so there is no
direct connection, but libiberty/Makefile.in
--- Comment #56 from amylaar at gcc dot gnu dot org 2010-07-13 21:56
---
Subject: Bug 44832
Author: amylaar
Date: Tue Jul 13 21:55:57 2010
New Revision: 162156
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162156
Log:
gcc:
PR other/44874
* tree-dump.c
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-07-13 21:56 ---
Subject: Bug 44874
Author: amylaar
Date: Tue Jul 13 21:55:57 2010
New Revision: 162156
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162156
Log:
gcc:
PR other/44874
* tree-dump.c
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-07-14 04:24 ---
Fixed in trunk.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-07-12 17:16 ---
Subject: Bug 44752
Author: amylaar
Date: Mon Jul 12 17:16:38 2010
New Revision: 162083
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162083
Log:
PR rtl-optimization/44752
* genautomata.c
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-07-12 19:51 ---
Fixed in trunk r162083.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from amylaar at gcc dot gnu dot org 2010-07-12 22:25
---
COMPILER is based on $(CC) / $(CXX), which during testing are overridden
to become the host compiler, i.e. stage 0 for a bootstrap, so to speak.
We want to use @CC@ / @CXX@ to use the same compiler that the latest
--- Comment #16 from amylaar at gcc dot gnu dot org 2010-07-12 22:40
---
Created an attachment (id=21188)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21188action=view)
proposed patch
This patch should restore the use of the previous stage compiler for plugins.
--
http
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
CC||amylaar at gcc dot gnu dot
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-07-12 22:54 ---
(In reply to comment #1)
This patch:
Index: postreload.c
===
--- postreload.c(revision 162085)
+++ postreload.c(working copy
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-07-12 23:45 ---
(In reply to comment #3)
Does the first chunk count as obvious?
I'd say yes.
My boostraps using that hunk with and without --enable-build-with-cxx on
i686-pc-linux-gnu
have progressed past the stage2/stage3
: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44898
--- Comment #54 from amylaar at gcc dot gnu dot org 2010-07-10 09:40
---
Subject: Bug 44832
Author: amylaar
Date: Sat Jul 10 09:40:36 2010
New Revision: 162035
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162035
Log:
2010-07-10 Richard Guenther rguent...@suse.de
at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44901
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-07-10 10:53 ---
Created an attachment (id=21174)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21174action=view)
test case - compressed with xz
$ ./bld-20100708/gcc/xgcc -B./bld-20100708/gcc -c -fpreprocessed -g -O2
-fomit
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-07-11 01:01 ---
(In reply to comment #7)
Created an attachment (id=21173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21173action=view) [edit]
...
let me know if it solve that aspect of the problem for you.
Yes, it does
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-07-11 01:58 ---
(In reply to comment #6)
This still looks broken. Under a normal bootstrap, on x86_64-apple-darwin10,
these new testcases are silently executed against the system compiler rather
than the newly built compiler
--- Comment #9 from amylaar at gcc dot gnu dot org 2010-07-11 04:22 ---
(In reply to comment #8)
Perhaps we just need something like...
No, COMPILER uses CC, too.
The issue is the the toplevel Makefile check-gcc rule
forces CC in the gcc/Makefile via EXTRA_HOST_FLAGS
In the native
--- Comment #49 from amylaar at gcc dot gnu dot org 2010-07-09 10:02
---
I'm working on a fix for 44874, it it seems we are missing references of
LABEL_DECLs by gotos.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- Comment #50 from amylaar at gcc dot gnu dot org 2010-07-09 11:38
---
Created an attachment (id=21157)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21157action=view)
combined ptch for 44832/44874 - WIP
For the unreduced testcase, I see differences regarding the labels
--- Comment #52 from amylaar at gcc dot gnu dot org 2010-07-09 15:06
---
(In reply to comment #49)
I'm working on a fix for 44874, it it seems we are missing references of
LABEL_DECLs by gotos.
Actually, they are marked used when the GIMPLE_LABEL itself is processed.
The problem I
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-07-10 04:24 ---
A patch has been posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00839.html
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #53 from amylaar at gcc dot gnu dot org 2010-07-10 04:44
---
A patch has been posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00840.html
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from amylaar at gcc dot gnu dot org 2010-07-10 05:07
---
Fix checked in trunk revision 161853.
The current problem is tracked as PR44832.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from amylaar at gcc dot gnu dot org 2010-07-08 11:04
---
(In reply to comment #35)
The ordering issue in VRP needs to be fixed. The sorting can use
LABEL_DECL_UID which is dense in a given function. (but watch out
for a -1 value where no UID has been assigned)
I
--- Comment #41 from amylaar at gcc dot gnu dot org 2010-07-08 12:01
---
(In reply to comment #39)
So you say during inlining we end up generating DECL copies in a different
_order_ comparing debug vs. non-debug cases? That would be a bug as well.
Indeed we do; once that is fixed
--- Comment #42 from amylaar at gcc dot gnu dot org 2010-07-08 12:08
---
(In reply to comment #40)
Indeed we do. -g vs. -g0 diff of non-debug decl copying:
How did you get this dump? Enumerating DECLs like this in (-nouid) dump
files seems to be an alternative way to solve the dump
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44874
--- Comment #44 from amylaar at gcc dot gnu dot org 2010-07-08 15:54
---
(In reply to comment #43)
Now, I see that in the non-debug case we are copying the LABEL_DECL while
copying statements while in the debug case we are copying it while
copying the block tree. We have
--- Comment #46 from amylaar at gcc dot gnu dot org 2010-07-08 17:21
---
(In reply to comment #45)
Using TREE_USED isn't really applicable here (we do never re-set it
at least). So an option would be to unconditionally preserve all
!DECL_INGNORED_P labels in BLOCKs.
Which is what
--- Comment #47 from amylaar at gcc dot gnu dot org 2010-07-08 20:00
---
Created an attachment (id=21150)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21150action=view)
proposed patch
(In reply to comment #46)
Could we use a different bit that is currently unused
--- Comment #48 from amylaar at gcc dot gnu dot org 2010-07-09 03:38
---
(In reply to comment #47)
I'm currently testing the attached patch.
Successfully bootstrapped ergtested in trunk revision 161952, both
with without --enable-build-with-cxx.
The only difference in the test
--- Comment #13 from amylaar at gcc dot gnu dot org 2010-07-07 13:15
---
(In reply to comment #12)
Hm, different SSA name versions are not good - that might cause
code generation differences. Where do they first differ?
t.c.025t.einline2 / t.c.gk.025t.einline2
--
http
--- Comment #14 from amylaar at gcc dot gnu dot org 2010-07-07 13:22
---
(In reply to comment #12)
$ diff -u -I '^ # DEBUG.*$' t.c.025t.* t.c.gk.025t.*
--- t.c.025t.einline2 2010-07-07 13:59:11.251978485 +0100
+++ t.c.gk.025t.einline22010-07-07 13:59:11.451101846 +0100
--- Comment #17 from amylaar at gcc dot gnu dot org 2010-07-07 13:48
---
(In reply to comment #16)
Maybe I'm blind, but the SSA name versions are all the same in
the above diff.
The ssa name 1881 gets changed to 1882, isn't that significant?
--
http://gcc.gnu.org/bugzilla
--- Comment #20 from amylaar at gcc dot gnu dot org 2010-07-07 14:00
---
Created an attachment (id=21123)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21123action=view)
typescript looking at inrements of next_decl_uid
The last ssa name before 1881 in the dump files is 1872; so
--- Comment #21 from amylaar at gcc dot gnu dot org 2010-07-07 14:02
---
(In reply to comment #19)
Yes, that's ok. I'm re-reducing the testcase (which also fails with
-fno-ivopts).
FWIW I've reduced the testcase with the aim of reproducing the problem in
r160832, which is when
--- Comment #22 from amylaar at gcc dot gnu dot org 2010-07-07 14:06
---
(In reply to comment #18)
That's not SSA name, but DECL_UID of the underlying decl.
I believe such changes are considered ok if it just means different gaps
between uids with -g vs. -g0.
For compiler-generated
--- Comment #25 from amylaar at gcc dot gnu dot org 2010-07-07 14:47
---
Created an attachment (id=21125)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21125action=view)
diff -u -I '^ # DEBUG.*$' t.c.093t.pre t.c.gk.093t.pre
Disregarding where merely the base names of ssa name
--- Comment #27 from amylaar at gcc dot gnu dot org 2010-07-07 14:56
---
(In reply to comment #26)
The first difference appears in .093t.pre (comparing -nouid dumps):
cat ii386.3.3.i.gk.094t.pre | grep -v '# DEBUG' | diff -u ii386.3.3.i.094t.pre
- | less
is that .093t.pre
--- Comment #29 from amylaar at gcc dot gnu dot org 2010-07-07 15:06
---
(In reply to comment #26)
thus I think we have to look for an instability in the SCC walker.
There's a qsort call. Is compare_ops guaranteed never to return 0 for
items that are not identical?
--
http
--- Comment #30 from amylaar at gcc dot gnu dot org 2010-07-07 17:27
---
(In reply to comment #28)
No, the culprit is loop header copying which causes
I also see changes in the MEM_* after loop header copying.
It happens during the second call of copy_loop_header. Alas,
it seems
--- Comment #31 from amylaar at gcc dot gnu dot org 2010-07-07 17:50
---
(In reply to comment #30)
The first difference I seen in debug / no debug values of
cfun-gimple_df-free_ssanames-ssa_name.version for the relevant function
is in vrp.
Debug:
Hardware watchpoint 10: cfun
--- Comment #32 from amylaar at gcc dot gnu dot org 2010-07-07 19:53
---
tree-vrp.c:find_switch_asserts uses compare_case_labels to sort case labels,
with the main key being the uid of the case label.
We have different case labels when debugging, and their uid sorts differently
--- Comment #33 from amylaar at gcc dot gnu dot org 2010-07-08 01:00
---
pop_labels_1 installs the LABEL_DECL of half in BLOCK_VARS:
Breakpoint 16, pop_labels_1 (slot=0xb7d86f94, data=0xb7d95068)
at ../../gcc/gcc/cp/decl.c:384
384 struct named_label_entry *ent = (struct
--- Comment #34 from amylaar at gcc dot gnu dot org 2010-07-08 01:10
---
FWIW, this simple patch stops the comparison failures both for my reduced
testcase as for the original testcase. I'm not sure if we want to
pay the price of carryinig more labels around for -g0, or if we'd rather
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-07-06 13:18 ---
Created an attachment (id=21106)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21106action=view)
i386.c preprocessed source
/user/inria/fsf/161802/bld-1/./prev-gcc/cc1plus -fpreprocessed i386.ii -quiet
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-07-06 14:42 ---
(In reply to comment #4)
Reverting up to r161801 still gets me
./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i
-fcompare-debug
g++: error: ii386.i: -fcompare-debug failure (length)
so
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-07-06 14:51 ---
(In reply to comment #4)
Reverting up to r161801 still gets me
./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i
-fcompare-debug
I've tried this with --save-temps in r161600 and there's lots
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-07-06 15:03 ---
(In reply to comment #4)
./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug
Works with g++ (GCC) 4.6.0 20100613 (experimental), fails with
g++ (GCC) 4.6.0 20100617 (experimental
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-07-06 18:21 ---
(In reply to comment #4)
Reverting up to r161801 still gets me
./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i
-fcompare-debug
g++: error: ii386.i: -fcompare-debug failure (length)
Works
--- Comment #9 from amylaar at gcc dot gnu dot org 2010-07-07 01:42 ---
Created an attachment (id=21117)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21117action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- Comment #10 from amylaar at gcc dot gnu dot org 2010-07-07 02:00
---
;; Function void ix86_expand_vector_init_general(bool, machine_mode, rtx, rtx)
Compiling the reduced testcase in a subdirectory of the r160832 gcc build
directory with:
../g++ -B.. -da -march=pentiumpro -mtune
--- Comment #11 from amylaar at gcc dot gnu dot org 2010-07-07 02:16
---
(In reply to comment #10)
;; Function void ix86_expand_vector_init_general(bool, machine_mode, rtx,
rtx)
Compiling the reduced testcase in a subdirectory of the r160832 gcc build
directory with:
../g++ -B
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-07-05 20:14 ---
(In reply to comment #5)
Created an attachment (id=21088)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21088action=view) [edit]
patch which needs testing
I have not tested this fix but it should work
--- Comment #9 from amylaar at gcc dot gnu dot org 2010-07-05 20:18 ---
Subject: Bug 44512
Author: amylaar
Date: Mon Jul 5 20:18:07 2010
New Revision: 161853
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161853
Log:
PR bootstrap/44512
* genenums.c (main): Output
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-07-05 23:15 ---
*** Bug 44829 has been marked as a duplicate of this bug. ***
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-07-05 23:15 ---
*** This bug has been marked as a duplicate of 44825 ***
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
OtherBugsDependingO 44433
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-07-06 05:25 ---
Adding -gtoggle to the options to compile the stage3 i386.o gives the same
assembly as stage2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-07-02 08:27 ---
Here is my patch:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00085.html
bootstrap regtest finished successfully on i686-pc-linuc-gnu in trunk
revision 161664.
--
amylaar at gcc dot gnu dot org changed
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-07-01 09:44 ---
What is the target triple from config.guess? I've tried cross compilers
from i686-pc-linux-gnu to ia64-elf and ia64-linux-gnu
(using ccc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)), but I get lots
of extra errors
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-07-01 10:27 ---
Subject: Bug 44732
Author: amylaar
Date: Thu Jul 1 10:27:34 2010
New Revision: 161658
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161658
Log:
PR target/44732
* config/ia64/ia64.c
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-07-01 10:35 ---
(In reply to comment #6)
Created an attachment (id=21054)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21054action=view) [edit]
preprocessed source
Preprocessed source of ia64.i for your convenience
--- Comment #10 from amylaar at gcc dot gnu dot org 2010-07-01 10:49
---
As I used cut paste for a few repeated stanzas, I just checked if
there was any more of the same.
Once you know what it is, it's easy to find in the patch:
[amyl...@laria ~]$ grep -A 5 -B 5 '^+[ ]*{' 44566
--- Comment #12 from amylaar at gcc dot gnu dot org 2010-07-01 11:18
---
Created an attachment (id=21056)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21056action=view)
* ia64_register_move_cost (Fix argument types).
Yes, it was my patch.
With the attached patch
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: mep
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: pdp-elf
http://gcc.gnu.org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44751
: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: crx-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44752
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-07-01 15:59 ---
Actually, crx is not the only target with this problem:
avr-elf/make.out:insn-automata.c:1:0: error: ISO C forbids an empty translation
unit [-Werror=edantic]
cris-elf/make.out:insn-automata.c:1:0: error: ISO C
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: m32c-elf
http://gcc.gnu.org/bugzilla
enum types mismatch
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot
Keywords: meta-bug
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
BugsThisDependsOn: 44749,44750,44751,44752,44754,44755
http://gcc.gnu.org/bugzilla/show_bug.cgi
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: lm32-elf
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: frv-elf
OtherBugsDependingO
: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: mn10300-elf
OtherBugsDependingO 44756
nThis
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: iq2000-elf
OtherBugsDependingO 44756
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44760
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: sh-elf
OtherBugsDependingO 44756
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44761
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: score-elf
OtherBugsDependingO 44756
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44762
dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: rx-elf
OtherBugsDependingO 44756
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44764
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: xtensa-elf
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: arc-elf
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: bfin-elf
OtherBugsDependingO 44756
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44767
: amylaar at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: spu-elf
OtherBugsDependingO 44756
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44769
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: m32r-elf
OtherBugsDependingO 44756
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44770
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: m68k-elf
OtherBugsDependingO 44756
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44771
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-07-01 19:14 ---
Alternatively, we could hookize FLOAT_WORDS_BIG_ENDIAN, and make jcf-parse.c
include target.h so it gets access to the target vector. This would also
be better since then the code in jfc-parse.c no longer depends
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-07-01 22:39 ---
(In reply to comment #2)
Is that really printing -Werror=edantic or a problem copy+pasting?
Yes, it's really printing that.
I think that that's because gcc thinks -pedantic starts with -W...
in opts.c:option_name
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-06-30 18:48 ---
Subject: Bug 44566
Author: amylaar
Date: Wed Jun 30 18:47:43 2010
New Revision: 161633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161633
Log:
PR other/44566
* coretypes.h [!USED_FOR_TARGET
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-06-30 19:08 ---
Patch committed to mainline.
AFAIK the only lingering issue is this one:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html
(And of course the stuff that needs some help from the FSF - PR44035, PR44033
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-06-29 18:22 ---
Subject: Bug 44034
Author: amylaar
Date: Tue Jun 29 18:22:00 2010
New Revision: 161547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161547
Log:
gcc:
PR other/44034
* target.def, doc
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-29 19:13 ---
Sorry, I certainly didn't mean to put a rule there; not sure if it was a typo
or some smartass-autoindent running wild.
I've removed the offending tab.
--
amylaar at gcc dot gnu dot org changed
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-06-26 10:22 ---
The patches have been tested posted to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02492.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02452.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02495
1 - 100 of 794 matches
Mail list logo
