LWN: Comments on "Building the whole Debian archive with GCC 4.1: a summary"

Building the whole Debian archive with GCC 4.1: a summary

JoeBuck — Wed, 29 Mar 2006 18:33:16 +0000

As you say, the ISO standard came out in 1998 (it was actually complete in December 1997, and only details have changed since draft standards put out in 1996). You've had more than eight years to fix your code.

Unfortunately, g++ 2.x accepted all kinds of bizarre stuff, and broke on all kinds of standard C++. The GCC developers made the decision to follow the standard. Unfortunately, too many folks in FLOSS-land never used any compiler other than g++, and never cracked a book on C++, so they just threw stuff at the compiler and accepted whatever the compiler let through. That was never a wise strategy.

C++ is the most complex of the widely used languages, and is hard to get right. Generally speaking, GCC has done very well, considering the massively difficult challenges.

There are a few cases where I would agree that GCC 4.1 is a bit too anal-retentive. However, for most of the cases that affect Debian code this is not the issue: if the compiler does not properly enforce the namespace rules, valid C++ programs break (because of name collisions or selecting the wrong overloaded function), and the only way to fix the breakage is to make changes that cause invalid programs that used to compile, to stop working.

Building the whole Debian archive with GCC 4.1: a summary

butlerm — Wed, 29 Mar 2006 14:19:05 +0000

I should substitute "let the construct suffer in benign neglect" for "declare the result to be undefined". GCC has added an option (-Wno-invalid-offset-of) that eliminates the need for class data member offset gymnastics as well.

wrong about offsetof()

butlerm — Wed, 29 Mar 2006 05:25:51 +0000

Sorry - I meant C++ classes in general, not PODs.

Building the whole Debian archive with GCC 4.1: a summary

butlerm — Wed, 29 Mar 2006 05:22:39 +0000

This is not something that just accidentally happened to work. The ISO C++ standard was not released until 1998. C++ had a 15 year history prior to that, and taking the offset of a class member was universally portable prior to that time.

But somehow, perhaps in a fit of Java envy, the ISO C++ folks decided that the C++ language should define an virtual abstraction far removed from its origins as a system programming language, and forbade perfectly well defined behavior. Not just declared the result to be "undefined" as sane standards bodies are wont to do, but forbade its use outright, breaking a large body of existing code.

And as one might expect, there is now speculation that the next version of the ISO C++ standard will remove this ridiculously pointless restriction.

C++ error FAQs a great service

vladimir — Wed, 29 Mar 2006 02:57:09 +0000

> Certainly, recompiling an entire distro is no fun.

Pshaw! We Gentoo folks are used to recompilation! I'm looking to move to GCC 4.1 this weekend, so I'm going to recompile my entire distribution. I suspect that most everyone who migrates to GCC 4.1 will do the same.

P.S. OK, OK. I'm not recompiling an *entire* distribution, just the ~2000 packages I have installed.

P.P.S. I think that Martin Michlmayr did a HUGE favor to the GNU community. Heartfelt thanks!

C++ error FAQs a great service

steven97 — Tue, 28 Mar 2006 20:49:00 +0000

Seconded. This is a really useful and interesting investigation. I wish GCC would receive this kind of testing more often.

C++ error FAQs a great service

bkoz — Tue, 28 Mar 2006 17:24:26 +0000

This was a nice contribution by the Debian community: I applaud them for their efforts. Certainly, recompiling an entire distro is no fun.

The thing I liked most about this are the public web pages that have been created that explain the differences between gcc-3.x and gcc-4.x. The previous examples that did this (ie kegel) were not as good IMHO as the new ones produced by this exercise.

- http://womble.decadentplace.org.uk/c++/syntax-errors.html
- http://womble.decadentplace.org.uk/c++/template-faq.html

In my experience it is this kind of timely reporting and instruction that users most desire WRT gcc documentation, and which the gcc team usually fails to deliver. (As they are working on the compiler/runtimes.)

If only the FSF or google would hire these C++ jocks to do this with every release! Whoo hoo.

Great job Debian/Google/Broadcom.

-benjamin

MIPS CPUs from Broadcom

smoogen — Tue, 28 Mar 2006 17:12:27 +0000

I think it is a problem with any group of more than 100 people that does not have good internal communication tables. I have seen so many times where 3 groups will do exactly the same project but did not communicate it until they were ready to produce it which usually meant that all 3 would then get into a fight about how to do it best... trying to put them onto the same lists usually resulted in the same lovefests that you see when you stick OpenBSD, FreeBSD, and NetBSD people on the same list (or say KDE and Gnome people). Sometimes it works out but the core philosophies/values that some people have are hard to get past.

MIPS CPUs from Broadcom

dmarti — Tue, 28 Mar 2006 17:11:41 +0000

If it helps you at all in your efforts for there to be a conference about doing hardware support the Linux way, and the ease and advantages thereof, please feel free to put yourself down for FreedomHEC and invite your Broadcom contacts too. The "year without a Christmas" is the perfect time to reach hardware people, IMHO.

Building the whole Debian archive with GCC 4.1: a summary

foo-bar — Tue, 28 Mar 2006 15:00:27 +0000

For example, the ISO C++ people, in their infinite wisdom, decided that anything resembling an offsetof() was to be illegal in C++ in all circumstances, breaking both C compatibility and a *large* body of C++ code. Granted offsetof() is not particularly well defined in cases where there are multiple base classes, but since when is a "C" style language the arbiter of correct programming practice?

