darwin may lose primary target status on FSF gcc

[Toby Peterson]

On Sat, Sep 19, 2009 at 10:15, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> On Sat, Sep 19, 2009 at 01:03:26AM -0700, Toby Peterson wrote:
>> On Fri, Sep 18, 2009 at 17:43, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>> > On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote:
>> >>
>> >> Given current reality, you're probably better off contributing to
>> >> llvm-gfortran... or better yet, a native fortran front-end for llvm.
>> >> FSF gcc is barely relevant on our platform these days.
>> >>
>> >> - Toby
>> >
>> > Toby,
>> >   I created the fink llvm/llvm-gcc42 packages to provide
>> > them with a llvm-gfortran. However the gfortran in llvm-gcc42
>> > is just that (locked at the gcc 4.2.1 release because it
>> > was the last GPLv2 release that Apple will accept). It has
>> > much worse performance than the current gfortran in gcc 4.4.0,
>> > has fewer features and significant portions of the newer
>> > features aren't working properly. The chances of llvm-gcc
>> > being updated to a newer release are basically zero and
>> > there is no clang related fortran compiler at all. You
>> > work with the hand your dealt...and for us that is trying
>> > to keep the wheels on FSF gcc for darwin as long as possible.
>> > Actually gcc 4.4.1 has excellent testsuite results on darwin10.
>> > Also look at...
>> >
>> > http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg18166.html
>> > http://archive.netbsd.se/?ml=fink-devel&a=2009-03&m=10250229
>> >
>> > where I benchmarked the various gcc compilers on Intel darwin.
>> > Lastly, if you check the table at...
>> >
>> > http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
>> >
>> > you will see how really bad it would be to have to rely on
>> > g95 even if it built on darwin10 (almost 3 times slower
>> > than current gfortran).
>>
>> That's why I suggested *contributing* to llvm-gfortran or a native
>> front-end. If it lags behind, make it better. FSF gcc just doesn't
>> have much of a future on our platform...
>>
>> - Toby
>
> Toby,
>    The llvm-gfortran project will be a lost cause in the long run
> mainly because it is trapped on a most inconvenient source base.  The
> GPLv3 license came into effect just as gfortran development was beginning
> to show massive progress. The FSF gcc used for llvm-gcc will likely
> never be updated because of the GPLv3 issue so its gfortran is trapped
> in a time warp. The most promising approach would be a native fortran
> compiler for clang but no such project exists yet. I can only work with
> the possible.

I'm not sure how what I'm suggesting is impossible. Hard, maybe, but impossible?

> ps You do realize that we are using gcc 4.2.1 (and not 4.2.4 or a later
> gcc release) only because of the GPLv3 license. Few people are aware
> but Apple's programmers (who are the FSF darwin maintainers) are not
> allowed to read the gcc mailing lists or the gcc source code since
> GPLv3 came into effect. They can only review and approve patches submitted
> for the FSF gcc that impact the darwin port. Fortunately that has
> allow me to keep the wheels on FSF gcc on darwin so far (knock on wood).

I'm fully aware of the evils of GPL.

- Toby