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
Dear all,
We would like to share notes from the lively panel discussion at
GROW'10 (GCC Research Opportunities Workshop) that took place at the
end of January in Pisa, Italy (alongside the HiPEAC conference).
The main topic of the discussion was:
How to make GCC more attractive to research
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 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
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
> 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 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
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 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
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
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
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?..
If yes, then why not to compare different compilers by just compiling multiple
programs
with GCC, LLVM, Open64, I
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
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
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 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 gc
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:
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
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
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
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.
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 b
what is the expected behavior of ?
%{.c|.cc|.for|.F90: foo }
.. as I read gcc/gcc.c I would expect to get "foo" for command lines
with files with these suffixes:
.c
.cc
.for
.F90
but not otherwise (since it says . binds more strongly than |) ;
Iain
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
On Apr 11, 2010, at 5:54 AM, Dorit Nuzman wrote:
>
> * Get statistics on percentage of papers/projects that use compilers other
> than GCC, and ask them why...
Hi Dorit,
Here is a semi reasonably list of llvm-based publications:
http://llvm.org/pubs/ which might be useful.
> (By the way, why
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
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
Thanks, Chris!
At GROW'10 panel, we have been discussing how to make GCC more attractive to
researchers
and to start listing features that are important to researchers and missing in
GCC but present
in other compilers. Maybe we should also make a "Publications" wiki page on GCC
website and sta
On Apr 11, 2010, at 12:05 PM, Grigori Fursin wrote:
> By the way, I remember that when we had first discussions to include plugin
> framework to GCC some
> years ago,
> first feedback was extremely negative. Nevertheless, GCC 4.5 will feature
> plugin framework (that
> will
> also be very usefu
> Hi,
>
> I have a project in mind which I'm going to propose to the GCC in terms
of
> Google Summer of Code. My project is not on the list of project ideas
> (http://gcc.gnu.org/wiki/SummerOfCode) that is why it would be very
> interesting
> for me to hear any opinions and maybe even to find a men
Sure, Chris, I agree ...
Still, I hope that those incremental improvements will continue even if they
may not be immediately useful or fully operational ...
Cheers,
Grigori
-Original Message-
From: Chris Lattner [mailto:clatt...@apple.com]
Sent: Sunday, April 11, 2010 9:38 PM
To: Grigo
> 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 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
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 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
Snapshot gcc-4.3-20100411 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100411/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
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
39 matches
Mail list logo
