about gcc >=4.2 in base

[Ole]

Hello!

Somewhere in the internet i reading that newer of gcc (>4.2) in the future is not will be placing to FreeBSD base system and instead of gcc will switching to pcc (http://en.wikipedia.org/wiki/Portable_C_Compiler). If the true - what reason for that?

[arust]

Maybe BSD License is a better choice in open source movement, instead of GNU General Public License

[artificer]

I remember seeing a relevant thread in one of the mailing lists.

It seems that GCC 4.2.1 is here to stay, due to the FreeBSD team's strong distate of the GPL v3 license, and the fact that 4.2.1 was the last GCC version licensed with GPL version 2.

[Oko]

Hello!

Somewhere in the internet i reading that newer of gcc (>4.2) in the future is not will be placing to FreeBSD base system and instead of gcc will switching to pcc (http://en.wikipedia.org/wiki/Portable_C_Compiler). If the true - what reason for that?

Short answer is very many reasons.

GCC has a very poor quality of code and poor over all design.
It is tightly control via proxy developers by industry monopolies.

GCC has been known for lack of will to hear any suggestion from
people coming with academic background (BSD, MIT license people).

GCC has dropped support for many chip architectures making almost impossible to use on anything else except i386 and amd64.

GCC is also bloated as actually many compilers in one.

GCC is very slooooow.

GCC is over optimized producing the poor quality code.

It has bad license.


On the another hand PCC is the relict of the past. It is written
by a research mathematician who was interested in designing best possible compiler. It is released around 2000 under BSD license
by commercial Unix vendor and resurrected by one of the brightest NetBSD/OpenBSD people Anders Magnusson.
It was default compiler of BSD Unix until
4.4 BSD Light. It is C only compiler of exceptionally clean design and code. It is extremely fast. Probably 10 faster than gcc. It is extremely small. It is extremely portable to any chip-set architecture. It is not fully optimized yet so it produces somewhat slower code than gcc but it has a far grater potential for optimization than gcc can dream of.

[trasz@]

First, FreeBSD is not switching to PCC. At least I don't know anything about that. LLVM would be a better choice. ;-)

Second - yes, GCC has its problems. And versions above 4.2 have more restrictive license than versions before. So it's possible that it wont be upgraded for some time, I don't know.

Anyway - if you need a newer GCC, just install it from ports. It's there, whatever version you want, from gcc 2.8.1, up to 4.4.0, snapshot from 20081121.

[Oko]

LLVM would be a better choice. ;-)

That is so wrong on many levels!!!

[Djn]

That is so wrong on many levels!!!


Compared to gcc, it's got cleaner code, a better architecture, and a more BSD-ish license. Any issues with speed (of both the compiler and the binaries) can be sorted.

So why the aggression?

[trasz@]

In addition to all that, it has strong support from the industry, Apple in particular. And very effective optimizer.

[Oko]

Compared to gcc, it's got cleaner code, a better architecture, and a more BSD-ish license. Any issues with speed (of both the compiler and the binaries) can be sorted.

So why the aggression?
Because PCC is better compiler. I could ask the same question you. What is wrong with you FreeBSD guys? Firstly that c*** with SVN instead of OpenCVS now LLVC instead of PCC. What is next?
Linux kernel and ALSA?
It is sad what is happening with FreeBSD since Matt Dillon left the project. If DragonFly just had enough human power you would see what is FreeBSD done right. Just compare Hummer and ZFC and you will know what I am talking about.

[trasz@]

Because PCC is better compiler. I could ask the same question you. What is wrong with you FreeBSD guys? Firstly that c*** with SVN instead of OpenCVS now LLVC instead of PCC. What is next?
Linux kernel and ALSA?


Let's stick to technical arguments. What _exactly_ does PCC do better than LLVM?

[Oko]

Let's stick to technical arguments. What _exactly_ does PCC do better than LLVM?

How about if you read documentation first

http://pcc.ludd.ltu.se/

and then you ask me which parts I really like.

In the mean time I am reading documentation for LLVM

http://llvm.org/

and I will put you a long list of things I dislike about it
from the technical point of view of course. Then we can compare the notes;).

