From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129921 invoked by alias); 2 Sep 2017 14:33:30 -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 129902 invoked by uid 89); 2 Sep 2017 14:33:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 02 Sep 2017 14:33:24 +0000 Received: by mail-wm0-f67.google.com with SMTP id l19so2581299wmi.1 for ; Sat, 02 Sep 2017 07:33:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=x6wr/15Rlxziyt2fu9hLjRNblmTwQGAvJIh3ih3FtSQ=; b=IgTt7nPNsPNCN0UNY+eNEG/1AXBYcl8EGroZNsJqOIfEMOkMppxtHE7ETtSNACEFf6 NJB266uPyFs+hn4xU20DQBO/6MgPvVL3vAlbAxdSCE8QhLdKTuhVmrC12N7oCdzUryrX yKg2aJEiAQ91aZUSAeRNMUUMJxKA4GY/qSq+Ufq0AZSfto0BdpHHI9U5YK2x71ztgLHb qqrsX5AGHih2YbnGarDo9XeNBXt45dnQszfMR6hCpc/uVr29fSMLGH9s7J/6QoyygNxQ nX2tQUDIBKA+6zdpy3W7uG+XI/PqFZuZS46Kw0JMsY8hdCLpEld76vPvm8aZZ6hN1wHt Kbkw== X-Gm-Message-State: AHPjjUjaPWYLiRkO1mzAqwoVN0GU9a+TK6nCd6LlXYxO2qa5BRB6AlXr jV4/5+8izajvZvN3WHE= X-Google-Smtp-Source: ADKCNb5gIGTMwZH5P15TxqBzmNCunuSOhe1ceuA7CJub/LRVJZ9KuO9Na+ETHY1Q79TMnQ7DivcVQg== X-Received: by 10.80.148.7 with SMTP id p7mr779807eda.23.1504362802296; Sat, 02 Sep 2017 07:33:22 -0700 (PDT) Received: from android-f83b394395796e13.fritz.box (p5494E583.dip0.t-ipconnect.de. [84.148.229.131]) by smtp.gmail.com with ESMTPSA id f41sm1379553edf.36.2017.09.02.07.33.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Sep 2017 07:33:21 -0700 (PDT) Date: Sat, 02 Sep 2017 14:33:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <4078981.6jQ9KEkrUD@polaris> References: <4078981.6jQ9KEkrUD@polaris> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [C++] Fix PR bootstrap/81926 To: gcc-patches@gcc.gnu.org,Eric Botcazou From: Richard Biener Message-ID: <8F5955E0-4B06-4668-9BCC-233E90F6F7A0@gmail.com> X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00106.txt.bz2 On September 2, 2017 1:01:11 PM GMT+02:00, Eric Botcazou wrote: >Hi, > >this is the bootstrap failure reported for the 7 branch on >SPARC64/Solaris: > >Comparing stages 2 and 3 >Bootstrap comparison failure! >gcc/go/parse.o differs >make[2]: *** [compare] Error 1 > >On Solaris, the bootstrap is usually an old-style bootstrap, meaning >that the=20 >debug info is generated during stage2 & stage3 so the comparison also >involves=20 >the debug info, unlike on Linux. This can be emulated on Linux by >configuring=20 >--with-build-config=3Dno and indeed you get the comparison failure there >too: > >Target: x86_64-suse-linux >Configured with: /home/eric/svn/gcc-7.2.0/configure >--build=3Dx86_64-suse-linux=20 >--prefix=3D/home/eric/install/gcc-7.2.0 --enable-languages=3Dc,c++,go >--enable- >__cxa_atexit --disable-nls --with-build-config=3Dno >Thread model: posix >gcc version 7.2.0 (GCC)=20 > >make[3]: Leaving directory '/home/eric/build/gcc-7.2.0' >Comparing stages 2 and 3 >Bootstrap comparison failure! >gcc/go/parse.o differs >Makefile:24421: recipe for target 'compare' failed >make[2]: *** [compare] Error 1 > >The difference is: > >35 .debug_info 0016367a 0000000000000000 0000000000000000 0001faf8 > 2**0 > CONTENTS, RELOC, READONLY, DEBUGGING > >35 .debug_info 00163670 0000000000000000 0000000000000000 0001faf8 > 2**0 > CONTENTS, RELOC, READONLY, DEBUGGING > > .byte 0 ! end of children of DIE 0x161dbc > .byte 0 ! end of children of DIE 0x161d9c > .byte 0 ! end of children of DIE 0x161d5b >- .byte 0xf2,0x1 ! uleb128 0xf2; (DIE (0x161dd2)=20 >DW_TAG_ptr_to_member_type) >- .uaword 0x10445d ! DW_AT_containing_type >- .uaword 0x14806e ! DW_AT_type >- .byte 0xa5,0x1 ! uleb128 0xa5; (DIE (0x161ddc)=20 >DW_TAG_subprogram) >+ .byte 0xa5,0x1 ! uleb128 0xa5; (DIE (0x161dd2)=20 >DW_TAG_subprogram) > .uaword 0x146733 ! DW_AT_abstract_origin > >It's a garbage collection issue similar to > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00541.html >but for build_offset_type instead of build_complex_type. > >It's called from the get_debug_type langhook in C++: > >tree >cp_get_debug_type (const_tree type) >{ > if (TYPE_PTRMEMFUNC_P (type) && !typedef_variant_p (type)) > return build_offset_type (TYPE_PTRMEMFUNC_OBJECT_TYPE (type), > TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type))); > > return NULL_TREE; >} > >Since the OFFSET_TYPEs created there are not attached to any GC root, >they are=20 >swept by every collection, meaning that the contents of the debug info >depends=20 >on the actual collection points. > >The proposed fix is to build OFFSET_TYPEs manually instead. As >witnessed by=20 >the change to g++.dg/debug/dwarf2/ref-3.C, this generates more DIEs in >the=20 >debug info, but DW_TAG_ptr_to_member_type DIEs only contain 10 bytes. A solution would be to put them into a global GCed pointer-map or vector, f= reeing that at free-lang-data time.=20 Richard.=20 >Bootstrapped on x86-64/Linux & SPARC64/Solaris, OK for mainline and 7 >branch? > > >2017-09-02 Eric Botcazou > > PR bootstrap/81926 > * cp-objcp-common.c: Include stor-layout.h. > (cp_get_debug_type): Build OFFSET_TYPEs manually. > > >2017-09-02 Eric Botcazou > > * g++.dg/debug/dwarf2/ref-3.C: Adjust DW_TAG_ptr_to_member_type count.