CLANG vs GCC tests of fortran/f2c program
perrin at apotheon.com
Wed Jun 20 17:40:08 UTC 2012
On Wed, Jun 20, 2012 at 11:09:23AM +0200, Wojciech Puchar wrote:
> >1. gcc will still be available through the ports system.
> As well as clang is available in ports. not an argument.
No, it's not an argument all by itself. It's *part* of an argument.
> >2. The move to clang/llvm as a default compiler will reduce the amount
> >of GPL code in the base system, eventually reducing distribution
> >issues (especially for 3rd parties).
> true. But JUST reducing GPL code should be a target per se.
> FreeBSD is about performance and quality not politics or religion.
FreeBSD needs to be able to keep up with bug fixes and support for C and
C++ language standards to maintain quality. It needs to avoid licensing
that discourages use to maintain relevance, development resources, and
productive value, all of which contribute to quality. Performance
differences between Clang and GCC are at present so minor as to be
considered negligible except for the most pathological edge cases, and
Clang performance is improving at a rapid pace that suggests it will soon
be a clear performance improvement over GCC. The Clang codebase is more
modular and less of a tangled mess, by all accounts, which improves
maintainability, extensibility, fixability, and advance-ability, which
may be why "In LLVM/Clang [a char type incrementation bug] was not known
but was fixed in less than 24 hours," while "In GCC the bug is known and
has existed for some time."
In short, as FreeBSD as a whole is to something like Microsoft Windows
with regard to stability, bug fixing, and ease of maintenance, so it
seems Clang is to GCC. That's not "politics or religion." That's a very
real-world, practical benefit to using Clang, to say nothing of the
benefit of not having to jump through political, religious, or legal
hoops to redistribute something distributed under a copyfree license like
Clang, as contrasted with something distributed under a copyleft license
> >3. clang/llvm provides better error and warning messages, as well as
> >good static code analysis, which helps reduce some classes of bugs and
> >eventually will result in a more reliable FreeBSD system.
> as with 1 - you may use clang when developing.
Thank you for such permission. I didn't need it, and I doubt anyone else
> >4. clang/llvm is improving quickly.
> When/If it WILL actually improve to be better than gcc it should be
> imported to FreeBSD. not sooner.
Looking to the future helps ensure that we can choose something that will
be better in the long run now, get involved early, and thus help it
improve more quickly as well as helping ensure that its "improvements"
are to some extent suitable to our uses. Stop thinking about a fiscal
period obsessed CEO, and start thinking long-term.
> >5. clang/llvm is more modular than gcc, although there are plans for
> >gcc to become as modular, it will take time.
> Doesn't matter how it is written, but how it performs.
How it is written matters for purposes of ensuring faster and less
problematic fixes when problems arise. Think long-term for a change.
> >6. gcc produces faster code, but clang/llvm will eventually (soon
> >enough) get there.
> This is your prediction. Not definite fact, mine and other
> predictions are different.
By the same token, GCC getting greater modularity is not a definite fact,
and I would prefer a compiler it will be easier to maintain for future
stability, security, and correctness, over one with a generally
negligible performance advantage.
> >7. From the reasons above, it makes sense to complete a task sooner
> >rather than later, especially that clang/llvm isn't showing any signs
> >of weakness (lack of development power, etc).
> NOBODY prevent you and FreeBSD developers to fix things already - so
> FreeBSD and ports would compile with both compilers.
> Actually it is good to fix it already, as making programs compile
> with both means usually fixing non-portability bug which would help
> using third compiler that may possibly emerge.
> But this DO NOT require clang to be a part of main system. As well
> as making it default.
It also does not require GCC to be part of the base system, or to be the
default, so this point in your argument is moot.
> >8. There might be more reasons for or against, but I couldn't think of any.
> All "for" arguments assumes clang WILL be better. This is a change
> as less than 2 days before it was stated to already be better.
It is, in many respects, already better. It produces more-correct output
than GCC; it does not pollute the base system with copyleft licensing; it
does not pollute "intermediate code" representations combined or
transformed by other tools during compilation with copyleft licensing; it
has a better architecture for maintenance, which bears directly on the
ability of FreeBSD developers to contribute to its development and on the
likelihood of the compiler maintaining stability, currency, and
correctness in the future; it shows far greater beneficial improvement
over time than GCC, suggesting much better development support; upstream
development is much more responsive to the needs of downstream users and
redistributors, including the FreeBSD project; it includes interesting
project initiatives, including one that may ultimately obviate the need
for Oracle's troublesome JVM; et cetera.
If nothing else, the more-correct output should trump negligible
performance differences that are likely to evaporate in the near future,
especially considering how long GCC has had to clean up its output
problems and consistently failed to do so.
> As a comparision - DragonFly BSD is stated to have better ideas that
> would result in better performing system in a future.
> But FOR NOW it is much worse performer than FreeBSD that's why i
> (and lots of other people) does not switch to DragonFly but of
> course will when(and if) DragonFly BSD will actually be better. And
> i don't really think this "IF" will happen at all, but i wish to
> DragonFly BSD i am wrong.
> Same should be used for clang. AS LONG as it is not better it should
> not be imported into base system or worse - used as default.
It is better. It just isn't better for the specific cases *you* consider
important, even when those cases are of questionable value in the vast
majority of circumstances and the ways in which it is better that you
ignore are far more broadly applicable.
> Making decision based on wishes and personal likes instead of
> technical facts isn't something that anyone should be proud about.
So . . . stop doing it. Wishing away other factors does not mean they do
> As for your words about doing decision good for FreeBSD, not me - it
> is pure nonsense attacks because anything that is good for FreeBSD
> quality is good for me, and the reverse.
That's only true if everyone else measures "quality" the same way you do.
Saving three seconds per day on specific tasks is not likely to be the
sole factor in most people's determinations of quality.
> The decision of switching to clang now it shows that ideologic and
> "religious" arguments won over technical arguments.
> The agressive and data-manipulationg reactions of many people on
> that list shows that above sentence is true.
When you refuse to assume good faith at first encounter in discussion,
you just make everyone into your enemy. This pretty well ensures that
the majority of people will ignore your concerns, no matter how valid
they may (or may not) be. Try approaching a discussion with the attitude
that it is an opportunity for both you and the other party to each learn
something from the other, rather than with the attitude that if anyone
starts out disagreeing with you that person must be a malevolent entity
bent on the destruction of all that is good and right in the world.
> This IMHO much change.
What does that H stand for? It sure as hit ain't "humble".
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
More information about the freebsd-questions