[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0

[seongbae dot park at gmail dot com]

--- Comment #3 from seongbae dot park at gmail dot com  2006-06-23 18:26 
---
I'm able to reproduce the problem with 4.2.0 on linux/x86.

valgrind-3.2.0/memcheck/mc_main.c has 

359 static AuxMapEnt  hacky_auxmaps[N_AUXMAPS];
...
362 static AuxMapEnt* auxmap  = &hacky_auxmaps[0];

There's no direct use of hacky_auxmaps except through auxmap.

Anyway, 4.2 leaves the relocation:

# readelf -s ./bad.o | grep aux
   323:  0 NOTYPE  GLOBAL DEFAULT  UND hacky_auxmaps
# readelf -r ./bad.o | grep aux
9c87  00014301 R_386_32     hacky_auxmaps
#

which obviously can not be resolved. 
The bad relocation is in .rel.debug_info section.

I'll try to trace back why the bad relocation is generated.


-- 


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

[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0

[seongbae dot park at gmail dot com]

--- Comment #4 from seongbae dot park at gmail dot com  2006-06-23 18:43 
---
The problem is causedby the extra DW_AT_const_value.
4.1.0 generates the following dwarf entry for auxmap:

 <1>: Abbrev Number: 31 (DW_TAG_variable)
 DW_AT_name: (indirect string, offset: 0x35e): auxmap
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 362
 DW_AT_type: 
 <1>: Abbrev Number: 26 (DW_TAG_const_type)

whereas 4.2.0 generates:
 <1><9c6e>: Abbrev Number: 70 (DW_TAG_variable)
 DW_AT_name: (indirect string, offset: 0x16dd): auxmap_used
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 361
 DW_AT_type: <9c69>
 DW_AT_const_value : 0

and the bad relocation is the value of DW_AT_const_value.
In the asembly:
.uleb128 0x48
.long   .LASF367
.byte   0x1
.value  0x16a
.long   0x9c8b
.long   hacky_auxmaps
.uleb128 0x1b

Looks like the new feature to note the constant value of a symbol 
(auxmap is initialized to &hacky_auxmaps[0] as shown above)
causes the relocation to be left against a static symbol.


-- 

seongbae dot park at gmail dot com changed:

   What|Removed |Added

     CC|                |seongbae dot park at gmail
       |    |dot com


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

[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0

[seongbae dot park at gmail dot com]

--- Comment #5 from seongbae dot park at gmail dot com  2006-06-23 23:55 
---
Looks like this indeed is a duplicate of 27657.

In toplev.c:
   1013   cgraph_varpool_assemble_pending_decls ();
...
   1040   (*debug_hooks->finish) (main_input_filename);

dwarf2 finish ends up calling final.c:output_address w/ SYMREF to hacky_auxmap,
which calls mark_decl_referenced() for hacky_auxmap declaration
and is added to the pending list of varpool decls to be emitted.
However, there's no call to cgraph_varpool_assemble_pending_decls() 
so even though hacky_auxmap is marked as needed, it won't get output.

Calling 
cgraph_varpool_assemble_pending_decls() 
after debug hook finish can alleviate the linking problem
by forcing the emission of hacky_auxmap (which seems 
unused except for debug information purpose,
after uncalled static function elimination).

However, the real cause is having const value marking for an unused 
(and hence removed) static variable - gcc seems to determine
that auxmap is not used, after some removal of unused static functions
and the analysis looks correct (though I didn't try hard to verify that).


-- 


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

[Bug middle-end/28160] Bogus "size of array 'foo' is too large" error with -mms-bitfields

[seongbae dot park at gmail dot com]

--- Comment #1 from seongbae dot park at gmail dot com  2006-06-26 20:46 
---
I belive this is a bug in stor-layout.c:place_field() around line 10503
bitpos is calculated as bit_offset of rli->prev_field + type size.
However, the prev_field is not really the immediately previous field but the
first field of the consecutive same-sized fields.
Hence, in this case:

struct S
{
  long long d:23;
  int e:32;
  int f:32;
} a;

rli->prev_field is "d" when "field" is f. 
The correct fix should calculate the bitpos as 
rli->bitpos + type size.


-- 

seongbae dot park at gmail dot com changed:

   What|Removed |Added

 CC|            |seongbae dot park at gmail
   |        |dot com


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

[Bug middle-end/28160] Bogus "size of array 'foo' is too large" error with -mms-bitfields

[seongbae dot park at gmail dot com]

--- Comment #2 from seongbae dot park at gmail dot com  2006-06-26 20:47 
---
Oops. Mu previous comment is misplaced. It should have been on PR28161. 
Please ignore it.


-- 


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

[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields

[seongbae dot park at gmail dot com]

--- Comment #1 from seongbae dot park at gmail dot com  2006-06-26 20:47 
---
I belive this is a bug in stor-layout.c:place_field() around line 10503
bitpos is calculated as bit_offset of rli->prev_field + type size.
However, the prev_field is not really the immediately previous field but the
first field of the consecutive same-sized fields.
Hence, in this case:

struct S
{
  long long d:23;
  int e:32;
  int f:32;
} a;

rli->prev_field is "d" when "field" is f. 
The correct fix should calculate the bitpos as 
rli->bitpos + type size.


-- 

seongbae dot park at gmail dot com changed:

   What|Removed |Added

 CC|            |seongbae dot park at gmail
   |        |dot com


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

[Bug middle-end/28160] Bogus "size of array 'foo' is too large" error with -mms-bitfields

[seongbae dot park at gmail dot com]

--- Comment #3 from seongbae dot park at gmail dot com  2006-06-26 21:08 
---
The immediate cause of the problem is in stor-layout.c:place_field():

   1118   if (DECL_SIZE (field) != NULL
   1119   && host_integerp (TYPE_SIZE (TREE_TYPE (field)), 0)
   1120   && host_integerp (DECL_SIZE (field), 0))
   1121 rli->remaining_in_alignment
   1122   = tree_low_cst (TYPE_SIZE (TREE_TYPE(field)), 1)
   1123 - tree_low_cst (DECL_SIZE (field), 1);

For the field "d", 
remiaining_in_alignment becomes negative after line 1121-1123
- because the DECL_SIZE is larger than TYPE_SIZE for "d".


-- 


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

[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields

[seongbae dot park at gmail dot com]

--- Comment #2 from seongbae dot park at gmail dot com  2006-06-26 21:10 
---
More specifically:

   1048   if (rli->remaining_in_alignment < bitsize)
   1049 {
   1050   /* out of bits; bump up to next 'word'.  */
   1051   rli->offset = DECL_FIELD_OFFSET (rli->prev_field);
   1052   rli->bitpos
   1053 = size_binop (PLUS_EXPR, TYPE_SIZE (type),
   1054   DECL_FIELD_BIT_OFFSET
(rli->prev_field));
   1055   rli->prev_field = field;
   1056   rli->remaining_in_alignment
   1057 = tree_low_cst (TYPE_SIZE (type), 1);
   1058 }

The third operand of size_binop() of size_binop() at line 1053-1054 
should be rli->bitpos.


-- 


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

[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields

[seongbae dot park at gmail dot com]

--- Comment #4 from seongbae dot park at gmail dot com  2006-06-26 23:41 
---
You're correct -I've overlooked the type mismatch. 
One question though is the local variable "type" of place_field() is 
TREE_TYPE (field), not DECL_BIT_FIELD_TYPE (field).
I'm not familiar with gcc type system to know which is correct
but it doesn't look consistent as it is.


-- 


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

[Bug gcov/profile/28441] Need atomic increment of gcov counters for MP programs

[seongbae dot park at gmail dot com]

--- Comment #5 from seongbae dot park at gmail dot com  2006-07-23 17:27 
---
It seems that you didn't change libgcov.c,
which suggests that you didn't address __gcov_{pow2,interval}_profiler.
Without such change, -fprofile-generate will cause the mismatch between
the value counters and edge counters, 
so it would be very nice if you can fix that as well 
(this is just a suggestion).

In case someone wants to address that issue,
I think there are three choices:

#1 make above profiler routines to use atomic increment *always*
#2 introduce a new environment variable to pick atomic/non-atomic increment
#3 make atomic increment version of those routines and -fprofile-multithread to
generate codes to call them.

I prefer #3, but #1 might be simple enough without much bad affect.

Another comment is about the name of -fprofile-multithread.
There's an alternative MT-safe profiling scheme of making counters TLS.
So I'd prefer if the option for atomic increment is more explicit, 
something like -fprofile-atomic-increment.


-- 


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

[Bug target/29337] New: -mfpmath=387 doesn't use fistp for double-to-integer conversion

[seongbae dot park at gmail dot com]

-mfpmath=387 used on x86_64 is supposed to force gcc to use 387 for floating
point{math. However, even with the option, gcc generates cvtts{s,d}2* instead
of fistp* for floating-point to integer conversion. 

This makes a difference if/when the extra precision of 387 makes difference to
the conversion - which -mfpmath=387 is supposed to prevent.


-- 
   Summary: -mfpmath=387 doesn't use fistp for double-to-integer
conversion
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: seongbae dot park at gmail dot com
  GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/29337] -mfpmath=387 doesn't use fistp for double-to-integer conversion

[seongbae dot park at gmail dot com]

--- Comment #2 from seongbae dot park at gmail dot com  2006-10-03 23:37 
---
(In reply to comment #1)
> (In reply to comment #0)
> 
> > This makes a difference if/when the extra precision of 387 makes difference 
> 
> for an extra prescision try to use a `long double'.

I'm afraid you're missing my point.
The problem is that for 64-bit and 32-bit floating-point to integer conversion,
x86 (32bit) target uses fistp* whereas x86_64 (64-bit) target uses cvt* WHEN
-mfpmath=387.
This defeats the purpose of the option -mfpmath=387 which is supposed to make
floating-point computations to use 387, instead of SSE2.


-- 


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

[Bug target/29337] -mfpmath=387 doesn't use fistp for double-to-integer conversion

[seongbae dot park at gmail dot com]

--- Comment #6 from seongbae dot park at gmail dot com  2006-10-05 05:00 
---
For example:

# cat m.c
int todouble(double a, double b) {
  return (int)(a+b);
}
#

With 4.1.0 i686-unknown-linux-gnu target:

# gcc -O2 m.c -S
# cat m.s
...
.type   todouble, @function
todouble:
pushl   %ebp
movl%esp, %ebp
subl$8, %esp
fnstcw  -2(%ebp)
fldl16(%ebp)
faddl   8(%ebp)
movzwl  -2(%ebp), %eax
orw $3072, %ax
movw%ax, -4(%ebp)
fldcw   -4(%ebp)
fistpl  -8(%ebp)
fldcw   -2(%ebp)
movl-8(%ebp), %eax
leave
ret
...

With x86_64-unknown-linux-gnu (without -mfpmath=387):

# gcc -O2 m.c -S
# cat m.s
...
todouble:
.LFB2:
addsd   %xmm1, %xmm0
cvttsd2si   %xmm0, %eax
ret


With x86_64-unknown-linux-gnu with -mfpmath=387:
# gcc -O2 m.c -mfpmath=387 -S
# cat m.s
...
todouble:
.LFB2:
movsd   %xmm0, -8(%rsp)
fldl-8(%rsp)
movsd   %xmm1, -8(%rsp)
fldl-8(%rsp)
faddp   %st, %st(1)
fstpl   -8(%rsp)
movlpd  -8(%rsp), %xmm0
cvttsd2si   %xmm0, %eax
ret
#

All three codes can behave differently.
There's no doubt that using cvt* is faster, but that's not the point either.
I'm arguing that the purpose of -mfpmath=387 is to be compatible with 387
behavior, hence it should imply -mno-sse. 
The fact that -mfpmath=sse exists implies that -mfpmath=387 turns off sse
(and that's what the description of -mfpmath=387 says).
Clearly this is not the current behavior of -mfpmath=387 - so if this behavior
is not going to be fixed, at the least,
the documentation should be updated to reflect that.

Having said that,
-mno-sse is an acceptable workaround so I won't pursue the bug anymore.


-- 


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

[Bug c++/29225] [4.0/4.1/4.2 regression] ICE in gimplify_expr, at gimplify.c:4513

[seongbae dot park at gmail dot com]

--- Comment #5 from seongbae dot park at gmail dot com  2006-10-13 02:27 
---
A modified and valid case which doesn't cause ICE:


template bool operator<( LHS lhs, RHS rhs );

struct ComputedAttribute {
int descriptor();
};

class AttributeDescriptor {};

template 
struct less_member_2_m
{
   typedef R (T::* T_mem_ptr) ();
   T_mem_ptr mem_ptr;

   template 
   bool operator()(R_alt & rhs )
   {
 T a;
 return ( a.*mem_ptr  )() < rhs ;
   }
};

void computedAttribute( AttributeDescriptor & desc  )
{
less_member_2_m m;
m.mem_ptr = &ComputedAttribute::descriptor;

m(desc);
}


Change the operator() to:
   template 
   bool operator()(R_alt & rhs )
   {
 T a;
 return ( a.*mem_ptr ) < rhs ;
   }

causes the ICE.
# /home/spark/blds/trunk-work/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/spark/local/ws/trunk-work/configure
--prefix=/home/spark/blds/trunk-work/ --disable-nls --disable-multilib
-enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit -enable-c99
--enable-long-long --enable-shared --enable-languages=c,c++
Thread model: posix
gcc version 4.2.0 20061006 (experimental)
# /home/spark/blds/trunk-work/bin/g++ correct.cc -c
# /home/spark/blds/trunk-work/bin/g++ incorrect.cc -c
incorrect.cc: In member function 'bool less_member_2_m::operator()(R_alt&) [with R_alt = AttributeDescriptor, T =
ComputedAttribute, R = int]':
incorrect.cc:28:   instantiated from here
incorrect.cc:19: internal compiler error: in gimplify_expr, at gimplify.c:5806
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
#

Note that this is the same ICE I get from the attachment.


-- 

seongbae dot park at gmail dot com changed:

   What|Removed |Added

         CC|    |seongbae dot park at gmail
           ||dot com


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

[Bug middle-end/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90

[seongbae dot park at gmail dot com]

--- Comment #22 from seongbae dot park at gmail dot com  2007-07-26 17:56 
---
Subject: Re:  [4.3 regression]: gfortran.dg/auto_array_1.f90

On 7/26/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> Seongbae Park (???, ???) wrote:
> > On 7/26/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> >> This patch extends the fix in
> >> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html
> >> to handle the case of clobbers inside conditional calls.
> >>
> >> This problem caused the regression of gfortran.dg/matmul_3.f90 on the
> >> ia-64 in addition to the regression cited in this pr.
> >>
> >> Tested on ppc-32, ia-64 and x86-64.
> >>
> >> 2007-07-26 Kenneth Zadeck <[EMAIL PROTECTED]>
> >>
> >> PR middle-end/32749
> >>
> >> * df-problems.c (df_note_bb_compute): Handle case of clobber
> >> inside conditional call.
> >>
> >> ok to commit?
> >
> > This change is OK.
> > Though I wonder if we need to do similar checking
> > for the regular insn case below.
> No the checking is done in df_create_unused_note. The only reason you
> have to do it here is that you are not calling that.
>
> thanks

Now that I look at df_create_unused_note,
this patch smells a bit - because the condition
inside the for loop looks identical to df_create_unused_node.
I think it would be cleaner if we split the live vector update
into a separate function. i.e. attached patch (untested).


--- Comment #23 from seongbae dot park at gmail dot com  2007-07-26 17:56 
---
Created an attachment (id=13986)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13986&action=view)


-- 


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

[Bug middle-end/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90

[seongbae dot park at gmail dot com]

--- Comment #20 from seongbae dot park at gmail dot com  2007-07-26 17:27 
---
Subject: Re:  [4.3 regression]: gfortran.dg/auto_array_1.f90

On 7/26/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> This patch extends the fix in
> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html
> to handle the case of clobbers inside conditional calls.
>
> This problem caused the regression of gfortran.dg/matmul_3.f90 on the
> ia-64 in addition to the regression cited in this pr.
>
> Tested on ppc-32, ia-64 and x86-64.
>
> 2007-07-26  Kenneth Zadeck <[EMAIL PROTECTED]>
>
> PR middle-end/32749
>
> * df-problems.c (df_note_bb_compute): Handle case of clobber
> inside conditional call.
>
> ok to commit?

This change is OK.
Though I wonder if we need to do similar checking
for the regular insn case below.


-- 


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

[Bug rtl-optimization/33669] [4.3 Regression] Revision 128957 miscompiles 481.wrf

[seongbae dot park at gmail dot com]

--- Comment #12 from seongbae dot park at gmail dot com  2007-10-08 20:18 
---
Subject: Re:  [4.3 Regression] Revision 128957 miscompiles 481.wrf

Please remove the extra blank line above the line 984 (in new file).
This patch is OK.

Seongbae

On 10/7/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> This patch fixes pr33669.
>
> The failure only happens if you have a block with 2 or more uses of a
> multiword pseudo register that is local to this block and has been
> allocated by local_alloc.  The uses must be in a particular form: the
> last use must be a subreg use that only used some of the hard registers and
> a previous non subreg use of the multiword register.
>
> When all of this happens, the code did not properly expand this to a
> whole multiregister when the second to last use is encountered in the
> backwards scan.
>
> I.e. a lot of things have to happen to get this to fail.
>
> I have tested this patch on ia-64, x86-{64,32} and ppc-32.
>
> Ok for commit?
>
> Kenny
>
> 2007-10-07  Kenneth Zadeck <[EMAIL PROTECTED]>
>
> PR middle-end/33669
> * ra-conflict.c (record_one_conflict_between_regnos,
> set_conflicts_for_earlyclobber, global_conflicts): Improved logging.
> (global_conflicts): Removed incorrect check.
>
> 2007-10-07  Kenneth Zadeck <[EMAIL PROTECTED]>
>
> PR middle-end/33669
> * gcc.c-torture/execute/pr33669.c: New.
>
>
>
>


-- 


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

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

[seongbae dot park at gmail dot com]

--- Comment #51 from seongbae dot park at gmail dot com  2008-01-17 21:31 
---
Subject: Re:  [4.3 regression] bad interaction between DF and SJLJ exceptions

In df_live_transfer_function:

Doesn't look like we need df_live_scratch - can't we do:

bitmap_and (out, gen, bb_lr_info->out);
bitmap_and_into (in, bb_lr_info->in);
return bitmap_ior_and_compl_into (out, in, kill);

?

Seongbae

On Jan 17, 2008 1:05 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> This is the second of three patches to fix 34400.  This patch also makes
> some progress on 26854 but more work is required that is not going to be
> done in 4.3 to fix the problems here.
>
> This patch uses the output of the df_lr problem to make the df_live
> problem converge faster.
> This not only saves time but also space since the size of the df_live
> bitmaps never grows and the space of our bitmaps is proportional to the
> number of 1 bits.
>
> This has been tested on several platforms and along with the patch just
> committed cuts the time on the 34400 problems significantly.  I believe
> that this patch also has some modest improvement on bootstrap time, i.e
> regular programs.
>
> The change to df_live_reset is a slightly related latent bug fix.
>
> Ok to commit?
>
> Kenny
>
>
> 2008-01-17  Kenneth Zadeck  <[EMAIL PROTECTED]>
> Steven Bosscher  <[EMAIL PROTECTED]>
>
> PR rtl-optimization/26854
> PR rtl-optimization/34400
> * df-problems.c (df_live_scratch): New scratch bitmap.
> (df_live_alloc): Allocate df_live_scratch when doing df_live.
> (df_live_reset): Clear the proper bitmaps.
> (df_live_bb_local_compute): Only process the artificial defs once
> since the order is not important.
> (df_live_init): Init the df_live sets only with the variables
> found live by df_lr.
> (df_live_transfer_function): Use the df_lr sets to prune the
> df_live sets as they are being computed.
> (df_live_free): Free df_live_scratch.
>
>


-- 


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

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

[seongbae dot park at gmail dot com]

--- Comment #52 from seongbae dot park at gmail dot com  2008-01-17 22:31 
---
Subject: Re:  [4.3 regression] bad interaction between DF and SJLJ exceptions

I just talked to Kenny on the phone, and my suggestion is wrong
since it changes the return value - doing my naive suggestion
would lead to infinite loop, as the transfer function will almost always
return true, even when the out set didn't change.
Can you add a comment to that effect there ?
Also please add a comment above df_live_scratch definition
that this is an optimization to reduce memory allocation overhead
for the scratch.

Can you explain why the hunk in df_live_bb_local_compute() is correct ?
As this seems to change what DF_REF_AT_TOP means for artificial defs...

Seongbae

On Jan 17, 2008 1:31 PM, Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ)
<[EMAIL PROTECTED]> wrote:
> In df_live_transfer_function:
>
> Doesn't look like we need df_live_scratch - can't we do:
>
> bitmap_and (out, gen, bb_lr_info->out);
> bitmap_and_into (in, bb_lr_info->in);
> return bitmap_ior_and_compl_into (out, in, kill);
>
> ?
>
> Seongbae
>
>
> On Jan 17, 2008 1:05 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> > This is the second of three patches to fix 34400.  This patch also makes
> > some progress on 26854 but more work is required that is not going to be
> > done in 4.3 to fix the problems here.
> >
> > This patch uses the output of the df_lr problem to make the df_live
> > problem converge faster.
> > This not only saves time but also space since the size of the df_live
> > bitmaps never grows and the space of our bitmaps is proportional to the
> > number of 1 bits.
> >
> > This has been tested on several platforms and along with the patch just
> > committed cuts the time on the 34400 problems significantly.  I believe
> > that this patch also has some modest improvement on bootstrap time, i.e
> > regular programs.
> >
> > The change to df_live_reset is a slightly related latent bug fix.
> >
> > Ok to commit?
> >
> > Kenny
> >
> >
> > 2008-01-17  Kenneth Zadeck  <[EMAIL PROTECTED]>
> > Steven Bosscher  <[EMAIL PROTECTED]>
> >
> > PR rtl-optimization/26854
> > PR rtl-optimization/34400
> > * df-problems.c (df_live_scratch): New scratch bitmap.
> > (df_live_alloc): Allocate df_live_scratch when doing df_live.
> > (df_live_reset): Clear the proper bitmaps.
> > (df_live_bb_local_compute): Only process the artificial defs once
> > since the order is not important.
> > (df_live_init): Init the df_live sets only with the variables
> > found live by df_lr.
> > (df_live_transfer_function): Use the df_lr sets to prune the
> > df_live sets as they are being computed.
> > (df_live_free): Free df_live_scratch.
> >
> >
>
>
>
> --
> #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
>


-- 


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

[Bug c++/30257] New: static initializers are attributed to bogus line number in coverage.

[seongbae dot park at gmail dot com]

For a given input:

 1  class A {
 2int a;
 3  public:
 4A(int i) { a = i * i; }
 5
 6virtual void func(void);
 7  };
 8
 9  const A a1(1);
10
11  void func(void)
12  {
13  }


When compiled with -fprofile-arcs -ftest-coverage,
the gcno file contains a function 
_Z41__static_initialization_and_destruction_0ii
with some of the line number attributed to t.cc:13.
Since the static initializer has nothing to do with the function
"func()", it shouldn't get that line number.


-- 
   Summary: static initializers are attributed to bogus line number
in coverage.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: seongbae dot park at gmail dot com
 GCC build triplet: i686-unknown-linux-gnu
  GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu


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

[Bug c++/30257] static initializers are attributed to bogus line number in coverage.

[seongbae dot park at gmail dot com]

--- Comment #2 from seongbae dot park at gmail dot com  2006-12-19 06:58 
---
Yes, it looks like duplicate, although PR 15369 is against 3.4.


-- 


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