headers
Mark Mitchell | 1 Aug 2006 01:28

Re: header.h vs. HEADER_H in dependencies

Volker Reichelt wrote:

> I could revert part of the change, i.e. replace $(VARRAY_H) in
> REGS_H and BASIC_BLOCK_H by varray.h again. (I'm just testing the
> patch. It survives bootstrap and the messages are gone. The
> testsuite is still running, though.)

Please do that, for now.  Let's not do over-much in this stage of the
development cycle.

I don't think you can really win here without automatically generated
dependencies.  The core problem is that the headers included by tm.h are
conditional on GENERATOR_FILE, but the Makefile is structured (using
$FOO_H dependencies) to assume that the set of dependencies is purely a
function of the header file.

(I thought moving cpplib to the top level was the change required to get
automatic dependencies working.  However, I'm not sure why even that is
required.  I would think that we could get with a Makefile that just
called out the vital dependencies (e.g., gen* dependent on first
building gen*.c, etc.).  If the compiler is being built with a non-GCC
compiler as the bootstrap compiler, just don't generate automatic
dependencies.  Then, editing stuff will not rebuild enough things.  But,
people who want to do serious development on GCC will always have a GCC
compiler around to use as the build compiler anyhow, in practice.)

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Mitchell | 1 Aug 2006 01:29

Re: trivial rs6000 fix

Stuart Hastings wrote:

> 2006-08-31  Stuart Hastings  <stuart <at> apple.com>
> 
>     * rtl.h (UINTVAL) New.
>     * config/rs6000/rs6000.c (SMALL_INT) Use it.
>     * testsuite/gcc.dg/20060801-1.c: New.

OK.

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(650) 331-3385 x713
Permalink | Reply | 0 comments |
headers
Volker Reichelt | 1 Aug 2006 01:49
Picon
Picon
Favicon

Re: header.h vs. HEADER_H in dependencies

On 31 Jul, Mark Mitchell wrote:
> Volker Reichelt wrote:
> 
>> I could revert part of the change, i.e. replace $(VARRAY_H) in
>> REGS_H and BASIC_BLOCK_H by varray.h again. (I'm just testing the
>> patch. It survives bootstrap and the messages are gone. The
>> testsuite is still running, though.)
> 
> Please do that, for now.  Let's not do over-much in this stage of the
> development cycle.

Done.

I filed the remaining problems as http://gcc.gnu.org/PR28561

Regards,
Volker
Permalink | Reply | 0 comments |
headers
Dirk Mueller | 1 Aug 2006 01:50
Picon

[PATCH] bitmap leak low hanging fruits


Hi, 

In two places bitmap's were allocated but never free'd. 

2006-08-01  Dirk Mueller  <dmueller <at> suse.de>

    * tree-vrp.c (fix_equivalence_set): Avoid bitmap memory leak.
    * tree-outof-ssa.c (check_replaceable): Likewise.

