This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: subreg question
On Thu, Dec 13, 2001 at 12:39:03PM -0800, Dale Johannesen wrote:
>
> On Thursday, December 13, 2001, at 12:28 PM, Daniel Jacobowitz wrote:
>
> >On Thu, Dec 13, 2001 at 12:21:33PM -0800, Dale Johannesen wrote:
> >>
> >>On Thursday, December 13, 2001, at 10:16 AM, Aldy Hernandez wrote:
> >>
> >>>>>>>>"Dale" == Dale Johannesen <dalej@apple.com> writes:
> >>>
> >>>>What cases of subreg are supposed to be handled exactly?
> >>>>double x(float y) {
> >>>> double z;
> >>>> *((float *)&z) = y; <-- boo!
> >>>> return z; }
> >>>
> >>>i believe this is invalid code, hence implementation dependent. You
> >>>can't access an lvalue as a different type as it was declared.
> >>
> >>I don't see why not. (C89) 3.3.4 says the cast might produce an invalid
> >>pointer if it's not aligned properly, which is not the case here.
> >>Other than that I don't find any relevant restriction in the standard.
> >>What did you have in mind?
> >>(FWIW, gcc doesn't warn about this even with -pedantic.)
> >
> >It's not an invalid pointer. It doesn't alias with Z, though.
>
> Why not?
The C standard's aliasing rules. *((float *)&z) is an object of type
float; double is a different type than float; z is an object of type
double; *((float *)&z) and z can not alias.
> >That
> >assignment does not define Z, but only clobbers some memory.
>
> Seems to me it defines however much of Z is covered by a float-sized
> object (4 out of 8 bytes, on most machines). The other half of Z,
> and its value, are indeed undefined. If we had another assignment
> to *((float *)((char*)&z+4)), then all of Z would be defined (somehow).
It sets that memory, but it doesn't define Z. The fact that it clobbers Z
is somewhat incidental.
> >You don't
> >get a warning because no one ever wrote the warning code for alias
> >violations; but this returns an undefined value, not y.
>
> Certainly. I'm not suggesting this particular example does something
> useful, just questioning the generated rtl. Anyway, even an invalid
> program doesn't justify generating invalid rtl.
Of course :)
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer