Re: A reload inheritance bug

[Mark Shinwell]

Bernd Schmidt wrote:

Mark Shinwell wrote:


and the code following in emit_reload_insns?  Perhaps if spill_reg_index
took account of registers selected during find_reloads then this could
be simplified too.

So what do you think is the best approach to fix all of this? :-)


Sounds like you gave the answer yourself in the first paragraph.  At
least that's what I'd try.


I've been experimenting with the following (which fixes the original ARM
problem and doesn't appear to regress on i686-pc-linux-gnu).  However I'm
still not very happy with this, since I'm thinking it might be too
specific to this particular situation.

Do you think it should be the case that, at the point below, _any_ reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?

Mark

--


Index: src/gcc-mainline/gcc/reload1.c
===
--- src/gcc-mainline/gcc/reload1.c  (revision 125602)
+++ src/gcc-mainline/gcc/reload1.c  (working copy)
@@ -5657,6 +5657,22 @@ choose_reload_regs (struct insn_chain *c
  && ! rld[r].secondary_p)
continue;

+ /* If find_reloads chose a hard register for an input reload register
+(which can happen for example at an input reload if the hard
+register corresponds to an input operand that dies in the
+instruction), ensure that we record this allocation.  */
+ if (rld[r].when_needed == RELOAD_FOR_INPUT
+ && rld[r].reg_rtx
+ && REGNO (rld[r].reg_rtx) < FIRST_PSEUDO_REGISTER)
+   {
+ reload_spill_index[r] = REGNO (rld[r].reg_rtx);
+ mark_reload_reg_in_use (j,
+ rld[r].opnum,
+ rld[r].when_needed,
+ rld[r].mode);
+ continue;
+  };
+
  /* If find_reloads chose to use reload_in or reload_out as a reload
 register, we don't need to chose one.  Otherwise, try even if it
 found one since we might save an insn if we find the value lying

Re: FW: [gnu.org #336636] Needed Java Compilers for SUSE Linux Enterprise Server 10

[Richard Guenther]

On 6/11/07, Krupa Stephen Gadde <[EMAIL PROTECTED]> wrote:

Hi,

Can I get any help on this???


This is not the right place to ask either.  Please ask your OS vendor
(SUSE/Novell)
on how to get Java compilers.

Richard.

mf-runtime.c IC error..

[Seema S. Ravandale]

Hi...
I have inserted some code for available analysis in the source code of
GCC4.0.2
But "make" fails at the file mf-runtime.c
the error i got is as follow:

/home/divya/GCC-4.0.2/build/gcc/xgcc -B/home/divya/GCC-4.0.2/build/gcc/
-B/home/divya/GCC-4.0.2/target/i686-pc-linux-gnu/bin/
-B/home/divya/GCC-4.0.2/target/i686-pc-linux-gnu/lib/ -isystem
/home/divya/GCC-4.0.2/target/i686-pc-linux-gnu/include -isystem
/home/divya/GCC-4.0.2/target/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H
-I. -I../../../src/gcc-4.0.2/libmudflap -I. -Wall -ffunction-sections
-fdata-sections -O2 -g -O2 -MT mf-runtime.lo -MD -MP -MF
.deps/mf-runtime.Tpo -c ../../../src/gcc-4.0.2/libmudflap/mf-runtime.c 
-fPIC -DPIC -o .libs/mf-runtime.o
../../../src/gcc-4.0.2/libmudflap/mf-runtime.c: In function
'__mf_sigusr1_respond':
../../../src/gcc-4.0.2/libmudflap/mf-runtime.c:2192: internal compiler
error: Segmentation fault


i tried to debug this code with gdb as follow:

# gdb /home/divya/GCC-4.0.2/build/gcc/xgcc
# set args -B/home/divya/GCC-4.0.2/target/i686-pc-linux-gnu/bin/
-B/home/divya/GCC-4.0.2/target/i686-pc-linux-gnu/lib/ -isystem
/home/divya/GCC-4.0.2/target/i686-pc-linux-gnu/include -isystem
/home/divya/GCC-4.0.2/target/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H
-I. -I../../../src/gcc-4.0.2/libmudflap -I. -Wall -ffunction-sections
-fdata-sections -O2 -g -O2 -MT mf-runtime.lo -MD -MP -MF
.deps/mf-runtime.Tpo -c ../../../src/gcc-4.0.2/libmudflap/mf-runtime.c 
-fPIC -DPIC -o .libs/mf-runtime.o
#run

Then segmentation fault message flashed by gdb was as follow:

Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x833000
Detaching after fork from child process 26021.
../../../src/gcc-4.0.2/libmudflap/mf-runtime.c: In function
‘__mf_sigusr1_respond’:
../../../src/gcc-4.0.2/libmudflap/mf-runtime.c:2192: internal compiler
error: Segmentation fault

What could be the possible reasons for such error??



-- 
Seema S. Ravandale,
Research Fellow,
Centre for Formal Design and Verification of Softwares,
Indian Institute of Technology, Bombay.

Re: A reload inheritance bug

[Rask Ingemann Lambertsen]

On Mon, Jun 11, 2007 at 09:22:24AM +0100, Mark Shinwell wrote:

> + if (rld[r].when_needed == RELOAD_FOR_INPUT
> + && rld[r].reg_rtx
> + && REGNO (rld[r].reg_rtx) < FIRST_PSEUDO_REGISTER)
> +   {

$ grep -F -e HARD_REGISTER gcc/rtl.h
#define HARD_REGISTER_P(REG) (HARD_REGISTER_NUM_P (REGNO (REG)))
#define HARD_REGISTER_NUM_P(REG_NO) ((REG_NO) < FIRST_PSEUDO_REGISTER)

-- 
Rask Ingemann Lambertsen

Re: FW: [gnu.org #336636] Needed Java Compilers for SUSE Linux Enterprise Server 10

[Krupa Stephen Gadde]

Hi Richard,

Thanks for the info. I'll ask my OS vendor.

Thanks and Regards
Stephen K. Gadde

 Original message 
>Date: Mon, 11 Jun 2007 10:56:51 +0200
>From: "Richard Guenther" <[EMAIL PROTECTED]>  
>Subject: Re: FW: [gnu.org #336636] Needed Java Compilers for SUSE Linux 
>Enterprise Server 10  
>To: "Krupa Stephen Gadde" <[EMAIL PROTECTED]>
>Cc: gcc@gcc.gnu.org
>
>On 6/11/07, Krupa Stephen Gadde <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Can I get any help on this???
>
>This is not the right place to ask either.  Please ask your OS vendor
>(SUSE/Novell)
>on how to get Java compilers.
>
>Richard.

Re: mf-runtime.c IC error..

[Seema S. Ravandale]

Hi.
Thanks for the help. The problem is solved anyways.
After few trials, i came to know that few memory locations were getting
overwritten by mallacious data and thats bcoz of ggc_realloc. In my prog
ggc_realloc was getting called many times. When i increased the size for
the very first allocation so that there will be fewer calls to
ggc_realloc, "Make" went through.

Is there any known/similar problem related to ggc_realloc() ?? Is it to do
with book-keeping information getting merged with allocated memory or it
is taken care by gcc-garbage collector??
Thank you.
- Seema

> hi seema,
>   Did you try checking the backtrace when you get the segfault.
> Except for a corrupted value of __mf_opts, there is not much there that
> can cause a segfault. Try putting a bpt on fancy_abort and backtrace
> when it is hit.
>
> HTH
> saurabh
>
> On Mon, 2007-06-11 at 14:34 +0530, Seema S. Ravandale wrote:
>> Hi...
>> I have inserted some code for available analysis in the source code of
>> GCC4.0.2
>> But "make" fails at the file mf-runtime.c
>> the error i got is as follow:
>>
>
>

Re: Miscompilations for cris-elf on dataflow-branch

[Kenneth Zadeck]

Seongbae Park (박성배, 朴成培) wrote:
> This little patch:
>
> diff -r 9e2b1e62931a gcc/combine.c
> --- a/gcc/combine.c Wed Jun 06 23:08:38 2007 +
> +++ b/gcc/combine.c Mon Jun 11 05:39:25 2007 +
> @@ -4237,7 +4237,7 @@ subst (rtx x, rtx from, rtx to, int in_d
>
> So force this insn not to match in this (rare) case. */
> if (! in_dest && code == REG && REG_P (from)
> - && REGNO (x) == REGNO (from))
> + && reg_overlap_mentioned_p (x, from))
> return gen_rtx_CLOBBER (GET_MODE (x), const0_rtx);
>
> /* If this is an object, we are done unless it is a MEM or LO_SUM, both
>
> should fix the problem (thanks to Ian Lance Talyor and Andrew Pinski
> for helping me debug the problem on IRC).
> I've started the bootstrap/regtest on x86-64.
> I'd appreciate it if you can test this on cris.
> Although the change is approved by Ian already,
> I think I'll hold the patch till the dataflow merge happens.
> Thanks,
>
> Seongbae
>
> On 6/10/07, Seongbae Park (박성배, 朴成培) <[EMAIL PROTECTED]>
> wrote:
>> Thanks for the detailed instruction on how to reproduce it
>> - I have successfully reproduced the problem, and narrowed it down
>> to combine that's deleting the insn in question.
>> Hopefully I'll be able to figure out what's wrong soon.
>>
>> Seongbae
>>
>> On 6/10/07, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote:
>> > I hear dataflow-branch is near merge to trunk, so I thought it'd
>> > be about time to verify that it works for the targets I
>> > maintain...
>> >
>> > Comparing dataflow-branch with trunk, both r125590, I see these
>> > regressions (alas no improvements) on the branch for cris-elf
>> > cross from x86_64-unknown-linux-gnu (Debian etch, I think):
>> >
>> > gcc.sum gcc.c-torture/execute/20020201-1.c
>> > gcc.sum gcc.c-torture/execute/20041011-1.c
>> > gcc.sum gcc.c-torture/execute/920501-8.c
>> > gcc.sum gcc.c-torture/execute/920726-1.c
>> > gcc.sum gcc.c-torture/execute/ashldi-1.c
>> > gcc.sum gcc.c-torture/execute/ashrdi-1.c
>> > gcc.sum gcc.c-torture/execute/builtin-bitops-1.c
>> > gcc.sum gcc.c-torture/execute/builtins/pr23484-chk.c
>> > gcc.sum gcc.c-torture/execute/builtins/snprintf-chk.c
>> > gcc.sum gcc.c-torture/execute/builtins/sprintf-chk.c
>> >
>> > Though repeatable by anyone (see for example
>> > ), all
>> > are unfortunately execution failures, so I thought best to do
>> > some preliminary analysis.
>> >
>> > Looking at the source code for what the tests have in common, it
>> > seems all either use sprintf "%d" or a DImode shift operation
>> > (requiring a library call). My money is on all being the same
>> > one bug.
>> >
>> > Here's a cut-down test-case, derived from
>> > gcc.c-torture/execute/builtin-bitops-1.c:
>> >
>> > --
>> > static int
>> > my_popcountll (unsigned long long x)
>> > {
>> > int i;
>> > int count = 0;
>> > for (i = 0; i < 8 * sizeof (unsigned long long); i++)
>> > if (x & ((unsigned long long) 1 << i))
>> > count++;
>> > return count;
>> > };
>> >
>> > extern void abort (void);
>> > extern void exit (int);
>> >
>> > int
>> > main (void)
>> > {
>> > int i;
>> >
>> > if (64 != my_popcountll (0xULL))
>> > abort ();;
>> >
>> > exit (0);
>> > }
>> > --
>> >
>> > Here's the assembly diff to trunk, revisions as per above,
>> > option -Os as mentioned below:
>> >
>> > --- lshr1.s.trunk 2007-06-11 03:49:21.0 +0200
>> > +++ lshr1.s.df 2007-06-11 03:49:59.0 +0200
>> > @@ -15,7 +15,6 @@ _main:
>> > move.d ___lshrdi3,$r2
>> > moveq -1,$r10
>> > .L7:
>> > - move.d $r10,$r11
>> > move.d $r0,$r12
>> > Jsr $r2
>> > btstq (1-1),$r10
>> >
>> > To repeat this without building a complete toolchain, have a gcc
>> > svn checkout with those darned mpfr and gmp available somewhere
>> > (added in that checkout or installed on the host system), then
>> > do, in an empty directory:
>> > /path/to/gcctop/configure --target=cris-elf --enable-languages=c &&
>> make all-gcc
>> > This will give you a cc1, which you know how to handle. :)
>> >
>> > To repeat with the program above named lshr1.c, just use:
>> >
>> > ./cc1 -Os lshr1.c
>> >
>> > The lost insn, numbered 61 in both trees, loads the high part of
>> > that all-bits operand to the register in which that part of the
>> > parameter is passed to the DImode left-shift library function
>> > __lshrdi3. From the dump-file it seems the first pass it is
>> > lost, is combine.
>> >
>> > Let me know if I can be of help.
>> >
>> > brgds, H-P
>> >
>>
>>
>> -- 
>> #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
>>
>
>
thanks for looking at this. i had gone to bed..

kenny

Dataflow maintainers

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Ken Zadeck, Seongbae Park, Daniel Berlin, and Paolo Bonzini as
Dataflow maintainers.

Please join me in congratulating Ken, Seongbae, Dan, and Paolo on
their new role.  Please update your listings in the MAINTAINERS file.

Happy hacking!
David

Another reload inheritance bug

[Rask Ingemann Lambertsen]

   I've run into a case where reload clobbers a register which it had
decided to use for reload inheritance. Reload is given this:

(insn 623 430 431 35 ../../.././gcc/dp-bit.c:734 (set (reg:HI 162 [+6 ])
(mem/c/i:HI (plus:HI (reg/f:HI 10 bp)
(const_int -2 [0xfffe])) [0 S2 A16])) 9 {*movhi} (nil)
(expr_list:REG_EQUIV (mem/c/i:HI (plus:HI (reg/f:HI 10 bp)
(const_int -2 [0xfffe])) [0 S2 A16])
(nil)))

(insn 431 623 432 35 ../../.././gcc/dp-bit.c:734 (set (mem/s/j:HI (plus:HI 
(reg/v/f:HI 37 [ tmp ])
(const_int 10 [0xa])) [0 .fraction.ll+6 S2 A16])
(reg:HI 162 [+6 ])) 9 {*movhi} (insn_list:REG_DEP_TRUE 421 (nil))
(expr_list:REG_DEAD (reg:HI 162 [+6 ])
(nil)))

(note 432 431 433 35)

(note 433 432 434 35)

(insn 434 433 435 35 ../../.././gcc/dp-bit.c:735 (parallel [
(set (mem/s/j:HI (plus:HI (reg/v/f:HI 37 [ tmp ])
(const_int 2 [0x2])) [0 .normal_exp+0 S2 A16])
(plus:HI (mem/s/j:HI (plus:HI (reg/v/f:HI 37 [ tmp ])
(const_int 2 [0x2])) [0 .normal_exp+0 S2 
A16])
(const_int 1 [0x1])))
(clobber (reg:CC 13 cc))
]) 44 {*addhi3} (nil)
(expr_list:REG_UNUSED (reg:CC 13 cc)
(nil)))

   Reload faces two problems here:
1) Eliminating %bp to %sp where %sp can not be used as a base register.
2) Register 37 didn't get a hard reg, so it is on the stack.

   Reload handles insns 623 and 431 fine and correctly records that register
37 has been loaded into %bx (reg:HI 6 b) as a result. Unfortunately, reload
clobbers %bx in insn 897 before using %bx in insn 434.

movw%sp,%bx ;# 895  *movhi/1
movw74(%bx),%ax ;# 623  *movhi/1

movw94(%bx),%bx ;# 896  *movhi/1
movw%ax,10(%bx) ;# 431  *movhi/2

movw%sp,%bx ;# 897  *movhi/1
incw2(%bx)  ;# 434  *addhi3/1

   Everything looks fine early in choose_reload_regs():

(gdb) call debug_rtx (chain->insn)
(insn 434 433 435 35 ../../.././gcc/dp-bit.c:735 (parallel [
(set (mem/s/j:HI (plus:HI (reg/v/f:HI 37 [ tmp ])
(const_int 2 [0x2])) [0 .normal_exp+0 S2 A16])
(plus:HI (mem/s/j:HI (plus:HI (reg/v/f:HI 37 [ tmp ])
(const_int 2 [0x2])) [0 .normal_exp+0 S2 
A16])
(const_int 1 [0x1])))
(clobber (reg:CC 13 cc))
]) 44 {*addhi3} (nil)
(expr_list:REG_UNUSED (reg:CC 13 cc)
(nil)))

   The *addhi3 pattern is nothing unusual. We're using the first
alternative of adding one to a memory operand:

(define_insn "*addhi3"
  [(set (match_operand:HI 0 "nonimmediate_operand" "=rm,rm,qm,qm,r,m,!r,!r")
 (plus:HI (match_operand:HI 1 "nonimmediate_operand" "%0,0,0,0,0,0,*w,*B")
  (match_operand:HI 2 "general_operand" "P1,M1,Um,Uo,g,ri,*x,i")))
   (clobber (reg:CC CC_REG))]

(gdb) call debug_reload()
Reload order: 0 1 2 3 4
Reload 0: reload_in (HI) = (reg/f:HI 12 sp)
BASE_REGS, RELOAD_FOR_OPADDR_ADDR (opnum = 0)
reload_in_reg: (reg/f:HI 12 sp)
Reload 1: reload_in (HI) = (mem/f/c/i:HI (plus:HI (reg/f:HI 12 sp)
(const_int 94 [0x5e])) 
[0 tmp+0 S2 A16])
BASE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), can't combine
reload_in_reg: (reg/v/f:HI 37 [ tmp ])
Reload 2: BASE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (reg/f:HI 12 sp)
Reload 3: BASE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), can't combine
reload_in_reg: (reg/v/f:HI 37 [ tmp ])
Reload 4: reload_in (HI) = (mem/s/j:HI (plus:HI (reg/v/f:HI 37 [ tmp ])
(const_int 2 [0x2])) [0 
.normal_exp+0 S2 A16])
reload_out (HI) = (mem/s/j:HI (plus:HI (reg/v/f:HI 37 [ tmp ])
(const_int 2 [0x2])) [0 
.normal_exp+0 S2 A16])
GENERAL_REGS, RELOAD_OTHER (opnum = 0), optional
reload_in_reg: (mem/s/j:HI (plus:HI (reg/v/f:HI 37 [ tmp ])
(const_int 2 [0x2])) [0 
.normal_exp+0 S2 A16])
reload_out_reg: (mem/s/j:HI (plus:HI (reg/v/f:HI 37 [ tmp ])
(const_int 2 [0x2])) [0 
.normal_exp+0 S2 A16])

reload 0:
(gdb) print regno
$61 = 12
(gdb) call debug_rtx(reg_last_reload_reg[regno])
(reg:HI 6 b)
(gdb) print /x reg_reloaded_valid
$67 = 0xc0
(gdb) print reg_reloaded_contents[6]
$64 = 37
(gdb) print reg_reloaded_contents[7]
$65 = 37
(gdb) print [EMAIL PROTECTED]
$70 = "\000\000\000\000"

   I.e. reload looks at register 6 for reload inheritance, but the contents
aren't right, so no reload inheritance for reload 0.

reload 1:
(gdb) print regno
$77 = 37
(gdb) print mode
$78 = HImode
(gdb) call debug_rtx(reg_last_reload_reg[regno])
(reg:HI 6 b)

(gdb) 

Re: A reload inheritance bug

[Bernd Schmidt]

Mark Shinwell wrote:
> Do you think it should be the case that, at the point below, _any_ reload
> with reg_rtx corresponding to a hard register should have the relevant
> bit set in reload_spill_index?

I think so.  I'm attaching a patch below.  It appears to have no effect
on all code I've tried - does it fix your test case?
> + if (rld[r].when_needed == RELOAD_FOR_INPUT
> + && rld[r].reg_rtx
> + && REGNO (rld[r].reg_rtx) < FIRST_PSEUDO_REGISTER)
> +   {
> + reload_spill_index[r] = REGNO (rld[r].reg_rtx);
> + mark_reload_reg_in_use (j,
> + rld[r].opnum,
> + rld[r].when_needed,
> + rld[r].mode);

I don't think we need mark_reload_reg_in_use, as there are other
mechanisms preventing conflicts.


Bernd

-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Index: reload1.c
===
--- reload1.c   (revision 124499)
+++ reload1.c   (working copy)
@@ -5556,7 +5556,14 @@ choose_reload_regs (struct insn_chain *c
   for (j = 0; j < n_reloads; j++)
 {
   reload_order[j] = j;
-  reload_spill_index[j] = -1;
+  if (rld[j].reg_rtx != NULL_RTX)
+   {
+ gcc_assert (REG_P (rld[j].reg_rtx)
+ && HARD_REGISTER_P (rld[j].reg_rtx));
+ reload_spill_index[j] = REGNO (rld[j].reg_rtx);
+   }
+  else
+   reload_spill_index[j] = -1;
 
   if (rld[j].nregs > 1)
{

Help understanding tree-affine.c

[Revital1 Eres]

Hello,

I am trying to understand the usage of some functions in tree-affine.c
file and I appreciate your help.

For example; for the two memory accesses
 arr[b+8].X  and  arr[b+9].X, how does their affine combinations
will look like after executing the following sequence of operation?
(taken from http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02605.html)

get_inner_reference_aff (mem1, &off1, &size1);
get_inner_reference_aff (mem2, &off2, &size2);
aff_combination_expand (&off1, ttae_cache);
aff_combination_expand (&off2, ttae_cache);
aff_combination_scale (&off1, double_int_minus_one);
aff_combination_add (&off2, &off1);

Also, why does diff->n is an indication for the fact that two memory
accesses can overlap in the following snippet taken from the above link?

static bool
cannot_overlap_p (aff_tree *diff, double_int size1, double_int size2)
{
  double_int d, bound;

  /* Unless the difference is a constant, we fail.  */
  if (diff->n != 0)
return false;

Thanks in advance,
Revital

Re: Help understanding tree-affine.c

[Zdenek Dvorak]

Hello,

> I am trying to understand the usage of some functions in tree-affine.c
> file and I appreciate your help.
> 
> For example; for the two memory accesses
>  arr[b+8].X  and  arr[b+9].X, how does their affine combinations
> will look like after executing the following sequence of operation?
> (taken from http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02605.html)
> 
> get_inner_reference_aff (mem1, &off1, &size1);
> get_inner_reference_aff (mem2, &off2, &size2);

off1 will be affine combination 1 * &arr + 8 * b + 64,
off2 will be 1 * &arr + 8 * b + 72 (assuming that size of the element of arr
is 8),

> aff_combination_expand (&off1, ttae_cache);
> aff_combination_expand (&off2, ttae_cache);

In these cases, off1 and off2 will be unchanged, since b is not defined
in terms of an affine expression.

> aff_combination_scale (&off1, double_int_minus_one);
> aff_combination_add (&off2, &off1);

This subtracts the two affine combinations, so off2 will be 8 in the
end.

> Also, why does diff->n is an indication for the fact that two memory
> accesses can overlap in the following snippet taken from the above link?

n is the number of terms of the affine combination, excluding the
constant offset.  For example, off1 above has n = 2, the terms of the affine
combination (&arr, b) and their coefficients (1, 8) are kept in the
elts array, the constant offset (64) is kept in the offset field.

