Re: Bootstrap comparison failures on i586

[Uros Bizjak]

Hello!

> > Have you tried running valgrind?
>
> Thanks for the tip.  Indeed something shows up:
>
> [...]
>
>   if (parts.base)
> {
>   if (REGNO_POINTER_ALIGN (REGNO (parts.base)) < 32)  <-- 820
>   return 0;
> }
>
> I think parts.base is OK so it's probably REGNO_POINTER_ALIGN
>
> function.h:#define REGNO_POINTER_ALIGN(REGNO)
> (rtl.emit.regno_pointer_align[REGNO])
>
> which makes some sense since it was touched very recently:
>
> 2008-03-31  Jan Hubicka  <[EMAIL PROTECTED]>

This patch also fails for gcc.target/i386/movq.c with -fpic[1]. It
doesn't fail before this patch was committed [2].

[1] http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00031.html
[2] http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg1.html

Uros.

Re: [OT]: Categories and proposals for awards at the GCC Summit

[Robert Dewar]

Diego Novillo wrote:

Tom Tromey and I were chatting on IRC about the possibility of having
a Just-For-Fun awards ceremony at the GCC Summit where we would honor
folks in the community that have done some kind of positive
contribution to GCC (obviously a slow day for both of us).

The recipients would receive some sort of commemorative trinket, a
diploma and a good natured embarrassing moment in front of the whole
community.  But first, we want to know whether (a) this is something
people would go for, and (b) what categories should we have?

The idea is to have a moment of silly fun at the summit


I think you over-emphasize the silliness aspect here. If these awards
are instigated, you cannot avoid them being coveted and taken seriously.
That's not necessarily a bad thing, might well be a very good thing, but
always remember that when you give awards to some, you disappoint
others, no matter how hard you try to make things light.

Re: Analyzing *-rtems* ACATS

[Laurent GUERBY]

On Fri, 2008-04-04 at 15:07 -0500, Joel Sherrill wrote:

> Beyond those, I am left with:
> 
> 
> All targets had the following three failures:
> 
> c64005c - "WRONG ITERATIVE TRACE LENGTH."
> c64005d - "WRONG ITERATIVE TRACE LENGTH."
> c953002 - "WRONG ITERATIVE TRACE LENGTH."

These are tests with recursion and local strings, could you
try to run them with more stack for the main thread? (Or in some way
look at their stack usage). I've never seen them fail on a native
platform so this is a wild guess.

Laurent

RFC Test suite fix testing of no_trampolines

[Andy H]

There are several test in testsuite that use trampolines that are still 
run with dejagnu switch set to  no_trampolines.


Its on my TODO list for AVR target but a recent email reminded me that 
it  affects testing of other targets than can't or won't support 
trampolines.


Theres an  old patch by Björn Haase that was approved but not committed 
in 2005 that addressed many of these


http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01919.html

Essentially excluding them with  dg-require-effective-target

I am going to create an updated version of this. I realize that some of 
the target-supports changes are no longer needed.


Any comments?

Re: RFC Test suite fix testing of no_trampolines

[Paolo Bonzini]

Andy H wrote:
There are several test in testsuite that use trampolines that are still 
run with dejagnu switch set to  no_trampolines.


Its on my TODO list for AVR target but a recent email reminded me that 
it  affects testing of other targets than can't or won't support 
trampolines.


Theres an  old patch by Björn Haase that was approved but not committed 
in 2005 that addressed many of these


http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01919.html


The patch was even approved...

Paolo

Re: gcc-3.4.1 vs gcc-4.2.2 performance regression in memory initialization loop

[Richard Guenther]

On Sat, Apr 5, 2008 at 12:24 AM, Tan, Jeffri <[EMAIL PROTECTED]> wrote:
>
>  Apologies if this has been discussed before. I built the ARM compiler
>  for gcc-3.4.1 and gcc-4.2.2, and there seems to be a performance
>  regression. A tight loop in gcc-3.4.1 generates better code than
>  gcc-4.2.2.
>
>  In gcc-4.2.2, the store to the memory location of variable 'p' happens
>  in the loop. However, in gcc-3.4.1, 'p' is kept in a register until
>  after the loop when the the register is stored into the memory location
>  of 'p'.
>
>  Is gcc-4.2.2 being more conservative, in the possibility that p might
>  point to itself in the loop?

Yes, it appearantly thinks that the store to *p can clobber p.  This is
fixed with gcc 4.3.

Richard.

>  The command I used to build was:
>  cc1 -O2 test.c
>
>  --
>  test.c source:
>
>  int *p;
>  int array[400];
>
>  main() {
>   int i;
>   p=array;
>
>   for (i=0; i<400; i++) {
> *p++=0;
>   }
>  }
>
>  --
>  Gcc-4.2.2 version
> ldr r3, .L8
> mov r2, #0
> str r2, [r3], #4
> ldr r0, .L8+4
> str r3, [r0, #0]
> @ lr needed for prologue
> mov r1, #1
>  .L2:
> ldr r2, [r0, #0]
> mov r3, #0
> str r3, [r2], #4
> add r1, r1, #1
> cmp r1, #400
> str r2, [r0, #0]< store to 'p' inside loop
> bne .L2
> bx  lr
>  .L9:
> .align  2
>  .L8:
> .word   array
> .word   p
>
>  --
>  Gcc-3.4.1 version
> ldr r3, .L10
> ldr ip, .L10+4
> str r3, [ip, #0]
> @ lr needed for prologue
> mov r0, #0
> mov r1, #400
>  .L5:
> str r0, [r3], #4
> subsr1, r1, #1
> mov r2, r3
> bne .L5
> str r2, [ip, #0]< store to 'p' outside of loop
> mov pc, lr
>  .L11:
> .align  2
>  .L10:
> .word   array
> .word   p
>
>
>  Thanks for any input you can provide.
>
>  Jeffri Tan
>

Re: m32c build fails

[Richard Guenther]

On Sat, Apr 5, 2008 at 4:13 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>  I narrowed it down to commit 133403 (although whether that caused the
>  bug or merely expose it, I don't know):

I'm sure it just exposed it.

Richard.

>  2008-03-21  Richard Guenther  <[EMAIL PROTECTED]>
>
> * tree-scalar-evolution.c (chrec_contains_symbols_defined_in_loop):
> Use is_gimple_min_invariant instead of TREE_INVARIANT.
> * tree-ssa-loop-ivopts.c (force_expr_to_var_cost): Likewise.
> * tree-ssa-dom.c (record_equality): Likewise.
> * tree-inline.c (copy_body_r): Likewise.
> * tree-ssa-pre.c (make_values_for_stmt): Remove test for
> TREE_INVARIANT.
>
>  The test case is 132k but it's cplus-dem.c in libiberty for -mcpu=m32cm :
>
>  [EMAIL PROTECTED] pts/2 ~/m32c/gcc/m32c-elf/gcc
>  $ ./cc1 -fpreprocessed /tmp/cplus-dem.i -quiet -dumpbase cplus-dem.c 
> -mcpu=m32cm -auxbase-strip cplus-dem.o -g -O2 -W -Wall -Wwrite-strings 
> -Wc++-compat -Wstrict-prototypes -pedantic -o cplus-dem.s
>
> ../../../../gcc/libiberty/cplus-dem.c: In function 
> 'cplus_demangle_name_to_style':
>  ../../../../gcc/libiberty/cplus-dem.c:807: internal compiler error: in 
> build2_stat, at tree.c:3107
>  Please submit a full bug report,
>  with preprocessed source if appropriate.
>  See  for instructions.
>
>
>  [ gdb ] where
>  #0  fancy_abort (file=0x8c36cec "../../gcc/gcc/tree.c", line=3107, 
> function=0x8c3795f "build2_stat")
> at ../../gcc/gcc/diagnostic.c:684
>  #1  0x088a5a5b in build2_stat (code=PLUS_EXPR, tt=0xb7d9bdd0, 
> arg0=0xb7bd61e0, arg1=0xb7a635e4)
>
> at ../../gcc/gcc/tree.c:3107
>  #2  0x08392fef in fold_build2_stat (code=PLUS_EXPR, type=0xb7d9bdd0, 
> op0=0xb7bd61e0, op1=0xb7a635e4)
> at ../../gcc/gcc/fold-const.c:13372
>  #3  0x0835561c in fold_binary (code=PLUS_EXPR, type=0xb7d9bdd0, 
> op0=0xb7a635e4, op1=0xb7bd61e0)
> at ../../gcc/gcc/fold-const.c:9196
>  #4  0x08392fc6 in fold_build2_stat (code=PLUS_EXPR, type=0xb7d9bdd0, 
> op0=0xb7a635e4, op1=0xb7bd61e0)
> at ../../gcc/gcc/fold-const.c:13370
>  #5  0x0871baa3 in create_mem_ref (bsi=0xbf8b52ec, type=0xb7f7e888, 
> addr=0xbf8b52f8)
>
> at ../../gcc/gcc/tree-ssa-address.c:641
>  #6  0x08795e51 in rewrite_use_address (data=0xbf8b5428, use=0xac991f0, 
> cand=0xace3e08)
>
> at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5227
>  #7  0x08796155 in rewrite_use (data=0xbf8b5428, use=0xac991f0, 
> cand=0xace3e08)
> at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5286
>  #8  0x08796206 in rewrite_uses (data=0xbf8b5428) at 
> ../../gcc/gcc/tree-ssa-loop-ivopts.c:5315
>  #9  0x08796b7f in tree_ssa_iv_optimize_loop (data=0xbf8b5428, 
> loop=0xb7880b00)
>
> at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5485
>  #10 0x08796c18 in tree_ssa_iv_optimize () at 
> ../../gcc/gcc/tree-ssa-loop-ivopts.c:5518
>  #11 0x087aab13 in tree_ssa_loop_ivopts () at 
> ../../gcc/gcc/tree-ssa-loop.c:580
>  #12 0x084abb81 in execute_one_pass (pass=0x8c80340) at 
> ../../gcc/gcc/passes.c:1127
>  #13 0x084abccb in execute_pass_list (pass=0x8c80340) at 
> ../../gcc/gcc/passes.c:1180
>  #14 0x084abce7 in execute_pass_list (pass=0x8c7ff80) at 
> ../../gcc/gcc/passes.c:1181
>  #15 0x084abce7 in execute_pass_list (pass=0x8c7f7c0) at 
> ../../gcc/gcc/passes.c:1181
>  #16 0x086bbe59 in tree_rest_of_compilation (fndecl=0xb7f7c700) at 
> ../../gcc/gcc/tree-optimize.c:420
>  #17 0x08920435 in cgraph_expand_function (node=0xb7ea2900) at 
> ../../gcc/gcc/cgraphunit.c:1157
>  #18 0x089205c6 in cgraph_expand_all_functions () at 
> ../../gcc/gcc/cgraphunit.c:1220
>  #19 0x08920bd7 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1427
>  #20 0x08076db3 in c_write_global_declarations () at 
> ../../gcc/gcc/c-decl.c:8063
>  #21 0x086238c3 in compile_file () at ../../gcc/gcc/toplev.c:968
>  #22 0x08625402 in do_compile () at ../../gcc/gcc/toplev.c:2158
>  #23 0x08625464 in toplev_main (argc=19, argv=0xbf8b5794) at 
> ../../gcc/gcc/toplev.c:2190
>  #24 0x081250d2 in main (argc=Cannot access memory at address 0x20
>
>
> ) at ../../gcc/gcc/main.c:35
>
>

