From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51923 invoked by alias); 8 Nov 2017 17:33:45 -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 51869 invoked by uid 89); 8 Nov 2017 17:33:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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=HX-Google-Smtp-Source:sk:AGs4zMb X-HELO: mail-ot0-f169.google.com Received: from mail-ot0-f169.google.com (HELO mail-ot0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Nov 2017 17:33:43 +0000 Received: by mail-ot0-f169.google.com with SMTP id i19so2949425ote.13 for ; Wed, 08 Nov 2017 09:33:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ICvNT8XZzyLq9hjlho25A4qdVkbU05lckSKSm00B1ug=; b=VsXK/6RtKD8WDkdm4mF/8Q3PsIDjGMXoznRAxBaywhi7RkEhTl7Nvmd1VI1KXsjg/D raXb7eTT4qf9l1B+p6p1NLZLeI13O7WQ+Ok6FY3ZUfJYJtjiDqQ2N8shUfiKzrR/dksB T4ChEGZ/JOs5pZWXYGptUvhxOJyowjkGBdq+7ekVmNwSR8Du1U3Ti6pg6cGFXei48Znv RCXEljoNZJEoFz1wSwP+gFHuNF0nsOAuwe4K7IYq0JIjvBslwbAdrLLW/+U4GPTjUnml JUO7tvzGh78lQYS0xkCAlkcsHWeSCTKmQSOOv7Yt4aC9+zVz0AeZ9MxuoxifjjWDPf8H nb0A== X-Gm-Message-State: AJaThX6cs77ZIjAbo5IAtLWz24ObsSa4jonI/+g4aBbDw3Lb9jjl2qjH Zq83epH06Qbf3mMgkcIuaLg= X-Google-Smtp-Source: AGs4zMbSZNKiEELM4axhj9pLqF4kcrRH+U+EqeZqUNPiO7osMOrEfoSYwsxrYwRyz3Jf5uGLfYkLCQ== X-Received: by 10.157.52.38 with SMTP id v35mr783667otb.90.1510162421496; Wed, 08 Nov 2017 09:33:41 -0800 (PST) Received: from localhost.localdomain (75-171-240-43.hlrn.qwest.net. [75.171.240.43]) by smtp.gmail.com with ESMTPSA id j7sm2048428otd.68.2017.11.08.09.33.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 09:33:40 -0800 (PST) Subject: Re: [001/nnn] poly_int: add poly-int.h To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org References: <871sltvm7r.fsf@linaro.org> <87vaj5u7id.fsf@linaro.org> <87po8t5d55.fsf@linaro.org> <1b724f75-7515-08f7-a783-d86fb1fe8bf8@gmail.com> <87375oww6b.fsf@linaro.org> From: Martin Sebor Message-ID: Date: Wed, 08 Nov 2017 17:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87375oww6b.fsf@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00638.txt.bz2 On 11/08/2017 09:51 AM, Richard Sandiford wrote: > Martin Sebor writes: >> On 11/08/2017 02:32 AM, Richard Sandiford wrote: >>> Martin Sebor writes: >>>> I haven't done nearly a thorough review but the dtor followed by >>>> the placement new in the POLY_SET_COEFF() macro caught my eye so >>>> I thought I'd ask sooner rather than later. Given the macro >>>> definition: >>>> >>>> + The dummy comparison against a null C * is just a way of checking >>>> + that C gives the right type. */ >>>> +#define POLY_SET_COEFF(C, RES, I, VALUE) \ >>>> + ((void) (&(RES).coeffs[0] == (C *) 0), \ >>>> + wi::int_traits::precision_type == wi::FLEXIBLE_PRECISION \ >>>> + ? (void) ((RES).coeffs[I] = VALUE) \ >>>> + : (void) ((RES).coeffs[I].~C (), new (&(RES).coeffs[I]) C (VALUE))) >>>> >>>> is the following use well-defined? >>>> >>>> +template >>>> +inline poly_int_pod& >>>> +poly_int_pod::operator <<= (unsigned int a) >>>> +{ >>>> + POLY_SET_COEFF (C, *this, 0, this->coeffs[0] << a); >>>> >>>> It looks to me as though the VALUE argument in the ctor invoked >>>> by the placement new expression is evaluated after the dtor has >>>> destroyed the very array element the VALUE argument expands to. >>> >>> Good catch! It should simply have been doing <<= on each coefficient -- >>> I must have got carried away when converting to POLY_SET_COEFF. >>> >>> I double-checked the other uses and think that's the only one. >>> >>>> Whether or not is, in fact, a problem, it seems to me that using >>>> a function template rather than a macro would be a clearer and >>>> safer way to do the same thing. (Safer in that the macro also >>>> evaluates its arguments multiple times, which is often a source >>>> of subtle bugs.) >>> >>> That would slow down -O0 builds though, by introducing an extra >>> function call and set of temporaries even when the coefficients >>> are primitive integers. >> >> Would decorating the function template with attribute always_inline >> help? > > It would remove the call itself, but we'd still have the extra temporary > objects that were the function argument and return value. Sorry, I do not want to get into another long discussion about trade-offs between safety and efficiency but I'm not sure I see what extra temporaries it would create. It seems to me that an inline function template that took arguments of user-defined types by reference and others by value should be just as efficient as a macro. From GCC's own manual: 6.43 An Inline Function is As Fast As a Macro https://gcc.gnu.org/onlinedocs/gcc/Inline.html If that's not the case and there is a significant performance penalty associated with inline functions at -O0 then GCC should be fixed to avoid it. Martin