This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> Why wouldn't it be constructive? > > Even if it's impractical for gcc to change to the degree needed to fit > your particular project (especially in the short term), hearing the > details of how gcc's representations fell short, and how others may > have done things better, seems useful. My main concern is to avoid turning this into a "clang vs. gcc" debate. The two compilers make different trade-offs, so it is hardly surprising that one is better than the other for a particular use case. That does not mean that one is better than the other overall. But since it seems that there is significant interest, I have written down some of the technical problems that we ran into when working with gcc. Description and accompanying source code are enclosed. -DeLesley
Attachment:
gcc-problem-description.txt
Description: Text document
class Mutex { public: void Lock(); void Unlock(); }; class MyClass { public: virtual void myMethod(); MyClass(); ~MyClass(); }; // (1) Inaccurate CFG void foo1(Mutex* mu, bool c) { mu->Lock(); if (c) { MyClass mc; if (c) { mu->Unlock(); return; } // extra join point here to call ~MyClass() } mu->Unlock(); return; }; // (2) Inaccurate type information void foo2(void* p) { ((MyClass*) p)->myMethod(); } // (3) Problem with optimizations class DummyMutex { public: void Lock() { } void Unlock() { } }; void foo3(DummyMutex* dmu1, DummyMutex* dmu2) { dmu1->Lock(); dmu2->Lock(); dmu2->Unlock(); dmu1->Unlock(); }
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |