[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #16 from jakub at gcc dot gnu dot org 2008-12-19 09:50 ---
Given the sorry state of tree DSE (what we have is a joke), it is actually
trivial to come up with testcases for arbitrary pure/const call elimination
during RTL DCE. E.g.
/* PR rtl-optimization/38245 */
/* { dg-do run } */
/* { dg-options -O2 } */
extern int bar (long, long, long, long, long, long, long, long,
long, long, long, long, long, long, long, long)
__attribute__((pure));
struct A { int i, j; union { short s[4]; long long l; }; char pad[512]; } a;
void __attribute__((noinline))
foo (void)
{
a.s[2] = bar (6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21);
a.l = 6;
}
int
main (void)
{
foo ();
return 0;
}
This segfaults on i386-linux, x86_64-linux, powerpc64-linux (-m64 only, -m32 is
fine), haven't tried other targets. For ia64-linux and other targets where
return ip is passed in a register I think we'd want to call foo from some
function that has some stuff on the stack and checks that it hasn't been
modified by the foo call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug c++/38577] New: ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
g++ -c -m64 -pipe -fPIC -g -I/usr/include/freetype2 -I/usr/include/pgsql -I/usr/include/pgsql/server -I/usr/include/mysql -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -m64 -O2 -fomit-frame-pointer -fweb -frename-registers -D_REENTRANT -Wall -W -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQFORMINTERNAL_NAMESPACE -DQT_KEYWORDS -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_SHARED -I../../../mkspecs/linux-g++-64 -I. -I../../../include/QtUiTools -I../../../include/QtCore -I../../../include/QtNetwork -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../shared -I../../designer/src/uitools -I../../designer/src/lib/uilib -I.moc/release-shared -I.uic/release-shared -o .obj/release-shared/formpreviewview.o formpreviewview.cpp formpreviewview.cpp: In function 'void highlightWidgetItem(T*, bool)': formpreviewview.cpp:322: internal compiler error: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This happens while compiling Qt 4.5 beta 1. -- Summary: ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38577] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #2 from bero at arklinux dot org 2008-12-19 10:03 --- Created an attachment (id=16943) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16943action=view) gzipped preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38577] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #1 from bero at arklinux dot org 2008-12-19 10:03 --- The ICE occurs even at -O0 -- bero at arklinux dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.4.0 Known to work||4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug bootstrap/38578] New: fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue
At rev 142808 on trunk: ../trunk/configure --prefix=/n/50/guerby/install-trunk-142808 --enable-languages=c,c++ --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.3.2 --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi ... make boostrap ... /home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/ -B/n/50/guerby/install-trunk-142808/arm-linux-gnueabi/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/opt/cfarm/mpfr-2.3.2/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber\ ../../trunk/gcc/config/arm/arm.c -o arm.o cc1: warnings being treated as errors ../../trunk/gcc/config/arm/arm.c: In function 'output_move_double': ../../trunk/gcc/config/arm/arm.c:: error: comparison between signed and unsigned integer expressions ../../trunk/gcc/config/arm/arm.c:10149: error: comparison between signed and unsigned integer expressions ../../trunk/gcc/config/arm/arm.c: In function 'arm_expand_prologue': ../../trunk/gcc/config/arm/arm.c:12659: error: ISO C90 forbids mixed declarations and code make[3]: *** [arm.o] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod make[3]: Leaving directory `/home/guerby/build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/guerby/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/guerby/build' make: *** [bootstrap] Error 2 I assume --disable-werror will workaround this. -- Summary: fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC build triplet: arm-linux-gnueabi GCC host triplet: arm-linux-gnueabi GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578
[Bug bootstrap/38578] fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-19 10:22 --- I'm already testing fixes for this, but my native arm board is very sl -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-19 10:22:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578
[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #17 from jakub at gcc dot gnu dot org 2008-12-19 10:41 ---
Better testcase:
/* PR rtl-optimization/38245 */
/* { dg-do run } */
/* { dg-options -O2 } */
extern int bar (long, long, long, long, long, long, long, long,
long, long, long, long, long, long, long, long,
long, long, long, long, long, long, long, long,
long, long, long, long, long, long, long, long)
__attribute__((pure));
struct A { int i, j; union { short s[4]; long long l; }; char pad[512]; } a;
void __attribute__((noinline))
foo (void)
{
a.s[2] = bar (6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,
6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21);
a.l = 6;
}
int
main (void)
{
char buf[256];
int i;
for (i = 0; i (int) sizeof buf; i++)
buf[i] = i;
asm volatile ( : : r (buf) : memory);
foo ();
asm volatile ( : : r (buf) : memory);
for (i = 0; i (int) sizeof buf; i++)
if (buf[i] != (char) i)
__builtin_abort ();
return 0;
}
BTW, e.g. on powerpc64-linux or ia64-linux the stack arguments aren't in
CALL_INSN_FUNCTION_USAGE at all, only the register arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #67 from chris at bubblescope dot net 2008-12-19 11:45 --- Sorry to come back to this again. With C++0x just around the corner, is there any chance of getting this fixed, seeing as I expect this should be the standard way of checking if we are in conforming C++0x mode, when it gets released? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-19 12:01 --- The attachment is corrupted, you've only attached first 128KB of the *.gz file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug bootstrap/38578] fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue
--- Comment #2 from laurent at guerby dot net 2008-12-19 12:02 --- Thanks! The cfarm machine gcc50 has a 600 Mhz XScale-80219 with 512 MB of RAM, gcc-4.3.2 release C only bootstrap took 17 hours (and about the same for make check) - feel free to ask for an account if it's faster than what you have. If you know a way to purchase qualcomm snapdragon dual core 1.5 GHz arm (or a contact that might lead to it) I'm interested :). http://www.umpcportal.com/2008/12/analysis-dual-core-snapdragon-and-netbooks-from-qualcomm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #4 from bero at arklinux dot org 2008-12-19 12:25 --- Looks like bugzilla doesn't handle attachments 128 kB... I've uploaded the file to http://arklinux.org/~bero/formpreviewview.ii.gz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38579] New: Template: Wrong inherited copy-ctor visibility
The code below compiles, but it should give an error, because the Policy ctor
is not accessible when inheriting protected from Policy
To have valid C++ code the inheritance must be public.
struct Policy
{
protected:
Policy() {}
Policy(const Policy) {}
};
templateint I, class P
struct BugGcc :
protected P
//public P
{
BugGcc() {}
templateint I, class P
BugGcc(const BugGccI, P t) : P(t) {}
};
void foo()
{
BugGcc0, Policy f1;
BugGcc1, Policy f2(f1);
}
GCC:
gcc-Version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
--
Summary: Template: Wrong inherited copy-ctor visibility
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: syntheticpp at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38579
[Bug testsuite/33300] [libstdc++-v3] 27_io/ios_base/storage/2.cc with -m64 kills Darwin
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-12-19 14:04 --- I noticed today that r142822 no longer exhibited the failure of libstdc++-v3/testsuite/27_io/ios_base/storage/2.cc as... WARNING: program timed out. FAIL: 27_io/ios_base/storage/2.cc execution test at -m64 on i686-apple-darwin9 as it has up to as recently as r142799. So either the bug went latent or it was fixed by a patch in that range. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33300
[Bug libffi/26048] [4.2/4.3/4.4 Regression] libffi doesn't build on Solaris 10/x86 with native assembler
-- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-17 19:32:20 |2008-12-19 14:08:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26048
[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #18 from jakub at gcc dot gnu dot org 2008-12-19 14:37 --- Created an attachment (id=16944) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16944action=view) gcc44-pr38245.patch On x86_64 some more work is needed, because in leaf functions parts of the outgoing_args_size space might be in red-zone, and as all the left-over stack pushes are from %rsp upwards, that still clobbers the return pointer. Perhaps we might in that case just make the red-zone smaller to make sure all of the outgoing_args_size are is above the red zone. This patch also fixes powerpc64, though in that case (or for msabi on x86_64 too) if we eliminate a call that has arguments solely in registers, still outgoing_args_size area is allocated. I guess we might want to track the size of outgoing args we really pushed for some call, not considering OUTGOING_REG_PARM_STACK_SPACE, and remember it in a new crtl- field. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #10 from jakub at gcc dot gnu dot org 2008-12-19 14:57 --- Subject: Bug 37739 Author: jakub Date: Fri Dec 19 14:55:42 2008 New Revision: 142833 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142833 Log: PR bootstrap/37739 * config.host: For powerpc*-*-linux* host with 32-bit GCC, use rs6000/x-linux-relax snippet if ld is new enough, otherwise use rs6000/x-linux-O1. * config/rs6000/x-linux-relax: New file. * config/x-cflags-O1: New file. Added: trunk/gcc/config/rs6000/x-linux-relax trunk/gcc/config/x-cflags-O1 Modified: trunk/gcc/ChangeLog trunk/gcc/config.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME
--- Comment #21 from jakub at gcc dot gnu dot org 2008-12-19 14:58 --- Subject: Bug 38396 Author: jakub Date: Fri Dec 19 14:57:29 2008 New Revision: 142834 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142834 Log: PR libgcj/38396 * configure.ac (use_libgcj_bc): Set to no if not enable_shared. (LIBGCJ_SPEC): Use -lgcj instead of -lgcj_bc even for -static or -static-libgcj. * Makefile.am (ecjx_SOURCES): Add ecjx.cc. (ecjx_LDADD): Don't add libgcj.la when NATIVE USE_LIBBGCJ_BC. * ecjx.cc: New file. * Makefile.in: Regenerated. * configure: Regenerated. Added: trunk/libjava/ecjx.cc Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in trunk/libjava/configure trunk/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396
[Bug libffi/26048] [4.2/4.3/4.4 Regression] libffi doesn't build on Solaris 10/x86 with native assembler
--- Comment #9 from ro at gcc dot gnu dot org 2008-12-19 15:01 --- Subject: Bug 26048 Author: ro Date: Fri Dec 19 14:59:42 2008 New Revision: 142835 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142835 Log: PR libffi/26048 * configure.ac (HAVE_AS_X86_PCREL): New test. * configure: Regenerate. * fficonfig.h.in: Regenerate. * src/x86/sysv.S [!FFI_NO_RAW_API]: Precalculate RAW_CLOSURE_CIF_OFFSET, RAW_CLOSURE_FUN_OFFSET, RAW_CLOSURE_USER_DATA_OFFSET for the Solaris 10/x86 assembler. (.eh_frame): Only use SYMBOL-. iff HAVE_AS_X86_PCREL. * src/x86/unix64.S (.Lstore_table): Move to .text section. (.Lload_table): Likewise. (.eh_frame): Only use SYMBOL-. iff HAVE_AS_X86_PCREL. Modified: trunk/libffi/ChangeLog trunk/libffi/configure trunk/libffi/configure.ac trunk/libffi/fficonfig.h.in trunk/libffi/src/x86/sysv.S trunk/libffi/src/x86/unix64.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26048
[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc
--- Comment #22 from jakub at gcc dot gnu dot org 2008-12-19 15:02 --- 1) doesn't exist on the trunk, 2) fixed there. Both 1) and 2) need still fixing on 4.3 branch, a backport of r142834 should cure 2), 1) needs a separate patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.2 Known to work||4.4.0 Summary|[4.4 Regression] libgcj_bc |[4.3 Regression] ecj1 linked |for 4.3 and 4.4 are binary |against both -lgcj and - |incompatible but have the |lgcj_bc |same SONAME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-19 14:59 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug libffi/26048] [4.2/4.3/4.4 Regression] libffi doesn't build on Solaris 10/x86 with native assembler
--- Comment #10 from ro at gcc dot gnu dot org 2008-12-19 15:01 --- Fixed for 4.4.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26048
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-19 15:23 ---
Reduced testcase:
struct A
{
static A *bar () { return a; }
static A *a;
};
struct B : public A
{
static void baz ();
};
template class T
void foo ()
{
(static_castB * (A::bar ()))-baz ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-19 15:56 --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=142054 (PR37540). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #7 from jakub at gcc dot gnu dot org 2008-12-19 16:09 --- In build_new_method_call, call at that spot is either error_mark_node (already checked for), build_over_call returned value (can be a CALL_EXPR or INDIRECT_REF on a CALL_EXPR for references; both are handled already), or: call = build2 (COMPOUND_EXPR, TREE_TYPE (call), instance_ptr, call); or: call = build_nop (void_type_node, call); I guess these (COMPOUND_EXPR and NOP_EXPR) need to be handled too. -- jakub at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet||x86_64-pc-linux-gnu GCC host triplet||x86_64-pc-linux-gnu GCC target triplet||x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-pc-linux-gnu | GCC host triplet|x86_64-pc-linux-gnu | GCC target triplet|x86_64-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2008-12-19 16:09:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-19 16:44 --- Created an attachment (id=16945) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16945action=view) gcc44-pr38577.patch Patch I'm going to test. Both the COMPOUND_EXPR and NOP_EXPR are inserted again during instantiation when build_new_method_call is called again. Another alternative would be not to create the COMPOUND_EXPR or NOP_EXPR if (processing_template_decl) at all, but for the destructor cast to void that would mean the type wouldn't be void during template processing. Before the PR37540 patch the CALL_EXPR would have void_type_node, which is wrong, but leaving the type non-void would be IMHO worse. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug bootstrap/38546] configure: too many arguments
--- Comment #1 from rwild at gcc dot gnu dot org 2008-12-19 17:02 --- The code in question is if test -f $gcc_cv_binutils_srcdir/configure.in \ test -f ../binutils/Makefile \ test x$build = x$host; then gcc_cv_nm=../binutils/nm-new$build_exeext elif test -x nm$build_exeext; then gcc_cv_nm=./nm$build_exeext elif test -x $NM_FOR_TARGET; then gcc_cv_nm=$NM_FOR_TARGET else ... and the line in question is the one containing test -x $NM_FOR_TARGET This idiom exists in current trunk as well, so presumably also the bug, and also in a couple of other places in this file. I'm not sure whether NM_FOR_TARGET is required here to be one word only, but that would seem like a bug itself to me. -- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38546
[Bug fortran/38538] ICE with elemental character function
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-12-19 17:20 --- (In reply to comment #10) Many thanks, Dominique! At least I have something to work on. It's a cursed nuisance not having access to a fully functioning system, when I have time to work on gfortran. I think that I shall have to take up Tobi's offer of remote access to his machine. Hi Paul, you could apply for an account on the gcc compile farm (I have). As long as you have putty, and your private key, you can log on from just about everywhere. Very useful, and they have a couple of really fast systems, too! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug bootstrap/38578] fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-19 17:24 --- Subject: Bug 38578 Author: rearnsha Date: Fri Dec 19 17:22:58 2008 New Revision: 142837 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142837 Log: PR bootstrap/38578 * arm.c (load_multiple_sequence): Initialize ORDER array. (store_multiple_sequence): Likewise. (output_move_double): Make reg0 unsigned. (arm_output_epilogue): Make amount unsigned. (arm_expand_prologue): Move declaration of dwarf before block statements. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578
[Bug bootstrap/38578] fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-19 17:25 --- Fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #9 from jason at redhat dot com 2008-12-19 17:28 --- Subject: Re: [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000 jakub at gcc dot gnu dot org wrote: Another alternative would be not to create the COMPOUND_EXPR or NOP_EXPR if (processing_template_decl) at all, but for the destructor cast to void that would mean the type wouldn't be void during template processing. Before the PR37540 patch the CALL_EXPR would have void_type_node, which is wrong, but leaving the type non-void would be IMHO worse. This patch is OK if it passes testing. But it makes me wonder if we're handling decltype of the COMPOUND_EXPR case properly. The destructor issue makes me wish again that ARM hadn't decided to mess with the ABI. Sigh. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug target/38548] [4.4 Regression] bootstrap broken on arm-linux-gnu (not gnueabi)
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-19 17:28:02 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38548
[Bug target/38548] [4.4 Regression] bootstrap broken on arm-linux-gnu (not gnueabi)
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-19 17:32 --- Subject: Bug 38548 Author: rearnsha Date: Fri Dec 19 17:31:12 2008 New Revision: 142838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142838 Log: PR target/38548 * arm/t-linux (LIB1ASMFUNCS): Add _arm_addsubdf3 and _arm_addsubsf3. * arm/lib1funcs.asm (clzsi2): Use RET macro for return instruction. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/lib1funcs.asm trunk/gcc/config/arm/t-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38548
[Bug target/38548] [4.4 Regression] bootstrap broken on arm-linux-gnu (not gnueabi)
--- Comment #2 from rearnsha at gcc dot gnu dot org 2008-12-19 17:33 --- Fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38548
[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)
--- Comment #36 from janis at gcc dot gnu dot org 2008-12-19 17:50 --- I'll revert the patch that changes the XFAIL. I noticed yesterday that the test was failing on powerpc64-linux on a distribution that I hadn't tested on before, although the new XFAIL had worked on the other distributions I tried. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug bootstrap/38580] New: Bootstrap broken on mingw32
Bootstraping on i586-pc-mingw32 (with mingw-3.15.1, the latest version) is
broken by:
(SHLIB_LINK='ln -s -f @shlib_map_file@ @shlib_map_f...@.def if [ ! -d
@multilib_dir@/shlib ]; then mkdir @multilib_dir@/shlib else true; fi
/home/FX/gfortran/ibin/./gcc/xgcc -B/home/FX/gfortran/ibin/./gcc/
-L/home/FX/gfortran/ibin/i586-pc-mingw32/winsup/mingw
-L/home/FX/gfortran/ibin/i586-pc-mingw32/winsup/w32api/lib -isystem
/home/FX/gfortran/gcc-trunk/winsup/mingw/include -isystem
/home/FX/gfortran/gcc-trunk/winsup/w32api/include -B/mingw/i586-pc-mingw32/bin/
-B/mingw/i586-pc-mingw32/lib/ -isystem /mingw/i586-pc-mingw32/include -isystem
/mingw/i586-pc-mingw32/sys-include -O2
-I../../gcc-trunk/gcc/../winsup/w32api/include -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs
@shlib_map_f...@.def
-Wl,--out-implib,@multilib_dir@/shlib/@shlib_base_n...@.a.tmp -o
@multilib_dir@/shlib/@shlib_base_n...@_1.dll.tmp @multilib_flags@ @shlib_objs@
-lmingw32 -lmingwex -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32
-lshell32 if [ -f @multilib_dir@/shlib/@shlib_base_n...@_1.dll ]; then mv -f
@multilib_dir@/shlib/@shlib_base_n...@_1.dll
@multilib_dir@/shlib/@shlib_base_n...@_1.dll.backup; else true; fi mv
@multilib_dir@/shlib/@shlib_base_n...@_1.dll.tmp
@multilib_dir@/shlib/@shlib_base_n...@_1.dll mv
@multilib_dir@/shlib/@shlib_base_n...@.a.tmp
@multilib_dir@/shlib/@shlib_base_n...@.a'; \
/home/FX/gfortran/ibin/./prev-gcc/xgcc
-B/home/FX/gfortran/ibin/./prev-gcc/ -B/mingw/i586-pc-mingw32/bin/ -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/.
-I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include
-I/home/FX/gfortran/dependencies/include -I../../gcc-trunk/gcc/../libdecnumber
-I../../gcc-trunk/gcc/../libdecnumber/dpd -I../libdecnumber\
-DSTANDARD_STARTFILE_PREFIX=\../../../\
-DSTANDARD_EXEC_PREFIX=\/mingw/lib/gcc/\
-DSTANDARD_LIBEXEC_PREFIX=\/mingw/libexec/gcc/\
-DDEFAULT_TARGET_VERSION=\4.4.0\ -DDEFAULT_TARGET_MACHINE=\i586-pc-mingw32\
-DSTANDARD_BINDIR_PREFIX=\/mingw/bin/\ -DTOOLDIR_BASE_PREFIX=\../../../../\
`test X${SHLIB_LINK} = X || test yes != yes || echo
-DENABLE_SHARED_LIBGCC` \
-c ../../gcc-trunk/gcc/gcc.c -o gcc.o)
cc1.exe: warnings being treated as errors
../../gcc-trunk/gcc/gcc.c: In function 'process_command':
../../gcc-trunk/gcc/gcc.c:3423: error: passing argument 2 of 'execvp' from
incompatible pointer type
c:/MinGW/include/process.h:120: note: expected 'const char * const*' but
argument is of type 'char **'
This same error happens at stage 2 and 3. Working around it by compiling gcc.c
(and only gcc.c) without -Werror, I can confirm that the rest of the bootstrap
then goes fine.
--
Summary: Bootstrap broken on mingw32
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: build
Severity: critical
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: i586-pc-mingw32
GCC host triplet: i586-pc-mingw32
GCC target triplet: i586-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)
--- Comment #37 from janis at gcc dot gnu dot org 2008-12-19 18:14 --- Subject: Bug 24685 Author: janis Date: Fri Dec 19 18:12:40 2008 New Revision: 142840 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142840 Log: Revert: 2008-12-12 Janis Johnson janis...@us.ibm.com PR libgfortran/24685 * gfortran.dg/default_format_denormal_2.f90: Change XFAIL to check for size of long double. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/default_format_denormal_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #4 from hjagasia at gcc dot gnu dot org 2008-12-19 18:20 --- Created an attachment (id=16946) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16946action=view) Fixed changes suggested by Sebastian Pop. 2008-12-19 Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38510 * gcc.dg/graphite/pr38510.c: New. * graphite.c (recompute_all_dominators): Call mark_irreducible_loops. (translate_clast): Call recompute_all_dominators before graphite_verify. (gloog): Call recompute_all_dominators before graphite_verify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)
--- Comment #38 from janis at gcc dot gnu dot org 2008-12-19 18:22 --- Subject: Bug 24685 Author: janis Date: Fri Dec 19 18:20:41 2008 New Revision: 142841 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142841 Log: Revert: 2008-12-12 Janis Johnson janis...@us.ibm.com PR libgfortran/24685 * gfortran.dg/default_format_denormal_2.f90: Change XFAIL to check for size of long double. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/default_format_denormal_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #10 from jakub at gcc dot gnu dot org 2008-12-19 19:34 --- Subject: Bug 38577 Author: jakub Date: Fri Dec 19 19:33:28 2008 New Revision: 142842 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142842 Log: PR c++/38577 * call.c (build_new_method_call): Handle call being COMPOUND_EXPR or NOP_EXPR. * g++.dg/template/call6.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/call6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug libgomp/38270] libgomp test failures due to missing memory barrier
--- Comment #6 from janis at gcc dot gnu dot org 2008-12-19 19:43 --- Created an attachment (id=16947) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16947action=view) final patch This was the final patch; it wasn't submitted to gcc-patches, but was written based on a suggestion from Jakub. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38270
[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-19 20:05 ---
With COMPOUND_EXPR, finish_decltype_type doesn't ICE, but as you note, probably
doesn't do the right thing.
Say on:
struct A
{
static A *bar ();
};
struct B : public A
{
static int baz ();
};
template class T
void foo ()
{
__decltype ((static_castB * (A::bar ()))-baz ()) i;
}
void blah ()
{
__decltype ((static_castB * (A::bar ()))-baz ()) i;
}
void
bar ()
{
fooint ();
}
in foo finish_decltype_type is called just with CALL_EXPR and does the right
thing, but in blah is called with COMPOUND_EXPR and doesn't handle it as
CALL_EXPR, but just returns TREE_TYPE. Not sure how would a testcase where
this would make a difference look though.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[Bug c++/38581] New: Tru64 outputs non-virtual thunks as non-weak symbols
When building qt-3.3.8 and wxGTk on Tru64 UNIX 5.1 (alphaev67-dec-osf5.1) with gcc-4.2.4, we got linker failures about duplicate non-virtual thunks, e.g. from qt: /usr/ccs/bin/ld: .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to QDragMoveEvent::~QDragMoveEvent(): multiply defined .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to QDragMoveEvent::~QDragMoveEvent(): multiply defined .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to QDragEnterEvent::~QDragEnterEvent(): multiply defined .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to QDragEnterEvent::~QDragEnterEvent(): multiply defined This appears to be because the non-virtual thunks are not output weak on this platform, so, those that appear in multiple objects will cause linker errors like this (in the above case, there are _ZThn16_N14QDragMoveEventD0Ev and _ZThn16_N14QDragMoveEventD1Ev in both qdnd_x11.o and qmotifdnd_x11.o). This is easily reproducible, for example, compiling a slightly modified version of dllexport-MI1.C from the g++ testsuite. With gcc-4.2.4: % g++ -c -o dllexport-MI1.o dllexport-MI1.C; nm -wB dllexport-MI1.o | grep Thn 0x00 N $_ZThn8_N3MI1D0Ev..ng 0x00 N $_ZThn8_N3MI1D1Ev..ng 0x00 N $_ZThn8_NK3MI12vfEv..ng 0x000854 T _ZThn8_N3MI1D0Ev 0x000910 T _ZThn8_N3MI1D1Ev 0x000208 T _ZThn8_NK3MI12vfEv When compared to gcc-3.4.3: g++ -c -o dllexport-MI1.o dllexport-MI1.C; nm -wB dllexport-MI1.o | grep Thn 0x00 N $_ZThn8_N3MI1D0Ev..ng 0x00 N $_ZThn8_N3MI1D1Ev..ng 0x00 N $_ZThn8_NK3MI12vfEv..ng 0x000344 T* _ZThn8_N3MI1D0Ev 0x000548 T* _ZThn8_N3MI1D1Ev 0x0001f0 T* _ZThn8_NK3MI12vfEv The '*' in the nm output indicates a weak symbol. -- Summary: Tru64 outputs non-virtual thunks as non-weak symbols Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla-gcc at thewrittenword dot com GCC host triplet: alphaev67-dec-osf5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38581
[Bug c++/38581] Tru64 outputs non-virtual thunks as non-weak symbols
--- Comment #1 from bugzilla-gcc at thewrittenword dot com 2008-12-19 22:30 --- Created an attachment (id=16948) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16948action=view) preprocessed file to demonstrate the problem The slightly modified version of dllexport-MI1.C (really just removed the __attribute__ ((dllexport)), as they caused warnings). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38581
[Bug bootstrap/38580] Bootstrap broken on mingw32
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-12-19 23:01 --- Patch for this was submitted 4 months ago: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01143.html Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-19 23:01:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug bootstrap/38580] Bootstrap broken on mingw32
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-12-19 23:11 --- I'm adding Kai to the CC list. As he's now maintainer, he may want to help here. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||kai dot tietz at onevision ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug rtl-optimization/38495] [4.4 Regression] ACATS tests cxa4004 cxa4005 cxa4026 fail
--- Comment #5 from vmakarov at redhat dot com 2008-12-19 23:30 ---
Eric, thanks for analysis. It saved a lot of my time.
The problem was in wrong final live ranges of a379r452 therefore the conflicts
was not recognized and the pseudos were coalesced. One pseudo is a temporary
pseudo used for breaking register shuffle cycle (it is actually a rare case) on
a CFG edge (loop exit). And another pseudo is destination of removed store
insn on the loop exit. In normal case it should not conflict with the
temporary pseudo because the temporary lives only on the edge and another
pseudo lives only after the edge destination. But it should conflict with the
temporary in this case because we removed the store and another pseudo lives
through all loop. The suspicious code looks like
EXECUTE_IF_SET_IN_BITMAP (live_through, FIRST_PSEUDO_REGISTER, regno, bi)
{
a = node-regno_allocno_map[regno];
if (ALLOCNO_MEM_OPTIMIZED_DEST (a) == NULL)
{
ALLOCNO_LIVE_RANGES (a)
= ira_create_allocno_live_range (a, start, ira_max_point - 1,
ALLOCNO_LIVE_RANGES (a));
if (internal_flag_ira_verbose 2 ira_dump_file != NULL)
fprintf
(ira_dump_file,
Adding range [%d..%d] to live through allocno a%dr%d\n,
start, ira_max_point - 1, ALLOCNO_NUM (a),
REGNO (ALLOCNO_REG (a)));
}
I'll send a patch solving the problem after its testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38495
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-12-19 23:32 --- The approved patch doesn't seem to be checked into gcc trunk yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug fortran/38538] ICE with elemental character function
--- Comment #12 from pault at gcc dot gnu dot org 2008-12-19 23:59 --- Created an attachment (id=16949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16949action=view) a not quite patch for the PR I'm down to one regression now - the last test of char_length_7.f90. Pah! That was tough in the first place Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #16928|0 |1 is obsolete|| Attachment #16929|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug target/9703] [arm] Accessing data through constant pool more times could be solved in less instructions
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-20 00:26 --- This might have been implemented for 4.4 already. Section anchors now have been enabled for ARM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9703
[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-12-20 03:18 --- I can confirm that current (r142846) gcc trunk, with the changes from r142728, r142722 and proposed patch in Comment 4 applied, builds pymol 1.1r2 completely under either -O3 or -O2 and -fgraphite-identity -funroll-loops -fomit-frame-pointer -ffast-math. The resulting pymol runs fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #6 from spop at gcc dot gnu dot org 2008-12-20 07:43 --- Subject: Re: Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite --- Comment #4 from hjagasia at gcc dot gnu dot org 2008-12-19 18:20 --- Created an attachment (id=16946) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16946action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16946action=view) Fixed changes suggested by Sebastian Pop. Why did you introduced all these calls of recompute_all_dominators before the graphite_verify functions? Are all these calls needed? I don't think so. For instance, here: + recompute_all_dominators (); graphite_verify (); cleanup_tree_cfg (); recompute_all_dominators (); recompute_all_dominators is called twice with just cleanup_tree_cfg in between. I do not like the recompute_all_dominators calls: in the long run we should have all this information correctly updated during code generation, and not rely at all on recompute_all_dominators. If you can minimize the number of calls to recompute_all_dominators it would be nice, otherwise the patch is ok. Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
