Why Clang

classic Classic list List threaded Threaded
216 messages Options
1 ... 891011
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Reid Linnemann
On Thu, Jun 21, 2012 at 11:27 PM, Chad Perrin <[hidden email]> wrote:

> I disagree with the assessment by others that FreeBSD is in some way
> effectively a subsidiary of its corporate users, but it does have
> corporate users, as well as non-corporate users.  Just as it must
> reasonably see to the needs of the individuals who use it, so must it
> also reasonably see to the needs of those corporate users, especially
> when some of those corporate users' employees are key developers for the
> base system (to the significant benefit of the rest of us).  Thus, saying
> that a particular set of conditions having an impact on commercial
> sponsors of FreeBSD has "zero bearing on FreeBSD itself" is just . . .
> incorrect.

And I would like to stress on this point that, when I referred to
corporate sponsorship in an earlier post, I was thinking specifically
about the sponsorship of employing developers that keep the system
moving forward, not necessarily monetary donations. The foundation
does need money, but the software is doomed if no one is gainfully
employed to maintain and enhance it. I think there is an altruistic
fiction that many people subscribe to that free software is merely the
result of the generosity of developers producing code of their own
volition and on their own spare time and "giving it away," and from
that viewpoint the act of considering concerns of a sponsoring entity
amounts to "selling out." The reality is much different and much more
complex, as you well know.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Wojciech Puchar-5
In reply to this post by Robert Bonomi
> Because it doesn't address an of the *OTHER* valid reasons why GCC is
> being replaced -- among them:
>  1) GCC's continuously increasing propensity to generate "bad code",

examples? All test shows that gcc code is not only bad, but very good. Why
are you just saying things you know isn't true?


>  2) The inability of GCC mamintainers to fix _long-standing_ bugs, some
>     have been identified for over a decade, and have not been fixed.

That's true. still not that much.

>  3) The continuously increasing trend of introducing 'non standard' features,
No need to use them.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Volodymyr Kostyrko
Wojciech Puchar wrote:
>> Because it doesn't address an of the *OTHER* valid reasons why GCC is
>> being replaced -- among them:
>> 1) GCC's continuously increasing propensity to generate "bad code",
>
> examples? All test shows that gcc code is not only bad, but very good.
> Why are you just saying things you know isn't true?

0k, what if I add my example?

Hardware:
Processor: Intel Xeon E5620 (16 Cores), Motherboard: Supermicro X8DT3
1234567890, Memory: 24576MB, Disk: SEAGATE ST3146855SS S527 + SEAGATE
ST31000640SS 0001 + SEAGATE ST31000640SS 0001 + SEAGATE ST3146855SS S528
+ TOSHIBA Trans 1.00 + TEAC DV-28S-V 1.0B

Software:
OS: FreeBSD, Kernel: 9.0-RELEASE-p3 (x86_64), Compiler: GCC 4.2.1
20070831 + Clang 3.0 (SVN 142614), File-System: zfs

CPUTYPE=core2

clang 3.0
Test project /tmp/ports/usr/ports/graphics/png/work/libpng-1.5.11
     Start 1: pngtest
1/2 Test #1: pngtest ..........................   Passed    0.02 sec
     Start 2: pngvalid
2/2 Test #2: pngvalid .........................   Passed   14.03 sec

gcc 4.6 (lang/gcc, USE_GCC=4.6+)
Test project /tmp/ports/usr/ports/graphics/png/work/libpng-1.5.11
     Start 1: pngtest
1/2 Test #1: pngtest ..........................   Passed    0.02 sec
     Start 2: pngvalid
2/2 Test #2: pngvalid .........................   Passed   14.40 sec

gcc 4.2.1
Test project /tmp/ports/usr/ports/graphics/png/work/libpng-1.5.11
     Start 1: pngtest
1/2 Test #1: pngtest ..........................   Passed    0.02 sec
     Start 2: pngvalid
2/2 Test #2: pngvalid .........................   Passed   14.96 sec

This one shows that clang is superior to both gcc 4.2.1 and gcc 4.6.

