From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31594 invoked by alias); 12 Feb 2015 19:39:41 -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 31570 invoked by uid 89); 12 Feb 2015 19:39:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ob0-f177.google.com Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 12 Feb 2015 19:39:39 +0000 Received: by mail-ob0-f177.google.com with SMTP id wp18so11695607obc.8 for ; Thu, 12 Feb 2015 11:39:37 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.130.135 with SMTP id oe7mr3952705oeb.5.1423769977442; Thu, 12 Feb 2015 11:39:37 -0800 (PST) Received: by 10.76.72.42 with HTTP; Thu, 12 Feb 2015 11:39:37 -0800 (PST) In-Reply-To: References: <20150206162314.GA12597@intel.com> <20150207122739.GA25185@gmail.com> <20150207155606.GA14159@gmail.com> <20150207164507.GA19402@gmail.com> <54DA75D2.40402@redhat.com> <54DC46BF.5060503@redhat.com> Date: Thu, 12 Feb 2015 19:39:00 -0000 Message-ID: Subject: Re: [PATCH] PR rtl-optimization/32219: optimizer causees wrong code in pic/hidden/weak symbol checking From: Jack Howarth To: "H.J. Lu" Cc: Richard Henderson , GCC Patches , Mike Stump , Iain Sandoe , Jan Hubicka Content-Type: multipart/mixed; boundary=089e01229faabf84e4050ee94736 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00791.txt.bz2 --089e01229faabf84e4050ee94736 Content-Type: text/plain; charset=UTF-8 Content-length: 4207 On Thu, Feb 12, 2015 at 2:18 PM, H.J. Lu wrote: > On Thu, Feb 12, 2015 at 11:16 AM, Jack Howarth wrote: >> H.J., >> Oddly I saw no regressions in the g++ test suite at -m32/-m64 on >> x86_64-apple-darwin14. >> Jack > > They have > > // { dg-require-effective-target tls } > > Does x86_64-apple-darwin14 support TLS? If yes, what does the > generated assembly code look like? We use emutls on darwin. Those failing test are run at -m32/-m64... Executing on host: /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/gcc/testsuite/g++.dg/gomp/tls-wrap4.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0 -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++11 -fPIC -S -m64 -o tls-wrap4.s (timeout = 300) spawn -ignore SIGHUP /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/gcc/testsuite/g++.dg/gomp/tls-wrap4.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0 -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++11 -fPIC -S -m64 -o tls-wrap4.s^M PASS: g++.dg/gomp/tls-wrap4.C -std=gnu++11 (test for excess errors) PASS: g++.dg/gomp/tls-wrap4.C -std=gnu++11 scan-assembler-not _ZTW1i@PLT and produce the attached assembly. Jack > >> On Thu, Feb 12, 2015 at 1:16 PM, H.J. Lu wrote: >>> On Wed, Feb 11, 2015 at 10:22 PM, Richard Henderson wrote: >>>> On 02/10/2015 01:19 PM, Richard Henderson wrote: >>>>> As an existing issue, I'm not sure why "specified" visibility is any different >>>>> from unspecified visibility. As far as I'm aware, the "specified" bit simply >>>>> means that the decl doesn't inherit inherit visibility from the class, or from >>>>> the command-line. But once we're this far, the visibility actually applied to >>>>> the symbol should be all that matters. >>>> >>>> The test is there to differentiate explicit visibility from that implied from >>>> the command-line. Without it, we assume hidden visibility for external symbols >>>> too early, making the command-line option useless. This is visible even in >>>> building libgcc. >>>> >>>> I believe this set of patches does what we want, and cleans things up a bit in >>>> the process. >>>> >>>> >>> >>> I tried them on Linux/x86-64. They caused: >>> >>> FAIL: g++.dg/gomp/tls-wrap4.C -std=gnu++11 scan-assembler-not _ZTW1i@PLT >>> FAIL: g++.dg/gomp/tls-wrap4.C -std=gnu++11 scan-assembler-not _ZTW1i@PLT >>> FAIL: g++.dg/gomp/tls-wrap4.C -std=gnu++14 scan-assembler-not _ZTW1i@PLT >>> FAIL: g++.dg/gomp/tls-wrap4.C -std=gnu++14 scan-assembler-not _ZTW1i@PLT >>> FAIL: g++.dg/tls/thread_local-wrap4.C -std=gnu++11 >>> scan-assembler-not _ZTW1i@PLT >>> FAIL: g++.dg/tls/thread_local-wrap4.C -std=gnu++11 >>> scan-assembler-not _ZTW1i@PLT >>> FAIL: g++.dg/tls/thread_local-wrap4.C -std=gnu++14 >>> scan-assembler-not _ZTW1i@PLT >>> FAIL: g++.dg/tls/thread_local-wrap4.C -std=gnu++14 >>> scan-assembler-not _ZTW1i@PLT >>> >>> >>> -- >>> H.J. > > > > -- > H.J. --089e01229faabf84e4050ee94736 Content-Type: application/octet-stream; name="tls-wrap4.s" Content-Disposition: attachment; filename="tls-wrap4.s" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i62jvjf40 Content-length: 2262 CS5zZWN0aW9uIF9fVEVYVCxfX3RleHRjb2FsX250LGNvYWxlc2NlZCxwdXJl X2luc3RydWN0aW9ucwoJLmdsb2JsIF9fWlRXMWkKCS53ZWFrX2RlZmluaXRp b24gX19aVFcxaQoJLnByaXZhdGVfZXh0ZXJuIF9fWlRXMWkKX19aVFcxaToK TEZCMToKCXB1c2hxCSVyYnAKTENGSTA6Cgltb3ZxCSVyc3AsICVyYnAKTENG STE6Cgltb3ZxCV9fX2VtdXRsc192LmlAR09UUENSRUwoJXJpcCksICVyYXgK CW1vdnEJJXJheCwgJXJkaQoJY2FsbAlfX19lbXV0bHNfZ2V0X2FkZHJlc3MK CXBvcHEJJXJicApMQ0ZJMjoKCXJldApMRkUxOgoJLnRleHQKCS5nbG9ibCBf bWFpbgpfbWFpbjoKTEZCMDoKCXB1c2hxCSVyYnAKTENGSTM6Cgltb3ZxCSVy c3AsICVyYnAKTENGSTQ6CgljYWxsCV9fWlRXMWkKCW1vdmwJKCVyYXgpLCAl ZWF4CglzdWJsCSQ0MiwgJWVheAoJcG9wcQklcmJwCkxDRkk1OgoJcmV0CkxG RTA6Cgkuc2VjdGlvbiBfX1RFWFQsX19laF9mcmFtZSxjb2FsZXNjZWQsbm9f dG9jK3N0cmlwX3N0YXRpY19zeW1zK2xpdmVfc3VwcG9ydApFSF9mcmFtZTE6 Cgkuc2V0IEwkc2V0JDAsTEVDSUUxLUxTQ0lFMQoJLmxvbmcgTCRzZXQkMApM U0NJRTE6CgkubG9uZwkwCgkuYnl0ZQkweDEKCS5hc2NpaSAielJcMCIKCS5i eXRlCTB4MQoJLmJ5dGUJMHg3OAoJLmJ5dGUJMHgxMAoJLmJ5dGUJMHgxCgku Ynl0ZQkweDEwCgkuYnl0ZQkweGMKCS5ieXRlCTB4NwoJLmJ5dGUJMHg4Cgku Ynl0ZQkweDkwCgkuYnl0ZQkweDEKCS5hbGlnbiAzCkxFQ0lFMToKTFNGREUx OgoJLnNldCBMJHNldCQxLExFRkRFMS1MQVNGREUxCgkubG9uZyBMJHNldCQx CkxBU0ZERTE6CgkubG9uZwlMQVNGREUxLUVIX2ZyYW1lMQoJLnF1YWQJTEZC MS0uCgkuc2V0IEwkc2V0JDIsTEZFMS1MRkIxCgkucXVhZCBMJHNldCQyCgku Ynl0ZQkwCgkuYnl0ZQkweDQKCS5zZXQgTCRzZXQkMyxMQ0ZJMC1MRkIxCgku bG9uZyBMJHNldCQzCgkuYnl0ZQkweGUKCS5ieXRlCTB4MTAKCS5ieXRlCTB4 ODYKCS5ieXRlCTB4MgoJLmJ5dGUJMHg0Cgkuc2V0IEwkc2V0JDQsTENGSTEt TENGSTAKCS5sb25nIEwkc2V0JDQKCS5ieXRlCTB4ZAoJLmJ5dGUJMHg2Cgku Ynl0ZQkweDQKCS5zZXQgTCRzZXQkNSxMQ0ZJMi1MQ0ZJMQoJLmxvbmcgTCRz ZXQkNQoJLmJ5dGUJMHhjCgkuYnl0ZQkweDcKCS5ieXRlCTB4OAoJLmFsaWdu IDMKTEVGREUxOgpMU0ZERTM6Cgkuc2V0IEwkc2V0JDYsTEVGREUzLUxBU0ZE RTMKCS5sb25nIEwkc2V0JDYKTEFTRkRFMzoKCS5sb25nCUxBU0ZERTMtRUhf ZnJhbWUxCgkucXVhZAlMRkIwLS4KCS5zZXQgTCRzZXQkNyxMRkUwLUxGQjAK CS5xdWFkIEwkc2V0JDcKCS5ieXRlCTAKCS5ieXRlCTB4NAoJLnNldCBMJHNl dCQ4LExDRkkzLUxGQjAKCS5sb25nIEwkc2V0JDgKCS5ieXRlCTB4ZQoJLmJ5 dGUJMHgxMAoJLmJ5dGUJMHg4NgoJLmJ5dGUJMHgyCgkuYnl0ZQkweDQKCS5z ZXQgTCRzZXQkOSxMQ0ZJNC1MQ0ZJMwoJLmxvbmcgTCRzZXQkOQoJLmJ5dGUJ MHhkCgkuYnl0ZQkweDYKCS5ieXRlCTB4NAoJLnNldCBMJHNldCQxMCxMQ0ZJ NS1MQ0ZJNAoJLmxvbmcgTCRzZXQkMTAKCS5ieXRlCTB4YwoJLmJ5dGUJMHg3 CgkuYnl0ZQkweDgKCS5hbGlnbiAzCkxFRkRFMzoKCS5jb25zdHJ1Y3RvcgoJ LmRlc3RydWN0b3IKCS5hbGlnbiAxCgkuc3Vic2VjdGlvbnNfdmlhX3N5bWJv bHMK --089e01229faabf84e4050ee94736--