[Bug c++/38297] New: O2 causes invalid code

[Bug c++/38297] New: O2 causes invalid code

[andrew at warnux dot com]

I am compiling with g++ on a 64 bit Ubuntu OS.  I spent days trying to find out
why my programs kept crashing.  I found that when using O2 optimizations the
problem is there, when using O1 it is not a problem.

I am not using any compiler options other than stripping symbols, hiding
warnings, and O2.

Here is a very simple test case that causes the bug every time.

void RefTest(byte*& p)
{
        ++p;
}
void RefTest(char*& p)
{
        ++p;
}

char* c= "0123";
char* p= c;
RefTest((byte*&)p);
cout << p << endl; // 0123
RefTest(p);
cout << p << endl; // 123

return 0;


-- 
           Summary: O2 causes invalid code
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: andrew at warnux dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[andrew at warnux dot com]

------- Comment #1 from andrew at warnux dot com  2008-11-28 00:32 -------
I guess you want this too:

gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-11-28 01:38 -------
What is byte typedef?  Is it unsigned char or signed char?  If so then you are
violating aliasing rules by modifying a char* via that pointer type.  Yes
char/unsigned char/signed char are special but their pointer types are not.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[andrew at warnux dot com]

------- Comment #3 from andrew at warnux dot com  2008-11-28 01:59 -------
unsigned char

char and byte are the same size (1 byte), so why is there a problem?


-- 

andrew at warnux dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2008-11-28 02:20 -------
Yep you are violating C++ aliasing rules as you are accessing a char * as an
unsigned char*.  It would be ok if you accessed a char as an unsigned char but
you are accessing the pointers instead.

It is not the size which matters but rather the types which are being accessed
here.

*** This bug has been marked as a duplicate of 21920 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[andrew at warnux dot com]

------- Comment #5 from andrew at warnux dot com  2008-11-28 02:33 -------
Thanks!  I guess I learned something new today.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[andrew at warnux dot com]

------- Comment #6 from andrew at warnux dot com  2008-11-28 16:38 -------
I do have a couple concerns:

1. This one is MAJOR.  Without using -Wstrict-aliasing, I never see warnings
about this change.  I can't even begin to explain how bad that is.  The gcc
programmers made a big change (that is default compile) and there isn't even a
warning by default!  I wonder how many other things like this have been done.

2. Will other compilers compile this kind of code correctly?
inline bool IsNegative(float f)
{
    union
    {
        float f;
        int i;
    } u;
    u.f = f;
    return u.i & 0x80000000;
}
http://xania.org/200712/cpp-strict-aliasing


-- 

andrew at warnux dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2008-11-28 16:52 -------
1) Yes that is the reason why -Wstrict-aliasing exist.  This is undefined
behavior at runtime not at compile time so we cannot error out.  It is also the
reason why -Wstrict-aliasing is enabled with -Wall.

2) Use memcpy instead of an union if you want a portable way to type pun.

*** This bug has been marked as a duplicate of 21920 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[cdfrey at netdirect dot ca]

------- Comment #8 from cdfrey at netdirect dot ca  2008-11-28 19:24 -------
Why is the union access not portable, and listed as a GCC extension?

According to the quotation of the standard at:
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
(this link is found in the GCC docs on this topic)

The standard seems to list a union as a valid way to do type punning.

I can understand if it's just a matter of other compilers being buggy, but is
there any other reason that might make this non-portable?

What am I missing?

Thanks,
- Chris


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[andrew at warnux dot com]

------- Comment #9 from andrew at warnux dot com  2008-11-28 22:01 -------
I have another question.  I want to be able to detect if fno-strict-aliasing
was used when compiling.  Preferably at compile time but run time will be fine.
 How can I do this?


-- 

andrew at warnux dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[andrew at warnux dot com]

------- Comment #10 from andrew at warnux dot com  2008-11-28 22:02 -------
The shortest answer possible will be fine.  I don't want to be an annoyance.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2008-11-28 23:32 -------
There is no way currently inside the code to figure out if the C/C++ aliasing
rules are activated or not.  And I hope there will never be a way because it is
better to fix up your code.  The reason why the union case is considered
unspecified is because it depends on the under laying bit representation of
float. 

*** This bug has been marked as a duplicate of 21920 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[cdfrey at netdirect dot ca]

------- Comment #12 from cdfrey at netdirect dot ca  2008-11-28 23:36 -------
> The reason why the union case is considered
> unspecified is because it depends on the under
> laying bit representation of float.

That makes sense.  In this case, it's not really a type punning issue and more
of a float issue.  We'd be up the same creek without a paddle if we used
memcpy() on floats too.

Thanks,
- Chris


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2008-11-30 11:43 -------
Note that the C standard forbids type-punning through a union.  Basically it
says
that you may only read from a union member if you have previously written to
it.
It also says that all other bits apart from the ones you have written to
contain
undefined values after the write.  So

 union { int i; float f; } u;
 u.i = 1;
 x = u.f;

invokes undefined behavior in C (but not in GNU C because of the language
extension).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297

[Bug c++/38297] O2 causes invalid code

[joseph at codesourcery dot com]

------- Comment #14 from joseph at codesourcery dot com  2008-11-30 15:37 -------
Subject: Re:  O2 causes invalid code

On Sun, 30 Nov 2008, rguenth at gcc dot gnu dot org wrote:

> Note that the C standard forbids type-punning through a union.  
> Basically it says that you may only read from a union member if you have 
> previously written to it. It also says that all other bits apart from 
> the ones you have written to contain undefined values after the write.  
> So
> 
>  union { int i; float f; } u;
>  u.i = 1;
>  x = u.f;
> 
> invokes undefined behavior in C (but not in GNU C because of the language
> extension).

Note that C99 TC3 adds a footnote: "*) If the member used to access the 
contents of a union object is not the same as the member last used to 
store a value in the object, the appropriate part of the object 
representation of the value is reinterpreted as an object representation 
in the new type as described in 6.2.6 (a process sometimes called "type 
punning"). This might be a trap representation."


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297