similar to: [LLVMdev] Mach-O LTO and local relocations

This is probably a problem with having too many sections. There are a few places where mach-o has a limit on the number of sections. For instance the n_sect field of the nlist record is one byte. So any symbol in a section past the 255th section wraps around and shows up with the wrong n_sect number. -Nick On Apr 29, 2010, at 6:19 AM, Jack Howarth wrote: > I am wondering how the

Nick, Steven believes that aermod certainly could have more than 255 sections. Is there a particular approach that would be recommended for working around such a problem? Short of reducing the actual number of sections? It is suggested that this is why -ffunction-sections doesn't work on darwin and that one possible solution is to embed an 'ar' format section in the .gnu.lto

Is the new EH scheme completely compatible with the existing linker in Xcode 4.1? I am finding that today's changes break the ability to link xplor-nih with dragonegg under FSF gcc 4.6.2... de-g++46 -c thread.cc -O3 -ffast-math -funroll-loops -g -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG -I/Users/howarth/xplor-nih-2.27/vmd/

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

We don't currently apply any relocations (that I know of) for debug info in LLDB. > On Jun 2, 2014, at 12:35 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > > I think I'm getting closer. The debug_info section is being relocated correctly (I think): > > 0x00000000: Compile Unit: length = 0x00000045 version = 0x0003 abbr_offset = 0x00000000 addr_size =

Comparing the Polyhedron 2005 benchmark results for gfortran from llvm-gcc-4.2 of April 7th, 2010 and September 18th, 2010 (from the rc2 2.8 release branch), we seem to be regressing in performance for this release.... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command :

With the case-insensitive file system patch from http://llvm.org/bugs/show_bug.cgi?id=9656#c15 applied to dragonegg 2.9, the following Polyhedron 2005 benchmarks are seen on x86_64-apple-darwin10 under gcc 4.5.3svn using the dragonegg plugin... ================================================================================ Date & Time : 8 Apr 2011 19:52:56 Test Name :

Building the current release 2.7 branch on x86_64-apple-darwin10 with r81455 reverted, I get the following Polyhedron 2005 benchmark results (with no test failures)... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3

On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > Building the current release 2.7 branch on x86_64-apple-darwin10 > with r81455 reverted, I get the following Polyhedron 2005 benchmark > results (with no test failures)... Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested

On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: > On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: > > Duncan, > > I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn > > for the llvm 3.3 release? Is the deprecation and poisoning of IDENT_ASM_OP too problematic > > to work around without some

Hi Jack, thanks for these numbers. > With the commit from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/158488.html, > the Polyhedron 2005 benchmarks complete again on x86_64-apple-darwin12. The result are similar to what > were seen with FSF gcc 4.6.2svn and llvm/dragonegg 3.0 (which was the last release that passed pb05) >

Duncan, With the commit from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/158488.html, the Polyhedron 2005 benchmarks complete again on x86_64-apple-darwin12. The result are similar to what were seen with FSF gcc 4.6.2svn and llvm/dragonegg 3.0 (which was the last release that passed pb05) http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044091.html. Jack

Hello, I'm finally getting back to getting JIT debugging work for MCJIT. This has worked for ELF for a while in LLVM and support in lldb was added in January (for ELF). I'm now trying to add support for Mach-O and would appreciate some feedback (though I'm fighting my way through learning the format, I'm still just a novice). My current patchset for llvm is here:

On Wed, Apr 07, 2010 at 09:54:36PM -0700, Chris Lattner wrote: > > On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > > > Building the current release 2.7 branch on x86_64-apple-darwin10 > > with r81455 reverted, I get the following Polyhedron 2005 benchmark > > results (with no test failures)... > > Very nice! A 14% speedup on a benchmark we don't tune for

On Thu, May 09, 2013 at 12:21:30PM -0400, Jack Howarth wrote: > On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: > > On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: > > > Duncan, > > > I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn > > > for the llvm 3.3 release? Is the deprecation and

[CCing Dale since this was his change, not mine] The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets

On Wed, Oct 06, 2010 at 02:26:35PM +0200, Duncan Sands wrote: > Hi Jack, > > > I am finding that llvm 2.8 rc3 with dragonegg svn built against current > > gcc-4_5-branch doesn't appear to allow gfortran to use -ffast-math. Attempting > > to compile code using the dragonegg plugin under gcc 4.5.2 with that option produces the error... > > > > f951:

Hi Jack, On 09/05/13 18:21, Jack Howarth wrote: > On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: >> On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: >>> Duncan, >>> I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn >>> for the llvm 3.3 release? Is the deprecation and poisoning of

On Thu, Apr 08, 2010 at 08:45:48AM -0700, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt

Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is http://llvm.org/bugs/show_bug.cgi?id=15980 which results in unresolved symbols for _iround and _iroundf in the aermod and rnflow testcases. Note that this