From owner-freebsd-toolchain@freebsd.org Sun Jan 21 01:05:57 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58919ED22BD for ; Sun, 21 Jan 2018 01:05:57 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic312-37.consmr.mail.ne1.yahoo.com (sonic312-37.consmr.mail.ne1.yahoo.com [66.163.191.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 296267338C for ; Sun, 21 Jan 2018 01:05:56 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1516496750; bh=G5Q6Fpc/nM9NOPjWGBD1moffyv9tb+m82MDIwe44XOs=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=nO1r2DKFoDPudVZyERTC0bmQ2z5tuWRbgHhY3OmhntQ4/JonkOFZ7911qHh+UYEV5EoHH5GXRQSP1lMvU0A7ZTVZx/piAaqirXq6Lmi/oXMFDIAVau+JW7a3UWDAxIyHjSEzdCWFpVd827HbokglUhAZE5C0vmi93DOav4nPtJPAxE0kO/wcAe8gEVcZu+//isWyPct0GixkyRO0NJ11p5detW30pJAB1IINYkwgr9VcNS9RMB3GyUjFbUS8+So+cF1RlVX7KzxjQgVcfpEBakMwGV9sewlnRhg+6nqJZ6ZtDQOfjesinm6JEKvIEooFuW5GeHeqOyQmxx64tYJEfQ== X-YMail-OSG: 1WAF3FoVM1mWIts4T6Esu_LtUSHVBK8xXY47nQ6mQxBnzRss3wnYplZkFeOZrg7 79RDFxvnivGReqgG031rNMXVQWc7o5BEaUqdI48CqBlhE0NFeQ8kxYAc5Dira.lHkb6YLqDm6SKS c.ebFp3XsGXZ90uik5t3WzredpwisHUPH5iCpyV7iIRahKWr4gETS_FPpU9A9OjPKBV9KxWSiUs8 Yk5NKtNhiJqudlZD97tVlNbccMFGqg9k7vZjWLp3DzFGGXmXl5LoLXfhHuhrBgbuAmxP5HQ1msD4 E_kKehUjTbXstKmKGF8AAmwjRLPXwbTyqCG9ZmSJIYQU_QQuBeyucaahFjXdZ8S6c8hLWFF_ynFk xfFZDbWQZDmHUBK6r3WaUTVieNaklc0oHDUWoAz4PMMMJwAwfloJ.mO6jZ11jXBu10t_zqKpzwL6 Y8BGXxavay1HANqFIeJ.EgxjK_wcZ9sbWe_gwnMcBehZGb5btYKVTB_9PSZWU18Opxc4Ry2ryqFT AlaNXNu.8uQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Sun, 21 Jan 2018 01:05:50 +0000 Received: from smtp235.mail.ne1.yahoo.com (EHLO [192.168.0.8]) ([10.218.253.206]) by smtp406.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 57f354ca5d4b331749f470663f89717a; Sun, 21 Jan 2018 01:05:48 +0000 (UTC) Subject: Re: Attribute alloc__size use and clang 5.0.1 vs. gcc7 (e.g.): __builtin_object_size(p,1) and __builtin_object_size(p,3) disagreements result To: Mark Millard , FreeBSD Toolchain , FreeBSD Hackers References: <1AA0993D-81E4-4DC0-BBD9-CC42B26ADB1C@yahoo.com> From: Pedro Giffuni Message-ID: <8c4c5985-885a-abf7-93df-0698c645d36e@FreeBSD.org> Date: Sat, 20 Jan 2018 20:05:48 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 01:05:57 -0000 Very interesting , thanks for running such tests ... On 01/20/18 18:59, Mark Millard wrote: > [Noting a typo in the program source, and > so in the output text: the 2nd occurance of: "my_calloc_alt0 > should have been: "my_calloc_alt1 > . Hand edited corrections below for clarity.] > > On 2018-Jan-20, at 3:27 PM, Mark Millard wrote: > >> [Bugzilla 225197 indirectly lead to this. >> Avoiding continuing there.] >> >> I decided to compare some alternate uses of >> __attribute__((alloc_size(. . .))) compiled >> and run under clang 5.0.1 and gcc7. I did not >> get what I expected based on prior discussion >> material. >> >> This is an FYI since I do not know how important >> the distinctions that I found are. >> >> Here is the quick program: >> >> # more alloc_size_attr_test.c >> #include >> #include >> >> __attribute__((alloc_size(1,2))) >> void* my_calloc_alt0(size_t n, size_t s) >> { >> void* p = calloc(n,s); >> printf("calloc __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n" >> ,(long) __builtin_object_size(p, 0) >> ,(long) __builtin_object_size(p, 1) >> ,(long) __builtin_object_size(p, 2) >> ,(long) __builtin_object_size(p, 3) >> ); >> return p; >> } >> >> __attribute__((alloc_size(1))) __attribute__((alloc_size(2))) >> void* my_calloc_alt1(size_t n, size_t s) >> { >> void* p = calloc(n,s); >> printf("calloc __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n" >> ,(long) __builtin_object_size(p, 0) >> ,(long) __builtin_object_size(p, 1) >> ,(long) __builtin_object_size(p, 2) >> ,(long) __builtin_object_size(p, 3) >> ); >> return p; >> } >> >> int main() >> { >> void* p = my_calloc_alt0(2,7); >> printf("my_calloc_alt0 __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n" >> ,(long) __builtin_object_size(p, 0) >> ,(long) __builtin_object_size(p, 1) >> ,(long) __builtin_object_size(p, 2) >> ,(long) __builtin_object_size(p, 3) >> ); >> void* q = my_calloc_alt1(2,7); >> printf("my_calloc_alt0 __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n" > The above line should have been: > > printf("my_calloc_alt1 __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n" > >> ,(long) __builtin_object_size(q, 0) >> ,(long) __builtin_object_size(q, 1) >> ,(long) __builtin_object_size(q, 2) >> ,(long) __builtin_object_size(q, 3) >> ); >> } >> >> # uname -apKU >> FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M amd64 amd64 1200054 1200054 >> >> The system-clang 5.0.1 result was: >> >> # clang -O2 alloc_size_attr_test.c > The later outputs are edited for clarity: > >> # ./a.out >> calloc __builtin_object_size 0,1,2,3: 14, 14, 14, 0 >> my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 >> calloc __builtin_object_size 0,1,2,3: 14, 14, 14, 0 > my_calloc_alt1 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 >> The lang/gcc7 result was: >> >> # gcc7 -O2 alloc_size_attr_test.c >> >> # ./a.out >> calloc __builtin_object_size 0,1,2,3: -1, -1, 0, 0 >> my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 14 >> calloc __builtin_object_size 0,1,2,3: -1, -1, 0, 0 > my_calloc_alt1 __builtin_object_size 0,1,2,3: 14, 7, 14, 14 >> I'll ignore that gcc does not provide actual sizes >> via __builtin_object_size for calloc use. >> >> Pairing the other lines for easy comparison, with >> some notes mixed in: >> >> __attribute__((alloc_size(1,2))) style: >> my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 (system clang) >> my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 14 (gcc7) >> >> __attribute__((alloc_size(1))) __attribute__((alloc_size(2))) style: > my_calloc_alt1 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 (system clang) > my_calloc_alt1 __builtin_object_size 0,1,2,3: 14, 7, 14, 14 (gcc7) So on GCC7 it appears  __attribute__((alloc_size(1,2))) != __attribute__((alloc_size(1))) __attribute__((alloc_size(2))) This is not good as it was the base for r280801 .. related to the old discussion about deprecating old compilers that don't accept VA_ARGS. I am unsure if its a regression but it appears that for clang it is the same thing though. >> Thus. . . >> >> For __attribute__((alloc_size(1))) __attribute__((alloc_size(2))): >> __builtin_object_size(p,1) is not equivalent (clang vs. gcc7) >> >> For both of the alloc_size usage styles: >> __builtin_object_size(p,3) is not equivalent (clang vs. gcc7) >> >> This means that the two style of alloc_size use are not >> equivalent across some major compilers/toolchains. This is actually not a surprise: GCC and clang implementation of __alloc_size__ has differences due to limitations on the LLVM IR (or the fact there is one). The alloc_size attribute is basically only used for the so-called FORTIFY_SOURCE feature that depends on GCC with some support from the C-library: last time I looked clang didn't support the compile-time checks very well. The attributes are mostly unused in FreeBSD at this time but, GCC7 -Walloc-size-larger-than=size depends on them (I have never tested that though). FWIW, we had an unfinished GSoC that attempted to implement FORTIFY_SOURCE but we got stuck on the lack of clang support and other issues. Lately Google has been spending some effort on it but it is more limited and doesn't match the GCC behavior. >> But I do not know if either of the differences is a problem or >> not. >> >> >> Note: without a sufficient -O all the figures can be >> the mix of -1's and 0's. > > === > Mark Millard > marklmi at yahoo.com > ( markmi at dsl-only.net is > going away in 2018-Feb, late) >