xplc tests failures on ia64, sparc, and armel with gcc-4.4 -O2

[Matthias Klose]

0.3.13-2ubuntu1 to build with -Os to work around:

Running tests:
tests/test007.cpp:59: u1 is not equal to UUID_null after resetting
./testmain: 1 failed, 229 passed
make[1]: *** [tests] Error 1
make[1]: Leaving directory `/build/buildd/xplc-0.3.13'
make: *** [debian/stamp-makefile-check] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

[Matthias Klose (doko)]

confirmed with xplc_0.3.13-2 and gcc-4.4_4.4.1-4ubuntu3

[Matthias Klose (doko)]

same on ia64

[Matthias Klose (doko)]

in lucid, builds ok on armel with gcc-4.4

[Michael Hope (michaelh1)]

This works-around the upstream bug by setting -fno-strict-aliasing for all architectures instead of having an architecture specific optimisation-based work around.

This does not fix the upstream bug which should be solved.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xplc - 0.3.13-2ubuntu5

---------------
xplc (0.3.13-2ubuntu5) maverick; urgency=low

  [ Michael Hope ]
  * Instead of replacing -O2 with -Os on ia64 and sparc Debian architectures,
    build with -fno-strict-aliasing all the time to work around an aliasing
    bug; LP: #437726.

  [ Loïc Minier ]
  * Add build-dep on autotools-dev to get CDBS to update config.sub and .guess
    to the latest versions automatically.
 -- Michael Hope <email address hidden> Wed, 21 Jul 2010 12:31:11 +0200

[Loïc Minier (lool)]

Thanks, I uploaded your changes after tweaking the changelog slightly and I took the occasion to also fix a lintian warning in the same upload.

[Loïc Minier (lool)]

Not a gcc bug.

[Pierre Phaneuf (pphaneuf)]

I could use some tips on how to fix the bug in the upstream. Notably, is there any reproduction on i386 or x86_64? I'm not sure where the aliasing occurs exactly... Thanks!

[Ulrich Weigand (uweigand)]

The problem is in the operator== and operator!= routines for UUID, in include/xplc/uuidops.h:

inline int operator==(const UUID& uuid1, const UUID& uuid2) {
    return
      (&uuid1 == &uuid2) ||
      ((static_cast<const u_int32_t*>(&uuid1.Data1)[0] == static_cast<const u_int32_t*>(&uuid2.Data1)[0]) &&
       (static_cast<const u_int32_t*>(&uuid1.Data1)[1] == static_cast<const u_int32_t*>(&uuid2.Data1)[1]) &&
       (static_cast<const u_int32_t*>(&uuid1.Data1)[2] == static_cast<const u_int32_t*>(&uuid2.Data1)[2]) &&
       (static_cast<const u_int32_t*>(&uuid1.Data1)[3] == static_cast<const u_int32_t*>(&uuid2.Data1)[3]));
}

Since UUID (and GUID) is defined like this:

typedef struct _GUID {
  u_int32_t Data1;
  u_int16_t Data2;
  u_int16_t Data3;
  u_int8_t Data4[8];
} GUID;

those static_casts above cause the aliasing violation. Note how uuid1.Data2/3/4 have effective type u_int16_t or u_int8_t, but are accessed via an lvalue of type u_int32_t ? This causes undefined behavior.

To avoid this, there are basically two standards-compliant ways I can see: either, you compare all elements separately, or else you compare the whole struct via a memcmp. (The latter could in theory cause spurious failures if there were padding bytes in the structure; but in practice this does not occur on any system I'm aware of.)