On Tue, 3 Apr 2012, Pawe�~B Sikora wrote:
i'm only suggesting that astyle (or another tool) can be used in svn
pre-commit
hook to verifying gnu formatting rules (incoming files can be extracted from
I think it's a bad idea to check anything in a pre-commit hook that isn't
also covered by a
On 4/16/2012 5:36 AM, Chiheng Xu wrote:
On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewarde...@adacore.com wrote:
hand, but to suggest banning all templates is not a supportable
notion.
Why ?
Because some simple uses of templates are very useful, and
not problematic from any point of view.
On Tue, Apr 17, 2012 at 2:52 AM, Oleg Endo oleg.e...@t-online.de wrote:
On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote:
On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu chiheng...@gmail.com wrote:
And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or
On Wed, 2012-04-18 at 06:03 +0800, Chiheng Xu wrote:
Sorry, I don't know what is the benefit of const ivars.
I didn't say there's a benefit of using const ivars in this hypothetical
case. It's just another possible option of doing certain things.
But if you use tree-code instead of
And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or logic), the most important thing about them is
how to access their fields.
Given the above assumption, now I doubt the necessity of accessor
macros or C++ getter/setter method.
Is tree-code more
On Mon, Apr 16, 2012 at 3:48 PM, Duncan Sands baldr...@free.fr wrote:
And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or logic), the most important thing about them is
how to access their fields.
Given the above assumption, now I doubt the necessity
On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar de...@adacore.com wrote:
hand, but to suggest banning all templates is not a supportable
notion.
Why ?
--
Chiheng Xu
On 16 April 2012 10:36, Chiheng Xu wrote:
On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar de...@adacore.com wrote:
hand, but to suggest banning all templates is not a supportable
notion.
Why ?
Because they're useful.
On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote:
On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu chiheng...@gmail.com wrote:
And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or logic), the most important thing about them is
how to access their
On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu chiheng...@gmail.com wrote:
And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or logic), the most important thing about them is
how to access their fields.
Given the above assumption, now I doubt the
On Sat, Apr 14, 2012 at 9:15 AM, Chiheng Xu chiheng...@gmail.com wrote:
The rest, 440 or so of them, is below 50 KB, which contribute 75% of
The rest, 440 or so of them, is below 50 KB, which contribute 25% of
--
Chiheng Xu
On 4/13/2012 9:15 PM, Chiheng Xu wrote:
So, I can say, most of the GCC source code is in large files.
And this also hold for language front-ends.
I see nothing inherently desirable about having all small files.
For example, in GNAT, yes, some files are large, sem_ch3 (semantic
analysis for
On 4/13/2012 9:34 PM, Chiheng Xu wrote:
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++ compiler? ...
Probably, if you can refrain from using some advance C++
On Sat, Apr 14, 2012 at 5:09 PM, Robert Dewar de...@adacore.com wrote:
On 4/13/2012 9:34 PM, Chiheng Xu wrote:
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++
On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar de...@adacore.com wrote:
On 4/13/2012 9:15 PM, Chiheng Xu wrote:
So, I can say, most of the GCC source code is in large files.
And this also hold for language front-ends.
I see nothing inherently desirable about having all small files.
For
On Sat, Apr 14, 2012 at 4:09 AM, Robert Dewar de...@adacore.com wrote:
On 4/13/2012 9:34 PM, Chiheng Xu wrote:
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++
On 4/14/2012 6:38 AM, Chiheng Xu wrote:
Actually, I only partially agree with you on this. And I didn't say
smaller is necessarily better.
But normally, high cohesion and low coupling code tend not be large.
Normally large files tend to export only few highly related entry
points. Most of the
On 4/14/2012 6:39 AM, Gabriel Dos Reis wrote:
Indeed, the notion that 'namspace' is advance is troublesome.
Similarly I would find any notion that simple uses and definitions
of templates (functions, datatypes) advanced a bit specious.
Indeed! In the case of templates there is a real issue,
On 4/14/2012 6:02 AM, Chiheng Xu wrote:
If debugger fully support namespace, that will be nice. I just say,
in case debugger have trouble with namespace, you can avoid it.
But personally, when I write C++ code, I never use namespace. I
always prefix my class name(and corresponding source file
On 14 April 2012 11:02, Chiheng Xu wrote:
If debugger fully support namespace, that will be nice. I just say,
in case debugger have trouble with namespace, you can avoid it.
So it's completely unfounded speculation then.
But personally, when I write C++ code, I never use namespace. I
On 4/13/12, Chiheng Xu chiheng...@gmail.com wrote:
On Apr 9, 2012, Richard Guenther richard.guent...@gmail.com wrote:
Certainly there are cases where the type must be made more specific,
and getting the wrong type here would necessarily be a dynamic check.
However, the number of dynamic checks
On 11/04/2012 07:55, Jakub Jelinek wrote:
On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote:
The standard says they need not ignore them.
I was thinking more about iterating over the contents. What in the
current code is an indirect function call inside of a loop becomes
mostly
On 11/04/2012 22:13, Eric Botcazou wrote:
So, you only know it's 2 tokens once you know all of tree.def? I'm
aware that this is just some arbitrary example, but I believe this
actually strengthens the concern I had.
Well, if you don't know of FIELD_DECL, you won't go very far, really.
On 11/04/2012 13:57, Torvald Riegel wrote:
Please don't dismiss this so easily. Of course this is just an example
and nothing major, but I believe many people will use tab completion on
the shell, for example, and code completion is really similar. On the
shell, or with paths names, you
On 11/04/2012 14:21, Bernd Schmidt wrote:
On 04/11/2012 02:57 PM, Torvald Riegel wrote:
However, the concern you raised is only one part of the problem. The
other is that, put in a simplified way, GCC is competing with LLVM about
new and/or non-fulltime-compiler developers. For me, it looks
On 11/04/2012 20:30, Tobias Burnus wrote:
In any case, the gfortran front end cannot really afford to loose
developers, given that it is a hobbyist* project and given that
attracting new developers is difficult.
Tobias
* In terms of the development; I assume that those who use it for
On Thu, Apr 12, 2012 at 6:30 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Yes, files are too big - but splitting them is not easy unless you can
figure out
a hierarchy that you can expose. The largest file is dwarf2out.c with
22825 lines,
but the average is more like 2000 (just
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++ compiler? ...
Probably, if you can refrain from using some advance C++
features(namespace, template, etc.), you will not
On Wed, Apr 4, 2012 at 8:04 PM, Richard Guenther
richard.guent...@gmail.com wrote:
I agree for the idea of converting all of GCC to C++ (whatever that means).
I disagree for the part making the internal infrastructure easier to use,
understand and maintain. Which means targeting mostly
On Mon, Apr 9, 2012 at 6:40 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Certainly there are cases where the type must be made more specific,
and getting the wrong type here would necessarily be a dynamic check.
However, the number of dynamic checks can be substantially reduced.
To
On Tue, Apr 10, 2012 at 2:22 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
A build conversion to C++ is a precondition to any source change
using C++, though the two could be bundled into one patch. In any
event, I agree that the
On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
Class hierarchy is one such feature that is useful. Assuming we have
two hierarchies for gcc: one for values rooted at ValExp, and one for
gimple stmts
On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek ja...@redhat.com wrote:
*) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
e.g.
exp-as_component_ref().get_field() ..
exp-as_mem_access().get_base() ...
Ian Lance Taylor i...@google.com writes:
And GCC usually has better diagnostic than clang except in those few
areas which it does not (those some might say those areas are the most
important ones).
No. clang's diagnostics for C++ are much much better than GCC's.
Obviously GCC's can improve,
On Wed, Apr 11, 2012 at 11:11 PM, Miles Bader mi...@gnu.org wrote:
Ian Lance Taylor i...@google.com writes:
And GCC usually has better diagnostic than clang except in those few
areas which it does not (those some might say those areas are the most
important ones).
No. clang's diagnostics
On Wed, Apr 11, 2012 at 10:24 AM, Lawrence Crowl cr...@google.com wrote:
On 4/10/12, Jakub Jelinek ja...@redhat.com wrote:
That when stepping through code in the debugger you keep
enterring/exiting these one liner inlines, most of them really
should be at least by default considered just as
On Thu, Apr 12, 2012 at 11:28 AM, Chiheng Xu chiheng...@gmail.com wrote:
The reason why GCC's code is very hard to hack is not simple. In part,
this is because GCC use a very old, extremely hard to understand build
system. In part, this is because GCC developer are more focused on
fixing bugs
Hi,
Basile Starynkevitch bas...@starynkevitch.net skribis:
My feeling is that the plugin ability of GCC should help academia to work
more on (that
is, inside) GCC, to only to use GCC.
Yes, except that, on one hand, they have a library stack with stable
APIs, and on the other, an otherwise
Diego == Diego Novillo dnovi...@google.com writes:
Diego Tom, I'm thinking of that patch on black listing functions. There was
Diego also the idea of a command that would only step in the outermost
Diego function call of an expression.
That patch went in. The new command is called skip.
I
On 4/12/12 3:40 PM, Tom Tromey wrote:
Diego == Diego Novillodnovi...@google.com writes:
Diego Tom, I'm thinking of that patch on black listing functions. There was
Diego also the idea of a command that would only step in the outermost
Diego function call of an expression.
That patch went
Diego == Diego Novillo dnovi...@google.com writes:
Diego Nice! What version of gdb has this support?
7.4.
Tom
On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote:
The standard says they need not ignore them.
I was thinking more about iterating over the contents. What in the
current code is an indirect function call inside of a loop becomes
mostly be inline functions in a C++ iterator
On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote:
In the short term, a partial conversion to C++ gains us nothing. Even
ignoring the bugs inevitably caused by any such project, we'll end up
with a strange mish-mash of styles for a very long time, which instead
of helping
On Wed, Apr 11, 2012 at 2:01 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote:
In the short term, a partial conversion to C++ gains us nothing. Even
ignoring the bugs inevitably caused by any such project, we'll end up
with a strange
when you say that, do you mean you would prefer and expect:
1. native C++ style, or
2. you would like the C-style round-about and paraphrasing to remain
unperturbed
?
The reason I ask is that I expect a proper C++ implementation would come
with a C++-native style of usage.
I don't
On Wed, Apr 11, 2012 at 02:45:55AM -0500, Gabriel Dos Reis wrote:
On Wed, Apr 11, 2012 at 2:01 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote:
In the short term, a partial conversion to C++ gains us nothing. Even
ignoring the bugs
On Wed, Apr 11, 2012 at 2:42 AM, Eric Botcazou ebotca...@adacore.com wrote:
when you say that, do you mean you would prefer and expect:
1. native C++ style, or
2. you would like the C-style round-about and paraphrasing to remain
unperturbed
?
The reason I ask is that I expect a proper
But IMHO not sufficient for a switch. The GCC C++ proponents should do
more on a branch to convince. Yes, the syntactic suger for vec.h isn't
very nice, but the actual implementation is very clever and heavily tuned
for GCC's needs; if we convert to C++ just because of vec.[ch], we open
Expressing an idea in C takes me more lines (roughly 2-3 fold) than
in C++, so I am a bit puzzled by your observation.
We're specifically discussing vec.[ch] here, which is a clever attempt at
implementing vectors in C, with macro magic all over the place.
--
Eric Botcazou
On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo dnovi...@google.com wrote:
On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohndje@gmail.com
wrote:
Also, it will be more convenient to make this change incrementally,
but the GCC community probably
On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel trie...@redhat.com wrote:
On Tue, 2012-04-10 at 18:24 +0200, Michael Matz wrote:
Hi,
On Tue, 10 Apr 2012, Xinliang David Li wrote:
exp-as_component_ref().get_field() ..
Actually it's not questionable. The above stuff is
2012/4/10 Dave Korn dave.korn.cyg...@gmail.com:
On 10/04/2012 17:41, Paweł Sikora wrote:
On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
Class hierarchy is one such feature that is useful. Assuming we have
two
On Wed, Apr 11, 2012 at 3:35 AM, Lawrence Crowl cr...@google.com wrote:
On 4/10/12, Richard Guenther richard.guent...@gmail.com wrote:
On Apr 9, 2012 Lawrence Crowl cr...@google.com wrote:
On 4/9/12, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence
On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl cr...@google.com wrote:
On 4/10/12, Jakub Jelinek ja...@redhat.com wrote:
That when stepping through code in the debugger you keep
enterring/exiting these one liner inlines, most of them really
should be at least by default considered just as
On Wed, Apr 11, 2012 at 10:06 AM, Eric Botcazou ebotca...@adacore.com wrote:
But IMHO not sufficient for a switch. The GCC C++ proponents should do
more on a branch to convince. Yes, the syntactic suger for vec.h isn't
very nice, but the actual implementation is very clever and heavily tuned
On 04/11/2012 02:10 AM, Eric Botcazou wrote:
Expressing an idea in C takes me more lines (roughly 2-3 fold) than
in C++, so I am a bit puzzled by your observation.
We're specifically discussing vec.[ch] here, which is a clever attempt at
implementing vectors in C, with macro magic all over the
On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
I have been having difficulty following the twists and the turns and
the goal post moving.
Are you essentially requiring to see GCC rewritten in C++ before we
switch to C++?
Frankly, despite all this discussion, we still don't really know what
On Tue, Apr 10, 2012 at 10:54:01AM -0700, Xinliang David Li wrote:
manipulation -- be it C or C++. However I think this is really more
about the general perceptions and how future developers feel about it.
If GCC would ever be in C++, that would be a very strong argument for
me _not_ to touch
On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
I have been having difficulty following the twists and the turns and
the goal post moving.
Are you essentially requiring to see GCC rewritten in C++ before we
switch
On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel trie...@redhat.com wrote:
Think about programmers new to GCC for a second, and about code
completion tools.
Honestly I care 1000 times more for existing GCC developers. Before
new
On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel trie...@redhat.com wrote:
On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel trie...@redhat.com wrote:
Think about programmers new to GCC for a second, and about code
completion tools.
2012/4/11 Paweł Sikora pl...@agmk.net:
On Wednesday 11 of April 2012 14:57:53 Torvald Riegel wrote:
Now, how many release cycles do we have until LLVM is basically good
enough to be used as a distro compiler
freebsd-9 switches to clang/llvm as a distro compiler.
some info @
On Wed, Apr 11, 2012 at 7:34 AM, Bernd Schmidt ber...@codesourcery.com wrote:
On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
I have been having difficulty following the twists and the turns and
the goal post moving.
Are you essentially requiring to see GCC rewritten in C++ before we
switch
On Wed, Apr 11, 2012 at 8:13 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Please don't dismiss this so easily. Of course this is just an example
and nothing major, but I believe many people will use tab completion on
the shell, for example, and code completion is really similar. On
On 04/11/2012 02:57 PM, Torvald Riegel wrote:
However, the concern you raised is only one part of the problem. The
other is that, put in a simplified way, GCC is competing with LLVM about
new and/or non-fulltime-compiler developers. For me, it looks like LLVM
is more appealing to them, and I
On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
The reason why I am mystified is that the people who seem to argue
that it would be pointless to convert the existing codebase to C++ seem
to be the same people who insist on seeing significant part of GCC
converted to C++
On Wed, Apr 11, 2012 at 8:28 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
The reason why I am mystified is that the people who seem to argue
that it would be pointless to convert the existing codebase to C++ seem
to be the same
On 11 April 2012 13:57, Torvald Riegel wrote:
Now, how many release cycles do we have until LLVM is basically good
enough to be used as a distro compiler (e.g., until code quality and
confidence in bug freedom is sufficiently similar)? If we haven't
ensured that GCC is appealing by this time,
On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
The reason why I am mystified is that the people who seem to argue
that it would be pointless to convert the existing codebase to C++ seem
to be the same
On Wed, Apr 11, 2012 at 2:16 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo dnovi...@google.com wrote:
On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohndje@gmail.com
wrote:
Also, it will
On Wed, Apr 11, 2012 at 2:43 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl cr...@google.com wrote:
On 4/10/12, Jakub Jelinek ja...@redhat.com wrote:
That when stepping through code in the debugger you keep
enterring/exiting these one
On Wed, Apr 11, 2012 at 5:43 AM, Marek Polacek pola...@redhat.com wrote:
On Tue, Apr 10, 2012 at 10:54:01AM -0700, Xinliang David Li wrote:
manipulation -- be it C or C++. However I think this is really more
about the general perceptions and how future developers feel about it.
If GCC would
Mostly agreed. In particular, the discussions should be more concrete
-- instead of voting on moving everything to C++ which can create a
huge chaos, we should first carefully partition the components that
are candidates for the migration (as mentioned by Richard). For
instance,
1) core APIs
On Wed, Apr 11, 2012 at 5:47 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
I have been having difficulty following the twists and the turns and
the goal post
On Wed, Apr 11, 2012 at 5:57 AM, Torvald Riegel trie...@redhat.com wrote:
On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel trie...@redhat.com wrote:
Think about programmers new to GCC for a second, and about code
completion tools.
On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel trie...@redhat.com wrote:
On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel trie...@redhat.com wrote:
On Wed, Apr 11, 2012 at 6:21 AM, Bernd Schmidt ber...@codesourcery.com wrote:
On 04/11/2012 02:57 PM, Torvald Riegel wrote:
However, the concern you raised is only one part of the problem. The
other is that, put in a simplified way, GCC is competing with LLVM about
new and/or
On Wed, Apr 11, 2012 at 7:44 AM, David Edelsohn dje@gmail.com wrote:
On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
The reason why I am mystified is that the people who seem to argue
that it would be
On 11 April 2012 18:24, Xinliang David Li wrote:
Yes, GCC is still in some comfortable zones such as generated code
quality, performance, etc, but the advantage and gap is quickly
reducing (e.g, LLVM is the default compiler in Xcode) -- and other
advantages in LLVM (will soon) outweigh its
On Wed, 11 Apr 2012 10:30:36 -0700
Xinliang David Li davi...@google.com wrote:
[..]
yes -- GCC is not considered old and not 'cool' -- so it is hard to
advertise. One criteria to see GCC's future popularity is how widely
it is adopted by academia ..
Do you mean used by academia (including
On 04/11/2012 07:26 PM, Jonathan Wakely wrote:
GCC's diagnostics have got a lot better recently.
The http://clang.llvm.org/diagnostics.html page compares clang's
diagnostics to GCC 4.2, which was outdated long before that page was
written.
It doesn't help GCC's cause when people keep
On Wed, Apr 11, 2012 at 1:37 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Wed, 11 Apr 2012 10:30:36 -0700
Xinliang David Li davi...@google.com wrote:
[..]
yes -- GCC is not considered old and not 'cool' -- so it is hard to
advertise. One criteria to see GCC's future popularity
Torvald Riegel wrote:
On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
Honestly I care 1000 times more for existing GCC developers. Before
new programmers will have an easier time with GCC_existing_ GCC
developers will have to spend at least two GCC release cycles (that's
On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 11 April 2012 18:24, Xinliang David Li wrote:
Yes, GCC is still in some comfortable zones such as generated code
quality, performance, etc, but the advantage and gap is quickly
reducing (e.g, LLVM is the default
On Wed, Apr 11, 2012 at 11:17 AM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Apr 11, 2012 at 10:24 AM, Xinliang David Li davi...@google.com
wrote:
On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel
On 11 April 2012 21:00, Xinliang David Li davi...@google.com wrote:
On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely jwakely@gmail.com
wrote:
On 11 April 2012 18:24, Xinliang David Li wrote:
Yes, GCC is still in some comfortable zones such as generated code
quality, performance, etc,
On Wed, Apr 11, 2012 at 11:37 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Wed, 11 Apr 2012 10:30:36 -0700
Xinliang David Li davi...@google.com wrote:
[..]
yes -- GCC is not considered old and not 'cool' -- so it is hard to
advertise. One criteria to see GCC's future
On Wed, 2012-04-11 at 21:30 +0200, Tobias Burnus wrote:
Torvald Riegel wrote:
On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
Honestly I care 1000 times more for existing GCC developers. Before
new programmers will have an easier time with GCC_existing_ GCC
developers
On Wednesday 11 of April 2012 11:43:36 Richard Guenther wrote:
() The overloadable operator new means that memory can be
_implicitly_ allocated in the right place.
Implicit allocation is bad. In a compiler you want to _see_ where you
spend memory.
in c++ you can overload new/delete
On Wed, 2012-04-11 at 01:14 +0200, Eric Botcazou wrote:
I can't derive a definition of token from your example that seems
meaningful. It can't be parser tokens I assume, because you split
GET_FIELD_DECL (but why in 2 not 3?).
FIELD_DECL is a single object, see tree.def.
So, you only
So, you only know it's 2 tokens once you know all of tree.def? I'm
aware that this is just some arbitrary example, but I believe this
actually strengthens the concern I had.
Well, if you don't know of FIELD_DECL, you won't go very far, really.
--
Eric Botcazou
On Wed, 2012-04-11 at 23:13 +0200, Eric Botcazou wrote:
So, you only know it's 2 tokens once you know all of tree.def? I'm
aware that this is just some arbitrary example, but I believe this
actually strengthens the concern I had.
Well, if you don't know of FIELD_DECL, you won't go very
On 4/11/12, Richard Guenther richard.guent...@gmail.com wrote:
On Apr 11, 2012 Lawrence Crowl cr...@google.com wrote:
On 4/10/12, Jakub Jelinek ja...@redhat.com wrote:
That when stepping through code in the debugger you keep
enterring/exiting these one liner inlines, most of them
Andrew Pinski pins...@gmail.com writes:
The main reason why LLVM is the default compiler in XCode is license
rather any technical reason.
Yes.
And GCC usually has better diagnostic than clang except in those few
areas which it does not (those some might say those areas are the most
Jonathan Wakely jwakely@gmail.com writes:
I get my views on their relative merits from actually using GCC and
clang, not from out of date webpages.
Me too, and I think clang's are better.
Simply having caret diagnostics and good suggestions are quite important
for people who are not C++
On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
Class hierarchy is one such feature that is useful. Assuming we have
two hierarchies for gcc: one for values rooted at ValExp, and one for
gimple stmts rooted at GimpInst.
1) For IR browsing,
*) all the macro accessors
On Mon, Apr 9, 2012 at 8:51 PM, Lawrence Crowl cr...@google.com wrote:
On 4/9/12, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
A build conversion to C++ is a precondition to any source change
using C++, though the two could be bundled
On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li davi...@google.com wrote:
On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 04/04/2012 11:06 AM, Richard Guenther wrote:
So -
Hi,
On Tue, 10 Apr 2012, Jakub Jelinek wrote:
*) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
e.g.
exp-as_component_ref().get_field() ..
exp-as_mem_access().get_base() ...
exp-as_mem_acesss().get_address() -- produces
On Tue, Apr 10, 2012 at 8:26 AM, Michael Matz m...@suse.de wrote:
Hi,
On Tue, 10 Apr 2012, Jakub Jelinek wrote:
*) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
e.g.
exp-as_component_ref().get_field() ..
1 - 100 of 177 matches
Mail list logo
