From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2778 invoked by alias); 17 Jul 2017 10:33:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 130036 invoked by uid 89); 17 Jul 2017 10:33:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=sth X-HELO: mail-lf0-f53.google.com Received: from mail-lf0-f53.google.com (HELO mail-lf0-f53.google.com) (209.85.215.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jul 2017 10:33:29 +0000 Received: by mail-lf0-f53.google.com with SMTP id h22so82647734lfk.3 for ; Mon, 17 Jul 2017 03:33:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=faVKV6bDZp2u1/48DaUZfNIVc7NxNC6BR8aYCzZhdk0=; b=Cn73x9Zop8ROy/HDdCeOH6u9G6xrph/E7/nWU1gmeGBOicq6s7irU/zgAP7KL/jQ4X NWMdqGMVc08hnS28DcHR6KhtZzf+SAvMpEQ7RRvlh+CRxFfXdwQCNk2JYMjMhOkSru1b t2tGrJgxNRII43VC9HRxwzJK0B+qUwNvisLq8uN/VUOseMJckNrAD5ugkzijDuZuIB5j lOEt/NXHzO0vWX5MrPoTPMkIkXes3d57fuwVAtiW8bJX60MbLeFfBa07RNcAkwW8rlXB dLPMetL08ldp8q8lEpGqX2p2rsK27kGxEiG+njFWkImZLDe3JuNrC9jk05PDX2GMpN08 xFCA== X-Gm-Message-State: AIVw111M4rIT8Kl19MtmHkDcGZIRFJTSmDhKx2qamgGjUKOeM6j8lK02 Yl5o3HKCY9TVkovgta4AqpGW601/6hH/Ul0= X-Received: by 10.46.77.81 with SMTP id a78mr4466428ljb.139.1500287607097; Mon, 17 Jul 2017 03:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.31.134 with HTTP; Mon, 17 Jul 2017 03:33:26 -0700 (PDT) In-Reply-To: <2205209.DOC5pnjhMb@polaris> References: <2319634.9b0vxstqzg@polaris> <2205209.DOC5pnjhMb@polaris> From: Richard Biener Date: Mon, 17 Jul 2017 10:33:00 -0000 Message-ID: Subject: Re: [patch] Fix ICE on CONSTRUCTOR containing absolute addresses To: Eric Botcazou Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00957.txt.bz2 On Mon, Jul 17, 2017 at 10:51 AM, Eric Botcazou wrote: >> Apart from the MEM construction where I simply trust you this looks >> ok. Mind adding MEM_REF support for this case as well? > > Do you mean MEM_REF ? Is that possible? Yes. >> Btw, why's simply output_constant_def (TREE_OPERAND (target, 0), 1); >> not correct? > > If you do that, you get a symbol in the constant pool whose value (address) is > arbitrary; here what we want is a fixed value. That being said, given that > the contents of the contant pool is hashed, there is very likely not much > difference in the end, although that would be conceptually incorrect. > >> Isn't this about &*0x1? > > Yes, it's not the address of a constant, it's the address of an object whose > base address is absolute, so &(abs_address)->field[index]. This kind of thing > is not folded by build_fold_addr_expr. So this isn't about global void *x[] = { &((struct Y *)0x12)->foo } but for a local one where supposedly variable indexing is valid (don't we gimplify that)? And + case INDIRECT_REF: + /* This deals with absolute addresses. */ + offset += tree_to_shwi (TREE_OPERAND (target, 0)); + x = gen_rtx_MEM (QImode, + gen_rtx_SYMBOL_REF (Pmode, "origin of addresses")); simply translates 0x12 to &* + 0x12 (where origin == 0 somehow?). I suppose returing directly here and sth like value->base = gen_rtx_SYMBOL_REF (Pmode, "origin of addresses"); value->offset = offset + tree_to_shwi (...); return; would be clearer. Or even value->base = tree-to-rtx (TREE_OPERAND (target, 0)); value->offset = offset; ? > -- > Eric Botcazou