From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118720 invoked by alias); 1 Jul 2015 12:31:50 -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 118709 invoked by uid 89); 1 Jul 2015 12:31:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: DUB004-OMC3S32.hotmail.com Received: from dub004-omc3s32.hotmail.com (HELO DUB004-OMC3S32.hotmail.com) (157.55.2.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Wed, 01 Jul 2015 12:31:44 +0000 Received: from DUB118-W35 ([157.55.2.8]) by DUB004-OMC3S32.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 1 Jul 2015 05:31:41 -0700 X-TMN: [IT6Mxv0CD+60Enejxr5OxGb+4FeFIavC] Message-ID: From: Bernd Edlinger To: "gcc-patches@gcc.gnu.org" CC: Richard Biener , Jakub Jelinek , Jeff Law , Eric Botcazou Subject: RE: [PING] [RFC] Sanitize rtx_addr_can_trap_p_1 Date: Wed, 01 Jul 2015 12:31:00 -0000 In-Reply-To: References: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg00042.txt.bz2 Hi, the bogus offsets-issue is now entered in bugzilla, see PR66614. It is however only a very minor issue, and does probably have no impact on the generated code at all. How should I continue with the rtx_addr_can_trap-patch? Is it OK to commit? Thanks Bernd. ---------------------------------------- > From: bernd.edlinger@hotmail.de > To: gcc-patches@gcc.gnu.org > CC: richard.guenther@gmail.com; jakub@redhat.com; law@redhat.com; ebotcaz= ou@adacore.com > Subject: RE: [RFC] Sanitize rtx_addr_can_trap_p_1 > Date: Mon, 15 Jun 2015 05:50:46 +0200 > > Hi, > > I have here an updated patch, which improves two things: > > First it moves debug code out to an extra patch, as suggested by Jakub. > > Secondly, it fixes the checks on STACK_GROWS_DOWNWARD and > ARGS_GROW_DOWNWARD. Previously these used to be conditionally defined > symbols, but recently they were changed to be always defined, but with 0 = or 1. > > That made all #ifndef checks on those two flags work the wrong way, and i= t caused > most of the false positives in the previous version. > > Now the number of false positives in the stage2 drops significantly to on= ly 4 new ones: > > *** argp can trap: function=3Duw_init_context_1, pass=3Dreload, offset=3D= 236, size=3D4, low_bound=3D-16, high_bound=3D16 > *** argp can trap: function=3Duw_init_context_1, pass=3Dreload, offset=3D= 236, size=3D4, low_bound=3D-16, high_bound=3D16 > *** argp can trap: function=3Duw_init_context_1, pass=3Dreload, offset=3D= 440, size=3D8, low_bound=3D-16, high_bound=3D16 > *** argp can trap: function=3Duw_init_context_1, pass=3Dreload, offset=3D= 440, size=3D8, low_bound=3D-16, high_bound=3D16 > > These came from libgcc/unwind-dw2.c > > They seem to have the same reason as the 2930 "frame can trap" warnings t= hat were already > there before the patch. > > > All these seem to happen due to some hidden bug. In the debugger the cal= l stack looks always like this: > > #0 rtx_addr_can_trap_p_1 (x=3D0x7ffff6ecb378, offset=3D440, size=3D8, mo= de=3DDImode, unaligned_mems=3Dfalse) at ../../gcc-trunk/gcc/rtlanal.c:671 > #1 0x0000000000d90f4a in rtx_addr_can_trap_p_1 (x=3D0x7ffff67ac7f8, offs= et=3D0, size=3D8, mode=3DDImode, unaligned_mems=3Dfalse) at ../../gcc-trunk= /gcc/rtlanal.c:699 > #2 0x0000000000d953c4 in may_trap_p_1 (x=3D0x7ffff67ac810, flags=3D0) at= ../../gcc-trunk/gcc/rtlanal.c:2760 > #3 0x0000000000d95619 in may_trap_p_1 (x=3D0x7ffff671ac90, flags=3D0) at= ../../gcc-trunk/gcc/rtlanal.c:2838 > #4 0x0000000000d956cc in may_trap_p (x=3D0x7ffff671ac90) at ../../gcc-tr= unk/gcc/rtlanal.c:2857 > #5 0x0000000000c6b2ab in process_bb_lives (bb=3D0x7ffff6c3a958, curr_poi= nt=3D@0x7fffffffd8e4: 23, dead_insn_p=3Dtrue) at ../../gcc-trunk/gcc/lra-li= ves.c:698 > #6 0x0000000000c6d19a in lra_create_live_ranges_1 (all_p=3Dtrue, dead_in= sn_p=3Dtrue) at ../../gcc-trunk/gcc/lra-lives.c:1262 > #7 0x0000000000c6d47c in lra_create_live_ranges (all_p=3Dtrue, dead_insn= _p=3Dtrue) at ../../gcc-trunk/gcc/lra-lives.c:1327 > #8 0x0000000000c4a253 in lra (f=3D0x24f7940) at ../../gcc-trunk/gcc/lra.= c:2309 > #9 0x0000000000bf3d25 in do_reload () at ../../gcc-trunk/gcc/ira.c:5401 > #10 0x0000000000bf40d3 in (anonymous namespace)::pass_reload::execute (th= is=3D0x23fce20) at ../../gcc-trunk/gcc/ira.c:5572 > #11 0x0000000000d08e37 in execute_one_pass (pass=3D0x23fce20) at ../../gc= c-trunk/gcc/passes.c:2359 > #12 0x0000000000d09081 in execute_pass_list_1 (pass=3D0x23fce20) at ../..= /gcc-trunk/gcc/passes.c:2412 > #13 0x0000000000d090b2 in execute_pass_list_1 (pass=3D0x23fbda0) at ../..= /gcc-trunk/gcc/passes.c:2413 > #14 0x0000000000d090ef in execute_pass_list (fn=3D0x7ffff7044c78, pass=3D= 0x23f8bc0) at ../../gcc-trunk/gcc/passes.c:2423 > #15 0x00000000008de80c in cgraph_node::expand (this=3D0x7ffff6c09498) at = ../../gcc-trunk/gcc/cgraphunit.c:1937 > #16 0x00000000008dee3d in expand_all_functions () at ../../gcc-trunk/gcc/= cgraphunit.c:2073 > #17 0x00000000008df954 in symbol_table::compile (this=3D0x7ffff6ecf000) a= t ../../gcc-trunk/gcc/cgraphunit.c:2426 > #18 0x00000000008dfb68 in symbol_table::finalize_compilation_unit (this= =3D0x7ffff6ecf000) at ../../gcc-trunk/gcc/cgraphunit.c:2513 > #19 0x0000000000e094ba in compile_file () at ../../gcc-trunk/gcc/toplev.c= :580 > #20 0x0000000000e0b9fa in do_compile () at ../../gcc-trunk/gcc/toplev.c:2= 070 > #21 0x0000000000e0bc46 in toplev::main (this=3D0x7fffffffdc50, argc=3D35,= argv=3D0x7fffffffdd58) at ../../gcc-trunk/gcc/toplev.c:2171 > #22 0x00000000016b656d in main (argc=3D35, argv=3D0x7fffffffdd58) at ../.= ./gcc-trunk/gcc/main.c:39 > > I cannot find any instruction in the rtl dumps that corresponds to this l= arge argp offset. So I think there must be > something wrong along the call stack above, which looks identically even = on the bogus frame pointer references. > > > Is this patch OK for trunk now? > > At least Jakub and I are in favour of it, Eric is against it. > That makes 2:1 ... > > > Thanks > Bernd. > =20=09=09=20=09=20=20=20=09=09=20=20