Hi David,
On 10 July 2015 at 16:11, David Malcolm wrote:
> AIUI, we have CALL_INSN instructions all the way through the RTL phase
> of the backend, so we can identify which locations in the generated code
> are calls; presumably we'd need at each CALL_INSN to determine somehow
> which RTL express
Hi David, hi Basile,
On 10 July 2015 at 03:53, David Malcolm wrote:
> FWIW PyPy (an implementation of Python) defaults to using true GC, and
> could benefit from GC support in GCC; currently PyPy has a nasty hack
> for locating on-stack GC roots, by compiling to assembler, then carving
> up the a
Hi all,
Here is an updated patch (attached) for __seg_fs and __seg_gs:
* added a target hook "default_pointer_address_modes" to avoid
disabling a few gcc optimizations which, according to my reading of
the documentation, should continue to work even in the presence of
multiple address spaces as l
Hi Richard,
On 3 July 2015 at 10:29, Richard Biener wrote:
> It's nice to have the ability to test address-space issues on a
> commonly available target at least (not sure if adding runtime
> testcases is easy though).
It should be easy to add testcases that run only on CPUs with the
"fsgsbase"
Hi all,
I implemented support for %fs and %gs segment prefixes on the x86 and
x86-64 platforms, in what turns out to be a small patch.
For those not familiar with it, at least on x86-64, %fs and %gs are
two special registers that a user program can ask be added to any
address machine instruction.