I haven't test data now but a month or so ago I tested them on one of
the Alioth Shootout examples (nestedloop probably). gcc 4.2.1 was
winning, clang was close with fractions of percent drop of speed but gcc
4.6 was off for nearly 7%.

>> 3) The continuously increasing trend of introducing 'non standard'
>> features,
> No need to use them.

There's no 'Unsubscribe me' link included...

--
Sphinx of black quartz judge my vow.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Mark Felder-4
In reply to this post by Wojciech Puchar-5
On Fri, 22 Jun 2012 09:25:55 -0500, Wojciech Puchar  
<[hidden email]> wrote:

> examples? All test shows that gcc code is not only bad, but very good.  
> Why are you just saying things you know isn't true?

Fast code is not guaranteed to be correct code.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Robert Bonomi
In reply to this post by Thomas Mueller

"Thomas Mueller" wrote:
>
>
> There actually is/was a closed-source BSD (BSDI), and there is Mac OS X, with BSD under the covers.

BSDi sold source-code licenses.  I was an early-adopter, and I _have_ one.

The vast majority of the code was taken directly from BSD 4.4 Lite, and
the source-code carried just the UCB copyriht and licensinG,  The 'missing
pieces' necessary to make an 'operational' O/S were copyright BSDi, most
had fairly liberal license terms.  There were some _vendor_supplied drivers
that were binary-only, and had more rstrictive licensing.`


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Robert Bonomi
In reply to this post by Wojciech Puchar-5
> From [hidden email]  Fri Jun 22 09:26:33 2012
> Date: Fri, 22 Jun 2012 16:25:55 +0200 (CEST)
> From: Wojciech Puchar <[hidden email]>
> To: Robert Bonomi <[hidden email]>
> cc: [hidden email]
> Subject: Re: Why Clang
>
> > Because it doesn't address an of the *OTHER* valid reasons why GCC is
> > being replaced -- among them:
> >  1) GCC's continuously increasing propensity to generate "bad code",
>
> examples? All test shows that gcc code is not only bad, but very good.

YOU ARE A LIAR. The _only_thing *you* measure by is 'speed'.  You don't
understand what the words "bad code" means -- that it has *nothing* to do
with how fast the code executes.. Despite the fact I explicitly described
what I was talking about -- and that you intentionally removed that
description.

> Why are you just saying things you know isn't true?

Why are you just _lying_ trollbiu?

Just because _you_ haven't seen it doesn't mean it's not true.

I *KNOW* it is true -- I've been bitten by GCC bad code _multiple_ times,
and in multiple ways, in application code.  Problems in O/S internals are
much more common.

I've had segfaults in code that couldn't _POSSIBLY_ segfault.  An example
of the _kind_ of thing that has blown up:

     int foo()
     {  int a,b,c[10];

        b=2;
        a=c[b];   /* dies here with a segfault */
     }

     running in the debugger confirms b has the correct value just before
     the statement assigning a value to a. issue a 'next' command in the
     debugger, and you get a segfault.  printing the value of 'b' shows
     it is 2.

     Disassembling the machine code shows that the WRONG REGISTER is used
     to calculate the effective address of the array element.

     It's clearly a bug in the optimizer -- I'd be surprised if it showed
     in that 'minimal' illustrative code.  When I've gotten bit, it was
     a 1,000+ LOC module.

     I've also seen it use machine 'loop' instructions with the DF flag
     set wrong.


> >  2) The inability of GCC mamintainers to fix _long-standing_ bugs, some
> >     have been identified for over a decade, and have not been fixed.
>
> That's true. still not that much.

Your opinion of the seriousness doesn't count.  Those of us who have had
to 'code raround' those bugs for years and years have a _very_ different
opinion.

> >  3) The continuously increasing trend of introducing 'non standard' features,
> No need to use them.

Trollboi shows he doesn't know what he doesn't know, yet again.

Some of them _conflict_ with STANDARD C.   Thus 'standards-compliant' C source
does 'something else', when compiled with GCC.  The FSF thinks 'their way'
is "better", and have no intention of changing.

>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Chad Perrin
In reply to this post by Wojciech Puchar-5
On Fri, Jun 22, 2012 at 08:28:17AM +0200, Wojciech Puchar wrote:
> >
> >biggest problem with what you propose, though, is that it would destroy
> >the social factors in development of the FreeBSD system that make it what
> >it is, and thus destroy FreeBSD itself, as far as I am concerned.
>
> I am not sure, as long as clients would be treated seriously!

I look at large corporate software vendors and see them treating
customers seriously maybe 2% of the time at best.  In this case, most of
the developers and project managers of FreeBSD are also "customers",
which changes things significantly.


> >
> >I would have thought that even you should be able to understand that
> >without help.
>
> another personal attack? I though i talk with adults.

1. It's a comment on your tendency to ignore substantive arguments from
other people, including probably half a dozen (so far) lengthy
explanations of factors you refuse to consider written by *me*.

2. You're a hypocrite, pretending you're an innocent victim of personal
attacks, given the way you go around making personal attacks on everyone
else with a broad brush.  I've commented on that, too, but -- like much
of the rest of what I've said -- you simply ignored it.


> >
> >Turning it into a commercial enterprise rather than an open source
> >project would probably turn it into a project that is driven about 60% by
> >corporate politics and 40% by marketing BS, with no room left over for
> >quality except as needed to support the minimum credibility its CEO deems
> >necessary to support those two concerns.
>
> It depends solely on development team.

I take it you don't know anything at all about how public corporations
manage their development teams.  That, or you're being disingenuous.

It depends on the development team, and the priorities they choose to
pursue first, right now.  Under the stewardship of a publicly traded
corporation, it would depend on the CEO, the board of directors,
marketing, PR, and the accounting department, and the priorities *they*
choose to pursue first, instead.


>
> For now - as we see - it's decision are driven by money.
> But not all users money but few selected large users.

It's not *just* a decision driven by money.  Money applies, certainly,
but not as much as it would if FreeBSD were a for-profit public
corporation rather than a community-driven open source project.  When you
say this, by the way, you ignore something like 90% of the perfectly
reasonable additional motivating factors that have been brought up.  I
suppose I should not expect any different by now, given the strong track
record you've managed to establish just in this one extended discussion.


> >
> >"Worse" based on a couple of very narrowly applicable metrics derived
>
> There will be IMHO soon good compiler available. it's highly
> probable that pcc would improve a lot, for now it is small, quick
> but doesn't produce good code for new CPUs. But it probably will
> improve.
>
> CLANG is already great bloat, and will be worse.

Binary size and minuscule benchmark variations are all you see.  It is
ludicrous to watch you close your eyes, stick your fingers in your ears,
and shout "lalalalalalalala" so consistently to prevent any other factors
involved in compiler choice from entering your mind -- such as good
output from a compiler that will be stable and do what you expect.


>
> No amount of money will fix it, actually too much money will hurt.

. . . and yet you want to turn the FreeBSD project over to Microsoft (or
the equivalent).  You contradict yourself.

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Chad Perrin
In reply to this post by Julian H. Stacey-3
On Fri, Jun 22, 2012 at 01:16:09PM +0200, Julian H. Stacey wrote:

> Chad Perrin wrote:
> > On Thu, Jun 21, 2012 at 01:06:12PM +0200, Wojciech Puchar wrote:
> > > i already proposed (but not publically) to turn FreeBSD into
> > > commercial system.
> > >
> > > REALLY i would not see a problem to pay say 100$ per server licence.
> >
> > I would see a problem with that -- not because I don't think FreeBSD is
> > worth it.  I do, and I think it is worth more than that, in fact.  The
> > biggest problem with what you propose, though, is that it would destroy
>
> Hi Chad etc,
> I admire the perserverance, but maybe "Don't feed the troll" ?

Yeah. . . .

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Chad Perrin
In reply to this post by Reid Linnemann
On Fri, Jun 22, 2012 at 09:24:57AM -0500, Reid Linnemann wrote:

> On Thu, Jun 21, 2012 at 11:27 PM, Chad Perrin <[hidden email]> wrote:
> > I disagree with the assessment by others that FreeBSD is in some way
> > effectively a subsidiary of its corporate users, but it does have
> > corporate users, as well as non-corporate users.  Just as it must
> > reasonably see to the needs of the individuals who use it, so must it
> > also reasonably see to the needs of those corporate users, especially
> > when some of those corporate users' employees are key developers for the
> > base system (to the significant benefit of the rest of us).  Thus, saying
> > that a particular set of conditions having an impact on commercial
> > sponsors of FreeBSD has "zero bearing on FreeBSD itself" is just . . .
> > incorrect.
>
> And I would like to stress on this point that, when I referred to
> corporate sponsorship in an earlier post, I was thinking specifically
> about the sponsorship of employing developers that keep the system
> moving forward, not necessarily monetary donations. The foundation
> does need money, but the software is doomed if no one is gainfully
> employed to maintain and enhance it. I think there is an altruistic
> fiction that many people subscribe to that free software is merely the
> result of the generosity of developers producing code of their own
> volition and on their own spare time and "giving it away," and from
> that viewpoint the act of considering concerns of a sponsoring entity
> amounts to "selling out." The reality is much different and much more
> complex, as you well know.

Indeed.  When I contribute to an open source project, as an individual,
much the same factors apply.  I do not do it to help someone like Michel
Talon, or even Reid Linnemann; I do it to help myself, by improving
software I like, or to help people who in turn work to improve software I
like.  I have selfish goals that are served by my support of well-
designed copyfree software, whether that support is financial in nature,
a contribution of development effort, or something less direct.

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why Clang

Wojciech Puchar-5
In reply to this post by Chad Perrin
>> I am not sure, as long as clients would be treated seriously!
>
> I look at large corporate software vendors and see them treating
> customers seriously maybe 2% of the time at best.  In this case, most of

I assumed FreeBSD team are OK and would fit in this 2% or even those 0.2%



am i wrong?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: CLANG vs GCC tests of fortran/f2c program

jb-2
In reply to this post by Chad Perrin
Chad Perrin <perrin <at> apotheon.com> writes:

>
> Anyway, switching from GCC to Clang has essentially nothing to do with
> the kinds of problems we increasingly see in the Linux world.  In fact,
> one of the biggest problems in the Linux world is the fact that GNU
> projects have a tendency to degrade in quality over time and pretty
> thoroughly undermine the Unix philosophy in egregious ways, which means
> that the sooner we can divest ourselves of GNU tools (including GCC) the
> better off we will probably be (though I would still advocate a measured
> approach to replacing GNU tools, rather than a headlong rush without any
> forethought).
>

Some Linux distros are starting to integrate clang into their environment.

GPL had been introduced to address certain philosophical problems felt by devs,
namely how to make sure that their products do not get hijacked by people who
do not want to contribute back (because they are unscrupulous, or do not share
with devs the same values). Fair enough.

GPL has not been challenged in court of law perhaps for a good reason yet.
  One could be that its enemies are content with what it represents in their
view and so why should they bother trying to protect its followers from
hurting themselves ? They believe that GPL is viral, but not fascist yet and
anybody of different philosophy can just ignore it and go their own licensing
way.
  Another could be that its enemies want it to reach a critical mass of
participation, so when they hit, it will be big time and hopefully deadly.
Things like that need time, and perhaps some errors by GPL advocates.
  It is also possible (why not ?) that GPL will self-destruct - there are
indications that they are going down, down, down as a choice of license.
  I believe GPL can be confusing in its interpretation - even its followers
are confused, and that's the seeds of destructions as I see it (btw, I have
participated in some discussion of GPL that made me and other participant feel
its current interpretation is vulnerable, and so with potential significant
effect on a business model dependent on it.).

GPLv3 apparently introduced a very sensitive question:
  Does GPLv3 apply to gcc only, or it *may* apply to code generated by gcc as
  well ?
and until it gets answered any responsible dev or business should stay away
from it.
  If so, then it follows that the dev or the bussiness do not want to live in
a "LaLaLand according to GPL"; they want to conduct activities based on sound
rules - who in her right mind would blame them for that ?
So, you cut the GPL cord now and go your own way, the sooner the better.
This is the most important factor, in any business - clarity of contract,
license law.

I would strongly disagree with Wojciech's assertion that only performance of
compiler generated code really counts.
>From the software purchaser's point of view, yes, she wants the app that was
paid for fast, let's be realistic.
But if you consider devs or software houses, that will be more subtle.
I think the design and maintainability of compiler source code decides about
quality of that tool in a significant way, equally or perhaps even little more
than its speed or that of generated code alone - after all it is a tool on
which software product depends now and in the future.
And this translates into e.g. maintenance costs, a matter of interest to
purchaser of software and others, in general the so called users.

I am more concerned about an aspect of the language the clang tools are
written in, namely the use of object-oriented paradigm of c++ (it is a phony
paradigm, one that does not exist in nature or reality, which explains
the failure rate of C++ OO projects historically and current usage decline).
I sense that the relative slowness of generated code has to do with it. Perhaps
some other attributes of that code's quality too, even if not now, then in the
future.

As one can see even by the test results done in 2010:
  http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1
clang looked good vice gcc.
There was an improvement since then, e.g.:
  http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc

Once again, in a matter like choice of tools you make your living with, you
should not gamble - the more clarity you have the better. Once you decide what
your philosophy, license model, and business requiremnts are, you just go and
do not look back.
The choice was made (perhaps GPL helped make that choice ...) - it is clang
compiler tools.

jb



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: CLANG vs GCC tests of fortran/f2c program

Jakub Lach
> I am more concerned about an aspect of the language the clang tools are
> written in, namely the use of object-oriented paradigm of c++ (it is a phony
> paradigm, one that does not exist in nature or reality, which explains
> the failure rate of C++ OO projects historically and current usage decline).
> I sense that the relative slowness of generated code has to do with it. Perhaps
> some other attributes of that code's quality too, even if not now, then in the
> future.

Yes, this is one thing really puzzled me. Maybe it's related to Apple's affinity
to Objective-C?
Reply | Threaded
Open this post in threaded view
|

Re: CLANG vs GCC tests of fortran/f2c program

jb-2
Jakub Lach <jakub_lach <at> mailplus.pl> writes:

>
> > I am more concerned about an aspect of the language the clang tools are
> > written in, namely the use of object-oriented paradigm of c++ (it is a
> > phony
> > paradigm, one that does not exist in nature or reality, which explains
> > the failure rate of C++ OO projects historically and current usage
> > decline).
> > I sense that the relative slowness of generated code has to do with it.
> > Perhaps
> > some other attributes of that code's quality too, even if not now, then in
> > the
> > future.
>
> Yes, this is one thing really puzzled me. Maybe it's related to Apple's
> affinity
> to Objective-C?

Well, let me add some more and important facts to this discussion.
If it caused so much emotions and name calling, then at least everybody should
know what this is all about.

Clang is a compiler front-end for C, C++, Objective-C and Objective-C++
programming languages and it uses LLVM as its back-end.

Both, clang and LLVM, are written in C++.

LLVM provides middle layers of compilation process and is e.g. responsible for
optimization of intermediate code, which next will be converted and linked into
machine-dependent assembly code.

Based on this source
  http://en.wikipedia.org/wiki/Objective-C
the Objective-C was influenced by Smalltalk's object-oriented programming
model, while C++ by Simula's.
This has implications for characteristics and performance of Objective-C,
for example:
- there are quite few important language elements in C++ that are not in
  Objective-C, like namespaces, multiple inheritance, operator overloading, etc
- "... Objective-C applications tend to be larger than similar C or C++
  applications because Objective-C dynamic typing does not allow methods to be
  stripped or inlined."
- "... Because Objective-C uses dynamic runtime typing and because all method
  calls are function calls (or, in some cases, syscalls), many common
  performance optimizations cannot be applied to Objective-C methods (for
  example: inlining, constant propagation, interprocedural optimizations, and
  scalar replacement of aggregates). This limits the performance of Objective-C
  abstractions relative to similar abstractions in languages such as C++ where
  such optimizations are possible."
- "... Objective-C is decidedly geared toward run-time decisions while C++ is
  geared toward compile-time decisions. The tension between dynamic and static
  programming involves many of the classic trade-offs in programming: dynamic
  features add flexibility, static features add speed and type checking."
  My Note: please keep in mind we are talking about language used for writing
  clang, a compiler tool.

So, Objective-C has disadvantage with regard to size od generated code,
performance, and optimization as compared to C++.

But both share OO (object-oriented) paradigm, which many pros consider
synthetic, or pulled out of thin air if you prefer, with negative effects on
devs mental health, design, and resulting code quality.

I hope I got all facts right -:)

It seems to me that switching to clang was a correct strategic decision for
reasons linked to GPLv3 license as described in my prior post and by other
thread posters.
But there seems to be some price paid related to "written in C++" facts
described by me in both posts, which may make some people come to a conclusion
that the decision was based more on a political factor (Apple) than on
technical merits.
Because I did not participate or followed FreeBSD's internal process, I can
not express any opinion to what extend both factors were considered and
discussed.

OK. Judge for yourselves, and have fun.

jb


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: CLANG vs GCC tests of fortran/f2c program

Wojciech Puchar-5
>  programming involves many of the classic trade-offs in programming: dynamic
>  features add flexibility, static features add speed and type checking."
>  My Note: please keep in mind we are talking about language used for writing
>  clang, a compiler tool.
>
> So, Objective-C has disadvantage with regard to size od generated code,
> performance, and optimization as compared to C++.
>
> But both share OO (object-oriented) paradigm, which many pros consider
> synthetic, or pulled out of thin air if you prefer, with negative effects on
> devs mental health, design, and resulting code quality.
>
> I hope I got all facts right -:)

most probably, but what does it mean if clang have multiple layers,
frontend, LLVM backend, etc. etc. for normal user who just needs C
compiler.

It doesn't matter how it do this but what are the results.

> It seems to me that switching to clang was a correct strategic decision for
> reasons linked to GPLv3 license as described in my prior post and by other
> thread posters.
You didn't wrote anything new here.

> But there seems to be some price paid related to "written in C++" facts
> described by me in both posts, which may make some people come to a conclusion
> that the decision was based more on a political factor (Apple) than on
> technical merits.

It doesn't really care how clang is written but how it works. And it was
political decision because compiler itself, on GPLv3 licence, does not
block anyhow distributing it's output - binaries.

C++ libraries can be limiting, but... wasn't replaced.

If it would be truly about removing GPLv3 code that hurts, replacing
libstdc++ would be first thing to do.

For now we have removed GPL code that doesn't hurt

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: CLANG vs GCC tests of fortran/f2c program

Vincent Hoffman-Kazlauskas
On 25/06/2012 13:56, Wojciech Puchar wrote:
>
> C++ libraries can be limiting, but... wasn't replaced.
>
> If it would be truly about removing GPLv3 code that hurts, replacing
> libstdc++ would be first thing to do.
I assume you mean like the new libc++?
http://wiki.freebsd.org/NewC%2B%2BStack

>
> For now we have removed GPL code that doesn't hurt
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "[hidden email]"


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: CLANG vs GCC tests of fortran/f2c program

Wojciech Puchar-5
>>
>> If it would be truly about removing GPLv3 code that hurts, replacing
>> libstdc++ would be first thing to do.
> I assume you mean like the new libc++?
> http://wiki.freebsd.org/NewC%2B%2BStack

yes. this is actually GREAT MOVE!
even if it's slower, object oriented languages are not about speed anyway.

This should be done first, not compiler.

Compiler - only after actually better would exist.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
1 ... 891011