You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yow! We never emitted code for any of those functions at the very least. My estimate is that this is causing about 60% of the extra strings. (Only an estimate because there are other sources of differences, such as clang emitting all case names for a given enum, while gcc only emits the used ones. I consider clang's behaviour better.)
The text was updated successfully, but these errors were encountered:
These strings, except _ZNK6locale16_M_add_referenceEv, are used for method declaration descriptions. One way to filter them would be following untested patch, if Nick's measurement indicates overall win.
Extended Description
Consider this testcase:
class locale {
private:
void _M_add_reference() const throw() {
}
};
class ios_base {
locale _M_ios_locale;
public:
class Init {
};
};
static ios_base::Init __ioinit;
When built without debug info, GCC and clang agree, the resulting assembly is:
.local _ZL8__ioinit
.comm _ZL8__ioinit,1,1
but where things get exciting is the debug info. Besides the filename/directory/compiler identifier, the strings that GCC emits are
.LASF4:
.string "Init"
.LASF5:
.string "__ioinit"
which makes sense, there's one object named __ioinit of type Init (technically "ios_base::Init", so emitting that would be fine too). Clang emits:
.Lstring3:
.ascii "__ioinit"
.zero 1
.Lstring4:
.ascii "_ZL8__ioinit"
.zero 1
.Lstring5:
.ascii "Init"
.zero 1
.Lstring6:
.ascii "_M_ios_locale"
.zero 1
.Lstring7:
.ascii "_ZNK6locale16_M_add_referenceEv"
.zero 1
.Lstring8:
.ascii "_M_add_reference"
.zero 1
.Lstring9:
.ascii "locale"
.zero 1
.Lstring10:
.ascii "ios_base"
.zero 1
Yow! We never emitted code for any of those functions at the very least. My estimate is that this is causing about 60% of the extra strings. (Only an estimate because there are other sources of differences, such as clang emitting all case names for a given enum, while gcc only emits the used ones. I consider clang's behaviour better.)
The text was updated successfully, but these errors were encountered: