2010/4/13 Dave Korn dave.korn.cyg...@googlemail.com:
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
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 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 actually
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
: 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 Tue, Apr 13, 2010 at 16:51
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
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
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
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 have
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 7:14 PM, Jack Howarth howa...@bromo.med.uc.edu 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
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 argument for
On Tue, Apr 13, 2010 at 10:22 AM, Steven Bosscher stevenb@gmail.com 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
On Tue, Apr 13, 2010 at 12:21:09PM -0700, Andrew Pinski wrote:
On Tue, Apr 13, 2010 at 10:22 AM, Steven Bosscher stevenb@gmail.com
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
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 15:16, Jack Howarth howa...@bromo.med.uc.edu 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
On Tue, Apr 13, 2010 at 10:19 PM, Diego Novillo dnovi...@google.com 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
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 16:51, Steven Bosscher stevenb@gmail.com 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
On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth howa...@bromo.med.uc.edu 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,
On Wed, Apr 14, 2010 at 12:57:41AM +0200, Steven Bosscher wrote:
On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth howa...@bromo.med.uc.edu
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
On 12 April 2010 00:38, Dave Korn dave.korn.cyg...@googlemail.com 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
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
On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
On 12 April 2010 00:38, Dave Korn dave.korn.cyg...@googlemail.com 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
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 3:35 PM, Jack Howarth howa...@bromo.med.uc.edu 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 dave.korn.cyg...@googlemail.com wrote:
On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
[ ... ] lack of test
On Mon, Apr 12, 2010 at 03:42:39PM +0200, Richard Guenther wrote:
On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth howa...@bromo.med.uc.edu
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 dave.korn.cyg...@googlemail.com wrote:
On
On 12/04/2010 07:47, Manuel López-Ibáñez wrote:
On 12 April 2010 00:38, Dave Korn dave.korn.cygwin@ 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
On 12 April 2010 16:18, Dave Korn dave.korn.cyg...@googlemail.com 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.
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 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 more
On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth howa...@bromo.med.uc.edu 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
On Mon, Apr 12, 2010 at 05:45:52PM +0200, Steven Bosscher wrote:
On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth howa...@bromo.med.uc.edu
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.
On Mon, Apr 12, 2010 at 5:59 PM, Jack Howarth howa...@bromo.med.uc.edu 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
-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 it is (perceived as) more
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 your new PR
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
Weddington, Eric eric.wedding...@atmel.com 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,
On Sat, Apr 10, 2010 at 3:03 PM, Duncan Sands baldr...@free.fr 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
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 Sun, Apr 11, 2010 at 01:19:06PM +0200, Steven Bosscher wrote:
On Sat, Apr 10, 2...@3:03 PM, Duncan Sands baldr...@free.fr 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
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
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
On Sun, Apr 11, 2010 at 10:30 AM, Jack Howarth howa...@bromo.med.uc.edu 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
On Sun, Apr 11, 2010 at 10:56:55AM -0400, David Edelsohn wrote:
On Sun, Apr 11, 2010 at 10:30 AM, Jack Howarth howa...@bromo.med.uc.edu
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
On 11 April 2010 16:17, Jack Howarth howa...@bromo.med.uc.edu 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
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, not
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
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
because it negates the efforts of those who
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
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
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
gcc
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
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
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
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
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
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 be every
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
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
Robert Dewar de...@adacore.com 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
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
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-culture
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 11 April 2010 18:50, Dave Korn dave.korn.cyg...@googlemail.com 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
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
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
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.
69 matches
Mail list logo
