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
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
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();
}
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
"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
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
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 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 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 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
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
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
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
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
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.
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
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.
/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++
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
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
20 matches
Mail list logo
