Re: GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- From: Gil Hamilton <gil_hamilton@xxxxxxxxxxx>
- Date: Tue, 25 Nov 2008 20:51:12 +0100 (CET)
Måns Rullgård <mans@xxxxxxxxx> wrote in
news:yw1x1vwz39z4.fsf@xxxxxxxxxxxxxxxxxxxx:
Carlos Moreno <cm_news@xxxxxxxxxxxxxx> writes:
uint128_t v1=0xFFFFFFFFFFFFFFFF, v2=0xFFFFFFFFFFFFFFFF;
const uint128_t p = static_cast<uint128_t>(v1) * v2;
cout << hex << *(reinterpret_cast<const uint64_t *>(&p)) << *
(reinterpret_cast<const uint64_t *>(&p) + 1) << endl;
The correct output is: 1fffffffffffffffe
And that's what it outputs with -O1 or below. When compiled with
-O2, the output is: 4009400
The C++ encryption might change things, but in C it is invalid to
access something through the "wrong" pointer type. In your case, you
are accessing a uint128_t using a uint64_t pointer, which violates
strict aliasing rules. If you compile this with -Wall, do you get a
warning about that? Does compiling with -fno-strict-aliasing produce
the expected result?
Måns is spot on:
Compiling with -Wstrict-aliasing (or -Wall) generates
"warning: dereferencing type-punned pointer will break strict-aliasing
rules".
And compiling with -fno-strict-aliasing causes the problem to go away.
GH
.
- Follow-Ups:
- Re: GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- From: Måns Rullgård
- Re: GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- References:
- GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- From: Carlos Moreno
- Re: GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- From: Måns Rullgård
- GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- Prev by Date: Re: GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- Next by Date: Re: PC:n maadoitus?
- Previous by thread: Re: GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- Next by thread: Re: GCC bug? (4.2.4 on Ubuntu 8.04 / AMD64)
- Index(es):
Relevant Pages
|
