Error in ira-color.c while bootstrap trunk

2011-03-30 Thread Revital Eres
Hello,

I get the following error while bootstrap trunk -r171713 on arm-linux-gnueabi

configured with:

../gcc/configure --prefix=/home/eres/mainline/
build_armv7 --enable-checking --enable-languages=c --enable-bootstrap
--with-arch=armv7-a --with-mode=thumb

Thanks,
Revital

/home/eres/mainline/build_armv7/./prev-gcc/xgcc
-B/home/eres/mainline/build_armv7/./prev-gcc/
-B/home/eres/mainline/build_armv7/armv7l-unknown-linux-gnueabi/bin/
-B/home/eres/mainline/build_armv7/armv7l-unknown-linux-gnueabi/bin/
-B/home/eres/mainline/build_armv7/armv7l-unknown-linux-gnueabi/lib/
-isystem /home/eres/mainline/build_armv7/armv7l-unknown-linux-gnueabi/include
-isystem 
/home/eres/mainline/build_armv7/armv7l-unknown-linux-gnueabi/sys-include
   -c   -O2  -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Werror -Wold-style-definition -Wc++-compat -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber    ../../gcc/gcc/ira-color.c -o ira-color.o
../../gcc/gcc/ira-color.c: In function 'assign_hard_reg':
../../gcc/gcc/ira-color.c:1546:21: error: variable 'mode' set but not
used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

