/home/dave/gnu/gcc-4.3/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc-4.3/objdir/./ prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/ -c -g -O2 -DIN_GC C -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definiti on -Wmissing-format-attribute -Werror -DOBJCPLUS -I../../gcc/gcc/objc -I../../gc c/gcc/cp -fno-common -DHAVE_CONFIG_H -I. -Iobjcp -I../../gcc/gcc -I../../gcc/g cc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../g cc/gcc/../libdecnumber -I../libdecnumber -I. -Iobjcp -I../../gcc/gcc -I../../ gcc/gcc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I.. /../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/objc/objc-act.c -o o bjcp/objcp-act.o cc1: warnings being treated as errors ../../gcc/gcc/objc/objc-act.c: In function 'lookup_method_in_protocol_list': ../../gcc/gcc/objc/objc-act.c:570: error: comparison is always false due to limi ted range of data type ../../gcc/gcc/objc/objc-act.c: In function 'lookup_protocol_in_reflist': ../../gcc/gcc/objc/objc-act.c:598: error: comparison is always false due to limi ted range of data type ../../gcc/gcc/objc/objc-act.c:605: error: comparison is always false due to limi ted range of data type ../../gcc/gcc/objc/objc-act.c: In function 'generate_protocol_references': ../../gcc/gcc/objc/objc-act.c:4443: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'generate_protocol_list': ../../gcc/gcc/objc/objc-act.c:5457: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:5465: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:5478: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:5487: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'synth_id_with_class_suffix': ../../gcc/gcc/objc/objc-act.c:5834: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'build_keyword_selector': ../../gcc/gcc/objc/objc-act.c:5910: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:5930: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'build_method_decl': ../../gcc/gcc/objc/objc-act.c:5967: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'get_arg_type_list': ../../gcc/gcc/objc/objc-act.c:6003: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'check_duplicates': ../../gcc/gcc/objc/objc-act.c:6087: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:6093: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'receiver_is_class_object': ../../gcc/gcc/objc/objc-act.c:6115: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'build_ivar_reference': ../../gcc/gcc/objc/objc-act.c:6714: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'objc_add_method': ../../gcc/gcc/objc/objc-act.c:6979: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'conforms_to_protocol': ../../gcc/gcc/objc/objc-act.c:7294: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'check_protocol': ../../gcc/gcc/objc/objc-act.c:7384: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'synth_self_and_ucmd_args': ../../gcc/gcc/objc/objc-act.c:8319: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'really_start_method': ../../gcc/gcc/objc/objc-act.c:8602: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8637: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8644: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8667: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'get_super_receiver': ../../gcc/gcc/objc/objc-act.c:8714: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8736: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8750: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'objc_lookup_ivar': ../../gcc/gcc/objc/objc-act.c:9428: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:9440: error: comparison is always false due to lim ited range of data type make[3]: *** [objcp/objcp-act.o] Error 1 make[3]: *** Waiting for unfinished jobs....
Occurs in stage2. dave@mx3210:~/gnu/gcc-4.3/objdir/prev-gcc$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --prefix=/home/dave/opt/gnu/gcc/gcc-4.3.0 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++,objc,fortran,java,obj-c++,ada Thread model: posix gcc version 4.3.0 20070310 (experimental)
The limit on the number of tree codes is reached (LAST_CPLUS_TREE_CODE = 251, LAST_OBJC_TREE_CODE = 262).
Subject: Re: [4.3 Regression] Objective-C++ has ran into the tree number limit > ---------------------------------------------------------------------------- > Summary|objc-act.c:570: error: |[4.3 Regression] Objective- > |comparison is always false |C++ has ran into the tree > | |number limit Don't like to name people, but I suppose this patch should be reverted: 2007-03-09 Douglas Gregor <doug.gregor@gmail.com> PR c++/20599 * typeck.c (check_return_expr): Check for bare parameter packs. (comptypes): Compare template parameter packs and type pack expansions. ... Dave
(In reply to comment #3) > Don't like to name people, but I suppose this patch should be reverted: Please, please, don't do that! Instead, let's solve the real issue with the tree-codes limit once and for all, because sooner or later we have to do that anyway (as Rth, among others, also maintained time ago, in the occasion of the GOMP additions)
Subject: Re: [4.3 Regression] Objective-C++ has ran into the tree number limit > > Don't like to name people, but I suppose this patch should be reverted: > > Please, please, don't do that! Instead, let's solve the real issue with the > tree-codes limit once and for all, because sooner or later we have to do that > anyway (as Rth, among others, also maintained time ago, in the occasion of the > GOMP additions) I recognize that the patch contains a very significant body of work. I also realize that the tree code limit needs fixing. However, that may require a significant increase in memory for trees. That's why I added the comment. It's not fair to trade one feature for another (variadic templates for obj-c++). There's been no discussion on the impact of fixing the tree code limit. I note that a 15% compile time memory usage regression, <http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00652.html>, would be considered a release blocker. The patch was obviously not fully tested, or the problem was overlooked. As a backend maintainer, I've seen build and check times grow substantially with every new release. So, I'm highly suspicious of the process used to introduce major new features. The tree code limit should have been fixed first. Dave
> It's not fair to trade one feature for another (variadic templates > for obj-c++). I agree. > There's been no discussion on the impact of fixing the tree code limit. > I note that a 15% compile time memory usage regression, > <http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00652.html>, > would be considered a release blocker. By the way, that issue has been already analyzed and seems solvable rather easily, Doug is working on it with Richard' help. > The patch was obviously not fully tested, or the problem was overlooked. > As a backend maintainer, I've seen build and check times grow substantially > with every new release. So, I'm highly suspicious of the process used > to introduce major new features. The tree code limit should have been > fixed first. Yes, you have a point. But now, since because of our "lazyness" we never managed to attack the tree code limit, let's take this "crisis" as an occasion to do that, or at least let's try to our best, instead of reverting completely Doug' work, which is incredibly important for our implementation of C++0x features and, I would say, gives GCC a great competitive advantage.
Even though Objective-C++ is not a release blocker, it would be nice for all of the C++ patches to test with objective-C++ on and really that should be a requirement. I rather see Objective-C++ working than C++0x. The features that C++0x give are not as good as the features give by Objective-C++ in my mind. Though the objective-C++ can reduce the number of tree codes it uses, the number will only be by like 2-3. Objective-C++ uses only 10 extra tree codes about C++ so really C++ is going to hit the limit soon if we are not careful anyways. Also adding new features should not break old features so Doug in my mind you should revert your patch in 48 hours if you cannot fix it by then, I requesting this as the GNU libobjc maintainer.
(In reply to comment #7) > Also adding new features should not break old features Here we are not talking about trade-offs, that should be rather clear by now. We are talking about fixing for real the underlying very serious issue with the tree code limit which otherwise blocks development in many new areas. Temporarily, Doug can well revert his patch but the limit **must** be removed anyway.
This problem has been solved by 16-bit tree codes: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01721.html