On Thu, Jan 23, 2014 at 11:52:00PM -0500, Vladimir Makarov wrote:
> o IMHO, the data in articles lack credability may be because a wrong
> setup (by me or by phoronix). E.g. I tried to reproduce Scimark
> results for GCC4.8 and LLVM3.3 from his article "LLVM Clang 3.4
> Already Has Some Performanc
On Thu, 2014-01-23 at 17:42 -0800, Ian Lance Taylor wrote:
> On Thu, Jan 23, 2014 at 1:28 PM, Basile Starynkevitch
> wrote:
> >
> > Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software
> > enthusiast and I like a lot the GPLv3
> >
> > As you know, GCC has some technical dev
On Thu, Jan 23, 2014 at 5:02 PM, Gregory Casamento
wrote:
>
> Granted, however, at the very least GCC should consciously ramp up it’s
> support for Objective-C. Currently the Objective-C implementation in GCC is
> woefully out of date as it doesn’t include basic support for ARC.
I would like t
Sorry, I forgot that pdf file is not permitted. Therefore I am
resending my email without it.
On 1/23/2014, 5:56 PM, Chris Lattner wrote:
On Jan 23, 2014, at 12:14 PM, Steven Bosscher wrote:
(Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a
better-supported point of view.
On Thu, Jan 23, 2014 at 1:28 PM, Basile Starynkevitch
wrote:
>
> Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software
> enthusiast and I like a lot the GPLv3
>
> As you know, GCC has some technical devices to invite plugin developers
> to make GPL compliant plugins.
> http:
On 24 January 2014 01:02, Gregory Casamento wrote:
>
> Granted, however, at the very least GCC should consciously ramp up it’s
> support for Objective-C. Currently the Objective-C implementation in GCC is
> woefully out of date as it doesn’t include basic support for ARC.
That's easy to say but
Eric,
On Jan 23, 2014, at 7:00 PM, Eric Botcazou wrote:
>> One other point I must make is in regards to clang's Objective-C support vs.
>> that of GCC. GCC regards Objective-C as a second class language and has
>> done so for some time. Objective-C, according to recent statistics has
>> surpa
> One other point I must make is in regards to clang's Objective-C support vs.
> that of GCC. GCC regards Objective-C as a second class language and has
> done so for some time. Objective-C, according to recent statistics has
> surpassed C++ in the number of developers using it (see this link
>
On 01/24/2014 12:12 AM, Jonathan Wakely wrote:
On 23 January 2014 22:56, Chris Lattner wrote:
Unrelated to this thread, it would be great for this web page to get updated. You may
find it to be "a better-supported point of view", but it is also comparing
against clang 3.2, which is from the
Guys,
I have resisted entering into this argument up until now. All I can do here
is share my experience with technical decisions that have been made in GCC.
I am the maintainer of GNUstep (http://www.gnustep.org/) and the principal
author of the Gorm (Interface Builder)
(http://www.gnuste
On 23 January 2014 22:56, Chris Lattner wrote:
>
> Unrelated to this thread, it would be great for this web page to get updated.
> You may find it to be "a better-supported point of view", but it is also
> comparing against clang 3.2, which is from the end of 2012, and a lot has
> changed since
On Thu, Jan 23, 2014 at 2:56 PM, Chris Lattner wrote:
> On Jan 23, 2014, at 12:14 PM, Steven Bosscher wrote:
>> (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a
>> better-supported point of view.)
>
> Unrelated to this thread, it would be great for this web page to get update
On Jan 23, 2014, at 12:14 PM, Steven Bosscher wrote:
> (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a
> better-supported point of view.)
Unrelated to this thread, it would be great for this web page to get updated.
You may find it to be "a better-supported point of view",
Snapshot gcc-4.8-20140123 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140123/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, 2014-01-23 at 22:28 +0100, Basile Starynkevitch wrote:
> Hello All, [GCC list, MELT group, and David Malcolm -python plugin- and
> Diego Novillo -plugin enthusiast & maintainer]
>
> Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software
> enthusiast and I like a lot the G
On 23 January 2014 21:58, Eric S. Raymond wrote:
> Steven Bosscher :
>> On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote:
>> > I have not run direct checks on the quality of the optimized code, but
>> > reports from others that it is improved seem plausible in light of
>> > the fact that GC
Steven Bosscher :
> On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote:
> > I have not run direct checks on the quality of the optimized code, but
> > reports from others that it is improved seem plausible in light of
> > the fact that GCC's optimization technology is two decades older in
> >
Some people have replied to me doubting that clang has the advantages
I listed (better error messages, faster compilation, superior optimization).
I maintain a C project called GPSD which, though not above medium
size, is for various reasons a pretty good compiler-quality stress
test. I found an o
Hello All, [GCC list, MELT group, and David Malcolm -python plugin- and
Diego Novillo -plugin enthusiast & maintainer]
Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software
enthusiast and I like a lot the GPLv3
As you know, GCC has some technical devices to invite plugin de
On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote:
> I have not run direct checks on the quality of the optimized code, but
> reports from others that it is improved seem plausible in light of
> the fact that GCC's optimization technology is two decades older in
> origin.
Yay, another "fact"
On Thu, Jan 23, 2014 at 6:49 PM, Eric S. Raymond wrote:
> (Redirected to the proper lists, excluding emacs-devel.)
This is not the proper list. "gcc@ is a ... list for general
development discussions about GCC." (xf
http://gcc.gnu.org/lists.html). Most of this pointless discussion has
nothing to d
On Thu, Jan 23, 2014 at 12:49 PM, Eric S. Raymond wrote:
>> Maybe nobody bothers because using clang is easier than to fight with
>> FSF policies.
>
> Which is pretty close if not identical to my original point.
Your original point came across as a complaint that GCC does not
support plugins bec
On Tue, 21 Jan 2014, Alexandre Oliva wrote:
> On Jan 21, 2014, e...@thyrsus.com (Eric S. Raymond) wrote:
>
> > I think it is time to question whether the anti-plugins policy is
> > still the best way to accomplish this.
>
> Err... Excuse me, but what anti-plugins policy are you talking about?
On 23 January 2014 17:49, Eric S. Raymond wrote:
> (Redirected to the proper lists, excluding emacs-devel.)
Why do you think the gcc list is the proper place?
> The clang people aren't just a technical challenge to GCC, they're a
> philosophical/political one to the FSF as well. They are explic
(Redirected to the proper lists, excluding emacs-devel.)
Helmut Eller :
> > If nobody bothers with even
> > considering the question, it would appear that it is not all that
> > important...
>
> Maybe nobody bothers because using clang is easier than to fight with
> FSF policies.
Which is pretty
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The fact that these non-free tools are not based on gcc are a
> testament t
On Wed, 22 Jan 2014, Sylvestre Ledru wrote:
> Actually, I wonder if -Wmissing-return should not be included by default ...
I don't think that's appropriate for C; control reaching the end of a
function is quite likely to mean simply that the user is writing C90 / C99
code without annotations fo
Hello,
I have found a strange case of an ICE due to a MEM with an address with vector
mode.
The ICE looks like:
baaclc_block.c: In function 'fn2':
baaclc_block.c:22:1: internal compiler error: in trunc_int_for_mode, at
explow.c:56
}
^
0x64d050 trunc_int_for_mode(long, machine_mode)
/h
On Thu, Jan 23, 2014 at 8:24 PM, Dodji Seketeli wrote:
> Prathamesh Kulkarni writes:
>
>>
>> Shall it be correct then to replace calls to error() and friends,
>> taking only format string with no-argument specifiers
>> to error_at_no_args() ? (similarly we shall need warning_at_no_args,
>> pedwar
Prathamesh Kulkarni writes:
>
> Shall it be correct then to replace calls to error() and friends,
> taking only format string with no-argument specifiers
> to error_at_no_args() ? (similarly we shall need warning_at_no_args,
> pedwarn_no_args, etc.)
I would guess so, yes.
>>
>> Also, you'd need
On Thu, Jan 23, 2014 at 5:02 PM, Dodji Seketeli wrote:
> "Joseph S. Myers" a écrit:
>
>> On Wed, 22 Jan 2014, Prathamesh Kulkarni wrote:
>>
>>> Unfortunately, I am not clear on how to check for format specifiers in
>>> string.
>>> Should I do it manually by checking the format string for specifi
On Thu, Jan 23, 2014 at 12:32:34PM +0100, Dodji Seketeli wrote:
> "Joseph S. Myers" a écrit:
>
> > On Wed, 22 Jan 2014, Prathamesh Kulkarni wrote:
> >
> >> Unfortunately, I am not clear on how to check for format specifiers in
> >> string.
> >> Should I do it manually by checking the format stri
> The *political* aspects are dictating the *technical* aspects.
Perhaps.
> So... like it or not, that makes this list exactly the right place to
> have this discussion.
No because the *people* that decide the political and technical aspects
are different and this list is for the latter, not the
On 23/01/14 12:42, Michael Witten wrote:
On Thu, Jan 23, 2014 at 11:04 AM, Duncan Sands wrote:
the... list is for technical rather than political discussion
That's just it; that's the whole point.
The *political* aspects are dictating the *technical* aspects.
Not for clang they aren't, so
On Thu, Jan 23, 2014 at 11:04 AM, Duncan Sands wrote:
> the... list is for technical rather than political discussion
That's just it; that's the whole point.
The *political* aspects are dictating the *technical* aspects.
So... like it or not, that makes this list exactly the right place to
hav
"Joseph S. Myers" a écrit:
> On Wed, 22 Jan 2014, Prathamesh Kulkarni wrote:
>
>> Unfortunately, I am not clear on how to check for format specifiers in
>> string.
>> Should I do it manually by checking the format string for specifiers
>> and call abort if found a no-argument specifier,
>> or is
Hi David,
> At any rate, if you want to bash the strategies of the GNU project,
these lists are the wrong place to go. Try doing it on the Clang list
though I am skeptical that they do not have better things to do as well.
the Clang list is for technical rather than political discussion, as y
Michael Witten writes:
> On Wed, Jan 22, 2014 at 2:33 PM, Jordi Gutiérrez Hermoso wrote:
>
>> The fact that these non-free tools are not based on gcc are a
>> testament to how proprietary software developers cannot plug into gcc,
>> and how clang is fostering non-free software.
>
> What does it m
On Wed, Jan 22, 2014 at 2:33 PM, Jordi Gutiérrez Hermoso wrote:
> The fact that these non-free tools are not based on gcc are a
> testament to how proprietary software developers cannot plug into gcc,
> and how clang is fostering non-free software.
What does it matter whether clang fosters non-fr
39 matches
Mail list logo