GCC does have various extensions to ISO standard. These extensions are well documented and were added intentionally. Apparently offsetof(non-POD) didn't deserve to become an extension and hence was removed.

All I can say is it is unusually irritating for GCC to disallow what used to be perfectly legal idiom with well defined semantics and then not provide some sort of backward compatibility option or other work around.

Anything that is not spelled in the ISO standard and is not defined as GCC extension is illegal by the definition. The fact that it worked doesn't make it a "legal idiom". Writing such code is a mistake that the author is solely responsible for, and nobody has any moral obligation to provide any work arounds not even talking about backward compatibility which implies allowing illegal idioms in the future.

IMHO :-)

MIPS CPUs from Broadcom

tbm — Tue, 28 Mar 2006 11:17:01 +0000

Actually, it's a little bit more tricky than that. Broadcom has two different MIPS based lines. There's the SB1 core which, like you said, comes from SiByte. These target the higher end networking range, e.g. switches. There's the 1250 CPU with 2 cores and the 1480 with 4 cores. These chips are really expensive so you don't find them in any consumer devices.

Additionally, there's their low-end CPU line, the 47xx/5xxx line. These run at 150-300 MHz, are very cheap and you can find them everywhere, e.g. in lots of wireless routers. Some of these devices will make an excellent platform to run Debian on.

While the SB1 people at Broadcom get it, the same doesn't apply to the latter group (which, apparently, isn't just one group, but split again into different groups depending on the market segment they focus on). SB1 support is fairly well done and integrated into mainline, but the 47xx/5xxx support is based on 2.4 and is the usual badly hacked support which cannot be integrated (lots of platform independent code so you can share it between Linux and other OSes, files with unclear copyright statements). It's a big mess.

The OpenWRT people have started on a 2.6 implementation but it still includes quite a bit of the Broadcom code and therefor cannot be integrated into the kernel. Yet... my evil plan is to get Thiemo Seufer, a MIPS hacker and Debian developer, and some other hackers one of those routers and then they'll hopefully fix up the code and get it merged into the kernel.

I tried contacting the 47xx/5xxx people at Broadcom but have failed so far. The SB1 people also don't seem to have very good contacts with them. The problem of big corporations, I guess. But I'll continue trying...

Building the whole Debian archive with GCC 4.1: a summary

amcrae — Tue, 28 Mar 2006 10:42:39 +0000

>Thou as I heard infamous WLAN of theirs still got no public documentation... Go figure.
The Broadcom CPU folks are an acquisition (Sibyte originally). I had many dealings with them both pre and post acquisition, and the CPU folks have always had a strong open source policy. This is, of course, only sensible when you are trying to establish a CPU product in a mostly embedded market.
As opposed to WLAN chips aimed at a PC market.
The fact that the CPU stuff was an acquisition is probably the source of the different policies. It can surprise some people that large/largish companies can have seemingly conflicting policies with different products, but it does often happen.

Building the whole Debian archive with GCC 4.1: a summary

philips — Tue, 28 Mar 2006 08:47:12 +0000

Several propritary drivers I've seen from Broadcom for Linux had only partial Broadcom copyright. And they were *really* old. And ported from some funny OSs/architectures. I doubt you would wanted such drivers. Even for free.

With the hardware I worked, Broadcom was providing complete documentation for free - so I had no problems developing drivers for Linux.

Thou as I heard infamous WLAN of theirs still got no public documentation... Go figure.

wrong about offsetof()

philips — Tue, 28 Mar 2006 08:40:53 +0000

Yeah, I had some fun with that too.

People love to use inheritence with structures and then claim that it's perfectly Okay C (since no classes) code...

Building the whole Debian archive with GCC 4.1: a summary

tbm — Tue, 28 Mar 2006 07:31:42 +0000

Donated by Broadcom, a large company with different policies. This board is fully supported by the Linux kernel through work done by Broadcom and others.

Building the whole Debian archive with GCC 4.1: a summary

BrucePerens — Tue, 28 Mar 2006 07:27:53 +0000

Donated by Broadcom, the no-source driver folks???

wrong about offsetof()

JoeBuck — Tue, 28 Mar 2006 05:23:34 +0000

ISO C++, and GCC, allow offsetof() for C-style structs (PODs - plain old data types). It does not allow offsetof() for arbitrary C++ classes.

Building the whole Debian archive with GCC 4.1: a summary

butlerm — Tue, 28 Mar 2006 04:41:22 +0000

All I can say is it is unusually irritating for GCC to disallow what used to be perfectly legal idiom with well defined semantics and then not provide some sort of backward compatibility option or other work around.

For example, the ISO C++ people, in their infinite wisdom, decided that anything resembling an offsetof() was to be illegal in C++ in all circumstances, breaking both C compatibility and a *large* body of C++ code. Granted offsetof() is not particularly well defined in cases where there are multiple base classes, but since when is a "C" style language the arbiter of correct programming practice?

GCC adopted this rule in the 3.x series, and it takes an unusual amount of obfuscation to persuade the compiler to calculate the proper offset without triggering an error. If it were a trivial syntax change - no problem - but instead they removed what should be a fundamental capability of any low level or systems programming language.