Bad code on Ubuntu Hardy GCC 4.2, -O2

[Olly Betts]

There's a problem with 1.1.4 compiled with GCC 4.2 -O2 on Ubuntu Hardy (8.04).

GCC 4.1 and 4.3 apparently work.

It's unclear whether it is a compiler bug or bad code in Xapian triggering a problem. If the latter we need to fix it. If the former, a workaround would be nice.

Affects both chert and brass.

Mailing list thread:

​http://thread.gmane.org/gmane.comp.search.xapian.general/8149/focus=8154

[tack]

Output of make check with -O2. All tests pass with -O1.

[tack]

​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35643 looks related. I can reproduce the problem with -O1 -fstrict-aliasing.

Perhaps the most practical workaround is to enforce -O1 if gcc 4.2 is detected.

[tack]

I've also just verified that -O2 -fno-strict-aliasing works ok with gcc 4.2, and the test suite passes all tests.

Adding -fno-strict-aliasing if gcc 4.2 is detected would be even better than -O1, IMO.

[Olly Betts]

Good detective work! It's very hard to be sure that the issue is the same one in GCC, but if it works with GCC 4.1 and 4.3 and -fno-strict-aliasing avoids it, it seems quite likely.

I'll have a look through the log later, but it does seem forcing -fno-strict-aliasing for GCC 4.2 is the way to go.

[Richard Boulton]

It sounds like it might be a case of this problem (though I've not found actual equivalent code in Xapian - the symptoms fit, though): ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182

[Richard Boulton]

Patch configure to add nostrictalias with gcc4.2

[Richard Boulton]

I've attached a patch (nostrictaliaswith42.patch), and tested that compiling xapian trunk with gcc 4.2 (on ubuntu karmic, i386) and this patch applied passes the testsuite for me; without the patch, I get many test failures.

[tack]

I've tested Richard's patch and confirmed it's resolved my problem.

[Olly Betts]

I've committed the patch to trunk (with an expanded comment pointing to the GCC bug and this ticket to help out future developers) as r14068.

Since packages of 1.0.18 built successfully on Ubuntu hardy, it seems this bug doesn't affect 1.0 branch, though I wonder if it would be prudent to backport this to avoid any potential problems. My initial thinking was that the bug must be in new code in chert (perhaps pack.h) but the log shows it failing topercent2 with the inmemory backend. The only downside seems to be a likely performance degradation in the generated code.

So setting the milestone to 1.0.19 for now.

[Olly Betts]

Richard felt it was worth backporting, so done in r14091.