Hide Forgot
Description of problem: gcc 4.4 gives an incorrect error when compiling valid code that is a pointer to a typedef of a template. Upstream bug 42087 ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42087 ) gives the exact error that I encountered, but it was closed as a duplicate of bug 39390 ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390 ). There's no detail given in bug 39390 so there's no easy way to tell if the bug was actually a duplicate and if a single fix worked for both. Version-Release number of selected component (if applicable): gcc 4.47 How reproducible: Always Steps to Reproduce: 1. Copy the reproducer code from Bug 42087 2. Build using "g++ -O2 -Wall -Werror -c tst.cxx" 3. Observe incorrect error output Actual results: cc1plus: warnings being treated as errors tst.cxx: In function ‘int main()’: tst.cxx:23: error: dereferencing pointer ‘<anonymous>’ does break strict-aliasing rules /usr/lib/gcc/i686-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:179: note: initialized from here Expected results: Output of .o file with correct compilation of code. Additional info: I tested this on gcc 4.1.2 on RHEL 5 and it compiled without the error, so this is a regression from RHEL 5.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This is still an issue and I would like to request that a fix be considered for inclusion in the next release.
Fixed by unbackportable http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=145494. You can use -Wno-strict-aliasing to disable that warning.
This is not going to be fixed in the RHEL 6 system compilers. As Marek mentioned, you can use -Wno-strict-aliasing to disable the warning. The Developer Tool Set (DTS) compilers have the fix identified above and would be another option.
The DTS is a nice package, but currently it can't be used for building packages in the EPEL ( https://lists.fedoraproject.org/pipermail/epel-devel/2013-September/008737.html ) and has a significantly shorter support life than the compiler that comes with RHEL. So my questions are: Is RedHat going to help enable the use of DTS with the EPEL? Is forcing a user to upgrade compilers every few years on what is otherwise a stable platform really the path that RHEL is walking down?
I can't answer the first question, well out of my space. As for forcing upgrades, obviously we won't do that. We will continue to provide compilers in our base version of RHEL that are supported for 10+ years. However, there are simply some issues which are not feasible to fix in those toolchains without unacceptable risk to our customers and partners. This happens to be one of them. Thankfully there is a workaround to either use -Wno-strict-aliasing or use the DTS tools which are considerably newer and which have a fix for this specific problem. The DTS product is completely optional to our customers and was designed to provide customers a supported means to get access to newer tools as they come available.