-
Notifications
You must be signed in to change notification settings - Fork 6
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buid fails with -Werror=strict-aliasing (lto) #6
Comments
We have change our build flags to |
I was able to reproduce the problem with,
The first two strict-aliasing failures in LARGE_INTEGER li;
li = *(LARGE_INTEGER *)&V_CY(variant); which leads us to the definitions of typedef struct _LARGE_INTEGER {
DWORD LowPart;
LONG HighPart;
} LARGE_INTEGER
// FIXME: portability
typedef struct tagCY {
#if BIGENDIAN
int32_t Hi;
uint32_t Lo;
#else
uint32_t Lo;
int32_t Hi;
#endif
int64_t int64;
} CY; While the types in the first two fields are compatible, the structs themselves are not, at least not in their entirety. I presume this is what the compiler is complaining about. In this case there's an easy workaround though: // No!
// li = *(LARGE_INTEGER *)&V_CY(variant);
// Yes!
li.LowPart = V_CY(variant).Lo;
li.HighPart = V_CY(variant).Hi; But that brings us back to the first error in typedef struct FARSTRUCT tagFILETIME
{
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME; and we have the same sort of problem on line 179 of But on line 260 of FILETIME& OLEProperty::operator=(const FILETIME& v) {
Clear();
V_CY(&val) = *((CY *)&v);
return *((FILETIME *)&V_CY(&val));
} I don't see an obvious solution to this one because we actually want to return a reference. And I've been away from C++ too long to know intuitively what happens when we cast a dereferenced pointer back to a reference. I guess it makes sense for chains of overloaded operators like Anyway, the build succeeds with the two bad lines in |
When using
CFLAGS="-Werror=strict-aliasing
, the build fails:This was reported to us in Gentoo bug 859913.
Why would we enable this if it makes the build fail? Newer compilers are becoming more strict about what they will accept, and especially with link-time optimization (LTO), are beginning to make some more assumptions about the code. Gentoo is a source-based distribution and one of the main benefits of that is that users are free to enable link-time optimization themselves. But, as a safety net, it's a good idea to enable
-Werror=strict-aliasing
when doing so. You want the build to fail if the optimization pass might break the code; this prevents our users from winding up with a broken package installed.The text was updated successfully, but these errors were encountered: