From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31426 invoked by alias); 28 Jan 2020 12:02:06 -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 31414 invoked by uid 89); 28 Jan 2020 12:02:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:JE0GsRv-mcJ7V7, H*f:sk:BSyEs9J, H*i:CAAgBjMn, H*f:JE0GsRv-mcJ7V7 X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Jan 2020 12:02:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580212923; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zYO/8nLtKJuj0W0385XkgFi8dgKoebmmzGSRcUORykU=; b=JcTJIwgb++KvezB0zsKd4AdDOWQ7H06OaTH3svRoJyiSxLLt373TMFcf8mhlT6leBjOxpe 89ke64pluQBtVGp9OFE9fOdw1NZAaKB/VHiP/GE7TYH9EUBykj7SuCaHRcr7hEK0gnbNpt 1CN8poT/iH/qnonfZXUf6fiqgIN86jA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-20-buC18TeyN2KBCGHnu4G0yQ-1; Tue, 28 Jan 2020 07:02:00 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 97C30100550E; Tue, 28 Jan 2020 12:01:58 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EF4F760BFB; Tue, 28 Jan 2020 12:01:57 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 00SC1slo031979; Tue, 28 Jan 2020 13:01:54 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 00SC1qOg031978; Tue, 28 Jan 2020 13:01:52 +0100 Date: Tue, 28 Jan 2020 12:25:00 -0000 From: Jakub Jelinek To: Prathamesh Kulkarni Cc: Richard Biener , Joseph Myers , gcc Patches Subject: Re: [RFC] [c-family] PR92867 - Add returns_arg attribute Message-ID: <20200128120152.GY17695@tucnak> Reply-To: Jakub Jelinek References: <20200128113036.GX17695@tucnak> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg01841.txt.bz2 On Tue, Jan 28, 2020 at 05:09:36PM +0530, Prathamesh Kulkarni wrote: > On Tue, 28 Jan 2020 at 17:00, Jakub Jelinek wrote: > > > > On Tue, Jan 28, 2020 at 04:56:59PM +0530, Prathamesh Kulkarni wrote: > > > Thanks for the suggestions. In the attached patch I bumped up value of > > > ERF_RETURNS_ARG_MASK > > > to UINT_MAX >> 2, and use highest two bits for ERF_NOALIAS and ERF_RE= TURNS_ARG. > > > And use fn spec "Z" to store the argument number in fn-spec f= ormat. > > > Does that look OK ? > > > > No. > > > > +#define ERF_RETURN_ARG_MASK (UINT_MAX >> 2) > > > > /* Nonzero if the return value is equal to the argument number > > flags & ERF_RETURN_ARG_MASK. */ > > -#define ERF_RETURNS_ARG (1 << 2) > > +#define ERF_RETURNS_ARG (1 << (BITS_PER_WORD - 2)) > > > > How is size of host int related to BITS_PER_WORD? Not to mention that > > if BITS_PER_WORD is 64 and host int is 32-bit, 1 << (64 - 2) is UB. > Oops sorry. I should have used HOST_BITS_PER_INT. > I assume that'd be correct ? It still wouldn't, 1 << (HOST_BITS_PER_INT - 1) is negative number, you'd need either 1U and verify all ERF_* flags uses, or avoid using the sign bit. The patch has other issues, you don't verify that the argnum fits into the bits (doesn't overflow into the other ERF_* bits), in + char *s =3D (char *) xmalloc (sizeof (char) * BITS_PER_WORD);=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 + s[0] =3D 'Z';=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 + sprintf (s + 1, "%lu", argnum);=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1) sizeof (char) is 1 by definition 2) it is pointless to allocate it and then deallocate (just use automatic array) 3) it is unclear how is BITS_PER_WORD related to the length of decimal encoded string + Z char + terminating '\0'. The usual way is for unsigned numbers to estimate number of digits by counting 3 digits per each 8 bits, in your case of course + 2. More importantly, the "fn spec" attribute isn't used just in gimple_call_return_flags, but also in e.g. gimple_call_arg_flags which assumes that the return stuff in there is a single char and the reaming chars are for argument descriptions, or in decl_return_flags which you haven't modified. I must say I fail to see the point in trying to glue this together into the "fn spec" argument so incompatibly, why can't we handle the fn spec with its 1-4 returns_arg and returns_arg attribute with arbitrary position side-by-side? Jakub