This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/20185] assignment error in inline function
- From: "dirk at cle-mens dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 24 Feb 2005 12:21:51 -0000
- Subject: [Bug c++/20185] assignment error in inline function
- References: <20050224102935.20185.dirk@cle-mens.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From dirk at cle-mens dot de 2005-02-24 12:21 -------
(In reply to comment #1)
> Invalid for the same reason as PR 20184...
>
I get the same failure if I use (little endian system)
inline data::operator uint64 () const
{ return *reinterpret_cast<const uint64*>(this); }
or
inline data::operator uint64 () const
{ return *reinterpret_cast<const uint64*>(&lo); }
or
inline data::operator uint64 () const
{ return *(uint64*)&lo; }
It looks like an optimation failure.
The function has to copy 64 bits, but it only copies the low 32 bits into the
result. For verifying this, I have changed the values of table 'tab[]' into
{1,1,1,1,1}
Let's have a lokk into the assembler listing
movl $1, -48(%ebp)
movl $0, -44(%ebp) // this is data::data(1) -> u64
pushl %edx // the hi-32-bits of u64, but edx was not set
movl -48(%ebp), %eax // the low-32-bit of u64
pushl %eax
pushl $.LC3
call printf
And again: This failure appears only with the combination of inline and the
option -O2.
-------
Another question: I marked this bug 'reopen' while I'm posting this. Is this the
correct way?
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20185