[Bug middle-end/41229] [4.5 Regression] VTA: internal compiler error: verify_ssa failed
--- Comment #1 from jv244 at cam dot ac dot uk 2009-09-03 06:46 --- this is now failing at '-O2 -g' with current trunk. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.4.2 Summary|VTA: internal compiler |[4.5 Regression] VTA: |error: verify_ssa failed|internal compiler error: ||verify_ssa failed Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41229
[Bug middle-end/41225] [4.5 Regression] VTA: internal compiler error: in vect_stmt_relevant_p, at tree-vect-stmts.c:150
--- Comment #3 from jv244 at cam dot ac dot uk 2009-09-03 06:48 --- gfortran -c -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -g bug.f90 now fails. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.4.2 Summary|VTA: internal compiler |[4.5 Regression] VTA: |error: in |internal compiler error: in |vect_stmt_relevant_p, at|vect_stmt_relevant_p, at |tree-vect-stmts.c:150 |tree-vect-stmts.c:150 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41225
[Bug debug/40660] [4.5 Regression] Weird break points with 4.5, works with 4.4
--- Comment #12 from jv244 at cam dot ac dot uk 2009-09-03 06:50 --- looks like this is fixed on trunk. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2009-09-03 06:51 --- Created an attachment (id=18469) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18469action=view) Patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214
[Bug fortran/41219] libgfortran build warnings
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-03 06:55 --- Thomas, I think do to your changes one now gets a warning (unused argument) for libgfortran/intrinsics/unpack_generic.c. The last argument of unpack_internal (index_type fsize) is no longer used; as the function is static, one can simply remove it and update the callers (where some __attribute__((unused)) has then to be added). Is there really no need for the argument? Any any case, can you have a look and create a patch? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-03 06:55:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug middle-end/40106] [4.4/4.5 Regression] Time increase for the Polyhedron test air.f90 due to bad optimization
--- Comment #30 from dominiq at lps dot ens dot fr 2009-09-03 07:09 --- This is a regression from gcc 4.3.4 (gfc=trunk r151295, gfc44=4.4.1, gfc43=4.3.4): [ibook-dhum] test/dbg_air% gfc -S -m64 -O2 -funsafe-math-optimizations air_db.f90 [ibook-dhum] test/dbg_air% grep pow air_db.s call _pow call_pow [ibook-dhum] test/dbg_air% gfc44 -S -m64 -O2 -funsafe-math-optimizations air_db.f90 [ibook-dhum] test/dbg_air% grep pow air_db.s call_pow call_pow [ibook-dhum] test/dbg_air% gfc43 -S -m64 -O2 -funsafe-math-optimizations air_db.f90 [ibook-dhum] test/dbg_air% grep pow air_db.s [ibook-dhum] test/dbg_air% -- dominiq at lps dot ens dot fr changed: What|Removed |Added Summary|Time increase for the |[4.4/4.5 Regression] Time |Polyhedron test air.f90 due |increase for the Polyhedron |to bad optimization |test air.f90 due to bad ||optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug tree-optimization/41212] [4.5 Regression] miscompilation at -O2
--- Comment #4 from jpr at csc dot fi 2009-09-03 07:10 --- FWIW: I had a look at the -fdump-tree-all files. All seems well (to my untrained eyes), until bb 8: D.1412_51 = y; D.1430_52 = D.1412_51 * 2.0e+0; z = D.1430_52; in m.f90.060t.phiprop is transformed to bb 8: D.1412_51 = 1.0e+0; D.1430_52 = 2.0e+0; z = D.1430_52; in m.f90.061t.fre Regards,Juha -- jpr at csc dot fi changed: What|Removed |Added CC||jpr at csc dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug fortran/41219] libgfortran build warnings
--- Comment #2 from burnus at gcc dot gnu dot org 2009-09-03 07:12 --- Nightstrike: I do not understand libgfortran/intrinsics/getlog.c:85:3: warning: implicit declaration of function getlogin There is a #if defined __MINGW32__ !defined HAVE_GETLOGIN block which should make sure that it is defined. Can you try to find out what goes wrong? * * * Janne, I think the warning about unix.c:750:15: warning: statbuf.st_mode may be used uninitialized is spurious, but can you have a look? * * * Jerry, there is some inconsistency regarding st_parameter_dt's saved_type. One finds both bt and dtype assignments, which does not make sense. Does one need both types in a union? Or can one consolidate them? list_read.c: dtp-u.p.saved_type = BT_LOGICAL; list_read.c: dtp-u.p.saved_type = GFC_DTYPE_UNKNOWN; etc. Currently, one gets a compile-time warning (see comment 0). In write_a_char4, one has: const char crlf[] = \r\n; write_default_char4 (dtp, crlf, 2, 0); but the second argument should be gfc_char4_t* -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org, ||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug target/40454] [4.4 regression] zlib is about 20% slower when compiled with GCC 4.4.1
--- Comment #14 from bonzini at gnu dot org 2009-09-03 07:27 --- Can you also try with 4.5? -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-03 07:27:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug fortran/41219] libgfortran build warnings
--- Comment #3 from burnus at gcc dot gnu dot org 2009-09-03 07:36 --- Subject: Bug 41219 Author: burnus Date: Thu Sep 3 07:36:36 2009 New Revision: 151371 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151371 Log: 2009-09-03 Tobias Burnus bur...@net-b.de PR fortran/41219 * intrinsics/iso_c_binding.c (c_f_pointer_u0): Move variable declaration out of the loop. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/iso_c_binding.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug debug/41236] New: [4.5 regression] RTL checking failure compiling libgcc
At revision 151371 I get an RTL checking failure compiling libgcc: /home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/ -B/home/eric/install/gcc/i586-suse-linux/bin/ -B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem /home/eric/install/gcc/i586-suse-linux/include -isystem /home/eric/install/gcc/i586-suse-linux/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/home/eric/svn/gcc/libgcc -I/home/eric/svn/gcc/libgcc/. -I/home/eric/svn/gcc/libgcc/../gcc -I/home/eric/svn/gcc/libgcc/../include -I/home/eric/svn/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -Wno-missing-prototypes -Wno-type-limits -o unordtf2.o -MT unordtf2.o -MD -MP -MF unordtf2.dep -fexceptions -c /home/eric/svn/gcc/libgcc/../gcc/config/soft-fp/unordtf2.c -fvisibility=hidden -DHIDE_EXPORTS /home/eric/svn/gcc/libgcc/../gcc/config/soft-fp/unordtf2.c: In function '__unordtf2': /home/eric/svn/gcc/libgcc/../gcc/config/soft-fp/unordtf2.c:45:1: internal compiler error: RTL check: expected code 'subreg', have 'sign_extend' in loc_descriptor, at dwarf2out.c:11681 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [unordtf2.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/home/eric/build/gcc/native32/i586-suse-linux/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/home/eric/build/gcc/native32' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/eric/build/gcc/native32' make: *** [all] Error 2 All was working fine yesterday so it's very likely the enabling of VTA. -- Summary: [4.5 regression] RTL checking failure compiling libgcc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org GCC build triplet: ix86-*-linux GCC host triplet: ix86-*-linux GCC target triplet: ix86-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41236
[Bug bootstrap/41237] New: [4.5 Regression] Bootstrap failure on powerpc-apple-darwin9 due to a revision between 151343 and 151349
Bootstrap fails on powerpc-apple-darwin9 due to a revision between 151343 and 151349 (see http://gcc.gnu.org/ml/gcc-regression/2009-09/msg00024.html): /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.5w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.5w/powerpc-apple-darwin9/sys-include -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genrecog \ build/genrecog.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o .././libiberty/libiberty.a build/genrecog ../../gcc-4.5-work/gcc/config/rs6000/rs6000.md \ insn-conditions.md tmp-recog.c ../../gcc-4.5-work/gcc/config/rs6000/rs6000.md:12910: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:1690: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:1697: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:1851: warning: destination missing a mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:1851: warning: operand 0 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:2366: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:2374: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:2382: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:2390: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:2632: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:2632: warning: operand 2 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:2641: warning: operand 1 missing mode? ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:2641: warning: operand 2 missing mode? /bin/sh ../../gcc-4.5-work/gcc/../move-if-change tmp-recog.c insn-recog.c echo timestamp s-recog /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.5w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.5w/powerpc-apple-darwin9/sys-include-c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5-work/gcc -I../../gcc-4.5-work/gcc/. -I../../gcc-4.5-work/gcc/../include -I../../gcc-4.5-work/gcc/../libcpp/include -I/opt/mpc/build//include -I/sw/include -I../../gcc-4.5-work/gcc/../libdecnumber -I../../gcc-4.5-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -I/sw/include -DCLOOG_PPL_BACKEND insn-recog.c -o insn-recog.o [address=03d551b2 pc=00803828] ../../gcc-4.5-work/gcc/config/rs6000/altivec.md: In function 'recog_49': ../../gcc-4.5-work/gcc/config/rs6000/altivec.md:329:1: internal compiler error: Segmentation Fault -- Summary: [4.5 Regression] Bootstrap failure on powerpc-apple- darwin9 due to a revision between 151343 and 151349 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41237
[Bug debug/41236] [4.5 regression] RTL checking failure compiling libgcc
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-09-03 08:14 --- Created an attachment (id=18470) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18470action=view) Reduced testcase. To be compiled at -O -g with an --enable-checking=yes,rtl compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41236
[Bug debug/41238] New: VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
This ICE breaks alpha bootstrap, it can be reproduced with (to be) attached preprocessed source on a cross from x86_64-pc-linux-gnu to alpha-linux-gnu. ~/gcc-build-alpha/gcc/cc1 -quiet -O2 -g -mlong-double-128 libgcc2.i ../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c: In function '__divtc3': ../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c:1948:1: internal compiler error: in loc_cmp, at var-tracking.c:2456 Please submit a full bug report, (gdb) bt #0 fancy_abort (file=0xae4ac0 ../../gcc-svn/trunk/gcc/var-tracking.c, line=2456, function=0xae5073 loc_cmp) at ../../gcc-svn/trunk/gcc/diagnostic.c:727 #1 0x008bf675 in loc_cmp (x=0xca67dd8, y=0xca77808) at ../../gcc-svn/trunk/gcc/var-tracking.c:2456 #2 0x008bf6bd in onepart_variable_different_p (var1=value optimized out, var2=value optimized out) at ../../gcc-svn/trunk/gcc/var-tracking.c:3932 #3 0x008c8022 in variable_merge_over_cur (s1slot=0xca9b0b0, data=value optimized out) at ../../gcc-svn/trunk/gcc/var-tracking.c:3037 #4 0x00a26dd8 in htab_traverse_noresize (htab=value optimized out, callback=0x8c7bd0 variable_merge_over_cur, info=0x7827c7f0) at ../../gcc-svn/trunk/libiberty/hashtab.c:750 #5 0x008c13fc in dataflow_set_merge (dst=0xcac47f0, src=value optimized out) at ../../gcc-svn/trunk/gcc/var-tracking.c:3294 #6 0x008cc632 in variable_tracking_main () at ../../gcc-svn/trunk/gcc/var-tracking.c:5462 (gdb) up #1 0x008bf675 in loc_cmp (x=0xca67dd8, y=0xca77808) at ../../gcc-svn/trunk/gcc/var-tracking.c:2456 2456 gcc_assert (GET_MODE (x) == GET_MODE (y)); (gdb) p debug_rtx (x) (value/s/u:TF 179 @0xca67dd8/0xca69328) $1 = void (gdb) p debug_rtx (y) (value/s/u:DI 325 @0xca77808/0xca78118) $2 = void (gdb) up #2 0x008bf6bd in onepart_variable_different_p (var1=value optimized out, var2=value optimized out) at ../../gcc-svn/trunk/gcc/var-tracking.c:3932 3932 if (loc_cmp (lc1-loc, lc2-loc)) (gdb) p debug_variable (var1) Program received signal SIGSEGV, Segmentation fault. dump_variable (file=0x3365150860, var=0x0) at ../../gcc-svn/trunk/gcc/tree-dfa.c:273 273 if (TREE_CODE (var) == SSA_NAME) The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use set unwindonsignal on Evaluation of the expression containing the function (debug_variable) will be abandoned. (ouch...) Following patch is also needed to get that far on native alpha bootstrap: Index: config/alpha/alpha.c === --- config/alpha/alpha.c(revision 151367) +++ config/alpha/alpha.c(working copy) @@ -7664,7 +7664,7 @@ alpha_does_function_need_gp (void) pop_topmost_sequence (); for (; insn; insn = NEXT_INSN (insn)) -if (INSN_P (insn) +if (NONDEBUG_INSN_P (insn) ! JUMP_TABLE_DATA_P (insn) GET_CODE (PATTERN (insn)) != USE GET_CODE (PATTERN (insn)) != CLOBBER -- Summary: VTA: bootstrap failure, ICE in loc_cmp, at var- tracking.c:2456 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC host triplet: x86_64-linux-gnu GCC target triplet: alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug debug/41238] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #1 from ubizjak at gmail dot com 2009-09-03 08:21 --- Created an attachment (id=18471) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18471action=view) libgcc2 preprocessed source Fails with -g in __divtc3, compiles OK without. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug rtl-optimization/41239] New: Scheduler reorders division by zero before a call that might not return
This testcase distilled from postgresql fails at runtime on s390x-linux with
-O2 -march=z9-109 -mtune=z10:
/* { dg-do run } */
/* { dg-options -O2 } */
/* { dg-options -O2 -march=z9-109 -mtune=z10 { target s390x-linux } } */
struct S
{
short nargs;
unsigned long arg[2];
};
extern void abort (void);
extern void exit (int);
extern char errstart (int, const char *, int, const char *, const char *);
extern void errfinish (int, ...);
extern int errcode (int);
extern int errmsg (const char *fmt, ...) __attribute__ ((format (printf, 1,
2)));
unsigned long
test (struct S *x)
{
signed int arg1 = x-arg[0];
long int arg2 = x-arg[1];
if (arg2 == 0)
(errstart (20, int8.c, 924, __func__, ((void *) 0))
? (errfinish (errcode (0x2040082), errmsg (division by zero)))
: (void) 0);
return (long int) arg1 / arg2;
}
int
main (void)
{
struct S s = { 2, { 5, 0 } };
test (s);
abort ();
}
__attribute__((noinline)) char
errstart (int x, const char *y, int z, const char *w, const char *v)
{
asm volatile ( : +r (x) : r (y), r (z), r (w), r (v) : memory);
return x;
}
__attribute__((noinline)) int
errcode (int x)
{
asm volatile ( : +r (x) : : memory);
return x;
}
__attribute__((noinline)) int
errmsg (const char *x, ...)
{
asm volatile ( : +r (x) : : memory);
return *x;
}
__attribute__((noinline)) void
errfinish (int x, ...)
{
asm volatile ( : +r (x) : : memory);
if (x)
/* Could be a longjmp or throw too. */
exit (0);
}
The problem is that 2nd scheduler pass reorders the division before some of the
calls. If the calls were guaranteed to return, that would be fine, the program
would crash sooner or later, but as shown in the testcase the call can not
return (exit, longjmp, throw) and in that case whether the division is
scheduled before or after the call matters.
--
Summary: Scheduler reorders division by zero before a call that
might not return
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: s390x-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41239
[Bug fortran/41219] libgfortran build warnings
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-03 08:36 --- The getlogin function is getting prototyped in headers only, if the _POSIX define was set. So a bug-fix here would be for w64 to define before including headers the _POSIX macro. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #9 from ubizjak at gmail dot com 2009-09-03 08:47 --- You can just copy relevant entry from gcc-cvs ml: Author: jamborm Date: Wed Sep 2 17:52:18 2009 New Revision: 151345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151345 Log: 2009-09-02 Martin Jambor mjam...@suse.cz * tree-sra.c (struct access): New field grp_hint. (dump_access): Dump grp_hint. (sort_and_splice_var_accesses): Set grp_hint if a group is read multiple times. (analyze_access_subtree): Only scalarize accesses with grp_hint set or those which have been specifically read and somehow written to. (propagate_subacesses_accross_link): Set grp_hint of right child and also possibly of the left child. * testsuite/gcc.dg/tree-ssa/sra-8.c: New testcase. * testsuite/gcc.dg/memcpy-1.c: Add . to match pattern. * testsuite/gcc.dg/uninit-I.c: XFAIL warning test. * testsuite/g++.dg/warn/unit-1.C: XFAIL warning test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/unit-1.C trunk/gcc/testsuite/gcc.dg/memcpy-1.c trunk/gcc/testsuite/gcc.dg/uninit-I.c trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug lto/41230] [LTO] Segfault using -flto with -fvar-tracking-assignments
--- Comment #7 from ubizjak at gmail dot com 2009-09-03 08:53 --- (In reply to comment #3) Hmm, dropping the stmt looks like it would be a hack. Alex - if I just set flag_var_tracking_assignments to 1 if I encounter a GIMPLE_DEBUG during read-in I get t.c: In function 'foo': t.c:1:6: error: unrecognizable insn: (debug_insn 6 5 14 t.c:3 (var_location:SI hex (mem/c/i:SI (plus:SI (reg/f:SI 20 frame) (const_int -4 [0xfffc])) [0 hex+0 S4 A32])) -1 (nil)) t.c:1:6: internal compiler error: in insn_default_length, at config/i386/i386.md:544 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. is there sth else that I need to do to enable VTA? You should use NONDEBUG_INSN_P instead of INSN_P somewhere. Backtrace will tell you where. I have similar problem on alpha, see perhaps PR 41238. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230
[Bug tree-optimization/38275] bootstrap failure when -ftree-parallelize-loops=4 is enabled
--- Comment #3 from razya at gcc dot gnu dot org 2009-09-03 08:59 --- Subject: Bug 38275 Author: razya Date: Thu Sep 3 08:59:25 2009 New Revision: 151372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151372 Log: PR tree-optimization/38275 * tree-parloops.c (parallelize_loops): Replace profitability condition for expected number of iterations. * testsuite/gcc.dg/autopar/reduc-1char.c: Increase number of iterations. Adjust the logic accordingly. * testsuite/gcc.dg/autopar/reduc-2char.c: Ditto. * testsuite/gcc.dg/autopar/reduc-1.c: Ditto. * testsuite/gcc.dg/autopar/reduc-2.c: Ditto. * testsuite/gcc.dg/autopar/reduc-3.c: Ditto. * testsuite/gcc.dg/autopar/reduc-6.c: Ditto. * testsuite/gcc.dg/autopar/reduc-7.c: Ditto. * testsuite/gcc.dg/autopar/reduc-8.c: Ditto. * testsuite/gcc.dg/autopar/reduc-9.c: Ditto. * testsuite/gcc.dg/autopar/pr39500-1.c: Ditto. * testsuite/gcc.dg/autopar/reduc-1short.c: Ditto. * testsuite/gcc.dg/autopar/reduc-2short.c: Ditto. * testsuite/gcc.dg/autopar/parallelization-1.c: Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/autopar/parallelization-1.c trunk/gcc/testsuite/gcc.dg/autopar/pr39500-1.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-1.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-1char.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-1short.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-2.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-2char.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-2short.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-3.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-6.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-7.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-8.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-9.c trunk/gcc/tree-parloops.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38275
[Bug tree-optimization/38275] bootstrap failure when -ftree-parallelize-loops=4 is enabled
--- Comment #4 from razya at gcc dot gnu dot org 2009-09-03 09:14 --- (In reply to comment #3) Subject: Bug 38275 Author: razya Date: Thu Sep 3 08:59:25 2009 New Revision: 151372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151372 Log: PR tree-optimization/38275 * tree-parloops.c (parallelize_loops): Replace profitability condition for expected number of iterations. * testsuite/gcc.dg/autopar/reduc-1char.c: Increase number of iterations. Adjust the logic accordingly. * testsuite/gcc.dg/autopar/reduc-2char.c: Ditto. * testsuite/gcc.dg/autopar/reduc-1.c: Ditto. * testsuite/gcc.dg/autopar/reduc-2.c: Ditto. * testsuite/gcc.dg/autopar/reduc-3.c: Ditto. * testsuite/gcc.dg/autopar/reduc-6.c: Ditto. * testsuite/gcc.dg/autopar/reduc-7.c: Ditto. * testsuite/gcc.dg/autopar/reduc-8.c: Ditto. * testsuite/gcc.dg/autopar/reduc-9.c: Ditto. * testsuite/gcc.dg/autopar/pr39500-1.c: Ditto. * testsuite/gcc.dg/autopar/reduc-1short.c: Ditto. * testsuite/gcc.dg/autopar/reduc-2short.c: Ditto. * testsuite/gcc.dg/autopar/parallelization-1.c: Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/autopar/parallelization-1.c trunk/gcc/testsuite/gcc.dg/autopar/pr39500-1.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-1.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-1char.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-1short.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-2.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-2char.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-2short.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-3.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-6.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-7.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-8.c trunk/gcc/testsuite/gcc.dg/autopar/reduc-9.c trunk/gcc/tree-parloops.c Fixed in GCC4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38275
[Bug rtl-optimization/41239] Scheduler reorders division by zero before a call that might not return
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-03 09:24 --- sched-deps.c uses may_trap_p only to find out what insns can't be speculated, possibly trapping MEMs are handled by deps_may_trap_p. I wonder what exactly we want to forbid to cure this testcase. Just DIV/MOD/UDIV/UMOD that may_trap_p being moved across a function call that might not return (all CALL_Ps or all except a few known builtins? Say memcpy or strcpy could be said to always return), or all may_trap_p insns across all calls that might not return, or even across all such calls and all trapping insns? Ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41239
[Bug libgcj/28263] [win32] Memory Leak In Cleaning Exception Handling Contexts
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-09-03 09:24 --- This issue is solved for mingw-w64 runtime. It uses no more the mingwm10.dll mechanism. Instead it uses TLS callbacks to implement it. By this reason the Cleaning of Exception Contexts is always present for this runtime. Maybe mingw.org's runtime will support TLS callbacks sometimes, too. This bug remains for Windows OSes without TLS callback support, and for those the -mthreads build-option can solve the issue. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28263
[Bug tree-optimization/38275] bootstrap failure when -ftree-parallelize-loops=4 is enabled
--- Comment #5 from razya at gcc dot gnu dot org 2009-09-03 09:27 --- Fixed for GCC4.5 -- razya at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38275
[Bug tree-optimization/38156] gcc.dg/tree-ssa/update-unswitch-1.c fails when compiled with -ftree-parallelize-loops=4
--- Comment #7 from razya at gcc dot gnu dot org 2009-09-03 09:39 --- (In reply to comment #6) Submited the correct fix: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00277.html Committed for GCC4.5 http://gcc.gnu.org/viewcvs?view=revisionrevision=151373 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38156
[Bug debug/41238] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-03 09:51 --- parm_decl 0x72aca750 c type real_type 0x72ab1000 TFtype sizes-gimplified TF size integer_cst 0x72debc00 constant 128 unit size integer_cst 0x72debc30 constant 16 align 128 symtab -223674816 alias set -1 canonical type 0x72e0b840 precision 128 pointer_to_this pointer_type 0x72acbf00 used TF file ../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c line 1896 col 38 size integer_cst 0x72debc00 128 unit size integer_cst 0x72debc30 16 align 128 context function_decl 0x72ec0b00 __divtc3 (reg/v:TF 11 $11 [orig:188 c ] [188]) arg-type real_type 0x72ab1000 TFtype incoming-rtl (reg:DI 19 $19) chain parm_decl 0x72aca7e0 d Note the different mode between DECL_INCOMING_RTL and DECL_RTL. More importantly, $19 doesn't hold the value c at all, *(long double *)$19 does. Not sure how should var-tracking.c find out this fact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug debug/41238] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-03 10:06 --- Looking at it, vt_find_parameters has been doing this even before VTA merge, thinking the low bits of the argument are in $19 instead of where that register points. At least in 4.4 cross to sparc64-linux for -m32 -mptr32 -g -O2 I see vt_find_parameter thinking the TFmode parameter which is passed at *(long double *)$i0 has its low 32 bits in $i0 itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug target/39064] libiberty md5.h needs uintptr_t
--- Comment #3 from sezeroz at gmail dot com 2009-09-03 10:10 --- The discussion thread at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00778.html still haven't provide a solution for this one even after the recent build system changes.. Will md5.h, splay-tree.h and sha1.h be modified to use autotools support, or, should the suggested patch be applied to md5.h? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064
[Bug lto/41230] [LTO] Segfault using -flto with -fvar-tracking-assignments
--- Comment #8 from rguenther at suse dot de 2009-09-03 10:25 --- Subject: Re: [LTO] Segfault using -flto with -fvar-tracking-assignments On Wed, 2 Sep 2009, rmansfield at qnx dot com wrote: --- Comment #6 from rmansfield at qnx dot com 2009-09-02 22:50 --- (In reply to comment #5) Note that in general you have to repeat all options on the link command line, otherwise you are building with -O0 there. Yep, I realize that. I just came across this crash by accidentally leaving -fvar-tracking-assignments off the link line. Improper usage that cause crashes/ICEs are still worth PRs, right? Yes. We're going to have more of these I guess and need to sort out a general policy (we could for example error out on more incompatible switch combinations - or silently enable switches). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230
[Bug rtl-optimization/41239] Scheduler reorders division by zero before a call that might not return
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-03 10:31 --- We can never move maybe trapping instructions across a function call that might not return (and as we don't have an attribute for returns_always we have to assume that a function may not return always apart from maybe some known builtins). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41239
[Bug tree-optimization/41212] [4.5 Regression] miscompilation at -O2
--- Comment #5 from jpr at csc dot fi 2009-09-03 10:40 --- Adding -fstrict-aliasing to -O1 breaks the code: gfortran -o m m.f90 -O1; ./m y= 0.60653065945526063 2*y= 1.2130613189105213 gfortran -o m m.f90 -O1 -fstrict-aliasing ; ./m y= 0.60653065945526063 2*y= 2. and equally adding -fno-strict-aliasing to -O2 saves the day gfortran -o m m.f90 -O2; ./m y= 0.60653065945526063 2*y= 2. gfortran -o m m.f90 -O2 -fno-strict-aliasing;./m y= 0.60653065945526063 2*y= 1.2130613189105213 Juha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #4 from ramana at gcc dot gnu dot org 2009-09-03 11:03 --- Confirmed with rev 151319 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-03 11:03:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #28 from joseph at codesourcery dot com 2009-09-03 11:04
---
Subject: Re: can not build gcc 4.4.1 on Snow Leopard
Mac OS X 10.6
On Thu, 3 Sep 2009, howarth at nitro dot med dot uc dot edu wrote:
Mike,
Regarding passing -m32 within the x86_64 host case, I was considering the
case of trying to cross compile the i686-apple-darwin10 target on the
x86_64-apple-darwin10 host. While this sounds odd, we currently do this on
i386 fink for 10.6 (but we cheat by using wrappers for the compilers that pass
-m32 and explicitly pass --build=i686-apple-darwin10
--host=i686-apple-darwin10
--target=i686-apple-darwin10 to gcc's configure). Without my proposed patch
in
comment 10, if the user passed...
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10
the i[[3456789]]86-*-darwin* host case won't be triggered but rather the
absent
x86_64-*-darwin* host case. Without the patch, no -m32 will be added to CC
and the compiler will attempt to build the i686-apple-darwin10 compiler with
the default m64 code generation.
If you pass those options, you are asking for the compiler that is built
to be a 64-bit binary itself, but to default to generating 32-bit code.
CC at top level is the compiler for the host, so should be a 64-bit
compiler and no -m32 should be added; adding -m32 is actually *wrong*
here. No pre-existing compiler generating 32-bit code is required by this
configuration (presuming that the build system is also
x86_64-apple-darwin10, the same as the host). If you wanted a compiler
that was a 32-bit binary, as well as generating 32-bit code, you'd specify
--host=i686-apple-darwin10, and pass a 32-bit CC setting.
If I remove the change from comment 20 and use the stock configure from gcc
trunk with...
../gcc/configure --prefix=/Users/howarth/dist
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona
--with-tune=generic --host=x86_64-apple-darwin10 --target=i686-apple-darwin9
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
where /sw is a i386 fink installation containing i386 binaries for gmp/mpfr, I
get the configure failure...
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for the correct version of mpc.h... no
checking for the correct version of the gmp/mpfr libraries... no
configure: error: Building GCC requires GMP 4.2+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
If you are using --host=x86_64-apple-darwin10, you clearly need 64-bit
copies of GMP and MPFR in the appropriate locations.
Adding Apple's patch as...
@@ -3645,6 +3653,12 @@
powerpc-*-darwin*)
host_makefile_frag=config/mh-ppc-darwin
;;
+ i[3456789]86-*-darwin*)
+# gcc can default to x86_64 code generation, avoid that
+if test ${build} = ${host}; then
+ CC=${CC-gcc} -m32
+fi
+;;
This also seems wrong (or at least unnecessary). If the user configures
--host=i686-apple-darwin10 when the host compiler defaults to 64-bit code
generation, the user has passed incorrect configure options. It is the
responsibility of the user in that case to set CC=gcc -m32, not the
responsibility of GCC. This is just the same as if you wish to bootstrap
a 32-bit compiler on x86_64-linux-gnu: you have to set CC appropriately
yourself, as well as passing suitable configure options. Such a bootstrap
works fine, and if you are doing something different here for Darwin from
what is done for the GNU/Linux case that is a good sign you are doing
something wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug target/41240] New: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
As of 20090903 (rev. 151371), mainline fails to bootstrap while building the N64 stage1 libgcc on IRIX 6.5: vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__lshrti3': /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:431:1: error: unrecognizable insn: (debug_insn 14 13 15 3 /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:414 (var_location:DI bm (reg/v:DI 3 $3 [orig:193 bm ] [193])) -1 (nil)) /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:431:1: internal compiler error: in get_attr_got, at config/mips/mips.md:455 This worked fine yesterday (20090902, rev. 151332). -- Summary: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug other/41234] Configure fails to find non-existant g++ preprocessor flag with syntax errors
--- Comment #1 from redi at gcc dot gnu dot org 2009-09-03 11:16 --- You didn't say how you configured it. As with bug 40950, you might need --enable-stage1-languages=c,c++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41234
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #1 from ubizjak at gmail dot com 2009-09-03 11:17 --- get_attr_* does not work with DEBUG_INSN instructions. Backtrace will tell you where to put NONDEBUG_INSN_P instead of INSN_P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug middle-end/40106] [4.4/4.5 Regression] Time increase for the Polyhedron test air.f90 due to bad optimization
--- Comment #31 from dominiq at lps dot ens dot fr 2009-09-03 11:20 --- More reduced nonfunctional (invalid) test to show the problem: IMPLICIT REAL*8(a-H,O-Z) PARAMETER (NX=150,NY=150) DIMENSION NPX(30), FV2(NX,NY), T(NX,NY), dtt(NX,NY) do it = 1, 2000 DO i = 1 , MXPx DO j = 1 , MXPy FV2(i,j) = T(i,j)**1.5 ENDDO ENDDO DO ix = 1 , NDX maxx = maxx + NPX(ix) + 1 DO iy = 1 , NDY DO i = minx , maxx DO j = miny , maxy dtt(i,j) = dtd ENDDO ENDDO miny = miny + NPX(iy) + 1 ENDDO ENDDO end do WRITE (7,*) MXPx , MXPy END [ibook-dhum] test/dbg_air% gfc -S -m64 -O2 -funsafe-math-optimizations air_red.f90 [ibook-dhum] test/dbg_air% grep pow air_red.s call_pow [ibook-dhum] test/dbg_air% gfc -S -m64 -O2 -funsafe-math-optimizations -fno-strict-overflow air_red.f90 [ibook-dhum] test/dbg_air% grep pow air_red.s [ibook-dhum] test/dbg_air% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #2 from ubizjak at gmail dot com 2009-09-03 11:24 --- FYI, similar failure happens on alpha, fixed by: Index: config/alpha/alpha.c === --- config/alpha/alpha.c(revision 151367) +++ config/alpha/alpha.c(working copy) @@ -7664,7 +7664,7 @@ alpha_does_function_need_gp (void) pop_topmost_sequence (); for (; insn; insn = NEXT_INSN (insn)) -if (INSN_P (insn) +if (NONDEBUG_INSN_P (insn) ! JUMP_TABLE_DATA_P (insn) GET_CODE (PATTERN (insn)) != USE GET_CODE (PATTERN (insn)) != CLOBBER -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug debug/41232] [4.5 Regression] VTA: SSA name in freelist but still referenced
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|VTA: SSA name in freelist |[4.5 Regression] VTA: SSA |but still referenced|name in freelist but still ||referenced Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41232
[Bug c++/41231] Error when declaring a nested template member class of a dependent template class a friend
--- Comment #1 from redi at gcc dot gnu dot org 2009-09-03 11:27 --- *** This bug has been marked as a duplicate of 40664 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41231
[Bug c++/40664] Parse error declaring friend class using dependent template instance
--- Comment #2 from redi at gcc dot gnu dot org 2009-09-03 11:27 --- *** Bug 41231 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||pleexed at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40664
[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()
--- Comment #5 from redi at gcc dot gnu dot org 2009-09-03 11:35 --- Your testcase works for me. Please see http://gcc.gnu.org/bugs.html for the information you need to provide, specifically you haven't said how you configured gcc or what command you're using to compile the testcase. Without that noone can analyse the bug and give a solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214
[Bug tree-optimization/41212] [4.5 Regression] miscompilation at -O2
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-03 11:40 --- This looks like your restrict changes get in the way. We have y_13 = (real(kind=8) restrict) y; .. *y_13 = D.1416_35; ... D.1412_51 = y; so one access via the plain y gets re-introduced by forwprop somehow and somehow we conclude y_13 cannot point to it. Hmmm. My bet is on the TBAA hack by micha here ... the local variables have a different alias-set than the pointed-to type in the parameter. Micha - that's quite unfortunate, and I think the only way out is to not do this TBAA trick if the address of such variable is taken - which also means always for global vars. Ugh. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, matz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug bootstrap/41237] [4.5 Regression] Bootstrap failure on powerpc-apple-darwin9 due to a revision between 151343 and 151349
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41237
[Bug debug/41236] [4.5 regression] RTL checking failure compiling libgcc
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41236
[Bug bootstrap/41241] New: [4.5 regression] bootstrap comparison failure
At revision 151371 I get a bootstrap comparison failure on i586 with the default compiler (--enable-checking=yes): Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/cfgloopmanip.o differs gcc/ada/sem_res.o differs gcc/ada/checks.o differs gcc/ada/sem_dist.o differs gcc/ada/exp_ch9.o differs gcc/ada/exp_util.o differs gcc/ada/exp_dist.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/eric/build/gcc/native32' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/eric/build/gcc/native32' make: *** [all] Error 2 Very likely VTA again. -- Summary: [4.5 regression] bootstrap comparison failure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org GCC build triplet: i586-*-linux GCC host triplet: i586-*-linux GCC target triplet: i586-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug fortran/41242] New: procedure pointer is not correctly recognized
When compiling the following code, gfortran does not correctly recognize a procedure pointer and crashes with the following message: no_func.f90:59.12: n_in = prc_lib% get_n_in (2) 1 Error: 'prc_lib' at (1) is not a function I attach the code and also as attachment: module iso_varying_string implicit none type, public :: varying_string private character(len=1), dimension(:), allocatable :: chars end type varying_string interface assignment(=) module procedure op_assign_VS_CH end interface assignment(=) public :: assignment(=) contains elemental subroutine op_assign_VS_CH (string, char) type(varying_string), intent(out) :: string character(len=*), intent(in) :: char integer :: i allocate(string%chars(LEN(char))) forall(i = 1:len(char)) string%chars(i) = char(i:i) end forall end subroutine op_assign_VS_CH end module iso_varying_string module no_func use iso_varying_string, string_t = varying_string !NODEP! implicit none private type :: nf_t private procedure(prc_get_int), nopass, pointer :: get_n_in = null () end type nf_t abstract interface function prc_get_int (pid) result (n) import integer, intent(in) :: pid integer :: n end function prc_get_int end interface contains subroutine no_func_config (prc_lib) type(nf_t), intent(inout), target :: prc_lib integer :: n_in type(string_t) :: prc_id prc_id = foobar n_in = prc_lib% get_n_in (2) end subroutine no_func_config end module no_func -- Summary: procedure pointer is not correctly recognized Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reuter at physik dot uni-freiburg dot de GCC build triplet: on Ubuntu Linux 2.6.27-7-generic Kernel i686 32bit GCC host triplet: gfortran 4.5.0 v151352 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41242
[Bug debug/41238] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-03 11:58 --- Created an attachment (id=18472) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18472action=view) gcc45-pr41238.patch Here is an untested fix (well, tested on the provided testcase, but nothing else). The function.c change is only needed for arguments passed by invisible reference which don't have the pointers passed in registers, but on the stack (say long double argument on alpha or sparc -m32 with -mlong-double-128 which has 6 or so other integral arguments before it). Saying the stack slot contains the parameter is certainly wrong in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug fortran/41242] procedure pointer is not correctly recognized
--- Comment #1 from reuter at physik dot uni-freiburg dot de 2009-09-03 11:58 --- Created an attachment (id=18473) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18473action=view) Test file for the bug report -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41242
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-03 12:40 --- Oh, just curious - if you disable address space randomization, does the build succeed? (echo 0 /proc/sys/kernel/randomize-va-space) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-09-03 12:45 --- Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc --- Comment #1 from ubizjak at gmail dot com 2009-09-03 11:17 --- get_attr_* does not work with DEBUG_INSN instructions. Backtrace will tell you where to put NONDEBUG_INSN_P instead of INSN_P. Unfortunately, gdb 6.8 cannot cope with the debug information created by either gcc 3.4.5 (my current bootstrap compiler) or mainline as of 20090828 (pre-VTA): #0 fancy_abort (file=0x10fd1be0 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x10fd8590 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/diagnostic.c:728 #1 0x10aab0f4 in _fatal_insn (msgid=0x10fe9df8 unrecognizable insn:, insn=0x41b8c60, file=0x10fd1be0 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x10fd8590 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/rtl-error.c:112 #2 0x10aab158 in _fatal_insn_not_found (insn=0x41b8c60, file=0x10fd1be0 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x10fd8590 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/rtl-error.c:120 #3 0x10a06d9c in get_attr_got (insn=0x41b8c60) at /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md:455 #4 0x10232148 in ?? () #5 0x10232434 in ?? () #6 0x10232d78 in ?? () #7 0x10234098 in mips_initial_elimination_offset (from=77, to=29) at /vol/gcc/src/gcc-dist/gcc/config/mips/mips.c:9124 #8 0x101fdc54 in ?? () #9 0x101f3ce8 in reload (first=0x41b8600, global=1) at /vol/gcc/src/gcc-dist/gcc/reload1.c:971 #10 0x101d8c58 in ?? () #11 0x101d92a8 in ?? () #12 0x1070fd38 in ?? () #13 0x10710184 in execute_pass_list (pass=0x11067900) at /vol/gcc/src/gcc-dist/gcc/passes.c:1341 #14 0x107101b0 in execute_pass_list (pass=0x11069310) at /vol/gcc/src/gcc-dist/gcc/passes.c:1342 #15 0x10c15be8 in tree_rest_of_compilation (fndecl=0x412dd00) at /vol/gcc/src/gcc-dist/gcc/tree-optimize.c:390 #16 0x10acbcd8 in ?? () #17 0x10acbfc4 in ?? () #18 0x10acca44 in ?? () #19 0x10acb840 in cgraph_finalize_compilation_unit () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1042 #20 0x100b22a4 in c_write_global_declarations () at /vol/gcc/src/gcc-dist/gcc/c-decl.c:9378 #21 0x101c2e54 in ?? () #22 0x101c63c8 in ?? () #23 0x101c6528 in toplev_main (argc=5, argv=0x7ffb7ef4) at /vol/gcc/src/gcc-dist/gcc/toplev.c:2414 #24 0x101a5d40 in main (argc=5, argv=0x7ffb7ef4) at /vol/gcc/src/gcc-dist/gcc/main.c:35 The line number in mips.md is useless since it's inside a comment. The 4.5 backtrace is even less useful since gdb aborts at some point: #0 fancy_abort (file=0x11001a98 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x1100eaf0 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/diagnostic.c:728 #1 0x10aab1ac in _fatal_insn (msgid=0x11019cc0 unrecognizable insn:, insn=0x41b8c60, file=0x11001a98 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x1100eaf0 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/rtl-error.c:112 #2 0x10aab214 in _fatal_insn_not_found (insn=0x41b8c60, file=0x11001a98 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x1100eaf0 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/rtl-error.c:120 #3 0x109fe898 in get_attr_got (insn=0x41b8c60) at /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md:455 #4 0x102310b8 in ?? () warning: GDB can't find the start of the function at 0x102310b7. GDB is unable to find the start of the function at 0x102310b7 and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0x102310b7 for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. Backtrace stopped: previous frame inner to this frame (corrupt stack?) I'm sort of stuck now. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug debug/41236] [4.5 regression] RTL checking failure compiling libgcc
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-03 13:06 --- Created an attachment (id=18474) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18474action=view) gcc45-pr41236.patch Either this, or just using XEXP (rtl, 0) instead of SUBREG_REG (rtl). This is only RTL checking problem, without RTL checking it will work just fine. Doing full --enable-checking=yes,rtl bootstrap now. -- 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|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41236
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-03 13:06 --- I get different .text sizes for _umoddi3_s.o: - Start of section headers: 676 (bytes into file) + Start of section headers: 684 (bytes into file) ... - [ 1] .text PROGBITS 40 000148 00 AX 0 0 1 6 + [ 1] .text PROGBITS 40 000150 00 AX 0 0 1 6 which amounts to different asm: @@ -11,129 +11,135 @@ 4: 56 push %esi 5: 83 ec 20sub$0x20,%esp 8: 8b 7d 14mov0x14(%ebp),%edi - b: 8b 45 08mov0x8(%ebp),%eax + b: 8b 55 08mov0x8(%ebp),%edx e: 8b 4d 10mov0x10(%ebp),%ecx 11: 8b 75 0cmov0xc(%ebp),%esi 14: 85 ff test %edi,%edi - 16: 89 45 e8mov%eax,-0x18(%ebp) - 19: 89 4d f4mov%ecx,-0xc(%ebp) - 1c: 89 45 f0mov%eax,-0x10(%ebp) - 1f: 89 f2 mov%esi,%edx + 16: 89 d0 mov%edx,%eax + 18: 89 4d f4mov%ecx,-0xc(%ebp) + 1b: 89 55 f0mov%edx,-0x10(%ebp) + 1e: 89 75 ecmov%esi,-0x14(%ebp) 21: 75 15 jne0x38 23: 39 f1 cmp%esi,%ecx - 25: 76 49 jbe0x70 - 27: f7 f1 div%ecx - 29: 89 d0 mov%edx,%eax - 2b: 31 d2 xor%edx,%edx - 2d: 83 c4 20add$0x20,%esp - 30: 5e pop%esi - 31: 5f pop%edi - 32: 5d pop%ebp - 33: c3 ret - 34: 8d 74 26 00 lea0x0(%esi,%eiz,1),%esi + 25: 76 51 jbe0x78 + 27: 89 f2 mov%esi,%edx + 29: f7 f1 div%ecx + 2b: 89 d0 mov%edx,%eax + 2d: 31 d2 xor%edx,%edx + 2f: 83 c4 20add$0x20,%esp + 32: 5e pop%esi + 33: 5f pop%edi + 34: 5d pop%ebp + 35: c3 ret + 36: 66 90 xchg %ax,%ax 38: 39 f7 cmp%esi,%edi - 3a: 77 54 ja 0x90 - 3c: 0f bd c7bsr%edi,%eax - 3f: 83 f0 1fxor$0x1f,%eax - 42: 89 45 ecmov%eax,-0x14(%ebp) - 45: 75 59 jne0xa0 + 3a: 77 5c ja 0x98 + 3c: 0f bd d7bsr%edi,%edx + 3f: 83 f2 1fxor$0x1f,%edx + 42: 89 55 e8mov%edx,-0x18(%ebp) + 45: 75 61 jne0xa8 47: 8b 4d f0mov-0x10(%ebp),%ecx 4a: 39 4d f4cmp%ecx,-0xc(%ebp) - 4d: 0f 96 c1setbe %cl - 50: 39 f7 cmp%esi,%edi - 52: 0f 92 c0setb %al - 55: 08 c1 or %al,%cl - 57: 74 0b je 0x64 - 59: 8b 75 f0mov-0x10(%ebp),%esi - 5c: 2b 75 f4sub-0xc(%ebp),%esi - 5f: 19 fa sbb%edi,%edx - 61: 89 75 f0mov%esi,-0x10(%ebp) - 64: 8b 45 f0mov-0x10(%ebp),%eax - 67: 83 c4 20add$0x20,%esp - 6a: 5e pop%esi - 6b: 5f pop%edi - 6c: 5d pop%ebp - 6d: c3 ret - 6e: 66 90 xchg %ax,%ax - 70: 85 c9 test %ecx,%ecx - 72: 75 0b jne0x7f - 74: b8 01 00 00 00 mov$0x1,%eax - 79: 31 d2 xor%edx,%edx - 7b: f7 f1 div%ecx - 7d: 89 c1 mov%eax,%ecx - 7f: 89 f0 mov%esi,%eax + 4d: 0f 96 c2setbe %dl + 50: 3b 7d eccmp-0x14(%ebp),%edi + 53: 0f 92 c0setb %al + 56: 08 c2 or %al,%dl + 58: 74 0e je 0x68 + 5a: 8b 45 ecmov-0x14(%ebp),%eax + 5d: 2b 4d f4sub-0xc(%ebp),%ecx + 60: 19 f8 sbb%edi,%eax + 62: 89 4d f0mov%ecx,-0x10(%ebp) + 65: 89 45 ecmov%eax,-0x14(%ebp) + 68: 8b 45 f0mov-0x10(%ebp),%eax + 6b: 8b 55 ecmov-0x14(%ebp),%edx + 6e: 83 c4 20add$0x20,%esp ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #5 from ubizjak at gmail dot com 2009-09-03 13:08 --- (In reply to comment #3) I'm sort of stuck now. Add -save-temps to failing command on a native compiler, create a crosscompiler on i.e. x86_64 and debug ../gcc/cc1 from crosscompiler with -O2 -g some_file.i in x86_64 host. You don't even need to create binutils cross to create cc1, although the full build won't finish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-09-03 13:09 --- Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc --- Comment #4 from jakub at gcc dot gnu dot org 2009-09-03 13:03 --- Just try latest CVS gdb, or apply the 2 fixes recently mentioned on gcc-patches ml (DW_CFA_restore_state gdb fix and DW_LNE_set_distriminator fix), or just recompile anything you see in the backtrace with -g -O0. gdb 6.8 should be able to cope with gcc 3.4.5 output, and since this is in stage1, everything was already built with -g only. I'll try the CVS gdb to see if this helps. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-03 12:32 --- I see similar failure with r151376 on x86_64 with the 32bit multilibs. Trying to reproduce now. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i586-*-linux|i586-*-linux, x86_64-*-linux Last reconfirmed|-00-00 00:00:00 |2009-09-03 12:32:11 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-03 13:19 --- I get different code with two invocations of stage2 gcc. -g is needed, and you have to be lucky with address space randomization. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug bootstrap/41243] New: [4.5 regression] Revision 151313 caused random compare failure
On Linux/ia32 and Linux/x86-64, I got random compare failures during bootstrap: Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! x86_64-unknown-linux-gnu/32/libgcc/_umoddi3.o differs make[5]: *** [compare] Error 1 Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! i686-pc-linux-gnu/libgcc/bid128_fma.o differs make[5]: *** [compare] Error 1 It is not reproducible. -- Summary: [4.5 regression] Revision 151313 caused random compare failure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal 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=41243
[Bug debug/41236] [4.5 regression] RTL checking failure compiling libgcc
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-03 13:35 --- That still assumes that inside of SIGN_EXTEND/ZERO_EXTEND is a REG, which isn't always the case. Testing with loc_descriptor call there instead now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41236
[Bug tree-optimization/41244] New: data[i] - data isn't converted to i
In attached code:
in find(), generated code computes offset using multiplication/division.
in set(), generated code computes data[10] and compares data[i] with that (to
verify find() fails to be optimised because of overflow rules)
tested gcc: 4.3.4, 4.4.1, 4.5.0-alpha20090827
command line:
gcc main.c -o main.o -c -O3
-f(no-)strict-overflow or -m32 doesn't have any effect on that behaviour
-
static struct {
int a, b, c;
char pad[200]; /* padding so offset computation has to use expensive
div/mul */
} data[1000]; /* 1000 so loop isn't unrolled */
int find(int val)
{
int i;
for (i = 0; i 1000; i++) {
if (data[i].a == val) return data[i] - data; /* does *212,
/212 */
}
return -1;
}
void set(int val)
{
int i;
for (i = 0; i 1000; i++) {
data[i].b = data[i] - data 10 || data[i].a == val; /*
compares with data[10] */
}
}
-
Relevant generated ASM:
(eax is i, sar+imul is converted division by 212)
-
cdqe
imulrax, rax, 212
sar rax, 2
imuleax, eax, -1944890851
ret
-
--
Summary: data[i] - data isn't converted to i
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244
[Bug tree-optimization/41244] data[i] - data isn't converted to i
--- Comment #1 from zsojka at seznam dot cz 2009-09-03 13:50 --- Created an attachment (id=18475) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18475action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2009-09-03
13:53 ---
Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455
building stage1 N64 libgcc
--- Comment #5 from ubizjak at gmail dot com 2009-09-03 13:08 ---
(In reply to comment #3)
I'm sort of stuck now.
Add -save-temps to failing command on a native compiler, create a
crosscompiler
on i.e. x86_64 and debug ../gcc/cc1 from crosscompiler with -O2 -g
some_file.i in x86_64 host. You don't even need to create binutils cross to
create cc1, although the full build won't finish.
Good point: I routinely forget about cross compilers until I really have
to. This was really beneficial in this case, since the X4450 is a *much*
faster box. I did have to build cross binutils, though, since the bug is
only triggered when certain assembler features are present (I haven't
checked exactly which ones, but a cross compiler without a cross gas 2.19.1
didn't ICE).
I've come up with the following patch, similar to your's for the alpha:
2009-09-03 Rainer Orth r...@cecitec.uni-bielefeld.de
PR target/41240
* config/mips/mips.c (mips_function_has_gp_insn): Ignore debug insn.
Index: config/mips/mips.c
===
--- config/mips/mips.c (revision 151371)
+++ config/mips/mips.c (working copy)
@@ -8579,7 +8579,7 @@
push_topmost_sequence ();
for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
- if (USEFUL_INSN_P (insn)
+ if (USEFUL_INSN_P (insn) !DEBUG_INSN_P (insn)
(get_attr_got (insn) != GOT_UNSET
|| mips_small_data_pattern_p (PATTERN (insn
{
With it, my testcase passed and the cross-build ran until it hit missing
target headers. I'm now continuing the really bootstrap and will submit it
once that finishes.
Thanks alot.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #7 from hjl dot tools at gmail dot com 2009-09-03 13:54 --- *** Bug 41243 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug bootstrap/41243] [4.5 regression] Revision 151313 caused random compare failure
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-03 13:54 --- *** This bug has been marked as a duplicate of 41241 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41243
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #8 from hjl dot tools at gmail dot com 2009-09-03 13:56 --- It may be caused by VTA merge. I also got random compare failures. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug bootstrap/41245] New: [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
Subject says it all; i386-apple-darwin is a primary platform. Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree.o differs The output of ../trunk/contrib/compare-debug --preserve stage[23]-gcc/tree.o is long, so I'll attach it, but the end of it says: stage2-gcc/tree.o.stripped stage3-gcc/tree.o.stripped differ: char 529, line 4 stripping off .eh_frame, then retrying failed to strip off .eh_frame stage2-gcc/tree.o.stripped stage3-gcc/tree.o.stripped differ: char 529, line 4 preserving stage2-gcc/tree.o.stripped stage3-gcc/tree.o.stripped I also did a dwarfdump of both stripped files, and the difference between those two is minimal: --- dwarfdump2 2009-09-03 15:55:53.0 +0200 +++ dwarfdump3 2009-09-03 15:55:57.0 +0200 @@ -1,5 +1,5 @@ -- - File: stage2-gcc/tree.o.stripped (i386) + File: stage3-gcc/tree.o.stripped (i386) -- .debug_info contents: @@ -32812,7 +32812,7 @@ 0x0001c7d3: TAG_lexical_block [88] * AT_ranges( 0x0240 -[0x1328 - 0x1395) +[0x132c - 0x1395) [0x1398 - 0x139a) End ) So I guess this should be easier to understand than the corresponding powerpc issue (41224). -- Summary: [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: aoliva at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i386-apple-darwin9.8.0 GCC host triplet: i386-apple-darwin9.8.0 GCC target triplet: i386-apple-darwin9.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug tree-optimization/41244] data[i] - data isn't converted to i
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-03 14:12 ---
Because the index arithmetic is done unsigned.
return (int) ((unsigned int) i * 212) /[ex] 212;
We lost the information that i * 212 cannot overflow.
Simpler testcase:
extern int data[];
int find(int i)
{
return data[i] - data;
}
from which we enter c_fully_fold_internal with
((int) ((int *) data + (unsigned int) ((unsigned int) i * 4)) - (int) data)
/[ex] 4
addressed on the no-undefined-overflow branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2009-09-03 14:12:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-09-03 14:13 --- -g is not needed after all. It's just very random. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug debug/41238] [4.5 Regression] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|VTA: bootstrap failure, ICE |[4.5 Regression] VTA: |in loc_cmp, at var- |bootstrap failure, ICE in |tracking.c:2456 |loc_cmp, at var- ||tracking.c:2456 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug fortran/41168] incorrect processing of formatted records in mingw port
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-09-03 14:19 --- I can confirm I can reproduce this bug with an darwin-to-mingw cross-compiler, and running the executable under wine. I can also confirm that it's about the REWIND statement: if you have already run the test program once, you can recompile it without the WRITE and the REWIND, using the already existing testcase. Then, it passes OK. It's probably some bad counting of position on platforms with HAVE_CRLF. To investigate, it should be possible to build such a faulty linux compiler by forcing HAVE_CRLF to be true. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-03 14:19:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41168
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #10 from hjl dot tools at gmail dot com 2009-09-03 14:25 --- I got my first compare failure at revision 151353. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug driver/41024] driver passes wrong parameter to as
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-09-03 14:40
---
It's because of this in gcc/config/i386/mingw-w64.h:
#define ASM_SPEC %{v:-V} %{n} %{T} %{Ym,*} %{Yd,*} \
%{Wa,*:%*} %{m32:--32} %{m64:--64}
The %{v:-V} part is what's triggering what you see. Now, the question is why
is your as rejecting the -V option? My linux as accepts it, my darwin as also,
but i586-pc-mingw32-as doesn't...
After further investigation, it seems that handling the option -V on i386
processors is only done for ELF targets; can't even begin to think of a good
reason for that, but that's what gas source code says. So, I recommend the
following (untested) patch to GCC:
Index: gcc/config/i386/mingw-w64.h
===
--- gcc/config/i386/mingw-w64.h (revision 151373)
+++ gcc/config/i386/mingw-w64.h (working copy)
@@ -36,7 +36,7 @@
/* Enable multilib. */
#undef ASM_SPEC
-#define ASM_SPEC %{v:-V} %{n} %{T} %{Ym,*} %{Yd,*} \
+#define ASM_SPEC %{v} %{n} %{T} %{Ym,*} %{Yd,*} \
%{Wa,*:%*} %{m32:--32} %{m64:--64}
#if TARGET_64BIT_DEFAULT
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||patch
Last reconfirmed|-00-00 00:00:00 |2009-09-03 14:40:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41024
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-09-03 14:51 --- Created an attachment (id=18476) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18476action=view) testcase testcase, _umoddi_s.i from libgcc2.c valgrind ./cc1 -quiet -O2 -m32 t.i ==1232== Invalid read of size 1 ==1232==at 0x84CA158: reg_preferred_class (reginfo.c:916) ==1232==by 0x8415E19: update_equiv_regs (ira.c:2397) ==1232==by 0x8417A8F: ira (ira.c:3135) ==1232==by 0x8418335: rest_of_handle_ira (ira.c:3343) ==1232==by 0x84911CB: execute_one_pass (passes.c:1292) ==1232==by 0x84913FF: execute_pass_list (passes.c:1341) ==1232==by 0x849141B: execute_pass_list (passes.c:1342) ==1232==by 0x85EEB4B: tree_rest_of_compilation (tree-optimize.c:390) ==1232==by 0x8801650: cgraph_expand_function (cgraphunit.c:) ==1232==by 0x8801801: cgraph_expand_all_functions (cgraphunit.c:1170) ==1232==by 0x8801E72: cgraph_optimize (cgraphunit.c:1429) ==1232==by 0x8801355: cgraph_finalize_compilation_unit (cgraphunit.c:1042) ==1232== Address 0x4ac5707 is 0 bytes after a block of size 495 alloc'd ==1232==at 0x40240D2: calloc (vg_replace_malloc.c:397) ==1232==by 0x8B3E40F: xcalloc (xmalloc.c:162) ==1232==by 0x84CA23E: allocate_reg_info (reginfo.c:950) ==1232==by 0x84CA411: reginfo_init (reginfo.c:1003) ==1232==by 0x84911CB: execute_one_pass (passes.c:1292) ==1232==by 0x84913FF: execute_pass_list (passes.c:1341) ==1232==by 0x849141B: execute_pass_list (passes.c:1342) ==1232==by 0x85EEB4B: tree_rest_of_compilation (tree-optimize.c:390) ==1232==by 0x8801650: cgraph_expand_function (cgraphunit.c:) ==1232==by 0x8801801: cgraph_expand_all_functions (cgraphunit.c:1170) ==1232==by 0x8801E72: cgraph_optimize (cgraphunit.c:1429) ==1232==by 0x8801355: cgraph_finalize_compilation_unit (cgraphunit.c:1042) not sure if this is the cause of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #12 from vmakarov at redhat dot com 2009-09-03 15:01 --- It looks as an old IRA rare hidden bug which was triggered by the new patches. I check IRA on valgrind on a lot of tests but never saw it. Update_equiv_reg imported from the old RA uses pseudo class but it was never set up. And the problem is that it can not be set up at this stage yet. I'll send a patch to fix it in a few hours. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug middle-end/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-09-03 15:10 --- Also happens on i586-pc-mingw32 and with -m64 on i386-apple-darwin9. This P1 regression is more than 4 months old, and has a proposed patch; could someone post the patch for review? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i686-pc-linux-gnu, x86- |i686 |linux-gnu | Keywords||patch Last reconfirmed|2009-06-21 23:34:38 |2009-09-03 15:10:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
[Bug middle-end/40364] ICE in in purge_dead_edges, at cfgrtl.c:2325 compiling MAME
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-09-03 15:10 --- Will have to be tested again once PR 39886 is done with; hopefully, should then be gone. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40364
[Bug target/39694] -print-file-name doesn't work on mingw in 100%.
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-09-03 15:15 --- Works for me with current mainline: $ i586-pc-mingw32-gcc -print-file-name=libgcc_s.a /Users/fx/devel/mingw/cross/lib/gcc/i586-pc-mingw32/4.5.0/../../../../i586-pc-mingw32/lib/libgcc_s.a $ i586-pc-mingw32-gcc -print-file-name=libgcc.a /Users/fx/devel/mingw/cross/lib/gcc/i586-pc-mingw32/4.5.0/libgcc.a -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Known to fail||4.4.0 Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39694
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-09-03 15:24 --- Can you try a x86_64-apple-darwin9 bootstrap as well? It is puzzling that on x86_64-apple-darwin10, the corresponding dwarfdump for the stage2 binaries is empty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-03 15:26 --- Dominique, Can you run dwarfdump on a stage2 and stage3 binary that differ from this failed build on powerpc-apple-darwin9? Is there actual differences or is the stage2 binary empty like on x86_64-apple-darwin10? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-03 15:32 --- stage2 objects shouldn't contain any debug info, they are compiled with -g0. What is being checked is that after stripping debug info, both -g0 and -g objects should be the same (i.e. the code itself, data, ...). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug c/41246] New: %ecx corruption when combining -regparm=3 with nested functions
On i386, combining -regparm=3 with nested functions results in %ecx (holding the third function parameter because of -regparm=3) being overwritten with a temporary pointer used by GCC to implement the nested function call. GNU GRUB has had a workaround (disabling -regparm in a case-by-case basis) to this bug for a long while. It's only been brought up to me recently that we had this problem (I'm one of the GRUB maintainers). One of the GRUB developers (Bean) produced a test case. I'm attaching it here. -- Summary: %ecx corruption when combining -regparm=3 with nested functions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmh at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
[Bug c/41246] %ecx corruption when combining -regparm=3 with nested functions
--- Comment #1 from rmh at gcc dot gnu dot org 2009-09-03 15:34 --- Created an attachment (id=18477) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18477action=view) test case $ gcc -m32 regparm_nested.c ./a.out 10 31 31 $ gcc -m32 -mregparm=3 regparm_nested.c ./a.out 10 31 -3957600 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
[Bug debug/41238] [4.5 Regression] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #5 from ro at gcc dot gnu dot org 2009-09-03 15:56 --- Created an attachment (id=18478) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18478action=view) stage2 c-common.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug debug/41238] [4.5 Regression] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #6 from ro at gcc dot gnu dot org 2009-09-03 15:57 --- Created an attachment (id=18479) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18479action=view) stage3 c-common.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug debug/41238] [4.5 Regression] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #7 from ro at gcc dot gnu dot org 2009-09-03 15:59 --- With your patch, the ICE on sparc-sun-solaris2.11 is gone, but the bootstrap still aborts with a comparison failure: Bootstrap comparison failure! gcc/objc/objc-act.o differs gcc/c-common.o differs I'm attaching the stage2 and 3 c-common.s files for investigation: apart from massive differences in label names, there are some code generation diffs as well. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #16 from dominiq at lps dot ens dot fr 2009-09-03 16:07 --- Is there actual differences or is the stage2 binary empty like on x86_64-apple-darwin10? The file I looked at (was stage2-gcc/intl.o) was empty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #17 from dominiq at lps dot ens dot fr 2009-09-03 16:15 --- If I am not mistaken, strip on darwin does not strip the DWARF stuff by default nor with the options I have tried (including -S file.o -o out_file). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug debug/41236] [4.5 regression] RTL checking failure compiling libgcc
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-03 16:36 --- 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=41236
[Bug c++/41231] Error when declaring a nested template member class of a dependent template class a friend
--- Comment #2 from pleexed at gmail dot com 2009-09-03 16:36 --- Created an attachment (id=18481) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18481action=view) Workaround By declaring a typedef in a templated proxy class and using that in the friend declaration, the desired effect of the original testcase can be produced, without provoking a compiler or linker error. The code in this attachment works on my system as posted in the initial bug report (g++ (Ubuntu 4.3.2-2ubuntu9) 4.3.3 20081217 (prerelease)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41231
[Bug debug/41238] [4.5 Regression] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #10 from ubizjak at gmail dot com 2009-09-03 16:36 --- The patch works for alpha too, up to the point where bootstrap hits: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-vect-slp.o differs gcc/c-common.o differs gcc/ipa-struct-reorg.o differs gmake[2]: *** [compare] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug fortran/41212] [4.5 Regression] miscompilation at -O2
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-03 16:39 --- Hmm, in a sense what forward prop is doing is at least fishy. It forwards the casted ADDR_EXPR into some references of y_13, but not into all of them. As y_13 is a restrict pointer this is always going to be a problem, because suddenly you have accesses to the object via that restrict pointer and via something else not based on that pointer. Either forward prop needs to forward this into _all_ y_13 uses or into none. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug bootstrap/41247] New: [4.5 regression] Comparison failure on Solaris 11/SPARC after VTA merge
As already reported in PR debug/41238, Comment #7, even after applying Jakubs patch there are still two comparison failures that break bootstrap. See the attachements there for details. -- Summary: [4.5 regression] Comparison failure on Solaris 11/SPARC after VTA merge Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.11 GCC host triplet: sparc-sun-solaris2.11 GCC target triplet: sparc-sun-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41247
[Bug target/41246] %ecx corruption when combining -regparm=3 with nested functions
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-03 16:40 --- Yes, I think we should sorry() here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
[Bug target/39065] libiberty hashtab.c:hash_pointer() needs intptr_t
--- Comment #6 from hjl at gcc dot gnu dot org 2009-09-03 16:46 --- Subject: Bug 39065 Author: hjl Date: Thu Sep 3 16:46:00 2009 New Revision: 151386 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151386 Log: 2009-09-03 Ozkan Sezer seze...@gmail.com PR target/39065 * configure.ac: Also check for intptr_t. * config.h.in: Regenerated. * configure: Regenerated. * hashtab.c (hash_pointer): Cast the pointer argument to intptr_t instead of of long. Modified: trunk/libiberty/ChangeLog trunk/libiberty/config.in trunk/libiberty/configure trunk/libiberty/configure.ac trunk/libiberty/hashtab.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
[Bug fortran/41212] [4.5 Regression] miscompilation at -O2
--- Comment #8 from rguenther at suse dot de 2009-09-03 16:50 --- Subject: Re: [4.5 Regression] miscompilation at -O2 On Thu, 3 Sep 2009, matz at gcc dot gnu dot org wrote: --- Comment #7 from matz at gcc dot gnu dot org 2009-09-03 16:39 --- Hmm, in a sense what forward prop is doing is at least fishy. It forwards the casted ADDR_EXPR into some references of y_13, but not into all of them. As y_13 is a restrict pointer this is always going to be a problem, because suddenly you have accesses to the object via that restrict pointer and via something else not based on that pointer. Either forward prop needs to forward this into _all_ y_13 uses or into none. That won't help. The canonical counter-example would be that the caller already accesses the plain y and z variables. That forwprop simulates this is just unfortunate. I'll nevertheless look into the forwprop issue - but that will just fix this particular testcase without addressing the real problem. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug bootstrap/41237] [4.5 Regression] Bootstrap failure on powerpc-apple-darwin9 due to a revision between 151343 and 151349
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-09-03 16:58 --- I don't have access to powerpc-apple-darwin9 so I cannot investigate this. Moreover, I doubt my commit (r151345) is the one that has caused this. Therefore I'll remove myself from the CC. However, if you find out that I am wrong and my commit is indeed the problem, feel free to assign this bug to me (though I will need some assistance trying things out). Thanks. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41237
[Bug middle-end/41248] New: Assertion at 2910 of cfgexpand.c (expand_debug_locations)
On ia64-hp-hpux11.23, which supports a 32 and 64 bit mode, I get an assertion failure during bootstrap. This is with version 151382. insn is: (debug_insn 52 51 53 9 /proj/opensrc/nightly/src/trunk/libgcc/../gcc/gcov-io.c:238 (var_location:SI result (high (nil))) -1 (nil)) val is: (plus:DI (const:DI (plus:DI (symbol_ref:DI (__gcov_var) [flags 0x2] var_decl 7b50cba0 __gcov_var) (const_int 12 [0xc]))) (mult:SI (plus:SI (reg:SI 340 [ prephitmp.26 ]) (const_int 4 [0x4])) (const_int 4 [0x4]))) So the modes do not match. I am compiling in 32 bit mode, so ptr_mode is SImode but Pmode is DImode. -- Summary: Assertion at 2910 of cfgexpand.c (expand_debug_locations) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41248
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-09-03 16:32 --- My mistake. I believe dwarfdump is showing the debug symbols and not the sections. The stage2 build apparently doesn't generate any debug symbols. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug debug/41238] [4.5 Regression] VTA: bootstrap failure, ICE in loc_cmp, at var-tracking.c:2456
--- Comment #9 from jakub at gcc dot gnu dot org 2009-09-03 16:35 --- Fixed. For the sparc comparison failures please open a new bug. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
[Bug debug/41236] [4.5 regression] RTL checking failure compiling libgcc
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-03 16:33 --- Subject: Bug 41236 Author: jakub Date: Thu Sep 3 16:33:27 2009 New Revision: 151385 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151385 Log: PR debug/41236 * dwarf2out.c (loc_descriptor): Don't use SUBREG_REG macro on SIGN_EXTEND or ZERO_EXTEND. Don't assume there is a REG inside of it or SUBREG. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41236
