Re: howto configure so that CFLAGS='-g3 -O0' in gcc/Makefile?
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 non-default GCC flags when compiling the stage2 and
stage3 compilers, set BOOT_CFLAGS on the command line when doing
`make'.
Thanks Jonathan.
I also noticed the same info here:
http://gcc.gnu.org/wiki/DebuggingGCC
Well, I think what I did that; however, when I got into gdb, I got this:
#{##
Current directory is ~/download/gcc/4.4-20090630/build/gcc/
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Breakpoint 1 at 0x411136: file
/home/evansl/download/gcc/4.4-20090630/build/../src/gcc/gcc.c, line 7008.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
Function "exit" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
Function "abort" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
No source file named parser.c.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
/home/evansl/download/gcc/4.4-20090630/build/gcc/.gdbinit:13: Error in
sourced command file:
No symbol "expand_location" in current context.
(gdb) run
Starting program: /home/evansl/download/gcc/4.4-20090630/build/gcc/g++
-std=gnu++0x bug.dir/bug.cpp
warning: failed to reevaluate condition for breakpoint 1: No symbol
"expand_location" in current context.
warning: failed to reevaluate condition for breakpoint 1: No symbol
"expand_location" in current context.
g++: error trying to exec 'cc1plus': execvp: No such file or directory
Program exited with code 01.
(gdb)
#}##
What am I doing wrong now? Should I do `make install` also?
OOPS, tried that and didn't help.
Please help!
-regards,
Larry
Re: howto configure so that CFLAGS='-g3 -O0' in gcc/Makefile?
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/install/build.html
>>
>> If you wish to use non-default GCC flags when compiling the stage2 and
>> stage3 compilers, set BOOT_CFLAGS on the command line when doing
>> `make'.
>>
>
> Thanks Jonathan.
>
> I also noticed the same info here:
>
> http://gcc.gnu.org/wiki/DebuggingGCC
>
> Well, I think what I did that; however, when I got into gdb, I got this:
>
> #{##
> Current directory is ~/download/gcc/4.4-20090630/build/gcc/
> GNU gdb 6.8-debian
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu"...
> Breakpoint 1 at 0x411136: file
> /home/evansl/download/gcc/4.4-20090630/build/../src/gcc/gcc.c, line 7008.
> Function "internal_error" not defined.
> Make breakpoint pending on future shared library load? (y or [n])
> [answered N; input not from terminal]
> Function "exit" not defined.
> Make breakpoint pending on future shared library load? (y or [n])
> [answered N; input not from terminal]
> Function "abort" not defined.
> Make breakpoint pending on future shared library load? (y or [n])
> [answered N; input not from terminal]
> No source file named parser.c.
> Make breakpoint pending on future shared library load? (y or [n])
> [answered N; input not from terminal]
> /home/evansl/download/gcc/4.4-20090630/build/gcc/.gdbinit:13: Error in
> sourced command file:
> No symbol "expand_location" in current context.
> (gdb) run
> Starting program: /home/evansl/download/gcc/4.4-20090630/build/gcc/g++
> -std=gnu++0x bug.dir/bug.cpp
> warning: failed to reevaluate condition for breakpoint 1: No symbol
> "expand_location" in current context.
> warning: failed to reevaluate condition for breakpoint 1: No symbol
> "expand_location" in current context.
> g++: error trying to exec 'cc1plus': execvp: No such file or directory
>
> Program exited with code 01.
> (gdb)
> #}##
>
> What am I doing wrong now? Should I do `make install` also?
> OOPS, tried that and didn't help.
Are you trying to debug the compiler, or the compiler driver?
If the compiler, debug cc1 or cc1plus, not gcc.
If the driver, pass -B/path/to/build/gcc/ to gcc.
Andrew.
pa-hpux bootstrap failure after "post-cond-optab improvements"
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 != EXPAND_STACK_PARM ? target : NULL_RTX,
tmode != VOIDmode ? tmode : mode);
- if (temp != 0)
- return temp;
+ gcc_assert (temp);
+ return temp;
causes bootstrap to fail on pa-hpux. The first level visible behavior is
a stop at the beginning of stage2
.../libiberty/sigsetmask.c:28:1: error: conflicting types for 'sigsetmask'
/usr/include/sys/signal.h:256:18: note: previous declaration ...
This is caused by configure missing the existing declaration because
configure:6773: checking for sigsetmask
...
conftest.c: In function 'main':
conftest.c:76:1: : in expand_expr_real_1, at expr.c:9112
This reproduces on the tiny case below:
/* err.c */
extern char asprintf ();
char (*f) () = asprintf;
int
main ()
{
return f != asprintf;
}
$ ./prev-gcc/cc1 err.c
err.c: In function 'main':
err.c:7:3: internal compiler error: in expand_expr_real_1, at expr.c:9112
we hit the newly introduced assert with do_store_flag returning 0 out of
/* We won't bother with store-flag operations involving function pointers
when function pointers must be canonicalized before comparisons. */
#ifdef HAVE_canonicalize_funcptr_for_compare
if (HAVE_canonicalize_funcptr_for_compare
&& ((TREE_CODE (TREE_TYPE (TREE_OPERAND (exp, 0))) == POINTER_TYPE
&& (TREE_CODE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 0
== FUNCTION_TYPE))
|| (TREE_CODE (TREE_TYPE (TREE_OPERAND (exp, 1))) == POINTER_TYPE
&& (TREE_CODE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 1
== FUNCTION_TYPE
return 0;
#endif
Could you please have a look ?
Thanks in advance,
Olivier
Re: pa-hpux bootstrap failure after "post-cond-optab improvements"
Could you please have a look ? I'm reverting the expand_expr_real_1 part (the part that introduced the assertion). Paolo
Re: pa-hpux bootstrap failure after "post-cond-optab improvements"
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)
@@ -9109,8 +9109,10 @@
tmode != VOIDmode ? tmode : mode);
- gcc_assert (temp);
- return temp;
+ if (temp)
+ return temp;
+ /* Use a compare and a jump for BLKmode comparisons, or for
+functions if HAVE_canonicalize_funcptr_for_compare. */
+
/* Although TRUTH_{AND,OR}IF_EXPR aren't present in GIMPLE, they
are occassionally created by folding during expansion. */
case TRUTH_ANDIF_EXPR:
Re: pa-hpux bootstrap failure after "post-cond-optab improvements"
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
Immediates propagated wrongly in stores
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)
(const_int 1 [0x1])) -1 (nil))
(insn 45 44 46 4 st3.c:21 (set (mem/s:DI (reg:DI 109 [ ivtmp.43 ]) [2
data S8 A64])
(reg:DI 119)) -1 (nil))
is transformed into :
(insn 46 44 48 3 st3.c:22 (set (mem/s:DI (reg:DI 109 [ ivtmp.43 ]) [2
data S8 A64])
(const_int 1 [0x1])) 72 {movdi_internal1} (expr_list:REG_EQUAL
(const_int 1 [0x1])
(nil)))
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?
As always, thanks for your time,
Jean Christophe Beyler
Re: Immediates propagated wrongly in stores
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't change the operand predicate. The constraint letters are only used during register allocation, and the predicate is used elsewhere. (match_operand:MODE N "predicate_function" "constraint_letters") There are a number of pre-defined predicate functions you can use, register_operand nonmemory_operand nonimmediate_operand general_operand and most ports find they need special ones to exactly match the characteristics of some insns. e.g. cpu.md: (define_insn "*adddi_internal" [(set (match_operand:DI 0 "register_operand" "=r,r,r") (plus:DI (match_operand:DI 1 "register_operand" "%r,r,r") (match_operand:DI 2 "add_operand" "r,K,L")))] "" "@ addq %1,%2,%0 lda %0,%2(%1) ldah %0,%h2(%1)") predicates.md: (define_predicate "add_operand" (if_then_else (match_code "const_int") (match_test "satisfies_constraint_K (op) || satisfies_constraint_L (op)") (match_operand 0 "register_operand"))) You should strive to ensure that the predicate function exactly matches the constraint letters. If the predicate function accepts more than the constraint letters, the reload pass will fix it up. But better code is generated when reload doesn't need to do this. r~
Re: Immediates propagated wrongly in stores
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 to handle the fact that I won't
allow stores to use immediates so I thought of changing the above
into:
(define_insn "movdi_internal1"
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R,T,r,R,o")
(match_operand:DI 1 "move_operand" "r,iF,R,J,J,o,r,r"))]
And then defining a simple predicate:
(define_predicate "move_operand"
(if_then_else (match_operand 0 "register_operand")
(match_operand 1 "general_operand")
(match_operand 1 "register_operand")))
For me this means :
If the first operand is a register (that would then either be a
register-register move or a load),
Then return whether or not operand 1 is a general operand
Else it's a memory operand (by definition of the
nonimmediate_operand predicate) and
return whether or not operand 1 is a register operand
In essence, it seemed to me that this should work as a first draft in
rewriting the whole movdi (and let me test it). However, this makes
the compiler fail on this instruction (unrecognisable)
st4.c:66: error: unrecognizable insn:
(insn 41 40 42 3 st4.c:22 (set (reg/f:DI 119)
(symbol_ref:DI ("data") )) -1 (nil))
For me this doesn't make sense since in this set, the predicate should
check the first register. The test of the if should be true, therefore
matching the second operand to a "general_operand" that it is, no?
Thanks for your help,
Jean Christophe Beyler
On Wed, Jul 1, 2009 at 12:23 PM, Richard Henderson wrote:
> 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't change
> the operand predicate. The constraint letters are only used during
> register allocation, and the predicate is used elsewhere.
>
> (match_operand:MODE N "predicate_function" "constraint_letters")
>
> There are a number of pre-defined predicate functions you can use,
>
> register_operand
> nonmemory_operand
> nonimmediate_operand
> general_operand
>
> and most ports find they need special ones to exactly match the
> characteristics of some insns. e.g.
>
> cpu.md:
> (define_insn "*adddi_internal"
> [(set (match_operand:DI 0 "register_operand" "=r,r,r")
> (plus:DI (match_operand:DI 1 "register_operand" "%r,r,r")
> (match_operand:DI 2 "add_operand" "r,K,L")))]
> ""
> "@
> addq %1,%2,%0
> lda %0,%2(%1)
> ldah %0,%h2(%1)")
>
> predicates.md:
> (define_predicate "add_operand"
> (if_then_else (match_code "const_int")
> (match_test "satisfies_constraint_K (op) ||
> satisfies_constraint_L (op)")
> (match_operand 0 "register_operand")))
>
> You should strive to ensure that the predicate function exactly
> matches the constraint letters. If the predicate function accepts
> more than the constraint letters, the reload pass will fix it up.
> But better code is generated when reload doesn't need to do this.
>
>
> r~
>
Re: A small (preprocessor) problem, and a modest enhancement proposal
"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 macro
expansion. So, for example, something like the following should work.
#define APP(a, b) a ## b
#define VARNAME(a, b) APP(a, b)
#define foo1(ARG1,ARG2,V1,V2) \
{ \
register int V1 = ARG1; \
register int V2 = ARG2; \
foobar = V1 + V2; \
}
#define foo(ARG1,ARG2) \
foo1(ARG1, ARG2, VARNAME(macro_arg1_, __COUNTER__), \
VARNAME(macro_arg2_, __COUNTER__))
#define bar1(ARG1,ARG2,V1,V2) \
{ \
register int V1 = ARG1; \
register int V2 = ARG2; \
foo (V1, V2); \
}
#define bar(ARG1,ARG2) \
bar1(ARG1, ARG2, VARNAME(macro_arg1_, __COUNTER__), \
VARNAME(macro_arg2_, __COUNTER__))
Ian
Re: -fstack-limit-register not work for ARM?
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? > > another thing, in old GCC 3.x series, there is a -mapcs-stack-check, > but once GCC and ARM ABI upgraded to use AAPCS, > seems there is no such option like -maapcs-stack-check. This e-mail message is appropriate for the mailing list gcc-h...@gcc.gnu.org, not g...@gcc.gnu.org. Please take any followups to gcc-h...@gcc.gnu.org. Thanks. -fstack-limit-register will affect the use of alloca and variable length arrays on ARM. However, it will not affect ordinary functions. It looks like the backend support for -fstack-limit-register was only ever implemented for Blackfin, m68k, and PPC. This seems like an omission which should be documented. It was added here: http://gcc.gnu.org/ml/gcc-patches/1999-11/msg00739.html and was never really carried forward. I don't think it would be very difficult to add it to the ARM backend, but somebody would have to actually do the work. You're right that there is no -maacps-stack-check option, and in fact -mapcs-stack-check doesn't work either. Sorry that I don't have better news on this front. Ian
Re: Immediates propagated wrongly in stores
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,R,J,J,o,r,r"))]
For my movdi. I therefore first wanted to handle the fact that I won't
allow stores to use immediates so I thought of changing the above
into:
(define_insn "movdi_internal1"
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R,T,r,R,o")
(match_operand:DI 1 "move_operand" "r,iF,R,J,J,o,r,r"))]
And then defining a simple predicate:
(define_predicate "move_operand"
(if_then_else (match_operand 0 "register_operand")
(match_operand 1 "general_operand")
(match_operand 1 "register_operand")))
Predicates can only examine one operand, not two.
However, you can write
(define_expand "movdi"
[(set (match_operand:DI "nonimmediate_operand" "")
(match_operand:DI "general_operand" ""))]
""
"my_expand_move (operands[0], operands[1]); DONE;")
(define_insn "*movdi_internal"
[(set (match_operand:DI 0 "nonimmediate_operand" "...")
(match_operand:DI 1 "general_operand" "..."))]
"my_move_ok (operands[0], operands[1])"
...)
void my_expand_move (rtx op0, rtx op1)
{
// Handle TLS, PIC and other special cases...
if (MEM_P (op0))
op1 = force_reg (mode, op1);
emit_insn (gen_rtx_SET (VOIDmode, op0, op1));
}
bool my_move_ok(rtx op0, rtx op1)
{
if (MEM_P (op0))
return register_operand (op1, VOIDmode);
return true;
}
Compare this with similar code in other ports.
r~
Re: Immediates propagated wrongly in stores
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 "nonimmediate_operand" "=r,r,r,R,T,r,R,o")
(match_operand:DI 1 "general_operand" "r,iF,R,J,J,o,r,r"))]
"my_move_ok (operands[0], operands[1])"
"* return my_move_2words (operands, insn); "
[(set_attr "type" "move,arith,load,store,store,load,store,store")
(set_attr "mode" "DI,DI,DI,DI,DI,DI,DI,DI")
(set_attr "length" "1,1,1,1,1,1,1,1")])
int my_expand_move (rtx op0, rtx op1)
{
/* Removed PIC, etc. for the moment */
if (
((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;
}
return 0;
}
bool my_move_ok(rtx op0, rtx op1)
{
if (MEM_P (op0))
return register_operand (op1, VOIDmode);
return true;
}
This seems to do what I want, now I'm going to clean up all those
constraints and see if they are compatible and work on from there.
Thanks for your help, tell me if my solution seems very bad,
Jc
On Wed, Jul 1, 2009 at 3:26 PM, Richard Henderson wrote:
> 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,R,J,J,o,r,r"))]
>>
>>
>> For my movdi. I therefore first wanted to handle the fact that I won't
>> allow stores to use immediates so I thought of changing the above
>> into:
>>
>> (define_insn "movdi_internal1"
>> [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R,T,r,R,o")
>> (match_operand:DI 1 "move_operand" "r,iF,R,J,J,o,r,r"))]
>>
>> And then defining a simple predicate:
>>
>> (define_predicate "move_operand"
>> (if_then_else (match_operand 0 "register_operand")
>> (match_operand 1 "general_operand")
>> (match_operand 1 "register_operand")))
>
> Predicates can only examine one operand, not two.
>
> However, you can write
>
> (define_expand "movdi"
> [(set (match_operand:DI "nonimmediate_operand" "")
> (match_operand:DI "general_operand" ""))]
> ""
> "my_expand_move (operands[0], operands[1]); DONE;")
>
> (define_insn "*movdi_internal"
> [(set (match_operand:DI 0 "nonimmediate_operand" "...")
> (match_operand:DI 1 "general_operand" "..."))]
> "my_move_ok (operands[0], operands[1])"
> ...)
>
> void my_expand_move (rtx op0, rtx op1)
> {
> // Handle TLS, PIC and other special cases...
>
> if (MEM_P (op0))
> op1 = force_reg (mode, op1);
>
> emit_insn (gen_rtx_SET (VOIDmode, op0, op1));
> }
>
> bool my_move_ok(rtx op0, rtx op1)
> {
> if (MEM_P (op0))
> return register_operand (op1, VOIDmode);
> return true;
> }
>
> Compare this with similar code in other ports.
>
>
>
> r~
>
Re: Immediates propagated wrongly in stores
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 actually need these reload checks.
At least some other ports I glanced at don't need them.
r~
gcc and x86 condition codes
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 that writes to the eflags register kills it and no subsequent instructions can try to access any flags not written by this instruction. Is this assumption correct in current gcc (>= 4.0.0). 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. Cheers -Amitabha
Re: -fstack-limit-register not work for ARM?
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 option work? another thing, in old GCC 3.x series, there is a -mapcs-stack-check, but once GCC and ARM ABI upgraded to use AAPCS, seems there is no such option like -maapcs-stack-check. This e-mail message is appropriate for the mailing list gcc-h...@gcc.gnu.org, not g...@gcc.gnu.org. Please take any followups to gcc-h...@gcc.gnu.org. Thanks. -fstack-limit-register will affect the use of alloca and variable length arrays on ARM. However, it will not affect ordinary functions. It looks like the backend support for -fstack-limit-register was only ever implemented for Blackfin, m68k, and PPC. This seems like an omission which should be documented. It was added here: http://gcc.gnu.org/ml/gcc-patches/1999-11/msg00739.html and was never really carried forward. I don't think it would be very difficult to add it to the ARM backend, but somebody would have to actually do the work. You're right that there is no -maacps-stack-check option, and in fact -mapcs-stack-check doesn't work either. Sorry that I don't have better news on this front. Thanks for the confirmation. 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 after drinking some volka ;0) Cheers. Jun
Re: gcc and x86 condition codes
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~
Re: -fstack-limit-register not work for ARM?
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 > after drinking some volka ;0) [-fstack-limit-register for ARM] The place to change would be arm_expand_prologue, probably just after the last place which emits an add to stack_pointer_rtx. Ian
RE: How to deal with unrecognizable RTL code
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 legitimate address: mem/s:SI (plus:SI (reg/v/f:SI 91 [ frame ]) (const_int 4 [0x4])) Of course it is not a valid address in strict mode. And a logical error was found in my rice_reg_ok_for_base function. After fixing it, cc1 works well . Thank you very much! Daniel.tian ___ Best Regards Daniel Tian Mavrix Technology, Inc. Address：200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech Park, Shanghai, P.R.China (201204) Tel:86(21)51095958 - 8125 Fax:86(21)50277658 email：daniel.t...@mavrixtech.com.cn www.mavrixtech.com
About feasibility of implementing an instruction
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] the data has to be stored into a 32bit memory location. The data should be stored in such a way that if it is stored for 0-7 in memory the data can be moved to b32-b39 of a even register and if the data in the memory is stored in 16-23 of the memory word then it can be moved to b32-b39 of a odd register. Hope i make myself clear. Will it be possible to implement this in the gcc back-end so that the particular instruction is supported? Regards, Shafi
