https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #9 from Jeffrey A. Law ---
Yea, I think so -- which would be undefined because the sizes are different
according to the docs you referenced. Which would also invalidate part of my
responses in c#5 and c#7.
It sounds like something o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #8 from Andrew Macleod ---
(In reply to Jeffrey A. Law from comment #7)
> If you're V_C_E-ing to a narrower type, you just ignore the bits outside the
> target type, it's a lot like a narrowing subreg in the RTL world.
>
> I don't kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #7 from Jeffrey A. Law ---
If you're V_C_E-ing to a narrower type, you just ignore the bits outside the
target type, it's a lot like a narrowing subreg in the RTL world.
I don't know what the semantics are for the widening case. IST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #6 from Andrew Macleod ---
and when the precision is different what? assume 0's for the missing bits?
If we allow and want that behaviour, we should change the documentation to
reflect that...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #5 from Jeffrey A. Law ---
The best way to think about V_C_E is that it's the same bits, just viewed in a
different type whereas a cast can do things like sign/zero extension,
truncation of floating point values to integers, etc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #2 from Richard Biener ---
Created attachment 46610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46610&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