Let me start with few things. LLVM is based on GCC and written in C++. Just the last thing is enough in my book. Having any code on Unix except pure C is wrong not because of ideology but because C++ is ill conceived language as all objected programming. Now unless you come up with OS written in assembly
or in ADA the buck stops with C. Now, I might be unlucky and you might be the developer of Kolibri OS for all I know but I suspect not since you are writing from Poland not Russia.

[Ole]

Hello,

Thanks in the first to trasz for unrolled answer to my question. I be afraid that gcc >4.2x will be not accessibility in FreeBSD.

Now it become to very interesting and cognitive discussion. I want to asking about
First, FreeBSD is not switching to PCC. At least I don't know anything about that. LLVM would be a better choice. ;-)


The direction therefrom for moving to LLVM for base FreeBSD compiler is already selected ? if and when plan to move to another compiler is already be, like similar discussion must be somewhere places. I googled only this mail discussion http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-05/msg00237.html.

[Oko]

Hello,

Thanks in the first to trasz for unrolled answer to my question. I be afraid that gcc >4.2x will be not accessibility in FreeBSD.

Now it become to very interesting and cognitive discussion. I want to asking about


The direction therefrom for moving to LLVM for base FreeBSD compiler is already selected ? if and when plan to move to another compiler is already be, like similar discussion must be somewhere places. I googled only this mail discussion http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-05/msg00237.html.

Nobody ever said anything about GCC not being accessible. GCC will always be available from ports on any flavor of *BSD. The heated discussion we are having is about compiler in the base.

I, as most OpenBSD/NetBSD and I hope DragonFly BSD people believe that there the base should contain nothing but superb pure C compiler (even though there is PCC version for Fortran).
It is possible to compile entire kernel and most of userland of OpenBSD as well as NetBSD with PCC. The only significant part of userland which can not be compiled is Groff (written in C++) and guess what? Groff is going down too. If SUN releases Heirloom troff under BSD (currently is CDDL) it is likely to be imported
into the base of OpenBSD otherwise there are free versions of Roff and people already working on beefing them up. One of those free versions was part of Minix.

So do not worry abut GCC. It is here to stay. The question is can we do better than that and not just little bit. Can we do much better than that. That is what all *BSDs are about. BSDs are about pushing limits of computing. That is way there is not one but four different BSD flavors because each one is pushing in very different direction. Friendly exchange that we are having is also part of BSD academic culture.

[trasz@]

The direction therefrom for moving to LLVM for base FreeBSD compiler is already selected ? if and when plan to move to another compiler is already be, like similar discussion must be somewhere places. I googled only this mail discussion http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-05/msg00237.html.

No. There is nothing "selected" right now. I don't think FreeBSD is going to switch to anything other than GCC at least in the next year.

Second - FreeBSD is not a company. It's not like we have our bosses from the core team say "ok, this thing here is wrong, replace it with this one". It's a community process. Basically, some day it will happen that various people on the mailing lists start talking about moving to another compiler _again_, but this time they reach some conclusion. At least some of them. Then somebody else will post patches, that will get talked about again, more people will reach agreement, HEADSUP will be posted and the change will go in. It will take _many_ months from the discussion to the actual commits.

[trasz@]

I, as most OpenBSD/NetBSD and I hope DragonFly BSD people believe that there the base should contain nothing but superb pure C compiler (even though there is PCC version for Fortran).

It may be a shock to you, but I actually like some C++ features, like STL - sane implementation of strings is a good thing to have. But i digress.

The root clause of disagreement here is that you are looking from an idealistic standpoint, while I'm looking from a practical one. We are not developing the compiler. We don't want to. If somebody wants to do this, both LLVM and PCC projects are open and ready to accept patches. In the base system, we want to _use_ the compiler. It doesn't matter what language it's written in (except that the base needs to be 'self contained', i.e. it must be possible to recompile itself without any external software, which means it needs to include the compiler and all its dependancies). What matters is that the compiler generates good object code, supports architectures that we support, produces useful diagnostic messages, and it's useful for something else than the base system itself, so that users don't need to install another compiler from ports when they want to compile something.

[Oko]

The root clause of disagreement here is that you are looking from an idealistic standpoint, while I'm looking from a practical one.

Well said. I can sign that statement.

