Ian Lance Taylor wrote:
> "Ulrich Weigand" writes:
> > The way some ports take around this issue is to recognize, in your
> > EXTRA_CONSTRAINT_STR implementation, certain forms of complex
> > addresses as those which you *know* reload will already have marked
> > for reloading, and therefore *acce
"Ulrich Weigand" writes:
> The way some ports take around this issue is to recognize, in your
> EXTRA_CONSTRAINT_STR implementation, certain forms of complex
> addresses as those which you *know* reload will already have marked
> for reloading, and therefore *accept* them (if they'd otherwise
> m
Bingfeng Mei wrote:
> I think I found the cause. find_reloads_address returns 0 even
> it reloads both parts of address (see the patch). Therefore,
> corresponding address_reloaded[i] is not set and in
> the following code of find_reloads,
>
>if (EXTRA_CONSTRAINT_STR (operand, c, p))
>
"Bingfeng Mei" writes:
> I think I found the cause. find_reloads_address returns 0 even
> it reloads both parts of address (see the patch). Therefore,
> corresponding address_reloaded[i] is not set and in
> the following code of find_reloads,
>
>if (EXTRA_CONSTRAINT_STR (operand, c, p))
>
Hi, Ian,
I think I found the cause. find_reloads_address returns 0 even
it reloads both parts of address (see the patch). Therefore,
corresponding address_reloaded[i] is not set and in
the following code of find_reloads,
if (EXTRA_CONSTRAINT_STR (operand, c, p))
win = 1;
/* If the address
"Bingfeng Mei" writes:
> from gen_reload function.
> /* Otherwise, just write (set OUT IN) and hope for the best. */
> else
> emit_insn (gen_rtx_SET (VOIDmode, out, in));
Those lines are one of the curses of reload. When you hit them, you
know something has gone wrong. Unfortunately,
A couple of conflicts in the merge, but nothing too big.
Bootstrapped and tested on x86_64.
gcc/ChangeLog.pph
Mainline merge r167963.
* BASE-VER: Update revision stamp.
libcpp/ChangeLog.pph
* internal.h (struct cpp_lookaside): Rename field
flag_pth_debug to pth
On Fri, Dec 17, 2010 at 06:00, Eugen Wagner wrote:
> int a;
> a = 100;
> The variable a is not wrapped into SSA_NAME a_1.
Because 'a' is a "memory variable". Memory is never rewritten into
SSA form. To represent memory, we use factored use-def chains (the
VDEF/VUSE notation you see in the dum
Quoting Nathan Froyd :
The grand plan (I was waiting until I had a patch to talk about this,
but since you asked...), looks something like this:
- Hookize FUNCTION_ARG &co. (patch approved, I need to reassure myself
that some of the const-ization in the patch isn't going to break
bootstrap
Hi,
noticed, that after converting into ssa-form, there are still
variables, which are not wrapped into SSA_NAME.
Assigment to scalar variable:
int a;
a = 100;
The variable a is not wrapped into SSA_NAME a_1.
b = foo();
is converted into
b.0_3 = foo ();
# .MEM_25 = VDEF <.MEM_24>
b = b.0_3;
Ian,
Thanks for the reply.
Basically GCC generates an unrecognizable instruction during reload
src/weighted_prediction.c:815:1: error: unrecognizable insn:
(insn 1716 1715 680 84 src/weighted_prediction.c:729 (set (reg:SI 4 r4)
(plus:SI (mult:SI (reg:SI 9 r9)
(const_int 8
Hi Ian, thanks for the response.
I did manage to fix it. The problem was in my call_internal
implementation. I went back and looked again at the arm implementation
and spotted what I'd done wrong.
Sorry for the bother.
On 17 December 2010 01:21, Ian Lance Taylor wrote:
> Neil Hickey writes:
>
12 matches
Mail list logo
