From owner-freebsd-questions@FreeBSD.ORG Fri Jun 22 23:53:41 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A93321065672 for ; Fri, 22 Jun 2012 23:53:41 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFD28FC16 for ; Fri, 22 Jun 2012 23:53:41 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id q5MNs09A044205 for freebsd-questions@freebsd.org; Fri, 22 Jun 2012 18:54:00 -0500 (CDT) Date: Fri, 22 Jun 2012 18:54:00 -0500 (CDT) From: Robert Bonomi Message-Id: <201206222354.q5MNs09A044205@mail.r-bonomi.com> To: freebsd-questions@freebsd.org In-Reply-To: Subject: Re: Why Clang X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 23:53:41 -0000 > From wojtek@wojtek.tensor.gdynia.pl Fri Jun 22 09:26:33 2012 > Date: Fri, 22 Jun 2012 16:25:55 +0200 (CEST) > From: Wojciech Puchar > To: Robert Bonomi > cc: freebsd-questions@freebsd.org > Subject: Re: Why Clang > > > Because it doesn't address an of the *OTHER* valid reasons why GCC is > > being replaced -- among them: > > 1) GCC's continuously increasing propensity to generate "bad code", > > examples? All test shows that gcc code is not only bad, but very good. YOU ARE A LIAR. The _only_thing *you* measure by is 'speed'. You don't understand what the words "bad code" means -- that it has *nothing* to do with how fast the code executes.. Despite the fact I explicitly described what I was talking about -- and that you intentionally removed that description. > Why are you just saying things you know isn't true? Why are you just _lying_ trollbiu? Just because _you_ haven't seen it doesn't mean it's not true. I *KNOW* it is true -- I've been bitten by GCC bad code _multiple_ times, and in multiple ways, in application code. Problems in O/S internals are much more common. I've had segfaults in code that couldn't _POSSIBLY_ segfault. An example of the _kind_ of thing that has blown up: int foo() { int a,b,c[10]; b=2; a=c[b]; /* dies here with a segfault */ } running in the debugger confirms b has the correct value just before the statement assigning a value to a. issue a 'next' command in the debugger, and you get a segfault. printing the value of 'b' shows it is 2. Disassembling the machine code shows that the WRONG REGISTER is used to calculate the effective address of the array element. It's clearly a bug in the optimizer -- I'd be surprised if it showed in that 'minimal' illustrative code. When I've gotten bit, it was a 1,000+ LOC module. I've also seen it use machine 'loop' instructions with the DF flag set wrong. > > 2) The inability of GCC mamintainers to fix _long-standing_ bugs, some > > have been identified for over a decade, and have not been fixed. > > That's true. still not that much. Your opinion of the seriousness doesn't count. Those of us who have had to 'code raround' those bugs for years and years have a _very_ different opinion. > > 3) The continuously increasing trend of introducing 'non standard' features, > No need to use them. Trollboi shows he doesn't know what he doesn't know, yet again. Some of them _conflict_ with STANDARD C. Thus 'standards-compliant' C source does 'something else', when compiled with GCC. The FSF thinks 'their way' is "better", and have no intention of changing. >