We are not developing the compiler.
We don't want to.
On the another hand OpenBSD/NetBSD are developing new compiler;)

[dap]

How about if you read documentation first

http://pcc.ludd.ltu.se/

and then you ask me which parts I really like.

I couldn't find what it supports from C99, do you know that ?

[Oko]

I couldn't find what it supports from C99, do you know that ?

Final goal is to support 100% C99. I am not sure in how many percentage support right now but as I said earlier it can compile kernel of OpenBSD an all of userland except Groff (C++) with only couple patches added to OpenBSD. OpenBSD will have entire tool chain based on its own code hopefully within next two years. That would decrease the size of present OpenBSD installation from around 550MB (including X org, all services and utilities including Apache server) to about 300MB. When Groff gets replaced we are going probably to 200-250MB range. That is almost DSL babe;)

People who tried to use GCC on non Wintel architectures will really appreciate new PCC. If ever had to compile something on SGI or Motorolla you will know what I am talking about.
Only GCC<3.0 works on those architectures and only with patches.
These architectures are very important for the debugging the
code and security enhancement. Since FreeBSD in practical sense supports only i386, amd64, pc98 I can see why FreeBSD guys see no
need for new compiler.

[Djn]

I'll have to disagree with one thing:
The only GCC code in LLVM is the frontend. Since the backend is independent, and they have their own alternative frontend (clang) that's supposedly more or less C99-ready, it's somewhat wrong to say that it's "based on GCC".

Granted, it'll need the gcc frontend to compile C++ (and thus itself) until clang does C++ well, and that could take years. They shouldn't have to sync it with the current gcc version especially often, though, so it should be able to avoid GPLv3.

[trasz@]

Since FreeBSD in practical sense supports only i386, amd64, pc98 I can see why FreeBSD guys see no
need for new compiler.

You seem to have a little distorted view. :-)

Right now architectures that are both critical, well-maintained and very actively developed in FreeBSD are i386, amd64, ARM and MIPS. Another important target - which basically works, but doesn't seem as actively developed in the FreeBSD - is PowerPC. Keep in mind that embedded is very important for us, since that is where much (most?) of the money come from (think Nokia or Juniper). Yet another target, that is not as crucial as some time ago, but still works quite nicely (at least on Ultra 5), is sparc64. Compiler that is expected to replace GCC must support these - otherwise we would need to keep two compilers in the base.

[trasz@]

Granted, it'll need the gcc frontend to compile C++ (and thus itself) until clang does C++ well, and that could take years.

Given how Apple needs it for Xcode, I think we can expect usable results earlier. ;-)

[Oko]

You seem to have a little distorted view. :-)

Right now architectures that are both critical, well-maintained and very actively developed in FreeBSD are i386, amd64, ARM and MIPS. Another important target - which basically works, but doesn't seem as actively developed in the FreeBSD - is PowerPC. Keep in mind that embedded is very important for us, since that is where much (most?) of the money come from (think Nokia or Juniper). Yet another target, that is not as crucial as some time ago, but still works quite nicely (at least on Ultra 5), is sparc64. Compiler that is expected to replace GCC must support these - otherwise we would need to keep two compilers in the base.

That is not what your web-site is saying. I listed Tier one architectures from your web-site. So you are saying that support for PC98 is dropped as well.

I do know that most embedded devices are ARM and MIPS based (probably 80% of the entire chip market are chips for embeded devices)
but I am not embedded device guy so I went with what you web-site is saying.

Your support for MIPS64 (SGI) hardware is non existing. You seems to be very proud of your support sparc64 so I hate to burst
your bubble. OpenBSD is the only operating system other than Solaris which support UltraSPARC IV/T1/T2 and Fujitsu SPARC64-V/VI/VII chip-sets. Last time I tried to use FreeBSD on Sparc it was chocking on Blade 1000. We are talking about 5 year old Blades here. I had Ultra 5 as my Unix workstation in mid 90s. Do you honestly thing of that as something which has any value outside of museum ;)?

Do you support SMP on sparc64;)?

What do you mean by PowerPC (IBM) or old Apple lagacy hardware? The second
one is irrelevant.

[trasz@]

That is not what your web-site is saying. I listed Tier one architectures from your web-site. So you are saying that support for PC98 is dropped as well.