--- tree-vrp.c	(revision 115775)
+++ tree-vrp.c	(working copy)
 <at>  <at>  -760,7 +759,7  <at>  <at>  fix_equivalence_set (value_range_t *vr_p
   bitmap_iterator bi;
   unsigned i;
   bitmap e = vr_p->equiv;
-  bitmap to_remove = BITMAP_ALLOC (NULL);
+  bitmap to_remove;

   /* Only detect inconsistencies on numeric ranges.  */
   if (vr_p->type == VR_VARYING
 <at>  <at>  -768,6 +767,7  <at>  <at>  fix_equivalence_set (value_range_t *vr_p
       || symbolic_range_p (vr_p))
     return;

+  to_remove = BITMAP_ALLOC (NULL);
   EXECUTE_IF_SET_IN_BITMAP (e, 0, i, bi)
     {
       value_range_t *equiv_vr = vr_value[i];
--- tree-outof-ssa.c	(revision 115775)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Mitchell | 1 Aug 2006 01:59

Re: [PATCH] bitmap leak low hanging fruits

Dirk Mueller wrote:

> 2006-08-01  Dirk Mueller  <dmueller <at> suse.de>
> 
>     * tree-vrp.c (fix_equivalence_set): Avoid bitmap memory leak.
>     * tree-outof-ssa.c (check_replaceable): Likewise.

OK.  (The second hunk is the same as Jan's change; whoever gets their
first wins.)

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(650) 331-3385 x713
Permalink | Reply | 1 comment |
headers
Dirk Mueller | 1 Aug 2006 02:48
Picon

Re: [PATCH] bitmap leak low hanging fruits

On Tuesday, 1. August 2006 01:59, Mark Mitchell wrote:

> OK.  (The second hunk is the same as Jan's change; whoever gets their
> first wins.)

whoops, didn't notice that. Since Jan came first, I left out the 2nd hunk. 

Dirk
Permalink | Reply | 0 comments |
headers
Daniel Berlin | 1 Aug 2006 04:06

Re: Save 6% of GGC memory (consumed in tree-ssa-pre)

Jan Hubicka wrote:
> Hi,
> memory statistics for combine.c at -O2 shows 13% of memory to be taken
> by create_tree_ann function:
> tree-phinodes.c:156 (allocate_phi_node)             3813160: 4.6% 0: 0.0%          0: 0.0%      22568: 0.3%      12114
> genrtl.c:17 (gen_rtx_fmt_ee)                        7518920: 9.1% 0: 0.0%       3080: 0.0%    1504400:17.1%     188050
> tree-dfa.c:209 (create_tree_ann)                   10927080:13.3% 0: 0.0%       7440: 0.1%     728968: 8.3%      91121
> Total                                              82223861 12694004          6318427          8805836          1369076
> 
> This is the same for my now favorite testcase and other common sources.
> I always accounted it to annotations being bloated, but I unstrumented
> create_tree_ann for statistics and found out that this all memory is in
> fact allocated all by tree-vn and it is all there just to hold one
> pointer value_handle.  I would say that a hashtable would do a lot
> better job here (or direct use of the annotation pointer on
> expressions), but I am leaving it for Danny 

If you use a hashtable, your PRE times will jump about 4 or 5x (my
recollection but feel free to try it yourself :) )
It makes *very* heavy use of getting the value handle, and it can't
really be avoided.
Permalink | Reply | 3 comments |
headers
Alexandre Oliva | 1 Aug 2006 06:25
Picon
Favicon

Re: [PATCH] Further improved native as support on Solaris/x86

On Jul 22, 2006, Paul Brook <paul <at> codesourcery.com> wrote:

>> But it was a good suggestion.  I agree that if the "label - ." syntax
>> can be made to work, we can avoid the "label1 - label2" problem.  But
>> as explained above and in my previous e-mail the "label - ." syntax
>> isn't recognized by SUN as either.

> I'd expect/hope that any assembler capable of doing label - . would also be 
> capable of doing label1 - label2.

I wouldn't.  If a linker is expected to do relaxations that change
code size, then `label1 - label2' requires more information than
`label - .'  Not the case for x86_64, but I thought I'd point this out
anyway.

--

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva <at> {redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva <at> {lsd.ic.unicamp.br, gnu.org}
Permalink | Reply | 0 comments |
headers
Alexandre Oliva | 1 Aug 2006 06:27
Picon
Favicon

Re: [PATCH] Further improved native as support on Solaris/x86

On Jul 21, 2006, Roger Sayle <roger <at> eyesopen.com> wrote:

>         .long   .L4-.L8

> Notice that the symbol .L8 is in the section .rodata, and the symbol
> .L4 (and all the others) are in the section .L4.

>         "switch.s", line 20 : Illegal subtraction - symbols from different sections: ".L3", ".L8"

> Defining JUMP_TABLES_IN_TEXT_SECTION makes the problem go away.

Even if you try to split hot/cold code into separate sections?  I
wouldn't think so, in general.

--

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva <at> {redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva <at> {lsd.ic.unicamp.br, gnu.org}
Permalink | Reply | 0 comments |
headers
Jayant Sonar | 1 Aug 2006 07:18
Favicon

RE: [PATCH, M32C] : Special page vector table implementation

Hi DJ,

> This part looks fine, although since it doesn't fix any bugs, it 
> will have to wait for stage 1 (remind me then to apply it):

Thank you for your comments.
I'll remind you when GCC will enter in stage 1.

> This part needs to have the text moved after the gas/gld requirements
> paragraph, which only apply to H8/300:

I've modified the patch as per your suggestion and re-attaching it 
here again.

Regards,
Jayant Sonar
KPIT Cummins Infosystems Ltd,
Pune (INDIA) 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C
 and M32C series. 
The following site also offers free technical support to its users. 
Visit http://www.kpitgnutools.com for details. 
Latest versions of KPIT GNU tools were released on June 1, 2006.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Attachment (special_page_vect_patch.tar.gz): application/x-gzip, 3202 bytes
Permalink | Reply | 0 comments |

Gmane