There is one g++ LTO test case (g++.lto/20090303) that fails on sparc,
it compiles the intermediate objects with -fPIC but the final
compilation creates an executable.
The problem is that when LTO re-instantiates the options for the
individual builds, the proper ASM specs of the target are not
ex
llect2: ld returned 1 exit status
$ g++ --version | head -1
g++ (GCC) 4.5.0 20100312 (experimental)
$ g++ -dumpmachine
x86_64-unknown-linux-gnu
$ ld --version | head -1
GNU ld (GNU Binutils) 2.20.1.20100303
I've implemented some special insns that access hardware resources.
These insns have side effects so they cannot be deleted or reordered
with respect to each other. I made them UNSPEC_VOLATILE, which
generates correct code. Unfortunately, performance is poor.
The problem is that UNSPEC_VOLATILE
On Thu, Mar 11, 2010 at 10:46:42AM +0100, Paolo Bonzini wrote:
> On 03/05/2010 05:03 PM, Joseph S. Myers wrote:
> >I don't know if there's an existing free software implementation of UAX#14
> >(Unicode Line Breaking Algorithm) suitable for use in GCC; that would be
> >the very heavyweight approach.
On 03/01/2010 04:47 PM, Rainer Orth wrote:
> If this is deemed acceptable, I'll probably go ahead and implement
> proper support for this in libffi, but only after providing a common
> symbol versioning infrastructure in GCC instead of again duplicating
> what we already have in several runtime lib
Hello Vladimir,
On s390x I have seen some testcase where IRA goes ballistic and loads a value
from stack (160(%r15)) over and over again:
[...]
82: e3 80 f0 a0 00 04 lg %r8,160(%r15) <--
88: e3 b0 f0 a0 00 04 lg %r11,160(%r15) <--
8e: e3 c0 f0 a0 00 04 l
>> You might want to look at the gengtype debugging dump support on
>> gc-improv branch, which I will submit shortly for 4.6 trunk.
>
> Thanks! Yes, I looked at your gengtype.c in your branch, and it is the kind
> of code I was dreaming of.
> Usually, in persistency machinery, the code to reload d
