Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR
Thomas Schwinge dixit: >First, the check for gcc_cv_libc_provides_ssp is not complete, as has >already pointed out (with patches!) before, but is still not fixed on >trunk. Let me revisit that: in configure.ac it is being checked for >``case "$target" in *-*-linux*)'' which should rather match ``*-*-linux* >| *-*-*-gnu* | *-*-gnu*'' to catch all GNU/Linux, GNU/Hurd, GNU/k*BSD >systems. FWIW, DragonFly, MirBSD and OpenBSD (at least) also provide the SSP functions in their respective C libraries. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C"
Re: register class constraints question
I'm not sure if this changed with IRA, but at least with the old reload code, if the instruction doesn't match, reload will look for the alternative with the cheapest total cost of alternative and reloads. Unfortunately, the fact that some reloads might be impossible does not figure in the decision. Where the costs are equal, the order is the tie-breaker; the first alternative is choosen then. You must make sure that the HI regs alternative gets precedence over the HL regs one when the operand getting the HI or HL regs is reloaded. Uou can do this by tweaking alternative costs, alternative order, REG_MOVE_COST (for the reload costs), or any combination if these. Or better, fix the alternative choosing algorithm to avoid alternatives which are already known to be impossible to fulfill when looking at the registers that are live during the insn and the constraints of a single operand in isolation. I.e. if we require n hard registers of a particular class, check that there are n hard registers free in that class. Probably discounting the possibility of having different overlapping classes between primary output and secondary / tertiary reloads which can fit individually but not together. (I.e. leave it to the port writer to avoid that). To avoid slowing the compiler down too much, you might want to restrict this to CLASS_LIKELY_SPILLED and/or delay the test till the alternative is choosen as the best one, and if the test fails, re-do the alternative choosing with a bit mask of discarded alternatives. (In which case a combined register/memory alternative that uses impossible address reloads on the first round will be discarded so the register part is also disabled - but I suppose that's a limitation we can live with.) It may be noted that there is nothing really stopping us from considering all operands of an alternative - for each operand, reload decides on an actual register class requirement, even if the alternative has multiple subparts - but I think it would make the code much more complex, and I doubt it would buy much in making ports easier to write or the generated code better.
build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR
Hello!
First, the check for gcc_cv_libc_provides_ssp is not complete, as has
already pointed out (with patches!) before, but is still not fixed on
trunk. Let me revisit that: in configure.ac it is being checked for
``case "$target" in *-*-linux*)'' which should rather match ``*-*-linux*
| *-*-*-gnu* | *-*-gnu*'' to catch all GNU/Linux, GNU/Hurd, GNU/k*BSD
systems. (This is being patched in the Debian GCC package for some time
already.)
But then, second, there still is a problem in that test: later on glibc's
features.h is being grepped, expecting it to reside at a place like
SYS_ROOT/usr/include/features.h. However, this needn't be true:
gcc/doc/fragments.texi
@item NATIVE_SYSTEM_HEADER_DIR
If the default location for system headers is not @file{/usr/include},
you must set this to the directory containing the headers. This value
should match the value of the @code{SYSTEM_INCLUDE_DIR} macro.
Unfortunately, NATIVE_SYSTEM_HEADER_DIR is a Makefile variable (see
gcc/config/t-gnu). It is being used only in three places:
gcc/config/t-gnu, gcc/config/t-gnu and gcc/config/i386/t-mingw32. What
do you suggest? Make that definition a shell variable and move it to
gcc/config.gcc?
Regards,
Thomas
signature.asc
Description: Digital signature
Re: Help with IA64 profiling bug - g++.dg/tree-prof/indir-call-prof.C
On Tue, 2008-10-07 at 17:55 +0200, Andreas Schwab wrote: > > I think to make that work tree_gen_ic_profiler and > tree_gen_ic_func_profiler would have to dereference the function > descriptor to extract the code address, which would then have the > necessary uniqueness which the vtable function descriptor lacks. > > Andreas. There seems to be more then just a missing level of dereferencing going on. For example, I think that the program, when compiled with -fprofile-generate, should be putting an address into __gcov_indirect_call_callee before calling __gcov_indirect_call_profiler (if I am reading the x86 code correctly) but on IA64 I don't see anything that writes to __gcov_indirect_call_callee. There is already a defect for this bug, PR 32277, I may just add what I have found to the PR and XFAIL the test like Richard suggested. It has never worked on IA64. Steve Ellcey [EMAIL PROTECTED]
Re: Help with IA64 profiling bug - g++.dg/tree-prof/indir-call-prof.C
Steve Ellcey <[EMAIL PROTECTED]> writes: > There seems to be more then just a missing level of dereferencing going > on. For example, I think that the program, when compiled with > -fprofile-generate, should be putting an address into > __gcov_indirect_call_callee before calling __gcov_indirect_call_profiler > (if I am reading the x86 code correctly) but on IA64 I don't see > anything that writes to __gcov_indirect_call_callee. I don't see that problem here. The variable is set at the right places, except that it is set to the address of the vtable descriptor, which is different to the normal descriptor. When I modify __gcov_indirect_call_profiler to compare the actual function addresses the testcase works as expected. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
gcc-4.2-20081008 is now available
Snapshot gcc-4.2-20081008 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20081008/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 140989 You'll find: gcc-4.2-20081008.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20081008.tar.bz2 C front end and core compiler gcc-ada-4.2-20081008.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20081008.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20081008.tar.bz2 C++ front end and runtime gcc-java-4.2-20081008.tar.bz2 Java front end and runtime gcc-objc-4.2-20081008.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20081008.tar.bz2The GCC testsuite Diffs from 4.2-20081001 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Re: Help with IA64 profiling bug - g++.dg/tree-prof/indir-call-prof.C
On Thu, 2008-10-09 at 00:27 +0200, Andreas Schwab wrote: > I don't see that problem here. The variable is set at the right places, > except that it is set to the address of the vtable descriptor, which is > different to the normal descriptor. When I modify > __gcov_indirect_call_profiler to compare the actual function addresses > the testcase works as expected. > > Andreas. Does that mean you have a patch? I tried changing __gcov_indirect_call_profiler but got nowhere. Steve Ellcey [EMAIL PROTECTED]
Re: register class constraints question
Joern Rennecke <[EMAIL PROTECTED]> writes: > I'm not sure if this changed with IRA, Acts the same with 4.3 and 4.4. > reload will look for the alternative with the cheapest total cost of > alternative and reloads. This was the key. Disparaging the smaller class's alternative with '?' works - it avoids the regalloc problem, yet that alternative ends up being used anyway (coincidence). Thanks!
RE: Defining a common plugin machinery
Thanks, Taras! I slightly updated this page, i.e. we would like to be able to load plugins through environment variables to be able to optimize programs transparently as it is done in MILEPOST GCC (without Makefile modifications). By the way, we plan to extend the Interactive Compilation Interface by the end of this year to access most of the internal transformations, however it will be based on the event and call-back mechanisms, which is similar to your GCC API proposal so we shouldn't have lots of compatibility problems if we later agree on the same plugin system... Take care, Grigori > -Original Message- > From: Taras [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2008 11:57 PM > To: Basile STARYNKEVITCH > Cc: Brendon Costa; Hugh Leather; gcc@gcc.gnu.org; 'Sean Callanan'; Cupertino > Miranda; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Taras Glek'; 'Diego Novillo'; Mike > O'Boyle; Grigori > Fursin > Subject: Re: Defining a common plugin machinery > > Basile STARYNKEVITCH wrote: > > > > My hypothesis is that several plugin mechanisms for GCC already exist > > (on some branches or somewhere else). If a small plugin patch has a > > better chance to get accepted into the trunk, we should limit > > ourselves to such a small thing. If big plugin machinery could be > > accepted (I would prefer that) we should understand what would make > > them more acceptable. In both cases, plugins have probably some > > requirements defined by the future runtime license, which I don't know > > yet. > http://gcc.gnu.org/wiki/GCC_PluginAPI > > I put up an API proposal. It's a result of the plugin API discussion at > the GCC summit. > > > Taras
Re: Defining a common plugin machinery
Grigori Fursin wrote: Thanks, Taras! I slightly updated this page, i.e. we would like to be able to load plugins through environment variables to be able to optimize programs transparently as it is done in MILEPOST GCC (without Makefile modifications). By the way, we plan to extend the Interactive Compilation Interface by the end of this year to access most of the internal transformations, however it will be based on the event and call-back mechanisms, which is similar to your GCC API proposal so we shouldn't have lots of compatibility problems if we later agree on the same plugin system... Personally I'm against the env var idea as it would make it harder to figure out what's going on. I think someone mentioned that the same effect could be achieved using spec files. Taras
Re: Defining a common plugin machinery
> Personally I'm against the env var idea as it would make it harder to > figure out what's going on. I think someone mentioned that the same > effect could be achieved using spec files. > Ian mentioned the idea of creating small wrapper scripts with the names: gcc/g++ etc which just call the real gcc/g++... adding the necessary command line args. These can then just be put earlier in the search path. I currently use the env var method in my project, but I think the wrapper script idea is a bit nicer than using env vars personally, so i will likely change to that soon. Brendon.
RE: Defining a common plugin machinery
Ok. I am fine with that. Actually, it requires minor modifications to the GCC anyway, so I can just keep them as patches for the ICI/MILEPOST GCC ;) ... Cheers, Grigori > -Original Message- > From: Taras Glek [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 09, 2008 8:29 AM > To: Grigori Fursin > Cc: 'Basile STARYNKEVITCH'; 'Brendon Costa'; 'Hugh Leather'; gcc@gcc.gnu.org; > 'Sean Callanan'; > 'Cupertino Miranda'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Taras Glek'; > 'Diego Novillo'; 'Mike > O'Boyle' > Subject: Re: Defining a common plugin machinery > > Grigori Fursin wrote: > > Thanks, Taras! > > > > I slightly updated this page, i.e. we would like to be able to load plugins > > through environment variables to be able to optimize programs transparently > > as it is done in MILEPOST GCC (without Makefile modifications). By the way, > > we plan to extend the Interactive Compilation Interface by the end of this > > year > > to access most of the internal transformations, however it will be > > based on the event and call-back mechanisms, which is similar to your > > GCC API proposal so we shouldn't have lots of compatibility problems > > if we later agree on the same plugin system... > > > Personally I'm against the env var idea as it would make it harder to > figure out what's going on. I think someone mentioned that the same > effect could be achieved using spec files. > > Taras
RE: Defining a common plugin machinery
> > Personally I'm against the env var idea as it would make it harder to > > figure out what's going on. I think someone mentioned that the same > > effect could be achieved using spec files. > > > Ian mentioned the idea of creating small wrapper scripts with the names: > gcc/g++ etc which just call the real gcc/g++... adding the necessary > command line args. These can then just be put earlier in the search path. > > I currently use the env var method in my project, but I think the > wrapper script idea is a bit nicer than using env vars personally, so i > will likely change to that soon. That's right. It's a nicer solution. We just already have environment variables in our ICI implementation, but it can be useful if we will one day switch to the common plugin system without support for env variables ... Cheers, Grigori > Brendon.
