Bug 230701

Summary: Warnings issued by g++4 about broken strict-aliasing rules in /usr/include/c++/3.4.3/bits/basic_string.h when compiling with -fstrict-aliasing -Wall
Product: Red Hat Enterprise Linux 4 Reporter: Ratko Veprek <veprek>
Component: gcc4Assignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 4.4   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-02 12:05:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Ratko Veprek 2007-03-02 11:15:50 UTC
Hi there!

Description of problem:
There may be some problem with the backwards compatiblity between g++-4.1 (Red
Hat 4.1.0-18) and libg++ 3.4.3. When using -fstrict-aliasing optimization flag,
i get warnings about broken strict-aliasing rules. The warnings do not apper
when using g++ 3.4.6. 

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
g++4 (GCC) 4.1.0 20060515 (Red Hat 4.1.0-18)

How reproducible:
always, just compile the following code on an x86_64 machine
#include <string>
int main() {
  std::string sausage("huhu");
}
using g++4 -Wall -fstrict-aliasing -c test.cc
then leave -fstrict-aliasing or use g++

should I take that warning message serious?

Thank you very much!

Best regards

ratko

Comment 1 Jakub Jelinek 2007-03-02 12:05:16 UTC
The -Wstrict-aliasing warning support was added only in 4.1+ and libstdc++-v3
4.1+ headers have been tweaked to shut the warning in this case down by
additional cast through void *, but as in RHEL4 libstdc++-v3 3.4.6 is used, you
get that harmless warning.  The code is believed to be ok, because
_S_empty_rep_storage is never written into at runtime (only initialized to 0 by
the linker).