> Um, why are you using use_toc_relative_ref then, if not to access MEMs
> outside the TOC?
OK, I guess I misunderstood what you meant by "memory not in the TOC", you are
probably referring to the MEM generated by the call to force_const_mem, which
indeed points outside the TOC for VxWorks.
--
On Tue, Jan 17, 2017 at 09:21:38AM +0100, Eric Botcazou wrote:
> > The one thing I find questionable about this patch is that it will set
> > mem_alias_set for the resulting MEMs to the TOC alias set. Is that
> > correct for memory not in the TOC?
>
> I don't understand why the memory would not b
> The one thing I find questionable about this patch is that it will set
> mem_alias_set for the resulting MEMs to the TOC alias set. Is that
> correct for memory not in the TOC?
I don't understand why the memory would not be in the TOC (but I discovered
this TOC business while investigating the
On Mon, Jan 16, 2017 at 09:26:53AM +0100, Eric Botcazou wrote:
> rs6000 (Fix reload failures in 64-bit mode):
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00568.html
The one thing I find questionable about this patch is that it will set
mem_alias_set for the resulting MEMs to the TOC alias se
aarch64 (Enable descriptors for nested functions in Ada):
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01253.html
arm (Enable descriptors for nested functions in Ada):
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01254.html
rs6000 (Fix reload failures in 64-bit mode):
https://gcc.gnu.org/
aarch64 (Enable descriptors for nested functions in Ada):
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01253.html
arm (Enable descriptors for nested functions in Ada):
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01254.html
rs6000 (Fix reload failures in 64-bit mode):
https://gcc.gnu.org/