make[3]: *** [ira-color.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod
make[3]: Leaving directory `/home/eres/mainline/build_armv7/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/eres/mainline/build_armv7'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/eres/mainline/build_armv7'
make: *** [bootstrap] Error 2


A question about handling debug_insn in schedulers

2011-04-11 Thread Revital Eres
Hello,

I wonder how the instruction scheduler deals with debug_insn?
Looking at how SMS handles notes I wonder if this mechanism is adopted to
handle debug_insn in other schedulers:  notes are ignored during the
scheduling procedure
and are carefully placed before the instruction that follow them in the
original order of the loop after the scheduling is done.

Thanks,
Revital


Trunk bootstrup failure with SMS flags

2011-06-06 Thread Revital Eres
Hello,

Recent trunk (-r174631) is broken when bootstrap it with SMS flags on
ARM (configured with --with-arch=armv7-a).
The last version of trunk that I'm aware of that passes bootsrap with
SMS flags is 173786.

Unfortunately I still can not put my finger on the cause for this fail
and I begin to suspect perhaps it is
not directly related to SMS; this is why I'm posting this email-- I
appreciate any suggestion to continue with the investigation.

The following is the fail I get in libgcc:

/home/40014/mainline/build/./gcc/xgcc
-B/home/40014/mainline/build/./gcc/
-B/home/40014/mainline/build/armv7l-unknown-linux-gnueabi/bin/
-B/home/40014/mainline/build/armv7l-unknown-linux-gnueabi/lib/
-isystem /home/40014/mainline/build/armv7l-unknown-linux-gnueabi/include
-isystem /home/40014/mainline/build/armv7l-unknown-linux-gnueabi/sys-include
   -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include  -fPIC -Wno-missing-prototypes -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-fno-stack-protector   -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include  -DHAVE_CC_TLS  -o _popcountdi2.o -MT
_popcountdi2.o -MD -MP -MF _popcountdi2.dep -DL_popcountdi2 -c
../../../gcc/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/../gcc/libgcc2.c: In function '__popcountsi2':
../../../gcc/libgcc/../gcc/libgcc2.c:791:1: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_popcountsi2.o] Error 1
make[3]: *** Waiting for unfinished jobs

Running the command line with debbuger I see the following:

Program received signal SIGSEGV, Segmentation fault.
0x00374b5c in check_dependency (bb=0x407ed090, use=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/loop-invariant.c:792
792   inv = invariant_table[DF_REF_ID(def)];
(gdb) where
#0  0x00374b5c in check_dependency (bb=0x407ed090, use=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/loop-invariant.c:792
#1  check_dependency (bb=0x407ed090, use=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/loop-invariant.c:772
#2  0x00376814 in check_dependencies () at ../../gcc/gcc/loop-invariant.c:824
#3  find_invariant_insn () at ../../gcc/gcc/loop-invariant.c:876
#4  find_invariants_insn () at ../../gcc/gcc/loop-invariant.c:929
#5  find_invariants_bb () at ../../gcc/gcc/loop-invariant.c:948
#6  find_invariants_body () at ../../gcc/gcc/loop-invariant.c:970
#7  find_invariants () at ../../gcc/gcc/loop-invariant.c:991
#8  move_single_loop_invariants () at ../../gcc/gcc/loop-invariant.c:1583
#9  move_loop_invariants () at ../../gcc/gcc/loop-invariant.c:1936
#10 0x00373d90 in rtl_move_loop_invariants () at ../../gcc/gcc/loop-init.c:248
#11 0x003ce254 in execute_one_pass (pass=0xb13208) at
../../gcc/gcc/passes.c:1863
#12 0x003ce574 in execute_pass_list (pass=0xb13208) at
../../gcc/gcc/passes.c:1917
#13 0x003ce58c in execute_pass_list (pass=0xb132a4) at
../../gcc/gcc/passes.c:1918
#14 0x003ce58c in execute_pass_list (pass=0xb1345c) at
../../gcc/gcc/passes.c:1918
#15 0x004e1c2c in tree_rest_of_compilation (fndecl=0x40814f00) at
../../gcc/gcc/tree-optimize.c:417
#16 0x001b8c70 in cgraph_expand_function (node=0x4080abb0) at
../../gcc/gcc/cgraphunit.c:1630
#17 0x001ba97c in cgraph_expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1689
#18 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1952
#19 0x001bb008 in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1126
#20 0x000b4c84 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9844
#21 0x00474504 in compile_file (argc=1076070708, argv=0x0) at
../../gcc/gcc/toplev.c:586
#22 do_compile (argc=1076070708, argv=0x0) at ../../gcc/gcc/toplev.c:1923
#23 toplev_main (argc=1076070708, argv=0x0) at ../../gcc/gcc/toplev.c:1995
#24 0x4024a622 in __libc_start_main (main=0x99068 , argc=73,
ubp_av=0xbe9d52b4, init=,
fini=0x9362a9 <__libc_csu_fini+1>, rtld_fini=0x40081985,
stack_end=0xbe9d52b4) at libc-start.c:226
#25 0x00099092 in _start ()

Thanks,
Revital


Bootstrap failure on PowerPC

2011-06-09 Thread Revital Eres
Hello,

I get the following bootstrap failure on ppc64-redhat-linux with trunk -r174840
compiling with -O2 flag..

Thanks,
Revital


/bin/sh ../../libtool --tag=CC   --mode=compile
/home/eres/mainline/build/./gcc/xgcc
-B/home/eres/mainline/build/./gcc/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/bin/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/lib/
-isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/include
-isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/sys-include
 -m32 -fPIC -mstrict-align -DHAVE_CONFIG_H -I.
-I../../../../../../../gcc/libjava/classpath/native/fdlibm
-I../../include-fexceptions -fasynchronous-unwind-tables -g -O2
-m32 -fPIC -mstrict-align -MT w_exp.lo -MD -MP -MF .deps/w_exp.Tpo -c
-o w_exp.lo ../../../../../../../gcc/libjava/classpath/native/fdlibm/w_exp.c
../../../../../../../gcc/libjava/classpath/native/fdlibm/strtod.c: In
function ג_Jv_strtod_rג:
../../../../../../../gcc/libjava/classpath/native/fdlibm/strtod.c:106:1:
internal compiler error: in op_iter_init, at tree-flow-inline.h:745
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [strtod.lo] Error 1
make[7]: *** Waiting for unfinished jobs
mv -f .deps/s_tanh.Tpo .deps/s_tanh.Plo


Re: Bootstrap failure on PowerPC

2011-06-09 Thread Revital Eres
Hello,

>
> Can you provide a backtrace and open a bugreport?

Sure, will do that. (I deleted the bootstrap dir so I can not provide
that info immediately though)

Thanks,
Revital


Bootstrap failure with doloop optimization on ARM

2011-07-18 Thread Revital Eres
Hello,

Trunk currently fails to bootstrap with SMS flags on ARM machine. (I'm
using -r175900. btw, -r175091 bootstrap OK)
Investigating the problem; it seems that the cause is not related to
SMS but rather to the doloop optimization which is enabled only when
SMS flags are set. (but that also does not mean that doloop is the
reason for the fail; it could be some later passes)
The first file that doloop is applied on and causes bootstrap failure
is bb-reorder.c.
The problematic loop seems to be the last FOR_EACH_EDGE in
connect_traces function which is inlined into reorder_basic_block,
I'm having extremely difficulty in locating what's exactly the problem
and even creating a reduced testcase and I would highly appreciate any
help/suggestions.

I should also probably open a PR for this.

This is the bootstrap error:

  -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/../gcc/libgcc2.c: In function '__addvsi3':
../../../gcc/libgcc/../gcc/libgcc2.c:85:1: internal compiler error:
vector VEC(edge,base) index domain error, in ei_edge at
basic-block.h:672
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_addvsi3.o] Error 1
make[3]: *** Waiting for unfinished jobs
../../../gcc/libgcc/../gcc/libgcc2.c: In function '__addvdi3':
../../../gcc/libgcc/../gcc/libgcc2.c:110:1: internal compiler error:
vector VEC(edge,base) index domain error, in ei_edge at
basic-block.h:672
Please submit a full bug report,

Thanks,
Revital


A question about sched_analyze_insn in sched-deps.c

2011-08-10 Thread Revital Eres
Hello,

I appriciate explanation regarding the following piece of code in
sched_analyze_insn function (sched-deps.c): When handling jump instruction
dependence edges are created between the jump instruction and memory
writes and volatile reads and I'm not quite sure the reason why.

Thanks,
Revital


Re: A question about sched_analyze_insn in sched-deps.c

2011-08-10 Thread Revital Eres
Hello,

>> I appriciate explanation regarding the following piece of code in
>> sched_analyze_insn function (sched-deps.c): When handling jump instruction
>> dependence edges are created between the jump instruction and memory
>> writes and volatile reads and I'm not quite sure the reason why.
>
> Jump instructions can be conditional.  Note the check for whether the
> next instruction is a barrier.

Thanks for the answer. I'm asking that in the context of SMS --- I'm
not sure if this dependence is needed when SMS is applied. AFAIK SMS
will not do speculative memory access.  If that's indeed the case I'll
submit the following patch.

Thanks,
Revital

Index: sched-deps.c
===
--- sched-deps.c(revision 177556)
+++ sched-deps.c(working copy)
@@ -2777,32 +2777,36 @@ sched_analyze_insn (struct deps_desc *de
 }

  /* All memory writes and volatile reads must happen before the
-jump.  Non-volatile reads must happen before the jump iff
-the result is needed by the above register used mask.  */
+jump unless the analysis is done for the SMS pass.
+Non-volatile reads must happen before the jump iff the
+result is needed by the above register used mask.  */

- pending = deps->pending_write_insns;
- pending_mem = deps->pending_write_mems;
- while (pending)
+ if (common_sched_info->sched_pass_id != SCHED_SMS_PASS)
{
- if (! sched_insns_conditions_mutex_p (insn, XEXP (pending, 0)))
-   add_dependence (insn, XEXP (pending, 0), REG_DEP_OUTPUT);
- pending = XEXP (pending, 1);
- pending_mem = XEXP (pending_mem, 1);
-   }
-
- pending = deps->pending_read_insns;
- pending_mem = deps->pending_read_mems;
- while (pending)
-   {
- if (MEM_VOLATILE_P (XEXP (pending_mem, 0))
- && ! sched_insns_conditions_mutex_p (insn, XEXP (pending, 0)))
-   add_dependence (insn, XEXP (pending, 0), REG_DEP_OUTPUT);
- pending = XEXP (pending, 1);
- pending_mem = XEXP (pending_mem, 1);
+ pending = deps->pending_write_insns;
+ pending_mem = deps->pending_write_mems;
+ while (pending)
+   {
+ if (! sched_insns_conditions_mutex_p (insn, XEXP (pending, 
0)))
+   add_dependence (insn, XEXP (pending, 0), REG_DEP_OUTPUT);
+ pending = XEXP (pending, 1);
+ pending_mem = XEXP (pending_mem, 1);
+   }
+   
+ pending = deps->pending_read_insns;
+ pending_mem = deps->pending_read_mems;
+ while (pending)
+   {
+ if (MEM_VOLATILE_P (XEXP (pending_mem, 0))
+ && ! sched_insns_conditions_mutex_p (insn, XEXP (pending, 
0)))
+   add_dependence (insn, XEXP (pending, 0), REG_DEP_OUTPUT);
+ pending = XEXP (pending, 1);
+ pending_mem = XEXP (pending_mem, 1);
+   }
+   
+ add_dependence_list (insn, deps->last_pending_memory_flush, 1,
+  REG_DEP_ANTI);
}
-
- add_dependence_list (insn, deps->last_pending_memory_flush, 1,
-  REG_DEP_ANTI);
}
 }


A question abt finding all register uses in instruction

2011-10-24 Thread Revital Eres
Hello,

I am trying to extract the regsiter uses in instructions using note_uses
function. When encountering the following instruction I do not get r479
as a use; seemingly because of the following in note_use function:

   if (GET_CODE (dest) == ZERO_EXTRACT)
  {
(*fun) (&XEXP (dest, 1), data);
(*fun) (&XEXP (dest, 2), data);
  }

the instruction:

(insn 386 385 387 16 (set (zero_extract:SI (reg:SI 479)
(const_int 16 [0x10])
(const_int 16 [0x10]))
(const_int 4112 [0x1010])) 343 {*arm_movtas_ze}
 (nil))

I appreciate any advise of how to resolve this -- should I add

  (*fun) (&XEXP (dest, 0), data); ?

Thanks,
Revital


Question abt getting the number of available registers

2011-10-27 Thread Revital Eres
Hello,

I'm working on estimating register pressure in SMS and using
ira_available_class_regs for getting the number of available
registers.
However I encounter a case where ira_available_class_regs showed 64
available regs for a certain class while ira_class_hard_regs_num
showed 61 so I am not sure which one I should use. (I'm also not sure
if ira_class_hard_regs_num  can be used outside of ira-- if not, I
would need to do that calculation myself)

Thanks,
Revital