Hi All,
Shouldn't this macro:
#define REAL_VALUE_TO_TARGET_DOUBLE(IN, OUT) \
real_to_target (OUT, &(IN), mode_for_size (64, MODE_FLOAT, 0))
be using DOUBLE_TYPE_SIZE instead of the hard coded '64'? Am I missing
something here?
In the target I am currently working, DOUBLE_TYPE_SIZE is defined
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, &(
On Fri, Oct 3, 2008 at 1:49 PM, Richard Henderson <[EMAIL PROTECTED]> wrote:
> The size of the C type "double" is controlled by DOUBLE_TYPE_SIZE,
> not the size of the compiler mode "DFmode". This macro is referring
> to the latter -- a double-precision floating point mode.
>
>
> r~
>
Richard,
I
Hi All,
I am having trouble distinguishing div vs mod while implementing the
divmodsi4 instruction. The gccint documentation states:
"If an instruction that just produces a quotient or just a remainder
exists and is more efficient than the instruction that produces both,
write the output routine o
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
Hi All,
I have a similar issue to what is reported here
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143):
/Applications/avr/avr-src/gcc/unwind.h:59: error: unable to emulate 'DI'
As you clearly expressed by Paul, the underline issue that the target
only support data types up to 32-bits, while
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
Richard,
Thanks a lot for the detailed explanation. I need some time to digest,
since this is my first experience doing a gcc backend port.
> Probably most of that was just telling you what you already knew, sorry.
Not really, I am new to most of these concepts. At this stage, this is
exactly th
Hi All,
Since the architecture I am working with only support byte size moves,
I created a define_split break HI-move insn's into two QI-moves.
For example, the following insn:
(insn 84 5 9 (set (reg:HI 1 %r3)
(const_int 32767 [0x7fff])) 3 {*movhi} (nil)
(nil))
I split it into:
(
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])
Richard Sandiford wrote:
>
> You might as well make the first operand a register_operand and
> avoid the REG_P check.
I agree. I implemented this change and it works as expected.
>More importantly:
>
>>operands[4] = simplify_gen_subreg(QImode,operands[1],HImode,0);
>>operands[5]
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
Richard Sandiford wrote:
> Also, you need to beware of cases in which operands[1] overlaps
> operands[0]. The splitter says:
>
> [(set (match_dup 2) (match_dup 4))
> (set (match_dup 3) (match_dup 5))]
>
> and operands[2] is always the highpart:
>
>operands[2] = gen_highpart(QImode, operands
Dear All,
I recently started working in a GCC backend, and as a result I expect
to be actively participating in the ML.
That said, I have questions on how to properly and efficiently do a
post. I want to remove the annoyances that at the end just unnecessary
waste everyone's time.
1- I notice
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.
>
> I am sure that you have modified
Hi All,
I am getting the error message bellow while hacking my gcc backend.
Any suggestions on how to fix this?
error: insn does not satisfy its constraints:
(insn 25 50 26 2 (set (reg:HI 1 %r0 [33])
(plus:HI (mem/s/j:HI (plus:HI (reg:HI 3 %r2)
(reg/v/f:HI 11 %i2h [
shafi wrote:
>Operand 0 is a register
>Operand 1 is a memory
>Operand 2 is a register
>
>
>> The md description for this instruction is:
>>
>> ;; addhi3
>> (define_expand "addhi3"
>> [(set (match_operand:HI 0 "register_operand" "")
>> (plus:HI (match_operand:HI 1 "coo
20 matches
Mail list logo
