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
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 "
On Tue, Apr 17, 2012 at 2:52 AM, Oleg Endo wrote:
> On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote:
>> On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu 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 th
On 4/16/2012 5:36 AM, Chiheng Xu wrote:
On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar 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 Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote:
> On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu 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.
> >
>
On 16 April 2012 10:36, Chiheng Xu wrote:
> On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar wrote:
>> hand, but to suggest banning all templates is not a supportable
>> notion.
>>
>
> Why ?
Because they're useful.
On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar wrote:
> hand, but to suggest banning all templates is not a supportable
> notion.
>
Why ?
--
Chiheng Xu
On Mon, Apr 16, 2012 at 3:48 PM, Duncan Sands 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 o
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 dir
On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu 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 of accessor
m
On 4/13/12, Chiheng Xu wrote:
> On Apr 9, 2012, Richard Guenther 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 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
> a
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 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 issu
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 fu
On Sat, Apr 14, 2012 at 4:09 AM, Robert Dewar wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>> wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably,
On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar 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 example,
On Sat, Apr 14, 2012 at 5:09 PM, Robert Dewar wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>> wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably,
On 4/13/2012 9:34 PM, Chiheng Xu wrote:
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
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.
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 ch
On Sat, Apr 14, 2012 at 9:15 AM, Chiheng Xu 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 Tue, Apr 10, 2012 at 4:46 PM, 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
On Tue, Apr 10, 2012 at 4:46 PM, 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 hierarchies for gcc: one for values rooted at ValExp, and one for
>> gimple stmts rooted at Gimp
On Tue, Apr 10, 2012 at 2:22 AM, Jakub Jelinek 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 conversion ne
On Mon, Apr 9, 2012 at 6:40 PM, Richard Guenther
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 provide a specifi
On Wed, Apr 4, 2012 at 8:04 PM, Richard Guenther
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 isolated sub-systems,
> like
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
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 have such
annoyances.
On Thu, Apr 12, 2012 at 6:30 PM, Richard Guenther
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 looking at gcc/*.c file
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 f
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
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 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 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
On Fri, 2012-04-13 at 10:29 -0500, Gabriel Dos Reis wrote:
> There is some repeat here. Over 13 years ago, people were screaming
> to have line wrapping by default -- because the diagnostic
> messages related to templates were just too long and too awful.
> I implemented line wrapping for g++ and
On Fri, Apr 13, 2012 at 9:11 AM, Ludovic Courtès
wrote:
> Hello,
>
> Richard Guenther skribis:
>
>> And since yesterday GCC shows
>>
>> t.C:2:10: error: expected ';' after class definition
>> class a {}
>> ^
>> t.C:6:1: error: expected ';' after struct definition
>> }
>> ^
>>
>> as w
Hello,
Richard Guenther skribis:
> And since yesterday GCC shows
>
> t.C:2:10: error: expected ';' after class definition
> class a {}
> ^
> t.C:6:1: error: expected ';' after struct definition
> }
> ^
>
> as we now enabled -fdiagnostics-show-caret by default.
How important is it t
On Thu, Apr 12, 2012 at 3:28 PM, Jonathan Wakely wrote:
> On 12 April 2012 22:53, Xinliang David Li wrote:
>> yes ..
>
> Excellent, thanks, and thanks for the link to the pdf, I hadn't seen
> it before and GCC does do pretty poorly with those examples.
The talk was given pretty recently ..
David
On 12 April 2012 22:53, Xinliang David Li wrote:
> yes ..
Excellent, thanks, and thanks for the link to the pdf, I hadn't seen
it before and GCC does do pretty poorly with those examples.
> thanks,
>
> David
>
> On Thu, Apr 12, 2012 at 2:51 PM, Jonathan Wakely
> wrote:
>> On 12 April 2012 22:3
yes ..
thanks,
David
On Thu, Apr 12, 2012 at 2:51 PM, Jonathan Wakely wrote:
> On 12 April 2012 22:32, Xinliang David Li wrote:
>> Thanks for preparing the wiki page. I have looked at the examples from
>> this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf
>> with trunk
On 12 April 2012 22:32, Xinliang David Li wrote:
> Thanks for preparing the wiki page. I have looked at the examples from
> this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf
> with trunk gcc. In some cases, gcc's warning matches that of clang but
> in majority of cases, gc
Thanks for preparing the wiki page. I have looked at the examples from
this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf
with trunk gcc. In some cases, gcc's warning matches that of clang but
in majority of cases, gcc either emits no warnings or worse ones. The
warnings in
> "Diego" == Diego Novillo writes:
Diego> Nice! What version of gdb has this support?
7.4.
Tom
On Thu, Apr 12, 2012 at 2:43 PM, Jonathan Wakely wrote:
> On 12 April 2012 11:41, Jonathan Wakely wrote:
>> Two more examples, then I'll save it for a wiki page instead of the
>> mailing list:
>
> And here it is:
>
> http://gcc.gnu.org/wiki/ClangDiagnosticsComparison
Thanks; this is useful.
-- G
On 12 April 2012 11:41, Jonathan Wakely wrote:
> Two more examples, then I'll save it for a wiki page instead of the
> mailing list:
And here it is:
http://gcc.gnu.org/wiki/ClangDiagnosticsComparison
On 4/12/12 3:40 PM, Tom Tromey wrote:
"Diego" == Diego Novillo 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 c
> "Diego" == Diego Novillo 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 don't thin
Hi,
Basile Starynkevitch 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 quite stable API that
On 12 April 2012 11:35, Richard Guenther wrote:
> And since yesterday GCC shows
>
> t.C:2:10: error: expected ';' after class definition
> class a {}
> ^
> t.C:6:1: error: expected ';' after struct definition
> }
> ^
>
> as we now enabled -fdiagnostics-show-caret by default.
Yep :-)
B
On Thu, Apr 12, 2012 at 12:01 PM, Jonathan Wakely wrote:
> On 11 April 2012 19:41, Pedro Alves wrote:
>> 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
On Thu, Apr 12, 2012 at 11:28 AM, Chiheng Xu 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 or adding new f
On 04/12/2012 11:01 AM, Jonathan Wakely wrote:
> Manu has filed lots of bugs in bugzilla with specific comparisons of
> GCC's diagnostics to Clang's.
>
> I'll start a page on the GCC wiki but I hope others will add to it.
> The people asking to see results should be the ones doing the
> compariso
On 11 April 2012 19:41, Pedro Alves wrote:
> 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
>> writte
On Wed, Apr 11, 2012 at 10:24 AM, Lawrence Crowl wrote:
> On 4/10/12, Jakub Jelinek 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 normal statements
>> (e.g. g
On Wed, Apr 11, 2012 at 11:11 PM, Miles Bader wrote:
> Ian Lance Taylor 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
Ian Lance Taylor 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, but to
Jonathan Wakely 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++ experts.
Ian
Andrew Pinski 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
> important ones).
No
On 4/11/12, Richard Guenther wrote:
> On Apr 11, 2012 Lawrence Crowl wrote:
> > On 4/10/12, Jakub Jelinek 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
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
> 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 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
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/delet
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
> >> >
On Wed, Apr 11, 2012 at 11:37 AM, Basile Starynkevitch
wrote:
> On Wed, 11 Apr 2012 10:30:36 -0700
> Xinliang David Li 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 b
On 11 April 2012 21:00, Xinliang David Li wrote:
> On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely
> 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
On Wed, Apr 11, 2012 at 11:17 AM, Andrew Pinski wrote:
> On Wed, Apr 11, 2012 at 10:24 AM, Xinliang David Li
> wrote:
>> On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
>> wrote:
>>> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel wrote:
On Wed, 2012-04-11 at 11:24 +0200, Richard Guenth
On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely 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 compiler in
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 1:37 PM, Basile Starynkevitch
wrote:
> On Wed, 11 Apr 2012 10:30:36 -0700
> Xinliang David Li 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
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 ke
On Wed, 11 Apr 2012 10:30:36 -0700
Xinliang David Li 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 teaching program
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 it
On Wed, Apr 11, 2012 at 10:24 AM, Xinliang David Li wrote:
> On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
> wrote:
>> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel wrote:
>>> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel w
On Wed, Apr 11, 2012 at 7:44 AM, David Edelsohn wrote:
> On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek 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
On Wed, Apr 11, 2012 at 6:21 AM, 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.
On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
wrote:
> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel wrote:
>> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel wrote:
>>> > Think about programmers new to GCC for a second, and ab
On Wed, Apr 11, 2012 at 5:57 AM, Torvald Riegel wrote:
> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel wrote:
>> > Think about programmers new to GCC for a second, and about code
>> > completion tools.
>>
>> Honestly I care 1000 time
On Wed, Apr 11, 2012 at 5:47 AM, Richard Guenther
wrote:
> On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt
> 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 requiri
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
a)
On Wed, Apr 11, 2012 at 5:43 AM, Marek Polacek 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 ever be in C+
On Wed, Apr 11, 2012 at 2:43 AM, Richard Guenther
wrote:
> On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl wrote:
>> On 4/10/12, Jakub Jelinek wrote:
>>> That when stepping through code in the debugger you keep
>>> enterring/exiting these one liner inlines, most of them really
>>> should be at l
On Wed, Apr 11, 2012 at 2:16 AM, Richard Guenther
wrote:
> On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo wrote:
>> On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
>>>
>>> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn
>>> wrote:
>>>
Also, it will be more convenient to make this change incre
On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek 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 people who in
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 ti
On Wed, 2012-04-11 at 15:13 +0200, Richard Guenther wrote:
> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel wrote:
> > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
> >> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel wrote:
> >> > Think about programmers new to GCC for a second, an
On Wed, Apr 11, 2012 at 8:28 AM, Jakub Jelinek 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 people who in
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++ be
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, an
On Wed, Apr 11, 2012 at 8:13 AM, Richard Guenther
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 wit
On Wed, Apr 11, 2012 at 7:34 AM, Bernd Schmidt 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 to C++?
>
> Fran
2012/4/11 Paweł Sikora :
> 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 @ http://wik
On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel wrote:
> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel wrote:
>> > Think about programmers new to GCC for a second, and about code
>> > completion tools.
>>
>> Honestly I care 1000 time
On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel 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 programmers
On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt 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 to C++?
>
> Fran
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 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 wha
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 Wed, Apr 11, 2012 at 10:06 AM, Eric Botcazou 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
>> for GCC's nee
On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl wrote:
> On 4/10/12, Jakub Jelinek 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 normal statements
>> (e.g. gl
On Wed, Apr 11, 2012 at 3:35 AM, Lawrence Crowl wrote:
> On 4/10/12, Richard Guenther wrote:
>> On Apr 9, 2012 Lawrence Crowl wrote:
>> > On 4/9/12, Jakub Jelinek wrote:
>> > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
>> > > > A build conversion to C++ is a precondition t
1 - 100 of 196 matches
Mail list logo
