https://sourceware.org/bugzilla/show_bug.cgi?id=20068
Bug ID: 20068
Summary: GAS complains about ‘Error: floating point number
invalid‘ when producing a literal pool.
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: chuazl at comp dot nus.edu.sg
Target Milestone: ---
Created attachment 9248
--> https://sourceware.org/bugzilla/attachment.cgi?id=9248&action=edit
Change the type of padding to O_constant
Assembling the following ARM assembly will result in gas complaining:
LDR R0, =0x12345678
FLDD D9, =0xfff000000fff
.LTORG
‘Error: floating point number invalid‘
Adding an additional 4 bytes into the literal pool will cause GAS to assemble
without any errors.
LDR R0, =0x12345678
LDR R0, =0x87654321
FLDD D9, =0xfff000000fff
.LTORG
Debugging GAS reveals that the error is generated from emit_expr_with_reloc(),
more specifically, it fails this test :
if (op == O_big && exp->X_add_number <= 0)
Digging further, this expression is generated due to alignment for a 8 byte
long literal being added to the pool, more specifically in add_to_lit_pool().
If the pool is not 8 byte aligned and a 8 byte literal is added to the pool, a
4 byte pad will be generated with the following code.
<...>
else if (pool_size & 0x7)
{
<....>
pool->literals[entry] = inst.reloc.exp;
pool->literals[entry].X_add_number = 0;
pool->literals[entry++].X_md = (PADDING_SLOT << 8) | 4;
pool->next_free_entry += 1;
pool_size += 4;
}
Since the current exp is of type O_big, the padding expression will be of type
O_big with X_add_number = 0 failing the above test.
Workaround patch:
Change the type of the padding to O_constant. Again, not too sure about the
correctness.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
