On Tue, Mar 12, 2013 at 2:10 PM, Kurt Starsinic <[email protected]> wrote: > I thought this was an interesting tidbit on code optimization and > architecture-specific limitations. This is the kind of topic that has come > up a lot in the book club, but it's generally useful to know for writing > optimized code: > > http://stackoverflow.com/questions/15349959/gcc-refuses-to-emit-long-calls-for-operator-new-delete-on-powerpc?newsletter=1&nlcode=75484%7c33c5
So, this kind of problem only occurs when generating very large objects -- specifically, very large `.text` sections within objects (which, despite the name, are actually the machine code). Some processors like to use narrower width integers for calculating jump addresses -- in this case 24 bits. When performing a jump from an address on one end of the object to an address on the other end, if you've got really big object code, the distance between the pointers might be bigger than 2^24 -- and then you're screwed because the 24-bit integer overflows. "You can't get there from here!" > The takeaway for me is, if there's a compiler flag that you don't > understand (in this case, -mlongcall), then there's probably a situation > where you wished you'd supplied it. :^) Except that setting that flag didn't seem to help the poster. The Stack Overflow denizens are claiming a compiler bug! My rule of thumb: It's _never_ a compiler bug. But I've been wrong about that before. ;) Marvin Humphrey
