search for: msbb

On Thu, Oct 30, 2008 at 5:23 PM, Jack Howarth <howarth at bromo.msbb.uc.edu> wrote: > Chris and Bill, > I have tested the proposed patch from... > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html > > under i686-apple-darwin9 and it solves the problems building gfortran > from llvm svn. The resulting compiler works fine s...

On Thu, Oct 30, 2008 at 05:38:30PM -0700, Bill Wendling wrote: > On Thu, Oct 30, 2008 at 5:23 PM, Jack Howarth <howarth at bromo.msbb.uc.edu> wrote: > > Chris and Bill, > > I have tested the proposed patch from... > > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html > > > > under i686-apple-darwin9 and it solves the problems building gfortran > > from llvm svn....

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find

How do the llvm-gcc developers handle regression testing? Are there regular postings of the make check results for llvm-gcc-4.2 such as on the gcc-testresults mailing list? If not, it might be a good idea if linux and darwin workstations could be found to dedicate as regression test machines and a llvm-gcc-testresults mailing list created for those results. That would be extremely useful in

Duncan, I don't be that can be the cause because I have... --enable-languages=c,c++,fortran in my configure options for llvm-gcc-4.2. Jack On Mon, Aug 11, 2008 at 08:40:52AM +0200, Duncan Sands wrote: > Hi Jack, > > > The curent llvm svn (r54623) is unable to link the gfortran > > compiler in llvm-gcc-4.2 svn. I am getting the error... > ...

Duncan, So you agree that nothing on that offending link line is really requiring g++? I'll see if I can find the lines in Makefile.in and Makefile.am that are producing that link line and propose a patch. I don't see why the linkage of the gfortran compiler itself should have anything to do with c++ code. Not even FSF gcc trunk has switched over to building with c++ yet. I assume

Does anyone know if the issue with building the gfortran front-end on Darwin will be addressed for llvm 2.4? The last time a checked a few weeks back, llvm-gcc-4.2 svn was still producing the linkage error... > Undefined symbols: > "_create_init_utf16_var", referenced from: > _darwin_build_constant_cfstring in libbackend.a(darwin.o) I believe the analysis of this was

Anton, I didn't have to time to do fresh set of benchmarks for llvm-gfortran from 2.4 and current gcc trunk. I'll do that this weekend. However I suspect I'll see similar behavior as before. Compared to FSF gcc 4.2, llvm-gfortran will show improvements but it won't be as impressive compared to gcc trunk. Is there a projected date for supporting the vectorization in llvm for the

Anton, Can you post you results from contrib/test_summary for a make check-fortran of llvm 2.4's gcc 4.2 compilers on linux? I'll remove the offending flags from CC1_SPECS in darwin.h on llvm 2.4 and post the same results for i686-apple-darwin9. Are there any major issues left with the functionality of gfortran under llvm? Jack

What exactly is the state of gfortran support for the llvm gcc 4.2 front-end in the svn? I built yesterday's llvm-gcc-4.2 branch on powerpc-apple-darwin9 with fortran included in the languages. The gfortran compiler appears to have been built but nothing seems to be compiled for the libgfortran directory. Thanks in advance for any information as I am working on test fink packaging for

I am seeing the same problems using 'llvm-ld' with llvm-gcc at -O4 on x86_64 Fedora 8 linux as on Darwin. Another example of this is building the scimark2_1c benchmark... http://math.nist.gov/scimark2/download_c.html as follows on x86_64 Fedora 8... /home/howarth/llvm-gcc42-work/bin/gcc -O4 -m64 -c FFT.c /home/howarth/llvm-gcc42-work/bin/gcc -O4 -m64 -c kernel.c

Yesterday while attempting to append an attachment to a bugzilla report for llvm, the llvm bugzilla server appeared to have run out of disk space. Now this problem seems to have extended to the bug database server which reports... Software error: Can't connect to the database. Error: Too many connections Is your database installed and up and running? Do you have the correct username and

I've filed bugzilla reports for the gcc 4.2.1 gfortran testsuite failures in llvm/llvm-gcc-4.2 v2.3. These are... http://llvm.org/bugs/show_bug.cgi?id=2430 http://llvm.org/bugs/show_bug.cgi?id=2431 http://llvm.org/bugs/show_bug.cgi?id=2437 http://llvm.org/bugs/show_bug.cgi?id=2438 http://llvm.org/bugs/show_bug.cgi?id=2439 http://llvm.org/bugs/show_bug.cgi?id=2440

I've benchmarked the llvm 2.3/llvm-gcc-4.2 release against the stock gfortran compiler from gcc 4.2.4 on a 2.33GHz MacBook Pro using the '-ffast-math -funroll-loops -msse3 -O3' optimization flags. llvm-gfortran Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- ------- ---------- ------- -------

IMHO, this is one of my biggest concerns about Apple eventually switching over to llvm-gcc. The absence of the rigorous patch review process required in FSF gcc will tend to allow these sort of issues to slip by. Jack On Tue, Aug 12, 2008 at 09:05:11PM -0700, Bill Wendling wrote: > On Aug 10, 2008, at 11:40 PM, Duncan Sands wrote: > >> Hi Jack, >> >>>

On Fri, Oct 31, 2008 at 10:38:50AM -0700, Mike Stump wrote: > On Oct 31, 2008, at 9:40 AM, Jack Howarth wrote: >> However in current llvm svn, when I compile code with llvm-gfortran, I >> get these warning >> flags passed by default so that I get bogus warnings of... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/ >>

The previously posted benchnarks for gcc vs llvm-gfortran had one mistake. I was actually had the gfortran for 4.3.1 installed instead of that from gcc 4.2.4. Below are the polyhedron benchmark results for all three compilers... gfortran 4.2.4 Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- -------

Anton, Doh! It appears that *-*-darwin* is preset in configure to not build libgfortran... # APPLE LOCAL end ARM darwin target powerpc-*-darwin* | i[3456789]86-*-darwin*) noconfigdirs="$noconfigdirs bfd binutils ld gas opcodes gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" # LLVM LOCAL begin noconfigdirs="$noconfigdirs target-boehm-gc

I noticed that llvm 2.2 is slated for release on Feb. 4th of 2008. Do the llvm 2.2 releases mimic those of FSF gcc by requiring no major regressions for the release? For example, would Bug 1462 (CodeGen doesn't fully support i128) likely be fixed for 2.2 (even though it as marked as priority 2)? Also, how are the merges with the Apple GCC 4.2 branch handled? Are those done at some regular

Looking back through the commits to llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h, I see a total backout of format related warnings in r56923 followed by the reapplication of r569065 with a fix (r56946)... -- llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h 2008/10/01 17:38:40 56923 +++ llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h 2008/10/02 06:16:08 56946 @@ -101,6 +101,8 @@ %{!mmacosx-version-min=*: