This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/66086] Casting a pointer to an uintptr_t and later to a double confuses the optimizer
- From: "agriff at tin dot it" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 10 May 2015 12:32:18 +0000
- Subject: [Bug c/66086] Casting a pointer to an uintptr_t and later to a double confuses the optimizer
- Auto-submitted: auto-generated
- References: <bug-66086-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66086
--- Comment #6 from Andrea Griffini <agriff at tin dot it> ---
The question is however: with a 32-bit intptr_t and a 64-bit double (that
has no problem with ints up to 2^53) is it legal for gcc to avoid
initialization of the memory? This is what gcc is doing.
Where it's written in the standard that you cannot store an intptr_t value
in a double and get it back? Is the fact that in some other hypothetical
platform with some other hypothetical intptr_t size it could possibly
happen that you lose accuracy enough to allow not performing a write when
asked to?
On Sun, May 10, 2015 at 12:08 PM, pinskia at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66086
>
> --- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> > note that on x86-64 the used values are 48-bit only and a double
> provides enough
> > accuracy to store them correctly.
>
> These kind of assumptions are bad and very unportable. I can think of
> targets
> were pa and va are going to be bigger than 48bits.
>
> --
> You are receiving this mail because:
> You reported the bug.
>