Re: Bootstrap comparison failures on i586

[Jan Hubicka]

> 
> This patch also fails for gcc.target/i386/movq.c with -fpic[1]. It
> doesn't fail before this patch was committed [2].
> 
> [1] http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00031.html
> [2] http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg1.html

This did not reproduce for me, but I've comitted the following as
obvious. I am sorry for all the fallout...

Index: ChangeLog
===
*** ChangeLog   (revision 133932)
--- ChangeLog   (working copy)
***
*** 1,5 
--- 1,7 
  2008-04-05  Jan Hubicka  <[EMAIL PROTECTED]>
  
+   * emit-rtl.c (init_emit): xcalloc regno_pointer_align.
+ 
* tree-dump.c (dump_enable_all): Remove prototype; do not accept
letter argument.
(dump_files): Update.
Index: emit-rtl.c
===
*** emit-rtl.c  (revision 133929)
--- emit-rtl.c  (working copy)
*** init_emit (void)
*** 4991,4998 
rtl.emit.regno_pointer_align_length = LAST_VIRTUAL_REGISTER + 101;
  
rtl.emit.regno_pointer_align
! = xmalloc (rtl.emit.regno_pointer_align_length
!  * sizeof (unsigned char));
  
regno_reg_rtx
  = ggc_alloc (rtl.emit.regno_pointer_align_length * sizeof (rtx));
