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
Warnings issued by g++4 about broken strict-aliasing rules in /usr/include/c+...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc4 (Show other bugs)
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2007-03-02 06:15 EST by Ratko Veprek
Modified: 2007-11-16 20:14 EST (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Ratko Veprek 2007-03-02 06:15:50 EST
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 07:05:16 EST
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.