From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123273 invoked by alias); 17 Dec 2015 12:36:11 -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 123211 invoked by uid 89); 17 Dec 2015 12:36:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Yura, yura, H*r:May, Hx-languages-length:2330 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mailout2.w1.samsung.com Received: from mailout2.w1.samsung.com (HELO mailout2.w1.samsung.com) (210.118.77.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 17 Dec 2015 12:36:09 +0000 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NZI00AAV5O6IC80@mailout2.w1.samsung.com>; Thu, 17 Dec 2015 12:36:06 +0000 (GMT) Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 96.D9.16778.63CA2765; Thu, 17 Dec 2015 12:36:06 +0000 (GMT) Received: from [106.109.9.145] by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0NZI00AY25O4TGA0@eusync2.samsung.com>; Thu, 17 Dec 2015 12:36:06 +0000 (GMT) Subject: Re: [PATCH 1/5] Fix asymmetric comparison functions To: Richard Biener References: <5672787D.6040105@samsung.com> <56727936.4030605@samsung.com> <5672A0D1.2040207@samsung.com> <5672A747.1070806@samsung.com> Cc: GCC Patches , Andrey Belevantsev , Andrew MacLeod , Andrew Pinski , Diego Novillo , Geoff Keating , Jakub Jelinek , Jason Merrill , Steven Bosscher From: Yury Gribov Message-id: <5672AC45.2020008@samsung.com> Date: Thu, 17 Dec 2015 12:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01756.txt.bz2 On 12/17/2015 03:25 PM, Richard Biener wrote: > On Thu, 17 Dec 2015, Yury Gribov wrote: > >> On 12/17/2015 02:59 PM, Richard Biener wrote: >>> On Thu, 17 Dec 2015, Yury Gribov wrote: >>> >>>> On 12/17/2015 02:41 PM, Richard Biener wrote: >>>>> On Thu, 17 Dec 2015, Yury Gribov wrote: >>>>> >>>>>> Some obvious symmetry fixes. >>>>>> >>>>>> Cc-ing >>>>>> * Andrey (Belevantsev) for bb_top_order_comparator >>>>>> * Andrew (MacLeod) for compare_case_labels >>>>>> * Andrew (Pinski) for resort_field_decl_cmp >>>>>> * Diego for pair_cmp >>>>>> * Geoff for resort_method_name_cmp >>>>>> * Jakub for compare_case_labels >>>>>> * Jason for method_name_cmp >>>>>> * Richard for insert_phi_nodes_compare_var_infos, compare_case_labels >>>>>> * Steven for cmp_v_in_regset_pool >>>>> >>>>> So for compare_case_labels we only ever have one label with >>>>> !CASE_LOW - which means you only run into the case that needs >>>>> !CASE_LOW && !CASE_LOW if comparing an element with itself, correct? >>>>> >>>>> In this case (missing "same element" handling rather than symmetry >>>>> fixing) I'd prefer a >>>>> >>>>> if (case1 == case2) >>>>> return 0; >>>>> >>>>> So just to confirm - do the patches also contain same element >>>>> compare fixings? >>>> >>>> Yes, that's a fix for same element. How about adding if + gcc_assert that >>>> both cases can't be NULL otherwise? >>> >>> Well, does qsort require the compare function to result in zero >>> for same elements when the sequence to be sorted doesn't contain >>> duplicates? >> >> Sure, that's part of total ordering requirement in standard. >> >>> If an assert works for you that hints at these places found via static >>> analysis rather than a runtime fuzzer? >> >> Sorry, not sure I fully understood but - yes, adding assertion would typically >> allow for better checking by static analyzers. > > The question was if you actually observed the case to happen with a > testcase (and whatever mungled qsort implementation) or whether > it was a theoretical outcome computed by a static analyzer. > > That is, whether you could hand me a testcase where it happens > or not. Well, this was detected by calling qsort(x, x) and checking that return value is zero in qsort interceptor. So I guess it's more of "theoretical" sort. /Yura