Red Hat Bugzilla – Bug 1013751
gcc 4.4 gives an incorrect error with pointer to typedef
Last modified: 2016-06-09 13:31:22 EDT
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):
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
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
Output of .o file with correct compilation of code.
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.