Georg-Johann Lay wrote:
> Ulrich Weigand schrieb:
> > Georg-Johann Lay wrote:
> >
> >>http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
> >>
> >>Are you going to install that patch? Or maybe you already installed it?
> >
> > No, it isn't approved yet (in fact, it isn't even posted for approval).
>
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
Are you going to install that patch? Or maybe you already installed it?
No, it isn't approved yet (in fact, it isn't even posted for approval).
Usually, patches that add new target macros, or new
Georg-Johann Lay wrote:
> http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
>
> Are you going to install that patch? Or maybe you already installed it?
No, it isn't approved yet (in fact, it isn't even posted for approval).
Usually, patches that add new target macros, or new arguments to target
mac
http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
Georg-Johann Lay a écrit:
Ulrich Weigand wrote:
Georg-Johann Lay wrote:
Thanks, it works.
OK, thanks for testing!
[...]
Bye,
Ulrich
Are you going to install that patch? Or maybe you already installed it?
Then, I wonder how the following
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>
>> Thanks, it works.
>
> OK, thanks for testing!
>
>> std Y+2,r31 ; 30 *movphi/3 [length = 7]
>> std Y+1,r30
>
> I'm actually not seeing those (maybe I'm using a different code
> base than you were using ...)
>
> But I st
Georg-Johann Lay wrote:
> Thanks, it works.
OK, thanks for testing!
> std Y+2,r31 ; 30 *movphi/3 [length = 7]
> std Y+1,r30
I'm actually not seeing those (maybe I'm using a different code
base than you were using ...)
But I still see that the frame is created. The pro
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>> Ulrich Weigand wrote:
>>> This means that problems like the one you're seeing have been hidden
>>> so far. I've started looking into fixing this, but since I don't
>>> have a target where this is needed, this effort never really went
>>> anywhere.
Nope, I don't use those :-)
DJ Delorie wrote:
> Was this reproducible for m32c also? I can test it if so...
The patch simply passes the destination address space through
to MODE_CODE_BASE_REG_CLASS and REGNO_MODE_CODE_OK_FOR_BASE_P,
to allow targets to make register allocation decisions based
on address space.
As long as
Was this reproducible for m32c also? I can test it if so...
Michael Matz wrote:
> On Fri, 5 Aug 2011, Ulrich Weigand wrote:
> > Instead, if you just have a address and you don't know ahead of time
> > whether it refers to Flash or RAM space, you ought to hold that number
> > in an "int" (or "short" or whatever integer type is most appropriate),
> > and then
Hi,
On Fri, 5 Aug 2011, Ulrich Weigand wrote:
> > However, there are situations like the following where you like to take
> > the decision at runtime:
> >
> > char cast_3 (char in_pgm, void * p)
> > {
> > return in_pgm ? (*((char __pgm *) p)) : (*((char *) p));
> > }
>
> That's really an a
Georg-Johann Lay wrote:
> AVR hardware has basically three address spaces:
[snip]
OK, thanks for the information!
> Of course, RAM and Flash are no subsets of each other when regarded as
> physical memory, but they are subsets when regarded as numbers. This
> lead to my mistake to define RAM and
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
Ulrich Weigand wrote:
I'd be happy to bring this up to date if you're willing to work with
me to get this tested on a target that needs this support ...
Just attached a patch to bugzilla because an AVR user wanted to play
with the AS support a
Georg-Johann Lay wrote:
> Ulrich Weigand wrote:
> > I'd be happy to bring this up to date if you're willing to work with
> > me to get this tested on a target that needs this support ...
>
> Just attached a patch to bugzilla because an AVR user wanted to play
> with the AS support and asked me to
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>
>> Trying to make named address space support work for target AVR,
>> I am facing the following problem:
>>
>> For generic AS, there are three valid base pointer registers
>> X , Y and Z.
>>
>> For the new __pgm AS, only Z is available without offs
DJ Delorie wrote:
> > The only target supporting named address spaces today is spu-elf,
>
> m32c-elf does too.
Huh, I totally missed that, sorry ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
> The only target supporting named address spaces today is spu-elf,
m32c-elf does too.
Trying to make named address space support work for target AVR,
I am facing the following problem:
For generic AS, there are three valid base pointer registers
X , Y and Z.
For the new __pgm AS, only Z is available without offset.
The problem is now that addresses.h:base_reg_class() does not
pas
19 matches
Mail list logo
