[4.0/4.1 regression]
Hi,
I've filed PR25218:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25218
which leads at -O3 to:
4.0.1
bug.c:20: internal compiler error: in compensate_edge, at reg-stack.c:2795
4.1
bug.c:20: internal compiler error: in initialize_original_copy_tables, at
cfg.c:1025
Cheers,
Joost
---
static float rgam;
extern void *jmp(void *);
void drotmg(float d1) {
void *labels[] = { &&L170, &&L180, 0 };
for(;;) {
goto *jmp(labels);
if (d1 <= rgam)
goto L170;
L170:
if (d1 <= rgam)
goto L170;
}
L180:
goto L170;
}
---
STL mt_allocator crash in global construcutor
FC4, g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
We have a no. of libraries which have worked fine up till now (even using
4.0.1 on FC3, albeit with libstdc++-3.4.4-). Now with 4.0.1 (& 4.0.2)'s
libstdc, I'm getting a crash immediately at start-up in mt_allocator.h, within
_M_adjust_freelist:
void
_M_adjust_freelist(const _Bin_record& __bin, _Block_record* __block,
size_t __thread_id)
{
if (__gthread_active_p())
{
__block->_M_thread_id = __thread_id;
HERE -> --__bin._M_free[__thread_id];
++__bin._M_used[__thread_id];
}
}
At the point at which it happens, _M_free is uninitialised. This is
constructing a deque with the following code:
<.h>
#include
#include
class CObject
{
public:
struct SDeadObject
{
void *Ptr;
std::string Name;
SDeadObject() { Ptr = NULL; Name = ""; }
SDeadObject( void *ptr, const std::string &name ) {
Ptr = ptr; Name = name; }
};
typedef std::deque DEAD_OBJECT_DEQUE;
typedef std::deque::iterator DEAD_OBJECT_DEQUE_ITERATOR;
protected:
static DEAD_OBJECT_DEQUE RecentlyDeadObjects;
};
<.cpp>
CObject::DEAD_OBJECT_DEQUE CObject::RecentlyDeadObjects;
Now, if I create a library with /just/ this code it, and dlopen() it, it
works OK. However, if I link that library to my other two base libraries, I
get the crash.
I'm guessing that the order of global constructors is altered by the
dependancy linkage, and that this constructor is being called before the pool
allocator's [I can't find the body code for the pool template's
_M_initialize() anywhere ...].
But I don't have any idea how to work around it, or even be sure whether
it's our code or the STL.
I did discover that GLIBCXX_FORCE_NEW=1 at runtime makes it work OK.
g++ -MMD -Wall -fmessage-length=0 -ggdb-fpic -D_GNU_SOURCE
-DPROJECT=Buffy -I../../../Buffy-D__posix -DDISABLE_CF_HACKS -o
Linux-i686/Debug/jobby.lo -c jobby.cpp && cp -f Linux-i686/Debug/jobby.d
Linux-i686/Debug/jobby.dep && sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/
*\\$//' -e '/^$/ d' -e 's/$/ :/' >>Linux-i686/Debug/jobby.dep && rm -f Linux-i686/Debug/jobby.d
g++ -shared -o ../../../Libs/Buffy/Linux-i686/Debug/libCF.so
-L../../../Libs/Buffy/Linux-i686/Debug -Wl,-rpath=/software/lib
-Wl,-rpath=/mnt/software/lib
-Wl,-rpath-link=../../../Libs/Buffy/Linux-i686/Debug
Linux-i686/Debug/jobby.lo -lPSUtils
--
[EMAIL PROTECTED] ~]# rm -f .signature
[EMAIL PROTECTED] ~]# ls -l .signature
ls: .signature: No such file or directory
[EMAIL PROTECTED] ~]# exit
Different Object Model in g++-2.95 and g++-3.3.5?
Hi, all:
I compiled the following code using g++-2.95:
-
#include
using namespace std;
class A {
public:
virtual void echo () {};
};
class B: public virtual A {
public:
int b;
virtual void echo () {};
};
int
main()
{
cout << sizeof(A) << endl;
cout << sizeof(B) << endl;
return 0;
}
The result is:
4
12
If I compile it using g++-3.3.5, the result is:
4
8
So I am wondering whether g++-3.3.5 changes its object model.
---
Holderlin Zhang
Department of Applied Math., Nankai University
Re: Different Object Model in g++-2.95 and g++-3.3.5?
holderlin writes: > So I am wondering whether g++-3.3.5 changes its object model. The V3 multi-vendor standard C++ ABI is used in GCC releases 3.0 and above. http://www.codesourcery.com/cxx-abi/ Andrew.
Re: STL mt_allocator crash in global construcutor
The correct list for this post is [EMAIL PROTECTED] I suggest that you come up with a self-contained bit of code to reproduce the problem you are having and entering it into gcc bugzilla, which can be found here: http://gcc.gnu.org/bugzilla best, benjamin
Re: [PATCH] New predicate covering NOP_EXPR and CONVERT_EXPR
Richard Kenner <[EMAIL PROTECTED]> wrote: > Java has to be fixed (probably with a frontend-specific tree code), > and maybe also Ada. > > Ada does not. It generates CONVERT_EXPR vs. NOP_EXPR in some attempt > to preserve some old-semantic difference but always treats them the > same when looking at trees. This is a jolly good news to me, thanks. -- Giovanni Bajo
Possible size-opt patch
Bernd, I read you're interested in code-size optimizations. I'd like to point you to this patch: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html which was never finished nor committed (I don't know if RTH has a newer version though). This is would be of great help for code size issues in AVR, but I don't know if and how much it'd help for Blackfin. -- Giovanni Bajo
GCC back-ends
Hi, Does GCC front- and middle-end keep the source code line numbers all the way until the RTL is generated? I'd need that for the tool I'm developing. Also, are there any simple source code browsers / static analysis tools that use GCC as the front-/middle-end that I might check out to see how to hook up with GCC? Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
gcc-4.1-20051202 is now available
Snapshot gcc-4.1-20051202 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051202/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 107949 You'll find: gcc-4.1-20051202.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051202.tar.bz2 C front end and core compiler gcc-ada-4.1-20051202.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051202.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051202.tar.bz2 C++ front end and runtime gcc-java-4.1-20051202.tar.bz2 Java front end and runtime gcc-objc-4.1-20051202.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051202.tar.bz2The GCC testsuite Diffs from 4.1-20051125 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: weakref and static
> Unfortunately, it can't do that; Mach-O (on Darwin) doesn't support > aliases in the object file at all, and even ELF doesn't support > aliases to symbols outside the current .o. The easiest solution to > this is to require that weakrefs must be 'static', because the name > that they define is not visible outside this translation unit. > > There's an additional wrinkle, which is although this name is > 'static', it is also 'weak' because it can be NULL. So we have > introduced a new concept, a static weak name. Fortunately it is > limited to just this one case. The hpux linker and dynamic loader don't support undefined symbols. Thus, weakrefs are essentally useless as currently implemented. In principle, GAS can handle 'weak' 'static' symbols under hpux. Thus, I like your idea. However, there are issues with using weakrefs in at least some of the gthr files. Alexandre is looking at these. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
new gcc/g++ 4.1.0 flags?
Where exactly are the compiler flags new to gcc 4.1.0 described. I now understand that -ffriend-injection can be used with g++ to overcome the new strictness about the scope of friends. However, I am seeing another compile error in xplor-nih of the form... cdsVector.cc: In function 'CDSVector CDSVector_Sl_int_Sgpow__(CDSVector*, const float_type&)': _cdsVector.cc:1173: warning: converting to 'int' from 'double' /Users/howarth/Desktop/xplor-nih-2.12/CDSlib/cdsVector.hh: In member function 'CDSVectorBase& CDSVectorBase::operator*=(const T1&) [with T1 = double, T = int, ALLOC = CDS::DefaultAlloc]': _cdsVector.cc:1177: instantiated from here /Users/howarth/Desktop/xplor-nih-2.12/CDSlib/cdsVector.hh:242: warning: converting to 'int' from 'double' _cdsVector.cc: In function 'T sum(const CDSVector&) [with T = int]': _cdsVector.cc:2426: instantiated from here _cdsVector.cc:913: warning: converting to 'int' from 'double' _cdsVector.cc: In function 'float_type norm(const CDSVector&) [with T = double]': _cdsVector.cc:6004: instantiated from here _cdsVector.cc:942: error: no matching function for call to 'norm(const double&)' which -ffriend-injection doesn't solve. It would be nice if gcc 4.1.0 clearly listed the new areas of c++ strictness and which compile flag can be used to override the new behavior. Thanks in advance for any clarifications. Jack
Re: build1, build1_v and friends
Paul Thomas wrote: Richard, gfortran is failing to build, evidently because of your patch. There are maybe 20-30 occurrences of build1 and build1_v scattered through the gfortran trans- files. What do I do to rectify this? I have reverted to r10790(ie. just before your group of patches) and the build goes through fine. I have done absolutely no investigation because I am tyring to sort out a Sherlock Holmes "three piper" in gfortran. If we have to replace the build1's with something, please let me know and I will implement it. Best regards Paul Thomas
Re: build1, build1_v and friends
Richard, If we have to replace the build1's with something, please let me know and I will implement it. I completely missed r107917... I will set about doing it. Paul T
