From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8933 invoked by alias); 11 Aug 2010 21:27:39 -0000 Received: (qmail 8864 invoked by uid 48); 11 Aug 2010 21:27:27 -0000 Date: Wed, 11 Aug 2010 21:27:00 -0000 Message-ID: <20100811212727.8863.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "redi at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00897.txt.bz2 ------- Comment #34 from redi at gcc dot gnu dot org 2010-08-11 21:27 ------- (In reply to comment #25) > In other words my code is not portable because GCC is not doing what it should. > GCC causes code not to be portable a lot of times, like in the following case > (which does not compile because of GCC's shortcommings): > > class Temp { > public: > Temp(int b); > Temp(Temp& t); > void operator=(Temp& t); > }; > > void func(int a, class Temp& b, int c); > > func(10, Temp(20), 30); // error ISO/IEC 14882:2003(E) 8.5.3 [dcl.init.ref] paragraph 5 > This code does not compile in GCC, and so is not portable. That's shortcomming > of GCC that makes my code be not portable, not me. Its GCC's fault that code > that invokes Temp(20) as a parameter is not portable, not the programmer's > fault. ibid. > Unfortunately, conversations like this one show that GCC will never be perfect, > because people like you will insist that the compiler doesn't need to do what I > said it should (even when facing the obvious references that I've posted), and > prove that page 70 is right about warning programmers not to rely on compilers > to do correct parameter placements. What a charming idea, that a compiler could become perfect by doing "what I said it should" > My personal experience is that GCC is the cause for such portability problems. > You still insist that GCC doesn't need to improve in this respect, and that > shows why GCC will never be as good as other compilers. Microsoft, for example, > appreciates comments like mine because it helps them improve the product, but > you just want to dismiss it as bad code on my part. I know Microsoft's people > get paid to do so, but, still, I'm talking about the right mind set. Oh, how delightfully quaint! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249