[Bug bootstrap/21168] New: bootstrap failed on Linux/ia64
This patch http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02301.html caused /net/gnu-9/export/gnu/src/gcc-next/gcc/gcc/config/ia64/crtfastmath.c: In function \u\u\u__ia64_set_fast_math /net/gnu-9/export/gnu/src/gcc-next/gcc/gcc/config/ia64/crtfastmath.c:37: internal compiler error: in schedule_block, at haifa-sched.c:2111 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [crtfastmath.o] Error 1 make[4]: *** Waiting for unfinished jobs -- Summary: bootstrap failed on Linux/ia64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org,nathan at codesourcery dot com GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21168
[Bug tree-optimization/21155] [4.1 Regression] ICE in ssa tree check compiling crafty with -ftree-vectorize -maltivec
-- What|Removed |Added Keywords||ice-on-valid-code Summary|ICE in ssa tree check |[4.1 Regression] ICE in ssa |compiling crafty with - |tree check compiling crafty |ftree-vectorize -maltivec |with -ftree-vectorize - ||maltivec Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21155
[Bug bootstrap/21162] Build failure
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-22 17:38 --- David, could you help here? I don't think a cross-compiler is necessary. -- What|Removed |Added CC||davem at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug bootstrap/21162] New: Build failure
I get a build failure while building stage2 in a bootstrap-lean on Debian Sarge for sparc on a Sun Blade 100. I used the following command: ~/gcc-build$ ../gcc-4.0.0/configure --prefix=/usr/local/gnu/gcc/4.0.0 && make bootstrap-lean check install The tail end of the build process is as follows. I can make a transcript of the entire process if that will help. stage1/xgcc -Bstage1/ -B/usr/local/gnu/gcc/4.0.0/sparc64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild -I../../gcc-4.0.0/gcc -I../../gcc-4.0.0/gcc/build -I../../gcc-4.0.0/gcc/../include -I../../gcc-4.0.0/gcc/../libcpp/include \ -o build/errors.o ../../gcc-4.0.0/gcc/errors.c stage1/xgcc -Bstage1/ -B/usr/local/gnu/gcc/4.0.0/sparc64-unknown-linux-gnu/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a /usr/bin/ld: warning: sparc architecture of input file `../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible with sparc:v9 output /usr/bin/ld: warning: sparc architecture of input file `../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible with sparc:v9 output /usr/bin/ld: warning: sparc architecture of input file `../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible with sparc:v9 output /usr/bin/ld: warning: sparc architecture of input file `../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible with sparc:v9 output ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x3b0): In function `find_empty_slot_for_expand': ../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x3cc):../../../gcc-4.0.0/libiberty/hashtab.c:261: undefined reference to `.umul' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x40c):../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x42c):../../../gcc-4.0.0/libiberty/hashtab.c:261: undefined reference to `.umul' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x624): In function `htab_find_with_hash': ../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x640):../../../gcc-4.0.0/libiberty/hashtab.c:261: undefined reference to `.umul' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x6bc):../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x6dc):../../../gcc-4.0.0/libiberty/hashtab.c:261: undefined reference to `.umul' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x7b4): In function `htab_find_slot_with_hash': ../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x7d0):../../../gcc-4.0.0/libiberty/hashtab.c:261: undefined reference to `.umul' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x854):../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x874):../../../gcc-4.0.0/libiberty/hashtab.c:261: undefined reference to `.umul' ../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)(.text+0x124): In function `xcalloc': ../../../gcc-4.0.0/libiberty/xmalloc.c:161: undefined reference to `.umul' collect2: ld returned 1 exit status make[2]: *** [build/genmodes] Error 1 make[2]: Leaving directory `/home/gnu/gcc-build/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/home/gnu/gcc-build/gcc' make: *** [bootstrap-lean] Error 2 I was previously getting a similar error when trying to build gcc 3.4.3 in the same environment. I've got GNU as version 2.15, GNU ld version 2.15 (I presume this is all the same version number for binutils). Will provide additional info upon request. -- Summary: Build failure Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jdavidb at goreadthebible dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc64-unknown-linux-gnu GCC host triplet: sparc64-unknown-li
[Bug c++/21165] [4.0/4.1 Regression] bogus error on a user-defined conversion in a template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-23 04:18 --- Confirmed, it ICEs with checking enabled: t.cc: In member function 'typename T::BA C< , T>::foo(typename T::BA)': t.cc:23: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have typename_type in lookup_conversions, at cp/search.c:2407 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-checking, ice-on-valid- ||code, rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-04-23 04:18:57 date|| Summary|bogus error on a user- |[4.0/4.1 Regression] bogus |defined conversion in a |error on a user-defined |template|conversion in a template Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21165
[Bug middle-end/20973] [4.0 Regression] kdelibs (khtml) miscompiled by reload
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-22 17:30 --- Subject: Bug 20973 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-22 17:30:21 Modified files: gcc: ChangeLog reload.c Log message: PR middle-end/20973 * reload.c (push_reload, find_dummy_reload): Check for uninitialized pseudos. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.177&r2=2.7592.2.178 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.268&r2=1.268.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
[Bug c++/21166] g++ gives error on reference to packed structure elements
-- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21166
[Bug fortran/20864] different types not diagnosed correctly
-- What|Removed |Added Keywords||accepts-invalid Summary|error needed|different types not ||diagnosed correctly http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20864
[Bug bootstrap/21162] Build failure
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-22 17:42 --- > For that matter, if one cannot build the 64 bit compiler with the stock > compiler > on Debian sparc64-unknown-linux-gnu, how does one build this compiler? That's a Debian problem, the system compiler is probably the 32-bit biarch compiler, in which case you have to configure with CC="gcc -m64" to bootstrap the 64-bit compiler. Does that solve the problem? -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug libfortran/21108] reshape with order causes memory corruption
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-22 20:02 --- Subject: Bug 21108 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-22 20:02:44 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/generated: reshape_i4.c reshape_i8.c libgfortran/intrinsics: reshape_generic.c libgfortran/m4 : reshape.m4 Added files: gcc/testsuite/gfortran.dg: nested_reshape.f90 reshape-alloc.f90 reshape.f90 Log message: 05-04-22 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * gfortran.dg/nested_reshape.f90: new test * gfortran.dg/reshape-alloc.f90: new test * gfortran.dg/reshape.f90: new test 2005-04-22 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * m4/reshape.m4 (reshape_`'rtype_kind): rs, rex: New variables, to be used in calculation of return array sizes. Populate return array descriptor if ret->data is NULL. Fix condition for early return (it used to test something undefined if order was used). Remove duplicate check wether pad is used. * intrinsics/reshape_generic.c (reshape_generic): Likewise. Fix a few places where the wrong variables were set. * generated/reshape_i4.c: Regenerated. * generated/reshape_i8.c: Regenerated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_reshape.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/reshape-alloc.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/reshape.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5383&r2=1.5384 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.198&r2=1.199 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i4.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i8.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/reshape_generic.c.diff?cvsroot=gcc&r1=1.7&r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/reshape.m4.diff?cvsroot=gcc&r1=1.7&r2=1.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21108
[Bug fortran/20863] error needed
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-22 14:41 --- No. 7 in the lower part of p. 212 of the draft f95 standard. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-22 14:41:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20863
[Bug fortran/20865] statement function shall not be supplied as procedure argument
-- What|Removed |Added Keywords||accepts-invalid Summary|error needed|statement function shall not ||be supplied as procedure ||argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20865
[Bug libfortran/20436] usring nested reshape functions gives runtime error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-22 20:02 --- Subject: Bug 20436 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-22 20:02:44 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/generated: reshape_i4.c reshape_i8.c libgfortran/intrinsics: reshape_generic.c libgfortran/m4 : reshape.m4 Added files: gcc/testsuite/gfortran.dg: nested_reshape.f90 reshape-alloc.f90 reshape.f90 Log message: 05-04-22 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * gfortran.dg/nested_reshape.f90: new test * gfortran.dg/reshape-alloc.f90: new test * gfortran.dg/reshape.f90: new test 2005-04-22 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * m4/reshape.m4 (reshape_`'rtype_kind): rs, rex: New variables, to be used in calculation of return array sizes. Populate return array descriptor if ret->data is NULL. Fix condition for early return (it used to test something undefined if order was used). Remove duplicate check wether pad is used. * intrinsics/reshape_generic.c (reshape_generic): Likewise. Fix a few places where the wrong variables were set. * generated/reshape_i4.c: Regenerated. * generated/reshape_i8.c: Regenerated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_reshape.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/reshape-alloc.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/reshape.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5383&r2=1.5384 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.198&r2=1.199 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i4.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i8.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/reshape_generic.c.diff?cvsroot=gcc&r1=1.7&r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/reshape.m4.diff?cvsroot=gcc&r1=1.7&r2=1.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20436
[Bug bootstrap/21162] Build failure
--- Additional Comments From jdavidb at goreadthebible dot com 2005-04-22 17:50 --- (In reply to comment #7) > > For that matter, if one cannot build the 64 bit compiler with the stock > > compiler > > on Debian sparc64-unknown-linux-gnu, how does one build this compiler? > > That's a Debian problem, the system compiler is probably the 32-bit biarch > compiler, in which case you have to configure with CC="gcc -m64" to bootstrap > the 64-bit compiler. Does that solve the problem? Well, for my purposes, I have chosen to solve the problem by building with the options as specified in Andrew's reply. I can probably run a test for you if you want, using the options you've mentioned. But shouldn't something in configure automatically detect "we're building the 64-bit compiler (by default because of platform), but the compiler we have is 32-bit, and that requires we tack on some additional options to build"? Basically, what I wanted is to stick a fresh "default" gcc 4.0 in /usr/local/gnu/gcc/4.0.0 . Whether it's 32 bit or 64 bit is immaterial to me. I see how Debian is causing the problem, though if they are using a 32 bit compiler on a 64 bit platform. But I would think gcc configure should work around that. I'll check with CC="gcc -m64" ./configure and report back what I get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug tree-optimization/21167] [4.0/4.1 Regression] ICE in get_indirect_ref_operands at tree-ssa-operands.c when compiling MySQL-4.1
-- What|Removed |Added CC||halcy0n at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21167
[Bug libfortran/20074] reshape of pointer array segfaults at runtime
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-22 20:02 --- Subject: Bug 20074 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-22 20:02:44 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/generated: reshape_i4.c reshape_i8.c libgfortran/intrinsics: reshape_generic.c libgfortran/m4 : reshape.m4 Added files: gcc/testsuite/gfortran.dg: nested_reshape.f90 reshape-alloc.f90 reshape.f90 Log message: 05-04-22 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * gfortran.dg/nested_reshape.f90: new test * gfortran.dg/reshape-alloc.f90: new test * gfortran.dg/reshape.f90: new test 2005-04-22 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * m4/reshape.m4 (reshape_`'rtype_kind): rs, rex: New variables, to be used in calculation of return array sizes. Populate return array descriptor if ret->data is NULL. Fix condition for early return (it used to test something undefined if order was used). Remove duplicate check wether pad is used. * intrinsics/reshape_generic.c (reshape_generic): Likewise. Fix a few places where the wrong variables were set. * generated/reshape_i4.c: Regenerated. * generated/reshape_i8.c: Regenerated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_reshape.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/reshape-alloc.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/reshape.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5383&r2=1.5384 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.198&r2=1.199 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i4.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i8.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/reshape_generic.c.diff?cvsroot=gcc&r1=1.7&r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/reshape.m4.diff?cvsroot=gcc&r1=1.7&r2=1.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20074
[Bug c++/20949] [4.0/4.1 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...
-- Bug 20949 depends on bug 20973, which changed state. Bug 20973 Summary: [4.0 Regression] kdelibs (khtml) miscompiled by reload http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
[Bug middle-end/20973] [4.0 Regression] kdelibs (khtml) miscompiled by reload
--- Additional Comments From schlie at comcast dot net 2005-04-22 18:01 --- (In reply to comment #15) > Subject: Bug 20973 > Branch: gcc-4_0-branch > Changes by: [EMAIL PROTECTED]2005-04-22 17:30:21 > Modified files: > gcc: ChangeLog reload.c Is 4.1 intended to have the same behavior as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
[Bug middle-end/20794] [4.0/4.1 Regression] Arrays and pointer arithmetic on __attribute ((aligned)) types permitted
--- Additional Comments From sje at cup dot hp dot com 2005-04-22 20:22 --- I submitted a patch, http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html, but as the mail says it results in a lot of regressions in the compat and vector tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug middle-end/20973] [4.0 Regression] kdelibs (khtml) miscompiled by reload
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-22 18:03 --- (In reply to comment #17) > Is 4.1 intended to have the same behavior as well? the mainline was fixed already except it did not show up here: http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg01085.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
[Bug middle-end/20973] [4.0 Regression] kdelibs (khtml) miscompiled by reload
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-22 17:58 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
[Bug tree-optimization/21088] VRP passes fold the type of operands of a comparison
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-23 02:02 --- Subject: Bug 21088 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-23 02:01:59 Modified files: gcc: ChangeLog fold-const.c tree-vrp.c tree.h Log message: PR tree-optimization/21088 * fold-const.c (fold_unary, fold_binary, fold_ternary): Export. * tree-vrp.c (compare_values): Use fold_binary to compare pointers. Use boolean_type_node as the type of a comparison expression being folded. * tree.h: Add prototypes for fold_unary, fold_binary, fold_ternary. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8412&r2=2.8413 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.567&r2=1.568 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.11&r2=2.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.718&r2=1.719 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21088
Re: G++ 3.4.3
Bruzzone Mirko wrote: /tmp//ccWSbEX3.s: Assembler messages: /tmp//ccWSbEX3.s:845: Error: Unrecognized opcode: `mfcr' You are probably using the wrong assembler, or an out of date assembler. Try reading the install instructions for this target at http://gcc.gnu.org/install/specific.html#x-ibm-aix It has a number of comments about assembler issues. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
[Bug tree-optimization/21088] VRP passes fold the type of operands of a comparison
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-23 02:03 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21088
[Bug fortran/20866] recursively defined statement function
-- What|Removed |Added Keywords||accepts-invalid Summary|error needed|recursively defined ||statement function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20866
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kargl at gcc dot gnu dot org 2005-04-22 22:34 --- This is a shorter version of the Fortran code. The bug is now critical to gfortran because almost all Fortran codes contain nested do loops. SUBROUTINE CHER2K(N, C, LDC) INTEGER I, J, N, LDC COMPLEX C(LDC,*) DO 20, J = 1, N DO 10, I = 1, J C(I,J) = (0.0E+0, 0.0E+0) 10CONTINUE 20 CONTINUE END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug fortran/20867] statement function args not given implicit type early enough
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2005-04-22 14:47:05 date|| Summary|error needed|statement function args not ||given implicit type early ||enough http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20867
[Bug fortran/20868] reference to upper bound of assumed-size array
-- What|Removed |Added Keywords||accepts-invalid Summary|error needed|reference to upper bound of ||assumed-size array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20868
[Bug fortran/20868] reference to upper bound of assumed-size array
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-22 14:47:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20868
[Bug fortran/20870] reference to size of assumed-size array
-- What|Removed |Added Keywords||accepts-invalid Summary|error needed|reference to size of ||assumed-size array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20870
[Bug tree-optimization/21167] [4.0/4.1 Regression] ICE in get_indirect_ref_operands at tree-ssa-operands.c when compiling MySQL-4.1
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |tree-optimization Keywords||ice-on-valid-code Summary|ICE in |[4.0/4.1 Regression] ICE in |get_indirect_ref_operands at|get_indirect_ref_operands at |tree-ssa-operands.c when|tree-ssa-operands.c when |compiling MySQL-4.1 |compiling MySQL-4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21167
[Bug target/21169] [4.0/4.1? regression] ICE in reload_cse_simplify_operands with -fnon-call-exceptions -fPIC -O2
-- What|Removed |Added Component|rtl-optimization|target Keywords||ice-on-valid-code, ssemmx Summary|[4.0 regression] ICE in |[4.0/4.1? regression] ICE in |reload_cse_simplify_operands|reload_cse_simplify_operands |with -fnon-call-exceptions -|with -fnon-call-exceptions - |fPIC -O2|fPIC -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21169
[Bug tree-optimization/21088] VRP passes fold the type of operands of a comparison
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21088
[Bug bootstrap/21162] Build failure
--- Additional Comments From jdavidb at goreadthebible dot com 2005-04-22 18:13 --- (In reply to comment #7) > > For that matter, if one cannot build the 64 bit compiler with the stock > > compiler > > on Debian sparc64-unknown-linux-gnu, how does one build this compiler? > > That's a Debian problem, the system compiler is probably the 32-bit biarch > compiler, in which case you have to configure with CC="gcc -m64" to bootstrap > the 64-bit compiler. Does that solve the problem? Still solving my problem as described earlier, but as a test I tried: ~/gcc-64-build$ CC="gcc -m64" ../gcc-4.0.0/configure --prefix=/usr/local/gnu/gcc/4.0.0 && make bootstrap-lean ... and the output ended with: checking for sparc64-unknown-linux-gnu-ar... no checking for ar... ar checking for sparc64-unknown-linux-gnu-ranlib... no checking for ranlib... ranlib checking for sparc64-unknown-linux-gnu-gcc... gcc -m64 checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make: *** [configure-build-libiberty] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug tree-optimization/21170] [4.1 Regression] Comments still mention rewrite_ssa_into_ssa.
-- What|Removed |Added Summary|Comments still mention |[4.1 Regression] Comments |rewrite_ssa_into_ssa. |still mention ||rewrite_ssa_into_ssa. Target Milestone|--- |4.1.0 Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21170
[Bug java/21164] New: libjava tests uses absolute paths
libjava tests uses absolute paths e.g. bytecompile /Volumes/SandBox/rt/src/gcc/libjava/testsuite/libjava.jni/noclass.java bytecompile /Volumes/SandBox/rt/src/gcc/libjava/testsuite/libjava.jni/overload.java bytecompile /Volumes/SandBox/rt/src/gcc/libjava/testsuite/libjava.jni/pr11951.java This is very inconvenient to compare tests agains known base results. -- Summary: libjava tests uses absolute paths Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dpatel at apple dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21164
[Bug bootstrap/21162] Build failure
--- Additional Comments From jdavidb at goreadthebible dot com 2005-04-22 18:15 --- (In reply to comment #9) > Yes, it should just "work". And it would have if you: > > 1) Make sure /lib64/libc.so.6 is installed. > 2) Delete the file /etc/disable_64_gcc > > Then gcc would output 64-bit code by default when the > "uname" command outputs "sparc64". You could then simply > run "sparc32 bash" to get an environment where uname outputs > plain "sparc" and this causes the Debian gcc to output 32-bit > code by default. > > We plan on adding similar logic to the compiler driver itself. > > I totally agree with you that when "uname" outputs "sparc64" > the compiler on the system should be outputting 64-bit code > by default which is what many (not just gcc's) configure > scripts and build trees expect. > > Since this problem has to do with Debian's gcc behavior and > not with a gcc proper bug per-se, I'm closing this as invalid. Thanks for the additional information. I'm in uncharted waters for me personally with the mixed 32/64 bit environment. Sounds like the preferred solution, at present, is to run $ sparc32 ../gcc-4.0.0/configure ... Someone might add a note to the docs along these lines: "If you are running Debian GNU/Linux for Sparc and you 'just want a compiler,' you will probably need to set up a 32-bit sparc environment when you run configure, as follows: $ sparc32 ../gcc-4.0.0/configure ..." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug c++/21163] New: internal compiler error: in output_constant_pool_2, at varasm.c:3135
gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0/configure --prefix=/usr/local/gcc-4.0.0 Thread model: posix gcc version 4.0.0 g++ --save-temps -mmmx -g -O2 test_mmx_diff2.cpp test_mmx_diff2.cpp: In function int simple_block_diff_mmx_4(short int** const&, short int** const&, int): test_mmx_diff2.cpp:42: internal compiler error: in output_constant_pool_2, at varasm.c:3135 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error: in output_constant_pool_2, at varasm.c:3135 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: asuraparaju at gmail dot com CC: asuraparaju at gmail dot com,gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu configured with: ../gcc- 4.0.0/configure --pref http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug bootstrap/21162] Build failure
--- Additional Comments From davem at gcc dot gnu dot org 2005-04-22 18:08 --- Yes, it should just "work". And it would have if you: 1) Make sure /lib64/libc.so.6 is installed. 2) Delete the file /etc/disable_64_gcc Then gcc would output 64-bit code by default when the "uname" command outputs "sparc64". You could then simply run "sparc32 bash" to get an environment where uname outputs plain "sparc" and this causes the Debian gcc to output 32-bit code by default. We plan on adding similar logic to the compiler driver itself. I totally agree with you that when "uname" outputs "sparc64" the compiler on the system should be outputting 64-bit code by default which is what many (not just gcc's) configure scripts and build trees expect. Since this problem has to do with Debian's gcc behavior and not with a gcc proper bug per-se, I'm closing this as invalid. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug target/21169] [4.0/4.1? regression] ICE in reload_cse_simplify_operands with -fnon-call-exceptions -fPIC -O2
-- What|Removed |Added CC||rth at gcc dot gnu dot org Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21169
[Bug c++/21163] internal compiler error: in output_constant_pool_2, at varasm.c:3135
--- Additional Comments From asuraparaju at gmail dot com 2005-04-22 15:28 --- Created an attachment (id=8710) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8710&action=view) g++ --save-temps -mmmx -g -O2 test_mmx_diff2.cpp g++ --save-temps -mmmx -g -O2 test_mmx_diff2.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
Re: Gcc 3.4.3
Bruzzone Mirko wrote: ld: 0711-252 SEVERE ERROR: File auxiliary symbol entry 1 in object /home/mirko/nfs/sp7/SpBLDAIX7-SV/obj/spts/sptsquit.o : Field x_offset contains 4. Valid values are between 4 and -1. That looks like a problem with the IBM assembler/linker that we probably can't do anything about. However, you might want to look at the install info for this target, e.g. http://gcc.gnu.org/install/specific.html#x-ibm-aix This has some comments about assembler and linker issues. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
[Bug bootstrap/21162] Build failure
--- Additional Comments From davem at gcc dot gnu dot org 2005-04-22 18:21 --- Right, it can't compile a test program with "-m64" because the /lib64/libc.so.6 package is not installed. Also, when you use "sparc32" you should use it to create a complete execution environment with "sparc32 bash" or whatever shell you use. You need to be in that environment when you invoke the make, not just when you run the configure scripts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug bootstrap/21162] Build failure
--- Additional Comments From jdavidb at goreadthebible dot com 2005-04-22 18:25 --- (In reply to comment #12) > Right, it can't compile a test program with "-m64" because the > /lib64/libc.so.6 package is not installed. Strangely, I do seem to have that file installed. But I also have the /etc/disable_64_gcc file you mentioned earlier. > Also, when you use "sparc32" you should use it to create a > complete execution environment with "sparc32 bash" or whatever > shell you use. You need to be in that environment when you > invoke the make, not just when you run the configure scripts. Oh, yes. I'm used to running it all on one command line with && or ; but that wouldn't work because the sparc32 would only apply to the first command. Thanks for pointing that out. Trying to figure out if I should cancel my other build that is running at the moment, where I specified the host/target manually. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug bootstrap/21162] Build failure
--- Additional Comments From davem at gcc dot gnu dot org 2005-04-22 18:27 --- You may with to restart your build with the correct environment setup, just to be safe. Depending upon what you've enabled it can take a long time :-) Yes, the /etc/disable_64_gcc file is what prevents gcc from outputting 64-bit code by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
--- Additional Comments From law at redhat dot com 2005-04-22 18:30 --- The reload bug has been "resolved" or at least it's in a state where we can move forward with the jump threading changes. I've finally got the dynamic branching data which shows pretty much what I expected -- we execute fewer jumps :-) What I've done is used GCC's arc-profiling and branch prediction support to give us a picture of the runtime branching behavior of a set of programs (SPECINT2000). Specifically we're looking at how many conditional branches were executed (regardless of whether or not they were taken or not taken). We measure this with and without the jump threading changes. This gives us a highly accurate measure of how effective the jump threading changes are at reduncing the number of branches a program executes at runtime (it does not measure the secondary effects like exposing new expression redundancies). For SPECINT2000 we see a reduction in conditional branches of 4%. Yes, the threading changes manage to eliminate 4 out of every 100 branches executed at runtime across a fairly large benchmark suite. One benchmark (gzip) saw an incredible 21% reduction in runtime branches executed, though sadly gzip doesn't show a measurable runtime improvement (most likely because there were few, if any secondary optimization opportunities exposed by jump threading and/or the branches it eliminated were easily predicted by the hardware and thus weren't causing considerable branch mis-prediction penalties). These changes are also now showing a net improvement in compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
[Bug tree-optimization/21170] New: Comments still mention rewrite_ssa_into_ssa.
tree-ssa-dom.c: rewrite_ssa_into_ssa. tree-ssa-threadupdate.c: SSA_NAMEs. Right now, we just call into rewrite_ssa_into_ssa Note that rewrite_ssa_into_ssa was just removed today. -- Summary: Comments still mention rewrite_ssa_into_ssa. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: dnovillo at redhat dot com ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21170
[Bug c/21160] how to force a variable into the stack?
--- Additional Comments From joseph at codesourcery dot com 2005-04-22 15:51 --- Subject: Re: how to force a variable into the stack? On Fri, 22 Apr 2005, pinskia at gcc dot gnu dot org wrote: > No you have not taken the address, as it will not escape or otherwise. > volatile in a local function is the > same as almost as a non register. > Another way to "fix" this would be do the following: > escape_function(&a); > and mark escape_function as no inline, but this might not work in the furture > as we might know that > escape_function does not escape that address, the way to work around that > would be make a static file > scope variable which gets assigned that pointer but even that might cause the > escapeness in the future > so the only correct way is mark the variable as volatile. > > -- >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID You appear not to have noticed that the bug reporter pointed out an inconsistency between GCC's documentation and its behavior. Such an inconsistency is always a bug - in this case, a bug in the documentation - and you should not close a bug report concerning such an inconsistency until it has been fixed. The problem passage is that describing "candidates for register allocation", since GCC can now allocate variables, and parts of structure variables, to different registers and stack locations at different times. The other documentation concerning longjmp, in interface.texi and in trouble.texi, is quite correct: following the ISO C standard, the value of a non-volatile automatic variable changed between setjmp and longjmp is undefined and the only way to avoid this undefined behavior is to use "volatile". Even if the address escapes, the behavior is still undefined, although making the address escape might serve to avoid the warning (in cases where you know the variable in fact can't change between setjmp and longjmp) until there is fine-grained warning control, which we hope to have in GCC 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
[Bug bootstrap/21162] Build failure
--- Additional Comments From jdavidb at goreadthebible dot com 2005-04-22 16:00 --- Thank you, but doesn't this still represent a problem? Shouldn't config.guess figure out what kind of compiler to build for my platform without my having to tell it? I checked and there's nothing in the installation instructions about it. Perhaps a note could be added to the effect that some (or all?) sparc64-unknown-linux-gnu users will need to specify the target, host, and build systems themselves? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug target/21163] [4.0 Regregresion] internal compiler error: in output_constant_pool_2, at varasm.c:3135
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-22 16:01 --- This works on the mainline. -- What|Removed |Added Known to work||4.1.0 Summary|internal compiler error: in |[4.0 Regregresion] internal |output_constant_pool_2, at |compiler error: in |varasm.c:3135 |output_constant_pool_2, at ||varasm.c:3135 Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug tree-optimization/15352] [tree-ssa] missed jump threading opportunity due to lack of short circuit
--- Additional Comments From law at redhat dot com 2005-04-23 00:55 --- Should be fixed with today's checkin -- with the caveat that Kazu's desired code is incorrect. We thread everything fully in this code now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15352
[Bug c++/21087] [4.0/4.1 Regression] ICE in do_nonmember_using_decl
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-22 16:57 --- Subject: Bug 21087 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-22 16:57:24 Modified files: gcc/cp : ChangeLog name-lookup.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: builtin2.C Log message: gcc/cp/ChangeLog: PR c++/21087 * name-lookup.c (push_overloaded_decl): Do not overload with non-duplicate anticipated built-in. gcc/testsuite/ChangeLog: PR c++/21087 * g++.dg/lookup/builtin2.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4716&r2=1.4717 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.114&r2=1.115 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5381&r2=1.5382 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/builtin2.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kargl at gcc dot gnu dot org 2005-04-22 23:03 --- Kazu, I just tried the patch, pr21030-vrp-ice.patch. It seems to fix the problems with gfortran and -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/16538] Missed jump threading opportunity with struct fields (but RTL thread_jumps does catch it)
--- Additional Comments From law at redhat dot com 2005-04-23 00:57 --- This appears to be fixed now (probably the combination of Dan's aliasing work and the jump threading changes). Can a bugmaster please close this :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16538
[Bug tree-optimization/15221] a jump threading opportunity blocked by a few intervening instructions
--- Additional Comments From law at redhat dot com 2005-04-23 00:52 --- Sould be fixed with today's checkin (with caveats mentioned earlier regarding the invalidity of the statement that the two tests should compile into the same code). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15221
[Bug c/21167] New: internal compiler error in get_indirect_ref_operands at tree-ssa-operands.c when compiling MySQL
Hi, When trying to compile MySQL 4.1, it fails with the following error : default.c: In function 'search_default_file_with_ext': default.c:346: internal compiler error: in get_indirect_ref_operands, at tree-ssa-operands.c:1449 Please submit a full bug report, with preprocessed source if appropriate. Download gcc-bug.tar.gz, and execute : if /home/joce/bin/gcc -DDEFAULT_BASEDIR=\"/usr/local/mysql\" -DDATADIR="\"/usr/local/mysql/var\"" -DDEFAULT_CHARSET_HOME="\"/usr/local/mysql\"" -DSHAREDIR="\"/usr/local/mysql/share/mysql\"" -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I.-O3 -DDBUG_OFF -Wimplicit -Wreturn-type -Wswitch -Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare -Wwrite-strings -Wunused -mtune=athlon-mp -march=athlon-mp -mfpmath=sse -mmmx -msse -m3dnow -O3 -fno-omit-frame-pointer -MT default.o -MD -MP -MF ".deps/default.Tpo" -c -o default.o default.c; \ then mv -f ".deps/default.Tpo" ".deps/default.Po"; else rm -f ".deps/default.Tpo"; fi in the mysys directory Thanks and regards, Jocelyn -- Summary: internal compiler error in get_indirect_ref_operands at tree-ssa-operands.c when compiling MySQL Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P1 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joc at presence-pc dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21167
[Bug fortran/20872] error needed
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-22 14:51 --- "... shall not be a generic name (unless it is also a specific name)" -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-22 14:51:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20872
[Bug fortran/20871] error needed
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-22 14:50 --- "A non-intrinsic elemental procedure shall not be used as dummy argument" -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-22 14:50:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20871
[Bug tree-optimization/18076] Missed jump threading optimization
--- Additional Comments From law at redhat dot com 2005-04-23 01:01 --- The threading part of this has been fixed Now we just need to fix DSE to finish cleaning things up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18076
[Bug target/21163] internal compiler error: in output_constant_pool_2, at varasm.c:3135
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-22 15:58 --- Even though the ICE has nothing to do with the following but you are violating C aliasing rules with the following: __m64 pic = *(__m64 *)&pic_data[j][i]; __m64 ref = *(__m64 *)&ref_data[j][i]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug tree-optimization/19516] missed optimization (bool)
--- Additional Comments From law at redhat dot com 2005-04-23 01:10 --- We're performing the requested optimization now. This should probably be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19516
[Bug c/21171] New: Generates wrong code (w/ optimization) when copying data from a table to a table in a structure
Compiling the test code with optimizations enabled generates invalid code. Data
gets read from the source table but gets not written to the destination.
Test code:
/* start of test.c */
/* compile: arm-elf-gcc -Os -c -o test.o test.c */
/*dump: arm-elf-objdump -D test.o | more*/
typedef unsigned int u_int32_t;
typedef unsigned char u_int8_t;
#define AIC_VECTORS 32
typedef volatile struct AT91RM9200_AIC {
u_int32_t SVR[AIC_VECTORS];
} AT91RM9200_AIC_t;
typedef volatile struct AT91RM9200_regs {
AT91RM9200_AIC_t AIC;
} AT91RM9200_regs_t;
#define CPUReg ((AT91RM9200_regs_t*)0xFFF0)
extern const u_int32_t __IntTable[AIC_VECTORS];
int main()
{
int c;
AT91RM9200_AIC_t *aic = &CPUReg->AIC;
for (c=0; c < AIC_VECTORS; c++) {
aic->SVR[c] = __IntTable[c];
}
return 0;
}
/* end of test.c */
objdump output:
test.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e59f2014ldr r2, [pc, #20] ; 1c <.text+0x1c>
4: e59f3014ldr r3, [pc, #20] ; 20 <.text+0x20>
8: e2822004add r2, r2, #4 ; 0x4
c: e1520003cmp r2, r3
10: 1affbne 4
14: e3a0mov r0, #0 ; 0x0
18: e12fff1ebx lr
As you can see, there is no store (str) instruction at all. Code just goes
through the __IntTable[] but does nothing useful.
--
Summary: Generates wrong code (w/ optimization) when copying data
from a table to a table in a structure
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sami dot kantoluoto at embedtronics dot fi
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-netbsdelf2.0
GCC host triplet: i386-unknown-netbsdelf2.0
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21171
[Bug c++/21165] New: bogus error on a user-defined conversion in a template
The test case below demonstrates two problems:
1) the line number in the error message points to an expression that involves
only two ints (i.e., no object of T::BI as the message claims).
2) the program is well formed and the error is a regression from previous
versions of the compiler.
$ cat t.cpp && gcc -c t.cpp
/* 1 */ struct A
/* 2 */ {
/* 3 */ A (int = 0);
/* 4 */ operator int () const;
/* 5 */ };
/* 6 */
/* 7 */ struct B
/* 8 */ {
/* 9 */ typedef int BI;
/* 10 */ typedef A BA;
/* 11 */
/* 12 */ };
/* 13 */
/* 14 */ template
/* 15 */ struct C
/* 16 */ {
/* 17 */ typedef typename T::BA BA;
/* 18 */ typedef typename T::BI BI;
/* 19 */
/* 20 */ BA foo (BA ba) {
/* 21 */ const int i = BI (ba);
/* 22 */
/* 23 */ if (i < 0)
/* 24 */ return A ();
/* 25 */
/* 26 */ return A ();
/* 27 */ }
/* 28 */ };
/* 29 */
/* 30 */ template struct C;
t.cpp: In member function 'typename T::BA C< ,
T>::foo(typename T::BA)':
t.cpp:23: error: 'typename T::BI' used where a 'int' was expected
--
Summary: bogus error on a user-defined conversion in a template
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21165
[Bug libgcj/21164] libjava tests uses absolute paths
-- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21164
[Bug bootstrap/21162] Build failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-22 15:55 --- /usr/bin/ld: warning: sparc architecture of input file `../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible with sparc:v9 output This means that you are building a sparc 64 bit but have building orginaly with a sparc 32bit compiler. So this is invalid. Read the installation instructions, I think there might be something there about this. If there is not, here is how to do this: configure --target=sparc-linux-gnu --host=sparc-linux-gnu --build=sparc-linux-gnu otherconfigoptions && make bootstrap && make -k check && make install -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug SWING/16522] Implementation of JComboBox
--- Additional Comments From fitzsim at redhat dot com 2005-04-22 14:51 --- Done. Closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16522
[Bug c/21171] Generates wrong code (w/ optimization) when copying data from a table to a table in a structure
--- Additional Comments From sami dot kantoluoto at embedtronics dot fi 2005-04-23 08:31 --- Created an attachment (id=8713) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8713&action=view) A bit more simplified test file with a test code that gets compiled correctly commented out. Code that gets compiled _corretly_: *(&CPUReg->SVR[c]) = __IntTable[c]; And code that doesn't: CPUReg->SVR[c] = __IntTable[c]; Objdump of working code: test.o: file format elf32-littlearm Disassembly of section .text: : 0: e59f101cldr r1, [pc, #28] ; 24 <.text+0x24> 4: e59f001cldr r0, [pc, #28] ; 28 <.text+0x28> 8: e4912004ldr r2, [r1], #4 c: e59f3018ldr r3, [pc, #24] ; 2c <.text+0x2c> 10: e1510003cmp r1, r3 14: e4802004str r2, [r0], #4 18: 1a00bne 8 1c: e3a0mov r0, #0 ; 0x0 20: e12fff1ebx lr (this could be optimized by not reloading the r3 every loop). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21171
[Bug c++/21166] New: g++ gives error on reference to packed structure elements
In the code below, the g++ is being overly picky about taking a reference to a
packed char. Chars can have any alignment so the error is incorrect. note
that the same code using pointers doesn't produce a similar error:
=
struct s1 {
charc1;
} __attribute__((packed));
char&
f(struct s1 *s)
{
return s->c1;
}
char *
g(struct s1 *s)
{
return &s->c1;
}
--
Summary: g++ gives error on reference to packed structure
elements
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21166
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From eisvogel at seitics dot de 2005-04-22 16:10
---
This bug is AFAICT not fully resolved in 4.0 HEAD as of today. The test case
compiles under 3.4.3, though. The code snippet used to be part of an MD5
transform function but I have stripped it down to the point where it is still
valid C code but does not do anything useful any more. In this state removing
any of the remaining lines usually prevents the ICE from occurring, most notably
the LPM macro (taken from avr-libc HEAD).
$ avr-gcc -Os -mmcu=atmega162 -c test.c
test.c: In function 'test':
test.c:46: error: unable to find a register to spill in class 'POINTER_REGS'
test.c:46: error: this is the insn:
(insn 18 115 20 0 (set (reg/v:SI 56 [ a ])
(mem:SI (post_inc:HI (reg/f:HI 22 r22 [orig:59 D.1226 ] [59])) [2 S4
A8])) 14 {*movsi} (insn_list:REG_DEP_TRUE 115 (nil))
(expr_list:REG_INC (reg/f:HI 22 r22 [orig:59 D.1226 ] [59])
(nil)))
test.c:46: internal compiler error: in spill_failure, at reload1.c:1897
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Compiler version:
$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../configure --target=avr --prefix=/home/eisvogel/avr
--enable-languages=c,c++ --disable-nls
Thread model: single
gcc version 4.1.0 20050422 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug c/21160] [4.0/4.1 Regression] documentation for -Wuninitialized out of date
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-22 16:11
---
The bug is that the paragraph
These warnings occur only for variables that are candidates for
register allocation. Therefore, they do not occur for a variable that
is declared @code{volatile}, or whose address is taken, or whose size
is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
structures, unions or arrays, even when they are in registers.
is out of date because of tree-ssa changes.
--
What|Removed |Added
Severity|normal |minor
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
Summary|how to force a variable into|[4.0/4.1 Regression]
|the stack? |documentation for -
||Wuninitialized out of date
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
Re: gcc-4.0.0: bootstrap error on ia64-linux
Daniel Heiserer wrote: ../../../gcc-4.0.0/libffi/src/ia64/unix.S:104: Error: Unknown pseudo function [EMAIL PROTECTED]' You need a newer assembler. The assembler has supported ltoffx since December 2002, and this has been in binutils releases since binutils-2.14. binutils-2.16 will be coming out shortly, or you could try a recent H.J. special binutils release. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
[Bug c/21171] Generates wrong code (w/ optimization) when copying data from a table to a table in a structure
--- Additional Comments From sami dot kantoluoto at embedtronics dot fi
2005-04-23 08:45 ---
Created an attachment (id=8714)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8714&action=view)
objdump output of working version when compiled in thumb mode (-mthumb)
Same problems in thumb mode. Attachment shows the objdump output of the
_working_ version. Objdump output of non-working version is here:
test.o: file format elf32-littlearm
Disassembly of section .text:
:
0: 4b03ldr r3, [pc, #12] (10 <.text+0x10>)
2: 1c1amov r2, r3 (add r2, r3, #0)
4: 3280add r2, #128
6: 3304add r3, #4
8: 4293cmp r3, r2
a: d1fcbne 6
c: 2000mov r0, #0
e: 4770bx lr
10: lsl r0, r0, #0
...
Disassembly of section .comment:
<.comment>:
0: 43434700cmpmi r3, #0 ; 0x0
4: 4728203aundefined
8: 2029554eeorcs r5, r9, lr, asr #10
c: 2e302e34mrccs 14, 1, r2, cr0, cr4, {1}
As you can see, it does not even access the source table (non-thumb version
does).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21171
[Bug bootstrap/21168] bootstrap failed on Linux/ia64
--- Additional Comments From nathan at codesourcery dot com 2005-04-23 08:47 --- Subject: Re: New: bootstrap failed on Linux/ia64 hjl at lucon dot org wrote: > This patch > > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02301.html > > caused > > /net/gnu-9/export/gnu/src/gcc-next/gcc/gcc/config/ia64/crtfastmath.c: In > function \u\u\u__ia64_set_fast_math > /net/gnu-9/export/gnu/src/gcc-next/gcc/gcc/config/ia64/crtfastmath.c:37: > internal compiler error: in schedule_block, at haifa-sched.c:2111 oops. de morgan snafu. I must have been confused by the original form which used inconsistent != notation :) It used to be ! if (current_sched_info->queue_must_finish_empty && q_size != 0) ! abort (); and this patch correctly implements that as ! gcc_assert (!current_sched_info->queue_must_finish_empty || !q_size); Fixed with the attached patch, committed as obvious nathan 2005-04-23 Nathan Sidwell <[EMAIL PROTECTED]> * haifa-sched.c (schedule_block): Fix thinko in previous assertification patch. Index: haifa-sched.c === RCS file: /cvs/gcc/gcc/gcc/haifa-sched.c,v retrieving revision 1.254 diff -c -3 -p -r1.254 haifa-sched.c *** haifa-sched.c 22 Apr 2005 16:14:55 - 1.254 --- haifa-sched.c 23 Apr 2005 08:43:31 - *** schedule_block (int b, int rgn_n_insns) *** 2108,2114 /* Sanity check -- queue must be empty now. Meaningless if region has multiple bbs. */ ! gcc_assert (!current_sched_info->queue_must_finish_empty || q_size); /* Update head/tail boundaries. */ head = NEXT_INSN (prev_head); --- 2108,2114 /* Sanity check -- queue must be empty now. Meaningless if region has multiple bbs. */ ! gcc_assert (!current_sched_info->queue_must_finish_empty || !q_size); /* Update head/tail boundaries. */ head = NEXT_INSN (prev_head); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21168
[Bug bootstrap/21168] bootstrap failed on Linux/ia64
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-23 08:48:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21168
[Bug bootstrap/21168] bootstrap failed on Linux/ia64
--- Additional Comments From nathan at gcc dot gnu dot org 2005-04-23 08:48 --- 2005-04-23 Nathan Sidwell <[EMAIL PROTECTED]> * haifa-sched.c (schedule_block): Fix thinko in previous assertification patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21168
[Bug bootstrap/21162] Build failure
--- Additional Comments From jdavidb at goreadthebible dot com 2005-04-22 17:02 --- For that matter, if one cannot build the 64 bit compiler with the stock compiler on Debian sparc64-unknown-linux-gnu, how does one build this compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug target/21163] internal compiler error: in output_constant_pool_2, at varasm.c:3135
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-22 15:53 --- configured with: ../gcc-4.0.0/configure --pref -- What|Removed |Added Severity|critical|normal Component|c++ |target GCC target triplet|i686-pc-linux-gnu configured|i686-pc-linux-gnu |with: ../gcc-4.0.0/configure| |--pref | Keywords||ice-on-valid-code, ssemmx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug fortran/20877] result may not be entry
-- What|Removed |Added Keywords||accepts-invalid Summary|error needed|result may not be entry http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20877
[Bug libstdc++/21172] New: potential integer overflow error in STL heap functions
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_heap.h?rev=1.16&content-type=text/x-cvsweb-markup Any function that relies on the __adjust_heap functions have a potential integer overflow error in their calculation of __secondChild. -- Summary: potential integer overflow error in STL heap functions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pete_a90 at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug fortran/20878] error needed
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-22 14:59 --- "an interface body doesn't access the named entities by host association but it may access entities by use association" -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-22 14:59:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20878
[Bug AWT/20720] crash when pressing laptop arrow keys
-- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-22 14:56:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20720
[Bug c/21173] New: miscompiled pointer subtraction broke Linux kernel
/* gcc4pointersubtractionbug.c
* Written by Mikael Pettersson, [EMAIL PROTECTED], 2005-04-23.
*
* This program illustrates a code optimisation bug in
* gcc-4.0.0 (final) and gcc-4.0.0-20050417, where a pointer
* subtraction operation is compiled as a pointer addition.
* Observed at -O2. gcc was configured for i686-pc-linux-gnu.
*
* This bug broke net/ipv4/devinet.c:devinet_sysctl_register()
* in the linux-2.6.12-rc2 Linux kernel, causing /sbin/sysctl
* to trigger kernel oopses.
*
* gcc-4.0.0-20050416 and earlier prereleases do not have this bug.
*/
#include
#include
#define NRVARS 5
struct ipv4_devconf {
int var[NRVARS];
};
struct ipv4_devconf ipv4_devconf[2];
struct ctl_table {
void *data;
};
struct devinet_sysctl_table {
struct ctl_table devinet_vars[NRVARS];
};
void devinet_sysctl_relocate(struct devinet_sysctl_table *t,
struct ipv4_devconf *p)
{
int i;
for (i = 0; i < NRVARS; i++)
/* Initially data points to a field in ipv4_devconf[0].
This code relocates it to the corresponding field in *p.
At -O2, gcc-4.0.0-20050417 and gcc-4.0.0 (final)
miscompile this pointer subtraction as a pointer addition. */
t->devinet_vars[i].data += (char *)p - (char *)&ipv4_devconf[0];
}
struct devinet_sysctl_table devinet_sysctl;
int main(void)
{
struct devinet_sysctl_table t;
int i;
for(i = 0; i < NRVARS; i++)
devinet_sysctl.devinet_vars[i].data = &ipv4_devconf[0].var[i];
memcpy(&t, &devinet_sysctl, sizeof t);
devinet_sysctl_relocate(&t, &ipv4_devconf[1]);
for(i = 0; i < NRVARS; i++)
if (t.devinet_vars[i].data != &ipv4_devconf[1].var[i]) {
fprintf(stderr, "t.devinet_vars[%u].data == %p, should be %p\n",
i,
t.devinet_vars[i].data,
&ipv4_devconf[1].var[i]);
return 1;
}
printf("all ok\n");
return 0;
}
--
Summary: miscompiled pointer subtraction broke Linux kernel
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at csd dot uu dot se
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug tree-optimization/21167] [4.0/4.1 Regression] ICE in get_indirect_ref_operands at tree-ssa-operands.c when compiling MySQL-4.1
-- What|Removed |Added CC||palowoda at fiver dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21167
[Bug c++/21174] New: name lookup differs between namespace-scope and global scope
$ cat >bug.cxx
namespace N1
{
struct S {};
}
namespace N2
{
struct S {};
}
namespace N3
{
using namespace N1;
using namespace N2;
using N1::S;
S
f ();
}
using namespace N1;
using namespace N2;
using N1::S;
S
f ();
$ g++-3.4 --version
g++-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
$ g++-3.4 -c bug.cxx
bug.cxx:27: error: `S' does not name a type
--
Summary: name lookup differs between namespace-scope and global
scope
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boris at kolpackov dot net
CC: gcc-bugs at gcc dot gnu 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=21174
[Bug c++/2922] [DR 197] two-stage lookup for unqualified function calls with type-dependent arguments
--- Additional Comments From maxim dot yegorushkin at gmail dot com
2005-04-23 10:55 ---
(In reply to comment #10)
> Not working on this anymore. Andrew closed PR 11296 as a dup of this,
but I'm
> not 100% sure. This is the testcase, so that it can be tested and added to
the
> testsuite:
>
> -
> namespace N {
> template T foo (T) { return T (); }
> template T bar (T t) { return foo (t); }
> }
>
> struct S { S (int i = 0): i_ (i) { } int i_; };
>
> namespace N {
> /* template <> */ S foo (S) { return S (1); }
> }
>
> int main ()
> {
> return 1 == N::bar (S ()).i_;
> }
> -
> (should return 0, but returns 1).
>
Here is another test case that does compile time two-phase name check.
Comeau online 4.3.3 BETA August 4, 2003 passes it, gcc 3.4.3 fails. For
discussion please see http://groups-beta.google.com/group/comp.lang.c++.
moderated/msg/c7227abb97603d15?hl=en
namespace tpl_ {
template
char test(T);
template
struct check
{
static T const t;
enum { value = 1 == sizeof(test(t)) };
};
double test(int);
}
bool const two_phase_lookup_supported = tpl_::check::value;
int compile_time_assert[two_phase_lookup_supported ? 1 : -1];
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2922
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-04-23 10:58 --- (In reply to comment #10) > Kazu, I just tried the patch, pr21030-vrp-ice.patch. > It seems to fix the problems with gfortran and -O2. Kazu, could you propose your patch on gcc-patches or ping it ? Without this patch I won't be able to do any testing for my GCC Summit paper (deadline 1st of May). Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug c/21175] New: miscompiled pointer subtraction broke Linux kernel
/* gcc4pointersubtractionbug.c
* Written by Mikael Pettersson, [EMAIL PROTECTED], 2005-04-23.
*
* This program illustrates a code optimisation bug in
* gcc-4.0.0 (final) and gcc-4.0.0-20050417, where a pointer
* subtraction operation is compiled as a pointer addition.
* Observed at -O2. gcc was configured for i686-pc-linux-gnu.
*
* This bug broke net/ipv4/devinet.c:devinet_sysctl_register()
* in the linux-2.6.12-rc2 Linux kernel, causing /sbin/sysctl
* to trigger kernel oopses.
*
* gcc-4.0.0-20050416 and earlier prereleases do not have this bug.
*/
#include
#include
#define NRVARS 5
struct ipv4_devconf {
int var[NRVARS];
};
struct ipv4_devconf ipv4_devconf[2];
struct ctl_table {
void *data;
};
struct devinet_sysctl_table {
struct ctl_table devinet_vars[NRVARS];
};
void devinet_sysctl_relocate(struct devinet_sysctl_table *t,
struct ipv4_devconf *p)
{
int i;
for (i = 0; i < NRVARS; i++)
/* Initially data points to a field in ipv4_devconf[0].
This code relocates it to the corresponding field in *p.
At -O2, gcc-4.0.0-20050417 and gcc-4.0.0 (final)
miscompile this pointer subtraction as a pointer addition. */
t->devinet_vars[i].data += (char *)p - (char *)&ipv4_devconf[0];
}
struct devinet_sysctl_table devinet_sysctl;
int main(void)
{
struct devinet_sysctl_table t;
int i;
for(i = 0; i < NRVARS; i++)
devinet_sysctl.devinet_vars[i].data = &ipv4_devconf[0].var[i];
memcpy(&t, &devinet_sysctl, sizeof t);
devinet_sysctl_relocate(&t, &ipv4_devconf[1]);
for(i = 0; i < NRVARS; i++)
if (t.devinet_vars[i].data != &ipv4_devconf[1].var[i]) {
fprintf(stderr, "t.devinet_vars[%u].data == %p, should be %p\n",
i,
t.devinet_vars[i].data,
&ipv4_devconf[1].var[i]);
return 1;
}
printf("all ok\n");
return 0;
}
--
Summary: miscompiled pointer subtraction broke Linux kernel
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at csd dot uu dot se
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21175
[Bug bootstrap/21176] New: Cannot make on Solaris 9 (Intel)
On Solaris 9 (Intel), make gives us make[1]: Entering directory `/hoge/gcc-4.0.0/build-i386-pc-solaris2.9/libiberty' make[1]: *** No rule to make target `../include/ansidecl.h' needed by `regex.o' . Stop. make[1]: Leaving directory `/hoge/gcc-4.0.0/build-i386-pc-solaris2.9/libiberty' make: *** [all-build-libiberty] Error 2 -- Summary: Cannot make on Solaris 9 (Intel) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: shanwill44 at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21176
[Bug c/21175] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-23 11:56 --- *** This bug has been marked as a duplicate of 21173 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21175
[Bug c/21173] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-23 11:56 --- *** Bug 21175 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug c/21173] miscompiled pointer subtraction broke Linux kernel
-- What|Removed |Added CC||azarah at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug tree-optimization/21173] [4.0 regression] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-23 12:30 ---
// Confirmed on amd64 too, smaller testcase (compile with -O2):
void abort (void);
char q;
void *a[2];
void foo (char *p)
{
int i;
for (i = 0; i < 2; i++)
a[i] += p - &q;
}
int main (void)
{
int i;
foo (&q);
for (i = 0; i < 2; i ++)
if (a[i])
abort ();
return 0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed||1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i686-pc-linux-gnu |
Keywords||wrong-code
Known to fail||4.0.0
Known to work||3.4.4
Priority|P2 |P1
Last reconfirmed|-00-00 00:00:00 |2005-04-23 12:30:26
date||
Summary|miscompiled pointer |[4.0 regression] miscompiled
|subtraction broke Linux |pointer subtraction broke
|kernel |Linux kernel
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-23 12:51 --- -O1 -ftree-pre causing this. -- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Known to fail|4.0.0 |4.0.0 4.1.0 Summary|[4.0 regression] miscompiled|[4.0/4.1 regression] |pointer subtraction broke |miscompiled pointer |Linux kernel|subtraction broke Linux ||kernel http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-23 13:18 --- (In reply to comment #5) > A comment in the patch says "Tested on i686-pc-linux-gnu", but > it just means that it will have been tested by the time I post this patch. :-) > Patch looks fine. OK to install if it passes the usual testing. It's odd that I don't seem to have received this patch. Did you ever post it? Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-23 13:18 --- Hmm, is -&a legal gimple, if it is then it is a PRE bug, otherwise it is a bug in the gimplifier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-23
13:24 ---
.crited dump:
foo (p)
{
int i;
void * D.1576;
char * D.1575;
void * D.1574;
void * D.1573;
int i.0;
:
# i_16 = PHI ;
:;
D.1573_7 = a[i_16];
D.1574_9 = D.1573_7 + p_8;
D.1575_10 = -&q;
D.1576_11 = D.1574_9 + D.1575_10;
a[i_16] = D.1576_11;
i_13 = i_16 + 1;
if (i_13 <= 1) goto ; else goto ;
:;
goto ();
:;
return;
}
.pre dump:
foo (p)
{
int pretmp.3;
char * pretmp.2;
int i;
void * D.1576;
char * D.1575;
void * D.1574;
void * D.1573;
int i.0;
:
pretmp.2_6 = &q;
# i_16 = PHI ;
:;
D.1573_7 = a[i_16];
D.1574_9 = D.1573_7 + p_8;
D.1575_10 = pretmp.2_6;
D.1576_11 = D.1574_9 + D.1575_10;
a[i_16] = D.1576_11;
i_13 = i_16 + 1;
if (i_13 <= 1) goto ; else goto ;
:;
goto ();
:;
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug target/21171] Generates wrong code (w/ optimization) when copying data from a table to a table in a structure
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21171
[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-23 13:36 --- This could be the same bug as the one reported on the mailing list here: http://gcc.gnu.org/ml/gcc/2005-04/msg01260.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug fortran/20861] error needed
--- Additional Comments From jv244 at cam dot ac dot uk 2005-04-23 13:36 --- (In reply to comment #1) > Any pointers as to why this is invalid? 12.4.1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20861
[Bug tree-optimization/21167] [4.0/4.1 Regression] ICE in get_indirect_ref_operands at tree-ssa-operands.c when compiling MySQL-4.1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-23 13:36 --- Can someone attach the preprocessed source as directed by the bug filing directions? -- What|Removed |Added Status|UNCONFIRMED |WAITING Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21167
