From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 73EA13858D28 for ; Sat, 4 Dec 2021 00:10:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73EA13858D28 Received: by mail-wm1-x332.google.com with SMTP id 133so3677973wme.0 for ; Fri, 03 Dec 2021 16:10:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=gryNkJQdnUgnxJLIpgGjHJyomHRRigcemsPYiT6GCR4=; b=kfU/zUAtiQqw7eYv0naemwjqWr2eoVUUfyflGFxBwR9kG1uQov/90eya0hWB5lpzZ+ 6q9gVdZivtzGWR0EiwypLLsCvujESW1eQCxdaNXJPNucNAosTk+mAhzxACgp/d+yldo5 vWifVdb7JvB8qxuMuUDALerBsS32ORFLr5KXqI++tpWYTSZ8Bs9+LjVMd+yjF0PYtYvC CU//83XsaIvaVM8tJaxZcDsJTB9jD9rNHg9ICpMWgY9TWy8vuvOouMPtOAhlmod74Vxg RSKL/MKTtPXjazHkAwGy37TgVFpl75FeiHxDOijEN/W2WASI14swj9fN5KNmBzs7x3b3 W+vg== X-Gm-Message-State: AOAM531RpcQUWPqVbF681V3hH2hujvXu9ZM+H9TEmjjXrffG528onbFL /C0hweHvyL5oNKHHPn0Tp2w= X-Google-Smtp-Source: ABdhPJy08wYVywT6t45crV7mNVC2LOrSjYiqH1PXPI5SzKvNwr/r0PPmEfOdXG6MC2bofqpHRkstjg== X-Received: by 2002:a05:600c:3586:: with SMTP id p6mr18973214wmq.34.1638576632551; Fri, 03 Dec 2021 16:10:32 -0800 (PST) Received: from [10.29.0.6] ([188.241.83.106]) by smtp.gmail.com with ESMTPSA id ay29sm3804938wmb.44.2021.12.03.16.10.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Dec 2021 16:10:32 -0800 (PST) Message-ID: <41dcf936-cfca-0d17-4206-b3d1d5e415c1@gmail.com> Date: Sat, 4 Dec 2021 01:10:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: odd internal failure Content-Language: en-US To: Gary Oblock , David Malcolm , Richard Biener Cc: "gcc@gcc.gnu.org" References: <332033ff89dcde61932adacd4d509cded5728bd2.camel@redhat.com> From: Gabriel Ravier In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2021 00:10:36 -0000 On 12/4/21 00:54, Gary Oblock via Gcc wrote: > David, > > Thanks, I've bookmarked your advice. I do use gdb but I've always > found the macros in common use are the biggest hurdle. In addition > C++ has its own associated difficulties. > > Note, in the past working on other compilers I've always tried to have > a function version of the macros available. > > #if USE_FUNCTIONS > foo_t > MUMBLE( grumble_t *g) > { > return FU( BAR(g)); > } > #else > MUMBLE(g) FU(BAR(g)) > #endif > > There are many advantages to this. Some are, better type checking, > being able to step into them and invoke them in gdb "p MUMBLE(x)". > > Thanks again, > > Gary Shouldn't it be possible to use `-ggdb3` when compiling GCC to get debug information that includes macros ? It seems like that'd avoid having to manually define a bunch of equivalent functions for the sole purpose of being able to step through them. > > ________________________________ > From: David Malcolm > Sent: Thursday, December 2, 2021 6:04 AM > To: Richard Biener ; Gary Oblock > Cc: gcc@gcc.gnu.org > Subject: Re: odd internal failure > > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] > > > On Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote: >> On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock >> wrote: >>> Richard, >>> >>> I rebuilt at "-O0" and that particular call now works but on a call >>> to >>> the same function with a different offset it fails. 😱 >> use a debugger to see why > In case you haven't seen them, I put together some tips on debugging > GCC here: > https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html > https://github.com/davidmalcolm/gcc-newbies-guide/blob/master/debugging.rst > > Inserting print statements only gets you so far; at some point you > really need a debugger. > > Dave > >>> Thanks, >>> >>> Gary >>> >>> >>> ________________________________ >>> From: Richard Biener >>> Sent: Wednesday, December 1, 2021 1:09 AM >>> To: Gary Oblock >>> Cc: gcc@gcc.gnu.org >>> Subject: Re: odd internal failure >>> >>> [EXTERNAL EMAIL NOTICE: This email originated from an external >>> sender. Please be mindful of safe email handling and proprietary >>> information protection practices.] >>> >>> >>> On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc >>> wrote: >>>> What is happening should be trivial to determine but for some >>>> reason it's >>>> not. I'd normally bounce this off a coworker but given the pandemic >>>> and modern dispersed hiring practices it's not even remotely >>>> possible. >>>> >>>> I'm making this call and tree_to_uhwi is failing on an internal >>>> error. >>>> That's normally easy to fix, but here is where the weirdness kicks >>>> in. >>>> >>>> unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset); >>>> >>>> tree_to_uhwi from tree.h is: >>>> >>>> extern inline __attribute__ ((__gnu_inline__)) unsigned >>>> HOST_WIDE_INT >>>> tree_to_uhwi (const_tree t) >>>> { >>>> gcc_assert (tree_fits_uhwi_p (t)); >>>> return TREE_INT_CST_LOW (t); >>>> } >>>> >>>> and >>>> >>>> tree_fits_uhwi_p from tree.c is >>>> >>>> bool >>>> tree_fits_uhwi_p (const_tree t) >>>> { >>>> return (t != NULL_TREE >>>> && TREE_CODE (t) == INTEGER_CST >>>> && wi::fits_uhwi_p (wi::to_widest (t))); >>>> } >>>> >>>> Here's what this instrumentation shows (DEBUG_A is an indenting >>>> fprintf to >>>> stderr.) >>>> >>>> DEBUG_A ("TREE_CODE(offset) = %s && ", code_str (TREE_CODE >>>> (offset))); >>>> DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ? >>>> "true" : "false"); >>>> DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p >>>> (offset) ? "true" : "false"); >>>> >>>> TREE_CODE(offset) = INTEGER_CST && fits true >>>> tree_fits_uhwi_p(offset) true >>>> >>>> By the way, offset is: >>>> >>>> _Literal (struct BASKET * *) 8 >>>> >>>> And it's an operand of: >>>> >>>> MEM[(struct BASKET * *)&perm + 8B] >>>> >>>> Any clues on what's going on here? >>> it should just work. >>> >>>> Thanks, >>>> >>>> Gary >>>> >>> Btw, try to setup things so you don't spam below stuff to public >>> mailing lists. >>> >>>> CONFIDENTIALITY NOTICE: This e-mail message, including any >>>> attachments, is for the sole use of the intended recipient(s) and >>>> contains information that is confidential and proprietary to Ampere >>>> Computing or its subsidiaries. It is to be used solely for the >>>> purpose of furthering the parties' business relationship. Any >>>> unauthorized review, copying, or distribution of this email (or any >>>> attachments thereto) is strictly prohibited. If you are not the >>>> intended recipient, please contact the sender immediately and >>>> permanently delete the original and any copies of this email and >>>> any attachments thereto. >>>>