2010/4/13 Dave Korn :
> Until I find time to do a more major rewrite, anyone who wants to do testing
> on Cygwin could do worse than apply the sticking-plaster patch that I posted
> at:
>
> http://www.mail-archive.com/cygwin-patc...@cygwin.com/msg04677.html
>
> and build themselves a locally mod
Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Diego
Novillo
Sent: Tuesday, April 13, 2010 11:06 PM
To: Steven Bosscher
Cc: Jack Howarth; Paolo Bonzini; Dave Korn; Manuel López-Ibáñez; Duncan Sands;
gcc@gcc.gnu.org
Subject: Re: dragonegg in FSF gcc?
On 04/14/2010 03:36 PM, Jack Howarth wrote:
On Wed, Apr 14, 2010 at 08:24:35AM +0200, Duncan Sands wrote:
Hi Steven,
FWIW, this sounds great and all... but I haven't actually seen any
comparisons of GCC vs. LLVM with DragonEgg. A search with Google
doesn't give me any results.
Can you point o
On Wed, Apr 14, 2010 at 08:24:35AM +0200, Duncan Sands wrote:
> Hi Steven,
>
>> FWIW, this sounds great and all... but I haven't actually seen any
>> comparisons of GCC vs. LLVM with DragonEgg. A search with Google
>> doesn't give me any results.
>>
>> Can you point out some postings where people a
Hi Steven,
FWIW, this sounds great and all... but I haven't actually seen any
comparisons of GCC vs. LLVM with DragonEgg. A search with Google
doesn't give me any results.
Can you point out some postings where people actually made a
comparison between GCC and LLVM with DragonEgg?
I gave some
On Wed, Apr 14, 2010 at 12:57:41AM +0200, Steven Bosscher wrote:
> On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth
> wrote:
> > Rather than viewing dragon-egg as some sort
> > of lamprey which is feeding off of the FSF gcc project,
> > we should welcome the competition from a direct comparison
> >
On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth wrote:
> Rather than viewing dragon-egg as some sort
> of lamprey which is feeding off of the FSF gcc project,
> we should welcome the competition from a direct comparison
> of alternative back/middle ends (not fear it).
FWIW, this sounds great and al
On Tue, Apr 13, 2010 at 16:51, Steven Bosscher wrote:
> You say you see benefits for both compilers. What benefits do you see
> for GCC then, if I may ask? And what can GCC take from LLVM? (And I
> mean the FSF GCC, long term.) This is an honest question, because I
> personally really don't see a
On 13/04/2010 17:57, Paolo Bonzini wrote:
> The fact that testing under Cygwin is so much slower certainly has an
> impact.
It gets more manageable at -j levels, but there's an underlying bug in the
Cygwin DLL's process info management that causes expect to fall into
cpu-spinning lockups and
On Tue, Apr 13, 2010 at 10:19 PM, Diego Novillo wrote:
> Personally, I would love to see DragonEgg used to bridge between gcc
> and llvm. This will bring lots of benefits to both compilers, since
> we'll be able to easily compare and take from each other.
You say you see benefits for both compil
On Tue, Apr 13, 2010 at 15:16, Jack Howarth wrote:
> It is unclear to me what the original intentions were when the
> plugin infrastructure was created. That is, was it envisioned that
> FSF could accumulate the plugins directly in the source tree to
> ensure they were well maintained across FS
On 04/13/2010 09:16 PM, Jack Howarth wrote:
Paolo,
It is unclear to me what the original intentions were when the
plugin infrastructure was created. That is, was it envisioned that
FSF could accumulate the plugins directly in the source tree to
ensure they were well maintained across FSF gcc
On Tue, Apr 13, 2010 at 12:21:09PM -0700, Andrew Pinski wrote:
> On Tue, Apr 13, 2010 at 10:22 AM, Steven Bosscher
> wrote:
> > There are already plugins in the FSF gcc source tree. Well, OK, just
> > one (lto-plugin) but there aren't very many plugins at the moment that
> > are suitable for incl
On Tue, Apr 13, 2010 at 10:22 AM, Steven Bosscher wrote:
> There are already plugins in the FSF gcc source tree. Well, OK, just
> one (lto-plugin) but there aren't very many plugins at the moment that
> are suitable for inclusion in the FSF tree (i.e. not as tightly tied
> to a GCC feature that GC
On Tue, Apr 13, 2010 at 07:18:12PM +0200, Paolo Bonzini wrote:
> On 04/13/2010 07:14 PM, Jack Howarth wrote:
>> Paolo,
>> I hope you don't think I was trolling in my initial post. Assuming
>> plugins will eventually be welcomed into the FSF gcc source tree in
>> general, there is a valid argume
On Tue, Apr 13, 2010 at 7:14 PM, Jack Howarth wrote:
> I hope you don't think I was trolling in my initial post. Assuming
> plugins will eventually be welcomed into the FSF gcc source tree in
> general, there is a valid argument for having dragon-egg present with
> a configure option that build
On 04/13/2010 07:14 PM, Jack Howarth wrote:
Paolo,
I hope you don't think I was trolling in my initial post. Assuming
plugins will eventually be welcomed into the FSF gcc source tree in
general, there is a valid argument for having dragon-egg present with
a configure option that builds it if
On Tue, Apr 13, 2010 at 07:05:17PM +0200, Paolo Bonzini wrote:
> On 04/12/2010 04:18 PM, Dave Korn wrote:
>> Could anyone really believe that without being a grade A tinfoil-hat
>> wearing crazy? More precisely, could anyone capable of the kind of
>> rational thought processes that they'd need to
On 04/12/2010 04:18 PM, Dave Korn wrote:
Could anyone really believe that without being a grade A tinfoil-hat
wearing crazy? More precisely, could anyone capable of the kind of
rational thought processes that they'd need to have in order to be
able to make any kind of contribution to the GCC pro
On 04/11/2010 06:50 PM, Dave Korn wrote:
Grepping the -patches archives to see which platforms submitted
patches get testing on would also be interesting, but somewhat
harder owing to the more free-form nature of the text there. Still,
a two-to-one ratio of linux to rest-of-the-world would be in
On 04/11/2010 06:26 PM, Duncan Sands wrote:
Hi Robert,
b) better behavior for undefined cases
this is one of the problems with using LLVM with the Ada front-end.
LLVM makes pretty aggressive deductions when it sees undefined
behaviour
These do not seem to point at LLVM's optimizer bugs/aggr
"Weddington, Eric" writes:
>From my perspective (and someone correct me if I'm wrong) it is
>easier for LLVM to do such marketing and focus on usability details
>because they seem to have a central driver to the project, whether
>person/group (founder(s)/champion(s)). GCC is, what I would call,
>
Weddington, Eric wrote:
From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com]
The fact is that it is (perceived as) more difficult to contribute to
GCC than LLVM/Clang for the reasons we all know already.
From my perspective (and someone correct me if I'm wrong) it is easier for LLVM
to
On 12/04/2010 17:03, Steven Bosscher wrote:
> On Mon, Apr 12, 2010 at 5:59 PM, Jack Howarth wrote:
>
>> I have opened PR43729, "MachO LTO support needed for darwin", to discuss
>> this. Can you point me at Dave's previous patches that added LTO-suppport
>> to a non-ELF platform?
>
> I've linked
> -Original Message-
> From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com]
> Sent: Monday, April 12, 2010 8:27 AM
> To: Dave Korn
> Cc: Jack Howarth; Steven Bosscher; Duncan Sands; gcc@gcc.gnu.org
> Subject: Re: dragonegg in FSF gcc?
>
> The fact is that i
On Mon, Apr 12, 2010 at 5:59 PM, Jack Howarth wrote:
> I have opened PR43729, "MachO LTO support needed for darwin", to discuss
> this. Can you point me at Dave's previous patches that added LTO-suppport
> to a non-ELF platform?
I've linked your new PR to the existing "LTO doesn't work on non-E
On Mon, Apr 12, 2010 at 05:45:52PM +0200, Steven Bosscher wrote:
> On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth
> wrote:
> >> Err, well. I do not see how most of the code is OS specific
> >> anyway - there is _very_ little code in GCC that is OS specific.
> >>
> >> Richard.
> >
> > Richard,
> >
On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth wrote:
>> Err, well. I do not see how most of the code is OS specific
>> anyway - there is _very_ little code in GCC that is OS specific.
>>
>> Richard.
>
> Richard,
> Except for LTO (for which dragon-egg represents a way around
> since we can use t
On Mon, Apr 12, 2010 at 11:00:13AM -0400, Alfred M. Szmidt wrote:
> If the dragonegg and/or LLVM copyright was assigned to the FSF, which
> is a prerequisit for anything included in GCC and not what license the
> program is under currently, then I'm quite sure that the GCC
> maintainers would be mo
If the dragonegg and/or LLVM copyright was assigned to the FSF, which
is a prerequisit for anything included in GCC and not what license the
program is under currently, then I'm quite sure that the GCC
maintainers would be more than happy to include both.
On 12 April 2010 16:18, Dave Korn wrote:
>
> Could anyone really believe that without being a grade A tinfoil-hat wearing
> crazy? More precisely, could anyone capable of the kind of rational thought
Then, you do not read LWN comments, OS news or BSD mailing lists. You
probably do well for you
On 12/04/2010 07:47, Manuel López-Ibáñez wrote:
> On 12 April 2010 00:38, Dave Korn wrote:
>> On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
>>
>>> [ ... ] lack of test results in some platforms does not mean
>>> that GCC developers are uninterested on supporting those platforms and
>>> much less
On Mon, Apr 12, 2010 at 03:42:39PM +0200, Richard Guenther wrote:
> On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth
> wrote:
> > On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
> >> On 12 April 2010 00:38, Dave Korn wrote:
> >> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth wrote:
> On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
>> On 12 April 2010 00:38, Dave Korn wrote:
>> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
>> >
>> >> [ ... ] lack of test results in some platforms does not mean
>> >
Jack Howarth wrote:
Manuel,
What I meant to say was that the reality of the situation is
that 90%+ of the code (by line) is probably created by paid
employees and the way things have shaken out has placed the bulk
of those on linux.
Just a note, AdaCore is certainly not Linux-only-centric
On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
> On 12 April 2010 00:38, Dave Korn wrote:
> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
> >
> >> [ ... ] lack of test results in some platforms does not mean
> >> that GCC developers are uninterested on supporting those pl
Hi Jonathan,
egcs code was always license-compatible with GCC and was always
assigned to the FSF
The difference is quite significant.
both dragonegg and LLVM are license-compatible with GCC. The dragonegg
code is licensed under GPLv2 or later, while LLVM is licensed under the
University of I
On 12 April 2010 00:38, Dave Korn wrote:
> On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
>
>> [ ... ] lack of test results in some platforms does not mean
>> that GCC developers are uninterested on supporting those platforms and
>> much less that they are against supporting those platforms. The
On 11 April 2010 17:17, Jack Howarth wrote:
>
> I would also add that some of this seems like deja vu from the
> egcs days. Granted it is extremely unlikely, but who is to say that
> at some future date, if the license conflicts subside, that FSF gcc
> might decide that llvm wasn't so bad for the
On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
> [ ... ] lack of test results in some platforms does not mean
> that GCC developers are uninterested on supporting those platforms and
> much less that they are against supporting those platforms. The GCC
> community haven't forbidden anyone from co
On 11 April 2010 18:50, Dave Korn wrote:
>
> Here's a very crude indicator:
No, it is not. Apart from all the points that Laurent raised in a
previous email, lack of test results in some platforms does not mean
that GCC developers are uninterested on supporting those platforms and
much less that
> I don't see how this is gcc the compiler shooting itself in the foot.
Simply because LLVM isn't part of the GNU project.
--
Eric Botcazou
On Sun, 2010-04-11 at 17:50 +0100, Dave Korn wrote:
> On 11/04/2010 16:23, Manuel López-Ibáñez wrote:
> > On 11 April 2010 16:17, Jack Howarth wrote:
> >> ps I've watched FSF gcc development for awhile now
> >> and have become a bit concerned that it is slowing
> >> tending towards a gnu-linux mono
Duncan Sands wrote:
I hope it was clear from my email that by "gcc" I was talking about the gcc
optimizers and code generators and not the gcc frontends. If the dragonegg
project shows that feeding the output of the gcc frontends into the LLVM
optimizers and code generators results in better co
Robert Dewar writes:
>
> Sure you can run some benchmarks and look for missed optimization
> opportunities, that's always worth while, for instance people
> regularly compare gcc and icc to look for cases where the gcc
> optimization can be improved
OT, but there's lots of cool data on all of thi
Duncan Sands wrote:
Goes away is a bit strong. In practice, front ends know about their back
ends and are tuned in various ways for things to work well.
Likewise, back-ends are tuned for their front-ends.
Ciao,
Duncan.
Yes indeed, in particular, there is often a substantial covert
channel b
Hi Duncan,
>how do you compile a program with LLVM? It's not a compiler, it's a set of
>optimization and codegen libraries. You also need a front-end, which takes
>the users code and turns it into the LLVM intermediate representation [IR].
>The
>dragonegg plugin takes the output of the gcc-4.5
Goes away is a bit strong. In practice, front ends know about their back
ends and are tuned in various ways for things to work well.
Likewise, back-ends are tuned for their front-ends.
Ciao,
Duncan.
On 11/04/2010 16:23, Manuel López-Ibáñez wrote:
> On 11 April 2010 16:17, Jack Howarth wrote:
>> ps I've watched FSF gcc development for awhile now
>> and have become a bit concerned that it is slowing
>> tending towards a gnu-linux mono-culture (through
>> no real fault of its own). There should b
Duncan Sands wrote:
In my opinion a bit of friendly competition from LLVM is on the whole a
good thing for gcc.
I definitely agree with that position. Real competition between LLVM &
GCC is good for both projects, and is good for free software as a whole.
Cheers.
--
Basile STARYNKEVITC
Duncan Sands wrote:
Hi Robert,
b) better behavior for undefined cases
this is one of the problems with using LLVM with the Ada front-end. LLVM makes
pretty aggressive deductions when it sees undefined behaviour, which can result
in (for example) validity checks being removed exactly in the c
Hi Robert,
b) better behavior for undefined cases
this is one of the problems with using LLVM with the Ada front-end. LLVM makes
pretty aggressive deductions when it sees undefined behaviour, which can result
in (for example) validity checks being removed exactly in the cases when they
are mo
Duncan Sands wrote:
how do you compile a program with LLVM? It's not a compiler, it's a set of
optimization and codegen libraries. You also need a front-end, which takes
the users code and turns it into the LLVM intermediate representation [IR]. The
dragonegg plugin takes the output of the gc
Hi Grigori,
Hope my question will not completely divert the topic of this discussion -
just curious what do you mean by better code? Better execution time, code size,
compilation time?..
this depends on each persons needs of course. The dragonegg plugin makes it
easy for people to see if the
On Sun, Apr 11, 2010 at 06:02:38PM +0200, Duncan Sands wrote:
>> useful and effective, then work on it as well and give it credit; if
>> GCC is so bad, then why rely on it? The rhetoric is disconnected from
>> the actions.
>
> I'm not sure what you mean. Working on an LLVM middle-end/back-end for
Hi David,
The Graphite project and the various GCC targets participate in GCC
development. Helping fix GCC bugs affecting those features, supports
and grows the GCC developer base. There needs to be some mutualistic
relationship. I don't see members of the LLVM community arguing that
they sho
Grigori Fursin wrote:
Hello,
Hope my question will not completely divert the topic of this discussion -
just curious what do you mean by better code? Better execution time, code size,
compilation time?..
Could mean all these things as well as other issues
a) better realiability
b) better beh
PM
To: Eric Botcazou
Cc: gcc@gcc.gnu.org; Steven Bosscher
Subject: Re: dragonegg in FSF gcc?
Hi Eric,
>> As for "negating the efforts of those working on the middle ends and back
>> ends", would you complain if someone came up with a new register allocator
>> becau
Duncan Sands wrote:
I hope it was clear from my email that by "gcc" I was talking about the gcc
optimizers and code generators and not the gcc frontends. If the dragonegg
project shows that feeding the output of the gcc frontends into the LLVM
optimizers and code generators results in better co
Hi Eric,
As for "negating the efforts of those working on the middle ends and back
ends", would you complain if someone came up with a new register allocator
because it negates the efforts of those who work on the old one? If LLVM
is technically superior, then that's a fact and a good thing, no
On 11 April 2010 16:17, Jack Howarth wrote:
> ps I've watched FSF gcc development for awhile now
> and have become a bit concerned that it is slowing
> tending towards a gnu-linux mono-culture (through
> no real fault of its own). There should be every effort
> made to keep as many alternative pla
On Sun, Apr 11, 2010 at 10:56:55AM -0400, David Edelsohn wrote:
> On Sun, Apr 11, 2010 at 10:30 AM, Jack Howarth
> wrote:
> > Steven,
> > One other comment. I've felt for awhile that a major
> > strength of FSF gcc was the fact that its support for
> > so many targets insured that latent bugs t
On Sun, Apr 11, 2010 at 10:30 AM, Jack Howarth wrote:
> Steven,
> One other comment. I've felt for awhile that a major
> strength of FSF gcc was the fact that its support for
> so many targets insured that latent bugs tended to be
> found in the compiler. Likewise graphite has recently
> exposed
> As for "negating the efforts of those working on the middle ends and back
> ends", would you complain if someone came up with a new register allocator
> because it negates the efforts of those who work on the old one? If LLVM
> is technically superior, then that's a fact and a good thing, not
>
Steven,
One other comment. I've felt for awhile that a major
strength of FSF gcc was the fact that its support for
so many targets insured that latent bugs tended to be
found in the compiler. Likewise graphite has recently
exposed certain latent bugs as well. Why should we not
expect the same t
On Sun, Apr 11, 2010 at 01:19:06PM +0200, Steven Bosscher wrote:
> On Sat, Apr 10, 2...@3:03 PM, Duncan Sands wrote:
> > Hi Basile,
> >
> >> I tend to be quite happy with the idea of dragonegg being a good GCC
> >> plugin, since it is a good illustration of the plugin feature.
> >
> > I think Jack
Hi Steven,
I think Jack wasn't suggesting that dragonegg should be changed to not be
a plugin any more. I think he was suggesting that it should live in the gcc
repository rather than the LLVM repository.
So, no offense, but the suggestion here is to make this subversive
(for FSF GCC) plugin
On Sat, Apr 10, 2010 at 3:03 PM, Duncan Sands wrote:
> Hi Basile,
>
>> I tend to be quite happy with the idea of dragonegg being a good GCC
>> plugin, since it is a good illustration of the plugin feature.
>
> I think Jack wasn't suggesting that dragonegg should be changed to not be
> a plugin any
Hi Basile,
I tend to be quite happy with the idea of dragonegg being a good GCC
plugin, since it is a good illustration of the plugin feature.
I think Jack wasn't suggesting that dragonegg should be changed to not be
a plugin any more. I think he was suggesting that it should live in the gcc
Jack Howarth wrote:
What are the opinions here about merging
dragonegg into FSF gcc? It is in the odd position
of straddling two projects so perhaps it could
reside in both the LLVM and FSF gcc projects
with regularly remerging. Certainly it would be
an interesting addition to FSF gcc.
What
70 matches
Mail list logo
