I'm investigating the reason why the amount of stack used by some pieces
of code increased significantly since gcc 3.3. Notably,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505 has a testcase which
went up from 512 bytes to 20K between gcc 3.3 and 4.x, then back down to
~5K with later optimiz
gcc-4.6.2/gcc/Makefile.in:
tree-nomudflap.o : $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(TREE_INLINE_H) \
$(C_TREE_H) $(C_COMMON_H) $(GIMPLE_H) $(DIAGNOSTIC_H) $(HASHTAB_H) \
output.h langhooks.h tree-mudflap.h $(TM_H) coretypes.h \
$(GGC_H) gt-tree-mudflap.h $(TREE_PASS_H) $(DIAGNOSTIC_CORE_H
/src/gcc-4.7.0/configure -disable-bootstrap -enable-languages=go
book2:gccgo-4.7 jay$ g++ -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++
On 18 May 2012 16:53, Joel Sherrill wrote:
> You didn't mention Cygwin in your list
> but otherwise, it is pretty complete.
According to the libstdc++ testsuite, cygwin doesn't require -pthread
I think HPUX does need it, and IIRC when it was supported Tru64 did.
Snapshot gcc-4.6-20120518 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120518/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello again,
As promised I am providing Linux results now. With the recent fixes to
gdbserver and mips-linux-tdep the number of Linux progressions matches, as
far as the order of magnitude is concerned, that of bare-iron ones and is
around 30 for MIPS16 and around 100 for microMIPS multilibs.
On Fri, May 18, 2012 at 1:59 PM, Ian Lance Taylor wrote:
> Diego Novillo writes:
>
>> I've converted vec.[hc] to C++ and this meant some subtle changes to
>> how VEC(T,stack) works. We no longer need all those macro expansions.
>
> But it took me hours to write those macros
Worry not. I ca
Diego Novillo writes:
> I've converted vec.[hc] to C++ and this meant some subtle changes to
> how VEC(T,stack) works. We no longer need all those macro expansions.
But it took me hours to write those macros
> This means that the allocation function for vectors can detect when a
> stack v
Joel Sherrill writes:
> I agree with you on this one. Would it be a good general
> rule that on a system with pthreads, -pthread should be
> accepted by gcc?
Yes, I think so.
Ian
This is rather old code for you folks, but I'm not quite sure how to
deal with this issue.
I've converted vec.[hc] to C++ and this meant some subtle changes to how
VEC(T,stack) works. We no longer need all those macro expansions.
This means that the allocation function for vectors can dete
On 05/18/2012 10:50 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepiuswrites:
I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properl
Joel Sherrill writes:
> On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
>> Joel Sherrill writes:
>>
>>> On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepius writes:
> I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread
On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepius writes:
I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread works on a number of hosts,
including Solaris, Da
Joel Sherrill writes:
> On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
>> Ralf Corsepius writes:
>>
>>> I am not sure, but AFAICT, -pthread is Linux-specific.
>> It's not properly documented, but -pthread works on a number of hosts,
>> including Solaris, Darwin, FreeBSD, NetBSD, OpenBSD, AIX.
>
On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepius writes:
I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread works on a number of hosts,
including Solaris, Darwin, FreeBSD, NetBSD, OpenBSD, AIX.
Ian.. Is it better to make it a noop
"Peter A. Felvegi" writes:
> All versions I've tried (4.4, 4.5, 4.6, 4.7) compiles the code. clang
> gives proper diagnostic stating that Base::foo is private.
>
> If base::foo is not static, gcc catches the error, too:
> gccacbug.cpp: In member function ‘int DerivT::Foo() [with T = void]’:
> gcc
Ralf Corsepius writes:
> I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread works on a number of hosts,
including Solaris, Darwin, FreeBSD, NetBSD, OpenBSD, AIX.
Ian
Hello,
I've bumped into the following:
8<8<8<8<
class Base
{
static
int foo;
};
#if 0
class Deriv : public Base
{
public:
int Foo() { return foo; }
};
#endif
template
class DerivT : public Base
{
public:
int Foo() { return foo; }
};
void bar()
{
DerivT dt;
dt.Foo();
}
On 05/18/2012 09:24 AM, Sebastian Huber wrote:
Hi,
if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
target, then I get several unexpected errors due to:
gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option
'-pthread'
gcc/testsuite/g++/g++.log:g++: erro
Hi,
if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
target, then I get several unexpected errors due to:
gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option
'-pthread'
gcc/testsuite/g++/g++.log:g++: error: unrecognized command line option
'-pthrea
20 matches
Mail list logo
