===================================================================
@@ -1373,8 +1373,14 @@
case 1:
if (GET_CODE (x) != CONST_INT)
{
- aligned_p = 0;
- break;
+ /* There is no "unaligned byte" op or generic function to
+ which we can punt, so we have to handle this here. As
+ the expression isn't a plain literal, the generated
+ assembly-code can't be mmixal-equivalent (i.e. "BYTE"
+ won't work) and thus it's ok to emit the default op
+ ".byte". */
+ assemble_integer_with_op ("\t.byte\t", x);
+ return true;
}
fputs ("\tBYTE\t", asm_out_file);
mmix_print_operand (asm_out_file, x, 'B');
Until location views (in gcc-8), there apparently was no need to emit single bytes of data as anything but bare CONST_INTs, neither actual data nor dwarf2 debug. With location views, there's a field within dwarf2 records for inlined subroutines that as assembly code looks as follows in context (cutout of assembly output with -dA for the failing libgcc/unwind-c.c): .uleb128 0x1c !# (DIE (0x3b1) DW_TAG_inlined_subroutine) .4byte 0x95e !# DW_AT_abstract_origin .8byte LBI:49 !# DW_AT_entry_pc .byte LVU:281 !# DW_AT_GNU_entry_view .4byte Ldebug_ranges:0+0x50 !# DW_AT_ranges BYTE 2 !# DW_AT_call_file (/home/hp/x/libgcc/unwind-c.c) BYTE 200 !# DW_AT_call_line BYTE 11 !# DW_AT_call_column .4byte 0x489 !# DW_AT_sibling Note the ".byte LVU:281". The value of LVU:281 is (IIUC) set in a preceding line that says .loc 1 279 1 view LVU:281 so it's defined at the time it's used; no relocs or second-pass fixups needed in the assembler. The preferable "BYTE" pseudodirective (preferable because it's the same pseudo as "mmixal"), handles only literal values. There may supposedly exist other assemblers with similar issues, but I guess we'd have heard from them by now. This is the second patch of two needed to bring back mmix-knuth-mmixware to a buildable state. I'll backport both to gcc-8. Still, I see lots of test-suite failures, both due to LTO problems (linking ELF input to mmo format, with non-code non-data wrapped, but being mishandled by the linker) and to what appears to be another binutils-bug, so no test-results will be posted until I can trim the FAILs down to a level where the sheer volume does not get rejected by the gcc-testresults mailing list; say to the level of the cris-elf results recently posted there. gcc: PR target/85666 * config/mmix/mmix.c (mmix_assemble_integer): Handle byte-size non-CONST_INT rtx:es using assemble_integer_with_op ".byte". brgds, H-P