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: