On Thu, Jul 21, 2011 at 7:30 PM, Uros Bizjak ubiz...@gmail.com wrote:
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
On Wed, Jul 20, 2011 at 9:06 PM, H.J. Lu hongjiu...@intel.com wrote:
The testcase is gcc.c-torture/compile/pr45728.c. This patch zero-extends
symbol address to 64bit if needd. OK for trunk?
Thanks.
H.J.
2011-07-20 H.J. Lu hongjiu...@intel.com
PR target/49798
*
On 07/21/2011 09:13 AM, H.J. Lu wrote:
PR target/49798
* config/i386/i386.c (ix86_asm_integer): New.
(TARGET_ASM_INTEGER): Likewise.
This is the updated patch, using the same approach in sparc_assemble_integer.
OK for trunk?
Is there any reason why we don't simply
On Thu, Jul 21, 2011 at 9:15 AM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 09:13 AM, H.J. Lu wrote:
PR target/49798
* config/i386/i386.c (ix86_asm_integer): New.
(TARGET_ASM_INTEGER): Likewise.
This is the updated patch, using the same approach in
On 07/21/2011 09:20 AM, H.J. Lu wrote:
.quad symbol isn't really valid for 32bit.
Why not? We certainly know what value to put there.
I can add a new .xquad directive,
similar to .xword for sparc...
That seems like exactly the same meaningless complication.
r~
On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 09:20 AM, H.J. Lu 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
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
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
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
On 07/21/2011 09:28 AM, H.J. Lu wrote:
On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 09:20 AM, H.J. Lu 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,
On Thu, Jul 21, 2011 at 9:42 AM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 09:28 AM, H.J. Lu wrote:
On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 09:20 AM, H.J. Lu wrote:
.quad symbol isn't really valid for 32bit.
Why not? We certainly
On Thu, Jul 21, 2011 at 6:42 PM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 09:28 AM, H.J. Lu wrote:
On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 09:20 AM, H.J. Lu wrote:
.quad symbol isn't really valid for 32bit.
Why not? We certainly
On 07/21/2011 10:39 AM, Uros Bizjak wrote:
IMO, it is OK to disable 64bit relocations, and that compiler is at
fault here. Consider that something gets written to the d field (see
example of PR49798). Reading a pointer from *m fileld in DImode, we
will get non-zero bits in high 32bits of a
On Thu, Jul 21, 2011 at 11:02 AM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 10:39 AM, Uros Bizjak wrote:
IMO, it is OK to disable 64bit relocations, and that compiler is at
fault here. Consider that something gets written to the d field (see
example of PR49798). Reading a pointer
On Thu, Jul 21, 2011 at 10:30 AM, Uros Bizjak ubiz...@gmail.com wrote:
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
On Thu, Jul 21, 2011 at 10:00 PM, H.J. Lu hjl.to...@gmail.com wrote:
/* 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
On Thu, Jul 21, 2011 at 1:17 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Jul 21, 2011 at 10:00 PM, H.J. Lu hjl.to...@gmail.com wrote:
/* 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
On Thu, Jul 21, 2011 at 10:22 PM, H.J. Lu hjl.to...@gmail.com wrote:
Expand generates:
(insn 8 6 9 (set (reg:SI 68)
(symbol_ref:SI () [flags 0x40] var_decl 0x7fccc360b140
)) p
r49798.c:12 -1
(nil))
(insn 9 8 10 (set (reg:DI 67)
(zero_extend:DI (reg:SI 68)))
On Thu, Jul 21, 2011 at 2:00 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Jul 21, 2011 at 10:22 PM, H.J. Lu hjl.to...@gmail.com wrote:
Expand generates:
(insn 8 6 9 (set (reg:SI 68)
(symbol_ref:SI () [flags 0x40] var_decl 0x7fccc360b140
)) p
r49798.c:12 -1
(nil))
On Thu, Jul 21, 2011 at 11:02 AM, Richard Henderson r...@redhat.com wrote:
On 07/21/2011 10:39 AM, Uros Bizjak wrote:
IMO, it is OK to disable 64bit relocations, and that compiler is at
fault here. Consider that something gets written to the d field (see
example of PR49798). Reading a pointer
The testcase is gcc.c-torture/compile/pr45728.c. This patch zero-extends
symbol address to 64bit if needd. OK for trunk?
Thanks.
H.J.
2011-07-20 H.J. Lu hongjiu...@intel.com
PR target/49798
* config/i386/i386.c (ix86_asm_integer): New.
(TARGET_ASM_INTEGER):
21 matches
Mail list logo
