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 fin
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?
>>
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,
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 R
"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
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 prin
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
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.
Indee
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::functio
