This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/66086] Casting a pointer to an uintptr_t and later to a double confuses the optimizer


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.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]