From owner-freebsd-hackers@freebsd.org Sun Apr 16 13:48:00 2017 Return-Path: Delivered-To: freebsd-hackers@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 2DA07D40A98 for ; Sun, 16 Apr 2017 13:48:00 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F01681BEE for ; Sun, 16 Apr 2017 13:47:59 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id 0FC7067; Sun, 16 Apr 2017 15:47:57 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id F161428497; Sun, 16 Apr 2017 15:47:56 +0200 (CEST) Date: Sun, 16 Apr 2017 15:47:56 +0200 From: Jilles Tjoelker To: Kyle Evans Cc: freebsd-hackers@freebsd.org Subject: Re: Replacing libgnuregex Message-ID: <20170416134756.GA88424@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 13:48:00 -0000 On Tue, Apr 11, 2017 at 03:20:58PM -0500, Kyle Evans wrote: > On the other hand, I think I could fairly easily implement most of these > into libc/regex. Here's a summary of what this option entails adding to > libc/regex, from what I've found: > [snip] > * Add backreferences (\1 through \9) to EREs > [snip] Adding this enforces that EREs, like BREs, may sometimes require exponential time to match. I would prefer to avoid that. -- Jilles Tjoelker From owner-freebsd-hackers@freebsd.org Sun Apr 16 14:50:30 2017 Return-Path: Delivered-To: freebsd-hackers@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 F0603D40EEA for ; Sun, 16 Apr 2017 14:50:30 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0063.outbound.protection.outlook.com [104.47.32.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E05C1C56 for ; Sun, 16 Apr 2017 14:50:29 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q7b7A9rtdfhhe0EdgGD173yIs2OrUdofS8XBYKr63OA=; b=XZPm8CmqZ3ivObFDypVVdHD+Zp67/LUzwxQAs9En6l0APbsx508l2UjJjg0YFMYU1OSxE1uknlryZ5fgdy2jjfWpCsBMGjXjiHR4E0mNWD3t+V3n4Vm+NxQhVnCNln+ywGP6qb7cOgmF3p7FaqvRNbCtPk+AA7Loz12N9QawLN0= Received: from BY2PR05CA022.namprd05.prod.outlook.com (10.141.250.12) by CO2PR0501MB1048.namprd05.prod.outlook.com (10.160.7.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Sun, 16 Apr 2017 14:50:27 +0000 Received: from CY1NAM02FT063.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::204) by BY2PR05CA022.outlook.office365.com (2a01:111:e400:2c5f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Sun, 16 Apr 2017 14:50:27 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp1.campus.ksu.edu; Received: from ome-vm-smtp1.campus.ksu.edu (129.130.18.151) by CY1NAM02FT063.mail.protection.outlook.com (10.152.75.161) with Microsoft SMTP Server id 15.1.1019.14 via Frontend Transport; Sun, 16 Apr 2017 14:50:26 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp1.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v3GEoQxO023004 for ; Sun, 16 Apr 2017 09:50:26 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id 4018F248308; Sun, 16 Apr 2017 09:50:26 -0500 (CDT) Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id 0EFB9248306 for ; Sun, 16 Apr 2017 09:50:24 -0500 (CDT) Received: by mail-wr0-f174.google.com with SMTP id l28so72059979wre.0 for ; Sun, 16 Apr 2017 07:50:23 -0700 (PDT) X-Gm-Message-State: AN3rC/6ebb+1W0xOmI2R7w8+coRn5GnjmPUzjrRUZxZFB9c9rssBqW7W r6KSYn7Do4FFkPFaTmR1rCUT04DfVw== X-Received: by 10.223.151.80 with SMTP id r74mr14845930wrb.6.1492354222015; Sun, 16 Apr 2017 07:50:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.39.134 with HTTP; Sun, 16 Apr 2017 07:50:01 -0700 (PDT) In-Reply-To: <20170416134756.GA88424@stack.nl> References: <20170416134756.GA88424@stack.nl> From: Kyle Evans Date: Sun, 16 Apr 2017 09:50:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Replacing libgnuregex To: Jilles Tjoelker CC: X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(979002)(39400400002)(39410400002)(39450400003)(39840400002)(39860400002)(39850400002)(2980300002)(438002)(377454003)(24454002)(189002)(199003)(42186005)(59536001)(221733001)(8676002)(9896002)(8936002)(3480700004)(8576002)(512874002)(55446002)(88552002)(106466001)(61266001)(189998001)(90966002)(84326002)(356003)(53546009)(229853002)(46386002)(38730400002)(6246003)(4326008)(50986999)(6862004)(45336002)(2906002)(98316002)(110136004)(9686003)(93516999)(76176999)(5660300001)(2950100002)(63696999)(75432002)(54356999)(498394004)(236005)(61726006)(305945005)(7116003)(86362001)(55456009)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0501MB1048; H:ome-vm-smtp1.campus.ksu.edu; FPR:; SPF:Pass; MLV:ovrnspm; MX:1; A:1; PTR:ip-18-151.net.ksu.edu; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1NAM02FT063; 1:G2+3VoO16svqBXoFH2i86gp5z15l4Oo6A3jxUDqWnq9iATvOELihwAAJwGUsSuWE5XT1y+dkqUdt1szTKfwUVW9tkkq+BtB7knYdba8io9hdGELml5w6PG4Gq4v6tGfcHp+TWzIimQTQuhfZbA3Rhk+iyk/vlkmJUfrFziz4+4eW+hytOTmZxl5P9pUcXazM2iJtZjrXL2MG9K6GRHNXrNuYZiQYIGfkQHeiLI4OWT6O11e08pQ6gLM08NCvmsdMym8wOfe73W9IbzITDK6tDrwRN/13dBXyw4I4FkaldOZYVE0jzW5tVCMoMT4hZq8qZ8e1m4CNxdYpIFYW+1n6cQLbRPkAYO+JUMykSyMncOoTG4jFs+dzgt/Zd0f2YnxhEvMgYxSU8g1HRij1CFSUtVKcG+DiYyejlA05atGyAlikksCvWZR3AvhK3+BzQCtA3KDfUl1+Uvyvk+KqJQHactQKYl6MYE50rYRgaxZmwPSTIIGEsf2x90dA7V5YWzTrrznfhe1cnsSpwLkD8NzIived/97aWPSICgBNfeALfkussPXMcCKW0oql4g3iaoqth7Nd439kYmX1J4ZBNrP5VA== X-MS-Office365-Filtering-Correlation-Id: 216d00ed-e94d-435f-a5f8-08d484d7ebae X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CO2PR0501MB1048; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB1048; 3:gLRACOIWIyJPzillMKI0wEi6GzckszQV9h5xWTzrXeA2hPRjyTuXhjJry5X/20QVGMYGUm/rG9DhNEo6lNXTflOUV7ZPKAlpLzWi/YIrjvON0TTJIZZWiDd/UZuHdTu0/2usaYCx9Kf1+1cfjJ+almMuUVKRa5tM+E3nFf3QNsaEmh0OTIBov9icfIQLTNXp3+2FscOH2HtLluLrpCKesJtPNzB3D9p4+/UMzLqNO7MiaXZUbqI0S7a1HLaYkRriv0uCnHMtNmIARTNOx5bWTkSm8xkkQItaV+YF8E6Au/Fd/Lrfka57bq5qvGc2lZlzFZ994xT32FDqx6Sp7G4TRZXQMxmMM+jFHFm9f/oEF6pKVgKCaUwlwELW7vyVO5wsXztTB03x8Fn+WY0h6gOHcr3W/M5uRTsFZMVeKgXb0xbMm85so1jUsfz5ARj0aMn6q4D9tG22qnQH972q47j5ePBVlgTdBwTLoCsJqX5gnPYXj9SEs5Hzn4fr2kRXIj8GMQ9fYJhMmXTEEKnKjVk+Kg== X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB1048; 25:Of60qjnrnpXoqJh8N0ceEB49IJU7pNxh2Kxq13z4oO97LgWBDmerjyi8Z9f2t+0ZMX72T63QARDTjWyxSAYJ9dFt3wRsSpn1Ml93nPdAkJvI/hNY+7U53Af/T5EU7sq2851UlsxEy5stE+vUrv9rmEqA6Qhqr7QNZ9VWY4lbrOUkAc0Bp163WCOSfKHUNlLKWGpmvJU83Iox4p9+YW9ICW5AKYh/33hEHJ+hfeE6vU+B/zCQmbCmFn1uFgyLPVwJcUR3egV3BxO0rXtsVztOldgsWokTYzfOrotP6ewOKooGUW3DHPscPqAIoWTXuj2T+/E4/P8Wwjw5hQq8OIBifdldMolrVA7yCYEhUCjKlTiDRbu7V3PrZl3j+Y7vA2ftnraaF6gE1xDKs8QWVBIzMsJblyMKLLXU7xXu1CrxGz918wpV2Xsac71gMUigkOtzaHF2JNaxR5JX89tDF5a2VFo8hcdbi3lirE/bBSjo6k0=; 31:95N/CIeXwFFp8gtS6cN4kiWVXoO6PuXUamZc8hb+8CEPvmZ1MAkb4TnJqLrV/B5gwjmV/REIyTcuVkd1otMFns4ZVgBGqlIPT5fKjhiiRXSlRJsDAbys9LptKtMX/36axz/QbaqObZddJNmBcD3Oy71oPB+O5BbnMTaEEjquPn2VMa4xzla5bA5EzaBjXv1CfXGAOR9NKEjUeT0aHk+XhmChBMniwE/Dslo+r/0fYmq/5u/H3a+XPScJgr8ZMzijRJ0moKxdK1bQWuP2cEFJ2A== X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB1048; 20:X2Y7mE2wFOvEN9U0sbZYKx4LaP+pWg5noQq1VI2cvUmBZ34ij9qhYxjlYRxnQVo9PGf0SIgunD7FEOrVkB8mXc8jBPdx37MUxIkL1QlNbF9cw65q9tpYYaygJEqZbNlKCAazf0ZZ57bxkBMCagh7pvDbV/tiRbjFA0A7BXLK1VFlVKECc8qRk1irI9xeoTgfkPYDHRCrThAz2ijLFerk0lGalO5kh5RIN3xW0mqa7YvNfVbD46z7zCxAnAnauO0MV836Mtf11tiQKz1ku0CXOk3Zat0jRwMCYru/wE3lS8mPNNwGVNEeS0KkA89xci3yuXPuFhTHN8TPxlzZIxVMLSAxFLPugkyjmgFfknxIQGPWu1lO0DE5IUtkHBvYVAiGG3jw7PGrMKgI6PjWFE3jBkmOqt3UaaBHmnUHzlyDoObGPrYIHrknFWvU35SPDstPHdt4kZt96b2S0TsuB02B3pYtDxgyT0/2bU2zEHRXhd5tTwiAnjY6nMjKtNNWAf2x X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13024025)(13023025)(13018025)(13015025)(13017025)(5005006)(8121501046)(10201501046)(93006095)(93004095)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:CO2PR0501MB1048; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB1048; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB1048; 4:tFvPZb85cLDclCG2Cd3nZWKRBqAXDoOiDpHA130EopzZg2ZN6Unrb620Xg9ckQoAGJoxUemTmwadP5MLr2Ve26IIgrxypTGweFefhVL0stfoIuZeJIBunokxQ1yfI1U48NMuHoC1BkYiKGfEKGEIWK2PlYz1V556l9GVuqmwsKJNwJ1YcoFoPNsLdCILUrHEouCI1Vi6XYUq7b2BW+NF21lLnZ4Ydc6KNlMDaVYYMOyNM/1B7I+sbynKMXNjNKg+NMLDAKnn6SEGBp/IfuuJgZ4ypSAH3fujc7lilyG7G9KlcUUu6keJJ2hg8OB0GPymnjR0GfG3tXT3h+SMguFjW0FI7fvLvQNdg69MN10HaeSREdNthkKKdtPRN/bPOoK41XBx985er4O4q5nieKF0LFWWfcWdUsBIoubcGo9vPb6cDlpMXiWboNFQ/OZ+ZBqW1Hy2crSLZd7dPJCnMLhL1zgy/fZXrd8WY2C7MbRDjtOsQbyGV6Tv2fHSEGnzfs7AFwB62FtWiVRESkJSRJhVEf9ULwavJG29PII5UGUv0qaRrSQ5BMXoI1faNPVH70DMOtY5zUk+AWbhXkQvEY6VxvSGHNTr+4ZqhuhQm5K43G2pjzxlbM22rpuj7wEvjoWBty+d9Jkc00J4IPH2OEM0Qe6rJUW4m+MLd8s3GFeYWnuZdX0Snncp1NiXGW7GA8SsQuLoDYVsdW/V0TP9+IZ/SGQWkO9AVqiGaDYV08S2uZkTo5WtmWPBV0QvMN54keefVTSx5ngZ+wiwKf8fdI4RhgCiw5FcEDVv4EhEkDo6ohaoYXIduFpi/WMpqpFlmM8Y3oivt7AciYczf2lnThHTgQ== X-Forefront-PRVS: 0279B3DD0D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR0501MB1048; 23:4HdVBhD/GxacBfZSfdwSctoLAYqwoeUt67ZwhwG?= =?us-ascii?Q?Yp8vsD+n4avSp6FyMrZVKvdu8u65wiqoNWnrSaT/oHsTFISCiXV+xtsbHmfA?= =?us-ascii?Q?DkUD7ONOaUFl/mCqsOkNp/tYZVKz07l3Sc9ZoEdtCzMMcNbDLMZuROPlm2KZ?= =?us-ascii?Q?LRPeDkrcQCMBsmdAQyDZHTCaQheCvZMFubsziLvYkBi6HN+3TUhdlv0GTzae?= =?us-ascii?Q?z91ik8F58m3W+LzBnRNVrN6pntdhWCYNqu31rgVelud4FWpJllSDC/lkLLxN?= =?us-ascii?Q?XBHbaL/7CTLKlCTE8RkJRWh+1/r9Z4C5AXaKR6TOdDat/ps5PH8elJ2FN737?= =?us-ascii?Q?Sk+L4wppCTVPfwQI0KVMmRKLOQpwfTDzM1oE+c6g6iCktVhvri6lypvlENT2?= =?us-ascii?Q?syEs8JBJRnqlYzsIXvrUipuwnd8VZoMxomGWiHTymbwBwkoO/KKcK8AZnVHo?= =?us-ascii?Q?UJsDEq96dopS+nQB6nCLfI/Eg9hP/ucIvKWU9qgChX1+3l0I3y4GlhPCfR7n?= =?us-ascii?Q?C+iIa891brutgTLIVoYUuxoKIi1I8QZkBae8FZMhQaqrn8M2BZHphOSjaVCj?= =?us-ascii?Q?NsdQJe13noWn2gb3DivGOgbgxErA00/ZKvqafk42FfPvPYOeC82wY+APW6zd?= =?us-ascii?Q?gE7JkrkZNhZMxSJc3Q9DhGX38OmZhIGH+QnbTJ58wayqJ74SzSgWHNJWrE62?= =?us-ascii?Q?liR6nULua59XGOJFmgn+cKe+YGHLuPH1lpDJIUUdW4L95TYGpaSm7XVzUM6H?= =?us-ascii?Q?QX7Q2n66TMUy4Ecweey82iPcDVxuS3AdS01N1I5cm3qWCpgEVQD9MUs6T5pL?= =?us-ascii?Q?+zoKlC0qeqGPmGCeg5Iyhvt3l2QSBCqIInMbhZt8dypctGJ7237toH0GmZr6?= =?us-ascii?Q?urWVFxKURcrhdX+lIRtmtRpGo4k+hEJVfDCXZR4z72/4DLC3M7eurVPlRV2+?= =?us-ascii?Q?8+DulLVLU9vWk/HAcSWJvJebmfwZ0MBygWhKd9D1+RqRDaxbUALBgtHXF7Sp?= =?us-ascii?Q?lsLJ/K+jlPdFp1OJ4MxC6Y+wgeH8DE8ApzbaCc88efGiauQd0HiaqMJjzUlY?= =?us-ascii?Q?YoU+A9gIXRvDOoRYBElWI0jExT3xqEIgxQuHjvfz1bS0hnU7g1B1aubCCw0n?= =?us-ascii?Q?skmRjwQSslqRReDUTHfAisuGXF6A1H0Nq4UYkJITWY9/CGTJDmYjJO1liBQb?= =?us-ascii?Q?jIpXF5sZW/k80YESFjAWVFfzNZnS1MWKvIipubsQh0sMAnbHekPYFrGwARKS?= =?us-ascii?Q?+7UBjcQbMkXbxO3PzhBKw+3op9HEJwfir+uXbYhAFzEscT7SPPNZHoZMy2p3?= =?us-ascii?Q?coSpYIyb6BoisrM3ybrqzb6VL6S8UaWoOuljEwW2IOOf8BSYuRo+7bB+Garg?= =?us-ascii?Q?KAFXYh8/q5VyWDqb2DRXUrBGSuCy1vJVzU0TmicWHKU3ftTOC5gSNiiEiaTj?= =?us-ascii?Q?mWWvbe3lI1RZ7oNVYtUWnpAD7s4TSmfM=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB1048; 6:YLWww4enNBcP7QDQWJcC6102Aiz49JZzLdb3to1Sr8vnVJ1F5ez5zsv88IChdpAPpPlevNhy09791Eeshw1xxqU6cJYvwJvtC+jmhsW7bs3475sUMJs+G6WhESF6Op343wg9fUsvCGxToice02ZXMzUalbDLNRaZLUNtAmhx0hSShncM7gA3Rmm4dl+O9mUP0wN7ecu4nLghejgHepDOqfPyM7qkuLpozkTBptceinADxmmvRKI1FvKnVcj293DFyrvxtxlQg5l4AW6FF6F4nyn6ITktSVaPd8bLBGtilTChw+RvsI44fw4jQvOamQ380u0STkjW7Ul2fbrAdp22uPosPKF4bsQtE2W9rTgcsCc352UdOLZ7yRN9yO0W2CjjEcXvRCysqsJ1wGA7VPhOH06rkj3NUdqmMch37D3udPN+B5unxOILsG7RmWiQY/FYrKW3YO+AL3yLbB+29M+SxA==; 5:06OhdUeMWxoJVyOakpfOQWmnHfk8T2XwB9GEHcqmRE4Mfj1Q8qjqeFNwe4UNEN6u+bICUdL46IEcN1WRlDLhcotf694JAg3RN82HqtGupN3i1axV6q+YewURsiYkdlnTXL1aREwCfmuJ4/gz3d/zVA==; 24:d9h4+mExs2VAGUYEzOiYGD8W4AMemZJjh4hPrjjOU1L1m+E3ZFDJTNNgetlJrpkvbNgo9E/JPtZlCbJ88l+hv4i1emFi0LXogjC69etoI2w= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB1048; 7:e0Bl36j/sRWqVfl+FaZtoVDRyADE09JJSW9rZUx5LYTZAs1HCgMs7+a3zFrGfaUpqHUIiyJhZ0FyTTlMC06R2dW8hSndzMrQWIZjvPCshd3gIlWRitNEbdb32tXssgw8F39ln71mYWZF3g52XRW8DgeR1i2FvMFvpL+PK04XQDy83fH3t+CENXl6/ro4Wb+bq74c5//tByI1gI13ELRlwp1qnYnvRnKP9MfMDcSj7Qr3jv1mF21hyP0YZBjE3Kny2Ry7RIwyb1Y93cFAAmpovN+FslRmojFaAA2h7H/kHAaybu/nyeykbsjhD6PSNaNyZ6Ed8pRaLT8+QlTOkGLn5g==; 20:uzhse8HO5HBm2VqH76qDtXkNVGmhYXxFfGd4KmYbe7Vzf1btd51jvgYAdLt3mOPecWBPZnUSm1hRDCRw/4TV+nOy5fZje+ZLCA8ijTNb8Ngyj/P5bnDnQV22G+zYQZBkq20g1P0BRbX6kszlDXeqmqX+V1Or/OO2qXPTsqqx7CM= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2017 14:50:26.8790 (UTC) X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp1.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB1048 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 14:50:31 -0000 On Sun, Apr 16, 2017 at 8:47 AM, Jilles Tjoelker wrote: > On Tue, Apr 11, 2017 at 03:20:58PM -0500, Kyle Evans wrote: > > On the other hand, I think I could fairly easily implement most of these > > into libc/regex. Here's a summary of what this option entails adding to > > libc/regex, from what I've found: > > > [snip] > > * Add backreferences (\1 through \9) to EREs > > [snip] > > Adding this enforces that EREs, like BREs, may sometimes require > exponential time to match. I would prefer to avoid that. > > -- > Jilles Tjoelker > I played with it a little bit more, and it looks like I could lib'ify what I have and have libc include a POSIX-strict version of the lib source fairly easily to keep the default implementation clean as it is now. Would this be acceptable? OTOH, one doesn't need to actually use backreferences in EREs and the matcher works the same as it does now. I kind of like the look of the 'lib' implementation now that I've seen it, though. From owner-freebsd-hackers@freebsd.org Sun Apr 16 20:43:32 2017 Return-Path: Delivered-To: freebsd-hackers@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 5B0D8D41909 for ; Sun, 16 Apr 2017 20:43:32 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [IPv6:2001:4b98:c:538::200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F9AC10FC for ; Sun, 16 Apr 2017 20:43:31 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by relay7-d.mail.gandi.net (Postfix) with ESMTPS id D9DF31155 for ; Sun, 16 Apr 2017 22:43:28 +0200 (CEST) Received: from britannica.bec.de (p200300D2ABD4B4004639C4FFFE599710.dip0.t-ipconnect.de [IPv6:2003:d2:abd4:b400:4639:c4ff:fe59:9710]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 917F3A80BE for ; Sun, 16 Apr 2017 22:43:28 +0200 (CEST) Date: Sun, 16 Apr 2017 22:43:26 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: Replacing libgnuregex Message-ID: <20170416204326.GA24950@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20170416134756.GA88424@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170416134756.GA88424@stack.nl> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 20:43:32 -0000 On Sun, Apr 16, 2017 at 03:47:56PM +0200, Jilles Tjoelker wrote: > On Tue, Apr 11, 2017 at 03:20:58PM -0500, Kyle Evans wrote: > > On the other hand, I think I could fairly easily implement most of these > > into libc/regex. Here's a summary of what this option entails adding to > > libc/regex, from what I've found: > > > [snip] > > * Add backreferences (\1 through \9) to EREs > > [snip] > > Adding this enforces that EREs, like BREs, may sometimes require > exponential time to match. I would prefer to avoid that. The Spencer RE doesn't need backreferences to be exponential, but I certainly agree that adding support for them makes it more difficult to change to a better RE implementation later. Joerg From owner-freebsd-hackers@freebsd.org Sun Apr 16 23:38:01 2017 Return-Path: Delivered-To: freebsd-hackers@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 68F60D41C16 for ; Sun, 16 Apr 2017 23:38:01 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0074.outbound.protection.outlook.com [104.47.36.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01ECE7EB for ; Sun, 16 Apr 2017 23:37:59 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nED/c0+b3UaPv0Gf80Agzii7vrfiP3Buz8GWmdTtU8s=; b=lUEv4IIlZRYB0FILIbNFo3TdEL1ugohyxDHbrzNGRbX9V0BsEd5Ne5TazdJxP535d7zutkWTa1nrmkKX+ojkiS0n75GJjHkpiY7c7tKWtY9ACNwImtWQgEOfYYAA2taWYDiiAgXc40FS/rSQlEN+LQKwXR+fCVLmWmMqrBMDuF8= Received: from SN1PR05CA0002.namprd05.prod.outlook.com (10.163.68.140) by CY1PR0501MB2041.namprd05.prod.outlook.com (10.164.3.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Sun, 16 Apr 2017 23:37:58 +0000 Received: from SN1NAM02FT019.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::208) by SN1PR05CA0002.outlook.office365.com (2a01:111:e400:5197::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Sun, 16 Apr 2017 23:37:57 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by SN1NAM02FT019.mail.protection.outlook.com (10.152.72.130) with Microsoft SMTP Server id 15.1.1019.14 via Frontend Transport; Sun, 16 Apr 2017 23:37:57 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v3GNbu3A001202 for ; Sun, 16 Apr 2017 18:37:57 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id D8323248308; Sun, 16 Apr 2017 18:37:56 -0500 (CDT) Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id A66D2248004 for ; Sun, 16 Apr 2017 18:37:54 -0500 (CDT) Received: by mail-wm0-f47.google.com with SMTP id o81so24748004wmb.1 for ; Sun, 16 Apr 2017 16:37:54 -0700 (PDT) X-Gm-Message-State: AN3rC/7c9TbcVERKwKACms+pJgVTh84RFLOTunm46QW3DYzgvqJTvf2O AbC+Fg2kBe+95wp3OuNmZsPfq4/jzg== X-Received: by 10.28.31.200 with SMTP id f191mr6707860wmf.63.1492385872676; Sun, 16 Apr 2017 16:37:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.39.134 with HTTP; Sun, 16 Apr 2017 16:37:32 -0700 (PDT) In-Reply-To: <20170416204326.GA24950@britannica.bec.de> References: <20170416134756.GA88424@stack.nl> <20170416204326.GA24950@britannica.bec.de> From: Kyle Evans Date: Sun, 16 Apr 2017 18:37:32 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Replacing libgnuregex To: X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39450400003)(39860400002)(39850400002)(39840400002)(39410400002)(39400400002)(2980300002)(438002)(189002)(24454002)(199003)(377454003)(189998001)(3480700004)(75432002)(76176999)(54356999)(50986999)(63696999)(45336002)(106466001)(55446002)(42186005)(9686003)(90966002)(236005)(2351001)(498394004)(512874002)(61726006)(7116003)(356003)(9896002)(93516999)(2906002)(8676002)(8936002)(110136004)(6916009)(86362001)(2950100002)(38730400002)(8576002)(229853002)(6246003)(84326002)(88552002)(53546009)(5660300001)(305945005)(221733001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB2041; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM02FT019; 1:GesCouPZLjT5VsquN2gGKAquuRIZcOenFjPs1dWkh1+LBZ9pHCgRTf5zpYeTJvVvUaiMORAExXYs148X5scArQpfLU42Bqr/mDHX8wb/+tS7vEftbhS9Ite6pMA1rVx+TDzm7T996R/DmE6PEotpg+oXmWgsLfXF0g7DeI4LB7o0kzNdTU8zffmR26ODusupKsNWWmkwL4HKb237V68Aag0PgPTM6cMpob5f9mYxN/fnaqcxLxrEd68Dhd6h62JpUO8crwdSkdkwTkpsyxnyVDJHqUlbRMQky2tWOGovpwGhmfZeis60oe2uDAEKCCt5WahcQTuJFbrxLMokVkDDXFRDQbUEPrqcIpFVxsYhAF2dLvF0pKK+xWPh0ibYIHIwfhdf5zqvzfq4YEA9wkCqGlOLPcmFcL1nsrLaRyiDGWyQu2id2HchP82W9UJi+Yw6e8jgpwhbX5604V5YqG93fuGa2ntQ5qmnDNZscQcbrpQL1qxfhGmXb7caUAvbOVqG0vzVkA6Wpiry3MCOydUHBcBbpQTiY+I4P998kxV2INQ= X-MS-Office365-Filtering-Correlation-Id: b6eaa67f-a3ab-44db-b14c-08d485219cb3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR0501MB2041; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2041; 3:b+2IxAiCUA2ML+ejKNy6doVAKI0q0tqHBKTApQMEzYCNZyMtA1a3UFGEsC5I15sdB6JCQA7u8TVxaocwoozFmO/G48UO+q3MdiQ/nq86ADqG2Vb1ol4J9+xYSRxoohegtwLqVWRK74+471mIBGRmIh4KRq1JKCkpP++nvioaFWwDMchTYHLDg4y7VfhklBeqJtvQM5teVjNsYsB4hdGEkKMfuYZmyZwOgGAFxoS8u2FsZy5lICbyC7p2K3xjd12dL5CjGHrHHNrPR5Rf1Ij8zfvgvFoYzP0bjM7BCaSaPxLuSGKHJ0B3/58Dcrz+nIOVRyNFs0h9rBeGThvghWFORpXNwBGDcAnnjz4IYB8Z27pv/DaVLkYtoDlEZm1Hr/bntPGqI/fPw2UNneICylG0x/dfNgwAO7D/W3sZdZlf8UEGDKlwHqY33c1PN2//Ge3DOn/3qwI4bKSrszOaRl/BJF10j+c1hdBIkV4Z113tJSoxreWtAdK9HJnnhhkYXAxmLjtEDP/vrzcgC9x98unqfQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2041; 25:KGZVnzecRpnXnnkqAMpH4xD3K9YicT2NPIQGap30xtcA5h3svWqWvcuq9kiRiTNPQK9jbw8LOofbxp2zN1zQrqeZFiIMk2IA7njIrwWVYkbDzrTZq2IEoSqY7Jl+X2fMedgY7dvfojdutBRbqqZjKUErSPpZTZdbrD55TuFlxBD0zR90zwOD6wzShMdXJ5ZwL/kCRL6H/8QUo1rJwf7ymMUFJCd2GxqVmwSwUYZLUyfMupR89XYA6NdhUJw+kJMSwslMK4h7jUyaA5J6Wh8zjr0q6qs2kj5kF4UoWajNDzZkVOKJuzRZhL1gH7SfASore77uejTE5Rbx0vuIEVGXATO84BILI0VL3MUKVQzI5eRbzQKnIKv4N8aHf6Ink+B7/8wxbQYzsWYsIQuzQV3fJYhzp/OIcDeg7KAq+XJ40wI+zamv8ZDyzyXgT1jttz1fTTN9fZbFT+GLby6XJpv89FIX4kvtNrJszWgSEroQU64=; 31:6T5gkKrss63C3VF4P3h2ahuDXpOC6Y8NT2xMiKsakNsujruXq+EAhU5ebTU56zl6DhLuTY7P9ZktspwtlH0ODdsVb8onSEbagCEeDjpPzny1nZu7Kk3qVWo+go13M19k87V2wc5GHWi7xmnnFfbERnAKl+5+uJ9R3zaxOIB0NhMTKvy6d0nTV2JxFFjZmdKoNVxDDWfc3H0mRDZYd46r9wwtsLjDs27gkhRPYCpthtX2ve9I4QXtNZnZ2tMx238VtJmSEavQwnYFNvxckqd2SQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2041; 20:qtn9jiipTmtzH/g/ZjnYEN3oe5JplGNKBOS8eoGoehyAqDh/tB0k67vNFHZ5w65SwOWCsMwbulp9za8v12EfSnWNNWaswhT0EFTj8Xf4paBZWDslIt0r+ZMu3urXqM3z40UImhQJ0Yh2joWEzGyhDXYirAk9IRgA7t8yT3V3FyEas7h9T4k4cvvuqZaST3AZAzs3ymhR3FkrSgfLckXC/iOjCEpPfK3MYjdglq3bny9R5n4pmdu3+mJqFPiz+tUGfcOEHfQNLtauyoNCwCKzTLkuuX+Eun4IN19shYc1Gx1B7obJGKwJTZYuebmIgDqdscQ8RieVaqLyMVenEjU2xJeTXQbKDefxfamRzBGNxi5Hmke8kLt/c9x3rNmQnFMJT0vk3rRruZ8oy7X6sGZJnl7zIpnKNjxDMlo1o6jq6DNPA1ggc/qw8DtIR+IinUJiA9ek+Xtn9MaN+9dhH3Q5qfCAshFAxDgmy5GiJxapdFViQY3OOiFpDNhlnmEkNDnQ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13015025)(13023025)(13024025)(13018025)(13017025)(5005006)(8121501046)(93006095)(93004095)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR0501MB2041; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2041; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2041; 4:abOwX8+kmchG68AdspcfgK1xxWXMin2/zTUE568Hpp2pBw0f36ORH8Xtrmzb+jhdyfXRV0ve4ITVulf/gtguRZQxyL3+UFyIMQcISZ0P1S1KNKm/gSbMQfp21eHit/TOe31ASv4DSC6kS0lHq26neHc0FQSPH7OcVORuXoY5YyFgY8tQ9GwVEOsXIHinNhMsz/+Gh+p3/YO2i1UXViiqKqlP2I8bQfeh0YULyAh0qtP5nY0CgzghF6qqGpE/SjwZP/drh+Q3ZfEldUQpNrv8MoZlKyhFwLRH06H71TYO3KcgBC86JbcxXNpiq96KxZJ536c0W9j8kJACqF3KRq5p34iqXfABmFxn2GOOUENOb3b9LWq3UyvTsGPxApU+ZJTHCzcPz/39IAfDZQQP+lnZ7s5yL5H6JNE4i4ks0LF/F8BWLjMRAalzPsbWMTUeRmVfQUvWA1M77wqlW8MWyKEDQ5UjpdTM1GXf4S8xI/nCE2oPmpfjxaHDxAWoLZuI67VJexdOYjGe2Jm2pdwNsT1wNzdKyOZZXsPOnaWCggrlwTigT+Kn6HdRi6TjaKgKr6LtnLF0SaEkb+6rWUCTdxKKWWQIpt5mqctJZNHvOQa5I4vYPRwa8bIZ1+uNmIkoSX7hlX3kCkhg1j14poyD7JbO9JorpM+b15TjP2TILpoEAmb6RjOWNi0xJ5TdVEdXf074A/uqdwWm39/ZEcL8+mE7gtuJEjatdGE7c9rBNMg5eEe/8BYbzCpz9YIKhUwp0j6pzHXpPbyDEdE4SvRASXpWc1OWGZFq7m0ThLsSZFRMZMTs80YufhhhejBRO7M8B1IcyJG9jxP8u3xKNIiFYTR6dmwk0I/UriHP0KJRBzW4TjvHrl8LeJ/SD84zy/O2dxru X-Forefront-PRVS: 0279B3DD0D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB2041; 23:gycSsECRFpN8LMwXp8WBXAUIejwAne10InXKYU4?= =?us-ascii?Q?d3Jjck8fQ7I5hHKQGRVRfgYTH+wZwC7qds/NC1GMpHTM/9mFDGSGBgJJYfuP?= =?us-ascii?Q?xPUhhXmCL9w5RCPvIA7bnHHJbRCnUjH2kMrqH8lWxKMBp2kNKoikvj51BjIA?= =?us-ascii?Q?eLpAeFpiui4KFNp3SS1buC1RzkrWly99HXW/yi79Hbb8SFCvN2sE0+qrBFMo?= =?us-ascii?Q?AWafBe4heDT9s9JCFzn1R+CpQZuZtPsgRR32vGe/xU2RTMMYPMu+btFyk9QR?= =?us-ascii?Q?sikSmt/f5nqVepT4fK8IV8FoX+tgnBZTPZquULcQSqXgpJRSjdsOEccQj4KY?= =?us-ascii?Q?bNxuNRm7Q3CPu3ZRm5felikgyNBITkFb6h1AcdDJKtKeBi6PxOmNYlacB6gu?= =?us-ascii?Q?f+a8XiP/vJmn2iQZNcTpJckQdZvRjRABmMMguJ7/EVgVjCeABmYWb3843IxX?= =?us-ascii?Q?Hhx9CDAsLZVFS87gX/bVTw3bCAD4VRw66mMyvxBAJ+Ms1Rr4NuJtppI+1nSA?= =?us-ascii?Q?vnUqO9a/8HXHmUWHAUKV+q8YCSH3PQgDvds7WbWDKmm4QbOme+rzHo8IRL+m?= =?us-ascii?Q?NtdV9QWkwLQFPWFsVinD+0dOEdmMZ0ewAaBESEHqoDO+F5IQJvkERmTXgMVn?= =?us-ascii?Q?eTwBEVbHnIcEy2kEid2bP5CNJHz1PjBMq1eyDU2DIakxgtUYRh3o0lsTfLzo?= =?us-ascii?Q?XTada45lHVqaPZZudpChGm6+/VRL2Q4Xwl3XKz+88odBtQ83HyChoKguV6GJ?= =?us-ascii?Q?PMaxxXaXly8rt1zJ8I3h8MG9wRcvQ83iAKSKFvL1yACTUsCvjYYT/pDtLsIG?= =?us-ascii?Q?o3nMh1juLPyI0Vrlxp5t8OjzTey4Y5fwiuI53yg3BLepK0M/Yy87rapUkq/8?= =?us-ascii?Q?1NbDqYZ9mps1ZAsR3DasUeOdl0mHxSumvLNPwl6sq+4h4ge6Fyz9uw7H7ZYU?= =?us-ascii?Q?2bcpMDY+STf4ZXP6WF/BvY6/o/q1c/PTX5/yNEZhoTDIOKhVrA1whLv72M//?= =?us-ascii?Q?YcIZwx1ksRO3y0hKhMRgIzk/0JUk4IlCi2QTT0A7yp1ru55eZ3knGVHc3HEo?= =?us-ascii?Q?ixv+9D31K617JyOSryfOLjHYZKZWUrHz/r2KRvAyrI4Vv7mMm2OpGhQ+FuJG?= =?us-ascii?Q?PZ89AFIzM/34J+7Ajrb/RImfLpB8/9DZ5QdRDE2PeXWXIyhjsNlQQzPBXpKB?= =?us-ascii?Q?0fEQrP+XjmKAqnZIsoVw0/w1r8EVYHZ5Xmc6pfvy6tJQU/a5h4SqPk8KtYbh?= =?us-ascii?Q?ThuLiCHTpaDS9xsW09CY=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2041; 6:aofCcdB1KB3rCr961TVFSeUD3W2B44Ut4cqcRPHFuiKtzAEKe2K4d6ULgsSS/8Q5oiIJbPnYIADHkqhD/UWdefgz4wyT4YtH9utj6fgjOZ1eEgmflbqk6H4XhveqZmVLatfRRnUopZsqdCD9IFDYyHXmTnv9gXYPRd7o66ZpaTuW8N1ALPY+62FlBTT56w+tS6iISA5J+nPw+HKxMyW2WLDEAhxnqgFELGDlFB4WoZGHSCxp9uAbIkghNcZEvRhhdzkq/bBuNiK5/lHmIu7iThgMsz/Og8dmK4p61Pp1HCrUm5SX4xb+GZFR5Im8wGoBR8eCv4DOyJFvMr+iN6WARRd7tzhX4vUdSLdUk8x12+Lr1DArCARFXfy+Ro1RIzvKWfhf+OdHewW1+zLi1fhViMjMe62xAKxFVw5qBf5YJo5kKjWEHkla3p8abkMjIa4hEGV18+ewkASz6bpnsSZJqw==; 5:dtZFt5nMqwj6jspKR/KiagoYRFdi0IPG2qHclUYezHoWEJzplHngWmxFKiQ5oKEWPKbjdLhzRl6plMtJGLGR11J7ly3YYdx5psRSKS0q5MBiGVS39f+0dFXAFVhQJJNA1YLHxY4OkAXn0xxX+473jw==; 24:zyxt/g0ID/H1ioCkNaS07rBggHOxkZ6l1tm5/2zTGfczsdbu+n/i31XfaHNz2ntXnQ0Y0zWvVEv9flEyii6j7+vlb4LXLqGmj7RBvbpIHjs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2041; 7:EbG/qMQGkSU8F73b6F1/gvXgEHNKHuJNdCrJPu4dyrjO9AnNTDDN973w/fY5hf5X6xt1Xp5FL9p8uhD28SVSjVcEgQQEkPdyXCx9Iowjaaikcua5ZCl4tEtB84FsgyGRWZHDB2pyFH7v/PTzjDwCRFSZ5ivZAseivKrnNHOliW0t+IkHHNIDAdBlaSrt6DjaDIEZDQpM9wb6IDW5FYGBpHx97eskwPP/4xdYRnhnVVXoSR3T74Krx8PxqTQOvfZVycvnpd5cTWpb0GNOVDC8uJM/j+FeM2BrjiH9PSKHQRzUl/t39BuhqU5kJjKYKnVUPehFsfiCNfYwmr8fzV6vLA==; 20:ErGKQtfdppXY4f6Rig63ad/SO+EbKZHWvuM9nqLhRNhJnOWsVKXjleoKcZ8LsoXrUjn3G+mzK7GWECSYzy0ARULG1wVHnWdE5xdXlSB0quSVAQQaxgheQQWNqy+437wcXDr3NwwWxShyrZWOj/vHraQlb8+W4KFsqeu4tfEEMBY= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2017 23:37:57.3644 (UTC) X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2041 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 23:38:01 -0000 On Sun, Apr 16, 2017 at 3:43 PM, Joerg Sonnenberger wrote: > On Sun, Apr 16, 2017 at 03:47:56PM +0200, Jilles Tjoelker wrote: > > On Tue, Apr 11, 2017 at 03:20:58PM -0500, Kyle Evans wrote: > > > On the other hand, I think I could fairly easily implement most of > these > > > into libc/regex. Here's a summary of what this option entails adding to > > > libc/regex, from what I've found: > > > > > [snip] > > > * Add backreferences (\1 through \9) to EREs > > > [snip] > > > > Adding this enforces that EREs, like BREs, may sometimes require > > exponential time to match. I would prefer to avoid that. > > The Spencer RE doesn't need backreferences to be exponential, but I > certainly agree that adding support for them makes it more difficult to > change to a better RE implementation later. > Are there plans in progress to replace this at some point? If not, would it be acceptable to lib'ify what we have now, ensure the libc bits remain strict POSIX (-DPOSIX_STRICT to exclude any GNU cruft, not just disabled at runtime), and have the libregex version include GNU extensions? This seems likes a reasonable approach to make sure expectations of libc remain as they are now while also not introducing more maintenance overhead, assuming there are no immediate plans to replace the regex implementation. From owner-freebsd-hackers@freebsd.org Mon Apr 17 00:05:22 2017 Return-Path: Delivered-To: freebsd-hackers@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 27202D41877; Mon, 17 Apr 2017 00:05:22 +0000 (UTC) (envelope-from jaguar.darocha@yandex.com) Received: from forward7p.cmail.yandex.net (forward7p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::ff]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA68B1719; Mon, 17 Apr 2017 00:05:21 +0000 (UTC) (envelope-from jaguar.darocha@yandex.com) Received: from mxback3g.mail.yandex.net (mxback3g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:164]) by forward7p.cmail.yandex.net (Yandex) with ESMTP id 042532140C; Mon, 17 Apr 2017 03:05:09 +0300 (MSK) Received: from web21g.yandex.ru (web21g.yandex.ru [95.108.253.230]) by mxback3g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id gkDvSHQB5L-58guxMde; Mon, 17 Apr 2017 03:05:08 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1492387508; bh=XZVaEdLebTIr8bUJGVt7WXqTV8J6N6nR63GbwUMEIj0=; h=From:To:In-Reply-To:Subject:Message-Id:Date; b=VvMve2Nn1yNchcGE3kGxaoPZWBh+3msiwb8uB3+sY2IlORriA5L7NT9Vpv5wX2wgw KhRdiOaDJpD3VpifF6rBcy0UjnD4Cb0VgSHeQssCfiOuspAlURfzxd4Zm4k2m3xAvA fJ4Rsf0JoB5ODFj0AdXDMOrLXqsZdXHO2ic78/ts= Authentication-Results: mxback3g.mail.yandex.net; dkim=pass header.i=@yandex.com Received: by web21g.yandex.ru with HTTP; Mon, 17 Apr 2017 03:05:08 +0300 From: Jaguar DaRocha Envelope-From: jaguar-darocha@yandex.com To: "freebsd-ppc@freebsd.org" , "freebsd-hackers@freebsd.org" , "baptiste.daroussin@gmail.com" In-Reply-To: Subject: Fwd: powerpc packages? Message-Id: <6510231492387508@web21g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 16 Apr 2017 18:05:08 -0600 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 00:05:22 -0000 From owner-freebsd-hackers@freebsd.org Mon Apr 17 00:18:23 2017 Return-Path: Delivered-To: freebsd-hackers@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 B0AEAD41E55; Mon, 17 Apr 2017 00:18:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D64B1EFA; Mon, 17 Apr 2017 00:18:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3H0IG66010285 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Apr 2017 17:18:16 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3H0IGwt010284; Sun, 16 Apr 2017 17:18:16 -0700 (PDT) (envelope-from sgk) Date: Sun, 16 Apr 2017 17:18:16 -0700 From: Steve Kargl To: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org Subject: [PATCH] Fixes for asin[fl]. Message-ID: <20170417001816.GA10277@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 00:18:23 -0000 Please commit. * libm/msun/src/e_asin.c: . Use integer literal constants where possible. This reduces diffs between e_asin[fl].c. . Remove a spurious tab in front of a single line comment. . Sort declaration. . Remove initialization of 't' in declaration statement. It's not needed. * libm/msun/src/e_asinf.c: . Use integer literal constants where possible. This reduces diffs between e_asin[fl].c. . Remove a spurious tab in front of a single line comment. . Sort declaration. . Use sqrtf(x) instead of sqrt(x). The additional precision in the result of sqrt(x) is not required. * libm/msun/src/e_asinl.c: . Remove trailing space in Sunsoft copyright statement. . Use integer literal constants where possible. This reduces diffs between e_asin[fl].c. . Remove a spurious tab in front of a single line comment. . Sort declaration. . Remove initialization of 't' in declaration statement. It's not needed. Reviewed by: md5 Index: src/e_asin.c =================================================================== --- src/e_asin.c (revision 1904) +++ src/e_asin.c (working copy) @@ -50,12 +50,13 @@ __FBSDID("$FreeBSD: head/lib/msun/src/e_ #include "math_private.h" static const double -one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ huge = 1.000e+300, pio2_hi = 1.57079632679489655800e+00, /* 0x3FF921FB, 0x54442D18 */ pio2_lo = 6.12323399573676603587e-17, /* 0x3C91A626, 0x33145C07 */ -pio4_hi = 7.85398163397448278999e-01, /* 0x3FE921FB, 0x54442D18 */ - /* coefficient for R(x^2) */ +pio4_hi = 7.85398163397448278999e-01; /* 0x3FE921FB, 0x54442D18 */ + +/* coefficient for R(x^2) */ +static const double pS0 = 1.66666666666666657415e-01, /* 0x3FC55555, 0x55555555 */ pS1 = -3.25565818622400915405e-01, /* 0xBFD4D612, 0x03EB6F7D */ pS2 = 2.01212532134862925881e-01, /* 0x3FC9C155, 0x0E884455 */ @@ -70,7 +71,7 @@ qS4 = 7.70381505559019352791e-02; /* 0x double __ieee754_asin(double x) { - double t=0.0,w,p,q,c,r,s; + double c, p, q, r, s, t, w; int32_t hx,ix; GET_HIGH_WORD(hx,x); ix = hx&0x7fffffff; @@ -83,30 +84,30 @@ __ieee754_asin(double x) return (x-x)/(x-x); /* asin(|x|>1) is NaN */ } else if (ix<0x3fe00000) { /* |x|<0.5 */ if(ix<0x3e500000) { /* if |x| < 2**-26 */ - if(huge+x>one) return x;/* return x with inexact if x!=0*/ + if(huge+x>1) return x;/* return x with inexact if x!=0*/ } t = x*x; p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))); - q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4))); + q = 1+t*(qS1+t*(qS2+t*(qS3+t*qS4))); w = p/q; return x+x*w; } /* 1> |x|>= 0.5 */ - w = one-fabs(x); - t = w*0.5; + w = 1-fabs(x); + t = w/2; p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))); - q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4))); + q = 1+t*(qS1+t*(qS2+t*(qS3+t*qS4))); s = sqrt(t); if(ix>=0x3FEF3333) { /* if |x| > 0.975 */ w = p/q; - t = pio2_hi-(2.0*(s+s*w)-pio2_lo); + t = pio2_hi-(2*(s+s*w)-pio2_lo); } else { w = s; SET_LOW_WORD(w,0); c = (t-w*w)/(s+w); r = p/q; - p = 2.0*s*r-(pio2_lo-2.0*c); - q = pio4_hi-2.0*w; + p = 2*s*r-(pio2_lo-2*c); + q = pio4_hi-2*w; t = pio4_hi-(p-q); } if(hx>0) return t; else return -t; Index: src/e_asinf.c =================================================================== --- src/e_asinf.c (revision 1904) +++ src/e_asinf.c (working copy) @@ -20,9 +20,10 @@ __FBSDID("$FreeBSD: head/lib/msun/src/e_ #include "math_private.h" static const float -one = 1.0000000000e+00, /* 0x3F800000 */ -huge = 1.000e+30, - /* coefficient for R(x^2) */ +huge = 1.000e+30; + +/* coefficient for R(x^2) */ +static const float pS0 = 1.6666586697e-01, pS1 = -4.2743422091e-02, pS2 = -8.6563630030e-03, @@ -35,7 +36,7 @@ float __ieee754_asinf(float x) { double s; - float t,w,p,q; + float p, q, t, w; int32_t hx,ix; GET_FLOAT_WORD(hx,x); ix = hx&0x7fffffff; @@ -45,21 +46,21 @@ __ieee754_asinf(float x) return (x-x)/(x-x); /* asin(|x|>1) is NaN */ } else if (ix<0x3f000000) { /* |x|<0.5 */ if(ix<0x39800000) { /* |x| < 2**-12 */ - if(huge+x>one) return x;/* return x with inexact if x!=0*/ + if(huge+x>1) return x;/* return x with inexact if x!=0*/ } t = x*x; p = t*(pS0+t*(pS1+t*pS2)); - q = one+t*qS1; + q = 1+t*qS1; w = p/q; return x+x*w; } /* 1> |x|>= 0.5 */ - w = one-fabsf(x); - t = w*(float)0.5; + w = 1-fabsf(x); + t = w/2; p = t*(pS0+t*(pS1+t*pS2)); - q = one+t*qS1; - s = sqrt(t); + q = 1+t*qS1; + s = sqrtf(t); w = p/q; - t = pio2-2.0*(s+s*w); + t = pio2-2*(s+s*w); if(hx>0) return t; else return -t; } Index: src/e_asinl.c =================================================================== --- src/e_asinl.c (revision 1904) +++ src/e_asinl.c (working copy) @@ -1,4 +1,3 @@ - /* @(#)e_asin.c 1.3 95/01/18 */ /* FreeBSD: head/lib/msun/src/e_asin.c 176451 2008-02-22 02:30:36Z das */ /* @@ -7,7 +6,7 @@ * * Developed at SunSoft, a Sun Microsystems, Inc. business. * Permission to use, copy, modify, and distribute this - * software is freely granted, provided that this notice + * software is freely granted, provided that this notice * is preserved. * ==================================================== */ @@ -27,14 +26,13 @@ __FBSDID("$FreeBSD: head/lib/msun/src/e_ #include "math_private.h" static const long double -one = 1.00000000000000000000e+00, huge = 1.000e+300; long double asinl(long double x) { union IEEEl2bits u; - long double t=0.0,w,p,q,c,r,s; + long double c, p, q, r, s, t, w; int16_t expsign, expt; u.e = x; expsign = u.xbits.expsign; @@ -46,7 +44,7 @@ asinl(long double x) return (x-x)/(x-x); /* asin(|x|>1) is NaN */ } else if (exptone) return x;/* return x with inexact if x!=0*/ + if(huge+x>1) return x;/* return x with inexact if x!=0*/ } t = x*x; p = P(t); @@ -55,22 +53,22 @@ asinl(long double x) return x+x*w; } /* 1> |x|>= 0.5 */ - w = one-fabsl(x); - t = w*0.5; + w = 1-fabsl(x); + t = w/2; p = P(t); q = Q(t); s = sqrtl(t); if(u.bits.manh>=THRESH) { /* if |x| is close to 1 */ w = p/q; - t = pio2_hi-(2.0*(s+s*w)-pio2_lo); + t = pio2_hi-(2*(s+s*w)-pio2_lo); } else { u.e = s; u.bits.manl = 0; w = u.e; c = (t-w*w)/(s+w); r = p/q; - p = 2.0*s*r-(pio2_lo-2.0*c); - q = pio4_hi-2.0*w; + p = 2*s*r-(pio2_lo-2*c); + q = pio4_hi-2*w; t = pio4_hi-(p-q); } if(expsign>0) return t; else return -t; -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Mon Apr 17 01:05:09 2017 Return-Path: Delivered-To: freebsd-hackers@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 6D4ACD32F5D for ; Mon, 17 Apr 2017 01:05:09 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0057.outbound.protection.outlook.com [104.47.32.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FBD51AA1 for ; Mon, 17 Apr 2017 01:05:08 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0iysOyJ7/tbU58KcEVw6HAy1nzIQkvB3Ex2TWIvSEf4=; b=K5sw3mjEu3tSJQqtT6RdjvqI1OnI/jz91yPNOKApeWHr07uyIN9ZG+YA7VYYjSVJ306ZNoePauUPRq3l7CL+whP6TcRUIjJP8prQYSR39nlNMISMUpQfFKBmLK5hE7Ax+p7k5tZ/Vz2SrbgDiVcKMYSKXU7mlYVnUx+WocEi9X4= Received: from CO2PR05CA047.namprd05.prod.outlook.com (10.141.241.175) by SN1PR0501MB2048.namprd05.prod.outlook.com (10.163.227.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Mon, 17 Apr 2017 01:05:07 +0000 Received: from CY1NAM02FT030.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::205) by CO2PR05CA047.outlook.office365.com (2a01:111:e400:1429::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Mon, 17 Apr 2017 01:05:06 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by CY1NAM02FT030.mail.protection.outlook.com (10.152.75.163) with Microsoft SMTP Server id 15.1.1019.14 via Frontend Transport; Mon, 17 Apr 2017 01:05:06 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v3H155Tk026918 for ; Sun, 16 Apr 2017 20:05:05 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id 6148B248308; Sun, 16 Apr 2017 20:05:05 -0500 (CDT) Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id 2F671248004 for ; Sun, 16 Apr 2017 20:05:03 -0500 (CDT) Received: by mail-wr0-f175.google.com with SMTP id o21so76158045wrb.2 for ; Sun, 16 Apr 2017 18:05:03 -0700 (PDT) X-Gm-Message-State: AN3rC/4yzL/5oxkJIHWmYMoA46F5mo5/wmRJ7OeFtNUP3uUY/00IT0QR Zsn6g8K582C3tYdWwMa5qEDthwHcfg== X-Received: by 10.223.135.196 with SMTP id c4mr16141095wrc.109.1492391101901; Sun, 16 Apr 2017 18:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.39.134 with HTTP; Sun, 16 Apr 2017 18:04:41 -0700 (PDT) In-Reply-To: References: <20170416134756.GA88424@stack.nl> <20170416204326.GA24950@britannica.bec.de> From: Kyle Evans Date: Sun, 16 Apr 2017 20:04:41 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Replacing libgnuregex To: X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39410400002)(39840400002)(39860400002)(39850400002)(39400400002)(39450400003)(2980300002)(438002)(377454003)(189002)(199003)(24454002)(3480700004)(512874002)(9686003)(59536001)(76176999)(55446002)(498394004)(8936002)(606005)(189998001)(9896002)(6916009)(93516999)(54356999)(6306002)(6246003)(50986999)(63696999)(356003)(90966002)(2950100002)(75432002)(61726006)(84326002)(305945005)(45336002)(38730400002)(229853002)(110136004)(8676002)(53546009)(2906002)(88552002)(106466001)(86362001)(5660300001)(7116003)(236005)(7906003)(221733001)(42186005)(8576002)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0501MB2048; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1NAM02FT030; 1:0NZYuLVdEdCaXzGDutzsFmF9zRHjHBONzQVOT3CheVDPSvAQKc4/ng0TK35ApgQoP4qmZLpr2dCksXndgoinUai3yrrMZEWYHcX9j8rD7f0dHDUa/pnedtQkyZ0tgwFpkCnSUkqeTbf3UdPCJkyL0sXxs7V3Zxm0HnwIihOhCRHQ00YV/7iUQGhW/kTFLYGEKUTc6/PyyS1a7JpOGiq/B3w1AYbB9UzTGrNsr9kKfE2+H0ZGycYWgQhqEm7mhiAbTnJ1QEeyukT4FbbLJIIIhIOdjm2d2XIGtjSRFTDtqSx+UXa5MsbPg+FqbjMxiKRIA7HjvILcE9vroYL8n0HSG0p07HfqMpkotpH+oBT9sy3/5wY4HMzopafCZQxQ4p4Enkj3bwQfGBNfzmHNwZc1T5uo4a/w7QqSzTnfAkxu/sRHJP+I6iTSLjs0ixV5naAWrx347SZKyjNX7Ec5/rRGarMJUbb778Pq8cRdhLK2hiYvrLWFADZ+TNa+4FI+ryGuH/R0tGqaAznWLl9eQVpJSZU8mkZ+liUED6wym8JkmW8= X-MS-Office365-Filtering-Correlation-Id: 1fc2a56f-072e-43fa-ceca-08d4852dc978 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075)(201703131423075)(201703031133081); SRVR:SN1PR0501MB2048; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2048; 3:esOXD9lQg9hT+9ye/6SDUEnvL42rSre4I9yoVWkez34swtEciy+WS7rvxl3PXbFrYEqyeb3tzZ1J369OQLIOZ1tgWb4SXjQh48JzdPxiVvTXoQmF9V4BJ1xS4fITPcBiwFDN91xho9BEiVi9WJ703oxOKuTT6lEVwv2eld5+NX+3kzhC65GwupiV9xRjAWD8Kv3CYA8ASfjHquqv4zttITKk/uHm/0jL5R/t+6KKtXKF1fcBK0SfFjBNtxfcxlIpft8jIdwUfZEmLLW4DSDL8j55Wh28jLtRsVZhVkFO7nJWkYtp3mq3X4ICw4MBNgLiQIVAxhAERq3uqIJusdkOq9mUpUjkoJMHDxuKnXPqH0NzKI/TT4LrbgJBkV5h0LD7ViLdYV4YqkxMgpBUVvi7lme40dOoCWahoGiEGuGJEB8il9dZM1IjFjNOERWIPHLKk/WsSPmNoEqGe1LwIE7q5gsJmFvr7z0DgAJNnLTE1LUwox7Q0me1+D9Br1QuMBTY X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2048; 25:NIBB01rs/qHEFdO0F2FhxSqZ2t3gB5VHBys2qstM0smUU+/7Pn+QhAiAdzuUI2hqxEdJIqYHB0r2mJymif4nm5waS4yDrQcDjQuIz4oKD6P1026Du8/uc6youQPlEjXJrdOkG9Y89xr2zCXIdqdxLKuOwddOVwWnRFPXU57wnkS5KtOZdpM0Wp2zBs6UMg9bxmA36sX3klLcZBwdPy/UsXxhNxQLFPzZFK2yvrXJfD4o5qTu3OXhSMxHkTKunzuhq1AZ+qcfLyDWN9g1sT7icmyJMHP6tjkTdvqbLo/Wm1l01/psnrEWdmaxi8TtFPNjVHAnc4erf2DmdUhishJnWiWiAA4WqMrwILHtAfzmJYzhPKgRFkVEaqRk6x6/AyMYi5KEOvy0hbJaS5UnJERBHDFEtVaknUyeFUXCN0s4g7ZRojlHLQOQXtqggKLrvBSC2rO7MIkyXw7kYyT4ZOBctsm4SkMJ1IpulIO2b8Fk7b8=; 31:XCJ+PeCY22+0uLJ/2YzcF89Gio+Zo7w+rz9rsHF/zPxTjsg7L/Dd6CumfeUImaOhnyiQFUcqjzXZHUecaWldSWzIA5TsMlPsutg667x15SLIekY+TakfAgTZABOIwIFf2lwVmSRKqvokkQe/flQRyWrkefk8d08JgRsetNYjmJJGw5VKySsouY9aI7jfrvrUXxJa8up8JaF8+3l4Py5iKuDW3cwkarLleuHouPcHK4jTfdV9o36wwIM555+gnTzVcaDV7/urr/7zaAMm/dIY7w== X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2048; 20:Agr2oK3HxadnefjG0qB15mm5l6G/zhx/59ztDC37EbYWD+qxFb1IZWM+tkAuUfTmuaM001JskvhJ+SWEOuY3yrRB1YuqjLq3aWcZiLBIoe2+RhAR0VmOD5FTkhzkO3sblILpMr0AN0gBKAs9kRm0PBKPwQTqFjSNcD0zBkPW9Mqmha6tdfXEMicvccZs7q9ASj62eSXLiWCBMUxIVz2dATqIR2ofwia+t51jNe8/vM7vFQXp2zw2qPc9aBhsaYhd/1RqvOpiTMTNehwe5Tx7nliHSOnAHBEbDdTZyD87np0VFCvXX3w3e4R3HkbMNSRmeoLFciTAs2To3zt7lIyUng/aBLla9jlOi0VGH47xaio2G57PAUeBUg3LL5sLmdJVSFFWow7up8kD7+5q1rfD6ygUS/ZcTJIyxJ5Mlo25NmEujU5ri9opCSfTNJ3DBgQn3PyxKCvrVN8Aeg7qK7v7gI07pOMPJdXjTQh2YMTa5blFAQyL1pcTqrE2bn2ppDV+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(112903893386949)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13023025)(13024025)(13015025)(13018025)(13017025)(5005006)(8121501046)(93006095)(93004095)(3002001)(10201501046)(6041248)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:SN1PR0501MB2048; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2048; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2048; 4:HuxPqw9pfj+Ak2XyNCN0vIWqAcAd2vbws3TKXinFsOX5L+l/uk0YzmwuOGdL6WUEHuPa1ba2mXA4rRvWUFop+yLsS/uaWZEkFVrSW9kER1EXfJrfoNUILAmryq9L39CBI5JolBMeNx+ZbT/EiHgLcDLOSZHI/RuK1wF9Z7A+JzncxQuYWxxIIo9m74LUqfeKgzCrOdELs/HpZrXN76hVjBDKF0/KlQzOLa9pL4XPJrA/mQlZr9X0ziDbWHZs94027O22EjNrFUvhL+/DK8opW+2saQfmlSgmGtRtjBjsE2YYW8yESMKU89WENTEjbK3R/xq+Ur4xuWi0tcZkn0sc5GDPGu6sxzKpW9vXX6zvgxqvZfqo0UoNLvmtHkhy4AF2A9eiwwk8CI9r0gZjURmey3YIBgJM/lu/1SfflQf8ITIBn7ejrovhLKqSTqA7Iqwpz7mKZCeTG27cUlOv6s7ANBMAIb6Z/u4cvmx2z0HYxjAV2zJnv7705Lr6uJbx5abaKoZEeUpc+5hg+vbaB6QjY7zB7Icv2+1G1p9Q3MYcJJGN5CqfzxYcOZWciofhM30tFu3bSrdzYb1+JO1k113jHkP5HIMQ2C2xablJKPwHo9YQWRTmPdhDP+d5n8fEulzNBP6ujWlbG5IyW+SAmHmAm9QN75PnXMHFRsZFEdcC2+8s2oVB78++5rDs/jsHQbmdgl5jWLCJXHekKE5ApnWrIGSMd5xj/nt0/mGHzh/nKInQLb54IAD+DTd7EEcyTwwE+ppmBAGBCjAH/cow+siEzvdBxL/3NIZP8OF23als5hkxkwICdc8uydhJWHPkuNQ3JLpXabG1Mz04h2OLdJi1E1BUgFhRtKeE/RKevQaH1yJ1e0l81wvkFlb7V0Wrwo1vaF9OL5ravz+js9UGU3h8CRfJSHIRnbzrOsCIRHvYVQc= X-Forefront-PRVS: 02801ACE41 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB2048; 23:LuDRNYQtsxW6ksx1/U2ZeG2WBsu45GM1VbxzhGr?= =?us-ascii?Q?va0aIzw6mv8eNsmvR//Q2fW+qfMHjaA1pzuuMlOwDPvtifXr43o1D0n9eH6a?= =?us-ascii?Q?Mo8L492r1LAud6R0PoOyTTTy3+e+C0dp35cm3SRD/KIZADxNSyeB4TbpWMa+?= =?us-ascii?Q?4Kkv0O8LgzqGusgdzzxorkQPXtvsWMwg6WIi9Sxucnkzmj3TISThy30u9QlL?= =?us-ascii?Q?BHGBubayqOtVQwSF4+GlCX9IEAvqvP+ngSXcDfSfwuZhVZljJB8sOZF/pPfo?= =?us-ascii?Q?HIovgC2ESUQxgcCaGqppEQMovDJffWp57JQy1r5xVZLY7TyilKbflilxwlBx?= =?us-ascii?Q?lBL0DJEUnX3hgjUm/x2D/MyGIExjR83vE6j+RjjVe+/BWmzjRrbl6u9UrSu7?= =?us-ascii?Q?MhJrgrfyW+NYh6dpE25y2JFE2I6E2hGdLcdMw34E1/or5wEPbbFEsz/BOqoA?= =?us-ascii?Q?Rq4+ZECFtg6kdiZ9FWGvGiiqTw2HvU5zH2ZPptTKY+2eeWb5P0EQneu0Xo4O?= =?us-ascii?Q?wvTXyDxKD+FJFag04aCmqt4COdC/HxTE877MN1N1VsyIiEZLh246ISzbLJij?= =?us-ascii?Q?8xF74VHNGXXKNeFyQx5YbdbsVVOPgd7SUVdu52ikSCFQRQG9QDXBwiUQxW7C?= =?us-ascii?Q?wOzVZe6Uhx4sqAHmw1nCDbhMFWYHSHnZ4QccgkaVA50yZ49Pss+2ovNTHPJN?= =?us-ascii?Q?srlDmDlPpeD1YcBFlYGRhAqVUJntky0cBNLbjTrKzljY3kGJxXXEYd+VGIOm?= =?us-ascii?Q?FkilRrFCUhbYE/xUoHjxByqW3K5OkMBXLEQxla7CJVWET5b+lOIfBgOI8Lna?= =?us-ascii?Q?DWfgBwOm79qAt9ngy0ivNPbZ9X1eEP/vTCHJlWdM0pb0P/hXKTyhxhWMlxpF?= =?us-ascii?Q?uMePXTQvzxLRdQSFr570Q0RavOmCFA2fyL3W9KPNzIK7h6uwkIJfNvn4ycQf?= =?us-ascii?Q?BwbjXbg+7TbX+Dm2kFkn0niknj5OU0YuFjrIWMnT1oFFNyUICMrJCz/J0ema?= =?us-ascii?Q?Ia/o20tTKSyLmUF3BErjLyl1lX/LBbL/UKMlpMREYHT3aCpkP+2UoSprCDKW?= =?us-ascii?Q?Anwf1ls1JRcOw4PpyQFNpj5xuAXGG0oN2dVtuZk5iwYx7kBFAGZnIDx5vU+W?= =?us-ascii?Q?CRIEiGmOW9HGT+COn28N9H8M69dy/uORe5D+E+OkEfX+ZEJ8cp4ktau462tG?= =?us-ascii?Q?sA1eHRLYSKEra02/pvMIPeidg+GwJZQe+d4P/J5UeH8kaaQmM7i8GiR9P7MY?= =?us-ascii?Q?awDsVIWHhT/TUdCBVyWls0deqvD/gDLo/dmPff8CnlVFnb+a/f2EYpCofBsq?= =?us-ascii?Q?uy+CQOgjtbwgSe4jezYsMa/w=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2048; 6:RrCxMJXwjjwHrjjyKL9w08iRRcoKcxqpGI7qUX8lzRPD4HYCFEEmLgUFpE+okE6lIQ98H0VH4858OtxZv93uE1BPAfKMBHc4cN1ZXPxIYZpdsLuSBtzpX4f5gSMiGYaHlxA6PjJ5lYc2QZbLMbbsjGJ1I2UekgLjcqgRepezkjGXCZ1i3VEi5ySOkx6YwSBU/I4nHpdUJkZE2PMImdXlld/Modv2UwOYvfBe6a+5rGlYaNVqrkaOxSyYR/GwVbi+H8R8n9pDPLMedjTxzvS9Av1okwNT6RwZjG3nG7eHKg9KcnthmYoJF4l4h/0n2le2+9zCd3H4KFXp/16L7roq5kGSFxK7X0YbwNtfalxLQRTdAO9J5nwzdd3WnZXBduGau4pzSAfhWqKOXqo3y4wqaBhuUN2Ddu7nUl5VhBZLHD3XoK0LceSE+0MpL60otnO2BwD8R2Z+E7vn5Kjnpx7ZPA==; 5:ZzTVMrXLcbxtYlsO6Sbj83fFrbqj7Z81cj85zOaUi4AtuLFmMO0JVjkqvRar0ObFpX/ddU+3RBTvkoVKWhzllZFSwmyc+27VQV3wm0V1sye1/EkL2Mkkz/DXxHxYksJ3zFrn8tGA/cV2rPdGNEfDRICaxnz6jhAiO8WrTvbCYvY=; 24:iXvE7HpYci5U1Kfjo/nen2DYgIV2vjBC6QYEXxsZxv8CYzUy322sWqGCwWCAI1L8p+/gGpfgQ+I+kR4oaDpoDJsl//8jPm9QDsri4RTtySk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2048; 7:1zGTRMVu9ORaPWdfB+IGhA0nY1s8Lx8nsYSaZ8AORFhmTMpwpr6A41KQVt0nIzeC4zcONykOoG3cBwf/d5WSo9io5ravH6kj3b9PBL/hJExGV3xojvG6JYUubf8ZjhyQjiHK3kajA+B5QfeGoHNoq0wxdr33m/zMb82XegLLQoCLuNmx5Mrr353xI1nPR5nXQ0jkMFJSvMlfYs6Pzh1vGcE4tC0pdfM4W7XYUWO6aC7Cu2MvWZzo4fCTgUE9a4TRxuAq4Y0Ry6jN60fNOChwD6/lVR7B7tLmfQWswFNA8Ud84n6NctfGZKqi31FIOxxBtikN7sXXtaKhGgGI8Zlyeg==; 20:zaikEauAje+TmGDrEJpapI4zoh4QsF6a67qDpQ68Ggc3uBwMWPhZM7XrahSKpYwlFvaOSY8sNlZmfDGpXZtksVfrlNZ53tf4a3DaVoIuMIu3uHTfp9K4GKjNpviln/oUz5YN6RzY4d0lnetLlQuiF1YSVTaYmiZFYku9AGlOeso= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2017 01:05:06.4196 (UTC) X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2048 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 01:05:09 -0000 On Sun, Apr 16, 2017 at 6:37 PM, Kyle Evans wrote: > On Sun, Apr 16, 2017 at 3:43 PM, Joerg Sonnenberger wrote: > >> On Sun, Apr 16, 2017 at 03:47:56PM +0200, Jilles Tjoelker wrote: >> > On Tue, Apr 11, 2017 at 03:20:58PM -0500, Kyle Evans wrote: >> > > On the other hand, I think I could fairly easily implement most of >> these >> > > into libc/regex. Here's a summary of what this option entails adding >> to >> > > libc/regex, from what I've found: >> > >> > > [snip] >> > > * Add backreferences (\1 through \9) to EREs >> > > [snip] >> > >> > Adding this enforces that EREs, like BREs, may sometimes require >> > exponential time to match. I would prefer to avoid that. >> >> The Spencer RE doesn't need backreferences to be exponential, but I >> certainly agree that adding support for them makes it more difficult to >> change to a better RE implementation later. >> > > Are there plans in progress to replace this at some point? > > If not, would it be acceptable to lib'ify what we have now, ensure the > libc bits remain strict POSIX (-DPOSIX_STRICT to exclude any GNU cruft, not > just disabled at runtime), and have the libregex version include GNU > extensions? This seems likes a reasonable approach to make sure > expectations of libc remain as they are now while also not introducing more > maintenance overhead, assuming there are no immediate plans to replace the > regex implementation. > To be perfectly clear, what I mean by "lib'ify" is generally this patch: https://files.kyle-evans.net/freebsd/libregex.diff Changes made to the source to make non-libc build work properly, tested with the netbsd-tests on libc as well as libregex. Further changes to include GNU extensions or whatnot would be conditionally compiled into libregex, and libregex may be excluded by adrian@ on his MIPS builds. =) bsdgrep(1) may be adjusted to link libregex (if it's being built) to maintain GNU extensions going forward, but I suspect that change would be after the dust settles on the bsdgrep stuff going on right now and if I can find a nice middle-ground to get libgnuregex replaced. From owner-freebsd-hackers@freebsd.org Mon Apr 17 00:47:13 2017 Return-Path: Delivered-To: freebsd-hackers@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 E31B4D325E0; Mon, 17 Apr 2017 00:47:13 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB69AE46; Mon, 17 Apr 2017 00:47:12 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id B986DC0E; Sun, 16 Apr 2017 19:47:11 -0500 (CDT) Date: Sun, 16 Apr 2017 19:47:10 -0500 From: Mark Linimon To: Jaguar DaRocha Cc: "freebsd-ppc@freebsd.org" , "freebsd-hackers@freebsd.org" , "baptiste.daroussin@gmail.com" Subject: Re: Fwd: powerpc packages? Message-ID: <20170417004710.GA13407@lonesome.com> References: <6510231492387508@web21g.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6510231492387508@web21g.yandex.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Mon, 17 Apr 2017 03:00:01 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 00:47:14 -0000 There was no text. However, I am working on building unofficial packages for powerpc64-11 from the quarterly branch. The repository is not stable yet, so I don't wish to widely advertise it until it is better tested/documented. Anyone interested should feel free to contact me privately. mcl From owner-freebsd-hackers@freebsd.org Mon Apr 17 04:08:11 2017 Return-Path: Delivered-To: freebsd-hackers@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 F1CC8D41623; Mon, 17 Apr 2017 04:08:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 767A487B; Mon, 17 Apr 2017 04:08:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id C1FE010507A; Mon, 17 Apr 2017 14:08:02 +1000 (AEST) Date: Mon, 17 Apr 2017 14:07:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org Subject: Re: [PATCH] Fixes for asin[fl]. In-Reply-To: <20170417001816.GA10277@troutmask.apl.washington.edu> Message-ID: <20170417134317.E931@besplex.bde.org> References: <20170417001816.GA10277@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=bSSs6WrcAUF_AD4-SooA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Mon, 17 Apr 2017 04:40:20 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 04:08:12 -0000 On Sun, 16 Apr 2017, Steve Kargl wrote: > Please commit. > > * libm/msun/src/e_asin.c: > . Use integer literal constants where possible. This reduces diffs > between e_asin[fl].c. > . Remove a spurious tab in front of a single line comment. > . Sort declaration. > . Remove initialization of 't' in declaration statement. It's not needed. This is mostly backwards. Don't make style changes away from fdlibm. fdlibm only has e_asin.c, and cygnus' e_asinf.c might have gratuitous differences, and our e_asinl.c is too different due to its hiding of the polynomial coeeficients and evaluation in invtrig.[ch] (there are many style bugs and small errors in the coefficients hidden in the latter). > Index: src/e_asin.c > =================================================================== > --- src/e_asin.c (revision 1904) > +++ src/e_asin.c (working copy) > @@ -50,12 +50,13 @@ __FBSDID("$FreeBSD: head/lib/msun/src/e_ > #include "math_private.h" > > static const double > -one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ Spelling 1 as "one" is standard style in fdlibm. If fdlibm supported float precision, then it whould do this even more, since this allows spelling all the float constants without an F, as needed to avoid them being double constants. > @@ -70,7 +71,7 @@ qS4 = 7.70381505559019352791e-02; /* 0x > double > __ieee754_asin(double x) > { > - double t=0.0,w,p,q,c,r,s; > + double c, p, q, r, s, t, w; > int32_t hx,ix; > GET_HIGH_WORD(hx,x); > ix = hx&0x7fffffff; Removing t is correct. > @@ -83,30 +84,30 @@ __ieee754_asin(double x) > return (x-x)/(x-x); /* asin(|x|>1) is NaN */ > } else if (ix<0x3fe00000) { /* |x|<0.5 */ > if(ix<0x3e500000) { /* if |x| < 2**-26 */ > - if(huge+x>one) return x;/* return x with inexact if x!=0*/ > + if(huge+x>1) return x;/* return x with inexact if x!=0*/ > } > t = x*x; > p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))); > - q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4))); > + q = 1+t*(qS1+t*(qS2+t*(qS3+t*qS4))); > w = p/q; > return x+x*w; > } > /* 1> |x|>= 0.5 */ > - w = one-fabs(x); > - t = w*0.5; > + w = 1-fabs(x); > + t = w/2; It was bad to spell 1 as one, but 2 as 2. > p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))); > - q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4))); > + q = 1+t*(qS1+t*(qS2+t*(qS3+t*qS4))); This still uses a slow rational function approximation and evaluates it slowly using Horner's method. I have only fixed this in my float version. The polynomial has terms out to S11, and would need too many terms for long doubles. But so does the rational function. > s = sqrt(t); > if(ix>=0x3FEF3333) { /* if |x| > 0.975 */ > w = p/q; > - t = pio2_hi-(2.0*(s+s*w)-pio2_lo); > + t = pio2_hi-(2*(s+s*w)-pio2_lo); > } else { > w = s; > SET_LOW_WORD(w,0); > c = (t-w*w)/(s+w); > r = p/q; The rational function is not all that slow, since there is a sqrt() as well as a division in some cases, but the division limits accuracy. So does the sqrt(). The float version cheats by using double for sqrt(). Bruce From owner-freebsd-hackers@freebsd.org Mon Apr 17 04:57:28 2017 Return-Path: Delivered-To: freebsd-hackers@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 B15A9D40956; Mon, 17 Apr 2017 04:57:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B94E998; Mon, 17 Apr 2017 04:57:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3H4vRAr011314 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Apr 2017 21:57:27 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3H4vPFk011313; Sun, 16 Apr 2017 21:57:25 -0700 (PDT) (envelope-from sgk) Date: Sun, 16 Apr 2017 21:57:25 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org Subject: Re: [PATCH] Fixes for asin[fl]. Message-ID: <20170417045725.GA11263@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170417001816.GA10277@troutmask.apl.washington.edu> <20170417134317.E931@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170417134317.E931@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 04:57:28 -0000 On Mon, Apr 17, 2017 at 02:07:57PM +1000, Bruce Evans wrote: > On Sun, 16 Apr 2017, Steve Kargl wrote: > > > Please commit. > > > > * libm/msun/src/e_asin.c: > > . Use integer literal constants where possible. This reduces diffs > > between e_asin[fl].c. > > . Remove a spurious tab in front of a single line comment. > > . Sort declaration. > > . Remove initialization of 't' in declaration statement. It's not needed. > > This is mostly backwards. Don't make style changes away from fdlibm. > fdlibm only has e_asin.c, and cygnus' e_asinf.c might have gratuitous > differences, and our e_asinl.c is too different due to its hiding of > the polynomial coeeficients and evaluation in invtrig.[ch] (there are > many style bugs and small errors in the coefficients hidden in the > latter). fdlibm will never be updated. So whatever fdlibm does/did is irrelevant. For e_asinf.c, like most cygnus attributed code, the conversion from double to float is, ahem, rather questionable. As for e_asinl.c, I have doubts to its suitability to ld128. > > Index: src/e_asin.c > > =================================================================== > > --- src/e_asin.c (revision 1904) > > +++ src/e_asin.c (working copy) > > @@ -50,12 +50,13 @@ __FBSDID("$FreeBSD: head/lib/msun/src/e_ > > #include "math_private.h" > > > > static const double > > -one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > > Spelling 1 as "one" is standard style in fdlibm. If fdlibm supported > float precision, then it whould do this even more, since this allows > spelling all the float constants without an F, as needed to avoid them > being double constants. Most compilers for the last 20 years know how to convert 1 to float, double, and long double. This is in line with getting rid of (float)0.5 type code. > > @@ -70,7 +71,7 @@ qS4 = 7.70381505559019352791e-02; /* 0x > > double > > __ieee754_asin(double x) > > { > > - double t=0.0,w,p,q,c,r,s; > > + double c, p, q, r, s, t, w; > > int32_t hx,ix; > > GET_HIGH_WORD(hx,x); > > ix = hx&0x7fffffff; > > Removing t is correct. > > > @@ -83,30 +84,30 @@ __ieee754_asin(double x) > > return (x-x)/(x-x); /* asin(|x|>1) is NaN */ > > } else if (ix<0x3fe00000) { /* |x|<0.5 */ > > if(ix<0x3e500000) { /* if |x| < 2**-26 */ > > - if(huge+x>one) return x;/* return x with inexact if x!=0*/ > > + if(huge+x>1) return x;/* return x with inexact if x!=0*/ > > } > > t = x*x; > > p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))); > > - q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4))); > > + q = 1+t*(qS1+t*(qS2+t*(qS3+t*qS4))); > > w = p/q; > > return x+x*w; > > } > > /* 1> |x|>= 0.5 */ > > - w = one-fabs(x); > > - t = w*0.5; > > + w = 1-fabs(x); > > + t = w/2; > > It was bad to spell 1 as one, but 2 as 2. ? > > p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))); > > - q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4))); > > + q = 1+t*(qS1+t*(qS2+t*(qS3+t*qS4))); > > This still uses a slow rational function approximation and evaluates it > slowly using Horner's method. I have only fixed this in my float version. > The polynomial has terms out to S11, and would need too many terms for > long doubles. But so does the rational function. I'll get to that problem later. See my sinpi[fl] inplementations. One does not need a rational approximation (at least with sinpi). > > s = sqrt(t); > > if(ix>=0x3FEF3333) { /* if |x| > 0.975 */ > > w = p/q; > > - t = pio2_hi-(2.0*(s+s*w)-pio2_lo); > > + t = pio2_hi-(2*(s+s*w)-pio2_lo); > > } else { > > w = s; > > SET_LOW_WORD(w,0); > > c = (t-w*w)/(s+w); > > r = p/q; > > The rational function is not all that slow, since there is a sqrt() as > well as a division in some cases, but the division limits accuracy. So > does the sqrt(). The float version cheats by using double for sqrt(). If you look at my patch, you'll see that the sqrt() in the float version has been replaced with sqrtf(). The float version cheats by using double in a few places. I think I know how to fix that issue. I also think that sqrt[fl] can be replaced by an in-line specialized sqrt to avoid the overhead of sqrt[fl]. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Mon Apr 17 09:24:58 2017 Return-Path: Delivered-To: freebsd-hackers@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 4B081D41F8F; Mon, 17 Apr 2017 09:24:58 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id EDE20A7D; Mon, 17 Apr 2017 09:24:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 1C963101DD7; Mon, 17 Apr 2017 19:24:53 +1000 (AEST) Date: Mon, 17 Apr 2017 19:24:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: Bruce Evans , freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org Subject: Re: [PATCH] Fixes for asin[fl]. In-Reply-To: <20170417045725.GA11263@troutmask.apl.washington.edu> Message-ID: <20170417182217.V1740@besplex.bde.org> References: <20170417001816.GA10277@troutmask.apl.washington.edu> <20170417134317.E931@besplex.bde.org> <20170417045725.GA11263@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=-nA7janlvo-EyaNZGOsA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Mon, 17 Apr 2017 11:50:50 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 09:24:58 -0000 On Sun, 16 Apr 2017, Steve Kargl wrote: > On Mon, Apr 17, 2017 at 02:07:57PM +1000, Bruce Evans wrote: >> On Sun, 16 Apr 2017, Steve Kargl wrote: >> >>> Please commit. >>> >>> * libm/msun/src/e_asin.c: >>> . Use integer literal constants where possible. This reduces diffs >>> between e_asin[fl].c. >>> . Remove a spurious tab in front of a single line comment. >>> . Sort declaration. >>> . Remove initialization of 't' in declaration statement. It's not needed. >> >> This is mostly backwards. Don't make style changes away from fdlibm. >> fdlibm only has e_asin.c, and cygnus' e_asinf.c might have gratuitous >> differences, and our e_asinl.c is too different due to its hiding of >> the polynomial coeeficients and evaluation in invtrig.[ch] (there are >> many style bugs and small errors in the coefficients hidden in the >> latter). > > fdlibm will never be updated. So whatever fdlibm does/did > is irrelevant. For e_asinf.c, like most cygnus attributed > code, the conversion from double to float is, ahem, rather > questionable. As for e_asinl.c, I have doubts to its > suitability to ld128. Predicting the future is not easy. Consider my version as the reference if not fdlibm. Cygnus did a not so bad job in the apparently short time available. They didn't increase the maintainence problem with cosmetic changes, perhaps for the smae portability reasons. I haven't tested e_asinl.c much. e_atanl.c is more of a problem. This fails some accuracy tests even with ld80. Otherwise, the inverse trig (non-hyperbolic) functions seem to be easier to evaluate accurately than most functions -- errors for float and double precision are somehow less than 1 ulp. >>> Index: src/e_asin.c >>> =================================================================== >>> --- src/e_asin.c (revision 1904) >>> +++ src/e_asin.c (working copy) >>> @@ -50,12 +50,13 @@ __FBSDID("$FreeBSD: head/lib/msun/src/e_ >>> #include "math_private.h" >>> >>> static const double >>> -one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ >> >> Spelling 1 as "one" is standard style in fdlibm. If fdlibm supported >> float precision, then it whould do this even more, since this allows >> spelling all the float constants without an F, as needed to avoid them >> being double constants. > > Most compilers for the last 20 years know how to convert 1 to > float, double, and long double. This is in line with getting > rid of (float)0.5 type code. I think that is my idea :-). I only use it in new code. >>> /* 1> |x|>= 0.5 */ >>> - w = one-fabs(x); >>> - t = w*0.5; >>> + w = 1-fabs(x); >>> + t = w/2; >> >> It was bad to spell 1 as one, but 2 as 2. > > ? 'one' was used for some technical or stylistic reason. Perhaps just to ensure that the compiler doesn't mistranslate it. Here 2 was used inverted as 0.5. There are even more reasons to spell this 0.5 as 'half' as is done in some places. It takes knowing a lot about the C standard and compilers to know that the compiler will first promote 2 to (type)2.0 with the correct type, and then strength-reduce the multiplication to division iff that is good. I think the unambiguous promotion rule was new in C90. Too new for fdlibm a couple of years later. The strength reduction is only correct if either the floating point is fuzzy or if it is as in Annex F or some other extension, and the result doesn't depend on the method in any rounding mode or if a pragma allows fuzziness. I think the result doesn't depend on the method in any rounding mode in IEEE754 arithmetic. We use this simplication in new code though it isn't portable. Anyone wanting portable code would have to change back to multiplying by 0.5. >>> p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))); >>> - q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4))); >>> + q = 1+t*(qS1+t*(qS2+t*(qS3+t*qS4))); >> >> This still uses a slow rational function approximation and evaluates it >> slowly using Horner's method. I have only fixed this in my float version. >> The polynomial has terms out to S11, and would need too many terms for >> long doubles. But so does the rational function. > > I'll get to that problem later. See my sinpi[fl] inplementations. > One does not need a rational approximation (at least with sinpi). sin() is fundamentally different. Its power series of course converges everywhere, and deeper magic lets it converge fairly fast out to pi/4. This also allows good polynomial approximations (no worse than some leading terms of the power series). Other functions benefit more from using rational functions. tan() does, and is actually implemented as a disguised rational function. >>> s = sqrt(t); >>> if(ix>=0x3FEF3333) { /* if |x| > 0.975 */ >>> w = p/q; >>> - t = pio2_hi-(2.0*(s+s*w)-pio2_lo); >>> + t = pio2_hi-(2*(s+s*w)-pio2_lo); >>> } else { >>> w = s; >>> SET_LOW_WORD(w,0); >>> c = (t-w*w)/(s+w); >>> r = p/q; >> >> The rational function is not all that slow, since there is a sqrt() as >> well as a division in some cases, but the division limits accuracy. So >> does the sqrt(). The float version cheats by using double for sqrt(). > > If you look at my patch, you'll see that the sqrt() in the > float version has been replaced with sqrtf(). The float version > cheats by using double in a few places. I think I know how to > fix that issue. It's difficult without losing accuracy or efficiency. That is why we switched to using sqrt(). My accuracy tests: float precision: acos: max_er = 0x1cbc92d0 0.8980, avg_er = 0.170, #>=1:0.5 = 0:5422147 (old) acos: max_er = 0x1cc99656 0.8996, avg_er = 0.170, #>=1:0.5 = 0:5584360 asin: max_er = 0x1d9cc0b9 0.9254, avg_er = 0.013, #>=1:0.5 = 0:2357938 (old) asin: max_er = 0x1619e27c 0.6907, avg_er = 0.012, #>=1:0.5 = 0:3315992 atan: max_er = 0x1b44773c 0.8521, avg_er = 0.186, #>=1:0.5 = 0:6406812 (old) atan: max_er = 0x1b3b6262 0.8510, avg_er = 0.186, #>=1:0.5 = 0:6759430 double precision: acos: max_er = 0x708 0.8789, avg_er = 0.137, #>=1:0.5 = 0:766994 asin: max_er = 0x6ca 0.8486, avg_er = 0.003, #>=1:0.5 = 0:354026 atan: max_er = 0x618 0.7617, avg_er = 0.140, #>=1:0.5 = 0:1142804 Here '(old)' is the committed version and the other float precision one is the development version (5-10 years old). The development version doesn't use rational functions (except possibly disguised). It is slightly less accurate, except for asinf() it is much more accurate. asinf() still uses sqrt(), but acosf() always used sqrt(). Note that the double precision versions are accurate enough despite not using sqrtl(). I think they sacrifice efficiency to be so accurate. > I also think that sqrt[fl] can be replaced by an in-line specialized > sqrt to avoid the overhead of sqrt[fl]. No way. sqrt[fl] is already inlined by the compiler at -O1 on most or all arches. It is also in libm as a function, but the function is rarely called. The C versions are too slow to be usable. On Haswell with gcc-3.3: fdlsqrtf: cycles per call: 101-168 fdlsqrt: cycles per call: 596-680 fdlsqrtl: cycles per call: 1119-1121 Most of the time is for perfect rounding which is not needed. Take that out and the software sqrtl might be only 10 times slower than the hardware version instead of 50 times slower. It would be about as slow as cbrtl: fdlcbrtf: cycles per call: 38-38 fdlcbrt: cycles per call: 166-166 fdlcbrtl: cycles per call: 77-81 This is with my optimized cbrtl (also cbrtf?) and committed cbrt. Haswell handles standard optimizations especially well but does badly with the old method in cbrt. Someone in comp.arch optimized cbrtl much more using methods that are too unportable for me. It is possible to get cbrt down to 20-30 cycles on Ivy Bridge. I can only do this for cbrtf using more portable methods and I still need SSE1. Bruce From owner-freebsd-hackers@freebsd.org Mon Apr 17 17:15:52 2017 Return-Path: Delivered-To: freebsd-hackers@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 20E02D4248F for ; Mon, 17 Apr 2017 17:15:52 +0000 (UTC) (envelope-from ablacktshirt@gmail.com) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4C63C8 for ; Mon, 17 Apr 2017 17:15:51 +0000 (UTC) (envelope-from ablacktshirt@gmail.com) Received: by mail-pg0-x243.google.com with SMTP id 63so15322789pgh.0 for ; Mon, 17 Apr 2017 10:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ke6p95ySSMz4Rap7lwncmAcoi7HSs+49oACgiwohkMU=; b=dd7p68BN3OSQfPRIlq163GnZ7AArX/A/o0atiidCULqv6cPLvlIKppeRrW0iGWs70C TjA1EkA8XbfyDoRmVhokhX/UkgGyOCN35Y7SDhcbZ29W2o7yXdZka2A/IW8Ne1oLG79H W5d8A2ut8ZBs/0MTPLMXIFGUhNOONEhp2C2Q9vGCLWUIWebdIlKsKC74mp2OzWTYw7nw xjq9rtwS2OFoTkraWxiTnwa1tNF6z0Iv9V9GmKXVWS3u/GZlEmvpuMJMDsP9N9aAZdiF RSlpW7FWTb21eZtumuIEQljUqaYaQgQFa7YEAg7wsm1zburwK0jnE8E9pHTV6Q4jmLKs 8ZLg== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ke6p95ySSMz4Rap7lwncmAcoi7HSs+49oACgiwohkMU=; b=kivib+JvC+AH8M/8hMCbq4iI9vd833Y3bb3Cst/tTyowKJxCMuxL4OPyNdxSefn176 26e1fhRnNiL1N9VkS/trRMwYyoKAouZLKm1glFh3P4Ssxh2slSItiK8NSAvkvfr48JIa bDB4pDEAH5BW8iiTZBjraVhcTzlwVciKie5CpO3l+HbtsKxppKCAks12qsIaf0CldnAE knkKp8PiNFGVQn3j87hj1U18bE+LPAED3v3sSDne8juLtNEZVL0jp8X7j2U+hNUpU5Fy 1HReTPecbcx9W3bwGGZ0UARx7K4W8XXN3wWzuxvTfjRd+E/mLhisMRYq6B2iPnlvYq7O 0HGg== X-Gm-Message-State: AN3rC/62UEaH/Ll/LIq3mT2YmEvQ+UyysPdK3V/eAul+X2zGNkctnEhU SCD5NfcWC6yXVg== X-Received: by 10.99.225.5 with SMTP id z5mr13233024pgh.145.1492449351336; Mon, 17 Apr 2017 10:15:51 -0700 (PDT) Received: from [192.168.0.100] ([110.64.91.54]) by smtp.gmail.com with ESMTPSA id b8sm19336398pgn.51.2017.04.17.10.15.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 10:15:50 -0700 (PDT) Subject: Re: Understanding the FreeBSD locking mechanism To: Chris Torek , imp@bsdimp.com References: <201704131218.v3DCIBJg093207@elf.torek.net> Cc: ed@nuxi.nl, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rysto32@gmail.com From: Yubin Ruan Message-ID: Date: Tue, 18 Apr 2017 01:15:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201704131218.v3DCIBJg093207@elf.torek.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:15:52 -0000 On 2017/4/13 20:18, Chris Torek wrote: >> I discover that in the current implementation in FreeBSD, spinlock >> does not disable interrupt entirely: > [extra-snipped here] >> 610 /* Give interrupts a chance while we spin. */ >> 611 spinlock_exit(); >> 612 while (m->mtx_lock != MTX_UNOWNED) { > [more snip] > >> This is `_mtx_lock_spin_cookie(...)` in kern/kern_mutex.c, which >> implements the core logic of spinning. However, as you can see, while >> spinning, it would enable interrupt "occasionally" and disable it >> again... What is the rationale for that? > > This code snippet is slightly misleading. The full code path runs > from mtx_lock_spin() through __mtx_lock_spin(), which first > invokes spinlock_enter() and then, in the *contested* case (only), > calls _mtx_lock_spin_cookie(). > > spinlock_enter() is: > > td = curthread; > if (td->td_md.md_spinlock_count == 0) { > flags = intr_disable(); > td->td_md.md_spinlock_count = 1; > td->td_md.md_saved_flags = flags; > } else > td->td_md.md_spinlock_count++; > critical_enter(); > > so it actualy disables interrupts *only* on the transition from > td->td_md.md_spinlock_count = 0 to td->td_md.md_spinlock_count = 1, > i.e., the first time we take a spin lock in this thread, whether > this is a borrowed thread or not. It's possible that interrupts > are actually disabled at this point. If so, td->td_md.md_saved_flags > has interrupts disabled as well. This is all just an optimization > to use a thread-local variable so as to avoid touching hardware. > The details vary widely, but typically, touching the actual hardware > controls requires flushing the CPU's instruction pipeline. > > If the compare-and-swap fails, we enter _mtx_lock_spin_cookie() > and loop waiting to see if we can obtain the spin lock in time. > In that case, we don't actually *hold* this particular spin lock > itself yet, so we can call spinlock_exit() to undo the effect > of the outermost spinlock_enter() (in __mtx_lock_spin). That > decrements the counter. *If* it goes to zero, that also calls > intr_restore(td->td_md.md_saved_flags). > > Hence, if we have failed to obtain our first spin lock, we restore > the interrupt setting to whatever we saved. If interrupts were > already locked out (as in a filter type interrupt handler) this is > a potentially-somewhat-expensive no-op. If interrupts were > enabled previously, this is a somewhat expensive re-enable of > interrupts -- but that's OK, and maybe good, because we have no > spin locks of our own yet. That means we can take hardware > interrupts now, and let them borrow our current thread if they are > that kind of interrupt, or schedule another thread to run if > appropriate. That might even preempt us, since we do not yet hold > any spin locks. (But it won't preempt us if we have done a > critical_enter() before this point.) > > (In fact, the spinlock exit/enter calls that you see inside > _mtx_lock_spin_cookie() wrap a loop that does not use compare-and- > swap operations at all, but rather ordinary memory reads. These > are cheaper than CAS operations on a lot of CPUs, but they may > produce wrong answers when two CPUs are racing to write the same > location; only a CAS produces a guaranteed answer, which might Hmm...I agree. I mis-read your words. The loop inside _mtx_lock_spin_cookie() might produce a wrong result, but the overall _mtx_lock_spin_cookie() won't, because it finally use a compare-and-swap instruction to test finally. (i.e the loop might produce a "false positive" result, so we have to check again....) -- yubinr > still be "you lost the race". The inner loop you are looking at > occurs after losing a CAS race. Once we think we might *win* a > future CAS race, _mtx_lock_spin_cookie() calls spinlock_enter() > again and tries the actual CAS operation, _mtx_obtain_lock_fetch(), > with interrupts disabled. Note also the calls to cpu_spinwait() > -- the Linux equivalent macro is cpu_relax() -- which translates > to a "pause" instruction on amd64.) > > Chris > From owner-freebsd-hackers@freebsd.org Mon Apr 17 18:19:38 2017 Return-Path: Delivered-To: freebsd-hackers@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 BB31DD42DE7 for ; Mon, 17 Apr 2017 18:19:38 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A3BE1242 for ; Mon, 17 Apr 2017 18:19:38 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:418:3fd::1f] (haymarket.m5p.com [IPv6:2001:418:3fd::1f]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id v3HIJU8o002882 for ; Mon, 17 Apr 2017 14:19:35 -0400 (EDT) (envelope-from george+freebsd@m5p.com) To: freebsd-hackers@FreeBSD.org From: George Mitchell Subject: Is this a cache poisoning attack? Message-ID: <15f762bd-383b-3545-c300-2b0bc92f2cfd@m5p.com> Date: Mon, 17 Apr 2017 14:19:24 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TweOOwuQeS0B9QxHwktndtlPErK1k8CXj" X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.1 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Mon, 17 Apr 2017 14:19:36 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 18:19:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TweOOwuQeS0B9QxHwktndtlPErK1k8CXj Content-Type: multipart/mixed; boundary="WMr1OesIgIiA0vENK5cAcR3fauXi39kiK"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@FreeBSD.org Message-ID: <15f762bd-383b-3545-c300-2b0bc92f2cfd@m5p.com> Subject: Is this a cache poisoning attack? --WMr1OesIgIiA0vENK5cAcR3fauXi39kiK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm getting a plethora of errors like this in my system log, as my sendmail is attempting to validate the domain names of incoming envelope senders of spammers (identifying info deleted): DNS format error from xxx#53 resolving xxx/MX for client xxx:xxx: Name . (SOA) not subdomain of zone xxx -- invalid response FreeBSD 10.3-RELEASE-p18, BIND 9.11.0-P5. Name service seems to be working normally otherwise. Is this a symptom of an attempted cache poisoning attack? -- George --WMr1OesIgIiA0vENK5cAcR3fauXi39kiK-- --TweOOwuQeS0B9QxHwktndtlPErK1k8CXj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlj1BywACgkQwRES3m+p 4fk0Wg/9E45G6vmW8g+jYOZFEqKeNbuLlld8AitB6n9sCosG9XGDfaDXDKIMxNPj cfsgD0KnGolCpxLkJjzMqHwHzj8mf5ICdveBY1WtBjCeMu694WQyKNYyqfP6w638 3bbRFDjGy9jFhvP7AikV5kyaVIp7UZVTHNW9ki89S1mtC1sZq4QDtgonxoyw1lr7 BoilM9DsNd1mYehX1bUwD95sXvMJEKyc4w1S7JmtWTf4CzjqYFVd5uKFq/Bg1QJ5 Vxl0Tu+IhAh9O8SNRHY3lTMNnOMsiL6p4EuhFOglqRq6ueSdLCUSxzqOVBAfrkTW 8lRwxNjOhTcgeXgeB9X8QKVJFPN/vwoO8WvWmjsgW4wB6MRyf0b3jkAoQbfa43Qe +QrE8qv1aMqg0jo0CmGmfSXqwFvjYLX9nKJgZvAe77utrxR9k+HrcgJiSTwDsxCv hxiAs84AUQp8kTu3kSD8RD7tMfJsaw8hGpq5EK0x0cpSlxOcAV8FQcxnT2SngPBW j0zw1+J7nWHUHjxzoE8B/zDjKvq95bDLtlTAbjn06Cil5WJlRw00fQKFA2VZ4LT0 ycVCemFDlRGCSll/n6fTxWWuiIEcgyujP/ZgEmV/GL2UiYmXshXyOB432c5dghUW RPtDgfYtHfyMgK+9hhUQyAgcACwtu56dtjsJKgp1efIHxJn+T88= =zztv -----END PGP SIGNATURE----- --TweOOwuQeS0B9QxHwktndtlPErK1k8CXj-- From owner-freebsd-hackers@freebsd.org Tue Apr 18 17:19:31 2017 Return-Path: Delivered-To: freebsd-hackers@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 931C2D44E3E for ; Tue, 18 Apr 2017 17:19:31 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 111DF77B for ; Tue, 18 Apr 2017 17:19:30 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id v3IGnenS032517 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Apr 2017 18:49:41 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.15.2/8.14.9) with ESMTP id v3IGnaZG014435 for ; Tue, 18 Apr 2017 18:49:36 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.15.2/8.14.9/Submit) with ESMTP id v3IGnU64014432 for ; Tue, 18 Apr 2017 18:49:31 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Tue, 18 Apr 2017 18:49:30 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: lock order reversal dirhash/bufwait Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 17:19:31 -0000 i'm getting this with latest 10-stable with witness etc. enabled. how to fix it? UFS options are options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big lock order reversal: 1st 0xfffffe0060aa58f8 bufwait (bufwait) @ kern/vfs_bio.c:3130 2nd 0xfffff800048db800 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:280 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2e/frame 0xfffffe0072edcf90 kdb_backtrace() at kdb_backtrace+0x58/frame 0xfffffe0072edd040 _witness_debugger() at _witness_debugger+0x34/frame 0xfffffe0072edd060 witness_checkorder() at witness_checkorder+0xfda/frame 0xfffffe0072edd280 _sx_xlock() at _sx_xlock+0x12f/frame 0xfffffe0072edd2d0 ufsdirhash_acquire() at ufsdirhash_acquire+0x4a/frame 0xfffffe0072edd300 ufsdirhash_add() at ufsdirhash_add+0x1c/frame 0xfffffe0072edd340 ufs_direnter() at ufs_direnter+0xc4a/frame 0xfffffe0072edd490 ufs_makeinode() at ufs_makeinode+0x58d/frame 0xfffffe0072edd620 ufs_create() at ufs_create+0x51/frame 0xfffffe0072edd650 VOP_CREATE_APV() at VOP_CREATE_APV+0x1c4/frame 0xfffffe0072edd6a0 VOP_CREATE() at VOP_CREATE+0x51/frame 0xfffffe0072edd700 vn_open_cred() at vn_open_cred+0x2b4/frame 0xfffffe0072edd820 vn_open() at vn_open+0x47/frame 0xfffffe0072edd860 kern_openat() at kern_openat+0x1f5/frame 0xfffffe0072edda20 kern_open() at kern_open+0x37/frame 0xfffffe0072edda50 sys_open() at sys_open+0x31/frame 0xfffffe0072edda70 syscallenter() at syscallenter+0x456/frame 0xfffffe0072eddab0 amd64_syscall() at amd64_syscall+0x57/frame 0xfffffe0072eddbb0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0072eddbb0 --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800b71a3a, rsp = 0x7fffffffe578, rbp = 0x7fffffffe5a0 --- From owner-freebsd-hackers@freebsd.org Tue Apr 18 18:16:35 2017 Return-Path: Delivered-To: freebsd-hackers@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 E6B99D4467E for ; Tue, 18 Apr 2017 18:16:35 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E61BF3A for ; Tue, 18 Apr 2017 18:16:35 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qk0-x230.google.com with SMTP id p68so931291qke.1 for ; Tue, 18 Apr 2017 11:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=IWcAaI88IFB982jKZQPnYseUl6C3APqsD+RWZ2D/CnU=; b=QeiU+qcuHbYr0WHN4vDiWbxGDiQUWTTc7yGiKfHYDphco190opWk1aSPUTVQfo7K8b FVl0ZIhO4SbjuIQPcAK7fW7Xdxm1X+jjm5P4W3BaZ5rYEyjEIecnx4bg89h/5oqRdUI7 qf+4DuAu75NFmOYLGMsuMjIpatCG5kqPD3wvUtWP0UrnwMpstPBkqhE67OYjHoWOu7wK 6NRM+WmePEJApek/CnMSXk/VqD+nPNM/ohN40h4IkWTxDOqiJemMizEIfklLy04Sn8Wl toldrRLbPtofHuomBAWYx7GEk/9P9H76SQlDrF+opp6bm2zGcTm7IiMvyK11WSDO12lw xZZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=IWcAaI88IFB982jKZQPnYseUl6C3APqsD+RWZ2D/CnU=; b=C6bbKbn8D1o611cw7W2/LpldaSVZpCrFAzJewxqqnHIzBqeL93daS56aENNvn+gNOf Ywc6G4f9qjuJmF+WNj4IzC3tQtswGdVoz3AKhxVg2GSr1rGWWG0xoygSAdbwSM/ntD0r Qsxk2vId6xJ5jpHs0jGUJDM/TPIAbv5giO48q+gfzXhqRb/dkEIQ3k+48TipgmJCwviX l/XwaiMGM/nO2XZW79MAY2KiUoeYigOImSQ4CPgdvepblCISrcCnR6SH6QSUyM0ehMxh LcDKZJkl+Z5kDTGdjHqTf55UGFYN0b3z5Dm9GgKwgmWkHT+xgAkH6VKANznCSKV3Z/bI VPeQ== X-Gm-Message-State: AN3rC/7oryxKNVwZEZ+EmFR8yHjrh+9XLLiPJCmz6MV0+DWDvDJSstmy AfC5ZaD9EgDA//GaR9J4KWrtkk2t5lqP X-Received: by 10.55.109.199 with SMTP id i190mt16159342qkc.91.1492539393879; Tue, 18 Apr 2017 11:16:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.172 with HTTP; Tue, 18 Apr 2017 11:16:03 -0700 (PDT) In-Reply-To: <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> From: Jia-Shiun Li Date: Wed, 19 Apr 2017 02:16:03 +0800 Message-ID: Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them Cc: freebsd-hackers@freebsd.org, freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:16:36 -0000 just noticed that rpi3 wiki page still has outdated issue info regarding this (the jemalloc error). Anyone to help update it? https://wiki.freebsd.org/arm64/rpi3 -Jia-Shiun On Mon, Apr 10, 2017 at 5:51 PM, Mark Millard wrote: > buildworld buildkernel completed non-stop for the first time > on a BPI-M3 board. > > Looks good for a check-in to svn to me (head and stable/11). > > This combined with 2017-Feb-15's -r313772's fix to the fork > trampline code's updating of sp_el0 makes arm64 far more stable > for my purposes. > > -r313772 was never MFC'd to stable/11. In my view it should be. > > From owner-freebsd-hackers@freebsd.org Wed Apr 19 17:35:40 2017 Return-Path: Delivered-To: freebsd-hackers@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 AB1FDD464CA for ; Wed, 19 Apr 2017 17:35:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-185.reflexion.net [208.70.211.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55D0C1945 for ; Wed, 19 Apr 2017 17:35:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12666 invoked from network); 19 Apr 2017 17:30:02 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Apr 2017 17:30:02 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 19 Apr 2017 13:28:58 -0400 (EDT) Received: (qmail 21793 invoked from network); 19 Apr 2017 17:28:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Apr 2017 17:28:58 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 65AAEEC7901; Wed, 19 Apr 2017 10:28:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: Date: Wed, 19 Apr 2017 10:28:56 -0700 Cc: freebsd-hackers@freebsd.org, freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <7D72C3EF-8F77-4701-93C9-1488072215FC@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> To: Jia-Shiun Li X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:35:40 -0000 On 2017-Apr-18, at 11:16 AM, Jia-Shiun Li wrote: > just noticed that rpi3 wiki page still has outdated issue info regarding > this (the jemalloc error). Anyone to help update it? > > https://wiki.freebsd.org/arm64/rpi3 stable/11 is still in process for the fork handling fixes. One of the 2 fixes to fork behavior has just been MFC'd: -r313772 from head is now -r317147 in stable/11 . So interrupts will no longer trash the sp_el0 register. There is still -r316679 from head to go so that Copy-On-Write would work for fork. (The defect may be more general than just being for fork.) > -Jia-Shiun > > On Mon, Apr 10, 2017 at 5:51 PM, Mark Millard wrote: > >> buildworld buildkernel completed non-stop for the first time >> on a BPI-M3 board. >> >> Looks good for a check-in to svn to me (head and stable/11). >> >> This combined with 2017-Feb-15's -r313772's fix to the fork >> trampline code's updating of sp_el0 makes arm64 far more stable >> for my purposes. >> >> -r313772 was never MFC'd to stable/11. In my view it should be. === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Thu Apr 20 07:13:06 2017 Return-Path: Delivered-To: freebsd-hackers@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 D804ED47AA3 for ; Thu, 20 Apr 2017 07:13:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-186.reflexion.net [208.70.211.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 874A7CC0 for ; Thu, 20 Apr 2017 07:13:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7796 invoked from network); 20 Apr 2017 07:16:09 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Apr 2017 07:16:09 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 20 Apr 2017 03:13:04 -0400 (EDT) Received: (qmail 6175 invoked from network); 20 Apr 2017 07:13:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Apr 2017 07:13:04 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 89504EC805D; Thu, 20 Apr 2017 00:13:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <7D72C3EF-8F77-4701-93C9-1488072215FC@dsl-only.net> Date: Thu, 20 Apr 2017 00:13:03 -0700 Cc: freebsd-hackers@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <89EA7C2B-0AE8-4E99-A1A6-4BDE9CD4D343@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> <7D72C3EF-8F77-4701-93C9-1488072215FC@dsl-only.net> To: Jia-Shiun Li X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 07:13:06 -0000 On 2017-Apr-19, at 10:28 AM, Mark Millard wrote: > On 2017-Apr-18, at 11:16 AM, Jia-Shiun Li wrote: >=20 >> just noticed that rpi3 wiki page still has outdated issue info = regarding >> this (the jemalloc error). Anyone to help update it? >>=20 >> https://wiki.freebsd.org/arm64/rpi3 >=20 > stable/11 is still in process for the fork handling fixes. >=20 > One of the 2 fixes to fork behavior has just been MFC'd: > -r313772 from head is now -r317147 in stable/11 . So > interrupts will no longer trash the sp_el0 register. >=20 > There is still -r316679 from head to go so that > Copy-On-Write would work for fork. (The defect > may be more general than just being for fork.) >=20 >> -Jia-Shiun >>=20 >> On Mon, Apr 10, 2017 at 5:51 PM, Mark Millard = wrote: >>=20 >>> buildworld buildkernel completed non-stop for the first time >>> on a BPI-M3 board. >>>=20 >>> Looks good for a check-in to svn to me (head and stable/11). >>>=20 >>> This combined with 2017-Feb-15's -r313772's fix to the fork >>> trampline code's updating of sp_el0 makes arm64 far more stable >>> for my purposes. >>>=20 >>> -r313772 was never MFC'd to stable/11. In my view it should be. Another head-vintage-specific rpi3 note on: https://wiki.freebsd.org/arm64/rpi3 is where it says: If you want to build your own ports or packages, you'll need to install = the aarch64-binutils package and link /usr/bin/ld to = /usr/local/bin/aarch64-freebsd-ld:=20 # pkg install aarch64-binutils # ln /usr/local/bin/aarch64-freebsd-ld /usr/bin/ld But using WITH_LLD_IS_LD=3D for an aarch64 buildworld now provides an aarch64 system ld that works for many things. This is now the default for aarch64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Thu Apr 20 16:40:52 2017 Return-Path: Delivered-To: freebsd-hackers@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 22E36D48860 for ; Thu, 20 Apr 2017 16:40:52 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB8A26A for ; Thu, 20 Apr 2017 16:40:51 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id v3KGZKvE092593 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 20 Apr 2017 09:35:21 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me From: Yuri Subject: How to get rid of the conflict between /usr/local/lib/gcc49/libgcc_s.so.1 and /lib/libgcc_s.so.1 To: Freebsd hackers list Message-ID: <2978fd74-4544-db57-f4f2-9300949e4764@rawbw.com> Date: Thu, 20 Apr 2017 09:35:19 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:40:52 -0000 Currently, FreeBSD can't run software that includes both fortran and clang-built parts that use exceptions. The immediate reason is that /usr/local/lib/gcc49/libgfortran.so.3 requires a newer version of libgcc, /usr/local/lib/gcc49/libgcc_s.so.1, but the older version /lib/libgcc_s.so.1 is used by the rest of the system. The immediate message is: ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc49/libgfortran.so.3 not found libgcc update us impossible due to the licensing change, libgcc is now GPL. One or only thing that is used in libgcc is the low level Unwind functionality. There are some alternative unwind implementations, for example https://github.com/pathscale/libunwind with the MIT license. Anybody has an idea how to solve this problem? One example of failure is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217459, but most science software is affected. Yuri From owner-freebsd-hackers@freebsd.org Thu Apr 20 16:53:08 2017 Return-Path: Delivered-To: freebsd-hackers@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 F40A9D4807E for ; Thu, 20 Apr 2017 16:53:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92D2313B5 for ; Thu, 20 Apr 2017 16:53:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ce902245-25e9-11e7-b96e-2378c10e3beb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id ce902245-25e9-11e7-b96e-2378c10e3beb; Thu, 20 Apr 2017 16:52:59 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v3KGqsqL001444; Thu, 20 Apr 2017 10:52:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1492707174.56859.1.camel@freebsd.org> Subject: Re: How to get rid of the conflict between /usr/local/lib/gcc49/libgcc_s.so.1 and /lib/libgcc_s.so.1 From: Ian Lepore To: Yuri , Freebsd hackers list Date: Thu, 20 Apr 2017 10:52:54 -0600 In-Reply-To: <2978fd74-4544-db57-f4f2-9300949e4764@rawbw.com> References: <2978fd74-4544-db57-f4f2-9300949e4764@rawbw.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:53:08 -0000 On Thu, 2017-04-20 at 09:35 -0700, Yuri wrote: > Currently, FreeBSD can't run software that includes both fortran and  > clang-built parts that use exceptions. > > The immediate reason is that /usr/local/lib/gcc49/libgfortran.so.3  > requires a newer version of libgcc, > /usr/local/lib/gcc49/libgcc_s.so.1,  > but the older version /lib/libgcc_s.so.1 is used by the rest of the > system. > > The immediate message is: ImportError: /lib/libgcc_s.so.1: version  > GCC_4.6.0 required by /usr/local/lib/gcc49/libgfortran.so.3 not found > > libgcc update us impossible due to the licensing change, libgcc is > now GPL. > > > One or only thing that is used in libgcc is the low level Unwind  > functionality. There are some alternative unwind implementations, > for  > example https://github.com/pathscale/libunwind with the MIT license. > > Anybody has an idea how to solve this problem? > > > One example of failure is  > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217459, but most  > science software is affected. > > A PR about this with lots more info and some potential fixes (or at least workarounds) is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 -- Ian From owner-freebsd-hackers@freebsd.org Thu Apr 20 16:58:47 2017 Return-Path: Delivered-To: freebsd-hackers@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 E0BC3D483EF for ; Thu, 20 Apr 2017 16:58:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ACEC81A36 for ; Thu, 20 Apr 2017 16:58:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3KGwfX9044362 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Apr 2017 09:58:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3KGwfjO044361; Thu, 20 Apr 2017 09:58:41 -0700 (PDT) (envelope-from sgk) Date: Thu, 20 Apr 2017 09:58:41 -0700 From: Steve Kargl To: Yuri Cc: Freebsd hackers list Subject: Re: How to get rid of the conflict between /usr/local/lib/gcc49/libgcc_s.so.1 and /lib/libgcc_s.so.1 Message-ID: <20170420165841.GA81717@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <2978fd74-4544-db57-f4f2-9300949e4764@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2978fd74-4544-db57-f4f2-9300949e4764@rawbw.com> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:58:48 -0000 On Thu, Apr 20, 2017 at 09:35:19AM -0700, Yuri wrote: > > Anybody has an idea how to solve this problem? > Try adding -static to your Fortran command line. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Fri Apr 21 03:07:12 2017 Return-Path: Delivered-To: freebsd-hackers@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 E1A4FD48C97 for ; Fri, 21 Apr 2017 03:07:12 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id CA1141818; Fri, 21 Apr 2017 03:07:12 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id v3L37BVk001409 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 20 Apr 2017 20:07:11 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me Subject: Re: How to get rid of the conflict between /usr/local/lib/gcc49/libgcc_s.so.1 and /lib/libgcc_s.so.1 To: Ian Lepore , Freebsd hackers list References: <2978fd74-4544-db57-f4f2-9300949e4764@rawbw.com> <1492707174.56859.1.camel@freebsd.org> From: Yuri Message-ID: <3d94b807-8ff4-42f9-59c0-bb3ee6026745@rawbw.com> Date: Thu, 20 Apr 2017 20:07:10 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1492707174.56859.1.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 03:07:13 -0000 On 04/20/2017 09:52, Ian Lepore wrote: > A PR about this with lots more info and some potential fixes (or at > least workarounds) is: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 208120 has some additional information, but for some reason it focuses on cmake when the problem is caused by the presence of multiple versions of libgcc. Users of fortran may or may not use cmake, therefore this problem is orthogonal to cmake. Yuri