Re: Bootstrap broken on ppc-darwin
On Jul 15, 2006, at 11:54 PM, Eric Botcazou wrote: /tmp/ccK4i3re.s:5107:FATAL:Symbol LFBB43 already defined. Same breakage on SPARC/Solaris 2.[56] and Alpha/Tru64. More information about this breakage. The symbol is defined for std::ostrstream::~ostrstream() and the virtual trunk to that function. I am trying to reduce a testcase right now. Thanks, Andrew Pinski
Re: Bootstrap broken on ppc-darwin
On Jul 16, 2006, at 4:16 PM, Andrew Pinski wrote:
I am trying to reduce a testcase right now.
And here is a reduced testcase:
struct basic_ios
{
virtual ~basic_ios() { }
};
class istrstream
: virtual public basic_ios
{
virtual ~istrstream();
};
istrstream::~istrstream() { }
-- Pinski
Re: -mno-80387 and MMX autovectorisation
On Thu, Jun 08, 2006 at 08:50:13AM -0700, Andrew Pinski wrote: > > On Jun 7, 2006, at 11:13 PM, Uros Bizjak wrote: > > >Hello! > > > >Current mainline gcc can efficiently disable x87 instruction when > >-mno-80387 switch is used. In this case, MMX registers can be used for > >the autovectorisation even without emms or femms instructions to > >switch back to x87 mode. > > I don't think so, because another function could use x87 instructions > even without you knowing it. But it would not be difficult to check regs_ever_live[] and emit the (f)emms instruction in the epilogue if an MMX register was ever used. -- Rask Ingemann Lambertsen
Re: Bootstrap broken on ppc-darwin
On Jul 16, 2006, at 5:19 PM, Andrew Pinski wrote:
And here is a reduced testcase:
struct basic_ios
{
virtual ~basic_ios() { }
};
class istrstream
: virtual public basic_ios
{
virtual ~istrstream();
};
istrstream::~istrstream() { }
Debugging shows this was definitely caused by the stabs changes:
Breakpoint 5, dbxout_begin_prologue (lineno=7, filename=0xbb4b
"t.cc") at ../../gcc/dbxout.c:1246
1246 if (use_gnu_debug_info_extensions
(gdb) p scope_labelno
$2 = 1
(gdb) continue
Continuing.
Breakpoint 5, dbxout_begin_prologue (lineno=10, filename=0xbb4b
"t.cc") at ../../gcc/dbxout.c:1246
1246 if (use_gnu_debug_info_extensions
(gdb) p scope_labelno
$3 = 1
Here we have the same scope_labelno. The first dbxout_begin_prologue
comes from calling rs6000_output_mi_thunk. The normal way
scope_labelno gets incremented is via the
call to debug_hooks->function_decl in rest_of_handle_final which is
not done for thunks.
I don't know if we should call debug_hooks->function_decl for thunks
or not.
Thanks,
Andrew Pinski
where is the gcc wiki?
Clicking on the Wiki link of the gcc home page, I get: Not Found The requested URL /wiki was not found on this server. Apache/2.0.52 (Red Hat) Server at gcc.gnu.org Port 80
Re: where is the gcc wiki?
On Jul 17, 2006, at 12:17 AM, Joern RENNECKE wrote: Clicking on the Wiki link of the gcc home page, I get: Did you not read Daniel's email: http://gcc.gnu.org/ml/gcc/2006-07/msg00227.html -- Pinski
Re: where is the gcc wiki?
http://gcc.gnu.org/ml/gcc/2006-07/msg00227.html ? Paolo.
Re: where is the gcc wiki?
Andrew Pinski wrote: On Jul 17, 2006, at 12:17 AM, Joern RENNECKE wrote: Clicking on the Wiki link of the gcc home page, I get: Did you not read Daniel's email: http://gcc.gnu.org/ml/gcc/2006-07/msg00227.html Oops, I wasn't aware this was still on-going and affects simple read access too. Unfortunately, the wayback machine is no help, since it got a 'spambot detected' page. Could a read-only copy of the old wiki pages be made available?
Re: A correction: Different invariants about the contents of static links]
"Rodney M. Bates" <[EMAIL PROTECTED]> writes: > OK, Thanks for the information. Just in case, does anybody already > have it in their head roughly where in gcc code this decision is made? tree-nested.c Ian
Re: Question of the LOG_LINKS field
"Ling-hua Tseng" <[EMAIL PROTECTED]> writes: > The algorithm is highly dependent on the information of LOG_LINKS(insn). > But I found that there are not any dependecy info for `reload instructions' > because the register allocation pass and reloading pass are peformed after > the first insn scheduling pass. Right. The LOG_LINKS field is not reliable after reload. > Should I write a violent algorithm to scan these data dependencies? Yes. > Are there any better solutions for this problem? At present, there is not. mips_avoid_hazard in config/mips/mips.c is an example of how the MIPS backend addresses a similar issue. Note the use of DELAYED_REG. Ian
ld -shared -Bsymbolic and C++ shared library
ld -shared -Bsymbolic will reduce number of dynamic relocations in a shared library. Unfortunately, it won't work correctly with C++ exception and maybe other language features. However, I think it is possible to make -shared -Bsymbolic to work for C++ by providing a way to specify a list of symbols which must be dynamic. We then can do # g++ -Wl,-Bsymbolic -shared -xxx "list of dynamic symbols" -o libfoo.so ... and libfoo.so written in C++ will work correctly with much fewer dynamic relocations. H.J.
local data flow
I 've been looking at the problem of converting the struct-equiv code to use DEF-USE chains instead of global dataflow information, but I have hit a snag. We can find local registers as being registers that are defined somewhere in the examined (partial) block, and have all their uses within the (partial) block. However, there is no feasible way to find dying inputs with def-use / use-def chains. We could find the definition with use-def chains, and examine all the uses of this definition with def-use chains, but we can't easily tell if a use could be reached through the examined (partial) block. And this is really not an isolated problem. Generally, when we examine REG_DEAD notes, there is no equivalent information to be found in def-use chains. The problem is that we are not really interested in what uses can be reached from the definition, but which can be reached from the use we are examining. I.e. we'd like a list of uses of the same register after the current use. In fact, we don't need an exhaustive list. It is sufficient if we have a set of uses such that any use which is reachable from the current use is dominated by one of the uses in the set (a minimal set is desirable, but not necessary). With these sets in place, we could also restrict the def-use information to such a set. When we add back pointers to each link, these data structures should be reasonably easy to keep sufficiently up-to-date to remain usable, i.e. such that every dependency is represented, and that there are no dangling pointers.
g77 problem for octave
Dear Sir/Madame, I have switched my OS to SuSE Linux 10.1 and for a while trying to install "Octave" to my computer. Unfortunately, the error message below is the only thing that i got. Installing octave-2.1.64-3.i586[Local packages] There are no installable providers of gcc-g77 for octave-2.1.64-3.i586[Local packages] On my computer, the installed version of gcc is 4.1.0-25 and i could not find any compatible version of g77 to install. For the installation of octave, i need exactly gcc-g77 not gcc-fortran. Can you please help me to deal with this problem? Thanks in advance, Tolga Yapici
Re: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?
In http://gcc.gnu.org/ml/gcc/2006-07/msg00362.html, you wrote: Are there any ideas on how and where to add a target and language independent code compaction pass into gcc? I think first you should be more specific about what you are trying to do. DO you only want to match essentially identical functions? I suppose that shouldn't be that hard to do, you can compare the gimple trees after / instead of inlining, while keeping a translation table for variable names. But would that be worth while? Have you studied any code base to determin how much of a code size saving you could expect?
Re: local data flow
Joern RENNECKE wrote: > I 've been looking at the problem of converting the struct-equiv code > to use DEF-USE chains > instead of global dataflow information, but I have hit a snag. > We can find local registers as being registers that are defined > somewhere in the examined (partial) block, > and have all their uses within the (partial) block. However, there is > no feasible way to find dying inputs > with def-use / use-def chains. We could find the definition with > use-def chains, and examine all the uses > of this definition with def-use chains, but we can't easily tell if a > use could be reached through the examined > (partial) block. > > And this is really not an isolated problem. Generally, when we > examine REG_DEAD notes, there is no > equivalent information to be found in def-use chains. The problem is > that we are not really interested > in what uses can be reached from the definition, but which can be > reached from the use we are examining. > I.e. we'd like a list of uses of the same register after the current > use. In fact, we don't need an exhaustive list. > It is sufficient if we have a set of uses such that any use which is > reachable from the current use is dominated > by one of the uses in the set (a minimal set is desirable, but not > necessary). With these sets in place, we could > also restrict the def-use information to such a set. When we add back > pointers to each link, these data structures > should be reasonably easy to keep sufficiently up-to-date to remain > usable, i.e. such that every dependency is > represented, and that there are no dangling pointers. you can have def-use chains, you can have use-def chains or you can have both. It seems like what you are asking for are use-def chains, i.e. the list of defs that can reach each use. If the set is empty, this is equiv to a reg-dead note. kenny
Re: where is the gcc wiki?
Paolo Carlini wrote: > http://gcc.gnu.org/ml/gcc/2006-07/msg00227.html > > ? > > Paolo. The new wiki is actually up, i'm just slowing editing the pages that were really badly converted. I'll move it back on monday, and let everyone else at the rest of them :) it's http://gcc.gnu.org/testwiki for now
Re: where is the gcc wiki?
Joern RENNECKE wrote: Clicking on the Wiki link of the gcc home page, I get: Not Found The requested URL /wiki was not found on this server. Apache/2.0.52 (Red Hat) Server at gcc.gnu.org Port 80 Daniel is working on it. He disabled it Friday.
Re: local data flow
Kenneth Zadeck wrote: you can have def-use chains, you can have use-def chains or you can have both. It seems like what you are asking for are use-def chains, No, I want to know if there exists a path from the current *use* of a register to some other *use* of the same register without going through a def. i.e. the list of defs that can reach each use. If the set is empty, this is equiv to a reg-dead note. Huh? If the set is empty, the use is either uninitialized or unreachable.
Are 8-byte ints guaranteed?
Hello world, are there any platforms where gcc doesn't support 8-byte ints? Can a front end depend on this? This would make life easier for Fortran, for example, because we could use INTEGER(KIND=8) for a lot of interfaces without having to bother with checks for the presence of KIND=8 integers. Regards Thomas
Re: local data flow
Joern RENNECKE wrote: > Kenneth Zadeck wrote: > >> >> >> you can have def-use chains, you can have use-def chains or you can have >> both. >> It seems like what you are asking for are use-def chains, >> > No, I want to know if there exists a path from the current *use* of a > register to > some other *use* of the same register without going through a def. > The right way to do this is not to build chains but to define your own dataflow problem to do this. I think that what you want is something like the reaching uses problem but you want a forwards version of this rather than a backwards version as is defined in df-problems.c. However, you may find that that problem does provide the info you are looking for. If this is what you want, I can help you define it. >> i.e. the list >> of defs that can reach each use. If the set is empty, this is equiv to >> a reg-dead note. >> >> > Huh? If the set is empty, the use is either uninitialized or > unreachable. yes, I am sorry
Re: local data flow
Kenneth Zadeck wrote: The right way to do this is not to build chains but to define your own dataflow problem to do this. But wouldn't I need to update the problem solution every time a change a bit of the program - which would be much more costly then doing a local update of some local def-firstuse or use-nextuse chains? I think that what you want is something like the reaching uses problem but you want a forwards version of this rather than a backwards version as is defined in df-problems.c. It is reaching uses, but the starting point is not necessarily a definition, but is more often a use. I want to know about uses that are forward of the current site in the control flow, but I suppose this is best computed with a backward propagation of lifeness data. AFAICT that's the same direction that the current reaching use problem has.
Re: Are 8-byte ints guaranteed?
are there any platforms where gcc doesn't support 8-byte ints? Can a front end depend on this? The rtl expander can open-code long long using a datatype with half the size if no patterns are defined in the md file. There are some processors where code using all long long operations would not fit into the addressable program memory, but you probably wouldn't want fortran for these anyway. More serious is the matter of having exactly 8 bytes. long long is docuemnted to be at least 64 bits, but there is no guarantee that it is exactly 64 bits. E.g. if the target is word-addressed with 36 bit units, you'll get a 72 bit long long (2 units). Currently, only the c4x has a BITS_PER_UNIT other than 8, and even the c4x definition is a reltively harmless 32, but there is no guarantee that gcc won't aquire again some more interesting definitions. Also, right now on the c4x, you have to watch out not to confuse a byte with an addressable unit.
Re: Are 8-byte ints guaranteed?
Thomas Koenig wrote: Hello world, are there any platforms where gcc doesn't support 8-byte ints? Can a front end depend on this? This would make life easier for Fortran, for example, because we could use INTEGER(KIND=8) for a lot of interfaces without having to bother with checks for the presence of KIND=8 integers. No doubt, there are such platforms, although I doubt there is sufficient interest in running gfortran on them. Support for 64-bit integers on common 32-bit platforms is rather inefficient, when it is done by pairs of 32-bit integers.
Re: g77 problem for octave
[EMAIL PROTECTED] wrote: Dear Sir/Madame, I have switched my OS to SuSE Linux 10.1 and for a while trying to install "Octave" to my computer. Unfortunately, the error message below is the only thing that i got. Installing octave-2.1.64-3.i586[Local packages] There are no installable providers of gcc-g77 for octave-2.1.64-3.i586[Local packages] On my computer, the installed version of gcc is 4.1.0-25 and i could not find any compatible version of g77 to install. For the installation of octave, i need exactly gcc-g77 not gcc-fortran. Can you please help me to deal with this problem? If you are so interested in using g77 rather than gfortran, it should be easy enough to grab gcc-3.4.x sources and build g77. One would wonder why you dislike gfortran so much.
Re: g77 problem for octave
On 7/16/06, Tim Prince <[EMAIL PROTECTED]> wrote: > On my computer, the installed version of gcc is 4.1.0-25 and i could not > find any compatible version of g77 to install. For the installation of > octave, i need exactly gcc-g77 not gcc-fortran. (...) If you are so interested in using g77 rather than gfortran, it should be easy enough to grab gcc-3.4.x sources and build g77. One would wonder why you dislike gfortran so much. I don't think he dislikes gfortran so much, he just needs _that_ specific version of the package to install octave, I guess. That would be a SuSE packaging problem, so I'm CC:'ing matz. Gr. Steven
Re: local data flow
Joern RENNECKE wrote: > Kenneth Zadeck wrote: > >> >> >> The right way to do this is not to build chains but to define your own >> dataflow problem to do this. >> > But wouldn't I need to update the problem solution every time a change > a bit of the > program - which would be much more costly then doing a local update of > some > local def-firstuse or use-nextuse chains? > depending on what you are doing, you can update the solution in place. The point of the dataflow talk was not to say that you cannot do anything incremental, it was to say that there are no good GENERAL techniques. Many times it is possible to update the solution precisely if you have a very good understanding of the local conditions under which the transformation is done on. The other trick it to do what I do in the new fast dce or the if-cvt on the dataflow branch: order the basic blocks so that it does not matter if you mess up the solution. Generally a post order or a reverse postorder traversial of the basic blocks will have the property that you can just mess things up in a wave that moves from the beginning to the end or the end to the end of the program without ever seeing the mess you make. The only time you need to iterate is if you mess things up a the top of a block that is the destination of the back edge. This is a very useful trick in a compiler. The cfg is your friend. >> I think that what you want is something like the reaching uses problem >> but you want a forwards version of this rather than a backwards version >> as is defined in df-problems.c. >> >> > It is reaching uses, but the starting point is not necessarily a > definition, but is more > often a use. I want to know about uses that are forward of the > current site in the > control flow, but I suppose this is best computed with a backward > propagation of > lifeness data. AFAICT that's the same direction that the current > reaching use problem > has. > the gen set of the reaching uses problem is the set of uses. the kill set are the defs and the clobbers. This is why the problem is called "reaching uses".
Re: Bootstrap broken on ppc-darwin
Andrew Pinski <[EMAIL PROTECTED]> writes: > Here we have the same scope_labelno. The first dbxout_begin_prologue > comes from calling rs6000_output_mi_thunk. The normal way > scope_labelno gets incremented is via the > call to debug_hooks->function_decl in rest_of_handle_final which is > not done for thunks. > I don't know if we should call debug_hooks->function_decl for thunks > or not. We shouldn't. It doesn't make sense, since there is no proper current_function_decl for a thunk. Previously, scope_labelno was referenced in dbxout_block and incremented in dbxout_function_end. Both functions are called only by dbxout_function_decl (a debug hook). So it was always consistent. Now scope_labelno is used by dbxout_begin_prologue and dbxout_source_line. Those are both debug hooks themselves. So this patch has introduced a dependency which was not previously there, which has led to a bug. There are several ways to fix this, of course. I think the simplest is going to be to always preincrement scope_labelno in dbxout_begin_prologue, rather than postincrementing it in dbxout_function_end. In cases where that fails, we are already in trouble. Note that scope_labelno is now used for two different things: for the LFBB symbol, and for the Lscope symbol. It does not have to be used for both, although as far as I can see it does no harm. Ian
Re: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?
Miguel Angel wrote:
> Hello!
>
> I have a VERY simple example:
> int f1 (int i) {i = (i-7)/9+3; return i;}
> int f2 (int i) {i = (i-7)/9+3; return i;}
>
> It could be reduced to:
> int f1 (int i) {i = (i-7)/9+3; return i;}
> int f2 (int i) {return f1 (i);}
>
>
> Are there any ideas on how and where to add a target and language
> independent code compaction pass into gcc?
Some people call this "uninlining". I've also heard the term
"procedural abstraction". The generalization is to identify common code
fragments that can be turned into functions. Then, replace the users of
the common code with function calls.
If we wanted to do this in GCC, it might well make sense to do this at
the same place we presently do inlining. Some toolchains do it in the
linker, at the level of assembly code.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: [lto] factor code common to all builtin_function
Rafael Espíndola wrote: > I have a patch that factors code common to all builtin_function > implementations. It is approved for trunk when we get to stage1. > > Are the developers involved in the lto branch interested in this > patch? If so, I can port it. Thanks for the offer! Yes, I think that would be good. However, we can also wait until it goes into the mainline, and until we decide to merge the mainline to LTO. I don't think we need it on the LTO branch on this time. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2 Status Report (2006-07-16)
At present, we have 160 serious regressions open against mainline (which will become 4.2). (I've downgraded many of Volker's reports about ICEs after valid error messages to P4, following Jason's recommendation. Upon reflection, I think that's the right thing to do; although robust error recovery is clearly a good thing, these ICEs don't have a substantial impact on most users.) Of the 160 regressions, 33 are P1s. As usual, a number are C++ issues. I intend to go after many of those personally in the near future. However, there are plenty of non-C++ P1s as well, so don't feel there's nothing for you non-C++ folks to do. Our historical standard for branching has been 100 regressions. I still think that's a reasonable target. The fact that we've still got a lot of issues on the mainline, even though we've been in regressions-only mode for quite a while, indicates that if we had a release branch we'd probably be having a very hard time getting 4.2 out -- and we'd be spending effort on 4.3. For those that think we're in Stage 3 for too long, please note that if every frequent GCC contributor fixed three regressions, we'd be under 100. We could do it tomorrow -- and certainly this week! -- with a concerted effort. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: local data flow
In http://gcc.gnu.org/ml/gcc/2006-07/msg00390.html, you write: > depending on what you are doing, you can update the solution in place. > The point of the dataflow talk was not to say that you cannot do > anything incremental, it was to say that there are no good GENERAL > techniques. Many times it is possible to update the solution precisely > if you have a very good understanding of the local conditions under > which the transformation is done on. Right. So the struct-equiv code does not have to be converted to use def-use chains to be beter integrated with thedataflow branch, it can happily go on using regsets of live registers. What it needed is a solid understanding about what invariants are required and how we can maintain them while we are changing the rtl, in order to keep the cost of updating the information under control. Which, ironically, is what I proposed to use in the first place outside of the dataflow branch to address the compile time problems, but Berndt considerd that approach to fragile. > The other trick it to do what I do in the new fast dce or the if-cvt on > the dataflow branch: > order the basic blocks so that it does not matter if you mess up the > solution. Generally a post order or a reverse postorder traversial of > the basic blocks will have the property that you can just mess things up > in a wave that moves from the beginning to the end or the end to the end > of the program without ever seeing the mess you make. cross-jumping two entire basic blocks creates opportunities for further cross-jumping and jump simplification involving the predecessor blocks. This appears to fit a reverse postorder traversal. However, if-conversion creates further if-conversion opportunities involving the newly merged block. Thus, while a postorder / reverse postorder traversal makes sense, we also need valid information for the newly merged block, its successors and predecessors. I suppose reg-live-at-start / reg-live-at-end information is actually easier to maintain during if-conversion that def-use chains. >>> I think that what you want is something like the reaching uses problem >>> but you want a forwards version of this rather than a backwards version >>> as is defined in df-problems.c. ... > the gen set of the reaching uses problem is the set of uses. the kill > set are the defs and the clobbers. This is why the problem is called > "reaching uses". In my problem, the gen set is the set of uses, and the kill set are defs, clobbers and uses. Hence, it's still backwards problem. But it is not really useful to compute this just for one or two code transformations - benefits could only be obtained if this information can be kept usable between different transformation to reduce the number of global updates. I suppose I should instead continue to operate on regsets, but keep them usable without frequent global updates, if that's all right with Berndt.
a question about code instrumentation in RTL level
The GCC internals explicitly introduced code manipulation APIs in TREE
representation (bsi_insert_before, bsi_remove etc). But I did not see the
equivalent for RTL representation.
Say, I want to enable a counter for a n-depth-nested loop. For example, I
want to add a counter instruction to count 2-depth-nested loop, then I need
to transform the following code as shown.
before transformation-
for (i=0; i< 5; i++ ){
for(j=0; j< 5; j++{
sum = sum+j;
}
}
---after transformation-
for (i=0; i< 5; i++ ){
for(j=0; j< 5; j++{
sum = sum+j;
}
}
counter++;
I found the following struct seemlessly provides information for above
purpose.
struct loop{
...
int depth;
rtx end;
}
i.e., it seems that I can simply do something like the following as long as
there is an API to manipulate RTL representation.
if (this_loop.depth ==2){
insert_after(this_loop.end);
}
Would you please kindly give me some hint to find out such APIs(I am sure
there is somewhere)? Thanks a lot.
_
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
