Bug 1013751 - gcc 4.4 gives an incorrect error with pointer to typedef
gcc 4.4 gives an incorrect error with pointer to typedef
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gcc (Show other bugs)
6.4
Unspecified Linux
unspecified Severity high
: rc
: ---
Assigned To: Jakub Jelinek
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-30 13:18 EDT by Dave Johansen
Modified: 2016-06-09 13:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-12 17:47:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 42087 None None None Never

  None (edit)
Description Dave Johansen 2013-09-30 13:18:47 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):
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.
Comment 2 RHEL Product and Program Management 2013-10-13 21:51:21 EDT
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.
Comment 3 Dave Johansen 2013-10-25 11:16:25 EDT
This is still an issue and I would like to request that a fix be considered for inclusion in the next release.
Comment 4 Marek Polacek 2014-02-12 10:27:34 EST
Fixed by unbackportable http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=145494.  You can use -Wno-strict-aliasing to disable that warning.
Comment 5 Jeff Law 2014-02-12 17:47:23 EST
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.
Comment 6 Dave Johansen 2014-02-13 10:15:35 EST
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?
Comment 7 Jeff Law 2014-02-13 11:05:07 EST
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.

Note You need to log in before you can comment on or make changes to this bug.