Re: print out %D spec
On Jan 25, 2014 1:32 AM, "Perry Smith" wrote: > > I think, a %D in a spec creates a list of -L/a/b/c -L/d/e/f. gcc -dumpspecs > shows me that link_libgcc goes to %D but it does not show me what %D > produces. Is there a way to get gcc to dump that out? > > Basically what I'm trying to do is find the list of library paths that GCC > tells ld to use when it calls ld. Adding -v to the gcc command will show everything it passes to the linker, you should be able to deduce what comes from the specs from that.
Re: clang and FSF's strategy
David Kastrup writes: > e...@thyrsus.com (Eric S. Raymond) writes: > >> David Kastrup's recent question on emacs-devel motivates me to bring >> up a larger related question I've been meaning to open for a while: >> Are the FSF's goals best served by continuing to technically restrict >> GCC? >> This is a question in which I have some positive stake. Yes, I >> continue to be opposed to the FSF's style of propaganda exactly >> because I think it hinders an end goal - a software ecosystem that is >> open-source and user-controlled - that I agree with and have worked >> hard to achieve. > > You are crossposting to two public project lists of the GNU project > with inflammatory language and mischaracterizations. You have been > involved with the GNU project long enough to be well aware that this > kind of crowbar approach does not lead to much more than headlines > about Free Software infighting. And just for the record, here are some of the headlines. http://lwn.net/Articles/582242/> I'm keeping the crosspost since the main issue started up on emacs-devel, and it mostly pertains to gcc-devel where some participants may be interested in using the opportunity to correct misconceptions in the discussion following the article (which could have been a lot worse I guess). With regard to the discussion on the mailing lists itself, I think that pretty much everything that's relevant to the big rhetorics has been said already. That does not mean that nothing remains to be done in the area of better integrating Emacs and GCC, but it does not appear like the main obstacles are of the kind that can be overcome by swashbuckling. -- David Kastrup
implementation & optimization of std::function with and without allocator
Hello All,
Consider the below toy example (I'm using Boehm GC 7.2d as provided on
Debian/Sid/x86-64):
// filetestclogc.cc
#include
#include
#include
#include
#include
gc_allocator mygcalloc;
extern "C" void apply_to_each(int lo, int hi,
const std::function&f)
{
for (int i=lo; i f (
#if 0 /* we should accept this but we don't yet */
std::allocator_arg, mygcalloc,
#endif
[&](int i) {printf("i=%d\n", i);});
apply_to_each(0, mx, f);
}
First, my understanding of the C++11 standard thru
http://en.cppreference.com/w/cpp/utility/functional/function/function
(which I know is imperfect, but I find it much more readable than
n3337.pdf draft of C++11 )
is that in principle we should compile this code with the #if 0 replaced
by #if 1 (but we don't yet, our header says "TODO: needs
allocator_arg_t"). Perhaps the type of mygcalloc is wrong...
(I don't understand at all the issues of accepting allocators for
std::function)
Then, I am surprised (and a bit disappointed) that (using GCC 4.8.2 from
Debian) with
g++-4.8 -Wall -std=c++11 -O3 -S \
-fdump-tree-phiopt -fverbose-asm testclogc.cc
we are not inlining all the lambda stuff. I was expecting we'll do the
inlining, since similar experiments with std::array etc... are very well
optimized, like
#include
#include
#include
#include
int sum (const std::array&a)
{
int s=0;
std::for_each(a.begin(), a.end(),
[&](int i) {printf("i=%d\n", i); s += i;});
return s;
}
I am not at all expert on C++ optimization, so probably I am very naive.
If someone had time to explain what passes are optimizing this sum
function with g++ -std=c++11 -O3 I would be very happy (the handling of
lambda-s is really mysterious to me)...
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: print out %D spec
Yea. I'm trying to smush this into a build process. The Ruby build process believes it knows how to set the internal libpath of the executables but it actually does not. It does not know what gcc knows and the end result is an executable that can not find libgmp.a. I was hoping to teach it Ruby's build process to construct a better libpath. The only thought I have is to compile a simple executable and then pull the libpath in the executable out of that using dump -H but I was hoping for something simpler. Thank you for your time, Perry On Jan 25, 2014, at 6:39 AM, Jonathan Wakely wrote: > On Jan 25, 2014 1:32 AM, "Perry Smith" wrote: >> >> I think, a %D in a spec creates a list of -L/a/b/c -L/d/e/f. gcc -dumpspecs >> shows me that link_libgcc goes to %D but it does not show me what %D >> produces. Is there a way to get gcc to dump that out? >> >> Basically what I'm trying to do is find the list of library paths that GCC >> tells ld to use when it calls ld. > > Adding -v to the gcc command will show everything it passes to the > linker, you should be able to deduce what comes from the specs from > that. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC Mips has 31 Masks in mips.opt
"Steve Ellcey " writes: > Richard, > > While experimenting with a local GCC change I added two new Masks to > mips.opt and ran into a build failure about too many masks: > > ./options.h:4172:2: error: #error too many target masks > > It looks like we already have 31 Masks in the MIPS mips.opt file and 32 > is the limit. It looks like the fix for this is to put some of the Masks > in a variable other then target_flags with the Var() syntax. I see i386 > and rs6000 doing this with ix86_isa_flags and rs6000_isa_flags. > > Now I could just put my new flags (and any other new flags that come > up) in a separate variable, but I was wondering if we wanted to > move a set of existing Masks to a new variable instead of just using > a first-come first-serve approach to what goes into the default > target_flags and what goes into a new flags variable. Yeah, I've been trying to use separate variables for new flags. That's why a lot of the MIPS options have discrete TARGET_… variables (defined via Var(TARGET_…)). target_flags should only really be needed for options whose defaults are controlled by config.gcc. E.g. from a quick look, -mdsp, -mdspr2, -mfp-exceptions, -mfused-madd and -mips3d don't need to be masks and could easily be converted to Var(TARGET_…). That's pre-approved it works. Others could be moved too with a bit more effort, but hopefully those 5 will be enough for now. Thanks, Richard
Re: implementation & optimization of std::function with and without allocator
On 25 January 2014 16:00, Basile Starynkevitch wrote: > > First, my understanding of the C++11 standard thru > http://en.cppreference.com/w/cpp/utility/functional/function/function > (which I know is imperfect, but I find it much more readable than > n3337.pdf draft of C++11 ) > is that in principle we should compile this code with the #if 0 replaced > by #if 1 (but we don't yet, our header says "TODO: needs > allocator_arg_t"). Perhaps the type of mygcalloc is wrong... > (I don't understand at all the issues of accepting allocators for > std::function) Using allocators with std::function isn't supported yet. This is documented at http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 (and looking at the code, as you have done, should make it pretty clear the necessary constructors are not defined). > Then, I am surprised (and a bit disappointed) that (using GCC 4.8.2 from > Debian) with > >g++-4.8 -Wall -std=c++11 -O3 -S \ >-fdump-tree-phiopt -fverbose-asm testclogc.cc > > we are not inlining all the lambda stuff. I was expecting we'll do the > inlining, since similar experiments with std::array etc... That isn't similar and the use of std::array is irrelevant. std::function involves type erasure, usually dynamic allocation, and indirection through function pointers. If you don't use std::function then none of that needs to be optimised away.
gcc-4.7-20140125 is now available
Snapshot gcc-4.7-20140125 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20140125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 207090 You'll find: gcc-4.7-20140125.tar.bz2 Complete GCC MD5=8a27248710d908fac543e6e8022ac26e SHA1=0532ebc4e6dc84334a5796126a9a0c6543da8cbc Diffs from 4.7-20140118 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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: implementation & optimization of std::function with and without allocator
On Sat, 25 Jan 2014, Jonathan Wakely wrote:
That isn't similar and the use of std::array is irrelevant.
std::function involves type erasure, usually dynamic allocation, and
indirection through function pointers. If you don't use std::function
then none of that needs to be optimised away.
Indeed. But optimizing the code generated when std::function is used seems
a worthy goal to me.
#include
int f(int i){return i-1;}
int main(){
std::function h=f;
return h(1);
}
Simplifying this to just:
int main(){return 0;}
should be achievable (and clang manages it, using either libstdc++ or
libc++). Filing some new PRs may be in order, if there aren't already a
few about this.
--
Marc Glisse
Re: implementation & optimization of std::function with and without allocator
On 25 January 2014 23:40, Marc Glisse wrote: > On Sat, 25 Jan 2014, Jonathan Wakely wrote: > >> That isn't similar and the use of std::array is irrelevant. >> std::function involves type erasure, usually dynamic allocation, and >> indirection through function pointers. If you don't use std::function >> then none of that needs to be optimised away. > > > Indeed. But optimizing the code generated when std::function is used seems a > worthy goal to me. Yes, I'd love to see it done, I'm just not surprised that it isn't done currently.
