Re: Inserting function calls
what you do seems basically OK to me. The problem is that you also need
to fix the ssa form for the virtual operands of the added calls
(i.e., you must call mark_new_vars_to_rename for each of the calls,
and update_ssa once at the end of tree_handle_loop).
Zdenek
Ok, by inserting the mark_new_vars_to_rename and the TODO_update_ssa
flag in the associated struct tree_opt_pass.
This works (yeah!) and I can link my call before loads but it seems to
miss some...
To pass through the statements I use :
datarefs = VEC_alloc (data_reference_p, heap, 10);
dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
compute_data_dependences_for_loop (loop_nest, true, &datarefs,
&dependence_relations);
for (j = 0; VEC_iterate (data_reference_p, datarefs, j, a); j++)
{
tree stmt = DR_STMT (a);
/* See if it is a load */
if (DR_IS_READ (a))
However if in my test code I have this :
for(i=0;i<10;i++)
for(j=i+1;j<10;j++)
{
a = t[j];
b = t[i-1];
//Calculations with a and b...
}
I get am able to insert before the first load but the second doesn't
seem captured, this is what I get from debug_loop_ir :
__MarkovMainEntry (2);
# VUSE ;
a_12 = *D.2174_11;
# VUSE ;
b_18 = *D.2179_17;
Any idea why ? I've looked around in the code to see how they parse
the data dependance tree but I don't see a difference.
Thank you again,
Jc
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
hi,
On Wed, 2006-08-30 at 16:44 -0500, Mark Mitchell wrote:
[snip]
> (Implied, but not stated, in your mail is the fact that the abbreviation
> table cannot be indexed directly. If it could be, then you wouldn't
> have to read the entire abbreviation table for each function; you would
> just read the referenced abbreviations. Because the abbreviation table
> records are of variable length, it is indeed true that you cannot make
> random accesses to the table. So, this paragraph is just fleshing out
> your argument.)
I have spent a considerable amount of time looking at the abbrev tables
output by gcc are not totally random: their entries are sorted by their
abbrev code. That is, the abbrev code of entry i+1 is higher than that
of entry i.
I don't know how useful this would be for you but for me, it made a
_huge_ difference because it means I did not have to parse the whole
abbrev table when looking for an entry with a specific abbrev code and I
did not have to create a cache of code->offset mappings for the full
table. You can use a very small (I use 16 entries) cache of abbrev codes
for each abbrev table which tells you where the entry which contains
that abbrev code is located in the table. The key here is that you do
not need to cache all codes because you can use a code smaller than the
one you need to start parsing the table at that point.
The attached file implements such a cache. The
dwarf2_abbrev_cu_read_decl function searches for an entry in the abbrev
table which matches a given abbrev code using the code cache. I cannot
remember if this version actually works because I remember hacking it
quite a bit and stopping in the middle of the rework but this code
should illustrate what I was suggesting.
I hope this helps,
regards,
Mathieu
/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 8 -*- */
/*
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2 as published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
Copyright (C) 2004,2005 Mathieu Lacage
Author: Mathieu Lacage <[EMAIL PROTECTED]>
*/
#ifndef DWARF2_ABBREV_H
#define DWARF2_ABBREV_H
#include
#include
struct reader;
struct dwarf2_abbrev {
uint32_t start; /* start of .debug_abbrev from start of file */
uint32_t end; /* end of .debug_abbrev from start of file */
};
#define CACHE_SIZE (16)
struct dwarf2_abbrev_cu {
uint32_t start; /* offset from start of file */
uint32_t end; /* offset from start of file */
struct cache {
uint8_t keys[CACHE_SIZE];
uint32_t values[CACHE_SIZE];
uint8_t last_used[CACHE_SIZE];
uint8_t time;
} cache;
};
struct dwarf2_abbrev_decl {
uint32_t offset; /* offset from start of file to this decl. */
uint64_t abbr_code; /* abbrev code for this entry */
uint64_t tag;/* abbrev tag for this entry */
uint8_t children;/* children for this entry */
};
struct dwarf2_abbrev_attr {
uint64_t form;
uint64_t name;
};
void dwarf2_abbrev_initialize (struct dwarf2_abbrev *abbrev,
uint32_t abbrev_start /* offset from start of file */,
uint32_t abbrev_end /* offset from start of file */);
void dwarf2_abbrev_initialize_cu (struct dwarf2_abbrev *abbrev,
struct dwarf2_abbrev_cu *abbrev_cu,
uint32_t offset /* offset from start of file */);
void dwarf2_abbrev_cu_read_decl (struct dwarf2_abbrev_cu *abbrev_cu,
struct dwarf2_abbrev_decl *decl,
uint64_t code,
struct reader *reader);
void dwarf2_abbrev_decl_read_attr_first (struct dwarf2_abbrev_decl *decl,
struct dwarf2_abbrev_attr *attr,
uint32_t *new_offset,
struct reader *reader);
void dwarf2_abbrev_read_attr (uint32_t cur_offset,
struct dwarf2_abbrev_attr *attr,
uint32_t *new_offset,
struct reader *reader);
bool dwarf2_abbrev_attr_is_last (struct dwarf2_abbrev_attr *attr);
#endif /* DWARF2_ABBREV_H */
/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 8 -*- */
/*
This program is free software; you
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Mark Mitchell wrote: > Kenneth Zadeck wrote: > >> Even if we decide that we are going to process all of the functions in >> one file at one time, we still have to have access to the functions that >> are going to be inlined into the function being compiled. Getting at >> those functions that are going to be inlined is where the double the i/o >> arguement comes from. > > I understand -- but it's natural to expect that those functions will > be clumped together. In a gigantic program, I expect there are going > to be clumps of tightly connected object files, with relatively few > connections between the clumps. So, you're likely to get good cache > behavior for any per-object-file specific data that you need to access. > I just do not know. I assume that you are right, that there is some clumping. But I am just no sure. >> I have never depended on the kindness of strangers or the virtues of >> virtual memory. I fear the size of the virtual memory when we go to >> compile really large programs. > > I don't think we're going to blow out a 64-bit address space any time > soon. Disks are big, but they are nowhere near *that* big, so it's > going to be pretty hard for anyone to hand us that many .o files. > And, there's no point manually reading/writing stuff (as opposed to > mapping it into memory), unless we actually run out of address space. > I am not so concerned with running out of virtual address space than I am about being able to break this up so that it can be done in parallel, on a farm of machines. Otherwise, lto can never be part of anyone's compile/test loop. The notion of having 20 or 50 compile servers each mapping all of the files of a large system in seems like a bad design point. > In fact, if you're going to design your own encoding formats, I would > consider a format with self-relative pointers (or, offsets from some > fixed base) that you could just map into memory. It wouldn't be as > compact as using compression, so the total number of bytes written > when generating the object files would be bigger. But, it will be > very quick to load it into memory. > If you look at my code, that is what I have, at least with respect to the function itself. There is one big difference here between lto and what a debugger needs. I could see designing a debugger (and I have no idea if any such debuggers exist) that simply maps in the debug information and just uses the incore representation as is. Dwarf seems to have been designed to support this. (but then again I could be dreaming). With an intermediate form of a compiler, the usage is quite different. All that we are going to do is load a function, convert it gimple and then throw away (the notion of throw away may not have meaning for memory mapped files) the on disk version. The prime goal is that the format be designed so that an enitity (generally a function) can be expanded into gimple in one pass. Then the question of the benefit of using a compressor comes down to processor speed vs io speed. With the parts that you are in charge of, namely the types and the globals, this is not true. I can very easily see an implementation of the types and decls that is like I describe for the debugger, you map it into mem and just use if from there. But since the intermediate code for a function body is going to get very modified, and our existing gimple is chocked full of pointers, it is harder to envision ever winning at that the mapping game. > I guess my overriding concern is that we're focusing heavily on the > data format here (DWARF? Something else? Memory-mappable? What > compression scheme?) and we may not have enough data. I guess we just > have to pick something and run with it. I think we should try to keep > that code as as separate as possible so that we can recover easily if > whatever we pick turns out to be (another) bad choice. :-) > >> One of the comments that was made by a person on the dwarf committee is >> that the abbrev tables really can be used for compression. If you have >> information that is really common to a bunch of records, you can build >> an abbrev entry with the common info in it. > > Yes. I was a little bit surprised that you don't seem to have seen > much commonality. If you recorded most of the tree flags, and treated > them as DWARF attributes, I'd expect you would see relatively many > expressions of a fixed form. Like, there must be a lot of PLUS_EXPRs > with TREE_USED set on them. But, I gather that you're trying to avoid > recording some of these flags, hoping either that (a) they won't be > needed, or (b) you can recreate them when reading the file. I think > both (a) and (b) hold in many cases, so I think it's reasonable to > assume we're writing out very few attributes. > I had thought about that with the flags, and decided it was too much work/per gain. I decided to just compress the flags, so that only the flags that are used for a given tree node were written as a
mprec.h:297:1: warning: "_EXFUN" redefined
This is on a cygwin/winxp system... while building gcc trunk, currently, and for quite some time, I have been getting this warning: /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. -I../../../../../../gcc/libjava/classpath/native/fdlibm -I../../include -O2 -g -O2 -MT mprec.lo -MD -MP -MF .deps/mprec.Tpo -c ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c -o mprec.o In file included from ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:88: ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.h:297:1: warning: "_EXFUN" redefined In file included from /usr/include/assert.h:9, from ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:84: /usr/include/_ansi.h:36:1: warning: this is the location of the previous definition Now, is this something to be concerned about and if so, in which development forum would it be adressed? -- Cheers, /ChJ
mprec.c:104: error: static declaration of 'calloc' follows non-static declaration
again, on cygwin/winxp, I get an error ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:104: error: static declaration of 'calloc' follows non-static declaration am I doing something seriously wrong here? -- Cheers, /ChJ
mprec.c:105: error: expected identifier or '(' before '{' token
last one, again on cygwin/winxp, I get an error:
../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:105:
error: expected identifier or '(' before '{' token
hints?
--
Cheers,
/ChJ
Re: mprec.h:297:1: warning: "_EXFUN" redefined
Christian Joensson writes: > This is on a cygwin/winxp system... while building gcc trunk, > currently, and for quite some time, I have been getting this warning: > > /usr/local/src/trunk/objdir/./gcc/xgcc > -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ > -B/usr/local/i686-pc-cygwin/lib/ -isystem > /usr/local/i686-pc-cygwin/include -isystem > /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. > -I../../../../../../gcc/libjava/classpath/native/fdlibm > -I../../include -O2 -g -O2 -MT mprec.lo -MD -MP -MF .deps/mprec.Tpo -c > ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c -o > mprec.o > In file included from > ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:88: > ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.h:297:1: > warning: "_EXFUN" redefined > In file included from /usr/include/assert.h:9, > from > ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:84: > /usr/include/_ansi.h:36:1: warning: this is the location of the > previous definition > > Now, is this something to be concerned about and if so, in which > development forum would it be adressed? [EMAIL PROTECTED] I don't think it's terribly impoertant. Andrew.
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On 8/31/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Mark Mitchell wrote: > Kenneth Zadeck wrote: > >> Even if we decide that we are going to process all of the functions in >> one file at one time, we still have to have access to the functions that >> are going to be inlined into the function being compiled. Getting at >> those functions that are going to be inlined is where the double the i/o >> arguement comes from. > > I understand -- but it's natural to expect that those functions will > be clumped together. In a gigantic program, I expect there are going > to be clumps of tightly connected object files, with relatively few > connections between the clumps. So, you're likely to get good cache > behavior for any per-object-file specific data that you need to access. > I just do not know. I assume that you are right, that there is some clumping. But I am just no sure. I just want to point out that this argument (okay cache locality) was used as a reason the massive amount of open/seek/close behavior by Subversion's FSFS filesystem is "a-ok". It turns out not to be in practice, for a few reasons: First, the syscall overhead ends up being pretty bad. Probably not as bad in LTO as in Subversion (for obvious reasons), but you shouldn't discount it. Second, and more importantly, on a network file system, the open/seek/read calls to get at the cached data are going to be RPC calls. --Dan
Re: segmentation fault in building __floatdisf.o
hi,
Thanks for your explaination.I just figured out the
problem.actually a pattern named "bgtu" was generated by gcc and in
my backend ,i defined all branch patterns except bgtu.So when gcc
tried to match "bgtu" pattern ,it could not find it and generated
above mentioned error.Now i have defined that pattern and it is
compiling without any error.
It was by luck that i figured out that "bgtu" was missing.Would you
please tell me how can i figure out that gcc is trying to match which
pattern.Where in gcc code ,patterns are being matched to those in
backend files.
thanks,
shaz
On 8/30/06, Dave Korn <[EMAIL PROTECTED]> wrote:
On 30 August 2006 15:11, kernel coder wrote:
> hi,
> I'm having some problem during build up of libgcc2 in function
> __floatdisf(build up of __floatdisf.o).Actually i'm modifying mips
> backend.The error is
>
> ../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf':
> ../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error: Segmentation
> fault
This is always the first sign of a bug in your backend, as it's the first
bit of code that gets compiled for the target by the newly-compiled backend.
In this case, it's a really bad bug, because we're bombing out with a SEGV,
rather than getting a nice assert. This could be because of dereferencing a
null pointer.
> before crash following pattern is called
>
> (define_expand "cmp"
> [(set (cc0)
> (compare:CC (match_operand:GPR 0 "register_operand")
> (match_operand:GPR 1 "nonmemory_operand")))]
> ""
> {
> fprintf(stderr," cmp \n");
> branch_cmp[0] = operands[0];
> branch_cmp[1] = operands[1];
> debug_rtx(branch_cmp[0]);
> debug_rtx(branch_cmp[1]);
> DONE;
> })
> (subreg:SI (reg:DI 30) 4)
> (subreg:SI (reg:DI 25 [ u.0 ]) 4)
>
> after this i think it tries to mach some s bCOND pattern but in this
> case it fails .
>
> Is this my proposition correct?
Unlikely. You'd expect to see a proper ICE message with backtrace if recog
failed.
> In another working case where no error is being generated.Following is
> the sequence of called patterns
>
> (define_expand "cmp"
> [(set (cc0)
> (compare:CC (match_operand:GPR 0 "register_operand")
> (match_operand:GPR 1 "nonmemory_operand")))]
> ""
> {
> fprintf(stderr," cmp \n");
> cmp_operands[0] = operands[0];
> cmp_operands[1] = operands[1];
> debug_rtx(cmp_operands[0]);
> debug_rtx(cmp_operands[1]);
> DONE;
> })
> (subreg:SI (reg:DI 30) 0)
> (subreg:SI (reg:DI 25 [ u.0 ]) 0)
>
> Then the following pattern is matched
>
> (define_expand "bltu"
> [(set (pc)
> (if_then_else (ltu (cc0) (const_int 0))
> (label_ref (match_operand 0 ""))
> (pc)))]
> ""
> {
> fprintf(stderr,"\n branch_fp 8 bltu\n");
> })
> I've tried my best to track the problem but could not due my limited
> knowledge.Would you please give me some hint to debug the problem .
I suspect that what's going wrong is that, in the error case, one of the
'branch_cmp' or 'cmp_operands' arrays is getting set, but when the branch
pattern comes to be matched, it is the /other/ array that is used, which is
where the null pointer is coming from.
You've given no information about what you've actually changed, and I'm no
MIPS expert, but in my local copy of the gcc 4 sources there's no such thing
as 'branch_cmp', only 'cmp_operands', whereas in gcc series 3m, it's the other
way round
So I'm guessing that you've added a new variant of the cmp expander,
and you've based it on some old code from a series 3 version of the compiler,
and it's not good in series 4?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: regress and -m64
On Aug 30, 2006, at 9:55 PM, Jack Howarth wrote: Try building some of the g++ testcases manually and see what the errors are. Perhaps this is a problem: grep 'Symbol not found' g++.log | sort | uniq -c 1254 dyld: Symbol not found: ___dso_handle
Re: MyGCC and whole program static analysis
As some few people might already know, the GGCC (globalgcc) project is just starting (partly funded within the ITEA framework by french, spanish, swedish public money) - its kick off meeting is next week in Paris. GGCC aims to provide a (GPL opensource) extension to GCC for program wide static analysis (& optimisations) and coding rules validation. But this mail is not a formal announcement of it... I am also extremely interested in the LTO framework, in particular their persistence of GIMPLE trees. Could LTO people explain (if possible) if their framework is extensible (to some new Gimple nodes) and usable in some other setting (for example, storing program wide static analysis partial results, perhaps in a "project" related database or file). This is one of the goals of LTO. To steer this thread onto another topic, if you ever plan on getting your "globalgcc" changes back into gcc proper, I highly suggest you do your design and implementation discussions on gcc's mailing lists, and coordinate with GCC people who work in those areas. GCC itself is gearing up to start doing program wide analysis and optimization, and I guarantee you that if you guys go off and do it on your own in seclusion you will 1. duplicate work 2. make it incredibly hard to get your work back into gcc. Of course, if getting work into gcc is not a goal of globalgcc, than by all means, ...
Re: Inserting function calls
Any idea why ? I've looked around in the code to see how they parse the data dependance tree but I don't see a difference. Interesting. So what statements *are* in the list of data dependences if not these.
Re: regress and -m64
Brad, You build system certainly has issues. Why don't you strip down your .cshrc or .bashrc to a completely empty file, open a new terminal session so none of the previous .cshrc settings are in effect and rebuild gcc trunk. Also, I am assuming you are running MacOS X 10.4 and have at least Xcode 2.3. What do you get for.. ld64 -v on Xcode 2.3 I get... @(#)PROGRAM:ld64 PROJECT:ld64-47.2 DEVELOPER:root BUILT:May 4 2006 11:37:00 ...whereas on Xcode 2.4 I get... @(#)PROGRAM:ld64 PROJECT:ld64-59.2 DEVELOPER:root BUILT:Jul 1 2006 14:09:03 With fink's odcctools I get... @(#)PROGRAM:ld64 PROJECT:odcctools-590.42.1od14 ...which is the same cctools release number as the cctools in Xcode 2.3. http://www.opensource.apple.com/darwinsource/DevToolsMay2006/ Again, one advantage of using fink is that you have a far more controlled build environment and can alway find out what packages are install with 'dpkg -l' and what package a file belongs to with... dpkg -S /sw/lib/odcctools/bin/ld64 odcctools: /sw/lib/odcctools/bin/ld64 ...making it a lot easier to sanity check your build environment. Jack
Re: segmentation fault in building __floatdisf.o
"kernel coder" <[EMAIL PROTECTED]> writes: >Thanks for your explaination.I just figured out the > problem.actually a pattern named "bgtu" was generated by gcc and in > my backend ,i defined all branch patterns except bgtu.So when gcc > tried to match "bgtu" pattern ,it could not find it and generated > above mentioned error.Now i have defined that pattern and it is > compiling without any error. It should not have gotten a segmentation fault in that case. Something odd is still happening. > It was by luck that i figured out that "bgtu" was missing.Would you > please tell me how can i figure out that gcc is trying to match which > pattern.Where in gcc code ,patterns are being matched to those in > backend files. Matching RTL against the patterns defined in the MD file is done in the function recog. This is a generated function and can be found in insn-recog.c in your build directory. Looking at the function is unlikely to be helpful, but looking at calls to recog (there are lots of them) may help. Ian
Trans.: Re: Inserting function calls
Dear all,
Any idea why ? I've looked around in the code to see how they parse
the data dependance tree but I don't see a difference.
Interesting.
So what statements *are* in the list of data dependences if not these.
Ok apparently it's more a problem of optimization levels in O3 the
compiler does not seem to generate the calls but in O1 it does.
Here is the test case :
#include
int fct(int *t);
int main()
{
int tab[10];
int i;
printf("Hello World %d\n",tab[5]);
printf("Sum is : %d\n",fct(tab));
return 0;
}
int fct(int *t)
{
int i=9;
int res;
while(i>=0) {
if(t[i] Perform loop invariant motion on trees. This pass moves only
invariants that
would be hard to handle at RTL level (function calls, operations
that expand to
Index: tree-pass.h
===
--- tree-pass.h (revision 116373)
+++ tree-pass.h (working copy)
@@ -251,6 +251,7 @@
extern struct tree_opt_pass pass_record_bounds;
extern struct tree_opt_pass pass_if_conversion;
extern struct tree_opt_pass pass_vectorize;
+extern struct tree_opt_pass pass_load_inst;
extern struct tree_opt_pass pass_complete_unroll;
extern struct tree_opt_pass pass_loop_prefetch;
extern struct tree_opt_pass pass_iv_optimize;
Index: tree-load-inst.c
===
--- tree-load-inst.c(revision 0)
+++ tree-load-inst.c(revision 0)
@@ -0,0 +1,139 @@
+#include
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "tree.h"
+#include "flags.h"
+#include "rtl.h"
+#include "tm_p.h"
+#include "ggc.h"
+#include "langhooks.h"
+#include "hard-reg-set.h"
+#include "basic-block.h"
+#include "output.h"
+#include "expr.h"
+#include "function.h"
+#include "diagnostic.h"
+#include "bitmap.h"
+#include "pointer-set.h"
+#include "tree-flow.h"
+#include "tree-gimple.h"
+#include "tree-inline.h"
+#include "varray.h"
+#include "timevar.h"
+#include "hashtab.h"
+#include "tree-dump.h"
+#include "tree-pass.h"
+#include "toplev.h"
+#include "target.h"
+#include "cfgloop.h"
+#include "tree-chrec.h"
+#include "tree-data-ref.h"
+#include "tree-scalar-evolution.h"
+#include "lambda.h"
+#include "coverage.h"
+
+extern struct loops *current_loops;
+static void tree_handle_loop (struct loops *loops);
+
+
+static unsigned int tree_load_inst (void)
+{
+ fprintf (stderr, "My load instrumentation start %p\n",current_loops);
+
+ if (current_loops == NULL)
+{
+ fprintf (stderr,"No loop\n");
+ return 0;
+}
+
+ tree_handle_loop (current_loops);
+ return 0;
+}
+
+void tree_handle_loop (struct loops *loops)
+{
+ unsigned int i;
+ unsigned int j;
+ static int compteur_interne = 0;
+
+ for (i = 1; inum; i++)
+{
+ struct loop *loop_nest = loops->parray[i];
+
+ //If no loop_nest
+ if (!loop_nest)
+continue;
+
+ VEC (ddr_p, heap) *dependence_relations;
+ VEC (data_reference_p, heap) *datarefs;
+
+ datarefs = VEC_alloc (data_reference_p, heap, 10);
+ dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
+ compute_data_dependences_for_loop (loop_nest, true, &datarefs,
+ &dependence_relations);
+
+ tree call_type = build_function_type_list (void_type_node,
+ integer_type_node,
+ NULL_TREE);
+ tree call_fn = build_fn_decl ("__MarkovMainEntry",call_type);
+
+ data_reference_p a;
+ for (j = 0; VEC_iterate (data_reference_p, datarefs, j, a); j++)
+{
+ tree stmt = DR_STMT (a);
+
+ /* On fait nos test pour voir si c'est un load */
+ if (DR_IS_READ (a))
+{
+ printf ("Have a load : %d\n", compteur_interne);
+ tree compteur = build_int_cst (integer_type_node,
compteur_interne);
+ compteur_interne++;
+
+ /* Generation de l'instruction pour l'appel */
+ tree args = tree_cons(NULL_TREE,//build_tree_list
(NULL_TREE, compteur);
+compteur,
+NULL_TREE);
+
+ /* Je suppose que args est correctement mis en place */
+ tree call = build_function_call_expr (call_fn, args);
+
+ mark_new_vars_to_rename(call);
+ block_stmt_iterator bsi;
+ bsi = bsi_for_stmt (stmt);
+ bsi_insert_before (&bsi, call, BSI_SAME_STMT);
+
+}
+}
+ VEC_free (data_reference_p, heap, datarefs);
+ VEC_free (ddr_p, heap, dependence_relations);
+}
+
+ debug_loop_ir ();
+ fprintf (stderr,"My load instrumentation stop\n");
+}
+
+static bool gate_tree_load_inst (void)
+{
+ return flag_tree_load_inst;
+}
+
+
+struct tree_opt_pass pass_load_inst =
+ {
+"loadinst", /* name */
+gate_tree_load
Re: GCC testsuite timeout question (gcc.c-torture/compile/20001226-1.c)
On Tue, Aug 30, 2005 at 05:44:52PM -0700, Mike Stump wrote:
> On Aug 30, 2005, at 4:34 PM, Steve Ellcey wrote:
> >I see that it is timing out on a slow machine that I have. I tried
> >to look around to find out how and where the timeout limit was set
> >and could not find it.
[snip]
> M-x grep timeout *.exp from gcc and dejagnu yields:
>
> gcc:
> if [target_info exists gcc,timeout] {
> lappend options "timeout=[target_info gcc,timeout]"
> }
>
> dejagnu:
> if [board_info $dest exists testcase_timeout] {
> set testcase_timeout [board_info $dest testcase_timeout]
> } else {
> set testcase_timeout 300
> }
>
> if [info exists timeout] {
> verbose "Setting timeout to $timeout" 2
> set status [remote_exec host "$compiler $opts" "" "" ""
> $timeout]
>
> so, in .dejagnurc, or your site.exp, or in your boards files, or any
> place else (cmd line), you should be able to just set it.
Can you give me an actual example of this? I've tried all of the
following in ~/.dejagnurc without any effect:
set board_info(gcc,timeout) "5400"
set target_info(gcc,timeout) "5400"
set target_info(unix,timeout) "5400"
set board_info(unix,timeout) "5400"
set target_info(host,timeout) "5400"
set board_info(host,timeout) "5400"
set board_info("unix","gcc,timeout") "5400"
set board_info("host","gcc,timeout") "5400"
set target_info("unix","gcc,timeout") "5400"
set target_info("host","gcc,timeout") "5400"
set board_info(host,testcase_timeout) "5400"
set board_info(unix,testcase_timeout) "5400"
set target_info(host,testcase_timeout) "5400"
set target_info(unix,testcase_timeout) "5400"
set timeout 5400
set testcase_timeout 5400
In case it isn't obvious, I have little or no clue about tcl, expect and
dejagnu. The only time that I've had success in modifying the timeout was by
adding this to /usr/share/dejagnu/baseboards/unix.exp:
set_board_info gcc,timeout 5400
This only works for the gcc tests, and I'm assuming that s/gcc/g++/ would
make it work for the g++ tests, and so on. But I'd much prefer not to modify
any of DejaGnu's files or any of the files in my copy of the repository.
The question of how to raise the dejagnu timeout has been asked a few
times before over the years with no good answer, and given that it is likely
for people to run into this issue again, I'd like
http://gcc.gnu.org/install/test.html> to say a few words about this.
--
Rask Ingemann Lambertsen
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Daniel Berlin wrote: On 8/31/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Mark Mitchell wrote: > Kenneth Zadeck wrote: > >> Even if we decide that we are going to process all of the functions in >> one file at one time, we still have to have access to the functions that >> are going to be inlined into the function being compiled. Getting at >> those functions that are going to be inlined is where the double the i/o >> arguement comes from. > > I understand -- but it's natural to expect that those functions will > be clumped together. In a gigantic program, I expect there are going > to be clumps of tightly connected object files, with relatively few > connections between the clumps. So, you're likely to get good cache > behavior for any per-object-file specific data that you need to access. > I just do not know. I assume that you are right, that there is some clumping. But I am just no sure. I just want to point out that this argument (okay cache locality) was used as a reason the massive amount of open/seek/close behavior by Subversion's FSFS filesystem is "a-ok". Here, we won't be making syscalls -- but we will be taking page faults if we go out of cache. I don't know what the consequences of page faults for files backed over NFS are, but if your object files are coming over NFS, your linker isn't going to go too fast anyhow. I would expect most users carefully use local disk for object files. Since we're descending into increasingly general arguments, let me say it more generally: we're optimizing before we've fully profiled. Kenny had a very interesting datapoint: that abbreviation tables tended to be about the size of a function. That's great information. All I'm suggesting is that this data doesn't necessarily imply that enabling random access to functions (as we all agree is necessary) implies a 2x I/O cost. It's only a 2x I/O cost if every time you need to go look at a function the abbreviation table has been paged out. I think we've gotten extremely academic here. As far as I can tell, Kenny has decided not to use DWARF, and nobody's trying to argue that he should, so we should probably just move on. My purpose in raising a few counterpoints is just to make sure that we're not overlooking anything obvious in favor of DWARF; since Kenny's already got that code written, it would be nice if we had a good reason not to start over. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote: > Here, we won't be making syscalls Yes, you almost certainly will. If you've got a thousand object files, you probably don't want to keep them all opened all the time; there are these pesky things like open file descriptor limits, for instance, and you'll tend to degrade performance. -- Daniel Jacobowitz CodeSourcery
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Kenneth Zadeck wrote: I am not so concerned with running out of virtual address space than I am about being able to break this up so that it can be done in parallel, on a farm of machines. Otherwise, lto can never be part of anyone's compile/test loop. I think we just expanded the scope of work by an order of magnitude. :-) If you had just said that you wanted to support multi-threaded LTO, that would have been a big deal. But multiple machines with multiple address spaces trying to do LTO on one program is a really big deal. (Of course, there is a "cheap hack" way of doing what you want: run LTO on clumps of object files in parallel, and then just link the pre-optimized files together in the ordinary way.) I'd really like to see us inline a function before we even begin to have this conversation. :-) I have no idea how "stable" all the types and decls are over a compilation. I write my info pretty early, and I assume the types and decls are written pretty late in the compilation (otherwise you would not have address expressions for the debugger). If there has been any "processing" on these between when I write my stuff and when the types and decls get written, things may not match up. I don't think that this is an issue. The important information about types and declaration is stable. Things like "is this declaration used?" change over the course of the compilation, but that's not useful for DWARF anyhow -- and, in general, we don't write out information about types/declarations that are entirely unused. The key aspects (sizes/layouts/etc.) are fixed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Help running a SPARC/Ada test case?
Is there anyone out there who might have a SPARC environment with Ada
support who could run the attached Ada testcase on a version of gcc
patched with the attached patch? I'd like to verify whether the test
behaves correctly when compiled at -O0, -O1, and -O2. The expected
(correct) behavior is the following output:
a_value= 10 b_value= 20
Some context of what I'm trying to accomplish can be seen by looking at
the thread starting here:
http://gcc.gnu.org/ml/gcc/2006-08/msg00389.html
My utmost gratitude to anyone who can help!
- Josh
Index: gcc/calls.c
===
--- gcc/calls.c (revision 116236)
+++ gcc/calls.c (working copy)
@@ -1985,9 +1985,8 @@
/* For variable-sized objects, we must be called with a target
specified. If we were to allocate space on the stack here,
we would have no way of knowing when to free it. */
- rtx d = assign_temp (TREE_TYPE (exp), 1, 1, 1);
+ rtx d = assign_temp (TREE_TYPE (exp), 0, 1, 1);
- mark_temp_addr_taken (d);
structure_value_addr = XEXP (d, 0);
target = 0;
}
with Ada.Text_Io;
procedure Test_Func is
type A_Int is new Integer range 1..10;
type B_Int is new Integer range 11..20;
type A_Array is array(1..5) of A_Int;
type B_Array is array(1..5) of B_Int;
procedure Print_Values (A_Value : in A_Int;
B_Value : in B_Int) is
begin
Ada.Text_Io.Put_Line("a_value=" & Integer'Image(Integer(A_Value)) &
" b_value=" & Integer'Image(Integer(B_Value)));
end Print_Values;
function Get_A return A_Array is
A : A_Array := (others => 10);
begin
return A;
end Get_A;
function Get_B return B_Array is
B : B_Array := (others => 20);
begin
return B;
end Get_B;
J : Natural := 3;
begin
Print_Values
(A_Value =>Get_A(J), B_Value =>Get_B(J));
end Test_Func;
Re: Inserting function calls
Hello,
> >what you do seems basically OK to me. The problem is that you also need
> >to fix the ssa form for the virtual operands of the added calls
> >(i.e., you must call mark_new_vars_to_rename for each of the calls,
> >and update_ssa once at the end of tree_handle_loop).
> >
> >Zdenek
> >
>
> Ok, by inserting the mark_new_vars_to_rename and the TODO_update_ssa
> flag in the associated struct tree_opt_pass.
>
> This works (yeah!) and I can link my call before loads but it seems to
> miss some...
>
> To pass through the statements I use :
>
> datarefs = VEC_alloc (data_reference_p, heap, 10);
> dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
> compute_data_dependences_for_loop (loop_nest, true, &datarefs,
> &dependence_relations);
>
> for (j = 0; VEC_iterate (data_reference_p, datarefs, j, a); j++)
> {
> tree stmt = DR_STMT (a);
>
> /* See if it is a load */
> if (DR_IS_READ (a))
>
> However if in my test code I have this :
>
> for(i=0;i<10;i++)
> for(j=i+1;j<10;j++)
> {
> a = t[j];
> b = t[i-1];
>
> //Calculations with a and b...
>}
>
>
> I get am able to insert before the first load but the second doesn't
> seem captured, this is what I get from debug_loop_ir :
>
> __MarkovMainEntry (2);
> # VUSE ;
> a_12 = *D.2174_11;
> # VUSE ;
> b_18 = *D.2179_17;
>
> Any idea why ? I've looked around in the code to see how they parse
> the data dependance tree but I don't see a difference.
is there the data reference for it in the datarefs array?
Zdenek
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Mark Mitchell wrote: > Kenneth Zadeck wrote: > >> I am not so concerned with running out of virtual address space than I >> am about being able to break this up so that it can be done in parallel, >> on a farm of machines. Otherwise, lto can never be part of anyone's >> compile/test loop. > > I think we just expanded the scope of work by an order of magnitude. :-) > > If you had just said that you wanted to support multi-threaded LTO, > that would have been a big deal. But multiple machines with multiple > address spaces trying to do LTO on one program is a really big deal. > (Of course, there is a "cheap hack" way of doing what you want: run > LTO on clumps of object files in parallel, and then just link the > pre-optimized files together in the ordinary way.) > > I'd really like to see us inline a function before we even begin to > have this conversation. :-) I have no intention in expanding the scope of the work. I just am not going to do anything that precludes doing this. As long as the function bodies are in a form that can be easily accessed without reading and processing the entire file, I am fine. > >> I have no idea how "stable" all the types and decls are over a >> compilation. I write my info pretty early, and I assume the types and >> decls are written pretty late in the compilation (otherwise you would >> not have address expressions for the debugger). If there has been any >> "processing" on these between when I write my stuff and when the types >> and decls get written, things may not match up. > > I don't think that this is an issue. The important information about > types and declaration is stable. Things like "is this declaration > used?" change over the course of the compilation, but that's not > useful for DWARF anyhow -- and, in general, we don't write out > information about types/declarations that are entirely unused. The > key aspects (sizes/layouts/etc.) are fixed. > You are either right, or we will fix it. Those are the only two options. My only point was that there is a lot of compiler in between where someone could have done something silly.
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Daniel Jacobowitz wrote: On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote: Here, we won't be making syscalls Yes, you almost certainly will. OK, good point. In any case, my concern is that we're worrying a lot about on-disk encoding, but that there are lots of other hard problems we have to solve before we can make this work -- even independent of resource constraints. So, I suggest we choose an encoding that seems approximately reasonable, but not worry too much about exactly how optimal it is. I think that boils down to: Kenny, I think you should do what you think best, but without working too terribly hard. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: regress and -m64
Brad, If you google "dyld: Symbol not found: ___dso_handle", you'll come up with the following messages... http://gcc.gnu.org/ml/gcc/2006-03/msg00712.html http://gcc.gnu.org/ml/gcc/2006-03/msg00718.html http://gcc.gnu.org/ml/gcc/2006-03/msg00735.html So it certainly sounds like your cctools is stale. Note that the issue with the __Unwind_GetIPInfo will likely still exist but you will only run into if you set the MACOSX_DEPLOYMENT_TARGET. A generic build or one without building java won't show the issue on gcc trunk. Jack
Re: Inserting function calls
is there the data reference for it in the datarefs array?
Zdenek
Using this code after the construction of the data dependance :
datarefs = VEC_alloc (data_reference_p, heap, 10);
dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
compute_data_dependences_for_loop (loop_nest, true, &datarefs,
&dependence_relations);
static int cnt = 0;
char s[128];
sprintf(s,"output%d",cnt++);
FILE *f = fopen(s,"w");
dump_data_references(f,datarefs);
fclose(f);
With this program :
#include
int fct(int *t);
int main()
{
int tab[10];
int i;
printf("Hello World %d\n",tab[5]);
printf("Sum is : %d\n",fct(tab));
return 0;
}
int fct(int *t)
{
int i=9;
int res=0;
int j,a,b;
for(i=0;i<10;i++)
for(j=i+1;j<10;j++)
{
a = t[j];
b = t[i-1];
res += b - a;
}
return res;
}
I got :
For the main :
(Data Ref:
stmt:
ref:
base_object:
)
For fct :
(Data Ref:
stmt: a_16 = *D.2144_15;
ref: *D.2144_15;
base_object:
Access function 0: {0B, +, 1B}_2
)
Jc
-
Degskalle There is no point in arguing with an idiot, they will just
drag you down to their level and beat you with experience
Référence: http://www.bash.org/?latest
-
Re: Inserting function calls
Hello,
> >is there the data reference for it in the datarefs array?
> >
> >Zdenek
> >
>
> Using this code after the construction of the data dependance :
>
>
> datarefs = VEC_alloc (data_reference_p, heap, 10);
> dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
> compute_data_dependences_for_loop (loop_nest, true, &datarefs,
> &dependence_relations);
>
> static int cnt = 0;
> char s[128];
> sprintf(s,"output%d",cnt++);
> FILE *f = fopen(s,"w");
> dump_data_references(f,datarefs);
> fclose(f);
>
> With this program :
>
> #include
>
> int fct(int *t);
>
> int main()
> {
> int tab[10];
> int i;
>
> printf("Hello World %d\n",tab[5]);
>
> printf("Sum is : %d\n",fct(tab));
>
> return 0;
> }
>
> int fct(int *t)
> {
> int i=9;
> int res=0;
> int j,a,b;
>
>
> for(i=0;i<10;i++)
>for(j=i+1;j<10;j++)
> {
> a = t[j];
> b = t[i-1];
> res += b - a;
> }
> return res;
> }
>
>
> I got :
>
>
> For the main :
>
> (Data Ref:
> stmt:
> ref:
> base_object:
> )
>
> For fct :
>
> (Data Ref:
> stmt: a_16 = *D.2144_15;
> ref: *D.2144_15;
> base_object:
> Access function 0: {0B, +, 1B}_2
> )
one possibility is that the t[i-1] load got moved out of the loop by
PRE; could you check that the load is still present in the loop?
Zdenek
regress changes?
Geoff, What happened to regress to allow it to suddenly do make checks at every svn revision? I assume it isn't a measly G4 anymore (grin). If you have that many clock cycles to do builds and make checks every revision how about adding in -m64 make checks now? Jack
gets is not too dangerous
Hello: We are students of computer sciences in the Santa Maria University, Chile. We just want to know if the function "gets" it's too dangerous for a warning. The fact is that our teacher's assistant give us a homework, and one restriction was to use gcc to compile our code, without warnings. We ask you for a simple explanation (if it's possible) about our warning, telling that "gets" is not too dangerous, because in our case, works perfectly, under some restrictions obviously. Please send us a notification for our teacher's assistant, and that way don't have a discount in our qualification. Thankfully Francisco Gutierrez J & Miguel Champin C. Students of enginieering in computer sciences. UTFSM (www.utfsm.cl)
Re: gets is not too dangerous
> > Hello: > > We are students of computer sciences in the Santa Maria University, > Chile. We just want to know if the function "gets" it's too dangerous > for a warning. The fact is that our teacher's assistant give us a > homework, and one restriction was to use gcc to compile our code, > without warnings. > We ask you for a simple explanation (if it's possible) about our > warning, telling that "gets" is not too dangerous, because in our case, > works perfectly, under some restrictions obviously. the gets warning is not from GCC but from the linker because glibc says to warn about it. -- Pinski
Re: gets is not too dangerous
On Thu, Aug 31, 2006 at 05:52:16PM -0400, Miguel Angel Champin Catalan wrote: > We ask you for a simple explanation (if it's possible) about our > warning, telling that "gets" is not too dangerous, because in our case, > works perfectly, under some restrictions obviously. Really a gcc-help topic but ... Google for "never use gets". It most emphatically is too dangerous.
Re: Potential fix for rdar://4658012
Sorry I didn't reply to this earlier. I was unexpectedly in a place with very bad network access. > The one exception to this is if the address of the temp is taken before > I call pop_temp_slots. In that instance, even though I may be "done" > with the temp, it needs to live until the end of the high-level-language > scope, and so it is marked with addr_taken and is pushed up in the temp > scopes using preserve_temp_slots. It is this logic that is used for > function calls that return a value on the stack. Right. > > However, in the case where we're passing the address of a temp slot to a > function, it doesn't make sense to me that this is the same as other > "address-of" operations on a stack slot. The function call (at least in > C and C++) cannot preserve this address, and it is reasonable to say > that attempts to access this address after the caller is done with the > location, are invalid. Here's where I disagree. The issue isn't what the front-ends (and especially not a *subset* of the front-ends) do, but what they *are allowed* to do. Going back to 3.4 for a moment, the question is whether you could create a valid tree where the address would survive. And I think you can. All it would take is a machine like Sparc that passes all aggregates by reference is to have a CALL_EXPR with two operands that are each CALL_EXPRs of aggregate types. We never had a precise specification of what trees were valid then (which is precisely the set of valid GENERIC, and hence is similarly not very precisely defined), but I think almost everybody working on the 3.4 compiler would say that the above is valid whether or not C or C++ could generate it. Therefore, the middle-end had to properly support it. However, in GCC 4, with tree-ssa, the RTL expanders receive a much smaller subset of trees, namely those defined in GIMPLE. I *believe*, but aren't sure, that the above is not valid GIMPLE. That would make the change safe. But: (1) The code we generate is pretty inefficient in the current case, since we copy the entire aggregate. If we try to fix that, we *will* be preserving the address for later, though perhaps in a temporary more properly allocated. (2) I suspect that we can rip out much more of this code than just this line and I'd prefer to do it that way. > Hopefully this is enough of an explanation to reveal whether my > understanding is consistent or inconsistent with the experts, and can > move the discussion forward. As I said once before, this code didn't change between 3.4 and 4.x, so something else is the cause of the regression. I'd like to understand what that was. I think you posted the changes you propose for the C and C++ front ends, but I don't remember what they were.
gcc-4.0-20060831 is now available
Snapshot gcc-4.0-20060831 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060831/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 116608 You'll find: gcc-4.0-20060831.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060831.tar.bz2 C front end and core compiler gcc-ada-4.0-20060831.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060831.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060831.tar.bz2 C++ front end and runtime gcc-java-4.0-20060831.tar.bz2 Java front end and runtime gcc-objc-4.0-20060831.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060831.tar.bz2The GCC testsuite Diffs from 4.0-20060824 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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.
Linker for OOP
I found this description in GCC Internals info file. 11.7 Constant Expression Types == ... `(const:M EXP)' Represents a constant that is the result of an assembly-time arithmetic computation. The operand, EXP, is an expression that contains only constants (`const_int', `symbol_ref' and `label_ref' expressions) combined with `plus' and `minus'. However, not all combinations are valid, since the assembler cannot do arbitrary arithmetic on relocatable symbols. M should be `Pmode'. Are there any plan to implement this facility as an extension to object file format? I don't know the fact but I suppose why linker was originally invented was to promise user to recompile only modified .c files, and this principal was broken with object oriented programming. I think with this facility, simple OO language will be much cleaner than the current, because the offset of member variables or method table are resolved in link phase. Please comment. --- Mikiya Matsuzaka
Re: Linker for OOP
On Fri, Sep 01, 2006 at 07:42:08AM +0900, Mikiya Matsuzaka wrote: >`(const:M EXP)' > Represents a constant that is the result of an assembly-time > arithmetic computation. The operand, EXP, is an expression that > contains only constants (`const_int', `symbol_ref' and `label_ref' > expressions) combined with `plus' and `minus'. However, not all > combinations are valid, since the assembler cannot do arbitrary > arithmetic on relocatable symbols. > > M should be `Pmode'. > > > Are there any plan to implement this facility as an extension to > object file format? > > I don't know the fact but I suppose why linker was originally > invented was to promise user to recompile only modified .c files, > and this principal was broken with object oriented programming. If you are proposing extensions to object file formats or the linker, you're on the wrong list. Try the binutils list.
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
mathieu lacage wrote: I have spent a considerable amount of time looking at the abbrev tables output by gcc are not totally random: their entries are sorted by their abbrev code. That is, the abbrev code of entry i+1 is higher than that of entry i. That's an interesting observation. Essentially, you've shown that by storing lg(n) information, you can cut the cost to find an entry in an abbreviation table of size n to a constant. Since, for LTO, we certainly can depend on the .o file being produced by GCC, we could depend on this behavior, even though it's not mandated by the DWARF standard. I think this is probably moot, since I believe that Kenny feels DWARF is not suitable for reasons other than the abbreviation table issue, but this is a clever technique. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
SPEC CPU 2006 and gcc
Has anyone tried SPEC CPU 2006 with gcc mainline and 4.1 branch? Currently, there is at least one regression affecting SPEC CPU 2006: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908 I was wondering if anyone had run into problems with gcc. I need 3 patches for SPEC CPU 2006 to support gcc on Linux: 1. Add -fPIC to bzip2 for shared library. Link time issue. 2. Fix perlbench for gcc on ia64. Run time issue. 3. Initialize stack pointers in tonto. Run time issue. H.J.
