From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29826 invoked by alias); 11 May 2017 00:37:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 29813 invoked by uid 89); 11 May 2017 00:37:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50,KAM_LOTSOFHASH,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=goc, courtesy, investigations, H*Ad:D*googlegroups.com X-HELO: NAM01-BN3-obe.outbound.protection.outlook.com Received: from mail-bn3nam01on0041.outbound.protection.outlook.com (HELO NAM01-BN3-obe.outbound.protection.outlook.com) (104.47.33.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 May 2017 00:37:47 +0000 Authentication-Results: gcc.gnu.org; dkim=none (message not signed) header.d=none;gcc.gnu.org; dmarc=none action=none header.from=cavium.com; Received: from mail-yw0-f170.google.com (209.85.161.170) by CY4PR07MB3414.namprd07.prod.outlook.com (10.165.88.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 11 May 2017 00:37:46 +0000 Received: by mail-yw0-f170.google.com with SMTP id l135so5737883ywb.2 for ; Wed, 10 May 2017 17:37:46 -0700 (PDT) X-Gm-Message-State: AODbwcCUbZu8BlANxzTpXEY3F5Jy7YRvokbK8yejTLCymEmDxgdhr8mw Sk1wn35ur7MpP30/V4SPVZSlnWs7ZA== X-Received: by 10.129.183.4 with SMTP id v4mr7624925ywh.194.1494463062564; Wed, 10 May 2017 17:37:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.140 with HTTP; Wed, 10 May 2017 17:37:42 -0700 (PDT) In-Reply-To: References: From: Andrew Pinski Date: Thu, 11 May 2017 00:42:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Go patches committed: merge recent changes to gofrontend To: Ian Lance Taylor Cc: gcc-patches , "gofrontend-dev@googlegroups.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: DM5PR06CA0025.namprd06.prod.outlook.com (10.168.181.11) To CY4PR07MB3414.namprd07.prod.outlook.com (10.165.88.15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: da869964-6389-4088-03d8-08d49805f1ed X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:CY4PR07MB3414; X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB3414;3:xnoQDezYZrvJK00wrjfBg8vbwW4TJr468kC0ugpJpPIVSJuPq5M2ElK79gchFPeZNVDlf9o9IPE33vDJ1A5fjDuEAFogbjEkmp/VR1f6JhAEb3hNgx5kwuuMp68gc2xhODpwt5mf0hTEW1Gcg32l+U8YKWsqhwamjVn57m0nUD07aJ5cvyZ/G6cl/GKTnDMhiGE4i2HkUlfZ7Jw5q9isYCfX61zb7r/y5ahPtGvNfwSkq6WLFgfBIlxBLqDmqbPI6jA1qo3mD50VlQfaQkbtc93MOvVlsp/raf4PhtjGVw2eZAeA8uIaRLEc+MNSuyt91zqXbCVGj/Zicy2FIa6DYw==;25:AZqrWWautqfSw93IQf0G8vbvnNYqzZRLc7gifeuy9F5ZQ8NAmD0BY79+Ivsup9I8EjnsqoB4aV1Mv+WsgeXQJFRyHwo+2nr3fqLuKcct9uRiIMaK8WPIDOjlVBXpSyrdOFjDj9F6AlMfviERCkQgsrS5crb1KYXaGTqwLGha8UJWt5y3Sa0GRtLMvGE2g9DTmVm5SXsCwnY91uPtUZTPzpdqjjpnD5ewSc/6DQSksrHQHwskU+4GvBhTSxdlCVnkEIUtGlpNgZB6l2hpO90CQR+DM+v2NCQ3e6H3f/VGMGhRvDNt41UIOY072wXm1azJxZ9lttIcayx/7eyxh+SA5EYcsC7Bz7yJNz2H3W+ViGXfvt5Up9cPpB9BQ7bdMsaH3vP0+Z7cqdjcHp6RddxUQkWPyZAhcDHwFvagy6S6/BtQ/L7o8mcygZi22dmeP5rgG7lKGkGjwhnEUcT1wzzlyg== X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB3414;31:6/XHzX1WB6YUql1zESDZpo8Inwm3kdZ69Uc7/mD98PhcTDq5yA3mdPldTd2LKi7I2G0bXEsd/Uk1L7SmI7AxTFNIg24FexB3QiI11mdLvbM71tkptajjfIFYeMB3oLGlv8+6TZshMTc1dd3M4KeQ2OYxnmYnaiREbSADQRabXR41I9M72CgSEy8UxYZV2oym4jy/ArRI4np2FLzW18jJn37mDfEqoD92CWCEg4YC7xuRgsFIk8//HxTyfgbRs5mc8D0UTnsZt68Vi72t8rnE8Q==;20:DHOKuEbdWW302jUhrNht2GAUIci4YeR8J2yS2/yoYDP3Q4PzbTQqhAz4QXymrR/xcW52k1USiX4JFUsl+nl/XwZ7N3Cup+IGRz4OnfBhZwJl3vwVBz81tGLxME57MKaRxS0xF+/M+zyGep6JhqsoDtTJyM0LZL0tPUawe0D4tvWdbt3oBqh15Bsf6rLxpDVTjbM8wf4OLP/rDVYVsPCAH60E7XxD9hOgeu7w0d2HMNmEPbi8K+dsXHnUufhoppCCWfrlsboHYG7bdv9OPjwwkBCjhkVUnm6b6wVAYn2fKyzPuT3N2ynATpbZckuPGan2dHcp97OEQbBreEqy2uuyyWLN028hYYNRIligoSUNI966YHGcBQoQ9c60ssw79gOrf9beZhb9kPVbyhhucsSFGkiEE8JBhDol9Qi4luypqH1Kh9rmfwReINF0zkyY+CGIVoUbOvdIqf0EAHHNP/4o//Wx4lrZPwQKCx+2WTwQn8uROIOXRKSScpV9UonfJn9k X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(250305191791016)(158342451672863)(278428928389397)(164563717011359)(22074186197030)(166708455590820)(131327999870524)(211936372134217); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(6072148);SRVR:CY4PR07MB3414;BCL:0;PCL:0;RULEID:;SRVR:CY4PR07MB3414; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA3TUIzNDE0OzQ6WkJSN2gxaVpMQmtvVXlMRzVSNTA2ZE5NSzM1?= =?utf-8?B?c0Fla1hFV2VKQjRBRkl3SWtWazA5enZoUUk3MlkxT0FlRDVLVG1EdWZlekpu?= =?utf-8?B?dmZqemt3aVV4NWRnSmJyc3B5djZsWnFlSkRMZ04vYXUyTmRrVmU5VkdEbElW?= =?utf-8?B?U1JGQk8xcTB6b24yS2creWFqMVdEdm9IOWNNdHFQU3Q3Yml4VTNWK3BwNVdh?= =?utf-8?B?MHJVWDJzcjVxQStQV20xWXBHZlI1RUhHYkRzZ1VRY2ZEc0s2TldpM0g4Y3pr?= =?utf-8?B?dllFU0txQWZGV3l2RmF2Q1NqWENncWRXUG1uZ2lWOU4wNmVlMmtnNkUxb1No?= =?utf-8?B?VU5kRXRpUGZmQnBmMGMyZEtRVTRJTmx5d0tpWmx0bTdEVm1oTkx4RnFNRWhV?= =?utf-8?B?RmM5S2IvQjVEMEhQUWtXMjdSM0dXRTlBSUUrTElSSEZPaks1MFFPU3dzeTh5?= =?utf-8?B?VnBwS2lMOFFFaWQxVnhKemhNWS9QOHovUWNrWkNTTkFNQXJjbEFaR1plSWlF?= =?utf-8?B?bkFIdUdqVENEQzFYdDJKL0ZCRi91S2EwTXhlYkw5aCsxZzdGUDc1OTRJR0Rp?= =?utf-8?B?aENUZWtqa0tySzNDY1BzUlpUT1JaMEluNnJqRVNmUlZ0YzlEM1BhbTNLNEVv?= =?utf-8?B?MExOeSs2ZkYxTUV6cXRVOVVWTUFJcTl3UUovT3JTOUxvbEhMTUpRQTcxM3l3?= =?utf-8?B?dDZNdUcxQm1zWEFMTkM1RVlXakdPVCtoT1pHQWpOL1U3SWpnZE5OWlo1V0ky?= =?utf-8?B?NGgvVlZ4KysvL3JRNlgyWTB6dGdYRzVQRklVODJWQzhiUnNWS0JZQ1VHVzYy?= =?utf-8?B?SlYrUlBCTE0zNGVTYkJxMHFoRTllWUQ4YU5JeTRvRlhTdm9hS0xKNXF0akwz?= =?utf-8?B?ZndZZklSTUNKUlhUVlVUWXZGWCt5WFNBRk4wR1FpMXdZdE9NbC9GTWVXbXlh?= =?utf-8?B?N0x1VVovYUFQYkdla0Zsdm9mYWV2RkFnTXhJeG1pcnlZOWs3RkpneEQ1WDNZ?= =?utf-8?B?aER4YlVxdGFiOUg1eXRkNVRtb2RJbWJQUkJWaHBINmJiaUFWNVhBNDkwemk3?= =?utf-8?B?K2pTaDFzb09keitXU1NOMzBNM2dEMkNTVVdadGdLODRlUUlDTGZNbmNjZU1i?= =?utf-8?B?dTJpVlZISmp2MzMzZEJPT2NvTk9weGtPNU9LZGlQQVp1T0F3eDNBN045TEd3?= =?utf-8?B?OGR1NlFBVDdoVkVhVmRabWRsR0xwektQd25QUHIrZ3VYS0RhNE1DY0JiS2Vu?= =?utf-8?B?MEFhVlFFcEVXR1JCOElrT3Y5UzFvTmkxWDVHWWdRRUozcnhMemFTc2xPemxp?= =?utf-8?B?OUZPQUxuV0E0YTVTVml3ektyUjJ2aUhnc0RJQTF6OU1ObytXcVY5ekhUUVIy?= =?utf-8?Q?1pvCQuM?= X-Forefront-PRVS: 0304E36CA3 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(377424004)(24454002)(377454003)(59536001)(66066001)(61266001)(47776003)(23676002)(61726006)(42186005)(98316002)(53946003)(4326008)(6306002)(9686003)(54906002)(53936002)(498394004)(72206003)(6246003)(50986999)(8676002)(8746002)(38730400002)(81166006)(9896002)(63696999)(76176999)(54356999)(93516999)(53546009)(110136004)(6116002)(3846002)(508600001)(5890100001)(2950100002)(305945005)(575784001)(107886003)(50466002)(2906002)(229853002)(189998001)(122856001)(55446002)(5660300001)(7736002)(6862004)(55456009)(559001)(579004);DIR:OUT;SFP:1101;SCL:1;SRVR:CY4PR07MB3414;H:mail-yw0-f170.google.com;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA3TUIzNDE0OzIzOktURWtYWUE5TXdGRXVwN3FnSFdlRjBQR3hu?= =?utf-8?B?WXJEek5WS0Vva0lCLzc0SHhDVTlFYlQzQ2thSjhyTU5BNWhQbG5WRCtFR3BO?= =?utf-8?B?NjJ6ZFlBdkx0T2xKOVNrZmU2MHVBckczQmZGaW5wTHFPYlBHdGMzclBpSkxR?= =?utf-8?B?WlVNODNHWkRoaURrekc1cWVqRkNtQy9pa0V4OWs3d3F1NjB5RThmQWthdmp1?= =?utf-8?B?NDFSMzNGSEZVbGJKUjlHaWJKYUtnSVJaV1hJTGlSTzhyV3hlQ3h0U09kRCtt?= =?utf-8?B?dWM3bDU2RkE3ekhXcWhSY0Fqak9aV2pvVEJxZ21IVHVYVVdraW53VzBWWUY4?= =?utf-8?B?NGtiaGoySGRaaXNzSlA0akI1WmhXMGNEQjhFbllxbzBSMUx3QnZTZ0VRcE03?= =?utf-8?B?OU40aktaa0tRbWFrb3dyRDVYNmpQRlJKOENGZnExSlQ5T3Z3Yk5VTTFtSXhV?= =?utf-8?B?dy9heHNxeHUxNkZvQ3dTN3dPcEJEbFJ0YmdwK24wOHhLaGdRRDJ2REpreG95?= =?utf-8?B?R2l0Mm1iSkRDNlVNSVQyVHpUQTM2SmhuWjA4cGdrNTlFanJpYUhFNVlaVWYy?= =?utf-8?B?Q3QxdVRUTVMzZnFYQzUxNjNUaVFzdUs1Sjh5ak8vTEx1NmUwSEFqMkhWdDBV?= =?utf-8?B?eExscHdHNHFWeVprd3RtUnRKcytJdlZrREFQNlUxT1g2cUovYm95SXM2cFVk?= =?utf-8?B?eDdKWWdqSkxPUEhIRzJ2RWNabUVDcUUrRjJaVEVGbGdhc3ZMdDd2ZXdTQldS?= =?utf-8?B?YUNISU5jdlJzOEZ2a09ndUNvcFpEeFB5R2Nud1ZyT25mYzN2NFpEeG1BTk1G?= =?utf-8?B?ZHdLN0FKTVVXMStjRXdpdFE5MkRSemF2UGNzWGNMSy91T0s3aGdMWTh3eGM5?= =?utf-8?B?bC9PY0VjRU53V2FGbHljS1piT2J5NGREVG1DUFJ2clZPVnFUMXlLRVBSc3l0?= =?utf-8?B?bEc4bzlOZDhhaXdQOVN3ekxSVnZjejg5SFVmK0NBNDZrT2tTSVlYSHNFUjZw?= =?utf-8?B?TGVlNllaV1FzMi8zNUpqaTFibXM3UnBTTUJoS1hRM0xZbGJTV1FuSy9Fb0xC?= =?utf-8?B?b1AxNVhWV3RaK0V5RGw1bWtiL2FJUjNUUHBGYmcvdkZIcTVQT0VHMVU0QmhB?= =?utf-8?B?ODhlbmhvMDNHbzE4SVBUZDNacHJyV0NPMUdjZ1dZVnZ6SWhOcGVhQ0g4S2lo?= =?utf-8?B?RVhZeFJBTFJFeDI3UDRiN0hLdVl1cmorTSt6dXZjelNPMExBeVprWjdvWkdR?= =?utf-8?B?Y0ZZekxFZ0FWbk5McEduUmJIU3Q1QVBKR2Z5K01vdHRVaS9HOU92elN3Y2Rj?= =?utf-8?B?U1E5a2ZlMXdkdXNZMWw5R3pJS1UxNzhZRjlDeXR2eXhQRVZUbzlLWXl0MURD?= =?utf-8?B?U0ZQZzdZSk5BL1dnWHZZRnY3SFYyaDQwOHNJTmFlWGVEanVFOS80TjRUalFY?= =?utf-8?B?dllVUGFwTWFRaVIybUc0dU9ScjhYMkMwbWt0WWhpdTdpL3FEazN1S0swM0Nu?= =?utf-8?B?Qkdid09zczVMZHNhNHZiNFJMOWpFc3FrbXJDT1JmbFVsQ2oxSXFnNy9xME1S?= =?utf-8?B?TzVwb2ZmWVg5Sk51bTlBcW1uWVpVUzF2RDZsRnE0eC9EK0tSSTZYWUduUFlN?= =?utf-8?B?cTBpc25QUDZTMWtkYk1zTFZ5akFuMDdXR2FqdDViRGJod1cwMGp0VWFCRjY4?= =?utf-8?B?bi90LzJIUWplUUp3SEtYMkdTeWFUOGc1Mm53MnhPSzE1Q2NOOUVTcVcvMzh6?= =?utf-8?B?NDA0a2JpZmg3R3FXZFNINkdrWGZiK3gxSVV3MkRpS3pCWUVTOG9xbmJnem1P?= =?utf-8?B?MWkxUkI2a2t2SnVzeHkwZ0RscWkvK2NacXFlTy9qM0ZpYWNoZUJMOXlmay9W?= =?utf-8?B?cFhKeFRObml0NFZKajFWS2NSNTF4d0pvSVhmK1d1UnZvSGF3cTQ4TVhlbkI0?= =?utf-8?B?SnJFc1dhY2JBPT0=?= X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB3414;6:A06xysHTGoA0xFtsrxRshiZ9WuUVkOnjQKieX/Cz7/GZN2gYJ/kFxyTR7c30JN+plvXQIzmmHOmcOjj1k296haIFvl0iCS1yPUjnqZK4hPtgbzvWmkhx1fTIpoHywhYeP+C+Cf+YGD/hKZyUbSciJyNiAkuOchjGm1wz/MWyu2tS9ZtF5Ood+iFq3gXjVDY4S/kuDinFEbEnqUaLx6NcBrwDOVSi1r3Znaxkjiv0w7OggNsPayUN+G5+uHzoVKvzIstArs0SQXwd8aoURi60Wt0ED20c8ugmMICAlekyg0mgCJtu6+cxDcDJlccFaOD9JqU7DaCVRaHD3VEqirW1je1hUBpdTju+zmhz3aUuMmGJQYfKfrw4L0Bso3OrqurGeL+I9WXjk1zv5NgW6+sr114gjMU6ERoNJmCddKk32xBTJGFG4YSjQZaIpzky3JQHIVWQ1MVO8NC2zTw68VI9UW4Mto7DMPD8qDUGUqoxMUekNHzEvHaZ9egCY9M1tGTyoLaD9aF6qvU5/nA9pwF4hg==;5:3ppRFMkeEhNgcHQXSbF0wH+tHuO/1rQWDJIzQX3MYYWwO9lH8yUowE/O9d43uoTRVdvoX4NxOVeUyqByR0kAuouPZZcWVzl1fBXpUeS2FSY/1ec1i/w+DR/BEugXuDzw/1mfK3iZv8Mgv5ixNlxSlA==;24:rtmbZhv7aFCdeOvCRCG8R5tr2/eo5OtbrzqOfsY4qwzq6O8uIhzC8BAuP7Pu6EoInd85/FP5yYSd3BT4iDHPIQKEK+KIn70g4YlOUkif4fE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB3414;7:TlpCkco47vXtihkKU/1h2Qivouo+ZCykr5SPWh8+Ti0fcY6TMEhsNa+6SGerYi1teBtfMh4GQXgE4WJmRYd+dWTxeptLtH3CGrYlnCmOIOlz3JAoXnUkUKv0TREqM+HZjYwjBqcYMgM5j2tpAjsdvjkV86EJSuSSw5/ZVY6cdgbpWrdDlLMNEMVDdKbGWmRpORphD3nipvXuz0UMSOCUx+OvuiK1HeUtvhEDV397lYRmCvc4DrxejKvCHujXa1h0GMQij6h1He+THyYodzW/mOAHQ1aK8mPY5Dd2UlqJJizQIvi20aF5NzA+BtrFzngOh7yq7i0Q4Vk6sGgS74PpKA== X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 00:37:46.7183 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR07MB3414 X-SW-Source: 2017-05/txt/msg00838.txt.bz2 On Wed, May 10, 2017 at 10:26 AM, Ian Lance Taylor wrote: > I have committed a large patch to update the Go frontend and libgo to > the recent changes in the gofrontend repository. I had postponed > merging changes during the GCC 7 release process. I am now merging > all the changes that were pending during that period. Although this > is a merged patch, the changes can be seen individually in the > gofrontend repo (https://go.googlesource.com/gofrontend). They are > also listed below. > > This is a fairly significant patch that brings in the concurrent > garbage collector used in the Go 1.8 runtime. This significantly > reduces pauses due to garbage collection while running a Go program. > > This patch also brings in experimental support for AIX for gccgo, > contributed by Matthieu Sarter and others at Atos Infog=C3=A9rance. > > The actual patch is too large for this e-mail patch, but I have > attached all the changes to the gcc/go directory. > > Ian This causes a build failure on aarch64-linux-gnu: ../../../gcc/libgo/runtime/proc.c: In function =E2=80=98runtime_malg=E2=80= =99: ../../../gcc/libgo/runtime/proc.c:729:43: warning: implicit declaration of function =E2=80=98mstats=E2=80=99; did you mean =E2=80=98mst= art1=E2=80=99? [-Wimplicit-function-declaration] void *p =3D runtime_sysAlloc(stacksize, &mstats()->other_sys); ^~~~~~ mstart1 ../../../gcc/libgo/runtime/proc.c:729:51: error: invalid type argument of =E2=80=98->=E2=80=99 (have =E2=80=98int=E2=80=99) void *p =3D runtime_sysAlloc(stacksize, &mstats()->other_sys); ^~ Thanks, Andrew > > > 2017-05-10 Than McIntosh > > * go-backend.c: Include "go-c.h". > * go-gcc.cc (Gcc_backend::write_export_data): New method. > > 2017-05-10 Ian Lance Taylor > > * go-gcc.cc (Gcc_backend::Gcc_backend): Declare > __builtin_prefetch. > * Make-lang.in (GO_OBJS): Add go/wb.o. > > commit 884c9f2cafb3fc1decaca70f1817ae269e4c6889 > Author: Than McIntosh > Date: Mon Jan 23 15:07:07 2017 -0500 > > compiler: insert additional conversion for type desc ptr expr > > Change the method Type::type_descriptor_pointer to apply an additional > type conversion to its result Bexpression, to avoid type clashes in > the back end. The backend expression for a given type descriptor var > is given a type of "_type", however the virtual calls that create the > variable use types derived from _type, hence the need to force a > conversion. > > Reviewed-on: https://go-review.googlesource.com/35506 > > > commit 5f0647c71e3b29eddcd0eecc44e7ba44ae7fc8dd > Author: Than McIntosh > Date: Mon Jan 23 15:22:26 2017 -0500 > > compiler: insure tree integrity in Call_expression::set_result > > Depending on the back end, it can be problematic to reuse Bexpressions > (passing the same Bexpression to more than one Backend call to create > additional Bexpressions or Bstatements). The Call_expression::set_res= ult > method was reusing its Bexpression input in more than one tree > context; the fix is to pass in an Expression instead and generate > multiple Bexpression references to it within the method. > > Reviewed-on: https://go-review.googlesource.com/35505 > > > commit 7a8e49870885af898c3c790275e513d1764a2828 > Author: Ian Lance Taylor > Date: Tue Jan 24 21:19:06 2017 -0800 > > runtime: copy more of the scheduler from the Go 1.8 runtime > > Copies mstart, newm, m0, g0, and friends. > > Reviewed-on: https://go-review.googlesource.com/35645 > > > commit 3546e2f002d0277d805ec59c5403bc1d4eda4ed9 > Author: Ian Lance Taylor > Date: Thu Jan 26 19:47:37 2017 -0800 > > runtime: remove a few C functions that are no longer used > > Reviewed-on: https://go-review.googlesource.com/35849 > > > commit a71b835254f6d3164a0e6beaf54f2b175d1a6a92 > Author: Ian Lance Taylor > Date: Thu Jan 26 16:51:16 2017 -0800 > > runtime: copy over more of the Go 1.8 scheduler > > In particular __go_go (aka newproc) and goexit[01]. > > Reviewed-on: https://go-review.googlesource.com/35847 > > > commit c3ffff725adbe54d8283c373b6aa7dc95d6fc27f > Author: Ian Lance Taylor > Date: Fri Jan 27 16:58:20 2017 -0800 > > runtime: copy syscall handling from Go 1.8 runtime > > Entering a syscall still has to start in C, to save the registers. > Fix entersyscallblock to save them more reliably. > > This copies over the tracing code for syscalls, which we previously > weren't doing, and lets us turn on runtime/trace/check. > > Reviewed-on: https://go-review.googlesource.com/35912 > > > commit d5b921de4a28b04000fc4c8dac7f529a4a624dfc > Author: Ian Lance Taylor > Date: Fri Jan 27 18:34:11 2017 -0800 > > runtime: copy SIGPROF handling from Go 1.8 runtime > > Also copy over Breakpoint. > > Fix Func.Name and Func.Entry to not crash on a nil Func. > > Reviewed-on: https://go-review.googlesource.com/35913 > > > commit cc60235e55aef14b15c3d2114030245beb3adfef > Author: Than McIntosh > Date: Mon Feb 6 11:12:12 2017 -0500 > > compiler: convert go_write_export_data to Backend method. > > Convert the helper function 'go_write_export_data' into a Backend > class method, to allow for an implementation of this function that > needs to access backend state. > > Reviewed-on: https://go-review.googlesource.com/36357 > > > commit e387439bfd24d5e142874b8e68e7039f74c744d7 > Author: Than McIntosh > Date: Wed Feb 8 11:13:46 2017 -0500 > > compiler: insert backend conversion in temporary statement init > > Insert an additional type conversion in Temporary_statement::do_get_b= ackend > when assigning a Bexpression initializer to the temporary variable, to > avoid potential clashes in the back end. This can come up when assign= ing > something of concrete pointer-to-function type to a variable of gener= ic > pointer-to-function type. > > Reviewed-on: https://go-review.googlesource.com/36591 > > > commit c5acf0ce09e61ff623847a35a99da465b8571609 > Author: Matthieu Sarter > Date: Wed Mar 1 17:57:53 2017 +0100 > > libgo: build tags for aix > > Build tags for the libgo source files required to build > libgo on AIX. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37633 > > > commit 67ed19616898ea18a101ec9325b82d028cd395d9 > Author: Matthieu Sarter > Date: Thu Mar 2 15:41:31 2017 +0100 > > libgo: handle AIX tag in match.sh and gotest > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37638 > > > commit 83ea2d694c10b2dd83fc8620c43da13d20db754e > Author: Matthieu Sarter > Date: Wed Mar 1 17:48:16 2017 +0100 > > libgo: add AIX support in configure and Makefile > > - support for GOOS=3Daix > - CFLAGS/GOCFLAGS/LDFLAGS for AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37632 > > > commit 35d577fe22ffa16a3ccaadf5dae9f6f425c8ec8c > Author: Matthieu Sarter > Date: Mon Mar 6 15:00:15 2017 +0100 > > runtime: adapt memory management to AIX mmap > > On AIX: > * mmap does not allow to map an already mapped range, > * mmap range start at 0x30000000 for 32 bits processes, > * mmap range start at 0x70000000_00000000 for 64 bits processes > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37845 > > > commit 4e49e56a5fd4072b4ca7fcefe4158d6885d9ee62 > Author: Matthieu Sarter > Date: Mon Mar 6 13:42:26 2017 +0100 > > runtime: add getproccount implementation for AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37844 > > > commit ff626470294237ac664127894826614edc46a3d0 > Author: Matthieu Sarter > Date: Mon Mar 6 17:31:21 2017 +0100 > > runtime: handle ERESTART errno with AIX's wait4 > > On AIX, wait4 may return with errno set to ERESTART, which causes > unexepected > behavior (for instance, go build may exit with the message "wait: res= tart > system call" after running a command, even if it was successfull). > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37846 > > > commit 37daabbfc83d533b826ef9ab10e2dee7406e7198 > Author: Matthieu Sarter > Date: Mon Mar 6 11:02:58 2017 +0100 > > runtime: support for AIX's procfs tree > > On AIX, the process executable file is available under > /proc//object/a.out > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37842 > > > commit a0275c039d56acf4bf48151978c1a4ec5758cc2c > Author: Ian Lance Taylor > Date: Wed Mar 8 07:00:05 2017 -0800 > > libgo/Makefile.am: don't use nonportable \n or \t in sed expression > > The resulting zstdpktlist.go is less pretty, but it works. > > Reviewed-on: https://go-review.googlesource.com/37940 > > > commit 29b190f76105aafa2b50b48249afdafecc97a4be > Author: Matthieu Sarter > Date: Thu Mar 9 16:02:34 2017 +0100 > > runtime: netpoll and semaphores for AIX > > semaphore implementation based on Solaris implementation in > libgo/go/runtime/os_solaris.go > > netpoll is just a stub to avoid build failure on AIX. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37966 > > > commit 55ca6d3f3cddf0ff9ccb074b2694da9fc54de7ec > Author: Matthieu Sarter > Date: Thu Mar 9 15:38:30 2017 +0100 > > libmain: ensure initfn is called when loading a go library > > AIX does not support .init_array. > The alterative is to export the __go_init function and tell the linker > it is an init function with the -Wl,-binitfini:__go_init option. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37965 > > > commit 349a30d17d880ac8bc1a35e1a2ffee6d6e870ae9 > Author: Matthieu Sarter > Date: Fri Mar 10 11:15:08 2017 +0100 > > libgo: use an import list for missing symbols > > libgo depends on symbols provided by Go programs at runtime. On AIX, > this requires either to build libgo with -Wl,-berok linker option and > the programs with -Wl,-brtl, or to provide a list of imported symbols > when building libgo. The second options seems preferable, to avoid > requiring an additional option for every Go program. > > There are also some symbols that are specific to GNU ld and do not > exist when linking with AIX ld (__data_start, __edata, __etext and > __bss_start). > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37969 > > > commit 91db0ea1ff068ca1d97b9c99612100ea5b96ddb2 > Author: Matthieu Sarter > Date: Wed Mar 8 15:34:45 2017 +0100 > > crypto/x509: add certificate files locations for AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/37952 > > > commit 92e521c854e91709b949548c47e267377850f26a > Author: Ian Lance Taylor > Date: Fri Mar 10 14:10:11 2017 -0800 > > compiler: fix check for pointer in Temporary_reference_expression > > The check for an unrepresentable pointer in > Temporary_reference_expression::do_get_backend was incorrectly > translated from C to Go in https://golang.org/cl/14346043. Fix the > check to use points_to rather than has_pointer and deref. This should > not make any difference in practice as either way the condition will > only be true for a pointer to void, but points_to is correct and more > efficient. > > Reviewed-on: https://go-review.googlesource.com/38009 > > > commit 9a0b676e59e7171a630c48fdc3d4de6712bad0ca > Author: Matthieu Sarter > Date: Thu Mar 16 16:51:53 2017 +0100 > > libgo: add missing _arpcom struct to *sysinfo.go > > This struct is filtered due to having a field of type _in6_addr, > but other types exported to *sysinfo.go are depending on it. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38251 > > > commit 61262a757bdd3d9a595ab6a90f68c0c4ebed7bc1 > Author: Matthieu Sarter > Date: Thu Mar 16 18:27:46 2017 +0100 > > syscall: raw_ptrace stub for AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38253 > > > commit 8029632b50880fd9b5e39299c738b38e3386595f > Author: Matthieu Sarter > Date: Wed Mar 15 16:58:37 2017 +0100 > > libgo: adapt runtime.inc to AIX > > * Two AIX types are wrongfully exported to runtime.inc as their names > make them look like a Go type. > * The sigset go type conflicts with a system sigset type. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38192 > > > commit 25f3a90d14bc268479369ecc0eada72791612f86 > Author: Matthieu Sarter > Date: Wed Mar 15 16:58:37 2017 +0100 > > libgo: update Makefile.in, accidentally omitted from last change > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38310 > > > commit d52b4895616b66f93b460366527e74336829aaa5 > Author: Matthieu Sarter > Date: Thu Mar 16 18:39:26 2017 +0100 > > syscall: TIOCSCTTY does not exist on AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38254 > > > commit ff1ec3847a4472008e5d53a98b6694b1e54ca322 > Author: Matthieu Sarter > Date: Thu Mar 16 18:07:34 2017 +0100 > > syscall: syscall does not exist on AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38252 > > > commit c1ee60dabf0b243a0b0286215481a5d326c34596 > Author: Matthieu Sarter > Date: Fri Mar 17 17:18:18 2017 +0100 > > net: EAI_OVERFLOW does not exist on AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38266 > > > commit ad4ad29aed9f70b14b39b488bfeb9ee745382ec4 > Author: Matthieu Sarter > Date: Fri Mar 17 17:23:56 2017 +0100 > > net: sockopt/sockoptip stubs for AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38267 > > > commit 5d7db2d7542fe7082f426d42f8c2ce14aad6df55 > Author: Matthieu Sarter > Date: Fri Mar 17 16:35:05 2017 +0100 > > os/user: add listgroups stub for AIX > > This is required to build os/user. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38263 > > > commit 4e57a7973e9fa4cb5ab977c6d792e62a8f7c5795 > Author: Matthieu Sarter > Date: Wed Mar 22 11:11:30 2017 +0100 > > os: fix readdirnames for AIX > > Largefile implementation should be used on AIX. > > readdir64_r function returns 9 and sets result to NULL when > reaching end of directory, so this return code should not > always be considered as an error. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38359 > > > commit b34036967d1ec57b25e3debe077439b4210a1d4a > Author: Matthieu Sarter > Date: Fri Mar 17 17:39:31 2017 +0100 > > libgo: adapt sigtab.go to AIX > > On AIX, _NSIG is not directly defined to its integer value in > gen-sysinfo.go. > The real value is _SIGMAX32+1 or _SIGMAX64+1, depending if we are > building a 32bit ligbo or a 64bit libgo, so we need to read one of > those constants to set nsig value in mksigtab.sh > > This change also ensures that all signal numbers from 0 to nsig-1 > are referenced in sigtable. > > Reviewed-on: https://go-review.googlesource.com/38268 > > > commit 20991c32671a183ec859b4f285df37fdd4634247 > Author: Matthieu Sarter > Date: Thu Mar 23 17:28:09 2017 +0100 > > syscall: missing import in socket_bsd.go > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38369 > > > commit c34754bd9adf5496c4c26257eaa50793553c11e8 > Author: Matthieu Sarter > Date: Wed Mar 22 17:57:01 2017 +0100 > > sycall: WCOREDUMP macro is not defined on AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38363 > > > commit 4f38813482227b12ea0ac6ac1b981ff9ef9853ef > Author: Matthieu Sarter > Date: Thu Mar 23 17:44:43 2017 +0100 > > libgo: additional build tags for AIX > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38510 > > > commit d117ede6ff5a7083e9c40eba28a0f94f3535d773 > Author: Matthieu Sarter > Date: Thu Mar 23 17:48:46 2017 +0100 > > go/build: add AIX to "go build" command known OS > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38511 > > > commit 7b0ddaa6a6a71f9eb1c374122d29775b13c2cac5 > Author: Ian Lance Taylor > Date: Thu Mar 23 09:57:01 2017 -0700 > > compiler: don't crash if imported package imports this one > > When building a test it's OK if test code imports a package that > imports this one. The go tool is supposed to catch cases where this > creates an impossible initialization order. The compiler already has > code to permit this in Gogo::add_import_init_fn. This CL avoids a > compiler crash on a similar case when writing out the export data. > > I have no test case for this. Basically it pushes a compiler crash > into an error reported elsewhere. > > Problem was reported by Tony Reix. > > Reviewed-on: https://go-review.googlesource.com/38462 > > > commit 925636975d075e3e3353823b09db3f933f23cb03 > Author: Ian Lance Taylor > Date: Wed Mar 29 14:14:18 2017 -0700 > > runtime: copy finalizer support from Go 1.8 runtime > > Reviewed-on: https://go-review.googlesource.com/38794 > > > commit 1ccb22b96cb3b1011db0e427877d9ddecb577fa9 > Author: Matthieu Sarter > Date: Thu Mar 30 15:21:06 2017 +0200 > > runtime: initcontext and setcontext stubs for AIX > > Further investigations are required to understand the clobbering > issue and implement a proper fix. Until then, those stubs are > required to allow the build to complete. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38930 > > > commit 27db481f369b54256063c72b911d22390c59199c > Author: Matthieu Sarter > Date: Wed Mar 29 18:07:25 2017 +0200 > > os: fix Readlink failure on AIX > > AIX readlink routine returns an error if the link is longer > than the buffer, instead of truncating the link. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38700 > > > commit c93babbf48eddd0bc34d4179ffb302dc60087299 > Author: Matthieu Sarter > Date: Wed Mar 29 17:26:35 2017 +0200 > > compiler: implement support for reading AIX big archives > > This is required to read go export from a Go library. > > Code courtesy of Damien Bergamini from Atos Infog=C3=A9rance. > > Issue golang/go#19200 > Reviewed-on: https://go-review.googlesource.com/38698 > > > commit 930dd53482bdee3a9074850d168d0b9d7819c135 > Author: Ian Lance Taylor > Date: Thu Apr 6 18:50:11 2017 -0700 > > compiler: fix whether conversions are static initializers > > The compiler was incorrectly treating type conversions from string to > int or vice-versa as static initializers. That doesn't work, as those > conversions are implemented via a function call. > > This case may never actually arise but it seems like the right thing = to do. > > Reviewed-on: https://go-review.googlesource.com/39872 > > > commit f02691e4195728dbf06f4dde0853c6bccc922183 > Author: Ian Lance Taylor > Date: Thu Apr 6 17:24:08 2017 -0700 > > compiler, runtime: don't let slices point past end of memory block > > When Go code uses a slice expression like [:len(str)] or [:cap(slice)= ], > it's natural for the resulting pointer to point just past the end of > the memory block. If the next memory block is not live, we now have a > live pointer to a dead block, which will unnecessarily keep the block > alive. That wastes space, and with the new Go 1.8 GC (not yet > committed) will trigger an error when using GODEBUG=3Dgccheckmark=3D1. > > This changes the implementation of slice expressions to not move the > pointer if the resulting string length or slice capacity is 0. When > the length/capacity is zero, the pointer is never used anyhow. > > Reviewed-on: https://go-review.googlesource.com/39870 > > > commit 17527c35b027e1afcc318faf5563909e1e9d44a6 > Author: Ian Lance Taylor > Date: Thu Apr 6 15:30:11 2017 -0700 > > compiler: emit write barriers > > The Go 1.8 concurrent GC requires optional write barriers for all > assignments that may change pointer values in the heap or in a global > variable. For details see https://blog.golang.org/go15gc. > > This changes the gofrontend code to emit write barriers as needed. > This is in preparation for future changes. At the moment the write > barriers will do nothing. They test runtime.writeBarrier.enabled, > which will never be non-zero. They call simple functions which just > do a move without doing any of the other operations required by the > write barrier. > > Reviewed-on: https://go-review.googlesource.com/39852 > > > commit c0b00f072bf34b2c288e1271ec8118b88c4f6f6f > Author: Matthieu Sarter > Date: Tue Apr 11 17:47:29 2017 +0200 > > libgo: allow building gox files from PIC objects > > libtool builds non-PIC objects in the same directory as .lo files > and PIC objects in a .libs subdirectory. > BUILDGOX rule uses the non-PIC objects to build the gox files, > but on AIX only the PIC objects are built. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/40355 > > > commit ea0f3da174c5503a209043f14ddda34871cfec52 > Author: Ian Lance Taylor > Date: Thu Apr 6 19:06:14 2017 -0700 > > compiler: add code to generate a ptrmask for a type > > The Go 1.8 garbage collector uses a ptrmask for all types below a > certain size. A ptrmask is simply a bit vector with a single bit for > each pointer-sized word in the value. The bit is 1 if the type has a > pointer in that position, 0 if it does not. > > This change adds code to the compiler to generate a ptrmask. The code > is not used by anything yet, it is just compiled. It will be used > when we switch over to the Go 1.8 garbage collector. > > The new Array_type::int_length method, and the new memory_size > methods, will also be used by other patches coming later. > > Reviewed-on: https://go-review.googlesource.com/39873 > > > commit 3029e1df3be3614d196a03c15e50e68ff850aa4c > Author: Ian Lance Taylor > Date: Fri Apr 7 10:31:39 2017 -0700 > > compiler: add code to generate a gcprog for a type > > The Go 1.8 garbage collector uses a gcprog for all types above a > certain size. A gcprog describes where the pointers are in the type, > using a simple bytecode machine that supports repeating bits. The > effect is to permit using much less space to describe arrays. The > format is described in runtime/mbitmap.go in the docs for runGCProg. > This is not yet added to the gofrontend, but can be seen in the gc so= urces. > > This change adds code to the compiler to generate a gcprog. The code > is not used by anything yet, it is just compiled. It will be used > when we switch over to the Go 1.8 garbage collector. > > Reviewed-on: https://go-review.googlesource.com/39923 > > > commit 8b01ef1e9176d20f4c9e667972fe031069a4d057 > Author: Ian Lance Taylor > Date: Thu Apr 13 07:00:35 2017 -0700 > > compiler: add ptrdata computations and expressions > > For the upcoming Go 1.8 GC we need to compute the "ptrdata" of a type: > the number of bytes in the type that can contain pointers. For types > that do not contain pointers this number is zero. For many types it > is a number larger than zero but smaller than the total size of the > type. The Go 1.8 GC uses this number to make loops looking for > pointers run faster by not scanning the suffix of a value that can not > contain a pointer. > > Unfortunately there are two subtly different definitions of ptrdata, > and we need both. The first is the simple one: the prefix that can > contain pointers. The second is the number of bytes described by the > gcprog for the type. Recall that we describe the exact position of > pointers in a type using either a ptrmask or a gcprog. The ptrmask is > simpler, the gcprog uses less space. We use the gcprog for large > types, currently defined as types that are more than 2048 bytes. When > the Go 1.8 runtime expands a gcprog, it verifies that the gcprog > describes exactly the same number of bytes as the ptrdata field in the > type descriptor. If the last pointer-containing portion of a type is > an array, and if the elements of the array have a ptrdata that is less > than the size of the element type, then the simple definition of the > ptrdata will not include the final non-pointer-containing bytes of the > last element of the array. However, the gcprog will define the array > using a repeat count, and will therefore include the full size of the > last element of the array. So for a type that needs a gcprog, the > ptrdata field in the type descriptor must be the size of the data > described by the gcprog, and that is not necessarily the same as the > simple ptrdata. > > It might seem that we can always use the gcprog version of the ptrdata > calculation, since that is what will appear in a type descriptor, but > it turns out that for global variables we always use a ptrmask, not a > gcprog, even if the global variable is large. This is because gcprogs > are handled by expanding them into a ptrmask at runtime, and for a > global variable there is no natural place to put the ptrmask. Simpler > to always use the ptrmask. That means that we need to describe the > size of the ptrmask, and that means that we need an expression for the > simple form of the ptrdata. > > This CL implements the ptrdata calculation. This code is not actually > used yet. It will be used later when the Go 1.8 GC is committed. > > Reviewed-on: https://go-review.googlesource.com/40573 > > > commit 7a37331303b572412179a08141f1dd35339d40c8 > Author: Ian Lance Taylor > Date: Fri Apr 14 06:55:48 2017 -0700 > > compiler: zero length arrays never contain pointers > > Reviewed-on: https://go-review.googlesource.com/40696 > > > commit c242f0508a64d3d74a28d498cbaeda785ff76258 > Author: Ian Lance Taylor > Date: Fri Apr 14 07:26:54 2017 -0700 > > bytes: disable allocations test on gccgo > > It turns out that testing.AllocsPerRun has not been producing correct > results with the current gccgo memory allocator. When we update to > the Go 1.8 memory allocator, testing.AllocsPerRun will work again, and > this test will fail due to lack of escape analysis. > > Reviewed-on: https://go-review.googlesource.com/40700 > > > commit 0dc369f1d63376a36bfb0999a1b0377fd444bfab > Author: Matthieu Sarter > Date: Tue Apr 11 16:22:38 2017 +0200 > > os: alternative way to find executable path, using Args[0] > > AIX does not provide a proper way to find the original > executable path from procfs, which contains just an > hardlink. > Executable path can be found using Args[0], Getcwd and > $PATH. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/40353 > > > commit f9bad1342569b338e3b2ea9f12ffc6d3d3fa3028 > Author: Ian Lance Taylor > Date: Fri Apr 14 08:01:19 2017 -0700 > > compiler: don't write struct with multiple sink fields to C header fi= le > > When writing a struct to the C header file used by the C runtime code, > a single sink field is fine: it will be called "_", which is valid C. > There are structs with single sink fields that we want to write out, > such as finblock. As it happens, though, the Go 1.8 runtime has a > struct with two sink fields, gcControllerState, which will produce a C > definition with two fields named "_", which will fail. Since we don't > need to know that struct in C, rather than fix the general case, just > punt if the struct has multiple sink fields. > > After the conversion to the Go 1.8 GC, we may be able to get rid of > the C header file anyhow. I'm not sure yet. > > Reviewed-on: https://go-review.googlesource.com/40701 > > > commit cfc28901a572aeb15b2f10a38f79eec04c64dfb2 > Author: Ian Lance Taylor > Date: Fri Apr 14 10:07:23 2017 -0700 > > runtime: disable allocations test on gccgo > > It turns out that testing.AllocsPerRun has not been producing correct > results with the current gccgo memory allocator. When we update to > the Go 1.8 memory allocator, testing.AllocsPerRun will work again, and > these tests will fail due to lack of escape analysis. > > Reviewed-on: https://go-review.googlesource.com/40703 > > > commit 36fedd76edaa48b9ec09709a70d9e4abaddf0caf > Author: Ian Lance Taylor > Date: Fri Apr 14 10:47:06 2017 -0700 > > runtime: remove unused size argument from hash/equal fns > > The size argument was removed from hash and equal functions in CL > 34983. Somehow I missed removing them from three of the predefined > functions. > > Reviewed-on: https://go-review.googlesource.com/40770 > > > commit 90f6accb48d2e78cad8955b9292933f6ce3fe4c8 > Author: Ian Lance Taylor > Date: Fri Apr 14 13:23:05 2017 -0700 > > runtime: remove unused stack.go > > We're never going to use stack.go for gccgo. Although a build tag > keeps it from being built, even having it around can be confusing. > Remove it. > > Reviewed-on: https://go-review.googlesource.com/40774 > > > commit befa71603fc66a214e01ac219f2bba36e19f136f > Author: Ian Lance Taylor > Date: Fri Apr 14 13:18:34 2017 -0700 > > runtime: build fastlog > > Take out the build tags which were preventing fastlog2 from being > built. It's used by the upcoming Go 1.8 GC. > > Reviewed-on: https://go-review.googlesource.com/40773 > > > commit b7e19e9be4ab4c3cd8f4c9506d79a8cd56bace40 > Author: Ian Lance Taylor > Date: Fri Apr 14 10:04:23 2017 -0700 > > runtime: add tests from Go 1.8 > > Some runtime package tests never made it into the gofrontend repo for > some reason. Add them now. > Reviewed-on: https://go-review.googlesource.com/40869 > > > commit 1feef185aebd71bc2a09b9a04287461806096610 > Author: Ian Lance Taylor > Date: Mon Apr 17 16:26:11 2017 -0700 > > runtime: change mcall to take a Go function value > > For future work in bringing in the Go 1.8 GC, change the mcall > function to take a Go function value, which means that mcall can take > a closure rather than just a straight C function pointer. > > As part of this change move kickoff from C to Go, which we want to do > anyhow so that we run the write barriers that it generates. > > Reviewed-on: https://go-review.googlesource.com/40935 > > > commit c3db34f4efc2d610f74a01dd2ad7775f48889b29 > Author: Matthieu Sarter > Date: Tue Apr 11 16:11:26 2017 +0200 > > runtime: netpoll implementation for AIX > > Code courtesy of Damien Bergamini from Atos Infog=C3=A9rance. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/40352 > > > commit f5634dff40e53ad9ce61afd67fd07334e3af9d1f > Author: Ian Lance Taylor > Date: Tue Apr 18 22:06:07 2017 -0700 > > runtime: move mstart from Go to C > > The assignments done in mstart must be done without write barriers, as > mstart is running without an m or p. In the gc toolchain the > equivalent code to intialize g and g->m is written in assembler; > on GNU/Linux, it's in the clone function. > > Reviewed-on: https://go-review.googlesource.com/40989 > > > commit 671d7c74592f4b6fe3665af279482ba0ea47ca2d > Author: Ian Lance Taylor > Date: Tue Apr 18 17:47:28 2017 -0700 > > compiler: varargs slices do not escape in runtime > > Also, don't try to allocate an empty slice on the stack, as it will > confuse the GCC backend. > > Also add a few trivial style, code formatting, and debug output fixes. > > Updates golang/go#17431 > > Reviewed-on: https://go-review.googlesource.com/40983 > > > commit 94699d25f31353bf03419eda56b15993a39f3275 > Author: Ian Lance Taylor > Date: Tue Apr 18 17:30:09 2017 -0700 > > compiler: add Ptrmask_symbol_expression > > Add an expression to evaluate to the ptrmask for a type. This will be > used for global variables, which always use a ptrmask no matter how > large they are. > > Reviewed-on: https://go-review.googlesource.com/40981 > > > commit bfff1654eac5b9288fa6c431e66cba8c9da6a660 > Author: Ian Lance Taylor > Date: Mon Apr 17 10:51:16 2017 -0700 > > runtime: change g's in systemstack > > The systemstack function in the gc toolchain changes to a different g. > This is often used to get more stack space; the gofrontend uses a > different stack growth mechanism that does not require changing g's, > so we've been running with a version of systemstack that keeps the > same g. However, the garbage collector has various tests to verify > that it is running on g0 rather than on a normal g. For simplicity, > change the gofrontend version of systemstack to change to a different > g just as the gc toolchain does. > > This permits us to uncomment some sanity checks in notetsleep. > Doing that requires us to fix up a couple of places where C code calls > {start,stop}TheWorldWithSema while not on g0. > > Note that this does slow down some code in the runtime package > unnecessarily. > It may be useful to find some places where the runtime calls > systemstack only to get more stack space and change it to use some > other function. That other function would act like systemstack in the > gc toolchain but simply call the argument in the gofrontend. > > Reviewed-on: https://go-review.googlesource.com/40973 > > > commit b2ccc7601ce71a7c5732154cf9b2eeea64681469 > Author: Ian Lance Taylor > Date: Wed Apr 19 10:36:12 2017 -0700 > > compiler, runtime: include ptrmask in GC roots > > Change the list of registered GC roots to include a ptrmask, > and change the data structures to be easily used from Go code. > The new ptrmask will be used by the Go 1.8 GC to only scan pointers. > Tweak the current GC to use the new structures, but ignore the new > ptrmask information for now. > > The new GC root data includes the size of the variable. The size is > not currently used, but will be used later by the cgo checking code. > > Reviewed-on: https://go-review.googlesource.com/41075 > > > commit 9e065149970bc180e4ca83bb99c74d9c4f43b47b > Author: Ian Lance Taylor > Date: Wed Apr 19 12:23:16 2017 -0700 > > compiler, runtime: don't pass size to __go_new > > There is no reason to pass the size to __go_new, as the type > descriptor includes the size anyhow. This makes the function > correspond to the Go 1.8 function runtime.newobject, which is what we > will use when we update to the Go 1.8 memory allocator. > > Reviewed-on: https://go-review.googlesource.com/41080 > > > commit c321de7b738c4a3387c1842919c9305acfa04c57 > Author: Ian Lance Taylor > Date: Wed Apr 19 13:13:56 2017 -0700 > > compiler, runtime, reflect: make type descriptors more like Go 1.8 > > Change the type descriptor structure to be more like the one in the Go > 1.8 runtime. Specifically we add the ptrdata field, rename the gc > field to gcdata and change the type to *byte, and rearrange a few of > the fields. The structure is still not identical to the Go 1.8 > structure--we don't use any of the tricks to reduce overall executable > size--but it is more similar. > > For now we don't use the new ptrdata field, and the gcdata field is > still the old format rather than the new Go 1.8 ptrmask/gcprog format. > > Reviewed-on: https://go-review.googlesource.com/41081 > > > commit 7b70c52cddeebea9ebeac003f8c6aad59497e5f0 > Author: Ian Lance Taylor > Date: Wed Apr 19 14:54:29 2017 -0700 > > reflect: make sure to clear unusable hash/equal function > > Otherwise we wind up copying the one from the prototype, which is wro= ng. > > Also rewrite the hash/equal functions to look like the ones in Go 1.8, > mainly a matter of changing names and using arrayAt. > > Reviewed-on: https://go-review.googlesource.com/41133 > > > commit 84d26f467f7de8bdbb0d230458135fe1b6b2a99d > Author: Ian Lance Taylor > Date: Wed Apr 19 14:59:13 2017 -0700 > > runtime: remove duplicate declarations of SetFinalizer/KeepAlive > > These should have been removed in CL 38794. It's a bug that the > compiler even permits these duplicate declarations. > > Reviewed-on: https://go-review.googlesource.com/41134 > > > commit f85ff7e64c24031f6d0bd7c9c426b6176cb95160 > Author: Ian Lance Taylor > Date: Wed Apr 19 15:56:32 2017 -0700 > > runtime: don't crash if panicstring called with no m > > It's possible for runtime_panicstring to be called with no m if a > signal handler, or scheduler innards, do something wrong. If that > happens carry on with the panic rather than crashing. > > Reviewed-on: https://go-review.googlesource.com/41137 > > > commit 5b362b04f642afb8b20715930416fc3b7d91bb12 > Author: Than McIntosh > Date: Fri Mar 31 14:35:48 2017 -0400 > > compiler: fix for expr sharing introduced by Order_eval::statement. > > When processing an expression statement with a top-level call > that returns multiple results, Order_eval::statement can wind up > creating a tree that has multiple references to the same call, > which results in a confusing AST dump. Change the implementation > to avoid introducing this unwanted sharing. > > Reviewed-on: https://go-review.googlesource.com/39210 > > > commit b05b4260a68695bf9c9cc29e14ae86ca2699458a > Author: Ian Lance Taylor > Date: Wed Apr 19 16:00:28 2017 -0700 > > runtime: restore correct m in gtraceback > > If gtraceback is used to get a stack trace of a g running in the same= m, > as can happen if we collect a stack trace from a g0, then restore the > old m value, don't clear it. > > Reviewed-on: https://go-review.googlesource.com/41138 > > > commit ca8bbf4dfac19b3f4f7ce21a688b96a418c75031 > Author: Ian Lance Taylor > Date: Wed Apr 19 16:03:24 2017 -0700 > > runtime: set startpc field when starting a new goroutine > > This puts the right value in a trace--previously it was always zero. > > Reviewed-on: https://go-review.googlesource.com/41139 > > > commit ca8bbf4dfac19b3f4f7ce21a688b96a418c75031 > Author: Ian Lance Taylor > Date: Wed Apr 19 16:03:24 2017 -0700 > > runtime: set startpc field when starting a new goroutine > > This puts the right value in a trace--previously it was always zero. > > Reviewed-on: https://go-review.googlesource.com/41139 > > > commit 887690dce42d7bf8f711f8ea082e4928fb70f2a5 > Author: Ian Lance Taylor > Date: Wed Apr 19 17:06:11 2017 -0700 > > runtime: add prefetch functions > > The Go 1.8 GC uses prefetch functions. Add versions for gccgo that > call __builtin_prefetch. Uncomment the test for them in testAtomic64. > Don't force the check function to return early, as now taking the > address of a local variable in the runtime package does not force it > onto the heap. > > Reviewed-on: https://go-review.googlesource.com/41144 > > > commit 4269db69f9184e5a45c54aaee7352425a1f88bff > Author: Ian Lance Taylor > Date: Wed Apr 19 17:55:21 2017 -0700 > > runtime: split up ticks to get correct alignment > > On 32-bit x86 a uint64 variable by itself is aligned to an 8-byte bou= ndary. > A uint64 field in a struct is aligned to a 4-byte boundary. > The runtime.ticks variable has a uint64 field that must be aligned > to an 8-byte boundary. Rather than rely on luck, split up the struct > into separate vars so that the required alignment happens reliably. > > It would be much nicer if issue golang/go#19057 were fixed somehow, > but that is for another day. > > Reviewed-on: https://go-review.googlesource.com/41143 > > > commit 66926cabdbdbf3431b4f172f7756e195c1c6c513 > Author: Matthieu Sarter > Date: Thu Apr 20 17:15:38 2017 +0200 > > libgo: fix bad value for O_CLOEXEC on AIX 7.1 > > On AIX 7.1, O_CLOEXEC is defined as 0x0000001000000000, which > creates an integer constant overflow error when building libgo. > > This affects only 7.1, O_CLOEXEC is not defined on 6.1 (and > defaults to O in sysinfo.go) and is defined as 0x00800000 on > AIX 7.2. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/41214 > > > commit af288ff10aeafc47651f5def327ed56425d5be19 > Author: Ian Lance Taylor > Date: Thu Apr 20 17:15:02 2017 -0700 > > runtime: preserve stack context in tracebackothers > > The tracebackothers function works by saving the current stack context > in the goroutine's context field and then calling gogo to switch to a > new goroutine. The new goroutine will collect its own stack trace and > then call gogo to switch back to the original goroutine. This works > fine, but if the original goroutine was called by mcall then the > contents of its context field are needed to return from the mcall. > Fix this by saving the stack context across the calls to the other > goroutines. > > Reviewed-on: https://go-review.googlesource.com/41293 > > > commit 43101e5956e793f1b4de05c15d7738c785e927df > Author: Matthieu Sarter > Date: Fri Apr 21 10:58:52 2017 +0200 > > os/user: use _posix_* libc functions > > libc getpwnam_r function has a different signature, we must use > _posix_getpwnam_r instead (by default, the pwd.h system include > file defines getpwnam_r as a static function calling > _posix_getpwnam_r, so a C program calling getpwnam_r will indeed > reference the _posix_getpwnam_r symbol). > > Idem for getpwuid_r, getgrnam_r and getgrgid_r. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/41334 > > > commit 71e1fec4d2a536591ea6657a06916a17b5127071 > Author: Ian Lance Taylor > Date: Wed Apr 19 21:24:48 2017 -0700 > > runtime: don't use pointers in g_ucontext_t or stackcontext > > The g_ucontext_t type holds registers saved for a goroutine. We have > to scan it for pointers, but since registers don't necessarily hold > pointers we have to scan it conservatively. That means that it should > not have a pointer type, since the GC will always scan pointers. > Instead it needs special treatment to be scanned conservatively. > The current GC doesn't care when a pointer type holds a non-pointer, > but the Go 1.8 GC does. > > For the current GC this means we have to explicitly scan the > g_ucontext_t values in a G. > > While we're at it change stackcontext to be uintptr too. The entries > in stackcontext never hold pointers that the Go GC cares about. > > Reviewed-on: https://go-review.googlesource.com/41270 > > > commit eab2960aee91d3e3a6baa5b1bce01262d24c714f > Author: Ian Lance Taylor > Date: Thu Apr 20 17:08:19 2017 -0700 > > runtime/internal/sys: define Goexperiment > > The gc toolchain defines Goexperiment based on the environment > variable GOEXPERIMENT when the toolchain is built. We just always set > Goexperiment to the empty string. > > Reviewed-on: https://go-review.googlesource.com/41292 > > > commit be4a751943265c0637da859d15a4faf162f5c478 > Author: Matthieu Sarter > Date: Thu Apr 20 14:04:35 2017 +0200 > > net: sockopt implementation for AIX > > This is a copy of the Linux implementation, it allows to > run some simple client/server applications on AIX, while > the current sockopt stubs don't. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/41213 > > > commit 46a669c4ca5b80fd6f6a0a42095804d9f704611d > Author: Matthieu Sarter > Date: Wed Mar 29 17:55:06 2017 +0200 > > math: fix sign for atan/expm1/log1p(-0) > > AIX libc returns +0 for atan(-0), expm1(-0) and log1p(-0), > while matching Go functions must return -0. > > Code courtesy of Tony Reix. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/38699 > > > commit 53b0e809130038a46f0a3d2870e3905f44ab888d > Author: Matthieu Sarter > Date: Wed Apr 26 17:29:22 2017 +0200 > > runtime: fix context clobbering on AIX > > On AIX 64-bits, r13 is a pointer to thread data. > setcontext() overwrites r13 with the value saved by getcontext(). > So, when a goroutine is scheduled on a new thread, r13 will point > to the old thread data after calling setcontext(). > > Code courtesy of Damien Bergamini. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/41854 > > > commit f8d5ebd71c71e6e777200530d8204b92619157f8 > Author: Matthieu Sarter > Date: Wed Apr 26 18:01:19 2017 +0200 > > runtime: fix wrong time calculation in semasleep > > tv_nsec is added twice when calculating the sleep end time. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/41855 > > > commit ef56097f4ea848d48fbf61eba1c757fe7fce99d3 > Author: Matthieu Sarter > Date: Fri Apr 28 10:27:32 2017 +0200 > > libgo: pass $(NM) value when running benchmarks > > On AIX, we need to use "nm -B" instead of "nm", to have the > epxected output format, so the configured $(NM) value from > the Makefile should be exported before running gotest, which > defaults to "nm" if $NM is not set. > > Issue golang/go#19200 > > Reviewed-on: https://go-review.googlesource.com/42051 > > > commit 0fb550083ae474fb964435927b899ec8e4b62771 > Author: Ian Lance Taylor > Date: Wed Nov 16 21:12:53 2016 -0800 > > runtime: copy garbage collector from Go 1.8 runtime > > This giant patch replaces the old Go 1.4 memory allocator and garbage > collector with the new Go 1.8 code. The memory allocator is fairly > similar, though now written in Go rather than C. The garbage > collector is completely different. It now uses ptrmask and gcprog > information, which requires changes in the compiler and the reflect > package as well as the runtime. And, of course, the garbage collector > now runs concurrently with program execution. > > In the gc toolchain the garbage collector is strict and precise at all > levels. In the gofrontend we do not have stack maps, so stacks, and > register values, are collected conservatively. That means that an > old, no longer used, pointer on a stack or in a register can cause a > memory object to live longer than it should. That in turns means that > we must disable some checks for invalid pointers in the garbage > collection code. Not only can we get an invalid pointer on the stack; > the concurrent nature of the collector means that we can in effect > resurrect a block that was already unmarked but that the collector had > not yet gotten around to freeing, and that block can in turn point to > other blocks that the collector had managed to already free. So we > must disable pointer checks in general. In effect we are relying on > the fact that the strict pointer checks in the gc toolchain ensure > that the garbage collector is correct, and we just assume that it is > correct for the gofrontend since we are using the same code. > > Reviewed-on: https://go-review.googlesource.com/41307 > > > commit a95078d501175240d095500a8c5fbfb21bec65cb > Author: Ian Lance Taylor > Date: Mon Apr 24 16:33:47 2017 -0700 > > libgo/Makefile: clean more files > > Fix up the mostlyclean, clean, and distclean targets to better follow > https://www.gnu.org/prep/standards/html_node/Standard-Targets.html. > > Reviewed-on: https://go-review.googlesource.com/41625 > > > commit 5956bf1055451cf4239cdfeca259c23b1ded54d8 > Author: Ian Lance Taylor > Date: Mon May 8 13:35:11 2017 -0700 > > libgo: delete goc2c > > The last .goc file has been removed, so remove goc2c. > > The goc2c program was my first contribution to the gc repository that > was more than 100 lines: > https://github.com/golang/go/commit/2b57a1124e87b0dc8bc1ff6899297b4d7= d6e74f2 > The program was used in gc for a few years under various guises but > was finally removed in https://golang.org/cl/132680043. Now we can > remove it from gofrontend as well. > > Reviewed-on: https://go-review.googlesource.com/42911 > > > commit a222e35d041de0cd42506b61c93b8209e07702b9 > Author: Than McIntosh > Date: Tue May 9 10:33:10 2017 -0400 > > compiler: set "need_init_fn" when adding gc root > > Variables that back slice initializers in certain cases have to be > added to the gc roots list, since they can be modified at runtime. The > code that was doing this addition did not update the flag that tracks > whether the package being compiled needs an initializer function, > which resulted in the call in question being left out of the final > generated code in certain cases. Fix is to change Gogo::add_gc_root() > to update the "needs init" flag. > > Reviewed-on: https://go-review.googlesource.com/43030 > > > commit 822ab419bf7d1c705cdce1c12133e7a11f56be2e > Author: Than McIntosh > Date: Tue May 9 11:36:51 2017 -0400 > > compiler: fix variable context nit in write barrier generation > > Update the write barrier generation code to insure that the "lvalue > context" tag on the space var expression is set only in the case where > the expr feeds directly into an assignment. This is somewhat > counter-intuitive, but needed in the case where the backend looks at > context tags. > > Reviewed-on: https://go-review.googlesource.com/43031