So, if there is any non-constant term (i.e., n > 0), we cannot be sure
that the difference of the addresses is non-zero (actually, this could
be improved -- we could consider the value of the offset modulo the
greatest common divisor of the coefficients, and in some cases derive
that there cannot be an overlap).

Zdenek

> static bool
> cannot_overlap_p (aff_tree *diff, double_int size1, double_int size2)
> {
>   double_int d, bound;
> 
>   /* Unless the difference is a constant, we fail.  */
>   if (diff->n != 0)
> return false;
> 
> Thanks in advance,
> Revital

Re: [RFC] Aggregate mapping

[Daniel Jacobowitz]

On Sun, Jun 10, 2007 at 12:56:26PM -0400, Jim Tison wrote:
> option or standalone program. I'm proposing to create a standalone program, 
> as 
> I don't know enough about gcc internals to force such maps to be generated 
> during compilation ... I'm not certain this would be appropriate, anyway. 
> OTOH, 
> I can't be the first to propose solving this problem.

I'm pretty sure the Linux kernel people have a similar tool, that they
use to find padding holes in data structures.  Aha, here it is:

  http://lwn.net/Articles/206805/

> AFAICT, the only accurate source data for such an aggregate map would be 
> DWARF 
> DIE entries.

Congratulations - I've seen people come up with all sorts of ways to
do this, but you've found the correct one :-) Use the debug
information; it's standardized and we have high incentive to keep it
correct.

> I've done some reading of the DWARF-2 and DWARF-3 standards. What I see 
> emitted 
> as DWARF in gcc-4.1.x is marked as DWARF-2; but I'm told that gcc properly 
> emits DWARF-3. Should I even check the version? Will I need to vary 
> processing 
> features by gcc level?

The version number found in .debug_info is not necessarily the same as
the version number of the standard.  I believe the 2 vs 3 controls
whether one field is a byte or a uleb128, and another similar format
change.  I recommend you accept version 2 or version 3, and handle any
new attributes that you're concerned about whether they appeared in
DWARF-2 or DWARF-3.

> Since I'm targeting all three ELF object types, I'm thinking I have to start 
> reading the sections .debug_info and .debug_abbrev at the DWARF CU level, and 
> build a tree of CU-related data. I've actually started this bit of code and 
> am 
> somewhat happy with test results so far.

Or just use libdwarf?  Really - it already does this.  I've been
planning to write Python bindings for it, too, but never had the time.
The more of this you reinvent, the more places you might make a
mistake.

> Nor am I planning to use libelf: it's too straightforward to find the ELF 
> sections I need and to read the ELF header. Use of libelf seems too 
> top-heavy, 
> although elf.h is very valuable to me.

If you write more complicated tools, you will want libelf later -
you might need to get at relocation data.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Miscompilations for cris-elf on dataflow-branch

[Hans-Peter Nilsson]

> Date: Sun, 10 Jun 2007 22:47:16 -0700
> From: "=?EUC-KR?B?U2VvbmdiYWUgUGFyayAoudq8urnoLCDa0+D328Yp?=" <[EMAIL 
> PROTECTED]>

> This little patch:
> [...]

> should fix the problem (thanks to Ian Lance Talyor and Andrew
> Pinski for helping me debug the problem on IRC). I've started
> the bootstrap/regtest on x86-64. I'd appreciate it if you can
> test this on cris.

No regression for cris-elf with this applied on main trunk,
about r125614 ~ r125617 (applied to r125617 but for cris-elf
it's equal to r125614 whose results were the baseline).

For the branch, I started a test-run at home, and it hadn't
finished when I left (the libstdc++ tests were still running).
At a glance, it seemed to have fixed all the regressions.  I've
just started a fresh run from the dataflow-branch r125590 with
this patch applied, results in about 2.5 hours.

> Although the change is approved by Ian
> already, I think I'll hold the patch till the dataflow merge
> happens.

Your call, but as it's a real bug, I'd fix it sooner rather than
later.

Thanks to everyone involved for the quick fix!

brgds, H-P

Re: GCC 4.3.0 Status Report (2007-06-07)

[Kaveh R. GHAZI]

On Thu, 7 Jun 2007, Mark Mitchell wrote:

> I am also considering a "lockdown" period beginning June 15th during
> which we would go into a regressions-only mode (other than possible
> merges of the functionality above) in order to begin eliminating some of
> the problems that have come in with the exciting new infrastructure. Any
> comments on that course of action?

Hi Mark,

Just a reminder, I'm planning on installing my patches for const typedefs
which you preapproved for stage 2 here:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00415.html

I will of course wait until after the lockdown.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: GCC 4.3.0 Status Report (2007-06-07)

[Michael Meissner]

On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote:
> Joseph S. Myers wrote:
> > On Thu, 7 Jun 2007, Mark Mitchell wrote:
> > 
> >> I am aware of three remaining projects which are or might be appropriate
> >> for Stage 1:
> > 
> > Do we at this point believe that the people who were working on updating 
> > the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now 
> > going to have them ready in time?
> 
> I don't see any evidence that those changes will be ready.  I haven't
> heard of any progress from the volunteer at AMD who was working on that.
>  However, I also think that those changes could go in during Stage 2, if
> they are ready by then.

Unfortunately that person has left AMD.  Evidently he and I had some
miscommunication, becuase I thought those patches had been checked in before he
left.  I have been told by my management to either resurrect the patches, or
create new patches to fix the backends.  Can you remind me what changes need to
be made?  Sorry about this confusion.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: GCC 4.3.0 Status Report (2007-06-07)

[H. J. Lu]

On Fri, Jun 08, 2007 at 06:07:14AM -0700, H. J. Lu wrote:
> On Thu, Jun 07, 2007 at 10:33:26PM -0700, Mark Mitchell wrote:
> > I am aware of three remaining projects which are or might be appropriate
> > for Stage 1:
> > 
> > In the interests of moving forwards, I therefore plan to close this
> > exceptionally long Stage 1 as of next Friday, June 15th.  The projects
> > named above may be merged, even though we will be in Stage 2 -- but no
> > other functionality of Stage 1 scope may be included after this point.
> > 
> 
> Intel is planning to contribute Intel BID runtime library before July
> 1. Marius, can we make it before June 15th?
> 

Hi Mark,

While working on libbid integration, I was blocked by a gcc 4.3
regression:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293

Can we get a few extra days?

Thanks.


H.J.

STL in G++?

[Dean Anderson]

This may be a stupid question, but I didn't find anything by googling 
gcc, g++, STL. So:

There are no STL header files in some versions of g++: 
The program works on some g++'s, but not on others:




#include 
#include 
#include 

using namespace std;

template 
class PrintGt5: public unary_function
{
public: 
PrintGt5(){}
void operator()(T a) { if (a > T(5)) cout << a << ' '; }
};

main()
{
int ar [10], i;

for(i=0; i < 10; i++) ar[i] = i;

for_each(ar, ar+10, PrintGt5());
cout << endl;

return 0;
}
[EMAIL PROTECTED] asn1]# g++ stl.cpp
stl.cpp:1:21: algorithm: No such file or directory
stl.cpp:2:20: iostream: No such file or directory
stl.cpp:3:22: functional: No such file or directory
stl.cpp:8: error: expected template-name before '<' token
stl.cpp:8: error: expected `{' before '<' token
stl.cpp:8: error: expected unqualified-id before '<' token
stl.cpp: In function `int main()':
stl.cpp:21: error: invalid use of undefined type `class PrintGt5'
stl.cpp:8: error: declaration of `class PrintGt5'
stl.cpp:21: error: `for_each' was not declared in this scope
stl.cpp:22: error: `cout' was not declared in this scope
stl.cpp:22: error: `endl' was not declared in this scope


STLport also won't compile, because it seems to expect _some_ headers
from g++.  I configured gcc for c,c++,ada support.  Version is gcc 
3.4.6 with ada-2005. 


The above program won't work on this:

g++ -v
Reading specs from 
/usr/local/lib/gcc/sparc-unknown-linux-gnu/3.4.6/specs
Configured with: ../gcc-34/configure --enable-shared 
--enable-threads=posix --disable-checking --with-cpu=v7 
--enable-languages=c,c++,ada
Thread model: posix
gcc version 3.4.6 for GNAT GPL 2006 (20060522)



The above program works on this one:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)



What's up with STL support in g++?  Is there some add-on for STL?

Thanks,


--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   

Re: STL in G++?

[Joe Buck]

On Mon, Jun 11, 2007 at 06:06:14PM -0400, Dean Anderson wrote:
> This may be a stupid question, but I didn't find anything by googling 
> gcc, g++, STL. So:

Please use gcc-help, so that someone can help you with your installation
problem.  All g++'s from 3.0 on ship with a standard library that has
, , etc.  You do not need any third-party package
like STLport.

It is unclear what you did wrong from your message, but it's off-topic
for the gcc list.

[fixed-point] Fixed-point branch merge plan

[Fu, Chao-Ying]

Hi,

  As Mark requested, we propose a merge plan for the fixed-point branch
as follows.

1. Merge in machine modes to support signed and unsigned
fract and accum modes.  Handle scalar and vector modes.

2. Merge in fixed-value.h and fixed-value.c to handle fixed-point values.
 
3. Merge in TREE structures for fixed-point types and constants.

4. Merge in C front-end changes to parse _Sat, _Fract and _Accum.

5. Merge in RTL structures for fixed-point constants and operators.

6. Merge in libcpp to parse fixed-point constants.

7. Merge in changes to support "case" of FIXED_POINT_TYPE, FIXED_CST,
and CONST_FIXED in .c and .h files.

8. Merge in the MIPS backend that supports fixed-point instructions.

9. Merge in configure/build system changes for the runtime library.

10. Merge in testsuite (from gcc.dg/fixed-point) that only run
when the compiler is configured to enable fixed-point.

  This plan is similar to the DFP merge plan from this link.
http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html
Our changes will be active for the mips target and all other targets
should not be affected.  For each step, we will wait for some days
to fix any breakage.  Comments are welcome!

  Thanks a lot!

Regards,
Chao-ying

gcc-4.1-20070611 is now available

[gccadmin]

Snapshot gcc-4.1-20070611 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070611/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 125627

You'll find:

gcc-4.1-20070611.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20070611.tar.bz2 C front end and core compiler

gcc-ada-4.1-20070611.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20070611.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20070611.tar.bz2  C++ front end and runtime

gcc-java-4.1-20070611.tar.bz2 Java front end and runtime

gcc-objc-4.1-20070611.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20070611.tar.bz2The GCC testsuite

Diffs from 4.1-20070604 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: GCC 4.3.0 Status Report (2007-06-07)

[Mark Mitchell]

Michael Meissner wrote:
> On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote:
>> Joseph S. Myers wrote:
>>> On Thu, 7 Jun 2007, Mark Mitchell wrote:
>>>
 I am aware of three remaining projects which are or might be appropriate
 for Stage 1:
>>> Do we at this point believe that the people who were working on updating 
>>> the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now 
>>> going to have them ready in time?

> Unfortunately that person has left AMD.  Evidently he and I had some
> miscommunication, becuase I thought those patches had been checked in before 
> he
> left.  I have been told by my management to either resurrect the patches, or
> create new patches to fix the backends.  Can you remind me what changes need 
> to
> be made?  Sorry about this confusion.

Thanks for following up.  The goal here is to merge the patches on the
(old) LTO branch which change the representation of TYPE_ARG_TYPES.  At
present, that is a TREE_LIST; on the LTO branch, this representation was
changed so that it was instead a TREE_VEC, which saves memory and makes
accesses more efficient.

The work remaining was to get these patches working with all of the
various back ends.  Some of them directly manipulate FUNCTION_TYPEs, and
so need changes.  If you would be willing to work on that, that would be
terrific!

Please let Kazu Hirta <[EMAIL PROTECTED]> or myself know if you need
help.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713