tions *of a different mode*. That is, to describe a movhi in
terms of two movqi I should use a define_split instead of a
define_expand.
2.2 the define_expand expects the mode of the matching rtl macro and
the output operations to be preserve. Otherwise gcc could get confuse
since the mode will be change for no apparent reason.
Thanks for your help.
Best regards,
-Omar
YPE_SIZE is defined as
32-bit, so the hard-coded '64' is causing trouble. I am planning on
doing this change on my local source tree, but wanted to discuss with
the community to see if there is some implementations details somewhere
that I need to consider as well.
Best regards,
-Omar
On Thu, Oct 2, 2008 at 11:59 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Omar Torres" <[EMAIL PROTECTED]> writes:
>
>> Shouldn't this macro:
>> #define REAL_VALUE_TO_TARGET_DOUBLE(IN, OUT) \
>> real_to_target (OUT, &(
really exists. I understand my
target is an outliner, but shouldn't the DOUBLE_TYPE_SIZE be used in
this macro to cover targets like mine?
Thanks,
-Omar
]) 56 {*divmodsi4} (insn_list:REG_DEP_TRUE 10
(insn_list:REG_DEP_TRUE 11 (nil)))
(expr_list:REG_UNUSED (reg:SI 5 %iph [34])
(expr_list:REG_UNUSED (reg:QI 2 %r2)
(expr_list:REG_UNUSED (reg:QI 1 %r3)
(nil)
Any suggestions on how I might be able to work around this?
On Fri, Oct 10, 2008 at 10:40 AM, Dave Korn <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor wrote on 10 October 2008 15:53:
>
>> "Omar Torres" <[EMAIL PROTECTED]> writes:
>>
>>> The problem is that both, the quotient and reminder, regist
its, while gcc is expecting up to
64-bit support.
Any suggestions on how to workaround this?
Thanks,
-Omar
Hi Andrew,
Looks like Paul did submitted a patch here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
Can you or someone else take a look and comment on it?
Thanks!
-Omar
On Thu, Oct 16, 2008 at 4:08 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Omar Torres wrote:
>
>>
On Thu, Oct 16, 2008 at 10:02 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Omar Torres wrote:
>> Hi Andrew,
>> Looks like Paul did submitted a patch here:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
>>
>> Can you or someone else take a look and com
On Thu, Oct 16, 2008 at 10:42 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>
>> LONG_LONG_TYPE_SIZE is in fact defined as 32-bit in the port I am
>> working. I inherited this GCC port, so I do not now whether or not
>> this is fully compliant with C99 standard.
>
> You do now.
Yes, thanks.
>
>> I
On Thu, Oct 16, 2008 at 11:59 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Paul Schlie wrote:
>> Andrew Haley wrote:
>>> Omar Torres wrote:
>>>> Hi Andrew,
>>>> Looks like Paul did submitted a patch here:
>>>> http://gcc.gnu.org/bugz
lf
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr51/crtusb1286.o
-L/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr51
-L/usr/local/avr/lib/gcc/avr/4.5.2
-L/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib -Map=SCD.map
SCD.o EMV.o halSCD.o scdIO.o utils.o terminal.o /tmp/ccAv4Kbo.o
/tmp/ccswYC86.o -lgcc -lc -lgcc
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status
Thanks,
Omar
tly the amount of details I am looking for. Thanks a lot for your
patience and level of detail.
> Good luck with the port,
>
> Richard
Regards,
-Omar
al>>8) & 0xff;
operands[4] = gen_rtx_CONST_INT (QImode, high);
operands[5] = gen_rtx_CONST_INT (QImode, low);
}
else {
fprintf (stderr, \"\nUnrecongnized:\");
debug_rtx (operands[1]);
}
}")
Thanks,
-Omar
Just correcting a typo...
Omar Torres wrote:
> I split it into:
(set (reg:QI 1 %r3)
(const_int 127 [0x7f])
(set (reg:QI 2 %r2)
(const_int 255 [0xFF])
rands[4])
> is a memory reference that uses the high part of operands[0] as
> a base register. In that case, the base register will be modified
> by the first split instruction and have the wrong value in the
> second split instruction. See other ports for the canonical way
> of handling this.
Thanks for the heads up. Could you point me to a specific target/file?
Best regards,
-Omar
Richard Sandiford wrote:
> "Omar Torres" <[EMAIL PROTECTED]> writes:
> More importantly:
>
>>operands[4] = simplify_gen_subreg(QImode,operands[1],HImode,0);
>>operands[5] = simplify_gen_subreg(QImode,operands[1],HImode,1);
>
> ..this cod
(mem/s/j:HI (plus:HI (reg/f:HI 7 %i0h [orig:39 source ] [39])
(const_int 2 [0x2])) [0 .r+0 S2 A8])) 3
{*movhi} (nil)
(nil))
I need to tell the compiler not to use as destination the same base
register when doing index operations. Any suggestions on how do I that?
Thanks for your help.
-Omar
is work? Should I use instead a different email client better
suit for GCC ML?
2- Currently, (1) is the only thing I have run cross. I am sure there
are other issues that those of you with more experience have already
discovered and solve. Any other Dos/Don'ts or tips/tricks when posting
to GCC ML?
Thanks,
-Omar
Mohamed Shafi wrote:
> Hello Omar,
>
> I saw your mail to gcc mailing list regarding splitting of HImode
> patterns into QImode patterns. I am also involved in porting. My
> problem is similar to yours. But i have to split SImode patterns into
> HImode patterns.
>
>
mode, operands[2], HImode, 1);
operands[8] = simplify_gen_subreg (QImode, operands[2], HImode, 0);
if (!which_alternative)
return "ADD\t%3,%7\n\tADDC\t%4,%8";
else if (1 == which_alternative)
return "ADD\t%3,%5\n\tADDC\t%4,%6";
else
return "ADD\t%3,%5,%8\n\tADDC\t%4,%5,%8";
})
Regards,
-Omar
nd 2 is a register, immediate or memory
2) Operand 0 is a register
Operand 1 is a register, immediate or memory
Operand 2 is the same register as operand 0
3) Operand 0 is a register
Operand 2 is a register
Operand 3 is also a register
>I am not sure what rim is for?
>
rim = is a short cut for r, m, i. I think is is allow to mix several
constrains like this, right?
Thanks,
-Omar
22 matches
Mail list logo
