Eric Fisher <[EMAIL PROTECTED]> writes:
> dp-bit.c: In function `__pack_d':
> dp-bit.c:435: error: unrecognizable insn:
> (insn 33 32 34 0 dp-bit.c:167 (set (reg:SI 159)
> (ltu:SI (reg:SI 158 [ .class ])
> (const_int 2 [0x2]))) -1 (insn_list 32 (nil))
> (nil))
> dp-bit.c:43
>It shouldn't. What is the actual error message?
>
>Ian
Such as follows,
dp-bit.c: In function `__pack_d':
dp-bit.c:435: error: unrecognizable insn:
(insn 33 32 34 0 dp-bit.c:167 (set (reg:SI 159)
(ltu:SI (reg:SI 158 [ .class ])
(const_int 2 [0x2]))) -1 (insn_list 32 (nil))
Eric Fisher <[EMAIL PROTECTED]> writes:
> Thanks. And there is another question. I've been told that 'scond'
> operations are not obligatory defined. If they are not defined then
> they will use 'bcond' like. But while I omit 'scond', gcc will fail
> error that such operation rtl doesn't define. S
>Probably because it was optimized. If you want a better answer, you
>have to give us more info about what happened, such as a C testcase, and
>RTL dumps. But it is probably better if you look at this yourself.
>Generate debugging dumps, -da -fdump-tree-all, and then start looking.
>Presumably an
Eric Fisher wrote:
This is a strange problem. Why an operantion that should be a 'xorsi3'
format, yet it comes out with a 'scond' format.
Probably because it was optimized. If you want a better answer, you
have to give us more info about what happened, such as a C testcase, and
RTL dumps. B
Hello,
This is a strange problem. Why an operantion that should be a 'xorsi3'
format, yet it comes out with a 'scond' format. I have defined
'xorsi3' indeed. When I use the encluesive operantion '^', it is ok to
emit 'xorsi3'. When I compile the libgcc, it is not ok in _pack_df.o.
So what's the pro
