This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dragonegg in FSF gcc?

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 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?

However, I found your posting of "llvm-gfortran" Polyhedron
comparisons of different LLVM versions
But that comparison does not including gfortran results.

I also found comparisons of llvm-gfortran and FSF gfortran
( and
But unfortunately I can't find these results posted on the GCC fortran
mailing list, or Bugzilla bug reports for cases where llvm-gfortran
performed better than FSF gfortran. So there's not much benefit from
these comparisons for GCC.

Where these results generated using DragonEgg? Or can you make these
comparisons without DragonEgg too?

> ? One could also make an argument that it is in the best
> interest of FSF gcc to do so. Isn't better to keep all
> of the alternative front-end developers (gfortran, ada,
> etc) within the FSF gcc tent rather than forcing the
> creation of competing clang fortran and ada projects.

Why would that be better? And, why would that be better only for the
front ends, but not for the middle ends and back ends? You don't seem
to have a problem with the creation of competing back ends. If you so
believe in competition between compilers, then why are you against
competition at the level of front ends? You should encourage a clang
fortran project.

But apparently, you don't. That doesn't look like a desire for
competition or comparisons, but only a desire to rip the parts of GCC
that LLVM doesn't already provide itself.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]