Description of problem: While trying to address a FTBFS during the Fedora 24 rebuild, I have run into an issue with strict-aliasing warnings. Here is a small reduced test case: $ cat sock.cpp #include <sys/socket.h> #include <netdb.h> void f(struct sockaddr &) {} int main () { struct sockaddr_in sa; f((struct sockaddr &)sa); } Compiling this on Fedora 23 (gcc-5.3.1-2.fc23.x86_64) works fine: $ gcc -O2 -Wall -Werror -o sock sock.cpp (no terminal output) Compiling it on Fedora 24 (gcc-6.0.0-0.10.fc24.x86_64) gives warnings: $ gcc -O2 -Wall -Werror -o sock sock.cpp sock.cpp: In function 'int main()': sock.cpp:8:24: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] f((struct sockaddr &)sa); ^~ cc1plus: all warnings being treated as errors Version-Release number of selected component (if applicable): gcc-6.0.0-0.10.fc24.x86_64 glibc-headers-2.22.90-33.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. See above Actual results: strict-aliasing warnings Expected results: No strict-aliasing warnings
This code violates strict aliasing so GCC is correct to warn here. Yet this sockaddr casting stuff is commonly used, so it seems that glibc could add the may_alias attribute to struct sockaddr, which would suppress the -Wstrict-aliasing warning.
Patch posted upstream: https://sourceware.org/ml/libc-alpha/2016-02/msg00340.html
Carlos ack'ed my upstream patch. I assume it will go into 2.24 (not into 2.23). There is no ABI impact as such, so I backported it to rawhide glibc. I hope this helps you with your mass-rebuild efforts.
Many thanks for the fast response. Compilation now works as expected.
Hi! With glibc-2.22.90-34, I have this package that now fails to build: https://kojipkgs.fedoraproject.org//work/tasks/1314/12981314/build.log with this error: /builddir/build/BUILD/simgear-3.7.0/simgear/io/raw_socket.cxx:400:18: error: prototype for ‘sockaddr* simgear::IPAddress::getAddr() const’ does not match any in class ‘simgear::IPAddress’ struct sockaddr* IPAddress::getAddr() const ^~~~~~~~~ In file included from /builddir/build/BUILD/simgear-3.7.0/simgear/io/raw_socket.cxx:28:0: /builddir/build/BUILD/simgear-3.7.0/simgear/io/raw_socket.hxx:67:13: error: candidate is: sockaddr* simgear::IPAddress::getAddr() const sockaddr* getAddr() const; ^~~~~~~ It works with glibc-2.22.90-33, so I assume this is related to the patch of this bug report? Is there something I should fix by my side ? Upstream code is here: https://github.com/FlightGear/simgear/blob/next/simgear/io/raw_socket.hxx#L67 https://github.com/FlightGear/simgear/blob/next/simgear/io/raw_socket.cxx#L400
Marek, it turns out that struct sockaddr and struct __attribute__ ((may_alias)) sockaddr { }; are treated as distinct types by the C++ front end, even though they forward declaration and definition do not conflict. This is arguably a compiler bug: either both types should be treated as equivalent in function signatures, or the forward declaration and the full definition should conflict. I'm not sure if we can settle this in time. I don't think I have much choice here, I need to back out the patch. The forward declaration scenario is more important to support than suppressing the (bogus) warning about breaking the aliasing rules (which is not really correct for C++ anyway).
I'm reverting this change.
This indeed looks like a bug. I found https://gcc.gnu.org/ml/gcc/2008-01/msg00440.html and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34936 Seems the revert is best at this moment.
Okay, doing a rawhide build now, effectively backing out the may_alias change. It was a nice idea …