Contributed by jose on from the new-compilers dept.
CVS archive
It was my impression that the OpenBSD developers was none to happy with newer gcc than 2.95 due to slow compile times."
This may make upgrading interesting ...
(Comments are closed)
OpenBSD Journal
Contributed by jose on from the new-compilers dept.
It was my impression that the OpenBSD developers was none to happy with newer gcc than 2.95 due to slow compile times."
This may make upgrading interesting ...
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Anonymous Coward () on
Comments
By DIGITALMAN () on
By thuglife () thuglife@bsd.hu on mailto:thuglife@bsd.hu
Comments
By Anonymous Coward () on
By Jedi/Sector One () j@pureftpd.org on http://www.skymobile.com/
By raiten () julien.touche@lycos.com on mailto:julien.touche@lycos.com
seems they are preparing a switch (some cvs log pointing warning/error find with gcc3 in base tree before)
that's why there is no new snapshots since Nov 1 ?
also want to know, what was the deciding point to switch
review from gcc summit point compilation time will be improved with 3.4 (mainly with precompiled headers) but 3.3 is only about speed of generated code.
note: for now, i believe FreeBSD5, netbsd-current, debian/unstable has switch to gcc3.2 and the others bsd seems to want to switch quickly to 3.3
Comments
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
the day the switch is done and the cvs mail
arrives in my inbox, no sooner.
I think they are going to import the amd64
port, which needs this obviously.
I've still got problems with propolice on 3.2.3
and 3.3.x though :-(
Comments
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
By dan () on
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
By the 9th goblin () on
http://www.topica.com/lists/inferno/read/message.html?mid=807659608
They are based in the Plan9 compilers by Ken God Thompson and it would be great if OpenBSD dumped that GCC abomination and used the best (Ken's)C compilers ever created...
Of course there will always be assholes that think that GCC's "features" are "useful"... oh, well, for them there will always be Lunix and GNU/TURD
-- the 9th goblin
Comments
By Scott () on
I really wish that companies that want to open up their source use an EXISTING "Open Source" license (i.e. GPL or BSD), rather than try to be cute and come up with their own.
Comments
By Anonymous Coward () on
I absolutely agree in the point about reusing exsisting licenses instead of creating your own... but oh well... as I said, IMHO it's way better than the GPL.
-- the 9th goblin
Comments
By markus () on
like 8c & friends will not
become BSD licensed.
Comments
By the 9th goblin () on
If there is a problem with vita's compilers license I'd like to know, as I know some people near vita that were quite enthusiastic about OpenBSD using the compilers, but probably it might be more useful to contact Forsyth directly.
-- the 9th goblin
Comments
By Anonymous Coward () on
too or is it like Tendra that only works for a few
platforms?
I dont think anyone in the openbsd camp would settle
for a compiler that made 75%+ of their platforms not
being able to use it.
Comments
By Anonymous Coward () on
The compilers were designed to be *fast*(build a complete plan9 system in 20 sec!) and portable, according to Ken a port to a new arch(including assembler) was estimated to take 2 weeks.
-- the 9th goblin
Comments
By Anonymous Coward () on
in my experience I have found that not all C is created equal in the eyes of a compiler
Comments
By goblin () on
See http://www.vitanuova.com/inferno/papers/compiler.html
it's a bit outdated(it's from early 90ies), but will give you an idea.
-- the 9th goblin
Comments
By Anonymous Coward () on
By Anonymous Coward () on
...if the compiler was under an acceptable license of course.
Comments
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
The kernel relies on embedded assembler in
critical parts, and those are a bitch to switch.
And fixing all those pesky little reliance on gcc stuff does take time, as we've noticed again and again: each compiler update makes us change a few details.
Lately, GCC has been geared towards more standardization. Thus, specific gnu features get deprecated, or are gone. Most of these are dead easy to fix, a few are not.
Some examples:
- automatic include path guessing. Gone from gcc3. Requires about ten Makefiles in src to change.
- K&R and ANSI prototypes mixes. GCC has some magic to make some K&R declarations work when they shouldn't. I was wondering why wdc was working, until Miod Vallat pointed the magic to me. If you remove that magic, you need to finish ansification of that code.
WRT C++, for better or for worse, most people need it. groff notwithstanding, there is a large number of programs in the ports tree that lots of people use.
Comments
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
using 4.4BSD-Alpha nroff several times, and am still
willing to have it going into stock OpenBSD.
I've not ported troff and eqn, and called neqn eqn,
when I started it because I knew nothing about *roff,
but plan to change that.
Some tools are missing, but I can not format papers
to text files with multiple columns, using col.
By markus () on
to try.
Being a plan9 user for years,
i'd like to see 8c in OpenBSD. The
code is portable and already compiles
on OpenBSD, but we won't switch
to a non-BSD licensed compiler.
Comments
By Anonymous Coward () on
Is it not possible to get someone to agree to license it under the LPL and then relicense it under BSD per term 3?
If so I can try to get my university to do such.
By Anonymous Coward () on
Plan9 is amazing piece of OS and their code would be such great contribution from Lucent.
Lets hope Vita Nuova can learn from Lucent mistakes and do the right thing.
Btw Im about to order it to take a look, but money concurrency bites soo hard... :D
By grey () on
That said, I would say that in the case of that compiler, license is one of the biggest hurdles for serious contemplation; whereas Theo's opinions on Tendra seem to indicate that tcc's adoption would likely never occur.
If memory serves, Theo and others have voiced gripes about gcc 3.x with regards to its optimization techniques being counter productive to some of the compiler targetted ProPolice inclusion of late. And of course the massively longer build times.
By Anonymous Coward () on
Comments
By goblin () on
-- the angry goblin
Comments
By dan () on
Comments
By Anonymous Coward () on
"When your hammer is C++, everything begins to look like a thumb."
You can hit your own thumbs, thank you very much.
-- the angry goblin
Comments
By dan () on
By krh () on
Please calm down. C++ is just a language.
By Anonymous Coward () on
By Anonymous Coward () on
What word processors do you use? OpenOffice.org? KWord? Oh wait, those use C++ too! Of course l33t dudes like you don't use word processors.
Fearrr the angry goblin.. release not your wrath on us.... NOT!
By the way there's something you might want to take up. It's called "growing up". You might want to seriously consider it some day.
By quel () on
Comments
By Paul () spawn@maltliquor.ca on mailto:spawn@maltliquor.ca
-Paul
By Anthony () on
I'm not too worried, the upgrade to 3.4 wasn't bad. Just curious. :)
Comments
By Benny Siegert () on http://mirbsd.de
Comments
By Anthony () on
I'm not really sure how much C++ there is in an OpenBSD base system, but I would think not a great deal, and only in user land.
I just ran a find for .cpp files in /usr/src, and it doesn't look like there's a whole hell of a lot. Of course, I don't have the expertise to say which ones are important enough to get in the way of building a bootable system that can build itself, but right this second I don't particularly care either. =P
It'll be in May, I have more immediate concerns.
Comments
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
GNU groff was the hardest part to replace.
Comments
By Anonymous Coward () on
By Anonymous Coward () on
Comments
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
The only man page I have to distribute in a
pre-compiled form (because nobody of us was
lazyless enough to make a groff port, there
is a ja-groff tho) is termcap(5).
Everything else is done with nroff, but
tools such as soelim are missing :-(
By Anonymous Coward () on
Comments
By Anonymous Coward () on
> ONLY_FOR_ARCHS= i386
> # supports 68k, alpha, mips, sparc as well, but
> not ported yet
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
It was mostly imported because it is much easier to have it in-tree to work on... the size of the diffs was rather too large.
For the time being:
- there are bugs in the new compiler's cpp -trad.
- the libstdc++ isn't imported yet, and doesn't work. It's likely to be some headers issue. I haven't had time to work on it.
- other stuff like objective-C and Fortran can wait.
- there is no propolice in the 3.3.2 in-tree yet.
As far as first reports go, all of src except groff compiles and works just fine on i386. Performance is less abysmal than expected (kernel actually compiles faster, and userland a bit slower (20%), which is much less catastrophic than was expected).
Some good surprises: the rewritten preprocessor groks a language that is closer to standard C, and the resulting error messages are much improved (since the compiler front-end and preprocessor have been merged, the compiler can get to precise locations in the src and show unexpanded macros). There are a few pleasant warnings too: gcc 3.3.2 knows about t[i++] = i being a bad thing. It also seems the generated code is slightly smaller, so it may make for improved bootable media.
As far as switching to 3.3.2 happens, should be incredibly less painless than other switches. Yes, C++ code will need recompiling. But of course, C++ libraries in the base system will get bumped.
This won't happen overnight, though. Some platforms will probably switch earlier. As someone mentionned, sparc64 support in gcc 2.95.x is bad. And new architectures like amd64 require gcc 3.x.
By the time 3.5 comes around, it should at least be reasonably easy to compile gcc3 and play with it. Having two available compilers means more system stability: gcc 2.95 can be used until gcc3 is completely ready. And the enhanced diagnostics of gcc3 will allow us to fix minor issues.
Performance issue with gcc3: that beast seems to require a heck of a lot more memory to be really efficient. We also need to check how good the -O1 code is. I've been told gcc 3.3.x -O1 is roughly on a par with gcc 2.95 -O2... if that's true, then gcc 3.3.x is faster than gcc 2.95 in some settings.
Comments
By Anonymous Coward () on
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
external gcc 3.2.2 from ports as the system compiler,
it worked. Then I tried updating the port to 3.3,
and it failed.
Next time I tried 3.3 then 3.3.1 in base, now 3.2.2,
until I discovered that everything works if I
disable propolice.
I'll now try diffing the old working and the new
tree, and look what happens.
Comments
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
Propolice in OpenBSD has undergone a lot of tests, largely courtesy of Miod Vallat. The first version that was committed in gcc 2.95 was definitely NOT production quality. There were quite a few bugs to fix.
In fact, gcc is as weird as propolice: a large part of these issues were latent gcc bugs, that propolice did trigger, where the default code paths used in gcc did not.
One of the things newer gcc do is have stronger internal checks. My feeling is that integrating propolice in gcc 3.3.2 should be easier than for 2.95. But of course, it's not just `put the patch in and hope it works'... If making OpenBSD was that easy... everyone can take a patch and apply it to an OS and run the resulting mix. Fixing the actual bugs after applying the patch may take some real expertise.
By Andrew Pinski () pinskia@gcc.gnu.org on mailto:pinskia@gcc.gnu.org
- there are bugs in the new compiler's cpp -trad.
libstdc++ does work for me on at i686-unknown-openbsd3.1 on the mainline of gcc (see http://gcc.gnu.org/ml/gcc-testresults/2003-12/msg00106.html).
I wish propolice get in the mainline of gcc.
There should be more speedups in gcc 3.4 anyway.
Yes I know I should update to openbsd 3.4 but I have not gotten around to because I would then need to change the compiling of gcc (because of the switch to elf).
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
problem has been fixed, it was in crt0.o, of all things.
Except for propolice, gcc 3.3.2 looks fine. I've been rebuilding my whole system with it, and I'm down to 75 ports to fix before everything works.
That's on i386, minor other fixes on other arches are expected, of course.
But still, it's looking good.