From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21800 invoked by alias); 19 Jun 2016 13:25:29 -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 21786 invoked by uid 89); 19 Jun 2016 13:25:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:15.1.517.7, H*RU:15.1.517.7, H*r:ip*15.1.517.7, berndedlingerhotmailde X-HELO: SNT004-OMC3S46.hotmail.com Received: from snt004-omc3s46.hotmail.com (HELO SNT004-OMC3S46.hotmail.com) (65.54.51.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Sun, 19 Jun 2016 13:25:18 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com ([65.55.90.135]) by SNT004-OMC3S46.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 19 Jun 2016 06:25:16 -0700 Received: from HE1EUR01FT022.eop-EUR01.prod.protection.outlook.com (10.152.0.58) by HE1EUR01HT133.eop-EUR01.prod.protection.outlook.com (10.152.0.216) with Microsoft SMTP Server (TLS) id 15.1.517.7; Sun, 19 Jun 2016 13:25:09 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.0.57) by HE1EUR01FT022.mail.protection.outlook.com (10.152.0.165) with Microsoft SMTP Server (TLS) id 15.1.517.7 via Frontend Transport; Sun, 19 Jun 2016 13:25:09 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) with mapi id 15.01.0517.014; Sun, 19 Jun 2016 13:25:08 +0000 From: Bernd Edlinger To: Jakub Jelinek , Jeff Law CC: "gcc-patches@gcc.gnu.org" , Vladimir Makarov , Richard Biener Subject: [PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155) Date: Sun, 19 Jun 2016 13:25:00 -0000 Message-ID: References: <5755AD05.4010608@redhat.com> <20160606180128.GC7387@tucnak.redhat.com> <20160606180845.GD7387@tucnak.redhat.com> <20160606194047.GF7387@tucnak.redhat.com> <74b7fd4b-e060-c3e8-16bb-9f529a7dc4b2@redhat.com> <20160609164304.GT7387@tucnak.redhat.com> <20160609164545.GU7387@tucnak.redhat.com> In-Reply-To: authentication-results: spf=softfail (sender IP is 25.152.0.57) smtp.mailfrom=hotmail.de; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.de discourages use of 25.152.0.57 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:25.152.0.57;IPV:NLI;CTRY:GB;EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1EUR01HT133;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;CAT:NONE;LANG:en;CAT:NONE; x-ms-office365-filtering-correlation-id: dd981885-4286-483d-c3a5-08d3984521e7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(5061506196)(5061507196)(1603103041)(1601125047);SRVR:HE1EUR01HT133; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(102415321)(82015046);SRVR:HE1EUR01HT133;BCL:0;PCL:0;RULEID:;SRVR:HE1EUR01HT133; x-forefront-prvs: 09781D4C35 Content-Type: multipart/mixed; boundary="_003_AM4PR0701MB2162A54B3CAFABC7BE6FD859E4290AM4PR0701MB2162_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2016 13:25:08.5580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT133 X-SW-Source: 2016-06/txt/msg01363.txt.bz2 --_003_AM4PR0701MB2162A54B3CAFABC7BE6FD859E4290AM4PR0701MB2162_ Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Content-length: 2595 Hi, ping... As this discussion did not make any progress, I just attached the latest version of my patch with the the changes that Vladimir proposed. Boot-strapped and reg-tested again on x86_64-linux-gnu. Is it OK for the trunk? Thanks Bernd. On 06/10/16 16:13, Bernd Edlinger wrote: > On 06/09/16 18:45, Jakub Jelinek wrote: >> On Thu, Jun 09, 2016 at 06:43:04PM +0200, Jakub Jelinek wrote: >>> Yes, I'm all in favor in disabling X constraint for inline asm. >>> Especially if people actually try to print it as well, rather than >>> make it >>> unused. That is a sure path to ICEs. >> >> Though, on the other side, even our documentation mentions >> asm volatile ("mtfsf 255,%1" : "=3DX"(sum): "f"(fpenv)); >> So perhaps we need to error just in case such an argument is printed? > > note that "=3DX" is also introduced internally in this asm statement: > > asm ("cmpl %2, 0" : "=3D@ccz"(z), "=3D@ccb"(b): "r"(i)); > > see i386.c, ix86_md_asm_adjust. > > The first =3D@cc is replaced by "=3DBf" constraint but any > further =3D@cc are replaced by "=3DX" and scratch operand. > > Printing the "=3DX" scratch is harmless, but printing the "=3DBf" causes > another ICE, I shall submit a follow up patch for that: > asm ("# %0" : "=3D@ccz"(z)); > > test.c:6:1: internal compiler error: in print_reg, at > config/i386/i386.c:17193 > } > ^ > 0xedfc30 print_reg(rtx_def*, int, _IO_FILE*) > ../../gcc-trunk/gcc/config/i386/i386.c:17189 > 0xf048a4 ix86_print_operand(_IO_FILE*, rtx_def*, int) > ../../gcc-trunk/gcc/config/i386/i386.c:17867 > 0x8bf87c output_operand(rtx_def*, int) > ../../gcc-trunk/gcc/final.c:3847 > 0x8c00ee output_asm_insn(char const*, rtx_def**) > ../../gcc-trunk/gcc/final.c:3763 > 0x8c1f9c final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > ../../gcc-trunk/gcc/final.c:2628 > 0x8c25c9 final(rtx_insn*, _IO_FILE*, int) > ../../gcc-trunk/gcc/final.c:2045 > 0x8c2da9 rest_of_handle_final > ../../gcc-trunk/gcc/final.c:4445 > 0x8c2da9 execute > ../../gcc-trunk/gcc/final.c:4520 > > > Well, regarding the X constraint, I do think that > it's definitely OK to use different rules if it is > used in asms vs. when if it is used internally in .md files. > > The patch handles X in asms to be just a synonym to the g constraint, > except that g allows only GENERAL_REGS and X allows ALL_REGS. > > What I am not sure of, is if X should allow more than g in terms of > CONSTANT_P. I think it should not, because probably the CONSTANT_P > handling in general_operand is likely smarter than that of the i > constraint. > > > Bernd. --_003_AM4PR0701MB2162A54B3CAFABC7BE6FD859E4290AM4PR0701MB2162_ Content-Type: text/plain; name="changelog-pr59155.txt" Content-Description: changelog-pr59155.txt Content-Disposition: attachment; filename="changelog-pr59155.txt"; size=421; creation-date="Sun, 19 Jun 2016 13:25:07 GMT"; modification-date="Sun, 19 Jun 2016 13:25:07 GMT" Content-ID: <1ED465EC957B974D9A5828E63EAD8875@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 Content-length: 574 Z2NjOg0KMjAxNi0wNS0yMyAgQmVybmQgRWRsaW5nZXIgIDxiZXJuZC5lZGxp bmdlckBob3RtYWlsLmRlPg0KDQoJUFIgaW5saW5lLWFzbS81OTE1NQ0KCSog bHJhLWNvbnN0cmFpbnRzLmMgKHByb2Nlc3NfYWx0X29wZXJhbmRzKTogQWxs b3cgQUxMX1JFR1MuDQoJKiByZWNvZy5jIChhc21fb3BlcmFuZF9vayk6IEhh bmRsZSBYIGNvbnN0cmFpbnQuDQoNCnRlc3RzdWl0ZToNCjIwMTYtMDUtMjMg IEJlcm5kIEVkbGluZ2VyICA8YmVybmQuZWRsaW5nZXJAaG90bWFpbC5kZT4N Cg0KCVBSIGlubGluZS1hc20vNTkxNTUNCgkqIGdjYy5kZy90b3J0dXJlL3By NTkxNTUtMS5jOiBOZXcgdGVzdC4NCgkqIGdjYy5kZy90b3J0dXJlL3ByNTkx NTUtMi5jOiBOZXcgdGVzdC4NCgkqIGdjYy5kZy90b3J0dXJlL3ByNTkxNTUt My5jOiBOZXcgdGVzdC4NCg== --_003_AM4PR0701MB2162A54B3CAFABC7BE6FD859E4290AM4PR0701MB2162_ Content-Type: text/x-patch; name="patch-pr59155.diff" Content-Description: patch-pr59155.diff Content-Disposition: attachment; filename="patch-pr59155.diff"; size=2660; creation-date="Sun, 19 Jun 2016 13:25:07 GMT"; modification-date="Sun, 19 Jun 2016 13:25:07 GMT" Content-ID: Content-Transfer-Encoding: base64 Content-length: 3608 SW5kZXg6IGdjYy9scmEtY29uc3RyYWludHMuYw0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KLS0tIGdjYy9scmEtY29uc3RyYWludHMuYwkocmV2aXNpb24g MjM3MTMzKQ0KKysrIGdjYy9scmEtY29uc3RyYWludHMuYwkod29ya2luZyBj b3B5KQ0KQEAgLTE4NTQsOCArMTg1NCw5IEBAIHByb2Nlc3NfYWx0X29wZXJh bmRzIChpbnQgb25seV9hbHRlcm5hdGl2ZSkNCiAJICBpZiAoY3Vycl9zdGF0 aWNfaWQtPm9wZXJhbmRfYWx0ZXJuYXRpdmVbb3BhbHRfbnVtXS5hbnl0aGlu Z19vaykNCiAJICAgIHsNCiAJICAgICAgLyogRmFzdCB0cmFjayBmb3Igbm8g Y29uc3RyYWludHMgYXQgYWxsLgkqLw0KLQkgICAgICBjdXJyX2FsdFtub3Bd ID0gTk9fUkVHUzsNCi0JICAgICAgQ0xFQVJfSEFSRF9SRUdfU0VUIChjdXJy X2FsdF9zZXRbbm9wXSk7DQorCSAgICAgIGN1cnJfYWx0W25vcF0gPSBBTExf UkVHUzsNCisJICAgICAgQ09QWV9IQVJEX1JFR19TRVQgKGN1cnJfYWx0X3Nl dFtub3BdLA0KKwkJCQkgcmVnX2NsYXNzX2NvbnRlbnRzW0FMTF9SRUdTXSk7 DQogCSAgICAgIGN1cnJfYWx0X3dpbltub3BdID0gdHJ1ZTsNCiAJICAgICAg Y3Vycl9hbHRfbWF0Y2hfd2luW25vcF0gPSBmYWxzZTsNCiAJICAgICAgY3Vy cl9hbHRfb2ZmbWVtb2tbbm9wXSA9IGZhbHNlOw0KSW5kZXg6IGdjYy9yZWNv Zy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gZ2NjL3JlY29nLmMJ KHJldmlzaW9uIDIzNzEzMykNCisrKyBnY2MvcmVjb2cuYwkod29ya2luZyBj b3B5KQ0KQEAgLTE3NzgsNiArMTc3OCwxMCBAQCBhc21fb3BlcmFuZF9vayAo cnR4IG9wLCBjb25zdCBjaGFyICpjb25zdHJhaW50LCBjbw0KIAkgICAgcmVz dWx0ID0gMTsNCiAJICBicmVhazsNCiANCisJY2FzZSAnWCc6DQorCSAgaWYg KHNjcmF0Y2hfb3BlcmFuZCAob3AsIFZPSURtb2RlKSkNCisJICAgIHJlc3Vs dCA9IDE7DQorCSAgLyogLi4uIGZhbGwgdGhyb3VnaCAuLi4gICovDQogCWNh c2UgJ2cnOg0KIAkgIGlmIChnZW5lcmFsX29wZXJhbmQgKG9wLCBWT0lEbW9k ZSkpDQogCSAgICByZXN1bHQgPSAxOw0KSW5kZXg6IGdjYy90ZXN0c3VpdGUv Z2NjLmRnL3RvcnR1cmUvcHI1OTE1NS0xLmMNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCi0tLSBnY2MvdGVzdHN1aXRlL2djYy5kZy90b3J0dXJlL3ByNTkx NTUtMS5jCShyZXZpc2lvbiAwKQ0KKysrIGdjYy90ZXN0c3VpdGUvZ2NjLmRn L3RvcnR1cmUvcHI1OTE1NS0xLmMJKHdvcmtpbmcgY29weSkNCkBAIC0wLDAg KzEsOCBAQA0KKy8qIHsgZGctZG8gY29tcGlsZSB9ICovDQorZG91YmxlIGYo ZG91YmxlIHgpew0KKyAgYXNtIHZvbGF0aWxlKCIiOiIrWCIoeCkpOw0KKyAg cmV0dXJuIHg7DQorfQ0KK2RvdWJsZSBnKGRvdWJsZSB4LGRvdWJsZSB5KXsN CisgIHJldHVybiBmKGYoeCkrZih5KSk7DQorfQ0KSW5kZXg6IGdjYy90ZXN0 c3VpdGUvZ2NjLmRnL3RvcnR1cmUvcHI1OTE1NS0yLmMNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCi0tLSBnY2MvdGVzdHN1aXRlL2djYy5kZy90b3J0dXJl L3ByNTkxNTUtMi5jCShyZXZpc2lvbiAwKQ0KKysrIGdjYy90ZXN0c3VpdGUv Z2NjLmRnL3RvcnR1cmUvcHI1OTE1NS0yLmMJKHdvcmtpbmcgY29weSkNCkBA IC0wLDAgKzEsOCBAQA0KKy8qIHsgZGctZG8gY29tcGlsZSB9ICovDQorZG91 YmxlIGYoZG91YmxlIHgpew0KKyAgYXNtIHZvbGF0aWxlKCIiOiIrWCIoeCkp Ow0KKyAgcmV0dXJuIHg7DQorfQ0KK2RvdWJsZSBnKCl7DQorICByZXR1cm4g ZigxLik7DQorfQ0KSW5kZXg6IGdjYy90ZXN0c3VpdGUvZ2NjLmRnL3RvcnR1 cmUvcHI1OTE1NS0zLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBn Y2MvdGVzdHN1aXRlL2djYy5kZy90b3J0dXJlL3ByNTkxNTUtMy5jCShyZXZp c2lvbiAwKQ0KKysrIGdjYy90ZXN0c3VpdGUvZ2NjLmRnL3RvcnR1cmUvcHI1 OTE1NS0zLmMJKHdvcmtpbmcgY29weSkNCkBAIC0wLDAgKzEsMjcgQEANCit2 b2lkDQorbm9wcm9wMSAoaW50ICoqeCwgaW50IHksIGludCB6KQ0KK3sNCisg IGludCAqcHRyID0gKnggKyB5ICogeiAvIDExOw0KKyAgYXNtIHZvbGF0aWxl ICgibm9wcm9wMSAlMCIgOiA6ICJYIiAoKnB0cikpOw0KK30NCisNCit2b2lk DQorbm9wcm9wMiAoaW50ICoqeCwgaW50IHksIGludCB6KQ0KK3sNCisgIGlu dCAqcHRyID0gKnggKyB5ICogeiAvIDExOw0KKyAgYXNtIHZvbGF0aWxlICgi bm9wcm9wMiAlMCIgOiA6ICJYIiAocHRyKSk7DQorfQ0KKw0KK2ludCAqZ2xv YmFsX3ZhcjsNCisNCit2b2lkDQorY29uc3QxICh2b2lkKQ0KK3sNCisgIGFz bSB2b2xhdGlsZSAoImNvbnN0MSAlMCIgOiA6ICJYIiAoZ2xvYmFsX3Zhcikp Ow0KK30NCisNCit2b2lkDQorY29uc3QyICh2b2lkKQ0KK3sNCisgIGFzbSB2 b2xhdGlsZSAoImNvbnN0MiAlMCIgOiA6ICJYIiAoKmdsb2JhbF92YXIpKTsN Cit9DQo= --_003_AM4PR0701MB2162A54B3CAFABC7BE6FD859E4290AM4PR0701MB2162_--