[Bug c++/46807] [4.6 Regression] internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 --- Comment #16 from rwgk at yahoo dot com 2011-02-16 05:08:05 UTC --- Thank you very much! The original problem is solved, too.
[Bug c++/46807] internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 --- Comment #6 from rwgk at yahoo dot com 2011-01-07 18:29:59 UTC --- Created attachment 22928 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22928 pre-processor output of original reproducer Created with (Fedora 14 64-bit): g++ -E gcc_bugs/pr46807_gcc46_ice.cpp This command still produces the original ICE with gcc svn trunk rev. 168562: g++ -E ~/gcc_bugs/pr46807_gcc46_ice.cpp
[Bug c++/46807] internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 --- Comment #7 from rwgk at yahoo dot com 2011-01-07 18:32:12 UTC --- This command still produces the original ICE with gcc svn trunk rev. 168562: Sorry, cut and paste error. The last command should have been g++ -O3 pr46807_gcc46_ice_pre_processed.cpp
[Bug c++/46807] internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 --- Comment #4 from rwgk at yahoo dot com 2011-01-07 04:28:46 UTC --- I just saw the GCC 4.6.0 Status Report (2011-01-04), Stage 3 is over announcement. This bug should be a P1 since it is an ICE on valid code. If necessary I'll try to reduce the reproducer, but since that is likely to be a significant effort, I'd like to be sure that someone is paying attention. Is there?
[Bug c++/46807] internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 --- Comment #2 from rwgk at yahoo dot com 2010-12-17 22:34:16 UTC --- Using a binary search I found that svn rev. 161579 introduced the ICE. (Note that I had to replace gcc/config/i386/i386.md with rev. 161594 since gcc doesn't build otherwise.) % svn log -v -r 161579 r161579 | jason | 2010-06-29 17:50:57 -0700 (Tue, 29 Jun 2010) | 40 lines Changed paths: M /trunk/gcc/cp/ChangeLog M /trunk/gcc/cp/call.c M /trunk/gcc/cp/class.c M /trunk/gcc/cp/cp-tree.h M /trunk/gcc/cp/decl.c M /trunk/gcc/cp/method.c M /trunk/gcc/cp/search.c M /trunk/gcc/cp/semantics.c M /trunk/gcc/cp/tree.c Machinery to support implicit delete/move. * cp-tree.h: (struct lang_type_class): Add lazy_move_assign, has_complex_move_ctor, has_complex_move_assign bitfields. (CLASSTYPE_LAZY_MOVE_ASSIGN): New. (TYPE_HAS_COMPLEX_MOVE_ASSIGN): New. (TYPE_HAS_COMPLEX_MOVE_CTOR): New. (enum special_function_kind): Add sfk_move_assignment. (LOOKUP_SPECULATIVE): New. * call.c (build_over_call): Return early if it's set. (build_over_call): Use trivial_fn_p. * class.c (check_bases): If the base has no default constructor, the derived one is non-trivial. Handle move ctor/op=. (check_field_decl): Likewise. (check_bases_and_members): Handle move ctor/op=. (add_implicitly_declared_members): Handle CLASSTYPE_LAZY_MOVE_ASSIGN. (type_has_move_constructor, type_has_move_assign): New. * decl.c (grok_special_member_properties): Handle move ctor/op=. * method.c (type_has_trivial_fn, type_set_nontrivial_flag): New. (trivial_fn_p): New. (do_build_copy_constructor): Use it. (do_build_assign_ref): Likewise. Handle move assignment. (build_stub_type, build_stub_object, locate_fn_flags): New. (locate_ctor): Use locate_fn_flags. (locate_copy, locate_dtor): Remove. (get_dtor, get_default_ctor, get_copy_ctor, get_copy_assign): New. (process_subob_fn, synthesized_method_walk): New. (maybe_explain_implicit_delete): New. (implicitly_declare_fn): Use synthesized_method_walk, type_has_trivial_fn, and type_set_nontrivial_flag. (defaulted_late_check): Set DECL_DELETED_FN. (defaultable_fn_check): Handle sfk_move_assignment. (lazily_declare_fn): Clear CLASSTYPE_LAZY_* early. Don't declare implicitly deleted move ctor/op=. * search.c (lookup_fnfields_1): Handle sfk_move_assignment. (lookup_fnfields_slot): New. * semantics.c (omp_clause_info_fndecl): Remove. (cxx_omp_create_clause_info): Use get_default_ctor, get_copy_ctor, get_copy_assign, trivial_fn_p. (trait_expr_value): Adjust call to locate_ctor. * tree.c (special_function_p): Handle sfk_move_assignment.
[Bug c++/46759] incorrect array bounds warning?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46759 --- Comment #4 from rwgk at yahoo dot com 2010-12-05 06:14:35 UTC --- Created attachment 22639 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22639 reproducer for similar warning from gcc 4.6 I'm getting a similar warning with g++ from the current svn trunk: svn trunk rev. 167466 g++ (GCC) 4.6.0 20101205 (experimental) % g++ -Wall -O3 pr46759_bounds_warning_2.cpp pr46759_bounds_warning_2.cpp: In function 'int main()': pr46759_bounds_warning_2.cpp:11:3: warning: array subscript is above array bounds [-Warray-bounds] The reproducer is attached. g++ 4.5.1 doesn't emit a warning. Would it be better to file this as a new bug?
[Bug c++/46807] New: internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 Summary: internal compiler error: in synthesized_method_walk Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@yahoo.com Fedora 14 64-bit gcc svn trunk rev. 167466 g++ (GCC) 4.6.0 20101205 (experimental) % g++ -c gcc46_ice.cpp In file included from gcc46_ice.cpp:1:0: /usr/include/boost/foreach.hpp: In function 'boost::foreach_detail_::auto_anyT boost::foreach_detail_::contain(const T, mpl_::true_*) [with T = boost::iterator_range__gnu_cxx::__normal_iteratoritem**, std::vectoritem* , mpl_::true_ = mpl_::bool_true]': gcc46_ice.cpp:12:3: instantiated from 'void work(const boost::iterator_rangeT) [with ForwardIteratorType = __gnu_cxx::__normal_iteratoritem**, std::vectoritem* ]' gcc46_ice.cpp:19:42: instantiated from here /usr/include/boost/foreach.hpp:609:12: internal compiler error: in synthesized_method_walk, at cp/method.c:1308 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/46807] internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 --- Comment #1 from rwgk at yahoo dot com 2010-12-05 07:42:02 UTC --- Created attachment 22640 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22640 reproducer Reproducer depends on vector and boost as shipped with Fedora 14.
[Bug c++/46759] incorrect array bounds warning?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46759 --- Comment #3 from rwgk at yahoo dot com 2010-12-02 19:47:29 UTC --- Created attachment 22606 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22606 reproducer with additional tests I changed the original reproducer to return 0 through 4 instead of true or false to verify that each branch is exercised with added tests. The output is as expected and valgrind doesn't report problems. Therefore I still believe the warning misfires. Assuming my code holds up under further scrutinization: It clearly is a minor problem but it creates distracting noise. If it is too much trouble to fix in the 4.5 branch, could the example be added to the test suite in the trunk, so that the same problem doesn't crop up again in the future? % valgrind a.out ==20636== Memcheck, a memory error detector ==20636== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==20636== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==20636== Command: a.out ==20636== 0 0 1 1 2 2 3 3 4 4 4 ==20636== ==20636== HEAP SUMMARY: ==20636== in use at exit: 0 bytes in 0 blocks ==20636== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==20636== ==20636== All heap blocks were freed -- no leaks are possible ==20636== ==20636== For counts of detected and suppressed errors, rerun with: -v ==20636== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[Bug bootstrap/46757] New: bootstrap failure under Fedora 13 and 14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46757 Summary: bootstrap failure under Fedora 13 and 14 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@yahoo.com Created attachment 22594 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22594 config.log Fedora 13 x86_64 Fedora 14 x86_64 On each machine these packages are installed into /usr/local: gmp-5.0.1.tar.bz2 mpfr-3.0.0.tar.bz2 mpc-0.8.2.tar.gz gcc svn trunk rev. 167359 ../gcc_trunk/configure --prefix=$th1/gcc_trunk_167359_fc14 --enable-languages=c,c++ runs to completion. make bootstrap runs for a while and stops with a failure: configure: error: cannot compute suffix of object files: cannot compile Attaching: config.log make_bootstrap_log
[Bug bootstrap/46757] bootstrap failure under Fedora 13 and 14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46757 --- Comment #1 from rwgk at yahoo dot com 2010-12-01 23:44:42 UTC --- Created attachment 22595 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22595 output of make bootstrap
[Bug c++/46759] New: incorrect array bounds warning?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46759 Summary: incorrect array bounds warning? Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@yahoo.com Created attachment 22598 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22598 small reproducer Linux theta.lbl.gov 2.6.35.6-48.fc14.x86_64 #1 SMP Fri Oct 22 15:36:08 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux g++ (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) g++ -Wall -O1 ~/bounds_warning.cpp # no warning g++ -Wall -O2 ~/bounds_warning.cpp bounds_warning.cpp: In function 'int main()': bounds_warning.cpp:21:14: warning: array subscript is above array bounds I stared at this for a while but couldn't find a problem with my code. Is there maybe a problem with the optimizer? Unfortunately I've been unable to bootstrap the 4.5 branch or the trunk. Could someone try out the attached reproducer against the current svn of the branch/trunk?
[Bug bootstrap/46757] bootstrap failure under Fedora 13 and 14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46757 --- Comment #3 from rwgk at yahoo dot com 2010-12-02 01:52:35 UTC --- Thank you very much for the hint! As a remark: I had a little bit of a battle with the gmp, mpfr, mpc dependencies, in particular mpc since I couldn't figure out the yum command to get it. Next I tried putting the three svn trees inside the gcc svn which made configure work, but make bootstrap failed after a while because there was a command that couldn't find mpfr.h. As a third attempt I installed the three dependencies into /usr/local. I wonder how many people go through a similar experience and just give up. I figure adding matching gmp/mpfr/mpc sources to the gcc svn and using those unconditionally could avoid such frustration, although I understand at an additional maintenance burden for the gcc developers.
[Bug c++/43594] New: long-standing g++ bug?
//#include cstdio
struct values
{
static const int one = 1;
};
struct counter
{
int n;
counter() : n(0) {}
counter
operator,(int const) { n++; return *this; }
};
int
main()
{
values vals;
counter cntr;
cntr, vals.one;
//std::printf(%d\n, cntr.n);
return 0;
}
g++ problem.cpp
/tmp/cc88FSiA.o: In function `main':
problem.cpp:(.text+0x19): undefined reference to `values::one'
collect2: ld returned 1 exit status
I'm getting the same failure with gcc 3.2, 4.1, 4.4, 4.5.0 20100109.
It works as expected with Visual C++ 9.0.
Is this a bug?
--
Summary: long-standing g++ bug?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwgk at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43594
[Bug libstdc++/42352] -std=c++0x reference binding problem
--- Comment #14 from rwgk at yahoo dot com 2009-12-19 15:09 --- (In reply to comment #13) That said, this specific issue has been moved yesterday to [Tentatively Ready] and it's safe enough to simply re-add for now the C++03 set of overloads (we don't implement yet the C++0x allocator model), I'll do that later today. For the records, I can now use -std=c++0x again for everything we have (I tested with svn rev. 155354). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug libstdc++/42352] -std=c++0x reference binding problem
--- Comment #12 from rwgk at yahoo dot com 2009-12-14 06:05 ---
(In reply to comment #10)
What do you mean by of this type? As I tried already to explain, until the
ISO C++ Committee resolves DR 1133 we cannot touch list::merge and
list::splice.
Sorry, I wasn't looking carefully enough. The remaining errors are indeed
different. Reduced below.
If I comment out all .splice() in our code everything else compiles.
The DR details are over my head, I'm afraid. Does cannot touch mean we are
stuck with a broken list.splice() and .merge() for now, until the standards
committee has made changes?
#include list
void work()
{
std::listint l, m;
l.splice(l.end(), m);
}
% g++ -c -std=c++0x ~/gcc_bugs/list_splice_bind.cpp
/net/cci/rwgk/gcc_bugs/list_splice_bind.cpp: In function 'void work()':
/net/cci/rwgk/gcc_bugs/list_splice_bind.cpp:6:21: error: cannot bind
'std::listint' lvalue to 'std::listint'
/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_155182_fc12_x86_64/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_list.h:1154:7:
error: initializing argument 2 of 'void std::list_Tp,
_Alloc::splice(std::list_Tp, _Alloc::iterator, std::list_Tp, _Alloc)
[with _Tp = int, _Alloc = std::allocatorint, std::list_Tp, _Alloc::iterator
= std::_List_iteratorint, std::list_Tp, _Alloc = std::listint]'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug c++/42352] New: -std=c++0x reference binding problem
Platform: Fedora release 12 (Constantine) Linux cage.lbl.gov 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux URL: svn://gcc.gnu.org/svn/gcc/trunk Revision: 150327 or higher gcc version 4.5.0 20090801 (experimental) (GCC) I'll attach a reproducer. g++ -c -std=c++0x list_sort_bind.cpp ... include/c++/4.5.0/bits/list.tcc:392:3: error: cannot bind 'std::listint' lvalue to 'std::listint' ... It works without -std=c++0x. svn rev. 150326 works, 150327 does not. The critical svn revision was: % svn log -v -c150327 r150327 | jason | 2009-07-31 19:26:42 -0700 (Fri, 31 Jul 2009) | 16 lines Changed paths: M /trunk/gcc/cp/ChangeLog M /trunk/gcc/cp/call.c M /trunk/gcc/cp/cp-tree.h M /trunk/gcc/cp/typeck.c M /trunk/gcc/testsuite/ChangeLog M /trunk/gcc/testsuite/g++.dg/cpp0x/initlist22.C M /trunk/gcc/testsuite/g++.dg/cpp0x/named.C M /trunk/gcc/testsuite/g++.dg/cpp0x/overload.C A /trunk/gcc/testsuite/g++.dg/cpp0x/overloadn.C (from /trunk/gcc/testsuite/g++.dg/cpp0x/overload.C:150326) A /trunk/gcc/testsuite/g++.dg/cpp0x/rv-cast.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv1n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv1p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv2n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv2p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv3n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv3p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv4n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv4p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv5n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv5p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv6n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv6p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv7n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv7p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv8p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/template_deduction.C M /trunk/gcc/testsuite/g++.dg/cpp0x/unnamed_refs.C M /trunk/libstdc++-v3/ChangeLog M /trunk/libstdc++-v3/include/bits/move.h M /trunk/libstdc++-v3/include/std/istream M /trunk/libstdc++-v3/include/std/ostream A /trunk/libstdc++-v3/testsuite/27_io/rvalue_streams.cc * call.c (convert_class_to_reference): Binding an lvalue to an rvalue reference is bad. If the user-defined conversion is bad, set bad_p before merging conversions. (maybe_handle_ref_bind): Don't push down bad_p. (reference_binding): Binding an lvalue to an rvalue reference is bad. (convert_like_real): Give a helpful error about binding lvalue to rvalue reference. (reference_related_p): No longer static. * typeck.c (build_typed_address): New. (build_static_cast_1): Add static_cast from lvalue to . * cp-tree.h: Adjust. * include/bits/move.h (forward): Implement as in N2835. (move): Implement as in N2831. * include/std/istream (rvalue stream operator): New. * include/std/ostream (rvalue stream operator): New. -- Summary: -std=c++0x reference binding problem Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug c++/42352] -std=c++0x reference binding problem
--- Comment #1 from rwgk at yahoo dot com 2009-12-11 18:05 --- Created an attachment (id=19277) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19277action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug c++/42352] -std=c++0x reference binding problem
--- Comment #5 from rwgk at yahoo dot com 2009-12-11 19:27 --- Thanks for the fast response! Everything else we have works with -std=c++0x. If this issue is fixed I could keep testing with -std=c++0x, which I imagine could be of great value long term. (We have several 100k of sources + boost + an extensive test suite exercising numerical procedures.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug libstdc++/42352] -std=c++0x reference binding problem
--- Comment #9 from rwgk at yahoo dot com 2009-12-12 05:49 --- Thanks very much for the quick fix! It didn't clear up all errors of this type, though, when compiling our code (I verified that the original problem is fixed). Based on your comments I decided to remove the -std=c++x0 for the small section of our sources which trigger the errors. I can still compile around 99% with the -std=c++0x option. Let me know if/when you are interested in reduced examples of the other failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression
--- Comment #2 from rwgk at yahoo dot com 2009-12-06 19:18 --- With a binary search in the svn history I found that the change below lead to the regression. I believe it is a major problem. Could someone confirm it? I think it should be a P1. r154768 | dodji | 2009-11-30 01:58:20 -0800 (Mon, 30 Nov 2009) | 9 lines Fix PR c++/42069 gcc/cp/ChangeLog: PR c++/42069 * pt.c (convert_template_argument): Strip typedefs from SCOPE_REFs. gcc/testsuite/ChangeLog: PR c++/42069 * g++.dg/template/typedef23.C: New test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
[Bug bootstrap/42247] make bootstrap failure
--- Comment #3 from rwgk at yahoo dot com 2009-12-02 18:15 --- (In reply to comment #2) Yeah, yum install glibc-devel.i686 in F12 case. Thank you very much! This is exactly what I needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42247
[Bug bootstrap/42247] New: make bootstrap failure
Platform: Fedora release 12 (Constantine) Linux cage.lbl.gov 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux g++ (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7) URL: svn://gcc.gnu.org/svn/gcc/trunk Revision: 154886 cd gcc_build ../gcc_trunk/configure make bootstrap -j24 make bootstrap The first make bootstrap -j24 fails with many errors after running for ca. two minutes. Re-running make bootstrap produces the error below. Le me know if you need the full log. I first observed the problem about two days ago under Fedora 11 x86_64. I'm also getting the error running just make. /net/cage/raid1/rwgk/gcc_build/./gcc/xgcc -B/net/cage/raid1/rwgk/gcc_build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include-g -O2 -m32 -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../../../../gcc_trunk/libgcc -I../../../../gcc_trunk/libgcc/. -I../../../../gcc_trunk/libgcc/../gcc -I../../../../gcc_trunk/libgcc/../include -I../../../../gcc_trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc_trunk/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/features.h:376:0, from /usr/include/stdio.h:28, from ../../../../gcc_trunk/libgcc/../gcc/tsystem.h:87, from ../../../../gcc_trunk/libgcc/../gcc/libgcc2.c:29: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. make[5]: *** [_muldi3.o] Error 1 -- Summary: make bootstrap failure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42247
[Bug c++/42251] New: failure detecting constant integral expression
Platform: Fedora release 12 (Constantine) Linux cage.lbl.gov 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux g++ (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7) URL: svn://gcc.gnu.org/svn/gcc/trunk Revision: 154886 % g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_154886_fc12_x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /net/cage/raid1/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_154886_fc12_x86_64 --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.5.0 20091201 (experimental) (GCC) g++ -c ~/not_const.cpp /net/cci/rwgk/not_const.cpp:58:13: error: integral expression 'boost::hash_detail::ldexpf_detect::check:: c99' is not constant /net/cci/rwgk/not_const.cpp:58:13: error: trying to instantiate 'templatebool x struct boost::hash_detail::call_c99_ldexpf' I'll add a self-contained reproducer (60 lines, no includes). Reduced from boost/functional/hash/detail/float_functions.hpp boost svn trunk 58091. It works with g++ 4.4.2 (Fedora 12) and I think many other compilers. -- Summary: failure detecting constant integral expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
[Bug c++/42251] failure detecting constant integral expression
--- Comment #1 from rwgk at yahoo dot com 2009-12-02 06:23 --- Created an attachment (id=19207) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19207action=view) self-contained reproducer (60 lines, no includes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
[Bug c++/37922] [4.3/4.4 Regression] code generation error
--- Comment #18 from rwgk at yahoo dot com 2008-12-17 19:01 --- (In reply to comment #17) A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00943.html I tried this patch locally and I'm happy to report that it fixes the original problem. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] [4.4 Regression] code generation error
--- Comment #7 from rwgk at yahoo dot com 2008-12-16 02:17 --- (In reply to comment #6) Does -fno-strict-aliasing work? Nope. I just tried it with svn revisions 129269 and 142737. Adding -fno-strict-aliasing does not change the (wrong) result. Thanks for looking at this! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] code generation error
--- Comment #5 from rwgk at yahoo dot com 2008-12-13 22:09 --- The bug is still present in svn revsion 140355 from last night. I ran an automatic search through the svn history. The result is that revision 129269 (svn log below) introduced the bug. Could someone please confirm the bug with the reproducer I posted last weekend? It should only take a second. r129269 | rsandifo | 2007-10-12 09:54:38 -0700 (Fri, 12 Oct 2007) | 14 lines gcc/ * dse.c (find_shift_sequence): Reinstate = UNITS_PER_WORD condition. * var-tracking.c (micro_operation_def): Update comment on u.loc. (mode_for_reg_attrs, var_lowpart): New functions. (add_uses): Consider recording a lowpart of LOC for MO_USE. (add_stores): Likewise MO_SET and MO_COPY. If the source of a set or copy is known, set LOC to the SET that performs the set, instead of the destination. (find_src_status, find_src_set_src): Remove LOC parameter. Replace INSN with the source value. (compute_bb_dataflow, emit_notes_in_bb): Check for a SET u.loc when handling MO_SET and MO_COPY. Update the calls to find_src_status and find_src_set_src. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] code generation error
--- Comment #3 from rwgk at yahoo dot com 2008-12-07 07:34 --- Created an attachment (id=16844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16844action=view) reproducer, no dependencies, no includes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] code generation error
--- Comment #4 from rwgk at yahoo dot com 2008-12-07 07:44 ---
Testing with:
g++ (GCC) 4.4.0 20081206 (experimental)
svn revision 142514
pr37922repro1.cpp should always exit with status 0.
However, it fails this test when compiling with -O3 and -O2:
g++ -Wall -fPIC -O3 pr37922repro1.cpp
./a.out ; echo $status
2
g++ -Wall -fPIC -O2 pr37922repro1.cpp
./a.out ; echo $status
2
g++ -Wall -fPIC -O1 pr37922repro1.cpp
./a.out ; echo $status
0
g++ -Wall -fPIC -O0 pr37922repro1.cpp
./a.out ; echo $status
0
The -fPIC is critical.
The problem region in the reproducer is marked with comments:
// THE PROBLEM IS AROUND HERE
if (proper_order 0) {
proper_order *= -1;
proper_r = -proper_r; // THIS FAILS ...
}
if (proper_order 1) {
rot_mx rmi = proper_r.minus_unit_mx(); // ... THEREFORE WRONG HERE
Sorry it is still 556 lines long, but I already spent 2 1/2 hours
reducing it this far. At least, it is completely self-contained and
compiles in fractions of a second.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] New: code generation error
Platform:
Fedora release 8 (Werewolf)
Linux chevy.lbl.gov 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008
x86_64 x86_64 x86_64 GNU/Linux
% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure
--prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_141361_fc8_x86_64
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.0 20081025 (experimental) (GCC)
Problematic C++ code fragment:
rot_mx proper_r = r;
int proper_order = type_;
if (proper_order 0) {
std::cout A branch std::endl;
proper_order *= -1;
proper_r = -proper_r;
}
if (proper_order 1) {
std::cout B branch std::endl;
...
}
Compiled with (just to show optimization options; please ignore the rest):
g++ -o cctbx/sgtbx/rot_mx_info.o -c -fno-strict-aliasing -fPIC
-ftemplate-depth-120 -w -DNDEBUG -O3 -ffast-math -fno-associative-math
-ftrapping-math -DBOOST_DISABLE_THREADS -fopenmp -Iinclude
-I/net/chevy/raid1/rwgk/hot/include -I/net/chevy/raid1/rwgk/as_in_cvs/include
-I/net/chevy/raid1/rwgk/hot/b u f/include -I/net/chevy/raid1/rwgk/as_in_cvs
-I/net/chevy/raid1/rwgk/hot/boost
/net/chevy/raid1/rwgk/as_in_cvs/cctbx/sgtbx/rot_mx_info.cpp
Given type_ = -2, the print statements should show
A branch
B branch
but only B branch is actually shown.
I can work around this problem either by compiling without optimizations, or by
replacing the code above with:
rot_mx proper_r;
int proper_order;
if (type_ 0) {
std::cout A branch std::endl;
proper_order = -type_;
proper_r = -r;
}
else {
std::cout A else branch std::endl;
proper_order = type_;
proper_r = r;
}
if (proper_order 1) {
std::cout B branch std::endl;
...
}
I tried to reduce the problem, but it turns out to be tricky. The code above is
part of a shared library (.so). Simply moving it into the same translation unit
as the calling code makes the error go away.
Before I spend more time on this, does the problem look familiar? (I.e. could
it be that this bug was reported already?)
I could give you a self-contained but very large reproducer. This would enable
you to inspect the generated code, and maybe give us a clue how to construct a
minimal reproducer.
--
Summary: code generation error
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwgk at yahoo dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] code generation error
--- Comment #2 from rwgk at yahoo dot com 2008-10-27 02:18 --- (In reply to comment #1) With out a testcase, it is hard to tell if it was reported before or not. Also does -fwrapv allows for the code to work? Yes! (FWIW: -ftrapv doesn't help.) what type is rot_mx? A user-defined type with an array of nine int plus another separate int. The whole thing is here: http://cctbx.svn.sourceforge.net/viewvc/cctbx/trunk/cctbx/sgtbx/rot_mx.h?view=markup Let me know if you have an interested in the large but self-contained reproducer. You'd have to get one file, run one command to build everything (takes a few minutes), then one command to demonstrate the problem. The reproducer is a simple main(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37518] New: preprocessor failure
Platform: Fedora release 8 (Werewolf) Linux chevy.lbl.gov 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_140355_fc8_x86_64 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080914 (experimental) (GCC) % cat boost_mpl_less.cpp #include boost/mpl/less.hpp % g++ -c boost_mpl_less.cpp In file included from /usr/include/boost/mpl/aux_/numeric_op.hpp:22, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/numeric_cast_utils.hpp:18, from /usr/include/boost/mpl/aux_/numeric_op.hpp:25, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/aux_/numeric_op.hpp:290:31: error: missing binary operator before token ( Observations: g++ -E boost_mpl_less.cpp /dev/null leads to the same error. Many other mpl headers lead to a similar error. Adding -fpermissive doesn't make a difference. Using the boost svn trunk instead of the boost that comes with Fedora 8 leads to the same error. -- Summary: preprocessor failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37518
[Bug c++/37518] preprocessor failure
--- Comment #2 from rwgk at yahoo dot com 2008-09-14 07:24 --- What is on that line? #elif BOOST_PP_ITERATION_DEPTH() == 1 If you don't have /usr/include/boost, you can get the entire boost tree from here: svn co https://svn.boost.org/svn/boost/trunk boost Then simply compile with -Iboost. I think this is invalid code This boost code is about four years old and compiles with many compilers incl. any other gcc = 3.2 (at least), many EDG versions, and Visual C++ = 6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37518
[Bug middle-end/34233] [4.3 Regresion] ICE: get_callee_fndecl, at tree.c:6592
--- Comment #7 from rwgk at yahoo dot com 2007-11-27 17:43 --- (In reply to comment #6) Fixed. Confirmed (yesterday with svn revision 130447). Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
[Bug c++/34229] New: error on correct code
Platform: Fedora release 7 (Moonshine) Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130411_x86_64_fc7 --enable-languages=c,c++,fortran --with-mpfr=/usr Thread model: posix gcc version 4.3.0 20071125 (experimental) (GCC) I'll attach a small reproducer. % g++ -c -fpermissive -I/usr/include/python2.5 used_but_not_defined.cpp /usr/include/boost/type_traits/detail/cv_traits_impl.hpp:37: error: static data member 'boost::detail::cv_traits_impboost::reference_wrapperboost::python::objects::unnamed::bind_return*::is_const' used, but not defined Some data points: svn revision 130341 didn't have this problem. svn revision 130396 is broken already. svn revision 130411 is still broken. Ralf -- Summary: error on correct code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
[Bug c++/34229] error on correct code
--- Comment #1 from rwgk at yahoo dot com 2007-11-25 20:30 --- Created an attachment (id=14636) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14636action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
[Bug c++/34229] error on correct code
--- Comment #4 from rwgk at yahoo dot com 2007-11-26 01:52 --- Created an attachment (id=14638) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14638action=view) reproducer preprocessed gzip'ed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
[Bug c++/34229] error on correct code
--- Comment #5 from rwgk at yahoo dot com 2007-11-26 02:11 --- cc'ing David Abrahams since the original code is his. -- rwgk at yahoo dot com changed: What|Removed |Added CC||dave at boost-consulting dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
[Bug c++/34229] error on correct code
--- Comment #6 from rwgk at yahoo dot com 2007-11-26 02:17 ---
The patch below makes the Boost.Python compilation work again with
gcc svn trunk revision 130411. This solves my problem. :-)
The g++ change could be tough for people who have to keep using older
boost versions for one reason or another. I think it would be best
to accept the old code if -fpermissive is given, at least on the
gcc 4.3 line.
Index: function.cpp
===
--- function.cpp(revision 41350)
+++ function.cpp(working copy)
@@ -565,7 +565,11 @@
}
-namespace
+namespace detail
+/* Cannot be anonymous namespace:
+ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
+ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
+ */
{
struct bind_return
{
@@ -610,7 +614,8 @@
function_call(PyObject *func, PyObject *args, PyObject *kw)
{
PyObject* result = 0;
-handle_exception(bind_return(result, static_castfunction*(func),
args, kw));
+handle_exception(
+ detail::bind_return(result, static_castfunction*(func), args,
kw));
return result;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
[Bug c++/34233] New: ICE: get_callee_fndecl, at tree.c:6592
Platform: Fedora release 7 (Moonshine) Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130411_x86_64_fc7 --enable-languages=c,c++,fortran --with-mpfr=/usr Thread model: posix gcc version 4.3.0 20071125 (experimental) (GCC) % g++ -c -fno-strict-aliasing -Wall -O2 -ffast-math -ftrapping-math ice_get_callee_fndecl.cpp ice_get_callee_fndecl.cpp:1: warning: -fassociative-math disabled; other options take precedence ice_get_callee_fndecl.cpp: In constructor 'cctbx::maptbx::find_gaussian_parameters::find_gaussian_parameters(const scitbx::af::const_refdouble, const scitbx::af::const_refdouble, const double, const double, double)': ice_get_callee_fndecl.cpp:78: internal compiler error: in get_callee_fndecl, at tree.c:6592 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I'll attach the reproducer. There are many ways to make the ICE go away. For example, I couldn't find an easy way to eliminate the dependence on std::string. Both -ffast-math and -ftrapping-math are essential. Ralf -- Summary: ICE: get_callee_fndecl, at tree.c:6592 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
[Bug c++/34233] ICE: get_callee_fndecl, at tree.c:6592
--- Comment #1 from rwgk at yahoo dot com 2007-11-26 03:33 --- Created an attachment (id=14639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14639action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
[Bug c++/34233] ICE: get_callee_fndecl, at tree.c:6592
--- Comment #2 from rwgk at yahoo dot com 2007-11-26 03:34 --- Created an attachment (id=14640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14640action=view) reproducer preprocessed gzip'ed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
[Bug tree-optimization/34127] ICE: tree-ssa-operands.c:1688
--- Comment #3 from rwgk at yahoo dot com 2007-11-18 02:54 --- (In reply to comment #2) Works for me, this is a dup of PR34113. *** This bug has been marked as a duplicate of 34113 *** This is not the case. My original bug report was based on svn revision 130232, which includes the fix for PR34113 (fixed with svn revision 130223). I tried again today from scratch with svn revision 130261 (this time under Fedora 5 because the other machine crashed): % gcc -fPIC -c -O3 ice_ssa_34127.c ice_ssa_34127.c: In function 'prepare_s': ice_ssa_34127.c:297: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1688 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- rwgk at yahoo dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34127
[Bug c/34127] New: ICE: tree-ssa-operands.c:1688
Platform: Fedora release 7 (Moonshine) Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130232_x86_64_fc7 --enable-languages=c,c++,fortran --with-mpfr=/usr Thread model: posix gcc version 4.3.0 20071116 (experimental) (GCC) I'll attach a stand-alone reproducer. It works with -O0 but not -O1 or higher: % gcc -c -fno-strict-aliasing -O1 -Wall ice_ssa.c ice_ssa.c: In function 's_init': ice_ssa.c:281: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1688 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The reproducer is derived from: Python-2.5.1/Modules/_struct.c It is still quite big (297 lines) but has no external dependencies. I've spend a significant amount of time stripping it down starting from ca. 6000 lines of pre-processed code. I hope you can do the rest much faster than I could. Ralf -- Summary: ICE: tree-ssa-operands.c:1688 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34127
[Bug c/34127] ICE: tree-ssa-operands.c:1688
--- Comment #1 from rwgk at yahoo dot com 2007-11-16 21:11 --- Created an attachment (id=14568) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14568action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34127
[Bug c++/34099] optimizer problem
--- Comment #1 from rwgk at yahoo dot com 2007-11-15 06:56 --- Created an attachment (id=14554) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14554action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug c++/34090] -O3 wrong code, -O2 OK
--- Comment #4 from rwgk at yahoo dot com 2007-11-15 02:18 --- (In reply to comment #3) What happens if you add -fno-strict-aliasing ? That's it! And maybe even try with warnings turned on. -Wall doesn't lead to any warnings. I've been compiling the boost_python runtime library with -fno-strict-aliasing for some time (just out of fear, although it didn't make a difference so far) but I used to get away with cutting corners when compiling our extensions without the -fno-strict-aliasing. The bulk of our code is expected to be safe with strict aliasing. The problem is, much of it is in header files as templates. If the Python bindings dictate that I have to use -fno-strict-aliasing, unfortunately that means almost all our templates are compiled with the same setting. But that's not a g++ problem! I suggest closing this problem report. Thanks! Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34090
[Bug c++/34099] New: optimizer problem
Platform: Fedora release 7 (Moonshine) Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130159_x86_64_fc7 --enable-languages=c,c++,fortran --with-mpfr=/usr Thread model: posix gcc version 4.3.0 20071113 (experimental) (GCC) I'll attach a small reproducer. It works with -O0: % g++ -O0 -Wall multiply_bug.cpp -fno-strict-aliasing ./a.out (7,4) But doesn't with -O1 or higher: % g++ -O1 -Wall multiply_bug.cpp -fno-strict-aliasing ./a.out (0,0) The reproducer #includes complex. I'm guessing it wouldn't be hard to reduce the reproducer if necessary. Ralf -- Summary: optimizer problem Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug c++/34090] New: -O3 wrong code, -O2 OK
Platform: Fedora release 7 (Moonshine) Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130159_x86_64_fc7 --enable-languages=c,c++,fortran --with-mpfr=/usr Thread model: posix gcc version 4.3.0 20071113 (experimental) (GCC) I'll attach a tiny reproducer. To reproduce the problem: % ./demo.csh 123 Traceback (most recent call last): File run.py, line 2, in module print foo(start=1, stop=3) Boost.Python.ArgumentError: Python argument types in demo.foo() did not match C++ signature: foo(int None, int stop) The 123 is the correct result as obtained when compiling with -O2. The Python traceback is due to wrong code produced with -O3. Sorry, I know the reproducer isn't minimal at all, even though it is tiny. It is a hell to reduce. I'm hoping for some kind of miracle... or at least suggestions for reducing this with a reasonable amount of effort. Ralf -- Summary: -O3 wrong code, -O2 OK Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34090
[Bug c++/34090] -O3 wrong code, -O2 OK
--- Comment #1 from rwgk at yahoo dot com 2007-11-14 03:15 --- Created an attachment (id=14550) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14550action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34090
[Bug c++/34063] New: ICE: build2_stat, at tree.c:3115
Platform: Fedora release 7 (Moonshine) Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130073_x86_64_fc7 --enable-languages=c,c++,fortran --with-mpfr=/usr Thread model: posix gcc version 4.3.0 20071110 (experimental) (GCC) I'll upload a small standalone reproducer. To reproduce the problem: % g++ -c -O1 ice_build2_stat.cpp ice_build2_stat.cpp: In function 'void foo()': ice_build2_stat.cpp:13: internal compiler error: in build2_stat, at tree.c:3115 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It works with this alternative command: g++ -c ice_build2_stat.cpp It also works with many other compilers including all older g++. Ralf -- Summary: ICE: build2_stat, at tree.c:3115 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
[Bug c++/34063] ICE: build2_stat, at tree.c:3115
--- Comment #1 from rwgk at yahoo dot com 2007-11-11 05:53 --- Created an attachment (id=14527) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14527action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
[Bug c++/34018] New: ICE: verify_stmts failed
Platform: Fedora release 7 (Moonshine) Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_129944_x86_64_fc7 --enable-languages=c,c++,fortran --with-mpfr=/usr Thread model: posix gcc version 4.3.0 20071106 (experimental) (GCC) I'll upload a small standalone reproducer. To reproduce the problem: % g++ -c -O1 ~/verify_stmts_failed.cpp /net/cci/rwgk/verify_stmts_failed.cpp: In constructor 'triangulation::triangulation(const tinylong unsigned int, 3ul)': /net/cci/rwgk/verify_stmts_failed.cpp:73: error: invalid operand to binary operator this_2(D)-n_cells.elems[0]; /net/cci/rwgk/verify_stmts_failed.cpp:73: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It works with these alternative commands: g++ -c -O1 ~/verify_stmts_failed.cpp -DDISABLE_INLINE g++ -c ~/verify_stmts_failed.cpp It also works with many other compilers including all older g++. Ralf -- Summary: ICE: verify_stmts failed Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34018
[Bug middle-end/34018] [4.3 Regression] ICE: verify_stmts failed
--- Comment #1 from rwgk at yahoo dot com 2007-11-07 19:45 --- Created an attachment (id=14501) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14501action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34018
[Bug c++/33185] [4.3 Regression] ICE: canonical types differ for identical types T [] and T []
--- Comment #8 from rwgk at yahoo dot com 2007-09-22 04:22 --- Created an attachment (id=14243) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14243action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33185
[Bug c++/33185] [4.3 Regression] ICE: canonical types differ for identical types T [] and T []
--- Comment #9 from rwgk at yahoo dot com 2007-09-22 04:23 --- Info regarding Comment #8: Fedora Core release 5 (Bordeaux) % uname -r -m 2.6.15-1.2054_FC5 x86_64 % g++ -fpermissive -c -fPIC -I/usr/include/python2.4 ice_canonical.cpp ice_canonical.cpp: In function 'void init_module()': ice_canonical.cpp:8: internal compiler error: canonical types differ for identical types const char [3] and const char [3] Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The result is the same with: g++ (GCC) 4.3.0 20070919 (experimental) SVN revision 128608 as-is g++ (GCC) 4.3.0 20070922 (experimental) SVN revision 128661M where the M is because I've locally applied the patch from Comment #7. Apparently, the patch isn't the whole solution. Note: the -fpermissive is required to avoid the new changes meaning error. I've already fixed the boost SVN trunk so that the -fpermissive is no longer required. I can reproduce the same ICE based on the boost SVN trunk, without using the -fpermissive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33185
[Bug tree-optimization/33458] [4.3 regression] ICE PHI def is not a GIMPLE value
--- Comment #3 from rwgk at yahoo dot com 2007-09-22 04:59 --- I'm getting an ICE that looks very similar (below). However, I cannot reproduce the ICE with the test case posted when this issue was opened. Therefore I'm wondering if my ICE is different. What is the platform, and what is the exact g++ command to reproduce the ICE with the original test case? Reducing the sources leading to my ICE is probably serious work... My platform is: Fedora Core release 5 (Bordeaux) % uname -r -m 2.6.15-1.2054_FC5 x86_64 g++ (GCC) 4.3.0 20070919 (experimental) SVN revision 128608 g++ (GCC) 4.3.0 20070922 (experimental) SVN revision 128661 ice_gimple.cpp: In constructor 'scitbx::iso_surface::triangulationCoordinatesType, ValueType::triangulation(scitbx::af::const_refValueType, scitbx::af::c_grid_padded3ul, long unsigned int , ValueType, const scitbx::af::tinyIndexValueType, 3ul, bool) [with CoordinatesType = double, ValueType = double]': ice_gimple.cpp:32: error: invalid operand to binary operator this_2(D)-n_cells.D.101998.elems[0]; ice_gimple.cpp:32: error: PHI def is not a GIMPLE value result_34 = PHI this_2(D)-n_cells.D.101998.elems[0](2), result_36(3) this_2(D)-n_cells.D.101998.elems[0]; ice_gimple.cpp:32: error: invalid operand to binary operator this_2(D)-cell_lengths.D.104936.elems[0]; ice_gimple.cpp:32: error: PHI def is not a GIMPLE value result_48 = PHI this_2(D)-cell_lengths.D.104936.elems[0](5), result_51(6) this_2(D)-cell_lengths.D.104936.elems[0]; ice_gimple.cpp:32: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #12 from rwgk at yahoo dot com 2007-02-26 02:26 ---
Daniel Berlin wrote:
This change actually made us more conservative with points-to, it certainly
won't cause *more* things to be optimized away.
Was the change supposed to fix a certain problem?
If not I suggest the two lines should be backed out since they clearly cause
a regression on the 4.2 branch.
My suggestion is motivated by another experiment I did with the latest
SVN (revision 122315):
Procedure:
configure; make bootstrap; make; make install
followed by
1. running all our unit tests (1700 seconds of CPU time Xeon 2.8GHz)
2. trying the reproducer with g++ -fPIC -O3 dbg.cpp; ./a.out
Fedora 5, x86_64:
With SVN as is and with the two lines in question backed out
1. all our unit tests are fine
2. ./a.out prints 1 (OK)
Fedora 6, i686:
With SVN as is
1. all our unit tests are fine
2. ./a.out prints 0 (failure)
With the two lines in question backed out
1. all our unit tests are fine
2. ./a.out prints 1 (OK)
Here is my local patch to back out the two lines introduced in
SVN revision 119791:
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 122315)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -3303,8 +3303,8 @@
{
rhsoffset = TREE_INT_CST_LOW (op1) * BITS_PER_UNIT;
}
- else
-return false;
+/*else
+return false; */
for (i = 0; VEC_iterate (ce_s, lhsc, i, c); i++)
for (j = 0; VEC_iterate (ce_s, temp, j, c2); j++)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #14 from rwgk at yahoo dot com 2007-02-26 03:37 --- Yes. http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00817.html It also fixed vect-101 testcase, in addition to 464.h264ref from spec2006. It initially caused a failure in 403.gcc, but this was later found to be a latent bug elsewhere. OK. I imagine yours is the same thing (a latent bug elsewhere). I was thinking the same thing. If you want to try pointing out why you think what the patch does is incorrect, i'm happy to work through it with you. I'm just a user sounding an alarm bell. Your latent bug somewhere else idea makes total sense to me. I'm a little frustrated that all my efforts haven't even lead to confirming the bug, and I'm afraid that it gets swept under the rug and my time was wasted. If you could at least confirm the bug I'd be motivated to strip down my reproducer some more if that could help resolving this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #16 from rwgk at yahoo dot com 2007-02-26 07:54 --- Created an attachment (id=13110) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13110action=view) minimal reproducer I got it down to 29 lines. There aren't any includes, defines are typedefs left. Attempts to further reduce the code change the result. The command line I used during the reduction process was: g++ -fPIC -O3 dbg_minimal.cpp ./a.out ; echo $status ; g++ -fPIC -O0 dbg_minimal.cpp ./a.out ; echo $status The resulting output is: 0 1 Here 0 indicates failure. I really hope this helps you pin-pointing the bug! For completeness: % g++ --version g++ (GCC) 4.2.0 20070225 (prerelease) This is SVN revision 122315. -- rwgk at yahoo dot com changed: What|Removed |Added Attachment #12945|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #9 from rwgk at yahoo dot com 2007-02-12 15:47 --- My binary search (using the gcc-4_2-branch) stopped here: 119790 OK 119791 fails The corresponding commit was: % svn log -r 119791 r119791 | dberlin | 2006-12-12 07:31:26 -0800 (Tue, 12 Dec 2006) | 6 lines 2006-12-12 Daniel Berlin [EMAIL PROTECTED] * tree-ssa-structalias.c (handle_ptr_arith): Return false when we can't handle the pointer arithmetic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #8 from rwgk at yahoo dot com 2007-02-12 05:23 --- I'm in the process of narrowing down the revision bracket the really hard way (make bootstrap; make; make install for each revision, using a binary search). Currently my best bracket is: 119819 fails 119788 works I should have it nailed down to the exact revision in the next 12 hours or so. BTW: I checked the most current revision (yesterday) and it still fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #6 from rwgk at yahoo dot com 2007-02-11 05:30 --- I immediately believe that Andrew's and Wolfgang's findings are accurate, but I never claimed that the mainline has a problem. I never even tried it. My interest it to make sure that our code works with any new gcc release, since that's what the OS makers pick up, and then we are stuck with the remaining bugs for 5+ years. It looks like a gcc 4.2 release is imminent, therefore I'm testing with the corresponding branch. From other bug reports I know that you have a regression hunt procedure. Is there any way I can submit my reproducer to the hunter? We have a fairly small time bracket already, given by Andrew's 4.2 test and the day this bug was opened. Therefore it would seem straightforward to find the checkin which caused the problem. I'll repeat my test with the current 4.2 branch and post my results here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #4 from rwgk at yahoo dot com 2007-02-03 20:42 --- I've repeated my test with g++ (GCC) 4.2.0 20070203 (prerelease) SVN revision: 121547 on two platforms: x86_64 Fedora Core release 5 (Bordeaux) Fedora Core release 6 (Zod) The results are still the same as last weekend, i.e. the 32-bit optimizer is still broken. Since my reproducer compiles+links in less than a second, wouldn't it be feasable to run the automatic regression hunt? According to Andrew's result we just have to concentrate on the few weeks between 2006-12-04 and 2007-01-24. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #3 from rwgk at yahoo dot com 2007-01-28 20:03 --- I've repeated my test with g++ (GCC) 4.2.0 20070128 (prerelease) SVN revision: 121258 on three platforms: x86_64 Fedora Core release 5 (Bordeaux) % g++ -fPIC -O3 dbg_gcc_bugzilla_30567.cpp % ./a.out 1 i686 Fedora Core release 4 (Stentz) % g++ -fPIC -O3 dbg_gcc_bugzilla_30567.cpp % ./a.out 0 Fedora Core release 6 (Zod) % g++ -fPIC -O3 dbg_gcc_bugzilla_30567.cpp % ./a.out 0 I.e. 64-bit is still OK, 32-bit is still broken. Could someone please try to reproduce with the current version of the 4.2 branch? I'm worried that 4.2 is released with this bug, and that we have to deal with it for years to come... BTW: the system gcc versions are: x86_64 Fedora Core release 5 (Bordeaux) g++ (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3) i686 Fedora Core release 4 (Stentz) g++ (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) i686 Fedora Core release 6 (Zod) g++ (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] New: -fPIC -O3 optimizer bug (32-bit target only)
Platform: Fedora Core release 4 (Stentz) Linux sharptail.lbl.gov 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 i686 i386 GNU/Linux % g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc-4_2-branch/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_4_2-branch_2007_01_22_0959_fc4_i686 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0 20070122 (prerelease) I'll upload a standalone reproducer. Sorry it is not minimal, but it is already heavily reduced from the original code and has only standard header dependencies. To reproduce the problem: g++ -fPIC -O0 ~/dbg.cpp ; ./a.out 1 g++ -fPIC -O3 ~/dbg.cpp ; ./a.out 0 g++ -fPIC -O3 ~/dbg.cpp -DSCITBX_MAT3_TRACE_SIMPLE ; ./a.out 1 g++ -O3 ~/dbg.cpp ; ./a.out 1 The output should be 1 in all cases. The error occurs in the rot_mx::type() function near the end of the reproducer. Inserting std::cout statements in this function makes the error go away. Therefore I don't know what exactly is going wrong. By chance I noticed that the SCITBX_MAT3_TRACE_SIMPLE change (see code) also works around the problem. However, the trace() function always works if called directly. I noticed the error the first time on Dec 29, 2006 under 32-bit Fedora 6. Therefore I believe it is not Fedora 4 or 6 specific, but a general 32-bit optimizer problem. The gcc svn versions from Dec 29 and Jan 22 both work flawlessly on a 64-bit platfrom (Fedora 5). I hope you can take it from here. Let me know if you need any other information. -- Summary: -fPIC -O3 optimizer bug (32-bit target only) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com 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=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #1 from rwgk at yahoo dot com 2007-01-24 00:10 --- Created an attachment (id=12945) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12945action=view) standalone reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug bootstrap/29382] New: Bootstrap comparison failure!
Platform info: Red Hat Enterprise Linux WS release 3 (Taroon) Linux legless 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686 i686 i386 GNU/Linux g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) gcc SVN snapshot: 2006-10-07 10:14 PDT Commands used: ../gcc_trunk/configure --prefix=/some/path --enable-languages=c,c++ make bootstrap End of make bootstrap output: Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/net/legless/scratch1/rwgk/gcc_build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/net/legless/scratch1/rwgk/gcc_build' make: *** [bootstrap] Error 2 Comments: I had the same problem with the SVN snapshot from 2006-09-21 22:03 PDT. Both SVN snapshots work without a problem under Fedora Core 5 x86_64. -- Summary: Bootstrap comparison failure! Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com 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=29382
[Bug c++/28003] New: optimizer bug
I will attach a small reproducer. /* Reproducer for optimizer bug in gcc svn trunk revision 114570 (as checked out 2006_06_12_0834 PDT) To produce correct output: g++ -Wall -O0 gcc_trunk_2006_06_12_0834_fc5_x86_64.cpp ./a.out To see the bug: g++ -Wall -O1 gcc_trunk_2006_06_12_0834_fc5_x86_64.cpp ./a.out Note the difference in the last line of the output: Correct: 1 0 0 Incorrect: 0 0 0 The output is also incorrect for -O2 and -O3. The last line of the output is correct if compiled with: g++ -Wall -O1 -DBAD_WORKAROUND gcc_trunk_2006_06_12_0834_fc5_x86_64.cpp ./a.out Platform: Fedora Core release 5 (Bordeaux) Linux rosie.lbl.gov 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006 x 86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch1/rwgk/gcc_trunk/configure --prefix=/usr /local_cci/gcc_trunk_2006_06_12_0834_fc5_x86_64 --enable-languages=c,c++ Thread model: posix gcc version 4.2.0 20060612 (experimental) */ -- Summary: optimizer bug Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug c++/28003] optimizer bug
--- Comment #1 from rwgk at yahoo dot com 2006-06-12 19:28 --- Created an attachment (id=11656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11656action=view) short reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug c++/19317] [4.0/4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From rwgk at yahoo dot com 2005-03-24 12:46 --- Using the latest CVS: gcc version 4.0.0 20050324 (prerelease) My reproducer attached to this report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19603 is still failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug c++/19603] New: code generation error
gcc CVS mainline, 2005/01/23 12:10 PST
Configured with: /net/legless/scratch1/rwgk/gcc_cvs_head/configure --
prefix=/usr/local_cci/gcc_cvs_head_20050123 --enable-languages=c,c++
Red Hat Enterprise Linux WS release 3 (Taroon)
Boost CVS mainline, 2005/01/06 10:09 PST
The following piece of code works correctly only if CCTBX_GCC4_WORKAROUND is
defined:
rt_mx rt_mx::new_denominators(int r_den, int t_den) const
{
rt_mx result(*this);
#ifndef CCTBX_GCC4_WORKAROUND
if (r_den) result.r_ = result.r_.new_denominator(r_den);
#else
if (r_den) {
rot_mx r = result.r_.new_denominator(r_den);
result.r_ = r;
}
#endif
if (t_den) result.t_ = result.t_.new_denominator(t_den);
return result;
}
A reproducer is available here:
http://cci.lbl.gov/~rwgk/bugs/gcc_cvs_head_20050123/gcc4_debug.tar.gz
To build:
gunzip -c gcc4_debug.tar.gz | tar xf -
cd gcc4_debug
make
Expected output:
g++ -fPIC -ftemplate-depth-120 -w -DBOOST_DISABLE_THREADS -DNDEBUG -O3 -ffast-
math -I. -c gcc4_debug.cpp
g++ -fPIC -ftemplate-depth-120 -w -DBOOST_DISABLE_THREADS -DNDEBUG -O3 -ffast-
math -I. -c cctbx.cpp -o cctbx_normal.o
g++ -o normal gcc4_debug.o cctbx_normal.o
g++ -fPIC -ftemplate-depth-120 -w -DBOOST_DISABLE_THREADS -DNDEBUG -O3 -ffast-
math -I. -DCCTBX_GCC4_WORKAROUND -c cctbx.cpp -o cctbx_hacked.o
g++ -o hacked gcc4_debug.o cctbx_hacked.o
This will only take a few seconds to build the commands normal and hacked.
The expected output is:
./normal
y,z,x
x,y,z
./hacked
y,z,x
y,z,x
The output of ./normal is wrong, the output of ./hacked is correct. The only
difference is the CCTBX_GCC4_WORKAROUND.
The same code works fine (without the workaround) with gcc 3.2.3 and many other
compilers.
I will try to attach the reproducer if possible. It still is 877kB in size,
starting from 15+MB, mainly because of the Boost headers. I spent several hours
stripping it down to this size. I hope you have tools to reduce the rest much
faster.
--
Summary: code generation error
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwgk at yahoo dot com
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=19603
[Bug c++/19603] code generation error
--- Additional Comments From rwgk at yahoo dot com 2005-01-24 11:49 --- Created an attachment (id=8052) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8052action=view) Reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19603
[Bug c++/19297] New: Internal compiler error when compiling Boost.Python test
gcc CVS mainline, 2005/01/06 09:53 PST Configured with: /net/legless/scratch1/rwgk/gcc_cvs_head/configure -- prefix=/usr/local_cci/gcc_cvs_head_20050106 --enable-languages=c,c++ Red Hat Enterprise Linux WS release 3 (Taroon) Boost CVS mainline, 2005/01/06 10:09 PST % g++ -I/net/legless/scratch1/rwgk/hot/boost -I/usr/include/python2.2 - E /net/legless/scratch1/rwgk/hot/boost/libs/python/test/bienstman1.cpp bienstman1_pp.cpp % g++ -c bienstman1_pp.cpp Lots of output ending with: /net/legless/scratch1/rwgk/hot/boost/boost/python/detail/destroy.hpp:33: internal compiler error: in create_tmp_var, at gimplify.c:368 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The same code compiles with gcc 3.2.3 on the same machine. I will attach the preprocessed source code. The same file is also available here: http://cci.lbl.gov/~rwgk/bugs/gcc_cvs_head_20050106/bienstman1_pp.cpp.gz -- Summary: Internal compiler error when compiling Boost.Python test Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com 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=19297
[Bug c++/19297] Internal compiler error when compiling Boost.Python test
--- Additional Comments From rwgk at yahoo dot com 2005-01-06 19:40 --- Created an attachment (id=7885) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7885action=view) Preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19297
[Bug c++/19298] New: Error compiling Boost.Python test
gcc CVS mainline, 2005/01/06 09:53 PST Configured with: /net/legless/scratch1/rwgk/gcc_cvs_head/configure -- prefix=/usr/local_cci/gcc_cvs_head_20050106 --enable-languages=c,c++ Red Hat Enterprise Linux WS release 3 (Taroon) Boost CVS mainline, 2005/01/06 10:09 PST % g++ -I/net/legless/scratch1/rwgk/hot/boost -I/usr/include/python2.2 - E /net/legless/scratch1/rwgk/hot/boost/libs/python/test/args.cpp args_pp.cpp % g++ -c args_pp.cpp Lots of output ending with: /net/legless/scratch1/rwgk/hot/boost/boost/python/object/make_ptr_instance.hpp:4 5: error: request for member ‘get_class_object’ in ‘boost::python::converter::detail::registered_baseconst volatile Y::converters’, which is of non-class type ‘const boost::python::converter::registration’ The same code compiles with gcc 3.2.3 on the same machine. I will attach the preprocessed source code. The same file is also available here: http://cci.lbl.gov/~rwgk/bugs/gcc_cvs_head_20050106/args_pp.cpp.gz -- Summary: Error compiling Boost.Python test Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com 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=19298
[Bug c++/19298] Error compiling Boost.Python test
--- Additional Comments From rwgk at yahoo dot com 2005-01-06 19:49 --- Created an attachment (id=7886) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7886action=view) Preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19298
[Bug c++/19298] Error compiling Boost.Python test
--- Additional Comments From rwgk at yahoo dot com 2005-01-06 19:51 --- Date: Thu, 06 Jan 2005 14:24:06 -0500 From: David Abrahams Ralf W. Grosse-Kunstleve wrote: Hi David, To ensure that Boost.Python will work with gcc 4 I've checked out the latest gcc cvs today, along with the latest boost cvs. There are lots of errors when compiling the Boost.Python tests, but as far as I can tell only two types of errors. One is an internal compiler error, i.e. there is no question that I have to file a bug report for this one. However, I am not sure about the second one. Could you please have a look? Raw error message: http://cci.lbl.gov/~rwgk/bugs/gcc_cvs_head_20050106/error_which_is_of_non_ class_type Same but processed with gSTLFilt.pl: http://cci.lbl.gov/~rwgk/bugs/gcc_cvs_head_20050106/error_which_is_of_non_ class_type_stlfilt That's not much help, is it!? If you think it is a gcc 4 problem rather than a boost problem I'll file a bug report. Well, let's see. I think you can do this analysis yourself, FWIW: /net/legless/scratch1/rwgk/hot/boost/boost/python/object/make_instance.hpp:63: error: request for member M-CM-M-bM-^BM-,M-KM-^\get_class_objectM-CM-M-bM-^B M-,M-bM-^DM- in M-CM-M-bM-^BM-,M-KM-^\boost::python::converter::detail::registered_baseconst v olatile Y::convertersM-CM-M-bM-^BM-,M-bM-^DM-, which is of non-class type M-CM-M-b M-^BM-,M-KM-^\const boost::python::converter::registrationM-CM-M-bM-^BM-,M-bM-^DM- It seems to be claiming that the static registration const member named converters of registered_baseY const volatile Doesn't have class type. Clearly wrong. I mean, it's a reference to an object of class type, but for all purposes other than initialization you can do the same things with that as you can do with a class instance. Thanks! Ralf BTW: Do you know what to make of the strange characters (e.g. M-CM-M-bM-^BM-, M-bM-^DM-)? GCC bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19298
[Bug c++/19297] [4.0 Regression] rejects valid code when compiling Boost.Python test
--- Additional Comments From rwgk at yahoo dot com 2005-01-06 19:57 --- --- Additional Comment #2 From Andrew Pinski 2005-01-06 19:45 [reply] --- Looks like there are two bugs here ... I've opened another bug report for the second error: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19298 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19297