No. It's just I can't say anything about PC98 because, frankly, I have never seen machine that implements it. It seems that's it being kept up to date with i386, but I have no way to say how things look like here.

Your support for MIPS64 (SGI) hardware is non existing.

Nobody cares about SGI MIPS machines anymore. And I say that as a proud owner of Indigo 2. FreeBSD PowerPC support is important for the embedded sector.

You seems to be very proud of your support sparc64 so I hate to burst
your bubble. OpenBSD is the only operating system other than Solaris which support UltraSPARC IV/T1/T2 and Fujitsu SPARC64-V/VI/VII chip-sets. Last time I tried to use FreeBSD on Sparc it was chocking on Blade 1000. We are talking about 5 year old Blades here. I had Ultra 5 as my Unix workstation in mid 90s. Do you honestly thing of that as something which has any value outside of museum ;)?

I'm a computer history hobbyist. I really like old machines. However, I like them in their original form, with their original operating systems. Blade 1000 is great for Solaris, but for FreeBSD... Well, i I need FreeBSD, I just get an amd64 machine, either a "physical" or a virtual one.

[Kitche]

I been playing around with LLVM and I must say I like it I might try compiling the FreeBSD sources with it using another OBJDIR so I do not mess up my already compiled sources with GCC. I'll tell you how it goes when I get it finished.

[Kitche]

well llvm-gcc compiles some of world then errors out at /usr/src/lib/fasm or close to that did this last night so I need to rerun the make buildworld to make sure.

[Oko]

People who were curious about PCC are welcome to test it

http://undeadly.org/cgi?action=article&sid=20090104030528

[Oko]

The compiler is almost production ready for i386 architecture:).

[morbit]

Is there any chance of introducing -march=core2 to FreeBSD base compiler?

[oliverh]

The compiler is almost production ready for i386 architecture:).

What production? Probably userland in OpenBSD.

[estrabd]

GCC 4.2.1 supports OpenMP, as slow as the generated executable is. Would this be something that the replacement compiler should support since SMP is so important now more than ever?

[Oko]

What production? Probably userland in OpenBSD.
You can compile kernel as well if you apply couple patches which I think are already in current:). In my understanding the only thing in the base of the OpenBSD which can not be compiled is obviously Groff since PCC is C only compiler and Groff is C++.
There is a lengthy discussion on undeadly.org/ about Groff "problem". It is too bad that Heirloom Troff has CDDL license but Nroff used by Minix has BSD license. There is also
MirBSD version of Nroff which has BSD license. I have also heard of one of your fellow Germans working on the Troff "problem" for OpenBSD as we speak;)

[estrabd]

I waited a few days and there are no comments regarding my question about OpenMP support. See 2 comments above.

Thanks

[susanth]

...hand OpenBSD/NetBSD are developing new compiler;)

May i know the name of that new compiler please. (OR is it PCC itself ? )
Any URL or project home page.

Thanks in advance

[joel@]

May i know the name of that new compiler please. (OR is it PCC itself ? )
It's PCC.

[Oko]

GCC 4.2.1 supports OpenMP, as slow as the generated executable is. Would this be something that the replacement compiler should support since SMP is so important now more than ever?
The short answer is I do not know.

The longer one is that if I have to guess support for OpenMP is
very, very low priority. The most important thing from the point of view of OpenBSD/NetBSD community is for PCC to generate correct, efficient, and small machine serial code. It is also very important that PCC is very portable as well that it has clear separation of front and back ends which will enable creation of some very interesting new tools for debbuging and code analysis. One of high priorities of PCC is to create so
efficient machine code that it could be executed theoretically on
PDP-11 as well as on the newest SUN blade.

Generating parallel machine code would add another layer of complexity and insecurity. SMP support is only moderately important at least for OpenBSD and it will remain like that probably for the very long time. Multi core CPUs are still very buggy and in some sense even dangerous from the security point of view.

I hope that somebody with greater technical knowledge of the issues would comment on your interesting question.

[Djn]

Interesting developments on CURRENT:


Hi,


Clang is a new frontend for C-like languages for LLVM. It's modern, BSD
licensed compiler that produces roughly the same code quality or better
as GCC. It's still in its development phase but quite mature. It includes
static analyzer as well.

