And that problem was visible in
both 8 and 16 bits configurations.
So I suspect the problem won't be seen on PowerPC unless someone does
TI or OI bit fields...
--
Stelian Pop
On Wed, Jun 03, 2009 at 07:49:29PM +0200, Stelian Pop wrote:
> I'm doing a port of gcc 4.3.3 on a custom architecture and I'm having trouble
> when initializing the bit fields of a structure.
Ok, after further analysis, it looks like a genuine bug in gcc,
in store_bit_field_1():
nd:HI (reg:HI 34)
(reg:HI 36))) -1 (nil))
(insn 19 18 0 991118-1.c:12 (set (mem/s/j/c:HI (reg/f:HI 33) [0+2 S2 A16])
(reg:HI 35)) -1 (nil))
Any idea on what is happenning here ? Am I missing some standard
patterns in my .md file ?
Thanks !
--
Stelian Pop
On Wed, May 06, 2009 at 03:42:47PM -0700, Ian Lance Taylor wrote:
> Stelian Pop writes:
>
> There is something strange in your trees. Why did it convert the
> pointers to "long int"? Why did it not simply convert them to "int"?
> The fact that they are
On Wed, May 06, 2009 at 01:23:57PM -0700, Ian Lance Taylor wrote:
> Stelian Pop writes:
>
> > I did spent a few hours looking but haven't had much luck.
> >
> > I tried tracing this one:
> >> > 6 long i = s.f-&s.b;
> > and noticed that
On Wed, May 06, 2009 at 12:19:55PM -0700, Ian Lance Taylor wrote:
> Stelian Pop writes:
>
> > on TARGET_8W and TARGET_16:
> > 920928-1.c:
> > 1 struct{int c;}v;
> > 2 static long i=((char*)&(v.c)-(char*)&v)
> > 930326-1.c:
> >
18 }
on TARGET_16W and TARGET_32: 2004-1.c:
1 extern void _text;
2 static __SIZE_TYPE__ x = (__SIZE_TYPE__) &_text - 0x1000L - 1;
Are those tests expected to fail on my port or is that something I've
obviously done wrong ?
Thanks.
Stelian.
--
Stelian Pop
On Fri, Apr 10, 2009 at 06:29:06PM +0100, Dave Korn wrote:
> Stelian Pop wrote:
> > Hi,
> >
> > I'm (still) porting GCC to a 16 bit microcontroller, and I'm having a few
> > issues with the way it handles memory accesses: this microcontroller can
> >
needs a SI one ?
Thanks.
--
Stelian Pop
ook.
[...]
> The s390 back-end globally reserves a register for the purpose of
> holding the target of long branches (well, the register is also
> used as "link register" for calls).
Ok, so I'll reserve a register for indirect jumps too then. I was hoping
to be able to avoid this.
Thanks !
Stelian.
--
Stelian Pop
On Wed, Mar 11, 2009 at 08:33:34AM +0100, Georg-Johann Lay wrote:
> Stelian Pop schrieb:
>> On Tue, Mar 10, 2009 at 10:18:10PM +0100, Georg-Johann Lay wrote:
>>
>>
>>> Note that no one is generating an insn that looks like "*jump". Maybe
>>>
t; if I change the default value (first line in my example) to be 'const_int 1',
>> I later get 'operand out of range' from the assembler because the 'rjmp'
>> instruction was used for deplacements bigger than 2048. How can this happen,
>> since my
On Tue, Mar 10, 2009 at 05:20:28PM +, Dave Korn wrote:
> Stelian Pop wrote:
>
> > I need to use a scratch register in the "jump" pattern and I can't
> > figure out how to do it properly.
> >
> > My problem is that the microcontroller I'
ug report, with preprocessed source if appropriate.
Any idea ?
Side question regarding the "length" attribute. It seems to work ok, but
if I change the default value (first line in my example) to be 'const_int 1',
I later get 'operand out of range' from the assembler because the 'rjmp'
instruction was used for deplacements bigger than 2048. How can this happen,
since my '(set (attr "length")' code explicitly sets the correct value
each time ?
Thanks,
--
Stelian Pop
Le lundi 21 juillet 2008 à 15:37 +0200, Stelian Pop a écrit :
> I have a problem with the jump instructions: my direct jumps are very
> limited in displacements, and I want to always generate indirect jumps
> instead.
Ok, no answer yet.
Does this mean that my question is really dumb ?
.3.1/gcc/emit-rtl.c:4085
#3 0x080da84c in try_redirect_by_replacing_jump (e=0xb7c26460,
target=0xb7c179d8, in_cfglayout=0 '\0')
at /wip/src/gcc-4.3.1/gcc/cfgrtl.c:822
#4 0x08360a08 in cleanup_cfg (mode=1)
[...]
Thanks,
--
Stelian Pop <[EMAIL PROTECTED]>
Le lundi 14 avril 2008 à 18:27 -0700, Jim Wilson a écrit :
> On Tue, 2008-04-15 at 00:06 +0200, Stelian Pop wrote:
> > - I had to add a PLUS case in PREFERRED_RELOAD_CLASS() or else reload
> > kept generating incorrect insn (putting constants into EVEN_REGS for
> > exampl
Le vendredi 11 avril 2008 à 11:14 -0700, Jim Wilson a écrit :
> Stelian Pop wrote:
> > #define PREFERRED_RELOAD_CLASS(X, CLASS)\
> > ((CONSTANT_P(X)) ? EIGHT_REGS : \
> >(MEM_P(X)) ? EVEN_REGS : CLASS)
> >
> > #defin
Le vendredi 11 avril 2008 à 11:14 -0700, Jim Wilson a écrit :
> Stelian Pop wrote:
> > #define PREFERRED_RELOAD_CLASS(X, CLASS)\
> > ((CONSTANT_P(X)) ? EIGHT_REGS : \
> >(MEM_P(X)) ? EVEN_REGS : CLASS)
> >
> > #defin
w, yes, I chose to support only 2^16 RAM addresses.
In fact, this microcontroller is able to address 2^24, and two registers
are used for indirect accesses (Rx and Rx+1, where x is even), this is
the reason why only even registers are allowed in indirect addressing...
--
Stelian Pop <[EMAIL PROTECTED]>
\
{ 0x }, \
{ 0x7FFE }, \
{ (1LL << FIRST_PSEUDO_REGISTER) - 1 }\
}
...
(define_register_constraint "z" "EVEN_REGS"
"Even registers (r0,r2,r4, @dots{} r30)")
--
Stelian Pop <[EMAIL PROTECTED]>
Le jeudi 10 avril 2008 à 15:48 +0200, Stelian Pop a écrit :
> Le mercredi 09 avril 2008 à 18:21 -0400, DJ Delorie a écrit :
> > > Maybe I should reserve a special register for this usage (say r0).
> >
> > That might be the only way, yes.
>
> Ok, I reserved r0 (BP
ne/bgt... etc define_insn() (like many
other targets).
Thanks.
--
Stelian Pop <[EMAIL PROTECTED]>
Le mercredi 09 avril 2008 à 21:19 +0200, Stelian Pop a écrit :
> > You might need to define LEGITIMIZE_RELOAD_ADDRESS, or at least
> > LEGITIMIZE_ADDRESS. I don't know if reload has assumptions about such
> > offsets, but the m32c port has a limit on the offset range s
t such
> offsets, but the m32c port has a limit on the offset range so it might
> help you figure out your port.
Ah, this looks exactly like what I needed, thanks!
I'll try this and come back afterwards.
--
Stelian Pop <[EMAIL PROTECTED]>
optional
reload_out_reg: (reg:QI 109 [ u ])
But those moves are illegal because there is no offset allowed in the
base register addressing mode (see the definition of my
GO_IF_LEGITIMATE_ADDRESS() ),
so gcc crashes with 'unrecognizable insn'.
So what's the proper way to tell that indirect addressing is allowed,
but not with an offset ? Should I define an extra define_expand to deal
with those insns ?
Thanks again,
Stelian.
--
Stelian Pop <[EMAIL PROTECTED]>
QI 30 r30))) 13 {addqi3} (expr_list:REG_EQUIV
(plus:QI (reg/f:QI 30 r30)
(const_int 24 [0x18]))
(nil)))
(insn 1119 1118 21 2
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:1090 (set (mem/c:QI (reg:QI
10 r10) [31 S1 A16])
(reg:QI 14
27 matches
Mail list logo
