Re: How to run testsuite without building a complier
On 10/5/07, Brian Dessent <[EMAIL PROTECTED]> wrote: > Mohamed Shafi wrote: > > > I want to know whether its possible to run the gcc testsuite without > > actually building the complier. > > > > I have the dejagnu framework, compiler executables and i have the gcc > > test suite. So is it possible to run the testsuite without building > > the complier? > > Use the contrib/test_installed script. > I used the script and even tried to execute the runtest command directly but the framework is not picking up the simulator for my target. If i run the testsuite using make check-gcc command from the build directory everything is fine. What could be the problem? Regards, Shafi
Re: Profile information - CFG
Seongbae Park (???, ???) wrote: On 9/27/07, Hariharan Sandanagobalane <[EMAIL PROTECTED]> wrote: Hello, I am implementing support for PBO on picochip port of GCC (not yet submitted to mainline). I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the profile information, the former containing the flow graph information(compile-time) and later containing the edge profile information(run-time). The CFG information seems to be getting emitted quite early in the compilation process(pass_tree_profile). Is the instrumentation also done at this time? If it is, as later phases change Yes. CFG, how is the instrumentation code sanity maintained? If it isnt, How Instrumentation code sanity is naturally maintained since those are global load/stores. The compiler transformations naturally preserve the original semantic of the input and since profile counters are global variables, update to those are preserved to provide what unoptimized code would do. would you correlate the CFG in gcno file to the actual CFG at execution(that produces the gcda file)? As for our port's case, we are already able to generate profile information using our simulator/hardware, and it is not-too-difficult for me to format that information into .gcno and .gcda files. But, i guess the CFG that i would have at runtime would be quite different from the CFG at initial phases of compilation (even at same optimization level). Any suggestions on this? Would i be better off keeping the gcno file that GCC generates, try to match the runtime-CFG to the one on the gcno file and then write gcda file accordingly? Not only better off, you *need* to provide information that matches what's in gcno, otherwise gcc can't read that gcda nor use it. How you match gcno is a different problem - there's no guarantee that you'll be able to recover enough information from the output assembly of gcc, because without instrumentation, gcc can optimize away the control flow. pass_tree_profile is when both the instrumentation (with -fprofile-generate) and reading of the profile data (with -fprofile-use) are done. The CFG has to remain the same between generate and use - otherwise the compiler isn't able to use the profile data. Thanks for your help, seongbae. I have managed to get the profile information formatted in the way .gcda would look. But, does GCC expect the profile to be accurate? Would it accept profile data that came out of sampling? -Hari Seongbae
Re: Profile information - CFG
On 10/5/07, Hariharan Sandanagobalane <[EMAIL PROTECTED]> wrote: > > > Seongbae Park (???, ???) wrote: > > On 9/27/07, Hariharan Sandanagobalane <[EMAIL PROTECTED]> wrote: > >> Hello, > >> I am implementing support for PBO on picochip port of GCC (not yet > >> submitted to mainline). > >> > >> I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the > >> profile information, the former containing the flow graph > >> information(compile-time) and later containing the edge profile > >> information(run-time). The CFG information seems to be getting emitted > >> quite early in the compilation process(pass_tree_profile). Is the > >> instrumentation also done at this time? If it is, as later phases change > > > > Yes. > > > >> CFG, how is the instrumentation code sanity maintained? If it isnt, How > > > > Instrumentation code sanity is naturally maintained > > since those are global load/stores. The compiler transformations naturally > > preserve the original semantic of the input > > and since profile counters are global variables, > > update to those are preserved to provide what unoptimized code would do. > > > >> would you correlate the CFG in gcno file to the actual CFG at > >> execution(that produces the gcda file)? > > > >> As for our port's case, we are already able to generate profile > >> information using our simulator/hardware, and it is not-too-difficult > >> for me to format that information into .gcno and .gcda files. But, i > >> guess the CFG that i would have at runtime would be quite different from > >> the CFG at initial phases of compilation (even at same optimization > >> level). Any suggestions on this? Would i be better off keeping the gcno > >> file that GCC generates, try to match the runtime-CFG to the one on the > >> gcno file and then write gcda file accordingly? > > > > Not only better off, you *need* to provide information that matches > > what's in gcno, otherwise gcc can't read that gcda nor use it. > > How you match gcno is a different problem > > - there's no guarantee that you'll be able to recover > > enough information from the output assembly of gcc, > > because without instrumentation, gcc can optimize away the control flow. > > > > pass_tree_profile is when both the instrumentation (with -fprofile-generate) > > and reading of the profile data (with -fprofile-use) are done. > > The CFG has to remain the same between generate and use > > - otherwise the compiler isn't able to use the profile data. > > Thanks for your help, seongbae. > > I have managed to get the profile information formatted in the way .gcda > would look. But, does GCC expect the profile to be accurate? Would it > accept profile data that came out of sampling? > > -Hari Gcc expects the profile to be "flow consistent". i.e. at any basic block, the sum of execution count of all incoming edges have to be equal to that of outgoing edges. I have a patch adding a new option to tolerate inconsistency but it will have to wait for stage1 opening in 4.4. -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
gcc-4.3-20071005 is now available
Snapshot gcc-4.3-20071005 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071005/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 129042 You'll find: gcc-4.3-20071005.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20071005.tar.bz2 C front end and core compiler gcc-ada-4.3-20071005.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20071005.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20071005.tar.bz2 C++ front end and runtime gcc-java-4.3-20071005.tar.bz2 Java front end and runtime gcc-objc-4.3-20071005.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20071005.tar.bz2The GCC testsuite Diffs from 4.3-20070928 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
OpenMP and libgomp.so.1 problems
Hi I've had major headaches on my gentoo system with GCC 4.2.1 using the -fopenmp flag with GCC compiled with openmp support The problem is: libgomp.so.1: shared object cannot be dlopen()ed Everything works great once OpenMP support is removed and -fopenmp is removed from my flags. I noticed that there is a fix for this in GCC 4.3 but will it also be fixed in GCC 4.2.2? Thanks for any insight you can offer Mike
Is it ever possible to build libmudflap, libssp, or libgomp when inhibit_libc is set?
Is it ever possible to build libmudflap, libssp, or libgomp when inhibit_libc is set? If not, is is reasonable to add a check to the top level configure to detect situations that will cause gcc configure to set inhibit_libc and add those libraries to either skipdirs or noconfigdirs. (Which would be preferred?) It looks like just a couple of lines in configure to exclude them automatically if they can never build under that condition on any target. Steve Kenton