--- 4991,4998 
rtl.emit.regno_pointer_align_length = LAST_VIRTUAL_REGISTER + 101;
  
rtl.emit.regno_pointer_align
! = xcalloc (rtl.emit.regno_pointer_align_length
!  * sizeof (unsigned char), 1);
  
regno_reg_rtx
  = ggc_alloc (rtl.emit.regno_pointer_align_length * sizeof (rtx));

Re: m32c build fails

[DJ Delorie]

> I'm sure it just exposed it.

If so, any clues about what the underlying bug might be?

Re: m32c build fails

[Richard Guenther]

On Sat, Apr 5, 2008 at 5:01 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>  > I'm sure it just exposed it.
>
>  If so, any clues about what the underlying bug might be?

It is probably simply a missing conversion or a latent bug in fold
that is exposed.  Is this
problem reproducible with a cross-compiler?  Can you open a bug-report
and attach
pre-processed source in that case?

Thanks,
Richard.

Re: m32c build fails

[DJ Delorie]

> Is this problem reproducible with a cross-compiler?

Yes, it's m32c-elf

> Can you open a bug-report and attach pre-processed source in that
> case?

It's trying to cross-build libiberty, so just building shows the bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834

Re: m32c build fails

[Richard Guenther]

On Sat, 5 Apr 2008, DJ Delorie wrote:

> 
> > Is this problem reproducible with a cross-compiler?
> 
> Yes, it's m32c-elf
> 
> > Can you open a bug-report and attach pre-processed source in that
> > case?
> 
> It's trying to cross-build libiberty, so just building shows the bug.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834

I will apply the following if you confirm this fixes m32c-elf.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Richard.

2008-04-05  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/35834
* tree-ssa-address.c (create_mem_ref): Use POINTER_PLUS_EXPR
for adding index to base.

Index: tree-ssa-address.c
===
--- tree-ssa-address.c  (revision 133937)
+++ tree-ssa-address.c  (working copy)
@@ -639,9 +639,9 @@ create_mem_ref (block_stmt_iterator *bsi
{
  atype = TREE_TYPE (parts.base);
  parts.base = force_gimple_operand_bsi (bsi,
-   fold_build2 (PLUS_EXPR, atype,
+   fold_build2 (POINTER_PLUS_EXPR, atype,
 parts.base,
-fold_convert (atype, parts.index)),
+parts.index),
true, NULL_TREE, true, BSI_SAME_STMT);
}
   else

Re: Analyzing *-rtems* ACATS

[Joel Sherrill]

Laurent GUERBY wrote:

On Fri, 2008-04-04 at 15:07 -0500, Joel Sherrill wrote:

  

Beyond those, I am left with:


All targets had the following three failures:

c64005c - "WRONG ITERATIVE TRACE LENGTH."
c64005d - "WRONG ITERATIVE TRACE LENGTH."
c953002 - "WRONG ITERATIVE TRACE LENGTH."



These are tests with recursion and local strings, could you
try to run them with more stack for the main thread? (Or in some way
look at their stack usage). I've never seen them fail on a native
platform so this is a wild guess.

  

Will do.  But the main thread has a 100K stack and these
didn't fail with 4.2.3 and the same settings.

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01028.html

I am not on the machine with the compiler so will have to
test this Monday.

Laurent

  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985