-dv -fdump-rtl-all question
Hi list, Is it ok to assume that when I compile a C file (that is guranteed to have some code in it) under the following flags, I always get the mentioned VCG file (and do not get a bigger one) ? Flags Maximum VCG file that is always created === " -dv -fdump-rtl-all" .49.stack.vcg "-O1 -dv -fdump-rtl-all" .49.stack.vcg "-O2 -dv -fdump-rtl-all" .50.compgotos.vcg "-O3 -dv -fdump-rtl-all" .50.compgotos.vcg So basically I want to assume the maximum vcg file that is created is a function of the optimizations and not a function of the source file.. thank you! sunzir
Re: SH2A: "RTV/N Rn" implementation
On Wed, Jul 18, 2007 at 12:11:28PM +0530, Naveen H.S. wrote:
> Hi,
>
> We had implemented an insn as:-
>
> (define_insn "return_rtv"
> [(parallel [
> (set (reg:SI R0_REG)
> (match_operand:SI "register_operand" "r"))
> (return)])]
This is actually what I had in mind. You just need to also modify the
epilogue expander to use that insn:
(define_expand "epilogue"
[(return)]
""
"
{
sh_expand_epilogue (0);
if (HAVE_return_rtv)
emit_jump_insn (gen_return_rtv (gen_rtx_REG (SImode, R0_REG)));
else
emit_jump_insn (gen_return ());
DONE;
}")
--
Rask Ingemann Lambertsen
Re: Execute test fails in gcc testsuite
On 7/18/07, Venkatesan Jeevanandam <[EMAIL PROTECTED]> wrote: I am working on the testsuite for a new crosscompiler hosted on x86 Platform, While performing execute test using gcc testsuite, I am getting the error message in execute test /tmp/2112-1.x0: /tmp/2112-1.x0: cannot execute binary file I know, have to use cross compiler simulator, for executing $Arch-sim /tmp/2112-1.x0 But I don't know where to mention this configuration. Since you havent mentioned anything about your .exp file in dejagnu/baseboards, I am assuming you havent already written one. Therefore you will need to write a .exp file ( e.g arm-sim.exp) file and put it in the dejagnu/baseboards directory. Then while doing make check-gcc pass it using the RUNTESTLFAG command line argument. Typically, $> make check-gcc RUNTESTFLAGS="--target_board=-sim" HTH, Pranav
Error referencing symbols in gdb when compiled with gcc 3.4.6
Hello, I am having a problem when using gcc 3.4.6. My code was compiled earlier using gcc 3.2.2 with the -g option. I was able to print the addess of any symbol or do a "ptype" on any symbol using gdb 6.4 with the generated binary. Now I compile the very same code using gcc 3.4.6 using the -g option again. Here, I get an error saying "There is no field/member named ". This very symbol was found when the code was compiled using gcc 3.2.2. To solve this problem, I followed two workarounds - but I do not understand why they worked with those workarounds. Workaround 1: I tried to compile the code with gcc 3.4.6 using -gstabs+ option instead of with -g. This resulted in the symbols being found and I could proceed with debugging using gdb 6.4 as before. No problems at all. Workaround 2 : I changed the order of linking the .o files to my resulting binary. The .o files where the symbol referencing was problematic were placed on top of the list of the object files to be linked. Now when I debug the resulting binary, things work perfectly again as it did earlier with the older compiler. I don't know why this is a problem. Is this a problem with giving the compiler options or is it a linker problem ? Or does it have to do with a problem of using the right debug formats (stabs, dwarf). Any help here will be highly appreciated. I've reached the dead end and do not know how to proceed further. Regards, Kalpana Balaji _ Wedding bells are ringing. When's your time to walk the aisle? http://ad.in.doubleclick.net/clk;112111293;17571293;v?http://www.simplymarry.com/timesmatri/faces/jsp/UserTrackLandingPage.jsp?origin=hotmail_taglines_ros_june07
Re: -dv -fdump-rtl-all question
On 7/18/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote: Hi list, Is it ok to assume that when I compile a C file (that is guranteed to have some code in it) under the following flags, I always get the mentioned VCG file (and do not get a bigger one) ? Flags Maximum VCG file that is always created === " -dv -fdump-rtl-all" .49.stack.vcg "-O1 -dv -fdump-rtl-all" .49.stack.vcg "-O2 -dv -fdump-rtl-all" .50.compgotos.vcg "-O3 -dv -fdump-rtl-all" .50.compgotos.vcg So basically I want to assume the maximum vcg file that is created is a function of the optimizations and not a function of the source file.. Why? There's no guarantee, although usually on any particular version of gcc on a given platform with given options, probably it is. -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Re: Can realloc be marked as a mallloc-like function?
On Tue, Jul 17, 2007 at 09:53:30AM -, Wolfram Gloger wrote: > Surely you agree that in my second example, "*p = 0" _cannot_ be moved > after the call to destroy_something_and_allocate_anotherthing(p)? It can't be moved after, but it could be removed entirely as dead code. I don't think we have a pass that will do that presently, but I see no reason why it couldn't happen some day, more or less automatically, with a pass that analyzes lifetimes of dynamic allocations. r~
FRE - SCCVN problem with initialized global variables
Hi,
GCC currently doesn't bootstrap on s390x. The problem is that
gengtype is miscompiled and I suspect the fre - sccvn changes to be
the culprit.
When sccvn performs the depth-first search for uses it might reach
global variable definitions. If the global variable is initialized
with a value that value is taken as constant and used to replace uses
of that variable.
e.g.:
int global = 1;
int
foo (int a)
{
return a != global;
}
int
main ()
{
global = 3;
if (foo (3))
abort ();
}
becomes (compiled with -O1):
foo (a)
{
int global.0;
int D.1626;
:
global.0_1 = 1;
D.1626_3 = a_2(D) != global.0_1;
return D.1626_3;
}
...
The example works fine when removing the initialization of global.
Bye,
-Andreas-
Here is the complete fre output:
;; Function foo (foo)
SCC consists of: global_5(D)
Value numbering global_5(D) stmt = (void) 0;
Setting value number of global_5(D) to global_5(D)
SCC consists of: a_2(D)
Value numbering a_2(D) stmt = (void) 0;
Setting value number of a_2(D) to a_2(D)
SCC consists of: global.0_1
Value numbering global.0_1 stmt = global.0_1 = global;
RHS global simplified to 1 has constants 0
Setting value number of global.0_1 to 1
SCC consists of: D.1626_3
Value numbering D.1626_3 stmt = D.1626_3 = a_2(D) != global.0_1;
Setting value number of D.1626_3 to D.1626_3
Value numbers:
global.0_1 = 1
Created value VH.0 for a_2(D)
SCCVN says global.0_1 value numbers to 1
Created value VH.1 for D.1626_3
Created value VH.2 for _4
exp_gen[0] := { }
tmp_gen[0] := { }
avail_out[0] := { a_2(D) (VH.0) }
exp_gen[2] := { }
tmp_gen[2] := { _4 (VH.2) }
avail_out[2] := { a_2(D) (VH.0) , D.1626_3 (VH.1) , _4 (VH.2) }
exp_gen[1] := { }
tmp_gen[1] := { }
avail_out[1] := { }
Replaced global with 1 in global.0_1 = global;
foo (a)
{
int global.0;
int D.1626;
:
global.0_1 = 1;
D.1626_3 = a_2(D) != global.0_1;
return D.1626_3;
}
;; Function main (main)
SCC consists of: global_2(D)
Value numbering global_2(D) stmt = (void) 0;
Setting value number of global_2(D) to global_2(D)
SCC consists of: global_3
Value numbering global_3 stmt = global = 3;
No store match
Value numbering store global to 3
Setting value number of global_3 to global_3
SCC consists of: D.1630_1
Value numbering D.1630_1 stmt = D.1630_1 = foo (3);
Setting value number of D.1630_1 to D.1630_1
Value numbers:
Created value VH.3 for D.1630_1
exp_gen[0] := { }
tmp_gen[0] := { }
avail_out[0] := { }
exp_gen[2] := { }
tmp_gen[2] := { }
avail_out[2] := { D.1630_1 (VH.3) }
exp_gen[3] := { }
tmp_gen[3] := { }
avail_out[3] := { D.1630_1 (VH.3) }
exp_gen[4] := { }
tmp_gen[4] := { }
avail_out[4] := { D.1630_1 (VH.3) }
exp_gen[1] := { }
tmp_gen[1] := { }
avail_out[1] := { }
main ()
{
int D.1630;
:
global = 3;
D.1630_1 = foo (3);
if (D.1630_1 != 0)
goto ;
else
goto ;
:
abort ();
:
return;
}
Re: Error referencing symbols in gdb when compiled with gcc 3.4.6
Kalpana Ramamurthy wrote: Hello, I am having a problem when using gcc 3.4.6. My code was compiled earlier using gcc 3.2.2 with the -g option. I was able to print the addess of any symbol or do a "ptype" on any symbol using gdb 6.4 with the generated binary. Now I compile the very same code using gcc 3.4.6 using the -g option again. Here, I get an error saying "There is no field/member named ". This very symbol was found when the code was compiled using gcc 3.2.2. First, please don't cross-post to both gcc and gcc-help mailing lists. This belongs on gcc-help; future replies should only go to gcc-help. You can see if there is debugging information in the object file file by running "readelf -aw" and searching for the name. You may want to check both the object file and the executable. If the symbol appears to be defined correctly, then the problem may be in gdb. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
auto increment in simple mac loop is not created.
Hi,
I'm compiling the following c code with -O2 on ia64-linux, xtensa-linux,
bfin targets, gcc-4.2.0:
int loop(int a[], int b[],int sum)
{
unsigned int i;
for (i = 0; i < 100; i++)
sum+=a[i]*b[i];
return sum;
}
I don't see any auto increment of the pointers inside the loop in any
one of them.
(You can see below the assembly code outputted by each one).
I'm writing new DSP port and naturally auto increment inside such a loop
is extremely important.
Am I missing something here?
Thanks,
Tal.
xtensa-linux output:
.file "loop_pointers.c"
.global __mulsi3
.text
.literal_position
.literal .LC2, [EMAIL PROTECTED]
.align 4
.global loop
.type loop, @function
loop:
.frame sp, 32
entry sp, 32
l32i.n a11, a2, 0
l32ra5, .LC2
l32i.n a10, a3, 0
mov.n a6, a2
callx8 a5
add.n a2, a4, a10
movi.n a7, 4
movia4, 0x190
.L2:
add.n a8, a7, a3
add.n a9, a7, a6
l32i.n a10, a8, 0
l32i.n a11, a9, 0
addi.n a7, a7, 4
callx8 a5
add.n a2, a2, a10
bne a7, a4, .L2
retw.n
.size loop, .- loop
.ident "GCC: (GNU) 4.2.0"
Ia64-linux output:
.file "loop_pointers.c"
.pred.safe_across_calls p1-p5,p16-p63
.text
.align 16
.global loop#
.proc loop#
loop:
.prologue
.mmb
ld4 r15 = [r33]
ld4 r14 = [r32]
nop 0
.mmi
setf.sig f9 = r34
addl r17 = 4, r0
.save ar.lc, r2
mov r2 = ar.lc
.body
;;
.mmi
setf.sig f7 = r15
setf.sig f8 = r14
mov ar.lc = 98
;;
.mmf
nop 0
nop 0
xma.l f6 = f7, f8, f9
.L2:
.mmi
add r14 = r17, r33
add r16 = r17, r32
adds r17 = 4, r17
;;
.mmi
ld4 r15 = [r14]
ld4 r14 = [r16]
nop 0
;;
.mmi
setf.sig f7 = r15
setf.sig f8 = r14
nop 0
;;
.mfb
nop 0
xma.l f6 = f7, f8, f6
br.cloop.sptk.few .L2
;;
.mib
getf.sig r8 = f6
mov ar.lc = r2
br.ret.sptk.many b0
.endp loop#
.ident "GCC: (GNU) 4.2.0"
bfin output:
.file "loop_pointers.c";
.text;
.align 4
.global _loop;
.type _loop, STT_FUNC;
_loop:
[--sp] = ( p5:3 );
P3 = R0;
P4 = R1;
LINK 0;
P0 = 4 (X);
P5 = 99 (X);
R1 = [P3];
R0 = [P4];
R0 *= R1;
R2 = R2 + R0;
LSETUP (L$L$2, L$L$8) LC1 = P5;
L$L$2:
P2 = P0 + P4;
P1 = P0 + P3;
R0 = [P2];
R1 = [P1];
R0 *= R1;
P0 += 4;
L$L$8:
R2 = R2 + R0;
UNLINK;
R0 = R2;
( p5:3 ) = [sp++];
rts;
.size _loop, .-_loop
.ident "GCC: (GNU) 4.2.0"
Re: FRE - SCCVN problem with initialized global variables
On 7/18/07, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
Hi,
GCC currently doesn't bootstrap on s390x. The problem is that
gengtype is miscompiled and I suspect the fre - sccvn changes to be
the culprit.
When sccvn performs the depth-first search for uses it might reach
global variable definitions
No, global variable definitions are *never* the SSA_NAME_DEF_STMT of
anything, so it won't reach them.
We explicitly pull out initializers from variables that are:
/* Pull out any truly constant values. */
if (TREE_READONLY (rhs)
&& TREE_STATIC (rhs)
&& DECL_INITIAL (rhs)
&& valid_gimple_expression_p (DECL_INITIAL (rhs)))
return DECL_INITIAL (rhs);
This is exacfly the same set of constraints CCP uses, and my guess is
if you disable SCCVN from doing this, you will discover the same code
is generated anyway.
. If the global variable is initialized
with a value that value is taken as constant and used to replace uses
of that variable.
e.g.:
int global = 1;
int
foo (int a)
{
return a != global;
}
int
main ()
{
global = 3;
if (foo (3))
abort ();
}
becomes (compiled with -O1):
foo (a)
{
int global.0;
int D.1626;
:
global.0_1 = 1;
D.1626_3 = a_2(D) != global.0_1;
return D.1626_3;
}
...
This only happens where ipa-reference proves the global is readonly
and marks it TREE_READONLY
(in this case, because there are no external function calls)
HTH,
Dan
Re: Can realloc be marked as a mallloc-like function?
On 7/18/07, Richard Henderson <[EMAIL PROTECTED]> wrote: On Tue, Jul 17, 2007 at 09:53:30AM -, Wolfram Gloger wrote: > Surely you agree that in my second example, "*p = 0" _cannot_ be moved > after the call to destroy_something_and_allocate_anotherthing(p)? It can't be moved after, but it could be removed entirely as dead code. I don't think we have a pass that will do that presently, but I see no reason why it couldn't happen some day, more or less automatically, with a pass that analyzes lifetimes of dynamic allocations. Currently, the only thing that does prevent this optimization is the fact that passing p to realloc makes p escape and the memory pointed to clobbered. But the alias analysis code already has special case code that would prevent this from happening (just maybe not in all places right now) - whether this is a good idea or not is another question. Richard.
Re: Can realloc be marked as a mallloc-like function?
On 7/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On 7/18/07, Richard Henderson <[EMAIL PROTECTED]> wrote: > On Tue, Jul 17, 2007 at 09:53:30AM -, Wolfram Gloger wrote: > > Surely you agree that in my second example, "*p = 0" _cannot_ be moved > > after the call to destroy_something_and_allocate_anotherthing(p)? > > It can't be moved after, but it could be removed entirely as dead code. > > I don't think we have a pass that will do that presently, but I see no > reason why it couldn't happen some day, more or less automatically, with > a pass that analyzes lifetimes of dynamic allocations. Currently, the only thing that does prevent this optimization is the fact that passing p to realloc makes p escape and the memory pointed to clobbered. But the alias analysis code already has special case code that would prevent this from happening (just maybe not in all places right now) - whether this is a good idea or not is another question. We could use zdenek's builtin function table to mention which arguments are not just written to, but *destroyed* for alias purposes, and then just directly get that info into aliasing. Boom, problem solved.
