optimizing static inline recursive functions
I believe gcc treats all function calls as fairly sacred and doesn't really optimize across function calls much. For example, the pcre(regex) library creates it's own stack frames and "simulates" the entire function recursion to overcome this (and I think it has to, otherwise big inefficiencies would result.) Are there plans to add this feature to gcc? Thanks a lot. Reza.
"Annotate" INSN in gcc
Hi, I am working on IA64 and gcc4.1.1. My primary work is to use control speculation on IA64 to implement efficient taint tracking. We have already had a paper on ISCA'08. For this purpose, I add a pass (before the 2nd instruction scheduling) to instrument loads, stores, and compares. During the pass, I identify each INSN by "manually" matching their patterns (since at that time, INSNs in gcc have not bee fully recognized, I have to write my own recognizers for instructions). However, the downside of this approach is that I may miss some instructions (though most of the instructions have been instrumented), and these uninstrumented ones (though rare) will bring bizarre bugs into the instrumented program. (recently I find one such bug in my instrumented program, missing to instrument one instruction in about 30, instructions...) So now, I want to add some checking in final to see if my instrumentation is complete. The basic thing I want to do is to associate some attributes to the INSN I want to instrument, and also my instrumentation INSNs, in the added pass. Later in final, I could use GCC's INSN_CODE (or perhaps INSN template) to match all INSNs and see whether I have done all things right. NOW my problem is: could GCC do this work easily, or I should add my own data structure to record instrumented INSN? I have read some doc about insn attributes, but it seems that they do not fit into my needs... NOTE: the attributes should be bundled with the INSN, they should go along with INSN in other passes, e.g. scheduling, and should not be deleted by other passes. Any help is truly appreciated :-) Thanks ! yours sincerely Andrew
Re: optimizing static inline recursive functions
On Sat, Nov 1, 2008 at 8:27 AM, Reza Roboubi <[EMAIL PROTECTED]> wrote: > I believe gcc treats all function calls as fairly sacred and doesn't really > optimize across function calls much. For example, the pcre(regex) library > creates it's own stack frames and "simulates" the entire function recursion > to overcome this (and I think it has to, otherwise big inefficiencies would > result.) > > Are there plans to add this feature to gcc? GCC does tail recursion optimization. What more general optimization are you looking for? Your description isn't very specific. Richard. > Thanks a lot. > > Reza. >
Re: GCC 4.3.2 ignores -I. if used with other -I directives?!
Angel Tsankov wrote: > Result on my system: > dbgcnt.o: ../dbgcnt.c ../include/config.h > I meant that on my system the commands produce exactly the same result, i.e. the -I. option seems to be ignored.
Re: Build fails on i386-apple-darwin8.11.1
Jack Howarth wrote: > On Fri, Oct 31, 2008 at 02:30:25PM -0700, Andrew Pinski wrote: >> I get the following build failure on i386-apple-darwin8.11.1. >> >> >> libtool: link: /Users/apinski/src/local/gcc/objdir/gcc/gcj >> -B/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava/ >> -B/Users/apinski/src/local/gcc/objdir/gcc/ -ffloat-store >> -fomit-frame-pointer -Usun -g -O2 -o .libs/jv-convert >> --main=gnu.gcj.convert.Convert -shared-libgcc >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava/.libs >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava >> ./.libs/libgcj.dylib >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libstdc++-v3/src >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs >> -lpthread -ldl >> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: >> __Unwind_GetIPInfo >> collect2: ld returned 1 exit status >> warning: no debug map in executable (-arch i386) >> warning: no debug map in executable (-arch i386) >> make[3]: *** [jv-convert] Error 1 >> make[3]: *** Waiting for unfinished jobs >> >> >> Last known build that worked was revision 141116. >> >> Thanks, >> Andrew Pinski > > The last build I did on i686-apple-darwin9 was r141456 and it built libjava > fine. > I haven't done a build since (testing llvm 2.4 at the moment) but I would > suspect... > > 2008-10-31 Andrew Haley <[EMAIL PROTECTED]> > > * Makefile.am (install-data-local): Correct symlink paths for > SDK-style installed JARs. > Correct symlinks for headers when DESTDIR is set. > > as the culrpit. I don't see how. All my patch did was move around the symlinks for java_home when --with-java-home is used. _Unwind_GetIPInfo should be in libgcc. I'm not sure where the extra leading __ came from: is Darwin one of those systems that prefixes all C symbols with an extra underscore? Is __Unwind_GetIPInfo in the built libgcc? Is #define HAVE_GETIPINFO 1 in config.log ? Andrew.
Re: GCC 4.3.2 ignores -I. if used with other -I directives?!
Angel Tsankov wrote: > [..] the -I. option seems to be ignored. A further investigation reveals that GCC ignore not only "-I." but also "-I".
GCC 4.3.2 ignores -I. if used with other -I directives?!
Hi, Here's how the test case: 1. Create the following directory tree: |--include/config.h (may be empty) |--source/config.h (may be empty) \--dbgcnt.c (contains only '#include "config.h"') 2. Go to directory "source" and execute the following commands: gcc -M -I../include -I. ../dbgcnt.c gcc -M -I. -I../include ../dbgcnt.c Result on my system: dbgcnt.o: ../dbgcnt.c ../include/config.h Is this the expected result or smth is wrong? Regards, Angel Tsankov
Re: GCC 4.3.2 ignores -I. if used with other -I directives?!
Angel Tsankov wrote: > Angel Tsankov wrote: >> [..] the -I. option seems to be ignored. > > A further investigation reveals that GCC ignore not only "-I." but > also "-I". > Still further investigation shows that versions 2.95.4, 3.0.4, and 3.1.1 take into account "-I", while versions 3.2.3 and 4.3.2 ignore such options. Any ideas why? Angel
GCC 4.4.0 Status Report (2008-11-01)
Status == The two months of Stage 3 have ended and the trunk is now in regression and documentation fixes only mode. At this point bugfixing should concentrate on getting the list of serious regressions down to a level that makes GCC 4.4 ready to release. As an exception to this we will still have the old register allocator removed before we branch for the GCC 4.4.0 release. As usual maintainers may consider fixing serious bugs such as rejection of valid code or wrong-code bugs appropriate even if they are not regressions. The two quality metrics you know from the past still apply. We will consider releasing GCC 4.4.0 once the number of serious regressions is below 100 and no more P1 regressions remain. Only after releasing GCC 4.4.0 we will branch and open Stage 1 for GCC 4.5 development. Past experience tells us that we can expect this to happen not before another two months pass, which would be early next year. Quality Data Priority # Change from Last Report --- --- P1 17 - 9 P2 141 + 8 P33 + 1 --- --- Total 161 +- 0 We seem to make good progress in tackling P1 bugs though the overall number of serious regressions didn't decline. Which probably means we are getting more testing coverage now, which is good. I encourage maintainers to look over the bugs in their respective area and make sure we do not miss regressions that are not marked appropriately ([X.Y Regression] in the summary and a target milestone of the next version of the oldest active branch affected). In case you think a bug is not appropriately prioritized bump the priority back to P3 which makes the release managers aware of it. Note that P3 means un-prioritized and that only bugs for C, C++ and their runtimes for the list of primary and secondary targets listed at http://gcc.gnu.org/gcc-4.4/criteria.html qualify for P1 or P2. Previous Report === http://gcc.gnu.org/ml/gcc/2008-10/msg00404.html The next report for 4.4.0 will be sent by Jakub. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: Matching delete operator overload as a template function
2008/10/28 S. Tang <[EMAIL PROTECTED]>:
> Hello there,
>
> From what I understand, if one uses placement new with a parameter to
> initialize a class, and if that class' constructor throws an exception, then
> a matching delete operator is called to release the memory.
>
> This does not seem to work if the overloaded delete operator is a template
> function.
I think you've found a bug. Here is a reduced test which should fail
to compile, but gcc accepts it:
#include
template class undef;
struct MyClass
{
MyClass() { throw 1; } // constructor throws exception
};
template class Pool2 { };
template
inline void *operator new(size_t size,Pool2& pool)
{
return new char[size];
}
template
inline void operator delete(void *p,Pool2& pool)
{
undef t;// ERROR
delete[] (char*)p;
}
int main (int argc, char * const argv[]) {
Pool2 pool2;
try {
MyClass *myclass = new (pool2) MyClass(); // delete not called!
} catch(...) { }
return 0;
}
Re: Build fails on i386-apple-darwin8.11.1
On Sat, Nov 01, 2008 at 11:14:14AM +, Andrew Haley wrote: > Jack Howarth wrote: > > On Fri, Oct 31, 2008 at 02:30:25PM -0700, Andrew Pinski wrote: > >> I get the following build failure on i386-apple-darwin8.11.1. > >> > >> > >> libtool: link: /Users/apinski/src/local/gcc/objdir/gcc/gcj > >> -B/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava/ > >> -B/Users/apinski/src/local/gcc/objdir/gcc/ -ffloat-store > >> -fomit-frame-pointer -Usun -g -O2 -o .libs/jv-convert > >> --main=gnu.gcj.convert.Convert -shared-libgcc > >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava/.libs > >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava > >> ./.libs/libgcj.dylib > >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libstdc++-v3/src > >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs > >> -lpthread -ldl > >> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: > >> __Unwind_GetIPInfo > >> collect2: ld returned 1 exit status > >> warning: no debug map in executable (-arch i386) > >> warning: no debug map in executable (-arch i386) > >> make[3]: *** [jv-convert] Error 1 > >> make[3]: *** Waiting for unfinished jobs > >> > >> > >> Last known build that worked was revision 141116. > >> > >> Thanks, > >> Andrew Pinski > > > > The last build I did on i686-apple-darwin9 was r141456 and it built libjava > > fine. > > I haven't done a build since (testing llvm 2.4 at the moment) but I would > > suspect... > > > > 2008-10-31 Andrew Haley <[EMAIL PROTECTED]> > > > > * Makefile.am (install-data-local): Correct symlink paths for > > SDK-style installed JARs. > > Correct symlinks for headers when DESTDIR is set. > > > > as the culrpit. > > I don't see how. All my patch did was move around the symlinks for java_home > when --with-java-home is used. > > _Unwind_GetIPInfo should be in libgcc. I'm not sure where the extra leading > __ came from: is Darwin one of those systems that prefixes all C symbols with > an extra underscore? > > Is __Unwind_GetIPInfo in the built libgcc? > > Is > #define HAVE_GETIPINFO 1 > in config.log ? > > Andrew. Andrew, I was just pointing out the only change related to libjava between Andrew's failed build and my last successful one. Actually, I just built r141510 last night without problems on i686-apple-darwin9 against Xcode 3.1.2 Preview and will post the testresults to the mailing list shortly. Jack
Re: Matching delete operator overload as a template function
2008/11/1 Jonathan Wakely: > 2008/10/28 S. Tang: >> Hello there, >> >> From what I understand, if one uses placement new with a parameter to >> initialize a class, and if that class' constructor throws an exception, then >> a matching delete operator is called to release the memory. >> >> This does not seem to work if the overloaded delete operator is a template >> function. this is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158 Jonathan
RE: GCC 4.4.0 Status Report (2008-11-01)
What are the rules for porting patches back from the graphite branch that fix ICEs when -fgraphite is used to compile code? There doesn't seem to have been much movement of patches out of the graphite branch lately. Jack
bootstrap4 vs. compare?
In 4.3.2, it seems to me that bootstrap4 does not skip compare, so fails
when it is precisely needed. I did a bootstrap4, compare failed, but manual
make compare3 succeeded.
I guess a workaround is:
/src/configure -disable-bootstrap
make
make install
rm -rf *
/src/configure
make
make install
It seems, based on subsequent make install (not using the
above workaround) that bootstrap4 did skip, or not proceed to, fixincludes.
So I manually:
make all-fixinc
but I get:
/usr/WorkShop/usr/bin/ncc -w -g -o fixincl fixincl.o fixtests.o fixfixes.o serv
er.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a
ld: FATAL 12: Expecting o32 objects: ../libiberty/libiberty.a(safe-ctype.o) is n
32.
Problem is almost obvious, using bootstrap compiler vs. stage1 compiler.
So I edited out the last line of stage3-bubble -- the one that says "make
compare".
That is progressing.
It might help to say:
Makefile.in:
# Bubble a bug fix through all the stages up to stage 3. They are
# remade, but not reconfigured. The next stage (if any) will not be
# reconfigured as well.
.PHONY: stage3-bubble
stage3-bubble:: stage2-bubble
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
if test -f stage3-lean || test -f stage2-lean ; then \
echo Skipping rebuild of stage3 ; \
else \
$(MAKE) stage3-start; \
if $(LEAN); then \
rm -rf stage1-* ; \
$(STAMP) stage1-lean ; \
fi; \
$(MAKE) $(RECURSE_FLAGS_TO_PASS) all-stage3; \
fi
+ifneq ($(.DEFAULT_GOAL),bootstrap4)
$(MAKE) $(RECURSE_FLAGS_TO_PASS) compare
+endif
though that is probably inadequate.
It's not the default goal that matters, but if bootstrap4 is a goal at all.
Or if compare3 is a goal.
- Jay
