Hello all,
I just want to know about the feasibility of implementing an
instruction for a port in gcc 4.4
The target has 40 bit register where the normal load/store/move
instructions will be able to access the 32 bits of the register. In
order to move data into the rest of the register [b32 to b39
Hi, Jeff:
Thanks. I fixed the bug. The problem is in GO_IF_LEGITIMATE_ADDRESS. In
the reload processing, find_reload function will check the operand address
whether it is effective. I traced the function, and found my
GO_IF_LEGITIMATE_ADDRESS macro thought the following address is strict
legit
Jun Sun writes:
> If you or someone could point out where are the code section is for
> adding this support for those arches, or even better, provide some
> hints for us to search the related svn history, that would be really
> helpful. We might get brave enough to add this code for ARM (probably
On 07/01/2009 02:49 PM, Amitabha Roy wrote:
A search led me to this message
http://gcc.gnu.org/ml/gcc/2005-11/msg00206.html
which says that it is true, or at least was true back then.
Still true today.
r~
Ian Lance Taylor wrote:
Haitao Zhang writes:
we recently use GCC 4.3.3 to build userland application use ARM EABI,
for running on a ARM7TDMI, mmuless platform.
after explicit compile application with -fstack-limit-register=R10,
there is no binary change with or without this option. Does this
Hi
I am working on transforming x86 binaries generated with gcc and
wanted to know whether gcc treats the eflags register as a single unit
when generating code or actually tracks individual flags.
My question is motivated by an optimisation I am making in my tool
that assumes that any instruction
On 07/01/2009 02:02 PM, Jean Christophe Beyler wrote:
((reload_in_progress | reload_completed) == 0&&
MEM_P (op0)&& !REG_P (op1)))
{
op1 = force_reg (GET_MODE (op0), op1);
emit_move_insn (op0, op1);
return 1;
I wouldn't think you'd actu
I tried something similar:
(define_expand "movdi"
[(set (match_operand:DI 0 "nonimmediate_operand" "")
(match_operand:DI 1 "general_operand" ""))]
""
"
if(my_expand_move (operands[0], operands[1]))
DONE;
")
(define_insn "movdi_internal1"
[(set (match_operand:DI 0 "non
On 07/01/2009 11:28 AM, Jean Christophe Beyler wrote:
Ok, I think I understand, I've been therefore playing with this. I
initially had:
(define_insn "movdi_internal1"
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R,T,r,R,o")
(match_operand:DI 1 "general_operand" "r,iF
Haitao Zhang writes:
> we recently use GCC 4.3.3 to build userland application use ARM EABI,
> for running on a ARM7TDMI, mmuless platform.
>
> after explicit compile application with -fstack-limit-register=R10,
> there is no binary change with or without this option. Does this option work?
>
> a
"Ronald F. Guilmette" writes:
> I'd like to propose a small enhancement for the GNU preprocessor, i.e.
> the addition of a new __MACRO__ pre-defined built-in symbol.
We support the __COUNTER__ macro these days. To get __COUNTER__ to be
expaned as you wish, you have to pass it through another ma
Ok, I think I understand, I've been therefore playing with this. I
initially had:
(define_insn "movdi_internal1"
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R,T,r,R,o")
(match_operand:DI 1 "general_operand" "r,iF,R,J,J,o,r,r"))]
For my movdi. I therefore first wanted
On 07/01/2009 08:36 AM, Jean Christophe Beyler wrote:
I tracked it down to the gcse pass. However, I thought I had turned
this off in the definition of a movdi in my machine description. But
apparently this is not sufficient, any ideas?
You probably just changed the constraint letters, but didn
Dear all,
I have this weird issue that I can't really understand:
In my architecture I do not have a store immediate into memory, I have
to go through a register.
However, the compiler is currently propagating constants into the
stores. So for example:
(insn 44 43 45 4 st3.c:21 (set (reg:DI 119
Paolo Bonzini wrote:
> I'm reverting the expand_expr_real_1 part (the part that introduced the
> assertion).
I see, thanks for your prompt feedback,
Olivier
Here it is. I committed it.
2009-07-01 Paolo Bonzini
* expr.c (expand_expr_real_1): Reinstate fallthrough to
TRUTH_ANDIF_EXPR.
Index: expr.c
===
--- expr.c (revision 149135)
+++ expr.c (working copy)
@
Could you please have a look ?
I'm reverting the expand_expr_real_1 part (the part that introduced the
assertion).
Paolo
Hello Paolo,
It seems to me that this piece of your r149032 change ...
* expr.c (expand_expr_real_1): Just use do_store_flag.
--- expr.c (revision 149031)
+++ expr.c (revision 149032)
@@ -9109,50 +9109,9 @@
temp = do_store_flag (exp,
modifier
Larry Evans wrote:
> On 06/30/09 12:59, Jonathan Wakely wrote:
>> 2009/6/30 Larry Evans:
>>> So... I read `man gcc` which claimed passing "CFLAGS=" on the
>>> command line is how to do this. Well, since in my case was
>>> '-g3 -O0' I had to pass it as CFLAGS='-g3 oO0'.
>>
>> http://gcc.gnu.org/in
On 06/30/09 12:59, Jonathan Wakely wrote:
2009/6/30 Larry Evans:
So... I read `man gcc` which claimed passing "CFLAGS=" on the
command line is how to do this. Well, since in my case was
'-g3 -O0' I had to pass it as CFLAGS='-g3 oO0'.
http://gcc.gnu.org/install/build.html
If you wish to use
20 matches
Mail list logo
