From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1AFF4385840F for ; Thu, 2 Dec 2021 14:23:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1AFF4385840F Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-582-9oHctW8QP6SpJFZXqinEnw-1; Thu, 02 Dec 2021 09:23:23 -0500 X-MC-Unique: 9oHctW8QP6SpJFZXqinEnw-1 Received: by mail-qv1-f69.google.com with SMTP id q2-20020a05621419e200b003aeeeff5417so39236685qvc.9 for ; Thu, 02 Dec 2021 06:23:23 -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=VYYq+QV3s0zpjH4TrvWh7Ei7oReCUNcA5fg/P9RAD5U=; b=hIINkpOidcQvXtp8fIoqF3+IXm5IGN20WZOoY32l457j4Jh5wQXCLhhGLyYbEt/aOG 9xNhNlteA2MfyAPpGpJJUH07ZgRpDjP3r245m/OjAYjEZ2vpEM11HHP/oSBi8HEPWa42 iI2nZlaj+pHt+o5M9jY54Nc5FIj6bW59+nnp6iaFA1T7gt0/mHS77hq4KrCrjPdKrWkI 13I7G03UC09Rsp8ixkrUCJ6DsDJiha/SOrgaQJdtSnpSVHTz0l4miGwCDvijNrvNAgp8 /zDXnJUzq6ktvASMV0rRvqaEeyWaMEpqh2ACc/xbW6uT/cdgLUCxgrGookn+93LEBHPH E66w== X-Gm-Message-State: AOAM531IjvHHYGjVWCV+mIXzSFpR6UDGWkCGWwmqawDqpITx4thvMwlB GFF9E28u8QO+ICtiDIpbuZjnDcxtK9nT0VDZ0u9zoOa3Vvvn/ApKeFnUURW1sjPSjl+NMCkdqbE j6b1BaBwDrwlixI6pRA== X-Received: by 2002:a05:622a:1053:: with SMTP id f19mr14010102qte.451.1638455002418; Thu, 02 Dec 2021 06:23:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJxTcOiYYsv9OIYkMrkqcbrK2fLkAW1Fx+SV4wfKJE41HBe4eHQlzRMuo8Z+PoLcGfkSWff+Tw== X-Received: by 2002:a05:622a:1053:: with SMTP id f19mr14010079qte.451.1638455002211; Thu, 02 Dec 2021 06:23:22 -0800 (PST) Received: from [192.168.1.113] ([69.165.238.126]) by smtp.gmail.com with ESMTPSA id bm25sm7884qkb.4.2021.12.02.06.23.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Dec 2021 06:23:21 -0800 (PST) Message-ID: <3bb6317f-b049-13f1-1bac-6ffd753e9685@redhat.com> Date: Thu, 2 Dec 2021 09:23:20 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: [PR103437] [committed] IRA: Process multiplication overflow in priority calculation for allocno assignments To: Jakub Jelinek Cc: "gcc-patches@gcc.gnu.org" References: <116e765c-ea89-47f4-600f-af115dd561c3@redhat.com> <20211202140021.GH2646553@tucnak> From: Vladimir Makarov In-Reply-To: <20211202140021.GH2646553@tucnak> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 14:23:27 -0000 On 2021-12-02 09:00, Jakub Jelinek wrote: > On Thu, Dec 02, 2021 at 08:53:31AM -0500, Vladimir Makarov via Gcc-patches wrote: >> The following patch fixes >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437 >> >> The patch was successfully bootstrapped and tested on x86-64. There is no >> test as the bug occurs on GCC built with sanitizing for an existing go test. > I'm afraid we can't use __builtin_smul_overflow, not all system compilers > will have that. > But, as it is done in int and we kind of rely on int being 32-bit on host > and rely on long long being 64-bit, I think you can do something like: > long long priorityll = (long long) mult * diff; > priority = priorityll; > if (priorityll != priority > ... > > My 1st version of the patch was based on long long but the standard does not guarantee that int size is smaller than long long size.  Although it is true for all targets supported by GCC. Another solution would be to switching to int32_t instead of int for costs but it will require a lot of changes in RA code. I see your point for usage system compiler different from GCC and LLVM.  I guess I could change it to #if __GNUC__ >= 5 current code #else long long code #endif What do you think?