On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak <ubiz...@gmail.com> wrote: >> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >> >>>>> ".quad symbol" isn't really valid for 32bit. >>>> >>>> Why not? We certainly know what value to put there. >>>> >>> >>> x32 doesn't support 64bit relocation, like R_X86_64_64. >>> In many causes, generate >>> >>> .long symbol >>> .long 0 >>> >>> for ".quad symbol" is wrong. Please see: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 >>> >>> for some examples. >> >> Please also see: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 >> >> on why I think this is middle-end/tree-optimization issue. >> > > I still think it is a backend issue.
/* Represents viewing something of one type as being of a second type. This corresponds to an "Unchecked Conversion" in Ada and roughly to the idiom *(type2 *)&X in C. The only operand is the value to be viewed as being of another type. **It is undefined if the type of the input and of the expression have different sizes.** ... DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) We have: <bb 2>: D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx); D.2702_1 = u.d; D.2704_3 = D.2702_1 == D.2709_8; D.2701_4 = (int) D.2704_3; return D.2701_4; Where sizeof (double) = 64 sizeof (ptr_type) = 32. Uros.
