Hello Arpi,
Monday, May 28, 2001, 1:38:52 PM, you wrote:
A> Hi,
>> > "Comment on the accusations of Red Hat Linux 7.x using a buggy or not
>> > standards compliant compiler"
>> >
>> > http://www.bero.org/gcc296.html
>>
>> Nice I'm sure gcc296 does a lot of things better, but once they are
>> failing to compile correct C++ code those improvements are useless.
>> And there was nothing wrong with libmpeg_audiodec.
A> There is a simple, short MMX yuv->rgb converter code in libmpeg2, it's
A> also bad with 2.96. gcc 2.96 simply _left_out_ the half of the asm code,
A> without any warning or other message. So we can consider it's buggy.
I think that you might be interested in the following dialogue, which
happened this weekend. I don't have backup copies of my emails, but
there's enough quoted to understand what we are talking about...
----------------------------------------------------------------
>From [EMAIL PROTECTED] Sun May 27 11:58:27 2001
Received: from wg.redhat.de ([193.103.254.4] helo=mail.redhat.de)
by mail1.chat.ru with esmtp (Exim 3.22 #14)
id 153vRT-000Hd9-00
for [EMAIL PROTECTED]; Sun, 27 May 2001 11:58:27 +0400
Date: Sun, 27 May 2001 09:58:16 +0200 (CEST)
From: Bernhard Rosenkraenzer <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Your comment on gcc 2.96 on divx.euro.ru
Message-ID: <[EMAIL PROTECTED]>
X-Spam-From: abuse@localhost
X-Spam-To: [EMAIL PROTECTED]
X-Subliminal-Message: Microsoft sucks! Update your system to Linux today!
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
you must be referring to a very very old version of gcc 2.96 - your code
compiles without modifications or other tweaks with the version that comes
with Red Hat Linux 7.1, and the version released as an errata for 7.0
some months ago.
It is probably true that our "marketing strategists" don't know about the
reasons - because it was a development decision, not a marketing ploy.
Marketing stays out of the development department. See
http://www.bero.org/gcc296.html for the details, and please fix up the
comment.
LLaP
bero
>From [EMAIL PROTECTED] Sun May 27 15:20:23 2001
Received: from wg.redhat.de ([193.103.254.4] helo=mail.redhat.de)
by mail1.chat.ru with esmtp (Exim 3.22 #14)
id 153yat-000HJX-00
for [EMAIL PROTECTED]; Sun, 27 May 2001 15:20:23 +0400
Date: Sun, 27 May 2001 13:20:22 +0200 (CEST)
From: Bernhard Rosenkraenzer <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: Your comment on gcc 2.96 on divx.euro.ru
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
X-Spam-From: abuse@localhost
X-Spam-To: [EMAIL PROTECTED]
X-Subliminal-Message: Microsoft sucks! Update your system to Linux today!
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 27 May 2001 [EMAIL PROTECTED] wrote:
Hello,
> I am absolutely positive that I am referring to the version of gcc which comes
> with RH 7.1.
This is odd, because it works here.
I've actually just tried to compile it on a 7.0 box without updating the
compiler, and it worked, as well.
One thing I did have to do though was updating to SDL 1.2.0 (I'm running
SDL 1.2.0 on my 7.1 box, as well) - maybe avifile doesn't work with the
combination of SDL 1.1.x and gcc 2.96? This could be possible because gcc
2.96 is way more strict about prototypes differing from declarations.
> I read this document long time ago ( actually, before I decided to put that
> comment on the site ), and I completely disagree with it.
> It actually claims that 'there are areas where 2.96 is better than 2.95'. Ok,
> maybe there are. Maybe C++ code compiled by 2.96 is 5% faster than when
> compiled by 2.95.3
The bigger difference is that a lot of valid C++ code that didn't compile
with 2.95.3 at all (because it's a horribly buggy C++ implementation) works
with 2.96. The optimizations are just an extra plus.
> I'm not arguing with this statement. Maybe it is more compliant with
> standards. But the thing is, most programmers do not write code which
> is compliant with ISO standards. What they do is they write code which
> is compliant with COMPILERS.
True - and that's why the compilers need to enforce ISO standards. If they
don't, you'll run in trouble as soon as someone tries to compile your code
with a different compiler.
This is not important in a world where everyone uses gcc, but
unfortunately that's only a small part of the world.
We received a number of inquiries from companies that wanted to port their
code from Windows, Solaris, or HP/UX to Linux, but couldn't, because egcs
1.1.x and gcc 2.95.x didn't understand the constructs they've used. Those
have stopped with 2.96.
> Unless you are super genius and have 15
> years of experience in C++, you can't write 20k lines of code and
> claim 'this code is completely compliant with C++ ISO standard',
> without even trying to compile it.
This is true - but once you have a compliant compiler, you can check the
code.
Almost all of the code that doesn't compile with 2.96 anymore was bad in
the first place (see the examples on bero.org/gcc296.html - I'm sure
you'll agree most of them are bad code; yet those are the things almost
all gcc "bugs" reported to us come down to.
> That's why every time you include
> an unstable development snapshot of C++ compiler into new release of
> your distro,
It is not an unstable development snapshot. We took an unstable
development snapshot and took about 5 months to stabilize it for the
initial version. For the current version, it's an unstable development
snapshot with 13 months of stabilizing work.
> you force thousands of programmers around the world to
> make their code compatible with your newly-invented C++ standard,
We didn't invent the standard. ISO did, and other compilers (Sun, HP,
Microsoft, Borland) implemented it first.
And once gcc 3.0 is released (probably in June or July this year),
everyone will have to adapt the code anyway. 3.0 is even less permissive
than 2.96.
> ands, more importantly, with bugs of your compiler.
Name one.
We're not aware of any bugs in the current version of 2.96 (2.96-85) on
x86. There are still 2 known bugs in the Alpha CPU backend, but even those
are removed in our tree by now.
> Note that the problem which is mentioned on the site is
> caused by a _bug_ of 2.96.whatever.
Please send me more details if you still think it's a bug in the compiler.
Since I can't reproduce it, I think it's a bug in obsolete versions of
SDL.
>From [EMAIL PROTECTED] Mon May 28 01:12:06 2001
Received: from wg.redhat.de ([193.103.254.4] helo=mail.redhat.de)
by mail1.chat.ru with esmtp (Exim 3.22 #14)
id 1547pW-000A4p-00
for [EMAIL PROTECTED]; Mon, 28 May 2001 01:12:06 +0400
Date: Sun, 27 May 2001 23:12:05 +0200 (CEST)
From: Bernhard Rosenkraenzer <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: Your comment on gcc 2.96 on divx.euro.ru
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
X-Spam-From: abuse@localhost
X-Spam-To: [EMAIL PROTECTED]
X-Subliminal-Message: Microsoft sucks! Update your system to Linux today!
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hello,
> >This is odd, because it works here.
> >I've actually just tried to compile it on a 7.0 box without updating the
> >compiler, and it worked, as well.
>
> Yes, it was already made compatible with bugs of compiler from 7.0. And it's
> really odd that it works for you on 7.1.
Can you show me what you did to work around bugs? If there are any bugs
left, they need to be fixed, and I'd like to make sure they are.
> >One thing I did have to do though was updating to SDL 1.2.0 (I'm running
> >SDL 1.2.0 on my 7.1 box, as well) - maybe avifile doesn't work with the
> >combination of SDL 1.1.x and gcc 2.96? This could be possible because gcc
> >2.96 is way more strict about prototypes differing from declarations.
>
> The problem has nothing to do with SDL.
Then I can't explain why it worked on my systems (and in our official
build environment).
> >The bigger difference is that a lot of valid C++ code that didn't compile
> >with 2.95.3 at all (because it's a horribly buggy C++ implementation) works
> >with 2.96. The optimizations are just an extra plus.
>
> I wouldn't call it 'horribly buggy'. During a year that I spent
> writing avifile, I met only one bug in 2.95. Probably you know better.
Ok, let me rephrase: 2.95.3 is a nice compiler, but it's not a C++
compiler. ;)
g++ in 2.95.3 compiles a language that resembles C++ (a subset of C++
with a couple of misinterpretations of standards and a couple of
extensions), and handles that language quite well, but if you want a C++
compiler, 2.95.3 is buggy.
2.96 is still not complete (that's why it's not yet 3.0), but it's much
more complete than earlier versions.
> Besides, I doubt that you can find a single Linux program in the world
> which would compile with 2.96, but not with 2.95.
Depends on what you count.
Some CVS versions of glibc 2.2.3 didn't compile with 2.95, some CVS
snapshots of lilo-config in KDE's CVS tree didn't compile with 2.95.
Workarounds were added in the CVS trees a couple of days later by people
running older compilers, so the code didn't make it into the release
versions.
And that's mostly because there was no compiler accepting new code until
recently - if gcc 1.0 had had a typo requiring people to write pryntf()
instead of printf() and they had kept if up until 2.95, most code would
still write pryntf() just because it's what people are used to - even
though it's not right.
> >We received a number of inquiries from companies that wanted to port their
> >code from Windows, Solaris, or HP/UX to Linux, but couldn't, because egcs
> >1.1.x and gcc 2.95.x didn't understand the constructs they've used. Those
> >have stopped with 2.96.
>
> The right thing to do would be to forward these inquiries to gcc
> developers and expect the problems to be fixed in 3.0.
That's basically what we did. 2.96 *is* taken from the branch that that
will be 3.0, and the standards enforcement things were in before we
created our own branch. It wasn't our idea.
> Unless you care about these companies more than about OSS community, of course...
We care about having a fast and standards compliant compiler for both the
OSS community and the companies. (And one that handles all CPUs we support
- try generating Itanium (ia64) binaries with 2.95.x).
> >> That's why every time you include
> >> an unstable development snapshot of C++ compiler into new release of
> >> your distro,
> >
> >It is not an unstable development snapshot. We took an unstable
> >development snapshot and took about 5 months to stabilize it for the
> >initial version. For the current version, it's an unstable development
> >snapshot with 13 months of stabilizing work.
>
> Hmmm, 'we'? I thought I was talking with RedHat employee? Or are you
> also one of primary gcc developers?
I'm not, but Jakub Jelinek, Richard Henderson, Jason Merrill and some
other people on our team are.
The stabilization was done by Red Hat, mostly by our gcc people, and all
the fixes were immediately contributed back to the gcc 3.0 branch, which
is why the release will be about half a year earlier than the FSF
originally planned.
> >> you force thousands of programmers around the world to
> >> make their code compatible with your newly-invented C++ standard,
> >
> >We didn't invent the standard. ISO did, and other compilers (Sun, HP,
> >Microsoft, Borland) implemented it first.
> >And once gcc 3.0 is released (probably in June or July this year),
> >everyone will have to adapt the code anyway. 3.0 is even less permissive
> >than 2.96.
>
> The 'standard' I'm talking about is an ISO standard in implementation of gcc
> 2.96.
That was already in the 3.0 branch (which is where 2.96 originated) months
before we created the 2.96 branch.
> >> ands, more importantly, with bugs of your compiler.
> >
> >Name one.
> >We're not aware of any bugs in the current version of 2.96 (2.96-85) on
> >x86. There are still 2 known bugs in the Alpha CPU backend, but even those
> >are removed in our tree by now.
> >
>
> There are bugs by definition. If there weren't any, this version would be
> already released as 'gcc 3.0' or at least 'gcc 2.98'.
Let me rephrase: We're not aware of any bugs in the current version of
2.96 that are not present in all earlier versions, as well.
The C++ implementation is still not complete, just more complete.
> Reference to generate() from subbandsynthesis() is the only one
> reference to this function in the whole project. However, attempt to
> link this code on RedHat 7.1 fails with 'undefined reference to
> Mpegtoraw::generate()'.
I can't reproduce this on my system (granted, it's somewhat post-7.1), so
either this is caused by something else or it was fixed between 2.96-81
and 2.96-85.
I'll try compiling this on a stock 7.1 system when I have the time. (I
don't have a stock 7.1 system ATM).
LLaP
bero
--
Best regards,
Eugene
mailto:[EMAIL PROTECTED] or [EMAIL PROTECTED]
[Team GADGET] [Team Two Divided By Zero] [Team Hackzone.ru]
NetZero Platinum
No Banner Ads and Unlimited Access
Sign Up Today - Only $9.95 per month!
http://www.netzero.net
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