And yes, it can compile FreeBSD kernel that actually boots and works. Not
as stable as GCC yet but the Clang team is working on that. The userland
needs some more work but a lot works already.

You can try yourself, the details are described here:


http://wiki.freebsd.org/BuildingFreeBSDWithClang


basically you just install devel/llvm-devel port, compile the kernel with -O1
and boot. Don't forget to try out the static analysis.

We'd like to encourage you to try this out and test stuff. We can't test
everything. In a case of problems (there sure will be) please contact me or
Pawel.

thank you!

your clang@freebsd team

Roman Divacky, Pawel Worach and Brooks Davis

[morbit]

Nevermind, delete.

[gnemmi]

... We are not developing the compiler. We don't want to... .

If we are not developing the compiler (PCC) but OpenBSD/NetBSD, which have a lot less resources than we do are ... what's the really good reason we are not pitching in?

OpenBSD/NetBSD are working on PCC
DragonFlyBSD is working on HAMMER and dma
OpenBSD keeps working on OpenSSH and is working on OpenSMTPD, OpenNTPD, OpenCVS, etc ..

and while they, with the limited resources they have (special mention goes to DragonFlyBSD) keep pushing the limits of Computer Science .. we are porting ZFS and Dtrace ...?

I think I'll be cancelling my FreeBSD subscription and start buying OpenBSD CDs and donating money to DragonFlyBSD ...

They make Computer Science keep walking and they need my money a lot more than Sun does ...

[Oko]

DragonFlyBSD is working on HAMMER and dma

If Matt Dillon can really pull up native kernel support for clustering DragonFly will by far the most interesting Open Source project.

[gnemmi]

If Dillon can pull that .. he would be taking CS to the next step ...

BTW ... I just found out that:
As you may have read some days ago, work has started to make the FreeBSD base system compile better with clang, the BSD licensed C compiler from the LLVM project.

and that:

After some talking on IRC, I think the best solution would be to rename all functions in libmp. Even though this may sound very awful at first, it seems the competition has done this as well:
http://docs.sun.com/app/docs/doc/819-2246/mp-3mp?a=view


Here's the original: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-February/027833.html

So .. I guess we seem to be competing with SUN instead of contributing to the development of BSDs ..

If I wanted to use Microsoft Word/IE/OutLook, or play games on my PC .. I'd be using Microsoft Windows ...

If I wanted to use Quick Look, iChat, Safari or benefit from Time Machine or Finder .. I'd be using Mac OS X

... and just in case I wasn't clear enough .. if I wanted to use OpenSolaris .. I would be using OpenSolaris ... not FreeBSD

I just want to use and contribute to the development of BSD systems in order to keep pushing the limits of CS ... instead of economically contributing to the cooking of a new product.

If FreeBSD chooses to turn into a SUN competitor instead of a BSD contributor, then I guess there's no more room for me amongst it's lines.

[Djn]

Reinventing the wheel is pushing the borders of CS? Uhm, what?
The Dragonfly clustering work might be impressive (we'll see when it becomes usable), but it' not exactly a new idea. As examples, there are VMS clusters out there that have uptimes comparable to the age of the FreeBSD project, and plan 9 can share the oddest things over the network. I do hope it will work out; it would be a nice addition. But it's not taking anything to "the next level".

FreeBSD needed a new better FS. We found a good tested one developed by someone with an interest in getting it right, and imported it. Huge value for the time spent.
The main focus of recently seems to have been on scaling nicely over many cores on a single computer. It doesn't sound as impressive, but it's no less useful for that.

[Oko]

there are VMS clusters out there that have uptimes comparable to the age of the FreeBSD project, and plan 9 can share the oddest things over the network. I do hope it will work out; it would be a nice addition. But it's not taking anything to "the next level".

On AIX as well. Do you have five million dollars for a solid IBM server? I didn't think so. Of course the most thing we are talking about were done or started 20 years ago on proprietary Unix. The problem is that in the mean time most of them went bankrupt and people are reinventing the wheel all the time on i386.

Tell me a single innovation that came out of Linux. Nothing, absolutely nothing after so much money spend by major corporations. In the mean time SUN made some major innovations. Like DTrace or ZFC for instance and SUN is dying.

[Djn]

That's a reasonable summary, yes. And that's why I'm quite happy that FreeBSD is adopting technologies from Sun - they're good solid ideas that it would be a shame to see die.

How is the clustering support in solaris, by the way? I don't mean that we should import it from them (clustering sounds like the kind of technology that's far too integrated to easily separate & port), but it would be a cheaper alternative to AIX/OpenVMS/the like if it's any good.

