Bug 230701 - 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
Summary: Warnings issued by g++4 about broken strict-aliasing rules in /usr/include/c+...
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc4   
(Show other bugs)
Version: 4.4
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-02 11:15 UTC by Ratko Veprek
Modified: 2007-11-17 01:14 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-02 12:05:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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


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).

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