Date: Fri, 22 Jun 2012 18:54:00 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: Why Clang Message-ID: <201206222354.q5MNs09A044205@mail.r-bonomi.com> In-Reply-To: <alpine.BSF.2.00.1206221624390.27991@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <wojtek@wojtek.tensor.gdynia.pl>
> To: Robert Bonomi <bonomi@mail.r-bonomi.com>
> 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.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206222354.q5MNs09A044205>