From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6872 invoked by alias); 22 Aug 2018 22:01:51 -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 6857 invoked by uid 89); 22 Aug 2018 22:01:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Aug 2018 22:01:49 +0000 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4D83581DE9; Wed, 22 Aug 2018 22:01:48 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-12.rdu2.redhat.com [10.10.112.12]) by smtp.corp.redhat.com (Postfix) with ESMTP id 29A49308BDA8; Wed, 22 Aug 2018 22:01:46 +0000 (UTC) Subject: Re: [PATCH][Middle-end]patch for fixing PR 86519 To: Qing Zhao , Rainer Orth Cc: gcc-patches References: <885E5FDA-DB64-4BEF-A476-16F2CF879E04@oracle.com> <08e76de9-c88f-4404-d5ae-21a8835190a9@redhat.com> <560DF293-03DF-4F82-A331-D971B05FB0D4@oracle.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <5971cdf7-717a-6b82-75d7-67340f7309b5@redhat.com> Date: Wed, 22 Aug 2018 22:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <560DF293-03DF-4F82-A331-D971B05FB0D4@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg01398.txt.bz2 On 08/22/2018 11:05 AM, Qing Zhao wrote: > >> On Aug 22, 2018, at 10:50 AM, Rainer Orth wrote: >> >> Hi Qing, >> >>> From the comments you put into PR86519, for SPARC, looks like that only >>> 32-bit sparc has the problem. >>> sparcv9 does NOT have the same issue. >>> >>> I was trying to find the string to represent 32-bit sparc target, but >>> haven’t found it. >>> >>> my guess is: sparc32*-*-*, is this correct? >> >> no, certainly not. You need to use something like sparc*-*-* && ilp32 >> to catch the 32-bit multilib in both sparc-*-* and sparcv9-*-* >> configurations. This is similar to { i?86-*-* x86_64-*-* } && ilp32 on x86. > > thanks for the info. > >> >> I'm still doubtful that enumerating target after target which all fail >> the original test for unrelated reasons is the way to go, especially >> given that there are others affected besides mips and sparc. > > I am not sure, either. > > however, given the available directives provided in testing suite, what’s the better solution > to this problem? We could move the test into the i386 target specific test directory. It'll still get good coverage that way and it'll be naturally restricted to a target where we don't have to worry about the function name we're scanning for showing up in undesirable contexts. Another approach might be to scan the RTL dumps. But if there were a target that didn't have direct jumps and requires a hi+lo_sum style sequence to load a symbolic constant it would fail. jeff