--- Comment #46 from jamborm at gcc dot gnu dot org 2009-10-06 13:31
---
Subject: Bug 41395
Author: jamborm
Date: Tue Oct 6 13:31:40 2009
New Revision: 152492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152492
Log:
2009-10-06 Martin Jambor mjam...@suse.cz
PR
--- Comment #47 from jamborm at gcc dot gnu dot org 2009-10-06 14:11
---
Finally, all problems that have cause this havoc are fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #44 from jamborm at gcc dot gnu dot org 2009-10-01 11:30
---
Subject: Bug 41395
Author: jamborm
Date: Thu Oct 1 11:30:12 2009
New Revision: 152366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152366
Log:
2009-10-01 Martin Jambor mjam...@suse.cz
PR
--- Comment #45 from jamborm at gcc dot gnu dot org 2009-10-01 14:47
---
Right, so I belieive all problems that were reported here (and were
indeed relevant to IPA-SRA) are now dealt with. x86_64 and i386
bootstraps and checks nicely with both yes and release checking,
alpha
--- Comment #40 from ubizjak at gmail dot com 2009-09-30 08:12 ---
(In reply to comment #39)
static tree
build_function_type_list_1 (bool vaargs, tree return_type, va_list argp)
Passing va_list by value is non-portable. One fix here is to pass argp
by reference. Dunno if that
--- Comment #41 from jamborm at gcc dot gnu dot org 2009-09-30 11:35
---
(In reply to comment #38)
(In reply to comment #37)
Can you please attach pre-processed source of it so that I can try
running it through a cross-compiler?
Additionally, -fdump-tree-cddce-slim and
--- Comment #42 from jamborm at gcc dot gnu dot org 2009-09-30 11:37
---
Created an attachment (id=18676)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18676action=view)
Making IPA-SRA ignore va_lists
This patch prevents IPA-SRA from considering va_list structs as candidates for
--- Comment #43 from ubizjak at gmail dot com 2009-09-30 13:34 ---
(In reply to comment #42)
Created an attachment (id=18676)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18676action=view) [edit]
Making IPA-SRA ignore va_lists
This patch prevents IPA-SRA from considering
--- Comment #37 from jamborm at gcc dot gnu dot org 2009-09-29 16:16
---
(In reply to comment #34)
It is tree.o object of stage2 gcc that gets miscompiled when -fipa-sra is
added
to BOOT_CFLAGS. If tree.o is substituted with the one from the build without
BOOT_CFLAGS, gcc is again
--- Comment #38 from ubizjak at gmail dot com 2009-09-29 18:36 ---
(In reply to comment #37)
Can you please attach pre-processed source of it so that I can try
running it through a cross-compiler?
Additionally, -fdump-tree-cddce-slim and -fdump-tree-eipa_sra-details
dumps would
--- Comment #39 from rth at gcc dot gnu dot org 2009-09-29 20:54 ---
(In reply to comment #35)
static tree
build_function_type_list_1 (bool vaargs, tree return_type, va_list argp)
Passing va_list by value is non-portable. One fix here is to pass argp
by reference. Dunno if that
--- Comment #34 from ubizjak at gmail dot com 2009-09-27 12:35 ---
It is tree.o object of stage2 gcc that gets miscompiled when -fipa-sra is added
to BOOT_CFLAGS. If tree.o is substituted with the one from the build without
BOOT_CFLAGS, gcc is again able to compile hello.c without
--- Comment #35 from ubizjak at gmail dot com 2009-09-27 14:29 ---
Bingo!
It is build_function_type_list_1 from tree.c that makes problems:
static tree
build_function_type_list_1 (bool vaargs, tree return_type, va_list argp)
This probably makes alpha specific bootstrap failure
--- Comment #36 from ubizjak at gmail dot com 2009-09-27 16:11 ---
This band-aid patch enables bootstrap with patch from comment #22 reverted to
proceed a bit further:
Index: tree.c
===
--- tree.c (revision 152218)
--- Comment #32 from jamborm at gcc dot gnu dot org 2009-09-25 14:43
---
(In reply to comment #30)
(In reply to comment #29)
Thanks. With the patch fixing the problem described in #24, we get
further when compiling with release checking but run into syntax
errors when compiling
--- Comment #33 from ubizjak at gmail dot com 2009-09-25 18:09 ---
(In reply to comment #32)
Uros, can you please try it now since we have PR 41463 fixed? x86_64
with release checking now finally bootstraps so perhaps even alpha
might? :-)
If there are problems, please try to
--- Comment #31 from jamborm at gcc dot gnu dot org 2009-09-24 22:53
---
(In reply to comment #29)
Thanks. With the patch fixing the problem described in #24, we get
further when compiling with release checking but run into syntax
errors when compiling stage3 libstc++.
This problem
--- Comment #29 from jamborm at gcc dot gnu dot org 2009-09-23 09:28
---
Thanks. With the patch fixing the problem described in #24, we get
further when compiling with release checking but run into syntax
errors when compiling stage3 libstc++. And the debug info is still
corrupted.
--- Comment #30 from ubizjak at gmail dot com 2009-09-23 09:48 ---
(In reply to comment #29)
Thanks. With the patch fixing the problem described in #24, we get
further when compiling with release checking but run into syntax
errors when compiling stage3 libstc++. And the debug info
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-09-22 08:21
---
I will have a look at the get_ref_base_and_extent issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-09-22 11:48
---
struct VEC_char_base
{
unsigned num;
unsigned alloc;
short vec[1];
};
short __attribute__((noinline))
foo (struct VEC_char_base *p, int i)
{
short *q;
p-vec[i] = 0;
q = p-vec[1];
*q = 1;
return
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-09-22 14:58
---
Subject: Bug 41395
Author: rguenth
Date: Tue Sep 22 14:58:05 2009
New Revision: 151981
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151981
Log:
2009-09-22 Richard Guenther rguent...@suse.de
PR
--- Comment #24 from jamborm at gcc dot gnu dot org 2009-09-21 19:49
---
OK, so I have finally got to the root of the assert failure in
reg-stack.c described in the bug description. The file is indeed
miscompiled, and the miscompiled function is VEC_char_base_replace.
A very short
--- Comment #25 from hjl dot tools at gmail dot com 2009-09-21 19:53
---
(In reply to comment #24)
OK, so I have finally got to the root of the assert failure in
reg-stack.c described in the bug description. The file is indeed
miscompiled, and the miscompiled function is
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-09-20 09:19
---
*** Bug 41414 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-09-20 09:20
---
*** Bug 41415 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-09-20 09:20
---
*** Bug 41413 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--- Comment #19 from developer at sandoe-acoustics dot co dot uk
2009-09-20 09:42 ---
applying
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01274.html
causes i686-apple-darwin9 to fail with the (long long) fault for all
--enable-checking=xx I've tried.
Thus, that fault seems separate
--- Comment #20 from jsg at openbsd dot org 2009-09-20 13:14 ---
bootstrap also fails on OpenBSD/i386 when it used to work a week ago ie:
gcc version 4.5.0 20090913 (experimental) (GCC)
When stage1 is building libgcc:
configure:3003: $? = 0
configure:2992:
--- Comment #21 from dominiq at lps dot ens dot fr 2009-09-20 15:36 ---
In reply to comment #20
bootstrap also fails on OpenBSD/i386 when it used to work a week ago ie:
gcc version 4.5.0 20090913 (experimental) (GCC)
You may try to revert revision 151815 (see pr41405, the patch is in
--- Comment #22 from hjl at gcc dot gnu dot org 2009-09-20 18:00 ---
Subject: Bug 41395
Author: hjl
Date: Sun Sep 20 17:59:44 2009
New Revision: 151905
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151905
Log:
2009-09-20 H.J. Lu hongjiu...@intel.com
PR
--- Comment #23 from hjl dot tools at gmail dot com 2009-09-20 19:37
---
*** Bug 41417 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2009-09-19 15:58
---
*** Bug 41409 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #12 from hjl dot tools at gmail dot com 2009-09-19 15:59
---
*** Bug 41407 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--- Comment #13 from hjl dot tools at gmail dot com 2009-09-19 17:50
---
*** Bug 41410 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Summary|[4.5 regression] Revision |[4.5 regression]
--- Comment #14 from ubizjak at gmail dot com 2009-09-19 21:21 ---
Checking is not a problem here, see Comments #9 and #10.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #15 from developer at sandoe-acoustics dot co dot uk
2009-09-19 22:45 ---
just checked; powerpc-apple-darwin9 [at 151880] this also fails.
looking through the error log there do seem to be a large number of garbage
strings in the informational messages;
e.g.
--- Comment #3 from janus at gcc dot gnu dot org 2009-09-18 10:47 ---
With r151837 the bootstrap works again, but the testsuite still shows a large
number of failures, already with check-gfortran (which was clean recently):
=== gfortran Summary ===
# of expected passes
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-09-18 14:42 ---
I can reproduce the problem. --enable-checking=assert is the key configure
option.
Thus, this bug is mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-09-18 15:10 ---
(In reply to comment #4)
--enable-checking=assert is the key configure option.
Are you sure about that? For me, configuring with --enable-checking=no still
yields loads of regressions in the Fortran testsuite. Other
--- Comment #6 from ubizjak at gmail dot com 2009-09-18 15:29 ---
This revision also fails to bootstrap on alphaev68-unknown-linux-gnu (revision
151799 is OK). stage2 compiler segfaults trying to build libgcc:
configure:3232: /home/uros/gcc-build/./gcc/xgcc
--- Comment #7 from ubizjak at gmail dot com 2009-09-18 15:31 ---
On alpha, bootstrap also fails with --enable-checking=assert.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-09-18 15:34 ---
(In reply to comment #5)
(In reply to comment #4)
--enable-checking=assert is the key configure option.
Are you sure about that? For me, configuring with --enable-checking=no still
yields loads of regressions
--- Comment #9 from ubizjak at gmail dot com 2009-09-18 16:35 ---
(In reply to comment #7)
On alpha, bootstrap also fails with --enable-checking=assert.
It also fails with --enable-checking=none.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--- Comment #10 from developer at sandoe-acoustics dot co dot uk
2009-09-18 19:08 ---
on i686-apple-darwin9 bootstrap fails with a variety of different errors
depending on what --enable-checking=xx is set.
For
=yes if fails with a lot of dsymutil crashes.
=runtime it fails per the
--- Comment #2 from hjl dot tools at gmail dot com 2009-09-18 05:44 ---
It is caused by revision 151800:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00547.html
It is reproducible on both Linux/ia32 and Linux/x86-64.
--
hjl dot tools at gmail dot com changed:
What
47 matches
Mail list logo
