From patchwork Sun Sep 9 18:31:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 967790 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-485368-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=bitrange.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="CVgFKnfg"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 427fs86zSDz9s3l for ; Mon, 10 Sep 2018 04:31:39 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; q=dns; s=default; b=ydmDyLSVv9Q7saOxhHHTUbUOWuLo3NgAJgLZPoEFR2GDquDM+d 522bfqMFHY1HzPKsgYuyH2nG+g89bHfVX2RqpsWoNW/IShhdrPj2GGZT3lu4PNqH 1MagtBDPgxqWM0pxDN4oS1Xr+zOrVd+cGNzqALUDSQZdeQA3D1SPR+PPg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; s= default; bh=K21Ky9KNjOln5CRBqtPEK1jrdWc=; b=CVgFKnfgcgup4f3jae7s CBwZztI+t02UTa44ZygBOgbMILgZqHL4Ogm5Yco6lwiZEyAtXAzN7b1EVKvb7ulC 4RzSDmpU+44lVFSBkMil1PWrXhcdoVYyHF1mAN1csSx0s+VTZRPl368CG7JtVa2g ab/B/CFj0Jz1z0p/g/+UOHE= Received: (qmail 60079 invoked by alias); 9 Sep 2018 18:31:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 59950 invoked by uid 89); 9 Sep 2018 18:31:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=heard, wrapped, views, dwarf2 X-HELO: arjuna.pair.com Received: from arjuna.pair.com (HELO arjuna.pair.com) (209.68.5.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 09 Sep 2018 18:31:10 +0000 Received: by arjuna.pair.com (Postfix, from userid 3006) id F111A8A51D; Sun, 9 Sep 2018 14:31:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id EEF738A43F; Sun, 9 Sep 2018 14:31:00 -0400 (EDT) Date: Sun, 9 Sep 2018 14:31:00 -0400 (EDT) From: Hans-Peter Nilsson To: gcc-patches@gcc.gnu.org cc: Alexandre Oliva Subject: Committed, PR target/85666 2/2, MMIX: Handle emitting data bytes as non-literals Message-ID: User-Agent: Alpine 2.20.16 (BSF 172 2016-09-29) MIME-Version: 1.0 X-IsSubscribed: yes 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 Index: gcc/config/mmix/mmix.c =================================================================== --- gcc/config/mmix/mmix.c (revision 264163) +++ gcc/config/mmix/mmix.c (working copy) @@ -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');