[LLVMdev] Embedded C Extensions

[Peter Wiedermann]

hello

> > in the first step, we either have to backport the changes in the gcc
> > frontend or port llvm-gcc to a more recent version (with the 4.2
> > release on its way, this might be a good candidate). it appears,
> > resources are better spent for latter. are there major concerns
> > speaking against this approach? does anybody have a rough estimate of
> > the required effort?
>
> llvm-gcc is mostly affected by changes in the GCC trees.  From my initial
> investigation, it looks like there are a few minor changes (e.g.
> CONSTRUCTOR nodes are a bit different) but nothing major.  It may be
> possible to get a prototype 4.2-merged compiler up in a few weeks.
>
> My group has plans to eventually merge the apple gcc 4.2 compiler work
> into llvm-gcc.  This would sync the front-end with 4.2 and provide several
> other features contributed by apple (most of which may not be interesting
> to people on non-darwin platforms though).  Unfortunately, we don't have a
> definite timespan for this.  We'll most likely pick up this project in the
> next 3-4 months.  This may or may not be too late for you.
>

Because 3-4 months are a long time for us, i would like merge the 
llvm-gcc to a more recent version of gcc.

Actually the fixed-point support for gcc is developed in a 4.3 branch
which is regularly merged with the trunk. So there are 2 possible
approaches:

   1) port llvm-gcc to the actual fixed-point branch (gcc 4.3)

   2) port llvm-gcc to gcc 4.2
      and backport the fixed-point extensions to that llvm-gcc4.2
      (i assume the backport will not be that much work because the
      frontends will not really differ)

I think the decision basically depends on your release plans.
If you want to keep track with the current 4.3 development, the first
approach would be the better one.
If you don't like a llvm-gcc release for every gcc release, the second
approach seems better to me.
So let me know about your preference.

kind regards
peter