From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15514 invoked by alias); 12 Jan 2004 21:34:20 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 15507 invoked by uid 48); 12 Jan 2004 21:34:19 -0000 Date: Mon, 12 Jan 2004 21:34:00 -0000 Message-ID: <20040112213419.15505.qmail@sources.redhat.com> From: "cgl20 at cam dot ac dot uk" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040112202443.13661.cgl20@cam.ac.uk> References: <20040112202443.13661.cgl20@cam.ac.uk> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/13661] Internal compiler error in c_expand_expr, at c-common.c:3714 X-Bugzilla-Reason: CC X-SW-Source: 2004-01/txt/msg01297.txt.bz2 List-Id: ------- Additional Comments From cgl20 at cam dot ac dot uk 2004-01-12 21:34 ------- (In reply to comment #2) > I could not confirm this at all on 3.2.3 or 3.3.1, are you sure that you sent the right preprocessed > source file? I have a little more to report. Since my last posting, I have attempted to narrow down the bug a little. I have fixed (hopefully all of) the bad code in the example pps.c++.gz supplied above, until there is only one line remaining that causes the problems. I have not uploaded this "corrected" code, but I will try to do later if I get the time or if others request it. Anyway, the end result is that the problem line (expected to be bad code) seems to be this one: const bool alterationsNecessitateCompleteRecalculation = ( typeid(firstAlteration) == typeid(AlterationsT::AlterationsNecessitateCompleteRecalculation) ); [Just "zgrep -B2 AlterationsT::AlterationsNecessitateCompleteRecalculation" in the supplied gz file, and you should see the above.] Now that all the other bugs are fixed, I find that I can elicit three types of behaviour from the compiler depending on subtle variations to the line above. Consider the following variants for the argument to the SECOND typeid(), in which I have abbreviated AlterationsT::AlterationsNecessitateCompleteRecalculation to "XXX". /* A: */ typeid( typename XXX () ); // FINE /* B: */ typeid( typename XXX ); // FINE /* C: */ typeid( XXX () ); // BAD CODE REPORTED /* D: */ typeid( XXX ); // Internal Compiler Error In the above cases, options A and B compile fine, presumably as one would hope! Option C (also rightly, presumably) does not compile and the compiler reports the messages reproduced at the foot of this reply. Option D, which corresponds to the state of the code in the form in which I originally sent it, (and which is presumbaly also Bad Code), is the one that causes the Internal Compiler Error as previously described. This seems to be an ICE on bad code of the above form. ------ option C error message ------------ /var/pcce/usera/lester/mycmt/Rich/RichMarkovRingFinder/v1r0/src/finder/RichStuff.tcc: In static member function `static double Lester::RichStuff::totalLogProb(const Lester::RichParams&, const Lester::Data&, const Lester::Alterations&) [with Mode = Lester::Rich2Configuration, const Mode&mode = Lester::globalRich2Configuration]': /var/pcce/usera/lester/mycmt/Rich/RichMarkovRingFinder/v1r0/src/finder/MyRichMetropolisSampler.h:60: instantiated from `double Lester::MyRichMetropolisSampler::logTargetDistribution(Lester::RichSpace::PointType&) const [with Mode = Lester::Rich2Configuration, const Mode&mode = Lester::globalRich2Configuration]' /var/pcce/usera/lester/mycmt/Rich/RichMarkovRingFinder/v1r0/src/MarkovChainSampler/MarkovChainSampler.h:30: instantiated from here /var/pcce/usera/lester/mycmt/Rich/RichMarkovRingFinder/v1r0/src/finder/RichStuff.tcc:69: invalid use of member `class Lester::Alterations::AlterationsNecessitateCompleteRecalculation ' gmake[3]: *** [../rh73_gcc32dbx/MarkovTest.o] Error 1 gmake[2]: *** [MarkovTest] Error 2 gmake[1]: *** [common_target] Error 2 gmake: *** [MarkovTest] Error 2 pccn:cmt> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13661