[Mel_Flynn]

Coming in late - I only see idealistic arguments against FreeBSD's course, "contributing to *BSD's", "pushing the limits of CS", "C++ in an OS is crap".
While these are valid points, they shouldn't be a deciding factor in any OS that wants to be used in production environments. While a lot of donations to FreeBSD come from embedded products, it's usage ranges from desktop, webserver, storage unit to firewall/router. In those environments, nobody cares about the footprint of an install CD, language used for a compiler, or whether new innovations have been made. The important points are SMP, network and IO throughput, disk management, ease of software and OS maintenance and mainstream hardware support. Of these, only the last has declined.
In the end, I wouldn't care if FreeBSD shipped a binary compiler by default and kept the sources in perforce, saves me quite a few stages during buildworld. I also don't care if my filesystem is a "lame port" or "impressive innovation", ultimately, I need my data to be safe, read and written fast and resistant to hardware failures.

I certainly welcome a new compiler, if it means faster code and it's license doesn't restrict my usage of it (in that order). Yet, it's not on my FreeBSD wish list as I can get by without one on production machines, by using freebsd-update and pkg_add or a buildserver and nfs. And there's far more pressing issues (usb2, anyone sick of Xorg yet?, lagg(4)+WPA+hostap, to name a few).

[estrabd]

The short answer is I do not know.

The longer one is that if I have to guess support for OpenMP is
very, very low priority. The most important thing from the point of view of OpenBSD/NetBSD community is for PCC to generate correct, efficient, and small machine serial code. It is also very important that PCC is very portable as well that it has clear separation of front and back ends which will enable creation of some very interesting new tools for debbuging and code analysis. One of high priorities of PCC is to create so
efficient machine code that it could be executed theoretically on
PDP-11 as well as on the newest SUN blade.

Generating parallel machine code would add another layer of complexity and insecurity. SMP support is only moderately important at least for OpenBSD and it will remain like that probably for the very long time. Multi core CPUs are still very buggy and in some sense even dangerous from the security point of view.

I hope that somebody with greater technical knowledge of the issues would comment on your interesting question.

I agree that one needs to crawl before he walks. I would like to point out that OpenMP is a standard supported by all of the major HW snf compiler vendors (often one and the same), and GNU supports this.

http://openmp.org/wp/openmp-compilers/

For example, IBM's XL suite has provided a "thread safe" version (*_r) if their compilers (as well as their own MPI libraries for distributed memory environments) by default on their power series machines for sometime; granted, my experience in seeing this has been isolated to HPC environments; so it's a virtually a requirement to provde this.

*However*, OpenMP is only one threading library that IBM's XL suite does (or intends) to support - *so,* given IBM's approach (i.e., a distinclty separate "thread safe" version of each compiler), maybe the same approach can be taken /once/ an initial switch is made - there is no immediate reason that any new base compiler needs to support these things. It could be a concurrent effort once things are settled. After all, I would assume that GCC >= 4.2.1 will most likely still be available via packages. That said, a thread-safe version of any base compiler would be nice - not only for testing base SMP installations, but also for eventual (and fairly easy) utilization of such capabilities in the base code itself.

I would also like to note that I am playing around with a couple of simple codes that are meant to help me evaluate FreeBSD's SMP progress, and they all use OpenMP as supported by the current base compiler - GCC 4.2.1. I think it is incredible that the base compiler does support OpenMP, so it makes sense to center some basic testing around it.
Cheers

[wsw1wsw2]

OpenBSD will have entire tool chain based on its own code hopefully within next two years.


What do you mean "entire tool chain" ? OpenBSD's own as(assembler) instead gas ? OpenBSD's own ld(link editor) instead GNU's version? Or just PCC instead gcc ?