xlpc fails during test with the Linaro GCC

[Michael Hope]

Seen on xplc 0.3.13-2ubuntu4 using gcc-4.4 4.4.4-7ubuntu1~ppa2

http://launchpadlibrarian.net/52093711/buildlog_ubuntu-maverick-armel.xplc_0.3.13-2ubuntu4_FAILEDTOBUILD.txt.gz

Fails during the test phase.

[Ulrich Weigand (uweigand)]

Confirmed: works with the maverick toolchain, fails with gcc-4.4 4.4.4-7ubuntu1~ppa2.

[Ulrich Weigand (uweigand)]

Actually, it turned out to be a bug in the xplc source code after all: a violation of aliasing rules.

From include/xplc/uuid.h:

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

typedef GUID UUID;

From 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]));
}

This routine uses lvalues of type u_int32_t to access objects with effective type u_int16_t or u_int8_t, which is not allowed according to the aliasing rules.

In the test case tests/test007.cpp:

  u1 = UUID_null;
  VERIFY(u1 == UUID_null, "u1 is not equal to UUID_null after resetting");

this seems to have caused parts of the initialization of u1 to be scheduled after the use of u1 by the above operator== when inlined. This depends on details of instruction scheduling decisions which have changed in Linaro GCC.

In any case, this is not a compiler problem but needs to be fixed in the original source by something along the lines of either:
- building with -fno-strict-aliasing as a workaround
- comparing all UUID structure elements one by one
- comparing structure contents using memcmp