>> 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
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
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
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.
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
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
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
